A Web site may have to receive up millions of user requests every day. In order to improve the efficiency of the system, HTTP 1.0 specifies that the browser and the server are only short-lived, and each request of the browser needs to establish a TCP connection with the server, the server After the request is processed, disconnect the TCP connection immediately, and the server does not track each customer does not record past requests. However, this also causes some performance defects, for example, a web file containing many images does not include real image data content, but only indicates the URL address of these images, when web browser access this web file When the browser first issues a request for the web file, when the browser resolves the HTML content in the web document returned by the web server, found the image tag, the browser will be based on the
tab. The URL address specified by the SRC property is again issued to the server, as shown in Figure 3.3.
Figure 3.3
Obviously, accessing a network file containing many images contains multiple requests and responses, each request and response need to establish a separate connection, and each connection is just transmitting a document and image, last and the next time Request completely separated. Even if the image file is small, the client and server side establish and close the connection is a relatively time-consuming process and will seriously affect the performance of the client and server. As mentioned in a web file contains Applets, JavaScript files, CSS files, etc., there will be similar to those described above.
To overcome this defect in HTTP 1.0, HTTP 1.1 supports persistent connections, which can transmit multiple HTTP requests and responses on a TCP connection, reducing the consumption and delay of the connection to establish and close the connection. A plurality of requests and answers containing a number of web files with many images can be transmitted in a connection, but requests and answers for each individual web file still need to use their respective connections. HTTP 1.1 also allows the client to send a next request without waiting for the previous request result, but the server side must return the response result in the order of receiving the client request, to ensure that the client can distinguish each request Response content, which significantly reduces the time required for the entire download process. The information exchange process of clients and servers based on HTTP 1.1 protocols are shown in Figure 3.4.
Figure 3.4
It can be seen that HTTP 1.1 has overcome the performance issues of HTTP 1.0 on the basis of inheriting HTTP 1.0. Not only that, HTTP 1.1 also improves and expands the functionality of HTTP 1.0 by adding more request heads and responders. For example, since the HTTP 1.0 does not support the Host request header field, the web browser cannot use the host-name to explicitly indicate which Web site to access the server, which cannot be configured with the same IP address and port number using the web server. Virtual web site. After increasing the Host request header field in HTTP 1.1, the web browser can use the Host Director to explicitly indicate which Web site to access the server, which enables the same IP address and port number on one web server. Use different hostnames to create multiple virtual web sites. The continuous connection of HTTP 1.1 also needs to add new request headers to help implement, for example, when the value of the Connection request head is Keep-alive, the client notification server returns the result of this request results to keep the connection; the value of the Connection request head is Close When the client notifies the server to turn off the connection after returning this request. HTTP 1.1 also provides request heads and response heads related to identity authentication, state management, and Cache cache.
Accept-language
The Accept-language header field is used to specify which national language of the client expects the server to return. You can specify multiple comma-separated national languages. For some web sites, you can return to the country language web documentation according to the different browser country language versions used by the user. For example, when accessing the www.google.com site using the Chinese IE, the server returns a web file using a Chinese language. Click the "Tool" à "Internet Options" menu of the IE browser, in the Open Internet Options dialog box, click the Language button, add English in the Open Language Preferences dialog, and will It moved to the first position in the language list, as shown in Figure 3.14. Figure 3.14
After setting the language preference, visit the www.google.com site again, then the server returns to the web file using English. The above experimental results are likely to be affected by Google Site Policy and Cookie. For example, when writing the first draft of this book, according to the above operation, see the expected effect, but after several months, after several months Even if the English is set to the language first, the results seen are still Chinese webpages. This may be because English has become the reason for the international general language, Google is ignored by the situation of language preferences to English! If you set the language preferences to Japanese, the server can return to Japanese web files.
The principle of implementing the above functions on the web server is very simple, because the IE browser will generate the corresponding Accept-Language request head according to the language list in the Language Preferences dialog, for example,
Accept-language: EN-GB, EN-CN
The web server uses the information in the Accept-Language request header, according to the order of the national language set, knows which country language of which country language is given to the browser. If the web server cannot return a web documentation in the country language in front of the Accept-Language setting value, the web server will return to the web documentation of the later country language. Regarding the name information of each national language, for example, China is en-cn, you can refer to RFC 1766, in fact, as long as it adds to a country in Figure 3.14, it is displayed in the sonistic brackets.
:
Hand experience:
ACCEPT-Language header field
(1) Execute Telnet www.google.com 80 in the command line window. In the Telnet program window started after successful connection, enter the following lines:
Get / http / 1.1
Host:
Accept-language: EN-US, EN-CN
You can see that the text of Google returns is a web document for English characters. Omitted the above Accept-Language field section, Google's default returned body part is also a web document for English characters.
(2) Reconnect the Google site, in the Telnet program window started after successful connection, enter the following lines:
Get / http / 1.1
Host:
Accept-language: zh-cn
It can be seen that the body returned by Google is a web document for Chinese characters.
