HTTP interview questions (with answers, constantly updated)

This is the 6th day of my participation in the August More Text Challenge

Computer network interview questions have been common in programmer interview, here the concept of complex, and rarely used in the usual work, it is easy to forget after reading.

So, I did a series of collation for the computer network interview questions, I referred to a large number of resources on the network and classic reference books, and strive for the specific interview questions to explain clearly, emphasize understanding memory, refused to eight essay!! . This article is not only a summary of my own learning, but also hope to help friends who are reviewing the interview.

This article series is divided into two parts: TCP and HTTP

HTTP post

The process of entering a URL into a browser to display a page (emphasis)

Generally speaking, it can be divided into the following processes:

• The DNS
• A TCP connection
• Sending an HTTP request
• The server processes the request and returns HTTP packets
• The browser parses the rendered page
• Connect the end of the

Articles can be reference: segmentfault.com/a/119000000…

If it is a Django application, you can answer:

DNS query — TCP handshake — HTTP request — Reverse proxy Nginx — UWSGI/Gunicorn — Web App response — TCP wave

What’s the difference between HTTPS and HTTP?

• Port: HTTP URL byhttp://Port 80 is used by default and the HTTPS URL is used byhttps://Port 443 starts and is used by default.
• Security and resource consumption: HTTP runs on TOP of TCP. All content transmitted is in plain text, and neither the client nor the server can verify the identity of the other. HTTPS is the HTTP protocol that runs on top of SSL/TLS, which 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. Therefore, HTTP is not as secure as HTTPS, but HTTPS consumes more server resources than HTTP.
  • Symmetric encryption: Only one key is used to encrypt and decrypt the same password, and the encryption and decryption speed is fast. Typical symmetric encryption algorithms include DES and AES.
  • Asymmetric encryption: The key is in pairs (and the private key cannot be deduced from the public key, nor the public key from the private key). Different keys are used for encryption and decryption (public key encryption requires private key decryption, and private key encryption requires public key decryption). Symmetric encryption is slower.

HTTPS how to establish a connection (key)

• The browser sends information about supported encryption algorithms to the server
• The server selects an encryption algorithm supported by the browser and sends a certificate back to the browser
• The browser verifies the validity of the certificate, encrypts the information with the certificate public key, and sends it to the server
• The server uses the private key to decrypt the message, validate the hash, and encrypt the response message back to the browser
• The browser decrypts the response message, verifies the message, and encrypts the interaction data

More detailed steps are as follows:

HTTPS adds the TLS protocol between the HTTP and TCP layers.

HTTPS is an application-layer protocol. You need to establish a TCP connection and then go through the TLS handshake to establish a secure communication connection.

In fact, different key exchange algorithms, TLS handshake process may have some differences.

Here to briefly introduce the key exchange algorithm, because considering the performance problems, so the two sides of the encryption application information is symmetric encryption keys, and symmetric encryption key can’t be leaked, to ensure the security of the symmetric encryption key, so use asymmetric encryption to protect the symmetric encryption key negotiation, the work is responsible for the key exchange algorithm.

TLS first handshake

• The Client first sends a “Client Hello” message.
• The message contains the TLS version number used by the Client, the list of supported cipher suites, and the generated Client Random number, which is retained by the server as one of the materials used to generate the symmetric encryption key.

TLS second handshake

• After receiving the Client Hello message from the Client, the Server checks whether the TLS version is supported, selects a password suite from the password suite list, and generates a Server Random number.
• Next, a “Server Hello” message is returned, which contains the TLS version number confirmed by the Server and a Server Random number, and an appropriate ciphersuite is selected from the client’s list of ciphersuites. In fact, these two random numbers are the conditions for generating the “session key”, which is the symmetric encryption key used during data transmission.
• Then, to prove its identity, the Server sends a “Server Certificate” to the client, which contains the digital Certificate.
• Then, the Server sends a “Server Hello Done” message, which tells the client that I have given you everything you need and that the greeting is over.

TLS handshake for the third time

• After verifying the certificate, the client considers the certificate to be trusted and continues to proceed. Then, the client generates a new pre-master number, encrypts the number with the RSA public Key of the server, and sends the pre-master number to the server through the Change Cipher Key Exchange message.
• After receiving the packet, the server decrypts it using the RSA private key to obtain the pre-master number sent by the client.
• So far, the Client and Server share three Random numbers, namely Client Random, Server Random and pre-master.
• Therefore, according to the three random numbers obtained, the two parties generate Master Secret, which is a symmetric key used for data encryption and decryption of subsequent HTTP requests/responses.
• After the session key is generated, the client sends a Change Cipher Spec message to tell the server to send messages in encrypted mode.
• The client then sends a “Encrypted Handshake Message (Finishd)” Message that summarizes all the data previously sent, encrypts it with the master Secret, and lets the server verify it. Verify that encrypted communications are available and that previous handshake messages have not been tampered with.
• You can see that the TLS handshake data transmitted before Change Cipher Spec is in plain text, and the subsequent data is ciphertext encrypted with symmetric keys

TLS for the fourth handshake

• The server performs the same operation, sending “Change Cipher Spec” and “Encrypted Handshake Message”. If both parties verify that encryption and decryption are ok, the Handshake is officially completed.
• Finally, the “session key” is used to encrypt and decrypt HTTP requests and responses.

Common status codes (key)

There are five types of HTTP status codes:

List of corresponding HTTP status codes:

• 100: Continue. The client continues to process the request
• 101: Switching Protocol The server switches to a more advanced protocol at the request of the client
• 200 The OK request succeeded. The desired response header or data body of the request is returned with this response
• 201 Created request to implement. And a new resource has been created based on requirements
• 202 Accepted The request was Accepted. The request has been accepted, but processing is not complete
• 300 Multiple Choices. The requested resource has a selection of feedback information, and the user or browser can choose a preferred address for redirection
• 301 Moved Permanently Moved Permanently. The requested resource has been permanently moved to the new URI, the return message contains the new URI, and the browser is automatically directed to the new URI
• 302 Found temporary movement. Similar to 301. However, the resource is only temporarily moved and the client should continue to use the original URI
• 303 See Other View Other IP addresses. Similar to 301. Use GET and POST requests to view
• 304 Not Modified. If the client sends a conditional GET request and the request is granted, the content of the document has not changed (since the last access or according to the conditions of the request), the server should return this status code
• 400 Bad Request The syntax of the client Request is incorrect and cannot be understood by the server. The requested parameters are incorrect
• 401 Unauthorized The current request requires user authentication
• 402 Payment Required This status code is reserved for possible future requirements
• 403 Forbidden The server understands the request but refuses to execute it
• 404 Not Found The requested resource failed to be Found on the server
• 405 Method Not Allowed The Method in the client request is prohibited
• 406 Not Acceptable the content characteristics of the requested resource do Not satisfy the criteria in the request header and therefore cannot generate the response entity
• The 500 Internal Server encountered an unexpected condition that prevented it from completing processing the request
• 501 Not Implemented Server does Not support a function required for the current request
• 502 Bad Gateway When a server working as a Gateway or proxy tries to execute a request, it receives an invalid response from the remote server
• 503 Service Unavailable The server cannot process requests due to temporary server maintenance or overload. However, the server may recover after a period of time
• 504 Gateway time-out The server acting as a Gateway or proxy fails to obtain requests from the remote server in a timely manner
• 505 HTTP Version Not Supported The server does not support or rejects the HTTP Version used in the request

What is the difference between status code 301 and 302?

• 301: Permanent move. The requested resource has been permanently moved to the new URI, and the old address has been permanently removed. The return message will include the new URI, and the browser will automatically redirect to the new URI. Future requests should be replaced with new URIs.
• 302: Temporary move. Similar to 301, the client redirects to a new URL after receiving the response message from the server. But the resource is only temporarily moved, the old address remains, and the client should continue to use the original URI.

What is HTTP2.0

• Binary transmission (increase transmission efficiency and reduce bandwidth usage)
• Multiplex content data, (Package 1-4 HTML Package 5-8 CSS HTML data CSS data)
• Server push (access HTML, server push CSS JS)

HTTP long connection and short connection, application scenarios

Short connections are used by default in HTTP/1.0. That is, each time the client and server perform an HTTP operation, a connection is established and broken at the end of the task. When the client browser accesses an HTML or other type of Web page that contains other Web resources (such as JavaScript files, image files, CSS files, etc.), the browser re-establishes an HTTP session each time it encounters such a Web resource.

From HTTP/1.1 onwards, long connections are used by default to preserve the connection feature. HTTP with long connections adds this line to the response header:

Connection:keep-alive

In the case of a long connection, when a web page is opened, the TCP connection between the client and the server for the transmission of HTTP data is not closed. When the client accesses the server again, it continues to use the established connection. Keep-alive does not hold a connection forever, it has a hold time that can be set in different server software such as Apache. To implement persistent connections, both clients and servers must support persistent connections.

HTTP long connection and short connection are essentially TCP long connection and short connection.

How do you differentiate between different HTTP requests? Content-Length | Transfer-Encoding:chunked

Article Reference:

• www.cnblogs.com/gotodsp/p/6…
• Blog.csdn.net/luzhensmart…

Differences between HTTP/1.1 and HTTP/1.0

• Cache processing: In HTTP/1.0, if-modified-since, Expries in header are used as the criteria for cache judgment. HTTP/1.1 request headers add more cache-related fields to support more flexible cache policies, such as entity-tag, if-unmodified-since, if-match, if-none-match, and other alternative cache headers to control cache policies.
• Bandwidth saving: When a client requests a resource, HTTP/1.0 by default sends the entire object associated with that resource to the requester, but many times the client may not need all the information about the object. However, in HTTP/1.1, the range header field is introduced, which allows only partial resources to be requested. It enables developers to request a certain resource through multiple threads, so as to make full use of bandwidth resources and realize efficient concurrency.
• Error notification management: HTTP/1.1 added 24 error status response codes on the basis of 1.0. For example, 414 indicates that the URL address contained in the client request is too long to be processed by the server. 410 indicates that the requested resource is permanently deleted.
• Host request header: Early HTTP/1.0 assumed that each server was bound to a unique IP address and provided a single service, and that the URL in the request message did not pass the Host name. With the advent of virtual hosts, multiple virtual hosts can exist on a physical server, and they share the same IP address. In order to support virtual hosting, HTTP/1.1 added the host request header, the request message and response message should declare this field, if the request message is missing this field will respond to a 404 error status code.
• Long connection: By default, HTTP/1.0 maintains a short connection between the browser and the server. Each request from the browser requires a TCP connection with the server. The server disconnects the TCP connection immediately after the request is completed. HTTP/1.1 uses persistent connections by default, which allows multiple HTTP requests and responses to be sent within the same TCP request. Previous VERSIONS of HTTP use non-persistent connections by default. If you want to maintain persistent connections over older versions of HTTP, you need to specify keep-alive as the header field of Connection.

The difference between HTTP/ 1.x and HTTP/2.0

• In contrast to HTTP/ 1.x’s text (string) transport, HTTP/2.0 uses binary transport. When the client and server transmit data, the data is divided into frames, which constitute a data flow. The flow has a stream ID and a priority. Priority and flow dependence can solve the problem of key requests being blocked to a certain extent.
• HTTP/2.0 supports multiplexing. Because of the existence of the flow ID, multiple HTTP requests can be transmitted through the same HTTP request. The client and server can identify the flow by the flow ID to locate the HTTP request.
• HTTP/2.0 header compression. HTTP/2.0 uses GZIP and COMPRESS to compress the header and send the header. At the same time, the communication parties maintain a header information table, in which all fields are recorded. During each HTTP transmission, only the index of the header field in the table needs to be transmitted, greatly reducing the number of retransmission and data volume.
• HTTP/2.0 supports server push. In the case that the client does not request permission, the server can push the required content to the client in advance. When the client exits the service, it can cancel the push of the server by sending a request related to reset.

The difference between cookies and sessions

• Cookie
  • Is a special message sent by the server to the client and stored in the client in the form of text
  • The cookie is sent back when the client requests it again
  • Upon receipt, the server will parse the Cookie to generate the corresponding content of the client
• The Session of the introduction
  • Server side mechanism, information stored on the server
  • Parse client requests and manipulate session ids, saving status information as needed
• How Session is implemented
  • Use cookies to implement (JSESSIONID)
  • Use URL write back to do this
• The difference between cookies and sessions
  • Cookie data is stored on the client’s browser and Session data is stored on the server
  • Session is more secure than Cookie
  • If you want to lighten the load on your server, you should use cookies

The difference between GET and POST requests

• HTTP packet layer: GET puts the request information in the URL (with length limitation), and POST in the message format
• Database level: GET complies with idempotency and security, but POST does not
• Other layers: GET can be cached and stored, but POST can’t

The resources

• Illustrated HTTP
• Diagram of TCP/IP
• How the Web Is Connected
• Leetcode-cn.com/leetbook/re…
• Blog.csdn.net/qzcsu/artic…
• Segmentfault.com/a/119000000…