Nowadays, the interview threshold is getting higher and higher, and many developers don’t know much about network knowledge, so they will be at a loss when they meet these interview questions. This article focuses on HTTP. The knowledge in this article comes from Illustrated HTTP and Wikipedia, please point out any errors. The article will be updated continuously.

Interview — Network TCP/IP

Understand Web and network basics

To end transmission

When transmitting data from layer to layer, the sender will add header information to each layer, and the receiver will delete a header after each layer

Multiple protocol functions

The role of IP, TCP, and DNS services in using HTTP

Simple HTTP protocol

Request packets and response packets

When the client initiates a request to the server, a request packet is generated. The request packet consists of request method, URL, protocol version, optional request header field and content entity.

The request message

The server that receives the request returns the processing structure of the request content in the form of a response. The response message basically consists of the protocol version, the status code, the cause phrase used to explain the state, the optional response header field, and the entity body.

The response message

HTTP is a simple introduction to protocols and cookies that do not save state

The HTTP protocol does not persist requests and responses. Cookie technology was introduced for state management. Cookies are used to manage login state. Without cookies, HTTP does not save state and you must log in again every time you open a new web page.

The Cookie notifies the client to automatically save the Cookie based on the set-cookie field in the response packet. Cookies are automatically sent on the next request and the server compares the data to get a status result.

Cookie

The difference between Post and Get

Let’s start with side effects and idempotence.

Side effects refer to changes made to resources on the server. Searching has no side effects, while registration has side effects.

Idempotent means that M and N requests (different and both greater than 1) are sent, and the state of the resources on the server is consistent. Registering 10 and 11 accounts is not idempotent, making 10 and 11 changes to articles is idempotent.

In standard application scenarios, Get is mostly used in idempotent scenarios with no side effects, such as searching for keywords. Post is mostly used in side-effect, non-idempotent scenarios, such as registrations.

Technically speaking:

  • Get requests can be cached, but Post requests cannot
  • Post is a little more secure than Get, because Get requests are contained in the URL and will be saved by the browser. Post is not, but in the case of packet capture, it is the same.
  • Post can use the Request Body to transfer more data than Get, which doesn’t have this technology
  • Urls have a length limit that affects Get requests, but this length limit is browser-specific, not RFC specific
  • Post supports more encoding types and does not restrict data types

Common status code

Common status code

2 xx success

  • 200 OK: indicates that the request from the client is processed correctly on the server
  • 204 No content: Indicates that the request is successful, but the response packet does not contain the body of the entity
  • 206 Partial Content for a range request

3 xx redirection

  • 301 Moved permanently, permanently redirects: indicates that the resource has been assigned a new URL
  • 302 Found, temporary redirection, indicating that the resource was temporarily assigned a new URL
  • 303 See Other: indicates that another URL exists for the resource. Use GET to obtain the resource
  • 304 Not Modified: indicates that the server allows access to the resource but the request condition is not met
  • 307 Temporary redirect Is the same as 302

4XX Client error

  • 400 Bad Request: Syntax errors exist in the request packet
  • 401 Unauthorized: The request to be sent requires authentication information that is authenticated through HTTP
  • 403 Forbidden: Access to requested resources is denied by the server
  • 404 not found: No requested resource was found on the server

5XX Server error

  • 500 Internal sever error: an error occurred when the server executed the request
  • 503 Service Unavailable: The server is temporarily overloaded or is being stopped for maintenance and cannot process requests

The HTTP header

Gm’s first

Field that can be used in both request and response packets

  • Cache-Control
    • No-cache Indicates that the client does not cache expired resources
    • No-store indicates that no cache is performed
    • Max-age indicates that the cache duration of the resource is smaller than the specified value. The client accepts the cache resource and the cache server does not confirm the validity of the resource
  • Connection controls the header field (hop-by-hop) that is no longer forwarded to the agent and manages persistent connections
    • Close indicates that the server is explicitly disconnected
    • Keep-alive indicates to save the persistent connection. Before HTTP/1.1, the default connection is non-persistent. You need to add this field if you want to save the persistent connection
  • Upgrade can be used to specify a completely different communication protocol, for which the server can return a 101 status code

Request header field

  • Accept refers to the media types that the user agent can handle and their relative priority
  • Accept-encoding is used to inform the server of the content Encoding supported by the user agent and the priority order of the content Encoding
  • Authorization refers to the authentication information used to inform the server of the user agent
  • Host If multiple domain names exist under an IP address, the help server knows the specific Host to be requested
  • The user-agent communicates information to the server, such as the browser that created the request and the name of the User Agent

HTTPS

HTTPS is HTTP based on the SSL/TLS security protocol.

In iOS, the client stores the CA certificate locally. In AN HTTPS request, the client first asks for the public key from the server. After obtaining the public key, the client uses the local CA certificate to verify the public key and sends the encrypted information to the server.

The SSL/TLS handshake phase is divided into five steps: In the first step, Alice gives the protocol version number, a Client random number generated by a Client, and the encryption method supported by the Client. In the second step, Bob confirms the encryption method used by both parties and presents the digital certificate, along with a Server random number. In the third step, Alice confirms that the digital certificate is valid, then generates a new random number (Premaster secret), encrypts this random number using the public key in the digital certificate, and sends it to Bob. Fourth, Bob uses his private key to obtain the random number sent by Alice (Premaster secret). In the fifth step, Alice and Bob use the first three random numbers according to the agreed encryption method to generate “session keys”, which are used to encrypt the whole process of the following dialogue.

HTTPS has a lower performance than HTTP because SSL/TLS has several handshakes and encryption and decryption processing, but encryption and decryption processing can already be accelerated by special hardware.