你可能沒有細究過的TCP/IP

---

---

概述

做爲互聯網時代偉大發明的TCP/IP技術能夠說對當今時代產生了深入的影響。通過近一個月的學習摸索，基本清楚了TCP/IP的面貌。因爲TCP/IP在OS中位於內核態，不少細節其實用戶沒法感知，因此本身對於TCP/IP會有一些疑惑。關於其中幾個點通過查閱一些書籍、博客並結合本身的一些理解，在此整理精煉成帖。

注： 本文首發於 My 公衆號 CodeSheep ，可 長按 或 掃描 下面的 當心心 來訂閱 ↓ ↓ ↓

---

疑惑1 — 關於擁塞

**疑惑一：**不管是滿啓動仍是擁塞避免階段，擁塞窗口都在增長，理論上必定會碰到擁塞點，爲何平時感受不到擁塞呢？

看了不少書和文獻之後可能的解答以下：

• 一、OS中對接收窗口的最大設定多年未動，如windows在不啓用「TCP Window Option」狀況下，最大接收窗口僅64KB。然而網絡進步，不少環境的擁塞點遠在64kb以上，即發送窗口永遠觸碰不到擁塞點

• 二、不少應用場景是交互式小數據交換，如聊天等，不會有擁塞的可能

• 三、有些應用在傳輸數據時採用同步方式，可能須要的窗口很是小（如採用了同步方式的NFS寫操做，每發一個寫請求就停下來等回覆，而一個寫請求可能僅有4kb）

• 四、即使偶爾擁塞，持續時間也不足以長到能感覺出來，除非抓包看包交換細節

---

疑惑2 — 關於超時重傳

疑惑二： 關於超時重傳後的ssthresh設置問題的爭議

• 一、Richard Stevens在《TCP/IP詳解》中把臨界窗口值定爲上次發生擁塞時的發送窗口的一半

• 二、RFC5681則認爲應是發生擁塞時未被確認的數據量的1/2（又稱FlightSize），且不小於2MSS

• 三、Westwood/Westwood+算法則這樣認爲：先推算出有多少包已被送達到接收方（可根據收方迴應的ACK來推算），從而精確地估算髮生擁塞時的帶寬，最後再依據帶寬來確認新的擁塞窗口

• 四、Vegas算法則這樣認爲：引入全新的概念，摒棄以前的在丟包後才調節擁塞窗口的作法。其經過監控網絡狀態來調整發包速度，實現「真正的擁塞避免」。當網絡良好時，RTT較穩定，此時能夠增長擁塞窗口；當網絡繁忙時，RTT增長，此時減少擁塞窗口

• 五、Compound算法這樣認爲：同時維持兩個擁塞窗口，一個相似於Vegas，另外一個相似於RFC5681，真正起做用的是二者之和（Win7上其默認關閉）

• 六、BIC算法/CUBIC算法 分別是linux2.6.18和linux 2.6.19所採用，目前還沒有研究

---

關於TCP/IP的幾點精煉總結：

• （1）當無擁塞時，發送窗口越大，性能越好。∴在帶寬沒有限制的狀況下，應儘可能增長接受窗口，好比啓用Scale Option

• （2）若常常發生擁塞，則限制發送窗口反而能夠提升性能，∵即使萬分之一的重傳對性能的影響都很是大。不少OS上可經過限制接收窗口的方法來↓發送窗口

• （3）超時重傳對於性能影響最大，∵RTO時間內未傳輸任何數據，而Cwnd會被設成1MSS，應儘可能避免

• （4）快速重傳對性能影響小一些，∵無等待時間，且Cwnd減幅不大

• （5）SACK和NewReno有利於增長重傳效率，增長傳輸性能

• （6）丟包對極小文件的影響比打文件嚴重。深層緣由是由於讀寫一個小文件須要的包數不多，∴丟包時每每湊不滿三個Dup ACK，只能等待超時重傳；而大文件有較大可能觸發快速重傳

後記

做者更多的原創文章在此