TCP/IP Illustrated Vol1 Second Edition即英文版第二版，TCP部分我的勘誤

目前已經有了英文版第二版的TCPIP詳解，中文版暫時尚未，可是英文版仍是有好幾處錯誤，做者和官方居然沒有維護一個勘誤表。

 

我的閱讀過程當中針對TCP部分可能有問題的地方簡單勘誤一下

 

P596：示意圖中最後一條TCP消息，Seq=K+1，做者寫成了Seq=K。

P600：TCP同關示意圖中最後一條TCP消息Seq=K+1，做者寫成了Seq=K。

P609：第二行應該爲Timestamp Echo Reply。

P650：tcp_retries1和tcp_retries2這兩個參數控制的是重傳總時間，而不是重傳次數。這兩個參數man page裏面也錯誤的描述爲控制重傳次數了，網上的錯誤描述也不少。另外SYNACK的重傳次數除了受到tcp_synack_retries影響外，還會受到SOCKET選項TCP_SYNCNT、TCP_DEFER_ACCEPT等的影響。

P737：Tahoe是4.3版本的BSD發佈的，慢啓動和擁塞避免也是4.3版本的BSD發佈的。做者都描述爲4.2版本了。

P768：在linux中關閉TCP鏈接的時候，rttvar、cwnd確實會保存到TCP metrics中，可是tcp創建鏈接時候並不會使用rttvar，而cwnd是擁塞窗口的最大值，並非擁塞窗口，並且只有在lock狀況纔會使用到cwnd。

P742：對於limited transmit，做者描述是每一對dup ACK發送一個unsent數據，協議描述的是對於收到的前兩個dup ACK，每一個dup ACK均可以觸發一個unsent數據包的發送。實際上limited transmit能夠擴展爲對於收到的前(dupthresh-1)個dup ACK，每一個dup ACK均可以觸發unsent數據包的發送，這個對應linux中disorder狀態。[RFC3042]

P743：對於application-limited發送端，做者解釋爲發送端有數據須要發送，可是受限於底層協議或者計算機忙於處理其餘任務而沒有發出去，顯然正好理解錯了，協議中application-limited狀態就是指發送端沒有更多數據等待發送的場景。[RFC2861]

P769：TFRC中發送端的速率公式給錯了，參考RFC5348及論文<Modeling TCP Throughput:A Simple Model and its Empirical Validation>的section 2.2，實際的速率計算公式爲：

                                s
   X_Bps = ----------------------------------------------------------
           R*sqrt(2*b*p/3) + (t_RTO * (3*sqrt(3*b*p/8)*p*(1+32*p^2)))

即書中公式[2]應該給分母添加一個括號。

P775：在計算K的時候做者首先說β默認是0.2，而後按照β=0.8給出一組K、Wmax、C的示例參數，緊接着下一段又說CUBIC中β默認值爲0.8。實際上β叫作multiplicative decrease factor，CUBIC中β默認值確實是0.2，可是在具體代碼實現上通常使用一個beta變量保存(1-β)的值，所以beta=0.8。通常討論代碼實現的時候咱們能夠說beta爲0.8，可是討論協議或者論文中的擁塞控制的時候咱們通常說β爲0.2。因此做者這裏舉例給出的K、Wmax、C的參數也就有問題了。另外linux內核cubic實現上beta=0.7，β=0.3。另外做者前面介紹的rate halving相關內容，應該更新爲PRR才和這裏相匹配

P776：Figure 16-20這個圖右上角W(t)的公式中第一個係數應該爲0.4。另外Wtcp的計算公式中β實際上又混爲(1-β)的值了，我在ncsu cubic主頁上看到過做者給出的那個公式，估計做者直接copy過來的。改成下面的計算公式更爲合理。能夠參考<CUBIC: A New TCP-Friendly High-Speed TCP Variant>，感興趣的能夠本身推導一下下面的這個公式

P777：倒數第二行括號裏面應該改成"up to 3, the value for β"，這段對於buffer的描述比較簡略，看不懂的能夠參考Vegas原始論文<TCP Vegas: End to End Congestion Avoidance on a Global Internet>的 Section III-B。

 

 

 

來自爲知筆記(Wiz)