TCP提高高效性的方法
*滑動窗口
*快重傳
*延遲應答
*捎帶應答
滑動窗口
上一篇我們說了確認應答機制，對每一個發送的數據段，都要給一個ACK確認應答，收到ACK後再發送下一個數據段，這樣做有一個比較大的缺點就是性能較差，尤其是數據往返的時間較長的時候
既然這樣一收一發的方式性能較低，那麼我們一次發送多條數據，就可以大大的提高性能（其實是將多個段等待時間重疊在一起了）。
*窗口大小指的是無需等待確認應答而可以繼續發送數據的最大值。
*發送窗口大小數據的時候，不需要等待任何ACK，直接發送；
*收到一個ACK後，滑動窗口向後移動繼續發送下一個段的數據，以此類推
*操作系統內核爲了維護這個滑動窗口，需要開闢發送緩衝區來記錄當前還有那些數據沒有應答；只有確認應答過的數據才能從緩衝區中刪除；
*窗口越大，網絡的吞吐量就越高
在這裏我們假設滑動窗口的大小是4000，那麼我們把數據1001-2001從主機A發送給主句B，在收到主機B的確認應答後，滑動窗口就會往後移動
快重傳
那麼問題來了
如果出現了丟包的問題，數據怎麼進行重傳呢？
這裏有兩種情況
1：數據包已經抵達，但是ACK被丟了
2：數據包丟了
我們先來看第一種情況
這個時候我們不用擔心，部分ACK丟了並不要緊，因爲可以通過後續的ACK進行確認，知道前面的數據沒有丟
第二種情況
*當某一段報文段丟失之後，發送端會一直收到1001這樣的ACK，就像是在提醒發送端“我想要的是1001”
*如果發送端主機連續三次收到了同樣的1001這樣的應答，就會將對應的數據1001-2000重新發送
*在這個時候接收端收到了1001，返回的ACK就是6001，其他的已經收到了
這種機制被稱爲快重傳，我們在上一篇中講到，超時重傳，兩個 是不一樣的，缺一不可，超時重傳是沒有收到一次ACK，超過時間纔會重傳，而這裏的快重傳是收到重複ACK3次後重傳
延遲應答
如果接收數據的主機立刻返回ACK應答，這個時候返回的窗口可能比較小。
*假設接收緩衝區爲1M，一次收到500K的數據；如果立刻應答，返回的窗口就是500K；
*但實際上可能處理端處理的素的很快，10S之內就把500K數據從緩衝區中消費掉了；
*在這種情況下，接收端處理還遠沒有達到自己的極限，即使窗口在放大一些，也能處理過來；
*如果接收端稍微等一會再應答，比如等待200ms再應答，那麼這個時候返回的窗口大小就是1M；
窗口越大，網絡吞吐量就越大，傳輸效率就越高，我們是爲了保證網絡不擁塞的情況下，儘量提高傳輸效率
捎帶應答
在延遲應答的基礎上，我們發現很多情況下，客戶端服務器在應用層也是“一發一收”的，意味着客戶端給服務器說了一句話，服務器也會給客戶端回一句話；
那麼這個時候ACK就可以搭順風車，和服務器返回的話一起回給客戶端