HTTP/2 - 版本历史

2023年12月8日 (五) 07:53 Riguz

2023-12-08T07:53:06Z

←上一版本		2023年12月8日 (五) 07:53的版本
第2行：		第2行：

	After a call for proposals and a selection process, SPDY/2 was chosen as the basis for HTTP/2. Since then, there have been a number of changes, based on discussion in the Working Group and feedback from implementers<ref>https://http2.github.io/faq/g</ref>.		After a call for proposals and a selection process, SPDY/2 was chosen as the basis for HTTP/2. Since then, there have been a number of changes, based on discussion in the Working Group and feedback from implementers<ref>https://http2.github.io/faq/g</ref>.

			* [https://datatracker.ietf.org/doc/html/rfc7540 RFC7540:HTTP/2]
			* [https://datatracker.ietf.org/doc/html/rfc7541 RFC7541:HPACK]

	=Overview =		=Overview =
	== HTTP/2 or HTTP/2.0?==		== HTTP/2 or HTTP/2.0?==

Riguz：/* HTTP2-Settings */

2023-12-08T07:50:45Z

HTTP2-Settings

←上一版本		2023年12月8日 (五) 07:50的版本
第77行：		第77行：

	=== HTTP2-Settings ===		=== HTTP2-Settings ===





			= FAQ =
			== Will I need TCP_NODELAY for my HTTP/2 connections? ==
			Yes, probably. Even for a client-side implementation that only downloads a lot of data using a single stream, some packets will still be necessary to send back in the opposite direction to achieve maximum transfer speeds. Without '''TCP_NODELAY''' set (still allowing the Nagle algorithm), the outgoing packets may be held for a while in order to allow them to merge with a subsequent one.

			In cases where such a packet, for example, is a packet telling the peer that there is more window available to send data, delaying its sending for multiple milliseconds (or more) can have a severe impact on high speed connections.



	[[Category:Network]]		[[Category:Network]]

Riguz：/* Header compression */

2023-12-08T07:45:39Z

Header compression

←上一版本		2023年12月8日 (五) 07:45的版本
第28行：		第28行：

	=== Header compression===		=== Header compression===
	Small files load more quickly than large ones. To speed up web performance, both HTTP/1.1 and HTTP/2 compress HTTP messages to make them smaller. However, HTTP/2 uses a more advanced compression method called HPACK that eliminates redundant information in HTTP header packets. This eliminates a few bytes from every HTTP packet. Given the volume of HTTP packets involved in loading even a single webpage, those bytes add up quickly, resulting in faster loading.		Small files load more quickly than large ones. To speed up web performance, both HTTP/1.1 and HTTP/2 compress HTTP messages to make them smaller. However, HTTP/2 uses a more advanced compression method called '''HPACK''' that eliminates redundant information in HTTP header packets. This eliminates a few bytes from every HTTP packet. Given the volume of HTTP packets involved in loading even a single webpage, those bytes add up quickly, resulting in faster loading.

	SPDY/2 proposed using a single GZIP context in each direction for header compression, which was simple to implement as well as efficient.		SPDY/2 proposed using a single GZIP context in each direction for header compression, which was simple to implement as well as efficient.

Riguz：/* Header compression */

2023-12-08T07:45:16Z

Header compression

←上一版本		2023年12月8日 (五) 07:45的版本
第29行：		第29行：
	=== Header compression===		=== Header compression===
	Small files load more quickly than large ones. To speed up web performance, both HTTP/1.1 and HTTP/2 compress HTTP messages to make them smaller. However, HTTP/2 uses a more advanced compression method called HPACK that eliminates redundant information in HTTP header packets. This eliminates a few bytes from every HTTP packet. Given the volume of HTTP packets involved in loading even a single webpage, those bytes add up quickly, resulting in faster loading.		Small files load more quickly than large ones. To speed up web performance, both HTTP/1.1 and HTTP/2 compress HTTP messages to make them smaller. However, HTTP/2 uses a more advanced compression method called HPACK that eliminates redundant information in HTTP header packets. This eliminates a few bytes from every HTTP packet. Given the volume of HTTP packets involved in loading even a single webpage, those bytes add up quickly, resulting in faster loading.

			SPDY/2 proposed using a single GZIP context in each direction for header compression, which was simple to implement as well as efficient.

			Since then, a major attack has been documented against the use of stream compression (like GZIP) inside of encryption; CRIME.

			With CRIME, it’s possible for an attacker who has the ability to inject data into the encrypted stream to “probe” the plaintext and recover it. Since this is the Web, JavaScript makes this possible, and there were demonstrations of recovery of cookies and authentication tokens using CRIME for TLS-protected HTTP resources.

			As a result, we could not use GZIP compression. Finding no other algorithms that were suitable for this use case as well as safe to use, we created a new, header-specific compression scheme that operates at a coarse granularity; since HTTP headers often don’t change between messages, this still gives reasonable compression efficiency, and is much safer.

	== HTTP/2 Discovery ==		== HTTP/2 Discovery ==

Riguz：/* HTTP/2 key differences to HTTP/1.1 */

2023-12-08T01:59:19Z

HTTP/2 key differences to HTTP/1.1

←上一版本		2023年12月8日 (五) 01:59的版本
第16行：		第16行：
	* uses header compression to reduce overhead		* uses header compression to reduce overhead
	* allows servers to “push” responses proactively into client caches		* allows servers to “push” responses proactively into client caches
			== Why binary？ ==
			Binary protocols are more efficient to parse, more compact “on the wire”, and most importantly, they are much less error-prone, compared to textual protocols like HTTP/1.x, because they often have a number of affordances to “help” with things like whitespace handling, capitalization, line endings, blank lines and so on.

			For example, HTTP/1.1 defines four different ways to parse a message; in HTTP/2, there’s just one code path.

	=== Multiplexing===		=== Multiplexing===

2023年12月8日 (五) 01:55 Riguz

2023-12-08T01:55:55Z

←上一版本		2023年12月8日 (五) 01:55的版本
第2行：		第2行：

	After a call for proposals and a selection process, SPDY/2 was chosen as the basis for HTTP/2. Since then, there have been a number of changes, based on discussion in the Working Group and feedback from implementers<ref>https://http2.github.io/faq/g</ref>.		After a call for proposals and a selection process, SPDY/2 was chosen as the basis for HTTP/2. Since then, there have been a number of changes, based on discussion in the Working Group and feedback from implementers<ref>https://http2.github.io/faq/g</ref>.
			=Overview =
	== HTTP/2 or HTTP/2.0?==		== HTTP/2 or HTTP/2.0?==
	The Working Group decided to drop the minor version (“.0”) because it has caused a lot of confusion in HTTP/1.x.		The Working Group decided to drop the minor version (“.0”) because it has caused a lot of confusion in HTTP/1.x.

Riguz：/* HTTP2 vs HTTP1 */

2023-12-08T01:55:41Z

HTTP2 vs HTTP1

←上一版本		2023年12月8日 (五) 01:55的版本
第8行：		第8行：
	In other words, the HTTP version only indicates wire compatibility, not feature sets or “marketing.”		In other words, the HTTP version only indicates wire compatibility, not feature sets or “marketing.”

	== ~~HTTP2 vs HTTP1 ==~~		== HTTP/2 key differences to HTTP/1.1==
	~~Multiplexing:~~ HTTP/1.1 ~~loads resources one after the other, so if one resource cannot be loaded, it blocks all the other resources behind it. In contrast~~, HTTP/2 is able to use a single TCP connection to send multiple streams of data at once so that no one resource blocks any other resource. HTTP/2 does this by splitting data into binary-code messages and numbering these messages so that the client knows which stream each binary message belongs to.		At a high level, HTTP/2:

	Server push: Typically, a server only serves content to a client device if the client asks for it. However, this approach is not always practical for modern webpages, which often involve several dozen separate resources that the client must request. HTTP/2 solves this problem by allowing a server to "push" content to a client before the client asks for it. The server also sends a message letting the client know what pushed content to expect – like if Bob had sent Alice a Table of Contents of his novel before sending the whole thing.		* is binary, instead of textual
			* is fully multiplexed, instead of ordered and blocking
			* can therefore use one connection for parallelism
			* uses header compression to reduce overhead
			* allows servers to “push” responses proactively into client caches

			=== Multiplexing===
			HTTP/1.1 loads resources one after the other, so if one resource cannot be loaded, it blocks all the other resources behind it. In contrast, HTTP/2 is able to use a single TCP connection to send multiple streams of data at once so that no one resource blocks any other resource. HTTP/2 does this by splitting data into binary-code messages and numbering these messages so that the client knows which stream each binary message belongs to.

			=== Server push ===
			Typically, a server only serves content to a client device if the client asks for it. However, this approach is not always practical for modern webpages, which often involve several dozen separate resources that the client must request. HTTP/2 solves this problem by allowing a server to "push" content to a client before the client asks for it. The server also sends a message letting the client know what pushed content to expect – like if Bob had sent Alice a Table of Contents of his novel before sending the whole thing.

			=== Header compression===
			Small files load more quickly than large ones. To speed up web performance, both HTTP/1.1 and HTTP/2 compress HTTP messages to make them smaller. However, HTTP/2 uses a more advanced compression method called HPACK that eliminates redundant information in HTTP header packets. This eliminates a few bytes from every HTTP packet. Given the volume of HTTP packets involved in loading even a single webpage, those bytes add up quickly, resulting in faster loading.

	Header compression: Small files load more quickly than large ones. To speed up web performance, both HTTP/1.1 and HTTP/2 compress HTTP messages to make them smaller. However, HTTP/2 uses a more advanced compression method called HPACK that eliminates redundant information in HTTP header packets. This eliminates a few bytes from every HTTP packet. Given the volume of HTTP packets involved in loading even a single webpage, those bytes add up quickly, resulting in faster loading.
	== HTTP/2 Discovery ==		== HTTP/2 Discovery ==
	;h2: HTTP/2 over TLS		;h2: HTTP/2 over TLS

2023年12月8日 (五) 01:53 Riguz

2023-12-08T01:53:32Z

←上一版本		2023年12月8日 (五) 01:53的版本
第1行：		第1行：
			HTTP/2 was first discussed when it became apparent that SPDY was gaining traction with implementers (like Mozilla and nginx), and was showing significant improvements over HTTP/1.x.

			After a call for proposals and a selection process, SPDY/2 was chosen as the basis for HTTP/2. Since then, there have been a number of changes, based on discussion in the Working Group and feedback from implementers<ref>https://http2.github.io/faq/g</ref>.

			== HTTP/2 or HTTP/2.0?==
			The Working Group decided to drop the minor version (“.0”) because it has caused a lot of confusion in HTTP/1.x.

			In other words, the HTTP version only indicates wire compatibility, not feature sets or “marketing.”

	== HTTP2 vs HTTP1 ==		== HTTP2 vs HTTP1 ==

Riguz：Riguz moved page Hypertext Transfer Protocol -- HTTP/2 to HTTP/2 without leaving a redirect

2023-12-06T07:26:26Z

Riguz moved page Hypertext Transfer Protocol -- HTTP/2 to HTTP/2 without leaving a redirect

←上一版本	2023年12月6日 (三) 07:26的版本
（没有差异）

2023年12月5日 (二) 09:31 Riguz

2023-12-05T09:31:07Z

←上一版本		2023年12月5日 (二) 09:31的版本
第47行：		第47行：

	[[Category:Network]]		[[Category:Network]]
			[[Category:RFC]]
			[[Category:Protocol]]
			[[Category:HTTP]]

HTTP/2 - 版本历史

2023年12月8日 (五) 07:53 Riguz

Riguz：​/* HTTP2-Settings */

Riguz：​/* Header compression */

Riguz：​/* Header compression */

Riguz：​/* HTTP/2 key differences to HTTP/1.1 */

2023年12月8日 (五) 01:55 Riguz

Riguz：​/* HTTP2 vs HTTP1 */

2023年12月8日 (五) 01:53 Riguz

Riguz：​Riguz moved page Hypertext Transfer Protocol -- HTTP/2 to HTTP/2 without leaving a redirect

2023年12月5日 (二) 09:31 Riguz

Riguz：/* HTTP2-Settings */

Riguz：/* Header compression */

Riguz：/* Header compression */

Riguz：/* HTTP/2 key differences to HTTP/1.1 */

Riguz：/* HTTP2 vs HTTP1 */

Riguz：Riguz moved page Hypertext Transfer Protocol -- HTTP/2 to HTTP/2 without leaving a redirect