编程知识 cdmana.com

Short connection and long connection management of HTTP

Opening and maintaining connections affects the site and Web Application performance . stay HTTP/1.x There are many models in it : Short connection , A long connection , and HTTP Assembly line .

Short connection model

HTTP The transport protocol of is mainly dependent on TCP Provides a connection from the client to the server . In the early HTTP Use a simple model to handle such connections . The life cycle of these connections is short : Every time a request is made, a new connection is created , On closing and receiving an immediate response .

This simple model has inherent limitations on performance : Open each TCP Connections are resource intensive . A lot of messages need to be exchanged between the client and the server . When the request is initiated , Both network latency and bandwidth have an impact on performance . Modern browsers tend to make many requests ( A dozen or more ) To get the complete information you need , It proves the inefficiency of this early model .

therefore HTTP/1.1 Two new models were born . First of all

Long connection model

It keeps the connection to complete multiple consecutive requests , Reduce the time it takes to constantly reopen the connection . And then there was

HTTP Pipeline model

It needs to be more advanced , Multiple consecutive requests can be sent without even waiting for an immediate return , This reduces the time spent on network latency .

HTTP/2 Other connection management models have been added .

HTTP The connection management of is suitable for the connection between two continuous nodes , Such as hop-by-hop, instead of end-to-end. When the model is used for the connection from the client to the first proxy server and the connection from the proxy server to the target server ( Or any agency ) The effect may be different .HTTP The protocol header is affected by different connection models , such as Connection and Keep-Alive, Namely hop-by-hop Protocol header , Their values can be modified by intermediate nodes .

A related topic is HTTP Connection upgrade , ad locum , One HTTP/1.1 Connection upgraded to a different protocol , such as TLS/1.0,Websocket, Even in plaintext form HTTP/2.

Short connection

HTTP The earliest models , It's also HTTP/1.0 The default model for , Is short . every last HTTP Requests are made by its own independent connection ; It means launching every HTTP There will always be one before the request TCP handshake , And continuously .

TCP Protocol handshakes are time consuming in themselves , therefore TCP More hot connections can be maintained to accommodate the load . The short connection broke TCP Have the ability to , The new cold connection reduces its performance .

This is a HTTP/1.0 The default model for ( If not specified Connection Protocol header , Or the value is set to close). And in the HTTP/1.1 in , Only when Connection Set to close This model will be used when .

Unless it's compatible with a very old , Systems that do not support long connections , There is no convincing reason for this model to continue .

A long connection

There are two big problems with short connections :

  • The time taken to create a new connection is particularly obvious
  • TCP The performance of the connection is only after the connection has been used for a period of time ( hotlink ) To be improved

To alleviate these problems , Long connections are designed , Even in HTTP/1.1 Before . Or it's called a keep-alive Connect .

A long connection will last for a while , Repetition is used to send a series of requests , Save on new buildings TCP Time to connect handshakes , It can also be used TCP Performance enhancements for . Of course, this connection won't stay forever : The connection will be closed after a period of idle time ( Server can use Keep-Alive Protocol header to specify a minimum connection retention time ).

shortcoming

There are still disadvantages to long connection :
Even in the idle state , It still consumes server resources , And under heavy load , There is also the risk of DoS attacks attack . In this case , You can use non long connections , That is, close those idle connections as soon as possible , It can also improve performance .

HTTP/1.0 Long connections are not used by default . hold Connection Set to close Other parameters can keep it connected for a long time , It's usually set to retry-after.

stay HTTP/1.1 in , The default is long connected , There's no need to declare it in the header ( But we'll still add it , If at some point for some reason to return to the HTTP/1.0 Well ).

HTTP Assembly line

HTTP Pipelining is not enabled by default in modern browsers :

  • Web Developers can't easily meet and judge all kinds of strange behaviors of those funny proxy servers .
  • The correct implementation of pipelining is complex : Size of resources in transit , How effective RTT Will be used to , And the effective bandwidth , What is the scope of the improvement brought about by the assembly line . If you don't know this , Important messages can be delayed to the back of unimportant ones . This concept of importance can even evolve to affect page layout ! therefore HTTP In most cases, the improvement of assembly line is not obvious .
  • The assembly line is subject to HOL problem .
    For these reasons , Pipelining has been replaced by better algorithms , Such as multiplexing, Has been used in HTTP/2.

By default ,HTTP Requests are made in order . The next request is sent only after the current request has received a response . Due to the limitation of network delay and bandwidth , Before the next request is sent to the server , It may take a long time to wait .

Pipeline is to make continuous requests on the same long connection , Instead of waiting for a reply to return . This avoids connection delays . Theoretically speaking , Performance is also due to two HTTP Requests can be packaged into a TCP In the message packet . Even if the HTTP Ask for continued , The size will increase , But setting TCP Of MSS(Maximum Segment Size) Options , Still enough to contain a series of simple requests .

Not all types of HTTP Request can be used in the pipeline : Only idempotent The way , such as GET、HEAD、PUT and DELETE Can be safely retried : If something goes wrong , The content of the pipeline should be easily retried .

today , All follow HTTP/1.1 Both proxy and server should support pipelining , Although there are still many limitations in practice : A very important reason is that , No modern browser currently enables this feature by default .

Domain name segmentation

Unless you have an urgent and urgent need , Don't use this outdated technology , Upgrade to HTTP/2 Just fine . stay HTTP/2 in , There is no need to do domain segmentation :HTTP/2 Can handle concurrent and non priority requests very well . Domain name fragmentation can even affect performance . majority HTTP/2 The implementation also uses a technology called connection aggregation to try to merge the fragmented domain names .

As HTTP/1.x The connection of , The request is serialized , Even if it's out of order , When there is not enough bandwidth available , There's no way to optimize . One solution , The browser establishes multiple connections for each domain name , To implement concurrent requests . The default number of connections used to be 2 To 3 individual , Now the number of concurrent connections that are commonly used has increased to 6 strip . If you try to be larger than that , There's a trigger server DoS The risk of protection .

If the server wants to respond more quickly to a website or application response , It can force clients to make more connections . for example , Don't get all resources under the same domain name , Suppose a domain name is www.example.com, We can split it into several domains :www1.example.com、www2.example.com、www3.example.com. All of these domains point to the same server , The browser will create for each domain at the same time 6 link ( In our case , The number of connections will reach 18 strip ). This technology is called domain name slicing .

Conclusion

The improved connection management has greatly improved HTTP Performance of . Whether it's HTTP/1.1 still HTTP/1.0, Use long connection – Until it's idle – Can achieve the best performance . However , To solve the problem of pipeline failure, we need to design a more advanced connection management model ,HTTP/2 Already trying .

Reference resources

  • https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Connection_management_in_HTTP_1.x

版权声明
本文为[The official account -JavaEdge]所创,转载请带上原文链接,感谢
https://cdmana.com/2020/12/20201224153141234r.html

Scroll to Top