TCP是一個巨復雜的協(xié)議，因為他要解決很多問題叠蝇，而這些問題又帶出了很多子問題和陰暗面。所以學習TCP本身是個比較痛苦的過程年缎，但對于學習的過程卻能讓人有很多收獲悔捶。關于TCP這個協(xié)議的細節(jié)，我還是推薦你去看W.Richard Stevens的《TCP/IP 詳解 卷1：協(xié)議》（當然单芜，你也可以去讀一下RFC793以及后面N多的RFC）蜕该。另外，本文我會使用英文術語洲鸠，這樣方便你通過這些英文關鍵詞來查找相關的技術文檔堂淡。
之所以想寫這篇文章，目的有三個坛怪，
- 一個是想鍛煉一下自己是否可以用簡單的篇幅把這么復雜的TCP協(xié)議描清楚的能力淤齐。
- 另一個是覺得現(xiàn)在的好多程序員基本上不會認認真真地讀本書，喜歡快餐文化袜匿，所以，希望這篇快餐文章可以讓你對TCP這個古典技術有所了解稚疹，并能體會到軟件設計中的種種難處居灯。并且你可以從中有一些軟件設計上的收獲。
- 最重要的希望這些基礎知識可以讓你搞清很多以前一些似是而非的東西内狗，并且你能意識到基礎的重要怪嫌。
所以，本文不會面面俱到柳沙，只是對TCP協(xié)議岩灭、算法和原理的科普。
我本來只想寫一個篇幅的文章的赂鲤，但是TCP真TMD的復雜噪径，比C++復雜多了柱恤，這30多年來，各種優(yōu)化變種爭論和修改找爱。所以梗顺，寫著寫著就發(fā)現(xiàn)只有砍成兩篇。
- 上篇中车摄，主要向你介紹TCP協(xié)議的定義和丟包時的重傳機制寺谤。
- 下篇中，重點介紹TCP的流迭吮播、擁塞處理变屁。
廢話少說，首先意狠，我們需要知道TCP在網(wǎng)絡OSI的七層模型中的第四層——Transport層粟关，IP在第三層——Network層，ARP在第二層——Data Link層摄职，在第二層上的數(shù)據(jù)誊役，我們叫Frame，在第三層上的數(shù)據(jù)叫Packet谷市，第四層的數(shù)據(jù)叫Segment蛔垢。
首先，我們需要知道迫悠，我們程序的數(shù)據(jù)首先會打到TCP的Segment中鹏漆，然后TCP的Segment會打到IP的Packet中，然后再打到以太網(wǎng)Ethernet的Frame中创泄，傳到對端后艺玲，各個層解析自己的協(xié)議，然后把數(shù)據(jù)交給更高層的協(xié)議處理鞠抑。
TCP頭格式
接下來饭聚，我們來看一下TCP頭的格式
[圖片上傳失敗...(image-9d41ae-1513065586927)]
TCP頭格式（圖片來源）
你需要注意這么幾點：
- TCP的包是沒有IP地址的，那是IP層上的事搁拙。但是有源端口和目標端口秒梳。
- 一個TCP連接需要四個元組來表示是同一個連接（src_ip, src_port, dst_ip, dst_port）準確說是五元組，還有一個是協(xié)議箕速。但因為這里只是說TCP協(xié)議酪碘，所以，這里我只說四元組盐茎。
- 注意上圖中的四個非常重要的東西：
Sequence Number是包的序號兴垦，用來解決網(wǎng)絡包亂序（reordering）問題。
Acknowledgement Number就是ACK——用于確認收到，用來解決不丟包的問題探越。
Window又叫Advertised-Window狡赐，也就是著名的滑動窗口（Sliding Window），用于解決流控的扶关。
-
TCP Flag
阴汇，也就是包的類型，主要是用于操控TCP的狀態(tài)機的节槐。
關于其它的東西搀庶，可以參看下面的圖示
[圖片上傳失敗...(image-fed5d3-1513065586927)]
（圖片來源）
TCP的狀態(tài)機
其實，網(wǎng)絡上的傳輸是沒有連接的铜异，包括TCP也是一樣的哥倔。而TCP所謂的“連接”，其實只不過是在通訊的雙方維護一個“連接狀態(tài)”揍庄，讓它看上去好像有連接一樣咆蒿。所以，TCP的狀態(tài)變換是非常重要的蚂子。
下面是：“TCP協(xié)議的狀態(tài)機”（圖片來源） 和 “TCP建鏈接”沃测、“TCP斷鏈接”、“傳數(shù)據(jù)” 的對照圖食茎，我把兩個圖并排放在一起蒂破，這樣方便在你對照著看。另外别渔，下面這兩個圖非常非常的重要附迷，你一定要記牢。（吐個槽：看到這樣復雜的狀態(tài)機哎媚，就知道這個協(xié)議有多復雜喇伯，復雜的東西總是有很多坑爹的事情，所以TCP協(xié)議其實也挺坑爹的）
[圖片上傳失敗...(image-7c337d-1513065586927)]
[圖片上傳失敗...(image-961941-1513065586927)]
很多人會問拨与，為什么建鏈接要3次握手稻据，斷鏈接需要4次揮手？
對于建鏈接的3次握手买喧，主要是要初始化Sequence Number 的初始值攀甚。通信的雙方要互相通知對方自己的初始化的Sequence Number（縮寫為ISN：Inital Sequence Number）——所以叫SYN，全稱Synchronize Sequence Numbers岗喉。也就上圖中的 x 和 y。這個號要作為以后的數(shù)據(jù)通信的序號炸庞，以保證應用層接收到的數(shù)據(jù)不會因為網(wǎng)絡上的傳輸?shù)膯栴}而亂序（TCP會用這個序號來拼接數(shù)據(jù)）钱床。
對于4次揮手，其實你仔細看是2次埠居，因為TCP是全雙工的查牌，所以事期，發(fā)送方和接收方都需要Fin和Ack。只不過纸颜，有一方是被動的兽泣，所以看上去就成了所謂的4次揮手。如果兩邊同時斷連接胁孙，那就會就進入到CLOSING狀態(tài)唠倦，然后到達TIME_WAIT狀態(tài)。下圖是雙方同時斷連接的示意圖（你同樣可以對照著TCP狀態(tài)機看）：
[圖片上傳失敗...(image-7221ea-1513065586927)]
兩端同時斷連接（圖片來源）
另外涮较，有幾個事情需要注意一下：
關于建連接時SYN超時稠鼻。試想一下，如果server端接到了clien發(fā)的SYN后回了SYN-ACK后client掉線了狂票，server端沒有收到client回來的ACK候齿，那么，這個連接處于一個中間狀態(tài)闺属，即沒成功慌盯，也沒失敗。于是掂器，server端如果在一定時間內(nèi)沒有收到的TCP會重發(fā)SYN-ACK亚皂。在Linux下，默認重試次數(shù)為5次唉匾，重試的間隔時間從1s開始每次都翻售孕讳，5次的重試時間間隔為1s, 2s, 4s, 8s, 16s，總共31s巍膘，第5次發(fā)出后還要等32s都知道第5次也超時了厂财，所以，總共需要 1s + 2s + 4s+ 8s+ 16s + 32s = 2^6 -1 = 63s峡懈，TCP才會把斷開這個連接璃饱。
關于SYN Flood攻擊。一些惡意的人就為此制造了SYN Flood攻擊——給服務器發(fā)了一個SYN后肪康，就下線了荚恶，于是服務器需要默認等63s才會斷開連接，這樣磷支，攻擊者就可以把服務器的syn連接的隊列耗盡谒撼，讓正常的連接請求不能處理。于是雾狈，Linux下給了一個叫tcp_syncookies的參數(shù)來應對這個事——當SYN隊列滿了后廓潜，TCP會通過源地址端口、目標地址端口和時間戳打造出一個特別的Sequence Number發(fā)回去（又叫cookie），如果是攻擊者則不會有響應辩蛋，如果是正常連接呻畸，則會把這個 SYN Cookie發(fā)回來，然后服務端可以通過cookie建連接（即使你不在SYN隊列中）悼院。請注意伤为，請先千萬別用tcp_syncookies來處理正常的大負載的連接的情況。因為据途，synccookies是妥協(xié)版的TCP協(xié)議绞愚，并不嚴謹。對于正常的請求昨凡，你應該調(diào)整三個TCP參數(shù)可供你選擇爽醋，第一個是：tcp_synack_retries 可以用他來減少重試次數(shù)；第二個是：tcp_max_syn_backlog便脊，可以增大SYN連接數(shù)蚂四；第三個是：tcp_abort_on_overflow 處理不過來干脆就直接拒絕連接了。
關于ISN的初始化哪痰。ISN是不能hard code的遂赠，不然會出問題的——比如：如果連接建好后始終用1來做ISN，如果client發(fā)了30個segment過去晌杰，但是網(wǎng)絡斷了跷睦，于是 client重連，又用了1做ISN肋演，但是之前連接的那些包到了抑诸，于是就被當成了新連接的包，此時爹殊，client的Sequence Number 可能是3蜕乡，而Server端認為client端的這個號是30了。全亂了梗夸。RFC793中說层玲，ISN會和一個假的時鐘綁在一起，這個時鐘會在每4微秒對ISN做加一操作反症，直到超過2^32辛块，又從0開始。這樣铅碍，一個ISN的周期大約是4.55個小時润绵。因為，我們假設我們的TCP Segment在網(wǎng)絡上的存活時間不會超過Maximum Segment Lifetime（縮寫為MSL – Wikipedia語條）胞谈，所以授药，只要MSL的值小于4.55小時士嚎，那么，我們就不會重用到ISN悔叽。
關于 MSL 和 TIME_WAIT。通過上面的ISN的描述爵嗅，相信你也知道MSL是怎么來的了娇澎。我們注意到，在TCP的狀態(tài)圖中睹晒，從TIME_WAIT狀態(tài)到CLOSED狀態(tài)趟庄，有一個超時設置，這個超時設置是 2*MSL（RFC793定義了MSL為2分鐘伪很，Linux設置成了30s）為什么要這有TIME_WAIT戚啥？為什么不直接給轉(zhuǎn)成CLOSED狀態(tài)呢？主要有兩個原因：1）TIME_WAIT確保有足夠的時間讓對端收到了ACK锉试，如果被動關閉的那方?jīng)]有收到Ack猫十，就會觸發(fā)被動端重發(fā)Fin，一來一去正好2個MSL呆盖，2）有足夠的時間讓這個連接不會跟后面的連接混在一起（你要知道拖云，有些自做主張的路由器會緩存IP數(shù)據(jù)包，如果連接被重用了应又，那么這些延遲收到的包就有可能會跟新連接混在一起）宙项。你可以看看這篇文章《TIME_WAIT and its design implications for protocols and scalable client server systems》
關于TIME_WAIT數(shù)量太多。從上面的描述我們可以知道株扛，TIME_WAIT是個很重要的狀態(tài)尤筐，但是如果在大并發(fā)的短鏈接下，TIME_WAIT 就會太多洞就，這也會消耗很多系統(tǒng)資源盆繁。只要搜一下，你就會發(fā)現(xiàn)奖磁，十有八九的處理方式都是教你設置兩個參數(shù)改基，一個叫tcp_tw_reuse，另一個叫tcp_tw_recycle的參數(shù)咖为，這兩個參數(shù)默認值都是被關閉的秕狰，后者recyle比前者resue更為激進，resue要溫柔一些躁染。另外鸣哀，如果使用tcp_tw_reuse，必需設置tcp_timestamps=1吞彤，否則無效我衬。這里叹放，你一定要注意，打開這兩個參數(shù)會有比較大的坑——可能會讓TCP連接出一些詭異的問題（因為如上述一樣挠羔，如果不等待超時重用連接的話井仰，新的連接可能會建不上。正如官方文檔上說的一樣“It should not be changed without advice/request of technical experts”）破加。
-
關于tcp_tw_reuse俱恶。官方文檔上說tcp_tw_reuse 加上tcp_timestamps（又叫PAWS, for Protection Against Wrapped Sequence Numbers）可以保證協(xié)議的角度上的安全，但是你需要tcp_timestamps在兩邊都被打開（你可以讀一下tcp_twsk_unique的源碼
）范舀。我個人估計還是有一些場景會有問題合是。
關于tcp_tw_recycle。如果是tcp_tw_recycle被打開了話锭环，會假設對端開啟了tcp_timestamps聪全，然后會去比較時間戳，如果時間戳變大了辅辩，就可以重用难礼。但是，如果對端是一個NAT網(wǎng)絡的話（如：一個公司只用一個IP出公網(wǎng)）或是對端的IP被另一臺重用了汽久，這個事就復雜了鹤竭。建鏈接的SYN可能就被直接丟掉了（你可能會看到connection time out的錯誤）（如果你想觀摩一下Linux的內(nèi)核代碼，請參看源碼 tcp_timewait_state_process）景醇。
-
關于tcp_max_tw_buckets臀稚。這個是控制并發(fā)的TIME_WAIT的數(shù)量，默認值是180000三痰，如果超限吧寺，那么，系統(tǒng)會把多的給destory掉散劫，然后在日志里打一個警告（如：
time wait bucket table overflow
）稚机，官網(wǎng)文檔說這個參數(shù)是用來對抗DDoS攻擊的。也說的默認值180000并不小获搏。這個還是需要根據(jù)實際情況考慮赖条。
**Again，使用tcp_tw_reuse和tcp_tw_recycle來解決TIME_WAIT的問題是非常非常危險的常熙，因為這兩個參數(shù)違反了TCP協(xié)議（RFC 1122） **
其實纬乍，TIME_WAIT表示的是你主動斷連接，所以裸卫，這就是所謂的“不作死不會死”仿贬。試想，如果讓對端斷連接墓贿，那么這個破問題就是對方的了茧泪，呵呵蜓氨。另外，如果你的服務器是于HTTP服務器队伟，那么設置一個HTTP的KeepAlive有多重要（瀏覽器會重用一個TCP連接來處理多個HTTP請求）穴吹，然后讓客戶端去斷鏈接（你要小心，瀏覽器可能會非常貪婪缰泡，他們不到萬不得已不會主動斷連接）刀荒。
數(shù)據(jù)傳輸中的Sequence Number
下圖是我從Wireshark中截了個我在訪問coolshell.cn時的有數(shù)據(jù)傳輸?shù)膱D給你看一下，SeqNum是怎么變的棘钞。（使用Wireshark菜單中的Statistics ->Flow Graph… ）
[圖片上傳失敗...(image-4432f-1513065586926)]
你可以看到，SeqNum的增加是和傳輸?shù)淖止?jié)數(shù)相關的干毅。上圖中宜猜，三次握手后，來了兩個Len:1440的包硝逢，而第二個包的SeqNum就成了1441姨拥。然后第一個ACK回的是1441，表示第一個1440收到了渠鸽。
注意：如果你用Wireshark抓包程序看3次握手叫乌，你會發(fā)現(xiàn)SeqNum總是為0，不是這樣的徽缚，Wireshark為了顯示更友好憨奸，使用了Relative SeqNum——相對序號，你只要在右鍵菜單中的protocol preference 中取消掉就可以看到“Absolute SeqNum”了
TCP重傳機制
TCP要保證所有的數(shù)據(jù)包都可以到達凿试，所以排宰，必需要有重傳機制。
注意那婉，接收端給發(fā)送端的Ack確認只會確認最后一個連續(xù)的包板甘，比如，發(fā)送端發(fā)了1,2,3,4,5一共五份數(shù)據(jù)详炬，接收端收到了1盐类，2，于是回ack 3呛谜，然后收到了4（注意此時3沒收到）在跳，此時的TCP會怎么辦？我們要知道呻率，因為正如前面所說的硬毕，SeqNum和Ack是以字節(jié)數(shù)為單位，所以ack的時候礼仗，不能跳著確認吐咳，只能確認最大的連續(xù)收到的包逻悠，不然，發(fā)送端就以為之前的都收到了韭脊。
超時重傳機制
一種是不回ack童谒，死等3，當發(fā)送方發(fā)現(xiàn)收不到3的ack超時后沪羔，會重傳3饥伊。一旦接收方收到3后，會ack 回 4——意味著3和4都收到了蔫饰。
但是琅豆，這種方式會有比較嚴重的問題，那就是因為要死等3篓吁，所以會導致4和5即便已經(jīng)收到了茫因，而發(fā)送方也完全不知道發(fā)生了什么事，因為沒有收到Ack杖剪，所以冻押，發(fā)送方可能會悲觀地認為也丟了，所以有可能也會導致4和5的重傳盛嘿。
對此有兩種選擇：
- 一種是僅重傳timeout的包洛巢。也就是第3份數(shù)據(jù)。
- 另一種是重傳timeout后所有的數(shù)據(jù)次兆，也就是第3稿茉，4，5這三份數(shù)據(jù)类垦。
這兩種方式有好也有不好狈邑。第一種會節(jié)省帶寬，但是慢蚤认，第二種會快一點米苹，但是會浪費帶寬，也可能會有無用功砰琢。但總體來說都不好蘸嘶。因為都在等timeout，timeout可能會很長（在下篇會說TCP是怎么動態(tài)地計算出timeout的）
快速重傳機制
于是陪汽，TCP引入了一種叫Fast Retransmit
的算法训唱，不以時間驅(qū)動，而以數(shù)據(jù)驅(qū)動重傳挚冤。也就是說况增，如果，包沒有連續(xù)到達训挡，就ack最后那個可能被丟了的包澳骤，如果發(fā)送方連續(xù)收到3次相同的ack歧强，就重傳。Fast Retransmit的好處是不用等timeout了再重傳为肮。
比如：如果發(fā)送方發(fā)出了1摊册，2，3颊艳，4茅特，5份數(shù)據(jù)，第一份先到送了棋枕，于是就ack回2白修，結(jié)果2因為某些原因沒收到，3到達了重斑，于是還是ack回2熬荆，后面的4和5都到了，但是還是ack回2绸狐，因為2還是沒有收到，于是發(fā)送端收到了三個ack=2的確認累盗，知道了2還沒有到寒矿，于是就馬上重轉(zhuǎn)2。然后若债，接收端收到了2符相，此時因為3，4蠢琳，5都收到了啊终，于是ack回6。示意圖如下：
[圖片上傳失敗...(image-5bd7c5-1513065586926)]
Fast Retransmit只解決了一個問題傲须，就是timeout的問題蓝牲，它依然面臨一個艱難的選擇，就是泰讽，是重傳之前的一個還是重傳所有的問題例衍。對于上面的示例來說，是重傳#2呢還是重傳#2已卸，#3佛玄，#4，#5呢累澡？因為發(fā)送端并不清楚這連續(xù)的3個ack(2)是誰傳回來的梦抢？也許發(fā)送端發(fā)了20份數(shù)據(jù)，是#6愧哟，#10奥吩，#20傳來的呢哼蛆。這樣，發(fā)送端很有可能要重傳從2到20的這堆數(shù)據(jù)（這就是某些TCP的實際的實現(xiàn)）圈驼∪搜浚可見，這是一把雙刃劍绩脆。
SACK 方法
另外一種更好的方式叫：Selective Acknowledgment (SACK)（參看RFC 2018）萤厅，這種方式需要在TCP頭里加一個SACK的東西，ACK還是Fast Retransmit的ACK靴迫，SACK則是匯報收到的數(shù)據(jù)碎版惕味。參看下圖：
[圖片上傳失敗...(image-dddcf-1513065586926)]
這樣，在發(fā)送端就可以根據(jù)回傳的SACK來知道哪些數(shù)據(jù)到了玉锌，哪些沒有到名挥。于是就優(yōu)化了Fast Retransmit的算法。當然主守，這個協(xié)議需要兩邊都支持禀倔。在 Linux下，可以通過tcp_sack參數(shù)打開這個功能（Linux 2.4后默認打開）参淫。
這里還需要注意一個問題——接收方Reneging救湖，所謂Reneging的意思就是接收方有權把已經(jīng)報給發(fā)送端SACK里的數(shù)據(jù)給丟了待秃。這樣干是不被鼓勵的齐媒，因為這個事會把問題復雜化了梧乘，但是艾船，接收方這么做可能會有些極端情況惹悄，比如要把內(nèi)存給別的更重要的東西畦戒。所以季俩，發(fā)送方也不能完全依賴SACK昼蛀，還是要依賴ACK棕兼，并維護Time-Out陡舅，如果后續(xù)的ACK沒有增長，那么還是要把SACK的東西重傳程储，另外蹭沛，接收端這邊永遠不能把SACK的包標記為Ack。
注意：SACK會消費發(fā)送方的資源章鲤，試想摊灭，如果一個攻擊者給數(shù)據(jù)發(fā)送方發(fā)一堆SACK的選項，這會導致發(fā)送方開始要重傳甚至遍歷已經(jīng)發(fā)出的數(shù)據(jù)败徊，這會消耗很多發(fā)送端的資源帚呼。詳細的東西請參看《TCP SACK的性能權衡》
Duplicate SACK – 重復收到數(shù)據(jù)的問題
Duplicate SACK又稱D-SACK，其主要使用了SACK來告訴發(fā)送方有哪些數(shù)據(jù)被重復接收了。RFC-2883 里有詳細描述和示例煤杀。下面舉幾個例子（來源于RFC-2883）
D-SACK使用了SACK的第一個段來做標志眷蜈，
如果SACK的第一個段的范圍被ACK所覆蓋，那么就是D-SACK
如果SACK的第一個段的范圍被SACK的第二個段覆蓋沈自，那么就是D-SACK
示例一：ACK丟包
下面的示例中酌儒，丟了兩個ACK，所以枯途，發(fā)送端重傳了第一個數(shù)據(jù)包（3000-3499）忌怎，于是接收端發(fā)現(xiàn)重復收到，于是回了一個SACK=3000-3500酪夷，因為ACK都到了4000意味著收到了4000之前的所有數(shù)據(jù)榴啸，所以這個SACK就是D-SACK——旨在告訴發(fā)送端我收到了重復的數(shù)據(jù)，而且我們的發(fā)送端還知道晚岭，數(shù)據(jù)包沒有丟鸥印，丟的是ACK包。
|
1
2
3
4
5
6
7
|
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)絡延誤**
下面的示例中库说，網(wǎng)絡包（1000-1499）被網(wǎng)絡給延誤了，導致發(fā)送方?jīng)]有收到ACK片择，而后面到達的三個包觸發(fā)了“Fast Retransmit算法”璃弄，所以重傳，但重傳時构回，被延誤的包又到了，所以疏咐，回了一個SACK=1000-1500纤掸，因為ACK已到了3000，所以浑塞，這個SACK是D-SACK——標識收到了重復的包借跪。
這個案例下，發(fā)送端知道之前因為“Fast Retransmit算法”觸發(fā)的重傳不是因為發(fā)出去的包丟了酌壕，也不是因為回應的ACK包丟了掏愁，而是因為網(wǎng)絡延時了。
|
1
2
3
4
5
6
7
8
9
10
11
|
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
---------
|
可見卵牍，引入了D-SACK果港，有這么幾個好處：
1）可以讓發(fā)送方知道，是發(fā)出去的包丟了糊昙，還是回來的ACK包丟了辛掠。
2）是不是自己的timeout太小了，導致重傳。
3）網(wǎng)絡上出現(xiàn)了先發(fā)的包后到的情況（又稱reordering）
4）網(wǎng)絡上是不是把我的數(shù)據(jù)包給復制了萝衩。
知道這些東西可以很好得幫助TCP了解網(wǎng)絡情況回挽，從而可以更好的做網(wǎng)絡上的流控。
Linux下的tcp_dsack參數(shù)用于開啟這個功能（Linux 2.4后默認打開）
好了猩谊，上篇就到這里結(jié)束了千劈。如果你覺得我寫得還比較淺顯易懂，那么牌捷，歡迎移步看下篇《TCP的那些事（下）》
