WEBVTT

1
00:00:00.080 --> 00:00:02.879
<v Speaker 1>Ever hit send on an email or type of website

2
00:00:02.919 --> 00:00:06.879
<v Speaker 1>address and just wonder what is actually happening. What's that

3
00:00:06.960 --> 00:00:13.800
<v Speaker 1>incredible invisible journey your data takes. Well, today we're diving

4
00:00:13.800 --> 00:00:15.400
<v Speaker 1>into that fascinating world.

5
00:00:15.679 --> 00:00:19.519
<v Speaker 2>It's a fundamental process. Really, it happens constantly. But those

6
00:00:19.559 --> 00:00:22.480
<v Speaker 2>first steps right inside your computer getting ready to go

7
00:00:22.519 --> 00:00:25.679
<v Speaker 2>onto the network, people often just skip over that.

8
00:00:25.839 --> 00:00:26.600
<v Speaker 1>Yeah, they totally.

9
00:00:26.800 --> 00:00:28.280
<v Speaker 2>We want to shed some light on that today.

10
00:00:28.359 --> 00:00:31.640
<v Speaker 1>That's exactly our mission for this deep dive. We're pulling

11
00:00:31.719 --> 00:00:35.240
<v Speaker 1>insights from the Guide to Networking Essentials seventh edition to

12
00:00:35.320 --> 00:00:38.479
<v Speaker 1>sort of illuminate those core bits and pieces. We want

13
00:00:38.479 --> 00:00:41.960
<v Speaker 1>to give you a shortcut, hopefully to understanding the magic,

14
00:00:42.159 --> 00:00:44.920
<v Speaker 1>maybe with a few aha moments along the way.

15
00:00:45.000 --> 00:00:48.520
<v Speaker 2>Definitely, we'll look inside the machine, how it connects physically,

16
00:00:48.640 --> 00:00:51.520
<v Speaker 2>the first gadgets your data bumps into just to give

17
00:00:51.520 --> 00:00:54.240
<v Speaker 2>you that solid foundation for how networks actually work.

18
00:00:54.600 --> 00:00:57.600
<v Speaker 1>Okay, let's unpack this then, before your data even thinks

19
00:00:57.640 --> 00:01:00.920
<v Speaker 1>about leaving your computer. There's a lot happening inside, isn't there?

20
00:01:01.280 --> 00:01:02.280
<v Speaker 1>With the core components?

21
00:01:02.320 --> 00:01:04.319
<v Speaker 2>Oh, absolutely, internal heavy lifting.

22
00:01:04.519 --> 00:01:07.519
<v Speaker 1>We all talk about the CPU, the brain, but the

23
00:01:07.560 --> 00:01:12.159
<v Speaker 1>source mentions most CPUs today are multiicore. What's the big

24
00:01:12.200 --> 00:01:12.920
<v Speaker 1>deal there.

25
00:01:12.719 --> 00:01:15.159
<v Speaker 2>Well, the guide uses a really neat analogy. Think of

26
00:01:15.200 --> 00:01:18.079
<v Speaker 2>it like having two brains instead of one. If you

27
00:01:18.120 --> 00:01:20.760
<v Speaker 2>had one brain, maybe you add four numbers one after

28
00:01:20.799 --> 00:01:22.920
<v Speaker 2>the other. One plus two is three, three plus three

29
00:01:23.040 --> 00:01:27.519
<v Speaker 2>is six. You get the idea sequentially exactly. But with

30
00:01:27.599 --> 00:01:30.040
<v Speaker 2>two brains, you could add the first pair one plus

31
00:01:30.120 --> 00:01:32.239
<v Speaker 2>two and at the exact same time add the second

32
00:01:32.239 --> 00:01:33.359
<v Speaker 2>pair three plus four.

33
00:01:33.560 --> 00:01:37.200
<v Speaker 1>Ah, so you get the result much faster parallel processing precisely.

34
00:01:37.439 --> 00:01:42.680
<v Speaker 2>Multicore CPUs execute multiple instructions truly simultaneously. That's a huge

35
00:01:42.719 --> 00:01:46.920
<v Speaker 2>boost for demanding tasks, gaming, video, editing, all that stuff.

36
00:01:47.000 --> 00:01:49.280
<v Speaker 1>That makes sense. It's not just faster, it's handling more

37
00:01:49.280 --> 00:01:52.359
<v Speaker 1>things at once. Okay, so the brain's working hard. Then

38
00:01:52.400 --> 00:01:57.439
<v Speaker 1>there's random access memory, the computer's short term or working storage.

39
00:01:57.519 --> 00:01:58.959
<v Speaker 2>Yep, absolutely crucial.

40
00:01:59.079 --> 00:02:01.319
<v Speaker 1>Why is it so critical? I mean, we have hard drives.

41
00:02:01.079 --> 00:02:05.439
<v Speaker 2>Too, because everything the CPU is actively working on the

42
00:02:05.480 --> 00:02:09.599
<v Speaker 2>program instructions, that's executing the data your application is manipulating

43
00:02:09.680 --> 00:02:11.800
<v Speaker 2>right now. It all has to be loaded into RAM,

44
00:02:12.039 --> 00:02:13.919
<v Speaker 2>has to be, has to be. If you don't have

45
00:02:14.039 --> 00:02:16.439
<v Speaker 2>enough RAM, the computer starts using the hard disc as

46
00:02:16.439 --> 00:02:20.280
<v Speaker 2>a temporary substitute. It's called swapping or paging, and that's bad.

47
00:02:20.520 --> 00:02:25.680
<v Speaker 2>It's slow. The guide really highlights this difference accessing RAM.

48
00:02:25.879 --> 00:02:30.599
<v Speaker 2>We're talking nanoseconds billionths of a second accessing a traditional

49
00:02:30.599 --> 00:02:34.120
<v Speaker 2>hard disc milliseconds thousandths of a second.

50
00:02:34.159 --> 00:02:36.560
<v Speaker 1>Okay, So nanoseconds versus milliseconds, it's.

51
00:02:36.520 --> 00:02:39.719
<v Speaker 2>Thousands of times faster in RAM, like comparing the speed

52
00:02:39.719 --> 00:02:42.240
<v Speaker 2>of a thought to maybe taking a slow walk down

53
00:02:42.280 --> 00:02:45.120
<v Speaker 2>the street. It's a night and day difference for performance, right.

54
00:02:45.280 --> 00:02:47.680
<v Speaker 1>I remember that feeling the computer just grinding when it

55
00:02:47.759 --> 00:02:50.360
<v Speaker 1>ran out of RAM. So having enough RAM is still

56
00:02:50.400 --> 00:02:51.639
<v Speaker 1>super important.

57
00:02:51.199 --> 00:02:54.199
<v Speaker 2>Absolutely fundamental for responsiveness.

58
00:02:53.400 --> 00:02:56.319
<v Speaker 1>And then for keeping stuff long term power off. You've

59
00:02:56.319 --> 00:02:59.360
<v Speaker 1>got the hard drive storing data magnetically.

60
00:02:59.439 --> 00:03:02.199
<v Speaker 2>Usually it's your persistent storage, yeah, the archive.

61
00:03:02.520 --> 00:03:06.840
<v Speaker 1>Okay, so you've got this really complex dance happening just

62
00:03:06.879 --> 00:03:09.800
<v Speaker 1>to get the data ready inside the machine. But how

63
00:03:09.800 --> 00:03:12.840
<v Speaker 1>does it actually get out? How does it jump from

64
00:03:12.879 --> 00:03:16.400
<v Speaker 1>the motherboard onto the network cable or the Wi Fi signal?

65
00:03:16.680 --> 00:03:19.400
<v Speaker 2>Ah? Well, that's where a very specific piece of hardware

66
00:03:19.439 --> 00:03:23.919
<v Speaker 2>comes in, the Network interface card or NIC. The NIC Okay, yep,

67
00:03:23.960 --> 00:03:26.280
<v Speaker 2>it's either an add on card you slot in or

68
00:03:26.360 --> 00:03:29.159
<v Speaker 2>much more commonly these days, it's just built right onto

69
00:03:29.199 --> 00:03:32.280
<v Speaker 2>the motherboard. It's the physical and logical bridge between your

70
00:03:32.280 --> 00:03:36.520
<v Speaker 2>computer and the network medium, the wire or the airwaves.

71
00:03:36.039 --> 00:03:38.879
<v Speaker 1>The bridge. I like that, and the source mentions something

72
00:03:38.919 --> 00:03:43.240
<v Speaker 1>really interesting. Yeah, called the NIC a gatekeeper for data

73
00:03:43.280 --> 00:03:44.360
<v Speaker 1>coming in. What does that mean?

74
00:03:44.520 --> 00:03:46.000
<v Speaker 2>Yeah, that's a great way to put it. It doesn't

75
00:03:46.039 --> 00:03:49.280
<v Speaker 2>just let any old data flood into your system. It's selective.

76
00:03:49.520 --> 00:03:49.840
<v Speaker 1>Also.

77
00:03:50.240 --> 00:03:52.680
<v Speaker 2>When a chunk of data called a frame arrives at

78
00:03:52.680 --> 00:03:56.159
<v Speaker 2>the NIC, the NIC looks at the destination address written

79
00:03:56.199 --> 00:03:58.599
<v Speaker 2>on it, specifically the destination.

80
00:03:58.240 --> 00:04:00.680
<v Speaker 1>M MASS address m MASS the address hardware.

81
00:04:00.360 --> 00:04:04.080
<v Speaker 2>Address right exactly that unique number burned into the NIC.

82
00:04:04.759 --> 00:04:08.120
<v Speaker 2>The NIC will only let the frame pass through if

83
00:04:08.159 --> 00:04:12.639
<v Speaker 2>that destination MSS address perfectly matches its own MS address.

84
00:04:12.719 --> 00:04:15.439
<v Speaker 1>Okay, so it's checking the mail looking for its specific name.

85
00:04:15.599 --> 00:04:18.759
<v Speaker 2>Pretty much. The only exceptions are if the frame is

86
00:04:18.800 --> 00:04:21.240
<v Speaker 2>addressed to the broadcast address, which is like shouting to

87
00:04:21.279 --> 00:04:22.959
<v Speaker 2>everyone on the local network.

88
00:04:22.600 --> 00:04:27.480
<v Speaker 1>Like ffffffffff that's the one in hext simal.

89
00:04:28.199 --> 00:04:29.560
<v Speaker 2>Or there's a special mode.

90
00:04:29.879 --> 00:04:31.000
<v Speaker 1>Uh oh, special mode.

91
00:04:31.079 --> 00:04:34.199
<v Speaker 2>It's called promiscuous mode. If you put an NIC into

92
00:04:34.240 --> 00:04:37.519
<v Speaker 2>promiscuous mode, it drops the gatekeeper role. It just lets

93
00:04:37.519 --> 00:04:40.399
<v Speaker 2>everything in. It processes all frames it sees on the wire,

94
00:04:40.759 --> 00:04:42.879
<v Speaker 2>regardless of the destination MSS.

95
00:04:43.240 --> 00:04:44.319
<v Speaker 1>Why would you want to do that?

96
00:04:44.600 --> 00:04:48.800
<v Speaker 2>Sounds risky, Well, it's essential for network troubleshooting. Tools like

97
00:04:48.879 --> 00:04:51.360
<v Speaker 2>wire Shark use it to capture all traffic on a

98
00:04:51.399 --> 00:04:52.879
<v Speaker 2>segment to see what's going wrong.

99
00:04:53.040 --> 00:04:55.360
<v Speaker 1>Ah, okay, for diagnostics, right.

100
00:04:55.319 --> 00:04:58.360
<v Speaker 2>But yes, it absolutely has security implications. Malware could try

101
00:04:58.360 --> 00:04:59.759
<v Speaker 2>to use it to sniff network traffic.

102
00:05:00.000 --> 00:05:02.680
<v Speaker 1>Shouldn't see, got it. So normally it's like a very

103
00:05:02.720 --> 00:05:05.120
<v Speaker 1>strict bouncer checking IDs.

104
00:05:05.000 --> 00:05:08.160
<v Speaker 2>A very specific bouncer. Yes, And that idea is the

105
00:05:08.319 --> 00:05:13.000
<v Speaker 2>MIIC address Media Access control address. Every single NIC has

106
00:05:13.000 --> 00:05:16.040
<v Speaker 2>a unique one forty eight bits long, usually written as

107
00:05:16.120 --> 00:05:19.639
<v Speaker 2>those twelve hexadecimal characters. It's burned in at the factory.

108
00:05:19.800 --> 00:05:23.560
<v Speaker 1>That uniqueness is key for knowing exactly which physical device

109
00:05:23.759 --> 00:05:25.680
<v Speaker 1>is which on your local network.

110
00:05:25.839 --> 00:05:28.279
<v Speaker 2>Absolutely fundamental for local communication.

111
00:05:28.480 --> 00:05:31.079
<v Speaker 1>Okay, so the data is prepped, it's passed through the

112
00:05:31.199 --> 00:05:35.319
<v Speaker 1>NIC's gate armed with its m MASSY address. Where does

113
00:05:35.360 --> 00:05:37.519
<v Speaker 1>it go next? It needs to connect to other computers.

114
00:05:37.600 --> 00:05:40.000
<v Speaker 2>Right now, we're talking about the local area network, the

115
00:05:40.120 --> 00:05:43.439
<v Speaker 2>land and connecting devices on the land. Usually involves a

116
00:05:43.519 --> 00:05:47.240
<v Speaker 2>central device. Most modern lands use what's called a physical

117
00:05:47.319 --> 00:05:51.079
<v Speaker 2>start topology start apology. Yeah, all the computers connect individually

118
00:05:51.120 --> 00:05:53.600
<v Speaker 2>to a central box, like points of a star. It's

119
00:05:53.600 --> 00:05:56.480
<v Speaker 2>replaced older ways because it's easier to manage upgrade and

120
00:05:56.519 --> 00:05:57.720
<v Speaker 2>supports faster speed.

121
00:05:57.839 --> 00:06:00.439
<v Speaker 1>That's central box. Back in the day, that was often

122
00:06:00.480 --> 00:06:02.560
<v Speaker 1>a hub, wasn't it What hubs actually do? Oh?

123
00:06:02.639 --> 00:06:05.800
<v Speaker 2>Hubs? Yeah, they were simple, very simple. Basically, a hub

124
00:06:05.879 --> 00:06:08.920
<v Speaker 2>is just a multiport repeater. It just takes the electrical

125
00:06:08.959 --> 00:06:11.600
<v Speaker 2>signal the bits coming in one port, cleans it up

126
00:06:11.639 --> 00:06:14.439
<v Speaker 2>a tiny bit, and blasts it out all the other ports.

127
00:06:14.959 --> 00:06:16.319
<v Speaker 2>No intelligence whatsoever.

128
00:06:16.399 --> 00:06:19.120
<v Speaker 1>It's like a loudspeaker shouting everything to everyone.

129
00:06:18.920 --> 00:06:23.759
<v Speaker 2>Exactly, which leads to the big problem bandwth sharing. If

130
00:06:23.800 --> 00:06:26.839
<v Speaker 2>you had ten computers connected to a one hundred megabit hub,

131
00:06:26.920 --> 00:06:28.720
<v Speaker 2>they all shared that hundred megabits.

132
00:06:29.000 --> 00:06:31.720
<v Speaker 1>If two talked at once, collision chaos.

133
00:06:31.759 --> 00:06:34.639
<v Speaker 2>You've got it, lots of collisions. Everything slows down, and

134
00:06:34.680 --> 00:06:37.279
<v Speaker 2>they only worked in half duplex. They could send or receive,

135
00:06:37.360 --> 00:06:39.120
<v Speaker 2>but not both at the same time. They're pretty much

136
00:06:39.120 --> 00:06:40.319
<v Speaker 2>obsolete now, thankfully.

137
00:06:41.279 --> 00:06:44.600
<v Speaker 1>So. The successor was the switch. How is a switch smarter?

138
00:06:45.000 --> 00:06:45.879
<v Speaker 1>What's the big leap?

139
00:06:46.199 --> 00:06:48.639
<v Speaker 2>Switches are much smarter. The key difference is that a

140
00:06:48.680 --> 00:06:52.600
<v Speaker 2>switch learns, it pays attention to the source MPAY address

141
00:06:52.639 --> 00:06:54.240
<v Speaker 2>of frames coming into each port.

142
00:06:54.399 --> 00:06:57.079
<v Speaker 1>Ah, it learns who lives where precisely.

143
00:06:57.360 --> 00:06:59.879
<v Speaker 2>It builds a little table often called a switching t

144
00:07:00.639 --> 00:07:05.360
<v Speaker 2>m MAC address table that MAPSMIC addresses to specific port numbers. Okay,

145
00:07:05.639 --> 00:07:08.120
<v Speaker 2>so when a frame comes in destined for a particular

146
00:07:08.199 --> 00:07:10.480
<v Speaker 2>m MAC address, the switch looks it up in its

147
00:07:10.519 --> 00:07:13.680
<v Speaker 2>table and forwards the frame only out the port connected

148
00:07:13.680 --> 00:07:15.160
<v Speaker 2>to that destination.

149
00:07:15.000 --> 00:07:17.839
<v Speaker 1>Not shouting anymore, just sending a direct message exactly.

150
00:07:18.279 --> 00:07:22.560
<v Speaker 2>This means no unnecessary traffic flooding the network. Each port

151
00:07:22.720 --> 00:07:26.839
<v Speaker 2>gets its own dedicated bandwidth, essentially its own collision domain, so.

152
00:07:26.959 --> 00:07:28.560
<v Speaker 1>No more collisions between ports.

153
00:07:28.560 --> 00:07:32.240
<v Speaker 2>Correct, and switches can operate in full duplex, send and

154
00:07:32.279 --> 00:07:36.839
<v Speaker 2>receive simultaneously on each port. It's a massive performance improvement,

155
00:07:37.199 --> 00:07:39.879
<v Speaker 2>and funny enough, they're usually cheaper than hubs now anyway,

156
00:07:40.000 --> 00:07:40.959
<v Speaker 2>because of mass production.

157
00:07:41.120 --> 00:07:43.879
<v Speaker 1>Makes sense. Okay, that covers wired connections, but what about

158
00:07:43.879 --> 00:07:47.920
<v Speaker 1>Wi Fi? We have wireless access points aps. Are they

159
00:07:47.959 --> 00:07:50.199
<v Speaker 1>just wireless hubs or wireless switches?

160
00:07:50.879 --> 00:07:55.279
<v Speaker 2>They serve that central connection point role yes, but wireless

161
00:07:55.319 --> 00:07:58.519
<v Speaker 2>is a whole different beast. The medium, the airwaves, is

162
00:07:58.560 --> 00:08:00.839
<v Speaker 2>inherently shared in a way that wires aren't.

163
00:08:01.000 --> 00:08:03.560
<v Speaker 1>Right. Everyone's trying to talk over the same air exactly.

164
00:08:03.959 --> 00:08:08.079
<v Speaker 2>So wired ethernet uses something called CSM maquet carrier sends

165
00:08:08.160 --> 00:08:12.560
<v Speaker 2>multiple access with collision detection. Listen first, then talk. If

166
00:08:12.600 --> 00:08:14.920
<v Speaker 2>you bump into someone else talking, you detect the collision,

167
00:08:15.000 --> 00:08:17.800
<v Speaker 2>back off and try again. Wireless can't reliably do the

168
00:08:17.839 --> 00:08:21.399
<v Speaker 2>detection part. A radio can't easily listen while it's transmitting.

169
00:08:21.720 --> 00:08:23.800
<v Speaker 2>It's kind of deafened by its own signal.

170
00:08:23.959 --> 00:08:27.199
<v Speaker 1>Ah, So how does it avoid just constant collisions?

171
00:08:27.319 --> 00:08:32.000
<v Speaker 2>It uses CSMAXI collision avoidance. It tries much harder not

172
00:08:32.080 --> 00:08:35.559
<v Speaker 2>to collide in the first place. Primarily, it requires an

173
00:08:35.600 --> 00:08:39.080
<v Speaker 2>acknowledgment for every single packet sent. If the sender doesn't

174
00:08:39.080 --> 00:08:42.440
<v Speaker 2>get an ack back quickly, it assumes the packet was lost,

175
00:08:42.639 --> 00:08:44.960
<v Speaker 2>maybe in a collision, and resends it.

176
00:08:45.039 --> 00:08:47.159
<v Speaker 1>Okay. That adds overhead it does.

177
00:08:47.080 --> 00:08:50.759
<v Speaker 2>And aps often use control signals like RTSCTS or request

178
00:08:50.879 --> 00:08:54.639
<v Speaker 2>to send and clear descend A device essentially asked permission,

179
00:08:54.759 --> 00:08:55.519
<v Speaker 2>can I talk now?

180
00:08:55.639 --> 00:08:56.480
<v Speaker 1>Like raising your hand?

181
00:08:56.759 --> 00:08:59.559
<v Speaker 2>Sort of The AP says, okay, coast is clear, you

182
00:08:59.600 --> 00:09:03.519
<v Speaker 2>can sent. This helps reserve the airwaves for one device.

183
00:09:03.159 --> 00:09:05.879
<v Speaker 1>At a time. So it's like that strict chairperson managing

184
00:09:05.879 --> 00:09:09.720
<v Speaker 1>the meeting. Lots of procedural talk before the actual message

185
00:09:09.759 --> 00:09:10.240
<v Speaker 1>gets through.

186
00:09:10.360 --> 00:09:13.720
<v Speaker 2>That's a great analogy. And all that extra chatter, the ACKs,

187
00:09:13.799 --> 00:09:18.039
<v Speaker 2>the rtscts. It means the effective bandwidth you actually get

188
00:09:18.039 --> 00:09:20.600
<v Speaker 2>for your data on Wi Fi is often only about

189
00:09:20.600 --> 00:09:22.159
<v Speaker 2>half of the advertised physical speed.

190
00:09:22.240 --> 00:09:24.639
<v Speaker 1>Wow. Half, that's significant, good to know.

191
00:09:25.039 --> 00:09:28.240
<v Speaker 2>Yeah, it's the price of managing that shared invisible medium.

192
00:09:28.559 --> 00:09:30.919
<v Speaker 1>Okay, so we followed the data from the CPU and

193
00:09:31.000 --> 00:09:34.440
<v Speaker 1>ram out the NIC through a switch or an AP.

194
00:09:35.080 --> 00:09:38.200
<v Speaker 1>But what does the data itself look like on this journey.

195
00:09:38.360 --> 00:09:40.919
<v Speaker 1>It can't just be one giant file flying around.

196
00:09:40.960 --> 00:09:43.879
<v Speaker 2>No, definitely not. That would be incredibly inefficient and prone

197
00:09:43.879 --> 00:09:47.480
<v Speaker 2>to errors. Large chunks of data are broken down. The

198
00:09:47.559 --> 00:09:50.120
<v Speaker 2>guide uses the example of a three minute music file

199
00:09:50.159 --> 00:09:53.480
<v Speaker 2>maybe three megabytes or three million bytes. Okay, that gets

200
00:09:53.519 --> 00:09:58.000
<v Speaker 2>chopped up into maybe two thousands smaller chunks or segments.

201
00:09:57.840 --> 00:10:01.399
<v Speaker 1>Like breaking a long speech into sentences said earlier, easier

202
00:10:01.399 --> 00:10:01.799
<v Speaker 1>to handle.

203
00:10:02.000 --> 00:10:05.200
<v Speaker 2>Exactly makes it manageable. Now, when one of these chunks

204
00:10:05.200 --> 00:10:08.519
<v Speaker 2>is prepared to be sent across different networks like the Internet.

205
00:10:08.639 --> 00:10:11.720
<v Speaker 2>It gets wrapped up with source and destination IP addresses.

206
00:10:11.919 --> 00:10:13.960
<v Speaker 2>Think of IP address as like the ZIP codes for

207
00:10:14.000 --> 00:10:14.480
<v Speaker 2>the Internet.

208
00:10:14.519 --> 00:10:16.039
<v Speaker 1>The general area is going to write.

209
00:10:16.360 --> 00:10:19.399
<v Speaker 2>At that point, that chunk plus the IP address is

210
00:10:19.440 --> 00:10:22.240
<v Speaker 2>called a packet. It's ready for routing across networks.

211
00:10:22.320 --> 00:10:25.360
<v Speaker 1>Packet, got it, But we talked about MC addresses for

212
00:10:25.399 --> 00:10:26.960
<v Speaker 1>the local delivery. Where did they fit in?

213
00:10:27.360 --> 00:10:30.320
<v Speaker 2>Ah, that's the next step to actually send the packet

214
00:10:30.320 --> 00:10:33.960
<v Speaker 2>over a specific local network link, like from your computer

215
00:10:34.000 --> 00:10:36.240
<v Speaker 2>to your router or from the router to the next hop.

216
00:10:36.279 --> 00:10:38.240
<v Speaker 2>The packet gets wrapped up again another layer.

217
00:10:38.440 --> 00:10:38.679
<v Speaker 1>Yep.

218
00:10:39.039 --> 00:10:42.120
<v Speaker 2>This time it gets the source and destination MS addresses

219
00:10:42.159 --> 00:10:45.360
<v Speaker 2>added to the front. Remember those are the specific hardware

220
00:10:45.360 --> 00:10:48.159
<v Speaker 2>addresses for the next hop on the journey. And critically,

221
00:10:48.320 --> 00:10:50.679
<v Speaker 2>it also gets an error checking code added to the end,

222
00:10:51.320 --> 00:10:55.120
<v Speaker 2>usually a CRC cyclic redundancy check. Error checking Yeah, it's

223
00:10:55.159 --> 00:10:58.320
<v Speaker 2>a calculation done on the data. The receiving device does

224
00:10:58.399 --> 00:11:02.320
<v Speaker 2>the same calculation. If the results don't match, it knows

225
00:11:02.360 --> 00:11:06.840
<v Speaker 2>the data got corrupted during transmission. Clever, So this whole thing,

226
00:11:07.000 --> 00:11:10.000
<v Speaker 2>the m messages at the front, the original packet with

227
00:11:10.039 --> 00:11:12.879
<v Speaker 2>this IQ addresses and data chunk in the middle and

228
00:11:12.919 --> 00:11:14.120
<v Speaker 2>the error check at the back.

229
00:11:14.159 --> 00:11:16.279
<v Speaker 1>That is called a frame a frame. So it's like

230
00:11:16.320 --> 00:11:19.320
<v Speaker 1>the packet gets put inside a local delivery envelope stamped

231
00:11:19.320 --> 00:11:22.039
<v Speaker 1>with the local MSc addresses and an error check seal.

232
00:11:22.360 --> 00:11:26.159
<v Speaker 2>Perfect analogy. The frame is what actually travels across the

233
00:11:26.200 --> 00:11:29.759
<v Speaker 2>ethernet cable or the Wi Fi signal for that specific hop.

234
00:11:29.759 --> 00:11:35.759
<v Speaker 1>And breaking it down like this chunks packets frames. That

235
00:11:35.799 --> 00:11:36.960
<v Speaker 1>makes air handling much.

236
00:11:36.799 --> 00:11:40.120
<v Speaker 2>Better, absolutely critical. If one frame gets corrupted, the receiver

237
00:11:40.279 --> 00:11:43.480
<v Speaker 2>knows immediately thanks to the CRC check, it can discard

238
00:11:43.519 --> 00:11:46.000
<v Speaker 2>that bad frame, and typically the sender just needs to

239
00:11:46.039 --> 00:11:48.840
<v Speaker 2>retransmit that one small frame, not the whole original file.

240
00:11:49.279 --> 00:11:52.279
<v Speaker 2>It makes data transfer vastly more reliable and efficient.

241
00:11:52.480 --> 00:11:55.559
<v Speaker 1>Wow. So when you put it all together, from the

242
00:11:55.600 --> 00:11:59.320
<v Speaker 1>CPU crunching numbers, RAM holding the data, the NIC acting

243
00:11:59.360 --> 00:12:03.639
<v Speaker 1>is a gatekeeper, or the switch intelligently directing traffic, or

244
00:12:03.679 --> 00:12:07.279
<v Speaker 1>the AP carefully managing the airwaves, all to send these

245
00:12:07.320 --> 00:12:10.080
<v Speaker 1>perfectly formatted frames. It's kind of amazing.

246
00:12:10.200 --> 00:12:12.960
<v Speaker 2>It really is an intricate dance of hardware and software

247
00:12:13.039 --> 00:12:16.480
<v Speaker 2>protocols and addresses happening billions, maybe trillions of times a

248
00:12:16.480 --> 00:12:19.039
<v Speaker 2>second across the globe. Usually it just works so seamlessly

249
00:12:19.080 --> 00:12:20.080
<v Speaker 2>you never even think about it.

250
00:12:20.159 --> 00:12:24.240
<v Speaker 1>Yeah you really don't. But understanding those fundamentals it demystifies

251
00:12:24.279 --> 00:12:25.919
<v Speaker 1>things a bit. You see the logic behind.

252
00:12:25.919 --> 00:12:27.799
<v Speaker 2>It makes the magic a little less mysterious.

253
00:12:27.840 --> 00:12:31.240
<v Speaker 1>Maybe exactly so, next time you hit send or click

254
00:12:31.279 --> 00:12:33.600
<v Speaker 1>that link, maybe take a second to picture that tiny

255
00:12:33.679 --> 00:12:39.759
<v Speaker 1>frame starting its journey, and maybe wonder what's the next evolution.

256
00:12:39.919 --> 00:12:42.720
<v Speaker 1>How are engineers making this even faster, even more reliable,

257
00:12:42.879 --> 00:12:45.399
<v Speaker 1>maybe even rethinking these layers entirely for the future.

258
00:12:45.639 --> 00:12:48.440
<v Speaker 2>That's the exciting part. The journey continues, and the innovation

259
00:12:48.639 --> 00:12:49.679
<v Speaker 2>never really stops.