But in practice, three steps turns out to be good enough for most purposes. We can't prove that without sending an infinite number of SYNs and ACKs, and then nothing else would ever get done, so that's not really a practical option. Just because this sequence of packets got through does not strictly guarantee that others will. Well, strictly speaking, we can't be certain we have a good channel. It also knows that the client knows this, so it can start sending data right away. Once that ACK gets through, now the server knows that it can send packets to the client. This is the final step of the handshake: the client now knows that packets can go both ways, and that the server is just about to figure this out (because it knows the ACK will go through). So it sends back an ACK: just a plain ACK this time, because it doesn't need proof anymore that its packets can get through. And because a SYN-ACK is a SYN, it also knows that the server wants proof that this message got through. This is the second step of the handshake.īecause a SYN-ACK is an ACK, the client now knows for sure that it can send packets to the server. TCP combines these two messages into one -a SYN-ACK message, if you will- to reduce network traffic. So the server needs to send two messages back to the client: an ACK (to prove that the SYN got through) and a SYN (to request an ACK of its own). But that doesn't prove that the server can send packets back: clients can send SYNs for lots of reasons. If the SYN gets through, then the server knows that the client can send packets to it, because, well, it just happened.
That doesn't tell either person anything, but it's the first step of the handshake.
The client sends a SYN packet to the server, to request proof that its messages can get through. There's actually a third kind of message, but we'll get to that in a moment.īefore the connection starts, neither side really knows anything about the other. TCP essentially uses two kinds of messages for this: SYN (to request proof that this packet got through) and ACK (which only gets sent after a SYN gets through, to prove that the SYN got through). The only way to be sure that you got a packet to the other side is by getting a packet from them that, by definition, would not have been sent unless the packet you sent got through. In order for the connection to work, each side needs to verify that it can send packets to the other side.
#Why dont they have skate 3 for pc full#
As such three packets are involved in a full TCP connection initiation process. And again, the middle two flags happen in the same packet. So in effect, what you have is exactly your description of the two-way handshake, but in each direction. Both parties need to establish an ISN, and both parties need to acknowledge the other's ISN. Which means only one party can send data.īut TCP is a bi-directional communication protocol, which means either end ought to be able to send data reliably. So to come back to your question, why not just use a two-way handshake? The short answer is because a two way handshake would only allow one party to establish an ISN, and the other party to acknowledge it. Notice the two instances of "SYN" and "ACK", one of each, in both directions. So the three-way handshake ends up being: Bob Alice SYN ACK What makes a packet a SYN or ACK is simply a binary flag turned on or off inside each TCP header, so there is nothing preventing both of these flags from being enabled on the same packet. In actuality though, the middle two events (#2 and #3) happen in the same packet. Bob picks an ISN and SYNchronizes it with Alice.Alice picks an ISN and SYNchronizes it with Bob.So you end up with this sequence of events for a start of a TCP conversation between Alice and Bob: Alice -> Bob SYNchronize with my Initial Sequence Number of XĪlice Bob I received your syn, I ACKnowledge that I am ready for Which in turn means, both parties need to notify the other party of their starting ISN. And since TCP is a bi-directional communication, both parties can "speak", and therefore both must randomly generate an ISN as their starting Sequence Number. It starts at the ISN (Initial Sequence Number), which is a randomly chosen value.
The receiving party can use the opposite speaker's sequence number to acknowledge what it has received.īut the sequence number doesn't start at 0. Effectively it ends up being a running byte count of everything that was sent. In TCP, the two parties keep track of what they have sent by using a Sequence number. Break down the handshake into what it is really doing.
0 kommentar(er)
