CODEWITHSUNDEEP
tcp
UsAaR33
UsAaR33

Reputation: 3686

Data payload in a TCP ack

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

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?

Upvotes: 13

Views: 9235

Answers (1)

Milan
Milan

Reputation: 15849

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.

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

Example 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.

Example 2.

Client sends the GET request.

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

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.

Upvotes: 9

Related Questions