Architecture behind HTTP/1.1

Question → What is Http/1.1 Client & Server ?

Answer → Here we go about the client & server architecture :-

• Today, if we have a web browser, a Python, a JavaScript app, or any app that makes a request that’s considered an HTTP/1.1 client.
• We also have an HTTP/1.1 Server, which can be the iOS, Apache, Tomcat, Apache, NodeJS, Python, Tornado. We can have many, many, many servers.

Question → How does an Http Request looks like ?

Answer → Http Request is composed of five parts :-

1.) Method → This can be either GET, PUT, POST, DELETE.

2.) Path → This is nothing but the path of the URL.

• The whole thing after the first slash is called as Path. In case of GET request, we can also put query parameters in the path itself.
• The URL has a limit and each server defines this limit differently. Some server says, it’s 2000 bytes whereas some other server says it’s 2000 characters, some say it’s 8000 characters. If you have a long get request with a big URL, it might fail if the server doesn’t support it.

3.) Protocol → The third piece of the http request is the protocol. It can be Http/1.1 OR Http/2 OR Http/3.

4.) Headers → Next piece we have is collection of key value pairs representing the headers. For example → Header-content-type, Cookie, Host.

5.) Body → The body is basically the body of the message which shall be sent in the request.

• For the POST request, the body doesn’t technically have a limit.

Question → Show a sample Http Request from the cURL utility

Answer → In the below screenshot, we are sending the cURL request :-

Question → Why is DNS-address being put in the host ?

Answer → Because one IP address can host “n” number of websites

• We don’t need to buy ten IP address just to host ten different websites.
• So, effectively we can have ten domains and all of them point to the same IP address.

Now, if you actually specify the host header (as you see in the request above), the app in the backend knows that oh, you’re going to host this particular website through this folder. That’s the trick behind a multi website hosting.

Question → How does the HttpResponse looks like ?

Answer → Here is how the HttpResponse looks like :-

The sample response while we get any response through curl looks like this. Note here that, in the highlighted line, we have three things being mentioned in below response :-

• Protocol + Version.
• StatusCode.
• Code Description.

Question → How does the Http/2 Response looks like ?

Answer → Here is how the Http/2 sample Response looks :-

There are many headers which an http/2 response contains and some of the mportant ones being shown above are :-

• ResponseProtocol and ResponseCode Header → There is no description after the statusCode i.e. 301, whereas in Http/1.1 you would see actually see the description as well.
• Location Header → This would ask the website to go and redirect to this address.

Question → How does the HTTP works ?

Answer → Here is the process/way which says, how http works :-

• You would first open a TCP connection because HTTP is built on top of TCP.
• Right after that you’re going to send a request and then you’re going to get back a response headers, response HTML, all the details.
• And then you close the connection.

Question → What additional happens in HTTPs protocol ?

Answer → Here, we do a TLS handshake first, and after the TCP.

• So, In this in the TLS handshake, both the client and the server will agree on the symmetric key, with the help of Asymmetric Encryption algorithms like Diffie-Hellman or RSA.
• And then we use symmetric encryption because it’s faster than asymmetric encryption, and especially for large content like what we’re about to send. Thus, same key does encrypts and the same key decrypts.

Question → How does HTTP/1.0 protocol works ?

Answer → Here is how the http/v1.0 protocol works, which came back around 1990s :-

• First time you want to send a request, you open a connection, you open a brand new TCP based connection.
• And then you send your get request and then the server processes it, and then the moment you get a response, you close the connection.

Question → Why does HTTP/1.0 protocol closes the TCP Connection each time ?

Answer → Back then in 1990s, keeping a TCP connection alive actually consumes a lot of memory effectively in the file descriptor. In those days, it was not a good idea because, we had limited memory in those days. We closes the connection every time just to save our memory.

Question → What are some disadvantage/shortcomings while working with HTTP/1.0 protocol ?

Answer → Following are some shortcomings of HTTP/1.1 protocol :-

• Opening and closing the TCP based connection really slows things down everytime because of added extra latency because the setup cost with the TCP is really expensive.
• The concept of buffering doesn’t exist. You have to send the entire response. You cannot chunk the response into smaller chunks. You have to specify a content length and then that content must be all shipped. Note that :- In simpler words, the header “transfer-encoding:chunked” is not supported at all by Http/1.1.
• You can’t even do multi homed website. Say, you have 7 DNS entries all point to the same IP address and you want to serve different websites for each website effectively for each domain. You couldn’t do this in Http/1.0, because the client never set the host header.

Question → What were the improvements made in the HTTP/1.1 protocol ?

Answer → Following is the architecture behind the HTTP/1.1 protocol :-

• Here, we make sure that, connection is kept alive. You tell the server, hey, keep this connection alive because I’m going to use it to send many, many, many requests.
• So you send a request, you get the index email, same connection.
• Don’t re-establish it, don’t close it, Send another image, get a response, Send the other image. Hey, give me give me another image.
• Give me this CSS, give me this JavaScript. All of them in the same JavaScript, JavaScript, all of them are using the same TCP connection.

Question → What are the benefits made in the HTTP/1.1 protocol ?

Answer → Following are the benefits provided by HTTP/1.1 protocol :-

• The TCP-connection shall be persisted.
• It has lower latency because, we don’t have to do this dance with the server to establish a connection every time we send a request.
• It also has low CPU usage, because the only thing you need to do is just read the stream and find out the the start of the request.

Question → Is there some disadvantage while using Http/1.1 ?

Answer → Yes, Http/1.1 can lead to Http Smuggling. In this situation, the server gets confused at where is the start of the request and where is the end of the request And hackers use that technique by leveraging the Content-Length header.

Question → Explain the concept of Pipelining with Http/1.1 ?

Answer → With pipelining, we are sending multiple requests one after another and using the same single connection, the server sends the response.

• This is a concept taken from the CPU.
• The client actually can send all the three requests together And the server can just process 1 to 3 at the same time and then respond.

Question → Are there any problem with this concept of Pipelining with Http/1.1 ?

Answer → Yes, with pipelining, we are limiting to the requests/responses. For example → Imagine that, what happened if let’s say, the HTML is so large, So it took time, but the image is tiny.

• The server can’t respond with the image first, because if it does, then the client will think that the first response corresponds to the first request and in that situation, the image will be rendered as the HTML and things will break.
• So, what the server does is, it goes sequential. Even if the image is small one, still it will actually block the image until the HTML is loaded and then it will respond with the image. This actually defeats the whole purpose of the of the pipeline.
• Plus, if there is a proxy right in the middle, we can’t guarantee that, the proxy in the middle will guarantee the order.

Therefore, nobody actually uses pipelining on HTTP/1.1. It’s disabled by default because it can become messy too easily, as you cannot guarantee that it was going to work correctly, especially in proxies, concept of blocking is just not cool, etc.

That’s all in this blog. I shall see you in next blog.