上篇

TCP頭格式

接下來(lái)，我們來(lái)看一下TCP頭的格式

TCP頭格式（圖片來(lái)源）

你需要注意這么幾點(diǎn)：

• TCP的包是沒(méi)有IP地址的，那是IP層上的事。但是有源端口和目標(biāo)端口。
• 一個(gè)TCP連接需要四個(gè)元組來(lái)表示是同一個(gè)連接（src_ip, src_port, dst_ip, dst_port）準(zhǔn)確說(shuō)是五元組，還有一個(gè)是協(xié)議。但因?yàn)檫@里只是說(shuō)TCP協(xié)議，所以，這里我只說(shuō)四元組。
• 注意上圖中的四個(gè)非常重要的東西：
  • Sequence Number是包的序號(hào)，用來(lái)解決網(wǎng)絡(luò)包亂序（reordering）問(wèn)題。
  • Acknowledgement Number就是ACK——用于確認(rèn)收到，用來(lái)解決不丟包的問(wèn)題。
  • Window又叫Advertised-Window，也就是著名的滑動(dòng)窗口（Sliding Window），用于解決流控的。
  • TCP Flag?，也就是包的類型，主要是用于操控TCP的狀態(tài)機(jī)的。

關(guān)于其它的東西，可以參看下面的圖示

（圖片來(lái)源）

TCP的狀態(tài)機(jī)

其實(shí)，網(wǎng)絡(luò)上的傳輸是沒(méi)有連接的，包括TCP也是一樣的。而TCP所謂的“連接”，其實(shí)只不過(guò)是在通訊的雙方維護(hù)一個(gè)“連接狀態(tài)”，讓它看上去好像有連接一樣。所以，TCP的狀態(tài)變換是非常重要的。

下面是：“TCP協(xié)議的狀態(tài)機(jī)”（圖片來(lái)源） 和 “TCP建鏈接”、“TCP斷鏈接”、“傳數(shù)據(jù)” 的對(duì)照?qǐng)D，我把兩個(gè)圖并排放在一起，這樣方便在你對(duì)照著看。另外，下面這兩個(gè)圖非常非常的重要，你一定要記牢。（吐個(gè)槽：看到這樣復(fù)雜的狀態(tài)機(jī)，就知道這個(gè)協(xié)議有多復(fù)雜，復(fù)雜的東西總是有很多坑爹的事情，所以TCP協(xié)議其實(shí)也挺坑爹的）

很多人會(huì)問(wèn)，為什么建鏈接要3次握手，斷鏈接需要4次揮手？

• 對(duì)于建鏈接的3次握手，主要是要初始化Sequence Number 的初始值。通信的雙方要互相通知對(duì)方自己的初始化的Sequence Number（縮寫(xiě)為ISN：Inital Sequence Number）——所以叫SYN，全稱Synchronize Sequence Numbers。也就上圖中的 x 和 y。這個(gè)號(hào)要作為以后的數(shù)據(jù)通信的序號(hào)，以保證應(yīng)用層接收到的數(shù)據(jù)不會(huì)因?yàn)榫W(wǎng)絡(luò)上的傳輸?shù)膯?wèn)題而亂序（TCP會(huì)用這個(gè)序號(hào)來(lái)拼接數(shù)據(jù)）。

• 對(duì)于4次揮手，其實(shí)你仔細(xì)看是2次，因?yàn)門(mén)CP是全雙工的，所以，發(fā)送方和接收方都需要Fin和Ack。只不過(guò)，有一方是被動(dòng)的，所以看上去就成了所謂的4次揮手。如果兩邊同時(shí)斷連接，那就會(huì)就進(jìn)入到CLOSING狀態(tài)，然后到達(dá)TIME_WAIT狀態(tài)。下圖是雙方同時(shí)斷連接的示意圖（你同樣可以對(duì)照著TCP狀態(tài)機(jī)看）：

兩端同時(shí)斷連接（圖片來(lái)源）

另外，有幾個(gè)事情需要注意一下：

• 關(guān)于建連接時(shí)SYN超時(shí)。試想一下，如果server端接到了clien發(fā)的SYN后回了SYN-ACK后client掉線了，server端沒(méi)有收到client回來(lái)的ACK，那么，這個(gè)連接處于一個(gè)中間狀態(tài)，即沒(méi)成功，也沒(méi)失敗。于是，server端如果在一定時(shí)間內(nèi)沒(méi)有收到的TCP會(huì)重發(fā)SYN-ACK。在Linux下，默認(rèn)重試次數(shù)為5次，重試的間隔時(shí)間從1s開(kāi)始每次都翻售，5次的重試時(shí)間間隔為1s, 2s, 4s, 8s, 16s，總共31s，第5次發(fā)出后還要等32s都知道第5次也超時(shí)了，所以，總共需要 1s + 2s + 4s+ 8s+ 16s + 32s = 2^6 -1 = 63s，TCP才會(huì)把斷開(kāi)這個(gè)連接。

• 關(guān)于SYN Flood攻擊。一些惡意的人就為此制造了SYN Flood攻擊——給服務(wù)器發(fā)了一個(gè)SYN后，就下線了，于是服務(wù)器需要默認(rèn)等63s才會(huì)斷開(kāi)連接，這樣，攻擊者就可以把服務(wù)器的syn連接的隊(duì)列耗盡，讓正常的連接請(qǐng)求不能處理。于是，Linux下給了一個(gè)叫tcp_syncookies的參數(shù)來(lái)應(yīng)對(duì)這個(gè)事——當(dāng)SYN隊(duì)列滿了后，TCP會(huì)通過(guò)源地址端口、目標(biāo)地址端口和時(shí)間戳打造出一個(gè)特別的Sequence Number發(fā)回去（又叫cookie），如果是攻擊者則不會(huì)有響應(yīng)，如果是正常連接，則會(huì)把這個(gè) SYN Cookie發(fā)回來(lái)，然后服務(wù)端可以通過(guò)cookie建連接（即使你不在SYN隊(duì)列中）。請(qǐng)注意，請(qǐng)先千萬(wàn)別用tcp_syncookies來(lái)處理正常的大負(fù)載的連接的情況。因?yàn)?，synccookies是妥協(xié)版的TCP協(xié)議，并不嚴(yán)謹(jǐn)。對(duì)于正常的請(qǐng)求，你應(yīng)該調(diào)整三個(gè)TCP參數(shù)可供你選擇，第一個(gè)是：tcp_synack_retries 可以用他來(lái)減少重試次數(shù)；第二個(gè)是：tcp_max_syn_backlog，可以增大SYN連接數(shù)；第三個(gè)是：tcp_abort_on_overflow 處理不過(guò)來(lái)干脆就直接拒絕連接了。

• 關(guān)于ISN的初始化。ISN是不能hard code的，不然會(huì)出問(wèn)題的——比如：如果連接建好后始終用1來(lái)做ISN，如果client發(fā)了30個(gè)segment過(guò)去，但是網(wǎng)絡(luò)斷了，于是 client重連，又用了1做ISN，但是之前連接的那些包到了，于是就被當(dāng)成了新連接的包，此時(shí)，client的Sequence Number 可能是3，而Server端認(rèn)為client端的這個(gè)號(hào)是30了。全亂了。RFC793中說(shuō)，ISN會(huì)和一個(gè)假的時(shí)鐘綁在一起，這個(gè)時(shí)鐘會(huì)在每4微秒對(duì)ISN做加一操作，直到超過(guò)2^32，又從0開(kāi)始。這樣，一個(gè)ISN的周期大約是4.55個(gè)小時(shí)。因?yàn)椋覀兗僭O(shè)我們的TCP Segment在網(wǎng)絡(luò)上的存活時(shí)間不會(huì)超過(guò)Maximum Segment Lifetime（縮寫(xiě)為MSL –?Wikipedia語(yǔ)條），所以，只要MSL的值小于4.55小時(shí)，那么，我們就不會(huì)重用到ISN。

• 關(guān)于 MSL 和?TIME_WAIT。通過(guò)上面的ISN的描述，相信你也知道MSL是怎么來(lái)的了。我們注意到，在TCP的狀態(tài)圖中，從TIME_WAIT狀態(tài)到CLOSED狀態(tài)，有一個(gè)超時(shí)設(shè)置，這個(gè)超時(shí)設(shè)置是 2*MSL（RFC793定義了MSL為2分鐘，Linux設(shè)置成了30s）為什么要這有TIME_WAIT？為什么不直接給轉(zhuǎn)成CLOSED狀態(tài)呢？主要有兩個(gè)原因：1）TIME_WAIT確保有足夠的時(shí)間讓對(duì)端收到了ACK，如果被動(dòng)關(guān)閉的那方?jīng)]有收到Ack，就會(huì)觸發(fā)被動(dòng)端重發(fā)Fin，一來(lái)一去正好2個(gè)MSL，2）有足夠的時(shí)間讓這個(gè)連接不會(huì)跟后面的連接混在一起（你要知道，有些自做主張的路由器會(huì)緩存IP數(shù)據(jù)包，如果連接被重用了，那么這些延遲收到的包就有可能會(huì)跟新連接混在一起）。你可以看看這篇文章《TIME_WAIT and its design implications for protocols and scalable client server systems》

• 關(guān)于TIME_WAIT數(shù)量太多。從上面的描述我們可以知道，TIME_WAIT是個(gè)很重要的狀態(tài)，但是如果在大并發(fā)的短鏈接下，TIME_WAIT 就會(huì)太多，這也會(huì)消耗很多系統(tǒng)資源。只要搜一下，你就會(huì)發(fā)現(xiàn)，十有八九的處理方式都是教你設(shè)置兩個(gè)參數(shù)，一個(gè)叫tcp_tw_reuse，另一個(gè)叫tcp_tw_recycle的參數(shù)，這兩個(gè)參數(shù)默認(rèn)值都是被關(guān)閉的，后者recyle比前者resue更為激進(jìn)，resue要溫柔一些。另外，如果使用tcp_tw_reuse，必需設(shè)置tcp_timestamps=1，否則無(wú)效。這里，你一定要注意，打開(kāi)這兩個(gè)參數(shù)會(huì)有比較大的坑——可能會(huì)讓TCP連接出一些詭異的問(wèn)題（因?yàn)槿缟鲜鲆粯?，如果不等待超時(shí)重用連接的話，新的連接可能會(huì)建不上。正如官方文檔上說(shuō)的一樣“It should not be changed without advice/request of technical experts”）。

• 關(guān)于tcp_tw_reuse。官方文檔上說(shuō)tcp_tw_reuse 加上tcp_timestamps（又叫PAWS, for Protection Against Wrapped Sequence Numbers）可以保證協(xié)議的角度上的安全，但是你需要tcp_timestamps在兩邊都被打開(kāi)（你可以讀一下tcp_twsk_unique的源碼?）。我個(gè)人估計(jì)還是有一些場(chǎng)景會(huì)有問(wèn)題。

• 關(guān)于tcp_tw_recycle。如果是tcp_tw_recycle被打開(kāi)了話，會(huì)假設(shè)對(duì)端開(kāi)啟了tcp_timestamps，然后會(huì)去比較時(shí)間戳，如果時(shí)間戳變大了，就可以重用。但是，如果對(duì)端是一個(gè)NAT網(wǎng)絡(luò)的話（如：一個(gè)公司只用一個(gè)IP出公網(wǎng)）或是對(duì)端的IP被另一臺(tái)重用了，這個(gè)事就復(fù)雜了。建鏈接的SYN可能就被直接丟掉了（你可能會(huì)看到connection time out的錯(cuò)誤）（如果你想觀摩一下Linux的內(nèi)核代碼，請(qǐng)參看源碼?tcp_timewait_state_process）。

• 關(guān)于tcp_max_tw_buckets。這個(gè)是控制并發(fā)的TIME_WAIT的數(shù)量，默認(rèn)值是180000，如果超限，那么，系統(tǒng)會(huì)把多的給destory掉，然后在日志里打一個(gè)警告（如：time wait bucket table overflow），官網(wǎng)文檔說(shuō)這個(gè)參數(shù)是用來(lái)對(duì)抗DDoS攻擊的。也說(shuō)的默認(rèn)值180000并不小。這個(gè)還是需要根據(jù)實(shí)際情況考慮。

Again，使用tcp_tw_reuse和tcp_tw_recycle來(lái)解決TIME_WAIT的問(wèn)題是非常非常危險(xiǎn)的，因?yàn)檫@兩個(gè)參數(shù)違反了TCP協(xié)議（RFC?1122）?

其實(shí)，TIME_WAIT表示的是你主動(dòng)斷連接，所以，這就是所謂的“不作死不會(huì)死”。試想，如果讓對(duì)端斷連接，那么這個(gè)破問(wèn)題就是對(duì)方的了，呵呵。另外，如果你的服務(wù)器是于HTTP服務(wù)器，那么設(shè)置一個(gè)HTTP的KeepAlive有多重要（瀏覽器會(huì)重用一個(gè)TCP連接來(lái)處理多個(gè)HTTP請(qǐng)求），然后讓客戶端去斷鏈接（你要小心，瀏覽器可能會(huì)非常貪婪，他們不到萬(wàn)不得已不會(huì)主動(dòng)斷連接）。

數(shù)據(jù)傳輸中的Sequence Number

下圖是我從Wireshark中截了個(gè)我在訪問(wèn)coolshell.cn時(shí)的有數(shù)據(jù)傳輸?shù)膱D給你看一下，SeqNum是怎么變的。（使用Wireshark菜單中的Statistics ->Flow Graph… ）

你可以看到，SeqNum的增加是和傳輸?shù)淖止?jié)數(shù)相關(guān)的。上圖中，三次握手后，來(lái)了兩個(gè)Len:1440的包，而第二個(gè)包的SeqNum就成了1441。然后第一個(gè)ACK回的是1441，表示第一個(gè)1440收到了。

注意：如果你用Wireshark抓包程序看3次握手，你會(huì)發(fā)現(xiàn)SeqNum總是為0，不是這樣的，Wireshark為了顯示更友好，使用了Relative SeqNum——相對(duì)序號(hào)，你只要在右鍵菜單中的protocol preference 中取消掉就可以看到“Absolute SeqNum”了

TCP重傳機(jī)制

TCP要保證所有的數(shù)據(jù)包都可以到達(dá)，所以，必需要有重傳機(jī)制。

注意，接收端給發(fā)送端的Ack確認(rèn)只會(huì)確認(rèn)最后一個(gè)連續(xù)的包，比如，發(fā)送端發(fā)了1,2,3,4,5一共五份數(shù)據(jù)，接收端收到了1，2，于是回ack 3，然后收到了4（注意此時(shí)3沒(méi)收到），此時(shí)的TCP會(huì)怎么辦？我們要知道，因?yàn)檎缜懊嫠f(shuō)的，SeqNum和Ack是以字節(jié)數(shù)為單位，所以ack的時(shí)候，不能跳著確認(rèn)，只能確認(rèn)最大的連續(xù)收到的包，不然，發(fā)送端就以為之前的都收到了。

超時(shí)重傳機(jī)制

一種是不回ack，死等3，當(dāng)發(fā)送方發(fā)現(xiàn)收不到3的ack超時(shí)后，會(huì)重傳3。一旦接收方收到3后，會(huì)ack 回 4——意味著3和4都收到了。

但是，這種方式會(huì)有比較嚴(yán)重的問(wèn)題，那就是因?yàn)橐赖?，所以會(huì)導(dǎo)致4和5即便已經(jīng)收到了，而發(fā)送方也完全不知道發(fā)生了什么事，因?yàn)闆](méi)有收到Ack，所以，發(fā)送方可能會(huì)悲觀地認(rèn)為也丟了，所以有可能也會(huì)導(dǎo)致4和5的重傳。

對(duì)此有兩種選擇：

• 一種是僅重傳timeout的包。也就是第3份數(shù)據(jù)。
• 另一種是重傳timeout后所有的數(shù)據(jù)，也就是第3，4，5這三份數(shù)據(jù)。

這兩種方式有好也有不好。第一種會(huì)節(jié)省帶寬，但是慢，第二種會(huì)快一點(diǎn)，但是會(huì)浪費(fèi)帶寬，也可能會(huì)有無(wú)用功。但總體來(lái)說(shuō)都不好。因?yàn)槎荚诘萾imeout，timeout可能會(huì)很長(zhǎng)（在下篇會(huì)說(shuō)TCP是怎么動(dòng)態(tài)地計(jì)算出timeout的）

快速重傳機(jī)制

于是，TCP引入了一種叫Fast Retransmit?的算法，不以時(shí)間驅(qū)動(dòng)，而以數(shù)據(jù)驅(qū)動(dòng)重傳。也就是說(shuō)，如果，包沒(méi)有連續(xù)到達(dá)，就ack最后那個(gè)可能被丟了的包，如果發(fā)送方連續(xù)收到3次相同的ack，就重傳。Fast Retransmit的好處是不用等timeout了再重傳。

比如：如果發(fā)送方發(fā)出了1，2，3，4，5份數(shù)據(jù)，第一份先到送了，于是就ack回2，結(jié)果2因?yàn)槟承┰驔](méi)收到，3到達(dá)了，于是還是ack回2，后面的4和5都到了，但是還是ack回2，因?yàn)?還是沒(méi)有收到，于是發(fā)送端收到了三個(gè)ack=2的確認(rèn)，知道了2還沒(méi)有到，于是就馬上重轉(zhuǎn)2。然后，接收端收到了2，此時(shí)因?yàn)?，4，5都收到了，于是ack回6。示意圖如下：

Fast?Retransmit只解決了一個(gè)問(wèn)題，就是timeout的問(wèn)題，它依然面臨一個(gè)艱難的選擇，就是重轉(zhuǎn)之前的一個(gè)還是重裝所有的問(wèn)題。對(duì)于上面的示例來(lái)說(shuō)，是重傳#2呢還是重傳#2，#3，#4，#5呢？因?yàn)榘l(fā)送端并不清楚這連續(xù)的3個(gè)ack(2)是誰(shuí)傳回來(lái)的？也許發(fā)送端發(fā)了20份數(shù)據(jù)，是#6，#10，#20傳來(lái)的呢。這樣，發(fā)送端很有可能要重傳從2到20的這堆數(shù)據(jù)（這就是某些TCP的實(shí)際的實(shí)現(xiàn)）?？梢?jiàn)，這是一把雙刃劍。

SACK 方法

另外一種更好的方式叫：Selective Acknowledgment (SACK)（參看RFC 2018），這種方式需要在TCP頭里加一個(gè)SACK的東西，ACK還是Fast Retransmit的ACK，SACK則是匯報(bào)收到的數(shù)據(jù)碎版。參看下圖：

這樣，在發(fā)送端就可以根據(jù)回傳的SACK來(lái)知道哪些數(shù)據(jù)到了，哪些沒(méi)有到。于是就優(yōu)化了Fast?Retransmit的算法。當(dāng)然，這個(gè)協(xié)議需要兩邊都支持。在 Linux下，可以通過(guò)tcp_sack參數(shù)打開(kāi)這個(gè)功能（Linux 2.4后默認(rèn)打開(kāi)）。

這里還需要注意一個(gè)問(wèn)題——接收方Reneging，所謂Reneging的意思就是接收方有權(quán)把已經(jīng)報(bào)給發(fā)送端SACK里的數(shù)據(jù)給丟了。這樣干是不被鼓勵(lì)的，因?yàn)檫@個(gè)事會(huì)把問(wèn)題復(fù)雜化了，但是，接收方這么做可能會(huì)有些極端情況，比如要把內(nèi)存給別的更重要的東西。所以，發(fā)送方也不能完全依賴SACK，還是要依賴ACK，并維護(hù)Time-Out，如果后續(xù)的ACK沒(méi)有增長(zhǎng)，那么還是要把SACK的東西重傳，另外，接收端這邊永遠(yuǎn)不能把SACK的包標(biāo)記為Ack。

注意：SACK會(huì)消費(fèi)發(fā)送方的資源，試想，如果一個(gè)攻擊者給數(shù)據(jù)發(fā)送方發(fā)一堆SACK的選項(xiàng)，這會(huì)導(dǎo)致發(fā)送方開(kāi)始要重傳甚至遍歷已經(jīng)發(fā)出的數(shù)據(jù)，這會(huì)消耗很多發(fā)送端的資源。詳細(xì)的東西請(qǐng)參看《TCP SACK的性能權(quán)衡》

Duplicate SACK – 重復(fù)收到數(shù)據(jù)的問(wèn)題

Duplicate SACK又稱D-SACK，其主要使用了SACK來(lái)告訴發(fā)送方有哪些數(shù)據(jù)被重復(fù)接收了。RFC-2833?里有詳細(xì)描述和示例。下面舉幾個(gè)例子（來(lái)源于RFC-2833）

D-SACK使用了SACK的第一個(gè)段來(lái)做標(biāo)志，

• 如果SACK的第一個(gè)段的范圍被ACK所覆蓋，那么就是D-SACK

• 如果SACK的第一個(gè)段的范圍被SACK的第二個(gè)段覆蓋，那么就是D-SACK

示例一：ACK丟包

下面的示例中，丟了兩個(gè)ACK，所以，發(fā)送端重傳了第一個(gè)數(shù)據(jù)包（3000-3499），于是接收端發(fā)現(xiàn)重復(fù)收到，于是回了一個(gè)SACK=3000-3500，因?yàn)锳CK都到了4000意味著收到了4000之前的所有數(shù)據(jù)，所以這個(gè)SACK就是D-SACK——旨在告訴發(fā)送端我收到了重復(fù)的數(shù)據(jù)，而且我們的發(fā)送端還知道，數(shù)據(jù)包沒(méi)有丟，丟的是ACK包。

Transmitted? Received??? ACK Sent
Segment????? Segment???? (Including SACK Blocks)
3000-3499??? 3000-3499?? 3500 (ACK dropped)
3500-3999??? 3500-3999?? 4000 (ACK dropped)
3000-3499??? 3000-3499?? 4000, SACK=3000-3500
---------

示例二，網(wǎng)絡(luò)延誤

下面的示例中，網(wǎng)絡(luò)包（1000-1499）被網(wǎng)絡(luò)給延誤了，導(dǎo)致發(fā)送方?jīng)]有收到ACK，而后面到達(dá)的三個(gè)包觸發(fā)了“Fast Retransmit算法”，所以重傳，但重傳時(shí)，被延誤的包又到了，所以，回了一個(gè)SACK=1000-1500，因?yàn)锳CK已到了3000，所以，這個(gè)SACK是D-SACK——標(biāo)識(shí)收到了重復(fù)的包。

這個(gè)案例下，發(fā)送端知道之前因?yàn)椤癋ast Retransmit算法”觸發(fā)的重傳不是因?yàn)榘l(fā)出去的包丟了，也不是因?yàn)榛貞?yīng)的ACK包丟了，而是因?yàn)榫W(wǎng)絡(luò)延時(shí)了。

Transmitted??? Received??? ACK Sent
Segment??????? Segment???? (Including SACK Blocks)
500-999??????? 500-999???? 1000
1000-1499????? (delayed)
1500-1999????? 1500-1999?? 1000, SACK=1500-2000
2000-2499????? 2000-2499?? 1000, SACK=1500-2500
2500-2999????? 2500-2999?? 1000, SACK=1500-3000
1000-1499????? 1000-1499?? 3000
1000-1499?? 3000, SACK=1000-1500
---------

可見(jiàn)，引入了D-SACK，有這么幾個(gè)好處：

1）可以讓發(fā)送方知道，是發(fā)出去的包丟了，還是回來(lái)的ACK包丟了。

2）是不是自己的timeout太小了，導(dǎo)致重傳。

3）網(wǎng)絡(luò)上出現(xiàn)了先發(fā)的包后到的情況（又稱reordering）

4）網(wǎng)絡(luò)上是不是把我的數(shù)據(jù)包給復(fù)制了。

?知道這些東西可以很好得幫助TCP了解網(wǎng)絡(luò)情況，從而可以更好的做網(wǎng)絡(luò)上的流控。

Linux下的tcp_dsack參數(shù)用于開(kāi)啟這個(gè)功能（Linux 2.4后默認(rèn)打開(kāi)）

好了，上篇就到這里結(jié)束了。如果你覺(jué)得我寫(xiě)得還比較淺顯易懂，那么，歡迎移步看下篇《TCP的那些事（下）》