Welcome back to the Knowledge Portal Video Series.
Today, we are going to talk about a very important aspect of the Http connection handling, which is
keep alive connections.
So we have two examples over here.
This is example one and this is example two.
So example one is one of the old ways of.
Doing things in the Http protocol.
So let's see on how it works.
So there is a Http request which is been sent from client to the server and corresponding to the request
the server sends the Http response back.
Now, as we know that Http works based on TCP protocol and in TCP before any data can be sent, there
has to be a three way handshake that has to occur.
So essentially, before a Http request is sent from the client to the server, there has to be a three
way handshake that has to occur.
And this indicates the three way handshake.
So this is an open function call and this is a closed function call.
So the.
Gap between these two indicates a single TCP three way handshake connection.
Now in the older times when the Http protocol was introduced for a single request and response, there
used to be a single TCP three way handshake that had to occur.
So essentially, if you want to send a bunch of requests and response, say here there are three requests
and response based packets and for three requests and response packets, there were three TCP three
way handshake that used to occur.
Now it doesn't seem much.
But nowadays, if you compare the modern based websites where there are a lot of Jquery's, Java scripts,
even CSS files, even if you open a single website, essentially a browser has to make around 50 to
60 Http requests to the server.
And if we still implement the old way of doing things, then for 50 Http requests there has to be a
53 way handshake that had to take place.
And this is not a optimal way of doing things because not only it consumes a lot of bandwidth, but
also TCP three way handshake in itself is a CPU consuming.
Thing.
And this was one of the reasons why keep alive connections were introduced.
So what happens in Keepalive based connection is.
Whenever a client sends a request to the server, it adds a keepalive in the connection header saying
Please do not close the connection.
And in response to that, the server sends the response saying that I am not going to close the connection
with the Keepalive header.
So essentially if we compare these two examples in order to send.
Six packets of Http requests and response.
There were three TCP connections that had taken place.
However, if we talk about modern based approach, there is only one TCP three way handshake and within
that there are multiple requests and response based packets that takes place.
So essentially this is what is a optimal way of doing things.
So if we look into how exactly it looks.
So a client sends a get requests and along with that in the connection header, it includes a keepalive
directive.
And in response to that, the server sends a response with a keepalive directive saying that the connection
is not being closed.
So let's look on how it looks in the wireshark.
Then the concept will become much more clearer.
So what we will do is we'll see both the approaches and we'll compare on why the first approach is not
the optimal way of doing things.
So I've configured my nginx to not use keepalive.
So essentially we'll be using the old approach first.
So I'll go to Firefox and let's open our inspector.
And let's go to example.com.
Followed by index.html.
Before we run this query, I'll open up my wireshark.
And start a packet capture.
Now I'll just open this up.
And essentially what you have seen over here is there are two requests which are made.
First is for this particular text and second is for the image file.
So I'll just close the Wireshark packet capture.
And let's look at what has happened.
So if I go to view source.
The first source is for the text document that we have seen.
And the second request, which is index dot PNG, is made for the image file.
So comparing the old way of doing things as there are two requests which are sent, essentially there
will be two instances of TCP three way handshake that would have occurred.
So let's verify it with our Wireshark once.
I will go to follow TCP stream.
And essentially.
If we minimize this.
Here.
If we see this is the first TCP three way handshake since Anak anak.
This includes or this indicates the open connection.
So this open connection indicates the first.
Three packets and after the server sends the response to the get request.
So this is where the response has come.
The connection is closed with Anak-anak.
Now let's go to the next TCP stream.
And again for my index dot PNG.
So this essentially is the second get request.
There is a new TCP three way handshake connection which has taken place.
Once the response comes from the Nginx server for this particular request, the connection is closed
again.
So essentially for two Http requests and response that we have seen over here, there are two three
way handshake that has occurred.
So if I show you my nginx configuration.
Here we have actually disabled the keep alive, and that is one of the reasons why for each request
and response, there is a new TCP three way handshake that takes place.
So let me actually comment it out and let's use keep alive based connection.
I'll save this and I'll restart the Nginx.
Now.
Let's start the packet capture again.
I'll clear it up and let's go to the browser.
I'll open up a new tab example.com and this time we'll load index.html.
So essentially same thing has happened to request has been sent.
And now if we look into the wireshark.
And if I go to the follow TCP stream within the first TCP stream, you see everything has occurred.
This is the first get request and this is the second get request and both of the get requests are under
the same TCP three way handshake stream.
And this is what the Keepalive based connection means.
So if we look into the connection header, the browser has sent a keepalive and the server has also
sent keepalive.
And this is one of the reasons why multiple requests and response can be sent within a single TCP three
way handshake.
So let's open the inspector and let me go to.
Knowledge portal in.
This is just for an example I just want to show you on how many requests are sent from the client browser.
To a modern based website.
Okay, so the page has loaded and if we see over here, there are a total of 104 requests which were
sent overall.
From loading a single web page.
And this is essentially the reason why having a.
Keepalive based persistent connection is very essential.
So in the Http 1.0 protocol, the Keepalive header was introduced.
However, for Http 1.1 based protocol keep alive is a mandatory thing.
So in 1.0, having a keep alive is an option.
However, for Http 1.1, all the sessions are.
Assumed to be persistent.
That means all the connections should have a keepalive based headers.
So this is it about this lecture.
I hope you got the basic reason on why the Keep Alive header was introduced in the Http 1.0 and mandatory
in the Http 1.1 based protocol.
So this is it about this video.
I hope this has been informative for you, and I'd like to thank you for viewing.