?

TCP是TCP/IP協(xié)議族中一個(gè)最核心的協(xié)議，它向下使用網(wǎng)絡(luò)層IP協(xié)議，向上為應(yīng)用層HTTP、FTP、SMTP、POP3、SSH、Telnet等協(xié)議提供支持。本文給出TCP報(bào)文格式的詳細(xì)說(shuō)明，介紹網(wǎng)絡(luò)數(shù)據(jù)包傳遞中如何進(jìn)行地址解析、建立TCP連接的三次握手過(guò)程以及斷開(kāi)TCP連接的四次揮手過(guò)程。

1.? 簡(jiǎn)介

傳輸控制協(xié)議（英語(yǔ)：Transmission?Control?Protocol，縮寫(xiě)：TCP）是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議，由國(guó)際互聯(lián)網(wǎng)工程任務(wù)組(The Internet Engineering Task Force, IETF)的 RFC793 定義。在簡(jiǎn)化的計(jì)算機(jī)網(wǎng)絡(luò) OSI 模型中，它完成傳輸層所指定的功能。

在TCP定義中，有以下3點(diǎn)需要特別說(shuō)明：

(1)什么是面向連接？

面向連接是相對(duì)于另一個(gè)傳輸層協(xié)議UDP(User Datagram Protocol,?用戶數(shù)據(jù)報(bào)協(xié)議)而言的。TCP在開(kāi)始傳輸數(shù)據(jù)前要先經(jīng)歷三次握手建立連接，并通過(guò)連接一對(duì)一發(fā)送消息，傳輸結(jié)束后通過(guò)四次揮手?jǐn)嚅_(kāi)連接。

而UDP是無(wú)連接的，發(fā)送方在發(fā)送數(shù)據(jù)之前不需要與接收方建立連接，即刻可以傳輸數(shù)據(jù)，每個(gè)UDP數(shù)據(jù)包都是獨(dú)立的，相互之間沒(méi)有關(guān)聯(lián)，因此UDP可以一對(duì)一、一對(duì)多或多對(duì)多發(fā)送消息。

(2)什么是可靠的通信協(xié)議？

是否可靠也是相對(duì)于UDP而言的。TCP自身有三次握手和超時(shí)重傳等機(jī)制確保數(shù)據(jù)的可靠傳輸，發(fā)送方在發(fā)送數(shù)據(jù)包后會(huì)等待接收方發(fā)送確認(rèn)(ACK)消息。如果發(fā)送方在一定時(shí)間內(nèi)未收到確認(rèn)消息，它將假定數(shù)據(jù)丟失，并重新發(fā)送數(shù)據(jù)。接收方收到重復(fù)的數(shù)據(jù)包時(shí)會(huì)發(fā)送冗余的ACK消息來(lái)通知發(fā)送方，以避免數(shù)據(jù)丟失。同時(shí)TCP還提供流量控制和擁塞控制，以保持網(wǎng)絡(luò)的穩(wěn)定性和性能。因此無(wú)論網(wǎng)絡(luò)如何變化，只要不是主機(jī)宕機(jī)等原因都可以保證一個(gè)報(bào)文可以到達(dá)目標(biāo)主機(jī)。

相對(duì)于TCP的可靠傳輸，UDP是不可靠的。UDP數(shù)據(jù)包的傳輸過(guò)程中不提供確認(rèn)、重傳、流量控制和擁塞控制等機(jī)制，因此UDP數(shù)據(jù)包可能丟失、重復(fù)、亂序或損壞。

(3)什么是面向字節(jié)流的？

TCP是面向字節(jié)流的傳輸，雖然應(yīng)用程序和TCP的交互是一次一個(gè)數(shù)據(jù)塊(大小不等)，但TCP把應(yīng)用程序看成是一連串的無(wú)結(jié)構(gòu)的字節(jié)流。TCP有一個(gè)緩沖，當(dāng)應(yīng)用程序傳送的數(shù)據(jù)塊太長(zhǎng)，TCP就可以把它劃分短一些再傳送。如果應(yīng)用程序一次只發(fā)送一個(gè)字節(jié)，TCP也可以等待積累有足夠多的字節(jié)后再構(gòu)成報(bào)文段發(fā)送出去。

與面向字節(jié)流相對(duì)的是UDP的面向報(bào)文。UDP對(duì)應(yīng)用層交下來(lái)的報(bào)文，既不合并也不拆分，而是保留這些報(bào)文的邊界，即應(yīng)用層交給UDP多長(zhǎng)的報(bào)文，UDP就照樣發(fā)送，一次發(fā)送一個(gè)報(bào)文。因此，應(yīng)用程序必須選擇合適大小的報(bào)文。若報(bào)文太長(zhǎng)，則IP層需要分片，降低效率。若太短，會(huì)使IP報(bào)文太小。

2.TCP報(bào)文格式

了解報(bào)文格式是搞懂一個(gè)通信協(xié)議的必經(jīng)之路。TCP報(bào)文由TCP首部(報(bào)頭)和應(yīng)用數(shù)據(jù)構(gòu)成，其中TCP首部是TCP?協(xié)議的核心所在，應(yīng)用數(shù)據(jù)部分是TCP報(bào)文的負(fù)載，如下圖所示。

以下詳細(xì)介紹各字段含義：

源端口(Source Port)和目的端口(Destination Port)：長(zhǎng)度各為16位，即2個(gè)字節(jié)，分別指示發(fā)送端的應(yīng)用程序使用的端口號(hào)以及接收端的應(yīng)用程序期望接收的端口號(hào)。它們的長(zhǎng)度說(shuō)明為什么計(jì)算機(jī)端口的范圍是1-65535 (0不使用，2^16=65536，最大位65536不使用)。有了源端口和目標(biāo)端口，加上IP首部里的源IP和目標(biāo)IP，就可以唯一確定一個(gè)連接。

序列號(hào)(Sequence Number)：長(zhǎng)度為32位，說(shuō)明序列號(hào)的范圍是[0, 2^32-1]，也就是[0, 4294967295]。當(dāng)序號(hào)增加到4294967295后，下一個(gè)序號(hào)將回到0重新開(kāi)始。在建立連接時(shí)由計(jì)算機(jī)生成的隨機(jī)數(shù)作為其初始值(ISN，即Initial Sequence Number，初始序列號(hào))，通過(guò) SYN 包傳給接收端主機(jī)，每發(fā)送一次數(shù)據(jù)，就累加一次該“數(shù)據(jù)字節(jié)數(shù)”的大小。序列號(hào)用來(lái)解決網(wǎng)絡(luò)包亂序問(wèn)題，實(shí)現(xiàn)可靠的數(shù)據(jù)傳輸和流量控制。

確認(rèn)號(hào)(Acknowledgment Number)：長(zhǎng)度為32位，只有在ACK標(biāo)志位被設(shè)置時(shí)才有效。它指示期望接收的下一個(gè)字節(jié)的序列號(hào)(所以該字段一般都是上次接收成功的數(shù)據(jù)字節(jié)序號(hào)加1)，用于確認(rèn)已經(jīng)成功接收的數(shù)據(jù)。在TCP連接建立后，確認(rèn)號(hào)的范圍通常是相對(duì)于初始序號(hào)(ISN)的相對(duì)偏移量。如果ISN的初始值為X，那么確認(rèn)號(hào)的范圍就是[X+1, X+1+N-1]，其中N表示已經(jīng)成功接收的字節(jié)數(shù)。發(fā)送端收到這個(gè)確認(rèn)應(yīng)答以后可以認(rèn)為在這個(gè)序號(hào)以前的數(shù)據(jù)都已經(jīng)被正常接收。確認(rèn)號(hào)的范圍是[0, 2^32-1]，也就是[0, 4294967295]。

數(shù)據(jù)偏移(Data Offset)：長(zhǎng)度為4位，指示TCP報(bào)文的“數(shù)據(jù)”起始處距離TCP報(bào)文起始處的距離有多遠(yuǎn)，以4字節(jié)為單位計(jì)算出的數(shù)據(jù)段開(kāi)始地址的偏移值。沒(méi)有選項(xiàng)時(shí)該值為5，即20字節(jié)；4位能表示的最大整數(shù)是15，也就說(shuō)明TCP報(bào)文里數(shù)據(jù)開(kāi)始的位置距離報(bào)文起點(diǎn)是60個(gè)字節(jié)(4*15)。這意味著TCP的首部長(zhǎng)度是20-60個(gè)字節(jié)。

保留(Reserved)：長(zhǎng)度為3位，保留供將來(lái)使用，目前應(yīng)設(shè)置為零。

控制標(biāo)志(Flags)：長(zhǎng)度為9位，用于控制和管理TCP連接。各控制標(biāo)志位說(shuō)明如下：

NS(Nonce Sum)：用于支持一種稱(chēng)為ECN-nonce的TCP擴(kuò)展機(jī)制，該機(jī)制用于增加擁塞控制的安全性，防止擁塞控制信息被惡意篡改。

CWR(Congestion Window Reduced)：用于指示發(fā)送方減小擁塞窗口(Congestion Window)的大小。CWR標(biāo)志位通常與擁塞控制機(jī)制一起使用，以應(yīng)對(duì)網(wǎng)絡(luò)擁塞的情況。

ECE(ECN-Echo)：ECE標(biāo)志被設(shè)置表示發(fā)送方支持顯式擁塞通知(Explicit Congestion Notification,?ECN)機(jī)制，并請(qǐng)求接收方通知其關(guān)于網(wǎng)絡(luò)擁塞的情況。接收方在收到設(shè)置了ECE標(biāo)志的TCP報(bào)文段后，如果網(wǎng)絡(luò)出現(xiàn)擁塞，則可以在回復(fù)的TCP報(bào)文段中設(shè)置ECN-Echo標(biāo)志作為響應(yīng)。通過(guò)使用ECE標(biāo)志和ECN-Echo回復(fù)，TCP連接的發(fā)送方和接收方可以共同協(xié)調(diào)擁塞控制，以提高網(wǎng)絡(luò)的性能和穩(wěn)定性。

URG(Urgent)：指示報(bào)文段中包含緊急數(shù)據(jù)。當(dāng)URG=1時(shí)，表明開(kāi)啟了urgent mode，通知接收方在處理數(shù)據(jù)時(shí)要特別注意緊急數(shù)據(jù)的處理。URG標(biāo)志位的設(shè)置與緊急指針字段(Urgent Pointer)一起使用。

ACK(Acknowledgment)：指示確認(rèn)號(hào)字段有效。僅當(dāng)ACK=1時(shí)確認(rèn)號(hào)字段才有效，當(dāng)ACK=0時(shí)確認(rèn)號(hào)無(wú)效。TCP規(guī)定，在連接建立后所有的傳送的報(bào)文段都必須把ACK置為1。

PSH(Push)：指示接收方應(yīng)立即將數(shù)據(jù)推送給應(yīng)用程序，而不是等待緩沖區(qū)填滿。當(dāng)兩個(gè)應(yīng)用進(jìn)程進(jìn)行交互式的通信時(shí)，有時(shí)一端的應(yīng)用進(jìn)程希望在鍵入一個(gè)命令后立即就能收到對(duì)方的響應(yīng)。在這種情況下，TCP就可以使用推送(push)操作。這時(shí)，發(fā)送方TCP把PSH置為1，并立即創(chuàng)建一個(gè)報(bào)文段發(fā)送出去。接收方TCP收到PSH=1的報(bào)文段，就盡快地(即“推送”向前)交付接收應(yīng)用進(jìn)程。而不用再等到整個(gè)緩存都填滿了后再向上交付。

RST(Reset)：用于復(fù)位連接，中斷當(dāng)前的通信。當(dāng)?RST=1?時(shí)，表示?TCP?連接中出現(xiàn)異常(如主機(jī)崩潰或其他原因)必須強(qiáng)制斷開(kāi)連接，然后再重新建立連接進(jìn)行傳輸。RST置為1還用來(lái)拒絕一個(gè)非法的報(bào)文段或拒絕打開(kāi)一個(gè)連接。

SYN(Synchronize)：用于建立連接，發(fā)起連接請(qǐng)求。在連接建立時(shí)用來(lái)同步序號(hào)。當(dāng)SYN=1而ACK=0時(shí)，表明這是一個(gè)連接請(qǐng)求報(bào)文段。對(duì)方若同意建立連接，則應(yīng)在響應(yīng)的報(bào)文段中使SYN=1和ACK=1，因此SYN置為1就表示這是一個(gè)連接請(qǐng)求或連接接受報(bào)文。

FIN(Finish)：用于關(guān)閉連接，請(qǐng)求終止連接。當(dāng)FIN=1時(shí)，表示發(fā)送方?jīng)]有數(shù)據(jù)要傳輸了，要求釋放連接。

窗口大小(Window Size)：長(zhǎng)度為16位，指示接收方的接收窗口大小，用于流量控制，最大的窗口大小為2^16-1=65535=64k。這是早期的設(shè)計(jì)，對(duì)于現(xiàn)在的網(wǎng)絡(luò)應(yīng)用，可能會(huì)不太夠，因此可以在選項(xiàng)里加一個(gè) 窗口擴(kuò)大選項(xiàng)，來(lái)傳輸更多的數(shù)據(jù)。窗口指的是發(fā)送本報(bào)文段一方的接受窗口(而不是自己的發(fā)送窗口)。窗口值告訴對(duì)方：從本報(bào)文段首部中的確認(rèn)號(hào)算起，接收方目前允許對(duì)方發(fā)送的數(shù)據(jù)量(以字節(jié)為單位)。之所以要有這個(gè)限制，是因?yàn)榻邮辗降臄?shù)據(jù)緩存空間是有限的。總之，窗口值作為接收方讓發(fā)送方設(shè)置其發(fā)送窗口的依據(jù)。

校驗(yàn)和(Checksum)：長(zhǎng)度為16位，用于檢測(cè)TCP報(bào)文段是否在傳輸過(guò)程中發(fā)生了錯(cuò)誤。校驗(yàn)和計(jì)算包括報(bào)頭和數(shù)據(jù)。

緊急指針(Urgent Pointer)：長(zhǎng)度為16位，只有在URG標(biāo)志位被設(shè)置時(shí)才有效。它指出本報(bào)文段中的緊急數(shù)據(jù)的字節(jié)數(shù)(緊急數(shù)據(jù)結(jié)束后就是普通數(shù)據(jù))。因此，在緊急指針指出了緊急數(shù)據(jù)的末尾在報(bào)文段中的位置。當(dāng)所有緊急數(shù)據(jù)都處理完時(shí)，TCP就告訴應(yīng)用程序恢復(fù)到正常操作。值得注意的是，即使窗口為0時(shí)也可以發(fā)送緊急數(shù)據(jù)。

選項(xiàng)(Options)：可選字段，長(zhǎng)度可變，最長(zhǎng)可達(dá)40個(gè)字節(jié)。當(dāng)沒(méi)有使用“選項(xiàng)”時(shí)，TCP的首部長(zhǎng)度是20字節(jié)。選項(xiàng)字段用于提供額外的功能和控制，每個(gè)選項(xiàng)的開(kāi)始是 1 字節(jié)的kind字段，說(shuō)明選項(xiàng)的類(lèi)型。一些常見(jiàn)的選項(xiàng)舉例如下：

最大報(bào)文段長(zhǎng)度(Maximum Segment Size,?MSS)：占用4字節(jié)，通常在創(chuàng)建連接而設(shè)置SYN標(biāo)志的數(shù)據(jù)包中指明這個(gè)選項(xiàng)，指明本端所能接收的最大長(zhǎng)度的報(bào)文段。通常將MSS設(shè)置為(MTU-40)字節(jié)，攜帶TCP報(bào)文段的IP數(shù)據(jù)報(bào)的長(zhǎng)度就不會(huì)超過(guò)MTU(MTU最大長(zhǎng)度為1518字節(jié)，最短為64字節(jié))，從而避免本機(jī)發(fā)生IP分片。只能出現(xiàn)在同步報(bào)文段中，否則將被忽略。

窗口擴(kuò)大因子(Window Scale Factor)：占用3字節(jié)，取值0-14。用來(lái)把TCP的窗口的值左移的位數(shù)，使窗口值乘倍。只能出現(xiàn)在同步報(bào)文段中，否則將被忽略。這是因?yàn)楝F(xiàn)在的TCP接收數(shù)據(jù)緩沖區(qū)(接收窗口)的長(zhǎng)度通常大于65535字節(jié)。

時(shí)間戳選項(xiàng)(TCP Timestamps Option,?TSopt)：占用10字節(jié)，其中最主要的字段是時(shí)間戳字段(Timestamp Value field,?TSval,?4字節(jié))和時(shí)間戳回送回答字段(Timestamp Echo Reply field,?TSecr,?4字節(jié))。時(shí)間戳選項(xiàng)允許通信的兩端在TCP報(bào)文段中包含時(shí)間戳值，以便進(jìn)行一些時(shí)間相關(guān)的操作和計(jì)算。

安全摘要選項(xiàng)(TCP Authentication Option,?TCP Option)：用于提供數(shù)據(jù)完整性和身份驗(yàn)證的功能。該選項(xiàng)用于對(duì)TCP報(bào)文段進(jìn)行保護(hù)，防止數(shù)據(jù)篡改和未經(jīng)授權(quán)的訪問(wèn)。

3.數(shù)據(jù)包傳遞的地址解析

我們?cè)凇癐P協(xié)議詳細(xì)解析”一文中介紹了IP報(bào)頭中“源地址”和“目的地址”，與本文TCP報(bào)頭中的“源端口”和“目的端口”共同確定了數(shù)據(jù)包傳遞過(guò)程中需要的地址，如下圖所示。

類(lèi)比日常工作中郵寄信件，我們裝在信封里的信件相當(dāng)于要傳遞的數(shù)據(jù)，標(biāo)準(zhǔn)的信件格式是要在信封上寫(xiě)“收信人地址”和“寄信人地址”，相當(dāng)于IP地址，其中，“收信人地址”對(duì)應(yīng)數(shù)據(jù)包里IP報(bào)頭中的“目的IP地址”，“寄信人地址”對(duì)應(yīng)數(shù)據(jù)包里IP報(bào)頭中的“源IP地址”，寫(xiě)上寄信、收信兩個(gè)地址就可以保證信件可以郵寄到目的地了。

但信件郵寄到目的地址后由誰(shuí)來(lái)收？從上面這封信的收件人地址檢索到這個(gè)地址是位于上海市浦東新區(qū)張江“A公司B部門(mén)”的，這個(gè)部門(mén)可能有成百上千人，收件人不明確，即使把信件送到這個(gè)地址，也沒(méi)辦法投遞到具體的收信人。

因此，郵件信件需要填寫(xiě)“收件人姓名”、“收件人地址”和“寄件人姓名”、“寄件人地址”的組合，才能保證信件能準(zhǔn)確投遞到具體的收件人手中。這里的收信人姓名相當(dāng)于TCP報(bào)頭的目的端口，寄信人姓名相當(dāng)于TCP報(bào)頭的源端口。

對(duì)比傳遞信件，我們來(lái)看網(wǎng)絡(luò)數(shù)據(jù)包傳遞過(guò)程的例子。位于北京的李四(電腦IP地址: 106.54.28.25)給上海的張三(電腦IP地址: 114.92.67.193)通過(guò)QQ(端口: 80)發(fā)送一條消息，如下圖所示：

首先，李四電腦將消息打包成TCP數(shù)據(jù)報(bào)后，添加IP報(bào)頭和以太網(wǎng)報(bào)頭形成網(wǎng)絡(luò)數(shù)據(jù)包，發(fā)送到計(jì)算機(jī)網(wǎng)絡(luò)中。計(jì)算機(jī)網(wǎng)絡(luò)通過(guò)數(shù)據(jù)包中IP報(bào)頭的目的IP地址(114.92.67.193)把該數(shù)據(jù)包準(zhǔn)確傳遞到張三電腦。

張三電腦收到了李四電腦發(fā)送過(guò)來(lái)的數(shù)據(jù)包后，由于張三電腦上同時(shí)運(yùn)行有多個(gè)程序(例如圖中的QQ、微信、Foxmail等)，雖然張三電腦知道這個(gè)數(shù)據(jù)包是傳輸給它的，但是它不知道該把這個(gè)數(shù)據(jù)包中的數(shù)據(jù)交給哪個(gè)程序。

針對(duì)這個(gè)問(wèn)題，使用數(shù)據(jù)包中TCP報(bào)頭的源端口和目的端口，根據(jù)不同的程序使用不同端口號(hào)來(lái)確定應(yīng)用程序并發(fā)送和接受數(shù)據(jù)，這樣數(shù)據(jù)包就能像郵寄信件一樣準(zhǔn)確投遞到具體電腦上指定的程序了。例如我們指定張三電腦上QQ、微信、Foxmail使用的端口分別是80、8900和110，那么當(dāng)收到數(shù)據(jù)包里目的端口80就是傳輸給QQ的。

上述例子還可以引申出數(shù)據(jù)包結(jié)構(gòu)中的其他字段的作用，例如我們收到信后可以簡(jiǎn)單地通過(guò)信封是否完整，來(lái)檢查該信件是否被別人在傳輸途中拆開(kāi)并篡改過(guò)信件內(nèi)容。對(duì)于網(wǎng)絡(luò)數(shù)據(jù)包，TCP報(bào)頭的“校驗(yàn)和”(Checksum)可以驗(yàn)證收到數(shù)據(jù)包數(shù)據(jù)是否在途被別人拆開(kāi)修改過(guò)。

4.TCP連接

為什么需要建立TCP連接？首先，IP協(xié)議是無(wú)連接的，IP并不維護(hù)任何關(guān)于后續(xù)數(shù)據(jù)報(bào)的狀態(tài)信息，每個(gè)數(shù)據(jù)報(bào)的處理相互獨(dú)立。這種無(wú)連接的優(yōu)點(diǎn)是不占用線路，降低了對(duì)網(wǎng)絡(luò)線路的要求；此外，IP協(xié)議是不可靠的，不能保證IP數(shù)據(jù)報(bào)能成功到達(dá)目的地，是一種盡力而為的傳輸服務(wù)，路由器對(duì)IP報(bào)文出現(xiàn)錯(cuò)誤的處理方式是丟包，并發(fā)送ICMP(Internet Control Message Protocol，互聯(lián)網(wǎng)控制協(xié)議)控制消息給源地址。因?yàn)镮P協(xié)議是無(wú)連接、不可靠的，因此，需要上層TCP來(lái)建立連接和差錯(cuò)重傳，實(shí)現(xiàn)面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議。 ?

4.1 三次握手過(guò)程詳解

由于建立TCP連接的過(guò)程需要來(lái)回3次，所以將這個(gè)過(guò)程形象的叫做三次握手(Three-Way Handshake)，一旦建立連接，兩臺(tái)主機(jī)就可以進(jìn)行全雙工的通信。

下面是三次握手的詳細(xì)過(guò)程，包括發(fā)送的報(bào)文段內(nèi)容：

(1)第一次握手

首先客戶端發(fā)起連接請(qǐng)求，向服務(wù)器發(fā)送一個(gè)SYN(同步)報(bào)文段，段中包含了目的端口和本機(jī)端口，設(shè)置SYN?標(biāo)志位為1，即SYN=1，并設(shè)置序號(hào)字段(Sequence Number)為一個(gè)隨機(jī)選擇的x，即seq=x，也就是初始序號(hào)(Initial Sequence Number,?ISN)，如果是第一個(gè)連接，很可能是0。此時(shí)服務(wù)器對(duì)應(yīng)的端口要處于監(jiān)聽(tīng)狀態(tài)，客戶端發(fā)起請(qǐng)求后進(jìn)入?SYN_SENT?狀態(tài)，等待服務(wù)器的確認(rèn)。

(2)第二次握手

服務(wù)端收到客戶端發(fā)來(lái)的?SYN?報(bào)文段，對(duì)這個(gè)SYN報(bào)文段進(jìn)行確認(rèn)。服務(wù)器向客戶端發(fā)送一個(gè)SYN-ACK報(bào)文段作為回應(yīng)，報(bào)文段中的標(biāo)志位設(shè)置為SYN=1和ACK=1，表示同時(shí)作為確認(rèn)和同步；序號(hào)字段設(shè)置為服務(wù)器的隨機(jī)選擇的初始序號(hào)y(服務(wù)端的TCP段序號(hào))，即seq=y；確認(rèn)號(hào)字段(Acknowledgment Number)設(shè)置為客戶端的初始序號(hào)加1，即ack=x+1。服務(wù)器端將上述所有信息放到一個(gè)TCP段(即SYN+ACK段)中，一并發(fā)送給客戶端，此時(shí)服務(wù)器進(jìn)入SYN_RECV狀態(tài)。

(3)第三次握手

客戶端接收到服務(wù)端發(fā)來(lái)的?SYN+ACK?報(bào)文段后，要向服務(wù)端發(fā)送一個(gè)ACK(確認(rèn))報(bào)文段，對(duì)連接請(qǐng)求的確認(rèn)進(jìn)行確認(rèn)。報(bào)文段中的標(biāo)志位設(shè)置為ACK=1，確認(rèn)號(hào)字段設(shè)置為服務(wù)器的初始序號(hào)加1，即ack=y+1，序號(hào)字段設(shè)置為客戶端的初始序號(hào)加1，即seq=x+1。此時(shí)客戶端進(jìn)入?ESTABLISHED(已連接)狀態(tài)，服務(wù)端接收到此?TCP段，也將進(jìn)入?ESTABLISHED?狀態(tài)，也就標(biāo)志著三次握手結(jié)束，連接成功建立。

三次握手完成之后，TCP連接就正式建立起來(lái)了，雙方可以開(kāi)始進(jìn)行數(shù)據(jù)的可靠傳輸。三次握手的目的是確保雙方的初始序號(hào)和確認(rèn)號(hào)的同步，并驗(yàn)證雙方的可達(dá)性。通過(guò)這個(gè)過(guò)程，TCP可以建立一個(gè)可靠的雙向通信通道，在后續(xù)的數(shù)據(jù)傳輸中保證數(shù)據(jù)的可靠性和順序性。

4.2四次揮手

四次揮手是TCP斷開(kāi)連接的過(guò)程。

(1)第一次揮手

客戶端數(shù)據(jù)發(fā)送完成，則向服務(wù)端發(fā)送連接釋放請(qǐng)求的FIN報(bào)文(請(qǐng)求連接終止：FIN=1)，主動(dòng)關(guān)閉TCP連接。報(bào)文中會(huì)指定一個(gè)序列號(hào)seq=u，并停止再發(fā)送數(shù)據(jù)，但依然能夠接收數(shù)據(jù)。此時(shí)客戶端處于?FIN_WAIT_1?狀態(tài)，等待服務(wù)端確認(rèn)。TCP規(guī)定，F(xiàn)IN報(bào)文即使不攜帶數(shù)據(jù)，也要消耗一個(gè)序號(hào)。

(2)第二次揮手

服務(wù)端收到FIN報(bào)文之后，通知相應(yīng)的高層應(yīng)用進(jìn)程，告訴它客戶端向服務(wù)端這個(gè)方向的連接已經(jīng)釋放了。此時(shí)服務(wù)端向客戶端發(fā)出連接釋放的應(yīng)答ACK報(bào)文，并進(jìn)入了CLOSE_WAIT(關(guān)閉等待)狀態(tài)。ACK報(bào)文頭包含：ACK=1，ack=u+1，并且?guī)献约旱男蛄刑?hào)seq=v。這里ack=u+1是第一次揮手的序列值+1，表示希望收到從第u+1個(gè)字節(jié)開(kāi)始的報(bào)文段，并且已經(jīng)成功接收了前u個(gè)字節(jié)。

客戶端收到服務(wù)端的確認(rèn)后，進(jìn)入?FIN_WAIT_2?狀態(tài)，等待服務(wù)端發(fā)出的連接釋放報(bào)文段。

前兩次揮手既讓服務(wù)端知道了客戶端想釋放連接，也讓客戶端知道了服務(wù)端已了解自己想要釋放連接的請(qǐng)求。

(3)第三次揮手

如果服務(wù)端也想斷開(kāi)連接，就向客戶端發(fā)送連接釋放報(bào)文。由于在CLOS_WAIT狀態(tài)，服務(wù)端很可能又發(fā)送了一些數(shù)據(jù)，假定此時(shí)連接釋放報(bào)文的序列號(hào)為seq=w，ack也是取第一次揮手的seq +1，即ack=u+1，這和第二次揮手時(shí)是一樣的。

此時(shí)服務(wù)端就進(jìn)入了LAST_ACK(最后確認(rèn))狀態(tài)，等待客戶端的確認(rèn)，并停止向客戶端發(fā)送數(shù)據(jù)，但服務(wù)端仍能夠接收從客戶端傳輸過(guò)來(lái)的數(shù)據(jù)。

(4)第四次揮手

客戶端收到服務(wù)器的連接釋放報(bào)文后，一樣發(fā)送一個(gè)?ACK?報(bào)文作為應(yīng)答(ack=w+1，seq=u+1)， 此時(shí)客戶端處于TIME_WAIT(時(shí)間等待)狀態(tài)，并在這個(gè)狀態(tài)等待?2MSL(Two Maximum Segment Lifetime,?最大報(bào)文生存時(shí)間)。

服務(wù)端收到從客戶端發(fā)出的?TCP?報(bào)文之后結(jié)束?LAST-ACK?階段，進(jìn)入?CLOSED?階段。客戶端等待完?2MSL之后，結(jié)束?TIME-WAIT?階段，進(jìn)入?CLOSED?階段，由此完成四次揮手。

為什么客戶端在TIME_WAIT階段要等?2MSL？?主要有以下兩點(diǎn)：

一是為了保證客戶端發(fā)送的最后一個(gè)ACK報(bào)文段能夠到達(dá)服務(wù)器端，確保服務(wù)端能正常進(jìn)入CLOSED狀態(tài)。服務(wù)端在?1MSL?內(nèi)沒(méi)有收到客戶端發(fā)出的?ACK?確認(rèn)報(bào)文，就會(huì)再次向客戶端發(fā)出?FIN?報(bào)文。

二是為了避免新舊連接混淆。由于網(wǎng)絡(luò)滯留，客戶端可能發(fā)送了多次請(qǐng)求建立連接的請(qǐng)求，經(jīng)過(guò)時(shí)間2MSL，就可以使本鏈接持續(xù)時(shí)間內(nèi)所產(chǎn)生的所有報(bào)文段都從網(wǎng)絡(luò)中消失，這樣就可以使下一個(gè)新的連接中不會(huì)出現(xiàn)這種舊的連接請(qǐng)求報(bào)文段。

編輯：黃飛