Day 3

On tonight’s assignment, we’ll be asking a question about how long you’d like class to be, now that you have an idea of how dense the material is and how long two hours feels like, so please provide us feedback!

For tomorrow, we’ll try to be done around 2:35pm, as we introduce some web development (HTML and CSS) and a web-based IDE (integrated development environment) that lets you use a real server!

A note from a student, who works part time as a Product Manager, happened to talk to some engineers the other day about storage. They talked about how a "float", a data type for storing floating-point values, is not efficient for storing prices. They actually use a "bigint", big integer, and just divide by 100 to represent an actual price. So this is a good opportunity to talk about data types.

A computer has a finite number of bits in memory. And there are infinitely many real numbers, so we might run into a problem with precision, since we can’t possibly represent all numbers with a limited amount of bits.

Let’s take a look at this program, written in C:

1#include <stdio.h>
2
3int main(void)
4{
5    float f = 1.0 / 10.0;
6    printf("%.1f\n", f);
7}

So in theory, this should print 0.1, and after we compile and run it, we do see 0.1.

We watch a few clips from TV shows where fancy technical terms are jumbled together, but don’t actually mean anything.

In one of the clips, a screen has the following in the address bar:

http://275.3.6.28

This looks like a real IP address, but isn’t. (Almost) every computer on the Internet has an IP address, to identify its location, and is a set of 4 bytes. So each number has 8 bits, which means that the 275 in the screenshot isn’t in the range of real IP addresses.

But when we go on the Internet, we don’t normally type in these numbers. Instead, we have domain names like www.facebook.com that maps to these numbers.

In a typical home, we might find the following:

But how do we actually connect to the Internet? Our ISP gives us an IP address, which we need to share with multiple computers somehow, and we also need to find the IP address of a server just by typing in a domain name.

So there’s a Domain Name System, DNS, that keeps track of these conversions. When someone buys a domain name, they tell some central authority what their IP address is, and ISPs like Comcast will have copies of the DNS database that match IP addresses to domain names.

And there’s a hierarchy as a result of caching, where IP addresses you looked up recently are stored nearby (whether on your laptop, the router, or the ISP’s DNS server) for some amount of time, so it doesn’t take forever to look them up again.

Now that we have the IP address of the server, we need our own so that they can send us information back.

Dynamic Host Configuration Protocol (DHCP) is the fancy term for how computers acquire IP addresses. Essentially, there are servers that your computer can talk to, to ask for an IP address.

Let’s put this a little more concretely. David has a printed picture of a cat that he wants to send to Dan, who’s at the back of the room.

Since picture files are pretty big, we’ll tear the picture and send it as chunks.

David puts each chunk into an envelope, with his name in the From: field and Dan’s name in the To: field.

He passes the envelopes to people nearby, who represent routers, and eventually the envelopes all get to Dan.

On the Internet, each number in an IP address tells every server in between which direction to send the packet (like an envelope) to, and eventually they’ll get to the person they were intended for.

There are also lots of paths that could be taken, that would eventually reach the destination, so if some servers went down data could still be sent.

Some routers on the Internet could also get too many packets and once, and that means some will get dropped.

The envelopes, too, were numbered 1 out of 4, 2 out of 4, etc., so even if they arrived out of order the person at the other end can reassemble the picture or message correctly.

We can actually run a program in our command line called traceroute that tells us the route our packets took:

% traceroute -q 1 www.mit.edu
traceroute to www.mit.edu (172.230.86.119), 30 hops max, 40 byte packets
 1  mr-sc-1-gw-vl-3085-fas.net.harvard.edu (140.247.89.129)  0.673 ms
 2  10.240.143.25 (10.240.143.25)  1.053 ms
 3  coregw1-vl-416-fas.net.harvard.edu (140.247.2.65)  0.842 ms
 4  bdrgw1-te-4-2-core.net.harvard.edu (128.103.0.18)  1.205 ms
 5  bst-edge-05.inet.qwest.net (63.145.1.133)  9.059 ms
 6  nyc-edge-04.inet.qwest.net (205.171.30.62)  6.854 ms
 7  a172-230-86-119.deploy.static.akamaitechnologies.com (172.230.86.119)  6.998 ms

That was pretty fast, with www.mit.edu just 7 physical routers away.

It looks like www.mit.edu was translated with DNS to an IP address first, 172.230.86.119, and we see that the first place we sent our packet to looks like server from Harvard FAS, with mr and sc referring to Science Center Machine Room, and gw meaning "gateway."

Then the next one doesn’t have a name, and the third is another Harvard FAS server, which seems to be a more important "core" gateway.

The fourth one is probably a "border" gateway, maybe toward the outside of Harvard’s network, and it looks like that connects to an ISP called Qwest, first to a server in Boston, and then in NYC. Then it goes to a server owned by Akamai Technologies.

So it seems that MIT’s website aren’t on servers near them, but rather somewhere in the cloud, hosted by a third party.

We can run another command:

% whois mit.edu
...
Domain Name: MIT.EDU

Registrant:
   Massachusetts Institute of Technology
   77 Massachusetts Ave
   Cambridge, MA 02139
   UNITED STATES

Administrative Contact:
   Mark Silis
   Massachusetts Institute of Technology
   MIT Room W92-167, 77 Massachusetts Avenue
   Cambridge, MA 02139-4307
   UNITED STATES
   (617) 324-5900
   mark@mit.edu

Technical Contact:
   MIT Network Operations
   Massachusetts Institute of Technology
   MIT Room W92-167, 77 Massachusetts Avenue
   Cambridge, MA 02139-4307
   UNITED STATES
   (617) 253-8400
   noc@mit.edu

Name Servers:
   USE2.AKAM.NET
   USE5.AKAM.NET
   USW2.AKAM.NET
   ASIA1.AKAM.NET
   ASIA2.AKAM.NET
   EUR5.AKAM.NET
   NS1-173.AKAM.NET
   NS1-37.AKAM.NET

Domain record activated:    23-May-1985
Domain record last updated: 17-May-2013
Domain expires:             31-Jul-2015

This command, whois, asks the root servers, or the central, highest authority on who owns which domain names.

These root servers actually don’t know the actual IP addresses, but rather points to name servers that would know. In MIT’s case, since their site is hosted by a company called Akamai, the name server records point to those servers.

We can run this command again:

% whois google.com
...
Name Server: ns1.google.com
Name Server: ns2.google.com
Name Server: ns3.google.com
Name Server: ns4.google.com
...

So Google has its own DNS servers,

If a website changes web hosts or servers, it might be some time before that change is reflected everywhere, so some people might still get an outdated IP address that no longer works. To minimize this, we might configure the "expiration date," or TTL (time to live) of our domain name to be a shorter time. That way, when the information is updated, servers in between will only cache the old information for a small amount of time before it gets the new information.

DNS poisoning is an attack where a country, or some group in control of those central servers, returns the wrong answer to DNS lookups, and redirects traffic to their servers, or taking entire websites offline by returning something like "site not found."

Some ISPs would also do this, but only for invalid URLs that had no legitimate entries. Instead, they would take you to pages with advertisements somehow related to that invalid URL.

If we go to the actual IP address of some domain name, it should generally bring us to the website (unless multiple websites are sharing the same server with the same IP address, in which case we need to ask it for the website we want in a more sophisticated way).

DNS entries are cached so future visits are faster, even if we risk having outdated entries for some amount of time.

We can also do something like this:

% traceroute -q 1 www.cnn.co.jp
traceroute to www.cnn.co.jp (103.4.202.6), 30 hops max, 40 byte packets
 1  mr-sc-1-gw-vl-3085-fas.net.harvard.edu (140.247.89.129)  0.838 ms
 2  10.240.143.25 (10.240.143.25)  1.181 ms
 3  coregw2-te-8-4-core.net.harvard.edu (140.247.2.37)  1.206 ms
 4  bdrgw2-te-4-2-core.net.harvard.edu (128.103.0.2)  1.670 ms
 5  bst-edge-05.inet.qwest.net (63.145.1.133)  1.357 ms
 6  pax-brdr-01.inet.qwest.net (205.171.234.102)  70.169 ms
 7  ae-4-90.edge1.SanJose2.Level3.net (4.69.152.199)  72.607 ms
 8  pajbb002.int-gw.kddi.ne.jp (111.87.3.37)  71.403 ms
 9  pajbb002.int-gw.kddi.ne.jp (111.87.3.101)  73.096 ms
10  tm4BBAC01.bb.kddi.ne.jp (106.162.175.26)  176.763 ms
11  182.248.216.222 (182.248.216.222)  171.354 ms
12  14.0.32.62 (14.0.32.62)  168.432 ms
13  103.4.202.6 (103.4.202.6)  174.038 ms

Here we’re connecting to Japan’s edition of CNN. That was still pretty fast, but we do see more routers in between, and longer reponses times in the hundreds of milliseconds.

Router 7 in particular seems interesting, it looks like our packet passed through San Jose, and in between router 9 and 10 we seem to have crossed the Pacific Ocean, since the response time increased so much. Routers 8 and 9 ended in .jp, but the company that owned them might just have some US servers.

There are all of these hops because we just don’t have that many direct connections. (It’s sort of like how railroad tracks go from major city to major city, and even though we can’t possibly lay down tracks between every pair of cities, there’s always a connection we can take to get between them.)

CS50 actually recently signed up for an Amazon service called Direct Connect that allows our servers to have a more direct connection, with fewer hops, to Amazon’s cloud servers, so we get better performance, at a cost of money.

Net neutrality is related, as there is a question (in simple terms) of whether ISPs should be allowed, while routing, to give priority to packets from, say, Skype, or Google Hangouts, if those companies are paying them.

And typically, the size of a packet is something like 1000 to 2000 bytes, although the maximum size can be configurable within each individual network.

It happens to be that certain companies or geographies get IP addresses, and even though the boundaries aren’t strict these days with so many mobile devices, there are still some loose assignments.

For example, Harvard’s pool of IPs start with the following:

140.247.#.#
128.103.#.#
...

Private IPs are reserved for devices on your local network,a nd not accessible by the Internet at large:

10.#.#.#
172.16.#.# – 172.31.#.#
192.168.#.#

This helps solve the problem of sharing one public IP address among the multiple devices in your home, with a technology called NAT, network address translation.

Your router keeps track of which packets are from which device internally, even though they are all sent out and come back in with the same public IP address.

If we think about how many bits are in an IP address, there are only 32, meaning that there are only 4 billion total, with some reserved for private addresses. So when we run out, we’ll have to switch to a new version called IPv6 with 128 bit addresses. DNS servers can already return these longer addresses, but only some websites have adopted it.

Companies and universities might also give out private IPs to users within the network, so they only take up one public IP.