TCP
(1) In which stage of the three-way handshake does TCP accept occur?
The relationship between connect and accept is shown below:
The accept process occurs after the three-way handshake. After the three-way handshake is completed, the client and the server have established a TCP connection and can exchange data. At this time, you can call the accept function to obtain this connection.
(2) If connect returns, can it be considered that the connection is successful?
After connect returns successfully, the three-way handshake is completed. The completed link will be put into a queue. The function of accept is to take out the link with the highest priority from the connected queue and bind it to a new fd. The server can use this new fd to recv and send data.
(3) Can data be carried during the three-way handshake?
You can carry it with you when you shake hands for the third time. The first two handshakes cannot carry data. If the first two handshakes can carry data, then once someone wants to attack the server, he only needs to put a large amount of data in the SYN message in the first handshake, and the server will inevitably consume more time and memory space to process these. data, increasing the risk of server attacks. During the third handshake, the client is already in the ESTABLISHED state and has been able to confirm that the server's receiving and sending capabilities are normal. At this time, it is relatively safe and can carry data.
(4) What is the meaning of waiting for 2MSL? What will happen if you don’t wait?
If you don't wait, the client will run away directly. When the server still has many data packets to send to the client and is still on the way, if the client's port happens to be occupied by a new application at this time, useless data will be received. packets, causing data packet confusion. Therefore, the safest way is to wait until all data packets sent by the server are dead before starting a new application. Then, wouldn’t one MSL be enough? Why wait for 2 MSL?
- 1 MSL ensures that the last ACK message of the actively closing party in the four waves can finally reach the opposite end.
- 1 MSL ensures that the peer does not receive ACK and the retransmitted FIN message can arrive
This is what waiting for 2MSL means.
SYN flood attack
(1) SYN Flood attack principle SYN Flood is a typical DoS/DDoS attack. The principle of the attack is very simple, which is to use the client to forge a large number of non-existent IP addresses in a short period of time and send SYN wildly to the server. For the server, there will be two dangerous consequences:
- To process a large number of SYN packets and return corresponding ACKs, there will inevitably be a large number of connections in the SYN_RCVD state, thus filling the entire semi-connection queue and unable to process normal requests.
- Because it is a non-existent IP, the server cannot receive the ACK from the client for a long time, which will cause the server to continuously resend data until the server's resources are exhausted.
(2) How to deal with SYN Flood attacks?
- Increasing SYN connections means increasing the capacity of the semi-connection queue.
- Reduce the number of SYN + ACK retries to avoid a large number of timeout retransmissions.
- Utilizing SYN Cookie technology, the server does not allocate connection resources immediately after receiving the SYN. Instead, it calculates a cookie based on the SYN and replies it to the client along with the second handshake. When the client replies with ACK, it brings this cookie value. , the server verifies that the cookie is legal before allocating connection resources.
（3）TCP Fast Open
Note: The client's final handshake ACK does not have to wait until the server's HTTP response arrives before being sent. The two processes have nothing to do with each other. During the first handshake, the server will calculate the cookie and pass it to the client and cache it. In subsequent handshakes, the client will carry the cookie for SYN. If the cookie is illegal, it will be discarded directly. If it is legal, the http response can be sent directly. (4) Advantages of TFO The advantage of TFO does not lie in the first three-round handshake, but in the subsequent handshakes. After getting the client's Cookie and passing the verification, it can directly return the HTTP response, making full use of 1 RTT (Round-Trip Time, round-trip delay) time to transmit data in advance, which is a relatively big advantage cumulatively.
(5) What to do if the serial number wraps around?
Now let's simulate this problem. The range of the serial number is actually 0 ~ 2 ^ 32 - 1. For the convenience of demonstration, let's narrow this range. Assume the range is 0 ~ 4, then it will return to 0 when it reaches 4.
Assume that at the 6th time, the packet that was still stuck in the network comes back, then there will be two data packets with sequence numbers 1 ~ 2. How to distinguish who is who? At this time, the problem of serial number wraparound arises. Then using timestamp can solve this problem very well, because every time a packet is sent, the core time of the sending machine at that time is recorded in the message, so even if the sequence number of the two packets is the same, the timestamp cannot be the same, so You can distinguish the two data packets. Attachment: timestamp is an optional option in the TCP message header. It occupies a total of 10 bytes and has the following format:
kind(1 字节) + length(1 字节) + info(8 个字节)Among them, kind = 8, length = 10, info consists of two parts: timestamp and timestamp echo, each occupying 4 bytes.
Information Direct: Linux kernel source code technology learning route + video tutorial kernel source code
Learning Express: Linux Kernel Source Code Memory Tuning File System Process Management Device Driver/Network Protocol Stack
Can you talk about Nagle's algorithm and delayed confirmation?
(1) Nagle Algorithm Imagine a scenario where the sender keeps sending very small packets to the receiver, only sending 1 byte at a time. Then it takes 1,000 times to send 1,000 bytes. This kind of frequent sending is problematic. Not only is the transmission delay consumed, but the sending and confirmation itself is also time-consuming. Frequent sending and receiving brings huge delays. To avoid frequent sending of small packets, this is what the Nagle algorithm does. Specifically, the rules of Nagle's algorithm are as follows:
- There is no need to wait when data is sent for the first time, even a 1-byte packet is sent immediately.
- Subsequent transmissions can be sent if one of the following conditions is met: the ACK of all packets before the data packet size reaches the Max Segment Size (MSS) has been received.
(2) Delayed confirmation Imagine this scenario. When I receive a packet from the sender, and then receive a second packet in a very short period of time, should I reply one by one, or should I wait a little and send the two packets together? How about merging the ACKs of the packets and replying together? What delayed acknowledgment does is the latter, delay it slightly, then merge the ACK, and finally reply to the sender. TCP requires that this delay must be less than 500ms, and general operating system implementations will not exceed 200ms. However, the important thing is that there are some scenarios where confirmation cannot be delayed. You must reply immediately after receiving it:
- A message larger than one frame was received and the window size needs to be adjusted.
- TCP is in quickack mode (set via tcp_in_quickack_mode)
- Out-of-order packets found
What happens when the two are used together? The former means delayed transmission, and the latter means delayed reception, which will cause greater delay and cause performance problems.
The difference between TCP’s Keep Alive and HTTP’s Keep Alive
TCP keepalive
- How do you know that the other party is still alive when there is no communication between the two parties for a long time? How do you know that this TCP connection is healthy and capable of communication?
- The keep-alive mechanism of TCP is used to solve such problems.
- The keep-alive mechanism is turned off by default, and any party in the TCP connection can turn this feature on.
- If the peer is alive normally and the connection is valid, the peer will definitely receive the probe message and respond. At this time, when the sender receives the response message, it proves that the TCP connection is normal and the keep-alive time counter can be reset.
- If due to network reasons or other reasons, the sending end cannot normally receive the response to the keep-alive detection message. Then after a certain detection interval (tcp_keepalive_intvl), keepalive detection messages will continue to be sent. No response is received from the peer until a response is received from the peer, or the configured maximum number of probe cycles (tcp_keepalive_probes) is reached. At this time, the peer will be considered unreachable, and the TCP connection still exists but has expired, and the connection needs to be interrupted. .
HTTP keep-alive
- keep-alive mechanism: If enabled, in an http request, after the server responds, it will no longer directly disconnect the TCP connection, but maintain the TCP connection for a period of time. During this period, if the same client initiates an http request to the server again, it can reuse the TCP connection, initiate a request to the server, and reset the timeout time counter, and it can continue to be reused in the next period of time. . This undoubtedly eliminates the loss of repeatedly creating and destroying TCP connections.
TCP head-of-line blocking and HTTP head-of-line blocking
1. TCP queue head blocking TCP data packets are transmitted in order. If a data packet in the middle is lost, it will wait for the data packet to be retransmitted, causing subsequent data packets to be blocked. (Stop waiting) 2. HTTP head-of-line blocking HTTP head-of-line blocking and TCP head-of-line blocking are completely different. http1.x uses long connections (Connection:keep-alive), which can send multiple http requests on one TCP request. There are two ways: unpipelined and piped. Non-pipelined , completely serial execution, request->response->request->response..., the latter request must be sent after the previous response. Pipelining , requests can be issued in parallel, but responses must be returned serially. The latter response must follow the previous response. The reason is that there is no serial number indicating the order and can only be received serially. The fatal weakness of pipelined requests:
- It will cause the head of the queue to be blocked. The previous response is not returned in time, and subsequent responses are blocked.
- The request must be idempotent and cannot modify resources. Because, when unexpectedly interrupted, the client needs to resend the request that has not received a response. Non-idempotent requests will cause resource damage.
For this reason, most browsers and web servers currently turn off pipelines and adopt non-pipeline mode. Whether it is non-pipelined or pipelined, it will cause head-of-line blocking (request blocking). Methods to solve the http queue head blocking: 1. Concurrent TCP connections (the browser uses 6-8 TCP connections for one domain name to concurrently make HTTP requests) 2. Domain name fragmentation (multiple domain names can establish more TCP connections, thereby improving Concurrency of HTTP requests) 3. HTTP2 mode http2 uses a domain name and a single TCP connection to send requests, and the request packets are binary framed** (multiplexed)** Different requests can be interspersed with each other, avoiding request queue head blocking at the http level . But head-of-line blocking at the TCP level cannot be avoided.
UDP
How does UDP achieve reliable transmission?
The transport layer cannot guarantee reliable transmission of data and can only be achieved through the application layer. The implementation method can refer to the tcp reliable transmission method, except that the implementation is not in the transport layer, and the implementation is moved to the application layer. The simplest way is to imitate the reliable transmission of TCP at the transport layer at the application layer. The following does not consider congestion handling, a simple design of reliable UDP.
- Add seq/ack mechanism to ensure data is sent to the peer
- Add sending and receiving buffers, mainly for user timeout retransmission.
- Add timeout retransmission mechanism.
Detailed description : When the sender sends data, a random seq=x is generated, and then each slice is allocated seq according to the data size. After the data reaches the receiving end, the receiving end puts it into the cache and sends an ack=x packet to indicate that the other party has received the data. After receiving the ack packet, the sender deletes the data corresponding to the buffer. After the time is up, the scheduled task checks whether the data needs to be retransmitted.
Original author: Learn embedded together
