WEBVTT 00:00.740 --> 00:05.660 Http compression is one of the very important features of the Http protocol. 00:06.380 --> 00:13.880 The reason for this is because not only it saves your bandwidth, but also the transverse fields becomes 00:13.880 --> 00:15.200 very, very fast. 00:15.560 --> 00:22.640 So essentially, if a website is using compression, then the website can actually load much more faster 00:22.670 --> 00:25.550 than the one which does not use compression. 00:26.480 --> 00:33.200 So let's understand on how compression can help as far as the Http protocol is concerned. 00:34.850 --> 00:42.020 So we have scenario one where there is a website which is running without compression. 00:42.590 --> 00:47.750 So let's assume that slash index dot HTML. 00:48.060 --> 00:55.280 So I'll say index dot HTML is of size 3000 bytes. 00:55.410 --> 00:57.080 I'll say 3000 bytes. 00:57.920 --> 01:05.940 Now, in order to send this amount of data through the TCP protocol, we already know that if the size 01:05.940 --> 01:16.890 of TCP is, say, 1500 bytes, then in order to send the index dot HTML, we'll need three TCP packets. 01:17.370 --> 01:21.600 So this is packet one. 01:21.840 --> 01:29.400 Let's say this is packet two and this is TCP packet three. 01:29.430 --> 01:39.510 So all of these packets are sent to the client from the server and the third packet as well. 01:40.350 --> 01:45.720 And before that the client will send the get request. 01:48.870 --> 01:57.570 Now the problem with this is that for each client it is actually sending three TCP packets so that it 01:57.570 --> 02:01.800 can send 3000 bytes of data associated. 02:02.190 --> 02:05.310 Now, this is not a big problem. 02:05.310 --> 02:09.990 If the amount of clients that are connecting to the servers are less. 02:10.680 --> 02:21.210 So if we assume that the amount of client are 100, then for 100 client there will be three TCP packets 02:21.210 --> 02:22.250 for each individual. 02:22.260 --> 02:25.690 So amount of packet will be 300. 02:25.710 --> 02:28.230 So I will say 300 TCP packets. 02:31.230 --> 02:34.410 Now, this is also not a big problem. 02:34.410 --> 02:41.580 So if we consider corporate websites where you actually have millions of users who are connecting to 02:41.580 --> 02:48.030 your particular server, so during that time, the amount of TCP packets which will be sent over the 02:48.030 --> 02:49.740 network will be tremendous. 02:50.310 --> 02:54.240 So it causes two big problems. 02:54.480 --> 03:00.540 The first is the bandwidth and the second is the speed. 03:02.320 --> 03:13.450 So as it is sending three TCP packets, it will take some amount of time to load the website. 03:14.830 --> 03:21.340 Now, this is considered, as you can also say, as website is running slow. 03:21.370 --> 03:22.510 Maybe so. 03:22.510 --> 03:30.640 This is one of the reasons why even Google sometimes penalizes the website because it loads very slow. 03:31.600 --> 03:35.770 So this is the basics of scenario without compression. 03:35.770 --> 03:40.450 So let's take second scenario where you are actually using the compression. 03:41.320 --> 03:46.090 So let's go down and this is the scenario with compression. 03:47.510 --> 03:49.060 We'll have a say. 03:49.060 --> 03:51.360 So index dot HTML. 03:51.760 --> 03:56.800 I'll say index dot HTML is of 3000 bytes. 03:57.940 --> 04:04.300 M2 is 1500, so it will take total of three packets to send the data. 04:05.350 --> 04:09.670 So what we basically do is this time we decide to use compression. 04:09.670 --> 04:19.090 So we compress index dot HTML and the 3000 bytes of data actually gets let's assume it goes to around 04:19.240 --> 04:20.590 2000 bytes. 04:21.610 --> 04:27.490 Compression can actually reduce the size by 70% also. 04:27.490 --> 04:31.150 So it can actually go down much more further. 04:31.150 --> 04:34.320 But for our example, let's consider 2000 bytes. 04:34.330 --> 04:42.880 So in order to transmit the 2000 bytes, we already know it will take two TCP packets with the M2 of 04:43.630 --> 04:45.120 1500 bytes. 04:45.130 --> 04:53.560 So now whenever a get request is made from the server to client, so this is get the server actually 04:53.560 --> 04:59.350 have to only send two TCP packets to transmit the data. 04:59.860 --> 05:06.620 So this is two TCP packets and the data is then loaded on the browser. 05:06.890 --> 05:11.230 So now there is certain amount of compression. 05:11.240 --> 05:19.550 Now as we have already discussed, if it is, if the site is getting around 100 users, then the bandwidth 05:19.580 --> 05:21.320 saving won't be much. 05:21.320 --> 05:23.660 But this will affect a lot. 05:23.690 --> 05:32.270 If a website is getting millions of users, then the amount of bandwidth that is saved is actually a 05:32.270 --> 05:32.670 lot. 05:32.690 --> 05:35.120 So if we say millions of users. 05:35.330 --> 05:40.580 So if you compare scenario one and scenario two, so in scenario two, actually one packet is getting 05:40.580 --> 05:41.030 saved. 05:41.030 --> 05:48.830 So that means for million users you have million packet which got saved because now one packet is not 05:48.830 --> 05:51.110 sent because of the compression ability. 05:52.700 --> 05:56.750 The second important benefit is the speed. 05:58.400 --> 06:01.100 Or you can also say site speed. 06:02.600 --> 06:08.270 The reason for this is because as there are only two packets sent, the amount of time it takes to send 06:08.270 --> 06:10.340 two packets is much more lesser. 06:10.430 --> 06:14.690 That's the reason why your website will actually load much more faster. 06:15.740 --> 06:21.680 And this is why compression is used in almost all the major websites. 06:22.130 --> 06:30.980 So there are lot of ways in which you can compress the data when you use the Http protocol. 06:31.100 --> 06:40.160 But in this video, I just wanted to give you an overview on how exactly a compression can help, not 06:40.160 --> 06:46.850 only as far as the transfer speed is concerned, but also as far as the bandwidth is concerned. 06:47.360 --> 06:54.350 So I hope you got the basic overview on why compression is necessary as far as the Http protocol is 06:54.350 --> 06:54.890 concerned. 06:55.490 --> 07:00.440 So I hope this video has been informative for you and I'd like to thank you for viewing.