How the Web Works (2): The client-server model, and the structure of the Web application

In the previous section of the article, we learned more about how the Web works at the basic level, including the client (your computer) interacting with the server (another computer that responds to a client requesting a webpage).

In this article--the second of four articles--we work together to understand how the client, server, and other parts of the basic Web application are configured to make the experience of browsing the Web a possibility.

Client-server model

The concept of client-server cross-network communication is known as a "client-server" model, which makes it possible to browse the site (such as you view the article) and interact with Web applications such as Gmail.

The client-server model is really just a way to describe how the client and the Web application server give-get relationships-just as you might use "boyfriends" and "girlfriends" to describe your personal relationship. This is the details of how the information is from one end to the other, making the process look complicated.

A basic Web application configuration

There are many ways to configure a Web application, that is to say, most of the way follows the same basic structure: the client, the server, and the database.

Client : The client interacts with the user, so the client code is primarily responsible for most of the functionality that the user actually sees. This includes:

Defines the structure of a Web page.

Sets the style of the Web page.

Respond to user actions (such as clicking a button, typing text, and so on)

structure : Your Web page content rendering and layout are defined by HTML (most Web applications today use HTML5, but others say otherwise.) ）

HTML represents a Hypertext markup language that allows you to use HTML tags to describe the basic physical structure of a document, and each HMTL tag in the document describes a specific element.

Web browsers use these HTML tags to decide how to render this document.

styles : Used to define what a Web page looks like, and web developers use CSS (cascading style sheets) to define styles. CSS is a language used to describe the style of elements in your HTML document, which allows you to change fonts, colors, layouts, simple animations, and other surface elements.

user interaction : Finally, JavaScript handles user interaction.

Some user interactions are interactions that can be handled without reaching the server, which in the term is "client-side JavaScript." Other interactions require you to send a request to the server for server processing.

For example, if a user posts a comment in a thread thread, you might want to store it in your database and organize all the scattered information in the same place. So, you send a request to the server that contains the new comment and user ID, and the server listens for those requests and processes them accordingly.

We'll delve deeper into HTTP request-response in the next section of this series of articles.

Server

The Web application server listens for requests from the client, and when you set up an HTTP server, you set a listening port number. The port number is always associated with the computer's IP address.

You can think of ports as a separate channel for each day of your computer that can perform different tasks: One port can be used to browse www.facebook.com while another port is used to get your mail. Computers can do both of these things because each application (Web browser and mail client) uses a different port number.

Once you have set up an HTTP server to listen for a specific port, the server waits for the client to pass the port's request and perform any requested action while sending the requested data through an HTTP response message.

Database

The database is the base of the Web schema--most people are afraid to explore it, but they are a solid foundation for judging. Databases are where information is stored, so you can easily access, manage, and update them.

For example, if you are building a social media site, you may use data to store information about your users, articles, and comments. When a visitor requests a page, the data from that page is the database from your site, allowing real-time user interaction, just as we do on Facebook or in apps like Gmail.

How to extend a simple Web application

The above configuration is sufficient for a simple application, but the application functions are expanded, and one server is not capable of processing thousands of requests from the guest at the same time.

To handle so many requests, all we can do is distribute the request traffic to a backend server farm.

Here it makes things interesting. You have multiple servers, each with its own IP address, how does the domain name server (DNS) know which application instance to send your traffic to?

The simple answer is that DNS does not know. Managing a separate instance of an application is done through a load balancer.

The load balancer plays the role of a traffic policeman, which sends the client requests to the server in a way that is as fast and efficient as possible.

Since you cannot broadcast the IP address of all your server instances, you create a virtual IP that exposes this IP address to all clients, this virtual IP points to your load balancer, so when DNS queries your website's IP, it will point to the IP of the load balancer, The load balancer then distributes the traffic to each back-end server in real time.

You might think how the load balancer knows which server to send traffic to, the answer is: algorithm.

A popular algorithm is polling, which evenly distributes all the servers that are requested to you (all available servers). If all your servers are processing speed and memory, you will usually choose this way.

Another algorithm is to determine the number of servers that the next request is sent to the fewest active connections based on the minimum number of connections.

Depending on your needs, you can choose from a number of algorithms to apply.

This process is similar to the following:

Service

We manage them by creating server pools and load balancers to solve our traffic problems, everything goes well, right?

...... But as your application grows, just increasing the server will still cause some problems. As your application adds more functionality and is added later, you will have to maintain the same server all the time. To solve this problem, we need a way to decouple the server functionality.

This is why services occur, one service is another server, except that it interacts with other servers only, not traditional Web servers that interact directly with the client.

Each service contains a separate feature, such as user authorization or the ability to provide search. Services allow you to split a single Web server into multiple services, each of which performs different functions.

The main benefit of splitting a single server into multiple services is to allow you to extend the service completely independently.

Another advantage of this is that it allows the company development team to develop part of the service instead of 10, 100, or even 1000 engineers to develop the same server application, which quickly becomes a nightmare for project management.

Note: Load balancing, back-end server clusters, and service concepts become increasingly challenging as your applications are deployed on a growing number of server clusters. Such things as session persistence are particularly tricky-for example, how to send multiple requests from the client to the same server during a session-and how to deploy your load balancing scheme. In this article we don't talk about these high-level topics for the time being.

Content distribution Network

All of the above works well to expand traffic, but your app is always in one place, and when your users visit your site in other parts of your country or in other countries, their pages may take a long time to load because they are too far apart from the client and server. After all, we're talking about "the World Wide Web", not "local".

The popular strategy is to use a Content distribution network (CDN), a large "proxy" server distributed system that is deployed in multiple datacenters. A proxy server is just an intermediary server that acts as a client and server.

Companies that have a large amount of decentralized traffic can choose paid CDN companies to distribute their content to end users. Akamai, for example, is a CDN company with tens of thousands of servers deployed strategically geographically around the world.

Let's compare how Web browsing is done with CDN and no CDN.

As we discussed in the first part of the traditional site, the URL of the domain name into the host server IP address.

However, if a company's website uses the domain name in the Akamai,url to convert the IP of the server under Akamai, then Akamai transmits the content of the site to the users browsing the site, so that the user does not even have to connect to the company's servers.

Akamai can acquire and save frequently used elements, such as HTML, CSS, software downloads, and media files, from the services of its customers.

The main goal of this is to make your site content closer to the user, and if the content requested by users is not available far away, it means a lower latency, which reduces the load time of the page.

In the next article, we'll explore HTTP and rest further.

Original link: http://www.cnblogs.com/Lau7/p/7883132.html

(go) How the Web Works (2): The client-server model, and the structure of the Web application