Welcome to Exploring Computing.
Today's video is Computer Networks--
What is a Protocol?
Today, we're going to be focusing on protocols.
And we're going to take a detailed look at the protocols
underlying the internet.
And it turns out that the protocols governing
the internet have quite a bit to do with what we can or can't
do with the internet and why the internet acts the way it does.
So let's start off by answering the question, what in the world
is a protocol?
I want to start off by talking about why we need protocols.
And I think that will give you a better sense of what
the protocols actually are.
Let's go back to the example we had last lecture, where
I've got a bunch of computers on the Wi-Fi network
in a classroom and I'm trying to send a message to my friend.
At the end of last lecture, we talked about naming schemes
and how to identify individual computers on the network.
So at this point, we have a way of identifying
each individual computer.
So suppose I want to send this message.
I don't have to send it to everybody in the classroom now.
I can give the specific address for my friend's computer
and make sure it goes to her.
But what am I actually sending?
Am I just sending the message and she's just
going to get a random message saying somebody
sent her the "I love computer science"?
Are we going to identify it with the address of the computer?
This seems a little bit creepier if we're
using the physical or MAC address here--
might be a little bit better if I had the hostname,
although, in general, most computers don't actually
have hostnames.
Hostnames are generally reserved for things
like web servers, where a lot of people
are going to have to access it using a name.
What I might want to do is include some sort
of information with the message that
identifies who sent the message and who
that message is going to.
So maybe something like this-- to Tammy, from Patrick.
But I have to decide exactly how that's being sent.
Remember, what's really being sent from one computer
to the other is just a sequence of bits organized into bytes.
So maybe I put her name first, followed
by a-- that's the ASCII null.
That slash 0 is the ASCII null, which
corresponds to the entire byte being just zeroed out,
followed by my name--
or I could send my name followed by the ASCII null,
followed by her name, or I could tack on a "from" and a "to."
And then the question comes, well,
is the "from" followed by colon?
Is it followed by a dash?
The basic idea here is there's lots of different ways
this message can get sent.
But what needs to occur is both my computer
and her computer need to be in complete agreement
on exactly what this message looks like,
not just the contents of the message,
but the other information associated with the message,
like what format am I going to use to send who the sender is
and who the recipient is.
And so this is really what a protocol is.
A protocol is an agreement between two or more computers
on how they plan to carry out a task.
Let's take a look at a real-life protocol.
We're going to look at the HTTP protocol.
This is the protocol used by the World Wide Web.
And as you can see here, HTTP stands for Hypertext Transfer
Protocol.
We'll actually be talking about exactly what hypertext
is next lecture.
For now, here's my laptop.
It's connected to the internet.
And you remember these diagrams from last lecture,
representing some sort of a network.
And I'm connected to part of the network.
And then there's a whole bunch of other networks
between my network and where the web server is.
And that's the dot, dot, dot, the internet.
And as you'll recall from last lecture,
the internet is actually an inter-network,
a connection of a whole bunch of different networks
all combined together.
And then on the far side, we've got the web server.
Now, I'm representing the web server by just a box.
Please don't tell my art teachers.
I've completely given up on any sort of perspective drawing.
But here on this inset here, you can actually
see what a web server actually looks like.
And what we're seeing here is this
is a rack that has a whole bunch of different computers in it.
Each of the horizontal components inside this rack
actually represents a different computer.
And this is what most of the web computers that you're
interacting with look like, particularly
if you're interacting with a commercial installation.
But we're just going to represent it
by that square box.
So here's the simplified diagram.
I'm getting rid of all the internet stuff.
But do keep in mind that internet is still there.
So I got my computer.
And I need to contact the web server.
We saw previously that the web server's identified
by the hostname, and that need to get
converted to an IP address, also known as IP number.
And then I'm going to go ahead and send
the request through the internet to the web server.
Now, it turns out that there's actually
several types of requests I can make to a web server.
I can make a "get" request, which says, hey,
you have some information.
Can you go ahead and send it to me?
I can use a "put" request which says, hey,
I want you to do something for me that's
going to modify your state.
Here's some information you might need.
And this is used for things like, say,
electronic commerce, where I'm actually putting an order.
So I'm sending the order information to the server.
And the server is changing its status
so that it remembers my order.
There's a "delete," which, generally, you're
only going to be able to do if you have authorization.
Anyway, the point is here there's a whole bunch
of different requests.
There are several more that I am not covering here.
So this all needs to be part of the HTTP protocol.
When a laptop or some other computer
is connecting to the web server, what sort of request
can it make of that web server?
And in addition to the request type,
such as "get" or "post" or "delete,"
there's actually a bunch of other information
that gets attached to the request.
And so these are just a couple examples.
We talked about character encodings.
In fact, we talked about character encodings
the very first day of class, when
you learned how to store Egyptian hieroglyphs using
the Unicode UTF-8 character encoding.
So I can send information to the web server saying,
these are the sorts of character encodings I can handle.
You can send a request to the server saying, hey,
I have a copy of this file.
But if the file on the server has
been modified since a particular date,
then I want a new copy of it.
You can tell it that you accept particular types of encoding.
And in this case, I'm not talking about character coding.
I'm actually talking about the compression techniques.
So we've talked about compression with images.
We talked about compression with sounds.
Compression also occurs with files.
You guys have experimented with that
if you've ever used a ZIP file.
And so one thing that the server can do
is it can zip up the files together or use
some other compression technique to reduce
the amount of space those files take before sending them
to the World Wide Web.
And so that's what the Accept-Encoding is saying.
It's saying, hey, I can handle those ZIP files
if you want to go ahead and send them to me in that format.
And so you can see that there's lots of different options
that the sender or the requester can do
with this particular protocol.
And then as far as the response goes,
the main part of the response is the files
that I'm going to get back.
In this case, I'm representing it as an HTML file.
We'll talk about HTML again next week.
But in addition, there's other things
that the web server can send to the requester.
That includes, hey, this content is encoded.
Here's the encoding.
It includes, here's how long this file is good for.
Here's when it's going to expire.
And then typically, it will also include
an idea of how long the file is so that the recipient will
know when the file is done transferring.
Another important part of the protocol is the status code.
You may be familiar with some of these.
The 200 code you guys never see, but your computer
does receive it.
When your computer receives the 200 code,
it knows, oh, everything's good.
And then, of course, we have the infamous 404,
which means you're requesting a file,
but that file does not exist, the 403,
which, in similar respects, I think
is a little bit harsher, which says, yeah, that file's there,
but I'm not giving it to you, you don't have permission,
and then 500, which means there's a server error.
And in fact, there's a whole slew of these different status
codes.
And so this is just a simple introduction to HTTP.
But mostly, I wanted to give you a sense
of what a protocol looks like using a real-life protocol.
And so from this, we can see that, yes,
a protocol is an agreement between two or more computers
on how they're going to carry out a task on the network.
But we also see that-- sorts of information
that needs to be included.
So the protocol should specify what
sorts of requests one computer can
make of another request, what sort of information
would be sent with that, what the format of that information
is.
And then also important is what to do
when something goes wrong.
And that's why we have those different error
codes we saw there.
One topic students often find confusing is
what is the relationship between a protocol and a program.
So let's take a quick look at that.
We've seen how the HTTP protocol works.
There are many different programs
that support the HTTP protocol.
So, for example, Chrome, Firefox, Safari, Edge--
these are all programs that run on our personal computers that
understand how to communicate with web servers using the HTTP
protocol.
And as long as our web browser programs understand and follow
the same rules, they can interoperate
with any of the web servers.
Similarly, there are many different types of web servers
out there.
And as long as the programs on those web servers
follow the rules for HTTP, they are
able to respond to requests from the different web browsers.
I should also mention that, while most of us
typically think of the program that is making requests
to the web server as our traditional web browser,
there are other programs out there that
make the exact same HTTP requests to the web server
as our traditional web browsers do.
So just to provide a few examples,
there are audio web browsers, which people
that are visually impaired use.
And they will actually be able to read the web
page to somebody.
And then there are other programs,
such as the Google search bot, which doesn't even
involve a human being.
It just makes requests to web pages
and uses those web pages to build up
its database, which it can use to tell us
how to find particular topics.
The bottom line is the protocol just specifies a set of rules
that different programs need to follow if they want to interact
with the other computers on the network that
are planning to work together to carry out this task.
Many people can write different programs
following those protocols.
And, in fact, as we've seen here with HTTP, they often do.
In the next series of videos, we're
going to take a look at the actual protocols
on the internet.
It turns out that the protocols on the internet
are what is referred to as layered.
This is a relatively complex topic.
But by understanding the layered protocols and how they work,
you will have a much, much stronger understanding
of how the internet works.
So we're going to go ahead and go over this.
The next video is going to talk about what
layered protocols actually are.
And then after that, we'll take a closer look
at the actual layers used on the internet.
I'll talk to you soon.