This is the sixth day of my participation in Gwen Challenge

HTTP is the basic network knowledge that interview often asks, this article briefly summarizes

HTTP profile

HTTP stands for Hyper Text Transfer Protocol. It is a Protocol used to Transfer hypertext from World Wide Web servers to local browsers. HTTP is a TCP/ IP-based communication protocol to transfer data (HTML files, image files, query results, etc.)

HTTP Request Mode

According to the HTTP standard, HTTP requests can use multiple request methods

HTTP1.0 defines three request methods: GET, POST, and HEAD

HTTP1.1 adds six new request methods: OPTIONS, PUT, PATCH, DELETE, TRACE, and CONNECT

GET requests information about the specified page and returns the entity body. HEAD is similar to a GET request, except that the response returned does not contain the specific content. The data is contained in the request body. A POST request may result in the creation of a new resource and/or the modification of an existing resource. PUT Data sent from a client to a server replaces the contents of a specified document. DELETE Requests the server to DELETE a specified page OPTIONS allows clients to view server performance. TRACE back requests received by the server. It is mainly used to test or diagnose PATCHCopy the code

HTTP Three handshakes four waves

Three handshakes and four waves are often asked in interviews. In addition to the process of shaking hands and waving hands, we also need to know the principle

Three-way handshake

  • The client sends a SYN packet with SYN=1 and SEq =x(random number).
  • The server receives the request and identifies it as a SYN=1 packet (the client initiates the request). The server then assemes an ACK packet containing SYN=1,ACK=1, ACK= x+1(seq+1 from the client), and SEq =y(random number).
  • When the client receives an ACK packet, the server will verify that the ACK code is the result of a SYN seq+1 packet. If yes, the server will send an ACK packet containing ACK=1, ACK= y+1
  • After receiving the ACK packet, the server verifies that ACK=1 and the ACK code is the result of the ACK code +1 sent by the server to the client.

Why three handshakes?

The seQ in the ACK packet is +1 to verify that the sending and receiving are normal. The triple handshake is the minimum number of secure handshakes to ensure that both the sending and receiving functions are normal

Four times to wave

  • The client sends a FIN packet containing FIN=1 and SEq =x(random number). After the FIN packet is sent, the client cannot send data but can accept data and waits for state 1 to be disabled
  • After receiving a FIN packet, the server returns an ACK packet containing ACK=1 and ACK= x+1. After sending the ACK packet, the server cannot accept data but can send data
  • The client waits for the SERVER to return the FIN package
  • The server sends a FIN packet, including FIN=1 and SEq = Y (random number). After sending the FIN packet, the server waits for the ACK packet from the client.
  • The client receives the FIN packet sent by the server and sends an ACK packet containing ACK=1 and ACK= y+1
  • The client waits 2MSL and then closes the connection.
  • The server receives the client ACK package and closes the connection.

Why four waves?

Because when the client sends the FIN packet to the server, the server may have data transmission at this time, so it cannot send the FIN packet and ACK packet information together to the client like a three-way handshake. It can only tell the client that I received your FIN packet. After the server sends the final data, it sends a FIN packet to the client. After the client receives the FIN packet, it shuts down. Similarly, the server does not shut down until it receives an ACK packet from the client.

The client does not close immediately after receiving the FIN packet and sending the ACK packet to the server. The waiting 2MSL is twice the Maximum Segment Lifetime. MSL refers to the maximum lifetime of a fragment in the network. 2MSL refers to the maximum time required for a send and a reply.

Waiting for MSL 2 because the client receiving the FIN bag after send an ACK packet to the server, the client can not make sure that the server receives an ACK packet, if by this time the server did not receive an ACK packet, the server will be for a period of time to send the FIN bag to the client, then client receives the FIN bags, will send an ACK packet to the server, Repeat the handshake for the fourth time. If the client waits more than 2MSL, the link will be dropped.

Why use HTTPS

When HTTP is used for communication, all communication is in plaintext. If the communication information between users or sensitive information such as passwords is monitored, the consequences will be very serious. Therefore, HTTP packets need to be encrypted.

  • Use symmetric encryption: but using symmetric encryption, it is required that both sides know the secret key and use the same secret key for encryption and decryption, but there will be a problem here, is the communication of the secret key, how does the client know what the secret key is? If write dead in the page, the secret key is also very easy to be cracked, if through the server will secret key to inform the client in advance, so in the process of transfer of the secret key, actually broker can access to the secret key, then encryption, there is no any effect, middlemen can still through the capture of the secret key to decrypt the encrypted information get clear information.

  • Asymmetric encryption: The sender uses the public key to encrypt data, and the receiver uses the private key to decrypt data. Then the client can request the server to obtain the public key of the server to encrypt the submitted content, and then the server uses its private key to decrypt the submitted content. But there will be a problem here, is that if middlemen capture to the server’s public key, and then the interception to return to the broker’s public key to the client, the client will unwittingly, thought that this public key is the target server’s public key, and then use the public key to encrypt the data (the actual use of middlemen is public key), after send the encrypted data at this time, The middleman can decrypt the data using his private key, then encrypt it using the target server’s public key and send it back to the target server, thus stealing the encrypted plaintext without anyone knowing. The main problem is that the client cannot know if the public key obtained is from the target server.

  • CA certificate: A CA certificate is a certificate issued by an organization. The CA uses its own private key to encrypt the public key of the server and generates a certificate using the server information. The signature of the certificate is also encrypted using the CA issuer’s private key. Then we will get a certificate file and configure it on our server. Nginx etc will have SSL configuration parameters for HTTPS requests, which is to read this file. So when the client to the server when a request, the server will return this certificate information, at this time because our system and browser are built in each big CA public key information, then the client only need to use the CA certificate issuing authority’s public key to decrypt the certificate, and then through some verify whether this certificate is valid (certificate owner, Validity period, etc.), if valid, then you can decrypt the server public key information in the certificate, and then use the server public key to encrypt information for transmission.

With HTTP, we just use TCP to shake hands and then communicate directly, but with HTTPS, we need SSL/TLS to shake hands after the TCP handshake is successful.

Four times to shake hands

  • First handshake: the client initiates an encrypted communication request to the server with the supported protocol version, such as TSL1.0, a random number generated by the client, the supported encryption algorithm, and the supported compression algorithm.

  • Second handshake: After receiving the request from the client, the server checks whether the encrypted communication protocol versions are consistent. If the versions are consistent, the server generates a random number and a CA certificate to confirm the encryption algorithm. Otherwise, the encrypted communication is disabled.

  • Third handshake: After receiving the return from the server, the client verifies the validity of the certificate and decrypts the certificate. After the verification succeeds, the client sends the following message to the server: The client encrypts a random number using the server public key decrypted by the CA certificate, notifies the client of the change of encoding, and notifies the client of the end of the handshake (including the hash value of all the contents of the first handshake, and verifies the server).

  • Fourth handshake: After receiving the handshake, the server returns a notification of the code change and the end of the handshake (containing the hash value of all the contents of the second handshake for verification by the client).

In the first three handshakes, a random code is generated for each other. After the third handshake, the client and server both have three random codes. However, these three random codes are used by the server and client to generate a secret key, which is finally encrypted and decrypted as a symmetric secret key. After the SSL/TSL four handshakes, HTTP communication continues