目的是為了提高效率，在流量控制的基礎上，盡量返回乙個合理但是比較大的視窗。
延時應答其實就是在不影響可靠性的前提下，讓ack的傳送時間晚一會，在這延時的過程中，讓應用程式有更多消費資料的時間，這樣接受緩衝區剩下的空間就會更大一點，返回的視窗也會大一點。
在延時應答的基礎上為了進一步提高程式執行效率而引入的機制。
這其實並不是tcp自身機制，只要是面向位元組流傳輸，都有這個問題。
粘包粘的是應用層資料報，導致處理資料的時候，容易讀取半個應用層資料報，
「面向位元組流」：一次讀乙個位元組，兩個位元組，或者n個位元組都可以。
所以就會出現有時沒有把傳送方的資料讀完而出現歧義，如上，讀乙個位元組，就會讀出「好」，假如讀完，就發現其實是拒絕的。
這裡的問題只能通過應用層本身區分出包和包之間的邊界。
解決方法：
1.使用分隔符。
我們可以在乙個資料報後面加乙個符號用來標識當前包已經結束，讀到這個符號就停止了。
2.明確包的長度。
在一些「異常情況下」，tcp對於連線會有特殊處理，
2.主機關機（按照正常流程）：關機的時候會強制先殺程序，殺程序的過程中就進行了四次揮手。
3.主機斷電/網線掛了：
a》如果是接收方斷電：對方傳送訊息時，就會沒有ack應答，就會觸發超時重傳，重傳一定次數就會重置連線，最後放棄連線。
b》傳送方斷電：接收方嘗試接受訊息，對接受端，本來也不知道傳送方啥時候傳送，這時引進乙個概念「心跳包」，tcp通訊雙方，即使沒有資料互動過程，也會定時互相傳輸乙個「心跳包」，只是為了說明看雙方是否還「活著」，如果很長時間沒有收到對方的心跳包，就認為對方已經「掛了」。
1.tcp適合於要求可靠性的場景，外網通訊，網路環境複雜，udp丟包概率大，優先考慮tcp。
2.udp適合於對於可靠性要求沒那麼高，但要求效率很高的場景。
3.udp能實現廣播，tcp只能一對一傳輸，要用tcp廣播，就需要應用層來配合了。
如何基於udp實現可靠傳輸？
這個呢，udp本身是改不了的，他是核心實現的，要在應用層來實現。這就可以根據tcp的機制來實現。
最主要的就是確認應答和超時重傳，通過設定序列號和確認序號的設定增加可靠性。而對於效率的問題，我們可以根據滑動視窗來解決了，之後的一系列問題，就都可以根據tcp的相關特性去解決了。
TCP 延時應答 捎帶應答
延時應答 我們知道tcp中，有確認應答機制以保證資料的可靠傳輸。但是是不是接受方接受到資料就立即返回ack應答呢？如果是這樣，這時候的緩衝區中接收區的資料還沒能夠處理，快取區的剩餘大小就是視窗大小。但是如果我們延遲一會，等待快取區中資料被處理，那麼剩餘的快取區就會大些 這就是延時應答。ps 假設接收...
TCP協議 擁塞控制，捎帶應答，延遲應答
擁塞控制，捎帶應答，延遲應答實際都與提高tcp的效率的機制 擁塞控制 上次我們談到tcp通過滑動視窗來高效可靠的傳送大量資料，但是當一開始就傳送大量資料，當遇到網路比擁堵或者網路狀態不佳的時候，就會引發一系列的問題。為了解決這一問題，tcp引入慢啟動機制，先發少量的資料，探探路 然後再決定資料的傳送...
TCP中的延遲應答與捎帶應答
1.1 應答方法 通常乙個資料段可以返回乙個ack應答，但是接收端如果立刻返回ack應答，會讓這個資料段中的視窗大小值比較小。假設我們接收緩衝區的為2m，收到了1m的資料，如果立刻應答，返回的視窗就是1m。實際上接收端處理資料可以很快，很短的時間內就把接收到的1m資料處理掉了。這種情況下，接收緩衝區...