重讀TCP 協議

拖延症晚期患者，終於在週末的尾巴開始寫這篇本來上週就應該總結出來的文章了……。

大部分介紹 tcp 協議的開頭都是， tcp 協議是一種面向連線的、可靠的、基於位元組流的傳輸層協議。講真的就是這麼單純的記住這個概念，在實踐中並沒有什麼具體用處，畢竟工作和考試不一樣……。為了更深刻的理解這個協議，讓我們先拆解下概念要點：

理解完上面的基礎概念，你就真的懂 tcp 協議了嗎？讓我們問幾個問題測試下

很簡單，筆者手邊的書就清楚的寫著這麼兩條

曾經我也是這麼回答的，但是這個回答明顯是經不起推敲的，啥叫可靠的終止 tcp 連線，為啥沒有 time_wait 狀態就不可靠了，咦，你是不是沒想過？

其實這個問題的根本原因是每次建立連線的序列號都是隨機的，並且這個序列號是 32 的，會發生迴繞。我們知道，ip 資料報最多存活 msl（報文最大生存時間），那麼就有可能發生下面的情況：

2.2.1 超時時間計算：

rtt 時間指的是乙個 tcp 資料分段的往返時間。但是路由是動態的，並且路由器有可能會快取或者丟棄任何資料，因此 rtt 時間也必須動態測量。 so，怎麼測量，多次測量取算術平均值？明顯是不符合要求的，假設兩次測量的值是 1 和 99 ，平均值則為 50 ，則會有以下的問題：

因此，除了考慮每兩次測量值的偏差之外，其變化率也應該考慮在內，如果變化率過大，則通過以變化率為自變數的函式為主計算rtt，反之如果變化率很小，則取測量平均值。

2.2.2 超時時間的管理：

超時的設定是基於每個 tcp 分段的還是基於每個 tcp 連線的呢？明顯這麼問的話，肯定就是基於 tcp 連線的，但是基於 tcp 連線有什麼好處嗎？

基於 tcp 連線設定超時能夠減少記憶體開銷和排程開銷。

設計計時器的原則——每乙個報文在超過最近 rtt 測量的時間收不到確認都必須可超時，因此rfc2988 定義一套很簡單的原則：

傳送tcp分段時，如果還沒有重傳定時器開啟，那麼開啟它。

傳送tcp分段時，如果已經有重傳定時器開啟，不再開啟它。

收到乙個非冗餘ack時，如果有資料在傳輸中，重置重傳定時器。

收到乙個非冗餘ack時，如果沒有資料在傳輸中，則關閉重傳定時器。

只要 1，2 存在就能夠滿足上述設計計時器的原則，為什麼還要增加後面的兩條呢？

本來呢，筆者是想把流量控制這部分也寫完的，但是鑑於最近不適合熬夜以及要「認真工作，快樂生活」，那我就先留個坑吧，不過 tcp 流量控制部分很多設計還是很值得學習。