Shulou(Shulou.com)06/01 Report--

This article mainly explains "what are the common factors that affect the performance of http". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "what are the common factors that affect the performance of http".

TCP connection establishment

Usually, if the network is stable, TCP connection establishment does not take a lot of time and the three-way handshake process will be completed within a reasonable time range, but because HTTP is a stateless short connection, a HTTP session will be disconnected after it is accepted. A web page usually has a lot of resources, which means that many HTTP sessions will take place. Compared with HTTP sessions, TCP three-way handshake to establish a connection will seem too time-consuming. Of course, you can reduce the number of TCP connection establishment times by reusing existing connections.

TCP slow start

TCP congestion control method 1 will limit the maximum transmission speed of the connection in the initial transmission phase just after the establishment of the TCP. If the data transmission is successful, the transmission speed will be gradually increased, which will lead to the slow start of TCP. Slow start limits the number of IP packets 2 that can be transmitted at a given time. So why is there a slow start? Mainly to prevent the network from being paralyzed by large-scale data transmission, a very important link of data transmission on the Internet is the router, and the speed of the router itself is not fast, and a lot of traffic on the Internet may be sent to ask it to route and forward. If the amount of data arriving at the router within a certain period of time is much greater than the amount it sends, the router will discard packets when the local cache is exhausted, which is called congestion. This condition on a router can affect many links and seriously cause large areas of paralysis. So either side of TCP communication needs congestion control, and slow start is one of the algorithms or mechanisms of congestion control.

You imagine a situation where we know that TCP has a retransmission mechanism. If a router in the network loses packets in a large area because of congestion, and as the sender of the data, its TCP stack will definitely detect this situation, then it will activate the TCP retransmission mechanism, and the router must affect more than one sender. So a large number of sender TCP stacks have started to retransmit, which is tantamount to sending more packets on the originally congested network, which is tantamount to adding fuel to the fire.

Through the above description, it is concluded that even in a normal network environment, the establishment of a TCP connection between the sender of a HTTP message and each request will be affected by slow start, and then according to the fact that HTTP is a short connection, the session will be disconnected at the end of a session. It is conceivable that the HTTP will be disconnected as soon as the client initiates a HTTP request to obtain a resource on the web page, and the TCP connection may be disconnected before the TCP slow start process is finished. Other follow-up resources on the web page will continue to establish TCP connections, and each TCP connection will have a slow start phase. This performance can be imagined, so in order to improve performance, we can turn on the persistent connection of HTTP, that is, keepalive.

In addition, we know that there is a concept of window in TCP, which has both sender and receiver. On the one hand, the function of window ensures that the sender and receiver become orderly when managing packets; in addition, multiple packets can be sent on an orderly basis to improve throughput; another point is that this window can be resized to prevent the sender from sending data faster than the receiver. Although the window solves the rate problem of double communication, but other network devices will pass through the network, how does the sender know the receiving capacity of the router? So there is the congestion control described above.

TCP delayed acknowledgement

First of all, we need to know what an acknowledgment is, which means that the sender sends a TCP segment to the receiver, and the receiver sends back an acknowledgement to indicate receipt. If the sender does not receive the acknowledgement within a certain period of time, then it needs to resend the TCP segment.

Acknowledgement messages are usually small, that is, an IP packet can carry multiple acknowledgement messages, so in order to avoid sending too many small messages, the receiver will wait to see if there is any other data sent to the receiver when sending back the acknowledgement message. If so, send the acknowledgement message and data together in a TCP segment. If the content is usually 100-200 milliseconds in a certain period of time, no other data needs to be sent, then the acknowledgement message is sent in a separate packet. In fact, the purpose of doing this is to reduce the network burden as much as possible.

A popular example is logistics, the load of the truck is certain, if it is 10 tons, from city A to city B, you must want it to be as full as possible instead of a small package and you will get up and go to city B.

Therefore, TCP is not designed to return ACK confirmation immediately after a packet. It usually accumulates in the cache for a period of time. If there is data in the same direction, the previous ACK confirmation will be sent back along with it, but it cannot wait too long. Otherwise, the other party will think that the packet has been lost and cause the other party to retransmit.

Whether or not to use and how to use delayed confirmation varies from operating system to operating system, for example, Linux can be enabled or disabled, and turning off means confirming one at a time, which is also a quick confirmation mode.

What you need to pay attention to is whether it is enabled or how many milliseconds are set, depending on the scene. For example, in online game scenarios, it must be confirmed as soon as possible, and delayed confirmation can be used in SSH sessions.

For HTTP, we can turn off or adjust the TCP delay confirmation.

Nagle algorithm

In fact, this algorithm is also designed to improve the IP packet utilization and reduce the network burden, which still involves small messages and full-size messages (calculated according to Ethernet standard MTU1500 bytes, messages less than 1500 are non-full-size messages), but no matter how small the tabloid message is, it will not be less than 40 bytes, because the IP header and the TCP header each occupy 20 bytes. If you send a 50-byte message, it means that there is too little valid data, just like delayed acknowledgement, small packets are not a big problem in the LAN, mainly affecting the WAN.

In fact, this algorithm is that if the sender has sent a message in the current TCP connection but has not yet received an acknowledgment, then if the sender still has a small message to send, it cannot be sent but should be put into a buffer to wait for the acknowledgment to be sent before. after receiving the acknowledgement, the sender will collect the small messages in the same direction in the cache and assemble them into a message to send. In fact, this means that the faster the receiver returns the ACK confirmation, the faster the sender will send the data.

Now let's talk about the problems caused by the combination of delayed acknowledgment and Nagle algorithm. In fact, it is easy to see that because of delayed acknowledgments, the receiver will accumulate ACK acknowledgments over a period of time, while the sender will not receive ACK during this period of time, so it will not continue to send the remaining non-full-size packets (the data is divided into multiple IP packets, and the number of packets of response data to be sent by the sender may not be an integer multiple of 1500. There is a high probability that some data at the end of the data will be grouped into small-size IP packets), so you can see the contradiction here. Then this problem will affect the transmission performance in TCP transmission. Then HTTP depends on TCP, so naturally it will also affect HTTP performance. Usually, we disable this algorithm on the server side. We can disable the algorithm on the operating system or set TCP_NODELAY in HTTP programs to disable the algorithm. For example, in Nginx you can use tcp_nodelay on; to disable it.

TIME_WAIT accumulation and Port exhaustion 3

This refers to the client side or the party that shuts down actively in the TCP connection, although the server can also initiate a shutdown initiatively, but we are talking about HTTP performance here. Because of the connection nature of HTTP, it is usually the client that initiates the active shutdown.

The client initiates a HTTP request (here it refers to a request for a specific resource rather than opening a so-called home page, which has N multiple resources, so it will lead to the initiation of N HTTP requests). After the request ends, the TCP connection is disconnected. Then the TCP state of the connection on the client will appear in a state called TIME_WAIT, which usually takes time after the 2MSL4 is closed. We know that the client accesses the HTTP service of the server using its own local random high port to connect to the server's port 80 or 443 to establish HTTP communication (which is essentially TCP communication), which means that the number of available ports on the client will be consumed. Although the client disconnects and releases this random port, after the client actively disconnects, the TCP status is within the 2MSL period from TIME_WAIT to the real CLOSED. This random port will not be used (if the client initiates HTTP access to the same server again), one of its purposes is to prevent dirty data on the same TCP socket. From the above conclusion, we know that if the client's HTTP access to the server is too dense, then it is possible that the port usage speed is higher than the port release speed, resulting in the connection cannot be established because there are no available random ports.

As we said above, it is usually the client that closes the connection actively.

TCP/IP detailed Volume 1 second Edition, P442, the last paragraph states that for interactive applications, the client usually performs an active shutdown operation and enters the TIME_WAIT state, while the server usually performs a passive shutdown operation and does not directly enter the TIME_WAIT state.

However, if the web server is enabled and keep-alive is enabled, the server will shut down actively when the timeout is reached. (I'm not saying that TCP/IP is misinterpreted here, but it's mainly for TCP in that section, and it doesn't introduce HTTP, and it means usually, not necessarily.)

I use Nginx for testing, and set the default setting of keepalive_timeout 65s leading Nginx in the configuration file to 75s. A setting of 0 means that keepalive is disabled, as shown below:

Next, I use the Chrom browser to visit the home page provided by Nginx by default, and monitor the whole communication process through the packet capture program, as shown below:

You can see from the above figure that the communication marked by Keep-Alive appears after the valid data has been transferred, and the server actively disconnects after no request within 65 seconds. In this case, you will see the status of TIME_WAIT on the Nginx server.

Server port exhaustion

Some people say that Nginx listens to 80 or 443, and the client connects to this port. How can the server run out of ports? Just like the following figure (ignoring the TIME_WAIT in the figure, the reason for this has already been mentioned above is due to the keepalive_timeout setting of Nginx)

In fact, it depends on the Nginx working mode, and we usually use Nginx to make it work in proxy mode, which means that the real resource or data is on the back-end Web application, such as Tomcat. The characteristic of proxy mode is that the proxy server goes to the backend to obtain data instead of the user, so Nginx is a client relative to the backend server. At this time, Nginx will use random ports to initiate requests to the backend, and the range of random ports available to the system is certain. You can use the sysctl net.ipv4.ip_local_port_range command to view the random port range on the server.

Through the delayed acknowledgement, Nagle algorithm, and Nginx acting as the client in the back end and connecting to the back end using random ports, which means that there is a risk of port exhaustion on the server side. It is possible for random ports to be released more slowly than to establish a connection to the back end. However, this usually does not happen, at least I did not find this phenomenon in the Nginx of our company. Because first of all, static resources are on CDN; secondly, most of the backend interfaces provide user authentication or database operations, which are basically fast if there is no bottleneck in the backend. But then again, if there is really a bottleneck in the backend and the cost of expanding or changing the architecture is relatively high, then what you should do in the face of a large number of concurrency is to limit the flow to prevent the backend from being killed.

The maximum number of files opened by the server-side HTTP process

We said that HTTP communication depends on TCP connections, and a TCP connection is a socket. For Unix-like systems, opening a socket is opening a file. If there are 100 requests to connect to the server, then once the connection is established, the server will open 100 files, while in the Linux system, the number of files that a process can open is limited to ulimit-f. So if this value is set too low, it will also affect the HTTP connection. For Nginx or other HTTP programs running in proxy mode, usually two sockets will be opened for one connection and two files will be occupied (except for those that hit the Nginx local cache or Nginx returns data directly). Therefore, for the proxy server, the number of files that can be opened by this process should also be set a little larger.

Persistent connection Keepalive

First of all, we need to know that keepalive can be set on two levels, and the two levels have different meanings. The keepalive of TCP is a live probing mechanism, such as the heartbeat message we often say, indicating that the other party is still online, and this heartbeat message is sent at intervals, which means that each other's TCP connection should always be open, while keep-alive in HTTP is a mechanism to reuse TCP connection to avoid frequently establishing TCP connection. So you must understand that TCP's Keepalive and HTTP's Keep-alive are not the same thing.

Keep-alive Mechanism of HTTP

Non-persistent connections disconnect the TCP connection after each HTTP transaction is completed, and the next HTTP transaction reestablishes the TCP connection, which is obviously not an efficient mechanism, so in HTTP/1.1 and enhanced versions of HTTP/1.0, HTTP is allowed to keep the TCP connection open after the transaction ends, so that subsequent HTTP transactions can reuse the connection until the client or server actively closes the connection. Persistent connections reduce the number of TCP connections and maximize the traffic restrictions caused by TCP slow start.

Related tutorials: HTTP Video tutorial

Let's take a look at this figure. Keepalive_timeout 65s in the figure sets the keep-alive feature of http and sets the timeout to 65 seconds. In fact, a more important option is keepalive_requests 100, which indicates the maximum number of HTTP requests that can be initiated by a TCP connection. The default is 100.

Keep-alive is not used by default in HTTP/1.0. The client must send a HTTP request with the header of Connection: Keep-alive to try to activate keep-alive. If the server does not support it, it will not be able to use it, and all requests will be carried out in a normal form. If the server supports it, the information of Connection: Keep-alive will be included in the response header.

Keep-alive is used by default in HTTP/1.1, and all connections are persistent unless otherwise specified. If you want to close a connection after the end of a transaction, the Connection: CLose header must be included in the response header of the HTTP, otherwise the connection will remain open all the time, and certainly not always open, and the idle connection must be closed, as set by Nginx above for up to 65 seconds, after which the server will actively disconnect the connection.

Keepalive of TCP

There is no uniform switch on or off the Keepalive function of TCP on Linux. Check the setting of system keepalive sysctl-a | grep tcp_keepalive. If you haven't modified it, it will display on Centos system:

one

two

three

Net.ipv4.tcp_keepalive_intvl = 75 # how many seconds is the direct interval between two probes

Net.ipv4.tcp_keepalive_probes = 9 # detection frequency

Net.ipv4.tcp_keepalive_time = 7200 # indicates how long it takes to detect, in seconds, that is, 2 hours.

According to the default setting, the overall meaning of the above is to detect once every 2 hours. If the first probe fails, then probe again in 75 seconds, and disconnect actively if it fails 9 times.

How to enable Keepalive at the TCP level on Nginx? in Nginx, there is a statement called listen, which is used to set the port on which Nginx listens in the server segment. In fact, there are other parameters behind it that are used to set socket attributes. See the following settings:

one

two

three

four

five

six

seven

# indicates enabled. The keepalive parameter of TCP uses the default

Listen 80 default_server so_keepalive=on

# indicates that keepalive of TCP is explicitly turned off

Listen 80 default_server so_keepalive=off

# means to enable. Set the detection every 30 minutes. The detection interval uses the default settings of the system. A total of 10 probes are performed. The settings here

# setting will override the above system default settings

Listen 80 default_server so_keepalive=30m::10

So whether or not to set this so_keepalive on Nginx depends on the specific scenario, do not confuse TCP's keepalive with HTTP's keepalive, because Nginx does not enable so_keepalive and does not affect your HTTP request to use the keep-alive feature. If there is a load balancer device between the client and the Nginx or between the Nginx and the back-end server, and responses and requests will pass through the load balancer device, then you should pay attention to this so_keepalive. For example, it is not affected in the direct routing mode of LVS, because the response does not pass through

LVS, but you need to pay attention to NAT mode, because LVS also maintains a TCP session for a period of time. If this period is less than the amount of data returned by the backend, LVS will disconnect the TCP connection if the client has not yet received the data.

Thank you for your reading, the above is the content of "what are the common factors that affect the performance of http". After the study of this article, I believe you have a deeper understanding of what the common factors that affect the performance of http are, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.