超硬核TCP、UDP基礎(chǔ)知識(shí)匯總4

7、TCP的連接與斷開

7.1、TCP的連接建立

7.1.1、TCP連接建立過(guò)程中要解決的3個(gè)問(wèn)題

1.要使一方確定對(duì)方的存在。

2.雙方之間協(xié)商一些參數(shù)比如說(shuō)滑動(dòng)窗口的大小，時(shí)間戳選項(xiàng)等等。

3.能夠?qū)\(yùn)輸實(shí)體資源(緩存大小，連接表中的項(xiàng)目)進(jìn)行一些分配。

7.1.2、三次握手建立連接

在建立連接之前，Client處于CLOSED狀態(tài)，而Server處于LISTEN的狀態(tài)。

1.第一次握手：客戶端主動(dòng)給服務(wù)端發(fā)送一個(gè)SYN報(bào)文，并攜帶自己的初始化序列號(hào)一起發(fā)送給服務(wù)端。此時(shí)客戶端處于一個(gè)SYN_SEND的狀態(tài)。

2.第二次握手：服務(wù)端收到客戶端發(fā)來(lái)的SYN報(bào)文之后，就會(huì)以自己的SYN報(bào)文作為應(yīng)答，然后將自己的初始化序列號(hào)發(fā)送給客戶端，并且會(huì)將客戶端的初始化序列號(hào)+1作為自己的ACK值發(fā)送給客戶端，以表示自己已經(jīng)收到了客戶端的SYN報(bào)文。此時(shí)服務(wù)端處于一個(gè)SYN_RECV的狀態(tài)。

3.第三次握手：客戶端收到服務(wù)端發(fā)來(lái)的SYN報(bào)文之后，會(huì)把服務(wù)端的初始化序列號(hào)+1作為ACK值發(fā)送給服務(wù)端，用來(lái)表示自己已經(jīng)收到了服務(wù)端發(fā)來(lái)的SYN報(bào)文。此時(shí)客戶端處于一個(gè)ESTABLISHED的狀態(tài)。

7.1.3、為什么兩次不行

一開始A向B發(fā)出建立連接的請(qǐng)求但是這個(gè)報(bào)文超時(shí)了，A又向B發(fā)送了一個(gè)請(qǐng)求連接報(bào)文然后通過(guò)兩次握手建立連接傳送數(shù)據(jù)最后釋放連接。但是這時(shí)候，超時(shí)的報(bào)文遲到發(fā)送他們又會(huì)建立連接然后服務(wù)端等待發(fā)送數(shù)據(jù)，但是這時(shí)候客戶端已經(jīng)沒有數(shù)據(jù)可發(fā)了。

7.1.4、三次握手的原因

可靠性要求之一（確認(rèn)、序號(hào)、重傳）：起始數(shù)據(jù)字節(jié)編號(hào)協(xié)商

如圖所示它主要是為了起始數(shù)據(jù)字節(jié)編號(hào)協(xié)商1是我發(fā)送的報(bào)文序號(hào)是456,2是我接受到了你下次從457開始發(fā)，3是好的我準(zhǔn)備接收124。如果沒有這個(gè)3號(hào)報(bào)文B端就不知道下次從哪開始發(fā)。

7.1.5、三次握手建立TCP連接的各種狀態(tài)

首先服務(wù)端開始處于監(jiān)聽狀態(tài)監(jiān)聽客戶端發(fā)來(lái)的請(qǐng)求，客戶端發(fā)送建立連接的請(qǐng)求之后處于SYN-SEND狀態(tài)，服務(wù)端發(fā)送確認(rèn)報(bào)文之后處于SYN-RCVD狀態(tài)，當(dāng)客戶端發(fā)送確認(rèn)報(bào)文給服務(wù)端客戶端處于ESTAB-LISHED(連接建立狀態(tài))服務(wù)端接收到報(bào)文后進(jìn)入ESTAB-LISHED狀態(tài)。

7.1.6、三次握手可以攜帶數(shù)據(jù)嗎？

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

那為什么會(huì)這樣呢？大家不妨大膽的猜測(cè)猜測(cè)....

因?yàn)槭蔷W(wǎng)絡(luò)連接，就會(huì)涉及到網(wǎng)絡(luò)安全的因素；大家想想，如果在第一次握手的時(shí)候就可以攜帶數(shù)據(jù)，那么要是有人蓄謀已久惡意攻擊服務(wù)器，在第一次握手中的SYN報(bào)文注入大量數(shù)據(jù)，攻擊者根本就不考慮服務(wù)器的發(fā)送接收能力，然后就瘋狂重復(fù)發(fā)SYN報(bào)文，這就會(huì)讓服務(wù)器花費(fèi)大量的內(nèi)存和時(shí)間去處理這些報(bào)文，所以如果在第一次握手就放數(shù)據(jù)的話，就會(huì)讓服務(wù)器更加容易受到攻擊。

7.2、TCP連接釋放

1.客戶端向服務(wù)端發(fā)送一個(gè)報(bào)文FIN為1，序號(hào)為u然后進(jìn)入FIN-WAIT1狀態(tài)。

2.服務(wù)端向客戶端發(fā)送確認(rèn)報(bào)文序號(hào)為v，確認(rèn)序號(hào)為u+1然后進(jìn)入CLOSE-WAIT狀態(tài)。

3.客戶端收到服務(wù)端發(fā)回的確認(rèn)報(bào)文之后進(jìn)入FIN-WAIT2狀態(tài)此時(shí)客戶端連接已經(jīng)關(guān)閉客戶端無(wú)法向服務(wù)端傳送數(shù)據(jù)。

4.然后服務(wù)端被動(dòng)關(guān)閉它向客戶端發(fā)送一個(gè)FIN為1的報(bào)文段要求釋放服務(wù)端到客戶端的連接。進(jìn)入LAST-ACK等待客戶端發(fā)送最后一個(gè)ACK報(bào)文。

5.客戶端發(fā)送最后一次揮手確認(rèn)報(bào)文然后進(jìn)行closed，服務(wù)端直接CLOSED。

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

當(dāng)不按套路出牌時(shí)返回RST比如上來(lái)沒建立連接服務(wù)端給客戶端來(lái)一個(gè)ACK或FIN。

7.2.1、為什么客戶端要等2MSL才關(guān)閉

1.因?yàn)榉?wù)端要保證TCP全雙工通信連接都能正確關(guān)閉，因?yàn)槿绻?wù)端沒收到ACK那么就會(huì)再發(fā)一次FIN那么客戶端如果關(guān)閉則無(wú)法回復(fù)ACKServer就會(huì)收到RST而不是ACK。所以為了讓服務(wù)端能正確的收到ACK報(bào)文確保連接正確關(guān)閉所以要等一會(huì)再關(guān)。

2.一旦客戶端直接進(jìn)入CLOSED很有可能端口號(hào)跟之前相同然后上一次連接中有些數(shù)據(jù)滯留在網(wǎng)絡(luò)，當(dāng)你再建立連接時(shí)這些老的數(shù)據(jù)包會(huì)和新的數(shù)據(jù)混淆等待2MSL基本上可以讓這些老數(shù)據(jù)消失。

7.2.2、?；钣?jì)時(shí)器

?當(dāng)建立連接之后一旦斷網(wǎng)了，連接空閑時(shí)間達(dá)到兩個(gè)小時(shí)以上服務(wù)器自動(dòng)發(fā)送探測(cè)報(bào)文段，若發(fā)送了10個(gè)報(bào)文段(每個(gè)相隔75秒)還沒有響應(yīng)，就假定客戶除了故障，因而終止連接。

?TCP計(jì)時(shí)器總結(jié)：TCP發(fā)送報(bào)文計(jì)時(shí)器，超時(shí)重傳計(jì)時(shí)器，?；钣?jì)時(shí)器，持續(xù)(0窗口探測(cè)計(jì)時(shí)器)，時(shí)間等待計(jì)時(shí)器(2MSL);

7.3、TCP黏包

7.3.1、什么是TCP黏包？

在以往的網(wǎng)絡(luò)基礎(chǔ)學(xué)習(xí)中，可能會(huì)客戶端連續(xù)不斷向服務(wù)端發(fā)送數(shù)據(jù)包的時(shí)候，服務(wù)端接收的數(shù)據(jù)會(huì)出現(xiàn)兩個(gè)數(shù)據(jù)包黏在一起的情況。

?TCP是基于字節(jié)流的可靠傳輸，在應(yīng)用層和傳輸層之間的數(shù)據(jù)交互是大小不等的數(shù)據(jù)塊，但是TCP就會(huì)將這些數(shù)據(jù)塊看成是一串一串沒有結(jié)構(gòu)的字節(jié)流，并且沒有邊界。

?學(xué)習(xí)TCP結(jié)構(gòu)的時(shí)候也可以看出，它的首部沒有表示數(shù)據(jù)長(zhǎng)度的字段。

所以，在使用TCP進(jìn)行數(shù)據(jù)傳輸?shù)臅r(shí)候，就會(huì)有黏包或者拆包的現(xiàn)象發(fā)生。一個(gè)數(shù)據(jù)包中包含了發(fā)送端發(fā)送的兩個(gè)數(shù)據(jù)包的信息，那么就把這種現(xiàn)象叫做黏包。接收端在收到這兩個(gè)數(shù)據(jù)包的時(shí)候，要么是不完整的，要么是多出來(lái)一塊，這種情況就是發(fā)生了黏包和拆包。

7.3.2、TCP黏包是怎么產(chǎn)生的？

1.發(fā)送方產(chǎn)生黏包

因?yàn)樵诓捎肨CP傳輸數(shù)據(jù)的客戶端和服務(wù)端是保持一個(gè)長(zhǎng)鏈接的狀態(tài)，雙方在不斷開的狀態(tài)下，是可以一直傳輸數(shù)據(jù)的。如果發(fā)送的數(shù)據(jù)包非常小的時(shí)候，那么TCP默認(rèn)就會(huì)啟用Nagle算法，將這些非常小的數(shù)據(jù)包進(jìn)行合并發(fā)送（這個(gè)合并發(fā)送過(guò)程就是在發(fā)送緩沖區(qū)中進(jìn)行的），發(fā)出來(lái)的數(shù)據(jù)就會(huì)是一個(gè)黏包的狀態(tài)。

2.接收方產(chǎn)生黏包

數(shù)據(jù)在到達(dá)接收方的時(shí)候，是從網(wǎng)絡(luò)模型的下方傳遞至傳輸層，傳輸層的TCP協(xié)議就會(huì)將這些數(shù)據(jù)放置到接收緩沖區(qū)，然后由應(yīng)用層主動(dòng)獲取，那么這個(gè)時(shí)候就會(huì)出現(xiàn)在我們程序調(diào)用的讀取數(shù)據(jù)函數(shù)不能及時(shí)的把緩沖區(qū)中的數(shù)據(jù)拿出來(lái)，下一個(gè)數(shù)據(jù)的一部分就又到緩沖區(qū)中，當(dāng)我們讀取的時(shí)候就是黏包。

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

1.FixedLengthFrameDecoder

對(duì)于使用固定長(zhǎng)度的粘包和拆包場(chǎng)景，可以使用FixedLengthFrameDecoder，該解碼器會(huì)每次讀取固定長(zhǎng)度的消息，如果當(dāng)前讀取到的消息不足指定長(zhǎng)度，那么就會(huì)等待下一個(gè)消息到達(dá)后進(jìn)行補(bǔ)足。

2.LineBasedFrameDecoder與DelimiterBasedFrameDecoder

對(duì)于通過(guò)分隔符進(jìn)行粘包和拆包問(wèn)題的處理，Netty提供了兩個(gè)編解碼的類，LineBasedFrameDecoder和DelimiterBasedFrameDecoder。這里L(fēng)ineBasedFrameDecoder的作用主要是通過(guò)換行符，即\\n或者\(yùn)\r\\n對(duì)數(shù)據(jù)進(jìn)行處理；而DelimiterBasedFrameDecoder的作用則是通過(guò)用戶指定的分隔符對(duì)數(shù)據(jù)進(jìn)行粘包和拆包處理。

3.LengthFieldBasedFrameDecoder與LengthFieldPrepender

這里L(fēng)engthFieldBasedFrameDecoder與LengthFieldPrepender需要配合起來(lái)使用，其實(shí)本質(zhì)上來(lái)講，這兩者一個(gè)是解碼，一個(gè)是編碼的關(guān)系。它們處理粘拆包的主要思想是在生成的數(shù)據(jù)包中添加一個(gè)長(zhǎng)度字段，用于記錄當(dāng)前數(shù)據(jù)包的長(zhǎng)度。

4.自定義粘包與拆包器

對(duì)于粘包與拆包問(wèn)題，其實(shí)前面三種基本上已經(jīng)能夠滿足大多數(shù)情形了，但是對(duì)于一些更加復(fù)雜的協(xié)議，可能有一些定制化的需求。對(duì)于這些場(chǎng)景，其實(shí)本質(zhì)上，我們也不需要手動(dòng)從頭開始寫一份粘包與拆包處理器，而是通過(guò)繼承LengthFieldBasedFrameDecoder和LengthFieldPrepender來(lái)實(shí)現(xiàn)粘包和拆包的處理。

8、UDP主要特點(diǎn)

1.不需要建立連接。

2.盡最大努力交付。

3.面向報(bào)文交付。

4.沒有擁塞控制。

5.支持多種交互通信。

6.首部開銷小僅有8字節(jié)。

7.應(yīng)用程序必須選擇合適的報(bào)文如果報(bào)文太長(zhǎng)則需要IP分片，太小降低效率。

8.1、運(yùn)用場(chǎng)景：

1.可以重復(fù)請(qǐng)求信息的情況下例如：RIP，DNS，DHCP等

2.一次性傳小量數(shù)據(jù)的應(yīng)用

3.實(shí)時(shí)應(yīng)用

4.多媒體應(yīng)用。

8.2、UDP首部信息

1.源端口（2）

2.目的端口（2）

3.長(zhǎng)度（2）

4.檢驗(yàn)和（2）（首部+偽首部+數(shù)據(jù)）

這個(gè)檢驗(yàn)和是交給上層應(yīng)用程序檢查的，它就相當(dāng)于你拆快遞先檢查收貨地址（IP地址），再檢查是不是你的名字（端口），再檢查里面收件是不是錯(cuò)的（里面的數(shù)據(jù)）。

以上就是我對(duì)TCP、UDP相關(guān)的總結(jié)；如果對(duì)您有所幫助的話，那就是我花時(shí)間整理這篇文章最大的意義了。