TCP – Nagle’s Algorithm

一直沒有很深入的認識 TCP(Transmission Control Protocol) , 因這次追查專案傳輸問題接觸到了 TCP 底下很常見的兩個傳輸優化方法.
也是很多人在探討 TCP 效能會遭遇的問題之一, 筆記一下給未來的自己~XD
這次的問題就是環繞在「納格演算法(Nagle’s Algorithm)」&「TCP delayed acknowledgment」共同運作時並且在「Write-Write-Read」的狀況下觸發的.

追查

為了避免各種可能的干擾, 後來是使用封包分析工具來監測內容.
原本是要用免費軟體 SmartSniff, 但他的時間顯示會併在一起難以觀察時間差.
後來找到 Device Monitoring Studio 這個共享軟體, 介面上有點複雜, 但功能蠻多的, 資料也很適合分析.
(也因此發現真的要嘗試分析封包的內容, 才能更直接的深入學習網路相關的各種知識哪~)
下圖是在專案中的測試, server 端的設定是 ACK delay 時間是 50, 表格內的 interval 是指 client 端發起 pingpong 的間隔長(ms).
正常的互動會像是 interval=100 的清單上, _ping 與 _ping 之間的間隔要差不多在 100±3ms.
但在 interval=50 開始會有一定落差, 在 interval=30 就幾乎是穿插在一起惹~
接著可以看到被標示 ack 的封包都會很一致的落在 51~56ms, 和下面參考文章內觀測現象很相似.
因此就請 server 端進行設定調整, 確定這次的問題根源就在這些設定上了~
Pasted image at 2017_07_18 02_30 PM

 

設定

C# 的 TcpClient.NoDelay. 或者其實背後也是修改 Socket.NoDelay.
Java 的 setTcpNoDelay.
FreeBSD 的 delacktime.

ref

再探Linux下的TCP延迟确认机制–TCP_QUICKACK (非原作者, 但找不到原作者的文章…)

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com 標誌

您的留言將使用 WordPress.com 帳號。 登出 /  變更 )

Google photo

您的留言將使用 Google 帳號。 登出 /  變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 /  變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 /  變更 )

連結到 %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.