TCP與UDP的區別
1.TCP是面向連接的傳輸協議，傳輸前雙方需建立連接通道，而UDP可以直接傳輸。
2.TCP傳輸信息可靠，信息傳輸無差錯，不丟失，不重複，且按序到達。UDP傳輸不保證可靠。
3.TCP是字節流傳輸（較長數據分割成數據塊進行傳輸），而UDP是報文流傳輸（給多少傳多少）。
4.TCP爲了實現傳輸可靠性使用了較爲複雜的算法和實現過程，不適用於實時傳輸，UDP實時性較好。
5.每一條TCP連接只能是點對點的，UDP支持一對一，一對多，多對一，多對多。
6.TCP佔用系統資源較多，UDP相對較少。
TCP三次握手的具體過程? 並解釋爲什麼需要三次握手?
第一次握手：客戶端向服務端發出請求，發送SYN包（同步序列編號）到客戶端，並進入SYN_SENT狀態。
第二次握手：服務端獲取到SYN包後，需要回復確認ACK，同時發送自己的SYN，並進入SYN_RECV狀態。
第三次握手：客戶端獲取到服務端發送的ACK和SYN後，需要回復確認ACK，發送完畢後，兩端同時進入ESTABLISHED（TCP連接成功）狀態，完成三次握手。
分析：
TCP可視爲全雙工通信，分爲兩個通信方向：Client>>Server / Server>>Client。
第一次握手：客戶端提交數據傳輸請求。
(C提交申請，但C自身並不知道C>>S 和S>>C是否可行)
第二次握手：服務端應答客戶端，表示確認接收到客戶端數據，併發出SYN，等待客戶端應答。
(S對C的請求進行應答，S可確認C>>S可行，但不知道S>>C是否可行)
第三次握手：客戶端應答服務端，表示確認接收到服務端數據，建立連接。
(C對S請求進行應答，C可知S>>C和C>>S均可行，S接收應答後可知S>>C可行，即可建立連接)
三次握手是對可靠傳輸進行確認的必要過程，完成三次握手可確保信息傳輸的可靠性。在兩端未確認的情況下進行傳輸，可能會導致信息重發等問題出現。
TCP四次斷開連接的過程， 並分析爲什麼斷開需要四次?
第一步，當主機A的應用程序通知TCP數據已經發送完畢時，TCP向主機B發送一個帶有FIN附加標記的報文段（FIN表示英文finish）。
第二步，主機B收到這個FIN報文段之後，並不立即用FIN報文段回覆主機A，而是先向主機A發送一個確認序號ACK，同時通知自己相應的應用程序：對方要求關閉連接（先發送ACK的目的是爲了防止在這段時間內，對方重傳FIN報文段）。
第三步，主機B的應用程序告訴TCP：我要徹底的關閉連接，TCP向主機A送一個FIN報文段。
第四步，主機A收到這個FIN報文段後，向主機B發送一個ACK表示連接徹底釋放。
分析：
同樣，關閉連接前要兩端都確認自己本端和對端數據傳輸完畢。即獲取對方發送的FIN並應答(ACK)告訴對方自己獲取到了對方的FIN。
第一步，A主機給發給B主機的消息傳輸完畢，向B發送FIN，告知B自己發送完畢，準備關閉連接。
（此時A傳輸完畢發出FIN，但不知道B是否發送完畢，也不知道B是否接收到自己的FIN報文）
第二步，B主機在未發送完畢的情況下接收到A的FIN，向A回覆ACK且通知本機應用層，並將未發送完畢的數據繼續發送完。
（B得知A發送完畢，A接收ACK後得知B接收到自己發送的FIN報文）
第三步，B主機發送完畢後，發出FIN報文，並等待A的應答（2MSL內沒有收到A的應答，則重發）
（B傳輸完畢，但不知道A是否接收到自己的FIN報文）
（MSL指一個片段在網絡中最大的存活時間，2MSL就是一個發送和一個回覆所需的最大時間）
第四步，A收到B的FIN報文，做出ACK應答，在等待2MSL後自行關閉。
（A應答，B收到後得知A收到了自己的FIN報文，B關閉，A在2MSL內沒有收到B的FIN重發，判斷B已經收到了自己的ACK，A關閉）
四次揮手可以看作是改良版的三次握手，只不過在第二次握手時考慮到B端數據沒有發送完畢的情況，因此ACK和FIN分兩次進行發送，變成了四次。
