Conceptually, I think of a TCP connection as having two aspects.

  1. The "connection" - i.e. an arrangement where the two hosts "agree" to commnunicate with each other. loosely analogous to calling someones phone and, when they pick up at the other end you have a "connection".
  2. The data transfer

The connection aspect of TCP is well covered in documents on the web, hosts negotiate the connection via 3 way handshake etc, but at this point you only have an idle connection - again analogous to someone picking up the phone at the other end and having "dead air"

My question is, once this connection is established, how is data, e.g. a file transfer initiated? I would imagine it looks something like the sender outlining what its going to send, i.e. "Im going send you ...., and you will know the transfer is complete when you have a file of X bytes, or you receive a trailer from me". How does a TCP data/file transfer get started?

  • TCP client makes socket_bind() --> socket_connect() --> socket_send(<your_data>) --- to TCP server Apr 24, 2018 at 7:23

1 Answer 1


TCP is a stream-oriented transmission protocol; it only cares about getting bytes in the right order from one host to another, it doesn’t care about the content of those bytes or any message they might form. Once a connection is established, either end of the connection can send bytes to the other.

To give meaning to a message you need to agree on a protocol on top of TCP. It’s this protocol which determines what messages should be sent, and how to interpret received messages; this includes determining when a message is complete. For example, in HTTP, if the “Content-Length” header is present, the receiver can use that to figure out whether it has received all the data; if it isn’t, other methods are used (see the RFC for details), up to simply waiting for the server to close the connection (which in some way is using TCP to determine message length, albeit in a rather expensive fashion).

If you want to send individual messages using a message-oriented transport protocol, you could use UDP or SCTP instead of TCP.

  • so does this mean it is up to the applications to agree on when they have finished/completed the transaction/transfer? Apr 24, 2018 at 7:27
  • Yes, that’s exactly what this means. They can agree to mark the completion of a transaction by closing the connection, but that’s part of the protocol above TCP. Apr 24, 2018 at 7:31
  • thanks. yes I know with HTTP the server gives guidance to the browser as to when the transfer is complete. .as you mentioned it could be Content-length, or it could use the Transfer-Encoding: chunked header, when the server itself doesn't know the file size (i.e. the HTTP data [html] is being generated by an application.) so it sends "chunks" preceded with a token telling the browser how big the chunk will be . when that token is `0' the browser knows its done. Apr 24, 2018 at 9:46
  • I was vaguely aware the applications could indicate the conclusion of a transfer by closing the connection itself, but I think typically in HTTP the browser and server want to keep the connection around for possible reuse. So I guess in this situation they simply conclude each HTTP transaction silently, without notifying the TCP layer that a transfer was complete in order to keep the connection around? Apr 24, 2018 at 9:54
  • From the point of view of the TCP connection, there is no such thing as a “complete transfer”; the TCP layer doesn’t know when a transfer is complete. Closing a TCP connection is an active operation, it’s not supposed to happen on its own. (It does in some contexts, but that’s external behaviour on the underlying network, not part of TCP itself; hence the use of keep-alives.) All that to say that concluding a transaction “silently” doesn’t mean anything to TCP; it would keep the connection open anyway. Apr 24, 2018 at 11:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .