• Brief History of HTTP
  • Ilya Grigorik
  • The Nuggets translation Project
  • Permanent link to this article: github.com/xitu/gold-m…
  • Translator: jerryOnlyZRJ
  • Proofread by Fengziyin1234, park-ma

Introduction to the

Hypertext Transfer Protocol (HTTP) is one of the most common and widely adopted application protocols on the Internet: it is a common language between clients and servers, supporting the modern Web. Starting with a simple single keyword and document path, it is no longer the exclusive domain of browsers and applies to almost any protocol for software and hardware applications that connect to the Internet.

In this chapter, we will briefly introduce the evolution of the HTTP protocol. A complete discussion of the different HTTP semantics is beyond the scope of this book, but understanding the key design changes to HTTP and the motivations behind each change will provide the necessary background for discussing HTTP performance, especially the many upcoming improvements to HTTP/2 mentioned in this article.

HTTP 0.9: single-line protocol

Tim Berners-Lee’s original HTTP proposal was designed with simplicity in mind to help support another of his nascent ideas: the World Wide Web. The strategy seems to work: aspiring protocol designers, take note

In 1991, Berners-Lee outlined the motivation for the new protocol and listed several high-level design goals: file transfer capabilities, the ability to request indexes to search hypertext archives, format negotiation, and the ability to reference clients to another server. To demonstrate a practical application of the theory, he built a simple prototype that implemented a fraction of the proposed functionality:

  • The client request is a single ASCII string.
  • Customer requests are terminated by carriage Return (CRLF).
  • The server response is an ASCII character stream.
  • The server response is a hypertext Markup language (HTML).
  • Terminate the connection after the document transfer is complete.

It’s not that complicated, these rules enable a very simple and Telnet-friendly protocol that some Web servers still support today:

$> Telnet Google.com 80 Connected to 74.125.xxx. XXX GET /about/ (Hypertext response) (connection closed)Copy the code

The request consists of a single line: GET method and the path to the requested document. The response is a single hypertext document — no headers or any other metadata, just HTML, which really couldn’t be simpler. In addition, since the previous interaction is a subset of the expected protocol, it is also known unofficially as HTTP/0.9. The rest, as they say, is history.

From these humble beginnings in 1991, HTTP took on a life of its own and grew rapidly over the next few years. Let’s quickly review HTTP/0.9 features:

  • Client-server, request-response protocol.
  • ASCII protocol, which runs on top of TCP/IP links.
  • Designed to transfer hypertext documents (HTML).
  • After each request, the connection between the server and client is closed.

Tip: Popular Web servers like Apache and Nginx still have some support for HTTP/0.9 because it’s really simple! If you’re curious, open a Telnet session and try to access google.com or your own favorite site over HTTP/0.9, and check out the behavior and limitations of this earlier protocol.

HTTP/1.0: Rapid development of protocols and information RFC

The period from 1991 to 1995 was a period of rapid development of the HTML specification, the birth of the browser, and the emergence and rapid growth of a public consumer-facing Internet infrastructure.

The Perfect storm: The Internet boom of the early 1990s

Based on Tim Berner-Lee’s original browser prototype, a team at the National Center for Supercomputing Applications (NCSA) decided to implement their own version. This marked the birth of the first popular browser: NCSA Mosaic. In October 1994, Marc Andreessen, a programmer on the NCSA team, teamed up with Jim Clark to create Mosaic Communications. The company later changed its name to Netscape and released Netscape Navigator 1.0 in December 1994. Since then, it has become clear that the Web is not just an academic hotspot, but one that will attract more attention.

In fact, the first World Wide Web conference was held that same year in Geneva, Switzerland, and the World Wide Web Consortium (W3C) was born to help guide the development of HTML. At the same time, an HTTP Working Group (HTTP-WG) was established within the IETF to focus on improving the HTTP protocol. To this day, they are still an important part of the Internet and continue to drive its evolution.

Finally, to create the perfect storm, CompuServe, AOL, and Prodigy began offering dial-up Internet access to the public in 1994-1995. Riding this Internet wave, Netscape made history with a very successful IPO on August 9, 1995 – the dotcom boom had arrived and everyone wanted a piece of it!

The growing number of use cases on public websites showed that the public was increasingly demanding functionality from emerging networks, which quickly exposed many of the fundamental limitations of HTTP/0.9: we needed protocols that could not only provide hypertext documents, but also richer metadata about requests and responses, enable content negotiation, and so on. The emerging Web developer community has responded by producing a number of experimental HTTP servers and clients through a dedicated process of “implement, deploy, and see if anyone starts adopting it.”

From this period of rapid experimentation, a series of best practices and common patterns began to emerge, and in May 1996, the HTTP Working Group (HTTP-WG) released RFC 1945, which documented a number of non-canonical but “common” implementations of HTTP/1.0. Please note that this is just a message RFC: HTTP/1.0, as we know it is not an official specification or Internet standard!

Having said that, the HTTP/1.0 request instance looks very familiar:

$> Telnet website.org 80 Connected to XXX.xxx.xxx. XXX GET/RFC /rfc1945. TXT HTTP/1.0 1 ️ user-agent: Cern-linemode /2.15 libwww/2.17 B3 Accept: */* HTTP/1.0 200 OK 2 one ️ content-type: text/plain content-length: 137582 Expires: Thu, 01 Dec 1997 16:00:00 GMT Last-Modified: Wed, 1 May 1996 12:45:26 GMT Server: Apache 0.84 (plain-text Response) (Connection closed)Copy the code

1 one ️ Request line with HTTP version number, followed by the request header

2 discount ️ has response status code, followed by response header

The previous changes, while more than an exhaustive list of HTTP/1.0 features, do illustrate some key protocol changes:

  • The request may contain multiple newline delimited header fields.
  • The response object is prefixed with the response state behavior.
  • The response object has its own set of newline-delimited header fields.
  • Response objects are not limited to hypertext.
  • After each request, the connection between the server and client is closed.

Both request and response headers should be guaranteed to be ASCII encoded, but the response object itself can be any type: AN HTML file, a plain text file, an image, or any other content type. As a result, the “hypertext transfer” part of HTTP became less appropriate shortly after the new feature was introduced. In fact, HTTP has rapidly evolved into hypermedia transport, but the original name still exists.

In addition to media type negotiation, RFC documents many other common functions: content encoding, character set support, multi-part typing, authorization, caching, proxy behavior, date formatting, and so on.

Tip: Almost every server on the Web today can and will still use HTTP/1.0. Besides that, you should know better by now! Requiring a new TCP connection per request can cause a significant performance penalty for HTTP/1.0. Reference: Three handshakes, and slow starts.

HTTP/1.1: Internet standards

The conversion of HTTP to the official IETF Internet standard took place in parallel with the documentation around HTTP/1.0 and took place over a period of about four years: 1995 to 1999. In fact, the first formal HTTP/1.1 standard was defined in RFC 2068, which was officially released in January 1997, about six months after HTTP/1.0. Two and a half years later, in June 1999, the standard included many improvements and updates and was released as RFC 2616.

The HTTP/1.1 standard addressed many of the protocol ambiguities found in earlier versions and introduced a number of key performance optimizations: keep-alive connections, chunk-encoded transport, byte range requests, additional caching mechanisms, transport encoding, and pipe requests.

With these capabilities, we can now examine a typical HTTP/1.1 session performed by any modern HTTP browser and client:

$> Telnet website.org 80 Connected to XXX.xxx.xxx. XXX GET /index.html HTTP/1.1 1 one ️ Host: website.org user-agent: Mozilla / 5.0 (Macintosh; Intel Mac OS X 10_7_4)... (snip) Accept: text/html,application/xhtml+xml,application/xml; Q = 0.9 * / *; Q =0.8 Accept-encoding: Gzip,deflate, SDCH Accept-language: EN-us, EN; Q = 0.8 Accept - Charset: ISO - 8859-1, utf-8; Q = 0.7 *; Q = 0.3 cookies: __qca = P0-800083390... (SNIP) HTTP/1.1 200 OK 2 discount ️ Server: nginx/1.0.11 Connection: keep-alive Content-type: text/ HTML; Charset = UTF-8 Via: HTTP/1.1 GWA Date: Wed, 25 Jul 2012 20:23:35 GMT Expires: Wed, 25 Jul 2012 20:23:35 GMT Cache-Control: max-age=0, no-cache Transfer-encoding: chunked 100 3 ️ <! Doctype HTML > (SNIP) 100 (SNIP) 0 4 discount ️ GET /favicon.ico HTTP/1.1 5 discount Host: www.website.org user-agent: Mozilla / 5.0 (Macintosh; Intel Mac OS X 10_7_4)... (SNIP) Accept: */* Referer: http://website.org/ Connection: close 6 accept-encoding: gzip,deflate,sdch Accept-Language: en-US,en; Q = 0.8 Accept - Charset: ISO - 8859-1, utf-8; Q = 0.7 *; Q = 0.3 cookies: __qca = P0-800083390... (SNIP) HTTP/1.1 200 OK 7 discount ️ Server: nginx/1.0.11 Content-Type: image/ X-icon Content-Length: 3638 Connection: close Last-Modified: Thu, 19 Jul 2012 17:51:44 GMT Cache-Control: max-age=315360000 Accept-Ranges: bytes Via: HTTP/1.1 GWA Date: Sat, 21 Jul 2012 21:35:22 GMT Expires: Thu, 31 Dec 2037 23:55:55 GMT Etag: W/PSA-GAu26oXbDi (icon data) (connection closed)Copy the code

1 one ️ Request HTML file, containing encoding, character set and cookie metadata

2 block response of original HTML request

The octet number in 3 one ️ block is represented as an ASCII hexadecimal number (256 bytes)

4 end of block flow response

5 discount ️ Request icon file created on the same TCP connection

6 discount ️ Notification server will not reuse connections

7 discount ️ icon response and then close the connection

Gee, there’s so much going on there! The first and most obvious difference is that we have two object requests, one for the HTML page and one for the image, both passed through a single connection. This is a practical application of the keep-Alive connection, which allows us to reuse existing TCP connections in order to make multiple requests to the same host and provide a faster end user experience. See TCP optimization.

To terminate a persistent Connection, notice that the second client request close sends an explicit instruction to the server through the Connection request header. Similarly, once the response is transmitted, the server can notify the client of its intention to close the current TCP connection. Technically, either party can terminate a TCP connection without such a signal, but clients and servers should provide it whenever possible to achieve a better connection reuse strategy on both sides.

Tip: change the syntax of the HTTP protocol under HTTP/1.1 to use keep-alive connections by default. This means that unless otherwise stated (via the Connection: close header), the server should leave the Connection open by default.

However, the same functionality has also been reverse-ported to HTTP/1.0 and enabled via the Connection: keep-alive header. Therefore, if you use HTTP/1.1, technically you don’t need the Connection: keep-alive request header, but many clients still choose to provide it.

In addition, the HTTP/1.1 protocol adds content, encodings, character sets, and even language negotiation, transfer encoding, caching instructions, client-side cookies, and a dozen other features that can be negotiated on each request.

We are not going to go into the semantics of each HTTP/1.1 feature, as it is more than enough to make a professional book, and there are plenty of good ones already. On the contrary, the previous example is a good illustration of the rapid progress and evolution of HTTP and the intricacies of each client-to-server exchange. There’s a lot going on there!

Tip: For a detailed reference to all The inner workings of The HTTP protocol, check out HTTP: The Definitive Guide by O’Reilly, by David Gourley and Brian Totty.

HTTP/2: Improved transport performance

Since its launch, RFC 2616 has become an unprecedented growth of the Internet: billions of various shapes and sizes of devices, from desktop computers to our small network equipment in the pocket, and our daily life are inseparable from the use HTTP to transmit news, video, and millions of other web applications.

What began as a simple single-line protocol for retrieving hypertext eventually evolved into a general-purpose hypermedia transport that, perhaps a decade later, could even be used to support any need you could imagine. The ubiquity of servers and the wide availability of protocols in clients means that many applications are now designed and deployed specifically on top of HTTP.

Need an agreement to control your coffee maker? RFC 2324 already covers the Hypertext Coffee-pot Control Protocol (HTCPCP/1.0) — originally the IETF’s April Fool’s joke, but increasingly not a “joke” in our new hyperconnected world.

Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed collaborative hypermedia information systems. It is a general-purpose stateless protocol that can be extended for many tasks beyond hypertext, such as name servers and distributed object management systems, by extending its request methods, error codes, and headers. A feature of HTTP is the input and negotiation of data representations, allowing the system to be built independently of the data being transferred.

RFC 2616: HTTP/1.1, June 1999

The simplicity of THE HTTP protocol made it possible for its initial widespread adoption and rapid development. In fact, it’s not uncommon to find embedded devices (sensors, actuators, and coffee makers) that use HTTP as their primary control and data protocol. But under the weight of its own success, it is also starting to show signs of weakness as we continue to move more and more of our daily interactions online — social, email, news, video and, increasingly, personal and work Spaces. Both users and Web developers now demand near-real-time responses and protocol performance from HTTP/1.1, and without changes, it won’t be able to meet that demand.

To meet these new challenges, HTTP must continue to evolve, so the HTTPbis Working Group announced a new initiative for HTTP/2 in early 2012:

The new implementation focuses on removing the legacy issues of the HTTP/1.x messaging framework and syntax, which have been identified as hampering performance and making it vulnerable to misuse of the underlying transport, while preserving HTTP semantics.

The working group will design the new specification based on the current semantics of HTTP and the ordered full-duplex pattern. As with HTTP/1.x, the primary target transport is TCP, but other transports should be available.

HTTP/2 Charter, January 2012

The primary focus of HTTP/2 is to improve transport performance and achieve lower latency and higher throughput. The major version increment sounds like a big step, and it will be an important one in terms of performance, but it is important to note that no high-level protocol semantics are affected: all HTTP headers, values, and user scenarios are the same.

Any existing web site or application can and will be delivered over HTTP/2 without modification: you do not need to change your application to take advantage of HTTP/2. HTTP servers will generally use HTTP/2, but this should be a transparent upgrade for most users. If the team achieves its goals, the only difference should be that our application delivers with lower latency and better network link utilization!

That being said, let’s not get too far ahead of ourselves. Before we start using the new HTTP/2 protocol capabilities, it’s worth taking a step back and reviewing our existing HTTP/1.1 deployment and performance best practices. The HTTP/2 Working group is making rapid progress on the new specification, but even when the final standard is complete and ready, we still have to support older HTTP/1.1 clients for the foreseeable future. In practice, it could be a decade or more.

If you find any mistakes in your translation or other areas that need to be improved, you are welcome to the Nuggets Translation Program to revise and PR your translation, and you can also get the corresponding reward points. The permanent link to this article at the beginning of this article is the MarkDown link to this article on GitHub.

The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.