Article directory

1. Standard sealing layer in the network
Summarize

1. Standard sealing layer in the network

1、TCP/IP

Application layer: specific communication between processes (specific information)
Transport layer: end-to-end data exchange; end: process (communication between processes)
Network layer: data exchange between WAN devices and devices, cross-LAN work (cross-LAN, inter-host communication)
Data link layer: related matters within a local area network LAN (communication between hosts within the LAN)
Physical layer: For example, two devices can be directly connected (direct connection)

Replenish

During the sending process: application layer - "transport layer - > network layer - " link layer, each layer will add its own necessary information to the data packet (encapsulation)
During the receiving process, link layer -> network layer - "transport layer -> application layer, each layer needs to be responsible for deleting (unpacking) the relevant information of this layer.
Each layer in the packet should carry two important pieces of information:
- How to split the data added by each layer (length, boundary) for unpacking
- Specifically handed over to the protocol of the upper layer for processing, in order to divide
- On the same host, a port can only be occupied by one process, even if multiple processes belong to the same program.
  - Common ports
    http: 80
    https: 443
    ssh: 22
    mysql: 3306
    redis: 6379

As long as there is a port, it must be at the level above the transport layer. There are two important protocols on the transport layer: TCP, UDP; based on the quadruple + protocol number = "quintuple

Network programming: use the socket (socket) provided by os to program the internal communication of network communication;
Socket (socket): Socket, equivalent to the real use of TCP, UDP and other network services provided by os through socket.

2. Important protocols of the transport layer: process to process

2.1 UDP User Datagram Protocol

No features, when compared to TCP: unreliable, connectionless, message-oriented
As the simplest transport layer protocol, UDP does not help users to deal with complex network environment, so it retains the characteristics of unreliable network.
UDP packet header information (header)
- Encapsulated data (header)
  - 8 bytes, fixed length; 16-bit source port number (sender), 16-bit destination port number (receiver); 16-bit UDP length (message length), 16-bit UDP checksum (checksum)
  - Checksum Function: Determine whether the received message (data) has errors; if the checksum is wrong, it will be discarded directly; if there is no error, the data will be received normally;
  - Simple working mechanism of checksum: Using the principle of hash function: By designing a hash function, a situation where the conflict rate is very low is achieved.
- data (payload payload)
UDP has a receive buffer (the UDP data that arrives after it is full will be discarded), and there is no send buffer; as much data is sent by the user layer, how much data is sent directly by UDP;
UDP sends data without any preparation, and can send (mail) anytime, anywhere. , so it is also unconnected;
Unreliability: The message is not guaranteed to be sent to the other party; after the packet loss occurs, the sender does not know it; the message cannot be guaranteed to be in order;
Affecting results: Because the bottom layer (physical layer + network layer) has a size limit on the data sent at one time; if data larger than the limit is forcibly sent, data truncation will occur.
The UDP socket can read and write, which is called full duplex (that is, it can send and receive).
The most suitable scenario for the UDP protocol: Scenarios with high real-time requirements and low reliability requirements - real-time chat (voice, video). Broadcast is supported.

2.2 TCP protocol: Transmission Control Protocol

Works at the transport layer. Above it is the application layer (providing services for the application layer); below is the network layer (relying on the network layer to work); there are two external event sources for the TCP protocol stack: method calls from the application layer; data from the network layer receive .
Core goals: to provide inter-process communication; to pursue reliability;
Passing data in units of processes; Pursuing reliability;
Reliability : TCP can only guarantee that it will do its best to send data to the other party in an orderly manner (TCP ensures that the data received by the application layer is in order); but it cannot guarantee that it can be sent to the other party. Even if it is not sent successfully, there is feedback.
Make sure that the other party accepts it in an orderly manner. Ensure that the other party will not receive erroneous data. TCP will design some mechanisms to optimize the network as much as possible and improve the possibility of the other party receiving.
**How to achieve reliability? **Mechanism: Confirmation response mechanism
- The data sent is generally called: segment (data segment); response: acknowledge
- The sender sends multiple segments at the same time, and the receiver responds multiple times. How does the sender know which segment the receiver has received? Numbering mechanism: The sender assigns a number to the sent data , and only needs to bring the corresponding number when responding.
- If the sender does not receive the corresponding response, it is considered that the other party has not received the data. ---- Timeout retransmission mechanism
The header format of the TCP protocol:
- not fixed length;
- 16-bit source port number, 16-bit destination port number.
- 32-bit sequence number Sequence Number SN: The segment that carries the data.
- 32-bit acknowledgement sequence number Acknoeledge Sequence Number ASN : The segment of the acknowledgment.
- The length of the 4-bit header can ensure that the receiver's TCP protocol stack performs unpacking work.
- There are two kinds of segments: carrying data, data + response segment; but unified settings are made. How to distinguish whether this segment has the function of response? ack = 1 has the function of response, and ack = 0 has no function of response.
TCP numbers each byte sent (just the payload). When sending, the SN in the header is filled with the sequence number of the first byte in the first payload. The receiver knows the length, and if the receipt is received, it all knows.
When the TCP protocol stack establishes a connection, it will randomly generate an Initial Sequence Number ISN.
The ASN is filled with the next byte of data received by the receiver, (the last one sent is 112, then the ASN is filled with 113, meaning: all data before 113 are received).
If the sender does not receive a reply after a certain period of time, the original one: the other party did not receive it; the original two: the other party received but the reply was lost. (Premise: The receiver can confirm whether the data has been accepted according to the SN.). The processing logic of the sender is consistent. After the timeout, it will be retransmitted directly (the retransmitted data will not be lost). The answering party judges whether to repeatedly accept, it is not a normal response; if it is discarded, it is a normal response.
What if it arrives out of order?
- The data sent by the sender first, and then accepted (the sender can directly send multiple times without waiting for a response) The first received data does not respond, (if it responds, the other party thinks it has all received before, if the first packet is lost , will not be repeated). The second received response, ASN = 2001. (Ensure that the other party's acceptance is in order, and the received data will no longer be accepted. Although the TCP protocol stack of the recipient host is not in order, it is guaranteed that the application of the recipient host The data received by the layer is ordered)
If after the timeout, the other party has not received the retransmission?
- Continue to retransmit until a threshold is reached. If there is no response, give up; Step 1: Try to notify the other party that the connection is closed abnormally, and send a reset segment; rst = 1 is a reset segment; rst = 0 is not. Whether the other party can receive it is not guaranteed. Step 2: Notify the application layer that the data transmission fails. There are different notification methods according to different languages. In Java, the notification is through an exception, and it will receive an IOException, describing the reset connection.
If it times out, how is the time determined?
- Ideally, find the minimum time to ensure that "the confirmation response must be returned within this time". If the timeout is set too long, the overall retransmission efficiency will be affected. If the timeout is set too short, repeated packets may be sent frequently.
- Solution: RTT: Round Trip Time Under normal circumstances, the time for data to go back and forth. Generally larger than this time, there is generally an experience value. After each retransmission, this number is amplified. In Linux, the timeout is controlled in a unit of 500ms, and the timeout time for each time-out retransmission is an integer multiple of 500ms. If there is still no response after resending once, wait for 2 500ms before retransmitting, and the next 4 500ms will accumulate a certain number of retransmissions. TCP considers that the network or the peer host is abnormal and forcibly closes the connection.
When TCP sends, it does not need to wait for a response before sending new data; it is also possible to only give one response.
TCP will occasionally send acknowledgments back periodically even when no data has been received. (at least update the window).
TCP does not understand the sending response after receiving the data, there is a delay response mechanism; wait for whether the data can be piggybacked.
Piggyback answer; data can be piggybacked when answering.
Fast retransmission; theoretically, the retransmission will not be retransmitted until the timeout, but the receiver sends 12 gold medals to let the sender retransmit immediately.

2.1.1 Three Characteristics of TCP

reliability (root)
connected
For byte streams, the data in the send buffer is not necessarily sent strictly according to the situation written by the application layer due to the limitation of the send window size. The receiver's application layer has no way to read data in the way that the sender's application layer splits. (Some people call it the sticky packet problem); through the application layer protocol design: 1. The method of fixed length; 2. The length is not fixed, carrying length/special characters as separators, such as \n.
- The HTTP protocol is a protocol on top of TCP, so it is also necessary to deal with byte stream-oriented issues in the protocol. Therefore, in the protocol design of HTTP, the request line and request header are divided by \r\n; for the body part, the content-length is used to specify the length to divide.

3. Connection management

3.1 Why do you need a connection, what is the abstraction of the connection (TCP has a connection, UDP has no connection)

As a TCP protocol stack, it is necessary to maintain a receive buffer;
- Ensure that data arriving out of order is sorted;
- Before the data is temporarily read by the application layer, the data is temporarily saved.
As a TCP protocol stack, it is necessary to maintain a send buffer;
- Due to the possibility of retransmission, unanswered data cannot be thrown away directly, so a space is needed for temporary storage.
As the TCP protocol stack, the sender needs to maintain the SN that has been sent; the receiver needs to maintain the SN that should be responded.

The TCP protocol stack, in order to ensure that the previous mechanisms are available, must maintain a set of related data for each channel. A set of related data ----" is abstracted into an object, and this object is called a connection.

Connection object: The representative of the channel through which the two parties communicate. For the TCP stack, a set of data related to channel information is maintained.

3.2 The necessity of establishing a connection

The process on host A wants to communicate with the process on host B through TCP.
Since TCP pursues reliability, before formally sending data, we want to verify whether the other party can receive the data (mutually confirm that the other party is online).
For the connection object, some information cannot be known independently, and both parties need to synchronize effective information (both sides synchronize the necessary initial information).
The communication phase is divided into three parts: the connection establishment phase (handshake phase), the channel availability phase, and the release disconnect phase (wave phase).

3.3 Introduce state mechanism, different states----current connection situation

3.3.1 Three-way handshake

The establishment of a TCP connection requires the two parties to exchange information three times; why three times? A synchronizes the information to B, and B synchronizes the information to A. It takes at least two times. TCP needs to ensure reliability, so in addition to the reply and reset), it needs to reply, and it needs 2 replies at the same time. Logically, it takes four times. , but in order to improve network utilization, it is inevitable to combine (2) and (3) (B responds to A's information and synchronizes the information to A). Twice is for synchronizing information. Synchronize (synchronize sync).
Four segments: data segment, response segment (ack = 1), reset segment (rst = 1), synchronization segment (syn = 1).
SN changes in three-way handshake:

3.3.2 State transition diagram (limited to three-way handshake phase)

At the TCP level, the standard terminology does not mention the client and the server, but the active connection and the passive connection; in practice, the server is usually the passive connection, and the client is the active connection.
Status of the connection phase:
- ---------- Before establishing a connection
- closed: no connection / when the connection is just established and not initialized;
- listen: listening state; passive connection party: waiting for others to establish a connection. Actually only one party exists, no channel exists yet.
- ---------- Establishing connection
- syn_rcvd: passive connecting party: just received the syn segmnet sent by the other party (active connecting party).
- syn_sent: Active connection party: issued a syn segment, waiting for the other party to respond.
- ---------- After the connection is established
- established: The connection has been established and can communicate normally.
Before the formal establishment of the three-way handshake, the passive connection party has two states: closed and listen.
Once the connection between the two parties is established, the status of both parties in the communication is equal: anyone can actively send data, or even send data at the same time. ·

3.3.3 Waves four times

The closing of the TCP connection is independent and does not affect the other party.
Why is the wave phase four times?
- The two communicating parties A and B (the party that initiates the shutdown actively is not necessarily the party that actively establishes the connection.
- A actively initiates the shutdown----"When B receives the shutdown message, it is also closed at the same time;
- A actively initiates the shutdown----"B continues after receiving the shutdown message----"after a period of time----"B initiates the shutdown again;
- A initiates the shutdown, and B initiates the shutdown almost at the same time.
TIME_WAIT may only appear on the side of the active closing party; CLOSE_WAIT may only appear on the side of the passive closing party.
Is it normal for a large number of CLOSE_WAIT states to appear on the server? If not, what issues should be investigated?
- Not particularly normal, but not necessarily wrong. Troubleshooting: The server forgot to close the connection. The connection needs to occupy at least memory, and a large number of waste connections are ineffective and waste resources.
Necessity of TIME_WAIT state: Is it CLOSED after a period of time, not CLOSED directly? When a connection is closed, the phenomenon is that it dies normally, but it will take some time to confirm whether it actually dies. There are two possible unexpected situations: Situation 1: B does not receive A's response, if A is closed, then B requests the response mechanism and cannot be sent again; Situation 2: The communication stage is lost for some reason, and it is transmitted later. If closed, it cannot be received.
TIME_WAIT duration: 2* MSL (Maximum Segment: The maximum time that a TCP Segment can survive in the network.

3.3.4 TCP exceptions

Process termination: The file descriptor will be released, and FIN can still be sent, which is no different from a normal shutdown.
Machine restart: Same as process termination.
The machine is disconnected from the network and the network cable is disconnected: the receiving end thinks that the connection is not there. Once the receiving end has a write operation, the receiving end finds that the connection is no longer there, and will reset it. Even if there is no write operation, TCP itself has a built-in keep-alive timer, which will periodically ask whether the other party is still there, and if not, it will release the connection.
Processes terminate, machines restart, and machines shut down gracefully; the OS has a chance to intervene. All connections can be closed normally (go through the four wave process).
The machine is directly powered off (sudden death); it is too late; computer A has not restarted ; computer B does not know, so it is still connected normally;
- When will B know? If process B on B tries to write data to the connection and never receives a response, it will try to give up after multiple retransmissions. As the B process (user layer), it can receive errors (write failures) from the TCP stack. (Process B only knows that there is a problem, but when the problem occurs, it does not know what the problem is).
- If process B on B is waiting for a message from the other party, it is in the state of reading. And there is no timeout mechanism (unlimited waiting) ----" Process B will never know that there is a problem with the connection, the reason: it is impossible to distinguish whether the other party has not sent a message or there is a problem with the connection.
- Only by writing data can problems be exposed;
- As a user process, you should: 1. Add a timeout for all reads; 2. Add a heartbeat mechanism. Send a message to the other party at regular intervals (fixed interval, non-fixed interval) and ask the other party to respond.
- If computer A restarts : if process B is reading, the phenomenon is different; if process B writes data, then process A restarts, causing all data in memory to be lost, so the connection is lost, and after receiving a piece of network data After that, I don't know who sent it (similar to amnesia), and return a reset segment (abnormal situation). For process B on B, after receiving the reset, I know that the other party has closed the connection abnormally, and it can also close the connection and notify B. process.
- As long as the data is written, there is a chance to know that the other party has a problem.
- As a developer of the application layer process, it is best to add: 1. read timeout mechanism; 2. heartbeat mechanism;
- TCP also provides a heartbeat mechanism (keepalive), but it is basically unused. Reason: in hours; global configuration.
The machines on both sides of the communication are normal, and a certain place on the network is disconnected; it is too late to shut down normally; I don't know this happening.

4. Intelligent flow control

TCP is based on reliability, and the receiving buffer of the other party can accommodate the data sent;

4.1 Based on the receiving ability of the other party - flow control (narrow sense) flow control

4.1.1 As a sender, how do you know the current acceptability of the other party?

Feedback from each other, told by the receiver. By what way? ----- There must be a response when sending data, and the receiving capability can be sent back with the response segment (segment). In the response sent by TCP, where is the receiving capability placed? ------16-bit window size (window: the current receiving capability of the receiver (the size of the remaining space in the receiving buffer of the receiver), in order to avoid confusion with other windows, we use the receiving window to refer to). Reception capability (current) >= reception capability (at the moment of response, data may be read by the network).

4.1.2 As a sender, how to control the amount of sending

Ensure that the data sent this time <= receiving capability;
By segmenting the send buffer (the second reason why TCP must have a send buffer)
| answered | not answered | pending | idle | to name one possibility, there are many possibilities on the network, send buffer (circular queue)
Increase the sending volume control mechanism
- Calculate the maximum sending amount according to the receiving ability of the other party (maximum sending amount = receiving ability of the other party)
- Application layer writes data
- Sliding window mechanism: the left side slides to the right with the received response; the right side slides to the right with the received response + receiving window.

4.2 Based on the current network quality----congestion control

Based on the current network conditions, the transmission volume control is carried out.

4.2.1 How to know the current network situation

Receiving capability is what the receiver explicitly tells us and is an exact value. The network carrying capacity is unknown. So some algorithm is used to infer this value. Use packet loss to infer network carrying capacity.
Use the packet loss situation to infer the network carrying capacity, and use the response situation to infer the loss situation. If there is a response every time the data is sent, it means that the network carrying capacity is very high. If every time the data is sent, there are very few responses, indicating that the quality is very low.
The specific calculation situation will not be inferred by a few packet losses to prevent jitter in the evaluation of network quality. Generally, the number of packets lost per unit time is used. For example, if the packet loss exceeds 10 times in 30s,
Congestion window, the maximum transmission size inferred based on the network carrying capacity. Slow start, fast start; when the network quality is good, the congestion window is very low at the beginning, which is called slow start; exponential growth, after reaching a threshold, becomes linear growth.
send window size = f (receive window size, congestion window size); send window size = min (receive window size, congestion window size);
When the network quality is relatively poor, the congestion window = initial value; exponential growth --> linear growth threshold = congestion window cwnd/2 (the speed of fast startup needs to be evaluated according to the current network conditions; if the cwnd is relatively large, it indicates the network quality Yes, it means that the network quality is poor once, but the growth is still very fast)

4.2.2 How to control the sending volume

It is the same mechanism as flow control

Summarize

TCP	UDP
process-to-process	process-to-process
Implement reliability mechanisms (hard, boost)	Unreliable
connected	not connected
byte stream	datagram oriented
one-on-one	Can be one-to-one or broadcast (one-to-many)
The real-time performance of data transmission is poor	Real-time performance is slightly better

In the case of determining UDP, but also want to pursue reliability? ----- Do the reliability mechanism at the application layer; learn the advantages of TCP and avoid its shortcomings. HTTP3 tries to use UDP (background: good network quality, HTTP3 does some reliability on its own).

Network Protocol UDP, TCP