Short connection
Establish a connection with the server before sending a request. After receiving a response packet, the server closes the connection immediately. Because the entire connection between a client and a server is short and does not remain connected for a long time, it is called a short-lived connection.
A long connection
Also known as persistent connections, long connections are enabled by default for HTTP/1.1 connections. Once the first request is sent to the server, subsequent requests reuse the first opened TCP connection, known as the long connection, to receive and receive data on this connection. You can also explicitly specify “Connection: keep-alive” in the request header.
Long connection disadvantage: Because the TCP connection is not closed for a long time, the server must store its state in memory, which consumes server resources. If there are a large number of idle long connections, the resources of the server will soon be exhausted and the server will not be able to provide services to the users who really need them.
Therefore, long connections also need to be closed at the appropriate time and cannot remain connected to the server forever, which can be done on either the client or the server.
On the client side, you can add a “Connection: close” field to the request header to tell the server, “Close the Connection after this communication.” When the server sees this field, it knows that the client wants to close the connection. Therefore, the server adds this field to the response packet and calls the Socket API to close the TCP connection after sending the response packet.
The server usually does not close the connection voluntarily but can do so by setting a policy, such as in Nginx
Use the keepalive_timeout command to set the timeout period for the long connection
Use the Keepalive_requests directive to set the maximum number of requests that can be sent over a long connection
Team head block
Queue head blocking has nothing to do with short and long connections, but is caused by the basic REQUEST-reply model of HTTP.
HTTP dictates that packets must be received on a first in, first out (FIFO) basis. This creates a serialized fifO queue, in which requests are processed in the first order, rather than in the first order.
If the request at the head of the queue is delayed because it is being processed too slowly, all subsequent requests in the queue have to wait along with it, resulting in other requests incurring undue time costs.
The example of using the company to punch in: queuing to punch in, there is a person in front of the punch in the machine failure, waiting for someone to repair the punch in the machine behind the people are late
Performance optimization
Clocking problem: The company will buy more units so that people don’t have to crowd in a queue, disperse clocking, a queue blocking can be changed to a non-blocking queue
In HTTP, it is concurrent connections, or making multiple long connections to a domain name at the same time, using quantity to solve a quality problem.
But there are drawbacks to this approach. If each client wanted to make many connections fast, the number of users multiplied by the number of concurrent connections would be astronomical. The server’s resources simply cannot support, or the server considers it a malicious attack, but will cause a denial of service.
Therefore, HTTP recommends that clients use concurrency, but not abuse it. So limit each client to a maximum of 6-8 concurrent connections
Continue punching problem: The company develops too fast and there are more and more people at the front desk, so there are more places for punching, and several punching machines are placed at the entrance of each floor and office area to further divide people.
This is domain sharding technology, using quantity to solve the idea of quality.
HTTP cache
HTTP caching policy is to solve the client and the server exists the problem of asymmetric information, the client in order to speed up part will cache the resource, but the next request, the client does not know if there is any update to get the resources, the service side also don’t know is which version of the client cache, don’t know should shouldn’t return resources, is a information synchronization problems, The HTTP caching strategy is designed to solve this problem.
HTTP caching strategies are divided into strong caching and negotiated caching
Strong cache: if the resource is not expired, request the server if the cache expires. The Cache rule is based on the cache-control value of response Headers.
(Strong cache hit display)
Cache-control: Multiple rules can be used at the same time
Private: The browser that initiates the request can cache (cacheability)
Public: both browser and proxy servers can cache (cacheability)
Max-age = XXX: Expiration time (time limit)
No-cache: no cache is allowed, but the server must check whether it has expired and the latest version before using it. (Cacheability)
No-store: does not allow caching, either strong or negotiated caching, for some data that changes very frequently, such as seckill pages; (Cacheability)
Must -revalidate: If the cache does not expire, you can continue to use it, but if you want to use it after it expires, you must verify with the server. (Revalidate)
Example: Go to the supermarket to buy a watermelon
No store: You can’t put watermelon in the refrigerator. You have to eat it or throw it away.
No-cache: You can put it in the fridge, but you must ask the supermarket if it is fresher before eating.
“Must-revalidate” means you can keep it in the refrigerator for the duration of its freshness, but ask the supermarket if it will allow you to eat it when it expires.
Ctrl+F5 “force refresh” it actually sends a “cache-control: no-cache” which means the same as “max-age=0”.
Negotiated cache: ETag and Last-Modified rule controls
Last-modified: indicates the time when the file was Last modified.
ETag: an Entity Tag that uniquely identifies resources. It is used to solve the problem that file changes cannot be accurately identified by modification time.
What Etag does:
A. Some servers cannot accurately obtain the last modification time of the resource, so they cannot determine whether the resource is updated by the last modification time
B. If the resource is modified very frequently, modify it within seconds, while last-Modified is only accurate to seconds
C) The last modification time of some resources has changed, but the content has not changed.
The Response header is ETag and Last-Modified
Request header if-none-match (ETag), if-modified-since (last-modified)
At the time of the request the server compares the identity you brought in to determine if the resource has been changed.
Summary of negotiation cache steps:
1. When requesting a resource, the ETag of the local resource is sent to the server to compare the ETag with the latest resource
2. If the resource has not changed, 304 is returned, and the browser reads the local cache
3. If the resource has been changed, return 200 to return the latest resource.
The negotiated cache sends a request to the server anyway, but only returns header information when the resource is unchanged, so the size is small. When the resource changes, the body data is returned, so the size is large.