[MUSIC] In this video, I'll provide an overview of the typical middleware used in web applications, and I'll show you how all of the middleware pieces fit together. Middleware makes it a lot easier to build web applications, as it provides services that as a developer you generally don't want to program. For instance, you don't want to have to write the code that connects your web application to a web server that caches web pages, manages the http protocol or manages the web session itself. Middleware components are not application specific. They're generally intended to work with any application. So as a developer, you want to use them so that you can focus the bulk of your attention on the code that makes your web application unique. Here are some of the components that you'll find in the middleware of a web application. Typical web application components include the web server itself, application servers, middleware frameworks. Now, a middleware framework provides services that are used to connect a web application framework to an application server that can serve up your application to a web server. It will also find session management services and proxy services. Now a proxy server is a server that acts as an intermediary for requests from clients seeking resources that reside on other servers. A reverse proxy is a special type of proxy server that retrieves resources on behalf of a client from one or more servers. These resources are then returned to the client as if they originated form the proxy server itself. So the client doesn't really know about the servers that are hidden behind the reverse proxy. The reason I'm telling you this is that a web server acts as a reverse proxy for the various servers associated with a web application. And finally load balancing services are often provided as part of the middleware. Let's take a look at how middleware services are typically organized in a web application. The HTTP protocol operates over the middleware of a web application. Let's take a closer look. Recall the TCP/IP networking model that was described in the first module in this course, and let's start with a HTTP request, that is issued by user's browser. An HTTP request has three parts, that action that is being requested, the header, and a body. We'll talk more about these in next lesson, for now though let's just think of this request as data that needs to be delivered to a web application. In the transport layer of the model, the transport control protocol is used. It's the TCP protocol that establishes the connection between the browser and the web service. The request data is packaged up into TCP segments. The important thing to understand is that the source and destination ports are apart of the TCP segment header. Specifically, the port that the user's operating system assigned to typical browser request is the source port. And the destination port is on the web server side. By default, it's assumed that on the web server side, port 80 is being used. That is, web servers are typically set up to listen for HTTP requests on port 80. By the way, when you use local host 3000, you're specifying port 3000 on the web server that's running on your machine. Next, at the network layer of the model, the internet protocol is used. The TCP segments are bundled up into IP packets. The IP addresses of the source and destination machines are stored in the IP header field of each packet. The IP protocol is responsible for delivering packets from the source to the destination computer based on the IP addresses in the packet headers. What is interesting is that each packet might take a different route through the Internet. For this reason, the protocol is said to connectionless. The service associated with this protocol is unreliable. What this means is if the packets are received out of order, or if some never make it to the destination, the IP protocol is not responsible for fixing things. It's the TCP protocol that takes care of fixing these errors. Finally, at the network interphase layer, the IP packets are converted into ethernet frames that can be delivered to the web server. So this is how the data in an HTTP request makes its way from the browser to the web server. Before talking about how the web server manages this data, let's take a look back at our web application architectural model. And let's consider what could happen if you're at a coffee shop using a public wi-fi network. Because the protocols I just mentioned to you are publicly available, bad guys can easily listen in to all of the network traffic that moves back and forth between the browser and the Web Server. This means that the bad guy can eavesdrop on your communication and possibly learn thing things that you'd like to keep secret, such as bank account numbers, passwords etc. Furthermore, if the bad guy want to become an active participant, he can do even more malicious things. For example, he can intercept your request and act like he is the web server. So you think you're communicating with the web server associated with some company, when in fact it's the bad guy masquerading as the company's web server. This is known as a man in the middle attack. We'll talk more about this and other security issues associated with web applications in a later course in the specialization. What you need to know is that you can protect yourself and here's how. The HTTPS protocol, which stands for HTTP secure, takes the HTTP protocol and then encrypts it, using what is known as transport layer security. Previously this was done using secure socket layer encryption. And SSL is still in use in some cases so we just call this TLS/SSL encryption. When the HTTPS protocol is in use, the default port becomes 443. That is it's typical to set up a web server so that the TLS, SSL encrypted data can be handled on report 443. You can tell when your browser is using this protocol, as you'll see HTTPS rather than HTTP in the address line of you browser. In addition, a browser will typically show a lock icon of some sort to indicate that the communication is encrypted. Applications implementing common services often use specifically reserved, well known port number for receiving service request from clients. Who is it that decided that we should use port 80 on a web server for the HTTP protocol, and port 443 for the HTTPS protocol? Well, the Internet Engineering Task Force develops and promotes voluntary internet standards, and in particular the standards that comprise the internet protocol suite, the TCPIP suite, in other words. Now the IETF was initially supported by the US Federal Government ever since 1993, it's operated as a standards development organization under the auspices of the internet society, which is an International Membership based non-profit organization. The goal of the IETF is to create voluntary standards to maintain and improve the usability and interoperability of the internet. The IETF delegates authority for managing domain name IP addresses and port registries to the Internet Corporation for Assigned Names and Numbers, known as ICANN. ICANN manages the Internet Assigned Numbers Authority, under a contract with the United States Department of Congress and pursuant to an agreement with the Internet engineering task force, the IETF. Now the IANA is responsible for maintaining the official assignment of port numbers to specific uses. If you visit the IANA.org website you can find a service name and transport protocol port number registry. And here is where you'll find that the HTTP and the HTTPS protocols have been assigned ports 80 and 443 respectively on web servers. Let's take a look at how this encryption, if managed properly, can make it impossible for a bad guy to listen in on network traffic. First, a trusted third party, known as a certificate authority, creates certificates that contain encryption decryption keys. These are stored on the web server and browser manufactures load up your browser with certificates that correspond to many of the major websites. In addition, if your browser doesn't know about some site, there's a protocol that uses public key cryptography, in order to exchange encryption keys prior to initiating the HTTPS protocol. Have you ever seen a warning that says that a certificate is not trusted? This means that the certificate authority can't vouch for the website. So even though you're using HTTPS, if you proceed, you could be communicating with someone other than whom they say they are. Let's take a look at the middleware components from the web server to the web application. I've been showing these as green in the web application architecture. First, there's the web server itself which is responsible for receiving the HTTP request and sending back responses. The two most common production quality web servers are Apache and Nginx. Next, we have the application server that's responsible for interfacing between the web server and the application code. In order to improve throughput, we sometimes have multiple application servers or the application servers themselves are able to hold multiple, simultaneous requests. Out of the box, Rails uses WEBrick, and WEBrick acts as both the web server and the application server. However, WEBrick is not production quality. It's fine in development mode, but it can't handle a load associated with production environments. Thus, in production environments, it's common to substitute in a production quality application server, such as Unicorn, Thin, Puma or Passenger. Some of these application servers are able to manage a cluster of web applications, balancing the workload given to each. Finally I'm showing how the web application framework is connected to the application server. Middleware framework code is use to facilitate this connection. We'll take a look at how rails does this using the rack framework in a later lecture in this lesson. Finally, after the we application has completed it's work, it returns information to the application server which then passes it on to the we server. The web server then initiates what's known as an HTTP server response which consists of the status of the response, for instance, was it successful or not, a header, and a body. This message then goes through the same protocol in order to return data to the client's browser. So this is at a high level the activities in a web application that take place over the middleware.
