Q 1: please explain what TCP is and the difference between it and UDP

TCP is a connection-oriented, reliable, byte stream – based transport layer protocol.

UDP is a connectionless transport layer protocol

Specifically, compared with UDP, TCP has three core features:

  1. Connection-oriented. The so-called connection refers to the connection between the client and the server. TCP requires three handshakes to establish the connection before the two sides communicate with each other, while UDP does not have the corresponding connection establishment process.
  2. Reliability. TCP puts a lot of effort into ensuring that the connection is reliable. In what ways is this reliability reflected? One is stateful, the other is controllable.

TCP keeps a precise record of what data is sent, received and not received, and ensures that packets arrive in sequence, with no margin of error. This is stateful.

When a packet is lost or the network environment is poor, TCP adjusts its behavior to control the sending speed or resending. It’s manageable.

Accordingly, UDP is stateless and uncontrollable.

  1. Byte – oriented stream. UDP data transmission is based on datagrams because it inherits only IP layer features, whereas TCP maintains state by turning IP packets into byte streams.

Second question: Talk about the TCP three-way handshake

What is TCP’s three-way handshake

  • In network data transmission, the transport layer protocol TCP is the reliable transmission to establish a connection. The process of TCP establishing a connection is called the three-way handshake.

Love simulation

Take romance as an example. The most important thing for two people to be together is to first confirm their ability to love and be loved. Now let’s simulate a three-way handshake.

For the first time:

M: I love you.

The woman received.

This proves that the man is capable of love.

The second:

Woman: I received your love and I love you too.

The man received it.

OK, now the situation shows that the woman has the ability to love and be loved.

The third time:

M: I received your love.

The woman received.

It is now possible to ensure that the man is capable of being loved.

Thus confirming both parties’ ability to love and be loved completely, the two begin a sweet love.

Real shake hands

In the TCP three-way handshake, two capabilities of the two parties need to be confirmed:Ability to sendandReceiving capacity. Then there is the following three-way handshake:

Both sides have been CLOSED since the beginning. The server then listens to a port and enters the LISTEN state.

Then the client initiates the connection and sends the SYN. The client becomes in the SYN-sent state.

After receiving the SYN, the server returns the SYN and ACK(corresponding to the SYN sent by the client) and changes itself to SYN-revd

The client then sends an ACK to the server and changes to the ESTABLISHED state. After receiving the ACK, the server state also changes to ESTABLISHED.

In addition, you need to pay attention to the following figure: SYN consumes a sequence number. The next ACK sequence number must be increased by 1. Just remember one rule:

The sequence number of TCP packets that need to be confirmed by the peer end must be consumed.

SYN requires confirmation from the other end, but ACK does not, so SYN consumes a sequence number that ACK does not.

Third question: why not twice?

Root cause: The receiving capability of the client cannot be confirmed

  • An invalid connection request segment may be sent to the server. > The segment of the first connection request packet sent by the client is not lost, but is detained at a network node for a long time. As a result, it is delayed to reach the server until a certain time after the connection is released. Originally, this is an invalid packet segment. However, after the server receives the invalid connection request packet segment, it mistakenly thinks it is a new connection request sent by the client. Then the client sends a confirmation message to agree to establish a connection. Assuming that the “three-way handshake” is not used, a new connection is established as soon as the server sends an acknowledgement. Since the client does not send a connection request, it ignores the server’s confirmation and does not send data to the server. However, the server assumes that the new transport connection has been established and waits for data from the client. As a result, many of the server’s resources are wasted. The three-way handshake prevents this from happening. For example, the client does not issue an acknowledgement to the server’s acknowledgement. Since the server receives no acknowledgement, it knows that the client has not requested a connection.
  • In addition, the two-handshake cannot ensure that the Client correctly receives the packet from the second handshake (the Server cannot confirm whether the Client has received the packet), nor can it ensure that the initial sequence number can be exchanged between the Client and Server

Fourth question: why not four times?

The purpose of the three-way handshake is to confirm the ability of both parties to send and receive. How about the four-way handshake?

Sure, 100 times is fine. But in order to solve the problem, three times is enough, and more is not much use.

Q 5: Can data be carried during the three-way handshake?

For the third handshake, you can carry it. The first two handshakes cannot carry data.

If the first two handshakes can carry data, the attacker only needs to send a large amount of data in the SYN packet in the first handshake to attack the server. As a result, the server consumes more time and memory space to process the data, increasing the risk of attack.

On the third handshake, the client is in the ESTABLISHED state, and you can confirm that the server is receiving and sending data properly.

Sixth question: What happens when you open it at the same time?

If SYN packets are sent at the same time, what is the status change?

This is a scenario that could happen.

The state changes as follows:

At the same time that the sender sends a SYN packet to the receiver, the receiver sends a SYN packet to the sender. Two people just got on!

After SYN is SENT, both states change to SYN-sent.

After each receives the SYN from the other, both states change to SYN-reVD.

After receiving the ACK + SYN packet, the state of the ACK + SYN packet changes to ESTABLISHED.

That’s the state transition in the simultaneous open case.

Q7: Tell me about the TCP wave four times

Process and dismantling

  1. First wave: The Client sets the FIN to 1 and sends the serial number SEQ to the Server. Enter the FIN_WAIT_1 state.
  2. Second wave: After receiving a FIN, the Server sends an ACK=1 and acknowledge number= received serial number +1. The CLOSE_WAIT state is displayed. At this point, the client has no data to send, but can still accept the data sent by the server.
  1. Third wave: The Server sets the FIN to 1 and sends a sequence number to the Client. Enter the LAST_ACK state.
  2. Fourth wave: The Client enters the TIME_WAIT state after receiving the FIN from the server. Then set ACK to 1 and send an acknowledge number= serial number +1 to the server. After receiving the acknowledge number, the server changes to the CLOSED state and does not send data to the client. The client also enters the CLOSED state after waiting 2*MSL (maximum lifetime of packet segments). Complete four waves.

Wait for 2MSL meaning

What happens if you don’t wait?

If the client does not wait, the client directly runs away. When the server still has many data packets to send to the client and the client port is occupied by a new application, the client receives useless data packets, causing packet chaos. Therefore, it is safest to wait for the packet from the server to die before starting a new application.

So, one MSL is not enough, why wait for 2 MSL?

  • An MSL ensures that the last ACK message from the active closing party in the four waves will finally reach the peer end
  • One MSL ensures that the peer end can receive FIN packets that have not received ACK retransmission

That’s what waiting 2MSL is all about.

Why four waves instead of three?

After receiving the FIN packet, the server does not return the FIN packet immediately. The SERVER sends the FIN packet only after all packets are sent. Therefore, an ACK indicates that a FIN has been received from the client, and the FIN is sent after a period of time. This creates four waves.

What’s wrong with three waves?

The server merges the ACK and FIN packets into a wave. A long delay may cause the client to mistakenly believe that the FIN has not reached the client, causing the client to repeatedly resend the FIN.

What about simultaneous closures?

What happens if the client and server send FIN at the same time? As shown in the figure:

Q: Describe the relationship between half-connection queues and SYN Flood attacks

Before the three-way handshake, the status of the server changes from CLOSED to LISTEN, and two internal queues are created: the half-connection queue and the full-connection queue, namely, the SYN queue and the ACCEPT queue.

Semi-connected queue

When a client sends a SYN to a server, the server replies with ACK and SYN, and the status changes from LISTEN to SYN_RCVD. Then the connection is pushed into the SYN queue, also known as the half-connection queue.

Full connection queue

When the client returns an ACK and the server receives it, the three-way handshake is complete. At this point, the connection wait will be picked up by the specific application. Before being picked up, it will be pushed to another TCP-maintained Queue, namely the Accept Queue.

Mechanism of SYN Flood attacks

SYN Flood attacks are typical DoS/DDoS attacks. The attack is based on the simple principle of using a client to forge a large number of non-existent IP addresses in a short period of time and frantically sending SYN to the server. For the server side, there are two dangerous consequences:

  1. Deal with a large number ofSYNPackage and return correspondingACKThere are bound to be a large number of connectionsSYN_RCVDState to fill the wholeSemi-connected queueUnable to process normal requests.
  2. Because the IP address does not exist, the server cannot receive the IP address from the client for a long timeACK, causing the server to continuously resend data until the server resources are exhausted.

How do I cope with SYN Flood Attacks?

  1. To increase SYN connections, you increase the capacity of the half-connection queue.
  2. Reduces the number of SYN + ACK retries to avoid a large number of timeout retries.
  3. Using the SYN Cookie technology, it is received on the serverSYNAfter the connection resources are not allocated immediately, but based on thisSYNComputes a Cookie and replies to the client with a second handshake, replies to the clientACKTake this with youCookieValue, the server verifies that the Cookie is valid before allocating connection resources.

Question 9: This section describes the fields in the TCP packet header

The header structure is as follows (in bytes):

Please remember this picture!

Source port, destination port

How to uniquely identify a connection? The answer is a quad of TCP connections — source IP, source port, destination IP, and destination port.

How come TCP packets have no source and destination IP addresses? This is because IP is already handled at the IP layer. TCP only needs to record the ports of both.

The serial number

The Sequence number is the Sequence number of the first byte in the column

As you can see from the figure, the serial number is an unsigned integer with a length of 4 bytes, that is, 32 bits, representing the range of 0 to 2^ 32-1. If it reaches its maximum then it loops to zero.

Serial numbers play two roles in TCP communication:

  1. Initial sequence numbers are exchanged in SYN packets.
  2. Ensure that packets are assembled in the correct order.

ISN

The Initial Sequence Number is the Initial Sequence Number. During the three-way handshake, SYN packets are exchanged between the two parties to exchange the ISN.

The ISN is not a fixed value, but increments by one every 4 ms, returning to 0 when overflow occurs. This algorithm makes guessing the ISN difficult. Then why are we doing this?

If the ISN is predicted by an attacker, both the source IP address and the source port number can be forged easily. After an attacker guesses the ISN, he can forge an RST to force the connection to be closed, which is very dangerous.

Dynamically increasing ISN greatly increases the difficulty of guessing ISN.

Confirmation no.

The ACK (Acknowledgment number). It is used to tell the other party that the next expected sequence number has been received. All bytes less than ACK have been received

Flag bit

Common flag bits are SYN,ACK,FIN,RST, and PSH.

SYN: indicates a synchronization sequence number, indicating that this is a connection request packet. ACK: the acknowledgment character. FIN: Finish: indicates that the sender is ready to disconnect. RST: Reset is used to forcibly disconnect the connection. PSH: indicates that the data packets should be sent to the upper-layer application immediately after they are received and cannot be cached.

Q: How does TCP open quickly?

The first section talked about TCP three handshakes, some people may say, every three handshakes good trouble! Can you make it better?

B: yes, you can. Today, I’ll talk about this optimized TCP handshake process, also known as TCP Fast Open (TFO).

The process of optimization is as follows: Remember SYN cookies when we said SYN Flood attacks? This Cookie is not a browser Cookie and can also be used to implement TFO.

TFO process

First round of three handshakes

First the client sends the SYN to the server, which receives it.

Pay attention to oh! Now, the server does not reply with SYN + ACK immediately. Instead, it calculates a SYN Cookie, puts the Cookie in the Fast Open option of the TCP packet, and then returns the PACKET to the client.

The client takes the value of the Cookie and caches it. Then complete the normal three handshakes.

This is how the first three handshakes go. The next three handshakes are different!

The next three handshakes

In the next three handshakes, the client sends cached cookies, SYN, and HTTP requests (yes, you read that right) to the server, which verifies that the Cookie is valid and discards it if it is not. If it is valid, SYN + ACK is normally returned.

The point is, the server can now send HTTP responses to the client! This is the most significant change, since the three-way handshake has not yet been established and the Cookie is only validated to return an HTTP response.

Of course, the ACK from the client has to be transmitted normally, otherwise it is not called the three-way handshake.

The process is as follows:

Note: The ACK of the last handshake from the client does not have to wait for the HTTP response from the server to arrive before being sent; there is no relationship between the two processes.

The advantage of TFO

The advantage of TFO is not in the first three handshakes, but in the later handshake. After getting the Cookie from the client and passing the verification, IT can directly return the HTTP response, making full use of one RTT(round-trip Time) for data transmission in advance. It adds up to a big advantage.