TCP/IP詳解卷一 第19章有個疑問
書中對Negle算的定義：該演算法要求一個T C P連接上最多只能有一個未被確認的未完成的小分組，在該分組的確
認到達之前不能發送其他的小分組。相反， T C P收集這些少量的分組，并在確認到來時以一
個分組的方式發出去。
然后書中有個例子，如下圖：
書中有段話：
報文段1 4和1 5看起來似乎是與N a g l e演算法相違背的，但我們需要通過檢查序號來觀察其中
的真相。因為確認序號是5 4，因此報文段1 4是報文段1 2中確認的應答。但客戶在發送該報文
段之前，接收到了來自服務器的報文段1 3，報文段1 5中包含了對序號為5 6的報文段1 3的確認。
因此即使我們看到從客戶到服務器有兩個連續回傳的報文段，客戶也是遵守了N a g l e演算法的。
但是我還是覺得報文段14和15不符合Negle演算法，不管作者怎么說，報文段14是客戶端發出去的一個分組，但是該分組還沒被確認又發出了報文段15，這還是違背Nagle演算法的吧，只不過站在服務端的角度才是遵守Nagle的。
uj5u.com熱心網友回復：
我最近也在鉆這個牛角尖，雖然說從常理上解釋這個操作時合理的，因為client在收到第12段報文之后，決定發送當期累積的報文，可是在發送之后，又收到了server發送過來的也就是第13段報文，此時對client來說，的確有一個未被確認的報文段，但是它收到了server的報文13，就必須發送ACK確認，如果按照nagle的定義，也就是不發送新的報文段，那么server會重發報文段13，然后client再發送新的報文段，這樣的操作還不如上圖中的。uj5u.com熱心網友回復：
最好不是應該將報文段14和15合成一段一起發送嗎
uj5u.com熱心網友回復：
14是收到12后就發送的，但是可能在剛剛發送完之后又收到了13，此時用戶行程又提交了新的需要發送的資料，也就是17:18(1)，這時候需要對13進行確認，并且有新的待發送的資料，所以發送了報文15，這是符合規則的。我覺得TCP協議只是制定了規則，至于如何實作，各個平臺都有差別。tcp協議用詞有MUST、SHOULD、MAY等等，對于angle演算法，使用的詞匯就是SHOULD，
A TCP SHOULD implement the Nagle Algorithm [TCP:9] to coalesce short segments.
希望有大神來傳道受業解惑
uj5u.com熱心網友回復：
但是從時間序列看，14是在收到12和13以后再發送的，不知道TCPDUMP命令監控的是哪一層協議，列印出的時間這么奇怪。
uj5u.com熱心網友回復：
哈哈哈，看到20章會有更多疑問的uj5u.com熱心網友回復：
Nagle演算法規定了，發送方網路鏈路上一個連接只能有一個未獲得ACK的請求包。這個就意味著，發送方只有等待上一個請求的ACK回來之后才能發送下一個請求，這樣兩個請求程序中間，發送方的快取區就存盤了足夠滑動視窗大小的包進行傳遞，這樣就有效避免了大量的小包產生。轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/101227.html
標籤：網絡協議與配置