Is it normal, or OK to NOT see an ACK from the web server before an HTTP OK is sent? Usually, I see the three-way handshake, the GET from the client, an ACK from the server and then the HTTP OK from the server. Thank you. AT asked 06 Mar '15, 13:44  alexltk0506 |
2 Answers:
It's not normal to see any TCP packets that aren't ACKs, other than the initial SYN; all TCP packets other than the initial SYN should have the ACK bit set. A TCP host can send an ACK-only packet with no data, but it doesn't have to do so; if, for example, a client sends a short (one-TCP-segment) HTTP request to a server, the server's TCP code could choose not to immediately respond to the TCP segment containing the request with an ACK-only packet and, if the HTTP server code responds to the request quickly enough, the ACK could be piggybacked with the response. answered 06 Mar '15, 18:17  Guy Harris ♦♦ |
The (bare) ACK sent by the server after it received the GET is sent by the TCP stack on the server. Assuming the server is using delayed acking, it waits a while before sending an ACK back, as it expects it will have to send data soon. Since the client will retransmit the data if it does not receive an ACK in time, the delay before sending a bare ACK is usually 100ms or 200ms. So if the HTTP daemon on the server is able to answer the GET request before the delayed ACK timer runs out, you will not see the extra ACK packet. If it is slower, you will see the ACK in between the GET and the HTTP OK. answered 08 Mar '15, 05:18  SYN-bit ♦♦ |
Thank you!