“This is the 23rd day of my participation in the Gwen Challenge in November. Check out the details: The Last Gwen Challenge in 2021”

1. HTTP long and short connections

The HTTP protocol has HTTP/1.0 and HTTP/1.1 versions. HTTP1.1 default HTTP persistent connection (persistent connection), data transfer is completed to keep TCP connection continuously open (not send RST packets, not four times handshake), waiting for the same domain name to continue to use this channel transmission data; The opposite is a short link.

In HTTP/1.0, short connections were used by default. That is, each time the browser and server perform an HTTP operation, they establish a connection and break the connection at the end of the task. Since HTTP/1.1, long connections have been used by default to preserve the connection feature.

2. Differences between HTTP/1.1 and HTTP/1.0

1 Scalability

A)HTTP/1.1 adds the version number in the message for compatibility judgment.

B)HTTP/1.1 adds the OPTIONS method, which allows the client to get a list of methods supported by the server.

In order to be compatible with future protocol specifications, HTTP/1.1 includes the Upgrade header field in the request message, through which the client can let the server know of other alternate communication protocols it can support, and the server can switch protocols accordingly to communicate with the client using alternate protocols.

2 the cache

In HTTP/1.0, the Expire header field is used to determine whether a resource is fresh or stale, and conditional requests are used to determine whether a resource is still valid. HTTP/1.1 adds some new cache features from 1.0, which are changed when the Age of cached objects exceeds Expire

Stale objects are revalidated with the source server instead of being discarded.

3 Bandwidth Optimization

In HTTP/1.0, there are some wasted bandwidth phenomena, such as the client only needs part of an object, but the server sends the whole object. For example, the client only needs to display part of a document, or it needs to support breakpoint continuation when downloading large files, rather than having to re-download the entire package after a disconnection.

HTTP/1.1 introduced the range header field in request messages, which allows only a portion of a resource to be requested. The Content-range header in the response message declares the offset and length of the returned portion of the object. If the server returns the content of the range requested by the object accordingly, the response code is 206

(Partial Content), which prevents the Cache from mistaking the response as a complete object.

Another situation is that if the request message contains large entity content, but it is not sure whether the server can receive the request (such as whether there is permission), if the request with entity is sent rashly, if it is rejected, it will also waste bandwidth.

HTTP/1.1 adds a new status code 100 (Continue). The client sends an Unauthorized request for the lead domain only. If the server rejects the request because of permissions, it returns the response code 401 (Unauthorized). If the server receives the request and sends back the response code 100, the client can continue to send the full request with the entity. Note that HTTP/1.0 clients do not support 100 response codes. But you can have the client add the Expect header field to the request message and set it to 100-continue.

A very effective way to save bandwidth resources is to compress the data to be transmitted. Content-encoding is the end-to-end Encoding of the message, which may be the inherent format (such as jpeg image format) of the resource stored on the server. Add an Accept-Encoding header field to the request message, which tells the server what Encoding the client can decode.

4 long connection

HTTP/1.0 stipulates that the browser and the server only maintain a short connection, each browser request needs to establish a TCP connection with the server, the server immediately disconnects the TCP connection after completing the request processing, the server does not track each client and does not record past requests. In addition, due to the small traffic of most web pages, a TCP connection rarely passes the slow-start area, which is not conducive to improving bandwidth utilization.

HTTP 1.1 supports both long-Connection and Pipelining processing, which enables multiple HTTP requests and responses to be transmitted over a single TCP connection, reducing the cost and latency of establishing and closing connections. For example, multiple requests and replies for a web page file containing many images can be transferred in a single connection, but each request and reply for a separate web page file still needs to use its own connection.

HTTP 1.1 also allows a client request results back don’t have to wait for the last time, you can send out the next request, but the server must be in order to receive the order of the client request of echo response as a result, to ensure that the client can distinguish between the response content of each request, it also significantly reduce the time required to download the entire process.

5 Message Passing

HTTP messages can contain entities of any Length, usually using Content-Length to indicate the end of the message. However, for many dynamically generated responses, the size of the message can only be determined by buffering the entire message, which increases latency. If long connections are not used, the end of a message can also be determined by a connection closure signal.

HTTP/1.1 introduced chunkedTransfer-coding to solve the above problem. The sender divides the message into several data blocks of arbitrary size, and each data block is sent with the length of the block. Finally, a zero-length block is used as the end of the message. This approach allows the sender to cache only one fragment of the message, avoiding the overload of buffering the entire message.

In HTTP/1.0, there was a Content-MD5 header field that could not be computed until the sender had buffered the entire message. In HTTP/1.1, chunked chunked messages pass a trailer after the last block (zero length) ends, which contains one or more header fields that the sender calculates after all the blocks have been passed. The sender will include a Trailer header field in the message to inform the recipient of the existence of the trailing.

6 the Host header fields

HTTP1.0 assumes that each server is bound to a unique IP address, so the URL in the request message does not pass the hostname. However, with the development of virtual hosting technology, there can be multiple virtual hosts (multi-homed Web Servers) on a physical server, and they share the same IP address.

HTTP1.1 both Request and response messages should support the Host header field, and an error (400 Bad Request) will be reported if there is no Host header field in the Request message. In addition, the server should be able to receive the resource request of the unique path marking.

7 Error Message

HTTP/1.0 defines only 16 status response codes, which are not specific enough for errors or warnings. HTTP/1.1 introduced a Warning header field to add a description of error or Warning messages.

In addition, 24 new status response codes are added in HTTP/1.1. For example, 409 (Conflict) indicates that the requested resource conflicts with the current state of the resource. 410 (Gone) Indicates that a resource on the server is permanently deleted.

3. What are the common HTTP status codes?

200 OK // The client request is successful

301Moved Permanently removed: The requested URL has been moved Permanently. The Response should contain a Location URL that indicates where the resource is now located

302 found redirection

400Bad Request // The client Request has a syntax error and cannot be understood by the server

401Unauthorized // The request is unauthorized. This status code must be used with the www-Authenticate header field using 403 Forbidden // The server received the request but refused to provide service

404 Not Found // The requested resource does Not exist, eg: An incorrect URL was entered

500 Internal Server Error // An unexpected Error occurs on the Server

503 Server Unavailable // The Server cannot process client requests and may become normal in a period of time

4. What’s the difference between GET and POST?

The difference between GET and POST is as follows:

1. The data of the GET request is appended to the URL (that is, the data is placed in the HTTP protocol header) to? Split URL and transfer data with & between parameters such as login.action? Name = zhagnsan&password = 123456. POST places the submitted data in the body of the HTTP package.

2. A maximum of 1024 bytes of data can be submitted through GET. In theory, THERE is no limit on the data submitted through POST, which can transmit a large amount of data. It is wrong and inaccurate to say:

The maximum amount of data submitted by GET is 1024 bytes

The length of the URL is directly related. In fact, URL does not have the problem of parameter upper limit, HTTP protocol specification does not limit URL length. This restriction is restricted by specific browsers and servers. Internet Explorer limits the URL length to 2083 bytes (2K+35). For other browsers such as Netscape,

FireFox, for example, theoretically has no length limit, which depends on the operating system support.

3.POST is more secure than GET. Note: Security is not the same as “security” mentioned in GET above. The above “Security” only means that the data is not modified, and here the Security means the real Security, such as: By submitting data via GET, the username and password will appear in clear text on the URL, because (1) the login page may be cached by the browser, and (2) other people can view the browser’s history so that they can GET your account and password, among other things, Submitting data using GET can also create a cross-site request Forgery attack.

Get is a request to send data to the server, while Post is a request to submit data to the server. In the FORM (FORM), the default Method is “Get”. In fact, Get and Post are just different.

5. What is the difference between HTTP redirection and request forwarding?

Essential difference: Forwarding is a server behavior, redirection is a client behavior.

Redirection features: After two requests are received, the browser address is changed and resources outside the Web can be accessed, and the transmitted data is lost.

Features of request forwarding: When a request is made once, the browser address stays the same and the user accesses its own Web resources. Data transmitted will not be lost.