7、TCP的連接與斷開

7.1、TCP的連接建立

7.1.1、TCP連接建立過程中要解決的3個問題

1.要使一方確定對方的存在。

2.雙方之間協商一些參數比如說滑動窗口的大小，時間戳選項等等。

3.能夠對運輸實體資源(緩存大小，連接表中的項目)進行一些分配。

7.1.2、三次握手建立連接

在建立連接之前，Client處于CLOSED狀態，而Server處于LISTEN的狀態。

1.第一次握手：客戶端主動給服務端發送一個SYN報文，并攜帶自己的初始化序列號一起發送給服務端。此時客戶端處于一個SYN_SEND的狀態。

2.第二次握手：服務端收到客戶端發來的SYN報文之后，就會以自己的SYN報文作為應答，然后將自己的初始化序列號發送給客戶端，并且會將客戶端的初始化序列號+1作為自己的ACK值發送給客戶端，以表示自己已經收到了客戶端的SYN報文。此時服務端處于一個SYN_RECV的狀態。

3.第三次握手：客戶端收到服務端發來的SYN報文之后，會把服務端的初始化序列號+1作為ACK值發送給服務端，用來表示自己已經收到了服務端發來的SYN報文。此時客戶端處于一個ESTABLISHED的狀態。

7.1.3、為什么兩次不行

一開始A向B發出建立連接的請求但是這個報文超時了，A又向B發送了一個請求連接報文然后通過兩次握手建立連接傳送數據最后釋放連接。但是這時候，超時的報文遲到發送他們又會建立連接然后服務端等待發送數據，但是這時候客戶端已經沒有數據可發了。

7.1.4、三次握手的原因

可靠性要求之一（確認、序號、重傳）：起始數據字節編號協商

如圖所示它主要是為了起始數據字節編號協商1是我發送的報文序號是456,2是我接受到了你下次從457開始發，3是好的我準備接收124。如果沒有這個3號報文B端就不知道下次從哪開始發。

7.1.5、三次握手建立TCP連接的各種狀態

首先服務端開始處于監聽狀態監聽客戶端發來的請求，客戶端發送建立連接的請求之后處于SYN-SEND狀態，服務端發送確認報文之后處于SYN-RCVD狀態，當客戶端發送確認報文給服務端客戶端處于ESTAB-LISHED(連接建立狀態)服務端接收到報文后進入ESTAB-LISHED狀態。

7.1.6、三次握手可以攜帶數據嗎？

大概很多人的正常思維都是在三次握手過程中是不可以攜帶數據的，其實不然，在第三次握手的過程中是可以攜帶數據滴；換句話說就是，在第一、第二次握手過程中不可以攜帶數據的，但是在第三次握手過程中是可以攜帶數據的。

那為什么會這樣呢？大家不妨大膽的猜測猜測....

因為是網絡連接，就會涉及到網絡安全的因素；大家想想，如果在第一次握手的時候就可以攜帶數據，那么要是有人蓄謀已久惡意攻擊服務器，在第一次握手中的SYN報文注入大量數據，攻擊者根本就不考慮服務器的發送接收能力，然后就瘋狂重復發SYN報文，這就會讓服務器花費大量的內存和時間去處理這些報文，所以如果在第一次握手就放數據的話，就會讓服務器更加容易受到攻擊。

7.2、TCP連接釋放

1.客戶端向服務端發送一個報文FIN為1，序號為u然后進入FIN-WAIT1狀態。

2.服務端向客戶端發送確認報文序號為v，確認序號為u+1然后進入CLOSE-WAIT狀態。

3.客戶端收到服務端發回的確認報文之后進入FIN-WAIT2狀態此時客戶端連接已經關閉客戶端無法向服務端傳送數據。

4.然后服務端被動關閉它向客戶端發送一個FIN為1的報文段要求釋放服務端到客戶端的連接。進入LAST-ACK等待客戶端發送最后一個ACK報文。

5.客戶端發送最后一次揮手確認報文然后進行closed，服務端直接CLOSED。

6.客戶端要等待2MSL才CLOSED。

當不按套路出牌時返回RST比如上來沒建立連接服務端給客戶端來一個ACK或FIN。

7.2.1、為什么客戶端要等2MSL才關閉

1.因為服務端要保證TCP全雙工通信連接都能正確關閉，因為如果服務端沒收到ACK那么就會再發一次FIN那么客戶端如果關閉則無法回復ACKServer就會收到RST而不是ACK。所以為了讓服務端能正確的收到ACK報文確保連接正確關閉所以要等一會再關。

2.一旦客戶端直接進入CLOSED很有可能端口號跟之前相同然后上一次連接中有些數據滯留在網絡，當你再建立連接時這些老的數據包會和新的數據混淆等待2MSL基本上可以讓這些老數據消失。

7.2.2、保活計時器

?當建立連接之后一旦斷網了，連接空閑時間達到兩個小時以上服務器自動發送探測報文段，若發送了10個報文段(每個相隔75秒)還沒有響應，就假定客戶除了故障，因而終止連接。

?TCP計時器總結：TCP發送報文計時器，超時重傳計時器，保活計時器，持續(0窗口探測計時器)，時間等待計時器(2MSL);

7.3、TCP黏包

7.3.1、什么是TCP黏包？

在以往的網絡基礎學習中，可能會客戶端連續不斷向服務端發送數據包的時候，服務端接收的數據會出現兩個數據包黏在一起的情況。

?TCP是基于字節流的可靠傳輸，在應用層和傳輸層之間的數據交互是大小不等的數據塊，但是TCP就會將這些數據塊看成是一串一串沒有結構的字節流，并且沒有邊界。

?學習TCP結構的時候也可以看出，它的首部沒有表示數據長度的字段。

所以，在使用TCP進行數據傳輸的時候，就會有黏包或者拆包的現象發生。一個數據包中包含了發送端發送的兩個數據包的信息，那么就把這種現象叫做黏包。接收端在收到這兩個數據包的時候，要么是不完整的，要么是多出來一塊，這種情況就是發生了黏包和拆包。

7.3.2、TCP黏包是怎么產生的？

1.發送方產生黏包

因為在采用TCP傳輸數據的客戶端和服務端是保持一個長鏈接的狀態，雙方在不斷開的狀態下，是可以一直傳輸數據的。如果發送的數據包非常小的時候，那么TCP默認就會啟用Nagle算法，將這些非常小的數據包進行合并發送（這個合并發送過程就是在發送緩沖區中進行的），發出來的數據就會是一個黏包的狀態。

2.接收方產生黏包

數據在到達接收方的時候，是從網絡模型的下方傳遞至傳輸層，傳輸層的TCP協議就會將這些數據放置到接收緩沖區，然后由應用層主動獲取，那么這個時候就會出現在我們程序調用的讀取數據函數不能及時的把緩沖區中的數據拿出來，下一個數據的一部分就又到緩沖區中，當我們讀取的時候就是黏包。

7.3.3、怎么解決黏包和拆包？

1.FixedLengthFrameDecoder

對于使用固定長度的粘包和拆包場景，可以使用FixedLengthFrameDecoder，該解碼器會每次讀取固定長度的消息，如果當前讀取到的消息不足指定長度，那么就會等待下一個消息到達后進行補足。

2.LineBasedFrameDecoder與DelimiterBasedFrameDecoder

對于通過分隔符進行粘包和拆包問題的處理，Netty提供了兩個編解碼的類，LineBasedFrameDecoder和DelimiterBasedFrameDecoder。這里LineBasedFrameDecoder的作用主要是通過換行符，即\\n或者\\r\\n對數據進行處理；而DelimiterBasedFrameDecoder的作用則是通過用戶指定的分隔符對數據進行粘包和拆包處理。

3.LengthFieldBasedFrameDecoder與LengthFieldPrepender

這里LengthFieldBasedFrameDecoder與LengthFieldPrepender需要配合起來使用，其實本質上來講，這兩者一個是解碼，一個是編碼的關系。它們處理粘拆包的主要思想是在生成的數據包中添加一個長度字段，用于記錄當前數據包的長度。

4.自定義粘包與拆包器

對于粘包與拆包問題，其實前面三種基本上已經能夠滿足大多數情形了，但是對于一些更加復雜的協議，可能有一些定制化的需求。對于這些場景，其實本質上，我們也不需要手動從頭開始寫一份粘包與拆包處理器，而是通過繼承LengthFieldBasedFrameDecoder和LengthFieldPrepender來實現粘包和拆包的處理。

8、UDP主要特點

1.不需要建立連接。

2.盡最大努力交付。

3.面向報文交付。

4.沒有擁塞控制。

5.支持多種交互通信。

6.首部開銷小僅有8字節。

7.應用程序必須選擇合適的報文如果報文太長則需要IP分片，太小降低效率。

8.1、運用場景：

1.可以重復請求信息的情況下例如：RIP，DNS，DHCP等

2.一次性傳小量數據的應用

3.實時應用

4.多媒體應用。

8.2、UDP首部信息

1.源端口（2）

2.目的端口（2）

3.長度（2）

4.檢驗和（2）（首部+偽首部+數據）

這個檢驗和是交給上層應用程序檢查的，它就相當于你拆快遞先檢查收貨地址（IP地址），再檢查是不是你的名字（端口），再檢查里面收件是不是錯的（里面的數據）。

以上就是我對TCP、UDP相關的總結；如果對您有所幫助的話，那就是我花時間整理這篇文章最大的意義了。