簡介
TCP和UDP協議都位於OSI七層模型中的傳輸層，處於IP協議的上一層，隸屬於TCP/IP協議簇，如果你不清楚TCP/IP協議，請看我寫的另外一篇文章：Android網絡編程（二）：TCP/IP協議詳解
TCP和TCP是傳輸層的兩個主要協議，互爲補充，都是用於處理數據包。UDP支持無連接傳輸，是不可靠的，但是傳輸性能好；TCP是面向連接的，可靠性更高，用得也最多。
UDP協議
UDP協議全稱是用戶數據報協議，在網絡中它與TCP協議一樣用於處理數據包，是一種無連接的協議。UDP有不提供數據包分組、組裝和不能對數據包進行排序的缺點，也就是說，當報文發送之後，是無法得知其是否安全完整到達的。
UDP不屬於連接型協議，因而具有資源消耗小，處理速度快的優點，所以通常音頻、視頻和普通數據在傳送時使用UDP較多，因爲它們即使偶爾丟失一兩個數據包，也不會對接收結果產生太大影響。比如我們聊天用的QQ就是使用的UDP協議。
UDP應用場景：
1.面向數據報方式
2.網絡數據大多爲短消息
3.擁有大量Client
4.對數據安全性無特殊要求
5.網絡負擔非常重，但對響應速度要求高
TCP協議
傳輸控制協議（TCP，Transmission Control Protocol）是一種面向連接的、可靠的、基於字節流的傳輸層通信協議。
應用層向TCP層發送用於網間傳輸的、用8位字節表示的數據流，然後TCP把數據流分區成適當長度的報文段之後TCP把結果包傳給IP層，由它來通過網絡將包傳送給接收端實體的TCP層。TCP爲了保證不發生丟包，就給每個包一個序號，同時序號也保證了傳送到接收端實體的包的按序接收。然後接收端實體對已成功收到的包發回一個相應的確認（ACK）；如果發送端實體在合理的往返時延（RTT）內未收到確認，那麼對應的數據包就被假設爲已丟失將會被進行重傳。TCP用一個校驗和函數來檢驗數據是否有錯誤；在發送和接收時都要計算校驗和。
TCP頭部消息
-
源、目標端口號字段：佔16比特。TCP協議通過使用”端口”來標識源端和目標端的應用進程。端口號可以使用0到65535之間的任何數字。在收到服務請求時，操作系統動態地爲客戶端的應用程序分配端口號。在服務器端，每種服務在”衆所周知的端口”（Well-Know Port）爲用戶提供服務。
-
順序號字段：佔32比特。用來標識從TCP源端向TCP目標端發送的數據字節流，它表示在這個報文段中的第一個數據字節。
-
確認號字段：佔32比特。只有ACK標誌爲1時，確認號字段纔有效。它包含目標端所期望收到源端的下一個數據字節。
-
頭部長度字段：佔4比特。給出頭部佔32比特的數目。沒有任何選項字段的TCP頭部長度爲20字節；最多可以有60字節的TCP頭部。
-
標誌位字段（U、A、P、R、S、F）：佔6比特。各比特的含義如下：
◆URG：緊急指針（urgent pointer）有效。
◆ACK：爲1時，確認序號有效。
◆PSH：爲1時，接收方應該儘快將這個報文段交給應用層。
◆RST：爲1時，重建連接。
◆SYN：爲1時，同步程序，發起一個連接。
◆FIN：爲1時，發送端完成任務，釋放一個連接。 -
窗口大小字段：佔16比特。此字段用來進行流量控制。單位爲字節數，這個值是本機期望一次接收的字節數。
-
TCP校驗和字段：佔16比特。對整個TCP報文段，即TCP頭部和TCP數據進行校驗和計算，並由目標端進行驗證。
-
緊急指針字段：佔16比特。它是一個偏移量，和序號字段中的值相加表示緊急數據最後一個字節的序號。
-
選項字段：佔32比特。可能包括”窗口擴大因子”、”時間戳”等選項。
TCP建立三次連接的過程（三次握手）
TCP是因特網中的傳輸層協議，使用三次握手協議建立連接。當主動方發出SYN連接請求後，等待對方回答 SYN + ACK ，並最終對對方的 SYN 執行 ACK 確認。這種建立連接的方法可以防止產生錯誤的連接，TCP 使用的流量控制協議是可變大小的滑動窗口協議。
TCP三次握手的過程如下：
- 客戶端發送 SYN（SEQ=x）報文給服務器端，進入 SYN_SEND 狀態。
- 服務器端收到 SYN 報文，迴應一個 SYN （SEQ=y）ACK(ACK=x+1）報文，進入 SYN_RECV 狀態。
- 客戶端收到服務器端的 SYN 報文，迴應一個 ACK(ACK=y+1）報文，進入 Established 狀態。
三次握手完成，TCP客戶端和服務器端成功地建立連接，可以開始傳輸數據了。
三次握手可以簡單理解爲A、B兩人開始連麥開黑：
A：聽到嗎？ （第一次握手）
B：聽得到，你能聽到我的聲音嗎？ （第二次握手）
A：能聽到。 （第三次握手）
ok，麥沒問題，開始遊戲
TCP終止連接過程（四次揮手）
- 客戶端進程發出連接釋放報文，並且停止發送數據。釋放數據報文首部，FIN=1，其序列號爲seq=u（等於前面已經傳送過來的數據的最後一個字節的序號加1），此時，客戶端進入FIN-WAIT-1（終止等待1）狀態。TCP規定，FIN報文段即使不攜帶數據，也要消耗一個序號。
- 服務器收到連接釋放報文，發出確認報文，ACK=1，ack=u+1，並且帶上自己的序列號seq=v，此時，服務端就進入了CLOSE-WAIT（關閉等待）狀態。TCP服務器通知高層的應用進程，客戶端向服務器的方向就釋放了，這時候處於半關閉狀態，即客戶端已經沒有數據要發送了，但是服務器若發送數據，客戶端依然要接受。這個狀態還要持續一段時間，也就是整個CLOSE-WAIT狀態持續的時間。客戶端收到服務器的確認請求後，此時，客戶端就進入FIN-WAIT-2（終止等待2）狀態，等待服務器發送連接釋放報文（在這之前還需要接受服務器發送的最後的數據）。
- 服務器將最後的數據發送完畢後，就向客戶端發送連接釋放報文，FIN=1，ack=u+1，由於在半關閉狀態，服務器很可能又發送了一些數據，假定此時的序列號爲seq=w，此時，服務器就進入了LAST-ACK（最後確認）狀態，等待客戶端的確認。客戶端收到服務器的連接釋放報文後，必須發出確認，ACK=1，ack=w+1，而自己的序列號是seq=u+1，此時，客戶端就進入了TIME-WAIT（時間等待）狀態。注意此時TCP連接還沒有釋放，必須經過2∗MSL（最長報文段壽命）的時間後，當客戶端撤銷相應的TCB後，才進入CLOSED狀態。
- 服務器只要收到了客戶端發出的確認，立即進入CLOSED狀態。同樣，撤銷TCB後，就結束了這次的TCP連接。可以看到，服務器結束TCP連接的時間要比客戶端早一些。
四次揮手可以簡單地理解爲A、B兩人結束對話：
A：我已經講完了。 （第一次揮手）
B：知道啦。 （第二次揮手）
B：但是我還沒講完，我跟你講哦%#￥#￥%#… （A在聽B講完）
B：我講完啦。 （第三次揮手）
A：收到。 （第四次揮手）
然後各回各家，各找各媽