Speaker 1: Get in touch with technology with tech Stuff from how
Speaker 1: stuff Works dot com. Hey there, and welcome to tech Stuff.
Speaker 1: I'm your host, Jonathan Strickland. I'm an executive producer at
Speaker 1: iHeart Radio and how Stuff Works in I love all
Speaker 1: things tech, and recently, as I was looking over tech news,
Speaker 1: I saw that the Venerable Transmission Control Protocol a a
Speaker 1: t c P is getting ready to take its bow
Speaker 1: upon the release of the next version of Hypertext Transfer
Speaker 1: Protocol or h t t P. In other words, it
Speaker 1: will no longer be part of how ht t P works.
Speaker 1: So wait, what does all that mean? That's a whole
Speaker 1: lot of initialisms, and why does it matter. Where did
Speaker 1: TCP come from? Anyway? Well, most of the time we
Speaker 1: group TCP together with Internet Protocol or i P, so
Speaker 1: it's pretty comedy here. People talk about the TCP slash
Speaker 1: i P protocol, but that name is misleading as generally
Speaker 1: what is meant by that is a suite of protocols,
Speaker 1: not just those two. Though. To be fair, when Robert
Speaker 1: Khan invinced SURF we're first working on the transport rules
Speaker 1: of the Internet, they lumped it all together in one
Speaker 1: protocol called t c P, So just a reminder. Let's
Speaker 1: start on the very basic definitions here. A protocol is
Speaker 1: essentially a set of rules or directions. So it's the
Speaker 1: parameters that we create so that computers know what to
Speaker 1: do when we tell them to do stuff. And a
Speaker 1: good protocol should be functional and consistent. You should be
Speaker 1: able to get the same result every time you follow
Speaker 1: those rules if you give the same inputs. Now, while
Speaker 1: there are several protocols in the TCP I P suite,
Speaker 1: the t c P and i P ones are particularly important.
Speaker 1: No big surprise, since that's the ones we use whenever
Speaker 1: we refer to these protocols. So a quick reminder about
Speaker 1: how computers send data over the Internet. Computers do not
Speaker 1: send enormous files all in one go, because that would
Speaker 1: be difficult to scale as the network of computers got
Speaker 1: larger and the file sizes got bigger as well, and
Speaker 1: it would mean that if something were to go wrong
Speaker 1: during the transmission of a file, you would at best
Speaker 1: end up with a corrupt file and you'd have to
Speaker 1: start all over again. At worst, you wouldn't end up
Speaker 1: with anything at all. So either way, you would have
Speaker 1: to figure out how to start up the process so
Speaker 1: to facilitate sending this information across the network so that
Speaker 1: it's not unmanageable. This protocol suite divvies up the file
Speaker 1: into smaller packets of data. Each packet has information associated
Speaker 1: with it that identifies where it is coming from, where
Speaker 1: it is headed on the Internet, and how the information
Speaker 1: contained within the packet fits in with all the other
Speaker 1: packets of information for that same file, so that the
Speaker 1: computer on the other end of the communication channel can
Speaker 1: get all those packets and then put it all back
Speaker 1: together so that you get the file that was sent
Speaker 1: by the first computer. TCP defines how applications can create
Speaker 1: channels of communication across a network. It also manages how
Speaker 1: a message is assembled into those smaller packets before they
Speaker 1: are then transmitted over the Internet and then reassembled at
Speaker 1: the destination address, and it makes sure that the recipient
Speaker 1: computer has actually received each packet in sequence to verify
Speaker 1: that the entire file has made it across. So it's
Speaker 1: kind of an error checking mechanism, or a way of
Speaker 1: ensuring that the information computer A is sending to computer
Speaker 1: B gets to where it's going. Without these rules, you
Speaker 1: would never really be sure if you send something from
Speaker 1: computer A. If computer B got it. This is a
Speaker 1: set of rules that tells computer or be to say, hey,
Speaker 1: by the way, once you get all these, let computer
Speaker 1: A know so that everyone knows that the transmission is complete.
Speaker 1: I P, by the way, defines how to address and
Speaker 1: route each packet to make sure it reaches the right destination.
Speaker 1: It's technically on a layer lower than the TCP protocol. Now,
Speaker 1: way back in the early nineteen seventies, you had a
Speaker 1: team working on a project called ARPA net. This is
Speaker 1: going to go back to DARPA, which I covered in
Speaker 1: a series of episodes recently, so this kind of ties
Speaker 1: in with that more than a little bit. Ar Ponett
Speaker 1: was an early computer network, and in a way it
Speaker 1: was a precursor to the Internet. Remember the Internet is
Speaker 1: a network of networks. Ar Ponnett was a network, period
Speaker 1: and while the team was working on this, they realized
Speaker 1: that the protocols they had been using for our bonnet
Speaker 1: were functional but not scalable. If you were to go
Speaker 1: beyond just one network, if you wanted to connect two
Speaker 1: networks together, you really needed a different solution. And as
Speaker 1: this network would get bigger, the situation would become untenable
Speaker 1: and so some of the team got to work designing
Speaker 1: new sets of rules for networked communication that could keep
Speaker 1: things running smoothly even as the network would get bigger
Speaker 1: and bigger, something that was truly scalable. One of the
Speaker 1: people working on this was a guy named Robert Kahn,
Speaker 1: one of the fathers of the Internet. You often hear
Speaker 1: about him and his buddy Vents Surf, who together would
Speaker 1: create TCP. So Robert Kahn comes on over to DARPA
Speaker 1: and he's part of the I P. T O Department.
Speaker 1: That's the department that's in charge of creating networks and
Speaker 1: that sort of thing. He specifically wanted to replace an
Speaker 1: earlier set of rules, an earlier protocol called the Network
Speaker 1: Control Program or in c P. And the reason for
Speaker 1: that gets a little technical, but I figure we can
Speaker 1: go a bit further than just it doesn't scale well,
Speaker 1: because that doesn't really tell you much. So for just
Speaker 1: a second, let's talk about what con was envisioning back
Speaker 1: in the early nineteen seventies. He wanted a protocol that
Speaker 1: was going to do certain things. He felt that a
Speaker 1: computer scientists had connected these distant computers together using the
Speaker 1: telephone system that created the first wide area network, but
Speaker 1: that was not going to be sustainable on a broader scale.
Speaker 1: He knew that the key component of the network technology
Speaker 1: at our ponet was the Interface Message Processor or i
Speaker 1: MP and MP and an MP is kind of like
Speaker 1: a router. It was a packet switching node that would
Speaker 1: serve as a connection between different computers on our bonnet.
Speaker 1: In addition to imps, the team on our Bonnet was
Speaker 1: working on a host to host protocol which would become
Speaker 1: the network control protocol, and developers began to create applications
Speaker 1: to run on those networks like email and con would
Speaker 1: demonstrate even a twenty node large network in nineteen seventy two,
Speaker 1: so a network consisting of twenty computers. Khan was also
Speaker 1: working on technology for a packet radio network that would
Speaker 1: actually use radio waves to send data back and forth
Speaker 1: across different computers, and that was going to use packet
Speaker 1: switching specifically because radio is tricky stuff. If a signal
Speaker 1: were lost or jammed, then the information that was being
Speaker 1: sent across the network would be lost and you'd end
Speaker 1: up with miscommunications and failures, so you had to have
Speaker 1: a way to deal with this. Originally, Khan had intended
Speaker 1: to develop a protocol specifically for radio packet networks to
Speaker 1: have the sort of error correction mechanism in there, a
Speaker 1: way of guaranteeing that the information from one system would
Speaker 1: get to another, and then this network would be able
Speaker 1: to interface with other networks like arpanet, using the already
Speaker 1: established in CP as a transport layer. But there was
Speaker 1: a big problem. N c P could only address networks
Speaker 1: and machines down to the imp level. N CP would
Speaker 1: rely upon our bonnet itself for end to end reliability,
Speaker 1: so it worked just fine if you were in our
Speaker 1: pannet if your machine was directly connected into that network,
Speaker 1: But if you wanted to interconnect the arpanet network with
Speaker 1: another network, something had to change because n c P
Speaker 1: could not handle identifying and responding to errors and delivering
Speaker 1: information to the computers that were outside of our bannet.
Speaker 1: N CP just didn't have that capability. Arpanet handled everything
Speaker 1: within the network, but it didn't have anything designed to
Speaker 1: handle stuff from outside that network. So at first Kahn
Speaker 1: had planned to only work on the packet radio networks
Speaker 1: and just concentrate on that, but ultimately his quest to
Speaker 1: create a protocol that could ensure message is were arriving
Speaker 1: at their destinations across different networks, expanded beyond just the
Speaker 1: packet radio application. So Cohn wanted an open network architecture,
Speaker 1: something that would allow any sort of networked system to
Speaker 1: interconnect with another and still have rules in place to
Speaker 1: ensure that the data was getting to where it needed
Speaker 1: to go. So Robert Kahn and vent Surf were two
Speaker 1: computer scientists who were working on this. They were the
Speaker 1: authors of these protocols. Vent Surf had been one of
Speaker 1: the people to create in CP well fun fact, by
Speaker 1: the way, TCP did not originally stand for Transmission control
Speaker 1: Protocol back when con and Surf first proposed it. Instead,
Speaker 1: it stood for Transmission Control Program, and that's a subtle difference,
Speaker 1: to be sure. They wrote the first version of TCP
Speaker 1: in ninety three, and they published a fully documented and
Speaker 1: revised version in four under RFC six. It was specifically
Speaker 1: titled Specification of Internet Transmission Control Program. Not long after
Speaker 1: the initial creation, other folks began to realize that it
Speaker 1: might be a better idea to break out the functions
Speaker 1: of t c P into two sets of protocols, and
Speaker 1: that's where we get t c P I P. Because, again,
Speaker 1: before it was all lumped together, and then they figured
Speaker 1: this would make more sense if we separated them out
Speaker 1: into two sets of rules. The creation of t C
Speaker 1: P I P predates the Open Systems Interconnection or O
Speaker 1: S I layer model. And I've talked about the O
Speaker 1: SI model in a past episode of tech Stuff. But
Speaker 1: the O SI model describes how different parts of a
Speaker 1: telecommunications or computer system communicate with one another. They have
Speaker 1: layers to describe the different functions. But T C P
Speaker 1: I P layers are are pretty similar to O SI layers,
Speaker 1: so we can we can talk about the two as
Speaker 1: being at least somewhat analogous. It's an abstract idea that's
Speaker 1: meant to describe how each layer fits within a grand scheme.
Speaker 1: So layers that are near the bottom of the stack
Speaker 1: support all the layers that are on top of it.
Speaker 1: Layers at the top do not necessarily support any other layers.
Speaker 1: They rely on the ones below them, but they don't
Speaker 1: support anything any layers above them. And again this is
Speaker 1: an abstraction. There are not actual literal layers in these systems,
Speaker 1: but within this framework, you could say TCP would be
Speaker 1: on layer four. That would be the transport layer. The
Speaker 1: Internet protocol is one layer further down. It's on layer three,
Speaker 1: meaning it is a little closer to the basic hardware
Speaker 1: layer of the system. That's the lowest layer is the hardware,
Speaker 1: and that uh means that the i P protocol supports
Speaker 1: the TCP protocols above it and above TCP are the
Speaker 1: application layers where you have stuff like file Transfer Protocol,
Speaker 1: email and h T t P. Those are all on
Speaker 1: top of it. I've got more to say about what
Speaker 1: TCP is and what it does in just a moment,
Speaker 1: but first let's take a quick break to thank our sponsor.
Speaker 1: So when laying out the rules for TCP, bob con
Speaker 1: had a few requirements and this is from the Internet
Speaker 1: Society's page on the History of the Internet, and they
Speaker 1: were each distinct network would have to stand on its
Speaker 1: own and no internal changes should be required to any
Speaker 1: such network to connect it to the Internet. Next, communications
Speaker 1: would be on a best effort basis, so if a
Speaker 1: packet did not make it to the final destination, it
Speaker 1: would shortly be retransmitted from the source. So this is
Speaker 1: the error correction part. A packet on its way to
Speaker 1: computer B never makes it, then computer A will retransmit
Speaker 1: that same packet black boxes would be used to connect
Speaker 1: these networks. These would later be called gateways and routers,
Speaker 1: and there would be no information retained by the gateways
Speaker 1: about the individual flows of packets passing through them, thereby
Speaker 1: just keeping them very simple and avoiding complicated adaptation and
Speaker 1: recovery from various failure modes. So they were really just
Speaker 1: a means of controlling traffic flow, but not monitoring traffic flow,
Speaker 1: and there would be no global control at the operations level.
Speaker 1: Those were his requirements. Those would develop into more granular
Speaker 1: requirements as the work would continue on the protocols. And
Speaker 1: Vince Surf did a really really good explanation about how
Speaker 1: TCP works in a short video, and he used a
Speaker 1: postcard analogy, and I highly recommend checking it out because
Speaker 1: he just puts it very simply. I'm gonna kind of
Speaker 1: paraphrase what he said here. He compared TCP to sending
Speaker 1: a book to a friend, and you're using the postal service,
Speaker 1: except your postal service is very peculiar. They will not
Speaker 1: carry anything other than postcards. So you cannot actually send
Speaker 1: the physical book as is to your friend because the
Speaker 1: post office is not gonna carry that. So what you
Speaker 1: have to do is cut your book up so that
Speaker 1: you can fit maybe about half a page on a postcard,
Speaker 1: and then you can send that postcard through the mail,
Speaker 1: and then you have to send all of the book
Speaker 1: in a series of postcards to your friend. But then
Speaker 1: you realize, hey, wait, because of the way I have
Speaker 1: to cut up this book, sometimes there's no indication there
Speaker 1: about a page number, so there's no way of knowing
Speaker 1: just on the page where this page fits in relation
Speaker 1: to the rest of the book. So then you number
Speaker 1: every single postcard, and that way your friend knows what
Speaker 1: order they go in, they know the sequence, so there's
Speaker 1: no guarantee that any one postcard will actually make it
Speaker 1: all the way through. There's also no guarantee your friend
Speaker 1: will receive the postcards in the same order that you
Speaker 1: sent them. But by numbering, your friend will know which
Speaker 1: postcards they have received. So if they get postcard number
Speaker 1: eighty three but they didn't get postcard number A D two,
Speaker 1: they can send you a message alerting you that they
Speaker 1: are missing one, and you can read, transmit or re send,
Speaker 1: so your friend can send a postcard back to you.
Speaker 1: Essentially says, hey, I got all the postcards up to
Speaker 1: number eighty two or whatever. But that's it, and this
Speaker 1: would let you know that you need to resend those postcards,
Speaker 1: which means you have to keep a copy of the
Speaker 1: postcards you've submitted. You can't just send your only copy
Speaker 1: because you'd be up the creek if your buddy says, hey,
Speaker 1: I didn't get that, and if nothing comes back to you,
Speaker 1: if your friend never says, oh, I received everything, then
Speaker 1: you would have to start re sending postcards until you
Speaker 1: finally got a message that says, hey, a toad, scut
Speaker 1: all the postcards, thank you, I'm going to read the
Speaker 1: book now, or whatever it might be. But that's how
Speaker 1: TCP works. But instead of it being you know, physical postcards,
Speaker 1: we're talking digital information. There's never a guarantee that the
Speaker 1: information you send is actually going to get to your
Speaker 1: destination or that will all arrive sequentially. But these safeguards
Speaker 1: mean that your computer will know when to send stuff
Speaker 1: again to guarantee transmission. The United States Department of Defense
Speaker 1: adopted TCP i P as a standard in nineteen eighty.
Speaker 1: DARPA was able to change over in advance of everyone else,
Speaker 1: which allowed for partitioning of the military networks from non
Speaker 1: military networks, and that would carry forward, so you have
Speaker 1: mill net that's its own separate network that's based on
Speaker 1: essentially the same architecture as the general Internet. T c
Speaker 1: P i P would become the official transport layer for
Speaker 1: ar PONNETT on January one, nine three. This was called
Speaker 1: a flag day. Now, that is an event that involves
Speaker 1: incorporating a critical change in a very large system UH
Speaker 1: in a simultaneous way, like it has to change throughout
Speaker 1: the system the same time, UH, and that is really
Speaker 1: tricky to do. The bigger the system, obviously, the harder
Speaker 1: it is for you to make a global change all
Speaker 1: at the same time. The transition had been planned out
Speaker 1: for years in advance because this would require network administrators
Speaker 1: to change over to the t c P i P
Speaker 1: protocol all at the same time, and surprisingly it went
Speaker 1: off without any really major problems, So that's pretty cool.
Speaker 1: By the mid nineteen eighties, the Internet was an established thing,
Speaker 1: though really only a relatively small number of people were
Speaker 1: aware of it. If you worked at DARPA, or if
Speaker 1: you were at a university with a really good computer
Speaker 1: science curriculum, or maybe you worked in a research facility,
Speaker 1: or maybe you were in the military, then you might
Speaker 1: know about it. A few other government offices also were
Speaker 1: on the early Internet, but apart from that and a
Speaker 1: few major businesses, it was largely a thing of mystery.
Speaker 1: The general public was pretty much ignorant of the Internet
Speaker 1: for almost a decade. It wouldn't be until the emergence
Speaker 1: of the World Wide Web that more people would become
Speaker 1: aware of the Internet, and in fact, at that point,
Speaker 1: the Worldwide Web and the Internet would often be confused
Speaker 1: as meaning the same thing for a lot of people.
Speaker 1: A lot of people would refer to the Worldwide Web
Speaker 1: as the Internet, not realizing that really the world Wide
Speaker 1: Web is one application built on top of the Internet,
Speaker 1: it is not itself the Internet. In the early nineties, uh,
Speaker 1: speaking of the Web, a guy named Tim berners Lee,
Speaker 1: he was working for a little scientific research organization called CERN,
Speaker 1: had a bright idea. And his idea was for an
Speaker 1: application protocol on top of the Internet that would facilitate
Speaker 1: communications between client computers and server computers, including file transfers
Speaker 1: and the ability for a sir her to refer a
Speaker 1: client to a different server. And that would be the
Speaker 1: foundation for the Worldwide Web. And just in case you
Speaker 1: didn't pick up on my stupid joke. CERN is not
Speaker 1: a little scientific research organization. It's the European Organization for
Speaker 1: Nuclear Research and it is a huge, huge deal. Among
Speaker 1: the many things it does is oversee the large Hadron collider,
Speaker 1: so big, big organization. Ultimately, the purpose of h t
Speaker 1: t P, which was created by Tim berners Lee, was
Speaker 1: to create a means of linking different documents together through
Speaker 1: what is called hypertext. And you've seen these. These are
Speaker 1: those highlighted words and web pages, and when you click
Speaker 1: on it, you go to a different web page. And
Speaker 1: that's the whole point is clicking on hypertext sends a
Speaker 1: command to navigate to a new page. And because the
Speaker 1: rules for h T t P allow for one server
Speaker 1: to refer a client to another server, those two web
Speaker 1: pages don't have a quote unquote live on the same
Speaker 1: server together. So we're talking about the very basic foundation
Speaker 1: of how the Worldwide Web works with the interlinking documents
Speaker 1: that allow you to hop from one page or one
Speaker 1: site to another. The features of HTTP version zero point nine,
Speaker 1: which was the first one released to the public, included
Speaker 1: the following clients Server Request Response Protocol as key protocol
Speaker 1: running over a t C p I P link. It
Speaker 1: was designed to transfer hypertext documents or h t m
Speaker 1: L and the connection between server and client is closed
Speaker 1: after every request. And that's it. It was bare bones stuff,
Speaker 1: but this was the beginning of something truly transformational. In fact,
Speaker 1: I could honestly say I would not have the career
Speaker 1: I have without this invention. So from the h t
Speaker 1: t P standard of pretty quickly, Tim burns Lee had
Speaker 1: set the stage, and then a team at the National
Speaker 1: Center of Supercomputing Applications or in c s A made
Speaker 1: the first popular web browser called Mosaic. One of the
Speaker 1: programmers on that team was a guy named Mark Andreason,
Speaker 1: who went on to co found the Mosaic Corporation and
Speaker 1: eventually publish a new browser called Netscape. Now, at that
Speaker 1: same time, the Internet Engineering Task Force was organizing a
Speaker 1: team called the ht t P Working Group dedicated to
Speaker 1: improving this HTTP protocol, and it was quickly developing in
Speaker 1: several different directions. And by that I mean a lot
Speaker 1: of different people had started by taking the version zero
Speaker 1: point nine h t t P and then tweaking it
Speaker 1: independently of each other. So it's evolving in different directions simultaneously.
Speaker 1: So while there's a shorthand that refers to h t
Speaker 1: t P one point oh. There is not an actual
Speaker 1: standard one point oh. There were many quote unquote flavors
Speaker 1: of one point oh because there were so many different
Speaker 1: variations on that, the I E. T F Working Group
Speaker 1: would publish a standard for HTTP Protocol version one point
Speaker 1: one under RFC two zero six eight if you want
Speaker 1: to read it. It's a little technical, but this version
Speaker 1: would be tweaked and updated before it was officially released.
Speaker 1: In Version two point oh of h T t P
Speaker 1: wouldn't come out until two thousand fifteen. That is a
Speaker 1: long time between versions one point one came out in
Speaker 1: two point oh and two thousand fifteen, and only about
Speaker 1: a third of all websites in the world today support
Speaker 1: version two point oh as the standard. Most websites are
Speaker 1: still using one point oh or one point one, So
Speaker 1: it may come as something of a surprise to hear
Speaker 1: that h T t P three point oh is right
Speaker 1: around the corner when not even a majority of sites
Speaker 1: are on the most recent version of two point oh,
Speaker 1: and perhaps an even bigger surprises that, unlike the earlier versions,
Speaker 1: this h T t P protocol will not rely upon
Speaker 1: t c P. I'll explain more in just a second,
Speaker 1: but first let's take another quick break to thank our sponsor. Okay,
Speaker 1: So why would h T t P three point oh
Speaker 1: ditch TCP, which has been a part of the framework
Speaker 1: of the Internet since the very beginning, since before there
Speaker 1: was an Internet. Well, it mostly comes down to two
Speaker 1: big things, speed and efficiency. So when Robert Cohn and
Speaker 1: when vent surf we're working on TCP, they were building
Speaker 1: out a protocol to handle any sort of application that
Speaker 1: would be built on top of what was to become
Speaker 1: the Internet. So and it has a very much a
Speaker 1: one size fits all kind of approach to that it
Speaker 1: provided useful or really I mean, at this point I
Speaker 1: should just say necessary set of features to facilitate communication.
Speaker 1: But some of those are excessive or not as pertinent
Speaker 1: to the types of traffic that happened over h T
Speaker 1: t P, or they impede some of the functions that
Speaker 1: htt P handles. For example, in an effort to establish
Speaker 1: a connection between a client and a server, TCP requires
Speaker 1: a number of back and forth messages, essentially saying, hey
Speaker 1: over there, services, Yeah, what is it? Client says, I
Speaker 1: want to talk to you? The services all right? Hang
Speaker 1: on a second, and the computer says now, good time,
Speaker 1: and the services yeah, yeah, let's go ahead and do that.
Speaker 1: It's far more technical than that, but there's this series
Speaker 1: that goes back and forth in order for a communication
Speaker 1: channel to be established between client and server. That gets
Speaker 1: even more complicated if you want to have an encrypted
Speaker 1: connection over Secure socket Layer or s s L using
Speaker 1: a website. So you know the little lock that you
Speaker 1: see in the address bar when you visit a secure website,
Speaker 1: that's part of s SL. Well, to establish that kind
Speaker 1: of connection between your computer or your computer's browser, which
Speaker 1: is the client, and the server which houses the website
Speaker 1: you're visiting to, it requires even more round trips between
Speaker 1: the two to first establish the connectivity and then established
Speaker 1: the encrypted communications. So the process is good for making
Speaker 1: sure that there is an actual route for data to follow,
Speaker 1: but it's not the most straightforward approach if you want
Speaker 1: to use HTTP, particularly if you want to use encrypted connections.
Speaker 1: There is another protocol, however, called User Data Gram Protocol
Speaker 1: or u d P, and that can serve as the
Speaker 1: foundation for a new transport layer for h T t
Speaker 1: P three point oh. U d P has a big
Speaker 1: advantage over TCP. It is incredibly simple and it is
Speaker 1: incredibly fast. It is a transport layer protocol just like TCP,
Speaker 1: but unlike TCP, u DP does not have the same
Speaker 1: features to ensure communications are established or successful, so that
Speaker 1: could be a big drawback. Right. U DP transmissions are unordered,
Speaker 1: so a later message can arrive ahead of an earlier one,
Speaker 1: and that can be very confusing if you haven't built
Speaker 1: in a way of dealing with that. There's also no
Speaker 1: means for the receiving computer to know if something has
Speaker 1: gone wrong, if packets go missing, like it doesn't know
Speaker 1: if doesn't have all the different pieces, if it's just
Speaker 1: over pure U d P. But U d P can
Speaker 1: act as a base to build upon. It doesn't have
Speaker 1: to be uh. The protocols don't have to be the
Speaker 1: end all be all. That's your starting point. So Google
Speaker 1: has taken you U d P as its starting point
Speaker 1: and built upon it to create an experimental network protocol
Speaker 1: called q U I C for Quick U d P
Speaker 1: Internet Connections. The I E t F has taken this
Speaker 1: experimental protocol and worked on creating a standardized version, which
Speaker 1: in some ways has moved away from what Google's initial
Speaker 1: design was all about, But the writing is on the
Speaker 1: wall for t c P as far as the h
Speaker 1: t t P standard is concerned. Moving forward, the transport
Speaker 1: layer that was initially published in the nineteen seventies is
Speaker 1: going to have to make way for a lighter, more agile,
Speaker 1: and less cumbersome standard. In addition to the move away
Speaker 1: from t c P, the new version of h T
Speaker 1: t P will be more secure. QUICK, as designed by Google,
Speaker 1: transports data by encrypting it by default, is not the
Speaker 1: added layer on top of everything. It is the default layer.
Speaker 1: Google's build, which is sometimes called h t t P
Speaker 1: over QUICK, is supported in the latest versions of Google
Speaker 1: Chrome and in the Opera web browser. Right now, only
Speaker 1: a few websites actually make use of it, most of
Speaker 1: them belong to Google, though Facebook has also been incorporating it.
Speaker 1: It's going to be a really long path to travel
Speaker 1: to get widespread adoption because right now less than two
Speaker 1: percent of all websites support QUICK. Meanwhile, TCP will still
Speaker 1: be in use. Just because it's being phased out of
Speaker 1: future versions of h T t P does not mean
Speaker 1: that this protocol is completely obsolete. As I mentioned earlier
Speaker 1: in this episode, the Worldwide Web is just one implication
Speaker 1: on top of the Internet, there are lots of others
Speaker 1: that will still make use of that venerable set of rules,
Speaker 1: and some websites may never move off of it, since
Speaker 1: it requires work to make the transition, and let's be honest,
Speaker 1: it's not always the highest priority for some businesses that
Speaker 1: maintain websites out there. But it is interesting to me
Speaker 1: to see this move away from TCP. I have always
Speaker 1: associated TCP as being a truly integral part of the Internet,
Speaker 1: and it still will be. It just won't necessarily be
Speaker 1: as integral to web browsing as it used to be.
Speaker 1: Fascinating stuff to me. I hope you guys enjoyed this episode.
Speaker 1: I know it got a little more uh techie with
Speaker 1: the protocols than usual, but I thought this was a
Speaker 1: big deal and one that maybe, probably I'm guessing, is
Speaker 1: not going to get widely reported outside of tech news circles.
Speaker 1: I doubt that you're gonna, you know, turn on the
Speaker 1: local news and some anchor is going to say and
Speaker 1: another news, the Worldwide Web is moving away from this
Speaker 1: ancient set of rules. I just don't see that making
Speaker 1: the news, but it is important anyway. If you guys
Speaker 1: have any suggestions for future episodes of tech Stuff. Maybe
Speaker 1: it's a technology, a company, a person in tech. Maybe
Speaker 1: there's someone you would want me to talk with about technology.
Speaker 1: You should send me those thoughts. You can email the
Speaker 1: show it is tech Stuff at how stuff works dot com,
Speaker 1: or you can go to our website that's text Stuff
Speaker 1: podcast dot com and you can find other ways to
Speaker 1: contact me there. Don't forget to head on over to
Speaker 1: our merchandise store that's at t public dot com slash
Speaker 1: tech Stuff. Everything you purchased there goes to benefit the show.
Speaker 1: We greatly appreciate that, and there's some pretty cool things
Speaker 1: over there. If you haven't checked it out, go see
Speaker 1: if there are any designs that you particularly like. And oh,
Speaker 1: remember we've been nominated in the Science and Technology category
Speaker 1: of the I Heart Radio Podcast Awards. You can head
Speaker 1: on over to the website for the I Heart Radio
Speaker 1: Podcast Awards and vote up to five times a day.
Speaker 1: You can dedicate all five of those votes to tech
Speaker 1: Stuff if that is your desire. But whatever you want
Speaker 1: to do, you should go check out all of those
Speaker 1: different categories see if there are any other shows you
Speaker 1: really like. Maybe you can discover some shows you didn't
Speaker 1: even know existed. I always love finding new podcasts. This
Speaker 1: is a great way of finding some really high quality ones,
Speaker 1: and I'll talk to you again really soon for more
Speaker 1: on this and thousands of other topics, because it how
Speaker 1: stuff works. Dot com