8

I'm an application developer looking to learn more about the transport layer of my requests that I've been making all these years. I've also been learning more of the backend and am building my own live data service with websockets, which has me curious about how data actually moves around.

As such I've learned about TCP, and I understand how it works, but there's still one term that confuses me-- a "TCP Connection". I have seen it everywhere, and actually there was a thread opened with the exact same question... but as the OP said in the comments, nobody actually answered the question: TCP vs UDP - What is a TCP connection?

"when we say that there is a connection established between two hosts, what does that mean? If I could get a magic microscope and inspect the server or the client, and - a-ha! - find the connection, what would I be looking at? Some variable allocated by the OS code? Some entry in some kind of table? How and when does that gets there, and how and when it is removed from there"

I've been reading to try to figure this out on my own,
Here is a nice resource that details HTTP flow, also mentions "TCP Connection" https://blog.catchpoint.com/2010/09/17/anatomyhttp/

Here is another thread about HTTP Keep-alive, same "TCP Connection": HTTP Keep Alive and TCP keep alive

My understanding:
When a client wants data from server, SYN/ACK handshake happens, this "connection" is established, and both parties agree on the starting sequence number, maximum packet size, etc.

as long as this "connection" is still open, client can request/receive data without doing another handshake. TCP Keep-alive sends a heartbeat to keep this "connection" open

1) Somehow a HTTP Header "Keep-alive" also keeps this TCP "connection" open, even though HTTP headers are part of the packet payload and it doesn't seem to make sense that the TCP layer would parse the HTTP headers?

To me it seems like a "connection" between two machines in the literal sense can never be closed, because a client is always free to hit a server with packets (like the first SYN packet, for example)

2) Is a TCP "connection" just the client and server saving the sequence number from the other's IP address? maybe it's just a flag that's saying "hey this client is cool, accept messages from them without a handshake"? So would closing a connection just be wiping that data out from memory?

A O
  • 5,516
  • 3
  • 33
  • 68

1 Answers1

6

... both parties agree on the starting sequence number

No, they don't "agree" one a number. Each direction has their own sequence numbering. So the client sends in the SYN to the server the initial sequence number (ISN) for the data from client to server, the server sends in its SYN the ISN for the data from server to client.

Somehow a HTTP Header "Keep-alive" also keeps this TCP "connection" open ...

Not really. With HTTP keep-alive the client just asks a server nicely to not close the connection after the HTTP response was sent so that another HTTP request can be sent using the same TCP connection. The server might decide to follow the clients wish or not.

To me it seems like a "connection" between two machines in the literal sense can never be closed,

Each side can send a packet with a FIN flag to signal that it will no longer send any data. If both sides has send the FIN the the connection is considered close since no one will send anything and thus nothing can be received. If one side decides that it does not want to receive any more data it can send a packet with a RST flag.

Is a TCP "connection" just the client and server saving the sequence number from the other's IP address?

Kind of. Each side saves the current state of the connection, i.e. IP's and ports involved, currently expected sequence number for receiving, current sequence number for sending, outstanding bytes which were not ACKed yet ... If no such state is there (for example one site crashed) then there is no connection.

... maybe it's just a flag that's saying "hey this client is cool, accept messages from them without a handshake"

If a packet got received which fits an existing state then it is considered part of the connection, i.e. it will be processed and the state will be updated.

So would closing a connection just be wiping that data out from memory?

Closing is telling the other that no more data will be send (using FIN) and if both side have done it both can basically remove the state and then there is no connection anymore.

Steffen Ullrich
  • 114,247
  • 10
  • 131
  • 172
  • Thanks for the answer! I think I'm just getting hung up on terminology. Clarifying question: why is it called a connection instead of a session? I imagine a connection like two machines connected with an ethernet cable. One always has a connection to the other and can always send requests unless the cable/connection is disconnected. Whereas "session" seems more apt because it really is just a state/whitelist. Just want to make sure that I understand that this "TCP Connection" is purely a retained state in memory, and not like allocating any physical resources – A O Apr 29 '20 at 21:04
  • @AO: It is called a connection because it connects two communication endpoints: a client and a server application. Sessions are usually used for application layer states, i.e. in context of a web application the session usually starts when the user logs in and ends when it logs out. In between that there are lots of requests which can span multiple connections. – Steffen Ullrich Apr 29 '20 at 21:24