Translation

English
English French Actions
Other frame types are described later. The `Flags` are used for some frame types and the `R` bit must be set to zero. The last important field of the `HTTP/2.0 Frame` header is the `Stream Identifier`. With HTTP/2.0, the bytestream of the underlying transport connection is divided in independent streams that are identified by an integer. The odd (resp. even) stream identifiers are managed by the client (resp. server). This enables the server (or the client) to multiplex data corresponding to different frames over a single bytestream.
This multiplexing capability is probably the most important feature of HTTP/2.0 from a performance viewpoint. To understand its benefits, let us consider a client that retrieves two web objects over a 1 Mbps connection. The two requests are sent together by the client. The first object is 125 bytes long, while the second is 12500 bytes long. In this case, the server will first return the first object as a single frame and the second will be sent in the subsequent frame.
Consider now that the first object is 12500 bytes long and the second 125 bytes long. With a 1 Mbps connection, this object will use the underlying connection during 100 milliseconds. The client will thus need to wait 100 milliseconds to retrieve the second object. This is the `Head of Line` (HoL) blocking problem that affects the performance of many web services. If the short web object is a javascript code that requests other web objects, its retrieval may be critical to display the retrieved web page.
With HTTP/2.0 frames, the server could send the first 1250 bytes of the long object during 10 milliseconds, then send a second frame that contains the short object during one millisecond and later send a longer frame that contains the remaining 11250 bytes of the long object. In this case, the client has received the short object after 10 milliseconds. Given the HTTP/2.0 streams, the transmission of long web objects does not anymore blocks the transmission of shorter ones.
The length of the HTTP/2.0 frames obviously affects how different web objects can be multiplexed over the underlying transport connection. If HTTP/2.0 frames are long, the overhead of the frame header is minimal, but long frames can block short web objects. On the other hand, if the frame length is small, then the overhead due to the HTTP/2.0 frame header could become significant.
The HTTP/2.0 streams can provide performance benefits, but they also increase the complexity of the implementations since an HTTP/2.0 receiver must be able to simultaneously process frames that correspond to different web objects. This complexity mainly resides on the client side. The HTTP/2.0 protocol includes several techniques that enable clients to manage the utilization of the HTTP/2.0 session.
The first frame that a client sends over an HTTP/2.0 session is the `Settings` frame. This is a control frame that indicates some parameters that the client proposes for this session. Several of these parameters are defined in :rfc:`7540`. The most important ones are probably the `SETTINGS_MAX_FRAME_SIZE` that specifies the maximum length of the HTTP/2.0 frames that this implementation supports and the `SETTINGS_MAX_CONCURRENT_STREAMS` that specifies the maximum number of parallel streams that this implementation can manage. The `SETTINGS_MAX_FRAME_SIZE` must be at least :math:`2^{14}` bytes but can go up to :math:`2^{24} -1` bytes. There is no minimum value for `SETTINGS_MAX_CONCURRENT_STREAMS`, but :rfc:`7540` recommends to support at least 100 different stream identifiers.
By using multiple streams, the server can multiplex different web objects over the same underlying transport connection. However, these objects are only sent in response to requests from clients. There are some situations where the server might know in advance that the client will request a given object. It could speedup the transfer by sending it before having received a client request. This is the `push` feature of HTTP/2.0. A server can independently push web objects to a client without having received any request. This feature can only be used by the server if the client has enabled it by sending `SETTINGS_ENABLE_PUSH` in its `Settings` frame. A classical use case for this `push` feature is to enable a server to automatically send an object which cannot be cached by the client, such as a dynamic javascript code, when another web object that references it is requested. However, measurement studies indicate that very few web servers seem to have adopted this feature [ZWH2018]_.
Another feature of HTTP/2.0 is that it is possible to assign different priorities to different streams. A high priority stream should carry more `Data` frames than a lower priority ones. The HTTP/2.0 specification defines `Priority` frames which can be used for this purpose.
As the server can send multiple objects at the same time, there is a risk of overloading the client buffers. To cope with this potential problem, HTTP/2.0 includes its own flow control mechanism. When an HTTP/2.0 session starts, a receiver agrees to receive up to 65,535 bytes over this connection (unless it has indicated a different initial window in its `Settings` frame). This limits the amount of data that a sender can transmit over the HTTP/2.0 session. The receiver can advertise a large receive window by sending a `Window_Update` frame at any time. This flow control mechanism can be applied to the entire connection or to a specific stream. In practice, using a small `HTTP/2.0 window` could severely limit the throughput over an HTTP/2.0 session.
HTTP/2.0 includes much more than what we have covered in this short introduction. There is for example a `Ping` frame that allows measuring the round-trip-time between a client and a server or the `GoAway` frame that indicates the termination of an HTTP/2.0 session. This frame contains an error code that indicates why the session has been terminated. Several error codes are defined in :rfc:`7540`, including `ENHANCE_YOUR_CALM` that is used to indicate that the other endpoint exhibits an behavior that could cause excessive load.
Detecting whether a server supports HTTP/2.0
The `HTTP2-Settings` line contains the HTTP/2.0 settings frame that the client would server over an HTTP/2.0 session encoded in Base64. The server replies with a response that indicates that it has accepted to upgrade the connection to HTTP/2.0. A sample response is shown below.
Finally, the client and the server need to confirm the utilization of HTTP/2.0. A client confirms this by sending the following Magic string `PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n` or `0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a` in hex. This string is followed by a SETTINGS frame. The server must send a possibly empty SETTINGS frame.
Footnotes
See https://en.wikipedia.org/wiki/HTTP_pipelining for additional information.

Showing only subset of the strings as there were too many matches.

Component Translation Difference to current string
This translation Propagated Empty cnp3-ebook/protocols/http2
The following strings have the same context and source.
Propagated Translated cnp3-ebook/exercises/transport Notes de pied de page
Propagated Translated cnp3-ebook/principles/naming Notes de pied de page
Propagated Translated cnp3-ebook/exercises/http Notes de pied de page
Propagated Translated cnp3-ebook/principles/referencemodels Notes de pied de page
Propagated Translated cnp3-ebook/principles/security Notes de pied de page
Propagated Translated cnp3-ebook/exercises/dns Notes de pied de page
Propagated Empty cnp3-ebook/protocols/bgp
Propagated Empty cnp3-ebook/protocols/dnssec
Propagated Translated cnp3-ebook/exercises/tcp Notes de pied de page
Propagated Translated cnp3-ebook/exercises/tls Notes de pied de page
Propagated Empty cnp3-ebook/protocols/rpc
Propagated Empty cnp3-ebook/protocols/ipv6
Propagated Empty cnp3-ebook/protocols/ppp
Propagated Empty cnp3-ebook/protocols/tls
Propagated Empty cnp3-ebook/protocols/wifi
Propagated Translated cnp3-ebook/exercises/sockets Notes de pied de page
Propagated Translated cnp3-ebook/principles/sharing Notes de pied de page
Propagated Empty cnp3-ebook/protocols/udp
Propagated Translated cnp3-ebook/principles/network Notes de pied de page

Loading…

User avatar None

New source string

cnp3-ebook / protocols/http2French

New source string 2 years ago
Browse all component changes

Things to check

Inconsistent

This string has more than one translation in this project or is untranslated in some components.

Reset

Glossary

English French
No related strings found in the glossary.

String information

Source string location
../../protocols/http2.rst:266
String age
2 years ago
Source string age
2 years ago
Translation file
locale/fr/LC_MESSAGES/protocols/http2.po, string 39