Web Server Concepts and Examples

Summary

In this comprehensive guide by WebConcepts, we unravel the mysteries of web servers, diving into what they are, how they function, and their roles in serving web content. We explore the notion that any device with a network connection, from a laptop to a smartphone, can serve as a web server. The video takes us through the fundamental tasks of a web server, the protocols they use, and the differences between static and dynamic routing. Through engaging analogies, we compare servers to call center operators and delve into the intricacies of HTTP requests and responses, ultimately demystifying the tech that powers our internet experiences.

Highlights

• A web server is essentially software that serves web content, not specific hardware! 🎉
• Listening, receiving requests, and returning responses are key tasks of a web server. 👂📩
• Different ports (like 8000 and 8001) allow for multiple servers on one device, just like extensions in a call center. 📞
• HTTP is a simple text-based protocol, dissolving common misconceptions about its complexity. 📝
• Dynamic routing allows web servers to serve customized content based on user requests. 🍽
• Through engaging analogies, the video brings to life complex concepts like TCP and HTTP. 🤔

Key Takeaways

• Any device with a network connection can be a web server, from a laptop to a smartphone! 📱💻
• Web servers are all about the software, not just the hardware. 🎉
• Jim the web server helps us understand how ports work in accessing services. 😀
• HTTP is simpler than you think—it's all about text communication! 📝
• Static and dynamic routing define how content is served—static for existing files, dynamic for changing content. 🚦
• Understanding HTTP and TCP is crucial as they are the languages and transport for web communication. 🌐

Overview

Imagine a world where any device you own—be it a laptop or even your smartphone—could serve as your gateway to web hosting. This video demystifies the concept of web servers, showing us that it's the software that does the magic, transforming mundane devices into web powerhouses. 🎩✨

Join Jim and Jane as they guide us through the world of web servers, analogizing them to customer service agents at a call center. We learn how ports work, how HTTP communication happens, and why understanding these elements is crucial for aspiring developers. 📞🌐

Lastly, dive into the world of routing—static vs. dynamic. Discover how static routing serves up files from a directory while dynamic routing fetches data from databases, crafting a unique response every time. This isn't just about browsing; it's about the dance of data across the web's stage. 💃🕺

Chapters

• 00:00 - 05:00: Introduction to Web Server Concepts The chapter introduces the concept of a web server, addressing common misconceptions and questions beginners might have. It highlights that any device with a network connection, such as laptops, Raspberry Pis, smartphones, or even gaming PCs, can function as a web server. The discussion demystifies the idea that specialized hardware is required for web servers.
• 05:00 - 10:00: Listening and Ports The chapter discusses how web servers operate, particularly in the context of Internet of Things (IoT) devices. It explains that when you connect to an IoT device over Wi-Fi, you're interacting with its web server, emphasizing that it's the software, not hardware, serving the web content. The chapter aims to break down and define the six functions a web server performs, starting with listening on a port.
• 10:00 - 15:00: Web Server Requests and HTTP Protocol This chapter provides an overview of how web servers process requests using transport protocols, specifically focusing on HTTP. It explains the concept of web servers listening for incoming requests and how they remain inactive until a request is received. The discussion aims to demystify the abstract list of actions a web server takes when handling requests.
• 15:00 - 20:00: HTTP Requests and Responses The chapter "HTTP Requests and Responses" uses a metaphor to explain how a web server operates. It compares a web server to a customer service representative named Jim who works at a call center. Jim, like a web server, waits for incoming calls but never initiates one. The metaphor extends to illustrate how a web server remains on standby, listening for incoming requests and responding to them without making outgoing contacts. This is similar to a local web server running on a machine, which can be accessed via the localhost IP address 127.0.0.1. Typing this address into a browser will display a message, demonstrating the server's readiness to respond to requests.
• 20:00 - 25:00: Static vs Dynamic Routing This chapter begins with an example involving Jim, who is presumably an IT professional. Jim addresses a question about what a web server listens to, explaining that it listens to a network port provided by the system's operating environment, like Windows or macOS. The discussion explains that the network protocol offers a wide range of 65,535 ports for software communication on a computer. The analogy used to describe this is comparing the web server's operation to a call center, where someone like Jim might work, with each port symbolizing a different extension at which the server can 'answer calls' or requests.
• 25:00 - 30:00: Dynamic Website Example In this chapter, the process of understanding how extensions and dialing systems work in a call center is explained. By dialing 127.0001, you can reach the call center's main line, but to contact someone specific, like Jim, you should know and dial his extension, which is 8000 in this case. Jim's phone will only ring if you dial this exact extension, highlighting the importance of inputting the correct numbers for intended communication. This concept was compared to web browsing, where assigning specific ports is necessary for directing data correctly. When we dialed the IP address 127.0.0.1 without specifying a port, it was noted how a web browser handles such situations, pointing out parallels between network communication and phone networking systems.
• 30:00 - 40:00: Conclusion and Summary The final chapter discusses how web requests are sent to either port 80 or 443, depending on whether HTTP or HTTPS is used. During a demonstration, the web server operated on port 80 using HTTP, allowing automatic routing of requests. When the server is stopped and restarted on port 8000, an error occurs indicating that the site can't be reached. This happens because the server is no longer available on the default port.

Web Server Concepts and Examples Transcription

• 00:00 - 00:30 so what is a web server i distinctly remember when i was first getting started programming wondering what kind of computers are used to serve web applications what like operating system do they run and how is the hardware different than the gaming pcs that i've built over the years and as it turns out as is often the case with all of this stuff where you don't know it's this black box you're trying to unwrap i was asking the wrong question from a hardware standpoint anything with a network connection could be a web server your laptop a raspberry pi a smartphone if you've ever done that dance where you're trying to configure an internet of things
• 00:30 - 01:00 device and you have to connect to it over wi-fi that internet of things device is running a web server once you get connected to it that's what you're interacting with you see a web server it's not about hardware though certainly some hardware is better suited to run a large web application at scale instead a web server is really just a piece of software that serves web content but serving web content that's a tad generic so let's break it down further and define the six things that a web server does in roughly the order in which they happen so to serve web content a web server listens on a port
• 01:00 - 01:30 for a request sent via a transport protocol and returns a response containing the requested resource again with this list we're still really abstract so let's go ahead and take each one of these items one by one for a closer look so to start let's focus for a minute on what it means for a web server to listen basically once a web server application starts up it just sits there idle waiting for incoming requests if no requests come in then the web server doesn't actually do anything i think everybody kind of intuitively knows this but it's important to keep the concept in the
• 01:30 - 02:00 front of our minds to illustrate this imagine the web server is a guy named jim who works as a customer service representative a call center you can reach jim by dialing one two seven zero zero zero zero zero zero one and like jim the web server just sits there waiting for incoming requests jim never places an outgoing call he just waits and listens now i happen to have a web server running right now on my local machine of course it's running on the local host ip address of 127.0.0.1 and if we dial that ip address into the browser you can see this message
• 02:00 - 02:30 hey it's jim how can i help you so what exactly is the web server listening to the answer is a network port provided by the operating system that the web server is running on think like windows mac os more specifically the network protocol that we're using provides 65 535 ports that software running on the computer can communicate over now when a web server starts up it begins listening on one or if so configured many of those ports going back to the call center example for a minute let's assume that jim works at a call center with 65 535 different extensions it's like a
• 02:30 - 03:00 really big facility and you can reach the call center's main line by dialing 127.0001 but to reach the phone on jim's desk you have to dial his extension let's suppose that dialing extension 8000 will make the phone on jim's desk ring jim's only listening for calls coming in on extension 8000 and if you dial any other extension then you won't get a boy jim so let's go back to our demo for a minute earlier when we dialed the ip address 127.0.0.1 we didn't provide a port and that's because a web browser
• 03:00 - 03:30 automatically sends web requests to either port 80 or port 443 depending on whether we prefix the url with http or https in the demo i had the web server running on port 80 using an unencrypted http connection so there was no need to specify a port as the web browser automatically routed our http request to port 80 by default but let's stop the web server and start it again on port 8000 now if we reload the page you can see we get an error that this site can't be reached as the ip address refused to connect and that's because there's no longer a
• 03:30 - 04:00 web server listening on port 80 on our local host we can tell the browser that we want our request sent to port 8000 instead by appending the ip address with a colon and then adding the port number now you can see since we've specified the right port to communicate with our server we've once again reached gym now just like you could have multiple people working at a call center each listening for incoming calls on a different extension so too can you have multiple web servers running on one machine let's suppose jim has a colleague named jane who can be reached by dialing extension 8001. if you dial extension 8001 you'll
• 04:00 - 04:30 hear jane speaking but if you dial extension 8000 you get hey it's jim how can i help you let's illustrate this by starting a second web server over on port 8001 sure enough if you navigate to port 8001 you see the message from jane but if you switch back to port 8000 then you get the message from jim the point is that one single computer can have many web servers or other networking services running at the same time and just like we have to dial the correct extension to reach jim at his desk so too must we send our request to the
• 04:30 - 05:00 correct port in order to reach the desired web server speaking of sending a request let's take a closer look at what exactly sending a request to a web server means see web servers and web clients like your chrome firefox whatever communicate via the hypertext transfer protocol or http and you can think of this as the language that the web server and the web client use but what does http actually look like for me this was the most interesting part of researching this video because of the misconceptions i had about what http actually is now when they say hyper text transfer
• 05:00 - 05:30 protocol they literally mean text like http is just a web browser and a web server sending raw human readable text files back and forth and i'm sure i'll get comments pointing out that http version 2 and beyond converts the text to a binary before sending but the point still stands http is based on text and i don't know why i thought it was more complicated than that well i kind of do and we'll cover that when we look at the transport layer later on but we are talking about the application layer for now and http is really really simple let's open up
• 05:30 - 06:00 this text file here containing an example http request and have a look that's it that's a valid request in the http language so bringing the request down the data is separated into three blocks the first line is the start line which contains the request method which is git in this case the request target which is the specific web page or resource we're requesting here you can imagine we're looking up an order on an e-commerce website and finally the http version which in the case of this request is version 1.1 now the next block is made up of every
• 06:00 - 06:30 subsequent line up until the first line break we encounter these lines contain the headers of our request as defined as key value pairs here we just have two host which is the ip and port we're attempting to send the request to and the user agent which is the header that tells the web server what type of browser we're using this can be useful so the web server might know to serve you mobile content in case you're accessing on a mobile device finally the third block is made up of an optional body which begins after that first line break at the end of our header block and since the request we're looking at
• 06:30 - 07:00 is a get request we actually don't have a body but suppose if the web server accepted a form submission to look up order status instead in that case the post request using the post request method might include a body that looks like this here we've added a body with the name of the form input where we entered our order id and the value of that input one two three in this case note that we also changed our request target to be just orders since we're providing the order id in the body instead of the url we also added a couple of new headers one content type which tells the web server how the data in our body is
• 07:00 - 07:30 encoded and a content length header telling the web server the size of the body and that's it i've seen http requests represented this way before but like i always thought it was some kind of shorthand or human-friendly representation of what was going on under the hood i didn't realize i was looking at the http protocol itself basically sending the contents of that file to the ip address on our web server using a transport protocol is literally the same thing as typing the web server's ip address port and target resource into the browser and that's because http is what's considered to be an application layer protocol
• 07:30 - 08:00 it's like the language that the web servers and the clients speak if any other application protocol other than http is sent to our web server it won't know how to handle it let's go back to jim and jane for a minute to kind of clarify this idea imagine that jim who if you recall available at extension 8000 only speaks french meanwhile let's imagine jane who again is available at extension 8001 only speaks german if you as a german speaker dial extension 8000 jim won't have any idea what you're saying because he only speaks french he won't even be able to help you with your request he won't know that you're
• 08:00 - 08:30 even making a request let's illustrate this point by starting jim's web server again on port 8000 but instead of starting jane's web server on port 8001 we'll start an ftp server on port 8001 instead now ftp stands for file transfer protocol and as the name suggests ftp servers were typically used to transfer files in the dark ages before you had services like dropbox now if you start an ftp server it begins listening for requests sent in the file transfer protocol which is a different language than the hypertext transfer protocol that web servers and web browsers speak
• 08:30 - 09:00 now that our ftp server is up and running on port 8001 let's go ahead and navigate our browser to that port on our local host and we can see that we get this error message this page isn't working 127.0.0.1 sent an invalid response error invalid http response now basically what happened is the web browser sent an http request to the ftp server then the ftp server didn't understand the request and returned a response indicating as much in the ftp language which our browser that only speaks http didn't understand either and thus our browser is giving us this
• 09:00 - 09:30 invalid http response error so now we know that http is the language web browsers and web servers speak but how is the http request actually being sent to the web server and i've kind of intentionally glossed over this until now while we've looked at what a valid http request looks like but we have to send it to the web server somehow you see http and ftp are what's known as application layer protocols meaning they both run on top of an underlying communications or transport layer protocol let's go back to jim and jane for a second think about
• 09:30 - 10:00 how they speak different languages french and german in our latest hypothetical but both of their voices are carried over the telephone line german and french are the application protocol like http and ftp but the phone line that's carrying their voice that's the transport layer which in the web server world is the transmission control protocol or tcp now i'm not going to get too deep into the inner workings of tcp it's really beyond anything you need to know to get started with building web applications but just know that tcp at a very simple level breaks data up into packets then using
• 10:00 - 10:30 handshake and confirmations it ensures that every packet is successfully received by the recipient and the recipient knows the order of each packet for reassembly now that we know how a request is sent to the web server the next thing that happens is that the web server returns a response again just like our browser sent our request in the http language so too does the web server return an http based response now just like our request an http response is just text data again separated into the same three
• 10:30 - 11:00 blocks again we have the start line which for a response is sometimes referred to as the status line it contains our http version and an http status code here the response contains the status code 200 which is kind of the generic response for a successful http request pretty sure i could easily do a 20 minute video just on http status code so make sure that you subscribe if you're interested in seeing that video but back to the request below that first line just like in our http request we have multiple lines of headers defined again as key value pairs and just like the request again headers
• 11:00 - 11:30 are enumerated beginning on line two and are bounded by the first line break that we encounter one of the important headers in this example response is the content type which here is text slash html which lets our browser know to expect a text file text content and that the text content will be html hypertext markup language aka a web page in the body of the response and moving down to the body sure enough as promised by our content type header our body contains html content here the html just a simple header tag
• 11:30 - 12:00 containing the text hello world now if this were an api response the content type might instead say application json in which case the response body would contain some json data for our application to consume and taking it one step further if the resource we were requesting was an image the content type might be image slash jpeg and the body would contain the binary contents of an image file the main takeaway here is that the content returned by a web server is not limited to just web pages the body of an http response can contain all kinds of things like images and pdf
• 12:00 - 12:30 documents and javascript code or web fonts in fact the video you're watching right now was returned piecemeal in bodies of a bunch of http responses sent by youtube's web servers to the web browser or your youtube app all right now this kind of transitions us to the last piece of what a web server does now we've looked at the http response in the abstract but let's talk a bit about how a web server decides what to respond with and i mean that in the practical sense if i request an image resource and the web server returns it where's that web server getting the
• 12:30 - 13:00 image from how do we actually set this up in the real world determining which resource to return is often referred to as routing which is really just the practice of connecting a request with the requested resource the content that's being requested and for our purposes you know it's helpful to think about routing as being separated into two distinct categories there's static routing and then there's dynamic routing now static routing is just the web server serving actual files out of a folder just like you have a folder on your desktop that you can navigate to and
• 13:00 - 13:30 open various files you can open an image of a cat you could open a text file similarly you can point a web server to a directory on the file system and tell the web server to return anything that's requested in fact let's do that now we'll open this folder and as you can see i've got an image file called cat.jpg which as you might have guessed just a picture of a cat and two html files index.html and hello.html and if we take a look at those files they're very simple html files that just contain their respective file names in an h1 tag so let's go ahead and start up a web server listening on port 8000 inside of
• 13:30 - 14:00 this folder now if we navigate to 127.0.0.1.cat.jpg our web server returns the image of the cat and if we navigate to the root at 127.0.0.1 we get the default index.html file's contents and finally if we add a slash hello.html to the root then we get the hello.html contents and if we navigate to somewhere that doesn't exist in the target folder then we get a 404 status for file not found and that's because the file does not exist on the web server now static html
• 14:00 - 14:30 websites like this they can be really cheap and performant to host since they require very little resources a static website the web server is just taking a file that already exists returning the contents and the body of the response something that web servers are highly optimized for and to that end you can host static sites completely free using something like github pages or mostly free with an amazon s3 bucket and handle huge spikes in traffic hundreds of thousands of visitors in case one of your blog posts makes it to the front page of hacker news or reddit without any slowness or downtime for
• 14:30 - 15:00 only a few cents a month but what about situations where the content that exists at a particular resource changes dynamically think about a my profile type page that changes depending on who the logged eden user is or imagine an e-commerce web page where you can check your order status surely you wouldn't generate a static html page for every single order in your system and then have to switch out those pages whenever an order status changes from processing to shipped to delivered of course not instead you'd save that info to a database
• 15:00 - 15:30 and serve the contents of that database dynamically in practice this usually means configuring your web server to route all requests to a single file or executable which serves as an entry point for your web application and that web application could be created using programming languages like javascript php python ruby and it would evaluate the http request and then dynamically prepare a response depending on the requested resource opening up the http request we looked at before we see it's requesting the resource
• 15:30 - 16:00 for order id 123 and if you sent that to a web application it would search the database for order 123 and return the status now i happen to have a very simple example of a dynamic website that does exactly that okay so now we're in this dynamic folder and i'm going to start a web server on port 8000 and if we navigate over and we go to localhost 8000 orders and we'll check order id of one you can see that it comes back says order one's been delivered and gives us a tracking number let's go
• 16:00 - 16:30 and check the status of order two we can see that order two has been shipped and again it provides us with the tracking number one more time let's go ahead and check us order status of order three we can see that it's processing and we don't have a tracking number yet let's see if there's an order status for four we check order status for four and it's the same processing and there is no tracking number let's go and check and see if there's an order status for five here we get this page cannot be found an error of 404 was given so that means there is no order id number five in our system here let's go ahead and jump into the code and see how i set this up
• 16:30 - 17:00 now i wanted to keep this as simple as possible so you can see this whole dynamic website consists of just a php file it's not importing any libraries at all no composer files it's just raw php standard library and you can see that the entire dynamic web application is only 45 lines long and we also have a sql lite database and if we jump into the contents of that real quick you can see that it has one table and in that table there's columns of id status and tracking number so let's jump into this index.php and see how it's
• 17:00 - 17:30 dynamically routing our request in order to return our order status we first are getting our order id from the route here we're using this parts url helper in order to get the path out of that request uri and then we're passing it to this regex method which basically says look for or this regex pattern says look for orders followed by a slash and then any digit and then it takes that regex pattern and it does this purex match and if no matches are found then it returns this not found function or calls this not found
• 17:30 - 18:00 function there it sets the header to 404 and then just exits right there but if this path variable does match this regex so it's like order slash one or order slash two then it returns that match as the order id so you basically get this integer back you can see it's saying return an integer from this function and that gets stored into this order id variable that order id then gets passed to our get order status from database function and we can see how that works down here basically it takes that order id as a property it creates a new connection to our
• 18:00 - 18:30 sqlite database then it creates this sql statement that says select all from orders where id equals question mark then it binds the order id and then here it fetches the first result as a associative array stores it in this result variable so if the order id is not found this result variable is null and then again it returns this not found function or calls this not found function that sets the response status code to 404 and then exits but if a request is found it's being returned as an associative array so
• 18:30 - 19:00 that's going to contain the id the status and the tracking number if it's not null and it's going to return all that back up here and store it in the order details variable finally we call the print html function and we pass it that order details array that we got back from the database and if we scroll down to the print html function you can see it takes that order those order details that array of order details and it just says print and it defines basic hypertech markup language you've got the opening html tag the body tag and
• 19:00 - 19:30 then you've got an h1 tag where you're reaching in and getting the order id and the order status and then you're getting the tracking number and returning it right here so again going back if we go to orders like one it's reaching into the database getting the content for order number one and returning it to the user so that's a really high level overview of what a web server does as always with this channel i'm just trying to introduce you to these concepts so when you encounter them later you have enough familiarity to google your way to a better understanding
• 19:30 - 20:00 something that all software developers do if you enjoy this kind of content please consider subscribing thank you so much for watching and i'll see you guys next time