建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
自從我寫(xiě)了上一篇博文之后，就再也找不到空閑時(shí)間寫(xiě)文章了。今天我終于可以抽出時(shí)間寫(xiě)一些關(guān)于 HTTP 的東西。
目前創(chuàng)新互聯(lián)已為1000+的企業(yè)提供了網(wǎng)站建設(shè)、域名、虛擬空間、網(wǎng)站托管、服務(wù)器托管、企業(yè)網(wǎng)站設(shè)計(jì)、巧家網(wǎng)站維護(hù)等服務(wù)，公司將堅(jiān)持客戶(hù)導(dǎo)向、應(yīng)用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶(hù)和合作伙伴齊心協(xié)力一起成長(zhǎng)，共同發(fā)展。
我認(rèn)為每一個(gè) web 開(kāi)發(fā)者都應(yīng)該對(duì)這個(gè)支撐了整個(gè) Web 世界的 HTTP 協(xié)議有所了解，這樣才能幫助你更好的完成開(kāi)發(fā)任務(wù)。
在這篇文章中，我將討論什么是 HTTP，它是怎么產(chǎn)生的，它的地位，以及我們應(yīng)該怎么使用它。
HTTP 是什么
首先我們要明白 HTTP 是什么。HTTP 是一個(gè)基于 TCP/IP 的應(yīng)用層通信協(xié)議，它是客戶(hù)端和服務(wù)端在互聯(lián)網(wǎng)互相通訊的標(biāo)準(zhǔn)。它定義了內(nèi)容是如何通過(guò)互聯(lián)網(wǎng)進(jìn)行請(qǐng)求和傳輸?shù)?。HTTP 是在應(yīng)用層中抽象出的一個(gè)標(biāo)準(zhǔn)，使得主機(jī)(客戶(hù)端和服務(wù)端)之間的通信得以通過(guò) TCP/IP 來(lái)進(jìn)行請(qǐng)求和響應(yīng)。TCP 默認(rèn)使用的端口是 80，當(dāng)然也可以使用其它端口，比如 HTTPS 使用的就是 443 端口。
HTTP/0.9 - 單行協(xié)議 (1991)
HTTP 最早的規(guī)范可以追溯到 1991 年，那時(shí)候的版本是 HTTP/0.9，該版本極其簡(jiǎn)單，只有一個(gè)叫做 GET的請(qǐng)求方式。如果客戶(hù)端要訪(fǎng)問(wèn)服務(wù)端上的一個(gè)頁(yè)面，只需要如下非常簡(jiǎn)單的請(qǐng)求：
- GET /index.html
服務(wù)端對(duì)應(yīng)的返回類(lèi)似如下：
- (response body)
- (connection closed)
就這么簡(jiǎn)單，服務(wù)端捕獲到請(qǐng)求后立馬返回 HTML 并且關(guān)閉連接，在這之中
- 沒(méi)有頭信息(headers)
- 僅支持 GET 這一種請(qǐng)求方法
- 必須返回 HTML
如同你所看到的，當(dāng)時(shí)的 HTTP 協(xié)議只是一塊基礎(chǔ)的墊腳石。
HTTP/1.0 - 1996
在 1996 年，新版本的 HTTP 對(duì)比之前的版本有了極大的改進(jìn)，同時(shí)也被命名為 HTTP/1.0。
與 HTTP/0.9 只能返回 HTML 不同的是，HTTP/1.0 支持處理多種返回的格式，比如圖片、視頻、文本或者其他格式的文件。它還增加了更多的請(qǐng)求方法(如 POST 和 HEAD)，請(qǐng)求和響應(yīng)的格式也相應(yīng)做了改變，兩者都增加了頭信息;引入了狀態(tài)碼來(lái)定義返回的特征;引入了字符集支持;支持多段類(lèi)型(multi-part)、用戶(hù)驗(yàn)證信息、緩存、內(nèi)容編碼格式等等。
一個(gè)簡(jiǎn)單的 HTTP/1.0 請(qǐng)求大概是這樣的：
- GET / HTTP/1.0
- Host: kamranahmed.info
- User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5)
- Accept: */*
正如你所看到的，在請(qǐng)求中附帶了客戶(hù)端中的一些個(gè)人信息、響應(yīng)類(lèi)型要求等內(nèi)容。這些是在 HTTP/0.9 無(wú)法實(shí)現(xiàn)的，因?yàn)槟菚r(shí)候沒(méi)有頭信息。
一個(gè)對(duì)上述請(qǐng)求的響應(yīng)例子如下所示：
- HTTP/1.0 200 OK
- Content-Type: text/plain
- Content-Length: 137582
- Expires: Thu, 05 Dec 1997 16:00:00 GMT
- Last-Modified: Wed, 5 August 1996 15:55:28 GMT
- Server: Apache 0.84
- (response body)
- (connection closed)
從 HTTP/1.0 (HTTP 后面跟的是版本號(hào))早期開(kāi)始，在狀態(tài)碼 200 之后就附帶一個(gè)原因短語(yǔ)(你可以用來(lái)描述狀態(tài)碼)。
在這個(gè)較新一點(diǎn)的版本中，請(qǐng)求和響應(yīng)的頭信息仍然必須是 ASCII 編碼，但是響應(yīng)的內(nèi)容可以是任意類(lèi)型，如圖片、視頻、HTML、文本或其他類(lèi)型，服務(wù)器可以返回任意內(nèi)容給客戶(hù)端。所以這之后，HTTP 中的“超文本(Hyper Text)”成了名不副實(shí)。 HMTP (超媒體傳輸協(xié)議(Hypermedia transfer protocol))可能會(huì)更有意義，但是我猜我們還是會(huì)一直沿用這個(gè)名字。
HTTP/1.0 的一個(gè)主要缺點(diǎn)就是它不能在一個(gè)連接內(nèi)擁有多個(gè)請(qǐng)求。這意味著，當(dāng)客戶(hù)端需要從服務(wù)器獲取東西時(shí)，必須建立一個(gè)新的 TCP 連接，并且處理完單個(gè)請(qǐng)求后連接即被關(guān)閉。需要下一個(gè)東西時(shí)，你必須重新建立一個(gè)新的連接。這樣的壞處在哪呢?假設(shè)你要訪(fǎng)問(wèn)一個(gè)有 10 張圖片，5 個(gè)樣式表(stylesheet)和 5 個(gè) JavaScript 的總計(jì) 20 個(gè)文件才能完整展示的一個(gè)頁(yè)面。由于一個(gè)連接在處理完成一次請(qǐng)求后即被關(guān)閉，所以將有 20 個(gè)單獨(dú)的連接，每一個(gè)文件都將通過(guò)各自對(duì)應(yīng)的連接單獨(dú)處理。當(dāng)連接數(shù)量變得龐大的時(shí)候就會(huì)面臨嚴(yán)重的性能問(wèn)題，因?yàn)?TCP 啟動(dòng)需要經(jīng)過(guò)三次握手，才能緩慢開(kāi)始。
三次握手
三次握手是一個(gè)簡(jiǎn)單的模型，所有的 TCP 連接在傳輸應(yīng)用數(shù)據(jù)之前都需要在三次握手中傳輸一系列數(shù)據(jù)包。
- SYN - 客戶(hù)端選取一個(gè)隨機(jī)數(shù)，我們稱(chēng)為 x，然后發(fā)送給服務(wù)器。
- SYN ACK - 服務(wù)器響應(yīng)對(duì)應(yīng)請(qǐng)求的 ACK 包中，包含了一個(gè)由服務(wù)器隨機(jī)產(chǎn)生的數(shù)字，我們稱(chēng)為 y，并且把客戶(hù)端發(fā)送的 x+1，一并返回給客戶(hù)端。
- ACK - 客戶(hù)端在從服務(wù)器接受到 y 之后把 y 加上 1 作為一個(gè) ACK 包返回給服務(wù)器。
一旦三次握手完成后，客戶(hù)端和服務(wù)器之間就可以開(kāi)始交換數(shù)據(jù)。值得注意的是，當(dāng)客戶(hù)端發(fā)出***一個(gè) ACK 數(shù)據(jù)包后，就可以立刻向服務(wù)器發(fā)送應(yīng)用數(shù)據(jù)包，而服務(wù)器則需要等到收到這個(gè) ACK 數(shù)據(jù)包后才能接受應(yīng)用數(shù)據(jù)包。
請(qǐng)注意，上圖有點(diǎn)小問(wèn)題，客戶(hù)端發(fā)回的***一個(gè) ACK 包僅包含 y+1，上圖應(yīng)該是 ACK:y+1 而不是 ACK:x+1,y+1
然而，某些 HTTP/1.0 的實(shí)現(xiàn)試圖通過(guò)新引入一個(gè)稱(chēng)為 Connection: keep-alive 的頭信息來(lái)克服這一問(wèn)題，這個(gè)頭信息意味著告訴服務(wù)器“嘿，服務(wù)器，請(qǐng)不要關(guān)閉此連接，我還要用它”。但是，這并沒(méi)有得到廣泛的支持，問(wèn)題依然存在。
除了無(wú)連接之外，HTTP 還是一個(gè)無(wú)狀態(tài)的協(xié)議，即服務(wù)器不維護(hù)有關(guān)客戶(hù)端的信息。因此每個(gè)請(qǐng)求必須給服務(wù)器必要的信息才能完成請(qǐng)求，每個(gè)請(qǐng)求都與之前的舊的請(qǐng)求無(wú)關(guān)。所以，這增加了推波助瀾的作用，客戶(hù)端除了需要新建大量連接之外，在每次連接中還需要發(fā)送許多重復(fù)的數(shù)據(jù)，這導(dǎo)致了帶寬的大量浪費(fèi)。
HTTP/1.1 - 1999
HTTP/1.0 經(jīng)過(guò)僅僅 3 年，下一個(gè)版本，即 HTTP/1.1 就在 1999 年發(fā)布了，改進(jìn)了它的前身很多問(wèn)題，主要的改進(jìn)包括：
- 增加了許多 HTTP 請(qǐng)求方法，包括 PUT、PATCH、HEAD、OPTIONS、DELETE。
- 主機(jī)標(biāo)識(shí)符 Host 在 HTTP/1.0 并不是必須的，而在 HTTP/1.1 是必須的。
- 如上所述的持久連接。在 HTTP/1.0 中每個(gè)連接只有一個(gè)請(qǐng)求并在該請(qǐng)求結(jié)束后被立即關(guān)閉，這導(dǎo)致了性能問(wèn)題和增加了延遲。 HTTP/1.1 引入了持久連接，即連接在默認(rèn)情況下是不關(guān)閉并保持開(kāi)放的，這允許多個(gè)連續(xù)的請(qǐng)求使用這個(gè)連接。要關(guān)閉該連接只需要在頭信息加入 Connection: close，客戶(hù)通常在***一個(gè)請(qǐng)求里發(fā)送這個(gè)頭信息就能安全地關(guān)閉連接。
- 新版本還引入了“管線(xiàn)化(pipelining)”的支持，客戶(hù)端可以不用等待服務(wù)器返回響應(yīng)，就能在同一個(gè)連接內(nèi)發(fā)送多個(gè)請(qǐng)求給服務(wù)器，而服務(wù)器必須以接收到的請(qǐng)求相同的序列發(fā)送響應(yīng)。但是你可能會(huì)問(wèn)了，客戶(hù)端如何知道哪里是***個(gè)響應(yīng)下載完成而下一個(gè)響應(yīng)內(nèi)容開(kāi)始的地方呢?要解決這個(gè)問(wèn)題，頭信息必須有 Content-Length，客戶(hù)可以使用它來(lái)確定哪些響應(yīng)結(jié)束之后可以開(kāi)始等待下一個(gè)響應(yīng)。
。值得注意的是，為了從持久連接或管線(xiàn)化中受益， 頭部信息必須包含 Content-Length，因?yàn)檫@會(huì)使客戶(hù)端知道什么時(shí)候完成了傳輸，然后它可以發(fā)送下一個(gè)請(qǐng)求(持久連接中，以正常的依次順序發(fā)送請(qǐng)求)或開(kāi)始等待下一個(gè)響應(yīng)(啟用管線(xiàn)化時(shí))。
。但是，使用這種方法仍然有一個(gè)問(wèn)題。那就是，如果數(shù)據(jù)是動(dòng)態(tài)的，服務(wù)器無(wú)法提前知道內(nèi)容長(zhǎng)度呢?那么在這種情況下，你就不能使用這種方法中獲益了嗎?為了解決這個(gè)問(wèn)題，HTTP/1.1 引進(jìn)了分塊編碼。在這種情況下，服務(wù)器可能會(huì)忽略 Content-Length 來(lái)支持分塊編碼(更常見(jiàn)一些)。但是，如果它們都不可用，那么連接必須在請(qǐng)求結(jié)束時(shí)關(guān)閉。
- 在動(dòng)態(tài)內(nèi)容的情況下分塊傳輸，當(dāng)服務(wù)器在傳輸開(kāi)始但無(wú)法得到 Content-Length 時(shí)，它可能會(huì)開(kāi)始按塊發(fā)送內(nèi)容(一塊接一塊)，并在傳輸時(shí)為每一個(gè)小塊添加 Content-Length。當(dāng)發(fā)送完所有的數(shù)據(jù)塊后，即整個(gè)傳輸已經(jīng)完成后，它發(fā)送一個(gè)空的小塊，比如設(shè)置 Content-Length 為 0 ，以便客戶(hù)端知道傳輸已完成。為了通知客戶(hù)端塊傳輸?shù)男畔?，服?wù)器在頭信息中包含了 Transfer-Encoding: chunked。
- 不像 HTTP/1.0 中只有 Basic 身份驗(yàn)證方式，HTTP/1.1 包括摘要驗(yàn)證方式(digest authentication)和代理驗(yàn)證方式(proxy authentication)。
- 緩存。
- 范圍請(qǐng)求(Byte Ranges)。
- 字符集。
- 內(nèi)容協(xié)商(Content Negotiation)。
- 客戶(hù)端 cookies。
- 支持壓縮。
- 新的狀態(tài)碼。
- 等等。
我不打算在這里討論所有 HTTP/1.1 的特性，因?yàn)槟憧梢試@這個(gè)話(huà)題找到很多關(guān)于這些的討論。我建議你閱讀 HTTP/1.0 和 HTTP/1.1 版本之間的主要差異，希望了解更多可以讀原始的 RFC。
HTTP/1.1 在 1999 年推出，到現(xiàn)在已經(jīng)是多年前的標(biāo)準(zhǔn)。雖然，它比前一代改善了很多，但是網(wǎng)絡(luò)日新月異，它已經(jīng)垂垂老矣。相比之前，加載網(wǎng)頁(yè)更是一個(gè)資源密集型任務(wù)，打開(kāi)一個(gè)簡(jiǎn)單的網(wǎng)頁(yè)已經(jīng)需要建立超過(guò) 30 個(gè)連接。你或許會(huì)說(shuō)，HTTP/1.1 具有持久連接，為什么還有這么多連接呢?其原因是，在任何時(shí)刻 HTTP/1.1 只能有一個(gè)未完成的連接。 HTTP/1.1 試圖通過(guò)引入管線(xiàn)來(lái)解決這個(gè)問(wèn)題，但它并沒(méi)有完全地解決。因?yàn)橐坏┕芫€(xiàn)遇到了緩慢的請(qǐng)求或龐大的請(qǐng)求，后面的請(qǐng)求便被阻塞住，它們必須等待上一個(gè)請(qǐng)求完成。為了克服 HTTP/1.1 的這些缺點(diǎn)，開(kāi)發(fā)人員開(kāi)始實(shí)現(xiàn)一些解決方法，例如使用 spritesheets、在 CSS 中編碼圖像、單個(gè)巨型 CSS / JavaScript 文件、域名切分等。
SPDY - 2009
谷歌走在業(yè)界前列，為了使網(wǎng)絡(luò)速度更快，提高網(wǎng)絡(luò)安全，同時(shí)減少網(wǎng)頁(yè)的等待時(shí)間，他們開(kāi)始實(shí)驗(yàn)替代的協(xié)議。在 2009 年，他們宣布了 SPDY。
SPDY 是谷歌的商標(biāo)，而不是一個(gè)縮寫(xiě)。
顯而易見(jiàn)的是，如果我們繼續(xù)增加帶寬，網(wǎng)絡(luò)性能開(kāi)始的時(shí)候能夠得到提升，但是到了某個(gè)階段后帶來(lái)的性能提升就很有限了。但是如果把這些優(yōu)化放在等待時(shí)間上，比如減少等待時(shí)間，將會(huì)有持續(xù)的性能提升。這就是 SPDY 優(yōu)化之前的協(xié)議的核心思想，減少等待時(shí)間來(lái)提升網(wǎng)絡(luò)性能。
對(duì)于那些不知道其中區(qū)別的人，等待時(shí)間就是延遲，即數(shù)據(jù)從源到達(dá)目的地需要多長(zhǎng)時(shí)間(單位為毫秒)，而帶寬是每秒鐘數(shù)據(jù)的傳輸量(比特每秒)。
SPDY 的特點(diǎn)包括：復(fù)用、壓縮、優(yōu)先級(jí)、安全性等。我不打算展開(kāi) SPDY 的細(xì)節(jié)。在下一章節(jié)，當(dāng)我們將介紹 HTTP/2，這些都會(huì)被提到，因?yàn)?HTTP/2 大多特性是從 SPDY 受啟發(fā)的。
SPDY 沒(méi)有試圖取代 HTTP，它是處于應(yīng)用層的 HTTP 之上的一個(gè)傳輸層，它只是在請(qǐng)求被發(fā)送之前做了一些修改。它開(kāi)始成為事實(shí)標(biāo)準(zhǔn)，大多數(shù)瀏覽器都開(kāi)始支持了。
2015年，谷歌不想有兩個(gè)相互競(jìng)爭(zhēng)的標(biāo)準(zhǔn)，所以他們決定將其合并到 HTTP 協(xié)議，這樣就導(dǎo)致了 HTTP/2 的出現(xiàn)和 SPDY 的廢棄。
HTTP/2 - 2015
現(xiàn)在想必你明白了為什么我們需要另一個(gè)版本的 HTTP 協(xié)議了。 HTTP/2 是專(zhuān)為了低延遲地內(nèi)容傳輸而設(shè)計(jì)。主要特點(diǎn)和與 HTTP/1.1 的差異包括：
- 使用二進(jìn)制替代明文
- 多路傳輸 - 多個(gè)異步 HTTP 請(qǐng)求可以使用單一連接
- 報(bào)頭使用 HPACK 壓縮
- 服務(wù)器推送 - 單個(gè)請(qǐng)求多個(gè)響應(yīng)
- 請(qǐng)求優(yōu)先級(jí)
- 安全性
1. 二進(jìn)制協(xié)議
HTTP/2 通過(guò)使其成為一個(gè)二進(jìn)制協(xié)議以解決 HTTP/1.x 中存在的延遲問(wèn)題。作為一個(gè)二進(jìn)制協(xié)議，它更容易解析，但可讀性卻不如 HTTP/1.x。幀(frames)和流(stream)的概念組成了 HTTP/2 的主要部分。
幀和流
現(xiàn)在 HTTP 消息是由一個(gè)或多個(gè)幀組成的。HEADERS 幀承載了元數(shù)據(jù)(meta data)，DATA 幀則承載了內(nèi)容。還有其他類(lèi)型的幀(HEADERS、DATA、RST_STREAM、SETTINGS、PRIORITY 等等)，這些你可以通過(guò) HTTP/2 規(guī)范來(lái)了解。
每個(gè) HTTP/2 請(qǐng)求和響應(yīng)都被賦予一個(gè)唯一的流 ID，并切分成幀。幀就是一小片二進(jìn)制數(shù)據(jù)。幀的集合稱(chēng)為流，每個(gè)幀都有個(gè)標(biāo)識(shí)了其所屬流的流 ID，所以在同一個(gè)流下的每個(gè)幀具有共同的報(bào)頭。值得注意的是，除了流 ID 是唯一的之外，由客戶(hù)端發(fā)起的請(qǐng)求使用了奇數(shù)作為流 ID，從來(lái)自服務(wù)器的響應(yīng)使用了偶數(shù)作為流 ID。
除了 HEADERS 幀和 DATA 幀，另一個(gè)值得一提的幀是 RST_STREAM。這是一個(gè)特殊的幀類(lèi)型，用來(lái)中止流，即客戶(hù)可以發(fā)送此幀讓服務(wù)器知道，我不再需要這個(gè)流了。在 HTTP/1.1 中讓服務(wù)器停止給客戶(hù)端發(fā)送響應(yīng)的唯一方法是關(guān)閉連接，這樣造成了延遲增加，因?yàn)橹笠l(fā)送請(qǐng)求時(shí)，就要必須打開(kāi)一個(gè)新的請(qǐng)求。而在 HTTP/2，客戶(hù)端可以使用 RST_STREAM 來(lái)停止接收特定的數(shù)據(jù)流，而連接仍然打開(kāi)著，可以被其他請(qǐng)求使用。
2. 多路傳輸
因?yàn)?HTTP/2 是一個(gè)二進(jìn)制協(xié)議，而且如上所述它使用幀和流來(lái)傳輸請(qǐng)求與響應(yīng)，一旦建立了 TCP 連接，相同連接內(nèi)的所有流都可以同過(guò)這個(gè) TCP 連接異步發(fā)送，而不用另外打開(kāi)連接。反過(guò)來(lái)說(shuō)，服務(wù)器也可以使用同樣的異步方式返回響應(yīng)，也就是說(shuō)這些響應(yīng)可以是無(wú)序的，客戶(hù)端使用分配的流 ID 來(lái)識(shí)別數(shù)據(jù)包所屬的流。這也解決了 HTTP/1.x 中請(qǐng)求管道被阻塞的問(wèn)題，即客戶(hù)端不必等待占用時(shí)間的請(qǐng)求而其他請(qǐng)求仍然可以被處理。
3. HPACK 請(qǐng)求頭部壓縮
RFC 花了一篇文檔的篇幅來(lái)介紹針對(duì)發(fā)送的頭信息的優(yōu)化，它的本質(zhì)是當(dāng)我們?cè)谕豢蛻?hù)端上不斷地訪(fǎng)問(wèn)服務(wù)器時(shí)，許多冗余數(shù)據(jù)在頭部中被反復(fù)發(fā)送，有時(shí)候僅僅是 cookies 就能增加頭信息的大小，這會(huì)占用許多寬帶和增加傳輸延遲。為了解決這個(gè)問(wèn)題，HTTP/2 引入了頭信息壓縮。
不像請(qǐng)求和響應(yīng)那樣，頭信息中的信息不會(huì)以 gzip 或者 compress 等格式壓縮。而是采用一種不同的機(jī)制來(lái)壓縮頭信息，客戶(hù)端和服務(wù)器同時(shí)維護(hù)一張頭信息表，儲(chǔ)存了使用了哈夫曼編碼進(jìn)行編碼后的頭信息的值，并且后續(xù)請(qǐng)求中若出現(xiàn)同樣的字段則忽略重復(fù)值(例如用戶(hù)代理(user agent)等)，只發(fā)送存在兩邊信息表中它的引用即可。
我們說(shuō)的頭信息，它們同 HTTP/1.1 中一樣，并在此基礎(chǔ)上增加了一些偽頭信息，如 :scheme，:host 和 :path。
4. 服務(wù)器推送
服務(wù)器推送是 HTTP/2 的另一個(gè)巨大的特點(diǎn)。對(duì)于服務(wù)器來(lái)說(shuō)，當(dāng)它知道客戶(hù)端需要一定的資源后，它可以把數(shù)據(jù)推送到客戶(hù)端，即使客戶(hù)端沒(méi)有請(qǐng)求它。例如，假設(shè)一個(gè)瀏覽器在加載一個(gè)網(wǎng)頁(yè)時(shí)，它解析了整個(gè)頁(yè)面，發(fā)現(xiàn)有一些內(nèi)容必須要從服務(wù)端獲取，然后發(fā)送相應(yīng)的請(qǐng)求到服務(wù)器以獲取這些內(nèi)容。
服務(wù)器推送減少了傳輸這些數(shù)據(jù)需要來(lái)回請(qǐng)求的次數(shù)。它是如何做到的呢?服務(wù)器通過(guò)發(fā)送一個(gè)名字為 PUSH_PROMISE 特殊的幀通知到客戶(hù)端“嘿，我準(zhǔn)備要發(fā)送這個(gè)資源給你了，不要再問(wèn)我要了?！边@個(gè) PUSH_PROMISE 幀與要產(chǎn)生推送的流聯(lián)系在一起，并包含了要推送的流 ID，也就是說(shuō)這個(gè)流將會(huì)被服務(wù)器推送到客戶(hù)端上。
5. 請(qǐng)求優(yōu)先級(jí)
當(dāng)流被打開(kāi)的時(shí)候，客戶(hù)端可以在 HEADERS 幀中包含優(yōu)先級(jí)信息來(lái)為流指定優(yōu)先級(jí)。在任何時(shí)候，客戶(hù)端都可以發(fā)送 PRIORITY 幀來(lái)改變流的優(yōu)先級(jí)。
如果沒(méi)有任何優(yōu)先級(jí)信息，服務(wù)器將異步地?zé)o序地處理這些請(qǐng)求。如果流分配了優(yōu)先級(jí)，服務(wù)器將基于這個(gè)優(yōu)先級(jí)來(lái)決定需要分配多少資源來(lái)處理這個(gè)請(qǐng)求。
6. 安全性
在是否強(qiáng)制使用 TLS 來(lái)增加安全性的問(wèn)題上產(chǎn)生了大范圍的討論，討論的結(jié)果是不強(qiáng)制使用。然而大多數(shù)廠(chǎng)商只有在使用 TLS 時(shí)才能使用 HTTP/2。所以 HTTP/2 雖然規(guī)范上不要求加密，但是加密已經(jīng)約定俗成了。這樣，在 TLS 之上實(shí)現(xiàn) HTTP/2 就有了一些強(qiáng)制要求，比如，TLS 的***版本為 1.2，必須達(dá)到某種級(jí)別的***限度的密鑰大小，需要布署 ephemeral 密鑰等等。
到現(xiàn)在 HTTP/2 已經(jīng)完全超越了 SPDY，并且還在不斷成長(zhǎng)，HTTP/2 有很多關(guān)系性能的提升，我們應(yīng)該開(kāi)始布署它了。
如果你想更深入的了解細(xì)節(jié)，請(qǐng)?jiān)L問(wèn)該規(guī)范的鏈接和 HTTP/2 性能提升演示的鏈接。請(qǐng)?jiān)诹粞园鍖?xiě)下你的疑問(wèn)或者評(píng)論，***如果你發(fā)現(xiàn)有錯(cuò)誤，請(qǐng)同樣留言指出。
這就是全部了，我們之后再見(jiàn)~
新聞名稱(chēng)：每一個(gè)web開(kāi)發(fā)者都應(yīng)該了解的HTTP/2
當(dāng)前網(wǎng)址：http://fisionsoft.com.cn/article/cdchjpo.html
