As soon as a client requests a communication session with the server, a three-way handshake process initiates TCP traffic by following three steps. First, a connection between server and client is established, so the target server must have open ports that can accept and initiate new connections.
This SYN packet is a random sequence number that the client wants to use for the communication for example, X. This packet includes two sequence numbers. The first one is ACK one, which is set by the server to one more than the sequence number it received from the client e. The second one is the SYN sent by the server, which is another random sequence number for example, Y. Once again, each side must acknowledge the sequence number received by incrementing it by one.
Upon completion of this process, the connection is created and the host and server can communicate. All these steps are necessary to verify the serial numbers originated by both sides, guaranteeing the stability of the connection.
Since both hosts must acknowledge the connection parameters of the other side, a missing or out-of-order segment can be quickly detected before the actual data transfer process is initiated.
And, this is possible only due to the 3-way handshake process that takes place in the TCP during establishing and closing connections between two devices. As the name suggests, there are three steps for both establishing and closing the connection. So in this blog, we'll learn about the TCP 3-way handshake process and the different steps involved in it.
The 3-Way Handshake process is the defined set of steps that takes place in the TCP for creating a secure and reliable communication link and also closing it. Actually, TCP uses the 3-way handshake process to establish a connection between two devices before transmitting the data.
After the establishment of the connection, the data transfer takes place between the devices. After which the connection needs to be terminated, which is also done by using the 3-way handshake process. Hosts on the network read all data segments within a session and exchange information about what data is received using the information in the TCP header.
TCP is a full-duplex protocol, where each logical connection represents two one-way communication streams or sessions. To set up the connection, the hosts do a TCP 3-way handshake. That doesn't tell either person anything, but it's the first step of the handshake. If the SYN gets through, then the server knows that the client can send packets to it, because, well, it just happened. But that doesn't prove that the server can send packets back: clients can send SYNs for lots of reasons.
This is the second step of the handshake. 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. 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. Once that ACK gets through, now the server knows that it can send packets to the client.
It also knows that the client knows this, so it can start sending data right away. The handshake is complete. We have a good channel. Well, strictly speaking, we can't be certain we have a good channel. Just because this sequence of packets got through does not strictly guarantee that others will. 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.
But in practice, three steps turns out to be good enough for most purposes. Actually, a 3-way handshake isn't the only means of establishing a TCP connection. TCP connection is bidirectional. What this means is that it actually is a pair of one-way connections.
Two simplex connections form one duplex TCP session, agree? So logically there are four steps involved; but because SYN and ACK flags are different "fields" of TCP header, they can be set simultaneously - the second and the third steps of the four are combined, so technically there are three packet exchanges. Each simplex half- connection uses 2-way exchange, as you proposed.
It is not necessary at all. The previous answers just describe the system without discussing the need for random sequence numbers etc.
The original question was about the design of TCP itself -- obviously if you use the TCP protocol then you need three messages because that is the protocol. But why was TCP designed that way in the first place? I believe the original idea was that there was no distinction between clients and servers. Both knew the other's ports in a bidirectional manner, and either could start the conversation. And that required Syns etc. But this is not, of course, how it is used today.
The server listens on a well known port and does and "accept", the client port number is ephemeral. I do not even think it is possible for a server waiting on an "accept" to send a request to another on the same client port number in normal operating systems.
Note that this is about bidirectional initiation of the connection, which is never done today. That is quite different from sending bidirectional messages down a connection once established. But Http 1. So that protocol includes its own session reuse mechanism which runs on top of Http 1. Such is the way with software. Fudges on kludges which when combined, produce an acceptable result.
0コメント