[MUSIC PLAYING]
DAVID MALAN: So odds are you're on the internet these days,
but what does that actually mean?
And indeed, this internet that we use very often these days for messaging,
for email, for browsing the web and other services still,
there's a whole infrastructure that underlies it that is increasingly
powering new ideas, new start ups, new companies, new businesses
as well as new forms of communication among humans.
And yet, like most every topic we've explored,
you'll realize that while it's very complex,
perhaps, up here, or certainly seems complex
up here, if we begin with some of the fundamentals and then layer
and layer and layer on top of those, do we pretty quickly get
back to today's technology but with a much better understanding of what's
going on from the ground up.
So here is a bit of alphabet soup.
Odds are you might have seen one or more of these acronyms
to date, IP, DHCP, DNS, TCP, UDP, ICMP, and so many more.
These are all examples of something called protocols,
where protocols are kind of like languages
that computers speak with one another.
They're not programming languages so they're not
used by humans to make computers do things or follow instructions per se.
A protocol is really a set of conventions
that two computers or two computer programs
might use when intercommunicating.
And so what's an example of a protocol in the real world?
Well, we humans have some silly protocols, one of which
here is, culturally, when you meet someone to extend your hand
and then he or she presumably extends their hand
and you do this for who knows what reason.
And now you've sort of completed that social transaction.
But it's a protocol in the sense that when I extend my hand,
most any polite other person knows that they're probably
supposed to extend their hand as well, embrace for a moment,
and then complete.
And the protocol says, too, you probably do this for terribly long.
And so there's these rules of thumb or actual rules
that you follow when implementing protocols.
And so computers, great as they are following rules,
very often use protocols when they intercommunicate,
in order to get data from one place to another.
So let's tell exactly that story.
If you're on the internet, right now, on the internet,
what does that actually mean and how can it
help us solve problems, ultimately, having access
to this inter-networked infrastructure?
Well, let's consider what happens when I first visit my favorite web
page, for instance.
If I go ahead and visit something like Facebook.com, I go ahead and log in
and I'm immediately presented with my news feed.
Or maybe your favorite website is Gmail or your favorite website
is Bing or maybe your favorite website is any number of other places
you might go on the web, all of which take in as input a request from you
and produce, ultimately, output, the screen that you ultimately see.
But how does that data get from one location to another?
Let's begin to draw a picture, perhaps.
And this picture might be representative of your own home network
or maybe your campus network or maybe your office network.
But generally speaking, you are on the internet
maybe with your phone or your laptop or your desktop device,
and we'll just depict that is this sort of abstract laptop here.
So that laptop somehow wants to communicate with a web server
elsewhere, Facebook, Google, Bing, whatever.
And we're just going to present that as way over here in the picture
in a really big corporate office building, perhaps.
And inside of that building are the servers
that compose that particular web site.
But how do I get data from that server, which, if it's Google or somewhere else
might be all the way in California or halfway across the world
and back to my laptop?
Well, somehow I have to be able to send messages to it
and receive messages from it.
And of course in between me and this resulting website
is what we'll generally call the internet.
It's kind of conveniently drawn as a cloud
here, which is another semi-technical term that's
come into vogue in recent years.
And the cloud really just refers to internet services these days.
It's not a technical term unto itself.
It's just a sexier term than saying, my business is on the internet.
Oversimplification, and we'll come back to that before long.
But you can assume here that the internet is somehow
this delivery mechanism.
It somehow gets data from point A to point B and back.
But how does that work?
If my data's coming in as input and it's reaching,
eventually, its destination and then a response
is coming back in this direction, what's actually going on underneath the hood
there, especially since, in the story at hand, all I've typed
is something like Facebook.com Gmail.com or the like?
Well, it turns out that your computer these days, when you first turn it on
and you connect to the Wi-Fi in a room or you connect with an ethernet cable
to the wired network, your computer receives some information
automatically.
Your computer speaks a protocol called DHCP, typically, Dynamic Host
Configuration Protocol.
But in most of these cases, the acronym isn't really what's important,
certainly, it's what the protocol itself does.
And in this case, this Dynamic Host Configuration Protocol
dynamically configures hosts via a protocol, if you will.
So what does this mean?
Essentially DHCP says this, when you turn on your computer
or you take out your phone for the first time
and you're connected on Wi-Fi or to a wired network, it says, hello, world.
I am alive.
I would like to be given an address that I can communicate
with other computers on the internet.
It's not quite that verbose, perhaps, but it is a question.
Hey, computers around me, please give me an address.
And what it gives you is what's called an IP address, Internet Protocol.
So just as in the real world where physical buildings have historically
been uniquely addressed with postal addresses
like Harvard's computer science building is at 33 Oxford Street
Cambridge, Massachusetts, USA.
02138 is the more precise zip code as well.
That uniquely identifies that building in the world.
So does my computer need an address, and it's not
going to be some free form address like that in words.
It's actually going to be a numeric address.
Specifically, I'm going to get an IP address of the form number dot number
dot number dot number, so four numbers separated by dots.
Each of those four numbers happens to be a byte long
or eight bits, so each of these numbers, therefore is between 0 and 255,
and so this means, long story short, that the total address is 32 bits--
plus 8 plus 8 plus 8-- and that means there's four billion possible addresses
in the world.
And that's great because people have got a lot of computers and a lot of laptops
and a lot of desktops and servers these days.
But it turns out we're actually running out
because we have so many such devices.
So there's a newer version of IP that's increasingly
being used called IP version 6.
We're talking here about IP version 4, since it's so omnipresent.
And IP version 6, just so you know, uses 128 bits for its addresses,
way more than 32, so we'll be good to go for some time.
But DHCP gives me this address, an IP address of the form something
dot something dot something dot something.
And the purpose of this address is to help my data get from point A
to point B. And indeed, anytime my computer sends
a request on the internet like, Facebook,
please show me my news feed, or Gmail, please show me my inbox,
my computer has to use that IP address.
So much like if sending a letter in the real world,
you might have an otherwise blank envelope
and you might want to send a message to someone else in the world,
you might write their physical address.
But in the computer world, we might write something like 1.2.3.4
in the to field, assuming that this is the IP address to which we
want to send this data.
Meanwhile, my from address might be 5.6.7.8,
so I'll write it in the top left hand corner
by convention, whereby that indicates to the whole internet this
is where this request came from.
Now, I know my origin address, the source address here at top left
because DHCP told me.
How do I know one, two, three, four?
How do I know the IP address of Facebook.com or Gmail.com, right?
We don't live in the world of 800 numbers
anymore, where you dial 1-800 something, something, something, something,
something and you have to advertise your phone number, per se.
We don't necessarily live only in the world of 1-800-COLLECT
any more where we had these mnemonics where you had letters mapping
to numbers just to help remember it.
We went full in on this idea of mnemonics
such that now we have Facebook.com and Gmail.com and no numbers
whatsoever for us humans to remember.
So thankfully, it turns out there's another system in this world,
another acronym, if you will, a new one now, called DNS, Domain Name System.
So there are also in the world, not just DHCP servers that
have people IP addresses from their local network,
there's also DNS servers whose purpose in life
is to convert domain names to IP addresses and vice
versa and a few other features as well.
Now, what does that mean?
That means that when my Mac or my PC sees
little old me, the human, typing Facebook.com
or Gmail.com, my laptop contacts a nearby DNS server and says,
hey, my human has asked me for Facebook.com.
What is its IP address?
And DNS server's purpose in life is to answer that question and say,
oh, Facebook.com, it's 1.2.3.4.
Use that address instead.
Now, thankfully, my computer can now write
that number on its virtual envelope, so to speak, and then
pass that envelope out to the internet.
And because of these numeric addresses, it will be properly, hopefully,
routed across the internet to its destination.
Because it turns out inside of the internet here,
interconnecting everything in between point
A and B are things called routers or gateways.
And I could draw this picture in any number of ways.
But the point is that it's just so darn interconnected.
And indeed, there might be even more pathways still
or maybe even fewer pathways.
Indeed, on the internet, there's often multiple ways
for data to get from one point to another, some shorter, some longer.
But there's this resilience, this redundancy,
and this was a feature back in the day, especially in so far
as the internet had militaristic origins.
It was meant to be redone into as to withstand failures of one or more
of these nodes, these dots in the picture.
Now, each of these dots is just a server, really,
a special server called router or gateway, whose purpose in life
is to do exactly that, to route data.
Upon receiving a virtual envelope like that one,
it looks at the to address realizes, oh, this is destined for 1.2.3.4.
I know that that address is over this way.
Meanwhile, if it gets another envelope from someone else,
it might say, oh, this is some other address.
It's going to go this way.
And so routers have multiple cables or they
have multiple virtual network connections elsewhere
or wireless connections, any number of possible connections
might they have to other routers.
And so it can route it to its next hop, so to speak.
And generally on the internet, within 30 hops,
within 30 transmissions from router, router, router
will your data get from one point to another.
And it might not follow the same path each time
but it will traverse this so-called internet.
And so that's kind of what the internet is.
It's this collection of routers and it's this collection
of networks, a network of networks that is incredibly
interconnected in different ways.
So DHCP gives me an IP address.
So I have a unique IP address.
DHCP, it turns out, also tells me what the IP address
is of my local DNS server so I know whom to ask to convert domain names to IP
addresses.
But once I have that, I can now use a protocol
called TCP to send my data reliably, typically, from one point to another.
So whereas IP is responsible for a few things,
one of its most important functions is this notion
of addressing and standardizing how things are addressed.
But TCP, one of its most salient features
is to guarantee, with high probability, delivery.
And what I mean by that is that bad stuff can
happen in the middle of the internet.
These routers can get really busy.
They can get really congested and overloaded.
And so routers might--
well, virtually drop packets.
They might receive so many packets at once they just
can't, like a human, deal with it all at one time because they
have a finite amount of memory or RAM or disk space and so they drop them,
so to speak.
They just delete them and they expect the senders to resend them.
TCP is a protocol, another agreement between computers,
that if the receiving computer realizes, hmm, I got some of your packets
but not all of them, TCP mandates, much like our human handshake,
that something next should happen.
TCP says, my laptop should retransmit that virtual envelope.
But TCP allows us to do something more than guarantee
with high probability delivery of data.
It also allows us to multiplex among services, or put more simply,
it allows a server to receive different types of data
for different types of services, for instance,
web services on the server, email services, chat services and the like.
And so it turns out that on this virtual envelope that gets sent from a computer
to a server, it's actually not sufficient
for there to be the return address and the IP address of the destination.
I also need to specify what type of information
is inside this envelope, or equivalently, what kind of service
I'm trying to contact.
And I could do this by specifying in words what's inside this envelope.
Maybe it's something like HTTP, the prefix
that you're familiar with from the web.
Maybe it's an email.
Maybe it's a chat message or the like.
But if it is, in fact, something like HTTP,
turns out the convention is not to use words but to use numbers.
And so in fact, I need to pull one other piece of information
on this envelope, which is a so-called port number, a TCP port
number, which is numerically printed after a colon on a virtual envelope
this.
And in this case I wrote 80 because 80 happens to be,
by human convention, the number we humans agreed on some years ago,
identifies web services on servers.
But this means that if the server I'm sending this to,
1.2.3.4, actually has other services on it like a chat server
and an email server and the like, this won't get confused with an email
that I or someone else am sending to the server or a chat message.
The server will know upon receipt of this,
oh, this is a request for a web page.
Let me send this virtual envelope to the web server.
But HTTP isn't the only such protocol.
There are something called UDP, which is common in some circles as well.
UDP works a little differently, in so far
as its feature is to not guarantee delivery.
If some data gets lost, packets get dropped, so to speak,
for whatever reasons, malfunction, technical difficulties,
routers are overloaded, UDP says, our protocol
shall be not to retransmit that data.
And that's a strange thing, because it sounds worse.
And yet, this protocol's been around for quite some time, still used,
quite appropriate in some contexts.
But what context would you actually want to just forge ahead, irrespective
of getting complete information?
Well, go to here is something like videoconferencing or audio conferencing
or live TV on the internet, watching a game like a football game,
for instance.
If you want to watch it in real time, you
might prefer that the stream, the bits that
are coming from the NFL or wherever to your computer don't actually buffer
don't actually stall.
You would rather miss a second so that at least you stay
current in real time with that game, or video conferencing even more so.
It'd kind of be annoying if you have a bad connection or some packets
get dropped and you just have to wait and wait for the person's voice
or image to be retransmitted.
You'd rather just say, what did you say?
Could you repeat yourself?
Say again?
You can just use human protocols to deal with that, too.
So sometimes you want live streaming applications for whatever purpose
and you want the data just to keep coming.
As much of it as can make it through is great.
But you don't necessarily want it to be resent.
So data is going from one point to another,
but how long does all this take?
My god, this is kind of a long story just to get data there.
Well, let's do an experiment.
Let's go ahead and pull up a program that uses a different protocol
altogether, ICMP.
And there's other protocols, still.
This one's a little more technical but it's
wonderfully revealing in a few ways.
I'm on my Mac here in the so-called terminal window
that you can pull up something similar on Windows and other operating systems
as well.
And what I'm going to do is literally trace
the route between my laptop here and some foreign server,
for instance, one on the west coast of the US, Berkeley's web server.
So let me do that, traceroute, www.berkeley.edu, enter.
And curiously, we start to see a whole bunch of lines of output, most of them
numerical.
And indeed, notice that each of these is an IP address.
But what is it an IP address of?
Well, we have 18 of these between me and Berkeley, apparently.
Turns out those represent routers between me and Berkeley, California.
Each of them has an IP address and each of them
has a measurement of how long it took my data to get from my Mac to that router.
It's highly variable.
Notice, it's kind of all over the place.
In fact, this is just weird.
This took 3,000 milliseconds or three seconds,
so I'm guessing that that router in row eight
was congested for some reason, some kind of network issue there temporarily,
but then my data actually went through.
And it's not cumulative.
These are individual tests from my Mac to each of these routers
iteratively, one at a time.
And you can kind of get an aggregate sense
of how long it takes, therefore, for data to get from the east coast
to the west coast.
If we look at some of the later numbers, they're kind of variable
but they seem to be around 75 milliseconds.
So this is kind of extraordinary.
If you want to fly from Boston, Massachusetts to San Francisco,
it's going to take you five, six, seven hours.
You want to send an email or send a packet,
it's going to take you 75 milliseconds.
That's astonishing, how quickly the data can transmit.
Now, notice this is not all that enlightening
knowing these IP addresses.
But eventually, some of them have domain names,
just because the humans controlling those routers decided,
we're going to give these routers actual names, domain names,
as opposed to just having IP addresses.
And you can often, but not always, infer from the domain names where they are.
So I'm going to guess that at least row 11
here, I don't know what XE7000.rtsw is, but losa.net, Los
Angeles in California.
I'm guessing my data kind of came into Southern California first.
But then notice what happens next.
A couple of nameless servers, LAX, so maybe that's the airport.
Indeed, routers, for historical reasons, tend
to be named after a nearby airport codes.
I'm not sure what this next one is here but I do
recognize Oakland and UCB, UC Berkeley.
So I'm guessing one of the next routers is actually in Oakland or near Oakland.
And so that's a pretty long cable or interconnection essentially
between LA and Berkeley.
But the result, ultimately, is that my data makes its way
to Berkeley, this time via this path.
If I ran it again now or in a day or a week,
the path might be a little different based
on congestion and interconnectivity, but the data actually gets there.
And cutely enough, it looks like Berkeley's web server is called Cal web
farm prod-- for production--
ist.berkeley.edu.
75 milliseconds only.
But what about this, what if we don't stop at the edge
as we do at the edge of this continent but keep going?
What's going to happen?
Well, let me try to trace the route to, say, www.cnn.co.jp,
the domain name for what I presume is going
to be the Japanese version of CNN's web site in Japan.
Here, too, we have a bunch of nameless servers just with IP addresses.
Gets through them pretty quickly.
We seem to have some lulls sometimes.
This program won't-- sometimes the routers won't respond to these queries
so they remain, essentially, anonymous.
But now this is quite interesting.
Oh, my god.
We went from routers 12, 13, 14, 15 taking about 63 milliseconds,
give or take, to 193 milliseconds, which isn't a blip because it
stays around that value, 180 milliseconds,
160 milliseconds, 177 milliseconds.
That's a big jump of 100-some milliseconds just between routers 15
and 16.
Why might that be?
What could be between routers 15 and 16?
Well, if you know your geography, it might very we be the Pacific Ocean.
There's quite a bit of distance, there's quite a bit
of cabling that actually connects the west coast of the country to Japan
and other areas in Asia and beyond, and that's what's pretty amazing.
Not only is there interconnectivity on the internet these days via cabling
and via Wi-Fi signals and via satellite signals,
via microwave signals and the like, you have so many different ways for data
to be transmitted.
And it's absolutely astonishing and exciting, dare I say,
just how interconnected the world now is.
In fact, thanks to this animation online, let's take a look
and appreciate just how extensive this network actually is.
[MUSIC PLAYING]
All right, so let's actually solve a problem now with this internet.
All right, the internet, as you probably heard, is filled with cats.
And yet, these cat images can be pretty big.
And indeed, bigger, still, than images are
things like video files from Netflix and the like.
And so there's huge amounts of traffic transmitting
over those kinds of interconnections.
So how do we ensure, at least with high probability,
that data can actually get through?
How can we ensure that there's some form of fairness, if not net neutrality,
so that my data can get to its destination
just as readily as your data can get there?
Well, sometimes it's opportune to actually take
big packets of information and chop them up.
So indeed, what a computer will often do, thanks to TCP/IP,
the combination of these protocols, is we'll
take large files and large images, in this case,
tear them up into, say, roughly--
oops-- equal sized parts like this here and then tear it down even further,
perhaps, to get it into a smaller byte-sized piece
and then send not only one packet of information over the internet.
But instead, put one piece of information in this packet here.
Put one other piece of information in this packet here,
whose addressing, both to and from, is identical.
And then do the same thing for the two other pieces
so that ultimately we have four packets, each of which
contains one portion, one quarter, in this case,
of the resulting message, all of which are destined for the same destination.
But the problem to be solved, now, is what do you do with this information?
If I have four seemingly identical envelopes
but inside of which are disparate pieces of information
that somehow need to be reassembled--
let's put on our proverbial engineering hats--
how do you solve this problem?
Is this sufficient information on the envelopes so
that if I send this out on the internet toward Berkeley or Stanford
or Facebook or wherever, how does that recipient know what to do with it?
What would you, the human, do if you have
not virtual but physical envelopes?
Well, here, too, and here's an opportunity
really to bring to bear human intuition to a problem that
seems fairly technical and well beyond one's own technical understanding.
And yet, it really is just a technical manifestation of a real world problem.
I need to keep these in order somehow.
So you know what?
I'm going to say something like one of four on the first one, like this.
The next one, I'm going to say two of four on the next one, like this.
And then I'm going to say three of four and then on the next one
here, I'm going to put four of four.
And what's the takeaway, now?
Now, whoever is the recipient of these several envelopes
as I send them out on the internet-- and indeed,
they don't have to follow the same path.
One can go this way.
One can be routed that way.
Another can go to this router.
Another can go to that router.
Because they're all addressed and because all of these routers
are somehow interconnected, all four of those packets
will hopefully get to their destination.
But if they don't, the recipient can look
at that additional detail I wrote on the envelope and see, oh, I got part one.
I got part two.
I got part three.
But where is part four of four?
It didn't arrive because of congestion.
Literally got dropped on the floor or not picked up.
So the computer, who's supposed to be receiving
that data, thanks to TCP recall, can say, hey, please send me again
packet four of four.
And so as technical as the internet might seem,
it really, again, is just some fairly intuitive solutions
to problems like this, albeit translated to more technical contexts, more
technical protocols, and more technical languages.
But let's look at some more user-facing protocols.
The ones we've discussed thus far are fairly low level, if you will.
And indeed, there's this whole internet hierarchy
of protocols layer on protocols layer on protocols
so that what we humans really tend to care about, if we're not the engineers
but we're really the software developers and we're the users of applications,
we care about application layer protocols that
is right between the human and all of those lower level protocols.
For instance, these, at least one of which has got to jump out at you, HTTP.
Odds are you've seen this.
Odds are you've typed this, though decreasingly
do you have to still type it because browsers will just add it for you,
HTTP.
The secure or encrypted version, HTTPS, IMAP for email in-bounds,
SMTP for email outbound, SFTP for Secure File Transfer, SSH for Secure Shell,
an encrypted text textual channel between two computers, and many more.
But HTTP, let's focus on that one because that is Hypertext Transfer
Protocol.
Or HTTPS, the same but the S stands for--
not savings-- secure, so it's actually encrypted in this case.
So what does this actually mean?
Well, at the end of the day, HTTP is a protocol
that governs what kinds of messages go inside of those envelopes
that I've been preparing for the internet, what kinds of messages
go inside of those envelopes.
And it turns out the simplest message that a computer sends
through this whole internet, ultimately, inside of virtual envelope
is quite often, thanks to HTTP, inside of this virtual envelope,
if I'm trying to request a cat from the internet,
might literally be a message like this, get me,
for instance slash cat.jpg for JPEG.
And maybe some additional text after that,
maybe some additional text below that, but at the end of the day inside
the virtual envelope, if I am on the internet and I'm going on Google Images
and I want to find a picture of a cat, inside of my envelope,
if I am a web browser speaking HTTP is going to literally be a textual message
that says get/cat.jpeg, if I know that's where the image is on some server.
The response is going to be what was just inside of those
four envelopes back from the server to me,
chopped up maybe into multiple pieces but in a way where I can then
realize, oh, wait a minute, you sent me only three or four.
Please send me the fourth one.
So it works in both ways, whether it's me sending a cat to someone
or receiving a cat from someone.
This protocol, HTTP, governs how the messages are formatted
and what language, so to speak, is spoken between web browser and server.
So indeed, HTTP is entirely about having a web
browser communicate with a server.
And we can see this in action.
I'm going to go ahead and pull up a so-called terminal window again,
this textual command prompt on my computer.
And I'm going to pretend to be a browser.
So I'm not going to just trace the route between point A
and point B. I'm actually going to request a web
page as though I am Chrome or Edge or Firefox or Safari
or whatever your favorite browser is.
But of course, as before, all I know is that I
want to visit my favorite web site, Facebook.com, for instance.
But I don't know its IP address necessarily,
so let's go through that step.
How do I look up its IP address?
Well, my Mac already has an IP address because of DHCP.
I'm already powered up.
I'm already connected to the Wi-Fi here on campus,
and so I already have my own IP address, and I also
have the IP address of a DNS server.
So my Mac just knows that.
But I can use that capability now to look up the IP address
for the name, Facebook, and I'm going to do that as follows,
nslookup, for name server lookup.
And I'm going to go ahead and type in www.facebook.com, enter.
And interestingly, we get back this somewhat cryptic response
but let's make some sense of it.
So it looks like the server that this response came back from 10.0.0.2,
which happens to be a private IP address here on campus that you might have
in your own company or university or even home network,
Then a non-authoritative answer is this, www.facebook.com,
whose canonical name is, curiously, star-mini.c10r.facebook.com.
Well, it turns out that companies like Facebook
absolutely have many, many, many different web servers,
and they might not necessarily have just one IP address.
But we might just be seeing one IP address
depending on where I am in the world and depending on how Facebook
has configured its infrastructure.
The takeaway, then, is that apparently so far as my Mac is concerned,
www.facebook.com is an alias for or a synonym for this
longer less well marketed domain name here.
But what we really care about, if I'm about to pretend to be a browser,
is this IP address.
Facebook's IP address is apparently 31.13.65.36.
And I can see this, in fact.
Let me go into Google Chrome, or any browser for that matter,
and go to http://31.13.65.36, enter.
And voila, I made it to Facebook.
Now of course no one in their right mind is
going to advertise the IP address as 31.13.65.36.
No one would remember that.
We're not in the age of phone numbers on the side of billboards anymore.
Now we have Domain Name System and DNS which does this conversion for us.
But now that I know that IP address, I can use this information
and pretend to be a browser and not just see the response in Chrome
as we just did, but I can see it in my textual window
so I can look inside the envelope.
Indeed, this terminal window is going to let me pretend to--
well, actually send a message as though I'm a browser pretending to be one.
But it's going to let me see inside of the response that comes back.
Here's what I'm going to do.
I'm going to go ahead and type in cURL dash I,
and I'm going to go ahead and type http:// and then that IP address
and I'm going to hit enter.
And notice, uh-oh, Facebook has moved permanently.
But this is a good thing.
To where has Facebook moved?
Well, apparently we've gone back a response,
via version 1.1 of of HTTP that Facebook, per this status code, so
to speak, has moved permanently.
Has moved permanently, which sounds scary, but where has it moved to?
Oh, they don't want people visiting their IP address, even though it works.
They want to redirect people, so to speak, to their domain name.
So we seem to be kind of in a cyclical situation here where, wait a minute,
I thought I had to convert my domain name to an IP address.
And indeed, I do, but it turns out cURL is pretending
to be a text-based browser here, effectively,
and it is already going to do this DNS look up for me so this is OK.
I'm going to go ahead now and do cURL dash I, http://www.facebook.com, enter.
Oh, my god.
Facebook moved again.
But where did they move this time?
Well, it seems that Facebook would prefer
that we visit https://www.facebook.com, which
is the secure, the encrypted version.
OK, I can oblige.
Let's go ahead and do that.
cURL dash I of the HTTPS version, which I've just pasted in, enter, and voila.
Now, this looks overwhelming, but what's really important is this message here.
It turns out everything is OK.
And indeed, what's come back from the server
is a virtual envelope, inside of which is this message here saying,
hey, no big deal.
Everything is OK.
And you never see this number when you visit web pages,
unless you're a software developer and you know what tools to use.
Instead, some of us out there, some of us normal humans
occasionally see a different number, maybe the one number
you associate with the web.
Let me simulate it as follows.
Let me go ahead and request this completely bogus page.
Hopefully that's not actually someone's user name and hit enter.
Scroll back up a bit.
What do you notice this time?
If you've ever wondered what 404 means, it
is the numeric code inside of a virtual envelope coming back from a server
when you have requested some nonsensical URL because
of a typographical error or just nonsense
that I typed that's now having the server tell you, uh-uh, not found, 404.
So this is just a special numeric code.
And this is common in programming to have
numbers correspond to different types of things that can go wrong
or, better yet, that can go well, as in the case of 200 OK.
Now, all of this stuff is called HTTP headers.
So I was oversimplifying earlier when I said
HTTP is just this handshake of sorts between servers where you say,
get me a cat picture and then you get back the response as per those four
envelopes.
There's more headers.
There's more key value pairs, words with colons, words with colons,
words with colons, and then values to the right of those.
And that is just additional metadata, more information from the server that
tells you a little something about it.
But if I instead run that same command one final time,
this time doing cURL and then specifying not dash I but just the URL itself
and hit enter, this craziness comes back.
And this looks like a whole lot of programming language in something
called JavaScript or big JSON object.
And my god, look how much data came back from the server.
But notice, I'm starting to see some structure.
Open bracket div and the word label here.
And if I go up here, input here.
And indeed, what you are seeing is a language called HTML.
Inside of the virtual envelope, if you're requesting not a cat image
but a web page that has your news feed or your inbox from Gmail or your search
results from Google is a language called HTML.
And HTML's not a programming language.
And indeed, it's not as cryptic looking as this.
Google is being very--
or, Facebook is being very efficient when
it comes to showing me this information and just
getting rid of as much formatting as they
can to save space, to save on internet bandwidth or transmission thereof.
But it's a language that comes back in this virtual envelope
that a browser knows how to display.
It's a markup language in the sense that it's
going to tell the browser what to show on the screen, where to show the cat,
where to put words, whether to make those words big or bold or italics
or centered or any number of other things.
And indeed, what you are seeing is this.
This is www.facebook.com graphically, as we see it in the browser.
Underneath the hood is that black and white seemingly nonsensical Greek,
if you will, that at first glance, there's no way most of us
would understand it.
But that's because we're looking at it here.
We need to dive in a little deeper, take a look
at what HTML is, how it's actually structured,
make the simplest of web pages, a hello world of web pages, if you will.
And then can we realize and build back up
to this point exactly what composes pages like Facebook and Gmail
and Google and Bing and others.
Because at that point, we'll have understood not only
how the internet works, but how you can use it
as a delivery vehicle for your ideas, for your programs, for your products,
for your companies and more and actually deliver information and deliver cats
and much more to your users on this internet.