Note that TCP doesn't actually provide that guarantee to the application layer. There's no way to know if some bytes you sent on a TCP socket ever arrived. So,

Note that TCP doesn't actually provide that guarantee to the application layer. There's no way to know if some bytes you sent on a TCP socket ever arrived. So, if you want a reliable packet delivery, you have to build that at the application layer yourself anyway. That's why HTTP requires the 204 No Content response code, for example - instead of relying on a TCP ACK to achieve the same. The only real guarantee that TCP provides is in-order delivery. That is, it really guarantees that if you sent two requests A and B to a server, the server will never see request B unless it saw request A first. Again looking at HTTP, this is why request pipelining theoretically works without including any request ID in the response: the client knows that if it sent reqA first and reqB second, the first response it gets from the server will be respA, and the second will be respB (if either of them ever arrives, of course). Note that the fact ACK is not shown to the application layer is not an implementation limitation, it is a fundamental part of the design of TCP. The ACK is generated by the TCP stack once the packet was received. This doesn't guarantee in any way that the application will ever see this packet: the application could crash, for example, and never receive (and thus act on) this message. The in-order guarantee works instead because the transport layer can simply avoid ever showing reqB to the application layer if it knows that there was a reqA before it that it didn't receive. So the transport can in fact ensure that it's impossible for the application to see out-of-order data, but it can't ensure that the application has actually received any data.