2020 Autumn Recruitment_TCP/IP Protocol Knowledge (Notes)

Network OSI model

The Open System Interconnection Model (OSI model) has 7 layers in total.
7. Application layer, 6. Expression layer, 5. Session layer, 4. Transport layer, 3. Network layer, 2. Data link layer, 1. Physical layer

The network model is divided into several levels

Four levels: application layer, transport layer (TCP, UDP), network layer (IP), network interface layer (socket).

The relationship between TCP protocol and IP protocol

In the network model, the TCP protocol is located at the transport layer, the IP protocol is located at the network layer, and the transport layer is located one layer above the network layer.
The TCP protocol mainly provides a reliable data transmission method between two computers in a network connection; the IP protocol specifies the path (the so-called transmission route) through which to reach the other computer and transmits the data packet to the other party, that is, the route the way.
The sending end adds the header through each layer, and the receiving end deletes the header through each layer.
The transport layer (TCP protocol) divides the data (HTTP messages) received from the application layer, and forwards them to the network layer after marking the serial number and port number on each message; adding the function to the network layer (IP protocol) The MAC address of the communication destination is then forwarded to the link layer.

The difference between TCP and UDP

	TCP	UDP
reliability	reliable	Unreliable
Connectivity	Connection-oriented	not connected
Message	Byte stream oriented (unbounded)	Message-oriented (reserving message boundaries)
effectiveness	Low transmission efficiency	High transmission efficiency
Duplex	Full duplex (point to point)	One to one, one to many, many to many
flow control	Have	no
Congestion control	Have	no

Why is TCP more reliable than UDP?

TCP is connection-oriented and establishes a reliable connection through a three-way handshake; UDP is connectionless.

• The primary reason for the use of the three-way handshake for TCP connections-in order to prevent the confusion caused by repeated connection initializations in the past, to prevent the two parties communicating using the TCP protocol from establishing the wrong connection;
• The initial serial numbers of the communicating parties can be initialized through the three-way handshake;
• Discuss the possibility of establishing a connection with other handshake;

Why is the TCP three-way handshake process three times instead of two or four times?

Two moving pictures-thoroughly understand the TCP three-way handshake and four-way wave
TCP why three-way handshake instead of two handshake (positive solution version)
four-way handshake process:

1. The client sends a SYN synchronization request to the server;
2. The server returns an ACK to the client to confirm synchronization;
3. The server sends a SYN synchronization request to the client;
4. The client returns an ACK to the server to confirm synchronization.

Obviously, the second and third handshake in the four-way handshake are all sent by the server to the client, so they can be simplified into a three-way handshake to improve the efficiency of establishing a connection.

Three handshake process:

1. The client sends a SYN synchronization request to the server;
2. The server returns an ACK to the client to confirm synchronization and sends a SYN synchronization request;
3. The client returns an ACK to the server to confirm synchronization.

In order to achieve reliable data transmission, both parties in the TCP protocol must maintain a sequence number to identify which of the sent data packets have been received by the other party ( if the party sending the request message does not receive the ACK confirmation from the other party, The request message will be retransmitted over time until it receives the ACK confirmation from the other party. The initial value of the sequence number of these retransmitted request messages is the same. If there is a request message that arrives after a delay, It will not be received repeatedly ).
The process of the three-way handshake is a necessary step for the communicating parties to inform each other of the initial value of the serial number and confirm that the other party has received the initial value of the serial number. If there are only two handshakes, at most only the initial sequence number of the initiator of the connection can be confirmed, and the sequence number selected by the other party cannot be confirmed.

How does TCP guarantee reliable transmission? (Focus on the transmission process)

The basis of TCP/IP reliable transmission is the sliding window protocol and the continuous ARQ (automatic repeat request) protocol, with flow control and congestion control, ensuring the entire transmission process:

1. The transmission channel does not produce errors;
2. No matter how fast the sender sends data, the receiver always has time to process the received data (guarantee by accumulated acknowledgment, timeout retransmission, flow control, congestion control, etc.).

How to confirm? -> Continuous ARQ protocol

How does the sender confirm which packets need to be retransmitted?

Stop waiting protocol : the sender will stop sending every time a packet is sent (start a timer at the same time) and wait for the other party to confirm; the receiver will confirm to the sender after receiving the message, and the sender has not received it after a period of time. The message is retransmitted after the confirmation (timeout retransmission); the sender will send the next packet after receiving the confirmation.
Sliding window protocol : The sender and the receiver maintain the sending window and the receiving window respectively. Each time the sender receives an acknowledgement, it slides the sending window forward by one segment. The receiver generally adopts a cumulative confirmation method.
Continuous ARQ protocol : The sender maintains a window, and any segment within the window can be sent continuously without waiting for the other party to confirm. The receiver generally uses cumulative acknowledgments, and sends cumulative acknowledgments to the last segment that arrives in sequence, indicating that all segments up to this segment have been confirmed to be received.
(Advantages: high channel utilization, easy to implement, even if the acknowledgement returned by the receiver is lost, it does not need to be retransmitted; disadvantages: a segment in the middle of the window is lost, and the segments after the lost segment in the window are required Resend, because the intermediate segment is lost, the subsequent segment cannot be confirmed)

The difference between flow control and congestion control

Flow control: When the receiver is too late to process the sender's data, it can prompt the sender to reduce the sending rate to prevent packet loss.
Congestion control: Reduce data transmission when the network is congested. (Maintain a congestion window cwnd, cwnd = min(rwnd, cwnd); congestion control algorithm: slow start, congestion avoidance, fast retransmission and fast recovery)
Congestion control is a global process involving all hosts, all networks, And all factors related to reducing network performance. On the contrary, flow control is often the control of point-to-point traffic, which is an end-to-end process . What the flow control needs to do is to suppress the rate at which the sending end sends data so that the receiving end can receive it.

time_wait state

The duration of time_wait is the two longest message segment lifetimes.
When the client or server is closed (Ctrl+C) first, it will enter the time_wait state.
effect:

1. Ensure that the last ACK message sent by the client can reach the server;
2. All the message segments generated during the duration of this connection will disappear from the network, so that the request message of the old connection will not appear in the new connection.

The relationship between TCP sticky packet TCP and HTTP, what kind of transmission can HTTP be based on

The main reason is that TCP is transmitted in the form of a byte stream without message boundaries. (The problem of sticky packets can be solved by programs. For example, when reading HTTP messages, it is generally used /r/nas a line break mark for each line of the message. Blank lines are /r/nused to distinguish the message header from the message body. The length of the message body can be based on the header. Field Content-Length is obtained, so that a complete HTTP message can be read)

TCP sticky packets, unpacking and solutions, causes and solutions of packet loss

TCP sticky packets, unpacking and solutions, causes and solutions of packet loss

What happened from entering the URL to the page loading?

Front-end classic interview questions: What happened from URL input to page loading?
Generally speaking, it is divided into the following processes:

1. DNS resolution: The process of finding which machine has the resources you need.
2. TCP connection: HTTP protocol uses TCP as its transport layer protocol. When TCP has a bottleneck, HTTP will also be affected.
3. Send HTTP request
4. The server processes the request and returns an HTTP message
5. The browser parses the rendered page
6. End of connection

The relationship between TCP and HTTP, what transmission can HTTP be based on?

The difference between TCP and Http! I understand, don’t be confused!
TCP is located in the transport layer of the network model, it is the transport layer protocol, which defines the specification of data transmission and connection mode; HTTP is located in the application layer of the network model, It is an application layer protocol that defines the specifications of the data content to be transmitted. The HTTP protocol is built on the TCP protocol, that is, the data in the HTTP protocol is transmitted using the TCP protocol (default port 80), so supporting HTTP must also support TCP.

HTTP/3 is actually based on UDP. What has the HTTP protocol experienced over the years? (It describes the technical development process of HTTP/1, HTTP/2, HTTP/3)
HTTP can also be transmitted based on QUIC protocol (HTTP/3, QUIC protocol is based on UDP protocol).
Google has developed a QUIC protocol based on the UDP protocol and used it on HTTP/3. HTTP/3 was previously called HTTP-over-QUIC. From this name, we can also find that the biggest transformation of HTTP/3 is to use it. QUIC.

The difference between GET and POST

GET: get resources; POST: transfer entity body.

Let's first conclude that there is no substantial difference between the GET and POST methods, but the message format is different.
GET and POST are just two request methods in the HTTP protocol, while the HTTP protocol is an application layer protocol based on TCP/IP. No matter GET or POST, the same transport layer protocol is used, so there is no difference in transmission .

In the message format, when there is no parameter, the biggest difference is the method name of the first line:

• The first line of the POST method request message is like this POST /uri HTTP/1.1 \r\n
• GET method request message is the first line of GET /uri HTTP/1.1 \r\n
  yes, no arguments when their difference is just the first few characters of different messages only.

What is the difference between messages with parameters? In the convention, the parameters of the GET method should be placed in the url, and the parameters of the POST method should be placed in the body.
Now we know that the two methods are essentially TCP connections, there is no difference, that is, if I do not follow the specifications, it is okay. We can write parameters in the URL and then use POST in the method; we can also write parameters in the Body and then use GET in the method. Of course, this requires server support.

The most intuitive difference is that GET includes the parameters in the URL, and POST passes the parameters through the request body . The parameters transmitted in the URL for GET requests are limited in length, while POST has no limitation. For the data type of the parameter, GET only accepts ASCII characters, while POST has no restrictions. GET is less secure than POST, because the parameters are directly exposed on the URL, so it cannot be used to transmit sensitive information. (From a transmission point of view, POST and GET are both insecure. Because HTTP is transmitted in plain text on the network, as long as the packet is captured on the network node, the data message can be completely obtained. For secure transmission, only encryption is required. That is HTTPS.)

The relationship between HTTP and HTTPS

Understand the HTTP and HTTPS protocols in ten minutes?
The following problems exist in general HTTP:

• Request information is transmitted in plain text, which is easy to be intercepted by eavesdropping;
• The integrity of the data has not been verified and is easily tampered with;
• Without verifying the identity of the other party, there is a danger of impersonation.

HTTPS protocol (HyperText Transfer Protocol over Secure Socket Layer): Generally understood as HTTP+SSL (Secure Socket Layer)/TLS (Transport Layer Security), the identity of the server is verified through an SSL certificate, and it is the communication between the browser and the server Encrypted. (The predecessor of TLS is SSL)

HTTPS is a secure version of the HTTP protocol. The data transmission of the HTTP protocol is in plain text and is insecure. HTTPS uses the SSL/TLS protocol for encryption.
HTTP and https use different connection methods, and the default port is different, http is 80, https is 443.

Why is the https protocol secure? -> HTTPS uses SSL (Secure Socket Layer)/TLS (Transport Layer Security) protocol for encryption, authentication and integrity protection.
https ssl connection process -> usually HTTP communicates directly with TCP. When using SSL, it evolves to communicate with SSL first, and then communicate with SSL and TCP.

How to determine that the server received the request correctly

• The response message returned is 200 OK.
• Returning 5xx means that it is an internal error of the server.
• A return of 4xx means that it is a client error, such as a syntax error in the request message, no permission to access the resource, and no resource found.

Persistent connection and pipeline (pipelining), short connection and long connection (persistent connection)

The most notable feature of HTTP connections is that every request sent by the client requires the server to send back a response, and after the request is over, the connection is actively released. The process from establishing a connection to closing a connection is called "a connection".

• In HTTP 1.0, each request of the client requires a separate connection to be established. After the request is processed, the connection is automatically released. (Short connection)
• In HTTP 1.1, multiple requests can be processed in one connection, and multiple requests can be overlapped, without waiting for one request to end before sending the next request. (Long connection/persistent connection)

Sending HTTP requests in a pipelined way: multiple requests are concurrently sent at the same time without waiting for a response one by one, which is faster than a persistent connection.
The pipeline mechanism must be completed through a persistent connection. Only HTTP/1.1 supports this technology (HTTP/1.0 does not support), and only GET and HEAD requirements can be pipelined, while POST has restrictions. In addition, the pipeline mechanism should not be activated when the connection is created for the first time, because the other party (server) does not necessarily support the HTTP/1.1 version of the protocol.

In the case of a long connection, when a web page is opened, the TCP connection used to transmit HTTP data between the client and the server will not be closed. If the client accesses the web page on the server again, it will continue to use this one. Connection established. Keep-Alive will not keep the connection permanently. It has a keep time, which can be set in different server software (such as Apache). To achieve a persistent connection, both the client and the server must support the persistent connection.
The long and short connections of the HTTP protocol are essentially the long and short connections of the TCP protocol.