HTTP에 대해 알아야할 모든 것

• What is HTTP?
• HTTP/0.9 - The One Liner (1991)
• HTTP/1.0 - 1996
• Three-way Handshake

HTTP is the protocol that every web developer should know, as it powers the entire web. 

Knowing HTTP can certainly help you develop better applications.

In this article, I will discuss what HTTP is, how it came to be, where it stands today, and how we got there

First things first, what is HTTP?

HTTP is a TCP/IP-based application layer communication protocol that standardizes how clients and servers communicate with each other.

It defines how content is requested and transmitted across the internet.

By application layer protocol, I mean that it’s simpley an abstraction layer that standardizes how hosts (clients and servers) communicate.

HTTP itself depends on TCP/IP to get requests and responses between the client and server.

By default, TCP port 80 is used, but other ports can also be used.

HTTPS, however, uses port 443

The first documented version of HTTP was HTTP/0.9 which was put forward in 1991.

It was the simplest protocol ever; having a single method called GET.

If a client had to access some webpage on the server, it would have made the simple request like below.

GET /index.html

And the response from server would have looked as follows.

(resposne body)
(connection closed)

That is, the server would get the request, reply with the HTML in response and as soon as the content has been transferred, the connection will be closed.

• No headers
• ‘GET’ was the only allowed method
• Response had to be HTML

As you can see, the protocol really had nothing more than being a stepping stone for what was to come.

In 1996, the next version of HTTP i.e. HTTP/1.0 evolved that vastly improved over the original version.

Unlike HTTP/0.9 which was only designed for HTML response, HTTP/1.0 could now deal with other response formats i.e. images, video files, plain text or any other content type as well.

It added more methods (i.e. POST and HEAD), request/response formats got changed, HTTP headers got added to both the request and responses, status codes were added to identify the response, character set support was introduced, multi-part types, authorization, caching, content encoding and more was included.

Here is how a sample HTTP/1.0 request and response might have looked like

GET / HTTP/1.0
Host: cs.fyi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5)
Accept: */*

As you can see, alongside the request, client has also sent it’s personal information, required response type etc.

While in HTTP/0.9 client could never send such information because there were no headers.

Example response to the request above may have looked like below

HTTP/1.0 200 OK 
Content-Type: text/plain
Content-Length: 137582
Expires: Thu, 05 Dec 1997 16:00:00 GMT
Last-Modified: Wed, 5 August 1996 15:55:28 GMT
Server: Apache 0.84

(response body)
(connection closed)

In the very beginning of the response there is HTTP/1.0 (HTTP followed by the version number), then there is the status code 200 followed by the reason phrase (or description of the status code, if you will). In this newer version, request and response headers were still kept as ASCII encoded, but the response body could have been of any type i.e. image, video, HTML, plain text or any other content type. So, now that server could send any content type to the client; not so long after the introduction, the term “Hyper Text” in HTTP became misnomer. HMTP or Hypermedia transfer protocol might have made more sense but, I guess, we are stuck with the name for life. One of the major drawbacks of HTTP/1.0 were you couldn’t have multiple requests per connection. That is, whenever a client will need something from the server, it will have to open a new TCP connection and after that single request has been fulfilled, connection will be closed. And for any next requirement, it will have to be on a new connection. Why is it bad? Well, let’s assume that you visit a webpage having 10 images, 5 stylesheets and 5 javascript files, totalling to 20 items that needs to fetched when request to that webpage is made. Since the server closes the connection as soon as the request has been fulfilled, there will be a series of 20 separate connections where each of the items will be served one by one on their separate connections. This large number of connections results in a serious performance hit as requiring a new TCP connection imposes a significant performance penalty because of three-way handshake followed by slow-start.