目錄web
抓包過程以及TCP包首部算法
可靠傳輸緩存
窗口概念引出微信
接收窗口 rwnd 和發送窗口 cwnd網絡
流量控制數據結構
舉例來講明具體TCP流量控制過程curl
擁塞控制tcp
慢開始和擁塞避免算法編輯器
快重傳和快恢復算法flex
流量控制和擁塞控制的區別
抓包過程以及TCP包首部
使用了 Wireshark 進行抓包，用兩個最經常使用的 curl 和 ping 命令來演示抓包狀況，開啓抓包。
## 先訪問我本身的網站首頁 curl https://zengzhiqin.kuaizhan.com ## 再查看我本身網站的地址 ping https://zengzhiqin.kuaizhan.com
Wireshark根據 ping 命令獲得的地址進行條件過濾，獲得上面兩個命令所獲得的包，主要有 TCP（https基於tcp協議）協議和 ICMP（ping命令是基於 ICMP 協議）協議的包，以下圖所示：
可靠傳輸
TCP 實現可靠傳輸的四種實現方法：
-
校驗 -
序號 -
確認 -
重傳
第1，2兩種機制，在我公衆號另一篇有詳細講解，這裏我主要講述第3，4種。
可靠傳輸目的:就是要讓發送方發送的全部數據，接收方都能完整，按序收到。
正如宮本武藏的口頭禪「排好隊，一個一個來」同樣，使用最笨的方法來解決最難的問題，既然你要可靠那麼就一個一個確認，只要你沒告訴我你收到了，那麼我就一直重發。
可靠傳輸的工做原理：中止等待協議
我分爲了四張圖，豎線表明的是時間軸，RTT表明數據包發過去而後確認包發回來的往返時間，分別是」無差錯你好我好你們好的狀況下「，」發送超時或者失敗「狀況下，」確認超時「和」確認丟失「的狀況下來分析的。經過這種確認重傳機制，TCP就能夠實現可靠傳輸，也就是第3，4點的實現方式。須要知道的一點是，重傳這個動做是發送方自發行爲，並不須要接收方通知它進行重傳。
窗口概念引出
上面的方法，確實不錯哈，用了最簡單的方法解決了可靠傳輸這個問題，但是網絡時時刻刻那麼忙，我等你一來一回的確認宮本武藏一個大招跳出去估計是一節一節的落地了，黃花菜都涼了。
上述中止等待協議最大的問題是信道利用率過低了。
RTT時間是由網絡情況決定拯救不了，T2通常也是固定的，由公式可看出，想要提升信道利用率只能從 T1 下手。
發送方能夠連續發送多個包，不用每次都停下來等待確認再繼續發，將上面這些的連續發送的包用一個窗口來包含起來即TCP窗口的由來，以下圖：
既然你發送方爲了避免一個一個包發能夠有窗口技術，那麼我接收方確定也不甘落後得學起來啊，即不進行一個一個確認，轉而累積確認。
接收窗口 rwnd 和發送窗口 cwnd
此處涉及到二個窗口：
-
接收窗口receiver window(即rwnd)，是 接收方根據本身的承受能力設置的接收緩存值大小，反映了接收方的接收能力，來作流量控制。 -
擁塞窗口congestion window(即cwnd)，是 發送方根據網絡擁塞程度設置的網絡窗口值，發送窗口=min(rwnd，cwnd)便是接收窗口和擁塞窗口的最小值，來作擁塞控制。
窗口數據結構以下：
其實看似這麼高深的東西，一步步想過來竟是如此簡單，感嘆一句」啊，聰明的人類「（調皮一下哈哈哈）。
流量控制
上面說到了經過窗口能夠增大信道的利用率，而後就是窗口的大小怎麼設置，設置多大，窗口還能夠用來作什麼？
發送方若是發的過快，那麼接收方就會來不及接受，就會丟包，這確定不行啊，萬一別人給我發了不少紅包丟一個我都不想噠~
流量控制目的：讓發送方根據網絡情況動態的調整發送頻率，好讓接收方來得及接收。
TCP利用滑動窗口機制實現流量控制。發送方的發送窗口是動態變化的，取決於接收方返回的報文段的窗口大小，多是數據報文段也多是確認報文，由於TCP包首部都有窗口信息，仍是這張圖再看一下窗口數據：
舉例來講明具體TCP流量控制過程
A主機向B主機發送數據，創建鏈接的時候 B 告訴 A：」大哥，個人rwnd=400byte「，假設每一個報文段都是100byte，初始序號是1，三次流量控制溝經過程以下：
這張圖，最後 rwnd=0 了，這種狀況持續到接收端騰出了新的接收緩存以後 B會主動給 A發送他的新的 rwnd，0窗口通知的時候 A 就會一直等待接收方新的 rwnd 通知，爲了防止新的 rwnd 丟失了，以前的文章不少都分析過這種狀況，爲了解決包超時收不到確認設置了等待一段時間就重傳，四次揮手過程設置了最後須要等待 2MSL 時間發送端才關閉，這些時間都是經過設置計時器來計時，都是爲了解決包丟失了形成死鎖。一樣這裏爲了解決新的 rwnd 丟失了形成 A 死鎖發送端只要收到了0窗口通知就會啓動計時器，若時間到了就會從新發送一個0窗口探測報文，接收方再回復如今的接收窗口。
擁塞控制
我家小區網絡最好的時候是晚上3-6點，上午10-12點，下午3-5點，這些時間段我玩王者最暢快，晚上8-11點網絡高峯時段每次卡一下回過神我就站在了泉水（真的好開心）。
試想一下本來網絡就很差，而後你還一次性向網絡倒那麼多數據包，你們都別過去了都超時，而後超時時間到了又都重發，惡性循環下去使得本來就不富裕的網絡更加雪上加霜，所以 TCP 你要本身學聰明，進行擁塞控制。擁塞控制的目的就是防止過多的數據注入到網絡中，網絡堵塞使得包一直到不了接收端。
擁塞控制算法有四種：
-
慢開始 -
擁塞避免 -
快重傳 -
快恢復
慢開始和擁塞避免算法
一個傳輸輪次指的是發送了一批報文段而且收到了確認的時間 RTT。
慢開始是指數增加，一直試探網絡情況若是健康就一直指數增加。到了ssthresh值的時候，這是慢開始輪限值，開始線性增加，一直增加到網絡擁塞的話，跳崖式下降一晚上回到解放前，從1開始，將新的ssthresh值調低爲原來擁塞時候的一半又開始指數增加，就這樣動態的變化。
快重傳和快恢復算法
從圖能夠看到這個算法前面和慢開始擁塞避免算法是一致的，主要是調整了跳崖式下降發送速率這個地方，這樣從0開始效率過低了，若是是男女友間在發送微信豈不是被折磨的心癢癢。
擁塞窗口cwnd每次指數增加一次都是在收到了確認報文的狀況下增加的，好比A發送1，23，4，5，6這些報文段，2丟失了，1345都收到了那麼每次345收到都會給A發送確認1收到了的確認報文，讓他發2（這個地方上一篇有提到），這種算法就是在2的超時計時器到期以前收到了三個確認以後就立刻重傳2，接收方都催着要了哥，後面三個確認包都到了說明網絡很好的嘛就是你迷路了，所以進行快速重傳仍是將新的ssthresh值調低爲原來擁塞時候的一半又開始指數增加，如今通常是用這種，上面那種方法因爲效率過低了被淘汰了。
流量控制和擁塞控制的區別
流量控制是點到點的問題，一對一，若是接收方的數據來不及接收那麼就能直接找到發送方這個罪魁禍首，主要是由於接收方來不及接受發送方的數據；
擁塞控制是多對一，一個接收方 面對多個發送方出現了網絡擁堵，接收方找不到具體的發送方，主要是由於網絡發生了堵塞發送方數據遲遲到不了接收方。
簡單理解，擁塞控制是路上堵車，流量控制是停車場停車車位不夠。
這篇內容陸陸續續寫了好幾天了，感受概念性的東西不少，我已經儘可能再用聊天式的輕鬆語氣來寫了。北京今天下雨了，五道口兩旁的樹木長得鬱鬱蔥蔥，擡頭看見樹葉將天空撕成了碎片，耳機裏一直在循環毛不易低沉性感聲線唱着的」一路山程「，我就這樣撐着傘走在這個都市的心臟上，一路憧憬着將來。
感謝朋友們的觀看，有收穫的朋友點個在看鼓勵一下吧，謝謝~
公衆號下期預告：應用層的那些玩意兒，也是離咱們最近的一層。
往期精彩：
抓包分析TCP三次握手四次揮手全過程，教你觀看「多包運動」的正確姿式
抓包分析以太網幀和IP數據包，頭部那麼多東東用來幹啥的，掃盲篇
本文分享自微信公衆號 - 全棧成長之路（shanyue-road）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。