Comparison of HTTP 1.1 and HTTP 1.0

Comparison of HTTP 1.1 with HTTP 1.0

A Web site may receive millions of user requests a day, in order to improve the efficiency of the system, HTTP 1.0 requires the browser and the server to maintain only a brief connection, every time the browser needs to establish a TCP connection with the server, the server completes the request processing immediately disconnect the TCP connection, The server does not track each customer nor does it record past requests. However, this also creates some performance flaws, for example, a Web page file that contains many images does not contain real image data content, but merely indicates the URL of the image, and when the Web browser accesses the Web page file, the browser first makes a request for the page file. When the browser resolves the HTML content in the document of the Web page returned by the server, and the image label is found, the browser sends a request to the server to download the image data again according to the URL address specified by the SRC attribute in the label. As shown in Figure 3.3.

Figure 3.3

Obviously, the entire process of accessing a Web page file that contains many images includes multiple requests and responses, each requiring a separate connection, each connecting only one document and image, and the last and next request completely detached. Even though the image files are small, each connection between the client and the server is a relatively time-consuming process and can severely affect the performance of the client and server. This can happen when a Web page file contains applet,javascript files, CSS files, and so on.

To overcome this flaw in HTTP 1.0, HTTP 1.1 supports persistent connections, where multiple HTTP requests and responses can be delivered on a single TCP connection, reducing the consumption and latency of establishing and closing connections. Multiple requests and responses to a Web page file that contains many images can be transmitted in a single connection, but requests and replies to each individual Web page file still need to use their own connections. HTTP 1.1 also allows the client to issue the next request without waiting for the last request result to be returned, but the server side must echo the response in the order in which the client requests are received to ensure that the client can differentiate between the response content of each request. This also significantly reduces the time required for the entire download process. The process of exchanging information between a client and a server based on the HTTP 1.1 protocol, as shown in Figure 3.4.

Figure 3.4

As you can see, HTTP 1.1 overcomes the performance problems of HTTP 1.0, based on the advantages of HTTP 1.0. Furthermore, HTTP 1.1 improves and expands the functionality of HTTP 1.0 by adding more request headers and response headers. For example, because HTTP 1.0 does not support host request header fields, the Web browser cannot use host header names to explicitly indicate which Web site to access on the server, so that you cannot use the Web server to configure multiple virtual Web sites on the same IP address and port number. After adding the host Request Header field in HTTP 1.1, Web browsers can use host header names to explicitly indicate which Web site to access on the server, which enables you to create multiple virtual Web sites on a single Web server using a different hostname on the same IP address and port number. The continuous connection of HTTP 1.1 also requires the addition of a new request header to help implement, for example, when the connection request header has a value of keep-alive, the client notifies the server to remain connected after returning the result of this request, and the connection request header value is close. The client notifies the server to close the connection after returning the result of this request. HTTP 1.1 also provides request headers and response headers related to mechanisms such as identity authentication, state management, and cache caching.

Accept-language

The Accept-language header field specifies the number of comma-delimited national languages that are used to specify which country language the client expects the server to return. For some Web sites, you can return a Web page document for the national language, depending on the language version of the browser that you are using. For example, when using Chinese IE browser to access the www.google.com site, the server returns a Web page file using the Chinese language. Click the Internet Options menu in IE, "tools" à in the Internet Options dialog box that opens, click the Language button, add English to the Open Language Preferences dialog box, and move it up to the first location in the language list, as shown in Figure 3.14.

Figure 3.14

Once you have set your language preferences, visit the www.google.com site again, and the server returns a Web page file that uses English. The above results are likely to be influenced by Google's site policy adjustments and cookies, for example, when the author writes the first draft of the book, sees the desired effect, but waits until the author gets back to school after a few months, even if English is set to the language But the result is still the Chinese web page. This may be due to the fact that English has become an international language, and Google has ignored the setting of language preferences into English. If you set the language preferences to Japanese, the server can return the Japanese web page files.

The principle of implementing these features on a Web server is simple, because IE browsers generate the appropriate Accept-language request headers based on the language list in the Language Preferences dialog box, for example,

Accept-language:en-gb,zh-cn

As soon as the Web server checks the information in the Accept-language request header, in the order in which the national language is set, it knows which national language Web page documents should be returned to the browser. If the Web server cannot return a Web page document that is in the national language before the Accept-language setting value, the Web server returns the Web page document for the following country language. Information about the names of each country's languages, for example, China is ZH-CN, you can see RFC 1766, in fact, as long as you add a language to a country in Figure 3.14, the text displayed in brackets is the name of the country's language.

: Hands-on experience: The role of the Accept-language header field

(1) Execute Telnet www.google.com 80 in the Command Line window, and enter the following lines in the Telnet program window that starts after a successful connection:

get/http/1.1

Host:

Accept-language:en-us,zh-cn

< blank line >

You can see that the text returned by Google is a Web document with English characters. Omit the Accept-language field section above, and the main body part returned by Google by default is also a Web document for English characters.

(2) Reconnect to the Google site, in the Telnet program window that starts after a successful connection, enter the following lines:

get/http/1.1

Host:

Accept-language:zh-cn

< blank line >

You can see that the body part returned by Google is a Chinese character Web page document.