This article is based on the collection of questions and answers from various interview guides on the Internet. No offense to the original writers, if you have similar questions in your blog or writing platform, please tell me, I will give you the link to add, I just for the convenience of later when I need to brush, do not have to look for questions everywhere.

Difference between Http and HTTPS

• HTTP is the HTTP protocol running on top of TCP. All transmitted content is in plain text, and neither the client nor the server can verify the identity of the other. • HTTPS means that HTTP runs on top of SSL/TLS and SSL/TLS runs on top of TCP. All transmitted content is encrypted using symmetric encryption, but the symmetric encryption key is asymmetrically encrypted using the certificate of the server. In addition, the client can authenticate the server. If client authentication is configured, the server can also authenticate the client. • HTTPS requires you to apply for a certificate from a CA. Generally, a free certificate is rare and requires a fee. • HTTP is a hypertext transfer protocol, where information is transmitted in plain text, while HTTPS is a secure SSL transfer protocol. • HTTP and HTTPS use completely different connections and use different ports, including 80 and 443. • HTTP is a simple and stateless connection. • HTTPS is a network protocol that uses SSL and HTTP to encrypt transmission and authenticate identities. It is more secure than HTTP

How does TCP ensure reliable transmission

○ Packet verification ○ Timeout retransmission mechanism ○ Reply mechanism ○ Reordering out-of-order packets ○ TCP also provides traffic control

Why does a TCP connection require three handshakes, not two? Why

• An error occurs in case an invalid connection request segment is suddenly sent to the server. • Invalid connection request packet segment In this case, the first connection request packet segment sent by the client is not lost, but is detained at a network node for a long time. As a result, it is delayed to reach the server until a certain time after the connection is released. Originally, this is an invalid packet segment. However, after the server receives the invalid connection request packet segment, it mistakenly thinks it is a new connection request sent by the client. Then the client sends a confirmation message to agree to establish a connection. Assuming that the “three-way handshake” is not used, a new connection is established as soon as the server sends an acknowledgement. Since the client does not send a connection request, it ignores the server’s confirmation and does not send data to the server. However, the server assumes that the new transport connection has been established and waits for data from the client. As a result, many of the server’s resources are wasted. The three-way handshake prevents this from happening. For example, the client does not issue an acknowledgement to the server’s acknowledgement. When the server receives no acknowledgement, it knows that the client has not requested a connection.”

What if the client keeps sending requests for connections?

• The server creates a link for each request, sends a reply to the client, and then waits for the client to send a third handshake packet, which is a waste of resources. Step 1: The client sends the connection request packet to the server (1) Step 2: the server replies the connection request packet to the client (2), and then the server waits for the client to send the third step packet of the TCP/IP connection (3) Step 3: If the client does not send the last packet to the server (3), The server must wait 30 to 2 minutes to close the link. When a large number of requests go to step 2, but not step 3, the server has a large amount of resources waiting for a third packet. It causes DDos attacks. • DDos prevention (there is no cure unless TCP/IP is not used), • Ensure that the system files on the server are the latest version, Update system patches in a timely manner • Disable unnecessary services • Limit the number of SYN half-connections that can be opened at the same time • Shorten the time-out period for SYN half-connections • Configure the firewall correctly • Prohibit access to non-open services on the host • Restrict access to short IP addresses • Enable anti-ddos properties of the firewall • Strictly restrict access to external servers. • Check privileged and non-privileged ports carefully when running the port mapper. • Carefully check the logs of network devices and host/server systems. Any log leak or time change could mean the machine is under attack. • Restrict network file sharing outside the firewall. This will give hackers the opportunity to intercept system files, host information exposed to hackers, is undoubtedly to give the other party the opportunity to invade.

What’s the difference between GET and POST?

• Browsers have limits on the length of urls, So GET requests cannot send large amounts of data instead of POST requests • GET requests send smaller amounts of data • GET requests are insecure • GET requests are idempotent • POST requests cannot be cached • POST requests are “secure” relative to GET requests • POST requests are used in the following situations:

  1. Unable to use cached files (updating files or databases on the server)
  2. Sending large amounts of data to the server (POST has no data limit)
  3. POST is more stable and reliable than GET when sending user input containing unknown characters >4. POST is more secure than GET

Is TCP different from UDP? How to improve TCP

• Difference between TCP and UDP ○ UDP is connectionless, that is, no connection is required before sending data. UDP uses best effort delivery, that is, reliable delivery is not guaranteed and congestion control is not used. ○ UDP is packet oriented. UDP has no congestion control and is well suited for multimedia communications. ○ UDP supports one-to-one, one-to-many, many-to-one, and many-to-many communication. ○ The header of UDP has a small overhead of only 8 bytes. ○ TCP is a connection-oriented transport layer protocol. ○ EACH TCP connection can have only two endpoints, and each TCP connection can be point-to-point (one-to-one). ○ TCP provides reliable delivery services. ○ TCP provides full-duplex communication. ○ TCP is a byte stream. ○ Minimum 20 bytes in header. • TCP accelerates transmission efficiency – A single confirmation mechanism is adopted

The process from entering a url to getting a page

• Query DNS, Obtain the IP address corresponding to the domain name ○ Search the DNS cache of the browser ○ Search the DNS cache of the operating system ○ Read the HOST file of the local HOST ○ Initiate a DNS system call • View the cache of the broadband carrier server • Initiate an iterative DNS resolution request from the carrier server • After a TCP/IP connection is established, the browser can send an HTTP request to the server. • The server receives the request and, according to the path parameters, • The browser gets the complete HTML page code and starts parsing and rendering. If it encounters static resources such as external JS, CSS and images referenced, they are also HTTP requests. • The browser renders the page based on the resources it receives, and eventually renders a complete page to the user

TCP Connection establishment (three-way handshake)

1. The TCP server process first creates the transfer control block TCB and is ready to accept the connection request from the client process. At this time, the server enters the LISTEN state. 2. The TCP client process creates TCB and sends a connection request packet to the server. SYN=1 in the header of the packet and seq= X is selected. According to TCP, the SYN segment (SYN=1) cannot carry data, but must consume a sequence number. 3. After receiving the request packet, the TCP server sends an acknowledgement packet if it agrees to the connection. In the acknowledgement packet, ACK=1, SYN=1, ACK= X +1, and seq= Y are initialized. Then, the TCP server process enters the SYN-RCVD state. This message also does not carry data, but again consumes a serial number. 4. The TCP client process sends an acknowledgement to the server after receiving the acknowledgement. Confirm the ACK=1, ACK= y+1, and seq= X +1 of the packet. In this case, the TCP connection is ESTABLISHED and the client enters the ESTABLISHED state. According to TCP, AN ACK packet segment can carry data, but does not consume serial numbers if it does not. 5. After receiving the confirmation from the client, the server enters the ESTABLISHED state and the two parties can communicate with each other.

Why does the TCP client send an acknowledgement at the end?

In short, the main purpose is to prevent invalid connection request packets suddenly sent to the server, resulting in errors. If you are using two handshake connection is established, suppose there is such a scenario, the client sends the first request connection and not lost, just because in the network node in the retention time is too long, as a result of the TCP client has not received the confirmation message, thought the server did not receive, at this time to send this message to the server, The client and server then complete the connection with two handshakes, transfer data, and close the connection. This message should be invalid. However, the two-handshake mechanism will allow the client and server to establish a connection again, which will lead to unnecessary errors and waste of resources. If the three-way handshake is used, even if the invalid packet is sent, the server receives the invalid packet and replies with an acknowledgement message, but the client does not send an acknowledgement again. Since the server does not receive an acknowledgement, it knows that the client has not requested a connection.

TCP connection release (four waves)

1. The client process sends a connection release packet and stops sending data. Release the header of the data packet, FIN=1, whose sequence number is SEq = U (equal to the sequence number of the last byte of the previously transmitted data plus 1). At this point, the client enters the fin-WaIT-1 state. According to TCP, FIN packets consume a sequence number even if they do not carry data. 2. After receiving the connection release packet, the server sends an ACKNOWLEDGEMENT packet with ACK=1, ACK= U +1 and its serial number seq= V. In this case, the server enters close-wait state. The TCP server notifies the higher-level application process that the client is released from the direction of the server. This state is half-closed, that is, the client has no data to send, but if the server sends data, the client still accepts it. This state also lasts for a period of time, i.e. the duration of the close-wait state. 3. After receiving the confirmation request from the server, the client enters the FIN-WaIT-2 state and waits for the server to send a connection release packet (before receiving the final data from the server). 4. After sending the final data, the server sends a connection release packet with FIN=1 and ACK = U +1 to the client. If the server is in the half-closed state, it is likely to send some more data. 5. After receiving the connection release packet from the server, the client sends ACK=1, ACK= W +1 and its serial number is SEq = U +1. In this case, the client enters the time-wait state. Note that the TCP connection is not released at this time, and the client can enter the CLOSED state only after 2∗MSL (maximum packet segment life) and the corresponding TCB is revoked. 6. The server enters the CLOSED state immediately after receiving the confirmation from the client. Similarly, revoking the TCB terminates the TCP connection. As you can see, the server ends the TCP connection earlier than the client.

Why does the client end up waiting for 2MSL?

MSL (Maximum Segment Lifetime) : TCP allows different implementations to set different MSL values. First, ensure that the client sends the final ACK packet to reach the server, because the ACK packet may be lost, standing in the server’s perspective, I have already sent the FIN + ACK message request disconnect, the client also did not give me response, should be I send the request of the disconnect message it did not receive, then the server will send a again, The client receives the retransmitted message within the 2MSL period, responds with a message, and restarts the 2MSL timer. Second, prevent “invalid connection request message segment” as mentioned in “three-way handshake” 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.

Why is establishing a connection a three-way handshake, but closing a connection a four-way wave?

During connection establishment, the server receives a SYN packet in LISTEN state and sends the ACK and SYN packets to the client. And close connection, the server receives the other side of the FIN message, just said to each other can no longer send data but also receives the data, and the oneself also is not necessarily all data are sent to each other, so their can immediately shut down, also can send some data to each other, then send the FIN message now agreed to close the connection to the other side, therefore, The ACK and FIN are usually sent separately, resulting in an extra ACK.

What if the connection has been established, but the client suddenly fails?

TCP also has a keepalive timer, so obviously if the client fails, the server can’t wait forever and waste resources. The server resets this timer every time it receives a request from the client, usually for two hours. If it does not receive any data from the client within two hours, the server sends a probe segment, which is then sent every 75 minutes. If there is no response after 10 probe packets are sent, the server assumes that the client is faulty and closes the connection.

The answers to some of the questions in this article are linked below:

Blog.csdn.net/qzcsu/artic…