TCP Connections

TCP connections

We've mentioned multiple times that TCP establishes connections, but what does it exactly mean to establish?

With these TCP connections, we know that a client machine will reach out to a server machine and establish a connection. Once that connection is established, there will be lots of communication that will go back and forth between these two devices, so they can get data back and forth between them. Then, after the connection is done with — after all the data has been transferred and the connection is no longer needed — it will terminate this connection between the two devices. So TCP will start up a connection and a communication with this device, do the communicating, and then tear it back down afterwards.

The three-way handshake

TCP first establishes a connection before it starts transferring any major data back and forth. This layer 4 connection that's established back and forth, we call that a three-way handshake. The reason why we call it a three-way handshake is there's going to be three components to this. This is the PC, and it's asking for a web page from this server. It's going to send a message that we call a SYN. Then that server is going to reply back, and that's a SYN-ACK. It's going to reply back with a SYN-ACK, and then that PC is going to acknowledge that, or send an ACK back. So this is the three-way handshake that gets transferred back and forth to establish the connection.

Let's take a little closer look at this. When a PC sends this to the web server, it's going to say, "Hey, I want to communicate to you. Let's synchronize." And it communicates this by having a one bit in the synchronize flag. The acknowledgement flag is actually going to be zero at this point, because there's nothing to acknowledge, so this field doesn't really matter at this point. Then it's going to come up with some random sequence as part of this. What this synchronization is doing is synchronizing the sequence numbers, and so this PC needs to choose what number it's going to start out with. So let's say it starts out with 156,651 — that's the sequence number that's being sent to that web server. Nothing in the acknowledgement field, so we've got a zero in the acknowledgement flag.

Now the web server is going to send a SYN-ACK back, which means there's a one in the synchronize column: "Hey, yeah, let's synchronize, I agree with that." And then it's going to send a one in the acknowledgement column for two reasons. One is that it's part of this process of acknowledging it. But really what it is, is it's saying that it now is going to utilize this acknowledgement number, and the acknowledgement number is the next segment that I'm expecting — and I'm expecting the next segment of 156,652. And then it'll also come up with its own sequence number. It comes up with some random number, and that's what's being sent across to this side.

This PC now sends, "Okay, I acknowledge this." So it puts actually a zero in this SYN flag right here, saying, "Hey, I'm acknowledging we are now synchronized." And for the acknowledgement number, it's the next byte that it's expecting, so 1658 is the next byte that it's accepting. And then it's going to be transmitting this, so its next sequence is 156,653, and it's going to be sending 156,653 as its next sequence number. And now at that point in time both parties agreed we are going to communicate. We now have established what our sequence numbers are and can communicate the rest of the data.

Terminating the connection

Once the communication is established, it transfers bits back and forth, those sequence numbers count up, and acknowledgements happen along the way. Then at that point in time it needs to tear that connection back down, and this is going to happen in a similar fashion. The communication that will happen is, first of all, this PC will send the web server a FIN notification, or a finish notification. That is done by sending a one within the FIN column right there. And then that machine is going to acknowledge that it's received that finish. And then the reverse is going to happen: this machine will send and repeat, "Hey, yeah, I'm also finished, so I'm going to end this as well," and then this PC acknowledges that. So this is a four-step process of going into finish, acknowledgement, finish, acknowledgement, to terminate the connection between these two devices.

Now, there is actually a three-step process that can be done too. That is an option that TCP sometimes will do, the three-step process in terminating this. So there are a couple of processes, but just know that at the end of this, the session is terminated.

Following the sequence and acknowledgement numbers

Let's do a summary of what we're talking about here. We're talking about the connection and how it's established, how that connection establishment happens, how it is terminated, and the transfer in between. And we see some flags that are changing throughout this. We also see some sequence numbers and some acknowledgement numbers.

So let's talk about this chart. It gets a little complicated, so let's break this down. First of all, this column right here is just the direction of traffic: what's coming from the PC going to the web server, and vice versa, what's coming from the web server to the PC. The direction of the arrow signifies this. The second column is the data payload of it. Then we have the sequence number, the acknowledgement numbers, and then we've got the flags right here.

When we start out with this communication, we know that the PC is going to first of all ask, "Hey, I want to download the web page, so I want to establish a connection with you." So that's what this first segment that's being sent across is: to establish that connection. We know there's nothing to acknowledge at this point, so the acknowledgement field is turned off. That's why this is the only one that we see a zero on, because we don't need the acknowledgement field, and then we set up the acknowledgement field later on. Just a slight note here is that this first three starts the establishment of the communication. Then we communicate what we want to communicate — and this could go on for quite a while, or it could be simple and short — and then we close out or terminate this connection.

So let's talk about what this looks like. We've got this PC1 making the request over to the server. This sequence number is going to be randomized, so this number right here will be randomized. I randomly chose zero just to make it easy, so I'm going to choose zero for this right here right now. And the request is being sent from this PC to this server, saying, "Okay, I want to establish a communication with you." This server then sends communication back — that's the second row in this table — saying, "Okay, I will communicate with you. I'm going to set up my random sequence number, which is 150. And the next bit or byte that I'm expecting from you, the next byte I'm expecting, is one from you." So that's the next sequence. With this they're synchronizing, so these synchronizing bits are turned on.

So now we're synchronized, and there's a final acknowledgement of that synchronization. It sends a one in the byte column over there, and it says, "Okay, I'm expecting next from you 151," which is just the next byte in the sequence. And so this machine right here says — well, it doesn't reply back at this point in time. We have an official connection between these two devices. It's a three-way handshake: "Hey, I'd like to communicate with you." "Okay, let's communicate." "Great, we're communicating."

So now the communication is happening. Now this PC needs to make its request, saying, "I would like this web page." And the request doesn't even have to be that big; it could be a pretty small request. So I just represented this by 100 bytes right here. And it's saying, "Okay, byte one of this 100 bytes is byte one, and so I'm sending my first 100 bytes over. The first byte is byte one." And so then I'm going to be looking for my acknowledgement — I'm going to be looking for the next byte of yours.

This machine then starts sending the web page over to this PC, the web page that it asked for, so it's going to start sending information over. Maybe the first initial one is quite a bit larger. Maybe it has a big segment that it's going to send over, so it's 1,400 bytes. So it's still on 151 as the first byte that's sending over, and then every byte counts up from there. The next byte number that it's expecting from the PC is 101. And we know that it's 101 because it's done the first 100 bytes, which is byte one through byte 100, so the next byte it's expecting is 101.

So it sends that chunk of data over there, and this PC is going to acknowledge it. It sends something back just to acknowledge, "Hey, I've got your message." It doesn't really need any payload, because it's not trying to upload anything to the web server. So it's sending it as sequence 101, and it acknowledges, "the next sequence number I'm expecting from you is 2451." And so now this server knows, because it gets a 2451 from this segment right here, that this PC received this last communication. It acknowledged that it received the last communication and is up to date in the payload that's been transferred so far.

So now this web server is ready to send the next set of data, the next payload. In this case right here, we just are saying that it's going to send 200, but it labels the first byte of that as 2451, and says, "the next byte that I'm expecting from you is 101." It's still 101 because you didn't send anything the last time. It was just the acknowledgement; you didn't send anything in your payload. So if you're going to send something more to me, then the next one I'm going to expect is 101.

So this communication happens. The data transfer happens back and forth until this web page is fully uploaded onto the PC, and then that PC is done, so it initiates a termination of this connection. So this segment gets sent back and it says, "Okay, I'm at" — because of all the communication that happened back and forth, maybe it's at 3503 — "so that's the next sequence number. I've downloaded everything from you, so the next sequence number I'm expecting from you is 4515. And I'm going to finish this conversation. I've got everything that I need."

This web server sends back a message. It's 4515, so 45,115 is the next sequence number. It says, "Okay, the next sequence number from you that I'm expecting is 3504." And then it will send back an acknowledgement that says, "Okay, now I'm ready to finish this, so I am also ending this. I'm going to have the sequence number — it hasn't changed, because they haven't sent you any data — and the next number I'm expecting from you is 3504." And then this PC replies with 3504 to end it and says, "if I do receive any more payload back from you, then I'm going to be expecting 45,16." But at that point in time the connection is terminated, and so this process would start all over again if there's anything else that this PC needs to download after this. So then this connection is completely terminated and there's nothing residual, nothing that's going to continue after this.

So we talked about the TCP header there, the TCP connection and how it establishes this connection, does its communication, and then terminates it at the end. And so that's why TCP is connection-oriented: it establishes these connections and tears down these connections. It doesn't just end. There's a graceful way of ending the communication.