Debugging the Internet: HTTP, TCP, and You

0:10Hello, and welcome to a new episode of Search Off the Record, a podcast coming to you from the Google search team where we talk about search and maybe have some fun along the way. My name's name, I'm a job title, or at least that's what's in our planning doc. In reality, my name is Gary, and I have no idea what I'm doing at Google, but I do stuff. Today, I'm joined by this wonderful person who I call Morty. I'm pretty sure that's not his real name. Is it? No. No. Okay. Well, let's not split hairs.

0:58So today I'm joined by Martin Splitt. Everyone say hi, or at least that's in my doc. Hi. Moin! No, hi. You have to say hi. Hi. Thank you. Hello. All right. So I'm sure you're wondering why I have gathered you here today. Yeah. Yeah. What is happening? What have I done wrong? Oh, you are wondering. Always. So I was talking to people. Yeah. Okay. That's just life. You were talking to people. Are these people in this room right now? No. Oh. Are they real? I hope so. Otherwise, I should really visit a psychotherapist or something. But one realization that I had, and I'm pretty sure that you are going to agree, is that even those who have been in the internet industry for long enough forgot about HTTP.

2:00As in, they use the term HTTP, but how it works and why it works and the different nuances and all the weird stuff that it's doing, and it's based on maybe people don't know that much about it anymore. JOHN MUELLER - I agree, yeah. And I have to say, I keep forgetting things about HTTP and find out new things. JOHN MUELLER - Well, it's evolving, so that's natural. So I was thinking that for a change, we don't have a script. And the two of us are just going to chat about HTTP. All right. 200, OK. Wow. So geeky. 100, continue. Oh, God. This was a mistake. Let's talk about something else. 101, switching phone calls.

2:55All right. So HTTP, it is the thing that makes the internet happen. Would you agree? Oh, careful. The internet or the web? Not the same thing. Nice. The web. OK, yes. I would say yes. OK, how about TCP? Because in one of my discussions, TCP and HTTP, they were used interchangeably. No, they're not. And I know that we are experimenting with something that uses or is kind of like HTTP, but it's not using TCP. Should we explain the difference? Of? Of HTTP versus TCP. Well, yeah. OK. Do you want to? Should I? Try. OK. OK. So I would, I'm probably going to botch it, because it's been a while I was working on my networking, as in like 20 years.

4:05But TCP is transport something protocol, transport control protocol, I think. It is the main protocol, I would say, of the old internet, of the old web. As in, like, it is the transmission protocol that was used on HTTP versions prior HTTP 3. Well, actually, HTTP 3 still uses that, but let's not go there yet. And it was, or it is coming from like the grandfather pretty much of the internet, Vinsurf. It was introduced a billion years ago, like 50 years maybe. I think it was introduced used in the 70s. And they needed a protocol that was capable of doing packet switching between network nodes. So basically, you send out a packet, and it could go one way or other way.

5:15Plus, it had to be able to negotiate connections and then reliably transfer the data packets from A to B. And there has been multiple approaches at this kind of stuff, yeah. Oh, yeah. And then I think it was also taken as the basis for other protocols later, like a voiceover IP, whatever the protocol was, RTP or something. It basically enables us to transfer data packets reliably. It accounts for data loss. So if there's something like a packet is lost, for example, then the server or the client can re-request the packet, which, well, it's important. And then on top of that, we have HTTP. Right?

6:16Yeah, well, HTTP and so many other things. Yeah. Well, yeah, but if we are talking about HTTP, then on top of this TCP thing, we have HTTP. Yeah, I think you could say that. In general, it's layers upon layers of the way that things work. And one of the lower layers is TCP. And then on top of that, you can do things It's like HTTP or HTTPS or FTP or mail stuff, SMTP, POP, this kind of stuff. Even pings, technically, you can send on. Like, you know, when you type in a command line, like ping something, you can actually send it over TCP. By default, it's on ICMP protocol, but you can switch it to TCP, which is basically not blocked.

7:13because usually ICMP is blocked by origins because, like, why are you pinging me? Traceroute, the program that is also normally or by default is working over ICMP, but you can switch it to a TCP. You can also switch it to UDP, I think. Yeah, yeah. That introduces more confusion. Let's not go there. Yeah. I think we cannot avoid talking about UDP because the new version of HTTP, HTTP 3, is making use of UDP a lot or UDP-like structure. I guess that makes sense in some ways, yeah. To understand the difference between them, you could think of one is like establishing a connection. So like having like a channel that you can pump things through, but that obviously requires like some setup and some teardown costs because you have to set up this quote unquote connection.

8:21And as you said, like if something gets lost, you know that it got lost and then you actually kind of by default wait for it to be retransmitted before assembling the rest. But sometimes that doesn't make sense. If you think about it, if you were to, let's say, do video streaming, if you use a video streaming provider or if you do a video call, if I miss one frame out of the 25 frames per second, it doesn't matter. But I don't want the image to freeze until that old frame from a few minutes ago comes in. So UDP is kind of fine with losing stuff, but it doesn't guarantee that everything makes its way across the network to the recipient, whereas TCP does.

9:02And I think with HTTP, in certain circumstances, it can make sense if we lose one quote unquote frame in between. But Quick does something weird to make that nice, right? Right. So UDP in general is not used on HTTP, like I would say. Like on HTTP, you are just going TCP, like transmission control protocol. But UDP has the feature that you described that like a packet is lost, don't care, let's go. But like UDP, you might actually see in DNS, which are not good. Maybe we talked about DNS in another episode. But DNS heavily relies on UDP. And then the new thing, the new kid on the block is QUIC, Q-U-I-C, which is more similar to UDP than TCP, I would say.

10:13Okay, how so? So QUIC, actually, I'm not even sure that it's more like a logic than an actual protocol because it is relying on UDP. when you need multiplexing. So basically, let's say in a simplified way, like a bidirectional stream, which to some extent HTTP2 already did with streaming, but it was weird, I guess. HTTP3, which relies on QUIC heavily, can open these streams where the streams can multiplex easily through QUIC. But then QUIC, what it does under the hood is just opening a UDP connection between two points and then multiplexing between those two points. OK. And why can't you? Because you have kind of a connection is more or less like a stream in TCP.

11:14Why can't we just use TCP for that? Good question. I have no idea. Yeah. So I think what they're trying to solve is a different thing, which is the data rate throttling. And the other thing is that now we need to open another can of worms, and that's HTTPS. Oh, right. So in HTTPS, the way that it works, so we already just I think it's worthwhile explaining why there's layering. So if you think about it, if you want to talk from one computer to another or from one phone to another or whatever, you need some sort of transmission medium that's a physical medium that can be radio waves that can be a cable can be fiber it can be whatever can be light signals it can be messenger pigeons for all i care so that's the physical medium the problem is right if it's messenger pigeons i just need you to receive a message i'm not interested in feeding the the pigeons i'm not interested in like raising them and nursing them back to health if they get sick and all that kind of stuff.

12:18So I want someone else to take care of that. And that's why we have this layering model, right? So someone takes care of the physical things. Then on top of that, we need to figure out how we group the bytes so that they go over this physical medium. Well, not bytes, the bits, actually. And so on and so forth. And that's why we have this layer model, so that you don't need to worry about the layers that you're not interested in. So for a website, I actually most of the time don't even care about HTTPS too much, because is I just have a document, a PDF, or an HTML file, or an image. And I just want that image to go from my server to your client on your phone, and that's it.

12:53And then I don't have to care. The lower level is, how does it get there? And that's HTTP normally. For the web, anyway, it's HTTP. And then HTTP needs to somehow transmit these messages. And that's usually TCP, as we discussed. But none of this does encryption. None of it. Like, none of it. It's just like basically yelling over from one end of the building to the other. Like, hey, I want this something something.jpg. Okay, here's something something.jpg. And everyone could figure it out. That's why HTTPS was invented. And that is kind of HTTP. Like, HTTP doesn't change. But the lower level is now using what's called transport layer security, if I'm not mistaken.

13:38Is that what? TLS. It used to be a secure socket layer, but that's dead and gone. It's now TLS for a long time. And the problem, I think, was that to do an HTTP request response, which all our websites are doing whenever someone requests them, you do a handshake. So it's kind of like, hi, I would like to open a TCP connection to you, Gary. And then you go, hi, Martin. Yes, please open a connection to me. and then I'm like, I have opened a connection to you. And then that's the handshake that we have to do. And for TLS, we have to do one more handshake. Because then we need to figure out, like, are you, hi, are you really Gary?

14:19And then you say, like, yes, here's my certificate. And I'm like, okay, cool. I would like to use this encryption mechanism. And then you're like, okay, cool. Here's my key. And then I'm like, hi, cool. Fantastic. Here's my key. So we have to do two handshakes. And with UDP, because it's this kind of like, ah, whatever. I send you a thing. you may receive it or not. I don't care. You don't have a handshake there. And for quick, I believe it enforces TLS. So HTTPS does not require TLS to be there. Then it's HTTP. There you go. I think quick only uses TLS, right? It has a quick connection. It's always a TLS-based connection.

14:58Yeah. Right. So we are saving a handshake as well. So we have less network traffic. Okay, that's pretty cool. And because it's UDP, I don't know. Have you heard about head of the line blocking before? Yes. I think that's the problem they are trying to solve with switching to UDP. Yes. I think. So in TCP, oh my god, these are topics that I haven't talked about in 20 years. It's so nice to bring them back. I love this kind of stuff. Network is my thing. Like, you keep, you send packets, right, from A to B. And then for whatever reason, on the way, it could be on the B side, it could be also in some cases on the A side or close to the A side, the packets start queuing up for whatever reason.

15:52So basically the, like, let's say the first packet is not letting through the follow-up packets. So basically you have like this weird blocking, essentially, where the packets can't reach because one packet was somehow blocked. And when I say blocked, it's just like gone missing or MIA or something. That first messenger pigeon you sent out met its untimely demise on the way. But the second one is fine. But then the second one has a problem because it doesn't know where to land, because the first just hasn't reached its destination. And in my brain, that's head of line blocking, which cannot happen with UDP.

16:39With UDP, basically, you have a bunch of pigeons on a line, tied to a line. And you pull them through to B from A. And then if the first pigeon falls to its demise is from the line midway, it doesn't matter, because the line is still going to be pulled through to B. So that's nice. I was listening to you and being fascinated, and I was thinking, how does this relate to site owners and SEOs and whatever? And that's a really good question. It actually does. It does. Because every now and then, you would get these weird messages in the Search Console that there was something with the network. like, I don't know how it's phrased, but like network blockage or connection issues or something like that.

17:34And that can actually happen in these layers that we are talking about, like down in TCP IP and actually, well, actually also in UDP, like why not? A DNS problem. A DNS is usually a the UDP thing. Oh, yeah, yeah. And definitely in Quique as well. These are the things that are affected when we are reporting those things in Search Console. Now, if we step one up, we have HTTP, like in your layers that you were describing in your cake. On the top, we would have HTTP slash S. There you have more verbose reporting of the issues. Because down in TCP slash UDP, there's not that much to know about what happened unless you break out your Wireshark program and you start inspecting the packets and whatnot.

18:33Otherwise, you wouldn't know what happened. Because there's no reporting whatsoever about what's happening and why. It is expected that from A something is going to reach B, but if the something hasn't reached B, then it's like, well, it was lost. Goodbye. And the upper layers usually swallow that. Like the HTTP response doesn't come in, your browser shows you, whoopsie, and server didn't respond. You get the Chrome Dino or something. Well, actually you don't because that's no internet. But you would get an error message like connection error or connection refused or something. For example, if the wrong parts of the message got lost, then the server might refuse the connection.

19:15Right? If authentication layer is somehow corrupted in an HTTPS connection, then the server might outright just refuse the connection without explaining itself. But then you have HTTP where you actually get stuff out of it because the servers that run the HTTP servers, or those HTTP servers can actually route the issue or pinpoint the issue, like what happened. Yeah, but that requires a lot of debugging in the lower levels, that's true. Well, I'm actually thinking about the error messages like HTTP 200. Ah, OK. That's the higher level ones. Sorry, OK, I didn't catch that. Yes. No, those are pretty descriptive.

20:05That's true. Yeah. Everyone knows 404. That's exactly that. Yeah. And that's coming from the HTTP server that powers your site. Like, basically, the user typed in something, well, typed in, as in, like, probably clicked something, and that something doesn't exist on your site. So basically, you just or the server just returns a 404. And that's what it should do. I would argue in most of the cases, it's just like, yeah, I have no idea about that URL. Yeah, I think that's a reasonable thing. And if it doesn't, then that's not necessarily a problem unless you want that file or that URL to actually return something meaningful.

20:48Yeah. Yeah. So that's fair. Yeah. And then you have other reporting as well in HTTP. You have 100, which I have no idea what it stands for. Hmm, what is it used for? Hold on. I saw that somewhere, but I'm not sure. It's continue, but I'm not sure when that's. I didn't even know that. I know that we technically don't support it, as in we just don't see it. Like we just like pass through without even noticing that something was in the 100 range. And just notice the next non-100 status code. Yeah, and I mean, there are complicated situations like WebSockets and stuff where WebSockets are based on an HTTP connection but are not HTTP themselves.

21:45Really? And you get HTTP responses in the 100 range as well. So it's not always as simple, is it? I don't know. Sometimes it is. I don't even know what a web socket is. Oh, so aha, OK. You can actually have a socket-like connection, so like a real-time channel between client and server where you can keep sending messages, what later on also So it's kind of, kind of possible with HTTP2 push. There's lots of reasons not to use that or server send. But it's one of the ways to kind of have like a real-time communication between server and client. So if you do like a chat, for instance, how would you do chat if you had HTTP?

22:33Because HTTP traditionally is you send a request to the server, client sends a request to the server, browser sends a request to web server, and the web server responds with something. but if I build a chat program then how would that work because at some point someone sends a message so then I would have yes exactly then you start polling so every 5 seconds every 10 seconds every minute I send a request to the server the server says no no new message and then after a few minutes I send a request to the server and it comes back with yeah here 10 new messages that's one way to do it then there's server sent events which is I can't remember how that works actually, to be honest.

23:14And then one of the ways to do this kind of thing is to establish a WebSocket connection. So you get a direct, because the TCP connection stays open anyways, so you can use that to send specific messages. And then in that case, the browser just gets an event like, hey, by the way, here's new data from the server, whenever there's a message. And for that, you need to tell the browser and the server, like, hi, I want to use WebSockets. and that's when you get an HTTP 101 switching protocols. It's funky. I never heard of this. I should read up on it. There's new stuff that I was like, oh, whoa, okay, wow.

23:56There's also the opportunity to do what's called early hints. Yeah, yeah. I don't know what they are specifically, But I know that they are also a feature in HTTP that I haven't been using much. MARTIN SPLITTENBERG, If I remember correctly, early hints was something that Cloudflare came out with a few years ago. And people were very excited about it. And then we were talking to some folks about whether we need to support it, but because it's in the 1xx range, and it doesn't actually benefit crawling that much, because we are just going to pass through anyway. It's like, yeah, we don't know how to say that we don't support it.

24:38But then it's not that we don't support it. It's just like we just completely ignore it. And then we were updating our documentation about it somehow. Oh, nice. Yeah. What are our status codes? Like these status codes are actually important, I think, for site owners and SEOs because they tell a story about what happened when a particular request came in. So we had 100, which, to be honest, I don't know when it would be used outside of WebSockets or early hints. We have the 200, which is just like, yeah, there was content. And here's the content, even if it's broken or something. Wait, wait, but in 200, you also have other stuff.

25:21Like you have 204. or which, because I remember 204 has to come back without body. Ah, yeah, it says no content, and that's for caching, right? Yeah. Ah, OK. So if I'm requesting something, and then the server goes like, no, no, nothing has changed, then it doesn't need to. OK, so it assumes or it knows that the client has already gotten the content of the page. So if I visit a website, if I visit, I don't know, the Wikipedia article on Jam, that doesn't change as much, I guess, because there's not that much invention in the Jam space, as far as I'm aware. If I open that in my browser and it saves it onto my computer for like a day or something and I visit it again, I don't need to actually transfer all the information again because I already have it on my computer or still have it on my computer.

26:18So then that's where 204 comes in, right? I mean, you can also describe it with something 304. I think, what was it? Yeah, 304 was not modified. Not modified. I'm not 100 % certain when you would use 204 and when you would use 304, because the 204 that I've seen, that is an endpoint on google.com, I think it's google.com slash generate underscore 204. And it just does that. Like, it generates a 204. Like, nobody know nothing. Nobody knows. Nobody knows. You get it? Yeah. Nobody knows. Nice. Anyway, so it generates a 204, and it was used, or it is used for polling whether you have internet, like on phones and whatnot.

27:15On Wi-Fis and stuff, yeah. on Wi-Fi's and stuff as well. But you can definitely use it for that. And then in 300, also just for the record, we are just going to run out of time. So we will need to continue this at one other point, because we have so many more stuff to talk about in HTTP realm. And we haven't even gotten to HTTP 1, 2, and 3. Oh, yeah. We just managed to mention them in passing, but otherwise nothing. I think you have the 3xx ones, which are mostly redirections, yes, which there you also have something confusing, because you have 301, 302, and 300 itself. And then you have 307, 308, which are also redirections.

28:06It's just like somehow it's different. But I have no idea why. I think they carry very specific meaning, and not necessarily meaning that you always need, I believe. Yeah, I guess. But for us, it's like for Google search, specifically, it's just like, yeah, it was a red reaction. It's like whatever. We kind of care about in canonicalization whether something was temporary or permanent. But otherwise, it was a red reaction. like whatever. Then you have 304 was the exception. 4xx also has an exception. Does it? I mean most of it is the client made a mistake, right? What's the exception then? Come on.

28:55You can do this. Oh, I'm a teapot. Right? Isn't that a four? So it has two exceptions then. Oh. OK, the teapot one, that's, I think that's super funny and just illustrates how the IETF works, because it was like an April Fool's joke. I don't remember from whom, but they just made it into the standard, because why not? But what other exception do you mean? 429. I don't think that's too many requests. I don't think, no, I disagree that that's a difference or exception. Yeah. Why? Do you want me to explain? Okay. So I think 400 means the client did something that it was not supposed to or made some sort of mistake, right?

29:44404, the client asked for a thing that I don't have. That's a mistake on the client side. Or 401 or 403 where I'm not allowed. 401 is unauthorized and the other one is forbidden and they have a significant. Anyway, so again, I asked for something that I'm not supposed to get to, these kind of things. 410, gone. Something was there, but no longer is. And 429, too many requests, just means I asked too often for something. Like I still have resources to serve you, but I don't want to. Yeah. Or I don't have to. I don't have resources to actually serve you. So instead of doing the work to serve you, I'll just tell you, no, back off.

30:27Well, but for that, you have all the 500s. Like if you are out of resources. Oh, okay. That is very philosophical. Okay. But maybe it's not because I don't have the resources. Maybe it's just I don't want you to ask me this often. It's like, are we there yet? Are we there yet? Are we there yet? I can answer, but I don't want to. Stop. I don't think that's a server error. But that's what I'm saying. But I think that's what I'm saying. Okay. Like, I could serve you this particular URL, but you were asking so often that I really just don't want to. OK, yeah. So I think that's not an exception, because it's just the client asked too often.

31:09Then the teapot is the exception. The teapot is definitely an exception. Because no one made something wrong there. Like, it's 5xx? Something on the server. That's always a server error. Yeah. That's always a server error. Yeah. And I don't think that there's an exception there, unless there's some esoteric 500 status code, like in the high ranges, like application-specific, like web dev, for example, I remember used... Oh, why did I mention web dev? Now we have to explain it. Actually, you can just use your favorite search engine to look up what web dev is. DAV. web DAV Martin our producer was yelling at us for running over good and I am going to schedule one more of these and we finish talking about HTTP in the meantime can people listening to this please let us know if this kind of stuff is interesting or not because I'm not sure if this is just a weird nerd fest or if people actually enjoy this Yeah.

32:20Please. That'd be interesting. We will keep doing it anyway because we actually like it. But you tell us. Man, this was great. Thank you so much. You're very welcome. I love it. That's it for this episode. OK. If people want to find you to chat more, where can they do that? Martin? LinkedIn, Blue Sky, Mastodon. Yeah. Yeah, and I'm antisocial. Don't find me. Well, thank you folks for listening and goodbye. Bye-bye.

32:57We've been having fun with these podcast episodes. I hope you, the listener, have found them both entertaining and insightful too. Feel free to drop us a note on LinkedIn or chat with us at one of the next events that we go to if you have any thoughts. And of course, don't forget to like and subscribe. Thank you and goodbye!