[MUSIC PLAYING]
SPEAKER: You type an address into
a browser, you send an email,
you perhaps have a video
conference or a chat online.
Have you ever stopped
to consider what exactly
is going on underneath the hood, so
to speak, of those pieces of software?
And really the entire
infrastructure that somehow
connects you to the person or persons
with whom you're communicating.
Well it turns out that there's
a whole stack, so to speak,
of internet technologies that underline
the software that you and I use
these days, every day.
And indeed, the software
that we use, browsers
and email clients and the
like, are really abstractions,
very user friendly abstractions, on
top of some lower level implementation
details.
And these days, too, have we built
abstractions even above those so known
as the cloud, an abstraction on top
of this underlying infrastructure
that enables us to do most anything
we want computationally without even
having that hardware locally.
So let's see if we can't distill what
goes on when you do type an address
or a URL into the address bar
of a browser and then hit Enter.
Or you type out an email--
specify someone's email
address and then hit Enter.
What exactly is going
on underneath the hood?
Well, at the end of the day, I dare say
that what your laptop, and my laptop,
and our desktops, and even our
servers are capable of really
is just sending messages in envelopes
back and forth across the internet.
Virtual envelopes, if you will.
Now in our human world, an envelope
needs a few things on the outside.
If you want to send a letter or a card
or something old school to someone,
you need to address it, of course.
And you need to put, perhaps in
the middle, the recipient's name,
and address, and other details.
You might put in the top left hand
corner, by convention, your own name
and or address.
You might even put a
little memo in the bottom
that specifies what's inside or
fragile or some other annotation.
So this metaphor of the
physical world is actually
pretty apt for what's going on
underneath the hood in computers.
When you have a computer
plugged into a network
or connected wirelessly
to a network, it really
is just sending and receiving
envelopes, virtual envelopes,
that at the end of the day are
just patterns of zeros and ones,
but collectively, those zeros and ones
represent your email or the request
that you've made of a web server,
the response you're getting back
from that web server.
So let's see if we can't formalize
exactly what these lower level
primitives are, consider exactly how
they're layered on top of one another,
because thereafter we can
build almost anything we want
on top of this infrastructure once
we understand what those underlying
building blocks actually are.
So let's consider how
we actually address
this envelope in the first place.
After all, when I turn on my
laptop or turn on my phone
or open up my desktop in the morning,
how does that computer or that phone
even know what its own
address is on the internet?
Because just as in our
human world, wherein
you need to be uniquely
addressable in the physical world
in order to even receive an
envelope or a card or a package,
so do computers need to be uniquely
identifiable on the internet.
Now for our purposes, now we
can consider the internet just
to be an internetworked
collection of computers connected
via wires, connected wirelessly.
There's some kind of interconnectivity
among all of these devices
and these days our phones and internet
of things devices and other things
still.
So let's just stipulate that
somehow or other there's
a physical connection, or
even a wireless connection,
between all of these various devices.
So those devices all
need unique addresses,
just like a building in the
human world needs an address.
For instance, the computer science
building here on campus is at 33 Oxford
Street, Cambridge,
Massachusetts, 02138, USA.
With that precise information, can
you send us a real mail or a package
or anything else through the
physical world in order for it
to arrive on our doorstep?
But what if you, instead,
wanted to send us an email
and get it to that
building, or really me,
wherever I am physically in the
world on my internet works device?
You need to know my
computer's address, you
need to know my phone's address,
or at least the mail server
that's responsible for
receiving that message from you.
Well, it turns out that most any
network on a campus, in a corporation,
even at home these
days has a DHCP server.
Stands for a Dynamic Host
Configuration Protocol,
and that's just a fancy way of
describing a server that is constantly
listening for new laptops, new desktops,
new phones, new other devices, to wake
up or be turned on and to shout out
the digital equivalent of hello, world,
what is my address?
Because the purpose
in life of these DHCP
servers is to answer that question.
To say, David you're going to go
ahead and be address 1.2.3.4 today.
Or David, you're going
to be 4.5.6.7 or 5.6.7.8.
Any number of possibilities
can be used to represent
uniquely my particular device.
So DHCP servers are run by the
system administrators on a campus,
in a company, in an
internet service provider.
More generally, they're
run by whoever provides us
with our internet connectivity.
They just exist on our network.
But these DHCP servers also
give us other information.
After all, it's not really sufficient
just to know what my own address is.
How do I know where anyone
else in the world is?
Well, it turns out that
the internet is filled
with devices called routers
whose purpose in life,
as their name suggests, is to
route information from point A
to point B to point C and so on.
And those routers, similarly,
need to know these addresses
so that they know upon receiving
some packet of information,
some virtual envelope, in
which direction to send it off.
So these DHCP servers also tell me not
just my address, but also the address
of the next hop, so to speak.
I, as a little old laptop
or phone or a desktop,
I have no idea where 99.999 percent
of the computers in the world
are, even higher than that perhaps.
But I do need to know where the
next computer is on the internet,
so that if I want to send
information that leaves this room,
it needs to go to a router
whose purpose in life
is to, again, route it further along.
And generally there might be
one, two, maybe even 30 steps
or hops in between me and my destination
for that email or virtual envelope,
and those routers are all
configured by people who aren't me,
system administrators beyond
this, beyond these walls
to know how to route that data.
So we can actually see evidence
of this that you yourself
have had underneath your
fingertips all this time
and you might not have
ever poked around.
For instance, if you want
to see your own address,
keep an eye out for a
number of this form.
It's a number dot number dot number dot
number, and each of those place holders
represents a specific value, either
starting at zero or ending at 255.
In other words, each of these hashes
can be any value between 0 and 255,
and that range 0 to 255 well
that's 256 total possible values.
That's eight bits.
Ergo, each of these place holders
represents 8 bits, 8 more bits, 8 more,
8 more.
So an IP address, by
definition, is 32 bits.
And there it is.
IP, an acronym you've
probably seen somewhere,
even if you've not thought
hard about what it is,
stands for Internet Protocol.
Internet Protocol mandates that
every computer on the internet,
at the risk of oversimplification, has
a unique address called an IP address.
And those IP addresses look like this.
If these IP addresses are composed of
32 bits, how many possible IPs are there
and therefore how many possible
machines can we have on our internet?
Well, 2 times 2 times 2, 2 to the 32,
so that's four billion, give or take.
By design of IP addresses,
you can have four billion,
give or take, possible permutations of
zeros and ones if you have 32 in total,
and that gives you four
billion, maximally,
computers and phones and internet
of things devices, and the like.
Now that sounds big,
but not when each of us
personally probably carries one IP
address in our pocket in our phone,
maybe another on our wrist these
days, one or more computers
in our life, not to mention all of the
other devices and servers in the world
that need these addresses, too.
So long story short,
this is version 4 of IP.
It's decades old, but there's
also a newcomer on the field
called IPv6, version 6.
There isn't really to be a version 5.
And IPv6 is only
finally gaining traction
because we're running so
short on IPs that it's
becoming a problem for campuses,
for companies, and beyond.
But IPv6 will use 128
bits instead of 32,
which gives us many, many, many,
many, more possibilities, bigger
numbers than I can even pronounce.
So that should cut it
for quite some time.
But not every computer on the internet
needs a public IP address, only
those envelopes, so to speak, that
need to leave my pocket, or my home,
or my campus, or my company.
It turns out, as a short term mechanism
to squeeze a bit more utility out
of our 32-bit addresses,
which are still omnipresent
and the most popular
among the versions, well
we can actually distinguish
between public IP
addresses that do actually go out on
the internet and private addresses.
And indeed, if your
own IP address happens
to start with the number 10
and then a dot or the number
172.16 and then a dot, or the
number 162.168 and then a dot,
and then something else, well, odds are,
your computer has a private IP address.
And this is just a feature of the little
router that's probably in your home,
or the bigger router on your
campus or corporate network,
that enables you to have an IP address
that's only used within the company,
only used within your home,
and cannot, by definition,
be routed publicly beyond your
company, beyond your home,
because the router will stop it.
And so here we actually have the
beginnings of a firewalling mechanism,
if you will.
In the real world, a
firewall is a device
that prevents fire from going from
one store to another, for instance.
In the virtual world, a
firewall is a piece of software
that prevents zeros and ones from
going from one place to another.
And in this case do we
already have a mechanism
via public and private addresses
of keeping some data securely,
or with high probability
securely, within our company
versus allowing it to
go out on the internet.
So we'll see now some screenshots
of some actual computers from Mac OS
and Windows alike that
reveal their IP addresses,
and you yourself can see
this on your own machines.
For instance, here on
Windows 10 is a screenshot
of what your Network Preferences,
so to speak, might look like.
And if you focus down here, it's
a bit arcane at first glance,
but IPv4 address is 192168.1.139
when we took that screenshot.
And indeed, it starts with
192168 which means it's private,
and indeed, I took this screenshot
while we were within a home network,
and so that suggests it can be used
to route among computers in that home
but not beyond.
You'll see, too, if we
move on to the next screen
where you see more advanced
network properties,
you can also see the dimension
of this default gateway, which is
synonymous with router, default router.
192168.1.1.
So a default router or default
gateway is that first hop,
so that if I want to send
an email outside of my home,
I want to visit a web page
outside of my company,
all I need do is hand that virtual
envelope containing that email
or that web request off to the
machine on the local network that
has that IP address.
I have no idea where it's going to
go thereafter, to hops two and three
and beyond, but that's why
we have this whole internet
and even more routers out there.
They, the routers, intercommunicate
and relay that data,
hop to hop to hop, until it
finally reaches its destination.
Now where did I get
my IPv4 address from,
where did I get my default gateway from?
From the DHCP server in my home,
in my company, or whatever network
I happen to be on.
And Mac OS is the same.
If these screens are unfamiliar,
you might recognize this,
under System Preferences in Mac OS.
Here, while connected to
Harvard University's network,
you can actually see that my
IP address was 10.254.16.242.
That number, too, starting with one
of those internal or private prefixes,
indicative of the fact
that even within Harvard,
where we keeping all of our Harvard
traffic internal to Harvard,
and then not exposing that externally.
And indeed, if we look in the
more advanced preferences here,
we can see that the router
for my Mac was 10.254.16.1.
Which is to say this Mac, when it's
ready to send something off campus,
simply hands that envelope off
to this particular router here.
And the router's job, ultimately, that
first hop, a border gateway or border
router, literally
referring to a computer
that physically or metaphorically
is on the edge of a campus
or company, its purpose in
life is to simply change
what's on that envelope
initially from the private IP
address to one or more
public IP addresses, thereby
maintaining this mapping.
So this might result in everyone
else in the world thinking
that I and you and everyone
else in my company or campus
are all actually at the same IP
address, but that's not true.
Each of our personal devices
has a private IP address
and that router can actually
translate via something
called network address translation,
or NAT, from a private address
to public and back.
And so in this way, too, can
a company help mask the origin
or the identity of whoever it is that's
accessing some internet-based service.
Of course, that same company could log
what it is that's leaving the company
and coming back in, so via
subpoena or another mechanism,
could someone certainly
figure out who was accessing
that service at a particular
time, but the outside world
would need help knowing that.
And so here, even within Harvard,
it's done perhaps for that reason.
But also perhaps in order
to use one public IP
address among hundreds or
thousands of university affiliates,
so that frankly we just don't
need as many IP addresses.
So what might be both a
technological motivation
can also have these policy
side effects as well.
So IP itself.
Protocol.
Well, what does that actually mean?
A protocol-- it's not a language, per
se, it's not a programming language.
It's really just a set
of conventions that
govern how computers intercommunicate.
IP, specifically, says that if you
want to send a message on the internet,
you shall write a sender address on
the envelope and a recipient address
on the envelope, and that will
ensure that the routers know
what to do with it, and
they'll send it back and forth
in the appropriate directions.
IP gives us some other features,
as well, fragmentation among them.
It turns out for efficiency if you've
got a really big email or a really
big file, whether a
PowerPoint file or video file,
it's not really fair to everyone else
to kind of jam that onto the network
and to the exclusion of other people's
data at any given point in time.
And so IP tends to fragment
big files into smaller pieces
and send them in multiple
envelopes that eventually
get reassembled at the other end, so
that there is a compelling feature as
well.
But this leads, of course, to a
slippery slope of implications
for net neutrality and for
companies or governments
to actually then start to
distinguish between quality
of service of this type of data
and this other type of data.
Why can they do that?
Well, it's all quantized at
a very small unit of measure,
and within these packets
are additional information.
Not just those addresses, but hints as
to what type of data is in the packet.
Is it an email, is it a web page, is
it a video conference, is it Netflix,
is it some competitor service?
And so ISPs or companies or
governments can certainly
distinguish among these types of packets
and treat them theoretically, and all
to really these days, differently.
So that they're derived simply
from these basic primitives.
Now we can very quickly
go pretty low level.
If you actually look back
at the formal definition
that humans crafted decades ago for
what IP is, this is how they drew it.
You might call this ASCII art,
to borrow a phrase from our look
at computational thinking.
It's sort of an artist's
rendition of some structure
just by using the keys
on his or her keyboard.
And so these dashes and
pluses, really, just
are meant to draw a rectangular
picture, nothing more.
The numbers on top represent
units of 10 bits at a time.
Here's bit 0, here's 10, here's 20,
and over here is the 32nd such bit.
So start at zero, and you count as
high as 31, so that's our 32nd bit.
And we can see a few
details within here.
We can see details like
the source address,
and it's the whole width of this
picture indicating that indeed this
is a 32-bit value that composes the
source address or the sender address.
Destination address is just as
wide, so there's another 32 bits.
There's options and other time to live.
You can specify just how many
routers this can be handed off
to before the router should
say, we just don't know where
this destination is, we shall give up.
And there's other
fields as well in here.
Now what are we really looking at?
This is just an artist's
rendition of what
it means to send a pattern of bits.
The first few bits
somehow relate to version.
The next few bits relate to IHL and
type of service and total length.
Eventually, the pattern
of bits represents
source address and destination address.
So any computer that's receiving
just a series of bits wirelessly
or over the wire in the form of
wavelengths of light or of electricity
on a wire, simply needs to realize,
oh, once I've received this many bits,
I can infer that those bits
were my source address,
those were my destination address.
But again, this is so low level, it's
a lot more pleasant to sort of think
about things at the virtual level.
An envelope that just has this
information written on it, and let's
not worry about an abstraction
level below this one, wherein
we get into the weeds of this data.
But it turns out that IP is not the
only protocol that drives the internet.
In fact there's several, but
perhaps the other most common one
that you've heard of is that one here.
TCP.
Transmission Control Protocol.
Now this is just a protocol
that solves a different problem.
Rather than simply focus on
addressing computers on the internet
and ensuring data gets
from one point to another,
TCP is about, among other
things, guaranteeing delivery.
TCP adds some additional zeros and ones
to that envelope on the outside of it
that helps us get that antelope
to its destination with much
higher probability.
In other words, the
internet's a busy place.
Servers are constantly
getting new users,
routers are receiving any number
of packets at any given time,
and sometimes there are
spikes in connectivity.
People might all be tuning into
some news broadcast online streaming
lots of video, or downloading
the latest news all at once,
or everyone's playing
the latest game online,
and so there can be
these bursts of activity.
And honestly humans don't necessarily
engineer with those bursts of activity
in mind, and so routers get
busy, computers get busy.
And when they get busy, they might
receive an envelope of information
and realize, wait a minute, I
don't have enough hands for this,
and packets get dropped, so to speak.
In fact that's a term of ours, to
drop a packet just means to ignore it.
You don't have enough memory,
enough RAM inside of your system
to hang onto it for any length
of time, so you just ignore it.
Now this would be pretty darn
frustrating if you send an email
and only with some probability
does it go through.
Now in practice that might
feel like it happens,
especially when things get
caught up in spam and the like,
but in practice you really do want
emails that are sent to be received.
When you request a web page,
you want the entire web page.
And even if those are big emails
or big web pages that are therefore
chopped into fragments, you really
want to receive all of the fragments
and not just only some of
the paragraphs in the email,
or only some sections of the web page.
So TCP ensures that you get all of
that data at the end of the day.
Well hopefully not at the end
of the day, but ultimately.
And so what TCP adds to the envelope
is essentially a little mental note
that this is packet number one of
two, or one of three, or one of four,
in the case of an even larger file.
And so when the recipient of this email
or this web request gets the envelope
and realizes, wait a minute, I've got
numbers two and three and four, wait
a minute, I'm missing
the first envelope.
TCP tells that Mac or
PC or other computer,
go ahead and send a message
back to the sender saying, hey,
I got everything except
packet one, please resend.
That's going to take a
little bit of extra time,
but that packet can be
resent and TCP knows
how to reassemble them
in the proper order
so that the human ultimately sees their
entire email or that entire web page
and not just some portion thereof.
So what does TCP really look like?
Well, let's just take a quick peek
underneath the hood here, too.
And here we see a similar pattern of
bits but not addresses, that, again,
is handled by IP itself, but
you see mention of source port,
and destination port.
Sequence number, which
helps with the delivery,
and then other options
as well, all of which
we relate to the delivery
of that information.
But these two up here, looks
like 16 bits each, source port
and destination port.
Those two have value, because
TCP does something else.
It doesn't just guarantee that data
gets from one point to another,
it also helps servers distinguish one
type of data from another, and in turn
allows companies and universities
and internet service providers
or governments to distinguish
different types of data
because it's right there on
the outside of the envelope.
In particular, TCP
specifies what protocol
is being used to convey this packet
of information from one computer
to another.
In other words, there's lots of
internet services these days.
There's email, there's chat,
there's video conferencing,
there's web browsers, and more.
So that's a lot of possibilities,
a lot of patterns of zeros and ones
that can be in these envelopes.
So how, upon receiving an envelope, does
a server know what type of information
is in it?
Especially big companies.
Google, for instance, supports
all of those services.
Video conferencing,
email, chat, and more.
So when Google's servers
receives a packet of information,
how does Google know that
this is an email from you,
as opposed to a chat message from
you, as opposed to a video from you
that you're uploading to YouTube?
You need to be able to distinguish
these various services because
at the end of the day,
they're just patterns of bits.
Well, if we reserve some
of those bits, or really
some of the markings on this virtual
envelope, for just one more number
we can distinguish
services pretty easily.
In fact, HTTP, an acronym
that you might not
know what it means but
you've surely seen it a lot,
since our hypertext
transfer protocol and it's
the conventions via which browsers and
servers send web pages back and forth.
Well, by convention,
humans decided years
ago to call that service number 80.
TCP port 80, so to speak.
And the secure version of that, HTTPS,
they decided to number that 443,
just because they'd already used quite
a few numbers in between those two
values.
INAP is the protocol via which
you can receive emails or check
your email, that's used different ports
depending on whether you're using it
security or insecurity like 143 or 993.
SMTP, which is outbound email,
can use similarly 25, 465, or 587.
And then, if familiar, there's
something called SSH, secure shell.
This is what developers
might use at a lower level
to connect from one computer,
say a laptop, to a remote server.
That tends to use port 22.
And there's hundreds,
there's actually thousands
of others, as many as 65,000
possibilities, but only some of those
are actually standardized.
So this is to say what
ultimately is going
on the outside of an envelope
is not just a user's address
but when I as a computer send
a message to some other server
and for instance my address
is 5.6.7.8 I'll write
that in the top corner of the envelope.
If the recipients of this envelope
are supposed to be 1.2.3.4
I do write that in the
middle of the envelope,
but I need to further specify IP
address 1.2.3.4 but port number,
let's say, 80, if it's a
request for a web page.
So conventionally you would do
:80 to distinguish that service.
And then of course because of TCP
I need to number these things,
so if it's a big request or a big
response I better write one of two,
one of three, or one
of four, or the like.
And so the envelope I'm
ultimately left with
is something a little more like this.
On the outside is this recipient's
address, on the outside
is the sender's address,
and on the outside
is the sequence number of
some sort that specifies
how many packets I've actually sent
and hopefully will be received.
So TCP then allows the recipient to
see this envelope, realize, oh this
is for my web server.
Google can hand it off to the
appropriate piece of software
that governs its web
servers and so it's not
confused for something else like
an email, a chat message, a voice
conference, or the like.
And again, all of these
features derive quite
simply from these patterns of
bits that esoterically happen
to be laid out in this way, but
if we abstract away from that
and stipulate that just think about it
like the real world with an envelope,
it's really just these numeric
values that somehow help
us get data from one point to another.
Collectively now, these two protocols,
which are so often used hand in hand,
are generally very abbreviated TCP/IP.
It's two separate protocols,
two separate conventions
used in conjunction.
Some of this information is just
written in different places,
if you will, on the virtual
envelope, but TCP/IP settings are
what you might look for
on a Mac or PC or server
to actually configure
this level of detail.
But of course, I've taken
some liberties here.
If my goal is to send a
message from one computer
to another, a chat message,
an email, anything else,
you know what, I'm pretty
sure I have no idea what
the IP address is of any colleague.
And I have no idea what the IP
address is of Google or Facebook
or any number of popular websites
that I might even visit daily.
I don't even know people's phone numbers
anymore but that's another matter.
In the context of words, though,
on the internet all of us,
of course, type words, not numbers,
when we want to reach some destination.
We go to facebook.com or gmail.com
or google.com or bing.com
or any number of other
domain names, so to speak.
And of course, that's
what you would write
on the outside of an
envelope in the human world,
ideally as many words as possible,
not just numbers let alone bits alone.
And ideally our
computers would similarly
express exactly what we humans
know, which is these domain
names that are part of URLs.
So it turns out we need the help of
at least one more service among all
of these internet technologies.
We need the help of a service
called DNS, domain name system.
A DNS server is a server that quite
simply translates domain names
like gmail.com and bing.com and
google.com into their corresponding IP
addresses.
We, the humans, might have
no idea what they are,
but odds are there's at least one
human or more in the world, probably
who works for those
companies, that does know.
And provided he or she
configures their DNS
servers to know that
association of domain name to IP
address, the equivalent of just an
Excel file with one column with names
and the other column with numbers, IP
addresses well their server can then
answer questions from little old me.
And indeed what my phone knows how to
do these days, what my Mac, my PC knows
how to do is when my human types
in gmail.com and hits enter,
the very first thing that my
browser, and in turn my operating
system like Mac OS or Windows
does, is it asks the local DNS
server for the conversion of
whatever I typed in, gmail.com,
to the corresponding IP address.
And hopefully, my own network be
it at home or on campus or in work,
has the answer to that question.
But the world's a big
place, and odds are
my home does not know the IP address
of every server in the world.
Odds are my campus or company doesn't
know the IP address of every server
in the world, especially since
they're surely changing continually
as new sites are coming online
and others are going offline.
So how do we know?
Well DNS is a whole
hierarchical system whereby
you might have a small DNS server, so
to speak conceptually here on site.
But then your internet service
provider or ISP, Comcast, Verizon,
or some other entity, they probably have
a bigger DNS server with more memory,
with a longer list of domain
names and IP addresses.
And you know what, even if
they don't know everyone,
there are probably what are
called root servers in the world,
that much like the root of a
tree, is where everything starts.
And indeed, you can find
out from these actual root
servers on the internet,
the mapping, effectively,
between all of the dot coms
and their IP addresses.
All of the dot govs or the dot
nets and their IP addresses.
And frankly, even if they don't know
the answer by definition of root server
they will be configured
to know who knows.
And so DNS is very hierarchical,
and it's also recursive.
You might ask a local server, which
might ask a more remote server, which
might ask and even further away server.
That server might say, wait a minute,
I know, this server knows, and then
the answer eventually
bubbles its way back to you.
And long story short,
we can be efficient.
We don't have to constantly
ask this question.
We can cache those results locally.
Remember them in my
browser, in my Mac or my PC.
There's downsides there, though, too.
By remembering that mapping
of domain name to IP address,
I can save myself the trouble of asking
that same question multiple times a day
or even per week or even per minute.
The catch, though, is that if Google
changes something, or Facebook
reconfigure something
and that IP changes,
caching might actually be a bad thing.
And so here, too, even at
the level of the internet
do we see these series of trade-offs.
You might save time by caching, but
you might sacrifice correctness,
because now the servers recollection of
that IP address might become outdated.
And so this is a whole
can of worms, ultimately,
and speaks to what it really
means to be an engineer
in the world of internet technologies
to anticipate to think about
and ultimately to solve these problems.
There is no sure fire solution other
than to expect that you'll need
to accommodate these changes over time.
So in Windows, can
you see this yourself?
Well, if you open up those
same Wi-Fi properties or wired
properties that you have, you'll see
again, not only your IPv4 address,
but it was there all this
time, your IPv4 DNS servers one
or more IP addresses turns out it's
exactly the same by coincidence
but also by design on this computer
of my router or my default gateway
192168.1.1.
Which is to say that if this PC needs
to know an answer to the question,
what is gmail.com's IP address it is
simply going to ask the local server
that has that address and that
DNS server, and this is important,
cannot have itself a name.
We need to know what its IP
address is, otherwise, of course,
we get into this endless loop.
If we know only the name of our
DNS server but only the DNS server
can convert that to an IP address, we'll
never actually answer that question.
It's more of a catch-22.
And even if it does
have a name, you need
to know manually, via your DHCP server
somehow, what its IP address actually
is.
Mac OS, the same.
And here on campus, Harvard happens to
have redundancy like most any company.
They don't have just one DNS server
they have at least three here,
128.103.1.1, and a couple
of others, as well.
And again, I got these automatically
when I turned on my Mac or my phone
or my PC via that local DHCP server.
So let's see if we can't
mimic what it is my Mac,
your PC, your phone is doing
everyday all day long, but rather
unbeknownst to us.
Here I have what's
called a terminal window.
This is just a textual
interface to my computer here.
Can exist on Macs, or PCs, or
other operating systems, as well.
And it allows me to execute
by typing commands textually,
only at my keyboard, no mouse,
exactly the types of commands
that your browser and other software
are effectively executing or running
for you.
For instance, suppose
I genuinely do want
to know the IP address of gmail.com.
I can ask this program as follows.
nslookup, for name server look
up, and then I can go ahead
and type literally
gmail.com and hit Enter.
Here, visually, we see on the screen
one answer that it's 172.217.3.37.
And this comes from a server
whose IP address in this room
is 10.0.0.2, which we know now
to be a private IP address,
and indeed, here on
campus we have servers
that are local only to this room, this
building, or this set of buildings
here.
Now this is a little
interesting because I'm
pretty sure business is good
for Google, and surely they
don't have just one server
and therefore one IP address.
Well, it turns out that there's a whole
hierarchy of servers out there, most
likely, that my data goes to and
thereafter through on Google's end.
The one IP address that they're
telling me is theirs is 172.217.3.37,
but once my packet of information gets
there to Mountain View, California,
or wherever their servers
happen to be closest to me,
then they might have any number of
servers, dozens, hundreds, thousands,
that can actually
receive that packet next.
This just happens to be the outward
facing IP that my own Mac or PC
or phone actually sees.
Well, let's see if we can't trace the
route to gmail.com via another command,
literally traceroute, can I see
the packets of information line
by line leaving my computer and making
their way, ultimately, to Google.
I'm going to go ahead and
do this once, so dash q1
means do one query, please, at a time.
And then I'm going to go
ahead and say, quite simply,
gmail.com, and then Enter.
And we will see, line by line,
the sequence of IP addresses
of every router that is to
say hop between me and Gmail.
On occasion we'll see
these asterisks instead,
which indicates that that
router isn't having any of this,
it's not responding to my requests,
so we can't see its IP or anything
else about it.
But we can see that in 17
steps does data leave my laptop
and end up at gmail.com,
and along the way
it encounters all of these routers that
have these unique IP addresses but not
names, it seems, and
the amount of time it
takes for my data to get
from my laptop to gmail.com
is, oh my, 0.967 milliseconds.
Less than one millisecond is
required to get data or an email
from my computer to gmail.com itself.
Now what about all of these other
measurements of time up above?
Each of these represents
the number of milliseconds
it took during this process for data
to go from my laptop to this router,
then to this router,
then to this router.
Now, of course, it seems
strange that it takes more time
to get these to these close routers
than it does to these further away.
But there, too, if I
ran this all day long
I would get different
numbers continually,
it depends how busy those routers
are at that moment in time.
It depends what else
everyone here on campus
is doing, or other people in the
world at that moment in time.
Routers might be a little slow
to respond because they're
busy doing something else.
My data might get
dropped in other contexts
and need to be resent, which
is just going to take time,
and I don't even see that
happening on the screen.
But it's fair to say that these give
us a sense of the range of times
it might take to go from
a point A to point B,
and let's say 1 to 20 milliseconds
or even 32 milliseconds, somewhere
in there is our average,
and that can vary over time.
But that's pretty fast, and indeed,
even though it took a moment
to run this whole test, this is why an
email can be sent from your computer
and be received nearly
instantly by someone
around the world, because at the end
of the day, we're limited, really,
ultimately, by the speed
of light and little more.
Well, to be fair, hardware and
cost and everything in between,
but you can certainly transmit your
data faster than you can yourself.
But what if we want to go
farther away than gmail.com?
Odds are they probably do
have servers in California,
but probably here on the east coast
of the US as well, let alone abroad.
What if I deliberately try
to access a domain that is,
in fact, abroad and go there?
Well, let me go ahead
and visit via traceroute,
say, www.cnn.co.jp, the domain
name for CNN's Japanese website.
And then we'll add
just dash q1 this time
at the end, which is fine, too,
to query the server just once.
And here we see the
sequence of steps, one
after another, whereby the data's
leaving my laptop and in turn campus,
and then we see some
anonymous routers in between.
But the 30th there seems to be
just in time, because within it
seems 178 milliseconds do
we make our way to Japan.
Now that's quite a few milliseconds
more, but that rather makes sense.
Whereas it might take one
to 20 to 32 milliseconds
to get from here to Gmail either
on the east coast or west coast,
I'm kind of not surprised that
it takes an order of magnitude
more, almost to factor of 10, to get
to Japan, because there's not only
a whole continent between us
here in Cambridge and Japan,
there's also an entire
Pacific Ocean between us.
And indeed, there are Transatlantic,
Transpacific, and transoceanic cables
all around the world these days
that actually transmit our data,
not to mention all of the wireless
technologies we have, satellites
and below.
And so it does stand to reason that
even though none of these routers
were paying attention to me at
that moment for privacy sake,
this last one indicates that 200
milliseconds later we can get halfway
across the world digitally.
And so that does rather speak to
just how quickly these low level
primitives operate, and
we can talk far longer
about how these things work
than it actually takes time
to actually get the data there.
So then together we have
TCP/IP via DHCP can we
get the addresses that we need to use
to address my envelopes and others,
as well.
Via DNS can we convert those domain
names into IP addresses and even back.
And those internet
technologies are ultimately
what govern how our data gets from point
A to point B. But what is the data?
Indeed, everything thus far
is really just metadata.
Information that helps our actual
data that we care about get from one
point to another.
But it's the data at the end of
the day that I really care about.
The contents of my email, the
contents of my chat message,
the voice that I'm sending over
a video conference, or even just
the contents of a web page.
Indeed, perhaps the most popular
service that you and I use every day
is just that, pulling
up pages on the web.
So just how is a web page
specifically requested and received?
Well, it turns out that http://
that you've surely seen,
but probably not typed for some
time, because your browser, odds are,
just inserts it automatically
or even invisibly for you.
That HTTP is yet another protocol in
this stack of internet technologies.
Hypertext transfer protocol.
A set of conventions that browsers and
web servers have agreed upon long ago
to use when intercommunicating.
And to be clear, then,
what exactly is a protocol?
Well, it's just a convention.
We humans have protocols even
though we might not call them such.
When I meet someone new on the
street I might reach up to him or her
and say, hello, my name is David.
And that protocol results
in that other person,
if polite, in extending their
hand too, reaching into mine
and probably saying as well, hello,
nice to meet you or how are you.
That's a human protocol that
we were taught some time ago,
and culturally we have all agreed
here in the US to, generally speaking,
greet each other in that manner.
Computers, similarly,
have standardized what
goes not only on the outside of these
envelopes but what goes in the inside,
as well.
And so if, for instance,
the goal at hand
is to request a web page of a
canonical website like www.example.com,
let's consider exactly what
is inside of this envelope.
Well, first of all here we have a
proper URL, uniform resource locator.
These days, your browser, whether it's
Chrome or Safari or Edge or Firefox,
probably doesn't even show
you all of this information.
In the interests of simpler
user interfaces or UIs,
browsers have started to hide
these so-called protocol here
at the left, even the ww here,
the hostname in the middle,
leaving you oftentimes with just
example.com or the equivalent
somewhere at the top of your screen.
But if you click on that
address, typically you'll
see more information such as that here.
And sometimes there's more
information that's just implicit.
It turns out if you try to
visit http://www.example.com
or any similar domain name, what
you're likely reaching for is
a very specific file on that server.
But how do we reach it?
Well, highlighted in yellow here is
what's called the domain name itself,
example.com.
This is something that
you buy, or really rent,
on an annual basis via an internet
registrar, a company, that
via the associations on the
internet that govern IP addresses
domain names has been
authorized to sell, or really
rent, you and anyone else a domain
name for some amount of time,
usually one year or two
years or 10 or anywhere
in between, for some dollar amount.
And what you get, then, is the
ability, for that amount of time
renewable thereafter, to use
that specific domain name.
It might be dot com,
or dot net or dot org,
or any number of hundreds of others
of TLDs, or top level domains.
Indeed, that suffix there is what
represents the type of website,
at least historically, that it is.
Dot com for commercial, dot net
for network, dot edu for education,
or dot gov for government.
Of course, all of those
TLDs, or top level domains,
were very US centric by
design, and so far it
was generally a cohort of Americans
that designed a lot of this system
initially.
Of course, other countries
have shorter TLDs.
Country codes, dot US, dot
JP and others that signify
a specific country in which they're in.
And these days anyone can
buy a dot com or dot net,
but not everyone can buy a dot gov or
dot edu, or several other top level
domains, as well.
It depends on whoever controls
that particular suffix.
This here we might call the hostname,
the name of the specific server
that you were trying to visit that
lives within that domain name.
In other contexts, you
might call this a subdomain,
indicating what subdivision of a
company or university you're actually
trying to access.
And then down here on the right,
implicitly so to speak, is a file name.
It is human convention, but
not required, that the name
of the file that contains the web page
that a server serves up by default,
happens to be traditionally index.html.
It could also be index.htm or any
number of other names or extensions,
but this is among the most common.
So if you don't mention that
via just a slash, it's implied,
and it's that file or
any other file, that's
implied or even specified explicitly
that is inside of this envelope.
That's the whole point of this
virtual packet of information,
to encapsulate the request for a
page and the actual page itself.
At the end of the day, it's
HTML, Hypertext Markup Language,
an actual language in which pages are
written, that's inside that envelope,
but it's transmitted there via HTTP.
The protocol, the set of conventions
via which browser and server agree
to send and receive that information.
So what does that information look like?
And just what have these
computers agreed on?
It turns out that
inside of this envelope,
when it represents a request for
a web page like my URL there,
are these lines here.
GET/HTTP/1.1, where
get is clearly a verb,
by definition in all
caps in this protocol,
slash means the default page of the
website index.html or something else.
And then often a mention of host
colon and then the name of the host
that you're actually looking for.
Because it turns out servers
can do so many things.
Not just Google servers with
voice and chat and other services,
one web server can actually
serve up multiple websites.
Example.com, acme.com,
Harvard.edu, google.com, all of us
can actually have shared tendencies, so
to speak, on the same server in theory.
And so by mentioning what actual
website you want inside of the envelope,
the recipient of this envelope can make
sure that it serves you my home page
and not someone else's.
But beyond that, there needs to be
additional information, as well.
You might explicitly specify
the name of the file.
And again, we humans have nothing
to do with any of this, ultimately,
we have just typed that URL.
But it's our browser, on
Mac OS or Windows or phones,
that's packaging up this information
inside of a virtual envelope
and sending it out,
ultimately, on our behalf.
And indeed, if all goes well and
that envelope reaches point B
and it's opened up and it represents
the name of a web page that does,
in fact, exist, the response
that I hope to get back
in another envelope
from point B to point A
is going to contain an
HTTP message like this.
Literally the name of the protocol
again, HTTP/1.1, and then a number,
and optionally a phrase.
200 is perhaps a number
you've never actually seen,
even though it is the best
possible response to get.
200 means, quite literally, OK.
The web page you
requested has been found
and has been delivered in
this response envelope, OK.
The type of content you've
received is in this case text/html.
Which is to say inside of that
envelope is a clue to your browser
what kind of content is inside deeper.
Is it text.html, like the
contents of a web page?
Is it an image/png like a graphic,
or image/gif, something animated,
or video/mp4, an actual video file,
this so-called MIME type or content
type is inside of the envelope for
your browser so as to provide a hint,
so as to know how to
display it on the screen.
There's so many other headers,
as well, but these two alone
really specify almost
as much information
as you need in order to render
that response for the user.
Now as an aside, there
are other versions.
And increasingly in vogue,
though not yet omnipresent,
is HTTP2 which has additional
features, particularly for performance
and getting data to
you even more quickly.
It simply replaces that 1.1
with a two and the response,
though, comes back almost the same.
So let's consider an example
then, such as harvard.edu.
It turns out that http://harvard.edu
is not where Harvard wants you to be.
In fact, let me go ahead
and pull up my browser here
and visit precisely that URL.
http://harvard.edu, Enter.
And within seconds do I find myself
not at harvard.edu, but rather
at ww.harvard.edu and moreover
at https://www.harvard.edu.
In other words, even though I
specified a protocol of HTTP,
a domain name of harvard.edu,
and no hostname, so to speak,
I have actually been whisked
away, seemingly magically,
to this URL instead, for reasons both
technical and perhaps marketing alike.
For today, though, let's focus
on exactly how this came to pass.
Well, it turns out that inside of
the envelope with which Harvard,
or any server, replies to me can
be additional metadata, as well.
Not just 200 OK, but really
the equivalent of uh-uh,
there's nothing to see
here, go here instead.
So let me go ahead and run a program,
again in that black and white window
known as my terminal
window, whereby I can
pretend to be a browser
without all of the graphics
and without all of the
distraction and focus only
on the contents of
those digital envelopes.
Here the program I'm going to run
is called curl for connect to a URL,
and I'm going to specify dash I which
is to say I only want the HTTP headers.
I'm going to go ahead now and say
http://harvard.edu, nothing more.
When I hit Enter now, here
are the complete headers
that come back from the server.
No dot dot dot this time, we
see everything, in fact, here,
but notice the first line.
It's not 200 OK, but rather
301 moved permanently.
Like, where did Harvard go?
Well, it turns out that Harvard
has specified its new location
down here as https://www.harvard.edu.
Now there's other
lines of headers there,
HTTP headers as they're called,
each of which starts with a word,
perhaps with some punctuation, and
a colon, followed by the value.
Location, value, go to this location
is the general paradigm there.
But why might Harvard not want to
show me their web page at the address
that I typed?
Well, it turns out that HTTP
is by definition insecure.
The extents to which
the message is encoded
is quite literally in English
or English-like syntax,
such as that we've been looking at here.
It's just that text that's
inside the envelope.
If instead, though, you want to encrypt
those contents so that no one knows
what web page you're
requesting or receiving,
and your employer and your university
administrator or your internet service
provider or country does
not know what you're doing,
be it for personal reasons,
financial, or otherwise, well then
you want to use HTTPS.
And Harvard University, like
so many companies today,
is insistent that you
actually visit them securely,
if only because it's best
practice, but it also
prevents potentially private
information from leaking.
And so here with this location
line is Harvard saying,
no, we will not respond
to you with OK via HTTP,
we have moved permanently to
a secure address at HTTPS,
where the S denotes secure.
But why the www?
Back in the day, you
probably did have to type
for many companies, www.example.com
instead of just going to example.com
and hoping that you end
up in the right place.
Well, humans have gotten more
comfortable with the internet
over the past years, over
the past decades, and indeed,
whereas years ago, in order to advertise
yourself effectively on the web,
you might have indeed needed to
go to press on your business card
or advertisement with
http://www.something.com.
But all of us have kind of seen
HTTP enough, if not HTTPS as well,
you don't need to tell me to type that.
And indeed, my browser no
longer requires me to type
that, so now you see business
cards and advertisements
with just www.something.com.
But you know what, I'm
not new to the internet.
I know what ww is, and I
know what dot com is as well,
don't even bother showing me or telling
me on your card or your website or ad
that it's www.something.com,
just tell me something.com.
And so browsers have been
getting more user friendly
and humans have been
getting more familiar,
and so we tend not to see
those prefixes anymore.
But it turns out that for technical
reasons, for security reasons,
it tends to be useful
to have a subdomain.
As an aside, for things
like cookies, it's
useful to keep cookies
in a subdomain as opposed
to the domain itself just to narrow the
scope via which they can be accessed.
But also for marketing
sake, it would be nice
if everyone in the world, whether they
type harvard.edu or www.harvard.edu,
ultimately end up in the same
location just because that's how we
want to present ourselves to the world.
And so for both technical and marketing
and security reasons alike might
Harvard or a company want to
redirect to a URL like this one here.
Now what does your browser know to do?
Well, when your browser receives
not 200 OK, in which case
it just shows you the page, but
instead receives 301 moved permanently,
it instead looks for that location
line and takes you there instead,
at which point then
you'll get that 200 OK.
And so this, again, is with browsers do.
HTTP is what they understand, and
know by definition of that protocol
how to handle these cases.
But not everything is always OK and not
always has something moved permanently.
Sometimes something's just not found.
And in fact, of all of these
numbers we've seen thus far,
odds are you've not seen or cared
about 200 or even 301, but most of us
have probably at least once seen 404.
Why?
Why in the world is that
the number we somehow
see anytime you visit a web page that's
gone, or anytime you mistype an address
and you reach a dead end?
Well, for better or for worse the
designers of websites for years
have exposed this value to end users
even though it's not all that useful.
But it's indeed the
unique value that humans
decided some years ago would uniquely
represent the notion of a page
not being found.
So if inside of that virtual envelope
comes back a message 404 not found,
the browser can say that
literally or perhaps display
a cute message to that effect, but
the reason that you're seeing that 404
is because quite literally
and mind numbingly that
is just the low level status code that
has come back from an HTTP server.
And there's more of these, too.
In fact, 200 OK is the
best you might get.
301 moved permanently we've seen.
302 found is another
form of redirection,
but a temporary one instead.
304 not modified is a response that
a server can send for efficiency.
If you visited a web
page just a moment ago
and you happen to hit
reload or click on a link
and get back the same content again,
it's not terribly efficient or good
business for a company to incur
the time and perhaps financial cost
to retransmit all of those bits
to you, and so it might instead
respond with an envelope more
succinctly with 304 not modified
without anything else deeper in that
envelope, no additional content.
And so this way your browser will just
reline its own cache, its own copy,
so to speak, of the original request.
Meanwhile, if you're not allowed to
visit some web page because you've not
logged in or you don't
have authorization there,
too, well 401 unauthorized
might instead come back.
As might 403 forbidden.
404 not found means
there's just nothing there.
418 I'm a teapot was an
April Fool's joke some years
ago where someone went to the
lengths of actually writing
a formal specification for what a server
should say when it is in fact a teapot.
But the worst error you might see,
and most users would never see this,
but developers of software would
is five zero zero, 500, which
represents an internal server
error, and almost always represents
a logical or a syntactic error in
the code that someone has written,
be it in Python or any
number of other languages.
And now a fun example, perhaps,
to bring all this home.
It turns out that safetyschool.org
is an actual address on the web.
And indeed, it happens to
have been bought or rented
for years now by some Harvard alum.
And indeed, if you
visit safetyschool.org,
you shall find yourself
at this website here.
http://safetyschool.org.
We find ourselves whisked
away to www.yale.edu.
But how is that implemented?
Well, let's again turn
to our terminal window,
where we can see really the
contents of that virtual envelope.
And if in here in my terminal
window I again type curl dash I,
http://safetyschool.org,
well I see all of the headers
that are exactly coming back.
And indeed, here, safetyschool.org
has permanently moved for years now
to this location, http://www.yale.org.
A fun jab at our rivals that
some alum has been paying now
for years on an annual basis.
So we now have a pair of
protocols, TCP and IP,
via which we can get data,
any data, from point A
to point B on the internet.
Sometimes that data is itself HTTP
data that is a request for a web page
or a response with a web page.
But what if there are so many others
trying to access data at point B--
that is to say, business is good, and
a web server out there is receiving
so many packets per second that the
server cannot quite yet keep up?
The routers in between might very well
be able to handle that load perfectly
because those are much bigger servers,
conceptually and physically, with far
more CPUs and RAM and
therefore can handle that load,
but some business' server out
there is only finite in capacity.
And so what happens when you need
to scale to handle more users?
Well, you might have
initially just one server
such as that Dell server pictured here.
This is what's called
a rack server, insofar
as it's designed to exist on a rack
that you slide this thing into,
and it happens to be one
rack unit or 1.5 inches,
which is simply a
standardization thereof.
Inside of this rack server
is its hard drive, and RAM,
and CPU, and more pieces, but
it's exactly the same technology
that you might have in
a box under your desk
or even in the form factor of a
laptop, just bigger and faster.
And, to be fair, more expensive.
But it's only so big, indeed,
it's only 1.5 inches tall
and some number of inches deep,
which is to say there's only
a finite amount of RAM in there.
There's only a fixed
number of CPUs in there,
and there's only so many gigabytes,
presumably, of disk storage space.
At some point or other, we're
going to run out of one or more
of those resources.
And even though we've not really gotten
into the weeds of how a server handles
and reads these envelopes,
it certainly stands
to reason that it can only
read with finite resources
some finite number of
packets per unit of time,
be it second or minutes or days.
And so at some point
if business is booming,
we might receive at any
given point more packets
of information that we can handle and
indeed, like some routers, if they're
overwhelmed, we might just
drop these incoming packets,
or worse yet, not expect them and
just crash or freeze or somehow
behave unpredictably.
And that's probably not
good for our business.
So how can we go about
solving this problem?
Well, the easiest way, quite simply,
is to scale vertically, so to speak.
That is don't use that server.
Instead, buy one that's bigger with more
RAM and more CPUs and more disk space
and faster internet
connectivity, and really just
avoid that problem altogether.
Why is this compelling?
Well, cost of it aside, you
don't have to change your code,
you needn't change your
configuration in software,
you need only throw hardware and in
turn, to be fair, money at the problem.
Now that in and of itself might alone
be a deal breaker, the money alone,
but at some point if we want to handle
that business, we've got to scale up,
but even this is shortsighted.
Because at the end of the day, Dell only
sells servers that operate so quickly
and have so much disk space.
Those resources, too,
are ultimately finite.
And while next year there
might be an even bigger version
of this same machine
out there, this year
you might have the top of the line.
So at some point, one server,
even with so many resources,
might not be able to handle all of the
packets and business you're getting.
So what do you then do?
Well, there is an opportunity to
scale not vertically, so to speak,
but horizontally instead.
Focusing not on the top
tier machines, but instead,
two of the smaller ones, or as needed
three or four or more of the same.
In other words, spending
lower on that cost curve,
getting more hardware,
hopefully, for your money,
but such that the net effect
is even more CPU power
and more disk space and more RAM than
you might have gotten with that one
souped up machine itself.
And heck, if you really
need the capacity,
you can buy any number
of these big servers,
but you do somehow ultimately
have to interconnect them.
And here now is where
there's a trade-off.
Whereas money was
really the only barrier
to solving this problem initially,
though easier said than done,
now we have to re-engineer
our system, because no longer
are packets of internet data
coming in from our customers
and ending up in one place,
they now have to somehow
be spread across multiple servers.
So how might we do this back in the day?
Well, back in the late 90s, when
Larry and Sergey of Google fame
built out their first
cluster of servers,
they didn't have those
pretty Dell boxes, rather,
this was, now in Google's
museum, reportedly
one of their first racks of servers.
Notice there's no shiny
cases, let alone logos,
but instead, lots of circuit boards on
which are hard drive after hard drive
after hard drive and suffice to say
so many wires connecting everything.
And even though, ironically, this
picture seems to be vertical,
this is, perhaps, one of the earliest
examples in our internet era of scaling
horizontally.
Each of these servers, which is
represented by each of these boards,
is somehow interconnected in
such a way that those servers
can intercommunicate.
But how?
Well, let's consider, with
the proverbial engineering hat
on, how servers might
somehow intercommunicate.
If up here, for instance, is
just some artist's rendition
of someone's laptop, a potential
customer who's sending us packets,
that customer might previously have
been accessing our server, which we'll
represent here with a
box and just call it
A. Server A. There's no
other servers involved,
but there is some internet in between
us here, so we'll assume that this
is the so-called cloud, so to speak.
And I, as this laptop or the
customer, has a connection
and so does that one and
only server have the same.
This picture is fairly straightforward.
Now you request a web
page via this browser,
it somehow traverses the
internet via routers,
and then ultimately ends
up at that server A.
But what if, instead,
there's not just A,
even if it's top of the line,
because that's not enough,
but instead their servers A and
B together here for this website.
Well, here we might now have two boxes,
the same size or bigger or smaller,
but ultimately finite, as well.
And somehow we need to now
decide how to route information
from customer to server
A or B. In other words,
there is now virtually
a fork in the road,
left or right, that
packets need to traverse.
So how can we implement
this building block?
Well, again, as always, go
back to first principles.
We know from our stack
of internet technologies
that we already have a
mechanism via which to translate
domain names into IP addresses.
And if each of these
servers, by definition of IP,
has its own IP address, why not
just use DNS to solve this problem?
When a customer requests example.com,
perhaps answer that request
with the IP address of A. And then when
a second customer somewhere else out
there on his or her laptop
asks for example.com next,
return to them the IP address of
B and vise versa, again and again.
Literally adopting a
round robin technique
of sorts, whereby one time you
answer A, the next time you answer B,
and back and forth you go.
On average, you would like to think that
this uniform distribution of answers
will give you 50% load,
that is to say traffic,
on one server and 50% on the other.
But perhaps this customer is
more of a shopper than this one,
and they end up imposing even
more load on A than on B,
so there with that simple
heuristic you can get skew.
You might not even use round
robin, you could just use random,
but on there on average yes, you'll
send 50% traffic left and 50% right,
but some of those users might
be heavier users than other.
So perhaps we should have
some form of feedback loop,
and DNS alone might not be sufficient.
We really need there to be a
middle man, such as this dot here,
that decides more intelligently
whether to send data to A or to B.
And we'll call this thing here,
this dot now, a load balancer.
Aptly name insofar as
it balances load that's
incoming across multiple servers.
But how?
Well, if these connections between
A and B in this load balancer
are not uni-directional,
but bidirectional somehow,
literally a cable that allows
bits to flow left and right.
Could we perhaps have A just continually
report back to that load balancer
saying, I have capacity,
I have capacity?
Whereas B might say, I've
got too many customers.
And logically, then, this load balancer
can just start sending no traffic to B
and send all of it to A or vise versa.
Of course, logically,
we could find ourselves
in a situation where both A and B
are too busy, what then do we do?
Well, at some point we have
to throw money at the problem
and solve it by just adding hardware.
And so C might be added to
the mix with that same logic,
but the load balancer
just has to know about it.
So all fine and good,
we seem to have solved
the problem in a very straightforward
way, but as with computer science
more generally, there's probably
a price paid and a trade-off,
and not just financial.
Unfortunately, even though I have two,
maybe even three servers now, therefore
seemingly having high
availability of service,
that is any one of these servers
theoretically could go down
and I've still got 2/3 of my capacity.
But there's a single point of
failure here, an SPOF so to speak,
that could really derail
the whole process.
What happens if this load balancer,
which while pictorial is just a dot,
is actually a server
underneath the hood itself?
What if that load balancer
goes down, or what if that load
balancer itself gets overwhelmed?
It does not matter how many servers you
have here, A through Z, if none of them
can be reached.
So this simple architecture
alone is not a solution.
And indeed, this is what is meant
by architecting network itself.
This design is probably not the
best, especially for business.
And so let's start anew, at least
down here inside this company,
and consider if one load balancer is
not great, what's better than one?
Well, honestly, two.
And so let's now draw
them a bit bigger, where
here we have a load balancer on
the left, and here on the right,
and we'll number them 1 and 2.
Whereas our servers we'll continue to
name A and B and C and perhaps even
through Z. And now we just have
to ensure that we have connections
to both load balancers,
and that each load
balancer can connect to each server
in this sort of mesh network here.
It's wonderfully redundant
now, albeit a bit complex.
But because we have all of
these interconnections now,
we can ensure that even if one or two go
down, data can still reach A, B, or C.
But how to know whether load balancer
1 should be doing all of this
or load balancer 2?
You know what, why don't we draw
another connection between 1 and 2?
And a very common paradigm in
systems is heartbeats, quite simply.
Much like you and I have every second
or so a heartbeat saying we are alive,
we are alive, hello world,
hello world, if you will,
so here might load balancers 1
and 2, themselves just servers,
say I am alive, I am alive,
hello number 2, hello number 2.
And if 2 does not hear 1
eventually, or if 1 does not hear 2,
the other can just commandeer that role.
By default, only 1 will be load
balancing, but if it goes offline,
2 will presume to take over.
And now we have this property
generally known as high availability.
Even if we lose one or more
servers can we still stay up,
and there is no single point of
failure, at least here in this picture,
because we now have that
second load balancer.
But if we look a little
higher, it would seem
that we do actually have another
single point of failure in here,
and now we go down the rabbit hole.
If this line here to
the cloud, the internet,
represents my internet
connection, my ISP,
what if that ISP, Comcast, Verizon
or any other, itself goes down,
a big storm and a loss of power
might take my whole business offline.
Well, the best way to
solve that would be
to access someone else's
internet connectivity
and make sure you're connected to that.
And in fact, if we keep going
with load balancer 3 or even 4
or server D, E, and F, this picture very
quickly starts to get so intertwined.
But this is how you do it.
And not too long ago was this done
entirely with wires and hardware.
But these days this topology,
if you will, this architecture,
is increasingly done in software.
And indeed, the whole
thing is done in the cloud.
Less frequently do staff of
companies find themselves crawling
along the floor and in wiring
closets and in data centers,
so to speak, making these
connections possible,
but rather they do it
virtually in software.
And indeed, thus was born the cloud.
Well, it turns out that as
Moore's law, so to speak,
helps us in each passing year, we
seem to have computers that are
half as expensive and twice as fast.
Can we ride that sort of curve
of innovation in such a way
that we can solve even more
problems each year more quickly?
And yet, with each
passing year, I the human
am not getting any better or
faster at checking my email
or using the web, so we increasingly
have on our laptops and desks
and our server rooms
more computational power
frankly than we really know what to do.
And so increasingly in vogue these
days is to virtualize that hardware,
and to take physical hardware with so
many CPUs and so much RAM and so much
disk space and to write
software that runs
on it that creates the illusion that one
computer is two, or one computer is 10.
That is to say, through
software can you write
code that virtualizes that hardware,
thereby creating the illusion that you
can have one server per customer
but all 10 of those customers
are on the same machine.
Virtualization includes products
like VMware and Parallels
and other companies
as well, and it's just
software that runs on
top of the hardware
and creates this illusion, which
then is all the better for business.
If you can sell one piece
of hardware multiple times
but not necessarily in a way
that you're over-provisioning it
to multiple customers, but rather
you're isolating each of those customers
from one another, giving them not
only the illusion of their own machine
but indeed, the constraints
whereby my data can't
be accessed by another customer who
only has cloud access there, too.
And indeed, this is really in
part, why we have now this cloud.
The cloud is more of a buzz
word than anything technical.
Indeed, using the cloud just
means using servers somewhere else
that someone else is managing.
No longer do companies with as much
frequency have their own server
room in their office, or their own data
center in some warehouse somewhere.
Rather, they virtualized even
that piece of their product
using Amazon or Microsoft
or Google or others
out there that provide
you with access to servers
that they themselves
control, but they provide you
with access to the illusion of your very
own servers known as virtual machines.
And via this process can
we take ever more advantage
of so many of those new
CPUs and disk space and RAM
that otherwise might
frankly go to waste,
because there's only so much we can
typically do with one such machine.
Hence you might now think of this
design, this stack, so to speak,
as follows.
In green here pictured is
infrastructure, the physical hardware
that you have bought.
Here in blue is the
hypervisor, the software
called VMware or Parallels or something
else, that virtualizes this hardware
and creates the illusion
that you actually have
three machines, for instance, on one.
And within each of those
machines, which you can think of
is just a separate window on
that computer, double click
to open computer A so to speak
and computer B and computer
C, each of those virtual machines, you
can install your own operating system
differently in each of
those virtual machines.
Some version of Windows
in A, another in B,
and maybe Linux or Unix or something
else in C. And then within A, B, and C
can you install your own apps, your
own software, or so can your customers,
thereby being isolated, not so
much physically but virtually,
from everyone else.
But of course, there's always a price.
While this might take better
advantage of the increasing
computational resources
that we have in these boxes,
there seems to be some duplication here.
And indeed, in computer
science, anytime you
start duplicating resources
or efforts there's
probably an opportunity
for better design.
And while this technology
itself is still nascent,
there's a newcomer to the
field called containerization,
and it exists in multiple forms.
But containerization shares
more software, in some sense,
underneath the hood, so that you might
install an operating system not three
times but once, and share it across
those machines but in such a way that
one cannot access the other.
And on top of that layer,
here called Docker,
one of the most popular
incarnations thereof,
you have as before your
infrastructure, the actual hardware,
on top of which is your own operating
system, be it Windows or Linux.
On top of that is this program
called Docker that provides you
then with the ability
to run A through F apps
instead of say, just three
because the overhead, so to speak,
computationally is not quite as
much as with virtual machines.
Here we have three operating
systems, each installed independently
on the same hardware, we're
just surely consume time,
whereas here you have just one
operating system theoretically and then
more room for more apps there upon.
So whereas containerization
allows you ultimately
to isolate one app from
another, in virtual machines
allow you to isolate one
machine from another,
they do this through different
techniques and with disparate overhead.
And surely in the years to
come will this overhead only
get chipped away at as
we humans get better
about running more and more software
and less and less but more capable
hardware.
There than we have these internet
technologies all the way up
to cloud computing itself, whereas
the technologies we've looked at
are fairly low level protocols that
simply get zeros and ones from point A
to point B. Once we have that ability
and we can stipulate that we can do it,
we can build any number of
abstractions on top of it.
In HTTP, for instance, do we
have effectively an application,
known as web browsing, via which we
can transmit text and images and sounds
and so much more.
And via the cloud itself
do we have the ability now
to slice up individual machines
as though they are multiple
and that picture before can be
implemented not with two load
balancers and three servers physically,
but maybe, just maybe, with just one.
One server that's been
so virtualized or in turn
containerized so that you can have
different parts of its hardware each
implementing different pieces of
functionality that collectively
implement that architecture.
And so whereas back in the day
might you actually physically
wire all of those disparate
types of machines together, now
can you do it virtually in software
literally with keystrokes and mouse
clicks because someone has written
software that abstracts away
that underlying hardware in such a way
that you can think about it virtually.
Now at the end of the day, the
servers in Google's and Microsoft
and Amazon's closets are still
completely physical themselves
with so many cables, but you can reroute
information, those zeros and ones,
different ways virtually
thanks to these layers
that we've built on top of
these internet technologies.
