網(wǎng)絡(luò)基礎(chǔ)技術(shù)

The Transport Layer Security (TLS) Protocol Version 1.2
Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
TLS v1.3規(guī)范

QUIC

QUIC主頁(yè)
QUIC概要設(shè)計(jì)文檔

QUIC傳輸格式的詳細(xì)設(shè)計(jì)文檔

Google的QUIC協(xié)議:可以將web的TCP轉(zhuǎn)為UDP
Caddy – 最簡(jiǎn)單的支持 HTTP/2 的網(wǎng)頁(yè)服務(wù)器
Caddy
Caddy FAQ
Caddy QUIC WiKi
怎樣讓網(wǎng)站支持QUIC
現(xiàn)在怎么為自己網(wǎng)站開(kāi)啟 QUIC？

HTTP/2

HTTP/2規(guī)范
HPACK規(guī)范
ALPN規(guī)范
NPN規(guī)范
OkHttp對(duì)與NPN協(xié)議協(xié)商的支持

SPDY主頁(yè)
HTTP/2 GitHub主頁(yè)
Known implementations of HTTP/2
Netty支持HTTP/2 over cleartext TCP
HTTP/2 資料匯總 | JerryQu 的小站
HTTP 2.0的那些事

未來(lái)已到——HTTP/2

HTTP/2 - Design and Goals

High Performance Networking HTTP1 HTTP2

Even Faster Images using HTTP2 and Progressive JPEGs

I’ve turned h2 on… now what?

HTTP/2 Push: The details

https://www.google.com
https://www.aliyun.com
https://www.youtube.com
https://www.facebook.com
https://twitter.com

When will nginx add support for QUIC?

Jaco Toledo, I have experience with HTML, CSS, PHP and MYSQL1.2k Views

Don't think nginx will support quic anytime soon.If you're interested in playing with QUIC today you'll need to build the test QUIC server and client that are part of the Chromium project, get Google Chrome Canary and enable QUIC in chrome://flags.
Written 8 Feb

Zhifeng Mi1.1k Views

nginx is working on TCP level 7
and quic is based on UDP
so I don't see any chance nginx will support quic.
And actually, you just need to develop a udp to tcp proxy to pass the data to nginx.
Now in Chrome if you enable quic, Chrome will start a proxy to send data to the
web server so if you don't want to modify the whole architect in your server side.
develop a upd to tcp proxy to support quic will be enough.
Written 27 Dec 2015 · View Upvotes

總結(jié)：
不太可能期待nginx去支持QUIC協(xié)議，在nginx中應(yīng)用QUIC協(xié)議的方法是開(kāi)發(fā)UDP到TCP的代理，由代理作為nginx服務(wù)器和終端進(jìn)行通信時(shí)的橋梁。

What REST API Services Can Expect from HTTP/2

One of the hottest topics for discussion today is the new HTTP/2 that is the most substantial protocol update since 1999, the year when the HTTP/1.1 version was released.

Among the key improvements brought by HTTP/2 are multiplexed streams, header compression, server push, and a binary protocol instead of textual one. These and other positive changes allowed to achieve good web pages loading results, including those having lots of additional files attached to them (e.g. styles, scripts, images, fonts, etc.). But what effect is this going to have upon REST APIs and their work?

The first thing to talk about is the format of data transmission. As it has been mentioned above, a binary format has substituted a textual one which is good news for servers but not for developers. The latter one is convenient for program debugging but the binary one is still a good innovation, as it is much easier for a computer to process such data. Consequently, the binary format will contribute to lightening some of the server processor load, which would be helpful for heavily loaded REST APIs.

The protocol is compatible with the HTTP/1.1 version. Status codes, methods and headers did not overcome any changes. The only thing that did change is the way of transmitting data via TCP connection.

HTTP/2 is much more effective when it comes to processing a large number of requests. One of the biggest HTTP/1.1 problems is that separate requests are expensive. The reason for this is that many TCP connections are created, and these are established due to the “3-way handshake” method. Then some time has to pass for “slow start” algorithm to make the connection effectively fast. HTTP/2 is devoid of such a drawback thanks to multiplexed streams. This allows to make several HTTP requests as if they were made concurrently. Therefore, all the styles, scripts and images will load faster and users will certainly notice the speed increase. Although in REST APIs there is no need to load a few files simultaneously, multiplexing will let to perform a number of concurrent server requests more effectively due to one TCP connection being used for all these requests. This will also lighten the server load, as there will be no necessity to allocate resources to maintain more than one TCP connection, which will save some memory though the work of processor will be a little bit more intensive.

One more improvement that came with HTTP/2 is header compression. API requests usually have much less headers than ordinary web pages. That is why the benefits it may bring are most likely to be minor.

“Server push” technology made it possible for server to initiate data transmission. Here is an example. A client requests a web page. The web server processes the request and, as a result, gets an idea of what resources the client needs additionally and thus can send them right after the response with the document. This way, the client does not need to send additional request to get the additional resources mentioned above. Unfortunately, it is difficult to find a RESTful API service where this technology can be truly useful.

Though many changes brought with HTTP/2 were created to speed web browsing up, some of themcan be used in the world of REST APIs as well. It is possible to achieve greater efficiency at a lower cost if the HTTP/2 strong points are taken into consideration when designing an application.

總結(jié)：
HTTP/2的主要特性：

多路復(fù)用流。降低多個(gè)文件傳輸時(shí)建立TCP連接及TCP慢啟動(dòng)的開(kāi)銷(xiāo)，降低服務(wù)器維護(hù)TCP連接的開(kāi)銷(xiāo)從而降低服務(wù)器負(fù)載，節(jié)省內(nèi)存。

首部壓縮。

服務(wù)器推送。

二進(jìn)制的協(xié)議。方便計(jì)算機(jī)對(duì)數(shù)據(jù)的處理，降低服務(wù)器CPU的負(fù)載。但對(duì)開(kāi)發(fā)者調(diào)試不利。

請(qǐng)求優(yōu)先級(jí)。

其它。

HTTP/2能夠給Web頁(yè)加載帶來(lái)好處的特性：
幾乎全部特性都能給Web頁(yè)加載帶來(lái)性能提升。

HTTP/2特性給REST API服務(wù)帶來(lái)的影響：

二進(jìn)制的數(shù)據(jù)傳輸格式。對(duì)于負(fù)載較重的REST API服務(wù)比較有用。

多路復(fù)用流。對(duì)于一次性發(fā)送大量請(qǐng)求的Web加載比較有意義。對(duì)于REST API服務(wù)，依然可以帶來(lái)一定的好處，降低服務(wù)器負(fù)載，節(jié)省內(nèi)存。

首部壓縮。對(duì)于REST API服務(wù)而言，通常首部的數(shù)據(jù)量都不是特別大，此項(xiàng)特性帶來(lái)的好處并不大。

服務(wù)器推送對(duì)REST API服務(wù)的意義并不大。

Chrome不再支持SPDY

Transitioning from SPDY to HTTP/2
Thursday, February 11, 2016

Last year we announced our intent to end support for the experimental protocol SPDY in favor of the standardized version, HTTP/2. HTTP/2 is the next-generation protocol for transferring information on the web, improving upon HTTP/1.1 with more features leading to better performance. Since then we've seen huge adoption of HTTP/2 from both web servers and browsers, with most now supporting HTTP/2. Over 25% of resources in Chrome are currently served over HTTP/2, compared to less than 5% over SPDY. Based on such strong adoption, starting on May 15th — the anniversary of theHTTP/2 RFC — Chrome will no longer support SPDY. Servers that do not support HTTP/2 by that time will serve Chrome requests over HTTP/1.1, providing the exact same features to users without the enhanced performance of HTTP/2.

At the same time, Chrome will stop supporting the TLS protocol extension NPN, which allows servers to negotiate SPDY and HTTP/2 connections with clients. NPN has been superseded by the TLS extension ALPN, published by the IETF in 2014. ALPN is already used 99% of the time to negotiate HTTP/2 with Chrome, and the remaining servers can gain ALPN support by upgrading their SSL library.

We are looking forward to HTTP/2 continuing to gain adoption, bringing us an even faster web.

Update: To better align with Chrome's release cycle, SPDY and NPN support will be removed with the release of Chrome 51.

Posted by Bence Béky, Network Protocol Engineer and HTTP/2 Enthusiast

總結(jié)：
采用HTTP/2的Web服務(wù)器和瀏覽器非常多。Chrome訪(fǎng)問(wèn)的資源中有25%使用HTTP/2傳輸，而使用SPDY的資源不足5%。

Chrome在5月15日起，也就是正式版HTTP/2 RFC發(fā)布一周年的時(shí)候，不再支持SPDY了。不支持HTTP/2的服務(wù)器將用HTTP/1.1協(xié)議訪(fǎng)問(wèn)。
同時(shí)也將不再支持HTTP/2和SPDY的NPN協(xié)商，而只支持ALPN協(xié)商。Chrome中已經(jīng)有99%的時(shí)間在使用ALPN協(xié)商。ALPN通常可以通過(guò)升級(jí)使用的SSL庫(kù)來(lái)實(shí)現(xiàn)。

總結(jié)

以上是生活随笔為你收集整理的QUIC/HTTP2相关资料整理的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。