How much do you know about TCP
It is often found in the front end interview group that someone will meet the interviewer to ask questions about TCP handshake and wave, such as do you know TCP, explain TCP three-way handshake and four-way wave, I think it is really meaningful to simply understand these two questions? So, try to learn a little bit more about network communication. Remember when I was in my last company, there was a brother who said that network communication is actually quite important. After all, we are basically living and working on the Internet now, especially as developers, we are basically dealing with HTTP requests every day. So it is necessary to understand the principle of network transmission. Let’s take a look at the content of network transmission in depth.
base
OSI(Open Systems Interconnection) network layering
From top to bottom:
7. Application Layer
6. Presentation
5. Session Layer
4. Transport layer
3. Network layer — router
2. Data Link layer — switch
1. Physical layer — network adapter, Hub
Wireshark: Wireshark: Wireshark: Wireshark: Wireshark: Wireshark: Wireshark: Wireshark: Wireshark Download to here, open a download, download your system can be used, all the way to complete the installation, then we start a combat capture package.
caught
Here I use baidu’s home page to do a packet capture experiment, first to set up a filter
Ok to see the IP is 180.97.33.108
Then go to the Wireshark to set the queried IP address
tcp base
Take a look at the TCP header packet structure
As we all know, the biggest difference between TCP and UDP is that TCP is stable and ordered. SEQ can ensure order. When A sends A packet to B, SEQ will be superimposed. Each transmission party will bring this information when transmitting data, and the other end can sort the order of receiving information according to this serial number, never ensuring that the transmission of information is orderly, and can also confirm whether there is packet loss through it; In addition to pay attention to when data needs to be sent, seq can follow the serial number as the origin, each byte of data will be sent to myself for number, such as the current seq = 10, this to send packet size is 200 bytes, so the actual sending will update seq = 210, in order to ensure the transmission of the data sequence;
3. Acknowledge number (” ACK “) as a reply to seQ (” seQ +1 “).
4. Windown stands for sliding window, which is actually represented by WIN. The size of WIN is very important. But WIN gets smaller with each packet sent (explained later);
5. Reserved is an important role in TCP transmission. The responder will perform corresponding operations according to the signal given by the other party.
I don’t want to introduce the basic content too much, but if you don’t understand it, you can move on and look at the concept first, and then we will introduce it based on the actual situation
Three handshakes (knocks on the blackboard)
A: B, hello, I am A requesting to establish A connection. My SEQ is 0, and my WIN is 65535. I hope the length of my response len is 0, and the maximum content I can receive is 1460, over. B: A, how are you, received your information, I am B, I the seq is 0 (note that the serial number is A independent calculation, here are starting from 0), I respond to your ack is 1 (on behalf of A seq + 1, I received you news of seq is 0), my window size is 8192, I want you to respond to this message I len is zero, The maximum response size I can receive on my end is 1452, over; A: OK, I received your response, now I send you seq is 1(0 last time, 1 this time), I reply you ack is 1(SEq +1 of B), my current window size is 25984, I want the response length to be 0; We’ve established a connection, over;
At this point, the complete three-way handshake is done, and then you can do some other data transfer, and at this point, I don’t know if you’ve ever wondered why it takes three handshakes to establish a connection, not one, not two, not four,
First of all, you can’t do it once, because if you do it once, you can’t confirm the situation of the other party, so you have to start at least twice,
2 times:
A: Hello, hello, this is A. Can you hear me? B: Yes, I can hear you. This is B. Can you hear me? A: (I heard you, I don’t want to talk to you.) B: Hello, hello? Do you hear me? I’m fucking dead. I gotta go.
Four times:
A: Hello, hello, this is A. Can you hear me? B: Yes, I can hear you. This is B. Can you hear me? A: Yes, and you? Can you hear me? B:?????? Are you retarded? I said I can hear you, don’t want to talk to xx…
So the most reasonable is 3 times:
A: Hello, hello, this is A. Can you hear me? B: Yes, I can hear you. This is B. Can you hear me? A: Yes. Let’s go fishing today. balabala
So, that’s right, in fact, not more, but reliable at the same time, but also to consider the performance and time issues, so, at present, it is generally accepted that three handshake times is more reasonable.
Four times to wave
We know that the TCP connection is full duplex, A and B can communicate with each other, do not understand, can think of call (analogy, don’t take it seriously), call the scene is the single and double work, because the same time can only be A person to speak, another person to listen to, if two people together, who can’t hear clearly, no sense, but the TCP is full duplex, A is sending A message to B at the same time that B is sending A message to A. Therefore, when disconnecting, both parties must be required to know. If only one party knows, it will not be possible. Therefore, when disconnecting, the following needs to be done:
A: B, sorry, I need to close the connection on my end, would you like to get ready? (Sends a FIN signal to B and waits for a response)
B: OK, A, I received your closed signal, I still have data to send, please wait for me (reply A, take back the last message of ACK, failure can be re-sent).
B: Buddy, I’m all right. I can turn it off. Just for your last word, I’ll turn it off as soon as you respond to me.
A: Ok brother, I will respond to you, you receive it as soon as closed, do not bother me (after sending this message, enter the time_wait state)
B :(directly shut down after receiving the ack message), this process does not generate data interaction and does not count the number of waving hands
A: After waiting for 2MSL(maximum packet segment survival time), THERE was nothing from B, so I turned it off.
Four waves and that’s it. Two questions:
1. Why does it take three handshakes and four waves?
When shaking hands, say hello to A and B, B can be directly put his own SYN packet and A response to A ACK information with you, but wave, A says I’m going to disconnect, B haven’t send out the final data, therefore need A response at first, I received your broken request, but you have to wait I give you the content of the final, so here separated step 2: (1) Answer A; (2) Send their last data
2. Why does A wait for the maximum time before closing TIME_WAIT?
The reason is that it is worried about the packet loss caused by the unreliable network. What if the ACK of the last response to B is lost? Within this time, A can send the packet again, but if the waiting time exceeds the maximum, it will be useless even if it cannot receive the packet, so it can be closed.
How to understand the function of sliding Windows?
From the above content, we understand the three-way handshake is simple and the content of the four wave, and then know the meaning of some message field, but the network itself is not stable, that is to say, in the middle can’t guarantee that packet will to the other side, so how the TCP as little time as possible to realize the stable and orderly transmission?
We know that in the SYN packet will bring your own seq, serial number, so that the other party to accept to know how to sort, after but if send must be synchronized, imagination, send A to B, need to B 1, 2, 3, 4, 5, sent after 1, die, etc. 1 ack come back, give 2, death, etc. 2 ack come back, In Linux, the maximum timeout of each TCP is 2^ 5-1 = 63s(retrytime is 5 times by default). After a packet is sent, no ACK response is received within a certain period of time. In order to confirm that the packet cannot be lost, the retry mechanism is started for 5 times. 1 second, 3 seconds, 7 seconds, 15 seconds, 31 seconds, where 31 seconds is the first 5 retry time 1+2+4+8+16=31 seconds, the last 32 seconds is waiting for the last retry timeout (wait time is 2 ^ N seconds), so the total is 63 seconds, if one after another, is not too terrible. In case of poor network environment, in order to minimize the loss of time without packet loss, the concept of sliding window, window, is introduced
Because the window is defined by the 16 bit, so the receiver TCP, window can provide 65535 bytes of the buffer, in fact, the sliding window is mainly for current limiting and buffer, each A win in the TCP transport is provided by the other side of the window size, distributing data when A to B, the win more than B length data will be lost, Windows can also improve the efficiency of sending data through concurrent behavior, as shown below:
It can be seen that A sends three consecutive packets to B, but the ACK of the response to B does not change, that is to say, it is the same response to the same B. However, A’s own SEQ is updated three times, first 1, then 69 and finally 1521, indicating that these three packets are sent consecutively. If the size of the current packet does not exceed the size of the window, the packet can be sent continuously.
Packet loss?
Look at the graph below
1. Retransmit 2 after timeout. 2. Retry 2, 3, 4, 5 after timeout;
The first method is slow and the second one wastes bandwidth. Therefore, TCP introduces a Fast Retransmit algorithm, which does not count time but retransmits data. If the packet does not arrive continuously, for example, 1 arrives, 2 does not arrive, and 3, 4, and 5 also arrive. B always returns ACK=2, which means it only confirms 1. Then A knows that 2 has not arrived and sends 2 again. But once B receives 2, it will directly ACK=6 to A.
The above is just a very simple solution, currently, after linux2.4, a more advanced way, there is a want to know can go here
attack
The typical scenario is DDOS attack, or TCP SYN Flood attack, also called Flood attack. Based on the above analysis, we know that the TCP handshake process is time-consuming. When the client initiates a connection request, the server responds and waits for the final confirmation from the client. By default, Linux waits for 1 to 63 seconds. This time can be to 1 to 2 min), the default is the longest will be disconnected after 63 s, before this time belongs to the state of half a connection, the server will not cast off the connection, but, just think if there is a person who suddenly think you sent the server within moments of tens of millions of a connection request, but the response from the server do not ignore, This is very easy to lead to our normal TCP connection can not go in, so there is a denial of service situation, and he only needs a simple script to throw packets to you, this situation will cause the server to the normal client performance for downtime. This kind of attack is cheap, but difficult to defend against, because you have to make sure that you don’t get rejected as the number of visits increases.
Another less serious attack is the ACK Flood attack. You can check it by yourself if you are interested.