延時應答
目的是爲了提高效率，在流量控制的基礎上，儘量返回一個合理但是比較大的窗口。
延時應答其實就是在不影響可靠性的前提下，讓ack的發送時間晚一會，在這延時的過程中，讓應用程序有更多消費數據的時間，這樣接受緩衝區剩下的空間就會更大一點，返回的窗口也會大一點。
捎帶應答
在延時應答的基礎上爲了進一步提高程序運行效率而引入的機制。
粘包問題
這其實並不是TCP自身機制，只要是面向字節流傳輸，都有這個問題。
粘包粘的是應用層數據包，導致處理數據的時候，容易讀取半個應用層數據包，
“面向字節流”：一次讀一個字節，兩個字節，或者N個字節都可以。
所以就會出現有時沒有把發送方的數據讀完而出現歧義，如上，讀一個字節，就會讀出“好”，假如讀完，就發現其實是拒絕的。
這裏的問題只能通過應用層本身區分出包和包之間的邊界。
解決方法：
1.使用分隔符。
我們可以在一個數據包後面加一個符號用來標識當前包已經結束，讀到這個符號就停止了。
2.明確包的長度。
保活機制
在一些“異常情況下”，TCP對於連接會有特殊處理，
1.進程崩潰：這種情況下TCP連接會正常四次揮手（只要是進程退出，都會自動關閉相關文件）
2.主機關機（按照正常流程）：關機的時候會強制先殺進程，殺進程的過程中就進行了四次揮手。
3.主機斷電/網線掛了：
a》如果是接收方斷電：對方發送消息時，就會沒有ack應答，就會觸發超時重傳，重傳一定次數就會重置連接，最後放棄連接。
b》發送方斷電：接收方嘗試接受消息，對接受端，本來也不知道發送方啥時候發送，這時引進一個概念“心跳包”，TCP通信雙方，即使沒有數據交互過程，也會定時互相傳輸一個“心跳包”，只是爲了說明看雙方是否還“活着”，如果很長時間沒有收到對方的心跳包，就認爲對方已經“掛了”。
TCP和UDP對比：
1.TCP適合於要求可靠性的場景，外網通信，網絡環境複雜，UDP丟包概率大，優先考慮TCP。
2.UDP適合於對於可靠性要求沒那麼高，但要求效率很高的場景。
3.UDP能實現廣播，TCP只能一對一傳輸，要用TCP廣播，就需要應用層來配合了。
常見面試題：
如何基於UDP實現可靠傳輸？
這個呢，UDP本身是改不了的，他是內核實現的，要在應用層來實現。這就可以根據TCP的機制來實現。
最主要的就是確認應答和超時重傳，通過設定序列號和確認序號的設定增加可靠性。而對於效率的問題，我們可以根據滑動窗口來解決了，之後的一系列問題，就都可以根據TCP的相關特性去解決了。