 Welcome back to the Cyber Underground, and I cannot say, this is Dave, the Cyber Guy. Sorry, the title is taken by somebody else. My sad news to everybody out there, I have to relinquish my title because somebody else has claimed it, and he has the domain, the Cyber Guy. So cyberguy.com out there is Kurt Knudsen, and I only found out about this because I must profess I watch all news stations to try to get a good idea of what's going on out there, and I actually stumbled across Fox News, and he was a cyber consultant on Fox News. With me today, I have Hal, who still retains the title, the Networking Guy. Thank you for being on the show. Thanks for having me back again. Thanks, brother. All right, so the audience should be reminded we work for the University of Hawaii, Kapilani Community College. You teach networking and cybersecurity, so do I, and we have a great time with it, and that's why we have this show, and hopefully we entertain and inform at the same time and keep people safe, and today we're going to talk about how the Internet has evolved and a big piece of its evolution is coming up again. And of course, Google's right out in front, right? So first of all, we have to ask our audience out there, please come up with a new title for me because I cannot be the Cyber Guy, so I need to be something. Be nice. Okay. I can only imagine the responses now. How about Cyberman? Cyberman. Someone's going to call me the tick or something. Just be nice. When you give me, I don't want a porn name, by the way, I just need a cyber name. So for now, just Dave. Let's talk about, I got some notes here about Google and their new implementation for HTTP3. HTTP3 is what the Internet Engineering Task Force, the IETF is going to call it, but Google called it Quick, Quick UDP Internet Connection, which is great, but they've come up with other implementations. So let's talk about what HTTP is and how it works and why we care, and then let's talk about what's going to happen now. So help me out. With HTTP, people take it for granted. We just open a browser and type in Amazon.com, we go to Amazon, and everything just kind of works. It's this ubiquitous, magical process now that we don't have to think about, but in days of old, 1989, you popped up in AOL, you didn't have just HTTP. There was Gopher and Waze and all these other protocols, and we just finally standardized on HTTP. Why do we do that? What was the benefit? What did we get out of HTTP over TCP, and what is it? Well, HTTP is the protocol that runs the web. So that web browsers used to talk to web servers, and web servers used to send web content back to web browsers. And I guess it evolved from those other protocols because some of those other protocols had different purposes. There were more for file transfer or text-based content, and HTTP evolved to support multimedia. You can have video content, audio content, dynamic web content. It's come a long ways from just the first web pages, which were just kind of black and white text, and not very exciting. It's become a lot more exciting now. There was more informational than participation. More multimedia, more interactive, and so that's how HTTP kind of developed from those other protocols, and it continues to develop. We've had different versions, but underneath the actual web layer, there's what we call a transport layer. So there are these protocols that manage the connection between the two endpoints, in the browser that you're working with, and the web server that you're actually talking to across the internet. So protocol is like a common language between two systems. So you both know what that language means. I send you some data, and you know what it means, because we're both on the same protocol. Yeah. So it's like if you were speaking Mandarin Chinese, and I was speaking Swedish, neither one of us would understand each other. We have to be speaking the same language or the same protocol. So this is just, it's the set of rules of how do we talk to each other. So HTTP sets up the rules for web browsers to talk to web servers, and these transport protocols set up the rules for how your computer actually talks to the servers and how those connections are managed. And there are two main protocols, transport protocols at this layer, TCP, which is transport control protocol, and UDP, which is user data gram protocol. And they really, why do we have two? Well, they were designed for different purposes. So one's connection, and one's connection less. One's connection oriented, that's TCP. And the other is connection less, as you said, that's UDP. So TCP was designed to guarantee every single bit of data was going to be guaranteed to be delivered and received. So it does all these extra steps. It has the client do a handshake with the server before any data is transferred to make sure that they're both connected on both ends. So if I'm a client in your server, I'm a browser and a PC and I'm browsing amazon.com. The first thing we have to do is I send out a signal, hey, I'd like some information. You say, yes, I'm here, and I respond, OK, I got that signal. So now we have a three-way handshake. So now we have a connection. SIN, SINAC, and AC, right? Exactly. After that's done, and that takes a lot of effort, right? There's a lot that goes into that. There's a lot of little flags, a lot of built bits. We send data in packets in TCP, right? So we chunk up the data. So if you have a bunch of data, you put into pieces, basically, right? And you give each one a sequence number. And the reason is because over the internet, you might not have a direct connection. Sometimes you take alternate routes, and each router and each waypoint or hop, as they say, is going to reroute you on the most efficient path it sees at the time. And maybe I'm on my phone, and I'm switching from mobile network to Wi-Fi back. So it's not always the same connection, as you said. So that's why you have the sewage numbers. So as things arrive, you know how they fit together. Because as you said, they may not always come over the exact same path. Right, right. So that's all built into TCP. We have the sequence numbers. We have some security features built in there. And it's a complicated system. It takes what's called a lot of overhead. There's a lot of extra, besides the data that I'm sending you. I have to send a lot more data to make sure this all happens. There's an acknowledgement. Every piece of data you send me, I send you an acknowledgement. So there's a lot of back and forth, back and forth data. And if you drop one, I'll send it again. Yeah, absolutely. But that absolutely guarantees that every single bit is received on the other end. So it's what we call the reliable protocol, and that delivery is guaranteed. It's like sending a letter with a post office with that little green card that comes back to you to acknowledge, yes, it was received. Signed by someone, and it's guaranteed. UDP is the opposite. UDP, you just send the data, and I hope it got there. Fire and forget. I assume it did. But I'll never know for sure, because I don't get any kind of acknowledgement. So why do we have these two different schemes? Well, the rationale has always been that if you're transferring a file, you need every single bit. If you lose one bit, the whole file's corrupt, and it's not going to do any good. Like a Word document, or an EXE executable file, or something in FTP, a zip file, you don't get the whole thing. It's corrupt, and it's useless. It's useless without every single bit. So for those kind of things, we always use TCP. But if you're viewing, say, a live stream of the surfer Waikiki or something, it's very time-sensitive. So if you should lose a few packets and ask them to be re-send later by the time they get to you, you're already past that point in the stream. It's not going to do any good. So why bother with all that re-sending and acknowledgment? Just send it. You can send more raw data because you're not sending all of these acknowledgments and handshakes. So we'll just send as much raw data as we can and hope for the best that it gets there. Now, gamers use UDP quite a bit. All the time, yeah. Gamers will know because when they hook up their Xbox or their PS3 or whatever system they're using, and they want to do internet gaming, what they have to do is they have to open up ports on their router, TCP and UDP ports, and arrange so you can stream both kinds of data. You can get the files that you really want to all be there at the time. And you also have streaming media and gaming stuff that, like you said, once you pass that certain point in time, no use going back. You just got to keep going forward. So you might see a little hazy, a little pixelated, get a little glitch. For the most part, you get a fade. But then when the stream is back, you just go forward the best you can. Yeah, that's where we get music too, right? Driving in a car, I got streaming music going on, Spotify, Apple Music. That's UDP. Yeah, okay. Any type of streaming like that is almost always over UDP. So TCP, we built HTTP on top of that. So the beauty of HTTP.9 when it came out was like not even 1.0. The beauty of it was it was a single ASCII line for the request. You just sent some ASCII text out and what you got back was HTML. Well, that's Hypertext Markup Language. And that's the meta-based language or the tag-based language that gets interpreted by the browser. And just to take a little pause here, for everybody out there that doesn't know about web programming, programming for the internet is probably the most difficult programming you can do because it's never just one language. HTML, you have cascading style sheets, you have JavaScript, you have a server-side scripting language like PHP or ASP.NET or JSP. And these things can add up to a lot of work. And then on top of that, JavaScript has multiple frameworks, right? We have the Google APIs that came out. We have what is it? JQuery. JQuery is a framework of JavaScript libraries. And you have to be able to put all those in your file to be interpreted by the web browser. Now the web browser interprets this thing on the fly. Top down left to right reads it raw and will display it as that browser is supposed to display it. That's why if I look at the same amazon.com webpage on multiple browsers, I'm going to see a little bit different web page on each browser, right? There's going to be slightly different colors, slightly different behavior. Things will be in the different places just a little bit because we're all pretty much on the same standard, but everyone does it a little bit differently. And there's always a little flexibility in those standards. So Microsoft Edge might do it slightly different than the way that Mozilla Firefox did it, but they're still hopefully adhering to the standards. They're just maybe using a little flexibility with it. And Microsoft does that more than anybody. They're masters of, we're going to do it differently. I remember, especially our friend Steve, teaches web programming. And he's going to have to teach his students when you're writing JavaScript, you have to allow for different browsers. If you're in Firefox, do this. If you're in IE, do this. And it's a different line of code, but to do the same thing depending on a browser. This is why when I was a web developer back in the day, I used to have to test everything on three or four or five different times. I had to test every page on every single browser to see if it wasn't enough just to try it on Internet Explorer. And okay, it works then, so I assume it's going to work everywhere else. They have to try it on all the different browsers and make sure that it works on all of them. And multiple versions. And sometimes multiple versions as well. Yeah, because as we know, every time, I'm going to pick a Microsoft. Every time Microsoft comes out with a new Internet Explorer, it's major. The difference between 6 and 7, 7, 8, 8, 9 was tremendous. You got many more features and it was interpreted completely different. So I had, you know, I opened up Opera and Firefox and Chrome and multiple versions of each. And now we have Edge to add on top of that. So when you're a web programmer, it's almost a full-time job just testing your stuff. It's pretty terrible. But HTTP allowed us to be able to transmit this and make this a ubiquitous protocol across the entire Internet, right? So we got the chance to start doing things like cascading style sheets, which is making all the graphics move and be where they want and give us some dynamic behavior. And you could use an interactive kind of website now with HTTP rather than just the raw, you know, just text-based stuff. And streams embedded within webpages. You can have video streams, audio streams, all kinds of things. So the assumption up to this point has always been, oh, a web page is like a file, so we should use TCP. But now Google is trying to say, well, wait a second. A web page, I'm streaming all kinds of different pieces of this web page. Is it really a file and should it really be on TCP or can we do this better and more efficiently by trying to treat it as a stream? Because not everything is mission critical. Not everything is critical to get it across. You can try again, and it's not going to fail on you. Okay, let's take a little break. We're going to pay some bills. Be right back, everybody, until then, stay safe. I'm Jay Feidell, ThinkTech. ThinkTech loves energy. I'm the host of Mina, Marco, and me, which is Mina Morita, former chair of the PUC, former legislator, and Energy Dynamics, a consulting organization in energy. Marco Mangelsdorf is the CEO of Provision Solar in Hilo. Every two weeks, we talk about energy, everything about energy. Come around and watch us. We're on at noon on Mondays every two weeks on ThinkTech. Aloha. Hey, Stan the Energyman here on ThinkTech Hawaii. And they won't let me do political commentary. So I'm stuck doing energy stuff, but I really like energy stuff. So I'm going to keep on doing it. So join me every Friday on Stan the Energyman at lunchtime, at noon on my lunch hour, we're going to talk about everything energy, especially if it begins with the word hydrogen. We're going to definitely be talking about it. We'll talk about how we can make Hawaii cleaner, how we can make the world a better place, just basically save the planet. Even Miss America can't even talk about stuff like that anymore. We got it nailed down here. So we'll see you on Friday at noon with Stan the Energyman. Aloha. Welcome back to our exciting episode of the Cyber Underground. I'm Dave, no longer the cyber guy needing a nickname. Help me out. I'm with Hal, the networking guy, and we're talking about Google's new implementation of the next HTTP version. They call it Quick. It's now going to be called HTTP 3. We've gone through one and two. And Stanley Google was also responsible for HTTP 2 as well. And actually, it didn't get finalized until just a couple of years ago. So we're not only advancing, but we're speeding up how fast we advance. So kind of overlapping. Yeah, and we get that asymptotic curve of technology just launching into the stratosphere now. I think Moore actually predicted this. Moore's Law, we're going to go faster and faster and faster until we have this little feedback loop of all the technology making everything faster. And I think we're approaching that rapidly. Just so you know, the cyber guy that I saw on Fox was actually pretty good. Cyberguy.com, I saw some of his articles in there. And we should actually have a show on what he was discussing, because he was discussing Alexa. And with this new Google protocol, I believe Alexa's going to be even more of a danger to our privacy. So they're recording everything that gets said at all times, wherever Alexa's got a microphone handy. Listening for you to give commands. But recording everything you say, even in the background, and uploading everything to the servers at Google. And they do language protocol arrangements. So you could do AI and interpret what's going on in the background and help get language interpretation better for Google. So it's helping us improve speech recognition. On the other hand, everything you say is now stored at Google, which that's scary. So we should do a show on that. And it's less of a problem now with Google's new HTTP 3, because we're going to put everything over UDP, which we just discussed. And once that happens, we increase the bandwidth availability and speed of the internet by about 30%. So let's talk about HTTP 1 again, what it did for us, and then when we moved to 2 about that. So HTTP 1, I remember this in the late 90s, they finally came out with an internet standard. But we've been programming for the web for five, six years. Yahoo came out in 1994. And Netscape did its IPO in 95. And this HTTP 1.1, I think, came out in 1999. It was a long time after we'd started this stuff. And I remember what it relief it was to think, oh, thank god, we've got a standard. And then almost nobody stuck with it. Microsoft went on its own path. But it actually helped a little bit, I think. And with the next implementation that was almost a decade away, we increased the speed of the internet with a host of different things. We got better routers. We got fiber optic connections now. And just so our audience knows, and I'm not telling you anything new, but we were one of the first people, we were the first country internet to have the internet. So we had old copper wire everywhere. When the other countries, like in Europe, first adopted the internet, they did it in the late 90s or even in the early 2000s. And some of them went straight to fiber optic, which was an amazing speed increase over what we had over here. And we've slowly been trying to upgrade our infrastructure. But as we know, infrastructure is hard to upgrade in the United States. Yeah, we have all of this legacy telephone network. And so naturally, the telecom giants want to leverage that, and not just rip it all out and put it in fiber. But any new installations anywhere are definitely fiber at this point, with slowly moving off of the copper. So it's not just the protocols and the program that it makes everything faster. It's also the infrastructure. It's also the way we move data. It's also switching technologies getting better every day. So there's many things driving this, but Google has actually added a lot to this. And they added in about 2009, this came out with another thing called SPDY or speedy, which became HTTP2. And sped up the internet, most estimates are like 50%. And I think that's amazing to look back at 2009. What were we doing in 2009 that became faster? For me, it was things like Netflix. Yeah, there's much more video streaming now than there was even a few years ago. So the things we're sending over HTTP now, used to be pretty much text, and it was images. But now it's all kinds of streaming video, streaming audio, all kinds of dynamic content. It's really changed. So I mean, you understand where Google's coming from saying, the web isn't what the web used to be, and maybe it needs a new protocol to allow it to work more efficiently, given what kind of things we're sending over HTTP now, as opposed to what we did. I can see that in the first decade of this millennium, we had a huge shift to more mobile computing, a lot more file transfers, much more mobile gaming, and internet gaming, and a ton more streaming. And I know that in the 90s, it was mostly adult content, let's just say. It was driving the need for more bandwidth. And many people pushed that, and were very emphatic about, we need more bandwidth. And when they looked into it, it was adult content. But starting this millennium, that shifted. Now, we still have a lot of adult content out there, because let's face it, these guys are pretty sick. But we also have a ton of internet gaming, and an enormous amount of streaming video and music. We've just all gone to Spotify, and Netflix, and all the other Amazon primes got their video service, and HBO, and all the movie channels now have their content streamed over the internet. Even most of the CBS NBC, the major players, they have a service you could sign up for. So you don't even need to subscribe to cable anymore. I mean, the cable companies, I gotta admit, I turned off my cable lock, because I found I was only watching a couple of stations. I don't have cable anymore either. So I bought those stations, and now I get them over the internet. Now I still pay my cable provider for my internet connection. So they still get a little bit of my money, but not like they used to. So everyone's gotta make this huge adjustment, and to compensate for us shifting so much of our economy onto the internet, we had to change the internet. And let's discuss that, some of the changes that we had to make with this new protocol. What a quick accomplish. You did some research? Yeah, so web pages used to be fairly simple. They used to be some text and some images, but now they're much more complex, and they're made of content maybe coming from different sources that are embedded or overlapped. So the way that HTTP was set up using TCP is you'd make one connection, request one web object, receive that, open up another connection, request the next piece. Well if you're looking at some of the web pages we have, now they're made up of like a dozen different pieces. So you're gonna be making all of these different connections. Each one requires the TCP handshake to happen, all the acknowledgments. Oh, but we should mention, the reason why we have so many connections is because HTTP in its first iteration said you make one ASCII one line request, and when you get a response, that's it. Your connection is severed. So we've never changed that until now. And that's why we have so much traffic, is like we have to renegotiate every time I want something else. And like you said, web pages have multiple pieces of content to shift back and forth. Sometimes in the background you don't even know what's going on. You can load the web page, and in the background we call this asymmetric, or there's an Ajax connection, which is the asymmetric XML JavaScript connections. You don't see it's going on, but if you click on something on the page, the page won't refresh, but in the background, another connection opens up, and that adds to the traffic. So how are we shifting away from that with quick or getting better with that? So one of the things that they're able to do with quick is send multiple objects over a single connection. So we're not setting up as many connections tearing down as many connections, and that's clearly going to be a lot more efficient. They call it multiplexing over a single connection. But essentially it's just reusing that connection to send multiple objects. Also switching from TCP to UDP eliminates a blocking issue. So TCP, as we said, uses secret numbers to show how all the pieces are supposed to fit together. Well, if you lose a packet somewhere halfway through and have to resend it, guess what? Everything stops and waits for that packet to come and fit into the sequence before we go and get the wraps. And it might have to be resented and you're waiting. And we're waiting. Everything stops and waits for that. But with quick, that's not the case because we're using UDP, no sequence numbers. So we get everything, we fit it together like a jigsaw puzzle, hopefully in the right order, and then we display it. So it's a lot more efficient. Now we've all clicked on a webpage and had a bad connection and half the webpage assembles and then you have blank white space below. Or you click on a connection, you see a blip of something and then it's a white page for three to four seconds and that's what's happening. It's waiting for those packets to catch up. And that's so frustrating. And hopefully this alleviates that. In addition, it's adding some security, right? It's forcing us to use security where now HTTP you can do HTTP or we can do HTTPS, which is over a different port, now 443, and it's secure. So we negotiate an RSA connection and exchange keys for encryption, right? This forces us to do this every time. We don't have the option anymore. It's always an encrypted connection. And everything, I think every single Google site is encrypted. More and more of the web is encrypted and less and less is unencrypted. So this quick doesn't apply to the unencrypted sites at all. This is strictly for those sites that are encrypted. So in our final seconds here, I'm going to just tell people that what this could do, and Cisco was putting this out there, is that not all systems can handle UDP connections right now. UDP might get blocked by default because no packet of inspection can happen at all through a firewall if you're using UDP and it can't be decrypted. So as usual, security's catching up to the new standard. So if we all do this, we might not have the great security that we have now. So Cisco put it out there, hey, let us catch up. So this new protocol just came out, the final draft is out. We don't know when full adoption is gonna happen. YouTube will let you do this if you use Opera, the browser or the other browser Chrome. Also Facebook. And Facebook will let you do this. And the beauty of it is if you try to make this connection and it fails because of some blocking or firewall, it'll just fall back to your regular TCP, HTTP too, which is okay for now. Well, we're out of time. Thanks for playing. Time went fast. Okay, everybody, thanks for joining us on the Cyber Underground. We'll see you next week for another great episode. Until then, stay safe.