Ten rules for creating large and high-performance Web sites

In China, the open-source LAMP stack is the most popular network architecture. it is developed using PHP and runs on an Apache server. it uses MySQL as a database and runs on Linux. It is a reliable platform that runs well and is now the world's most popular Internet system architecture.

In China, the open-source LAMP stack is the most popular network architecture. it is developed using PHP and runs on an Apache server. it uses MySQL as a database and runs on Linux. It is a reliable platform that runs well and is now the world's most popular Internet system architecture.

However, it is difficult for us to correctly scale and maintain security because each application layer has its own problems, defects, and best practices. The actual situation is that many websites are created quickly and cheaply by developers. Generally, there are no IT staff or managers, but programmers only manage the system.

The result is that, although the website can start to run at a very low cost, it usually faces real problems when there are a large number of users who need to scale up. After all, there are 0.3 billion million Internet users in China. if 80 million of them access this site, it will easily lead to 0.01% ~ 0.5 million of page traffic.

These problems are generated at all levels. The rules Summarized below are an overview of the most common problems, and explain why these rules are so important and the best way to fix them. Websites that follow these suggestions will improve scalability, security, and operational stability.

Use appropriate session management

The first way to expand the system is to add more hardware. For example, use two servers instead of one. This sounds reasonable, but may cause potential problems: Session management. This is a serious problem for Java programs, and may also cause scalability problems in PHP, especially for database load.

A session is defined as a separate end user login or connection period. it usually contains multiple TCP/IP HTTP connections and several Web pages, it usually includes dozens or even hundreds of page elements, such as frameworks, menus, and Ajax updates. All these HTTP requests need to know who the user is to meet the security requirements and send appropriate content to the user, because these are part of the session. Generally, each session includes associated session data, such as user name, user ID, history, shopping cart, and statistics.

The problem is that when there are two Web servers and multiple HTTP connections, user traffic will be allocated and moved between the two servers. it is difficult for the server to know who the user is, and track all the data, because each page or page component may come from different servers. In PHP, a session ID is created and put in the Cookie during the first connection or login. then, the Cookie is sent together with each HTTP request.

This poses a problem. Next, each PHP script needs to search for session data based on the ID. Since PHP cannot maintain state during execution (different from Java), the session data needs to be stored somewhere, usually in the database. However, if a complex page needs to be searched ten times during each page loading process (this is often done), it means that each page needs to perform ten SQL queries, this will cause a large load on the database.

In the preceding example of 0.01% Internet users in China, it may be easy to generate hundreds of queries per second for the sake of management sessions. The solution is to always use the session ID in the Cookie and use services such as Memcached to cache session data for high performance.

It is also important to note that security issues exist, because hackers can forge the session ID of another user, which is easily found or seen, especially in public Wi-Fi. The solution is to properly encrypt or sign the session ID and bind it with the time interval, IP address, and other key information such as the browser or other details. There are many good examples of good session management on the Internet, you can find the most suitable as needed.

Always consider security

Although writing code like preventing SQL injection and login security involves many security issues, unfortunately, almost no one has considered security, those who consider it do not have a good understanding of it. This article focuses on operational system security. For such security, we focus on three security fields: firewall, operating users, and file access permissions.

In addition to configuring dedicated hardware firewalls (such as Cisco's ASA), all servers should also run firewalls such as Iptables, which protect servers from other threats and attacks. These threats and attacks may come from the public Internet, other servers, or local servers. They also include developers and operators who use VPN or SSH channels. We only open the required port to the specified IP address. Iptables may be complex, but there are many good templates that we can usually use to help customers create Iptables. For example, the default RedHat or CentOS firewall configuration is only 10 lines, which is obviously not practical. Our best practice of Iptables configuration has about five pages, which includes the most advanced security protection provided by Linux.

All public services should run under special users, such as Apache. Never run with the Root user, because this will allow any user that breaks into Apache to take over the entire server. If Apache runs only under the Apache user or the Nobody, it is not easy to break into Apache.

Web server running or service files (such as .php and .html files) should not be writable to Web server users. This means that Apache or Nginx users should not have the write permission for the Web Directory. Many methods can do this, and the simplest is to use these files as owned by other users, then, users such as Apache and Nginx are assigned to a group that can read files with 640 permissions. This prevents almost all hackers and page attacks.

In addition, never use Ftp to upload files, especially in public Wi-Fi environments, because hackers can easily steal user names and passwords. Instead, Sftp is more secure. In addition, each employee should have his/her own user ID and random password.