概述
作為互聯(lián)網(wǎng)時代偉大發(fā)明的TCP/IP技術可以說對當今時代產(chǎn)生了深刻的影響。經(jīng)過近一個月的學習摸索，基本清楚了TCP/IP的面貌。由于TCP/IP在OS中位于內(nèi)核態(tài)，很多細節(jié)其實用戶無法感知，所以自己對于TCP/IP會有一些疑惑。關于其中幾個點經(jīng)過查閱一些書籍、博客并結合自己的一些理解，在此整理精煉成帖。
注： 本文原載于 My Personal Blog：， CodeSheep · 程序羊 ！
疑惑1 — 關于擁塞
疑惑一：無論是滿啟動還是擁塞避免階段，擁塞窗口都在增加，理論上一定會碰到擁塞點，為什么平時感覺不到擁塞呢？
看了很多書和文獻以后可能的解答如下：
1、OS中對接收窗口的最大設定多年未動，如windows在不啟用“TCP Window Option”情況下，最大接收窗口僅64KB。然而網(wǎng)絡進步，很多環(huán)境的擁塞點遠在64kb以上，即發(fā)送窗口永遠觸碰不到擁塞點
2、很多應用場景是交互式小數(shù)據(jù)交換，如聊天等，不會有擁塞的可能
3、有些應用在傳輸數(shù)據(jù)時采用同步方式，可能需要的窗口非常?。ㄈ绮捎昧送椒绞降腘FS寫操作，每發(fā)一個寫請求就停下來等回復，而一個寫請求可能僅有4kb）
4、即便偶爾擁塞，持續(xù)時間也不足以長到能感受出來，除非抓包看包交換細節(jié)
疑惑2 — 關于超時重傳
疑惑二： 關于超時重傳后的ssthresh設置問題的爭議
1、Richard Stevens在《TCP/IP詳解》中把臨界窗口值定為上次發(fā)生擁塞時的發(fā)送窗口的一半
2、RFC5681則認為應是發(fā)生擁塞時未被確認的數(shù)據(jù)量的1/2（又稱FlightSize），且不小于2MSS
3、Westwood/Westwood+算法則這樣認為：先推算出有多少包已被送達到接收方（可根據(jù)收方回應的ACK來推算），從而精確地估算發(fā)生擁塞時的帶寬，最后再依據(jù)帶寬來確認新的擁塞窗口
4、Vegas算法則這樣認為：引入全新的概念，摒棄之前的在丟包后才調(diào)節(jié)擁塞窗口的做法。其通過監(jiān)控網(wǎng)絡狀態(tài)來調(diào)整發(fā)包速度，實現(xiàn)“真正的擁塞避免”。當網(wǎng)絡良好時，RTT較穩(wěn)定，此時可以增加擁塞窗口；當網(wǎng)絡繁忙時，RTT增加，此時減小擁塞窗口
5、Compound算法這樣認為：同時維持兩個擁塞窗口，一個類似于Vegas，另一個類似于RFC5681，真正起作用的是兩者之和（Win7上其默認關閉）
6、BIC算法/CUBIC算法
分別是linux2.6.18和linux 2.6.19所采用，目前尚未研究
關于TCP/IP的幾點精煉總結：
（1）當無擁塞時，發(fā)送窗口越大，性能越好?！嘣趲挍]有限制的情況下，應盡量增加接受窗口，比如啟用Scale Option
（2）若經(jīng)常發(fā)生擁塞，則限制發(fā)送窗口反而可以提高性能，∵即便萬分之一的重傳對性能的影響都非常大。很多OS上可通過限制接收窗口的方法來↓發(fā)送窗口
（3）超時重傳對于性能影響最大，∵RTO時間內(nèi)未傳輸任何數(shù)據(jù)，而Cwnd會被設成1MSS，應盡量避免
（4）快速重傳對性能影響小一些，∵無等待時間，且Cwnd減幅不大
（5）SACK和NewReno有利于增加重傳效率，增加傳輸性能
（6）丟包對極小文件的影響比打文件嚴重。深層原因是因為讀寫一個小文件需要的包數(shù)很少，∴丟包時往往湊不滿三個Dup ACK，只能等待超時重傳；而大文件有較大可能觸發(fā)快速重傳
后記
由于能力有限，若有錯誤或者不當之處，還請大家批評指正，一起學習交流！
