1. TCP concepts
[! NOTE]
TCP (Transmission Control Protocol), also known as Transmission Control Protocol.
TCP protocol is connection-oriented, reliable byte stream-based transport protocol. Based on TCP when communicating, communicating parties need to establish a TCP connection, the three-way handshake to establish a connection to go through, when disconnected from the need to go through four wave.
1.1 TCP header
For the TCP header, the following fields are important:
序列号(Sequence number), the TCP sequence number to ensure that the packets are transmitted in order, by splicing the end of the packet sequence number确认号(Acknowledgement Number), this number represents a number of bytes of data received by the receiving end is a desired number, a serial number also represents the data has been received窗口大小(Window Size), also indicates how many bytes of data received, for flow control标识符- ACK = 1: This field indicates a valid acknowledgment number field is. In addition, TCP also provides all the segments transmitted after the connection must be set to an ACK.
- SYN = 1: When SYN = 1, ACK = 0, indicates that the current segment is a connection request packet. When SYN = 1, ACK = 1, indicates that the current segment is agreed to establish a response packet connection.
- FIN = 1: Indicates that the field is a segment release request message is a connection.
- URG = 1: This field is a part of the data representing the data packet contains emergency information, is a high priority data packets, urgent pointer is valid at this time. Some emergent data positioned at the head of the current packet data portion, urgent pointer indicating the tail of urgent data.
- PSH = 1: This field indicates a receiving terminal should immediately push data to the application layer, rather than waiting until the buffer is full before submitting.
- RST = 1: This field indicates the current TCP connection is a serious problem, you may need to re-establish a TCP connection can also be used to reject illegal segments and rejects the connection request.
1.2 three-way handshake
simply put:
- The first handshake
- SYN = 1， seq(client) = x
- The client sends a connection request to the server segment. In packet data communications segment comprising its initial sequence number. After sending the request, the client will enter the SYN-SENT state.
- The second handshake
- SYN = 1, ACK = 1, confirm the number = x + 1, seq (server) = y
- After the server receives a connection request message segment, if the agreed connection, an acknowledgment is sent, the reply also contains its own data in the initial communication sequence number after transmission completion state into the SYN-RECEIVED
- Third handshake
- ACK = 1, confirm the number = y + 1, seq (client) = x + 1
- After the client receives the response connection agreement, but also to send to the server a confirmation message. Client End made this segment after entering ESTABLISHED state, the server receives this response also after entering ESTABLISHED state, then the connection is established.
1.3 Why not use two-way handshake?
[! NOTE]
mainly to prevent the connection request has failed packet suddenly transmitted to the server, resulting in an error.
Consider a scenario, the first client sends a request and the connection is not lost, but the residence time is too long. Because TCP client has yet to receive a confirmation message, that server does not receive, then resend the message to the server.
And now the first request arrives at the server, the request has been scrapped, but will establish a connection.
If a three-way handshake, even if it is a failure message sent over, the service termination by the failure of a piece of the message and reply confirmation message, but the client does not send a confirmation again. Since the server does not receive confirmation, we know that the client did not request a connection.
1.3 Why is a three-way handshake to establish a connection, it can not be four times
The first handshake:
Client什么都不能确认
Server确认了对方发送正常The second handshake:
Client确认：自己发送/接收正常，对方发送/接收正常
Server确认：自己接收正常 ，对方发送正常Third handshake:
Client确认：自己发送/接收正常， 对方发送/接收正常
Server确认：自己发送/接收正常，对方发送/接收正常So confirm the sender and receiver functions are normal through the three-way handshake, but can also be four times seemed more superfluous
Four waving 1.4
TCP is a full-duplex, and both ends need to send FIN ACK while disconnected.
- The first wave
- If Client A that the data transmission is completed, it needs to send a connection release request to the server B.
- The second wave
- After B receives the connection release request, it will tell the application layer to release the TCP connection. Then sends an ACK packet, and enters CLOSE_WAIT state, A to B represents the connection has been released, A does not receive the data sent. However, because the TCP connection in both directions , it can still transmit data B to A.
- Third Wave
- If B is not finished at this time there will continue to send data, it sends a connection release request, then B to A will enter After completion of the LAST-ACK state.
- PS: by delaying confirmation of Technology (usually time-limited, or it will mistakenly believe that needs to be retransmitted), second and third handshake can be combined to delay the sending ACK packets.
- Fourth Wave
- A release request is received after sending an acknowledgment to the transponder B, this time into the A TIME-WAIT state. The state will continue 2MSL (maximum segment lifetime, time refers to the segment live in the network, the timeout will be abandoned) time, if the time period does not request retransmission of B, then it enters the CLOSED state. When B receives the acknowledgment, it will enter the CLOSED state.
Why A 1.5 To enter the TIME-WAIT state, waiting time before entering the 2MSL CLOSED state?
In order to ensure that B can receive confirmation A response. Direct access to the CLOSED state if A finished the acknowledgment, the acknowledgment because if the network problem has not been reached, will cause B can not be closed properly.
If A is sending the ACK directly to the CLOSED state after the response, and if the network delays the response is lost or in 2MSL has not reached B, then the following B wait timeout will re-send a FIN packet, but this time A has been closed , and never get a response a, resulting in B never closed properly
1.6 Why TIME_WAIT state
1.6.1 In order to achieve reliable release of this full-duplex TCP connection
This allows TCP to send the final ACK ACK prevent this loss (the other end of the timeout and retransmit the final FIN) 2MSL wait another result of this is that during the TCP connection waits 2MSL, define the socket (customer IP connections address and port number, IP address of the server and port number) can no longer be used. This connection can only be used again after the end of 2MSL.
1.6.2 To make the old packets in the network due to expire and disappear
Each specific TCP implementation must select a maximum segment lifetime MSL. It is the longest time before any segments are discarded within the network.
1.7 Why is a three-way handshake to establish a connection, close the connection is indeed four times waving it?
After the connection is established, the server in the LISTEN state, receiving the SYN packet to establish a connection request, and the SYN ACK packet was sent on to a client.
And when the connection is closed, the server receives each other's FIN message that just means the other party no longer send data but also receive data, while he may not have all the data is sent to the other party
2. ARQ (retransmission timeout) protocol
[! NOTE]
by acknowledgments and timeouts mechanism ensures correct delivery of data, ARQ protocols include停止等待 ARQand连续 ARQ
2.1 ARQ stop waiting
Normal transfer process
A long period of sending messages to B, must stop transmitting and starts a timer and wait for the end of the response, received peer response to cancel the timer and sends the next packet within the period of time the timer.
When packet loss or error:
In the process of packet transmission loss: this time over timer set time loss of data will be sent until the end of the response, so it is necessary to send the data every time the backup again.
Error messages during transmission: The end will abandon the message and waits for the A-side retransmission.
PS: General timer set time will be greater than the average time of a RTT.
ACK timeout or missing:
Response to the end of the transmission may also be the case of loss or timeout occurs. So over time A timer end will still be retransmitted packets. This time terminal B received the same number of packets and retransmitting the packet discards the response until the next sequence number A sends the packet.
The disadvantage of this protocol is the transmission efficiency is low, in good network environment have to wait for each message sent to the end ACK.
2.2 Continuous ARQ
In continuous ARQ, the transmit end has a transmission window, the data can be continuously transmitted within the window in the case where no response is received, so compared to the stop and wait ARQ protocol can reduce waiting time and improve the efficiency.
2.2.1 Cumulative confirmed
Continuous ARQ, the receiving end will continuously receive messages. If you stop and wait ARQ receiving a message is sent as a reply, it is a waste of resources. By cumulative confirmed that a reply can be unified response packet after receiving multiple messages. The ACK packet may be used to tell the end of data transmission before all the sequence number has been received, the next send data sequence number + 1.
However, there are a total of confirmed drawbacks. In continuous receive messages, you may experience after receiving the packet sequence number 5, has not received the packet sequence number 6, but No. 7 after the message has been received. When this happens, ACK can only reply 6, this will cause the sender to send duplicate data, in this case can be resolved by Sack.
2.2.2 sliding window
The above mentioned transmission window. In TCP, the window maintains both ends: respectively sending side window and a receive window.
The sender window containing the data was sent but not received a response and can be sent but the data is not sent.
The transmitting end is determined by the window size of the reception window remaining. Receiver will receive window size of the current remaining write response packet sender receives a response after transmitting window disposed according to the value and size of the current network congestion, the size of transmitting window is constantly changing.
When the sender receives the reply message, it will follow the sliding window
Sliding window flow control realized . Receiver via messages inform the sender how much data can also be sent, in order to ensure that the receiver can receive the data in time.
Zero window
In the process of sending messages, you may encounter zero window that appears to end. In this case, the sender stops sending data and starts persistent timer. The timer periodically sends a request to the peer so that the peer inform the window size. After more than a certain number of retries, TCP may break the link.
3. congestion handling
[! NOTE]
congestion and flow control process different from the latter acting on the receiving side, the receiver enough time to guarantee to accept data. While the former is the role of the network, to prevent excessive congestion data networks to avoid an overload situation.
Congestion process includes four algorithms, namely: slow start, congestion avoidance, fast retransmit and fast recovery.
3.1 slow start algorithm
[! NOTE]
slow start algorithm, by definition, will be sent at the beginning of the transmission window exponentially expand starting from 1, in order to avoid transmission of large amounts of data outset lead to network congestion.
Slow Start algorithm steps as follows
- Initial connection setting a congestion window (Congestion Window) is 1 MSS (maximum amount of data in one segment)
- Each had a RTT (Round Trip Delay) will window size times two
- Exponential growth is certainly not without limit, so there is a threshold limit, when the window size is greater than the threshold value will start congestion avoidance algorithm
3.2 Congestion Avoidance Algorithm
[! NOTE]
congestion avoidance algorithm compared to a simple point, with every passing RTT plus a window size only, so to avoid the exponential growth of network congestion, slowly adjust the size to an optimum value.
During transmission case might timer expires, the TCP would think that this time the network congestion, will immediately carry out the following steps:
- The threshold is set to half of the current congestion window
- The congestion window to 1 MSS
- Start Congestion Avoidance Algorithm
3.3 fast retransmit
Fast retransmission and fast recovery usually appear together. The case of the receiver can receive messages appear out of order, the receiver will only respond to the correct order of the last packet sequence number (without the Sack). If you receive three duplicate ACK, without waiting for the retransmission timer expires again but start fast retransmission. The algorithm is divided into two types:
4. TCP Summary
4.1 TCP Why so complicated?
[! NOTE]
because it is necessary to ensure reliability, while also improving performance as much as possible
4.1.1 ensure the reliability of mechanisms
- Checksum
- Sequence number (sequential arrival)
- The acknowledgment
- Retransmission timeout
- Connection Management
- flow control
- Congestion Control
4.1.2 improve the performance of the mechanism
- Sliding window
- Fast retransmit
- Delayed Answer
- Piggybacking
4.2 Timer
- Timeout retransmission timer
- Keep-alive timer
- TIME_WAIT timer
4.3 TCP-based application layer protocol
- HTTP
- HTTPS
- SSH
- Telnet
- FTP
- SMTP