WEBVTT 1 00:00:00.040 --> 00:00:02.439 Ever sent an email, streamed a movie, or maybe just 2 00:00:02.520 --> 00:00:04.839 you know, browse to web page. It feels almost like 3 00:00:04.960 --> 00:00:07.799 magic sometimes, doesn't It Just a few taps, a few clicks, 4 00:00:07.799 --> 00:00:10.560 and boom your message or your video, It just zips 5 00:00:10.560 --> 00:00:14.960 across the globe. What's actually really happening under that digital hood. 6 00:00:15.240 --> 00:00:18.000 Well, that's exactly what we're diving into today. We're aiming 7 00:00:18.079 --> 00:00:23.079 to peel back those seemingly simple layers and really reveal 8 00:00:23.160 --> 00:00:26.559 the intricate engineering and the foundational principles that make the 9 00:00:26.600 --> 00:00:29.600 Internet actually work. It's honestly, it's far more ingenious and 10 00:00:29.879 --> 00:00:32.159 often's surprising than most people probably realize. 11 00:00:32.200 --> 00:00:35.359 Okay, And to guide us on this journey, we're leaning 12 00:00:35.439 --> 00:00:39.439 on a leading textbook on computer networking. Think of it 13 00:00:39.479 --> 00:00:42.960 as our well, our expert map for navigating this incredibly 14 00:00:43.079 --> 00:00:46.679 complex but yeah, utterly fascinating world. We're going to explore 15 00:00:46.759 --> 00:00:49.240 the protocols, these kind of hidden rules that govern how 16 00:00:49.240 --> 00:00:52.399 all that information flows, and hopefully uncover some of the 17 00:00:52.399 --> 00:00:57.159 surprising efficiency and resilience behind it all. So let's start 18 00:00:57.200 --> 00:00:59.280 right at the beginning. When we say the Internet, what 19 00:00:59.320 --> 00:01:01.200 exactly are we retre talking about? Because it's not just 20 00:01:01.240 --> 00:01:01.880 the web. 21 00:01:01.640 --> 00:01:04.319 Right, no, no, definitely not. It's much bigger than that. 22 00:01:05.560 --> 00:01:09.959 Our source defines the Internet fundamentally, not as some single thing, 23 00:01:10.319 --> 00:01:14.879 but as this vast global network of networks. So imagine 24 00:01:15.159 --> 00:01:18.920 countless individual networks like your home Wi Fi, your office network, 25 00:01:19.799 --> 00:01:22.599 university campus network, maybe all of them are connected. It's 26 00:01:22.599 --> 00:01:25.120 really built from end systems you know, your PC, your 27 00:01:25.159 --> 00:01:27.719 smartphone talking to servers, and then all these things called 28 00:01:27.760 --> 00:01:31.560 packet switches like routers that guide the information along. 29 00:01:31.760 --> 00:01:33.640 Okay, and network of networks. That makes sense. 30 00:01:33.879 --> 00:01:36.000 But if it's all these different pieces, how do they 31 00:01:36.040 --> 00:01:39.879 communicate without just digital chaos. What's the sort of fundamental 32 00:01:39.920 --> 00:01:41.480 secret sauce holding it all together. 33 00:01:41.719 --> 00:01:44.280 Yeah, that's where protocols come in. The power of protocols, 34 00:01:44.359 --> 00:01:48.280 As you might say, think of protocols as the critical 35 00:01:48.359 --> 00:01:52.359 rules of the road. They're like universal languages, allowing different machines, 36 00:01:52.400 --> 00:01:56.040 different systems to actually understand each other. Our source highlights 37 00:01:56.040 --> 00:01:59.079 two really key ones TCP, which is the transmission control protocol, 38 00:01:59.319 --> 00:02:03.480 and IP, the Internet protocol. They're so basic, so fundamental, 39 00:02:03.719 --> 00:02:06.879 we often just lump them together and say TCPIP IP. 40 00:02:07.040 --> 00:02:09.439 For example, it's kind of like the common postal address 41 00:02:09.439 --> 00:02:11.800 system for every single package of data. 42 00:02:12.120 --> 00:02:13.879 Okay, TCPIP got it. 43 00:02:14.319 --> 00:02:16.960 And here's where I think it gets really interesting, this 44 00:02:17.080 --> 00:02:19.840 idea of packet switching. I mean, most of us probably 45 00:02:19.879 --> 00:02:21.680 don't think about how our data gets sent, but it 46 00:02:21.759 --> 00:02:24.840 sounds like a pretty revolutionary shift from older systems. Can 47 00:02:24.879 --> 00:02:26.400 you maybe paint a picture of that for us? 48 00:02:26.680 --> 00:02:29.439 Absolutely? Yeah, it's a huge deal. Imagine the old telephone 49 00:02:29.479 --> 00:02:33.120 system that used something called circuit switching. When you ate 50 00:02:33.159 --> 00:02:37.680 a call, you essentially reserved a dedicated private line, a 51 00:02:37.680 --> 00:02:40.479 circuit between you and the other person, and that was 52 00:02:40.520 --> 00:02:43.199 for the entire duration of the call. Even if you 53 00:02:43.240 --> 00:02:45.360 both went silent for a minute, maybe put the phone down, 54 00:02:45.759 --> 00:02:49.680 that dedicated path, that circuit was still yours, completely idle, 55 00:02:49.960 --> 00:02:53.080 but reserved. Our source gives an example where a link 56 00:02:53.280 --> 00:02:57.879 using circuit switching might only support say ten simultaneous users, 57 00:02:58.199 --> 00:02:58.840 just ten. 58 00:02:59.319 --> 00:03:01.400 So it's like have a reserved highway lane just for 59 00:03:01.439 --> 00:03:03.360 your car, even if you're pulled over on the shoulder 60 00:03:03.360 --> 00:03:04.680 and not actually driving. 61 00:03:04.840 --> 00:03:08.280 Exactly like that. Yes, now, packet switching, it's a completely 62 00:03:08.280 --> 00:03:12.520 different philosophy, a different approach. Your data, whether it's an email, 63 00:03:12.599 --> 00:03:16.039 a video stream, a web page request, whatever, gets chopped 64 00:03:16.120 --> 00:03:19.199 up into these small independent chunks. We call them packets. 65 00:03:19.560 --> 00:03:22.560 And here's the magic bit. These packets share the same 66 00:03:22.680 --> 00:03:25.680 communication links with packets from loads of other users. 67 00:03:25.759 --> 00:03:28.479 Ah, and that's where the efficiency boost comes from, right, 68 00:03:28.560 --> 00:03:31.080 because they're not hogging the whole road anymore. 69 00:03:31.280 --> 00:03:36.199 Precisely, that sharing allows for incredible over subscription. It's much 70 00:03:36.240 --> 00:03:39.039 more efficient. So in that same example, where circuit switching 71 00:03:39.039 --> 00:03:42.719 supported what ten users, packet switching could often support more 72 00:03:42.800 --> 00:03:45.759 than three times the number of users, offering essentially the 73 00:03:45.759 --> 00:03:48.800 same kind of performance level. But the real genius, I think, 74 00:03:48.840 --> 00:03:51.639 isn't just the raw efficiency, although that's huge, it's also 75 00:03:51.680 --> 00:03:55.520 the resilience and the scalability. Think about it. If one 76 00:03:55.639 --> 00:03:59.360 path gets congested or maybe even breaks entirely, packets can 77 00:03:59.439 --> 00:04:03.560 usually just another route to their destination. This completely changed 78 00:04:04.120 --> 00:04:08.159 the economic model, the resilience model of telecommunications. We went 79 00:04:08.159 --> 00:04:11.520 from these rigid, dedicated lines to a much more flexible, 80 00:04:11.639 --> 00:04:15.039 shared and robust infrastructure. And honestly, that's what allowed the 81 00:04:15.039 --> 00:04:18.319 Internet to just grow explosively and foster all this innovation 82 00:04:18.639 --> 00:04:21.079 that circuit switching well, it just couldn't have supported. 83 00:04:21.160 --> 00:04:21.439 Wow. 84 00:04:21.560 --> 00:04:25.040 Okay, so it's this incredibly robust shared system, but it 85 00:04:25.079 --> 00:04:27.439 didn't just pop up overnight, did it. What were some 86 00:04:27.480 --> 00:04:29.120 of those crucial early steps. 87 00:04:29.519 --> 00:04:33.839 No, definitely not overnight. Our source traces its history back 88 00:04:33.959 --> 00:04:38.199 way back to pioneering work on internetworking people like Vitten 89 00:04:38.279 --> 00:04:41.800 Surf and Robert Kahn working under Darbest sponsorship. By the 90 00:04:41.920 --> 00:04:44.439 end of the nineteen seventies, the sort of conceptual groundwork 91 00:04:44.480 --> 00:04:47.120 for TCP and IP was already being laid down. Then 92 00:04:47.199 --> 00:04:50.240 the nineteen nineties that's when things really took off. That 93 00:04:50.360 --> 00:04:54.759 ushered in the big Internet explosion and commercialization ARPINET that 94 00:04:54.839 --> 00:04:57.160 was the original network, it actually ceased to exist, and 95 00:04:57.199 --> 00:05:01.920 commercial Internet service providers ISPs gradually started taking over the 96 00:05:01.959 --> 00:05:05.959 backbone traffic from the government funded networks like NSF net. 97 00:05:06.120 --> 00:05:08.639 It is a really pivotal shift, you know, from basically 98 00:05:08.639 --> 00:05:11.519 a research project to a global commercial utility. 99 00:05:11.879 --> 00:05:12.040 Right. 100 00:05:12.079 --> 00:05:14.600 The nineties were huge for that. Okay, now let's talk 101 00:05:14.600 --> 00:05:18.480 about how this massive system is actually organized. Our source 102 00:05:18.519 --> 00:05:22.199 describes the Internet's architecture as a five layer Internet architecture. 103 00:05:22.279 --> 00:05:25.240 At least from an application developers perspective, people often compare 104 00:05:25.279 --> 00:05:28.199 it to a layered cake. What's the main idea behind 105 00:05:28.279 --> 00:05:30.079 breaking it down into these distinct layers? 106 00:05:30.079 --> 00:05:30.639 Why do that. 107 00:05:30.879 --> 00:05:33.959 Yeah, the layered cake analogy is pretty good. Actually, imagine 108 00:05:33.959 --> 00:05:37.639 a really complex assembly line. Each layer is like a 109 00:05:37.680 --> 00:05:41.959 specialized team. They're responsible for just one specific part of 110 00:05:42.000 --> 00:05:46.319 the whole process, and crucially, they only really interact directly 111 00:05:46.360 --> 00:05:49.519 with the layer immediately above and immediately below them. So 112 00:05:49.639 --> 00:05:52.920 your email, for instance, starts at the top the application layer. 113 00:05:53.000 --> 00:05:55.279 That's the message itself, which you wrote. That thing gets 114 00:05:55.319 --> 00:05:58.240 passed down to the transport layer. Its job is making 115 00:05:58.279 --> 00:05:59.800 sure it gets to the right piece of software on 116 00:05:59.800 --> 00:06:03.040 the computer. Then it goes down again to the network layer, 117 00:06:03.319 --> 00:06:05.600 which figures out the best root across the whole planet, 118 00:06:06.639 --> 00:06:08.720 and so on down the sack. This sort of division 119 00:06:08.759 --> 00:06:12.480 of labor makes the whole system incredibly robust, much easier 120 00:06:12.480 --> 00:06:16.319 to manage, and it allows for innovation at one layer 121 00:06:16.360 --> 00:06:19.560 without necessarily breaking all the others. The application architecture, you know, 122 00:06:19.600 --> 00:06:22.000 the stuff you actually see and interact with that's built 123 00:06:22.040 --> 00:06:24.199 on top of this fixed network architecture underneath. 124 00:06:24.199 --> 00:06:26.759 Okay, layers make sense. Starting at the top, then the 125 00:06:26.800 --> 00:06:29.800 application layer, This is the stuff we actually see and 126 00:06:29.879 --> 00:06:32.879 interact with every day, browsing the web, sending emails, that 127 00:06:32.959 --> 00:06:35.680 kind of thing, and the web of course runs on HTTP. 128 00:06:36.560 --> 00:06:41.360 What makes HTTP so fundamental to well our whole web experience? 129 00:06:41.639 --> 00:06:45.399 Right, HTTP hypertext Transfer protocol. It's basically the language of 130 00:06:45.399 --> 00:06:49.120 the web. When you request a web page, HTTP uses 131 00:06:49.160 --> 00:06:53.000 something called persistent connections. What that means is your browser 132 00:06:53.000 --> 00:06:55.800 can keep a single connection open to the server and 133 00:06:55.879 --> 00:06:58.480 use it to fetch multiple things like the main web 134 00:06:58.480 --> 00:07:01.560 page HTML. Then it's in images, it's style sheets, maybe 135 00:07:01.560 --> 00:07:04.120 some scripts, all without having to set up a brand 136 00:07:04.199 --> 00:07:07.160 new connection for every single little file. It can even 137 00:07:07.199 --> 00:07:10.079 do something called pipelining, where it sends multiple requests back 138 00:07:10.120 --> 00:07:12.000 to back without even waiting for the first reply to 139 00:07:12.000 --> 00:07:13.639 come back. Makes things faster. 140 00:07:13.879 --> 00:07:15.959 And what's kind of wild is how simple it seems 141 00:07:16.079 --> 00:07:19.399 underneath it all. Right, our source actually says HTTP request 142 00:07:19.480 --> 00:07:21.560 messages are just ordinary ASKI text. 143 00:07:21.959 --> 00:07:25.800 Yeah, that's one of its uh elegant features. I suppose 144 00:07:25.839 --> 00:07:28.439 it's design to be readable boost by someone who's reasonably 145 00:07:28.439 --> 00:07:33.120 computer savvy. These requests, they contain a method like get T, 146 00:07:33.360 --> 00:07:35.959 which just means please give me this thing than the 147 00:07:36.120 --> 00:07:37.800 URL the address of the thing you want, and the 148 00:07:37.959 --> 00:07:41.079 HTTP version being used. And then there can be additional 149 00:07:41.079 --> 00:07:43.639 info in what are called header lines. It's essentially just 150 00:07:43.680 --> 00:07:45.600 a clear written instruction to the server. 151 00:07:45.920 --> 00:07:49.800 Speaking of instructions, cookies, those little bits of data. They've 152 00:07:49.839 --> 00:07:52.199 always fascinated me because they enable so much of our 153 00:07:52.240 --> 00:07:55.959 personalized web experience, you know, log ins, shopping carts. 154 00:07:56.560 --> 00:07:58.439 But how do they actually work behind the scenes. 155 00:07:58.439 --> 00:07:59.399 What's the mechanism? 156 00:07:59.639 --> 00:08:02.839 Cookie? These are surprisingly clever for something so seemingly small. 157 00:08:03.600 --> 00:08:07.399 Our source breaks them down nicely into four main components. First, 158 00:08:07.600 --> 00:08:10.439 there's a special line in the HTTP response message coming 159 00:08:10.439 --> 00:08:13.040 from the server that basically says, hey, browser, here's a 160 00:08:13.079 --> 00:08:16.480 cookie for you. It sets the cookie. Second, there's a 161 00:08:16.519 --> 00:08:20.639 line in subsequent HTTP request messages going to the server 162 00:08:20.879 --> 00:08:23.680 where your browser sends it back saying, hey server, remember me, 163 00:08:23.759 --> 00:08:27.560 here's that cookie you gave me. Third, there's a small 164 00:08:27.600 --> 00:08:30.920 file actually stored on your computer, managed by your browser, 165 00:08:30.959 --> 00:08:34.360 where these little cookie values are kept. And fourth, there's 166 00:08:34.440 --> 00:08:37.440 usually a back end database at the website itself where 167 00:08:37.440 --> 00:08:40.720 the server links that cookie id to your information. So 168 00:08:40.759 --> 00:08:43.679 this whole system allows websites to well remember who you are, 169 00:08:43.799 --> 00:08:46.600 maybe keep you logged in, track your shopping cart contents, 170 00:08:46.679 --> 00:08:49.679 or personalized ads, all by associating that little cookie with 171 00:08:49.759 --> 00:08:51.360 your previous activity on their site. 172 00:08:51.399 --> 00:08:55.919 That's a fantastic example of those hidden layers doing complex work. Okay, 173 00:08:55.960 --> 00:08:57.480 so let's move down the stack a bit to the 174 00:08:57.480 --> 00:09:02.320 transport layer. Our source says it codes logical communication between 175 00:09:02.360 --> 00:09:06.759 application processes. From an applications point of view, What does 176 00:09:06.799 --> 00:09:08.759 that really mean, what's the experience? 177 00:09:09.360 --> 00:09:11.840 What it means is that the transport layer basically creates 178 00:09:11.840 --> 00:09:15.480 this illusion, an illusion that application process is running on 179 00:09:15.519 --> 00:09:18.960 different computers, different hosts, even if they're on opposite sides 180 00:09:19.000 --> 00:09:21.600 of the planet, are directly connected, like they're having a 181 00:09:21.639 --> 00:09:26.080 private one on one conversation just between them. It effectively 182 00:09:26.200 --> 00:09:30.240 hides or abstracts away all the messy physical details of 183 00:09:30.279 --> 00:09:33.759 the actual network in between all the routers, the cables, 184 00:09:33.840 --> 00:09:36.799 the wireless signals, everything. It's kind of like having a 185 00:09:36.840 --> 00:09:39.679 postal service that guarantees delivery to the specific person you 186 00:09:39.679 --> 00:09:42.120 address the letter to, not just dumping it at the 187 00:09:42.120 --> 00:09:43.000 front door of the building. 188 00:09:43.080 --> 00:09:44.159 Ah okay. 189 00:09:44.399 --> 00:09:47.879 And this is where TCP's famous reliability comes into play, 190 00:09:47.919 --> 00:09:50.360 isn't it. Because down at the lower levels, the Internet 191 00:09:50.360 --> 00:09:53.799 itself can be a pretty unreliable place. Packets can get lost, 192 00:09:53.840 --> 00:09:56.279 they can get duplicated, maybe arrive out of order. 193 00:09:56.399 --> 00:09:59.600 It's exactly right. The underlying IP layer, the network layer, 194 00:10:00.120 --> 00:10:03.440 is inherently unreliable. It makes what we call a best 195 00:10:03.559 --> 00:10:08.720 effort delivery, but no guarantees. But TCP huh. TCP takes 196 00:10:08.720 --> 00:10:12.639 that unreliable service and magically transforms it into a robust, 197 00:10:12.840 --> 00:10:16.720 reliable data transfer service for the application above it. It 198 00:10:16.759 --> 00:10:19.279 achieves this through a whole suite of clever mechanisms. It 199 00:10:19.360 --> 00:10:21.639 uses sequence numbers to keep track of the data order, 200 00:10:21.679 --> 00:10:25.240 making sure everything gets reassembled correctly. It uses acknowledgments or 201 00:10:25.279 --> 00:10:28.440 ACKs to confirm that data segments have been received successfully, 202 00:10:28.720 --> 00:10:31.960 and it uses timers. If an ACK isn't received back 203 00:10:31.960 --> 00:10:34.480 within a certain time, TCP assumes the pack it got 204 00:10:34.519 --> 00:10:38.519 lost and retransmits it. It's constantly checking, confirming, and resending 205 00:10:38.519 --> 00:10:41.240 if needed, until it's sure all the data has arrived 206 00:10:41.240 --> 00:10:42.559 correctly and in the right order. 207 00:10:42.799 --> 00:10:46.799 And TCP also does something called congestion control. That sounds important. 208 00:10:46.799 --> 00:10:49.759 It feels almost like the Internet social contract, maybe making 209 00:10:49.759 --> 00:10:52.200 sure one greedy user doesn't just hog all the bandwidth. 210 00:10:52.320 --> 00:10:55.080 That's actually a perfect way to describe it, a social contract. 211 00:10:55.919 --> 00:11:00.600 TCP's congestion control is designed precisely to prevent any connection 212 00:11:00.639 --> 00:11:05.679 from just completely swamping the links overwhelming the network. It 213 00:11:05.720 --> 00:11:09.080 works to ensure a relatively fair sharing of bandwidth across 214 00:11:09.120 --> 00:11:11.960 all the connections using that part of the network. If 215 00:11:12.000 --> 00:11:15.080 a TCP connection starts to sense congestion, maybe by seeing 216 00:11:15.159 --> 00:11:18.200 packets get dropped or noticing that round trip times are increasing, 217 00:11:18.360 --> 00:11:21.039 it will actually slow down as sending rate voluntarily. It's 218 00:11:21.080 --> 00:11:24.159 a cooperative mechanism really designed to keep the overall network 219 00:11:24.159 --> 00:11:26.320 stable and performing well for everyone using it. 220 00:11:26.559 --> 00:11:29.200 That sounds like a major difference compared to UDP, the 221 00:11:29.279 --> 00:11:31.080 other main transport protocol, right. 222 00:11:31.080 --> 00:11:35.559 Oh, absolutely a huge difference. UDP, the User Datagram Protocol, 223 00:11:35.639 --> 00:11:38.879 is the polar opposite in many ways. It's connectionless, meaning 224 00:11:38.879 --> 00:11:42.039 there's no setup handshake like tcps, and crucially it has 225 00:11:42.039 --> 00:11:45.919 no built in congestion control our sources. UDP does just 226 00:11:45.960 --> 00:11:48.679 about as little as a transport protocol can do. It's 227 00:11:48.879 --> 00:11:51.919 very simple, very minimal overhead. It basically just takes the 228 00:11:51.960 --> 00:11:54.440 application's data, slaps on a header, and throws the resulting 229 00:11:54.440 --> 00:11:57.559 packet onto the network, hoping for the best. No guarantees, 230 00:11:57.559 --> 00:12:01.440 no retransmissions, no flow control. This simplicity makes it useful 231 00:12:01.480 --> 00:12:04.120 for certain things like quick DNAs lookups, where speed matters 232 00:12:04.480 --> 00:12:07.240 and a lost packet isn't catastrophic, or maybe real time 233 00:12:07.240 --> 00:12:10.919 gaming where slightly old data is useless. Anyway, but our 234 00:12:10.960 --> 00:12:14.120 source does highlight a key controversy here. Running high band 235 00:12:14.120 --> 00:12:17.399 with multimedia applications like video streaming purely over UDP, well, 236 00:12:17.559 --> 00:12:20.120 that can be problematic. It can result in high loss 237 00:12:20.200 --> 00:12:22.399 rates for the UDP stream itself, and it can even 238 00:12:22.480 --> 00:12:25.600 end up crowding out of TCP sessions. Why because the 239 00:12:25.639 --> 00:12:28.799 UDP centers, unlike TCP, won't back off when the network 240 00:12:28.799 --> 00:12:32.840 gets congested. They just keep blasting data, acting like a 241 00:12:32.919 --> 00:12:35.879 rude guest at a crowded party, taking more than their. 242 00:12:35.759 --> 00:12:38.919 Fair share, right, the rude guest protocol? I like that. 243 00:12:39.440 --> 00:12:41.679 Okay, so TCP is making sure the data gets there 244 00:12:41.720 --> 00:12:46.279 reliably and fairly. But how does that data actually know 245 00:12:46.360 --> 00:12:50.559 which way to go across this gigantic network of networks. 246 00:12:50.600 --> 00:12:53.039 That sounds like the job of the next layer down, 247 00:12:53.080 --> 00:12:55.840 the network layer. You called it the Internet's GPS earlier. 248 00:12:55.879 --> 00:12:58.600 That's a great analogy. Yeah, the network layer is all 249 00:12:58.639 --> 00:13:02.240 about navigation, And here we make an important distinction between 250 00:13:02.240 --> 00:13:07.679 two related concepts, forwarding and routing. Forwarding is the immediate 251 00:13:07.840 --> 00:13:10.600 local action a router takes. It gets a packet on 252 00:13:10.600 --> 00:13:13.320 one of its input links, looks up the destination address 253 00:13:13.360 --> 00:13:15.799 in a table, and quickly moves that packet to the 254 00:13:15.840 --> 00:13:18.360 correct output link. It's like a traffic cop at a 255 00:13:18.399 --> 00:13:22.840 single intersection, just directing cars based on their immediate destination. Routing, 256 00:13:22.919 --> 00:13:25.000 on the other hand, that's the bigger picture. It's about 257 00:13:25.039 --> 00:13:28.039 the algorithms and protocols that run across the entire network 258 00:13:28.159 --> 00:13:31.200 to determine the good paths or routes that packets should take. 259 00:13:31.840 --> 00:13:35.440 Routing effectively builds those traffic maps the forwarding tables that 260 00:13:35.480 --> 00:13:37.799 thought outers then use for their quick forwarding decisions. 261 00:13:37.919 --> 00:13:40.879 And the fundamental address used for this global navigation is 262 00:13:40.919 --> 00:13:42.039 the IP address. 263 00:13:41.759 --> 00:13:45.360 Right Exactly, every interface, every connection point on every device 264 00:13:45.399 --> 00:13:48.799 connected to the Internet, your laptop's Wi Fi card, a 265 00:13:48.840 --> 00:13:53.080 server's network port, a router's interface needs a globally unique 266 00:13:53.120 --> 00:13:55.600 IP address, at least public one if it's directly on 267 00:13:55.600 --> 00:13:59.720 the Internet. These addresses are assigned hierarchically. Think of it 268 00:13:59.759 --> 00:14:04.519 like geographical addresses with countries, states, cities, streets. We use 269 00:14:04.559 --> 00:14:08.200 a system called classless intra domain routing or CIDR, which 270 00:14:08.240 --> 00:14:10.519 you see written as that ABC dot d X notation 271 00:14:10.919 --> 00:14:12.559 like one nine two point one six eight or one 272 00:14:12.559 --> 00:14:15.559 point zero two four. That X part defines the size 273 00:14:15.559 --> 00:14:18.679 of the network block. This hierarchical structure is key to 274 00:14:18.759 --> 00:14:21.759 making routing efficient. A router doesn't need a specific entry 275 00:14:21.759 --> 00:14:23.919 for every single address on the planet. It just needs 276 00:14:23.960 --> 00:14:26.639 to know which larger block and address belongs to and 277 00:14:26.679 --> 00:14:28.840 which direction to send packets for that block. 278 00:14:29.360 --> 00:14:31.320 Okay, hierarchical addressing makes sense. 279 00:14:31.480 --> 00:14:33.879 And speaking of IP addresses, you mentioned something earlier in 280 00:14:33.879 --> 00:14:35.399 that network address translation. 281 00:14:35.480 --> 00:14:36.279 You said it was clever. 282 00:14:36.600 --> 00:14:39.120 How does that actually let all the devices in my home, 283 00:14:39.240 --> 00:14:41.600 you know, my laptop, my phone, the smart TV all 284 00:14:41.600 --> 00:14:44.440 shared just one single public IP address from my ISP 285 00:14:44.960 --> 00:14:45.240 on that. 286 00:14:45.600 --> 00:14:49.080 Yes, it's genuinely fantastic, a really clever piece of engineering 287 00:14:49.360 --> 00:14:52.200 born partly out of necessity as we started running out 288 00:14:52.200 --> 00:14:56.159 of the original IPv for addresses. Think of your home router. 289 00:14:56.240 --> 00:14:58.799 The box your ISP probably gave you is acting like 290 00:14:58.799 --> 00:15:01.559 a kind of concierge reptionists for your local home network. 291 00:15:02.039 --> 00:15:05.320 All your devices inside your home, the laptop, phone, TV, 292 00:15:05.519 --> 00:15:08.000 maybe a gaming console, they each get a private IP address. 293 00:15:08.440 --> 00:15:10.519 These are addresses like one nine two point one six 294 00:15:10.679 --> 00:15:13.360 eight point one, one, zero, which are only unique within 295 00:15:13.399 --> 00:15:15.639 your home network. Now, when one of those devices wants 296 00:15:15.639 --> 00:15:17.679 to send a packet out to the public Internet, it 297 00:15:17.720 --> 00:15:20.399 first goes to your gnat router. The gnat router then 298 00:15:20.440 --> 00:15:23.399 cleverly rewrites the source IP address on that packet, changing 299 00:15:23.399 --> 00:15:26.279 it from the private internal address to your single globally 300 00:15:26.360 --> 00:15:29.000 unique public IP address, the one signed by your ISP. 301 00:15:29.320 --> 00:15:31.679 It also usually rewrites the source port number. It keeps 302 00:15:31.720 --> 00:15:34.840 a table remembering, okay, internal device X using internal port 303 00:15:35.000 --> 00:15:37.720 Y sent this packet out using public port Z. Then 304 00:15:37.799 --> 00:15:39.879 when the response comes back from the Internet addressed to 305 00:15:39.919 --> 00:15:43.399 your public IP and that specific public port Z, the 306 00:15:43.480 --> 00:15:46.559 gnat router looks up at the table sees ah that 307 00:15:46.639 --> 00:15:49.639 corresponds to internal device X on port Y, rewrites the 308 00:15:49.639 --> 00:15:52.559 destination IP import back to the private ones and forwards 309 00:15:52.600 --> 00:15:54.919 the packet to the correct device inside your home. It's 310 00:15:54.960 --> 00:15:58.320 incredibly efficient. Our source notes that allows a single public 311 00:15:58.399 --> 00:16:03.720 wan side IP address to support over sixty thousand simultaneous connections. Potentially, 312 00:16:04.039 --> 00:16:06.639 it was absolutely crucial for scaling the Internet within homes 313 00:16:06.679 --> 00:16:07.600 and small businesses. 314 00:16:07.679 --> 00:16:10.759 Wow, okay, that is clever. That really paints a picture 315 00:16:10.759 --> 00:16:12.919 of how my home network actually connects to the wider 316 00:16:13.000 --> 00:16:16.759 world a train trace. A slightly more involved but still 317 00:16:16.919 --> 00:16:20.759 super common everyday scenario when I boot my laptop, Right, 318 00:16:21.120 --> 00:16:22.960 how does it even get an ipodress in the first 319 00:16:22.960 --> 00:16:25.320 place so it can start browsing the Internet? And how 320 00:16:25.360 --> 00:16:27.519 do all these layers kind of work together for dispatching 321 00:16:27.559 --> 00:16:28.360 a simple web page? 322 00:16:28.559 --> 00:16:29.200 Right? Good question. 323 00:16:29.240 --> 00:16:31.519 It's quite an intricate little dance that happens almost instantly. 324 00:16:31.600 --> 00:16:34.039 So when your laptop first boots up and connects to 325 00:16:34.039 --> 00:16:36.320 the network, say via Wi Fi, it doesn't have an 326 00:16:36.320 --> 00:16:38.159 IP address yet. It needs one, so the first thing 327 00:16:38.159 --> 00:16:40.679 it typically does is broadcast a special message onto the 328 00:16:40.679 --> 00:16:44.919 local network. This is a DHCP discover message DHCP sends 329 00:16:44.919 --> 00:16:48.240 for Dynamic Host Configuration Protocol. It's basically shouting out, Hello, 330 00:16:48.440 --> 00:16:49.879 is there a DHGP server out there? 331 00:16:49.879 --> 00:16:50.840 I need an IP address? 332 00:16:51.159 --> 00:16:54.039 I mean your home rotor usually has a DHCHGPP server 333 00:16:54.080 --> 00:16:57.240 running on it. Here's this broadcast discovered message. The rotter 334 00:16:57.279 --> 00:16:59.559 then looks at this pool of available private LP addresses 335 00:16:59.600 --> 00:17:01.919 that it's allowed to assign. It picks one and sends 336 00:17:01.960 --> 00:17:05.039 back at DHGP offer message directly to your laptop using 337 00:17:05.039 --> 00:17:08.160 its Hondwa address. Initially, this message says, hey, laptop, I'm 338 00:17:08.160 --> 00:17:10.480 a DHCP server. How about you use this IP address, 339 00:17:10.480 --> 00:17:12.400 say one ninety two point one six eight point one 340 00:17:12.599 --> 00:17:14.640 zero one for the next twenty four hours, and here's 341 00:17:14.680 --> 00:17:17.279 the address of the gateway ROTA and the DNS server. Two. 342 00:17:18.240 --> 00:17:20.440 Your laptop perceeeds this offer and typically sends back a 343 00:17:20.680 --> 00:17:24.880 DGP request message saying okay, sounds good, I'll take that address. Finally, 344 00:17:24.920 --> 00:17:28.200 the roater sends back at DHGP ack and acknowledgment confirming 345 00:17:28.200 --> 00:17:28.720 the assignment. 346 00:17:28.880 --> 00:17:33.000 Great, that addresses yours for the least duration. And often 347 00:17:33.039 --> 00:17:36.119 this involves what our source calls a self learning switch 348 00:17:36.400 --> 00:17:39.440 inside your router. That switch quickly learns which physical port 349 00:17:39.440 --> 00:17:41.759 your laptop is connected to, even wirelessly, so it can 350 00:17:41.759 --> 00:17:45.319 deliver that final DHCP ACK directly to your laptop, not 351 00:17:45.400 --> 00:17:49.079 broadcast it unnecessarily. So now your laptop has its unique 352 00:17:49.079 --> 00:17:51.640 IP address, It knows the router's address, the gateway, and 353 00:17:51.680 --> 00:17:54.319 it knows the address of a DNS server. Then when 354 00:17:54.359 --> 00:17:57.480 you type a web address like www dot Google dot com, 355 00:17:57.680 --> 00:18:01.119 your laptop uses DNS usually over US, to ask the 356 00:18:01.200 --> 00:18:04.680 DNS server what's the IP address for www dot Google 357 00:18:04.680 --> 00:18:07.359 dot com. Once it gets the IP address back, your 358 00:18:07.359 --> 00:18:10.200 browser can initiate a TCP connection using that three way 359 00:18:10.200 --> 00:18:13.000 handshake we mentioned to Google server at that IP address. 360 00:18:13.400 --> 00:18:16.160 Once the TCP connection is established, your browser sends an 361 00:18:16.240 --> 00:18:19.400 htpadt request over that connection, asking for the web page. 362 00:18:19.680 --> 00:18:22.200 Google server sends back the web page content again using 363 00:18:22.279 --> 00:18:26.119 HTTP over TCPIP. Your browser receives it, renders it, and boom, 364 00:18:26.160 --> 00:18:28.480 you see the Google home page. It's really a beautifully 365 00:18:28.559 --> 00:18:32.720 orchestrated sequence evolving multiple protocols across multiple layers, all happening 366 00:18:32.720 --> 00:18:34.279 in fractions of a second. 367 00:18:34.400 --> 00:18:36.720 That really does make the invisible visible, doesn't it? 368 00:18:36.720 --> 00:18:40.000 Seeing how DHTP, DNS, TCP, IPHDGP all. 369 00:18:39.880 --> 00:18:43.039 Play their part just to load one page amazing. Okay, 370 00:18:43.119 --> 00:18:44.319 let's shift gears slightly. 371 00:18:44.599 --> 00:18:46.880 Let's talk about wireless networks like the Wi Fi we 372 00:18:46.920 --> 00:18:49.880 all rely on so heavily now. It feels so seamless 373 00:18:49.920 --> 00:18:52.559 most of the time, But you mentioned earlier wireless communication 374 00:18:52.640 --> 00:18:55.119 is inherently more complex than just plugging in a wire. 375 00:18:55.559 --> 00:18:57.319 Why is that? What are the main challenges? 376 00:18:57.559 --> 00:19:02.119 Yeah? Wired connections like Ethernet cables their relatively contained, shielded 377 00:19:02.200 --> 00:19:06.880 and predictable environments. Wireless, though, it's a much much trickier 378 00:19:06.960 --> 00:19:10.759 environment to communicate reliably. In your radio signals as they 379 00:19:10.759 --> 00:19:13.640 travel through the air are constantly battling a whole host 380 00:19:13.680 --> 00:19:16.640 of impairments. There's a tenuation, which just means the signal 381 00:19:16.720 --> 00:19:20.160 naturally gets weaker the further it travels, pretty intuitive. Then 382 00:19:20.160 --> 00:19:23.680 there's multipath propagation. This is where the radio signals bounce 383 00:19:23.680 --> 00:19:27.640 off walls, furniture, people, other objects, so the receiver doesn't 384 00:19:27.680 --> 00:19:30.759 just get the direct signal, it gets multiple reflected copies 385 00:19:30.880 --> 00:19:33.759 arriving at slightly different times, and these can interfere with 386 00:19:33.799 --> 00:19:37.680 each other, sometimes constructively, sometimes destructively, causing fading or distortion. 387 00:19:38.279 --> 00:19:41.400 And on top of all that, there's just omnipresent background 388 00:19:41.400 --> 00:19:45.319 noise interference from other Wi Fi networks, microwave ovens, bluetooth devices, 389 00:19:45.319 --> 00:19:47.519 cordless phones, all sorts of stuff operating in the same 390 00:19:47.559 --> 00:19:50.559 frequency bands. This is why metrics like signal to noise 391 00:19:50.640 --> 00:19:53.799 ratio or SNR and bit error rate or b error 392 00:19:53.880 --> 00:19:57.599 are so absolutely crucial for understanding and measuring wireless performance. 393 00:19:57.839 --> 00:19:59.720 It really is like trying to have a perfectly clear 394 00:19:59.720 --> 00:20:04.279 commentversation in a very noisy echoe room, much harder than 395 00:20:04.319 --> 00:20:05.880 talking through a direct private. 396 00:20:05.599 --> 00:20:08.680 Tube that makes sense a noisy echoe room. And because 397 00:20:08.720 --> 00:20:11.319 of those specific challenges, Wi Fi, which is based on 398 00:20:11.359 --> 00:20:14.400 the IEE eight to two point one standard, it has 399 00:20:14.440 --> 00:20:17.599 to use a fundamentally different approach to avoiding collisions. Right 400 00:20:18.039 --> 00:20:20.519 compared to old school wired Ethernet, How does Wi Fi 401 00:20:20.559 --> 00:20:23.440