一次简单的 HTTP 调用，为什么时延这么大？抓个包分析下

试想如果应用程序每次产生 1 个字节的数据，然后这 1 个字节数据又以网络数据包的形式发送到远端服务器，那么就很容易导致网络由于太多的数据包而过载。在这种典型情况下，传送一个只拥有1个字节有效数据的数据包，却要花费 40 个字节长包头(即 IP 头部 20 字节 + TCP 头部 20 字节)的额外开销，这种有效载荷(payload)的利用率是极其低下。

Nagle 算法的内容比较简单，以下是伪代码：

if there is new data to send  
if the window size >= MSS and available data is >= MSS  
send complete MSS segment now  
else  
if there is unconfirmed data still in the pipe  
enqueue data in the buffer until an acknowledge is received  
else 
send data immediately  
end if 
end if 
end if 

具体的做法就是：

• 如果发送内容大于等于 1 个 MSS， 立即发送;
• 如果之前没有包未被 ACK， 立即发送;
• 如果之前有包未被 ACK， 缓存发送内容;
• 如果收到 ACK， 立即发送缓存的内容。(MSS 为 TCP 数据包每次能够传输的最大数据分段)

5.3 Delayed ACK 又是什么玩意?

大家都知道 TCP 协议为了保证传输的可靠性，规定在接受到数据包时需要向对方发送一个确认。只是单纯的发送一个确认，代价会比较高(IP 头部 20 字节 + TCP 头部 20 字节)。TCP Delayed ACK(延迟确认)就是为了努力改善网络性能，来解决这个问题的，它将几个 ACK 响应组合合在一起成为单个响应，或者将 ACK 响应与响应数据一起发送给对方，从而减少协议开销。

具体的做法是：

• 当有响应数据要发送时，ACK 会随响应数据立即发送给对方;
• 如果没有响应数据，ACK 将会延迟发送，以等待看是否有响应数据可以一起发送。在 Linux 系统中，默认这个延迟时间是 40ms;
• 如果在等待发送 ACK 期间，对方的第二个数据包又到达了，这时要立即发送 ACK。但是如果对方的三个数据包相继到达，第三个数据段到达时是否立即发送 ACK，则取决于以上两条。

5.4 Nagle 与 Delayed ACK 一起会发生什么化学反应?

Nagle 与 Delayed ACK 都能提高网络传输的效率，但在一起会好心办坏事。例如，以下这个场景：

A 和 B 进行数据传输 : A 运行 Nagle 算法，B 运行 Delayed ACK 算法。

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!