table of Contents
TCP three-way handshake
1: The figure in the Glossary
- SYN: synchronous serial number.
它表示建立连接. Since TCP SYN = 1:00 can not carry data, but consumes a serial number, thus randomly select a sequence number seq = x data packets (the data package is a labeled SEQ, and there is no valid data) - ACK: acknowledgment number.
它表示响应(It is certainly able to respond to the last step on the connection is successful, ah, so that ACK = 1 representative confirmed the connection is successful it)
Accordingly, the SYN and ACK are 1, after the connection setup response indicates; but only a single SYN = 1, represents only a connection
- seq: (sequence number) sequence number. It is the end of packet transmission the initial sequence number.
seq=x 表示发送端数据包的初始序号为x(Seq = 0 represents the resolution which is 0) - ack: (acknowledge number) confirmation number. It is to confirm the receipt of the packet, as well as expectations for the next received packet.
ack=x+1表示 我方 到 x为止的所有数据都已正确收到，且我方告知 对方：我期待你下次给我发送包的初始序号(seq)是x+1
In order to facilitate memory, can be understood: SYN / ACK TCP protocol level mark, while seq / ack data level mark
2: TCP three-way handshake
- Client first sends a connection to Server: SYN = 1, seq = x;
因为To建立连接，所以SYN=1;又因为the TCP predetermined SYN = 1 can not carry data, but consume a sequence number,所以Client randomly picks a初始序号seq=x. (Because there is no response action, so there is not anything ACK, ACK = 0 we think of it)- After sending the Client enter syn_sent state, it indicates that the client waits for the server's reply.
- Server receives a request then sends an acknowledgment to Client: SYN = 1, ACK = 1, seq = y, ack = x + 1;
- Because Server responded after establishing connection, SYN = 1, ACK = 1. Because the predetermined TCP SYN = 1 can not carry data, but consumes a serial number, the Server a randomly selected initial sequence number seq = y. And because all of the data up to x Server have been correctly received, and told Server Client: I look forward to the initial sequence number you're next to me send packets (seq) is x + 1, so ack = x + 1
- After entering SYN_RCVD transmission server, indicating that the server has received a connection request of Client, the Client Request.
- Client needs to receive a confirmation acknowledgment retransmission, while carrying data to be sent to Server: ACK = 1, seq = x + 1, ack = y + 1; connection establishment
- Because of the response action, so ACK = 1 (because to carry data to be transmitted, so what happened here did not SYN). Because (2) in the Server has been told it would like to receive a package of initial sequence number is x + 1, so the initial sequence number seq = x + 1. Client and since all data have been correctly received up to y, and ready to receive the packet sequence number y + 1, so ack = y + 1
- After Server receives, the TCP connection enters the Established status, you can initiate a http request.
3: Why can not change the two-way handshake?
Some people may be puzzled why the three-way handshake it (twice to confirm)? This is mainly to prevent the connection request has failed packet is transmitted to the suddenly, resulting in an error.
Assuming that A sends a connection request to B, for some reason, it causes the connection request A issued by a network node stayed more time. A case will be treated as an invalid connection request this again initiate a new connection request to B, B to normal after receiving the connection request to establish a connection, data transfer is completed after the connection is released. If the first request is issued at this time A and reached the B, B would think A has initiated a connection request, if it is two-way handshake: connection is established at this time, B will wait A sends data to be wasted B's resources. If the three-way handshake: Since A is not a connection request, it will not bother connection response of B, B of A does not receive acknowledgment connection, this connection will be closed off