TCP ack 中的数据有效载荷 [英] Data payload in a TCP ack

问题描述

我正在筛选一些网络跟踪，并在我自己的机器上注意到当我通过 HTTP 连接时，数据包看起来像:

I'm sifting through some network traces and noticed on my own machine that when I connect over HTTP, packets look something like:

client --> server: GET
server --> client: tcp ack
server --> client: HTTP response
client --> server: tcp ack

但是，我查看了几年前保存的一些 CIFS (SMB) 跟踪.我看到如下内容:

However, I looked at some CIFS (SMB) traces I have saved from a few years back. I see things like:

client --> server: Create Request 
server --> client: Create response (This packet also acks the request)

在高层次上，我想知道为什么会有差异 - 是什么导致了不同的行为?是什么控制应用程序响应是放在请求确认还是另一个数据包上:应用程序还是操作系统?

At a high level, I'm wondering why the difference - what is causing the different behaviors? What is controlling whether the application response is placed on the request ack or another packet: the application or OS?

推荐答案

此行为取决于操作系统和应用程序.在linux中，内核不直接发送ACK，而是等待一个固定的毫秒数(大约200)，希望有一些数据要发送回来，并且可以让ACK捎带数据.

This behavior is dependent on both the OS and the application. In linux, the kernel doesn't send an ACK directly, but instead waits a fixed number of milliseconds (around 200), hoping that is has some data to send back and can let the ACK piggyback the data.

如果计时器关闭，则立即发送 ACK.

If the timer goes off, then the ACK is sent immediately.

示例 1.

Client sends the GET request.

Server tries to create a http response, but before it does that 200ms are gone
and it must send the ACK before the http response.

示例 2.

Client sends the GET request.

Server creates a http response within the timer limit, and the ACK can piggyback
the data.

意思是，如果您的应用程序在生成该响应时变慢，则将发送 ACK 而不捎带数据.并且还取决于操作系统，延迟计时器可以更高/更低，并再次改变 ACK 的发送方式.

Meaning, if your application got slower at generating that response, the ACK will be send without piggybacking on the data. And also depending on the OS, the delay timer can be higher / lower and once again changing how ACK's are sent.

这篇关于TCP ack 中的数据有效载荷的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！