Author : Kevin Lynx

準(zhǔn)備：

在這里本文將遵循上一篇文章的風(fēng)格，只提TCP協(xié)議中的要點，這樣我覺得可以更容易地掌握TCP。或者
根本談不上掌握，對于這種純理論的東西，即使你現(xiàn)在掌握了再多的細(xì)節(jié)，一段時間后也會淡忘。

在以后各種細(xì)節(jié)中，因為我們會涉及到分析一些TCP中的數(shù)據(jù)報，因此一個協(xié)議包截獲工具必不可少。在
<TCP/IP詳解>中一直使用tcpdump。這里因為我的系統(tǒng)是windows，所以只好使用windows平臺的tcpdump，
也就是WinDump。在使用WinDump之前，你需要安裝該程序使用的庫WinpCap。

關(guān)于WinDump的具體用法你可以從網(wǎng)上其他地方獲取，這里我只稍微提一下。要讓W(xué)inDump開始監(jiān)聽數(shù)據(jù)，
首先需要確定讓其監(jiān)聽哪一個網(wǎng)絡(luò)設(shè)備(或者說是網(wǎng)絡(luò)接口)。你可以:

windump -D

獲取當(dāng)前機(jī)器上的網(wǎng)絡(luò)接口。然后使用：

windump -i 2 

開始對網(wǎng)絡(luò)接口2的數(shù)據(jù)監(jiān)聽。windump如同tcpdump(其實就是tcpdump)一樣支持過濾表達(dá)式，windump
將會根據(jù)你提供的過濾表達(dá)式過濾不需要的網(wǎng)絡(luò)數(shù)據(jù)包，例如：

windump -i 2 port 4000 

那么windump只會顯示端口號為4000的網(wǎng)絡(luò)數(shù)據(jù)。

序號和確認(rèn)號：

要講解TCP的建立過程，也就是那個所謂的三次握手，就會涉及到序號和確認(rèn)號這兩個東西。翻書到TCP
的報文頭，有兩個很重要的域(都是32位)就是序號域和確認(rèn)號域。可能有些同學(xué)會對TCP那個報文頭有所
疑惑(能看懂我在講什么的會產(chǎn)生這樣的疑惑么？)，這里我可以告訴你，你可以假想TCP的報文頭就是個
C語言結(jié)構(gòu)體(假想而已，去翻翻bsd對TCP的實現(xiàn)，肯定沒這么簡單)，那么大致上，所謂的TCP報文頭就是：

typedef struct _tcp_header
{
    /**//// 16位源端口號
    unsigned short src_port;
    /**//// 16位目的端口號
    unsigned short dst_port;
    /**//// 32位序號
    unsigned long seq_num;
    /**//// 32位確認(rèn)號
    unsigned long ack_num;
    /**//// 16位標(biāo)志位[4位首部長度，保留6位，ACK、SYN之類的標(biāo)志位]
    unsigned short flag;
    /**//// 16位窗口大小
    unsigned short win_size;
    /**//// 16位校驗和
    short crc_sum;
    /**//// 16位緊急指針
    short ptr;
    /**//// 可選選項
    /// how to implement this ?   
} tcp_header;

那么，這個序號和確認(rèn)號是什么？TCP報文為每一個字節(jié)都設(shè)置一個序號，覺得很奇怪？這里并不是為每一
字節(jié)附加一個序號(那會是多么可笑的編程手法?)，而是為一個TCP報文附加一個序號，這個序號表示報文
中數(shù)據(jù)的第一個字節(jié)的序號，而其他數(shù)據(jù)則是根據(jù)離第一個數(shù)據(jù)的偏移來決定序號的，例如，現(xiàn)在有數(shù)據(jù)：
abcd。如果這段數(shù)據(jù)的序號為1200，那么a的序號就是1200，b的序號就是1201。而TCP發(fā)送的下一個數(shù)據(jù)包
的序號就會是上一個數(shù)據(jù)包最后一個字節(jié)的序號加一。例如efghi是abcd的下一個數(shù)據(jù)包，那么它的序號就
是1204。通過這種看似簡單的方法，TCP就實現(xiàn)了為每一個字節(jié)設(shè)置序號的功能(終于明白為什么書上要告訴
我們‘為每一個字節(jié)設(shè)置一個序號’了吧?)。注意，設(shè)置序號是一種可以讓TCP成為’可靠協(xié)議‘的手段。
TCP中各種亂七八糟的東西都是有目的的，大部分目的還是為了’可靠‘兩個字。別把TCP看高深了，如果
讓你來設(shè)計一個網(wǎng)絡(luò)協(xié)議，目的需要告訴你是’可靠的‘，你就會明白為什么會產(chǎn)生那些亂七八糟的東西了。

接著看，確認(rèn)號是什么？因為TCP會對接收到的數(shù)據(jù)包進(jìn)行確認(rèn)，發(fā)送確認(rèn)數(shù)據(jù)包時，就會設(shè)置這個確認(rèn)號，
確認(rèn)號通常表示接收方希望接收到的下一段報文的序號。例如某一次接收方收到序號為1200的4字節(jié)數(shù)舉報，
那么它發(fā)送確認(rèn)報文給發(fā)送方時，就會設(shè)置確認(rèn)號為1204。

大部分書上在講確認(rèn)號和序號時，都會說確認(rèn)號是序號加一。這其實有點誤解人，所以我才在這里廢話了
半天(高手寬容下:D)。

開始三次握手：

如果你還不會簡單的tcp socket編程，我建議你先去學(xué)學(xué)，這就好比你不會C++基本語法，就別去研究vtable
之類。

三次握手開始于客戶端試圖連接服務(wù)器端。當(dāng)你調(diào)用諸如connect的函數(shù)時，正常情況下就會開始三次握手。
隨便在網(wǎng)上找張三次握手的圖：

如前文所述，三次握手也就是產(chǎn)生了三個數(shù)據(jù)包。客戶端主動連接，發(fā)送SYN被設(shè)置了的報文(注意序號和
確認(rèn)號，因為這里不包含用戶數(shù)據(jù)，所以序號和確認(rèn)號就是加一減一的關(guān)系)。服務(wù)器端收到該報文時，正
常情況下就發(fā)送SYN和ACK被設(shè)置了的報文作為確認(rèn)，以及告訴客戶端：我想打開我這邊的連接(雙工)。客戶
端于是再對服務(wù)器端的SYN進(jìn)行確認(rèn)，于是再發(fā)送ACK報文。然后連接建立完畢。對于阻塞式socket而言，你
的connect可能就返回成功給你。

在進(jìn)行了鋪天蓋地的羅利巴索的基礎(chǔ)概念的講解后，看看這個連接建立的過程，是不是簡單得幾近無聊？

我們來實際點，寫個最簡單的客戶端代碼：

   sockaddr_in addr;
    memset( &addr, 0, sizeof( addr ) );
    addr.sin_family = AF_INET;
    addr.sin_port = htons( 80 );
    /**//// 220.181.37.55
    addr.sin_addr.s_addr = inet_addr( "220.181.37.55" );
    printf( "%s : connecting to server.\n", _str_time() );
    int err = connect( s, (sockaddr*) &addr, sizeof( addr ) );

主要就是connect。運(yùn)行程序前我們運(yùn)行windump：

windump -i 2 host 220.181.37.55 

00:38:22.979229 IP noname.domain.4397 > 220.181.37.55.80: S 2523219966:2523219966(0) win 65535 <mss 1460,nop,nop,sackOK>
00:38:23.024254 IP 220.181.37.55.80 > noname.domain.4397: S 1277008647:1277008647(0) ack 2523219967 win 2920 <mss 1440,nop,nop,sackOK>
00:38:23.024338 IP noname.domain.4397 > 220.181.37.55.80: . ack 1 win 65535 

如何分析windump的結(jié)果，建議參看<tcp/ip詳解>中對于tcpdump的描述。

建立連接的附加信息：

雖然SYN、ACK之類的報文沒有用戶數(shù)據(jù)，但是TCP還是附加了其他信息。最為重要的就是附加的MSS值。這個
可以被協(xié)商的MSS值基本上就只在建立連接時協(xié)商。如以上數(shù)據(jù)表示，MSS為1460字節(jié)。

連接的意外：

連接的意外我大致分為兩種情況(也許還有更多情況)：目的主機(jī)不可達(dá)、目的主機(jī)并沒有在指定端口監(jiān)聽。
當(dāng)目的主機(jī)不可達(dá)時，也就是說，SYN報文段根本無法到達(dá)對方(如果你的機(jī)器根本沒插網(wǎng)線，你就不可達(dá))，
那么TCP收不到任何回復(fù)報文。這個時候，你會看到TCP中的定時器機(jī)制出現(xiàn)了。TCP對發(fā)出的SYN報文進(jìn)行
計時，當(dāng)在指定時間內(nèi)沒有得到回復(fù)報文時，TCP就會重傳剛才的SYN報文。通常，各種不同的TCP實現(xiàn)對于
這個超時值都不同，但是據(jù)我觀察，重傳次數(shù)基本上都是3次。例如，我連接一個不可達(dá)的主機(jī)：

12:39:50.560690 IP cd-zhangmin.1573 > 220.181.37.55.1024: S 3117975575:3117975575(0) win 65535 <mss 1460,nop,nop,sackOK>
12:39:53.538734 IP cd-zhangmin.1573 > 220.181.37.55.1024: S 3117975575:3117975575(0) win 65535 <mss 1460,nop,nop,sackOK>
12:39:59.663726 IP cd-zhangmin.1573 > 220.181.37.55.1024: S 3117975575:3117975575(0) win 65535 <mss 1460,nop,nop,sackOK>

發(fā)出了三個序號一樣的SYN報文，但是沒有得到一個回復(fù)報文(廢話)。每一個SYN報文之間的間隔時間都是
有規(guī)律的，在windows上是3秒6秒9秒12秒。上面的數(shù)據(jù)你看不到12秒這個數(shù)據(jù)，因為這是第三個報文發(fā)出的
時間和connect返回錯誤信息時的時間之差。另一方面，如果連接同一個網(wǎng)絡(luò)，這個間隔時間又不同。例如
直接連局域網(wǎng)，間隔時間就差不多為500ms。

(我強(qiáng)烈建議你能運(yùn)行windump去試驗這里提到的每一個現(xiàn)象，如果你在ubuntu下使用tcpdump，記住sudo :D)

出現(xiàn)意外的第二種情況是如果主機(jī)數(shù)據(jù)包可達(dá)，但是試圖連接的端口根本沒有監(jiān)聽，那么發(fā)送SYN報文的這
方會收到RST被設(shè)置的報文(connect也會返回相應(yīng)的信息給你)，例如：

13:37:22.202532 IP cd-zhangmin.1658 > 7AURORA-CCTEST.7100: S 2417354281:2417354281(0) win 65535 <mss 1460,nop,nop,sackOK>
13:37:22.202627 IP 7AURORA-CCTEST.7100 > cd-zhangmin.1658: R 0:0(0) ack 2417354282 win 0
13:37:22.711415 IP cd-zhangmin.1658 > 7AURORA-CCTEST.7100: S 2417354281:2417354281(0) win 65535 <mss 1460,nop,nop,sackOK>
13:37:22.711498 IP 7AURORA-CCTEST.7100 > cd-zhangmin.1658: R 0:0(0) ack 1 win 0
13:37:23.367733 IP cd-zhangmin.1658 > 7AURORA-CCTEST.7100: S 2417354281:2417354281(0) win 65535 <mss 1460,nop,nop,sackOK>
13:37:23.367826 IP 7AURORA-CCTEST.7100 > cd-zhangmin.1658: R 0:0(0) ack 1 win 0 

可以看出，7AURORA-CCTEST.7100返回了RST報文給我，但是我這邊根本不在乎這個報文，繼續(xù)發(fā)送SYN報文。
三次過后connect就返回了。(數(shù)據(jù)反映的事實是這樣)

關(guān)于listen:

TCP服務(wù)器端會維護(hù)一個新連接的隊列。當(dāng)新連接上的客戶端三次握手完成時，就會將其放入這個隊列。這個隊

列的大小是通過listen設(shè)置的。當(dāng)這個隊列滿時，如果有新的客戶端試圖連接（發(fā)送SYN），服務(wù)器端丟棄報文，

同時不做任何回復(fù)。

總結(jié)：
TCP連接的建立的相關(guān)要點就是這些(or more?)。正常情況下就是三次握手，非正常情況下就是SYN三次超時，
以及收到RST報文卻被忽略。

本文轉(zhuǎn)自：http://www.shnenglu.com/kevinlynx/archive/2008/05/11/49482.html