TCP协议-TCP连接管理
一、TCP概述
TCP協(xié)議是 TCP/IP 協(xié)議族中一個(gè)非常重要的協(xié)議。它是一種面向連接、提供可靠服務(wù)、面向字節(jié)流的傳輸層通信協(xié)議。
TCP（Transmission Control Protocol，傳輸控制協(xié)議）。
1.1 TCP協(xié)議的特點(diǎn)
（1）TCP 是面向連接的傳輸層協(xié)議。這就是說(shuō)，通信雙方在使用TCP協(xié)議進(jìn)行通信之前，必須先建立TCP連接。在通信結(jié)束后，必須釋放已經(jīng)建立的TCP連接。這就好比打電話，通話前要先撥號(hào)建立連接，通話結(jié)束后要掛機(jī)釋放連接。
（2）TCP 是點(diǎn)對(duì)點(diǎn)（一對(duì)一）的連接。每一條TCP連接只能有兩個(gè)通信端點(diǎn)(endpoint)。所以基于廣播和多播（通信目標(biāo)是多個(gè)主機(jī)地址）的應(yīng)用程序不能使用TCP連接。
（3）TCP 提供可靠交付的通信服務(wù)。通過(guò)TCP連接傳遞的數(shù)據(jù)，無(wú)差錯(cuò)、不丟失、不重復(fù)，并且按序到達(dá)。
（4）TCP 提供全雙工通信。TCP允許通信雙方在任何時(shí)候都能發(fā)送和接收數(shù)據(jù)。TCP連接的兩端都設(shè)有發(fā)送緩存和接收緩存，用來(lái)臨時(shí)存放雙向通信的數(shù)據(jù)。在發(fā)送時(shí)，應(yīng)用程序在把數(shù)據(jù)發(fā)送給TCP的發(fā)送緩存后，就可以做自己的事，而TCP在合適的時(shí)候把數(shù)據(jù)通過(guò)網(wǎng)卡發(fā)送出去。在接收時(shí)，TCP把收到的數(shù)據(jù)先放入接收緩存，應(yīng)用層的應(yīng)用進(jìn)程在合適的時(shí)候再讀取緩存中的數(shù)據(jù)。
（5）TCP 是面向字節(jié)流的。TCP中的“流”(stream)指的是流入到進(jìn)程或從進(jìn)程流出的字節(jié)序列。“面向字節(jié)流”的含義是：雖然應(yīng)用程序和TCP的交互是一次一個(gè)數(shù)據(jù)塊（大小不等），但TCP把上層應(yīng)用程序交下來(lái)的數(shù)據(jù)僅僅看成是一連串無(wú)結(jié)構(gòu)的字節(jié)序列（就像水流一樣）。TCP并不知道所傳送的字節(jié)流的含義。TCP不保證接收方應(yīng)用程序所收到的數(shù)據(jù)塊和發(fā)送方應(yīng)用程序所發(fā)出的數(shù)據(jù)塊具有對(duì)應(yīng)大小的關(guān)系（例如，發(fā)送方應(yīng)用程序交給發(fā)送方的TCP共10個(gè)數(shù)據(jù)塊，但接收方的TCP可能只用了4個(gè)數(shù)據(jù)塊就把收到的字節(jié)流交付上層的應(yīng)用程序）。但是，接收方應(yīng)用程序收到的字節(jié)流必須和發(fā)送方應(yīng)用程序發(fā)出的字節(jié)流完全相同。因此，接收方的應(yīng)用程序必須有能力識(shí)別接收到的字節(jié)流，把它還原成有意義的應(yīng)用層數(shù)據(jù)。下圖的示意圖解釋了TCP面向字節(jié)流的含義：
TCP面向字節(jié)流的概念TCP和UDP在發(fā)送報(bào)文時(shí)所采用的方式完全不同。TCP并不關(guān)心上層的應(yīng)用程序一次把多長(zhǎng)的報(bào)文發(fā)送到TCP的緩存中，而是根據(jù)對(duì)方給出的窗口值和當(dāng)前網(wǎng)絡(luò)擁塞的程度來(lái)決定一個(gè)報(bào)文段應(yīng)該包含多少個(gè)字節(jié)（UDP發(fā)送的報(bào)文段是上層的應(yīng)用程序給出的）。如果應(yīng)用程序傳送到TCP緩存的數(shù)據(jù)塊太大，TCP就可以把它劃分短一些再傳送。如果應(yīng)用進(jìn)程一次只發(fā)來(lái)一個(gè)字節(jié)，TCP也可以等待積累有足夠多的字節(jié)后再構(gòu)成報(bào)文段發(fā)送出去。關(guān)于TCP報(bào)文段的長(zhǎng)度問(wèn)題，會(huì)在下面內(nèi)容中進(jìn)行討論。
1.2 TCP的連接概念
每一條TCP連接都有兩個(gè)端點(diǎn)。TCP連接的端點(diǎn)叫做套接字(socket)。根據(jù)RFC 793的定義：端口號(hào)拼接到(concatenated with)IP地址即構(gòu)成了套接字。因此，套接字的表示方法為：
套接字 socket = (IP地址：端口號(hào))
例如，若IP地址是 192.168.1.112，而端口號(hào)是 80，那么得到的套接字就是(192.168.1.112: 80)。
每一條TCP連接唯一地被通信兩端的兩個(gè)端點(diǎn)（即兩個(gè)套接字）所確定。即：
TCP連接 ::= {socket1, socket2} = {(IP1: port1), (IP2: port2)}
?IP1 和 IP2 分別是兩個(gè)端點(diǎn)主機(jī)的IP地址，而port1 和 port2 分別是兩個(gè)端點(diǎn)主機(jī)中的端口號(hào)。TCP連接的兩個(gè)套接字就是socket1 和 socket2。
二、TCP報(bào)文段的首部(頭部)結(jié)構(gòu)
TCP雖然是面向字節(jié)流的，但是TCP傳送的數(shù)據(jù)單元卻是報(bào)文段。一個(gè)TCP報(bào)文段分為首部和數(shù)據(jù)兩部分，而TCP的全部功能都體現(xiàn)在它首部中各字段的作用。因此，只有弄清楚TCP首部各字段的作用才能掌握TCP的工作原理。
這里再講一下“面向字節(jié)流”的含義，是指應(yīng)用層上的應(yīng)用程序?qū)?shù)據(jù)（這些數(shù)據(jù)可能是有結(jié)構(gòu)層次的）傳遞給傳輸層的TCP時(shí)，TCP只把這些數(shù)據(jù)看做是一連串的字節(jié)流，而不會(huì)去關(guān)心這些數(shù)據(jù)是什么結(jié)構(gòu)的。
TCP報(bào)文段首部的前20個(gè)字節(jié)是固定的，后面有4n字節(jié)是根據(jù)需要而增加的選項(xiàng)（n是整數(shù)）。因此TCP的首部的最小長(zhǎng)度是20字節(jié)。
下圖顯示了TCP首部的數(shù)據(jù)格式。如果不計(jì)選項(xiàng)字段，TCP首部的大小通常為20字節(jié)。
每個(gè)TCP首部都包含源端和目的端的端口號(hào)，大小均為16bit，用于尋找發(fā)送端和接收端應(yīng)用進(jìn)程。這兩個(gè)值+IP首部中的源端IP地址和目的端IP地址，就可以唯一確定一條TCP連接。
TCP報(bào)文段的首部格式?2.1 TCP首部固定部分各字段的含義
（1）源端口和目的端口：各占2字節(jié)，分別寫(xiě)入源端口號(hào)和目的端口號(hào)。和UDP的首部類似。
（2）序號(hào)：占4字節(jié)。序號(hào)范圍是 [0, 2^32-1]，共2^32（即4 294 967 296）個(gè)序號(hào)。序號(hào)增加到(2^32-1)后，下一個(gè)序號(hào)就又回到0。也就是說(shuō)，序號(hào)使用 mod 2^32 運(yùn)算。TCP是面向字節(jié)流的，在一個(gè)TCP連接中傳送的字節(jié)流中的每一個(gè)數(shù)據(jù)字節(jié)都按順序編號(hào)。整個(gè)要傳送的字節(jié)流的起始序號(hào)必須在TCP連接建立時(shí)設(shè)置。首部中序號(hào)字段值指的是本報(bào)文段所發(fā)送的數(shù)據(jù)的第一個(gè)字節(jié)的序號(hào)。
例如，某個(gè)TCP報(bào)文段的首部序號(hào)字段值是301，而這個(gè)報(bào)文段攜帶的數(shù)據(jù)共有100字節(jié)，那么最后一個(gè)字節(jié)的序號(hào)是400。顯然，下一個(gè)報(bào)文段（如果還有的話）的數(shù)據(jù)序號(hào)應(yīng)當(dāng)從401開(kāi)始，即下一個(gè)報(bào)文段的序號(hào)字段值是401。這個(gè)字段的名稱就叫做“報(bào)文段序號(hào)”。
（3）確認(rèn)號(hào)：占4字節(jié)。是期望收到對(duì)方下一個(gè)報(bào)文段的第一個(gè)數(shù)據(jù)字節(jié)的序號(hào)值。
例如，B正確收到了A發(fā)送過(guò)來(lái)的一個(gè)報(bào)文段，其序號(hào)字段值是501，而數(shù)據(jù)長(zhǎng)度是200字節(jié)（序號(hào)501~700）。這表明B正確收到了A發(fā)送的到需要700為止的數(shù)據(jù)。因此，B期望收到A的下一個(gè)數(shù)據(jù)字節(jié)序號(hào)是701，于是B在發(fā)送給A的確認(rèn)報(bào)文段中把確認(rèn)號(hào)設(shè)置為701。請(qǐng)注意，現(xiàn)在的確認(rèn)號(hào)不是501，也不是700，而是701。總之，應(yīng)當(dāng)記住：
若確認(rèn)號(hào) = N，則表明：到序號(hào) N-1 為止的所有數(shù)據(jù)都已正確收到。
由于序號(hào)字段有32位長(zhǎng)，可對(duì)4GB的數(shù)據(jù)進(jìn)行編號(hào)。在一般情況下，可保證當(dāng)序號(hào)重復(fù)使用，舊序號(hào)的數(shù)據(jù)早已通過(guò)網(wǎng)絡(luò)到達(dá)終點(diǎn)了。
（4）數(shù)據(jù)偏移：占 4 bit。這個(gè)字段用于記錄TCP報(bào)文段的首部長(zhǎng)度。由于TCP報(bào)文段的首部結(jié)構(gòu)中還有長(zhǎng)度不確定的選項(xiàng)字段，因此數(shù)據(jù)偏移字段是必要的。當(dāng)應(yīng)注意的是，“數(shù)據(jù)偏移”的單位是32位字（即為4字節(jié)的字長(zhǎng)為計(jì)算單位）。由于4位二進(jìn)制能夠表示的最大十進(jìn)制數(shù)是15，因此數(shù)據(jù)偏移的最大值是60字節(jié)，這也是TCP報(bào)文段首部的最大長(zhǎng)度（即選項(xiàng)字段長(zhǎng)度不能超過(guò)40字節(jié)）。一般情況下，TCP首部的長(zhǎng)度為20字節(jié)。
（5）保留：占6位。保留為今后使用，但目前應(yīng)置為0。
（6）6個(gè)控制位，用來(lái)說(shuō)明本報(bào)文段的性質(zhì)，它們各自的含義如下：
- 緊急URG：(Urgent Pointer)緊急指針字段。當(dāng)URG=1時(shí)，有效。它告訴系統(tǒng)此報(bào)文段有緊急數(shù)據(jù)，應(yīng)盡快傳送（相對(duì)于高級(jí)優(yōu)先的數(shù)據(jù)），而不要按原來(lái)的排隊(duì)順序來(lái)傳送。當(dāng) URG置1時(shí)，發(fā)送應(yīng)用進(jìn)程就告訴發(fā)送方的TCP有緊急數(shù)據(jù)要傳送。于是發(fā)送方TCP就把緊急數(shù)據(jù)插入到本報(bào)文段數(shù)據(jù)部分的最前面，而在緊急數(shù)據(jù)后面的數(shù)據(jù)仍是普通數(shù)據(jù)。這時(shí)要與首部中緊急指針(Urgent Pointer)字段配合使用。
例如，已經(jīng)發(fā)送了很長(zhǎng)的一個(gè)程序要在遠(yuǎn)地的主機(jī)上運(yùn)行。但后來(lái)發(fā)現(xiàn)了一些問(wèn)題，需要取消該程序的運(yùn)行。因此用戶從鍵盤發(fā)出中斷命令(ctrl + c)，如果不使用緊急數(shù)據(jù)，那么這兩個(gè)字符將存儲(chǔ)在接收TCP的緩存末尾。只有在所有的數(shù)據(jù)都被處理完畢后這兩個(gè)字符才被交付給接收方的應(yīng)用進(jìn)程，這樣做就浪費(fèi)了許多時(shí)間。
- 確認(rèn)ACK：(ACKnowledgment) 當(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) 當(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è)緩存都填滿后再向上交付。
雖然應(yīng)用程序可以選擇推送操作，但推送操作很少使用。
- 復(fù)位RST：(ReSeT) 當(dāng)RST=1時(shí)，表明TCP連接出現(xiàn)嚴(yán)重差錯(cuò)（如由于主機(jī)崩潰或其他原因），必須釋放連接，然后再重新建立TCP連接。RST置1，還可用來(lái)拒絕一個(gè)非法的報(bào)文段或拒絕打開(kāi)一個(gè)TCP連接。RST也可稱為重建位或重置位。我們將攜帶RST標(biāo)志的TCP報(bào)文段稱為復(fù)位報(bào)文段。
- 同步SYN：(SYNchronization)? 在TCP連接建立時(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)文段。我們將攜帶SYN標(biāo)志的TCP報(bào)文段稱為同步報(bào)文段。關(guān)于TCP連接的建立和釋放，會(huì)在下面的部分進(jìn)行詳細(xì)的討論。
- 終止FIN：(FINish)? 原來(lái)關(guān)閉一個(gè)TCP連接。當(dāng) FIN=1 時(shí)，表明此報(bào)文段的發(fā)送方的數(shù)據(jù)已經(jīng)發(fā)送完畢，通知對(duì)方本端要關(guān)閉連接了。我們將攜帶FIN標(biāo)志的TCP報(bào)文段稱為結(jié)束報(bào)文段。
（7）窗口：占2字節(jié)。窗口值是 [0, 2^16-1]之間的整數(shù)值。窗口字段指的是發(fā)送本報(bào)文段的一方的接收窗口(Receiver Window, RWND)（而不是自己的發(fā)送窗口）。窗口值告訴對(duì)方：本端的TCP接收緩沖區(qū)還能容納多少字節(jié)的數(shù)據(jù)，這樣對(duì)方就可以控制發(fā)送數(shù)據(jù)的速度。之所以要有這個(gè)限制，是因?yàn)榻邮辗降臄?shù)據(jù)緩存空間是有限的。總之，窗口值是接收方目前允許發(fā)送方發(fā)送的數(shù)據(jù)量（以字節(jié)為單位），作為發(fā)送方設(shè)置其發(fā)送窗口的依據(jù)。
例如，發(fā)送了一個(gè)TCP報(bào)文段，其確認(rèn)號(hào)是701，窗口字段值是1000。這就是告訴對(duì)方：從701號(hào)算起，我方（即發(fā)送此報(bào)文段的一方）的接收緩存空間還可接收1000個(gè)字節(jié)的數(shù)據(jù)（字節(jié)序號(hào)是701~1700），你在給我發(fā)送數(shù)據(jù)時(shí)，必須考慮到這一點(diǎn)。
總之，記住：窗口字段明確指出了 現(xiàn)在允許對(duì)方發(fā)送的數(shù)據(jù)量。窗口值經(jīng)常在動(dòng)態(tài)變化著。
（8）校驗(yàn)和：占2個(gè)字節(jié)。由發(fā)送方填充該字段，校驗(yàn)和字段檢驗(yàn)的范圍包括首部和數(shù)據(jù)這兩部分。接收端對(duì)TCP報(bào)文段執(zhí)行CRC算法以檢驗(yàn)TCP報(bào)文段在傳輸過(guò)程是否有損壞，校驗(yàn)和檢測(cè)也是TCP提供可靠傳輸?shù)囊粋€(gè)重要保障。和UDP數(shù)據(jù)報(bào)一樣，在計(jì)算校驗(yàn)和時(shí)，要在TCP數(shù)據(jù)報(bào)的前面加上12字節(jié)的偽首部。TCP偽首部的格式和UDP用戶數(shù)據(jù)報(bào)的偽首部格式一樣，但應(yīng)把偽首部第4個(gè)字段中的17改為6,（TCP的協(xié)議號(hào)是6），把第5個(gè)字段的UDP長(zhǎng)度改成TCP長(zhǎng)度。接收方收到此報(bào)文段后，仍要加上這個(gè)偽首部來(lái)計(jì)算校驗(yàn)和。若使用IPV6，則相應(yīng)的偽首部也要改變。
UDP用戶數(shù)據(jù)報(bào)的首部和偽首部（9）緊急指針：占2個(gè)字節(jié)。緊急指針字段僅在 URG=1 時(shí)才有意義。它指出本報(bào)文段中緊急數(shù)據(jù)的字節(jié)數(shù)（緊急數(shù)據(jù)都是放在TCP報(bào)文段數(shù)據(jù)部分的前面，緊急數(shù)據(jù)結(jié)束后才是普通數(shù)據(jù)）。該字段值和序號(hào)字段相加表示最后一個(gè)緊急數(shù)據(jù)的下一個(gè)字節(jié)的序號(hào)值。當(dāng)所有緊急數(shù)據(jù)都處理完時(shí)，TCP就告訴應(yīng)用程序恢復(fù)到正常操作。值得注意的是，即使窗口值為0時(shí)也可發(fā)送緊急數(shù)據(jù)。
（10）選項(xiàng)：TCP頭部最后一個(gè)選項(xiàng)(options)字段是可變長(zhǎng)的可選信息，最長(zhǎng)可達(dá)40字節(jié)，因此TCP首部最長(zhǎng)是60字節(jié)。當(dāng)沒(méi)有使用“選項(xiàng)”字段時(shí)，TCP首部長(zhǎng)度是20字節(jié)。
2.2 TCP首部選項(xiàng)字段結(jié)構(gòu)
TCP首部結(jié)構(gòu)的最后一個(gè)選項(xiàng)（Options）字段是一個(gè)可變長(zhǎng)的可選信息。
上面我們已經(jīng)知道，在TCP報(bào)文段的首部有一個(gè)“數(shù)據(jù)偏移”字段，占 4 bit位，最大能表示的十進(jìn)制數(shù)為 15，單位為32位字（也就是4字節(jié)），因此數(shù)據(jù)偏移字段的最大值是60字節(jié)。該字段的含義是TCP報(bào)文段的首部長(zhǎng)度。
因此，TCP首部選項(xiàng)字段的最大長(zhǎng)度 = 60字節(jié) - 首部固定大小的20字節(jié) = 40字節(jié)。
典型的TCP首部選型字段的結(jié)構(gòu)示意圖如下所示：
TCP首部選項(xiàng)字段的一般結(jié)構(gòu)- ?kind：占1個(gè)字節(jié)。該字段是說(shuō)明選項(xiàng)的類型。有的TCP選項(xiàng)沒(méi)有后面兩個(gè)字段，僅包含1字節(jié)的kind字段。
- length：占1個(gè)字節(jié)。指定該選項(xiàng)的總長(zhǎng)度。該長(zhǎng)度包括kind字段和length字段占據(jù)的2個(gè)字節(jié)。
- info：是選項(xiàng)的具體信息。常見(jiàn)的TCP選項(xiàng)有7種，如下圖所示：
（1）kind=0：是選項(xiàng)表結(jié)束選項(xiàng)。
（2）kind=1：是空操作(nop)選項(xiàng)，沒(méi)有特殊含義，一般用于將TCP選項(xiàng)的總長(zhǎng)度填充為4字節(jié)的整數(shù)倍。
（3）kind=2：是最大報(bào)文段長(zhǎng)度（Maximum Segment Size，MSS）選型。MSS是每一個(gè)TCP報(bào)文段中的數(shù)據(jù)部分的最大長(zhǎng)度。數(shù)據(jù)部分加上TCP首部才等于整個(gè)的TCP報(bào)文段，所以MSS并不是整個(gè)TCP報(bào)文段的最大長(zhǎng)度，而是TCP報(bào)文段長(zhǎng)度減去TCP首部長(zhǎng)度。TCP模塊通常將MSS設(shè)置為（MTU-40）字節(jié)（減掉的這40字節(jié)包括20字節(jié)的TCP首部長(zhǎng)度和20字節(jié)的IP首部長(zhǎng)度）。這樣攜帶TCP報(bào)文段的IP數(shù)據(jù)報(bào)的長(zhǎng)度就不會(huì)超過(guò)MTU（假設(shè)TCP報(bào)文段首部和IP數(shù)據(jù)報(bào)首部都不包含選項(xiàng)字段，當(dāng)然這是一般情況），從而本機(jī)發(fā)生IP分片。對(duì)于以太網(wǎng)而言，MSS的值是1460（1500-40）字節(jié)。
為什么要規(guī)定一個(gè)最大報(bào)文段長(zhǎng)度MSS呢？這并不是考慮接收方的接收緩存可能放不下TCP報(bào)文段中的數(shù)據(jù)，實(shí)際上，MSS與接收窗口值沒(méi)有關(guān)系。主要原因是為了提高網(wǎng)絡(luò)的利用率。因?yàn)門CP在傳送數(shù)據(jù)時(shí)，是以報(bào)文段為單位發(fā)送數(shù)據(jù)的。而待傳送的數(shù)據(jù)是以 MSS 的大小為單位進(jìn)行分割的，然后加上TCP首部，就組裝成一個(gè)完整的TCP報(bào)文段。進(jìn)行重發(fā)時(shí)，也是以 MSS 為單位。
如果MSS設(shè)置太低了，網(wǎng)絡(luò)的利用率就會(huì)降低；如果MSS設(shè)置太高了，又會(huì)增加網(wǎng)絡(luò)處理IP分片的開(kāi)銷。因此，設(shè)置一個(gè)合理的MSS值是很有必要的，MSS的值應(yīng)盡可能大些，只要在IP層傳輸時(shí)不需要再分片就行，最理想的情況是，最大TCP報(bào)文段長(zhǎng)度正好是IP數(shù)據(jù)報(bào)中不會(huì)被分片處理的最大數(shù)據(jù)長(zhǎng)度。
在建立TCP連接建立的過(guò)程中，雙方都把自己能夠支持的MSS填入這一字段，以后就按照這個(gè)數(shù)值傳送數(shù)據(jù)，兩個(gè)傳送方向可以有不同的MSS值。若主機(jī)未填寫(xiě)這一項(xiàng)，則MSS的默認(rèn)值是536字節(jié)長(zhǎng)度。因此，所有在互聯(lián)網(wǎng)上的主機(jī)都應(yīng)能接受報(bào)文段長(zhǎng)度是 536+20（TCP報(bào)文段固定首部長(zhǎng)度）=556字節(jié)。
<備注1> MTU(Maximum Transmission Unit，最大傳輸單元) 它屬于數(shù)據(jù)鏈路層上的概念，表示的是數(shù)據(jù)鏈層幀的數(shù)據(jù)部分的最大長(zhǎng)度。
<備注2> 有一種流行的說(shuō)法：在TCP連接建立的階段“雙方協(xié)商MSS值”，但這是錯(cuò)誤的，因?yàn)檫@里并不存在任何的協(xié)商，而只是一方把MSS值設(shè)定好以后通知另一方而已。
（4）kind=3：窗口擴(kuò)大因子選項(xiàng)。該選項(xiàng)是為了擴(kuò)大窗口。我們知道，TCP首部的窗口字段長(zhǎng)度是16位，因此最大的窗口大小為 64K(65 535) 字節(jié)。由上圖可知，窗口擴(kuò)大選項(xiàng)占3個(gè)字節(jié)，其中有一個(gè)字節(jié)表示移位值M。假設(shè)TCP首部中的接收窗口字段值為 N，窗口擴(kuò)大選項(xiàng)中的移位值為 M，那么TCP報(bào)文段的實(shí)際接收窗口大小為：N * 2^M，或者說(shuō)N左移M位。注意，M的取值范圍是[0, 14]的整數(shù)值。我們可以通過(guò)修改 Linux系統(tǒng)中的 /proc/sys/ipv4/tcp_window_scaling 內(nèi)核變量來(lái)啟動(dòng)或關(guān)閉窗口擴(kuò)大因子選項(xiàng)。
和MSS選項(xiàng)一樣，窗口擴(kuò)大因子選項(xiàng)只能出現(xiàn)在同步報(bào)文段中，否則將被忽略。但同步報(bào)文段本身不執(zhí)行窗口擴(kuò)大操作，即同步報(bào)文段首部的接收窗口字段值就是該TCP報(bào)文段的實(shí)際接收窗口大小。當(dāng)TCP連接建立好之后，每個(gè)數(shù)據(jù)傳輸方向的窗口擴(kuò)大因子就確定下來(lái)了。如果連接一方實(shí)現(xiàn)了窗口擴(kuò)大，當(dāng)它不再需要擴(kuò)大其窗口時(shí)，可發(fā)送M = 0的選型，使窗口大小回到16。
（5）kind=4：選擇確認(rèn)(Selective Acknowledgment, SACK)選項(xiàng)。TCP通信時(shí)，如果某個(gè)TCP報(bào)文段丟失，則TCP模塊會(huì)重傳最后被接收方確認(rèn)的TCP報(bào)文段后續(xù)的所有報(bào)文段，這樣原先已經(jīng)正確傳輸?shù)腡CP報(bào)文段也可能重復(fù)發(fā)送，從而降低了TCP性能。SACK選項(xiàng)正是為了改善這種情況而產(chǎn)生的，它使TCP模塊只重新發(fā)送丟失的TCP報(bào)文段，而不用發(fā)送所有未被確認(rèn)的TCP報(bào)文段。選擇確認(rèn)選項(xiàng)用在TCP連接建立過(guò)程中，表示是否支持SACK選項(xiàng)。我么可以通過(guò)修改Linux系統(tǒng)的 /proc/sys/net/ipv4/tcp_sack 內(nèi)核變量來(lái)啟用或關(guān)閉選擇確認(rèn)選項(xiàng)。
（6）kind=5：是SACK實(shí)際工作的選項(xiàng)。該選項(xiàng)的參數(shù)告訴發(fā)送方，本端已經(jīng)接收到的不連續(xù)的數(shù)據(jù)塊，從而讓發(fā)送端據(jù)此檢查并重發(fā)丟失的數(shù)據(jù)塊。每個(gè)塊邊沿(end of block)參數(shù)包含一個(gè)4字節(jié)的序號(hào)。其中，塊左邊沿表示不連續(xù)塊的第一個(gè)數(shù)據(jù)字節(jié)的序號(hào)，而塊右邊沿則表示不連續(xù)塊的最后一個(gè)數(shù)據(jù)字節(jié)的下一個(gè)字節(jié)序號(hào)。這樣一對(duì)參數(shù)（塊左邊沿和塊右邊沿）之間的數(shù)據(jù)就是沒(méi)有收到的。因?yàn)橐粋€(gè)塊信息占8字節(jié)，所有TCP首部選型中實(shí)際上最多可以包含4個(gè)這樣的不連續(xù)數(shù)據(jù)塊（考慮到選項(xiàng)類型的長(zhǎng)度占用的2個(gè)字節(jié)）。
（7）kind=8：是時(shí)間戳選項(xiàng)，占10個(gè)字節(jié)。時(shí)間戳選項(xiàng)有以下兩個(gè)功能：
第一，用來(lái)計(jì)算通信雙方之間的回路時(shí)間(Round Trip Time，RTT)。發(fā)送方在發(fā)送TCP報(bào)文段時(shí)把當(dāng)前時(shí)間值放入時(shí)間戳字段，接收方在確認(rèn)該報(bào)文段時(shí)把時(shí)間戳字段值復(fù)制到時(shí)間戳回顯應(yīng)答字段。因此，發(fā)送方在收到確認(rèn)報(bào)文后，可以準(zhǔn)確地計(jì)算出RTT來(lái)。
第二，用于處理TCP序號(hào)超過(guò)2^32(4,294,967,296)的情況，這又稱為防止序號(hào)繞回PAWS(Protect Against Wrapped Sequence numbers)。我們知道，TCP報(bào)文段的序號(hào)只有32位，而每增加2^32個(gè)序號(hào)后就會(huì)重新從0開(kāi)始編號(hào)。當(dāng)使用高速網(wǎng)絡(luò)時(shí)，在一次TCP連接的數(shù)據(jù)傳送中序號(hào)很可能會(huì)被重復(fù)使用。例如，當(dāng)使用 1.5Mbit/s的速率發(fā)送TCP報(bào)文段時(shí)，序號(hào)重復(fù)要6小時(shí)以上。但若使用2.5Gbit/s的速率發(fā)送數(shù)據(jù)報(bào)時(shí)，則不到14秒鐘序號(hào)就會(huì)重復(fù)。為了使接收方能夠把新的報(bào)文段和遲到很久的報(bào)文段（序號(hào)相同的情況下）區(qū)分開(kāi)，可以在報(bào)文段中加上時(shí)間戳選項(xiàng)。我們可以通過(guò)修改Linux系統(tǒng)的 /proc/sys/net/ipv4/tcp_timestamps 內(nèi)核變量來(lái)啟用和關(guān)閉時(shí)間戳選項(xiàng)。
示例1，我們使用Wireshark軟件查看一個(gè)TCP連接的SYN同步報(bào)文段信息。
SYN同步報(bào)文段信息?由上圖可以看到，TCP報(bào)文段首部各個(gè)字段的信息，該報(bào)文段的首部長(zhǎng)度是40字節(jié)，其中包括固定的首部長(zhǎng)度20字節(jié)+選項(xiàng)字段20字節(jié)長(zhǎng)度。標(biāo)志位Flags中，只有 SYN=1，其他標(biāo)志位均為0。初始序號(hào)值為0，確認(rèn)號(hào)為1，接收窗口值為5840，檢驗(yàn)和字段為0x5574，緊急指針字段為0。
?我們展開(kāi)其Options選項(xiàng)的內(nèi)容，如下圖所示：
SYN同步報(bào)文段Options選項(xiàng)信息?由上圖可知，在Options選項(xiàng)中，設(shè)置了如下的幾種TCP選項(xiàng)：
- kind=2，最大報(bào)文段MSS選項(xiàng)，MSS的值為1460。
- kind=4，選擇確認(rèn)SACK選項(xiàng)
- kind=8，時(shí)間戳timestamps選項(xiàng)
- kind=1，無(wú)操作NOP選項(xiàng)
- kind=3，窗口擴(kuò)大(Window scale)選項(xiàng)，移位值為7，可以擴(kuò)大2^7=128倍。
三、TCP的連接管理
TCP是面向連接的傳輸層協(xié)議。TCP連接的建立和釋放是每一次面向連接的通信中必不可少的過(guò)程。因此TCP通信過(guò)程有3個(gè)階段，即：連接建立、數(shù)據(jù)傳輸和連接釋放。這里我們主要將TCP連接的建立和釋放的過(guò)程。
3.1 TCP連接的建立
TCP連接的建立采用客戶-服務(wù)器方式。主動(dòng)發(fā)起連接建立的應(yīng)用進(jìn)程叫做客戶端(client)，而被動(dòng)等待連接建立的應(yīng)用進(jìn)程叫做服務(wù)器(server)。
TCP建立連接的過(guò)程叫做握手，握手的過(guò)程需要在客戶端和服務(wù)器之間交換3個(gè)TCP報(bào)文段，因此我們形象地將TCP連接的建立過(guò)程稱為“三次握手”。
下圖是TCP三次握手建立連接的過(guò)程，假定主機(jī)A運(yùn)行的是TCP客戶程序，主機(jī)B運(yùn)行的是TCP服務(wù)器程序。最初兩端的TCP進(jìn)程都處于關(guān)閉(Closed)狀態(tài)。注意：A客戶端主動(dòng)打開(kāi)連接，B服務(wù)器被動(dòng)打開(kāi)連接。
?描述整個(gè)過(guò)程：
【1. 服務(wù)器初始化狀態(tài)】
主機(jī)B的TCP服務(wù)器進(jìn)程先創(chuàng)建傳輸控制塊(TCB)，這時(shí)socket()，bind() 函數(shù)已經(jīng)執(zhí)行完畢，服務(wù)器進(jìn)程準(zhǔn)備接受客戶進(jìn)程的連接請(qǐng)求。然后服務(wù)器進(jìn)程調(diào)用listen()函數(shù)，此時(shí)服務(wù)器進(jìn)程處于監(jiān)聽(tīng)(listen)狀態(tài)，緊接著調(diào)用accept()函數(shù)，等待客戶的連接請(qǐng)求到來(lái)。如有，即作出響應(yīng)。
服務(wù)端進(jìn)程調(diào)用函數(shù)順序：socket—>bind—>listen—>accept。當(dāng)執(zhí)行到accept()函數(shù)時(shí)，服務(wù)器進(jìn)程會(huì)一直處于阻塞狀態(tài)，直到有客戶連接請(qǐng)求到達(dá)才返回。
【2. 客戶端發(fā)起連接請(qǐng)求，發(fā)送SYN同步報(bào)文段，第一次握手】
主機(jī)A的客戶進(jìn)程也是首先創(chuàng)建傳輸控制塊(TCB)，然后向主機(jī)B發(fā)出連接請(qǐng)求報(bào)文段，這時(shí)請(qǐng)求報(bào)文段的首部的同步位SYN=1，同時(shí)選擇一個(gè)初始序號(hào)seq=x，這個(gè)初始序號(hào)x就是隨機(jī)產(chǎn)生的整數(shù)ISN。TCP規(guī)定，SYN報(bào)文段（即SYN=1的TCP報(bào)文段）不能攜帶數(shù)據(jù)，但要消耗一個(gè)序號(hào)。這時(shí)，TCP客戶進(jìn)程進(jìn)入 SYN-SENT(同步已發(fā)送) 狀態(tài)。
客戶進(jìn)程調(diào)用函數(shù)順序：socket——>connect。當(dāng)客戶進(jìn)程調(diào)用connect()函數(shù)時(shí)，客戶進(jìn)程就會(huì)向服務(wù)器進(jìn)程發(fā)出連接請(qǐng)求的SYN同步報(bào)文段。
前面我們已經(jīng)講過(guò)，攜帶SYN標(biāo)志的TCP報(bào)文段稱為同步報(bào)文段。此時(shí)，同步標(biāo)志位 SYN = 1。
ISN(Initial Sequence Number) 初始序列號(hào)
【3. 服務(wù)器同意建立連接，回復(fù)確認(rèn)信息，第二次握手】
主機(jī)B的服務(wù)器進(jìn)程收到連接請(qǐng)求報(bào)文段后，如同意建立連接，則向主機(jī)A的客戶進(jìn)程發(fā)送確認(rèn)報(bào)文段。在確認(rèn)報(bào)文段的首部中，SYN=1，ACK=1，確認(rèn)號(hào)=x+1（沒(méi)有數(shù)據(jù)，所以長(zhǎng)度為0，直接seq+1即可），同時(shí)也為自己選擇一個(gè)初始序號(hào)seq = y。請(qǐng)注意，這個(gè)確認(rèn)報(bào)文段也不能攜帶數(shù)據(jù)，但同樣要消耗一個(gè)序號(hào)。這時(shí)，TCP服務(wù)器進(jìn)程進(jìn)入 SYN-RCVD(同步收到) 狀態(tài)。
【4. 客戶端確認(rèn)連接，發(fā)送確認(rèn)連接信息，第三次握手】
主機(jī)A的客戶進(jìn)程收到主機(jī)B的服務(wù)器進(jìn)程的確認(rèn)報(bào)文段后，還要向主機(jī)B的服務(wù)器進(jìn)程的SYN報(bào)文段給出確認(rèn)。在確認(rèn)報(bào)文段的首部中，ACK=1，確認(rèn)號(hào)ack=y+1，而自己的序號(hào)seq=x+1。TCP的標(biāo)準(zhǔn)規(guī)定，ACK報(bào)文段可以攜帶數(shù)據(jù)。但如果不攜帶數(shù)據(jù)，則不消耗序號(hào)。在這種情況下，客戶進(jìn)程的下一個(gè)數(shù)據(jù)報(bào)文段的序號(hào)仍是seq=x+1。這是，TCP連接已經(jīng)建立，主機(jī)A的客戶進(jìn)程也進(jìn)入 ESTABLISHED(已建立連接)狀態(tài)。當(dāng)主機(jī)B的服務(wù)器進(jìn)程接收到主機(jī)A的客戶進(jìn)程發(fā)來(lái)的確認(rèn)報(bào)文段后，也進(jìn)入ESTABLISHED(已建立連接)狀態(tài)。
上面給出的TCP連接建立過(guò)程叫做“三次握手”。請(qǐng)注意，在上圖中，B發(fā)送給A的報(bào)文段，也可以拆成兩個(gè)報(bào)文段分兩次發(fā)送。即先發(fā)送對(duì)A的連接請(qǐng)求同步報(bào)文段的確認(rèn)報(bào)文段(ACK=1, ack=x=1)，接著再發(fā)送B自己的連接請(qǐng)求的同步報(bào)文段(SYN=1, seq=y)給A。A收到B的同步報(bào)文段后，再給B回復(fù)一個(gè)確認(rèn)報(bào)文段。那么，這樣的過(guò)程就變成了“四次握手”，但效果是一樣的。
?3.1.1 TCP連接建立相關(guān)問(wèn)題
問(wèn)題1：TCP連接的建立為什么需要3次握手，而不是兩次握手？
在謝希仁編寫(xiě)的《計(jì)算機(jī)網(wǎng)絡(luò)》一書(shū)中，給出的理由是：防止已失效的連接請(qǐng)求報(bào)文段突然又傳送到了服務(wù)器端，因而產(chǎn)生錯(cuò)誤。但是這個(gè)解釋是不夠準(zhǔn)確的，不是最根本原因。首先，我們要清楚一點(diǎn)，TCP是全雙工通信的。三次握手的一個(gè)重要作用是客戶端和服務(wù)端交換彼此的ISN，以便讓對(duì)方知道接下來(lái)接收數(shù)據(jù)的時(shí)候如何按序列號(hào)重新組裝TCP報(bào)文段。如果只有兩次握手，至多只有連接發(fā)起方的起始序列號(hào)被確認(rèn)，而另一方的起始序列號(hào)卻得不到對(duì)方的確認(rèn)。因?yàn)橹挥蠺CP通信雙方的SYN同步報(bào)文段的首部中有本端的起始序列號(hào)，所以每一方都要對(duì)對(duì)方的SYN同步報(bào)文段回復(fù)一個(gè)ACK確認(rèn)報(bào)文段，用來(lái)表明我方已經(jīng)確認(rèn)收到你方發(fā)送的同步報(bào)文段了。
結(jié)論：TCP連接的建立過(guò)程中的三次握手，握的就是通信雙方的起始序列號(hào)。三次握手實(shí)質(zhì)上是三報(bào)文握手。
下面，我們來(lái)討論一下謝希仁先生給出的理由的這種情況的分析。
（1）“已失效的連接請(qǐng)求報(bào)文”是如何產(chǎn)生的。現(xiàn)假定出現(xiàn)一種異常情況，即 客戶端A發(fā)出的第一個(gè)連接請(qǐng)求報(bào)文段并沒(méi)有丟失，而是在某個(gè)網(wǎng)絡(luò)結(jié)點(diǎn)長(zhǎng)時(shí)間滯留了，以致延誤到連接釋放以后的某個(gè)時(shí)間才到達(dá)B。本來(lái)這是一個(gè)早已失效的連接請(qǐng)求報(bào)文段，但服務(wù)端B收到此失效的連接請(qǐng)求報(bào)文段后，就誤以為是客戶端A又發(fā)出一次新的連接請(qǐng)求。于是就向A發(fā)出確認(rèn)報(bào)文段，同意建立連接。如果只有兩次握手，那么只要B發(fā)出確認(rèn)報(bào)文段，B就認(rèn)為新的連接建立了，B進(jìn)入ESTABLISHED(已建立連接)狀態(tài)。
（2）由于現(xiàn)在A并沒(méi)有發(fā)出建立連接的請(qǐng)求，因此不會(huì)理睬B的確認(rèn)，也不會(huì)向B發(fā)送數(shù)據(jù)。但B卻以為新的連接是已經(jīng)建立了的，并一直在等待A發(fā)來(lái)數(shù)據(jù)。也就是說(shuō)，B此時(shí)一直處于忙等狀態(tài)，其結(jié)果是浪費(fèi)了B的資源開(kāi)銷。
結(jié)論：兩次握手，可能導(dǎo)致服務(wù)器需要維護(hù)許多不成功的TCP連接，造成服務(wù)器資源的浪費(fèi)。
需要注意的是，在TCP連接建立的過(guò)程中，只要服務(wù)器進(jìn)程收到了連接請(qǐng)求的SYN同步報(bào)文段，服務(wù)器就會(huì)為這個(gè)連接請(qǐng)求創(chuàng)建傳輸控制塊TCB數(shù)據(jù)結(jié)構(gòu)，這就需要開(kāi)辟內(nèi)存空間來(lái)維護(hù)這個(gè)數(shù)據(jù)結(jié)構(gòu)。
問(wèn)題2：在TCP連接建立過(guò)程中，如果服務(wù)器一直收不到客戶端的ACK確認(rèn)報(bào)文段，會(huì)發(fā)生什么？
操作系統(tǒng)會(huì)給每個(gè)處于 SYN-RCVD狀態(tài)的服務(wù)器進(jìn)程都設(shè)定一個(gè)定時(shí)器，如果超時(shí)時(shí)間還沒(méi)有收到客戶端第三次握手的ACK確認(rèn)報(bào)文段，將會(huì)重新發(fā)送第二次握手的報(bào)文段，直到重發(fā)達(dá)到一定次數(shù)時(shí)才會(huì)放棄。
問(wèn)題3：初始序列號(hào)ISN為什么要隨機(jī)初始化？
seq序號(hào)表示的是發(fā)送的TCP報(bào)文段數(shù)據(jù)部分的起始字節(jié)位置，服務(wù)器/客戶端可以通過(guò)序號(hào)正確讀取數(shù)據(jù)。如果不是隨機(jī)分配起始序列號(hào)，那么黑客就會(huì)很容易獲取到客戶端與服務(wù)器之間TCP通信的初始序列號(hào)，然后通過(guò)偽造序列號(hào)讓通信主機(jī)讀取到攜帶病毒的TCP報(bào)文段，發(fā)起網(wǎng)絡(luò)攻擊。
問(wèn)題4：在TCP連接建立的過(guò)程中，可能會(huì)出現(xiàn)什么攻擊？如何解決？
SYN flood 攻擊：又稱為SYN泛洪攻擊。下面介紹一下泛洪攻擊是如何發(fā)生的。
（1）攻擊者在短時(shí)間內(nèi)偽造大量不存在的IP地址，向服務(wù)器不斷地發(fā)送連接請(qǐng)求的SYN同步報(bào)文段，當(dāng)服務(wù)端收到這些連接請(qǐng)求的報(bào)文段后，就會(huì)為該連接請(qǐng)求創(chuàng)建傳輸控制塊來(lái)保存客戶端的信息。當(dāng)有大量的連接請(qǐng)求時(shí)，服務(wù)器會(huì)消耗掉大量的內(nèi)存資源，直至內(nèi)存資源被耗盡。
（2）服務(wù)器同時(shí)需要為每條連接請(qǐng)求回復(fù)ACK確認(rèn)報(bào)文段，并等待客戶端的確認(rèn)。但是客戶端的IP地址是虛假的，也就不會(huì)向服務(wù)器回復(fù)確認(rèn)報(bào)文段，那么服務(wù)器需要不斷地重發(fā)第2次握手的報(bào)文段直至超時(shí)。同時(shí)，這些偽造的連接請(qǐng)求SYN同步報(bào)文段還將長(zhǎng)時(shí)間占用未連接隊(duì)列（Linux默認(rèn)的限制一般是256個(gè)），導(dǎo)致正常客戶端的連接請(qǐng)求SYN同步報(bào)文段被丟棄，目標(biāo)系統(tǒng)運(yùn)行緩慢，嚴(yán)重者引起網(wǎng)絡(luò)阻塞甚至服務(wù)器系統(tǒng)癱瘓。
我們可以通過(guò)下面這個(gè)圖來(lái)直觀了解一下SYN泛洪攻擊的過(guò)程：
SYN泛洪攻擊?解決的辦法：
方法1：縮短SYN Timeout 時(shí)間。由于 SYN Flood 攻擊的效果取決于服務(wù)器上保持的半連接數(shù)，這個(gè)值=SYN攻擊頻度 x SYN Timeout，所以通過(guò)縮短從接收到SYN報(bào)文段到確定這個(gè)報(bào)文段無(wú)效并丟棄該連接的時(shí)間。例如，設(shè)置為20秒以下（過(guò)低的SYN Timeout 設(shè)置可能會(huì)影響客戶的正常訪問(wèn)），可以成倍地降低服務(wù)器的載荷。
方法2：設(shè)置 SYN Cookie。就是給每一個(gè)連接請(qǐng)求的IP地址分配一個(gè)Cookie，如果短時(shí)間內(nèi)連續(xù)收到某個(gè)IP地址的大量重復(fù)SYN報(bào)文段，就認(rèn)定是收到了攻擊。以后從這個(gè)IP地址來(lái)的報(bào)文段會(huì)被丟棄。
方法3：使用防火墻。SYN Flood攻擊很容易就能被防火墻攔截。
3.1.2 連接超時(shí)問(wèn)題
前面介紹的是TCP連接正常建立的過(guò)程。如果客戶端訪問(wèn)一個(gè)距離它很遠(yuǎn)的服務(wù)器或者由于網(wǎng)絡(luò)繁忙，導(dǎo)致服務(wù)器對(duì)于客戶端發(fā)出的同步報(bào)文段沒(méi)有應(yīng)答，此時(shí)客戶端程序?qū)a(chǎn)生什么樣的行為呢？顯然，對(duì)于提供可靠服務(wù)的TCP來(lái)說(shuō)，它必然是先進(jìn)行重連（可能執(zhí)行多次），如果重連仍然無(wú)效，則通知應(yīng)用程序連接超時(shí)，建立TCP連接失敗。
發(fā)起TCP連接請(qǐng)求的客戶端，當(dāng)發(fā)送了同步報(bào)文段后，會(huì)開(kāi)啟一個(gè)重傳定時(shí)器，當(dāng)超時(shí)時(shí)間到達(dá)后，如果沒(méi)有收到確認(rèn)報(bào)文段，會(huì)重發(fā)一次同步報(bào)文段，并將重連的超時(shí)時(shí)間增加一倍，直到達(dá)到規(guī)定的重連次數(shù)為止。TCP重連次數(shù)是由 /proc/sys/net/ipv4/tcp_syn_retries 內(nèi)核變量定義的，默認(rèn)值是6，它表示的含義是建立TCP連接時(shí)SYN同步報(bào)文段重發(fā)的次數(shù)。
可以通過(guò)sysctl 命令來(lái)查看：（Linux系統(tǒng)：CentOS-8.3）
# sysctl -a | grep tcp_syn_retries net.ipv4.tcp_syn_retries = 6?在Linux系統(tǒng)中，連接超時(shí)典型為2分7秒，而對(duì)于一些Client來(lái)說(shuō)，這是一個(gè)非常長(zhǎng)的時(shí)間，所以在實(shí)際網(wǎng)絡(luò)編程中，可以使用非阻塞模式來(lái)實(shí)現(xiàn)。例如：使用 select(2)、poll(2)、epoll(2)等系統(tǒng)調(diào)用來(lái)實(shí)現(xiàn)多路復(fù)用。
下來(lái)來(lái)分析一下，這個(gè)2分7秒的時(shí)間間隔是怎樣來(lái)的。
2分7秒 即 127秒，剛好是 2 的 7 次冪減1，如果TCP連接建立的SYN報(bào)文段超時(shí)時(shí)間間隔是按照2的冪來(lái)遞增的話，那么：
第 1 次發(fā)送 SYN 報(bào)文后等待 1s（2 的 0 次冪），如果超時(shí)，則重發(fā) 第 2 次發(fā)送后等待 2s（2 的 1 次冪），如果超時(shí)，則重發(fā) 第 3 次發(fā)送后等待 4s（2 的 2 次冪），如果超時(shí)，則重發(fā) 第 4 次發(fā)送后等待 8s（2 的 3 次冪），如果超時(shí)，則重發(fā) 第 5 次發(fā)送后等待 16s（2 的 4 次冪），如果超時(shí)，則重發(fā) 第 6 次發(fā)送后等待 32s（2 的 5 次冪），如果超時(shí)，則重發(fā) 第 7 次發(fā)送后等待 64s（2 的 6 次冪），如果超時(shí)，則超時(shí)失敗綜上，1+2+4+8+16+32+64=127?上面總的超時(shí)時(shí)間剛好是127秒。也就是說(shuō)，Linux內(nèi)核在嘗試建立TCP連接時(shí)，最多會(huì)嘗試7次，重發(fā)6次。
修改重連次數(shù)和超時(shí)時(shí)間
可以通過(guò)以下命令修改該值，例如將其改為5。
sysctl -w net.ipv4.tcp_syn_retries=5如果希望重啟系統(tǒng)后仍生效，可以在 /etc/sysctl.conf 文件中添加如下內(nèi)容：
net.ipv4.tcp_syn_retries=5在應(yīng)用程序中，我們可以通過(guò)設(shè)置socket選項(xiàng)中的 SO_SNDTIMEO 選項(xiàng)，然后調(diào)用connect()函數(shù)。具體代碼如下：
//設(shè)置connect超時(shí)時(shí)間 int timeout_connect(const char *ip, int port, int timeout) {int ret = 0;struct sockaddr_in cli_addr;bzero(&cli_addr, sizeof(cli_addr));cli_addr.sin_family = AF_INET;inet_pton(AF_INET, ip, &cli_addr.sin_addr);cli_addr.sin_port = htons(port);int sockfd = socket(AF_INET, SOCK_STREAM, 0);assert(sockfd >= 0)//通過(guò)選項(xiàng)SO_SNDTIMEO所設(shè)置的超時(shí)時(shí)間類型是timeval,這和select()系統(tǒng)調(diào)用的超時(shí)參數(shù)類型相同struct timeval timeout;timeout.tv_sec = time;timeout.tv_usec = 0;socklen_t len = sizeof(timeout);ret = setsockopt(sockfd, SOL_SOCKET, SO_SNDTIMEO, &timeout, len);assert(ret != 1);ret = connect(sockfd, (struct sockaddr*)&cli_addr, sizeof(cli_addr));if(ret == -1){//超時(shí)對(duì)應(yīng)的錯(cuò)誤號(hào)是EINPROGRESS。下面這個(gè)條件如果成立，我們就可以處理定時(shí)任務(wù)了if(errno == EINPROGRESS){printf("connection timeout, process timeout logic\n");return -1;}printf("error occur when connecting to server\n");return -1;}return sockfd; }3.2 TCP連接的釋放
TCP連接的釋放可以用“四次揮手”的過(guò)程來(lái)描述。數(shù)據(jù)傳輸結(jié)束后，通信的雙方都可釋放連接。現(xiàn)在 客戶端A和服務(wù)器B都處于 ESTABLISHED 狀態(tài)。釋放連接的過(guò)程如下圖所示：
?描述整個(gè)過(guò)程：
【1. A客戶端主動(dòng)斷開(kāi)連接，發(fā)送釋放連接的FIN報(bào)文段，第一次揮手】
A客戶端進(jìn)程先向B服務(wù)器進(jìn)程發(fā)送釋放連接的FIN結(jié)束報(bào)文段，并停止再發(fā)送數(shù)據(jù)，主動(dòng)關(guān)閉TCP連接。在結(jié)束報(bào)文段的首部中，終止控制位FIN=1，其序號(hào)字段seq=u，它等于前面已發(fā)送過(guò)的數(shù)據(jù)的最后一個(gè)字節(jié)的序號(hào)加1。此時(shí)，A客戶端進(jìn)程進(jìn)入 FIN-WAIT-1（終止等待1）狀態(tài)，等待B服務(wù)器進(jìn)程的確認(rèn)。請(qǐng)注意，TCP規(guī)定，FIN報(bào)文段即使不攜帶數(shù)據(jù)，它也要消耗掉一個(gè)序號(hào)。這點(diǎn)和SYN報(bào)文段是一樣的。
【2. B服務(wù)器收到A客戶端的結(jié)束報(bào)文段，發(fā)出確認(rèn)報(bào)文段，第二次揮手】
B服務(wù)器進(jìn)程收到A客戶端進(jìn)程發(fā)來(lái)的釋放連接的FIN結(jié)束報(bào)文段后，立即發(fā)出確認(rèn)報(bào)文段，確認(rèn)號(hào)ack=u+1，而這個(gè)報(bào)文段自己的序號(hào)seq=v，等于B服務(wù)器前面已發(fā)送過(guò)的數(shù)據(jù)的最后一個(gè)字節(jié)的序號(hào)加1。然后B服務(wù)器進(jìn)程進(jìn)入 CLOSE-WAIT（關(guān)閉等待）狀態(tài)。TCP服務(wù)器進(jìn)程這時(shí)通知高層的應(yīng)用進(jìn)程，那么從 A 到 B 這個(gè)方向的連接就釋放了，此時(shí)TCP連接處于半關(guān)閉(half-close)狀態(tài)，即A客戶端已經(jīng)沒(méi)有數(shù)據(jù)要發(fā)送了，但B服務(wù)器若發(fā)送數(shù)據(jù)，A客戶端仍要接收。也就是說(shuō)，從 B 到 A 這個(gè)方向的連接并未關(guān)閉，這個(gè)狀態(tài)可能會(huì)持續(xù)一段時(shí)間。
A客戶端收到B服務(wù)器的確認(rèn)報(bào)文段后，就進(jìn)入 FIN-WAIT-2（終止等待2）狀態(tài)，等待B服務(wù)器發(fā)出的FIN結(jié)束報(bào)文段。
【3. B服務(wù)器釋放連接，發(fā)出連接釋放的結(jié)束報(bào)文段，第三次揮手】
當(dāng)B服務(wù)器已經(jīng)沒(méi)有要向A客戶端發(fā)送的數(shù)據(jù)時(shí)，其應(yīng)用進(jìn)程就通知TCP釋放連接，向A客戶端發(fā)送釋放連接的結(jié)束報(bào)文段。在這個(gè)結(jié)束報(bào)文段的首部中，終止控制位FIN置1，假定其序號(hào)字段為w（在半關(guān)閉狀態(tài)中，B服務(wù)器可能又發(fā)送了一些數(shù)據(jù)），同時(shí)還必須重復(fù)上次已發(fā)送過(guò)的確認(rèn)號(hào)ack=u+1。這時(shí)，B服務(wù)器進(jìn)程就進(jìn)入 LAST-ACK（最后確認(rèn)）狀態(tài)，等待A客戶端的確認(rèn)。
【4. A客戶端收到B服務(wù)器釋放連接的結(jié)束報(bào)文段，發(fā)出確認(rèn)報(bào)文段，第四次揮手】
A客戶端在收到B服務(wù)器的釋放連接的結(jié)束報(bào)文段后，必須對(duì)此發(fā)出確認(rèn)，即向B服務(wù)端發(fā)送一個(gè)確認(rèn)報(bào)文段。在確認(rèn)報(bào)文段的首部中，控制位ACK=1，確認(rèn)號(hào)字段ack=w+1，而自己的序號(hào)字段seq=u+1（根據(jù)TCP標(biāo)準(zhǔn)，前面發(fā)送過(guò)的FIN報(bào)文段是要消耗一個(gè)序號(hào)的）。然后A客戶端進(jìn)入到TIME-WAIT（時(shí)間等待）狀態(tài)。
請(qǐng)注意，此時(shí)TCP連接還沒(méi)有釋放掉，必須經(jīng)過(guò)時(shí)間等待計(jì)時(shí)器(TIME-WAIT timer)設(shè)置的時(shí)間2MSL后，A才進(jìn)入到 CLOSED 狀態(tài)。時(shí)間MSL(Maximum Segment Lifetime，最長(zhǎng)報(bào)文段壽命) 即一個(gè)TCP報(bào)文段存活的最長(zhǎng)時(shí)間。RFC793建議設(shè)為2分鐘，現(xiàn)在可以根據(jù)情況使用更小的MSL值。因此從A客戶端進(jìn)入到 TIME-WAIT 狀態(tài)后，要經(jīng)過(guò)4分鐘才能進(jìn)入到CLOSED狀態(tài)，才可以建立下一個(gè)新的連接，當(dāng)A客戶端撤銷相應(yīng)的傳輸控制塊TCB后，就結(jié)束了這次的TCP連接。
B服務(wù)器只要收到了A客戶端發(fā)出的確認(rèn)報(bào)文段，就進(jìn)入 CLOSED狀態(tài)。同樣，B服務(wù)器在撤銷相應(yīng)的傳輸控制塊TCB后，就結(jié)束了此次的TCP連接。
可以發(fā)現(xiàn)，B服務(wù)器結(jié)束TCP連接的時(shí)間要比A客戶端早一些。
上述內(nèi)容就是TCP連接釋放的過(guò)程，俗稱“四次揮手”過(guò)程，其實(shí)質(zhì)上是四報(bào)文揮手。
3.2.1 TCP連接釋放相關(guān)問(wèn)題
問(wèn)題1：為什么建立連接是三次握手，而關(guān)閉連接卻是四次揮手？
在建立TCP連接時(shí)，當(dāng)服務(wù)器收到客戶端發(fā)來(lái)的連接請(qǐng)求的SYN同步報(bào)文段后，可以直接發(fā)送一個(gè)ACK+SYN的報(bào)文段給客戶端，其中ACK控制位是用來(lái)確認(rèn)的，SYN控制位是用來(lái)同步的。但是在關(guān)閉連接時(shí)，當(dāng)服務(wù)器收到客戶端發(fā)來(lái)的FIN結(jié)束報(bào)文段時(shí)，自己這邊可能還有數(shù)據(jù)沒(méi)有發(fā)送完，因此只能先回復(fù)一個(gè)ACK確認(rèn)報(bào)文，告訴客戶端，“你發(fā)來(lái)的FIN報(bào)文我收到了”。只有等到服務(wù)器所有的數(shù)據(jù)都發(fā)送完了，服務(wù)器才會(huì)向客戶端發(fā)送一個(gè)FIN結(jié)束報(bào)文段，最后客戶端回復(fù)一個(gè)確認(rèn)報(bào)文，總共就是四次揮手過(guò)程。也就是說(shuō)，在關(guān)閉連接的第二次揮手階段，服務(wù)器不能將控制位ACK+FIN 同時(shí)放在一個(gè)報(bào)文段中回復(fù)給客戶端。
注意：發(fā)送了FIN結(jié)束報(bào)文段，只是表示本端不能再繼續(xù)發(fā)送數(shù)據(jù)了，但是還可以接受數(shù)據(jù)。TCP通信它是全雙工的，收到一個(gè)FIN報(bào)文段，只是關(guān)閉了一個(gè)方向上的連接，而另一個(gè)方向仍能發(fā)送數(shù)據(jù)，此時(shí)TCP處于半關(guān)閉狀態(tài)。
問(wèn)題2：為什么客戶端在 TIME-WAIT 狀態(tài)時(shí)，必須等待2MSL的時(shí)間才能進(jìn)入到 CLOSED狀態(tài)呢？
第一，為了保證客戶端發(fā)送的最后一個(gè)ACK報(bào)文段能夠到達(dá)對(duì)端，即保證可靠地終止TCP連接。因?yàn)槿绻霈F(xiàn)網(wǎng)絡(luò)擁塞，這個(gè)ACK報(bào)文段是有可能丟失的，因而使處于LAST-ACK狀態(tài)的服務(wù)器收不到客戶端對(duì)自己已發(fā)送過(guò)的FIN+ACK報(bào)文段的確認(rèn)。那么，服務(wù)器會(huì)超時(shí)重傳這個(gè)FIN+ACK報(bào)文段，而客戶端就能在2MSL時(shí)間內(nèi)收到這個(gè)重傳的FIN+ACK報(bào)文段。接著客戶端重傳一次確認(rèn)，重新啟動(dòng)2MSL計(jì)時(shí)器。最后，客戶端和服務(wù)器都正常進(jìn)入到CLOSED狀態(tài)。如果客戶端在 TIME-WAIT 狀態(tài)時(shí)不等待一個(gè)2MSL時(shí)間，而是在發(fā)送完ACK確認(rèn)報(bào)文段后立即釋放連接，進(jìn)入到CLOSED狀態(tài)，那么就無(wú)法收到服務(wù)器重傳的FIN+ACK報(bào)文段，因而也不會(huì)再發(fā)送一次確認(rèn)報(bào)文段。這樣，服務(wù)器就無(wú)法按照正常步驟進(jìn)入到CLOSED狀態(tài)。
第二，防止已失效的連接請(qǐng)求報(bào)文段出現(xiàn)在本次TCP連接中。客戶端在發(fā)送完最后一個(gè)ACK報(bào)文段后，再經(jīng)過(guò)2MSL的時(shí)間后，就可以使本次TCP連接持續(xù)的時(shí)間內(nèi)所產(chǎn)生的所有報(bào)文段都從網(wǎng)絡(luò)上消失。這樣就可以使下一個(gè)新的TCP連接中不會(huì)出現(xiàn)之前舊的連接請(qǐng)求報(bào)文段。
問(wèn)題3：為什么是2MSL，這個(gè)時(shí)間是如何得來(lái)的？
我們知道，MSL是TCP報(bào)文段的最大生存時(shí)間，2MSL的時(shí)間是從客戶端發(fā)出最后一個(gè)ACK報(bào)文段開(kāi)始計(jì)時(shí)的，考慮到了重傳的因素。
客戶端—[ACK報(bào)文段]—>服務(wù)器 ?????????? 1MSL
服務(wù)器—[FIN+ACK報(bào)文段]—>客戶端??? 1MSL （如果服務(wù)器在超時(shí)時(shí)間內(nèi)沒(méi)有收到客戶端的ACK報(bào)文段，就重傳FIN+ACK報(bào)文段）
保證在TCP的兩個(gè)傳輸方向上，那些尚未被接收或遲到的報(bào)文段都消失，理論上保證最后一個(gè)ACK報(bào)文段可靠到達(dá)。
問(wèn)題4：TIME-WAIT 狀態(tài)何時(shí)出現(xiàn)？TIME-WAIT會(huì)帶來(lái)哪些問(wèn)題？
TIME-WAIT狀態(tài)是主動(dòng)關(guān)閉連接的一方收到了對(duì)方發(fā)來(lái)的FIN結(jié)束報(bào)文段并且本端發(fā)送ACK確認(rèn)報(bào)文段后的狀態(tài)。
TIME-WAIT的引入是為了讓TCP報(bào)文段得以自然消失，同時(shí)為了讓被動(dòng)關(guān)閉的一方能夠正常關(guān)閉連接。
- 服務(wù)器主動(dòng)關(guān)閉連接，短時(shí)間內(nèi)關(guān)閉了大量的客戶端連接，會(huì)造成服務(wù)器上出現(xiàn)大量的 TIME-WAIT狀態(tài)的連接，占據(jù)大量的tuple(源IP地址、目的IP地址、協(xié)議號(hào)、源端口、目的端口)，嚴(yán)重消耗著服務(wù)器的資源。
- 客戶端主動(dòng)關(guān)閉連接，短時(shí)間內(nèi)大量的短連接，會(huì)大量消耗客戶端主機(jī)的端口號(hào)，畢竟端口號(hào)只有65535個(gè)，斷開(kāi)耗盡了，后續(xù)就無(wú)法啟用新的TCP連接了。
問(wèn)題5：解決 TIME-WAIT 狀態(tài)引起的bind()函數(shù)執(zhí)行失敗的問(wèn)題？
問(wèn)題場(chǎng)景：我在編寫(xiě)一個(gè)基于TCP連接的socket服務(wù)器程序并反復(fù)調(diào)試的時(shí)候，發(fā)現(xiàn)了一個(gè)讓人無(wú)比心煩的情況：每次kill掉該服務(wù)器進(jìn)程并重新啟動(dòng)的時(shí)候，都會(huì)出現(xiàn)bind錯(cuò)誤：error:98，Address already in use。然而再kill掉該進(jìn)程，再次重新啟動(dòng)的時(shí)候，就bind成功了。
問(wèn)題原因：當(dāng)我kill掉服務(wù)器進(jìn)程的時(shí)候，系統(tǒng)并沒(méi)有馬上完全釋放掉socket的TCP連接資源，此時(shí)socket處于TIME-WAIT狀態(tài)，當(dāng)我使用 netstat 命令查看該進(jìn)程的端口號(hào)時(shí)，發(fā)現(xiàn)該進(jìn)程處于TIME-WAIT狀態(tài)，需要等待2MSL時(shí)間后，整個(gè)TCP連接才算真正結(jié)束。這就是我的服務(wù)器進(jìn)程被殺死后，不能馬上重新啟動(dòng)的原因（錯(cuò)誤提示為：“Address already in use”）。Linux系統(tǒng)中，一個(gè)端口釋放后需要等待兩分鐘才能再次被使用。
問(wèn)題解決：我們可以使用setsockopt()函數(shù)設(shè)置socket描述符的SO_REUSEADDR選項(xiàng)，該socket選項(xiàng)可以讓端口被釋放后立即就能被再次使用，表示允許創(chuàng)建端口號(hào)相同但是IP地址不同的多個(gè)socket描述符。
代碼描述如下：
int opt = 1; setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt));問(wèn)題6：TIME-WAIT 和 CLOSE-WAIT 的區(qū)別？
- TIME-WAIT 狀態(tài)是主動(dòng)關(guān)閉TCP連接的一方在本端已經(jīng)關(guān)閉的前提下，收到對(duì)端的關(guān)閉請(qǐng)求并將ACK確認(rèn)報(bào)文段發(fā)送過(guò)去后所處的狀態(tài)。
這種狀態(tài)表示：通信雙方都已完成工作，只是為了保證本次TCP連接能夠順利正常的關(guān)閉，即可靠地終止TCP連接。
- CLOSE-WAIT 狀態(tài)是被動(dòng)關(guān)閉TCP連接的一方在接收到對(duì)端的關(guān)閉請(qǐng)求（FIN結(jié)束報(bào)文段）并且將ACK確認(rèn)報(bào)文段發(fā)送出去后所處的狀態(tài)。
這種狀態(tài)表示：收到了對(duì)端關(guān)閉連接的請(qǐng)求，但是本端還沒(méi)有完成工作，還未關(guān)閉本端的TCP連接。
問(wèn)題7：半連接、半打開(kāi)、半關(guān)閉的區(qū)別？
半連接：在TCP連接建立的三次握手過(guò)程中，主動(dòng)發(fā)起連接請(qǐng)求的一方不發(fā)最后一次的ACK確認(rèn)報(bào)文，使得服務(wù)器端阻塞在 SYN-RCVD（同步收到）狀態(tài)。
半打開(kāi)：如果TCP通信一方異常關(guān)閉（如斷網(wǎng)、斷電、進(jìn)程被kill掉），而通信對(duì)端并不知情，此時(shí)TCP連接處于半打開(kāi)狀態(tài)，如果雙方不進(jìn)行數(shù)據(jù)通信，是無(wú)法發(fā)現(xiàn)問(wèn)題的。解決的辦法是引入心跳機(jī)制，設(shè)置一個(gè)保活計(jì)時(shí)器(keepalive timer)，以檢測(cè)半打開(kāi)狀態(tài)，檢測(cè)到了就發(fā)送RST復(fù)位報(bào)文段，重新建立連接。
設(shè)想有這樣的情況：客戶端已主動(dòng)與服務(wù)器建立了TCP連接。但是后來(lái)客戶端的主機(jī)突然發(fā)生故障，客戶端的TCP服務(wù)進(jìn)程被kill掉了。顯然，服務(wù)器以后就不能再收到客戶端發(fā)來(lái)的數(shù)據(jù)。因此，應(yīng)當(dāng)有必要的措施使得服務(wù)器不要再白白地等待下去。解決的辦法就是使用保活計(jì)時(shí)器。服務(wù)器每收到一次客戶端的數(shù)據(jù)，就重新設(shè)置保活計(jì)時(shí)器，時(shí)間的設(shè)置通常是兩小時(shí)。若兩小時(shí)沒(méi)有收到客戶端發(fā)來(lái)的數(shù)據(jù)，服務(wù)器就發(fā)送一個(gè)探測(cè)報(bào)文段，以后每隔75秒鐘發(fā)送一次。若一連發(fā)送10個(gè)探測(cè)報(bào)文段后仍無(wú)客戶的響應(yīng)，服務(wù)器就認(rèn)為客戶端出了故障，接著就關(guān)閉這個(gè)TCP連接。
半關(guān)閉：主動(dòng)發(fā)起連接關(guān)閉請(qǐng)求的一方A發(fā)送了FIN結(jié)束報(bào)文段，對(duì)端B回復(fù)了ACK確認(rèn)報(bào)文段后，B并沒(méi)有立即發(fā)送本端的FIN結(jié)束報(bào)文段給A。此時(shí)A端處于FIN-WAIT-2（結(jié)束等待2）狀態(tài)，A仍然可以接收B發(fā)送過(guò)來(lái)的數(shù)據(jù)，但是A已經(jīng)不能再向B發(fā)送數(shù)據(jù)了。這時(shí)的TCP連接為半關(guān)閉狀態(tài)。
半打開(kāi)和半關(guān)閉的區(qū)別：半打開(kāi)是指TCP通信的一端由于異常關(guān)閉，通信雙方已經(jīng)無(wú)法進(jìn)行正常的數(shù)據(jù)傳輸了；半關(guān)閉是指TCP通信的其中一個(gè)方向上的連接已經(jīng)關(guān)閉了，而另一個(gè)方向的連接還是正常的，仍然可以進(jìn)行數(shù)據(jù)傳輸。
四、TCP狀態(tài)轉(zhuǎn)換
為了更清晰地看出TCP連接的各種狀態(tài)之間的關(guān)系，下圖給出了TCP的狀態(tài)轉(zhuǎn)換示意圖。
說(shuō)明：紫色框框是TCP狀態(tài)，紅色是服務(wù)器進(jìn)程的正常狀態(tài)轉(zhuǎn)換，藍(lán)色是客戶端進(jìn)程的正常狀態(tài)轉(zhuǎn)換，黑色是異常變遷，即出現(xiàn)問(wèn)題時(shí)的狀態(tài)轉(zhuǎn)換。
TCP的狀態(tài)轉(zhuǎn)換?4.1 服務(wù)器正常狀態(tài)轉(zhuǎn)換
?服務(wù)器狀態(tài)轉(zhuǎn)換示意圖如下所示：
1. TCP連接建立的三次握手階段
- CLOSED —> LISTEN：服務(wù)器進(jìn)程調(diào)用listen()后進(jìn)入LISTEN狀態(tài)，被動(dòng)等待客戶端發(fā)起連接。
- LISTEN?? —> SYN-RCVD：服務(wù)器進(jìn)程一旦收到客戶端發(fā)來(lái)的連接請(qǐng)求SYN同步報(bào)文段，就會(huì)將該連接放入內(nèi)核中的等待連接隊(duì)列中，并向客戶端發(fā)送ACK+SYN確認(rèn)報(bào)文段，服務(wù)器進(jìn)程進(jìn)入 SYN-RCVD狀態(tài)。
- SYN-RCVD —> ESTABLISHED：服務(wù)器一旦接收到客戶端發(fā)來(lái)的ACK確認(rèn)報(bào)文段，就進(jìn)入 ESTABLISHED 狀態(tài)，此時(shí)TCP連接建立成功，可以進(jìn)行數(shù)據(jù)傳輸了。
2. TCP連接釋放的四次揮手階段
- ESTABLISHED —> CLOSE-WAIT：當(dāng)客戶端主動(dòng)發(fā)起連接關(guān)閉，服務(wù)器收到客戶端發(fā)來(lái)的FIN結(jié)束報(bào)文段，服務(wù)器向客戶端返回確認(rèn)報(bào)文段，服務(wù)器就進(jìn)入了 CLOSE-WAIT狀態(tài)，此時(shí)TCP處于半關(guān)閉狀態(tài)。
- CLOSE-WAIT —> LAST-ACK：當(dāng)服務(wù)器向客戶端發(fā)送關(guān)閉連接的FIN結(jié)束報(bào)文段后，服務(wù)器就進(jìn)入 LAST-ACK 狀態(tài)。
- LAST-ACK —> CLOSED：當(dāng)服務(wù)器收到客戶端對(duì)自己發(fā)出的FIN結(jié)束報(bào)文段的確認(rèn)報(bào)文段后，服務(wù)器關(guān)閉TCP連接，進(jìn)入 CLOSED 狀態(tài)。
4.2 客戶端正常狀態(tài)轉(zhuǎn)換
?客戶端狀態(tài)轉(zhuǎn)換示意圖如下所示：
1. TCP連接建立的三次握手階段
- CLOSED —> SYN-SENT： 客戶端調(diào)用connect()向服務(wù)器發(fā)送連接請(qǐng)求的同步SYN報(bào)文段，表示想與服務(wù)器建立TCP連接，自己進(jìn)入 SYN-SENT 狀態(tài)，等待服務(wù)器的響應(yīng)。
- SYN-SENT —> ESTABLISHED： connnect()調(diào)用成功，客戶端收到服務(wù)器的ACK確認(rèn)報(bào)文段，此時(shí)客戶端進(jìn)入 ESTABLISHED 狀態(tài)。
2. TCP連接釋放的四次揮手階段
- ESTABLISHED —> FIN-WAIT-1：?客戶端主動(dòng)調(diào)用close()，向服務(wù)器發(fā)送斷開(kāi)連接的FIN結(jié)束報(bào)文段，自己進(jìn)入 FIN-WAIT-1 階段，等待服務(wù)器的響應(yīng)。
- FIN-WAIT-1 —> FIN-WAIT-2：?客戶端收到服務(wù)器對(duì)自己發(fā)出的FIN結(jié)束報(bào)文段的確認(rèn)報(bào)文段后，進(jìn)入 FIN-WAIT-2 階段，等待服務(wù)器的結(jié)束報(bào)文段。
- FIN-WAIT-2 —> TIME-WAIT：?客戶端收到服務(wù)器發(fā)來(lái)的FIN結(jié)束報(bào)文段，發(fā)送ACK確認(rèn)報(bào)文段給服務(wù)器，自己則進(jìn)入 TIME-WAIT 狀態(tài)。
- TIME-WAIT —> CLOSED：?客戶端要等待2MSL，即2個(gè)報(bào)文最大生存時(shí)間，才進(jìn)入CLOSED狀態(tài)。這是為了保證客戶端發(fā)送的最后一個(gè)ACK確認(rèn)報(bào)文段能夠到達(dá)服務(wù)器，即保證可靠地終止TCP連接，以及防止已失效的連接請(qǐng)求報(bào)文段出現(xiàn)在本連接中。
?五、基于TCP協(xié)議的socket通信流程
????????Socket 又稱 ”套接字”，是系統(tǒng)提供的用于網(wǎng)絡(luò)通信的方法。它并不是一種協(xié)議，沒(méi)有規(guī)定計(jì)算機(jī)應(yīng)當(dāng)怎么傳遞信息，只是給開(kāi)發(fā)人員提供了一個(gè)發(fā)送和接收消息的接口。開(kāi)發(fā)人員能使用這個(gè)接口提供的方法，發(fā)送與接收消息。Socket描述了一個(gè) IP 和 端口號(hào)。它簡(jiǎn)化了開(kāi)發(fā)員的操作，知道了對(duì)方 IP 以及 port，就可以給對(duì)方發(fā)送消息，再由服務(wù)器處理發(fā)送過(guò)來(lái)的這些消息，Socket包含了通信的雙方，即客戶端與服務(wù)器。
TCP協(xié)議的socket通信流程，如圖所示：
5.1 TCP網(wǎng)絡(luò)編程—服務(wù)器編程步驟
1、socket()：創(chuàng)建一個(gè)套接字，創(chuàng)建成功返回一個(gè)套接字文件描述符 listen_fd。
1-1、setsockopt()：可選，設(shè)置socket屬性。
2、bind()：綁定本地的 IP 地址和端口號(hào)信息到socket上。
3、listen()：開(kāi)啟監(jiān)聽(tīng)。
4、accept()：接收客戶端的連接請(qǐng)求。連接成功，返回一個(gè)連接文件描述符 conn_fd。
5、recv()、send()：收發(fā)數(shù)據(jù)。或者使用 read()、write()。
6、close(conn_fd)：關(guān)閉網(wǎng)絡(luò)連接。
7、close(listen_fd)：關(guān)閉監(jiān)聽(tīng)。
5.2 TCP網(wǎng)絡(luò)編程—客戶端編程步驟
1、socket()：創(chuàng)建一個(gè)套接字，創(chuàng)建成功返回一個(gè)套接字文件描述符 client_fd。
1-1、setsockopt()：可選，設(shè)置socket屬性。
1-2、bind()：可選，綁定本地的 IP 地址和端口號(hào)信息到socket上。
2、connect()：請(qǐng)求連接到服務(wù)器端。
3、recv()、send()：收發(fā)數(shù)據(jù)。或者使用 read()、write()。
4、close(client_fd)：關(guān)閉網(wǎng)絡(luò)連接。
參考
《計(jì)算機(jī)網(wǎng)絡(luò)(第7版-謝希仁)》第5章
《Linux高性能服務(wù)器編程》第3章
《UNIX網(wǎng)絡(luò)編程卷1：套接字聯(lián)網(wǎng)API(第3版)》第1部分
四、TCP三次握手、四次揮手詳解
TCP連接的狀態(tài)詳解以及故障排查
TCP 為什么三次握手而不是兩次握手（正解版）
詳解TCP三次握手/四次揮手
?近 40 張圖解被問(wèn)千百遍的 TCP 三次握手和四次揮手面試題
總結(jié)
以上是生活随笔為你收集整理的TCP协议-TCP连接管理的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： 尽量干净地卸载360
- 下一篇： psp记忆棒测试软件,psp记忆棒修复工