目錄

• • TCP 協議
  • UDP協議
  • TCP和UDP的區別
  • TCP和UDP的使用場景

一 TCP協議

1.TCP的頭部格式

理解TCP協議，首要的就是TCP協議的頭部格式

· Source Port和Destination Port:分別占用16位，表示源端口號和目的端口號；用於區別主機中的不同進程，而IP地址是用來區分不同的主機的，源端口號和目的端口號配合上IP首部中的源IP地址和目的IP地址就能唯一的確定一個TCP連接；

· Sequence Number:用來標識從TCP發端向TCP收端發送的數據字節流，它表示在這個報文段中的的第一個數據字節在數據流中的序號；主要用來解決網絡報亂序的問題

· Acknowledgment Number:32位確認序列號包含發送確認的一端所期望收到的下一個序號，因此，確認序號應當是上次已成功收到數據字節序號加1。不過，只有當標誌位中的ACK標誌（下面介紹）為1時該確認序列號的字段才有效。主要用來解決不丟包的問題；

· Offset:給出首部中32 bit字的數目，需要這個值是因為任選字段的長度是可變的。這個字段占4bit（最多能表示15個32bit的的字，即4*15=60個字節的首部長度），因此TCP最多有60字節的首部。然而，沒有任選字段，正常的長度是20字節；

· TCP Flags:TCP首部中有6個標誌比特，它們中的多個可同時被設置為

· URG：此標誌表示TCP包的緊急指針域（後面馬上就要說到）有效，用來保證TCP連接不被中斷，並且督促中間層設備要盡快處理這些數據；

· ACK：此標誌表示應答域有效，就是說前面所說的TCP應答號將會包含在TCP數據包中；有兩個取值：0和1，為1的時候表示應答域有效，反之為0；

· PSH：這個標誌位表示Push操作。所謂Push操作就是指在數據包到達接收端以後，立即傳送給應用程序，而不是在緩沖區中排隊；

· RST：這個標誌表示連接復位請求。用來復位那些產生錯誤的連接，也被用來拒絕錯誤和非法的數據包；

· SYN：表示同步序號，用來建立連接。SYN標誌位和ACK標誌位搭配使用，當連接請求的時候，SYN=1，ACK=0；連接被響應的時候，SYN=1，ACK=1；這個標誌的數據包經常被用來進行端口掃描。

· FIN： 表示發送端已經達到數據末尾，也就是說雙方的數據傳送完成，沒有數據可以傳送了，發送FIN標誌位的TCP數據包後，連接將被斷開。這個標誌的數據包也經常被用於進行端口掃描。

· Window:窗口大小，也就是有名的滑動窗口，用來進行流量控制；這是一個復雜的問題，這篇博文中並不會進行總結的；

2.三次握手建立連接

1. 第一次握手：建立連接。客戶端發送連接請求報文段，將SYN位置為1，Sequence Number為x；然後，客戶端進入SYN_SEND狀態，等待服務器的確認；

2. 第二次握手：服務器收到SYN報文段。服務器收到客戶端的SYN報文段，需要對這個SYN報文段進行確認，設置Acknowledgment Number為x+1(Sequence Number+1)；同時，自己自己還要發送SYN請求信息，將SYN位置為1，Sequence Number為y；服務器端將上述所有信息放到一個報文段（即SYN+ACK報文段）中，一並發送給客戶端，此時服務器進入SYN_RECV狀態；

3. 第三次握手：客戶端收到服務器的SYN+ACK報文段。然後將Acknowledgment Number設置為y+1，向服務器發送ACK報文段，這個報文段發送完畢以後，客戶端和服務器端都進入ESTABLISHED狀態，完成TCP三次握手

3.四次揮手

1. 第一次分手：主機1（可以使客戶端，也可以是服務器端），設置Sequence Number和Acknowledgment Number，向主機2發送一個FIN報文段；此時，主機1進入FIN_WAIT_1狀態；這表示主機1沒有數據要發送給主機2了；

2. 第二次分手：主機2收到了主機1發送的FIN報文段，向主機1回一個ACK報文段，Acknowledgment Number為Sequence Number加1；主機1進入FIN_WAIT_2狀態；主機2告訴主機1，我“同意”你的關閉請求；

3. 第三次分手：主機2向主機1發送FIN報文段，請求關閉連接，同時主機2進入LAST_ACK狀態；

4. 第四次分手：主機1收到主機2發送的FIN報文段，向主機2發送ACK報文段，然後主機1進入TIME_WAIT狀態；主機2收到主機1的ACK報文段以後，就關閉連接；此時，主機1等待2MSL後依然沒有收到回復，則證明Server端已正常關閉，那好，主機1也可以關閉連接了。

問題一 為什麽需要三次握手？

為了防止已失效的連接請求報文段突然又傳送到了服務端，不采用三次握手，會導致服務器處於一直等待發送數據的狀態，浪費資源。“已失效的連接請求報文段”的產生在這樣一種情況下：client發出的第一個連接請求報文段並沒有丟失，而是在某個網絡結點長時間的滯留了，以致延誤到連接釋放以後的某個時間才到達server。本來這是一個早已失效的報文段。但server收到此失效的連接請求報文段後，就誤認為是client再次發出的一個新的連接請求。於是就向client發出確認報文段，同意建立連接。假設不采用“三次握手”，那麽只要server發出確認，新的連接就建立了。由於現在client並沒有發出建立連接的請求，因此不會理睬server的確認，也不會向server發送數據。但server卻以為新的運輸連接已經建立，並一直等待client發來數據。這樣，server的很多資源就白白浪費掉了。采用“三次握手”的辦法可以防止上述現象發生。例如剛才那種情況，client不會向server的確認發出確認。server由於收不到確認，就知道client並沒有要求建立連接。”

問題二 為什麽需要四次分手？

TCP協議是一種面向連接的、可靠的、基於字節流的運輸層通信協議。TCP是全雙工模式，這就意味著，當主機1發出FIN報文段時，只是表示主機1已經沒有數據要發送了，主機1告訴主機2，它的數據已經全部發送完畢了；但是，這個時候主機1還是可以接受來自主機2的數據；當主機2返回ACK報文段時，表示它已經知道主機1沒有數據發送了，但是主機2還是可以發送數據到主機1的；當主機2也發送了FIN報文段時，這個時候就表示主機2也沒有數據要發送了，就會告訴主機1，我也沒有數據要發送了，之後彼此就會愉快的中斷這次TCP連接。

二 UDP協議

1. UDP是一個非連接的協議，傳輸數據之前源端和終端不建立連接，當它想傳送時就簡單地去抓取來自應用程序的數據，並盡可能快地把它扔到網絡上。
2. 在發送端，UDP傳送數據的速度僅僅是受應用程序生成數據的速度、計算機的能力和傳輸帶寬的限制；在接收端，UDP把每個消息段放在隊列中，應用程序每次從隊列中讀一個消息段。
3. 由於傳輸數據不建立連接，因此也就不需要維護連接狀態，包括收發狀態等，因此一臺服務機可同時向更多的客戶機傳輸相同的消息。QQ為例子。
4. UDP信息包的標題很短，只有8個字節，相對於TCP的20個字節信息包的額外開銷很小。UDP的包頭結構：源端口16位，目的端口16位，長度16位以及16位的校驗和。
5. 吞吐量不受擁擠控制算法的調節，只受應用軟件生成數據的速率、傳輸帶寬、源端和終端主機性能的限制。UDP使用盡最大努力交付，即不保證可靠交付，因此主機不需要維持復雜的鏈接狀態表（這裏面有許多參數）。
6. UDP是面向報文的。發送方的UDP對應用程序交下來的報文，在添加首部後就向下交付給IP層。既不拆分，也不合並，而是保留這些報文的邊界，因此，應用程序需要選擇合適的報文大小。

我們經常使用“ping”命令來測試兩臺主機之間TCP/IP通信是否正常，其實“ping”命令的原理就是向對方主機發送UDP數據包，然後對方主機確認收到數據包，如果數據包是否到達的消息及時反饋回來，那麽網絡就是通的。

三 TCP和UDP的區別

1. TCP面向連接（如打電話要先撥號建立連接）;UDP是無連接的，即發送數據之前不需要建立連接
2. TCP提供可靠的服務。也就是說，通過TCP連接傳送的數據，無差錯，不丟失，不重復，且按序到達;UDP盡最大努力交付，即不保 證可靠交付
3. TCP面向字節流，實際上是TCP把數據看成一連串無結構的字節流;UDP是面向報文的
4. UDP沒有擁塞控制，因此網絡出現擁塞不會使源主機的發送速率降低（對實時應用很有用，如IP電話，實時視頻會議等）
5. 每一條TCP連接只能是點到點的;UDP支持一對一，一對多，多對一和多對多的交互通信
6. TCP首部開銷20字節;UDP的首部開銷小，只有8個字節
7. TCP的邏輯通信信道是全雙工的可靠信道，UDP則是不可靠信道

四 TCP和UDP使用場景

　　TCP用於在傳輸層有必要實現可靠性傳輸的情況。由於它是面向有連接並具備順序控制、重發控制等機制的。所以它可以為應用提供可靠傳輸。另一方面，UDP主要用於那些對高速傳輸和實時性有較高要求的通信或廣播通信。舉一個IP電話進行通話的例子。如果使用TCP，數據在傳送途中如果丟失會被重發，但是這樣無法流暢地傳輸通話人的聲音，會導致無法進行正常交流。而采用UDP，它不會進行重發處理。從而也就不會有聲音大幅度延遲到達的問題。即使有部分數據丟失，也只是影響某一小部分的通話。此外，在多播與廣播通信中也使用UDP而不是UDP。RIP、DHCP等基於廣播的協議也要依賴於UDP。

參考資料：

1. TCP協議：http://www.jellythink.com/archives/705
2. UDP協議：http://www.cnblogs.com/bizhu/archive/2012/05/12/2497493.html
3. TCP與UDP的區別：http://blog.csdn.net/li_ning_/article/details/52117463

理解TCP和UDP協議