WEBVTT - TCP and its History 0:00:04.120 --> 0:00:07.160 Get in touch with technology with tech Stuff from how 0:00:07.200 --> 0:00:13.680 stuff Works dot com. Hey there, and welcome to tech Stuff. 0:00:13.680 --> 0:00:16.880 I'm your host, Jonathan Strickland. I'm an executive producer at 0:00:16.920 --> 0:00:20.560 iHeart Radio and how Stuff Works in I love all 0:00:20.800 --> 0:00:25.680 things tech, and recently, as I was looking over tech news, 0:00:25.760 --> 0:00:30.520 I saw that the Venerable Transmission Control Protocol a a 0:00:30.680 --> 0:00:33.680 t c P is getting ready to take its bow 0:00:33.920 --> 0:00:37.560 upon the release of the next version of Hypertext Transfer 0:00:37.600 --> 0:00:40.920 Protocol or h t t P. In other words, it 0:00:40.960 --> 0:00:44.960 will no longer be part of how ht t P works. 0:00:44.960 --> 0:00:47.000 So wait, what does all that mean? That's a whole 0:00:47.040 --> 0:00:50.680 lot of initialisms, and why does it matter. Where did 0:00:50.720 --> 0:00:54.520 TCP come from? Anyway? Well, most of the time we 0:00:54.680 --> 0:00:59.120 group TCP together with Internet Protocol or i P, so 0:00:59.480 --> 0:01:03.000 it's pretty comedy here. People talk about the TCP slash 0:01:03.120 --> 0:01:07.080 i P protocol, but that name is misleading as generally 0:01:07.160 --> 0:01:10.000 what is meant by that is a suite of protocols, 0:01:10.040 --> 0:01:13.320 not just those two. Though. To be fair, when Robert 0:01:13.360 --> 0:01:16.600 Khan invinced SURF we're first working on the transport rules 0:01:16.680 --> 0:01:19.520 of the Internet, they lumped it all together in one 0:01:19.600 --> 0:01:24.160 protocol called t c P, So just a reminder. Let's 0:01:24.160 --> 0:01:28.280 start on the very basic definitions here. A protocol is 0:01:28.360 --> 0:01:32.200 essentially a set of rules or directions. So it's the 0:01:32.200 --> 0:01:35.360 parameters that we create so that computers know what to 0:01:35.440 --> 0:01:38.120 do when we tell them to do stuff. And a 0:01:38.160 --> 0:01:41.520 good protocol should be functional and consistent. You should be 0:01:41.520 --> 0:01:44.639 able to get the same result every time you follow 0:01:44.640 --> 0:01:47.840 those rules if you give the same inputs. Now, while 0:01:47.880 --> 0:01:51.640 there are several protocols in the TCP I P suite, 0:01:51.880 --> 0:01:55.480 the t c P and i P ones are particularly important. 0:01:55.600 --> 0:01:59.360 No big surprise, since that's the ones we use whenever 0:01:59.400 --> 0:02:03.200 we refer to these protocols. So a quick reminder about 0:02:03.320 --> 0:02:08.000 how computers send data over the Internet. Computers do not 0:02:08.320 --> 0:02:11.640 send enormous files all in one go, because that would 0:02:11.639 --> 0:02:14.960 be difficult to scale as the network of computers got 0:02:15.040 --> 0:02:18.760 larger and the file sizes got bigger as well, and 0:02:18.760 --> 0:02:20.640 it would mean that if something were to go wrong 0:02:20.919 --> 0:02:23.799 during the transmission of a file, you would at best 0:02:24.080 --> 0:02:26.680 end up with a corrupt file and you'd have to 0:02:26.720 --> 0:02:29.040 start all over again. At worst, you wouldn't end up 0:02:29.080 --> 0:02:31.840 with anything at all. So either way, you would have 0:02:31.880 --> 0:02:34.360 to figure out how to start up the process so 0:02:34.440 --> 0:02:38.000 to facilitate sending this information across the network so that 0:02:38.080 --> 0:02:42.560 it's not unmanageable. This protocol suite divvies up the file 0:02:42.680 --> 0:02:48.320 into smaller packets of data. Each packet has information associated 0:02:48.360 --> 0:02:51.640 with it that identifies where it is coming from, where 0:02:51.639 --> 0:02:55.000 it is headed on the Internet, and how the information 0:02:55.040 --> 0:02:58.560 contained within the packet fits in with all the other 0:02:58.639 --> 0:03:02.000 packets of information for that same file, so that the 0:03:02.000 --> 0:03:05.239 computer on the other end of the communication channel can 0:03:05.280 --> 0:03:07.200 get all those packets and then put it all back 0:03:07.240 --> 0:03:09.560 together so that you get the file that was sent 0:03:09.800 --> 0:03:15.960 by the first computer. TCP defines how applications can create 0:03:16.080 --> 0:03:21.000 channels of communication across a network. It also manages how 0:03:21.040 --> 0:03:25.120 a message is assembled into those smaller packets before they 0:03:25.160 --> 0:03:28.960 are then transmitted over the Internet and then reassembled at 0:03:28.960 --> 0:03:32.600 the destination address, and it makes sure that the recipient 0:03:32.639 --> 0:03:37.440 computer has actually received each packet in sequence to verify 0:03:37.440 --> 0:03:40.200 that the entire file has made it across. So it's 0:03:40.280 --> 0:03:44.080 kind of an error checking mechanism, or a way of 0:03:44.240 --> 0:03:48.000 ensuring that the information computer A is sending to computer 0:03:48.080 --> 0:03:52.240 B gets to where it's going. Without these rules, you 0:03:52.240 --> 0:03:55.480 would never really be sure if you send something from 0:03:55.480 --> 0:03:58.600 computer A. If computer B got it. This is a 0:03:58.640 --> 0:04:01.120 set of rules that tells computer or be to say, hey, 0:04:01.160 --> 0:04:03.600 by the way, once you get all these, let computer 0:04:03.680 --> 0:04:08.480 A know so that everyone knows that the transmission is complete. 0:04:09.160 --> 0:04:12.080 I P, by the way, defines how to address and 0:04:12.200 --> 0:04:16.240 route each packet to make sure it reaches the right destination. 0:04:16.520 --> 0:04:22.560 It's technically on a layer lower than the TCP protocol. Now, 0:04:22.600 --> 0:04:26.560 way back in the early nineteen seventies, you had a 0:04:26.600 --> 0:04:30.839 team working on a project called ARPA net. This is 0:04:30.839 --> 0:04:33.600 going to go back to DARPA, which I covered in 0:04:33.640 --> 0:04:36.839 a series of episodes recently, so this kind of ties 0:04:36.880 --> 0:04:40.320 in with that more than a little bit. Ar Ponett 0:04:40.480 --> 0:04:43.520 was an early computer network, and in a way it 0:04:43.560 --> 0:04:46.599 was a precursor to the Internet. Remember the Internet is 0:04:46.640 --> 0:04:51.480 a network of networks. Ar Ponnett was a network, period 0:04:52.480 --> 0:04:55.320 and while the team was working on this, they realized 0:04:55.360 --> 0:04:58.320 that the protocols they had been using for our bonnet 0:04:58.560 --> 0:05:02.000 were functional but not scalable. If you were to go 0:05:02.080 --> 0:05:05.960 beyond just one network, if you wanted to connect two 0:05:06.040 --> 0:05:09.560 networks together, you really needed a different solution. And as 0:05:09.600 --> 0:05:13.200 this network would get bigger, the situation would become untenable 0:05:13.640 --> 0:05:15.800 and so some of the team got to work designing 0:05:15.839 --> 0:05:19.839 new sets of rules for networked communication that could keep 0:05:19.880 --> 0:05:23.119 things running smoothly even as the network would get bigger 0:05:23.120 --> 0:05:26.520 and bigger, something that was truly scalable. One of the 0:05:26.560 --> 0:05:29.719 people working on this was a guy named Robert Kahn, 0:05:29.880 --> 0:05:32.520 one of the fathers of the Internet. You often hear 0:05:32.560 --> 0:05:36.360 about him and his buddy Vents Surf, who together would 0:05:36.600 --> 0:05:40.680 create TCP. So Robert Kahn comes on over to DARPA 0:05:40.720 --> 0:05:43.680 and he's part of the I P. T O Department. 0:05:43.880 --> 0:05:48.160 That's the department that's in charge of creating networks and 0:05:48.200 --> 0:05:51.240 that sort of thing. He specifically wanted to replace an 0:05:51.279 --> 0:05:55.120 earlier set of rules, an earlier protocol called the Network 0:05:55.240 --> 0:05:58.719 Control Program or in c P. And the reason for 0:05:58.800 --> 0:06:01.400 that gets a little technical, but I figure we can 0:06:01.440 --> 0:06:04.719 go a bit further than just it doesn't scale well, 0:06:04.800 --> 0:06:07.120 because that doesn't really tell you much. So for just 0:06:07.200 --> 0:06:10.200 a second, let's talk about what con was envisioning back 0:06:10.240 --> 0:06:13.719 in the early nineteen seventies. He wanted a protocol that 0:06:13.839 --> 0:06:16.200 was going to do certain things. He felt that a 0:06:16.200 --> 0:06:19.880 computer scientists had connected these distant computers together using the 0:06:19.920 --> 0:06:22.760 telephone system that created the first wide area network, but 0:06:22.880 --> 0:06:26.799 that was not going to be sustainable on a broader scale. 0:06:27.400 --> 0:06:30.120 He knew that the key component of the network technology 0:06:30.120 --> 0:06:34.080 at our ponet was the Interface Message Processor or i 0:06:34.320 --> 0:06:38.200 MP and MP and an MP is kind of like 0:06:38.360 --> 0:06:41.920 a router. It was a packet switching node that would 0:06:41.920 --> 0:06:45.799 serve as a connection between different computers on our bonnet. 0:06:46.520 --> 0:06:49.880 In addition to imps, the team on our Bonnet was 0:06:50.240 --> 0:06:52.920 working on a host to host protocol which would become 0:06:52.960 --> 0:06:57.159 the network control protocol, and developers began to create applications 0:06:57.440 --> 0:07:00.400 to run on those networks like email and con would 0:07:00.440 --> 0:07:05.120 demonstrate even a twenty node large network in nineteen seventy two, 0:07:05.160 --> 0:07:08.760 so a network consisting of twenty computers. Khan was also 0:07:08.839 --> 0:07:14.000 working on technology for a packet radio network that would 0:07:14.040 --> 0:07:17.440 actually use radio waves to send data back and forth 0:07:17.440 --> 0:07:20.720 across different computers, and that was going to use packet 0:07:20.760 --> 0:07:26.080 switching specifically because radio is tricky stuff. If a signal 0:07:26.320 --> 0:07:30.360 were lost or jammed, then the information that was being 0:07:30.400 --> 0:07:32.800 sent across the network would be lost and you'd end 0:07:32.840 --> 0:07:35.600 up with miscommunications and failures, so you had to have 0:07:35.640 --> 0:07:39.320 a way to deal with this. Originally, Khan had intended 0:07:39.360 --> 0:07:43.440 to develop a protocol specifically for radio packet networks to 0:07:44.040 --> 0:07:47.520 have the sort of error correction mechanism in there, a 0:07:47.560 --> 0:07:51.600 way of guaranteeing that the information from one system would 0:07:51.640 --> 0:07:55.720 get to another, and then this network would be able 0:07:55.760 --> 0:08:00.400 to interface with other networks like arpanet, using the already 0:08:00.520 --> 0:08:04.720 established in CP as a transport layer. But there was 0:08:04.760 --> 0:08:08.120 a big problem. N c P could only address networks 0:08:08.120 --> 0:08:12.000 and machines down to the imp level. N CP would 0:08:12.000 --> 0:08:16.040 rely upon our bonnet itself for end to end reliability, 0:08:16.120 --> 0:08:18.760 so it worked just fine if you were in our 0:08:18.840 --> 0:08:22.680 pannet if your machine was directly connected into that network, 0:08:23.040 --> 0:08:27.600 But if you wanted to interconnect the arpanet network with 0:08:27.720 --> 0:08:31.760 another network, something had to change because n c P 0:08:32.000 --> 0:08:36.280 could not handle identifying and responding to errors and delivering 0:08:36.800 --> 0:08:40.120 information to the computers that were outside of our bannet. 0:08:40.480 --> 0:08:43.800 N CP just didn't have that capability. Arpanet handled everything 0:08:43.800 --> 0:08:46.600 within the network, but it didn't have anything designed to 0:08:46.960 --> 0:08:51.160 handle stuff from outside that network. So at first Kahn 0:08:51.320 --> 0:08:54.800 had planned to only work on the packet radio networks 0:08:54.800 --> 0:08:57.760 and just concentrate on that, but ultimately his quest to 0:08:57.800 --> 0:09:01.439 create a protocol that could ensure message is were arriving 0:09:01.520 --> 0:09:07.200 at their destinations across different networks, expanded beyond just the 0:09:07.200 --> 0:09:12.800 packet radio application. So Cohn wanted an open network architecture, 0:09:13.160 --> 0:09:16.920 something that would allow any sort of networked system to 0:09:17.120 --> 0:09:20.560 interconnect with another and still have rules in place to 0:09:20.800 --> 0:09:24.040 ensure that the data was getting to where it needed 0:09:24.080 --> 0:09:27.760 to go. So Robert Kahn and vent Surf were two 0:09:27.800 --> 0:09:30.720 computer scientists who were working on this. They were the 0:09:30.800 --> 0:09:34.720 authors of these protocols. Vent Surf had been one of 0:09:34.720 --> 0:09:37.880 the people to create in CP well fun fact, by 0:09:37.920 --> 0:09:41.880 the way, TCP did not originally stand for Transmission control 0:09:41.960 --> 0:09:46.040 Protocol back when con and Surf first proposed it. Instead, 0:09:46.559 --> 0:09:50.800 it stood for Transmission Control Program, and that's a subtle difference, 0:09:50.840 --> 0:09:54.199 to be sure. They wrote the first version of TCP 0:09:54.480 --> 0:09:58.280 in ninety three, and they published a fully documented and 0:09:58.360 --> 0:10:04.760 revised version in four under RFC six. It was specifically 0:10:04.760 --> 0:10:10.360 titled Specification of Internet Transmission Control Program. Not long after 0:10:10.400 --> 0:10:13.280 the initial creation, other folks began to realize that it 0:10:13.360 --> 0:10:16.280 might be a better idea to break out the functions 0:10:16.320 --> 0:10:19.520 of t c P into two sets of protocols, and 0:10:19.559 --> 0:10:22.760 that's where we get t c P I P. Because, again, 0:10:22.800 --> 0:10:25.360 before it was all lumped together, and then they figured 0:10:25.440 --> 0:10:28.800 this would make more sense if we separated them out 0:10:28.880 --> 0:10:32.319 into two sets of rules. The creation of t C 0:10:32.520 --> 0:10:37.040 P I P predates the Open Systems Interconnection or O 0:10:37.280 --> 0:10:39.599 S I layer model. And I've talked about the O 0:10:39.760 --> 0:10:42.600 SI model in a past episode of tech Stuff. But 0:10:42.720 --> 0:10:45.800 the O SI model describes how different parts of a 0:10:45.800 --> 0:10:50.600 telecommunications or computer system communicate with one another. They have 0:10:50.880 --> 0:10:54.760 layers to describe the different functions. But T C P 0:10:54.960 --> 0:10:57.959 I P layers are are pretty similar to O SI layers, 0:10:58.160 --> 0:11:00.160 so we can we can talk about the two as 0:11:00.200 --> 0:11:04.960 being at least somewhat analogous. It's an abstract idea that's 0:11:05.000 --> 0:11:09.160 meant to describe how each layer fits within a grand scheme. 0:11:09.400 --> 0:11:12.240 So layers that are near the bottom of the stack 0:11:12.760 --> 0:11:15.319 support all the layers that are on top of it. 0:11:15.720 --> 0:11:19.720 Layers at the top do not necessarily support any other layers. 0:11:19.760 --> 0:11:22.600 They rely on the ones below them, but they don't 0:11:22.640 --> 0:11:26.120 support anything any layers above them. And again this is 0:11:26.160 --> 0:11:31.160 an abstraction. There are not actual literal layers in these systems, 0:11:31.200 --> 0:11:34.840 but within this framework, you could say TCP would be 0:11:34.920 --> 0:11:38.280 on layer four. That would be the transport layer. The 0:11:38.320 --> 0:11:42.360 Internet protocol is one layer further down. It's on layer three, 0:11:42.840 --> 0:11:46.640 meaning it is a little closer to the basic hardware 0:11:46.760 --> 0:11:50.480 layer of the system. That's the lowest layer is the hardware, 0:11:51.080 --> 0:11:55.080 and that uh means that the i P protocol supports 0:11:55.120 --> 0:11:59.880 the TCP protocols above it and above TCP are the 0:12:00.080 --> 0:12:03.880 application layers where you have stuff like file Transfer Protocol, 0:12:04.360 --> 0:12:07.520 email and h T t P. Those are all on 0:12:07.600 --> 0:12:10.400 top of it. I've got more to say about what 0:12:10.520 --> 0:12:13.240 TCP is and what it does in just a moment, 0:12:13.240 --> 0:12:16.440 but first let's take a quick break to thank our sponsor. 0:12:23.960 --> 0:12:27.720 So when laying out the rules for TCP, bob con 0:12:27.760 --> 0:12:31.160 had a few requirements and this is from the Internet 0:12:31.160 --> 0:12:34.800 Society's page on the History of the Internet, and they 0:12:34.800 --> 0:12:38.080 were each distinct network would have to stand on its 0:12:38.080 --> 0:12:42.240 own and no internal changes should be required to any 0:12:42.280 --> 0:12:47.320 such network to connect it to the Internet. Next, communications 0:12:47.480 --> 0:12:50.600 would be on a best effort basis, so if a 0:12:50.640 --> 0:12:53.920 packet did not make it to the final destination, it 0:12:53.960 --> 0:12:57.920 would shortly be retransmitted from the source. So this is 0:12:58.000 --> 0:13:02.640 the error correction part. A packet on its way to 0:13:03.360 --> 0:13:07.240 computer B never makes it, then computer A will retransmit 0:13:07.320 --> 0:13:10.720 that same packet black boxes would be used to connect 0:13:10.760 --> 0:13:14.240 these networks. These would later be called gateways and routers, 0:13:14.720 --> 0:13:18.160 and there would be no information retained by the gateways 0:13:18.240 --> 0:13:22.120 about the individual flows of packets passing through them, thereby 0:13:22.240 --> 0:13:25.640 just keeping them very simple and avoiding complicated adaptation and 0:13:25.679 --> 0:13:28.880 recovery from various failure modes. So they were really just 0:13:29.679 --> 0:13:35.480 a means of controlling traffic flow, but not monitoring traffic flow, 0:13:35.920 --> 0:13:39.240 and there would be no global control at the operations level. 0:13:39.400 --> 0:13:42.680 Those were his requirements. Those would develop into more granular 0:13:42.760 --> 0:13:46.920 requirements as the work would continue on the protocols. And 0:13:47.040 --> 0:13:51.240 Vince Surf did a really really good explanation about how 0:13:51.320 --> 0:13:54.679 TCP works in a short video, and he used a 0:13:54.720 --> 0:13:58.360 postcard analogy, and I highly recommend checking it out because 0:13:59.040 --> 0:14:01.680 he just puts it very simply. I'm gonna kind of 0:14:01.720 --> 0:14:06.000 paraphrase what he said here. He compared TCP to sending 0:14:06.240 --> 0:14:09.080 a book to a friend, and you're using the postal service, 0:14:10.080 --> 0:14:13.200 except your postal service is very peculiar. They will not 0:14:13.400 --> 0:14:17.240 carry anything other than postcards. So you cannot actually send 0:14:17.240 --> 0:14:20.720 the physical book as is to your friend because the 0:14:20.800 --> 0:14:23.320 post office is not gonna carry that. So what you 0:14:23.400 --> 0:14:27.040 have to do is cut your book up so that 0:14:27.080 --> 0:14:31.920 you can fit maybe about half a page on a postcard, 0:14:32.240 --> 0:14:34.280 and then you can send that postcard through the mail, 0:14:34.680 --> 0:14:37.240 and then you have to send all of the book 0:14:37.560 --> 0:14:39.520 in a series of postcards to your friend. But then 0:14:39.600 --> 0:14:42.040 you realize, hey, wait, because of the way I have 0:14:42.120 --> 0:14:46.000 to cut up this book, sometimes there's no indication there 0:14:46.040 --> 0:14:48.760 about a page number, so there's no way of knowing 0:14:48.920 --> 0:14:52.440 just on the page where this page fits in relation 0:14:52.480 --> 0:14:55.080 to the rest of the book. So then you number 0:14:55.480 --> 0:14:58.840 every single postcard, and that way your friend knows what 0:14:59.120 --> 0:15:01.960 order they go in, they know the sequence, so there's 0:15:02.320 --> 0:15:05.760 no guarantee that any one postcard will actually make it 0:15:05.760 --> 0:15:08.240 all the way through. There's also no guarantee your friend 0:15:08.280 --> 0:15:10.880 will receive the postcards in the same order that you 0:15:11.000 --> 0:15:14.360 sent them. But by numbering, your friend will know which 0:15:14.400 --> 0:15:17.800 postcards they have received. So if they get postcard number 0:15:17.840 --> 0:15:21.080 eighty three but they didn't get postcard number A D two, 0:15:21.360 --> 0:15:23.960 they can send you a message alerting you that they 0:15:24.000 --> 0:15:27.200 are missing one, and you can read, transmit or re send, 0:15:27.640 --> 0:15:29.840 so your friend can send a postcard back to you. 0:15:30.040 --> 0:15:32.680 Essentially says, hey, I got all the postcards up to 0:15:32.760 --> 0:15:35.560 number eighty two or whatever. But that's it, and this 0:15:35.560 --> 0:15:38.160 would let you know that you need to resend those postcards, 0:15:38.240 --> 0:15:40.280 which means you have to keep a copy of the 0:15:40.320 --> 0:15:43.560 postcards you've submitted. You can't just send your only copy 0:15:43.720 --> 0:15:48.200 because you'd be up the creek if your buddy says, hey, 0:15:48.240 --> 0:15:51.160 I didn't get that, and if nothing comes back to you, 0:15:51.200 --> 0:15:55.120 if your friend never says, oh, I received everything, then 0:15:55.160 --> 0:15:58.200 you would have to start re sending postcards until you 0:15:58.320 --> 0:16:00.800 finally got a message that says, hey, a toad, scut 0:16:00.800 --> 0:16:02.480 all the postcards, thank you, I'm going to read the 0:16:02.520 --> 0:16:04.720 book now, or whatever it might be. But that's how 0:16:04.760 --> 0:16:08.280 TCP works. But instead of it being you know, physical postcards, 0:16:08.320 --> 0:16:12.320 we're talking digital information. There's never a guarantee that the 0:16:12.360 --> 0:16:14.880 information you send is actually going to get to your 0:16:14.920 --> 0:16:19.160 destination or that will all arrive sequentially. But these safeguards 0:16:19.200 --> 0:16:21.920 mean that your computer will know when to send stuff 0:16:21.960 --> 0:16:26.280 again to guarantee transmission. The United States Department of Defense 0:16:26.360 --> 0:16:31.080 adopted TCP i P as a standard in nineteen eighty. 0:16:31.280 --> 0:16:35.200 DARPA was able to change over in advance of everyone else, 0:16:35.480 --> 0:16:39.240 which allowed for partitioning of the military networks from non 0:16:39.320 --> 0:16:42.120 military networks, and that would carry forward, so you have 0:16:42.240 --> 0:16:44.920 mill net that's its own separate network that's based on 0:16:45.440 --> 0:16:49.120 essentially the same architecture as the general Internet. T c 0:16:49.320 --> 0:16:52.880 P i P would become the official transport layer for 0:16:53.080 --> 0:16:57.680 ar PONNETT on January one, nine three. This was called 0:16:57.760 --> 0:17:00.720 a flag day. Now, that is an event that involves 0:17:00.920 --> 0:17:06.040 incorporating a critical change in a very large system UH 0:17:06.040 --> 0:17:08.800 in a simultaneous way, like it has to change throughout 0:17:08.840 --> 0:17:12.160 the system the same time, UH, and that is really 0:17:12.200 --> 0:17:14.480 tricky to do. The bigger the system, obviously, the harder 0:17:14.520 --> 0:17:17.400 it is for you to make a global change all 0:17:17.440 --> 0:17:20.400 at the same time. The transition had been planned out 0:17:20.400 --> 0:17:24.400 for years in advance because this would require network administrators 0:17:24.400 --> 0:17:26.400 to change over to the t c P i P 0:17:26.400 --> 0:17:29.920 protocol all at the same time, and surprisingly it went 0:17:29.960 --> 0:17:33.359 off without any really major problems, So that's pretty cool. 0:17:34.000 --> 0:17:38.359 By the mid nineteen eighties, the Internet was an established thing, 0:17:38.680 --> 0:17:41.480 though really only a relatively small number of people were 0:17:41.520 --> 0:17:44.280 aware of it. If you worked at DARPA, or if 0:17:44.320 --> 0:17:46.880 you were at a university with a really good computer 0:17:46.960 --> 0:17:50.280 science curriculum, or maybe you worked in a research facility, 0:17:51.200 --> 0:17:54.400 or maybe you were in the military, then you might 0:17:54.720 --> 0:17:57.640 know about it. A few other government offices also were 0:17:57.720 --> 0:18:02.560 on the early Internet, but apart from that and a 0:18:02.600 --> 0:18:06.080 few major businesses, it was largely a thing of mystery. 0:18:06.440 --> 0:18:09.480 The general public was pretty much ignorant of the Internet 0:18:09.560 --> 0:18:12.520 for almost a decade. It wouldn't be until the emergence 0:18:12.520 --> 0:18:14.960 of the World Wide Web that more people would become 0:18:15.000 --> 0:18:18.000 aware of the Internet, and in fact, at that point, 0:18:18.080 --> 0:18:21.320 the Worldwide Web and the Internet would often be confused 0:18:21.320 --> 0:18:24.160 as meaning the same thing for a lot of people. 0:18:24.200 --> 0:18:26.880 A lot of people would refer to the Worldwide Web 0:18:26.920 --> 0:18:30.240 as the Internet, not realizing that really the world Wide 0:18:30.240 --> 0:18:34.560 Web is one application built on top of the Internet, 0:18:35.040 --> 0:18:38.800 it is not itself the Internet. In the early nineties, uh, 0:18:38.840 --> 0:18:42.120 speaking of the Web, a guy named Tim berners Lee, 0:18:42.400 --> 0:18:46.000 he was working for a little scientific research organization called CERN, 0:18:46.400 --> 0:18:48.600 had a bright idea. And his idea was for an 0:18:48.640 --> 0:18:52.800 application protocol on top of the Internet that would facilitate 0:18:52.840 --> 0:18:58.520 communications between client computers and server computers, including file transfers 0:18:58.640 --> 0:19:00.879 and the ability for a sir her to refer a 0:19:00.960 --> 0:19:03.879 client to a different server. And that would be the 0:19:03.920 --> 0:19:07.119 foundation for the Worldwide Web. And just in case you 0:19:07.119 --> 0:19:10.080 didn't pick up on my stupid joke. CERN is not 0:19:10.320 --> 0:19:14.720 a little scientific research organization. It's the European Organization for 0:19:14.840 --> 0:19:19.479 Nuclear Research and it is a huge, huge deal. Among 0:19:19.800 --> 0:19:24.120 the many things it does is oversee the large Hadron collider, 0:19:24.520 --> 0:19:29.920 so big, big organization. Ultimately, the purpose of h t 0:19:30.119 --> 0:19:33.639 t P, which was created by Tim berners Lee, was 0:19:33.800 --> 0:19:37.760 to create a means of linking different documents together through 0:19:37.880 --> 0:19:40.640 what is called hypertext. And you've seen these. These are 0:19:40.640 --> 0:19:43.480 those highlighted words and web pages, and when you click 0:19:43.520 --> 0:19:45.959 on it, you go to a different web page. And 0:19:46.000 --> 0:19:48.679 that's the whole point is clicking on hypertext sends a 0:19:48.680 --> 0:19:52.119 command to navigate to a new page. And because the 0:19:52.240 --> 0:19:55.639 rules for h T t P allow for one server 0:19:56.080 --> 0:19:59.240 to refer a client to another server, those two web 0:19:59.240 --> 0:20:02.320 pages don't have a quote unquote live on the same 0:20:02.359 --> 0:20:06.520 server together. So we're talking about the very basic foundation 0:20:06.560 --> 0:20:10.919 of how the Worldwide Web works with the interlinking documents 0:20:10.960 --> 0:20:13.720 that allow you to hop from one page or one 0:20:13.800 --> 0:20:19.680 site to another. The features of HTTP version zero point nine, 0:20:19.920 --> 0:20:23.000 which was the first one released to the public, included 0:20:23.119 --> 0:20:29.200 the following clients Server Request Response Protocol as key protocol 0:20:29.320 --> 0:20:32.600 running over a t C p I P link. It 0:20:32.720 --> 0:20:36.000 was designed to transfer hypertext documents or h t m 0:20:36.160 --> 0:20:39.600 L and the connection between server and client is closed 0:20:39.680 --> 0:20:43.439 after every request. And that's it. It was bare bones stuff, 0:20:43.720 --> 0:20:47.520 but this was the beginning of something truly transformational. In fact, 0:20:48.280 --> 0:20:50.919 I could honestly say I would not have the career 0:20:51.000 --> 0:20:58.480 I have without this invention. So from the h t 0:20:58.480 --> 0:21:02.520 t P standard of pretty quickly, Tim burns Lee had 0:21:02.520 --> 0:21:05.040 set the stage, and then a team at the National 0:21:05.119 --> 0:21:09.359 Center of Supercomputing Applications or in c s A made 0:21:09.400 --> 0:21:13.359 the first popular web browser called Mosaic. One of the 0:21:13.400 --> 0:21:16.880 programmers on that team was a guy named Mark Andreason, 0:21:17.240 --> 0:21:20.359 who went on to co found the Mosaic Corporation and 0:21:20.400 --> 0:21:25.119 eventually publish a new browser called Netscape. Now, at that 0:21:25.240 --> 0:21:29.480 same time, the Internet Engineering Task Force was organizing a 0:21:29.480 --> 0:21:33.720 team called the ht t P Working Group dedicated to 0:21:33.840 --> 0:21:39.240 improving this HTTP protocol, and it was quickly developing in 0:21:39.440 --> 0:21:42.360 several different directions. And by that I mean a lot 0:21:42.359 --> 0:21:46.200 of different people had started by taking the version zero 0:21:46.280 --> 0:21:49.800 point nine h t t P and then tweaking it 0:21:50.200 --> 0:21:55.560 independently of each other. So it's evolving in different directions simultaneously. 0:21:56.560 --> 0:22:00.359 So while there's a shorthand that refers to h t 0:22:00.359 --> 0:22:04.000 t P one point oh. There is not an actual 0:22:04.359 --> 0:22:09.040 standard one point oh. There were many quote unquote flavors 0:22:09.040 --> 0:22:11.320 of one point oh because there were so many different 0:22:11.880 --> 0:22:15.480 variations on that, the I E. T F Working Group 0:22:15.760 --> 0:22:20.399 would publish a standard for HTTP Protocol version one point 0:22:20.520 --> 0:22:25.800 one under RFC two zero six eight if you want 0:22:25.800 --> 0:22:29.560 to read it. It's a little technical, but this version 0:22:29.600 --> 0:22:32.720 would be tweaked and updated before it was officially released. 0:22:32.760 --> 0:22:37.960 In Version two point oh of h T t P 0:22:38.480 --> 0:22:42.959 wouldn't come out until two thousand fifteen. That is a 0:22:43.040 --> 0:22:46.080 long time between versions one point one came out in 0:22:47.080 --> 0:22:51.480 two point oh and two thousand fifteen, and only about 0:22:51.480 --> 0:22:55.080 a third of all websites in the world today support 0:22:55.680 --> 0:22:59.240 version two point oh as the standard. Most websites are 0:22:59.240 --> 0:23:02.920 still using one point oh or one point one, So 0:23:03.200 --> 0:23:06.440 it may come as something of a surprise to hear 0:23:06.800 --> 0:23:09.600 that h T t P three point oh is right 0:23:09.640 --> 0:23:12.359 around the corner when not even a majority of sites 0:23:12.680 --> 0:23:15.240 are on the most recent version of two point oh, 0:23:15.359 --> 0:23:19.320 and perhaps an even bigger surprises that, unlike the earlier versions, 0:23:19.920 --> 0:23:24.600 this h T t P protocol will not rely upon 0:23:24.720 --> 0:23:27.320 t c P. I'll explain more in just a second, 0:23:27.320 --> 0:23:39.080 but first let's take another quick break to thank our sponsor. Okay, 0:23:39.760 --> 0:23:44.160 So why would h T t P three point oh 0:23:44.560 --> 0:23:47.480 ditch TCP, which has been a part of the framework 0:23:47.680 --> 0:23:51.640 of the Internet since the very beginning, since before there 0:23:51.960 --> 0:23:55.560 was an Internet. Well, it mostly comes down to two 0:23:55.600 --> 0:24:00.240 big things, speed and efficiency. So when Robert Cohn and 0:24:00.280 --> 0:24:03.280 when vent surf we're working on TCP, they were building 0:24:03.280 --> 0:24:07.240 out a protocol to handle any sort of application that 0:24:07.280 --> 0:24:10.280 would be built on top of what was to become 0:24:10.280 --> 0:24:13.520 the Internet. So and it has a very much a 0:24:13.600 --> 0:24:17.399 one size fits all kind of approach to that it 0:24:17.480 --> 0:24:20.280 provided useful or really I mean, at this point I 0:24:20.280 --> 0:24:25.440 should just say necessary set of features to facilitate communication. 0:24:25.960 --> 0:24:30.880 But some of those are excessive or not as pertinent 0:24:31.080 --> 0:24:33.560 to the types of traffic that happened over h T 0:24:33.760 --> 0:24:38.320 t P, or they impede some of the functions that 0:24:38.600 --> 0:24:42.520 htt P handles. For example, in an effort to establish 0:24:42.880 --> 0:24:47.360 a connection between a client and a server, TCP requires 0:24:47.400 --> 0:24:51.880 a number of back and forth messages, essentially saying, hey 0:24:51.920 --> 0:24:55.840 over there, services, Yeah, what is it? Client says, I 0:24:55.840 --> 0:24:57.880 want to talk to you? The services all right? Hang 0:24:57.920 --> 0:25:00.760 on a second, and the computer says now, good time, 0:25:00.800 --> 0:25:02.639