All language subtitles for 002 An Overview of How the Web Works_Downloadly.ir_en

So our goal is to develop

back-end applications with Node

and therefore it's probably a good idea

to get a basic understanding of how the web actually works

behind the scenes, right?

And this is gonna be a really full pack lecture.

And so let's dive right in.

Now, in order to get a better understanding

of how the web actually works,

let's start by asking the question:

What does actually happen each time

that we type a URL into our browser

in order to open up a new webpage?

Or each time that we request data from some API?

Which is actually quite the same

and so let's just focus on a simple website example here.

Well, the most simple answer is that our browser

which is also called a client sends a request

to the server where the webpage is hosted.

And the server will then send back a response,

which is gonna contain the webpage that we just requested.

And this process is called the request-response model

or also the client-server architecture.

And everything that we're gonna talk about

in this section revolves around this fundamental concept.

Okay, but let's now take this one step further

because this is probably not really new for you

at this point, right?

So let's say that we wanna access Google Maps

by writing google.com/maps into our browser as the URL.

And every URL gets an HTTP or HTTPS,

which is for the protocol that will be used

on the connection.

And we're gonna talk about this a bit later in this video.

Then we have the domain name here,

which is google.com in this case,

and also after a slash, the so-called resource

that we're going to access,

and in this case, /maps.

Now what you need to know here is that the domain name

like google.com is not actually the real address

of the server that we are trying to access

but just a nice name that is easy for us to memorize.

So we need a way of kind of converting the domain name

to the real address of the server

and that happens through a DNS.

So DNS stands for Domain Name Server,

which are special servers that are basically

like the phone-books of the internet.

So the first step that happens when we open up a website

is the the browser makes a request to a DNS

and this special server will then simply match

the web address that we typed into the browser

to the server's real IP address.

All right.

And actually this happens

through your internet service provider or ISP

but the complete details don't really matter for us.

What you need to retain from this part

is that the domain is not the real address

and that a DNS will convert it to that real IP address,

which a browser can then call after it being sent back

to our browser.

So this is how the real address looks like,

so it still has the protocol, but then comes the IP address.

And also the port that we accessed on the server.

And the port number is really just to identify

a specific service running on a server

and so you can think of it like a sub-address.

Remember how we listened to port 8000

on our web server when we set it up in the intersection

that is exactly what this port is.

Also please note that the port number

has nothing to do with the Google Maps resource

that we want to access.

That resource will actually be sent over

in the HTTP request as we will see in a moment.

Okay, and this wraps up the first step.

So once we have the real web address,

a TCP socket connection is established

between the browser and the server,

which are now finally connected.

And this connection is typically kept alive

for the entire time it takes to transfer

all the files of the website.

Now, what are our TCP and IP?

Well, TCP is the Transmission Control Protocol

and IP is the Internet Protocol,

and together they are communication protocols

that define exactly how data travels across the web.

So they're basically

the internet's fundamental control system,

because, again, they are the ones who set the rules

about how data moves on the internet.

And don't worry, we'll learn a bit more about TCP/IP

a bit later in this video.

Anyway, now it's time to finally make our request.

And the request that we make is an HTTP request

where HTTP stands for HyperText Transfer Protocol.

So after TCP/IP, HTTP is yet another communication protocol.

And by the way, a communication protocol

is simply a system of rules

that allows two or more parties to communicate.

And in the case of HTTP, it's just a protocol

that allows clients and web servers to communicate

by sending requests and response messages

from client to server and back.

Now, a request message will look something like this.

So the beginning of the message is the most important part

called the start line, which contains the HTTP method

that's used in the request,

then the request target and the HTTP version.

So about HTTP methods, there are many available

but the most important ones are get

for simply requesting data, post for sending data

and put and patch to basically modify data.

So you see an HTTP request to the server

is not only for getting data but we can also send data.

All right?

Now please don't worry if all these sounds a bit too much

for you at this point.

We will, of course, use these stuff

throughout the rest of the course,

which is actually the whole reason why I'm telling you this.

Anyway, about the request target,

this is where the server is thought that we want to access

the maps resource in this example.

Remember that?

So we had /maps in our URL and now it's sent

as the target in the HTTP request

so that the server can then figure out what to do with it.

And if this is empty, so if it was just a slash, basically,

then we would be accessing the website's root

which would be just google.com in this example.

Then the next part of the request are the request headers

which is just some information that we send

about the request itself,

and there are tons of different headers available

like what browser is used to make the request,

at what time, the user's language and many, many others.

Finally, in the case we're sending data to the server,

there will also be a request body

containing that data, for example, coming from an HTML form.

So that is the HTTP request.

Now, of course, it's not us developers

who manually write these requests

but it's still extremely important that you understand

what an HTTP request and also a response look like

because you will be working with them a ton, okay?

Also, I want to mention that there's also HTTPS

as you probably know.

And the main difference between HTTP and HTTPS

is that HTTPS is encrypted using TLS or SSL,

which are yet some more protocols

but I'm not gonna bore you with these.

But besides these additional encryption,

the logic between HTTP requests and responses

still applies to HTTPS.

All right, so our request now hits the server,

which will be working on it until it has our website

ready to send back.

And it will send it back using, as you can guess,

an HTTP response.

And the HTTP response message actually looks

quite similar to the request.

So also with a start line, headers and a body.

The start line has, besides the HTTP version,

a status code and a message.

So, basically, to let the client know

whether the request has been successful or not.

This 200, for example, means okay,

and the one that everyone knows is status code 404

which means not found.

And so this is where this 404 code

that you already knew comes from.

Then the response headers or information

about the response itself.

So just like before, and there are a ton available

and we can also actually make up our own headers.

Now, what's different about response headers

is that it's actually the back-end developer like you

who specifies them and sends them back in the response.

All right.

Finally, the last part of the response

is, again, the body, which is actually present

in most responses.

And it's also the developer who specifically sends back

the body in the response.

And we actually already did this back in the intersection

using response.end, remember?

And the body should usually contain the HTML of the website

we requested or, for example, JSON data coming back

from an API or something like that.

So we talked in great detail

about the most important parts here,

which are the HTTP request and the response.

But in our imaginary example, we only just did one request

to google.com and got one response.

However, if it's a website that we're trying to access,

there will be many, many more requests and responses.

And that is because when we do the first request,

all we get back is just the initial HTML file,

that file will then gets scanned for all the assets

that it needs to build the entire website

like JavaScripts, CSS files, image files or other assets.

And for each of these different files,

the browser will then make a new HTTP request to the server.

So, basically, this entire back and forth

between client and server that it just explained

happens for every single file

that is included in the website.

There can, however, be multiple requests and responses

happening at the same time.

But the amount is actually limited

because, otherwise, the connection would start to slow down.

Okay, and then finally, when all the files have arrived,

the website is rendered in the browser

according to the HTML, CSS and JavaScript specifications

that you might already know.

And now, as the final piece of this puzzle,

let's again talk about TCP/IP

and figure out how does request and response data

is actually sent across the web.

So we said before that TCP and IP

are the communication protocols that define

how data travels across the web.

Now, I'm not gonna go into a lot of detail here

but here is what you need to know.

First, the job of TCP is to break out the requests

and responses into thousands of small chunks called packets

before they are set.

Then once they get to their destination,

it will reassemble all the packets

into the original request or response

so that the message arrives at the destination

as quick as possible, which would not be possible

if we sent the website as one big chunk.

So that would be like trying to go

through dance traffic with like the biggest bus

that you can imagine.

So, not a good idea.

Now, at the second part, the job of the IP protocol

is to actually send and route all of these packets

through the internet.

So it ensures that all of them arrive at the destination

that they should go using IP addresses on each packet.

And again, this is just a very broad overview

of what really happens behind the scenes of the web,

because that is actually way too much information

than you actually need in order to become

a great back-end developer.

But I hope that you still found this information useful

and interesting, and also not all too confusing.

Now, in the next video, we will then actually do

some HTTP requests so that you become a bit more familiar

with the protocol.