Network protocol

What are the differences between HTTP and HTTPS?

Http is a hypertext transfer protocol, Https is a secure hypertext transfer protocol; Literally, Https encrypts request packets and sends ciphertext requests, whereas Http sends plaintext requests. Https can send ciphertext requests because before TCP three-way handshake is established at the transport layer, an SSL/TSL handshake request is established with the server. First launched an encryption request the server, the server will return a public key and a certificate to the client, the client generates a random value, and then through the public key encryption, sent to the server, the server after received will be according to your own private key to decrypt, after he got the random value, the random value is used for the encryption of salt. After completion, the ack is sent to the client. At this point, the data sent by the client must be encrypted through the public key. So as to achieve the effect of safety.

The default Http port is 80, and the default Https port is 443. You need to apply for digital authentication before someone asks: “Https is more symmetric encryption than Http.

When establishing a connection: HTTPS is more than HTTP TLS handshake process; When transmitting content: HTTPS encrypts data, usually symmetrically;

Reference: cloud.tencent.com/developer/a…

How does TCP guarantee reliable transmission?

TCP is connection-oriented, data flow transmission, mainly through its three-way handshake and four-way wave, as well as the ACK response mechanism in the transmission process, retransmission mechanism to ensure reliable transmission. It is summarized as follows:

• Serial number and acknowledgement acknowledgement
• Timeout retransmission control
• Connection management
• Sliding window control
• Flow control
• Congestion control

Serial number and acknowledgement acknowledgement

When sending data, the sender will bring its own serial number. When it is sent to the receiving party, it will return an ACK reply to the sender. When the sender receives an ACK reply, it represents that the data is successfully sent. At this point, the sender tries sending the message again.

The ack reply is lost in two ways. The first is that the message does not reach the receiver, and the second is that the ACK is lost due to network reasons on the way back. In the first case, the data can be resend, but in the second case, the receiver will appear to receive a duplicate message, repeatedly receiving the same data may be a “disaster”, not only waste network resources, but also consume resources to process it. Therefore, we need a mechanism to recognize whether the packet has been received and to determine whether the packet needs to be received. It is not recommended that the target host receives the same data repeatedly. To maintain data consistency, the target host must discard the repeated data packets. Therefore, how to determine whether the data packets have been repeatedly received? For this we introduced serial numbers. Through the sequence number and acknowledgement number, TCP can identify whether data has been received and determine whether data needs to be received, thus achieving reliable transmission.

Timeout retransmission

If the sender times out, it will resend the message. How to determine the timeout? In fact, after each packet is sent, the round-trip time and deviation value of the packet will be recorded. When the round-trip time and deviation value are added up, the timeout time will be slightly larger than this value. Therefore, the timeout period is not fixed, but dynamic fluctuation. If it expires, it will be retransmitted, but there is a limit on the number of retransmissions. If this limit is exceeded, the target machine will be disconnected from the host and will be interrupted.

Connection management

The TCP three-way handshake and four-way wave are described below

Sliding window control

TCP uses the unit of one segment. If the next communication is performed only after an acknowledgement is sent for each segment, this transmission mode has a disadvantage. The longer the round trip time (RTT) of packets, the lower the communication performance. This way is somewhat similar to the database can not concurrent requests, can only be processed one by one, naturally such efficiency is certainly lower than concurrent

To solve this problem, TCP introduced the concept of Windows. Acknowledgments are made in larger units instead of each segment, and the forwarding time will be significantly shortened. That is, the sending host does not have to wait for an acknowledgement after sending a segment, but continues to send.

Sliding Windows have the following characteristics:

• The data in the window above can be sent without receiving an acknowledgement. However, the sender is still responsible for retransmission if some of the data is lost before the acknowledgement of the entire window arrives. To do this, the sending host needs to set up a cache to hold the data to be retransmitted until it receives an acknowledgement from them.

• The part outside the sliding window includes data that has not been sent and data that has been confirmed to have been received by the peer end. When the data is sent and the acknowledgement is received as expected, the data can be removed from the cache without being resent.

• Upon receipt of an acknowledgement, slide the window to the position of the serial number in the acknowledgement acknowledgement. This allows multiple segments to be sent sequentially simultaneously to improve communication performance. This mechanism is also known as sliding window control.

Flow control

Is acting on the receiver, it is to control the sending speed of the sender so that the receiver has time to receive, to prevent the loss of packets. The so-called flow control, is to let the sender do not send too fast, so that the receiver can receive in time

Assuming no flow control, the sender sends data according to their own actual situation, if send too fast, to receive buffer at the receiving end soon filled, at this time the sender if continue to send data, the receiver processing not to come over, then the receiver will be ditched ought to have received data, send this triggers the retransmission mechanism, Therefore, network traffic is wasted.

Therefore, TCP needs to provide a mechanism for the sender to control the amount of data sent according to the actual receiving capability of the receiver. This is called flow control.

Congestion control

Congestion control is used to prevent too much data from being injected into the network, preventing the network from being overloaded.

What is congestion

We all know that resources in computer networks are limited. In a certain period of time, the demand for network resources exceeds the available part of the network, and the network performance deteriorates due to congestion.

Generally speaking, too many packets are sent and the device on the network cannot process them, resulting in network performance deterioration.

Why does TCP perform congestion control

A router on a network has a packet processing queue. If the router receives too many packets and cannot process them all at once, the packet processing queue becomes too long. At this point, the router discards the newly received data packets unconditionally.

In this case, the upper-layer TCP protocol retransmits the packets that are lost on the network, and the router discards the retransmitted packets. As a result, the network performance deteriorates sharply and the network breaks down. Therefore, TCP needs to control the number of packets sent to avoid the degradation of network performance.

Congestion control principle

With TCP’s sliding window control, even if no longer in a “segment” as a unit, but in a “window” as a unit to send confirmation reply signal, so the sending host can continuously send a large number of packets. However, if a large number of packets are sent at the beginning of the communication, the network can also crash.

In congestion control, the sender maintains a state variable called congestion window CWND (Congestion Window). The size of the congestion window depends on the level of congestion on the network and changes dynamically.

The sending window is set to the minimum value of the congestion window and the receiving window to avoid sending data that is larger than the receiving window.

Congestion control uses two important algorithms: slow start algorithm and congestion avoidance algorithm.

Slow start algorithm

The idea of the slow start algorithm is not to send a lot of data at the beginning, but to test the congestion level of the network, that is, gradually increase the size of the congestion window. In the slow algorithm, the CWND is doubled after each transmission turn.

For example, the sender starts with CWND =1 (the number of segments is used as a unit of window size for ease of understanding) and then doubles the CWND with each transmission turn, e.g. 1, 2, 4, 8… Exponential growth

So, the slow start here does not mean that the congested window grows slowly, but rather that the data in the large window is transferred slowly in the first place

Congestion avoidance algorithm

Congestion avoidance algorithms also gradually increase the size of CWND, but adopt linear growth rather than exponential growth like slow start algorithms.

In particular, the size of CWND is increased by one after each transfer turn. If network congestion is found, the ssTHRESH size is reset as described above (multiplication is reduced to 1/2) and the slow start algorithm is restarted from CWND =1.

The combination of slow start algorithm and congestion avoidance algorithm: Question: How are slow start algorithm and congestion avoidance algorithm used together in congestion control?

As mentioned above, the size of CWND under the slow start algorithm increases exponentially, so CWND cannot be allowed to grow arbitrarily. Therefore, we introduce a slow start threshold (SSthRESH) to control the growth of CWND.

Ssthresh is used to:

When CWND < SSTHRESH, the slow start algorithm is used. When CWND > SSTHRESH, congestion avoidance algorithm is used instead. When CWND = SSTHRESH, slow start with congestion avoidance algorithm random

At what layer of network protocols are TCP and UDP, and what are the differences between them?

Application layer, presentation layer, session layer, transmission layer, network layer, data link layer, physical layer. TCP and UDP are transport protocols at the transport layer. TCP: connection-oriented. Data is transmitted through a three-way handshake and a reply mechanism is provided to ensure the reliability of message transmission. Byte stream oriented. Full duplex communication.

UDP: non-connection-oriented, data cannot be transmitted reliably and retry is not performed. UDP is used in real-time scenarios, such as video calls. There are unicast, multicast, broadcast functions that can be one-to-one, one-to-many, many-to-many. UDP is packet-oriented. The UDP packet of the sender is forwarded to the IP layer after the header is added. UDP does not merge or split packets from the application layer, but retains the boundaries of the packets. Therefore, the application program must select the appropriate size of packets. Unreliability is reflected in the absence of connections. Communication does not need to be established.

The data is transmitted as it is received, without backing up the data, and without caring whether the data has been correctly received.

This section describes the TCP three-way handshake and four-way wave. Why three handshakes and four waves?

The client initiates a request and sends it to the server with a SEQ flag bit and a SY synchronous request. The state of the request is syn-sent. This is called the first handshake. When the server receives the request, it returns an ACK and seQ flag bit. ACK = ACK +1 of the client and SYN = 1 is returned to the client. The server enters the SYN_RECV state and completes the second handshake. After receiving the handshake, the client sends ACK=1, SEq =x+1, and ACK= Y +1 to the server. Both states enter ESTABLISHED, and the third handshake is completed.

Quadruple wave When the server wants to interrupt the connection, it sends a FIN signal to the server. After receiving the signal, the server replies with an ACK and then another FIN. Then the client replies with an ACK to complete the disconnection. Points in detail:

For the first wave, the client releases the release signal FIN=1 and enters the fin-WaIT-1 state with its serial number SEq = U

After receiving the second wave, the server returns ACK=1 seq= Y ACK= U +1 signal and enters the closed WAIT state close-wait The client enters the FIN-WAIT-2 state after receiving the message.

After the third wave, the server sends a FIN=1 signal, ACK=1, ACK= U +1, and seQ = W. The server enters the last-ACK state

Fourth wave: After receiving the reply, the client sends ACK=1, ACK= W +1, and seq= U +1. The client enters the time-wait state, and the client closes after the maximum two packet lifetime. The server enters the CLOSE state immediately after receiving the confirmation.

Why three handshakes?

1. Firstly, TCP connection communicates based on THE SEQ sequence number. The three-way handshake is used to establish the starting value of the serial number sent by both parties. That is to ensure that the serial number complete synchronization confirmation. For example, in the process of sending a connection request timeout, due to network congestion, and then sent to a connection request, at this time This link request to the server interaction is completed and closed down links, but at this time of the last link to the server, if is two shake hands, will establish a connection by the server at this time, However, the client side has already discarded this response, thus resulting in a waste of resources.

Why four waves

The four waves are primarily ACK responses and FIN requests are sent separately. When the server receives a FIN response, it simply indicates that the client has no message to send. But it can also receive data, and the server side can also receive data and send it back to the client, so it just sends an ACK telling the client that I received your request to close the connection. After the data is sent, a FIN can be sent to notify the client to close the connection.

The client finally waits for 2MSL

The first: Ensure that the last time the client sends an ACK response to the server, the standing in the server’s point of view, has been sent a FIN the disconnect request, the client has not give me response, should be to disconnect message it did not receive, I send the request and the server will send a again, and the client can be received within the MSL 2 periods the retransmission packets, A response message is sent and the 2MSL timer restarts.

Second, prevent similar invalid connection request message segments from appearing in this connection. After the client sends the last acknowledgement message, in this 2MSL time, all the message segments generated during the duration of the connection can be removed from the network. In this way, the new connection does not contain the request packets of the old connection.