Okay, so the very first thing to talk about kind of what you do everyday without
thinking about it, which is using the web as, as the world's largest deployed and
working client server system. Alright, so, what do we mean by that. And, by the way
just on the side slash advertisement read the book. Okay. It does not replace
reading the material. We're just trying to give you additional perspective here.
Okay, so what does the Web look like? We're gonna use an analogy of altitude,
where we're gonna start at about 100,000 feet out and then zoom in progressively to
more and more detail. And at the very top level the Web is a client-server
architecture that's request-reply oriented. So what does that mean? It means
that a Web browser sends a request to a website through the magical cloud called
the Internet, which is present whenever you talk about networking. And the website
replies to that request, sends something useful back to you or possibly an error
message. Okay, so that's at the very top level, that's what this is. And in terms
of this picture that we're gonna see over and over again. This is a picture that's,
it's taken straight out of the book. So we're kind of at the this top level right
here. All we're gonna do is talk about what's going to happen at this level,
we've got a browser like Firefox or Chrome. And we've got a site like rotten
potatoes which is the instructional example we developed through the book. If
you've used rotten tomatoes this is a very simple version of it. So what's going on
at this kind of hundred thousand feet level? And when we say that it's a client
server architecture right, whenever I use the word architecture there should be a
Pavlovian bell going off in your head which is telling you. By choosing an
architecture you've rejected an alternative, right? By definition an
architecture is a way that you put things together that you logically organize them.
So, if I'm telling you that the web is a client server architecture you should
immediately assume the implication is, other architectures are possible and the
web is not those. So we'll talk about what the other ones are and how the web came
none of those. So, the most common other architecture in network distributed
systems is the peer-to-peer architecture. Roughly speaking, when we talk about the
high level architecture. And soon we're going to get to what's inside each of
these boxes. And a client-server architecture, you've got typically a
single logical server. It's serving a large number of clients. Probably doesn't
even know who they all are, or how many of them there are. And the idea is, generally
speaking, the client asks the question. The server provides the answer. That's
generally speaking the client-server architecture. So over time, the client and
the server software get to be quite specialized for their tasks. Right? The
client's job is. Interact with a human being typically and ask questions on
behalf of the user. The server is supposed to wait for people to ask questions and
then serve many clients at a time answering those questions. An alternative
if you use something like bit torrent is the peer to peer architecture where
roughly speaking any given participant can be either a client or a server. Now, I'm
not saying that one of these is inherently better or worse than the other. But it is
the case that in a peer-to-peer architecture, cuz you've gotta do both
jobs, you tend not to end up hyper specialized for either one. In addition,
especially now that you've heard about warehouse skill computing, you could see
why the warehouse skill computing model, visa vi you know, ya'll with browsers is a
much better fit for clients' server, right. We've got the economy of scale in
the big server box. That's these concentrated warehouses full of trailers
full of computers. And then you've got a lot of clients that are much simpler and
these are usually on peoples' PCs. So it, the client server model is a better fit
for the web and they sort of have evolved hand-in-hand in that regard. So client
server is the first of many design patterns that we'll see. A design pattern
can actually be applied at many different levels of extraction. But basically
they're ways to capture common structural solutions to recurring problems. Right, so
the idea is you've got a thing that has a bunch of information that can answer
questions. You've got a lot of people that want to ask questions. Regardless of the
implementation you can talk about that as a client server system. Yeah. Browsers,
versus BitTorrents. Okay, so what about the nuts and bolts. It's a client server
system, but how do things actually communicate with each other. I'm gonna
condense like of tc pi history into one slide. So again, I'm giving you the high
order bits that you need to know. To get through the rest of this course. If you're
taking a networking class. You've seen some of this before. The first kind of
buzz word you need to remember, IP address or internet protocol address. It's
basically four one-byte numbers separated by dots and they ideally uniquely identify
one machine on the internet. One address is special, actually, several addresses
are special. For our purposes, this one is super special. 127.0.0.1 always means the
computer that I'm typing this on, right. Local host, is a special name that's
applied to it. And even if your computer's not connected to the internet, you can
always, Assume the existence of the special address and the special name that
goes with it, right. Local host is always available and you can always behave as if
it were an actual computer and you can do internet operations against it.
Communication between these entities occurs over a pair of protocols called
TCP/IP. Ip is the simpler of the two and it is a no guarantee, best effort service,
that says, I'll deliver a packet from one internet IP address to another internet IP
address. Best effort means, it might not work and don't ask me if it works later,
right, just hand it to me and it's your job to do some other processing to figure
out, maybe ask the other side if they got it. That's TCP's job, the Transmission
Control Protocol. It's a layer of software that runs on top of IP and it detects that
packets may be getting dropped because things are arriving not in the order I
sent them, or there's gaps in the sequence of when things are arriving. Maybe the
network is slow so things are being dropped. And it takes various actions to
respond appropriately to that. And what if you have multiple different applications
on the same computer and they all want to use TCP? No problem, there's a, an entity
called a port number which is just an integer that identifies this is the
address that I'm listening on for this computer. It lets many apps on one
computer all use TCPIP. The you know continuing in our tradition of identifying
touring award winners who are influential in shaping software as a service. This
surfing bob com, the godparent or something of the internet. They share
between the word for fundamental work on internet architecture including the way
these protocols are designed and why their responsibilities are divided that the way
they are. And kind of, the brilliants of the design is that from the point of view
of somebody trying to use two TCPIP the illusion is you get a, you have a string
that you wanna send to somebody else like get flash bears. And you put it into a
pipe and magically the string comes out the other side of the pipe in the same
order that you put it in, and now the other side decides it wants to respond,
and it puts another string back into the pipe, and the string comes back to you.
Thank you. Thank you. It took half an hour to do that stupid animation. [laugh] Okay.
So Let's jump back up for a moment. I said that the Web is really just request reply.
I actually lied a little bit. There's an additional piece that I didn't mention,
which is the domain name system. In reality, you know you almost never use IP
addresses directly, you use host names like Google.com. So there's actually an
additional step that I didn't show, which is that the web browser will first try to
look up the host name from a DNS server and DNS is just another software as a
service, right? It's actually a very sophisticated distributed implementation
of one, but from the point of view of our software as a service client server world,
this is just a different kind of server than a web server. Through a series of
mechanisms we won't talk about in this class. The answer comes back and now armed
with the IP address we can actually use TCPIP to get the thing that we want to
get. Okay, so those are kind of the, the basic moving parts of how you get bytes
from point A to point B and how you discover what the IP address of point B
actually is. Okay, so now we know how to talk to an endpoint on the Internet. Now
that we know how to talk to it, what do we say? Well, we say something using the
Hypertext Transfer Protocol. Just like TCP relies on IP, HTTP relies on TCP. So it,
it assumes that it can reliably send strings back and forth. And the strings
are actually very simple. They're just ASCII strings that typically begin with a
verb like GET or POST. They're followed by a URI. Also called a URL. Don't worry
about it. It's a URI. They'll of, often include the HTTP protocol version that's
understood by the client, and then there's some extra information regarding the thing
that I'm asking about. So the client sends over this string and then the server, if
all goes well, will listen to that string. Hah, a client is contacting me using http.
It's asking a question. I will respond with a confirmation that I understand the
protocol version, a status code saying whether I can successfully reply or not,
and assuming I can successfully reply, some headers and the body, the actual
thing that the client asked for. So, let's do a really simple example of this. And
we're gonna get the Let's make sure you. Is that legible? Bigger? That's pretty
good, right? Okay, I'm going to use the famous program NetCap to listen on TCP
Port 8000. Remember I said port numbers let different apps on the same computer
all use TCP. I'm going to hop over here to Firefox and I'm going to type in, okay, so
remember, local host is this very machine, right. The same machine on which that
terminal window's open. I'm going to specify port 8000 and I'm going to get la
de da. Okay, nothing's happening. Something's happening. Okay, so what's
happening over here? This is what me pretending to be a web server just
received from Firefox. There is a get. Here's the thing that I asked for,
ladidah, here is the protocol version number in HTTP, a bunch of headers that
you shouldn't worry too much about, and a cookie that we'll talk about shortly. Now
let's just cheat and reply, hello world. The standard reply to all computer science
questions the first time you see them. And then we will close the connection, ta da.
I don't know if you can read that but it says Hello World. Okay, hardly magic but
that HTTP is really that simple. I just pretended to be a web server and I just
typed a simple string, back to the client. We can do something a little bit more
realistic, what if we do this to a real web server? Where is my, there we go.
Okay, let's go to a real web server. Here's an ancient utility that, that
predates all of you [laugh] and possibly your parents, I don't know. But, we're
going to go to the Berkeley web site. Port 80, right? Remember? Port numbers. Port 80
is the official and blessed port for http, because the internet assigned numbers
authorities says it is. And we will manually request, this is what your
browser would generate if you actually type the URL. And I am going to say I'm a
really ancient HTTP client. Okay, bunch of garbage which you don't have to worry
about. We're gonna to learn more HTML in a minute. But again what's the message? Http
is a brain dead simple protocol. I open a TCP connection, I send a one line command
and I get a bunch of stuff back. And if we scroll up just a little bit. More than a
little bit. This much, here's what I got back from the server, right? But here's
this first line, protocol version 1.1, we're good with that. 200 is one of the
family of codes that means all is well, okay. Everything after the 200 is for
human readable eyes only. A bunch of headers that, again don't worry too much
about, they tell us more information about the thing that is about to be returned, a
blank line and then stuff and the stuff is what I asked for, this is pretty much all
there is to HTTP. Cookies. So, HTTP is a stateless protocol. This is, you may have
heard this before, but this actually turns out to be profound for a number of
reasons, which we're gonna see in, just a few minutes from now. Stateless just means
that every HTTP request, from a given browser to a given server, is independent
of every other request. It's like all the other one's never happened, there is no
connection whatsoever between them and you can imagine, as websites started to become
popular in the mid 90's this problem arose. You know, I want to create a site
that has a multiple site procedure like add something to your cart, check out
right? So that means that somehow it's got to remember where you are on the site and
if every HTTP request is independent of all the others, how are we going to
remember that? Originally people thought, well, let's see, we could use the ip
address. We know which ip address it's coming from. We could use that. But it
turns out that if a computer in a public space, that doesn't work so well. And,
also, if you're doing, like, home networking, if you've got a router in your
home they, they do a bunch of technical tricks so that all the machines in your
house actually appear to be sharing a single ip address. So, this trick wouldn't
work too well. What about what puts them extra stuff into every URI that will sort
of be some junk that identifies each user. And we'll actually see more of this when
we talk about our introduction to rail but very quickly as the web became popular it
became clear that a waiter served a lot of people would be the cash or keep copies of
frequently requested pages at various ISP's so that not every single request
would have to go all the way to the website. The problem is that, the way that
you remember which page you're caching is by the URI that references that page. So
if you put a bunch of extra junk into the URI to identify the user, that breaks
caching, right. Now you've got a bunch of users all requesting the same page, but it
looks like they're requesting different pages because of mismatches in the URI. So
after a short time cookies were, turned out to be the answer. And there's a, a
very good screen cast that you can watch that we carefully made showing how they
work. But just briefly referring back to when we contacted the Berkley website.
Sorry. I mean, when we contacted. Here we go. Okay, so this is an example of a
previously served cookie that FireFox is sending back through for the website. The
idea is that the website has the option of returning a cookie when it gives you an
answer to the first question and your browser is supposed to remember that
cookie and make sure that it sends it back every time it talks to that same server.
So, the cookie gives you a way at the server side to say, aha! I know this is
the same user because I, I'm gonna send each new request a unique cookie, and if
the request doesn't arrive with the cookie attached to it, this must be a new one.
Which is why a lot of websites don't actually work if you don't have cookies
turned on. So as soon as the mechanism was invented, people started using it for all
kinds of things, right. For customization, you can set up your Yahoo or Google
homepage to look different, flow tracking or click tracking, right, how long do you
spend on a page before you click on something. Whether you're logged in or
not, right. You do a procedure to log in and once you are logged in, a cookie is
issued that indicates in some way that you're authenticated. As long as you keep
supplying that cookie, you don't have to log in for every new page view. So I'll
leave a sort of question for the reader, which of these could be implemented as
client technology, but a hint in terms of thinking about this is. In software as a
server, you can never trust the client. But the client could be a bot. Client
could be a user who's using a really out-of-date browser. The client could be a
script that's running awry. You have to assume that all clients are untrustworthy
and evil. So. Serve a cookie, get the cookie back, but the cookie has to be
constructed in a way that you could verify that it's actually legitimate, hasn't been
tampered with. And when we talk about the rails framework we'll see how rails does
that for you.