我們前面說到玄奘西行，要出網關，既然出了網關，那就是在公網上傳輸資料，公網往往是不可靠的，因而需要很多的機制去保證傳輸的可靠性，這里面需要恒心，也即各種重傳的策略，還需要有智慧，也就是說，這里面包含著大量的演算法，
如何做個靠譜的人？
TCP 想成為一個成熟穩重的人，成為一個靠譜的人，那一個人怎么樣才算靠譜呢？咱們作業中經常就有這樣的場景，比如你交代給下屬一個事情以后，下屬到底能不能做到，做到什么程度，什么時候能夠交付，往往就會有應答，有回復，這樣，處理事情的程序中，一旦有例外，你也可以盡快知道，而不是交代完之后就石沉大海，過了一個月再問，他說，啊我不記得了，
對應到網路協議上，就是客戶端每發送的一個包，服務器端都應該有個回復，如果服務器端超過一定的時間沒有回復，客戶端就會重新發送這個包，直到有回復，
這個發送應答的程序是什么樣呢？可以是上一個收到了應答，再發送下一個，這種模式有點像兩個人直接打電話，你一句，我一句，但是這種方式的缺點是效率比較低，如果一方在電話那頭處理的時間比較長，這一頭就要干等著，雙方都沒辦法干其他事情，咱們在日常作業中也不是這樣的，不能你交代你的下屬辦一件事情，就一直打著電話看著他做，而是應該他按照你的安排，先將事情記錄下來，辦完一件回復一件，在他辦事情的程序中，你還可以同時交代新的事情，這樣雙方就并行了，
如果使?這種模式，其實需要你和你的下屬就不能靠腦?了，?是要都準備?個本?，你每交代下屬?個事情，雙方的本子都要記錄?下，
當你的下屬做完?件事情，就回復你，做完了，你就在你的本?上將這個事情劃去，同時你的本?上每件事情都有時限，如果超過了時限下屬還沒有回復，你就要主動重新交代?下：上次那件事情，你還沒回復我，咋樣啦？
既然多件事情可以一起處理，那就需要給每個事情編個號，防止弄錯了，例如，程式員平時看任務的時候，都會看 JIRA 的 ID，而不是每次都要描述一下具體的事情，在大部分情況下，對于事情的處理是按照順序來的，先來的先處理，這就給應答和匯報作業帶來了方便，等開周會的時候，每個程式員都可以將 JIRA ID 的串列拉出來，說以上的都做完了，?不??個個說，
如何實作一個靠譜的協議？
TCP 協議使用的也是同樣的模式，為了保證順序性，每一個包都有一個 ID，在建立連接的時候，會商定起始的 ID 是什么，然后按照 ID 一個個發送，為了保證不丟包，對于發送的包都要進行應答，但是這個應答也不是一個一個來的，而是會應答某個之前的 ID，表示都收到了，這種模式稱為累計確認或者累計應答（cumulative acknowledgment），
為了記錄所有發送的包和接收的包，TCP 也需要發送端和接收端分別都有快取來保存這些記錄，發送端的快取里是按照包的 ID 一個個排列，根據處理的情況分成四個部分，
第一部分：發送了并且已經確認的，這部分就是你交代下屬的，并且也做完了的，應該劃掉的，
第二部分：發送了并且尚未確認的，這部分是你交代下屬的，但是還沒做完的，需要等待做完的回復之后，才能劃掉，
第三部分：沒有發送，但是已經等待發送的，這部分是你還沒有交代給下屬，但是馬上就要交代的，
第四部分：沒有發送，并且暫時還不會發送的，這部分是你還沒有交代給下屬，而且暫時還不會交代給下屬的，
這里面為什么要區分第三部分和第四部分呢？沒交代的，一下子全交代了不就完了嗎？
這就是我們上一節提到的十個詞口訣里的“流量控制，把握分寸”，作為專案管理人員，你應該根據以往的作業情況和這個員工反饋的能力、抗壓力等，先在心中估測一下，這個人一天能做多少作業，如果作業布置少了，就會不飽和；如果作業布置多了，他就會做不完；如果你使勁逼迫，人家可能就要辭職了，
到底一個員工能夠同時處理多少事情呢？在 TCP 里，接收端會給發送端報一個視窗的大小，叫 Advertised window，這個視窗的大小應該等于上面的第二部分加上第三部分，就是已經交代了沒做完的加上馬上要交代的，超過這個視窗的，接收端做不過來，就不能發送了，
于是，發送端需要保持下面的資料結構，
- LastByteAcked：第一部分和第二部分的分界線
- LastByteSent：第二部分和第三部分的分界線
- LastByteAcked + AdvertisedWindow：第三部分和第四部分的分界線
對于接收端來講，它的快取里記錄的內容要簡單一些，
第一部分：接受并且確認過的，也就是我領導交代給我，并且我做完的，
第二部分：還沒接收，但是馬上就能接收的，也即是我自己的能夠接受的最大作業量，
第三部分：還沒接收，也沒法接收的，也即超過作業量的部分，實在做不完，
對應的資料結構就像這樣，
- MaxRcvBuffer：最大快取的量；
- LastByteRead 之后是已經接收了，但是還沒被應用層讀取的；
- NextByteExpected 是第一部分和第二部分的分界線，
第二部分的視窗有多大呢？
NextByteExpected 和 LastByteRead 的差其實是還沒被應用層讀取的部分占用掉的 MaxRcvBuffer 的量，我們定義為 A，
AdvertisedWindow 其實是 MaxRcvBuffer 減去 A，
也就是：AdvertisedWindow=MaxRcvBuffer-((NextByteExpected-1)-LastByteRead)，
那第二部分和第三部分的分界線在哪里呢？NextByteExpected 加 AdvertisedWindow 就是第二部分和第三部分的分界線，其實也就是 LastByteRead 加上 MaxRcvBuffer，
其中第二部分里面，由于受到的包可能不是順序的，會出現空檔，只有和第一部分連續的，可以馬上進行回復，中間空著的部分需要等待，哪怕后面的已經來了，
順序問題與丟包問題
接下來我們結合一個例子來看，
還是剛才的圖，在發送端來看，1、2、3 已經發送并確認；4、5、6、7、8、9 都是發送了還沒確認；10、11、12 是還沒發出的；13、14、15 是接收方沒有空間，不準備發的，
在接收端來看，1、2、3、4、5 是已經完成 ACK，但是沒讀取的；6、7 是等待接收的；8、9 是已經接收，但是沒有 ACK 的，
發送端和接收端當前的狀態如下：
- 1、2、3 沒有問題，雙方達成了一致，
- 4、5 接收方說 ACK 了，但是發送方還沒收到，有可能丟了，有可能在路上，
- 6、7、8、9 肯定都發了，但是 8、9 已經到了，但是 6、7 沒到，出現了亂序，快取著但是沒辦法 ACK，
根據這個例子，我們可以知道，順序問題和丟包問題都有可能發生，所以我們先來看確認與重發的機制，
假設 4 的確認到了，不幸的是，5 的 ACK 丟了，6、7 的資料包丟了，這該怎么辦呢？
一種方法就是超時重試，也即對每一個發送了，但是沒有 ACK 的包，都有設一個定時器，超過了一定的時間，就重新嘗試，但是這個超時的時間如何評估呢？這個時間不宜過短，時間必須大于往返時間 RTT，否則會引起不必要的重傳，也不宜過長，這樣超時時間變長，訪問就變慢了，
估計往返時間，需要 TCP 通過采樣 RTT 的時間，然后進行加權平均，算出一個值，而且這個值還是要不斷變化的，因為網路狀況不斷地變化，除了采樣 RTT，還要采樣 RTT 的波動范圍，計算出一個估計的超時時間，由于重傳時間是不斷變化的，我們稱為自適應重傳演算法（Adaptive Retransmission Algorithm），
如果過一段時間，5、6、7 都超時了，就會重新發送，接收方發現 5 原來接收過，于是丟棄 5；6 收到了，發送 ACK，要求下一個是 7，7 不幸又丟了，當 7 再次超時的時候，有需要重傳的時候，TCP 的策略是超時間隔加倍，每當遇到一次超時重傳的時候，都會將下一次超時時間間隔設為先前值的兩倍，兩次超時，就說明網路環境差，不宜頻繁反復發送，
超時觸發重傳存在的問題是，超時周期可能相對較長，那是不是可以有更快的方式呢？
有一個可以快速重傳的機制，當接收方收到一個序號大于下一個所期望的報文段時，就會檢測到資料流中的一個間隔，于是它就會發送冗余的 ACK，仍然 ACK 的是期望接收的報文段，而當客戶端收到三個冗余的 ACK 后，就會在定時器過期之前，重傳丟失的報文段，
例如，接收方發現 6 收到了，8 也收到了，但是 7 還沒來，那肯定是丟了，于是發送 6 的 ACK，要求下一個是 7，接下來，收到后續的包，仍然發送 6 的 ACK，要求下一個是 7，當客戶端收到 3 個重復 ACK，就會發現 7 的確丟了，不等超時，馬上重發，
還有一種方式稱為 Selective Acknowledgment （SACK），這種方式需要在 TCP 頭里加一個 SACK 的東西，可以將快取的地圖發送給發送方，例如可以發送 ACK6、SACK8、SACK9，有了地圖，發送方一下子就能看出來是 7 丟了，
流量控制問題
我們再來看流量控制機制，在對于包的確認中，同時會攜帶一個視窗的大小，
我們先假設視窗不變的情況，視窗始終為 9，4 的確認來的時候，會右移一個，這個時候第 13 個包也可以發送了，
這個時候，假設發送端發送過猛，會將第三部分的 10、11、12、13 全部發送完畢，之后就停止發送了，未發送可發送部分為 0，
當對于包 5 的確認到達的時候，在客戶端相當于視窗再滑動了一格，這個時候，才可以有更多的包可以發送了，例如第 14 個包才可以發送，
如果接收方實在處理的太慢，導致快取中沒有空間了，可以通過確認資訊修改視窗的大小，甚至可以設定為 0，則發送方將暫時停止發送，
我們假設一個極端情況，接收端的應用一直不讀取快取中的資料，當資料包 6 確認后，視窗大小就不能再是 9 了，就要縮小一個變為 8，
這個新的視窗 8 通過 6 的確認訊息到達發送端的時候，你會發現視窗沒有平行右移，而是僅僅左面的邊右移了，視窗的大小從 9 改成了 8，
如果接收端還是一直不處理資料，則隨著確認的包越來越多，視窗越來越小，直到為 0，
當這個視窗通過包 14 的確認到達發送端的時候，發送端的視窗也調整為 0，停止發送，
如果這樣的話，發送方會定時發送視窗探測資料包，看是否有機會調整視窗的大小，當接收方比較慢的時候，要防止低能視窗綜合征，別空出一個位元組來就趕快告訴發送方，然后馬上又填滿了，可以當視窗太小的時候，不更新視窗，直到達到一定大小，或者緩沖區一半為空，才更新視窗，
這就是我們常說的流量控制，
擁塞控制問題
最后，我們看一下擁塞控制的問題，也是通過視窗的大小來控制的，前面的滑動視窗 rwnd 是怕發送方把接收方快取塞滿，而擁塞視窗 cwnd，是怕把網路塞滿，
這里有一個公式 LastByteSent - LastByteAcked <= min {cwnd, rwnd} ，是擁塞視窗和滑動視窗共同控制發送的速度，
那發送方怎么判斷網路是不是慢呢？這其實是個挺難的事情，因為對于 TCP 協議來講，他壓根不知道整個網路路徑都會經歷什么，對他來講就是一個黑盒，TCP 發送包常被比喻為往一個水管里面灌水，而 TCP 的擁塞控制就是在不堵塞，不丟包的情況下，盡量發揮帶寬，
水管有粗細，網路有帶寬，也即每秒鐘能夠發送多少資料；水管有長度，端到端有時延，在理想狀態下，水管里面水的量 = 水管粗細 x 水管長度，對于到網路上，通道的容量 = 帶寬 × 往返延遲，
如果我們設定發送視窗，使得發送但未確認的包為為通道的容量，就能夠撐滿整個管道，
如圖所示，假設往返時間為 8s，去 4s，回 4s，每秒發送一個包，每個包 1024byte，已經過去了 8s，則 8 個包都發出去了，其中前 4 個包已經到達接收端，但是 ACK 還沒有回傳，不能算發送成功，5-8 后四個包還在路上，還沒被接收，這個時候，整個管道正好撐滿，在發送端，已發送未確認的為 8 個包，正好等于帶寬，也即每秒發送 1 個包，乘以來回時間 8s，
如果我們在這個基礎上再調大視窗，使得單位時間內更多的包可以發送，會出現什么現象呢？
我們來想，原來發送一個包，從一端到達另一端，假設一共經過四個設備，每個設備處理一個包時間耗費 1s，所以到達另一端需要耗費 4s，如果發送的更加快速，則單位時間內，會有更多的包到達這些中間設備，這些設備還是只能每秒處理一個包的話，多出來的包就會被丟棄，這是我們不想看到的，
這個時候，我們可以想其他的辦法，例如這個四個設備本來每秒處理一個包，但是我們在這些設備上加快取，處理不過來的在佇列里面排著，這樣包就不會丟失，但是缺點是會增加時延，這個快取的包，4s 肯定到達不了接收端了，如果時延達到一定程度，就會超時重傳，也是我們不想看到的，
于是 TCP 的擁塞控制主要來避免兩種現象，包丟失和超時重傳，一旦出現了這些現象就說明，發送速度太快了，要慢一點，但是一開始我怎么知道速度多快呢，我怎么知道應該把視窗調整到多大呢？
如果我們通過漏斗往瓶子里灌水，我們就知道，不能一桶水一下子倒進去，肯定會濺出來，要一開始慢慢的倒，然后發現總能夠倒進去，就可以越倒越快，這叫作慢啟動，
一條 TCP 連接開始，cwnd 設定為一個報文段，一次只能發送一個；當收到這一個確認的時候，cwnd 加一，于是一次能夠發送兩個；當這兩個的確認到來的時候，每個確認 cwnd 加一，兩個確認 cwnd 加二，于是一次能夠發送四個；當這四個的確認到來的時候，每個確認 cwnd 加一，四個確認 cwnd 加四，于是一次能夠發送八個，可以看出這是指數性的增長，
漲到什么時候是個頭呢？有一個值 ssthresh 為 65535 個位元組，當超過這個值的時候，就要小心一點了，不能倒這么快了，可能快滿了，再慢下來，
每收到一個確認后，cwnd 增加 1/cwnd，我們接著上面的程序來，一次發送八個，當八個確認到來的時候，每個確認增加 1/8，八個確認一共 cwnd 增加 1，于是一次能夠發送九個，變成了線性增長，
但是線性增長還是增長，還是越來越多，直到有一天，水滿則溢，出現了擁塞，這時候一般就會一下子降低倒水的速度，等待溢位的水慢慢滲下去，
擁塞的一種表現形式是丟包，需要超時重傳，這個時候，將 sshresh 設為 cwnd/2，將 cwnd 設為 1，重新開始慢啟動，這真是一旦超時重傳，馬上回到解放前，但是這種方式太激進了，將一個高速的傳輸速度一下子停了下來，會造成網路卡頓，
前面我們講過快速重傳演算法，當接收端發現丟了一個中間包的時候，發送三次前一個包的 ACK，于是發送端就會快速地重傳，不必等待超時再重傳，TCP 認為這種情況不嚴重，因為大部分沒丟，只丟了一小部分，cwnd 減半為 cwnd/2，然后 sshthresh = cwnd，當三個包回傳的時候，cwnd = sshthresh + 3，也就是沒有一夜回到解放前，而是還在比較高的值，呈線性增長，
就像前面說的一樣，正是這種知進退，使得時延很重要的情況下，反而降低了速度，但是如果你仔細想一下，TCP 的擁塞控制主要來避免的兩個現象都是有問題的，
第一個問題是丟包并不代表著通道滿了，也可能是管子本來就漏水，例如公網上帶寬不滿也會丟包，這個時候就認為擁塞了，退縮了，其實是不對的
第二個問題是 TCP 的擁塞控制要等到將中間設備都填充滿了，才發生丟包，從而降低速度，這時候已經晚了，其實 TCP 只要填滿管道就可以了，不應該接著填，直到連快取也填滿，
為了優化這兩個問題，后來有了 TCP BBR 擁塞演算法，它企圖找到一個平衡點，就是通過不斷地加快發送速度，將管道填滿，但是不要填滿中間設備的快取，因為這樣時延會增加，在這個平衡點可以很好的達到高帶寬和低時延的平衡，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/172562.html
標籤：其他