Internet & Networking Terminology

[00:00:00]
>> So in all these tools, I was using kind of these weird phrases called TCP and UDP. So what am I talking about exactly? So TCP stands for transmission control protocol. Again, I nternet's built on rules and cooperation, internet protocols, one, transmission control protocol is the other one, TCP/IP.

[00:00:21]
Most packets are going to be TCP packets. The other type of packet we're gonna run into is called a UDP, the User Datagram Protocol. And you're saying, Jim, why do I care about any of this stuff? I'm a front engineer. Blah, blah, blah, you're handsome. Well, TCP is always gonna be the most reliable connection.

[00:00:41]
TCP, actually I have this on the next slide. TCP has what's called the handshake. So I send a SYN, which is a the type of the packet that I'm gonna send, and said, I'm sending you something. The server is gonna say SYN ACK, I acknowledge your request and I'm gonna send you back.

[00:01:00]
Then I acknowledge that they acknowledged me. And we do this millions and millions and millions and millions of times. TCP is extremely reliable. It was invented because the internet in the early days and even now is really unreliable. Remember how it takes 20 hops to get to Google?

[00:01:18]
How do we know? Who's enforcing that these hops are actually taking place? What if something goes down and we have to reroute? How then does the server know how to talk back to me? Or what if one router is only allowing inbound traffic, but it's not allowing the outbound traffic?

[00:01:31]
How do those responses get back to me? It's all done through the magic of TCP. TCP is like, hey, bro, I'm sending you a file. I'm like, cool. I'll receive the file in the service like, cool. I'm glad you're gonna receive that file. And then it sends me the file and I can say, hey, I got 90% of that file, but these packets are missing, this chunk of the file is missing.

[00:01:54]
And the server will say, okay, let me resend those. And I will keep resending and retrying until everything is done and the connection is complete. TCP does that for us. It's very reliable. It has a lot of redundancies built in to make sure that the data is getting where it needs to go.

[00:02:12]
And we need to because the Internet's complicated, there's a lot of ways it can go sideways. UDP on the other hand, does not care. UDP is, hey, you need a file, catch. If you catch it or not, who knows? But it doesn't really care. UDP is a one way.

[00:02:27]
It's just gonna spray data at you. So why does that matter? Why do we use TCP and versus UDP? Why do we have these protocols? Well, one, anyone wanna take a guess?
>> Depends on the what you're trying to send and whether it needs to respond one after another or it can be kind of assembled after the fact?

[00:02:51]
>> Yeah, so the answer there was it depends on what you're trying to send, if it can be reassembled after the fact. What else would we use? Why would we care if the connection actually made it?
>> I mean for something like streaming video, if you receive a frame out of order, you're not gonna go back and replay that one frame when it's out of order.

[00:03:16]
So UDP is usually just good for sending real-time type stuff where it doesn't matter if it gets a few drops here and there.
>> Yeah, that's exactly right. UDP is useful for streaming video. And where it doesn't matter if you lose a couple packets along the way. Yes, question mark.

[00:03:37]
>> UDP is faster, better for real time data like wipe and video.
>> Yeah, exactly right. Something streaming streaming music, streaming video where if you do lose a couple of frames in there, it's not the end of the world. It's totally fine. You ever wonder why your video sometimes gets blurry when you're real time chatting?

[00:03:59]
That's because UDP. UDP is just sending you data, sending you data with the assumption that yeah, you're probably getting it. Dont really care if you're not, we're just gonna keep sending it until yours has stopped or connection is closed. Whereas TCP is much slower, it's much more reliable.

[00:04:15]
You can run video chat over TCP, but because video chat is actually very or video streaming or music streaming is very bandwidth-intensive. Running it over TCP is gonna be very expensive and it'll take up a lot more bandwidth than is necessary, versus UDP. But if I had, say, I don't know, a webpage, I'm not gonna send it over UDP because I need every single one of those bytes to be reassembled in the correct order to make sure my webpage comes together.

[00:04:40]
So that's why these two different protocols exist. Different purposes, different complexities. It's a trade off between the two. And there's something called ICMP Internet Control Message Protocol that's built over either TCP or UDP. Generally we send over TCP but it doesn't really matter. It's just a protocol on top of the other ones.

[00:05:00]
That's how pain works. That's how traceroute works. These are just The Internet Control Message Protocol just saying like, hey, what time is it? Or hey, are you still there? We're not sending data. It's just checking into the server itself. They don't actually provide any useful information to us itself.

[00:05:18]
Just yeah, more in the network tool side. And then all this happens at a packet level. A packet is the smallest unit of unit of data that can be transmitted over a network. Everything whether it's UDP or TCP operates running through a packet. We won't go into packets, that is a whole, that was, I don't know, like a few weeks in my computer science education.

[00:05:46]
But we won't go into packets, but packets are really interesting how they are composed. How they say, hey, I'm gonna send you a 10 gigabyte file or something like that. How are those broken down into packets that are really, really tiny chunks of information, sometimes kilobytes, sometimes smaller, bigger.

[00:06:02]
There's a whole protocol and standards for doing that. The fun thing about ICMP in the early days there's something called the ping of death. Which is, and I'll admit, I was not a good person before. Still not a good person today but I was less a good person when I was younger and into computers but maybe is how I got good at them.

[00:06:21]
But I could spin on my computer, I could ping somebody because every time I ping someone they have to respond back with a pong. So ping pong, ping pong, ping pong. I could fire off a thousand pings in real life much more than that. And they have to respond every time, but every time they respond it's using just a little bit of their CPU.

[00:06:40]
So it's possible in the old days to just ping somebody and get all of your buddies to ping a website and just take it down very easily just using ping, cuz you're forcing the computer to respond every single time. That's no longer a thing we can deal with pings of death.

[00:06:54]
Another trick was with even with pings was, I'm gonna ping you from my IP address but I'm gonna spoof that header in the packet and say it's actually coming from this address. So I can say ping google.com or something like that. Google's gonna respond with a pong to an entirely different IP address.

[00:07:13]
So I can flood a victim or someone I'm trying to go after, trying to take down, and I'm not even doing it. I'm just telling another server to do it. And we actually see a lot of, we don't see this as much anymore, cuz we have ways of mitigating that.

[00:07:25]
But we see that a lot with unpatched routers, things like that used for DDoS attacks were DDoS is a Distributed Denial-of-Service attack or just flooding computer. These days it's most often caused by hacked servers or misconfigured routers somewhere along the way. Okay, we talked about TCP UDP, the handshake and all this is courtesy of Cloudflare.

[00:07:46]
Cloudflare has excellent breakdowns of really complex networking diagrams, things like that, and they explain it in really plain terms so check out that link if you want have even more. And the Internet is built on the TCP/IP standard. We all collectively agree every single piece of hardware, every single piece of networking equipment agrees on these protocols and putting them all together.

[00:08:13]
And again, fascinating we've come to this consensus without anybody making us do it.