BRIAN YU: Let's begin by thinking about how
it is that computers and other devices communicate with one another
over the internet.
Presumably when this happens, one device is
sending some sort of message over the internet to another device.
And that other device is responding back with some sort of message.
And computers and other devices all across the internet
are performing this process, sending and receiving messages,
whether those messages or emails or web pages or chat messages or something
else, but how is this all happened?
Well, it turns out that computers and other devices on the internet
have standardized on a set of protocols some basic rules
to follow that govern how it is that these devices should be communicating
with one another.
And one of these protocols is called TCP/IP.
TCP stands for transmission control protocol,
and IP stands for Internet Protocol.
And these are the protocols that determine
how it is that computers are able to communicate with one another
over the internet.
How does this work?
Well, you can think of it as analogous to sending a letter in an envelope,
for example.
We have an envelope here that we want to send from one computer to another.
Or you can think more physically as sending from like, one address
to another.
What information needs to go on that envelope for us
to be able to know who we're sending information to
and to make sure that envelope can get to the right place.
Well, on a real envelope, you need the name and the address of the recipient.
And you'll also put on the envelope the sender and the sender's address.
And much in the same way that when you're sending physical mail,
you include the address of the person who you want to receive the message,
as well as the address of the person sending the message.
On the internet it's very similar, except instead of physical addresses,
computers and other devices on the internet
have IP addresses-- internet protocol addresses.
And these often take the form of some number, dot some other number,
dot some other number, dot some other number-- four numbers separated
by dots.
And so you might imagine that on this digital envelope
that we're sending from one computer on the internet
to another computer on the internet, we might have on the face of it
1.2.3.4, the IP address of the computer that we
want to be receiving this message.
And then we include our own IP address, the IP address of the sender.
In this case, 5.6.7.8.
Of course, this envelope contains more information than just this.
But at minimum, it definitely needs some address
that we're sending information to and some address
that we're sending information from.
These four numbers that make up the IP address, #.#.#.#,
all range from 0 to 255, so from 0.0.0.0 to 255.255.255.255.
And if that number 255 sounds familiar in binary,
the number 255, as you might recall, is really just eight ones
one after another, which means each of these numbers inside of an IP address
is represented by eight bits of information from all eight zeros
to all eight ones.
There are four numbers.
So four numbers with eight bits each means
that in total, we have 32 bits with which to work with IP addresses.
And if you recall, 32 bits means we can count as high as about 4 billion,
which means there can only ever be 4 billion addresses that
are available on the internet.
4 billion devices that are connected to the internet that
have addresses to which we can send information or that
have addresses that can be the senders of information themselves.
And while 4 billion feels like it's a pretty big number-- the number
that you can represent using 32 bits worth of information-- in practice now
with the internet so ubiquitous and with billions of people, many of whom
have computers but not just computers, but also phones and other devices
that are all connected to the internet, we're
fast running up against this 32-bit limit.
And it's for that reason that this notation of #.#.#.#,
each of which is 8 bits, is known as IPv4,
v4 of the internet protocol using 32-bit addresses,
we now have a newer protocol called IPv6 that uses 128-bit addresses instead
of 32-bit addresses, allowing for far, far more addresses that can be
available on the internet.
IPv4 is still pretty common.
But many devices now are transitioning to IPv6,
as the addresses that they use in order to communicate with one another
over the internet.
But what other information do we need in addition
to just the address of the person that we're sending information to?
You might imagine that if a computer has some IP address that
allows other people to send them messages over the internet,
that computer might be receiving a whole bunch of different types of messages.
That computer might be receiving emails and packets
that are traveling over the internet.
That computer might be receiving web pages.
It might be receiving file transfers from other devices.
And the computer needs some way of knowing
how to distinguish between all these different types of packets
of information.
Is this packet of information an email, or is this packet of information
a web page?
This is important relevant information that this device needs to know about.
So in order to solve that problem, we assign
each of the different services of information-- things,
like email or web pages or file transfers a number.
And that number is called a port number.
And so some common port numbers are 21 for FTP, a file transfer protocol that
allows you to transfer files over the internet,
25 for SMTP commonly used for email, and 80 for HTTP, which
you might be familiar with, which is for sending messages
over the internet in the form of web pages, for example.
And there are many other ports that are used as well.
So what really goes on the envelope, then,
is not just an IP address of the destination
of who you want to be sending a message over the internet
to but also a port number.
So it might look something like this--
1.2.3.4 is the IP address of who it is that you want to send a message to,
colon, and then the port number 80, in this case,
indicating HTTP, which means we're sending a web
page from one computer on the internet to another computer on the internet.
But these IP addresses are not what you and I would normally
interact with when we're typing in URLs into our web browser
in order to try to access a web page.
Indeed, we're not really typing IP addresses.
You more commonly are probably typing a URL--
something like this-- http://www.example.com
that tries to specify which website it is that you want to visit.
But if we've just established that all these devices on the internet
are identified by their IP address and not by the URL that looks like this,
how is it that our web browser knows that when we go to www.example.com,
what IP address should the computer be trying to connect to?
In order to solve that, we use what's called DNS or the domain name system.
And what DNS really is is it's really just a mapping between URLs--
things like google.com or harvard.edu and yale.edu
with their corresponding IP address.
It would be pretty annoying if every time you wanted to visit a website,
you needed to know the IP address of the server on which that website was
being served from in order to type in those exact numbers.
It's much easier to remember something like harvard.edu or google.com.
And so DNS is a bunch of servers--
these DNS servers that exist on the internet that
know for any particular URL what IP address does it correspond to.
And so when you type something like google.com into your web browser,
your web browser can check with the DNS server
and say, what is the IP address of google.com?
And once it knows the IP address, then your computer
is unable to communicate and say, let me go to google.com
and request google.com's web page from there.
So that's DNS.
This way of taking these URLs and translating them
into the corresponding IP addresses so that we
can take a URL, like http://www.example.com
and figure out where on the internet is the server that
is going to serve us that web page.
But let's now take a closer look at this first part of URL, http.
And HTTP, as it turns out, is yet another protocol
that exists on the internet.
In this case standing for hypertext transfer protocol.
Hypertext just being short for HTML or a markup language which
we're going to see shortly.
But what HTTP is all about really is what's
inside of each of those envelopes that when you send an envelope from one
device on the internet to another device,
sure, on the outside it's labeled by the IP address of the person
you're trying to communicate with and your own IP address of the sender.
But what's inside of the envelope?
What is the content of my request to a web server when
I'm trying to get a web page?
And what is the content of that response that
comes back when I am trying to get information back from a particular web
server?
Well, when I make a request, it might look a little something like this.
So inside of that envelope, we might see content
like this where the first word you see here is GET.
This is what we call a request method.
And in this case it just means I'm trying to get a web page.
Next up is this slash.
And the second part of specifying what particular resource on the web page
that I'm trying to connect to, do I want to get back?
And so many websites, like google.com, for example,
have a /search or a /settings or any number of other pages that I might want
to try to access.
Some may also have images that I might want to get.
And so this slash in this case is specifying
that I just want the root of the website-- whatever
I would get to if I went to in this case, www.example.com.
But as you might imagine, I might go to www.example.com/ something else to get
a particular page.
And that would go in the second parameter here.
Following that is HTTP/1.1.
This is specifying which version of the HTTP protocol
that I'm using in order to communicate with this host.
In this case, I'm using version 1.1, which is quite common.
Nowadays version two is also pretty common.
But you'll still see HTTP version 1.1 around quite a bit.
And beneath that I'm connecting to a particular host--
something like www.example.com example as the host
that I want to communicate with.
It's possible that the web server that I'm communicating with
is actually holding multiple hosts altogether
and is balancing between them.
And so in my request, I need to specify what host do I want to connect to?
In this case, www.example.com.
And there's more information that comes in the request other than that.
But the key ideas here is that I am trying
to get a page from a particular host.
I specify what page it is that I want to access in addition to specifying
which version of the HTTP protocol I'm using in order to try and make
this request to the website.
What then responds back to me when www.example.com receives my request
and wants to send something back to me the person who
requested this page in the first place, well,
the response might look something like this.
Again, starting with HTTP/1.1, the version of the HTTP protocol that is
being used in order to communicate information.
Next up is this number 200.
This is what we would call a status code.
Every time HTTP gives you a response, it's
going to come along with some code that specifies
how the response was resolved.
And 200 just means as the word immediately following it
would describe everything was OK.
We were able to successfully give you back some sort of response.
What type of response came back?
Well, that comes on the second line of the response.
Content type colon: text/html means the response that came back to me
is some HTML, some markup that's ultimately
going to represent a web page.
But more on HTML in just a moment.
The response has more information again than just that, likely
the actual content of the HTML that's coming back to me.
But in short, this response is specifying
the version of the HTTP protocol, the status code that came back,
200, meaning OK, and then the content type-- what type of information
is coming back to me.
In this case, it was HTML.
But it very well might have been a text file or an image
or any other information that might have been transferred over the internet.
This status code 200, meaning OK maybe isn't something you've seen before.
But certainly if you've used the internet,
there are other status codes that you're probably more familiar with.
For example, 404 might be pretty common which means not found.
If you try to request a page that just isn't there,
HTTP says that the server is going to respond with a status code of 404,
meaning that it wasn't found.
And there are other status codes as well.
Status codes, like 301 which means move permanently.
In other words, this page has moved somewhere.
And so you'll often be redirected from one page
to another page when you receive a status code of 301.
403 is a status code meaning forbidden.
For example, if you try to access a page that you don't have permission to see
or that you need to log in to see first, you'll
very often see a status code of 403, meaning
you don't have permission to be able to see this particular resource.
And status code 500 generally means an internal server error.
Whoever programmed the server that is accepting these requests
and responding with information likely has a bug in their code,
for example, that might result in an error that occurs.
And so that's when a status code of 500 gets responded as well.
And there are many other status codes.
But these are just some of the more popular ones.
And status code 200 is what comes back all the time when you request a page,
and you're able to view it successfully.
The web browser usually doesn't show you the status code number 200
just because everything went well, so there wasn't a reason
to show you anything in addition.
But as we'll see in just a moment, we can take a look
at what's actually happening in the network--
what messages are being sent--
what responses are coming back.
And in those responses, we'll often see a status code of 200
which will indicate to us that everything was indeed OK.
So let's take a look at a real example and actually
try to open up a web browser and see what
happens when we make a web request when we type in a URL
and try and visit a web page.
I'll go ahead and open up Google Chrome, although this feature is
available in other web browsers as well.
I'll go up into the View menu.
And I'll go to Developer and then Developer Tools.
And then over here on the right-hand side,
I'm going to go to the Network tab, which is going to allow me to monitor
all of the network traffic--
all of the requests and responses that are coming from my web browser
and being sent back to my web browser.
So we go to the URL bar.
And let me just visit a website, like google.com, for example.
And we'll take a look at what happens after this web page loads.
All right, so once google.com loads, you'll
notice here in the Network tab a lot of things have shown up.
But I'm going to ignore most of that and just scroll up to the very top
where I'll notice that I had an initial request for google.com which
is what I typed in.
And I'll click on that just to take a look at some more details.
Here I see the headers.
And if I scroll down, I can take a look at the Request Headers, which
was the information that I sent to Google's servers
when I tried to request this web page.
And I can also see above that the Response Headers,
the information that came back to me when
Google responded with this web page.
I'll go ahead and click the View Source button here just
to see what was inside of this request.
And you'll notice right here we see HTTP/1.1,
meaning version 1.1 of the HTTP protocol.
And the response code that seems to have come back to me
is 301, move permanently-- one we've seen before that means
I've been redirected to somewhere else.
Well, I typed in google.com.
So where have I been redirected to?
Well, if we look immediately below it on the second line,
we see location: and then http://www.google.com.
So it seems that whenever I try to visit google.com,
Google is redirecting me to www.google.com instead.
And this is a fairly common convention where www stands for worldwide web.
And many web applications are hosting their website
on www.something, for example, although strictly speaking, that isn't required.
So I've been redirected to www.google.com.
And we can see that here I have www.google.com.
This was the next request that my web browser
made because it saw that I'd been redirected somewhere else.
Here, 307, Internal Redirect just means I've been redirected again.
Where have I been redirected to?
Well, it looks like here, I've been redirected to https://www.google.com.
So https, the s standing for secure, just
means that Google wants me to connect to their website securely.
And indeed, more and more websites nowadays
are using https, a version of the protocol that
allows for information to be encrypted when it's transferred between one
computer and another over the internet just to make sure
that that connection is more secure.
And so now, I'll go to the next request that my computer made.
Here, the URL that I was requesting is now https://www.google.com.
And now, finally, the status code is 200, meaning everything was OK.
So what happened here?
I typed google.com into my web browser.
And I got a 301 response code, meaning that I'd been redirected
to somewhere else, www.google.com.
When I went there, I made a request to that URL
and got another response, which was that I'd been
redirected to https://www.google.com.
And when I made a request to that URL, now and only now
do I see that I get a status code of 200 meaning that everything was OK.
And a lot of other resources have come back,
as well, so when you load Google's web page,
it's likely loading other scripts or other images or other fonts,
for example, that all need to be loaded in order to display this web page.
But the key here is that anytime you make a request over the internet,
it's using this HTTP protocol that allows me
to make a request to a particular URL.
And when the response comes back, I can actually
see what's going on using the Network tab of Google
Chrome or similar features for other web browsers
that you might be using in order to get an understanding for what exactly
is coming back from this web server.
And as we'll see later on in this track, we'll
start to build web applications of our own
where we're writing these web servers and deciding
what status code should be returned?
What is the content that should be returned back to the user?
When they make a request to slash or to slash something
else or to any other page that might exist on our web application.
So ultimately, there are a lot of protocols
at play here in determining how it is that devices on the internet,
be that your computer or phones or tablets
are able to communicate with other devices on the internet.
We saw a TCP and IP, a transmission control protocol
and the internet protocol that are determining things
like how it is that information is sent from one device
to another-- what goes on the outside of that envelope-- things
like the IP address, the address of who it is that you're trying to send
information to in addition to the port number that determines what kind
of service you're trying to communicate, whether that be an email address
or whether that be a web page or whether that's a file
that you're trying to send from one person to another person.
And then we saw HTTP, the hypertext transfer protocol,
which is the protocol that determines what's
actually inside of that envelope.
What is the information that I am sending to a web server
when I'm trying to request a web page?
And then what comes back to me in that response--
the version of the protocol, the status code,
and then the actual content of what comes back to me.
So next, we'll take a look at that actual content
and take a look at how to build web pages that
can be sent using the HTTP protocol and ultimately
viewed inside of your web browser.