foreword
Regarding the Internet, I think you big brothers love it and hate it
What I love is that various powerful technical frameworks have already encapsulated the network in a simple and easy-to-use way. Every day request and fetchData are used.
I hate being asked every time I interview:
"What's the difference between HTTP and TCP?"
"What's the difference between HTTP and Socket?"
"What is three handshakes and four waves?"
"Why not two handshakes instead of three handshakes?"
"Why Not Three Waves Instead of Four Waves"
"Why wait 2msl when waving four times?"
"What's the difference between http1.0 http1.1 http2.0?"
"What's the difference between http and https?"
....
? ? ? Do I have to memorize this every time I request data? This interview with eight essays is really a headache.
Don't be afraid! In order to allow friends to do it once and for all, refuse to rote memorize! Xiaobian, I have sorted out this basic knowledge guide of the network that is not afraid to forget, for everyone to taste~
Private message me to get the latest interview materials , including ( C/C++ , Linux , FFmpeg , webRTC , rtmp , hls , rtsp , ffplay , srs )
What are HTTP and TCP?
First of all, we need to know that these two are protocols, the complete names are Http protocol and TCP/IP protocol
An agreement is what both parties agree on. For example, I made an agreement with you that I will give you an apple and you will give me a banana. The exchange of apples for bananas is the specific content of our agreement
So there is nothing mysterious about HTTP and TCP in essence, they just make some specifications for network requests.
So the question is, since they are all protocols, what is the difference between them?
There are of course many specific differences. But if you are not a professional network technician, you only need to have an overall understanding. At this time, we need to move out the TCP/IP layered model diagram that the teacher taught us.
Familiar or not? Here we only need to remember the application layer and the transport layer , and the others are rarely used.
From this model, we can know that the network request is a very complex process, so complicated that it must be divided into several layers, each layer completes its own tasks before the request can be successful.
The task of the transport layer is to establish network connections
The application layer is to transmit various types of data on the established network connection. such as text, images, videos, etc.
Since the network request is so complicated, it is impossible to describe the entire network request process with a single protocol.
So HTTP corresponds to the application layer protocol, and TCP corresponds to the transport layer protocol
This is the biggest difference between HTTP and TCP
Socket
At this time, a concept is introduced, socket
What is a socket?
From the previous article, we know that HTTP and TCP are just protocols. The protocol itself does not have the ability to realize functions, and a carrier is needed to realize it.
socket is the implementation of tcp protocol.
It defines some interfaces for establishing connections. Such as connect, listen, read, etc. The specific implementation of these interface methods strictly follows the TCP protocol
Okay, I know what it is, the next step is the highlight of the interview
Three handshakes and four waves
We first make it clear that the three-way handshake and the four-way wave are the content of the TCP/IP protocol, which belongs to the transport layer and is the way the network requests to establish and disconnect when transmitting data.
How to establish a network connection
Before understanding what a three-way handshake is, let's discuss a question
Now that there is a client client and a server server, how do we establish a network connection?
The simplest is of course that the client sends a request to the server to establish a connection, and then ignore it, I will just wait for the connection to be established, and wait for the server to send me data.
is this OK?
Of course not bro
What if the server doesn't boot at all, and if everyone ignores you?
It's like writing a love letter to your sister, only when the sister responds to you. You don't care if your sister responds or not, you keep writing to others, and you wait there stupidly.
That's not love, it's X-harassment and a spare tire
So we arrive at a basic guideline for establishing a connection
"Request must be answered"
Continue to think down. Since there is a response, my client will send you a request, and after receiving the response from the server, I will send the next request. Does it seem very orderly?
As expected of you, this is the "Stop Waiting Agreement"
timeout retransmission
"Stop waiting" is the simplest version of a network request
Simple means problems, because the network environment is unstable
For example, each request of the client must wait for the reply of the previous request to be sent. If the previous request is delayed due to network fluctuations, or is simply lost, won't the client's next request never be sent? Data is stuck here?
In order to solve this problem, there is a timeout retransmission mechanism in the TCP protocol. If no reply is received for a long time, the original packet will be sent again. Haven't received it yet, until it's normal.
serial number
Understand that when the network connection is established, "the request must have a response" , "timeout retransmission" , then let's think about another question
We know that the data transmitted by the connection request is transmitted in the form of packets. That is, the data requested at one time is composed of multiple data packets.
If a data packet is delayed due to network fluctuations, and a timeout retransmission is triggered during this delay, the server will receive two identical packets. How does the server handle it?
The way to deal with it is simple. That is, when the client sends a data packet, it adds something to it, so that the server can identify where the packet came from.
This process is to number packets. This number is called the sequence number of the data packet , which is the key to the next three handshakes
Third handshake
It's finally time to shake hands three times, why don't you guys like it first and change your mind?
Or a simple premise
The three-way handshake is actually a four-way handshake, but the two handshakes in the middle are merged.
Because establishing a connection is continuous. After the server receives the client's request in the first handshake, it will immediately send a response and send its own request, so the response and the request are combined into one request, which is the second handshake.
Why not two handshakes but three handshakes?
Then the question comes, according to the above basic principle of "request must have a response"
Why not two handshakes but three handshakes?
In the fourth edition of "Computer Network" by Xie Xiren, it is mentioned that“三次握手” 的目的是 “为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误”。
There is no problem with memorizing this sentence as an interview essay. But in fact, there is a key reason skipped here
Remember when we said why packets have sequence numbers?
It is to allow the server to identify the source of the data packet and distinguish whether it is an outdated data packet.
We look up from packets to a network connection. If a data packet is delayed for a long time, the connection is disconnected for a long time, and the next connection is established. At this time, the server receives the packet of the old connection. How to distinguish these two connections?
The answer is to add a serial number
This sequence number is called the initial sequence number and is used to identify a connection.
The conclusion is clear.
The initial sequence number is used to identify whether it is the same connection, and the packet sequence number is used to identify the source of the data packets in a connection.
Therefore, the client needs to send the initial serial number representing the connection to the server.
Hold on, you still don't understand why it's three handshakes instead of two?
Ha, did you forget that the TCP protocol is full-duplex communication? The concept of client and server is relative, gender swap, mother does not love
The initial serial number sent by the client to the server is the connection established by the client. The server can also act as a client and also send the initial serial number of the connection to the other party . In addition to the handshake merger mentioned earlier, isn't it a three-way handshake?
Suddenly realized? hey-hey
Come on, check yourself, ask yourself as an interviewer
"Why is a three-way handshake not a four-way handshake?"
"Why is a three-way handshake not a two-way handshake"
Private message me to get the latest interview materials , including ( C/C++ , Linux , FFmpeg , webRTC , rtmp , hls , rtsp , ffplay , srs )
waved four times
Halfway through the long journey, let's look at the four waves of disconnection
In fact, the fourth wave is similar to the three handshake, the difference is that the second and third wave cannot be combined
Why is this?
As mentioned earlier, the reason why the three-way handshake can be combined is that "the establishment of the connection is continuous" , and the server must respond immediately after receiving the first handshake request and send the request at the same time. But because TCP is full-duplex communication, the server may still need to send data after the client disconnects.
So the client “请求--回应”only disconnects the 客户端-->服务端connection at a time, and the server sends the request for 服务端-->客户端the disconnected connection after a while
Why wait for 2MSL
Here is a small knowledge point. After the client waved its hand for the last time to send a response, it will wait for 2msl (msl is the maximum survival time of a packet on the network) before it is completely closed. Why?
Or the problem of network instability. If the response message sent by the client's last wave is delayed or lost, the server will wait for one MSL and not receive it, and it will retransmit it over time, and repeat the process of the third wave.
In this way, the client will receive a disconnection request for a maximum of 2MSL, so it must wait at least 2MSL before disconnecting.
Well, most of the knowledge points of HTTP and TCP are finished. Of course, there are still many places for expansion, such as "timeout retransmission". In order to solve performance problems, continuous transmission, sliding window, congestion control and so on are introduced. However, these are the branches of HTTP knowledge, as long as you master the main knowledge, the rest of the branches and leaves are not within your grasp.
Of course, the interviewer will also ask some questions that can be answered by simple memory, such as:
"Tell me the difference between Http1.0 Http1.1 and Http2.0"
Difference between Http1.0, Http1.1 and Http2.0
What we said just now is actually the content of Http1.0. I think with my toes that Http1.1 and 2.0 must be optimized.
The optimization of Http1.1 is mainly to realize the long connection , and it is also the most extensive Http protocol at present.
The meaning of long connection is very simple. In Http1.0, we need to establish a Tcp connection every time we request a picture. When requesting a web page, there are often dozens or hundreds of Tcp connection establishments and disconnections, which is very time-consuming. Long connection means multiple requests. A Tcp connection can be reused, which improves the utilization of the Tcp connection
If the interviewer asks you if you still have it, you tell him that there is a continuation
This is easy to understand. In Http1.0, if we want to know the data in the middle of a video, we must first download the entire video. Http1.1 optimizes this funny scene, adding range to the request header, you can only request a part of the data
If I ask you what else...
You said that these are almost the ones that are commonly used. No, I will go back and take a good look. When we become colleagues, I will tell you well..
As for Http2.0, it's even more awesome
It supports multiplexing. Earlier, Http1.1 just reused Tcp connections, and Http2.0 can request multiple resources on one request
Similar to merging two requests into one. The server returns the requested resource twice at a time.