Week 6

Each of these rows is like a student in the audience between David and Dan, who passed the message along.

On line 2 we see the domain name typed in, and 23.209.73.59 is apparently the IP address of www.mit.edu that the computer figured out using DNS. We’re also going to limit ourselves to 64 hops, or by going through no more than 64 servers between us and MIT.

Then each row is a router, with the first being the amusingly named Yale central router "arubacentral", which appears to be on a virtual local area network (VLAN).

The next router has no name, just some private (because it starts with 10.#.#.#) IP address.

In the middle, steps 4 & 5, we go to routers with "jfk" and "nyc" in their names. It’s common to name routers after the nearest airport code or major cities.

Finally, the actual domain name for www.mit.edu, seems to indicate a server that’s part of a company called Akamai that they’ve outsourced server hosting to. This means that their website might not even be hosted in Cambridge (although as it turns out, Akamai is also based in Cambridge).

In step 5, we can see that one of the routers didn’t send us a full response (usually for privacy reasons).

If we look at steps 7 and 8, it suddenly took a lot longer to get a response from those servers - because we’ve crossed an ocean!

But here, despite the number of hours it would take to fly to Japan, our message took under than 200 milliseconds to send.

This is a really big piece of data, and we don’t want to stop all the other traffic on the Internet, so we’re going to break it up into smaller pieces to send to Cole. We place each one into different envelopes, labeling them 1 of 4, 2 of 4, 3 of 4, and 4 of 4. Each envelope is addressed to Cole, and says it’s from David.

But what if one router is broken or is powered off, and a packet doesn’t make it to Cole?

TCP, or Transmission Control Protocol, is another protocol used with IP on the Internet (you may have seen TCP/IP), which guarantees delivery. TCP tells computers to send a packet back - a message from Cole to David - telling him which packets in the original message were missing, since they were all numbered.

21 FTP
25 SMTP
53 DNS
80 HTTP
443 HTTPS

For example, FTP, file transfer protocol, was assigned a unique identifier of 21 some years ago.

SMTP, for outbound email, is 25.

And you may have seen that HTTP, web traffic, and HTTPS, secure web traffic, use 80 and 443. (Our web browsers append these port numbers to the ends of domain names for us so we don’t have to specify which port, but if you append :80 to most web addresses, you’ll end up in the same place.)

We could imagine trying to prevent access to a site by changing its listing in our DNS server to an incorrect IP address, but then someone could gain access by going directly to the correct IP address, or by changing their DNS server settings (e.g., to 8.8.8.8, Google’s DNS server).

This lets you circumvent firewall restrictions, because all your traffic first goes to this server elsewhere, and where it goes after that isn’t visible to the router that’s maintaining the firewall because it’s encrypted.

You can also use a VPN if you’re using unencrypted WiFi, to prevent someone else on the unsecure network from listening to all your traffic.

This does slow your connection down, since there could be a significant distance between you and the VPN server, and between the VPN server and the site you’re trying to access.

The client is your machine that asks for information, and the server is the machine that responds with information.

This simple message would be opened by the server on the other side, which then responds accordingly.

The / right after GET is just asking for the root directory, or the highest directory. To properly visit a website, we should really be typing http://www.facebook.com/ with that final / meaning we want the root of the hard drive, or the default page.

The next part, HTTP/1.1, means that we’re using version 1.1 of HTTP to talk to the server.

The first line is confirming that we’re using version 1.1 of HTTP to communicate, and 200 is a status code that means OK: the server has the page we’re looking for.

The second line is telling the web browser that you’re getting back a webpage of the type text/html (as opposed to an image or video, for example).

And then the …​ is the actual message that the server responds with.

…​and we still get the exact same page of results.

This is equivalent to sending the following request:

GET /search?q=cats HTTP/1.1
Host: www.google.com
...

What if we’re logging into a website and we type in our password? We don’t want that to show up in the address bar (where it’s visible to someone walking behind us, it’ll be remembered by our browser, and it’s visible to the DNS server).

If we’re uploading a photo, or some other kind of information that doesn’t lend itself well to representation as a text string, we might have a problem.

This gives the inputs email=malan@harvard.edu and password=12345 to Facebook’s login.php (the program, written in PHP, that allows users to log in). But now, instead of those parameters being part of the URL as they were before, they’re "inside the envelope", so to speak — they’re in the message rather than in the header.

Assuming Facebook is using HTTPS, this is encrypted, making it a secure way to pass things like passwords to the web server.

It does nothing other than display hello, world, and we notice that the first line declares this piece of code as using HTML, followed by various tags beginning with < and ending with >.

Notice that we type out </html>, closing the tag, ahead of time, and remember to put everything else inside those tags.

Notice that the body is the large white space, and the title is at the top of the tab.