Backend Knowledge system--a complete HTTP request

The requests here are in the range that the backend DevOps can control, not including DNS resolution, layers of routing, and so on, all from the request to the server we set up. 1. Establish a connection with the server The establishment of 1.1 TCP connection

Client's request arrives at the server, the first is to establish a TCP connection

The client first sends a connection temptation, ack=0 indicates that the confirmation number is invalid, and SYN = 1 means that this is a connection request or connection acceptance message, and that the datagram cannot carry data, seq = x represents the client's own initial sequence number (seq = 0 Represents this is package No. 0), This is when the client enters the Syn_sent state, which indicates that clients wait for the server to reply

When the server hears the connection request message, if it agrees to establish a connection, it sends a confirmation to the client. The SYN and ACK in the TCP message header are set to 1, ack = x + 1 means expecting to receive the first byte ordinal of the next segment of the message is x+1, indicating that all data for X has been received correctly (Ack=1 is actually ack=0+1, which is the 1th package expected by the client), seq = Y represents the server's own initial sequence number (Seq=0 represents this is the NO. 0 package issued by the server side). At this point the server entered the SYN_RCVD, indicating that the server has received the client's connection request, waiting for client confirmation.

The client receives confirmation and sends a confirmation again, carrying the data to be sent to the server. ACK 1 indicates that the confirmation number ack= y + 1 is valid (the representative expects to receive the 1th packet of the server), and the client's own serial number seq= X + 1 (indicating that this is my 1th package, relative to the No. 0 packet), once the client is confirmed, This TCP connection enters the established state, and you can initiate an HTTP request.

1.2 Common TCP connection Limits

1.2.1 Modify user process to open file limit

On Linux platforms, regardless of whether you write a client program or a server-side program, the highest number of concurrent TCP connection processing is limited by the system's number of simultaneous open files for a single user process (this is because the system creates a socket handle for each TCP connection). Each socket handle is also a file handle. You can use the Ulimit command to view the number of file limits that the system allows the current user process to open, 256,linux is 1024 on Windows, and the server for this blog is 65535

1.2.2 Modify the network kernel's restrictions on TCP connections

When writing client-side communication handlers that support high concurrent TCP connections on Linux, it is sometimes found that although the system has been removed from the user's limit on the number of files opened simultaneously, a new TCP connection can no longer be successfully established when the number of concurrent TCP connections increases to a certain number. There are many reasons why this is happening now.
The first reason may be because the Linux network kernel has a limited range of local port numbers. At this point, further analysis of why the TCP connection could not be established, the problem will be found in the Connect () call return failed to view the system error message is "Can" T assign requestedaddress. Also, if you use the Tcpdump tool to monitor the network at this time, you will find the network traffic that the client sends a SYN packet when there is no TCP connection at all. These situations indicate that the problem lies in the limitations of the local Linux system kernel.

In fact, the root cause of the problem is that the TCP/IP Protocol implementation module of the Linux kernel limits the scope of the local port number corresponding to all the client TCP connections in the system (for example, the kernel limits the local port number to the range of 1024~32768). When there are too many TCP client connections at one time in the system, because each TCP client connection takes up a unique local port number (this port number is in the system's local port number range limit), if an existing TCP client connection has full local port numbers, You cannot assign a local port number to a new TCP client connection at this point, so the system will fail back in the Connect () call in this case and set the error message to "Can" t assignrequested address. 2. Initiating an HTTP request

2.1 Request Format

For example, a request like this

Accept is to tell the server side that I accept those MIME types

Accept-encoding this looks like a file that accepts those compression patterns.

Accept-lanague tells the server what languages to send

Connection tells the server to support Keep-alive features

Cookies carry cookies on each request to facilitate server-side identification of the same client

Host is used to identify the virtual hosts on the requesting server, such as Nginx can define many virtual hosts
That's what this is used to identify the virtual host to access.

User-agent User Agent, the general situation is the browser, there are other types, such as: wget Curl search engine spiders and so on

Condition Request Header:
If-modified-since is the browser to the server to ask a resource file if ever modified, then send it back to me, so that the server-side resources
When the file is updated, the browser requests it again, instead of using the file in the cache

Security Request Header:
Authorization: Authentication information provided to the server by the client

2.2 keep-alive/persitent

The overhead of re-establishing a TCP connection for each HTTP request is significant, and so there is the keep-alive header, which allows multiple HTTP messages to be sent/received in a single TCP connection

However, there are drawbacks to keep-alive. In HTTP1.0, the client initiates the request with the Keep-alive header and the service-side response with the keep-alive header, the request is considered keep-alive until one of the parties actively disconnects. If you do not disconnect correctly, this resource will always be occupied.

Dumb agent problem: The dummy agent is only a simple forwarding request, and can not be resolved processing, maintain a durable connection and other work, and intelligent agent can resolve the message received at the same time can maintain a persistent connection.

As shown above, when the client and server do not resolve direct forwarding agent, connection:keep-alive This header is directly to the server, the server received this request, Sends a connection:keep-alive response to the client, and the same blind agent does not resolve the response and forwards all responses directly back to the client. Because the client received this header, it is believed that the establishment of a persistent connection has been successful, but the middle of the "stupid agent", do not know these things, the stupid agent has only one behavior pattern: after forwarding the request and Loopback server response request that the transaction is over, waiting for the connection to disconnect, And then because the connection:keep-alive header has been sent to the server and the client, both sides believe that the persistent connection has been established, so that the two sides think that the persistent connection OK and the middle of the mute agent waiting for the connection to disconnect, In this case, if the client sends a request again on this connection, the request stops at the sub proxy because the dummy agent is already waiting for the connection to close. This state will cause the browser has been suspended until a client or server in a connection timeout, close the connection, a good hand is so lost (the mute agent is to the content of the forwarding to the agent intact).

in order to avoid this situation, the modern agent is not forwarding connection:keep-alive this header.

Persistent

http/1.1 persistent connections are turned on by default and only the header contains connection:close to close the connection after the transaction ends. Of course, servers and clients can still turn off persistent connections at any time.

When the Connection:close header is sent, there is no way for the client to send more requests on that connection. Of course, according to the characteristics of the persistent connection, must transmit the correct content-length.

Also, according to the http/1.1 feature, a persistent connection should not be established with the http/1.0 client. Finally, be sure to prepare for the heavy hair.

piped Connections

http/1.1 allows pipelines to be used on persistent connections so that you do not have to wait for the response of the previous request to send a second request directly on the pipeline, improving performance at high latency.

Restrictions on piping connections: pipelines cannot be used without persistent connections. The response must be echoed in the same order of dispatch, because the message is not labeled and is likely to be scrambled in sequence. Because you can turn off persistent connections at any time, you should not use a piped send repeatedly to send repeated requests that have side effects (such as post, duplicate submission). 3. Load Balancing

After receiving the HTTP request, it is time to load balanced debut, which is located on the front end of the site, the high amount of traffic in a short time allocated to different machines to deal with. The load balancing scheme has two kinds of software and hardware

F5 Big-ip is a famous hardware scheme, but it is not discussed here.

The software scheme has the LVS haproxy Nginx and so on, leaves to add after 4.Nginx (Web server)

In a typical rails application deployment scenario, the Nginx role has two processing static file request forwarding requests to the back-end rails application

This is a simple nginx configuration file.

The back-end Rails server communicates with Nginx via UNIX sockets, Nginx static files in the servo public folder to the user 5.Rails (application server)

This article invincible, I have no more to write, can only say that I use is Puma. Because the server is a single core, only multi-threaded Puma or event-driven thin, taking into account the possibility of using Rails 5 actioncabel, or directly on the Puma bar. 6. Database (database server)

The application server needs to establish a connection to the database if it wants to access the database. Rails reads the configuration in the Database.yml and accesses the corresponding database.

An important configuration indicator pool: Database connections in rails are fully thread-safe, and all pool values are configured to be equal to the maximum number of threads puma, so that the thread waits for a database connection. 7.Redis, Memercache (cache server) 8. Message Queuing 9. Search Reference Documents

A complete HTTP transaction is a process.

Various restrictions on the maximum number of connections for high concurrent sockets under Linux

Keep-alive

Talk about the Enduring connection--http authoritative guide reading experience (v)

How the database connection pool works