TCP/IP Stack

  https://www.freesoft.org/CIE/RFC/1122/114.htm TCP Keep-Alives Implementors MAY include "keep-alives" in their TCP implementations, although this practice is not universally accepted. If keep-alives are included, the application MUST be able to turn them on or off for each TCP connection, and they MUST default to off. Keep-alive packets MUST only be sent when no data or acknowledgement packets have been received for the connection within an interval. This interval MUST be configurable and MUST default to no less than two hours. It is extremely important to remember that ACK segments that contain no data are not reliably transmitted by TCP. Consequently, if a keep-alive mechanism is implemented it MUST NOT interpret failure to respond to any specific probe as a dead connection. An implementation SHOULD send a keep-alive segment with no data; however, it MAY be configurable to send a keep-alive segment containing one garbage octet, for compatibility with erroneous TCP implemen...

 https://medium.com/dataseries/why-are-linux-kernel-protocol-stacks-dropping-syn-packets-5ee5cab351a6 The Per-host PAWS Check Results in the Drop of SYN Packets Symptom This is the most common problem in the actual production environment: For servers with both the net.ipv4.tcp_tw_recycle and the net.ipv4.tcp_timestamps enabled, the probability of this problem is very high when the server has NAT client access. From the client side, the symptom of this problem is that the new connection is unstable. Sometimes it can be connected and sometimes it cannot. Per-Host PAWS Principle For background information, PAWS is short for Protect Against Wrapped Sequences, which is a means for preventing sequence numbers from being wrapped. Next, Per-host checks the IP address of the peer host rather than the quad-tuples of the IP port. The way per-host PAWS checks is as follows: For the quintuple peer host IP of the TIME_WAIT socket that is quickly recycled, which helps to prevent the interference ...

As shown above, there are two queues: a SYN queue (or incomplete connection queue) and an accept queue (or complete connection queue). In the three-way handshake, after receiving a SYN packet from the client, the server places the connection information in the SYN queue and sends a SYN-ACK packet back to the client. The server then receives an ACK packet from the client. If the accept queue isn’t full, you should either remove the information from the SYN queue and put it into the accept queue, or execute as tcp_abort_on_overflow instructed. At this point, if the accept queue is full and tcp_abort_on_overflow is 0, the server sends a SYN-ACK packet to the client again after a certain period of time (in other words, it repeats the second step of the handshake). If the client experiences even a short timeout, it is easy to encounter a client exception. ss command Here, the Send-Q value in the second column is 50, indicating that the accept queue on the listen port (the third column) is 5...

  TCP FSM TCP Finite State Machine (FSM) States, Events and Transitions State State Description Event and Transition CLOSED This is the default state that each connection starts in before the process of establishing it begins. The state is called “fictional” in the standard. The reason is that this state represents the situation where there is no connection between devices—it either hasn't been created yet, or has just been destroyed. If that makes sense. J Passive Open:  A server begins the process of connection setup by doing a passive open on a TCP port. At the same time, it sets up the data structure ( transmission control block or TCB ) needed to manage the connection. It then transitions to the  LISTEN  state. Active Open, Send  SYN :  A client begins connection setup by sending a  SYN  message, and also sets up a TCB for this connection. It then transitions to the  SYN-SENT  state. LISTEN A device (normally a server) is waiti...

    Why TCP connection termination needs four-way handshake? Note that the server sends two packets:  ACK: 1  and  SYN: 1  in sequence. Why not combine these two packets into one to have a better network performance? We didn’t combine the  ACK: 1  packet (marked as ②) and the  FIN: 1  packet (marked as ③) into one packet. The reason is  ACK: 1  packet (marked as ②) is send by TCP stack automatically. And the next  FIN: 1  packet (marked as ③) is controlled in application level by calling  close  socket API. Application has the control to terminate the connection. So in common case, we didn’t merge this two packets into one. It’s flexible for the application to control this process, for example, in this way the application can reuse existing TCP connection to reduce the overhead and improve the performance. In packet 2, the server Ack’s the client Fin bit but notice that the Ack # is not incremented by 1....