DAVID J. MALAN: All right, this is CS50 and this

is lecture 6 and as you may recall, today we

begin to transition away from this low-level world of C

and command line programming into to a domain that's probably

a little more familiar, that of the web, and yet

all the ideas that we've been exploring thus far like functions and loops

and conditions and so forth are still going to be relevant.

It's just we're going to start using slightly different syntax and the user

interface, or UI, is now going to be your browser instead

of a black and white terminal window with just a simple textual prompt,

but how did we get here?

Well, recall that we've looked recently at structs

and what was nice about structs in C was that we had the ability

to make our own custom data types and to kind of encapsulate together

related data, and that became pretty powerful

when it came time for forensics to actually manipulate bitmap files

or JPEGs, and even though this struct is way more complicated

than a student structure, at the end of the day

it's just individual data types that are all somehow interrelated,

and by putting them in a struct you can move them all around

and copy them and save them all together as you might have done as well,

but then most recently did we introduce a somewhat fancier structure,

which is still the same idea.

It's got like one or more things inside of it,

but now, more powerfully, one of those things

had this star or asterisk, which gave us, of course, a pointer or an address,

but what was so powerful about this simple idea and this seemingly

simple symbol is that now we can kind of stitch together in our computer's

memory any kind of structure we want.

It doesn't have to just be one entity.

It can somehow be linked to another and you

can keep linking these structures together as well, and this of course

was an improvement on perhaps our simplest of data structures early on,

an array or a list, but of course, as soon

as you have pointers can you begin to link things together

until we got something like this and perhaps now with the dictionary

implementation you yourself might be exploring a linked list, a hash table,

a [? try ?] or some variant in between.

And then lastly, there was this painting of a picture, whereby

this is your computer's memory put a little more descriptively,

and this is germane only insofar as your computer uses

different chunks of memory differently.

All of your function calls end up using the stack.

All of your users of malloc and its cousins

end up using the heap, and then of course there's this up here,

and what was the text segment, which we didn't really dwell on?

What was the text segment all about?

Text-- you're being volunteered.

Yes, what's the text segment?

AUDIENCE: Files information?

DAVID J. MALAN: Files information, yeah.

Specifically, the 0s and 1s that compose the actual program.

So when you compile your source code, like hello.c, into 0s and 1s,

those end up getting stored in this location in memory

while the program is running.

So long-term they're stored on disk or your hard drive or whatever's inside

of the computer or the server so that the files persist even when the power

goes off or you walk away from the keyboard,

but as soon as you double click a program on your Mac or PC or as soon

as you do ./hello or some command like that,

those same 0s and 1s get loaded into your computer's RAM,

the picture we keep showing, and that's where they live while they're in use

by your Mac or PC or the actual server,

but thus far we've been running all of these programs with something like

./hello or some similar command and running them just in the so-called

terminal window.

But you are probably most familiar, certainly

with more graphical apps on your phones these days

and any time you visit a web browser on your phone

or on your desktop or laptop, you're still interacting with a program.

It's just that program is not only running on your Mac or PC.

Your browser is, like Chrome or Edge or Firefox or Safari

or whatever it is you use.

That's running on your Mac or PC, but what

you're communicating with is a program elsewhere,

somewhere else on the internet and those programs are called web servers.

A web server is just a piece of software that some human or humans wrote

and their purpose in life is to serve web pages.

When you request the homepage of Facebook,

there is a server out there, a program someone wrote,

that essentially spits out the 0s and 1s that compose Facebook's homepage,

but nicely enough, those 0s and 1s are not written as 0s and 1s

by Facebook engineers.

They're actually written as something a little more English-like,

a little more familiar, and it's not even programming code, per se.

It's what's called markup language, and we'll soon see that and more today.

So we've gone from compiling your code and running it

like this to actually doing that in a web-based environment,

but of course, when you're running your own programs in CS50 IDE down here,

you're actually using another piece of software

that fills the screen, CS50IDE, a.k.a.

Cloud9, which is the program essentially running somewhere in the cloud.

And we'll start to make this distinction and through examples

will the distinction among these different types of software

begin to make sense, but where is something like CS50IDE running?

Where is Facebook running?

Where is Google.com running?

Well, back in 1998, Google.com was running on this.

This was Larry and Sergey, the founders of Google's, very first implementation,

apparently, of their first rack of servers.

So servers are generally stored literally in a rack like this.

It's usually like 19 inches wide by convention

and you just stack computer on top of computer on top of computer,

but things were very bare bones back in the day of Google

and so there weren't even plastic or metal

cases around a lot of their computers.

They were trying to minimize cooling, minimize cost, presumably, and cram

as much hardware into that footprint as they could,

and so you actually see a lot of the wires and hardware

kind of sticking out, and this is on display now out west.

Of course these days, fast forward just a decade or two, and this

is one of Facebook's data centers where it's the exact same idea,

but much fancier, much prettier, much better lit servers,

but who serve, at the end of the day, the exact same role.

There are bunches of servers around the world that are just

sitting there waiting for you on the internet

to make a request for a homepage, for an email,

for any other type of information so that it ends up

getting sent from server to client.

And in fact, if you've ever thought about those words server and clients,

which is probably the lesser used of the two,

but a server-client relationship is what you have when you go into a restaurant,

and you ask the waiter or waitress for something to eat.

He or she brings something back to you, thereby serving you,

the client, and the relationship on the web is pretty much the same thing.

We are the clients.

Our browsers are the clients and out there

are servers like these who are serving up content and information,

such as on Facebook.

So let's consider how all this data even gets to us.

So odds are, these days, if you want to visit Facebook.com on your laptop

or desktop or phone without using the app, you probably just

type in Facebook.com and hit Enter.

If you're a little older school or literally older,

you might just actually type out the entirety of www.Facebook.com.

Both work and there are technical reasons for that related to the topic

we'll talk about today, but both of these work just

because Facebook has configured their website

to work in either of those addresses.

Now, as an aside, why are so many websites therefore prefixed with "www"

if both of them actually work?

Like, why have both?

It seems just like redundant to type "www."

if it's implied by Facebook.com.

Yeah, what do you think?

AUDIENCE: Is the "www" required?

DAVID J. MALAN: Is it required?

Nope, not required.

Not required.

Yeah?

AUDIENCE: Is it to identify that it's part of the World Wide Web?

DAVID J. MALAN: Kind of, yeah.

It's to identify that it's part of the World Wide Web

and no one really says World Wide Web these days.

We of course just say web, but back in the day and back in my day, frankly,

it wasn't obvious to a lot of human beings

what Facebook.com might actually even mean, irrespective of the fact

that it didn't exist at some point.

And so there was this sort of signal to the world

whereby you just started prefixing domain names with "www" just

to make super clear to users, oh, this is a website!

This is one of those things on the internet or the like,

and also back in the day, there were also

different services that have fallen into disuse these days,

like FTP was quite popular and Gopher, we used it

when I was here and other such things.

And so "www" was just an arbitrary prefix that just kind of said what it

is, but these days we humans pretty much know what a .com is and .net and .edu,

but even that kind of road is changing again because there's dozens,

hundreds of top-level domains.

It's not just .com and .edu and others now.

I mean, there's hundreds of these things out there

and so it might even be non obvious to this day.

So some people, therefore, go really all the way in and type out http://

and then the address that they want to visit,

but odds are most of us don't do this because our browsers just help us out

and prefix that, but that's where our focus will be today.

Like, this actually has significance because it specifies

what protocol or language, what convention your computer,

your laptop should use when talking to that server's address,

and actually, if you want the communications to be secure,

odds are your typing or your browser is doing it for you.

Adding an s there, denoting secure or encrypted a la Caesar and Vigenere

from some weeks ago and technically your browser

is also probably adding a trailing slash even

if it's not shown to you, which denotes you want the root of the server,

like the default homepage or something else.

In fact, maybe you do want something else.

You don't want just Facebook's website, you want Mark's page,

and so you could specifically /zuck or whatever the username actually is.

So this is a very long way of saying all this kind of stuff

that we type or autocomplete and take for granted these days actually

has some very fundamental meanings, all of which

make possible the entirety of the web.

So what actually goes on with HTTP and what does that actually mean?

So HTTP is a protocol.

It is a set of conventions that dictate how a computer

client, like a browser on your Mac or PC, talks to a web server,

and it's a protocol in the sense that it's not a language, per se.

It's really just a set of conventions and so

like this is kind of an arbitrary and awkward human convention.

Hello, I'm David.

AUDIENCE: I'm Kara.

DAVID J. MALAN: Kara, so Kara and I just introduced ourselves.

I extended my hand and she kind of knew instinctively

that it would be awkward not to shake my hands or to shake my hand

and so we exchanged pleasantries and said hello.

So this is just kind of a silly human convention

whereby we've agreed sort of socially in advance

how to greet each other in that way.

So HTTP is pretty much the same thing, but in this case

you're not actually physically doing something like that.

You're kind of sending a message from client to server.

You're putting a sort of handwritten note into an envelope this,

addressing it somehow and then sending it off on the internet for Kara