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

作為網際網路時代偉大發明的TCP/IP技術可以說對當今時代産生了深刻的影響。經過近一個月的學習摸索，基本清楚了TCP/IP的面貌。由于TCP/IP在OS中位于核心态，很多細節其實使用者無法感覺，是以自己對于TCP/IP會有一些疑惑。關于其中幾個點經過查閱一些書籍、部落格并結合自己的一些了解，在此整理精煉成帖。

疑惑一：無論是滿啟動還是擁塞避免階段，擁塞視窗都在增加，理論上一定會碰到擁塞點，為什麼平時感覺不到擁塞呢？

看了很多書和文獻以後可能的解答如下：

1、OS中對接收視窗的最大設定多年未動，如windows在不啟用“TCP Window Option”情況下，最大接收視窗僅64KB。然而網絡進步，很多環境的擁塞點遠在64kb以上，即發送視窗永遠觸碰不到擁塞點

2、很多應用場景是互動式小資料交換，如聊天等，不會有擁塞的可能

3、有些應用在傳輸資料時采用同步方式，可能需要的視窗非常小（如采用了同步方式的NFS寫操作，每發一個寫請求就停下來等回複，而一個寫請求可能僅有4kb）

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

疑惑二： 關于逾時重傳後的ssthresh設定問題的争議

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

2、RFC5681則認為應是發生擁塞時未被确認的資料量的1/2（又稱FlightSize），且不小于2MSS

3、Westwood/Westwood+算法則這樣認為：先推算出有多少包已被送達到接收方（可根據收方回應的ACK來推算），進而精确地估算發生擁塞時的帶寬，最後再依據帶寬來确認新的擁塞視窗

4、Vegas算法則這樣認為：引入全新的概念，摒棄之前的在丢包後才調節擁塞視窗的做法。其通過監控網絡狀态來調整發包速度，實作“真正的擁塞避免”。當網絡良好時，RTT較穩定，此時可以增加擁塞視窗；當網絡繁忙時，RTT增加，此時減小擁塞視窗

5、Compound算法這樣認為：同時維持兩個擁塞視窗，一個類似于Vegas，另一個類似于RFC5681，真正起作用的是兩者之和（Win7上其預設關閉）

6、BIC算法/CUBIC算法

分别是linux2.6.18和linux 2.6.19所采用，目前尚未研究

（1）當無擁塞時，發送視窗越大，性能越好。∴在帶寬沒有限制的情況下，應盡量增加接受視窗，比如啟用Scale Option

（2）若經常發生擁塞，則限制發送視窗反而可以提高性能，∵即便萬分之一的重傳對性能的影響都非常大。很多OS上可通過限制接收視窗的方法來↓發送視窗

（3）逾時重傳對于性能影響最大，∵RTO時間内未傳輸任何資料，而Cwnd會被設成1MSS，應盡量避免

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

（5）SACK和NewReno有利于增加重傳效率，增加傳輸性能

（6）丢包對極小檔案的影響比打檔案嚴重。深層原因是因為讀寫一個小檔案需要的包數很少，∴丢包時往往湊不滿三個Dup ACK，隻能等待逾時重傳；而大檔案有較大可能觸發快速重傳