本文在個人技術博客同步發布，詳情可用力戳
亦可掃描屏幕右側二維碼關注個人公眾號，公眾號內有個人聯系方式，等你來撩...
前幾天發了一個朋友圈，發現暗戀已久的女生給我點了個贊，於是我當晚輾轉反側、徹夜未眠！想着妹子是不是對我有感覺呢？不然怎么會突然給我點贊呢？要不趁機表個白？
於是第二天我在心中模擬了多次表白的話語，連呼吸都反復練習。到了晚上，我撥通了妹子的微信語音，還沒等對方開口我就按捺不住內心的想法，開始自說自話，一陣狂亂的表達...足足五分鍾一氣呵成，一切都是那么自然！
可是在我說完之后卻半天都沒有等到妹子的回應...過了好一會兒才聽到對方的聲音：“喂！喂！我這邊信號不好，你剛剛在說啥我一句都沒聽到，我在跟我男朋友逛街呢...”。
我掛斷了電話，我也對我這次失敗的表白進行了深度的總結！原因就是因為我沒有學好TCP！
如果我懂TCP，那我在表白之前至少要先問一句“在嗎？”！先建立可靠的連接，確保連接正常才能開始表白！
如果我懂TCP，那我在我說話的過程中需要對方不斷的確認，這樣才能保證我說的每一句話對方都能聽到！這樣我才能表白成功！
所以一切都是因為我沒有學好TCP，於是我走進了圖書館...
我們先來看下TCP的定義：
TCP全稱為Transmission Control Protocol（傳輸控制協議），是一種面向連接的、可靠的、基於字節流的傳輸層通信協議。TCP是為了在不可靠的互聯網絡上提供可靠的端到端字節流而專門設計的一個傳輸協議。
這里面每一個字我們都認識，但是連在一塊就不是那么好理解了！那我們就提煉一些關鍵的詞，也就是我上面高亮的那些：面向連接、可靠、基於字節流、傳輸層、協議、端到端！理解了這些關鍵字也就理解了TCP的實現原理，那我們就來從這些關鍵字開始進行分析！
傳輸層
我們先講傳輸層，因為可以從比較高的層面去看TCP，我們先看下經典的OSI七層網絡參考模型：
當我們需要在網絡上進行數據交換的時候，就需要經過這么幾層。每一層都有相關落地的實現，我們今天要講的TCP就是傳輸層的一種落地實現。可能我們平時在說到傳輸層的時候自然而然的就想到的TCP，但是TCP只是傳輸層的一種實現，其他比較常見的傳輸層協議還有UDP等!
我知道干巴巴的文字對你來說太抽象，那我就抓個包來看看，讓這幾層更加具象！本文中所有的包都是通過postman發送請求，然后用wireShark來抓的！如果對這兩款軟件還不了解的盆友可以先去了解下哈，這里不過多說明。我們在postman中輸入www.17coding.info的域名，然后發送請求，wireshark就能抓到數據包了。
圖上已經標明每一層與抓到的數據包對應的關系了！咦！我們上面不是說的7層網絡參考模型么？為什么數據包只有5層呢？注意參考二字，7層模型是一個理論模型，實際的網絡中往往都把應用層、會話層、表示層統為應用層！
什么是協議？
說到協議，就是雙方共同遵守的一種約定！比如我寫的這篇文章里，你能夠看懂我寫的每一個字並明白我的意思，那就是因為我們都遵循了漢語的語法，這本身也就是一種協議。還有比如我們寫代碼就必須按照規定的語法進行編寫，這樣編譯器才能進行正確編譯。
在計算機網絡中也有很多協議，比如常見的應用層協議http、ftp、dns協議等等。常見的傳輸層協議有TCP、UDP等等...其實這些協議都是發送方和接收方都在遵循的一種規范。如果我們遵循了其規范，也能成為協議的實現者，比如自己寫一個web服務器處理用戶請求。甚至我們還能自己規定一套協議，供別人使用！
TCP頭部格式
我們前面說了協議的定義，那TCP協議肯定也有一定的規范咯！這樣通信雙方才能識別對方的數據報文，進行數據交換，我們先看下TCP的報文格式
TCP報文包含數據頭和數據體，頭部有5行的固定長度以及1行可變長度！圖上前面5行就是固定長度！固定長度的每一行占有4個字節（32位）。因此頭部固定長度就為5*4=20個字節！
到這里我們可以抓個包來看下加深印象，我們依然向www.17coding.info發送一個請求，然后看看其TCP部分的數據包
接下來那我們就一行一行的來分析TCP的頭部：
第一行：
1、源端口：發送方端口
2、目標端口：接收方端口
前面我們說到TCP是端到端的，這里就能很好的體現了！每個數據包中都有發送方和接收方的端口。這里每個端口占用2個字節（16位）。
第二行、第三行：
1、序號：tcp是面向字節流的，數據分塊在緩存存放及發送，序號用來標記某個數據包最開始的字節是整個數據的第多少個字節。
2、確認號：每次收到請求后，接收方都會回復發送方，告訴對方自己已經接收了多少字節，下一個數據包需要從第多少字節開始發送。這里的值一般等於接收到的序號+接收到的數據包數據部分長度。
這里的序號和確認號是保證TCP可靠特性所不可或缺的，我們后面會通過抓包來詳細分析！序號和確認號分別都占用了4個字節（32位）！
第四行：
1、數據偏移：這里叫頭部長度更為合適。前面說過TCP頭部長度有部分是可變的，所以需要標識數據包數據部分從哪里開始。這個值占用了4位。
2、保留：未使用，供擴展使用。這個值占了3位。
3、標志：標志一共有9個，每個標識占1位，共占9位。上面的抓包截圖就能看到這9個標識位！
3.1、NS：Nonce，與ECN顯式擁塞通知相關。
3.2、CWR：CWR 標志與后面的 ECE 標志都用於 IP 首部的 ECN 字段，ECE 標志為 1 時，則通知對方已將擁塞窗口縮小
3.3、ECE：ECN-Echo，若設置了該標識，則會通知對方，從對方到這邊的網絡有阻塞。
3.4、URG：Urgent，用於在發送方加塞。比如在下載文件的時候，下到一半了需要停止下載，就需要發送一個緊急的請求告訴對方停止發送數據。數據包不排隊。
3.5、ACK：Acknowledgment，標記為一個確認。
3.6、PSH：Push，與URG對應的，用於接收方加塞。
3.7、RST：Reset，表示出現嚴重差錯，可能需要重新創建TCP連接。如果我們打開某個網站一直沒刷出來，我們F5進行刷新，那之前的數據包就要拒絕。
3.8、SYN：用於同步，建立請求的時候用。在握手時候會帶這個標記！
3.9、FIN：通信結束，釋放連接的時候用。在揮手時候會帶這個標記！
4、窗口：不管是發送方還是接收方，都有對應的發送窗口和接收窗口。在通信之前，通信雙方會協商窗口的大小。發送方按照接收方的接收窗口設置自己的發送窗口，同時發送窗口還受擁塞窗口的限制，這個在擁塞控制部分會提到！在發送過程中窗口會根據接收方的處理能力調整。這個值對TCP的可靠傳輸及流量控制起了很大的作用！這個值占了16位。
第五行：
1、校驗和：用於校驗數據包是否完整或者被修改。這個值占了16位。
2、緊急指針：用來標記本報文段中緊急數據的指針，也就是指明了從數據包數據部分的頭部到指定位置的數據為緊急數據，只有在設置了標志位URG的時候才起作用。這個值占了16位。
第六行：
1、選項：選項里面也有些重要的數據，我們挑幾個講一下
1.1、MSS：MSS的全稱為Maximum segment size，雙方協商的每一個報文段所能承載的最大數據長度（不包括文段頭）。
1.2、WS：WS的全稱為Window scale，也叫窗口因子！是用來調整窗口大小的。前面我們說到過窗口大小的字段，那這個窗口因子又是做什么用的呢？早期的網絡帶寬、硬件配置都比較差，所以窗口大小最大只預留了16個bit，也就是最大能設置的值為65535。隨着硬件和網絡的發展，65535已經不能滿足。所以就增加了一個WS的選項來擴展！如果設置了WS，那實際的窗口大小就等於窗口大小乘以窗口因子。
1.3、SACK:SACK的全稱為Selective ACK，選擇性確認是建立在累計確認（后面講） 的基礎上的！只有收到失序的分組時才會可能會發送SACK，如果接收方接收到了后面的數據包，而發現前面的數據包丟失，則會通知發送方哪些報文段丟失，需要重發！
2、填充：這個字段是為了讓整個頭部為4個字節的倍數。java中也有很多類似的用法！
我們找到一個數據包，看看其詳細的頭部數據：
1、紅色部分顯示了TCP頭部的長度為32byte，以及選項部分為12byte。前面我們說了TCP首部固定長度為20byte，所以20+12=32。
2、黃線部分的窗口大小為259byte，窗口因子為256。所以實際的窗口大小為259*256=66304！
面向連接怎么理解
從我表白失敗的例子就能看到，我還未確保連接的正常就開始表白，導致我說完了對方卻因為信號不好沒有聽到。如果我事先確保連接正常，就不會出現這樣的情況了！我們前面說了TCP是面向連接的，那TCP是怎么面向連接的呢？
三次握手交代了什么？
沒錯，都是從握手開始！我們都知道，tcp建立連接需要經過三次握手，那每次握手都交代了什么呢？如果只進行兩次握手行不行？我們先看一個電話接通的場景：
A：你好，你能聽到嗎？
B：我能聽到，你能聽到嗎？
A：我也能聽到。
.......
在正式通話之前，為了確保通話的可靠，往往都需要經過上面的三次對話進行確認。那這三次對話是必須的嗎？每一次對話的必要性又是什么呢？
A：你好，你能聽到嗎？（讓B知道A能說話）
B：我能聽到，你能聽到嗎？（讓A知道B能聽到，且能說話）
A：我也能聽到。（讓B知道A能聽到）
.......
只有經過三次的對話，才能確認自己的聲音能被對方聽到且能聽到對方的聲音。這也才能開展后續的對話。這里我們就不得不祭出經典的三次握手圖了：
我們分析三次握手過程及每次握手后的狀態如下：
1、A主機發送標識SYN=1(SYN表示A請求跟B建立連接，前面在講TCP頭部時候有說到過),序號Seq=x，第一次握手請求發送后A的狀態為SYN_SENT,B在接收到請求后狀態由LISTEN變為SYN_RCVD！
2、B主機收到連接請求后向A主機發送標識SYN=1,ACK=1(SYN表示B請求跟A建立連接，ACK表示對A的連接請求進行應答),序號Seq=y，確認號Ack=(x+1)，A接收到B的確認后，狀態變為ESTABLISHED,B的狀態依然為SYN_RCVD！
3、主機A收到后檢查Ack是否正確，若正確，則發送標識ACK=1(表示對B的連接請求進行應答)，序號Seq=(x+1),確認號Ack=(y+1)。B接收到A的確認后，A和B的狀態都變為ESTABLISHED！
這里我們要注意的幾點是：
1、圖中的發送請求中中括號里面的SYN、ACK就是前面說TCP頭部中的那幾個標志位！而Seq和Ack分別代表序號和確認號。
2、接收方在接收到發送方發送的Seq后，應答一個Ack，Ack的值等於Seq+1，表示已要發送方開始發送Seq+1位置的數據。
2、B在接收到了A的連接請求后回復中同時發送了SYN、ACK兩個標識位，將建立連接的請求和對A的應答在同一個包中發送了，這也是為什么只需要三次握手，就能建立連接。
我們依然向www.17coding.info發送請求，下面為三次握手的包：
在info那一欄，我們很明顯的能看到發送的數據包頭部有我們上面說到的那些標志位，還有Seq、Ack等頭部信息，還有Win、MSS等頭部選項數據！因此三次握手不僅僅是單純建立連接，還會協商一些參數！
當我鼠標選擇某一行時，如果這個數據包包含了對某個數據包的確認（也就是有ACK的標記），就能在對應的數據包的No列上面看到一個小勾勾，比如上面圖中我鼠標選擇的是第三次握手的數據包，在第二次握手的數據包前面就有個小勾勾。
為什么握手只需要三次而揮手需要四次？
通過三次握手，雙方就建立了一個可靠的連接，就能進行數據的傳輸了！當數據傳輸完成，就得將連接關閉，因為連接也是一種資源！連接的關閉需要經過四次揮手！
為什么握手可以三次完成，但是揮手卻需要四次呢？我偏要三次行不行？其實也沒啥不可以的！比如下面的對話場景：
A：我說完了，你說完就掛電話吧！
B：好嘞，我也說完了，可以掛電話了！
A：好嘞，拜拜。
掛斷......
這樣三次對話就可以實現揮手了，但是在實際的網絡中，當我發出一個請求的時候，可能服務器的響應體比較大，需要較長時間的傳輸！所以當客戶端主動發起斷開請求的時候，服務器先回應一個確認，等所有數據傳輸完畢后再發送服務器斷開的請求。
A：我說完了，你說完就掛電話吧！
B：好嘞...
B：......
B：我也說完了，可以掛電話了
A：好嘞，拜拜
掛斷......
所以大部分情況下都需要進行四次揮手！但是，在我個人的抓包實踐中，也會有三次揮手就能完成斷開連接的情況。
這里我們又不得不祭出經典的四次揮手圖了：
我們分析四次揮手過程及每次揮手后的狀態如下：
1、主機A發送標識FIN=1(FIN表示A請求關閉連接)用來關閉A到B的數據傳輸。此時A的狀態為FIN_WAIT_1！
2、主機B收到關閉請求后向A發送ACK(ACK表示應答A的關閉連接請求)，A不再向B發送數據。此時A的狀態為FIN_WAIT_2，B為CLOSE_WAIT！
3、主機B發送標識FIN=1用來關閉B到A的數據傳輸。此時A的狀態為TIME_WAIT，B為LAST_ACK！
4、主機A收到關閉請求后向B發送ACK,此時B不再向A發送數據。此時A、B都關閉了，狀態變為CLOSED。
在圖中我們能看到，A的TIME_WAIT狀態會持續2MSL再變成CLOSED，MSL（Maximum Segment Lifetime）的中文可以譯為“報文最大生存時間”！他是任何報文在網絡上存在的最長時間，超過這個時間報文將被丟棄。那TIME_WAIT維持2MSL的作用是什么呢？
1、第4次揮手的時候主機A發送ACK到主機B，如果發送完成后就直接就關閉連接，那如果由於網絡原因B沒有收到ACK，那B就沒法關閉連接了！因此A在回復確認后，還需要等待，萬一B沒有收到應答還會繼續發送FIN的請求。
2、如果不等待2MSL，那客戶端的端口可能會被重用，如果再次用這個端口建立與服務器的連接，那前后兩個使用相同四元組的的連接之間會形成干擾！
我們看上面向www.17coding.info發送請求的揮手數據包：
可能大家在抓包的時候不能立馬看到四次揮手的數據包！那是因為在HTTP1.1及之后，默認都開啟了長連接！也就是在一次請求之后，建立的連接並不會立馬關閉，而是供后續的其他請求繼續使用，以減少每次重新建立連接的資源消耗！如果想發出請求后立馬能抓到四次揮手的數據包，可以設置Http的頭部Connection:close。這樣每次發送請求都能看到完整的三次握手四次揮手的過程啦！
TCP是怎么保證可靠傳輸的？
保證傳輸的可靠我們前面已經說到了面向連接，建立連接是保證數據傳輸的第一步。那在連接建立之后的數據傳輸怎么保證可靠呢？
我們再次回到我們打電話的場景，一般在對話的過程中，都是得雙方都有互動，給與對方回應。而不是一個人一個勁的說而另一方沒有任何回應！比如下面場景：
A：跟你講哦，我上周網上認識了一個妹子
B：嚯，牛逼啊！
A：然后我昨天約出來見面了
B：666啊！然后呢？
A：然后我們@#￥%……&
B：卧槽，你剛剛說啥我沒聽清，你再說一遍？...
這樣的確認和應答就確保了雙方的通信能夠完整可靠。TCP也采用了這種y應答和確認重傳的機制，保證在不可靠的網絡上實現可靠的傳輸。只要我沒有收到確認，我就認為沒有發送成功，就會重發。
停止等待協議
停止等待協議就是每次給對方發送數據包后，需要等待對方的回應然后再發送下一個數據包！停止等待協議會出現如下幾種情況：
1、無差錯情況：A發送M1包到B，B收到后會給A一個確認，當A收到B的確認后再發送包M2。
2、超時重傳：A發送M1包到B，如果發送過程中包丟失，A會重新發送。A等待重發的時間是比一個報文的往返時間（RTT）稍微多一點。
3、確認丟失：如果B在給A發送確認的時候丟失，A會重新發送M1包給B，由於B已經處理過M1的數據包所以B會丟棄報文，然后重傳確認M1給A。
4、確認遲到：如果A發送數據包M1給B，B回復確認的時候延遲了。這時A又會重新發送包M1給B，B收到后丟棄數據包，然后重傳確認M1給A。這時A會收到多次確認，當第二次收到遲到的確認后A也會丟棄該確認。
我們從上面能看到，停止等待協議每次都是等到收到確認后再發下一個數據包。只要我沒收到你給我的確認，我就認為你沒有收到我發的數據包，我就會進行重發！這樣雖然可靠，但是會導致信道利用率較低！
流水線傳輸
流水線傳輸就是每次發送多組數據包，不必每次發完一組就停下來等待對方的確認。由於信道上一直有數據不間斷的傳輸，因此可以獲得較高的信道利用率！
流水線傳輸如何保證可靠的呢？需要發送方維持發送窗口，假如發送窗口是5，那5個數據包會同時發送，然后等確認！如果有收到接收方的確認，窗口就會滑動，進行第6個數據包的發送。
如果都是單個確認，可能效率會比較低，所以有了累計確認！也就是說假如發送方發送了數據包1、2、3、4，接收方只需要回復對數據包4的確認，那表示1234數據包都已經收到了，就可以進行第五個數據包的發送了！假如發送了數據包1、2、3、4，其中第三個數據包丟失，那該怎么確認呢？TCP只會回復對數據包2的確認，並且對數據包4進行選擇性確認（TCP頭部選項講到過的SACK），這樣發送方就知道數據包4已經成功發送，只需要重發數據包3。
繼續前面抓包的例子，接收方並不是對每個數據包都進行確認，而是對多個數據包進行累計確認：
這里我們能看到服務器發送多個數據包后，客戶端才進行了一次確認。
流量控制和擁塞控制
通過前面我們知道了，通過建立可靠的連接和確認機制，保證了TCP的連接的可靠！但是每個人使用的計算機的處理能力都是不一樣的，我發送太快了對方處理不過來怎么辦呢？通信雙方怎么去協調發送和接收數據的頻率呢？
以字節為單位的滑動窗口技術
在介紹TCP頭部的時候，我們已經提到過滑動窗口，並且介紹了相關的控制參數Win！也說到了接收窗口和發送窗口！那他們的關系是怎么樣的呢？
假設現在A需要傳輸數據給B，B就先要告訴A自己的接收窗口有多大。A根據B的接收窗口設置自己的發送窗口！A的發送窗口時不能大於B的接收窗口的！在開始傳輸數據之前，初始的窗口設置如下圖：
如上圖我們能否看到，B的接收窗口設置為10個字節，那A的發送窗口設置不能超過10個字節！如果開始傳送數據，A會將數據封裝成多個數據包進行傳輸，如下圖
在沒有收到B的確認之前，A的窗口不會滑動，也就是說最多能發10個字節的數據。如果B接受到數據且回復確認給了A，那A的窗口則進行滑動，如下圖：
這樣，A又可以進行第11、12個字節的發送啦！如果B的處理能力變弱了，也可以通知A將發送窗口調小！這樣也也就很好的協調了雙方的接收和發送能力！這也就很好的實現了TCP的可靠傳輸和流量控制！
上面的數據包繼續發送，如果在發送過程中，3、4、5這三個字節組成的數據包丟了，但是后面的數據卻收到了，這時候A的發送窗口會移動么？
如果是這種情況，A的發送窗口是不會移動的。B在接收到后面數據包的時候回復給A的Ack會設置為3，且在選項中設置一個SACK（在TCP頭部選項里面有描述），告訴A哪部分數據收到了，而哪部分數據需要進行重發！
擁塞控制
利用滑動窗口技術，可以很好的協調雙方的收發能力。但是，網絡狀況是非常復雜的，且在同一個網絡上可能有千千萬萬個發送方和接收方！如果大家都需要傳輸數據都需要占用網絡，不做好控制措施，就會導致整個網絡會堵塞甚至癱瘓。
如果我要從深圳開車去廣州，我就會走高速。如果只有我一個人開車，那肯定能暢通無阻！但是高速公路不是我家的，大家都能通行！所以一到了節假日，大家都蜂擁而上，而高速的承運能力不會因為節假日而調整！這時候往往就需要交通管制、限流等措施去舒緩交通！
1、綠線代表理想狀況下，如果高速公路的吞吐量為100！當需要通過的車輛不超過100時，所有車輛都能順利通過！當需要通過的車輛超過100，那每次通行的車輛為100，能提供的負載比較穩定。
2、紅色代表沒有任何交通管制情況下，如果高速公路的吞吐量為100！當需要通過的車輛不超過100時，會出現輕微的塞車現象！但是隨着車輛的增多，就會出現嚴重的阻塞，甚至癱瘓！
3、藍色代表在交通管制下，如果高速公路的吞吐量為100！當需要通過的車輛不超過100時，會出現輕微的塞車現象！但是隨着車輛的增多，交通一直保存較高的負載，不會出現癱瘓的情況！
網絡就好比高速公路，傳輸的數據包就好比要通過的車輛，而TCP則就更像一個交警，維護着數據傳輸的秩序！那TCP是怎么做的呢？
慢開始與擁塞避免
發送方維持一個cwnd（擁塞窗口，注意這里的擁塞窗口不能大於前面說到的發送窗口！），剛開始擁塞窗口設置為1。如果發現這個包沒有丟失，則調整擁塞窗口為2！如果又沒有丟包，則調整擁塞窗口為4！這樣每次以2倍的速度一直增長到16！然后17、18、19這樣一個一個的增加，直到大小與發送窗口一致。這就是所謂的慢開始和擁塞避免，16就是慢開始門限......
有沒有得寸進尺的感覺！
我就蹭蹭不進去...
...
我就進去不動...
...
我就..
如果在發送的過程中發現有丟包現象，則會調整擁塞窗口大小為1，並且設置新的慢開始門限為出現擁塞時的二分之一，也就是說當擁塞窗口為24的時候出現丟包現象，那新的慢開始門限就調整為12！如果理解了上面的文字描述，下面的圖就不難理解了！
快重傳
前面說過累計確認，還說到了選擇性確認。這個就跟快重傳有關！接收方如果發現丟包，不會等到累計確認，就通知發送方三個重復的確認通知對方重新發送丟失的包。當接收方收到三個重復的確認，則意識到數據包丟失，進行重傳！
通過下圖能看到，當出現丟包的情況，接收方的Ack都是等於50，而SACK分別對60~89之間的字節都進行了選擇性的確認！這時候發送方也就知道50~59這部分數據丟失而進行重傳！
快恢復
如果一旦發生丟包，擁塞窗口就變成1，這種方式也太傻了吧。如果能有個快速恢復的機制就好了！TCP就使用了快恢復機制！當出現丟包時，不會再次進行慢開始，而是直接轉入擁塞避免！也就是從新的慢開始門限進行加法增加！
看完全文，我們再回到TCP的定義，你是不是又能有更多的理解了呢？
TCP全稱為Transmission Control Protocol（傳輸控制協議），是一種面向連接的、可靠的、基於字節流的傳輸層通信協議。TCP是為了在不可靠的互聯網絡上提供可靠的端到端字節流而專門設計的一個傳輸協議。