WEBVTT 00:00.820 --> 00:03.250 Welcome back to the Knowledge Portal Video Series. 00:04.020 --> 00:10.410 Today, we are going to talk about a very important aspect of the Http connection handling, which is 00:10.590 --> 00:12.180 keep alive connections. 00:14.450 --> 00:16.520 So we have two examples over here. 00:16.550 --> 00:19.790 This is example one and this is example two. 00:20.120 --> 00:23.600 So example one is one of the old ways of. 00:24.600 --> 00:26.630 Doing things in the Http protocol. 00:26.640 --> 00:28.290 So let's see on how it works. 00:29.140 --> 00:36.670 So there is a Http request which is been sent from client to the server and corresponding to the request 00:36.700 --> 00:39.250 the server sends the Http response back. 00:40.540 --> 00:50.620 Now, as we know that Http works based on TCP protocol and in TCP before any data can be sent, there 00:50.620 --> 00:53.260 has to be a three way handshake that has to occur. 00:53.920 --> 01:01.540 So essentially, before a Http request is sent from the client to the server, there has to be a three 01:01.540 --> 01:03.090 way handshake that has to occur. 01:03.100 --> 01:06.340 And this indicates the three way handshake. 01:06.340 --> 01:09.940 So this is an open function call and this is a closed function call. 01:09.940 --> 01:11.320 So the. 01:12.400 --> 01:17.020 Gap between these two indicates a single TCP three way handshake connection. 01:18.840 --> 01:28.170 Now in the older times when the Http protocol was introduced for a single request and response, there 01:28.170 --> 01:33.090 used to be a single TCP three way handshake that had to occur. 01:33.120 --> 01:41.130 So essentially, if you want to send a bunch of requests and response, say here there are three requests 01:41.130 --> 01:48.270 and response based packets and for three requests and response packets, there were three TCP three 01:48.270 --> 01:49.860 way handshake that used to occur. 01:50.640 --> 01:53.130 Now it doesn't seem much. 01:53.890 --> 02:00.670 But nowadays, if you compare the modern based websites where there are a lot of Jquery's, Java scripts, 02:00.700 --> 02:09.630 even CSS files, even if you open a single website, essentially a browser has to make around 50 to 02:09.630 --> 02:12.610 60 Http requests to the server. 02:13.090 --> 02:21.730 And if we still implement the old way of doing things, then for 50 Http requests there has to be a 02:21.730 --> 02:24.910 53 way handshake that had to take place. 02:25.950 --> 02:33.540 And this is not a optimal way of doing things because not only it consumes a lot of bandwidth, but 02:33.540 --> 02:40.020 also TCP three way handshake in itself is a CPU consuming. 02:40.900 --> 02:41.230 Thing. 02:41.950 --> 02:46.420 And this was one of the reasons why keep alive connections were introduced. 02:47.480 --> 02:50.510 So what happens in Keepalive based connection is. 02:51.610 --> 02:58.240 Whenever a client sends a request to the server, it adds a keepalive in the connection header saying 02:58.240 --> 03:00.130 Please do not close the connection. 03:00.770 --> 03:07.880 And in response to that, the server sends the response saying that I am not going to close the connection 03:07.880 --> 03:09.290 with the Keepalive header. 03:09.500 --> 03:14.960 So essentially if we compare these two examples in order to send. 03:15.810 --> 03:18.900 Six packets of Http requests and response. 03:18.900 --> 03:22.590 There were three TCP connections that had taken place. 03:22.800 --> 03:29.700 However, if we talk about modern based approach, there is only one TCP three way handshake and within 03:29.700 --> 03:33.390 that there are multiple requests and response based packets that takes place. 03:33.510 --> 03:37.320 So essentially this is what is a optimal way of doing things. 03:38.440 --> 03:41.470 So if we look into how exactly it looks. 03:42.570 --> 03:49.710 So a client sends a get requests and along with that in the connection header, it includes a keepalive 03:49.710 --> 03:50.520 directive. 03:51.460 --> 03:58.600 And in response to that, the server sends a response with a keepalive directive saying that the connection 03:58.600 --> 04:00.010 is not being closed. 04:02.050 --> 04:06.040 So let's look on how it looks in the wireshark. 04:06.070 --> 04:08.440 Then the concept will become much more clearer. 04:09.220 --> 04:16.900 So what we will do is we'll see both the approaches and we'll compare on why the first approach is not 04:16.900 --> 04:18.550 the optimal way of doing things. 04:18.670 --> 04:22.600 So I've configured my nginx to not use keepalive. 04:22.750 --> 04:26.140 So essentially we'll be using the old approach first. 04:28.530 --> 04:33.540 So I'll go to Firefox and let's open our inspector. 04:34.980 --> 04:37.080 And let's go to example.com. 04:37.470 --> 04:39.600 Followed by index.html. 04:41.780 --> 04:45.710 Before we run this query, I'll open up my wireshark. 04:47.670 --> 04:49.500 And start a packet capture. 04:51.710 --> 04:55.070 Now I'll just open this up. 04:55.460 --> 05:00.380 And essentially what you have seen over here is there are two requests which are made. 05:00.410 --> 05:06.200 First is for this particular text and second is for the image file. 05:06.500 --> 05:09.710 So I'll just close the Wireshark packet capture. 05:10.540 --> 05:12.520 And let's look at what has happened. 05:13.610 --> 05:16.280 So if I go to view source. 05:20.220 --> 05:25.560 The first source is for the text document that we have seen. 05:25.560 --> 05:31.620 And the second request, which is index dot PNG, is made for the image file. 05:32.520 --> 05:37.950 So comparing the old way of doing things as there are two requests which are sent, essentially there 05:37.950 --> 05:42.030 will be two instances of TCP three way handshake that would have occurred. 05:42.780 --> 05:45.540 So let's verify it with our Wireshark once. 05:48.210 --> 05:50.070 I will go to follow TCP stream. 05:51.970 --> 05:53.560 And essentially. 05:54.980 --> 05:56.510 If we minimize this. 05:57.930 --> 05:58.410 Here. 05:58.410 --> 06:02.970 If we see this is the first TCP three way handshake since Anak anak. 06:03.000 --> 06:07.170 This includes or this indicates the open connection. 06:07.170 --> 06:10.890 So this open connection indicates the first. 06:12.140 --> 06:17.660 Three packets and after the server sends the response to the get request. 06:17.660 --> 06:19.640 So this is where the response has come. 06:19.880 --> 06:22.810 The connection is closed with Anak-anak. 06:24.560 --> 06:28.610 Now let's go to the next TCP stream. 06:30.580 --> 06:34.000 And again for my index dot PNG. 06:34.210 --> 06:38.500 So this essentially is the second get request. 06:41.140 --> 06:45.520 There is a new TCP three way handshake connection which has taken place. 06:46.130 --> 06:55.130 Once the response comes from the Nginx server for this particular request, the connection is closed 06:55.130 --> 06:55.460 again. 06:57.680 --> 07:03.710 So essentially for two Http requests and response that we have seen over here, there are two three 07:03.710 --> 07:05.480 way handshake that has occurred. 07:06.610 --> 07:11.980 So if I show you my nginx configuration. 07:15.630 --> 07:22.950 Here we have actually disabled the keep alive, and that is one of the reasons why for each request 07:22.950 --> 07:27.000 and response, there is a new TCP three way handshake that takes place. 07:27.120 --> 07:32.610 So let me actually comment it out and let's use keep alive based connection. 07:33.840 --> 07:37.110 I'll save this and I'll restart the Nginx. 07:42.260 --> 07:43.160 Now. 07:44.980 --> 07:47.620 Let's start the packet capture again. 07:50.150 --> 07:53.230 I'll clear it up and let's go to the browser. 07:53.240 --> 07:59.540 I'll open up a new tab example.com and this time we'll load index.html. 08:00.230 --> 08:04.370 So essentially same thing has happened to request has been sent. 08:04.620 --> 08:07.790 And now if we look into the wireshark. 08:13.760 --> 08:21.890 And if I go to the follow TCP stream within the first TCP stream, you see everything has occurred. 08:22.220 --> 08:28.970 This is the first get request and this is the second get request and both of the get requests are under 08:28.970 --> 08:31.490 the same TCP three way handshake stream. 08:32.180 --> 08:37.370 And this is what the Keepalive based connection means. 08:37.400 --> 08:45.410 So if we look into the connection header, the browser has sent a keepalive and the server has also 08:45.410 --> 08:46.400 sent keepalive. 08:46.940 --> 08:54.140 And this is one of the reasons why multiple requests and response can be sent within a single TCP three 08:54.140 --> 08:54.740 way handshake. 08:57.040 --> 09:03.550 So let's open the inspector and let me go to. 09:04.670 --> 09:06.020 Knowledge portal in. 09:06.110 --> 09:13.730 This is just for an example I just want to show you on how many requests are sent from the client browser. 09:14.750 --> 09:16.520 To a modern based website. 09:27.060 --> 09:36.660 Okay, so the page has loaded and if we see over here, there are a total of 104 requests which were 09:36.660 --> 09:38.730 sent overall. 09:40.890 --> 09:43.230 From loading a single web page. 09:43.650 --> 09:47.700 And this is essentially the reason why having a. 09:47.730 --> 09:51.870 Keepalive based persistent connection is very essential. 09:51.900 --> 09:58.920 So in the Http 1.0 protocol, the Keepalive header was introduced. 10:00.190 --> 10:07.090 However, for Http 1.1 based protocol keep alive is a mandatory thing. 10:07.090 --> 10:11.800 So in 1.0, having a keep alive is an option. 10:11.830 --> 10:16.180 However, for Http 1.1, all the sessions are. 10:17.440 --> 10:19.290 Assumed to be persistent. 10:19.300 --> 10:23.920 That means all the connections should have a keepalive based headers. 10:24.640 --> 10:27.070 So this is it about this lecture. 10:27.250 --> 10:36.160 I hope you got the basic reason on why the Keep Alive header was introduced in the Http 1.0 and mandatory 10:36.160 --> 10:38.800 in the Http 1.1 based protocol. 10:39.770 --> 10:41.650 So this is it about this video. 10:41.660 --> 10:45.650 I hope this has been informative for you, and I'd like to thank you for viewing.