preface
Last time we talked about HTTP, we know that HTTP is based on TCP, let’s take a look at this picture:
HTTP is an application-layer protocol and TCP is a transport layer protocol. HTTP is built on TOP of TCP as an upper-layer protocol. Of course, you can see that the transport layer protocol has a brother called UDP, this guy is often compared to TCP, this article will not tell, want to know about it, ok, let us directly into the body of it.
tcp
Transmission Control Protocol (TCP) is a connection-oriented, reliable, byte stream based transport layer communication Protocol
Transport is like when we buy a package and it’s delivered to us by a vehicle, the vehicle is TCP, and when it’s delivered to us TCP does its job, and then HTTP does the rest, and that’s what transport layer protocols do.
If you really want to dig into TCP, I’m afraid you won’t get the hang of it for a while. So let’s talk about TCP in terms of its two main features: connection-oriented and reliable. Let’s start this article by talking about this connection-oriented feature of TCP.
What is connection-oriented? It means that the communication parties have to establish a connection channel first.
Speaking of connection-oriented, what do you think of, yes, that one? That one?
The famous TCP three handshake!! Does the interviewer ask you a lot of questions in every interview? Here it is:
Let’s visualize the three-way handshake, which can be simulated using a phone call:
1, the client said: server brother hello, I am the client, can you hear me?
2, the server said: client brother hello, I am the server, I can hear you, can you hear me?
3, client said: server brother, I can hear you.
Ok, connection established, let’s chat….
Message structure
To start with the three-way handshake, let’s look at something: TCP data packets
A TCP packet is a data unit transmitted at the TCP layer. It is also called a packet segment. A complete packet structure consists of a header and data.
Source port
The 16-bit port number of the application on the source computer.
Destination port
The 16-bit application port number of the target computer.
Seq (Sequence Number)
The 32-bit serial number indicates the number of the first byte of the transmitted data segment. In TCP connections, each byte of the transmitted byte stream is sequentially numbered seq to maintain the order of the transmission. If SYN is 1, the initial sequence number (ISN) is synchronized.
ack(Acknowledgment Number)
32-bit acknowledgement sequence number, which indicates the number of the first byte of data that the receiver expects to receive from the sender in the next message segment. A white dot is the serial number (SEQ) that the receiver wants the sender to send to me next time it sends a packet.
Sign a
The flag bit indicates the behavior of the paper, occupying 1 bit. This paper will first talk about the following four flag bits:
SYN
Synchronization flag bit. When SYN=1, a new connection is initiated.
ACK
Acknowledgment flag bit. The acknowledgment number field (ACK) is valid only if ACK=1. When ACK=0, the ACK number is invalid. TCP specifies that the ACK number must be 1 after the connection is established.
PSH
Push flag tells the other party whether to immediately push the data to the upper layer after receiving the message. A value of 1 indicates that the data should be submitted to the upper layer immediately rather than cached.
FIN
Flag whether data has been sent. If FIN=1, data has been sent and the connection can be released.
Options: Options field, variable length, TCP header can have up to 40 bytes of optional information for passing additional information.
Data: Indicates the data field carried by the packet.
Note: Window size, TCP checksum, and emergency pointer fields are beyond the scope of this article.
State that
CLOSED: indicates the initial CLOSED state
LISTEN: Server listening status (waiting for client connections)
SYN_RECEIVED(SYN_RCVD): The server receives the SYN from the client
SYN_SENT: SYN is sent by the client
ESTABLISHED: indicates that the connection is ESTABLISHED
The above understanding of the packet structure and TCP connection process several states, combined with the above picture of the three-way handshake, let’s formally understand:
Three handshake process
1. The first handshake: the client sends a SYN to the server, indicating that it wants to establish a connection and enters the SYN_SENT state.
2. Second handshake: After receiving the request, the server replies with SYN + ACK to the client, indicating that it confirms the request. At this time, the server enters the SYN_RCVD state.
3. Third handshake: The client receives a SYN + ACK packet and sends an ACK packet to the server. The client enters the ESTABLISHED state.
The TCP connection succeeds, and the client and server start to transfer data.
That’s it. I’m sure you’ll be able to argue with the interviewer, too. You think you’re done with three handshakes? What? You’re still too young to be asked: Why three handshakes? What about two or four times?
Why three handshakes?
1. Determine whether the communication parties have the ability to send and receive
Huh? If it’s a second handshake, if you look at the three handshakes above,
In the first handshake, the client sends a SYN packet to the server. In the second handshake, the server replies with ACK+SYN. This indicates that the client can confirm the server’s ability to receive and send packets.
But if it’s just two handshakes, then the question is, yes, the client can confirm that the server has the ability to send and receive, but can the server confirm that the client has the ability to send and receive? You can’t confirm it, because you can’t get the client’s confirmation reply, and the server doesn’t know whether it’s successful or not.
2. Determine the initial serial number of both parties
As you can see from the picture, the three-way handshake is a process of telling each other the initial sequence number (ISN) and confirming that the ISN has been received.
If there is only two handshakes, only the start sequence number of the client is confirmed, but the sequence number of the server is not.
Uh… How do you explain this? We know that in order to maintain TCP order, the packet header needs to rely on SEQ to maintain order. Therefore, both parties must agree on an initial sequence number when establishing a connection, and subsequent communication depends on this initial sequence number to ensure order on the byte stream.
If you can’t keep the order, there may be data loss, or out of order resulting in data errors and a series of problems, the following can’t play.
If three times gets you there, why do it a fourth time? A waste of resources?
Finally, the reason for the need for a three-way handshake is that TCP needs to be reliable, whether it is to ensure that both parties have the ability to receive and send, or to keep byte stream transmission in order.
conclusion
In this article, we introduce the TCP three-way handshake process and the necessity of the three-way handshake based on TCP’s connection-oriented features. Next time we will talk about the second feature of TCP, reliability, stay tuned!
