So the question is, what are we going to do between these two things, okay?
What, how we, what, how are we going to ask for data?
And this application is the client application.
And this application is the server application.
Client and server are not necessarily the same, very much the same.
Client and server are likely very different applications.
The client is like giving me information. And the server is responsible for giving
giving the information to the client. So the client is often making a request,
and then the server is making a response back.
And so, this client server mechanism, this application to application
communication, we could build a mail system with it.
World wide web. Or we can stream videos much like we'll
be streaming this lecture back and forth. But we're going to focus on the world
wide web because it's really simple, and really elegant, and it's probably the
easiest one to understand. And, it's the most popular.
But there are many other protocols going on, file transfer and others, but, the
world wide web protocol, HTTPD, is the protocol that is the most popular.
So, the, there are two basic questions that the application layer has to solve.
One is, which application gets the data. And this is done using a mechanism called
ports, and ports allow a IP address, or a single computer, or a single server, to
serve up multiple services, and then for a client to be able to dial up much like
a telephone extension, and pick the service that they are interested in.
Once you've connected to the service that you're interested in, like the world wide
web service, then you need to know the protocol to talk to that.
Ports and TCP are like a telephone extension number.
Again, that, like I said, they, you can connect to an IP address but then you can
connect to a port within it. And so if you think about a telephone
number, and an extension, it's sort of a, a further refinement.
An IP address gives us a particular server,a piece of hardware connected to
the internet, and then a port within that tells us what application we're going to
talk to. So, let's talk about ports and
connections. So, if I add a server, and this kind of
a, a arbitrary server. Here, here is a single server,
www.umich.edu. And it has one IP address connected into
the cloud. We can have many clients talking to it.
And, we have many services running on this server like sending email, or
logging in to that server, or retrieving webpages, or retrieving my mail from that
server. And there are ports, so, incoming email
is done generally in port 25, remote log in is 22 or 23, web servers depending on
whether it's secure or not are 80 or 443, and, [COUGH] the personal mail box is on
ports 109 or 110. And so these computers don't just connect
to an IP address, but they connect to a port within an IP address.
So some common TCP ports that we have are the ones I just mentioned.
And you can take a look at these on the internet.
The various ports. Okay?
Now, once we have a connection to the web server, or to the mail server, or to the
post office server, we have to know how to talk to it.
And that's what's called an application protocol.
And that is, the rules for conversation, the rules for conversing.
So, TCP gives us this reliable connection, we now can connect to the
server that we desire to connect to by using ports, and the question is, what
are we going to to say across that connection, and what we say across that
connection, who talks first, what do you send, what comes back, depends on the
kind of server that you are talking to. We're going to play mostly with the world
wide, the world wide web. Oops, I clicked the wrong button there,
the world wide web server, because it's the simplest, and it's the most obvious
as to what's going on. So the world wide web clients, and the
world wide, which are otherwise known as browsers, the world wide web clients, and
the world wide web servers communicate using a protocol called HTTP.
As a matter of fact, if you look at the top of your URL it's http://, something,
dot dot dot, right? And [COUGH], and so basically, there is a
specification for how this is done. So when they wrote down, I'm going to
write the first web browser and the first web server, they also wrote a document
about how that piece of software would talk to this other piece of software.
And the, and it's a very simple concept, http has a protocol where you make a
connection to the, from the client to the server.
The client requests a document. The server feeds out the document.
And then the connection is dropped. Okay?
So it's very simple. We'll actually simulate this.
This is called the HTTP request response cycle.
Okay? And so the way it works, is, you're in a
browser, and you click on a link, the browser's an application, it's the
client, running on your computer, so, so this is kind of your computer down here,
okay. You click on a link, then the browser
makers a connection to the web server and sends a request to, for the document.
The web server looks up, does whatever, and sends the document back, and then the
document is displayed on your screen. Okay.
So, let me show you sort of how this works with a web browser.
So here is a canonical webpage. So here's a browser, here's the URL that
I went and got, you can get this URL as well, you can even look at the source.
So if you look at this source there is [COUGH] my HTML.
But one of the things that's in this source is a link.
And if I hover over top of this link, whoops, I gotta go like that to hover
over the top of the link. You can see, at the bottom of my screen,
you can see it's going to tell you that we're about to go retrieve page2.htm.
Now, this browser is running on my laptop.
It is a web client. It is an HTTP client.
And I'm about to click on this piece of software running on my computer.
And then it is going to make a connection out the back of it, retrieve a document
and then show me the other document. So it's going to happen real fast.
I'll click on second page. It requested, and got a document back,
and showed me the document. So that's the contents of the second
document, okay. And so that is the request response cycle
that is triggered, that is triggered by me making a click somewhere in my
browser. The, the browser sees the click, it opens
a connection, this is sort of the internet over here, it makes a
connection, requests a document, the document comes back, and then the new
document is displayed. The request, response cycle.
Click, request, response, display. Click, request, response, display.
So let's take a look in some more detail as to what's really going on here.
So, the command that is being sent up to the server, across this connection, and
remember that this part here's the internet right there.
The command is a get command. And the document is based on the URL I
clicked on that the browser knows about, and says get /page2.html, and what comes
back is HTML. And that is a markup language that
describes how this doc, how this page is supposed to be shown.
So let's say that we wanted some more detail on how this really worked, right.
Let's say that we want to write a web browser and we want to be a good citizen
and we want to talk properly to the the web.
Well, we would go back to the IETF, the Internet Engineering Task Force, and we
would go grab the document that says hey, if you want to write a browser, this is
what you do. This is what you do if you want to write
a browser. You can go grab RFC 1945.
Which is the hypertext transport protocol version 1.0.
Now I'm sure there's more complex superseeded versions of it, but if we
read it, and read it, and read it, we spent a lot of time, we'd get down to
section 5.1.2, and it would say, if you are making a request for a document this
is the request line. It has the letters G E T, followed by a
space, followed by the URL you're looking for, followed by a space, followed by the
version, okay? So that is the rule.
That is what you're supposed to send down this connection.
It'll give us some more examples on page 24.
And so, we could read all this, and we could write a web browser.
But what we're going to do, is we're going to fake being a web browser, we're
going to cheat. We're going to hack it.
We're going to pretend to be a web browser.
We're going to send the commands, to the web browser.
Now, I'm going to do this on a Macintosh, you could also do it on Windows, if you
installed Telnet Client, okay. So the key is you install a Telnet
client. Now most people would say that Relnet is
insecure, and it is, it's a very old protocol, because all it does is it opens
a TCP connection to a host on a port that I specify, and whatever I type goes
across that TCP connection. So it's a great way to hack, especially
older, less secure protocols. So because HTTP is generally a public
protocol, it's not really highly protected, so it's much simpler to hack
it. Hacking secure protocols is, requires
writing software rather than typing commands.
So if you're on windows you have to install Telnet, T-E-L-N-E-T.
So what I'm going to show you in a second, is I'm going to show you hacking.
And I'm going to telnet to www.drchuck.com, port 80.
What I'm saying is, connect me to this server on the internet, and connect me to
port 80, because I want to do HTTP connections, and then I will send one
command. I'm going to send that command.
And then the web server will give me back the page.
Okay? It's probably easier for me to just do
it. So let's take a look.
I am going to simulate what the web browser does when it's requesting, well
actually, we'll go to the second page, and when it's requesting the first page
it's doing a get for page one. Okay.
So that's what we're going to do, except now we're going to do it in a terminal.
So I'm going to type telnet, whoops, I always type this wrong.
T-E-L-N-E-T, www.dr-chuck.com, port 80. Okay.
So now I am connected to the webserver on dr-chuck.com.
I could, for example, type yo, what is up, dude.
Now that would suggest I have not read the protocol specification for the HTTP
protocol, so I do not know that I'm supposed to type the word Get here.
I'm going to type yo, what is up Dude. And it goes, you are not from my country.
You are not from my planet. I do not know what you said.
Of course that, the way web servers are saying this, is they're saying bad
request. Your browser sent a request that this
server could not understand. It is, the request header is missing a
colon separator. You do not comply, go away.
But we did talk. It just told us that whatever we were
saying is gibberish to it. And that's okay, because we have read the
document, and so we can do it. So let's do it.
So now I'm going to do is telnet to dr-chuck.com on port 80.
Go to dr-chuck, hook onto port 80, so we can talk to the web server, and now I am
going to behave. I read the specification.
I'm going to type G-E-T, get, space, one space, http://www.dr-chuck.com/page1.htm,
HTTP, space 1, dot, I think there's a slash there, whoops, oh no, no, no, get
it right, get it right. Slash 1 dot 0.
I think I got that right. So that is what I'm supposed to type if I
am a real browser. Now I have to actually type another new
line, so I'll type another new line, and now whoa, oh, I gave it the wrong page.
Look, look, look, look, look. I wanted to do, I told it to get
page.htm. So let's do it again, do it again.
I'm not very good at this, my browser is much better at it.
So I type get http://www.dr-chuck.com/page1.htm, space,
HTTP/1.0. I believe that's it.
Let's hope I got it right this time. And then another enter, and then another
enter. Yay, I got it.
So this time, I'd type, you know, I'd type this, then I'd type this.
Now it gave me some header information, it's saying things like 200 okay means I
like you what the time is, when this file was last modified.
It's an HTML file and it actually shows me the HTML text.
And so we have just hacked, a web server. You can do this to like facebook.com, and
do a Get. If you get the right thing, it will give
you stuff. You can go to various sites, you can fake
browsers. Now, you're only going to get so far,
because at some point, these servers know that you're not a browser, because a
browser actually sends a little more stuff than what we just sent.
But, you get the picture. Okay.
It's a protocol where we have rules, and if we type the right thing, if we type
the right thing, we know what the specification tells us to type, we are
rewarded, with the information on that server.
If we comply with the server's request, we can talk to it.
If we know how to talk, if we know what port to talk to, and we know what
protocol to talk to that port we can write a client that meets the needs of
that server and extract the data. So this is, I like, I like command lines,
I like sort of old school user interfaces, and this is a scene from one
of the Matrix movies, that you may recall.
I can't put it in here because of copyright re, requirements.
I might have a URL, or maybe students will come up with a URL.
You can probably search for the Trinity hacking scene.
People put it up and then it gets taken down and someone else puts it up.
So let me tell you a little story about this scene.
This scene was actually written by a former student of mine, who worked on all
three Matrix movies doing IT work on the movies.
And they were in Australia shooting the, the, the three, the second set of three
movies, and he saw this scene. And the scene was supposed to use a
Minority Report style way for her to hack into the, the power grid, and shut it
down. And he said, that's not the way that you
hack into computers. [COUGH].
All good hackers use a text based interfa, interface, some old thing.
And that's a throwback interface. So the Wachowski brothers told him
rewrite it. So he actually downloaded the exact
hacking software, its called Nmap, which stands for network map.
It is mapping the ports. Its, probes the ports and sees whats on
the ports. See what version of software's on each of
the ports. Figures out what the, what the weaknesses
of those things are, and even automatically exploits the weaknesses.
So he wrote a script that downloaded this thing that automatically breaks into
computers. By the way, the good guys use this and
the bad guys use this same thing. The good guys use it to test all of the
computers on their campus and make sure that they are okay, and the bad guys use
to break into the ones that the good guys aren't smart enough to fix.
And so [COUGH], this was kind of cool, and, and the people who wrote nmap were
really quite amazed when they saw the movie.
They even figured out what version it was and things like that.
And so it actually triggered a series of follow on scenes that use actual real
hacking software nmap hacking software. So, I don't know if we've got a URL for
this or not, whatever URL I come up with even the one in the n, nmap people come
up with, whatever it is goes away because of copyright, but you can find it,
because someone always puts it back up. So, okay, so, maybe you can go and maybe
the nmap people will know it or maybe you just have to search for the Trinity
hacking scene. So you can use telnet and you can hack,
legitimately hack a web server. So, [COUGH] basically the application
layer is a rich place, and there's lots of things that happen in the application
layer. We have this pipe abstraction, it's
kind of like a, a string with two tin cans, and we can shout into one end and
stuff comes out the other end. later we'll talk about adding security to
that, and we use these port numbers to allow to, multiple different servers, or
services on a computer that we can connect to.
[COUGH] So we kind of now reached the top of the architecture of the internet.
We've talked about ethernet, the link layer, the fiber and all the diverse
wireless, all of the wonderful things that happen there.
The internet work layer, which is this kind of geographical hopping thing that's
unreliable. The TCP layer that retransmits
automatically if necessary. And then the application layer, which is
what we do with all this networks. [COUGH] It's really impressive that this
came out of research work from the 1970s. And that most of the architectures that
were really present, most of the ideas of the architecture from the 70s are really
still present with us today. [COUGH] As the NSF net came out, these
architectures evolved a little bit, the last few tweaks, and there have been
tweaks going on ever since, but the, really the last few critical tweaks
happened in the late 1980s. The [COUGH] the number of web hosts or
the number of hosts on the internet goes from six in 1969, to sort of a billion in
2011. And, and it's pretty impressive that
roughly the same architecture that was designed with six computers is still
mostly functioning in a, in mostly the same patterns, all these years later with
bill, billions of computers. And so, if you start looking at the
network now, it almost looks like a live creature with veins, and nerves, and it
sort of almost pulses, and you see things like, you can search on the internet for
how the internet reacted to Hurricane Sandy, when, like, New York City was just
like shut off for three days. The internet just kind of like, routed
around it. Yeah a lot of stuff went across the
Atlantic ocean from New York City and yeah, it found different paths, and you
know, yeah, New York was down, but the rest of it wasn't, in many ways pretty
amazing. And, we certainly see other situations
where governments try to shut the internet down by going into the server
rooms, and shutting off, you know, what they think is the only connections, but
then more connections pop up. And so it's, it's very much a almost a
living thing. It's billions of computers, and hundreds
of thousands of routers. And, and, it's, hundreds of millions of
simultaneous connections going on all the time.
Including the one we're doing right now, probably.
And, it's trillions of bytes a day to moving across, and it's, it's, it's not
perfect, but it kind of works. You can think of it as like, the largest,
engi-collective, engineering thing that we've done together as humanity, we built
this. It's all one thing, and yet it's so many
different pieces. And we just kind of keep, gluing them
together, and gluing more things on more things.
And it was, it really was created almost like life itself.
It's very organic. It's designed to heal itself, rather than
be perfect. Because things that try to be perfect are
fragile, and they break too easily. But things that are designed to heal, can
heal. And you're never perfectly correct.
You're never all the way up, and you're never all the way down.
And so that's what's interesting about the internet.
Oops, went the wrong way. And so, we kind of come to the end of
this, where we started out with like machines, and pulleys and gears, and
spraying oil at [UNKNOWN], and, typing a few characters on a keyboard, to this
thing, where we, sort of just take for granted that we can watch basketball
anywhere on the planet, just with a couple of swipes of the, of the key.
And in a sense, it's just that same human urge to communicate at a distance.
And so the last thing that I'll close with is another video from Van Jacobsom.
Now, this is about a technique he calls Content Centric Networking.
