TCP首部格式

先看TCP報文段的格式，如下;

TCP報文段首部的前20個字節(jié)是固定的，后面有4N字節(jié)是根據(jù)需要而增加的選項。因此TCP報文段的最小長度為20個字節(jié)。

首部固定部分的各字段的意義如下：

1、源端口和目的端口：加上IP首部的源IP地址和目的IP地址，確定唯一的一個TCP連接。另外通過目的端口來決定TCP將數(shù)據(jù)報交付于那個應(yīng)用程序，從而實(shí)現(xiàn)TCP的分用功能。

2、序號：占4個字節(jié)，序號的范圍為[0,4284967296]。由于TCP是面向字節(jié)流的，在一個TCP連接中傳送的字節(jié)流中的每一個字節(jié)都按順序編號，首部中的序號字段則是指本報文段所發(fā)送的數(shù)據(jù)的***個字節(jié)的序號。另外，序號是循環(huán)使用的，當(dāng)序號增加到***值時，下一個序號就又回到了0。

3、確認(rèn)號：當(dāng)ACK標(biāo)志位為1時有效，表示期望收到的下一個報文段的***個數(shù)據(jù)字節(jié)的序號。確認(rèn)號為N，則表明到序號N-1為止的所有數(shù)據(jù)字節(jié)都已經(jīng)被正確地接收到了。

4、頭部長度：TCP報文段的頭部長度，它指出TCP報文段的數(shù)據(jù)部分的起始位置與TCP報文段的起始位置的距離。頭部長度占4個字節(jié)，但它的單位是32位字，即以4字節(jié)為計算單位，因此頭部長度的***值為15*4=60個字節(jié)，這就意味著選項的長度不超過40個字節(jié)。

5、保留位：必須為0.

6、下面的六個控制位說明報文段的性質(zhì)：

1)URG：與首部中的緊急指針字段配合使用。URG為1時，表明緊急指針字段有效，發(fā)送應(yīng)用進(jìn)程告訴發(fā)送方的TCP有緊急數(shù)據(jù)要傳送，于是發(fā)送方TCP就把緊急數(shù)據(jù)插入到本報文段數(shù)據(jù)的最前面，而其后面仍是普通數(shù)據(jù)。

2)ACK：僅當(dāng)ACK=1時確認(rèn)號字段才有效，當(dāng)ACK=0時，確認(rèn)號無效。TCP規(guī)定，在連接建立后所有的傳送報文段都必須把ACK置1。

3)PSH：如果發(fā)送的報文段中PSH為1，則接收方接受到該報文段后，直接將其交付給應(yīng)用進(jìn)程，而不再等待整個緩存都填滿后再向上交付。

4)RST：復(fù)位標(biāo)志，RST=1時，表明TCP連接中出現(xiàn)嚴(yán)重差錯，必須釋放連接，然后重新建立運(yùn)輸連接。

5)SYN：同步序號，用來發(fā)起一個連接。當(dāng)SYN=1而ACK=0時，表明這是一個連接請求報文段，若對方同意建立連接，則應(yīng)在響應(yīng)的報文段中使SYN=1和ACK=1。

6)FIN：用來釋放一個連接。當(dāng)FIN=1時，表明此報文段的發(fā)送方的數(shù)據(jù)已發(fā)送完畢，并要求釋放連接。

7、窗口：接收方讓發(fā)送方下次發(fā)送報文段時設(shè)置的發(fā)送窗口的大小。

8、校驗(yàn)和：校驗(yàn)的字段范圍包括首部和數(shù)據(jù)這兩部分。

9、緊急指針：緊急指針當(dāng)URG=1時才有效，它指出本報文段中的緊急數(shù)據(jù)的字節(jié)數(shù)。值得注意的是，即使窗口為0時，也可發(fā)送緊急數(shù)據(jù)。

10、選項與填充：選項應(yīng)該為4字節(jié)的整數(shù)倍，否則用0填充。最常見的可選字段是最長報文大小MSS(Maximum Segment Size)，每個連接方通常都在通信的***個報文段中指明這個選項。它指明本端所能接收的***長度的報文段。該選項如果不設(shè)置，默認(rèn)為536(20+20+536=576字節(jié)的IP數(shù)據(jù)報)，其中ip首部和tcp首部各20個字節(jié)，而internet 上標(biāo)準(zhǔn)的MTU (最小)為576B。#p#

TCP連接的建立

下圖為TCP三次握手連接的建立過程：

服務(wù)端的TCP進(jìn)程先創(chuàng)建傳輸控制塊TCB，準(zhǔn)備接受客戶端進(jìn)程的連接請求，然后服務(wù)端進(jìn)程處于LISTEN狀態(tài)，等待客戶端的連接請求，如有，則作出響應(yīng)。

1、客戶端的TCP進(jìn)程也首先創(chuàng)建傳輸控制模塊TCB，然后向服務(wù)端發(fā)出連接請求報文段，該報文段首部中的SYN=1，ACK=0，同時選擇一個初始序號seq=i。TCP規(guī)定，SYN=1的報文段不能攜帶數(shù)據(jù)，但要消耗掉一個序號。這時，TCP客戶進(jìn)程進(jìn)入SYN—SENT(同步已發(fā)送)狀態(tài)，這是TCP連接的***次握手。

2、服務(wù)端收到客戶端發(fā)來的請求報文后，如果同意建立連接，則向客戶端發(fā)送確認(rèn)。確認(rèn)報文中的SYN=1，ACK=1，確認(rèn)號ack=i+1，同時為自己選擇一個初始序號seq=j。同樣該報文段也是SYN=1的報文段，不能攜帶數(shù)據(jù)，但同樣要消耗掉一個序號。這時，TCP服務(wù)端進(jìn)入SYN—RCVD(同步收到)狀態(tài)，這是TCP連接的第二次握手。

3、TCP客戶端進(jìn)程收到服務(wù)端進(jìn)程的確認(rèn)后，還要向服務(wù)端給出確認(rèn)。確認(rèn)報文段的ACK=1，確認(rèn)號ack=j+1，而自己的序號為seq=i+1。TCP的標(biāo)準(zhǔn)規(guī)定，ACK報文段可以攜帶數(shù)據(jù)，但如果不攜帶數(shù)據(jù)則不消耗序號，因此，如果不攜帶數(shù)據(jù)，則下一個報文段的序號仍為seq=i+1。這時，TCP連接已經(jīng)建立，客戶端進(jìn)入ESTABLISHED(已建立連接)狀態(tài)。這是TCP連接的第三次握手，可以看出第三次握手客戶端已經(jīng)可以發(fā)送攜帶數(shù)據(jù)的報文段了。

當(dāng)服務(wù)端收到確認(rèn)后，也進(jìn)入ESTABLISHED(已建立連接)狀態(tài)。

雙方同時主動連接的TCP連接建立過程

正常情況下，傳輸連接都是由一方主動發(fā)起的，但也有可能雙方同時主動發(fā)起連接，此時就會發(fā)生連接碰撞，最終只有一個連接能夠建立起來。因?yàn)樗羞B接都是由它們的端點(diǎn)進(jìn)行標(biāo)識的。如果***個連接請求建立起一個由套接字(x,y)標(biāo)識的連接，而第二個連接也建立了這樣一個連接，那么在TCP實(shí)體內(nèi)部只有一個套接字表項。

當(dāng)出現(xiàn)同時發(fā)出連接請求時，則兩端幾乎在同時發(fā)送一個SYN字段置1的數(shù)據(jù)段，并進(jìn)入SYN_SENT狀態(tài)。當(dāng)每一端收到SYN數(shù)據(jù)段時，狀態(tài)變?yōu)镾YN_RCVD，同時它們都再發(fā)送SYN字段置1，ACK字段置1的數(shù)據(jù)段，對收到的SYN數(shù)據(jù)段進(jìn)行確認(rèn)。當(dāng)雙方都收到對方的SYN+ACK數(shù)據(jù)段后，便都進(jìn)入ESTABLISHED狀態(tài)。圖10-39顯示了這種同時發(fā)起連接的連接過程，但最終建立的是一個TCP連接，而不是兩個，這點(diǎn)要特別注意。

從圖中可以看出，一個雙方同時打開的傳輸連接需要交換4數(shù)據(jù)段，比正常的傳輸連接建立所進(jìn)行的三次握手多交換一個數(shù)據(jù)段。此外要注意的是，此時我們沒有將任何一端稱為客戶或服務(wù)器，因?yàn)槊恳欢思仁强蛻粲质欠?wù)器。

為什么一定要進(jìn)行三次握手呢?

前兩次的握手很顯然是必須的，主要是***一次，即客戶端收到服務(wù)端發(fā)來的確認(rèn)后為什么還要想服務(wù)端再發(fā)送一次確認(rèn)呢?這主要是為了防止已失效的請求報文段突然又傳送到了服務(wù)端而產(chǎn)生連接的誤判。

考慮如下的情況：客戶端發(fā)送了一個連接請求報文段到服務(wù)端，但是在某些網(wǎng)絡(luò)節(jié)點(diǎn)上長時間滯留了，而后客戶端又超時重發(fā)了一個連接請求報文段該服務(wù)端，而后正常建立連接，數(shù)據(jù)傳輸完畢，并釋放了連接。如果這時候***次發(fā)送的請求報文段延遲了一段時間后，又到了服務(wù)端，很顯然，這本是一個早已失效的報文段，但是服務(wù)端收到后會誤以為客戶端又發(fā)出了一次連接請求，于是向客戶端發(fā)出確認(rèn)報文段，并同意建立連接。假設(shè)不采用三次握手，這時服務(wù)端只要發(fā)送了確認(rèn)，新的連接就建立了，但由于客戶端比你更沒有發(fā)出建立連接的請求，因此不會理會服務(wù)端的確認(rèn)，也不會向服務(wù)端發(fā)送數(shù)據(jù)，而服務(wù)端卻認(rèn)為新的連接已經(jīng)建立了，并在一直等待客戶端發(fā)送數(shù)據(jù)，這樣服務(wù)端就會一直等待下去，直到超出?；钣嫈?shù)器的設(shè)定值，而將客戶端判定為出了問題，才會關(guān)閉這個連接。這樣就浪費(fèi)了很多服務(wù)器的資源。而如果采用三次握手，客戶端就不會向服務(wù)端發(fā)出確認(rèn)，服務(wù)端由于收不到確認(rèn)，就知道客戶端沒有要求建立連接，從而不建立該連接。#p#

TCP連接的釋放

下圖為TCP四次揮手的釋放過程：

數(shù)據(jù)傳輸結(jié)束后，通信的雙方都可以釋放連接，并停止發(fā)送數(shù)據(jù)。假設(shè)現(xiàn)在客戶端和服務(wù)端都處于ESTABLISHED狀態(tài)。

1、客戶端A的TCP進(jìn)程先向服務(wù)端發(fā)出連接釋放報文段，并停止發(fā)送數(shù)據(jù)，主動關(guān)閉TCP連接。釋放連接報文段中FIN=1，序號為seq=u，該序號等于前面已經(jīng)傳送過去的數(shù)據(jù)的***一個字節(jié)的序號加1。這時，A進(jìn)入FIN—WAIT-1(終止等待1)狀態(tài)，等待B的確認(rèn)。TCP規(guī)定，F(xiàn)IN報文段即使不攜帶數(shù)據(jù)，也要消耗掉一個序號。這是TCP連接釋放的***次揮手。

2、B收到連接釋放報文段后即發(fā)出確認(rèn)釋放連接的報文段，該報文段中，ACK=1，確認(rèn)號為ack=u+1，其自己的序號為v，該序號等于B前面已經(jīng)傳送過的數(shù)據(jù)的***一個字節(jié)的序號加1。然后B進(jìn)入CLOSE—WAIT(關(guān)閉等待)狀態(tài)，此時TCP服務(wù)器進(jìn)程應(yīng)該通知上層的應(yīng)用進(jìn)程，因而A到B這個方向的連接就釋放了，這時TCP處于半關(guān)閉狀態(tài)，即A已經(jīng)沒有數(shù)據(jù)要發(fā)了，但B若發(fā)送數(shù)據(jù)，A仍要接受，也就是說從B到A這個方向的連接并沒有關(guān)閉，這個狀態(tài)可能會持續(xù)一些時間。這是TCP連接釋放的第二次揮手。

3、A收到B的確認(rèn)后，就進(jìn)入了FIN—WAIT(終止等待2)狀態(tài)，等待B發(fā)出連接釋放報文段，如果B已經(jīng)沒有要向A發(fā)送的數(shù)據(jù)了，其應(yīng)用進(jìn)程就通知TCP釋放連接。這時B發(fā)出的鏈接釋放報文段中，F(xiàn)IN=1，確認(rèn)號還必須重復(fù)上次已發(fā)送過的確認(rèn)號，即ack=u+1，序號seq=w，因?yàn)樵诎腙P(guān)閉狀態(tài)B可能又發(fā)送了一些數(shù)據(jù)，因此該序號為半關(guān)閉狀態(tài)發(fā)送的數(shù)據(jù)的***一個字節(jié)的序號加1。這時B進(jìn)入LAST—ACK(***確認(rèn))狀態(tài)，等待A的確認(rèn)，這是TCP連接的第三次揮手。

4、A收到B的連接釋放請求后，必須對此發(fā)出確認(rèn)。確認(rèn)報文段中，ACK=1，確認(rèn)號ack=w+1，而自己的序號seq=u+1，而后進(jìn)入TIME—WAIT(時間等待)狀態(tài)。這時候，TCP連接還沒有釋放掉，必須經(jīng)過時間等待計時器設(shè)置的時間2MSL后，A才進(jìn)入CLOSED狀態(tài)，時間MSL叫做最長報文壽命，RFC建議設(shè)為2分鐘，因此從A進(jìn)入TIME—WAIT狀態(tài)后，要經(jīng)過4分鐘才能進(jìn)入到CLOSED狀態(tài)，而B只要收到了A的確認(rèn)后，就進(jìn)入了CLOSED狀態(tài)。二者都進(jìn)入CLOSED狀態(tài)后，連接就完全釋放了，這是TCP連接的第四次揮手。

雙方主動關(guān)閉的TCP連接釋放流程

與可以雙方同時建立TCP傳輸連接一樣，TCP傳輸連接關(guān)閉也可以由雙方同時主動進(jìn)行(正常情況下都是由一方發(fā)送***個FIN數(shù)據(jù)段進(jìn)行主動連接關(guān)閉，另一方被動接受連接關(guān)閉)

當(dāng)兩端對應(yīng)的網(wǎng)絡(luò)應(yīng)用層進(jìn)程同時調(diào)用CLOSE原語，發(fā)送FIN數(shù)據(jù)段執(zhí)行關(guān)閉命令時，兩端均從ESTABLISHED狀態(tài)轉(zhuǎn)變?yōu)镕IN WAIT 1狀態(tài)。任意一方收到對端發(fā)來的FIN數(shù)據(jù)段后，其狀態(tài)均由FIN WAIT 1轉(zhuǎn)變到CLOSING狀態(tài)，并發(fā)送***的ACK數(shù)據(jù)段。當(dāng)收到***的ACK數(shù)據(jù)段后，狀態(tài)轉(zhuǎn)變化TIME_WAIT，在等待2MSL后進(jìn)入到CLOSED狀態(tài)，最終釋放整個TCP傳輸連接。

為什么A在TIME—WAIT狀態(tài)必須等待2MSL時間呢?

1、為了保證A發(fā)送的***一個ACK報文段能夠到達(dá)B。該ACK報文段很有可能丟失，因而使處于在LIST—ACK狀態(tài)的B收不到對已發(fā)送的FIN+ACK報文段的確認(rèn)，B可能會重傳這個FIN+ACK報文段，而A就在這2MSL時間內(nèi)收到這個重傳的FIN+ACK報文段，接著A重傳一次確認(rèn)，重新啟動2MSL計時器，***A和B都進(jìn)入CLOSED狀態(tài)。如果A在TIME—WAIT狀態(tài)不等待一段時間就直接釋放連接，到CLOSED狀態(tài)，那么久無法收到B重傳的FIN+ACK報文段，也就不會再發(fā)送一次確認(rèn)ACK報文段，B就無法正常進(jìn)入CLOSED狀態(tài)。

2、防止已失效的請求連接出現(xiàn)在本連接中。在連接處于2MSL等待時，任何遲到的報文段將被丟棄，因?yàn)樘幱?MSL等待的、由該插口(插口是IP和端口對的意思，socket)定義的連接在這段時間內(nèi)將不能被再用，這樣就可以使下一個新的連接中不會出現(xiàn)這種舊的連接之前延遲的報文段。

補(bǔ)充：

當(dāng)客戶端執(zhí)行主動關(guān)閉并進(jìn)入TIME—WAIT是正常的，服務(wù)端執(zhí)行被動關(guān)閉，不會進(jìn)入TIME—WAIT狀態(tài)，這說明，如果終止了一個客戶程序，并立即重啟該客戶程序，則新的客戶程序?qū)⒉辉僦赜孟嗤谋镜囟丝?，而是使用新的端口，這不會帶來什么問題，因?yàn)榭蛻舳耸褂帽镜囟丝?，而并不關(guān)心這個端口是多少。但對于服務(wù)器來說，情況就不同了，服務(wù)器總是用我們熟知的端口，那么在2MSL時間內(nèi)，重啟服務(wù)器就會出錯，為了避免這個錯誤，服務(wù)器給出了一個平靜時間的概念，這是說在2MSL時間內(nèi)，雖然可以重新啟動服務(wù)器，但是這個服務(wù)器還是要平靜的等待2MSL時間的過去才能進(jìn)行下一次連接。