The Internet: Crash Course Computer Science #29

Hi, I'm Carrie Anne, and welcome to CrashCourse Computer Science!

As we talked about last episode, your computer is connected to a large, distributed network, called The Internet.

I know this because you're watching a youtube video, which is being streamed over that very internet.

It's arranged as an ever-enlarging web of interconnected devices.

For your computer to get this video, the first connection is to your local area network, or LAN, which might be every device in your house that's connected to your wifi router.

This then connects to a Wide Area Network, or WAN, which is likely to be a router run by your Internet Service Provider, or ISP - companies like Comcast, AT&T or Verizon.

At first, this will be a regional router, like one for your neighborhood, and then that router connects to an even bigger WAN, maybe one for your whole city or town.

There might be a couple more hops, but ultimately you'll connect to the backbone of the internet made up of gigantic routers with super high-bandwidth connections running between them.

To request this video file from youtube, a packet had to work its way up to the backbone, travel along that for a bit, and then work its way back down to a youtube server that had the file.

That might be four hops up, two hops across the backbone, and four hops down, for a total of ten hops.

If you're running Windows, MacOS or Linux, you can see the route data takes to different places on the internet by using the traceroute program on your computer.

Instructions in the Doobly Doo.

For us here at the Chad & Stacey Emigholz Studio in Indianapolis, the route to the DFTBA server in California goes through 11 stops.

We start at 192.168.0.1 -- thats the IP address for my computer on our LAN.

Then there's the wifi router here at the studio, then a series of regional routers, then we get onto the backbone, and then we start working back down to the computer hosting "DFTBA dot com", which has the IP address 104.24.109.186.

But how does a packet actually get there?

What happens if a packet gets lost along the way?

If I type "DFTBA dot com" into my web browser, how does it know the server's address?

Those are our topics for today!

INTRO As we discussed last episode, the internet is a huge distributed network that sends data around as little packets.

If your data is big enough, like an email attachment, it might get broken up into many packets.

For example, this video stream is arriving to your computer right now as a series of packets, and not one gigantic file.

Internet packets have to conform to a standard called the Internet Protocol, or IP.

It's a lot like sending physical mail through the postal system - every letter needs a unique and legible address written on it, and there are limits to the size and weight of packages.

Violate this, and your letter won't get through.

IP packets are very similar.

However, IP is a very low level protocol - there isn't much more than a destination address in a packet's header, which is the metadata that's stored in front of the data payload.

This means that a packet can show up at a computer, but the computer may not know which application to give the data to; Skype or Call of Duty.

For this reason, more advanced protocols were developed that sit on top of IP.

One of the simplest and most common is the User Datagram Protocol, or UDP.

UDP has its own header, which sits inside the data payload.

Inside of the UDP header is some useful, extra information.

One of them is a port number.

Every program wanting to access the internet will ask its host computer's Operating System to be given a unique port.

Like Skype might ask for port number 3478.

When a packet arrives to the computer, the Operating System will look inside the UDP header and read the port number.

Then, if it sees, for example, 3478, it will give the packet to Skype.

So to review, IP gets the packet to the right computer, but UDP gets the packet to the right program running on that computer.

UDP headers also include something called a checksum, which allows the data to be verified for correctness.

As the name suggests, it does this by checking the sum of the data.

Here's a simplified version of how this works.

Lets imagine the raw data in our UDP packet is 89 111 33 32 58 and 41.

Before the packet is sent, the transmitting computer calculates the checksum by adding all the data together: 89 plus 111 plus 33 and so on.

In our example, this adds up to a checksum of 364.

In UDP, the checksum value is stored in 16 bits.

If the sum exceeds the maximum possible value, the upper-most bits overflow, and only the lower bits are used.

Now, when the receiving computer gets this packet, it repeats the process, adding up all the data.

89 plus 111 plus 33 and so on.

If that sum is the same as the checksum sent in the header, all is well.

But, if the numbers don't match, you know that the data got corrupted at some point in transit, maybe because of a power fluctuation or faulty cable.

Unfortunately, UDP doesn't offer any mechanisms to fix the data, or request a new copy - receiving programs are alerted to the corruption, but typically just discard the packet.

Also, UDP provides no mechanisms to know if packets are getting through - a sending computer shoots the UDP packet off, but has no confirmation it ever gets to its destination successfully.

Both of these properties sound pretty catastrophic, but some applications are ok with this, because UDP is also really simple and fast.

Skype, for example, which uses UDP for video chat, can handle corrupt or missing packets.

That's why sometimes if you're on a bad internet connection, Skype gets all glitchy - only some of the UDP packets are making it to your computer.

Skype does the best it can with the data it does receive correctly.

But this approach doesn't work for many other types of data transmission.

Like, it doesn't really work if you send an email, and it shows up with the middle missing.

The whole message really needs to get there correctly!

When it "absolutely, positively needs to get there", programs use the Transmission Control Protocol, or TCP, which like UDP, rides inside the data payload of IP packets.

For this reason, people refer to this combination of protocols as TCP/IP.

Like UDP, the TCP header contains a destination port and checksum.

But, it also contains fancier features, and we'll focus on the key ones.

First off, TCP packets are given sequential numbers.

So packet 15 is followed by packet 16, which is followed by 17, and so on... for potentially millions of packets sent during that session.

These sequence numbers allow a receiving computer to put the packets into the correct order, even if they arrive at different times across the network.

So if an email comes in all scrambled, the TCP implementation in your computer's operating system will piece it all together correctly.

Second, TCP requires that once a computer has correctly received a packet - and the data passes the checksum - that it send back an acknowledgement, or "ACK" as the cool kids say, to the sending computer.

Knowing the packet made it successfully, the sender can now transmit the next packet.

But this time, let's say, it waits, and doesn't get an acknowledgement packet back.

Something must be wrong If enough time elapses, the sender will go ahead and just retransmit the same packet.

It's worth noting that the original packet might have actually gotten there, but the acknowledgment is just really delayed.

Or perhaps it was the acknowledgment that was lost.

Either way, it doesn't matter, because the receiver has those sequence numbers, and if a duplicate packet arrives, it can be discarded.

Also, TCP isn't limited to a back and forth conversation - it can send many packets, and have many outstanding ACKs, which increases bandwidth significantly, since you aren't wasting time waiting for acknowledgment packets to return.

Interestingly, the success rate of ACKs, and also the round trip time between sending and acknowledging, can be used to infer network congestion.

TCP uses this information to adjust how aggressively it sends packets - a mechanism for congestion control.

So, basically, TCP can handle out-of-order packet delivery, dropped packets - including retransmission - and even throttle its transmission rate according to available bandwidth.

Pretty awesome!

You might wonder why anyone would use UDP when TCP has all these nifty features.

The single biggest downside are all those acknowledgment packets - it doubles the number of messages on the network, and yet, you're not transmitting any more data.

That overhead, including associated delays, is sometimes not worth the improved robustness, especially for time-critical applications, like Multiplayer First Person Shooters.

And if it's you getting lag-fragged you'll definitely agree!

When your computer wants to make a connection to a website, you need two things - an IP address and a port.

Like port 80, at 172.217.7.238.

This example is the IP address and port for the Google web server.

In fact, you can enter this into your browser's address bar, like so, and you'll end up on the google homepage.

This gets you to the right destination, but remembering that long string of digits would be really annoying.

It's much easier to remember: google.com.

So the internet has a special service that maps these domain names to addresses.

It's like the phone book for the internet.

And it's called the Domain Name System, or DNS for short.

You can probably guess how it works.

When you type something like "youtube.com" into your web browser, it goes and asks a DNS server - usually one provided by your ISP - to lookup the address.

DNS consults its huge registry, and replies with the address... if one exists.

In fact, if you try mashing your keyboard, adding ".com", and then hit enter in your browser, you'll likely be presented with an error that says DNS failed.

That's because that site doesn't exist, so DNS couldn't give your browser an address.

But, if DNS returns a valid address, which it should for "youtube.com", then your browser shoots off a request over TCP for the website's data.

There's over 300 million registered domain names, so to make that DNS Lookup a little more manageable, it's not stored as one gigantically long list, but rather in a tree data structure.

What are called Top Level Domains, or TLDs, are at the very top.

These are huge categories like .com and .gov.

Then, there are lower level domains that sit below that, called second level domains; Examples under .com include google.com and dftba.com.

Then, there are even lower level domains, called subdomains, like images.google.com, store.dftba.com.

And this tree is absolutely HUGE!

Like I said, more than 300 million domain names, and that's just second level domain names, not all the sub domains.

For this reason, this data is distributed across many DNS servers, which are authorities for different parts of the tree.

Okay, I know you've been waiting for it... We've reached a new level of abstraction!

Over the past two episodes, we've worked up from electrical signals on wires, or radio signals transmitted through the air in the case of wireless networks.

This is called the Physical Layer.

MAC addresses, collision detection, exponential backoff and similar low level protocols that mediate access to the physical layer are part of the Data Link Layer.

Above this is the Network Layer, which is where all the switching and routing technologies that we discussed operate.

And today, we mostly covered the Transport layer, protocols like UDP and TCP, which are responsible for point to point data transfer between computers, and also things like error detection and recovery when possible.

We've also grazed the Session Layer - where protocols like TCP and UDP are used to open a connection, pass information back and forth, and then close the connection when finished - what's called a session.

This is exactly what happens when you, for example, do a DNS Lookup, or request a webpage.

These are the bottom five layers of the Open System Interconnection (OSI) model, a conceptual framework for compartmentalizing all these different network processes.

Each level has different things to worry about and solve, and it would be impossible to build one huge networking implementation.

As we've talked about all series, abstraction allows computer scientists and engineers to be improving all these different levels of the stack simultaneously, without being overwhelmed by the full complexity.

And amazingly, we're not quite done yet...

The OSI model has two more layers, the Presentation Layer and the Application Layer, which include things like web browsers, Skype, HTML decoding, streaming movies and more.

Which we'll talk about next week.

See you then.