Application layer of computer network -HTTP, HTPS, DNS- part ii

⭐️⭐️ This article is a summary of my computer network review, because the content is too much I divided it into two parts to write, the last one will transport layer protocol TCP, UDP, this one is about the application layer protocol HTTP, HTPS, DNS~~

The HTTP protocol

HTTP is a convention and specification for transferring hypertext data, such as text, images, audio, and video, between clients and servers. Port 80 is used by default. It uses TCP as the transmission layer protocol to ensure the reliability of data transmission.

HTTP features? What are its disadvantages?

Features: End-to-end, flexible, scalable, reliable, stateless, persistent connection

• HTTP is an end-to-end protocol and a request/response protocol.

• Flexible and extensible: one is semantically free, specifying only the basic format, without strict restrictions on other parts; The second allows the transfer of any Type of data object, such as text, image, audio, etc., with the transfer Type marked by the Content-Type.

• Reliable transport, HTTP is based on TCP/IP, so it inherits this feature.

• Stateless, which means that HTTP requests do not have the ability to save previously sent requests or responses, and each request is independent.

• Persistent connections, HTTP1.1 after the default use of persistent connections, the default TCP connection is not closed, multiple requests can be reused, for the same domain, most browsers support simultaneous establishment of up to six persistent connections.

  Disadvantages: may be eavesdropped, tampered with, encounter camouflage, stateless, queue head blocked

• Plaintext transmission (not encrypted), the content may be eavesdropped.

• The integrity of the packet cannot be verified and the content may be tampered.

• Do not verify the identity of the communicating party and may encounter camouflage.

• Statelessness, it’s a disadvantage and a benefit, in different scenarios.

• Queue head blocked. HTTP2 multiplexing solves the problem

• • HTTP/2 is multiplexed so that both the client and the server can send multiple requests or responses in a single connection at the same time without having to send them in sequence, thus avoiding the problem of “queue congestion”.
• • Binary minute hand roots: The message format is now split into binary frames, with Headers frames holding the header field and Data frames holding the request body Data. After frame splitting, the server sees a bunch of out-of-order binary frames instead of complete HTTP request packets. These binary frames are not sequenced, so they are not queued, and there is no HTTP queue blocking. When out-of-order binary frames arrive, the peer party will assemble binary frames with the same Stream ID into complete request packets and response packets.

HTTP request packet

The first line of an HTTP request is called a request line, followed by a header field, which can be followed by an entity body. There is a blank line after the request header. This blank line cannot be omitted. It is used to separate the header from the entity.

Request line fields: method field, URL field, and HTTP version field.

Methods field

General operations include GET, POST, HEAD, PUT, and DELETE. GET: obtains resources and is idempotent. HEAD: obtains the HEAD of a packet, which is similar to GET but does not return the body of a packet. DELETE: deletes a resource. This operation is the opposite of PUT. OPTIONS: queries HTTP methods supported by the server. Establish connection tunnels for proxy servers. Idempotent operations TRACE: TRACE requests to see how they were processed/tampered with. Idempotent operations. Vulnerable to XST cross-site tracking attacks.

What’s the difference between Post and Get?

(1) From the perspective of application scenarios, GET request is an idempotent request. Generally, GET request is used for scenarios that have no impact on server resources, such as requesting a web page. Post, on the other hand, is not an idempotent request and is generally used in situations that affect server resources. Things like registering users.

(2) From a caching perspective, browsers generally cache Get requests, but rarely Post requests.

(3) In terms of the format of the sent message, the entity part of the Get request message is empty, while the entity part of the Post request message is generally the data sent to the server.

(4) From the perspective of parameters, GET is generally placed in THE URL to transfer parameters, while POST is placed in the request body, which is more suitable for transferring sensitive information. Also, the argument passing of POST supports more data types. GET can only be URL encoded.

HTTP response packet

Response line fields: version number, status code, and reason phrase

Status code

1xx: indicates that the protocol processing is in the intermediate state and subsequent operations are required. 101 Switching Protocols

2xx: indicates that the status is successful. 200 OK 204 No Content 206 Partial Content

3xx: Indicates the redirection status. The location of resources changes and a request needs to be made again. 301 Moved Permanently 302 Found 303 See Other 304 Not Modefied 307 Temprary Redirect

302 is the protocol status code of HTTP1.0. In http1.1, there are two additional 303 and 307 to refine the 302 status code. 303 explicitly states that the client should use the GET method to obtain the resource, and that it will turn the POST request into a GET request for redirection. 307 will comply with browser standards and will not change from POST to GET.

4xx: The request packet is incorrect. 400 Bad Request 401 Unauthorized 403 Forbidden 404 Not Found

5xx: An error occurs on the server. 500 Internal Server Error 501 Not Implemented 502 Bad GateWay 503 Service Unavailable

HTTP radical

There are so many HTTP radicals that it’s not necessary to write them all down. I’ll just pick out the most important ones:

General Header Fields: The Header used by both request and response packets

• Cache-control Controls the Cache
• Connection Management, item by item header
• Transfor-encoding Transmission Encoding of the packet body

Reauest Header Fields: the Header used by the client to send request packets to the server

• Accept Specifies the media type that the client or agent can handle
• If-match Compare entity tag (ETage)
• If-none-match Compares entity flags (etages) as opposed to if-match
• If-modified-since Compares the resource update time (last-modified)
• If-unmodified-since Compares the resource update time (last-modified), as opposed to if-modified-since
• If-rnages send range requests for entity Byte when the resource is not updated
• Range Specifies the byte Range request for the entity
• Authorization Web authentication information
• Host Server for requesting resources
• User-agent Indicates the client program information

Response Header Fields: Fields used in the Response from the server to the client

• Accept-ranges Specifies the range of bytes that are acceptable
• Location Specifies the URI that the client is redirected to
• ETag is a string that can represent a resource unique to a resource
• Server Indicates the Server information

Entiy Header Fields: The Header is used for the entity part of the request and response messages

• Allow Resources can support HTTP request methods
• Last-modified resource The Last Modified resource
• Expires An expired resource for an entity body

HTTP / 2 protocol

New features of HTTP/2: binary protocol, multiplexing, data flow, header compression, server push

Binary protocol HTTP/2 is a complete binary protocol, header information and data body are binary, and collectively called “frame”, can be divided into header information frame and data frame. The concept of frame is the basis of its multiplexing.

Multiplexing HTTP/2 implements multiplexing. HTTP/2 still multiplexes TCP connections, but within a connection, both the client and the server can send multiple requests or responses at the same time, and do not send them in sequence, thus avoiding the “queue congestion” problem.

Data flow HTTP/2 refers to all packets of data for each request or response as a data flow. Each data stream has a unique number. The data flow ID must be marked when the data packet is sent to distinguish which data flow it belongs to.

Header compression HTTP/2 implements header compression, and since the HTTP 1.1 protocol has no state, all information must be attached to each request. Therefore, many fields of the request are repeated, such as Cookie and User Agent. The same content must be attached to each request, which will waste a lot of bandwidth and affect the speed. HTTP/2 optimizes this by introducing header compression.

Server push HTTP/2 allows a server to send resources to a client unsolicited. This is called server push.

The HTTPS protocol

In essence, it makes up for HTTP’s shortcomings: data privacy, encrypted content; (encryption and decryption) data integrity, content integrity check; (digital signature) identity authentication, third party cannot disguise the identity of client/server (digital certificate)

Differences between HTTP and HTTPS

HTTPS standard port 443, HTTP 80 HTTPS will display a green security lock on the browser, and HTTP does not make up for the shortcomings of HTTP, data privacy, integrity, authentication. So it’s safer.

Hybrid encryption (the way HTTPS is used)

Combining the advantages of the two encryption methods, asymmetric encryption is used in the key exchange, and symmetric encryption is used in the communication exchange message establishment.

Process: The party sending the ciphertext uses the “public key of the other party” to encrypt the “symmetric key”. After receiving the ciphertext, the other party uses its private key to decrypt the “symmetric key” to obtain the “symmetric key”. This ensures that the exchanged key is secure and uses the symmetric encryption mode to communicate.

Digital signature, digital certificate process (two pictures are done)

TLS1.2 handshake, the ECDHE handshake process?

A: Client_RANDOM, TSL version number, and encryption suite list ->B B: After confirming the version number, server_RANDOM, server_Params, required encryption suite, and its own certificate ->A A: Certificate verification succeeds. At the same time, calculate A pre_random, ECDHE(client_params, server_params) = per_random The three random numbers obtained are calculated by a pseudo-random function to obtain the final secret, which is the symmetric key for subsequent communication and sends the ending information to B B: The server will generate secret in the same way as the client, and also send an ending message to the client. AB: The handshake is over after each of you has received the final message and verified successfully. The secret symmetric key is then used to encrypt the packets for transmission. ,Copy the code

Detailed process:

1. When the client sends the HTTPS request for the first time, it sends the client_random, TSL version number, and encryption suite list to the server

2. After receiving the TSL, the server confirms the version number of TSL and sends server_random, server_Params, the encryption suite to be used, and its certificate to the client

3. Upon receiving this information, the client first validates the server’s certificate (subject 7), passing a client_params to the server if successful

4. At the same time, the client calculates a PRE_RANDOM through the ECDHE algorithm, passing in two parameters, one client_params and one server_params. ECDHE(client_params, server_params) = per_random

5. At this time, the client has client_RANDOM, server_RANDOM, and pre_RANDOM at the same time. It calculates these three parameters through a pseudo-random function to obtain the final secret, which is the symmetric key used for their subsequent communication.

6. After the client generates secret, it will send an ending message to the server, telling the server to use symmetric encryption after that, and the algorithm of symmetric encryption is agreed with the first time.

7. The server generates secret in the same manner as the client when it receives the client_params just passed in, and also sends a closing message to the client.

8. When both parties have received the closing message and verified it successfully, the handshake ends. The secret symmetric key is then used to encrypt the packets for transmission.

Description RSA handshake

1. The client first sends an HTTPS request to the server

2. The server returns the pre-configured public key certificate to the client along with other information

3. After receiving the certificate from the server, the client authenticates the certificate by referring to the process of digital certificate authentication to obtain the information about the server and its public key

4. After the verification is successful, the pseudo-random function is used to calculate a symmetric key (secret) needed for encryption, and the public key of the server is used to encrypt the symmetric key and send it to the server

5. The server then decrypts the message with its own private key to obtain the symmetric key inside. At this point, both the server and client have symmetric keys.

6. The subsequent transmission will use this secret for symmetric key encryption and decryption transmission

The difference with TLS handshake? Most important: RSA does not have forward security, ECDHE does; One crack does not affect the history of information is the nature of forward security.

Refer to the article

There may be some references I forgot, I will list what I remember, thanks again ~

• One hundred Chocolate: github.com/Chocolate19…
• CavsZhouyou：github.com/CavsZhouyou
• God three :(suggested intensive reading) HTTP soul question, consolidate your HTTP knowledge system
• Lindaidai_lin: Shutdown HTTP series of articles
• Looking for Sealen96: Interviewer (9) : Probably the most complete HTTP interview answer on the web

⭐️⭐️ all saw this, asking a like is not too much, can one button three times that would be better, your support is my motivation to continue writing

⭐️ should fill up the network interview questions encountered in the follow-up, may also be a summary of some small knowledge points such as cookies, anyway, this article is not the end of ~

Finally, I wish you all good health, happy every day, everything goes well, get rich and get rich