This article, based on my own experience, organizes the content that a WEB server might contain to implement, each point is touched, do not do too much expansion. The following sequence has no distinction of importance. Consider whether it is necessary according to the actual scenario.

routing

The routing of the WEB server, in essence, determines what logic to perform based on the information carried by the HTTP request.

The simplest if-else statement is also a route:

// The routing basis usually uses request method and URL
if (method === 'GET' && url === '/robots.txt') {
    // do something
}
else {
    // do other things
}
Copy the code

The way routes are defined varies from platform to framework, but the essence is the same: different execution logic is determined by the information carried by HTTP requests. Node.js Express for example:

const express = require('express');
const app = express();

// GET:/home will match funcA
app.get('/home', funcA);

// POST:/home will match funcB
app.post('/home', funcB);

// GET:/params/a or GET:/params/b will be match funcC
app.get('/params/:id', funcC); 

// GET:/regexp/list-1.html or GET:/regexp/list-2.html will be match funcD
app.get('/regexp/list-[0-9].html', funcD); 
Copy the code

The above code is a simple route definition method for Node.js + Express. However, it is not recommended to add routes line by line in real scenarios.

The log

Logs record information related to requests and are often used for data statistics and fault locating. Logs are classified into the following types:

  • Access log

Access log is the foundation of the most common log, recording every request part of the request and response information, please welcome the requestor IP usually information recorded, the request, the request URL, and the size of the request body, ask the Host, the request processing time, the response status code, and the size of the response body, and so on, these log location information is available for access statistics, issue, etc

  • Business log

Service logs are generated based on service requirements and can be used for service statistics, tracing, and fault locating

  • The error log

Errors and exceptions occurred during request processing should be output to the error log as long as they can be caught, and contain as much context information as possible to facilitate the developer to locate bugs

Keep the session

HTTP is a stateless protocol, but in some business scenarios, session information needs to be kept, that is, requests need to be traced and uniquely identified as requester.

Modern WEB servers can implement session persistence, which is easy to implement by ensuring that each request contains all the information context needed for the processing. Implementation principle:

  • On the initial request, the server assigns a unique ID(SessionId) and the corresponding Session information (Session) to the request, and then includes the ID in the response
  • When the client receives the response, it stores the obtained ID(Cookie) and carries it with each subsequent request
  • In subsequent requests, the server obtains the ID carried in the request and the corresponding session information based on the ID, that is, the session tracing is complete

The carrier of this ID is usually an HTTP header, which in browsers is set-cookie, used in response, and Cookie, used in request. Meanwhile, browsers have many other features for set-cookies, such as expiration time, scope (domain name, path), protocol (HTTP, HTTPS), and so on

A common interview question is the difference between a Cookie and a Session. Here’s what I understand:

  • Cookie is a way for a website to store data in the browser. The server stores information in the browser through the set-cookie header, and the browser carries the stored information to the server through the Cookie request header. The stored information is called Cookie
  • Session can refer to the Session corresponding to a request, which is an abstract concept, or it can refer to the information context of the Session itself, which is stored on the server side

Session usually corresponds to SessionId one by one. The transmission of SessionId depends on set-cookie /Cookie header. The data corresponding to SessionId can be stored in memory or database, the former is not recommended because it is difficult to share across processes.

The cache

Different parts or levels of the system often have significant differences in the resource cost and speed of data acquisition. In order to pursue higher performance and faster speed, the concept of cache is created. In many application scenarios, the use of cache can significantly improve the overall performance of the system.

HTTP – related caches often appear in the following places:

  • The client

The client, usually the browser, caches resources according to a series of HTTP cache rules. When a resource hits the cache, the resource is obtained at the fastest speed. For details about the cache policy, refer to the HTTP cache policy

  • Intermediate proxy

If the client does not hit the cache, the request is sent to the server, but it may go through different HTTP proxies, some of which implement caching, and some of which are dedicated to caching. If the cache is not expired, the cache proxy does not request server resources. Instead, it responds to clients with locally matched cache to improve resource acquisition speed and reduce network load

  • The reverse proxy

Reverse proxy, a common term in modern WEB server architectures, is the proxy real server to communicate with clients. A reverse proxy server usually provides the caching function to reduce the load on the real server and provide higher performance and faster resource access

Version control

Versioning, in this case, refers to the versioning of the API, once it is in production, and during subsequent iterations of the release, the same interface changes input or output if it is to be modified. Clients that depend on the server cannot keep up with updates synchronously. When deploying a new interface, you need to keep the old interface available in either of the following ways:

  • The same interface supports both the old and new scenarios

If the nature, input, and output of the interface are not changed, but the internal implementation is updated, this method is recommended. However, if the function codes of the new interface are added to the original interface due to input and output changes, the code will be difficult to read and maintain. Therefore, it is not recommended

  • Redefine an interface to support the new scenario

An interface is redefined to support new scenarios without changing the original interface. This method is called interface version control. New interfaces are defined and implemented based on constraints and specifications.

Versioning of interfaces is not necessary, but it does not mean that it is not important. It is best to take into account the initial design of the system. How to achieve versioning, i.e. how to determine constraints and specifications, varies from person to person, and there is no necessarily correct standard.

Access control

If certain sensitive resources can be accessed only by specific visitors, you need to perform access control. For example, the internal system does not allow external calls, user resources can be accessed only after login, management systems can be accessed only after administrator login, and certain known malicious IP addresses can be blocked

For the above scenarios, the possible methods are as follows:

  • Black and white list

Allowing or blocking access to specific users can be rigid, but in some cases very efficient and convenient

  • Verification code

There are various forms of captchas, but the main purpose is to distinguish between machines and humans

  • The user login

Rely on user login, identify user identity, control access authority

Single point call frequency limit

Single point call frequency limit is also a part of access control, which is special and often ignored. Single point call frequency limits often translate into machine and human recognition, because the normal operation of real people is often difficult to meet the call frequency limits threshold.

Factors to consider for single point call frequency limits:

  • High resource cost

It needs to consume too much computer resources (CPU, IO, disk, etc.), too much bandwidth, extra cost (SMS verification code, other charged services, etc.), if the API has the above features, then in order to avoid illegal use and lead to waste of system cost, it needs to be prevented as much as possible technically

  • Maintain fairness

In certain business scenarios, such as limited buying and voting, it may be necessary to limit the frequency of single point calls to maintain fairness

Unified response format

The unified response format mainly refers to the return value of the business API. The standard STATUS code of HTTP is one way, but it is not recommended to use it directly in business scenarios. Most modern server apis use JSON as the data exchange format, and applying HTTP standard status codes can make front-end logic processing cumbersome.

For example, if the article ID corresponding to the article ID does Not exist, if the HTTP standard status code is adopted, the response code should be 404, and the cause phrase is Not Found. Because the interface itself is designed as JSON return value, returning 404 status code will cause the front-end can Not enter the normal processing logic. Additional logic is required to understand the response and kindly prompt the user.

Unified API response format, using the following simple structure:

response = {
    code: number, // 0 indicates success, other indicates failure
    msg: string,  // Description. If code is not 0, it indicates an error description
    result: var	   // Response data on success, used for business processing
};
Copy the code

All exceptions that can be caught can be returned wrapped in the structure above, Content-Type: application/json.

peer

Server instances can be deployed in two types: single-node multi-process deployment and multi-machine multi-process deployment. A single machine with multiple processes can be deployed on multiple machines if the dependence on a single machine (such as local files, local network resources, and local unique services) is resolved.

Load balancing

If the server instances are deployed peer-to-peer, that is, multiple instances of the same service are running, there is usually a load balancing server in front that takes into account the load of multiple service instances and sends them different numbers of requests. Load balancing can be thought of as another level of routing.

The reverse proxy

A reverse proxy server hides information about the real server, interacts with clients, and integrates other functions. Outstanding representative: Nginx, stable and reliable performance, including most non-business related features, such as caching, access logging, load balancing, routing and forwarding, etc.

conclusion

A modern WEB server is not necessarily all of the above, nor is it limited to all of the above. Each of the above, is based on their own understanding, a simple description, not involved in the specific implementation and technical details, because each content, there are too much too much content. In the follow-up, I will write a separate article for a more detailed and in-depth introduction of some of these contents.

The original blog