詳解HTTP協議

1、HTTP簡介

1.HTTP

HTTP:超文本傳輸協議，是一種通訊協議；容許超文本標記文檔從Web服務器傳送到客戶端的瀏覽器中。

簡單：傳輸html文件的協議。

Web：是一種基於超文本和HTML的、全球性的、動態交互的、跨平臺的分佈式圖形信息系統。

http是無狀態協議，這保證了它的高效。Cookie和Section的出現使http在保持高效的狀況下，可以記住狀態；

2.URI與URL

• URI可分爲URL，URN或同時具有locators 和 names特性的東西；
• URN的做用就好像一我的的名字，URL就像這我的的地址；
• 換句話說：URN肯定了東西的身份，URL提供了找到它的方式；

URL是URI的一種，不是全部的URI都是URL；URI惟一地標識了身份，URL給出了訪問機制（http/ftp/telnet等）

2、狀態碼

1xx：接收的請求正在處理

2xx：請求正常處理完畢

狀態碼	狀態碼英文名稱	描述
200	OK	請求已成功，請求所但願的響應頭或數據體將隨此響應返回
202	Accepted	已接受，已經接受請求，但未處理完成
204	No Content	請求處理成功，可是返回的響應報文中不包含實體的主體部分
206	Partial Content	該狀態碼錶示客戶端進行了範圍請求， 而服務器成功執行了這部分的 GET 請求。 響應報文中包含由 Content-Range 指定範圍的實體內容。

3xx：重定向

狀態碼	狀態碼英文名稱	描述
301	Moved Permanently	永久重定向，請求的資源已被永久的移動到新的URI，返回信息會包括新的URI，瀏覽器會自動定向到新的URI。從此任何新的請求都會使用新的URI（好比某的網站域名已更改，訪問舊網址會自動跳轉到網址）
302	Found	暫時重定向，與301相似。但資源只是臨時被移動，客戶端應繼續使用原有的URI
303	See Other	該狀態碼錶示因爲請求對應的資源存在着另外一個 URI， 應使用 GET 方法定向獲取請求的資源。與302區別在於303但願用戶使用GET訪問新的URI，而302能夠使用POST訪問新的URI
304	Not Modified	該狀態碼錶示客戶端發送附帶條件時（If-Match， If-ModifiedSince等）， 服務器端容許請求訪 問資源， 但未知足附帶的條件。 此時返回，304 狀態碼， 不包含任何響應 的主體部分。另外一種理解：所請求的資源沒有更改，能夠使用緩存

4xx：客戶端錯誤

狀態碼	狀態碼英文名稱	描述
400	Bad Request	客戶端請求報文語法錯誤，服務器沒法理解
401	Unauthorized	表示發送的請求須要有經過HTTP認證（BASIC 認證、 DIGEST 認證） 的認證信息
403	Forbidden	服務器理解客戶端的請求，可是拒絕執行此請求
404	Not Found	服務器沒法根據客戶端的請求找到資源（網頁）

5xx：服務器錯誤

狀態碼	狀態碼英文名稱	描述
500	Internal Server Error	服務器端內錯誤或 Web 應用存在bug或某些臨時的故障，致使沒法完成請求
502	Bad Gateway	充當網關或代理的服務器，從遠端服務器接收到了一個無效的請求
503	Service Unavailable	代表服務器暫時處於超負載或正在進行停機維護， 如今沒法 處理請求

3、HTTP首部

1.HTTP請求和響應報文

1.1HTTP請求報文

1.2.HTTP響應報文

可見HTTP報文一共有四種首部字段（請求頭）：請求首部字段、響應首部字段、通用首部字段、實體首部字段；

1.3.示例

在chrome的開發者調試工具當中，從請求報文和響應報文分各抽出了一部分，造成了三部分：

General：

Request Headers：

Response Headers：

2.請求首部字段

2.1.Accept

做用：瀏覽器端能夠接受的媒體類型；

若想要給顯示的媒體類型增長優先級， 則使用 q來額外表示權重值，用分號（;）進行分隔。權重值 q 的範圍是 0~1（可精確到小數點後 3 位） ，且1爲最大值。不指定權重 q 值時，默認權重爲 q=1.0。

當服務器提供多種內容時，將會首先返回權重值最高的媒體類型。

2.2.Accept-Charset

做用：用來通知服務器用戶代理（瀏覽器）支持的字符集及字符集的相對優先順序。

圖Accept-Charset字段中的值：

Accept-Charset： iso-8859-5, unicode-1-1;q=0.8

中的unicode-1-1;q=0.8是一個總體，表示unicode編碼優先級爲0.8，小於默認的iso編碼優先級（默認q=1）；不要覺得分號（；）爲分割符，其實逗號（，）纔是分割符

2.3.Accept-Encoding

做用：用來告知服務器用戶代理支持的內容編碼及內容編碼的優先級順序。 可一次性指定多種內容編碼。

Accept-Encoding: gzip, deflate

常見的編碼方式有：gzip、compress、deflate、identity。

2.4.Accept-Language

做用：用來告知服務器瀏覽器可以接收的語言 ，以及相對優先級。

Accept-Language: zh-cn,zh;q=0.7,en-us,en;q=0.3

上述值表示：優先請求中文版，其次是英文版；

2.5.Host

Host: www.hackr.jp

若服務器未設定主機名，Host爲空值便可。

2.6.If-Match

形如If--xxx這種樣式的請求首部字段，均可稱爲條件請求。服務器接收到附帶條件的請求後，只有判斷指定條件爲真時，纔會執行請求。

上圖表示：只有當If-Match的字段值跟Etag值匹配一致時，服務器纔會接收請求。

2.7.If-Modified-Since

上圖表示：若是在If-Modified-Since字段指定的日期時間後，資源發生了更新，服務器會接收請求，此時返回狀態碼200；不然會拒絕接收請求返回304（由於資源都沒更新過，不須要從新請求），與響應頭Last-Modified是一對；

2.8.If-None-Match

只有在 If-None-Match 的字段值與 ETag 值不一致時， 可處理該請求。 與 If-Match 首部字段的做用相反；

2.9.If-Range

首部字段 If-Range 屬於附帶條件之一。 它告知服務器若指定的 If-Range 字段值（ETag 值或者時間） 和請求資源的 ETag 值或時間相一致時， 則做爲範圍請求處理。 反之， 則返回全體資源。

下面咱們思考一下不使用首部字段 If-Range 發送請求的狀況。 服務器端的資源若是更新， 那客戶端持有資源中的一部分也會隨之無效，固然，範圍請求做爲前提是無效的。這時，服務器會暫且以狀態碼 412:Precondition Failed 做爲響應返回， 其目的是催促客戶端再次發送請求。這樣一來，與使用首部字段 If-Range 比起來，就須要花費兩倍的功夫。

2.10.Referrer

做用：告訴服務器我是從哪一個頁面的連接過來的，服務器籍此能夠得到一些信息用於處理；

Referer: http://www.hackr.jp/index.htm

2.11.User-Agent

做用：告訴HTTP服務器，客戶端使用的操做系統和瀏覽器的名稱和版本；

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/2010010

不少時候咱們會經過該字段來判斷瀏覽器類型，從而進行不一樣的兼容性設計。

3.響應首部字段

3.1.Age

首部字段 Age 能告知客戶端，源服務器在多久前建立了響應。字段值的單位爲秒。

3.2.ETag

首部字段 ETag 能告知客戶端實體標識。它是一種可將資源以字符串形式作惟一性標識的方式。服務器會爲每份資源分配對應的 ETag值。
另外， 當資源更新時，ETag 值也須要更新。生成 ETag 值時，並無統一的算法規則，而僅僅是由服務器來分配。

與響應頭If-None-Match是一對；

3.3.Location

使用首部字段 Location 能夠將響應接收方引導至某個與請求 URI 位置不一樣的資源。 基本上，該字段會配合 3xx ： Redirection 的響應， 提供重定向的URI。

4.通用首部字段

4.1.Cache-Control

a.請求首部中Cache-Control的指令：

b.響應首部中Cache-Control的指令：

Cache-Control各指令詳解：

• public指令：客戶端和代理服務器（CDN）能夠緩存；

• Private指令：只有客戶端能夠緩存；

• no-store指令：真正意義上的全部內容都不緩存；

• no-cache指令：正確來講該指令仍是會使用緩存，只不過使用前要確認其新鮮程度（協商緩存）；

• **s-maxage = x指令 **:代理服務器請求源站緩存後的X秒內再也不發出請求，只對CDN緩存（CDN指的是擁有源服務器資源的多個分佈式服務器）有效；

Cache-Control: s-maxage=604800 //（單位 ： 秒）

此外，當使用 s-maxage 指令後，則直接忽略對 Expires 首部字段及max-age 指令的處理。 即優先級爲：S-maxage > Max-age > Expires

• Max-age = x指令：請求緩存後的X秒內再也不發起請求。

Cache-Control: max-age=604800 //（單位： 秒）

當客戶端發送的請求中包含max-age指令時： 若是斷定指定的時間比緩存資源的緩存時間數值更大，那麼客戶端就接收緩存的資源。另外，當指定 max-age 值爲 0（指定時間更小），那麼緩存服務器一般須要將請求轉發給源服務器。

當服務器返回的響應中包含 max-age 指令時，緩存服務器將不對資源的有效性再做確認，而直接把 max-age 數值做爲保存爲緩存的資源的最長時效。

應用 HTTP/1.1 版本的緩存服務器遇到同時存在 Expires 首部字段的狀況時，會優先處理 max-age 指令，而忽略掉 Expires 首部字段。

4.2.Connection

有兩個做用：

• 控制再也不轉發給代理的首部字段：

如圖中，Connection的值爲Upgrade表示不將Upgrade這個首部發給代理；

• 管理持久鏈接：

a.當Connection ： close 時：

表明一個Request完成後，客戶端和服務器之間用於傳輸HTTP數據的TCP鏈接會關閉（四次揮手）。當客戶端再次發送Request，須要從新創建TCP鏈接（三次握手）。

b.當Connection：Keep-Alive 時：

此時，當一個網頁打開完成後（已經創建TCP鏈接），客戶端和服務器之間用於傳輸HTTP數據的TCP鏈接不會關閉，若是客戶端再次訪問這個服務器，會繼續使用這條已經創建的鏈接；

4.3.Via

使用首部字段Via是爲了追蹤客戶端與服務器之間的請求和響應報文的傳輸路徑：

5.實體首部字段

實體首部字段是包含在請求報文和響應報文中的實體部分所使用的首部，用於補充內容的更新時間等與實體相關的信息。

5.1.Content-Type

做用：說明報文內對象的媒體類型；

Content-Type: text/html; charset=UTF-8

5.2.Expires

首部字段 Expires 會將資源失效的日期告知客戶端。緩存服務器（代理服務器）在接收到含有首部字段 Expires 的響應後，會以緩存來應答請求，在Expires 字段值指定的時間以前，響應的副本會一直被保存。當超過指定的時間後，緩存服務器在請求發送過來時，會轉向源服務器請求資源。

源服務器不但願緩存服務器對資源緩存時， 最好在 Expires 字段內寫入與首部字段 Date 相同的時間值。

可是，當首部字段 Cache-Control 有指定 max-age 指令時，比起首部字段 Expires，會優先處理 max-age 指令。

5.3.Last-Modified

首部字段 Last-Modified 指明資源最終修改的時間。 與請求頭If-Modified-Since是一對；

Last-Modeified: Wed, 23 May 2012 09:59:55 GMT

6.爲 Cookie 服務的首部字段

Cookie的工做機制是用戶識別及狀態管理。Web 網站爲了管理用戶的狀態會經過 Web 瀏覽器，把一些數據臨時寫入用戶的計算機內。接着當用戶訪問該Web網站時，可經過通訊方式取回以前發放的Cookie;

調用 Cookie 時，因爲可校驗 Cookie 的有效期，以及發送方的域、路徑、協議等信息，因此正規發佈的 Cookie 內的數據不會因來自其餘Web 站點和攻擊者的攻擊而泄露。

爲 Cookie 服務的首部字段：

6.1.Set-Cookie字段

當服務器準備開始管理客戶端的狀態時，會事先告知各類信息。

Set-Cookie: status=enable; expires=Tue, 05 Jul 2011 07:26:31 GMT; path

**Set-Cookie 字段的屬性 **

• expires 屬性：

Cookie 的 expires 屬性指定瀏覽器可發送 Cookie 的有效期。當省略 expires 屬性時，其有效期僅限於維持瀏覽器會話（Session）時間段內。 這一般限於瀏覽器應用程序被關閉以前。

另外，一旦 Cookie 從服務器端發送至客戶端，服務器端就不存在能夠顯式刪除 Cookie 的方法。但可經過覆蓋已過時的 Cookie，實現對客戶端 Cookie 的實質性刪除操做。

• domain 屬性：

經過 Cookie 的 domain 屬性指定的域名可作到與結尾匹配一致。 好比，當指定 example.com 後，除 example.com 之外， www.example.com或 www2.example.com 等均可以發送 Cookie。

所以， 除了針對具體指定的多個域名發送 Cookie 之 外，不指定domain 屬性顯得更安全。

• secure 屬性：

Cookie 的 secure 屬性用於限制 Web 頁面僅在 HTTPS 安全鏈接時，才能夠發送 Cookie。

發送 Cookie 時，指定secure屬性的方法以下所示：

Set-Cookie: name=value; secure

以上例子僅當在https://www.example.com/（HTTPS）安全鏈接的狀況下才會進行 Cookie 的回收。也就是說， 即便域名相同，http://www.example.com/（HTTP） 也不會發生 Cookie 回收行爲。

當省略 secure 屬性時，不論 HTTP 仍是 HTTPS，都會對 Cookie 進行回收。

• HttpOnly 屬性：

Cookie 的 HttpOnly 屬性是 Cookie 的擴展功能，它使 JavaScript 腳本沒法得到 Cookie。 其主要目的爲防止跨站腳本攻擊（Cross-sitescripting， XSS） 對 Cookie 的信息竊取。

發送指定 HttpOnly 屬性的 Cookie 的方法以下所示。

Set-Cookie: name=value; HttpOnly

經過上述設置，一般從Web頁面內還能夠對 Cookie 進行讀取操做。但使用 JavaScript 的 document.cookie 就沒法讀取附加 HttpOnly 屬性後的Cookie的內容了。 所以，也就沒法在 XSS 中利用 JavaScript 劫Cookie 了。

6.2.Cookie字段

首部字段 Cookie 會告知服務器，當客戶端想得到 HTTP 狀態管理支持時， 就會在請求中包含從服務器接收到的 Cookie。 接收到多個Cookie 時，一樣能夠以多個 Cookie 形式發送。

Cookie: status=enable

4、HTTP請求方法

HTTP/1.1 的經常使用方法 ：

1.GET

GET 方法用來請求訪問已被 URI 識別的資源。指定的資源經服務器端解析後返回響應內容。

舉例：

GET方法也能夠用來提交表單和其餘數據：

http://localhost/login.php?username=aa&password=1234

從上面的請求URL中，很容易就能辨認出表單提交的內容。HTTP0.9的時候只有GET方法，因此GET方法既能獲取數據，也能提交數據，只不過提交的數據是拼接在URL後的不能提交太多且不安全；提交大量數據時使用POST方法。

2.POST

• POST方法功能與GET方法相似，是GET方法的延伸，主要用於向服務器提交數據量較大的用戶表單數據；

• 提交的數據放在請求報文的主體中，保證了提交數據的安全；這樣就克服了GET方法提交的數據量過小和不能保密的缺點。

• POST方法的主要目的並非獲取響應主體的內容；

3.PUT

• PUT方法用來傳輸文件。 就像 FTP 協議的文件上傳同樣， 要求在請求報文的主體中包含文件內容， 而後保存到請求URI指定的位置。

• PUT方法和POST很類似，最大的不一樣是：PUT是冪等的，POST是不冪等的。 即建立文件使用POST更新文件使用PUT；

冪等：冪等操做的特色是其任意屢次執行所產生的影響均與一次執行的影響相同；

• 可是， 鑑於·HTTP/1.1 的 PUT 方法自身不帶驗證機制， 任何人均可以上傳文件 , 存在安全性問題， 所以通常的 Web 網站不使用該方法。

4.HEAD

HEAD 方法只獲取響應報文首部，不返回報文主體部分。 用於確認URI （超連接）的有效性及資源更新的日期時間等。 例如：

5.DELETE

• DELETE 方法用來刪除文件，是與 PUT 相反的方法。DELETE 方法按請求 URI 刪除指定的資源。

• 可是，HTTP/1.1 的 DELETE 方法自己和 PUT 方法同樣不帶驗證機制，因此通常的 Web 網站也不使用 DELETE 方法。(怎麼可能讓人隨便rm -rf) 舉例：

6.OPTIONS

OPTIONS 方法用來查詢針對請求 URI 指定的資源支持的方法。

示例：

7.TRACE

• 客戶端經過 TRACE 方法能夠查詢發送出去的請求是怎樣被加工修改/ 篡改的。 這是由於， 請求想要鏈接到源目標服務器可能會經過代理中轉， TRACE 方法就是用來確認鏈接過程當中發生的一系列操做。

• 可是， TRACE 方法原本就不怎麼經常使用， 再加上它容易引起XST（Cross-Site Tracing， 跨站追蹤） 攻擊， 一般就更不會用到了。

• 發送請求時， 在 Max-Forwards 首部字段中填入數值， 每通過一個服務器端就將該數字減 1， 當數值恰好減到 0 時， 就中止繼續傳輸， 最後接收到請求的服務器端則返回狀態碼200 OK的響應。

示例：

//請求
TRACE / HTTP/1.1
Host: hackr.jp
Max-Forwards: 2

響應：
HTTP/1.1 200 OK
Content-Type: message/http
Content-Length: 1024

TRACE / HTTP/1.1
Host: hackr.jp
Max-Forwards: 2（返回響應包含請求內容）

8.CONNECT

CONNECT 方法要求在與代理服務器通訊時創建隧道， 實現用隧道協議進行 TCP 通訊。 主要使用 SSL（Secure Sockets Layer， 安全套接層） 和 TLS（Transport Layer Security， 傳輸層安全） 協議把通訊內容加 密後經網絡隧道傳輸。

//格式
CONNECT 代理服務器名:端口號 HTTP版本

//例子
//請求
CONNECT proxy.hackr.jp:8080 HTTP/1.1
Host: proxy.hackr.jp

//響應
HTTP/1.1 200 OK（以後進入網絡隧道）

5、HTTP狀態管理

Cookie和Session，實現了HTTP的狀態管理，Cookie是在客戶端的，Session是在服務器的。

1.Cookie

HTTP 是無狀態協議（高效率，不記仇），它不對以前發生過的請求和響應的狀態進行管理。也就是說，沒法根據以前的狀態進行本次的請求處理。

假設要求登陸認證的 Web 頁面自己沒法進行狀態的管理（不記錄已登陸的狀態） ，那麼每次跳轉新頁面不是要再次登陸，就是要在每次請求報文中附加參數來管理登陸狀態。

保留無狀態協議這個特徵的同時又要解決相似的矛盾問題，因而引入了Cookie技術。Cookie 技術經過在請求和響應報文中寫入Cookie信息來控制客戶端的狀態。

• Cookie其實是一小段文本信息。客戶端請求服務器，若是服務器須要記錄該用戶狀態，就向客戶端瀏覽器頒發一個Cookie；
• 客戶端瀏覽器會把Cookie保存起來。當瀏覽器再請求該網站時，瀏覽器把請求的網址連同該Cookie一同提交給服務器。服務器檢查該Cookie，以此來辨認用戶狀態。

在一個網站地址欄輸入：

javascript:alert(document.cookie)

能夠彈出該網站的Cookie信息：

Cookie 會根據從服務器端發送的響應報文內的一個叫作 Set-Cookie 的首部字段信息， 通知客戶端保存Cookie。當下次客戶端再往該服務器發送請求時， 客戶端會自動在請求報文中加入 Cookie 值後發送出去。

服務器端發現客戶端發送過來的Cookie後， 會去檢查到底是從哪個客戶端發來的鏈接請求， 而後對比服務器上的記錄， 最後獲得以前的狀態信息。

第一次：沒有 Cookie 信息狀態下的請求

• 請求報文（沒有 Cookie 信息的狀態）

• **響應報文（服務器端生成 Cookie 信息） **

第二次：存有 Cookie 信息狀態的請求

• **請求報文（自動發送保存着的 Cookie 信息） **

2.Session

• Session是另外一種記錄客戶狀態的機制，保存在服務器上。客戶端瀏覽器訪問服務器的時候，服務器把客戶端信息以某種形式記錄在服務器上；
• 客戶端瀏覽器再次訪問時只須要從該Session中查找該客戶的狀態就能夠了；

Cookie和Session很是類似，Cookie至關於客戶端持有的通行證，Session至關於服務器上的通行名冊。

保存Session ID的方式

• Cookie
• URL重寫
• 隱藏表單

Session的有效期

• Session超時失效：被動失效，若是超過規定時間沒有再次訪問服務器，Session將失效；
• 程序調用HttpSession.invalidate()：主動失效；
• 服務器進程被中止；

3.Token

Token的引入

Token是在客戶端頻繁向服務端請求數據，服務端頻繁的去數據庫查詢用戶名和密碼並進行對比，判斷用戶名和密碼正確與否，並做出相應提示，在這樣的背景下，Token便應運而生。

Token的定義

Token是服務端生成的一串字符串，以做客戶端進行請求的一個令牌，當第一次登陸後，服務器生成一個Token便將此Token返回給客戶端，之後客戶端只需帶上這個Token前來請求數據便可，無需再次帶上用戶名和密碼。最簡單的token組成:uid(用戶惟一的身份標識)、time(當前時間的時間戳)、sign(簽名，由token的前幾位+鹽以哈希算法壓縮成必定長的十六進制字符串，能夠防止惡意第三方拼接token請求服務器)。

使用Token的目的

Token的目的是爲了減輕服務器的壓力，減小頻繁的查詢數據庫，使服務器更加健壯。

Session管理及Cookie應用

• 步驟 1：客戶端把用戶 ID 和密碼等登陸信息放入報文的實體部分，一般是以 POST 方法把請求發送給服務器。而這時，會使用 HTTPS通訊來進行 HTML表單畫面的顯示和用戶輸入數據的發送。

• 步驟 2：服務器會發放用以識別用戶的 Session ID。經過驗證從客戶端發送過來的登陸信息進行身份認證， 而後把用戶的認證狀態與Session ID 綁定後記錄在服務器端。

  向客戶端返回響應時，會在首部字段Set-Cookie 內寫入 SessionID（如 PHPSESSID=028a8c…） 。

  爲防止Session ID 被第三方盜走，服務器端須要對其進行有效性管理；而且爲減輕跨站腳本攻擊（XSS） 形成的損失，建議事先在 Cookie內加上 httponly 屬性。

• 步驟 3： 客戶端接收到從服務器端發來的 Session ID 後，會將其做爲Cookie 保存在本地。下次向服務器發送請求時，瀏覽器會自動發送Cookie，因此 Session ID 也隨之發送到服務器。服務器端可經過驗證接收到的 Session ID 識別用戶和其認證狀態。

4.Cookie與Session的區別

• 存放位置不一樣：Cookie存放在客戶端，Session保存在服務器端；
• 安全性（隱私策略）不一樣：Cookie存儲在瀏覽器中，對客戶端是可見的，客戶端的一些程序可能會窺探或修改Cookie的內容；而Session存儲在服務器端，對客戶端來講是透明的；若是想要使用Cookie須要對其進行加密；
• 有效期上的不一樣：設置Cookie很大的過時時間，Cookie就能被瀏覽器保存很長時間；而服務器會按期清理超時的Session ID避免出現過大壓力；可是Session依賴於相似Session ID這樣的Cookie，而Cookie對Session ID過時時間默許爲-1。因此只要關閉了瀏覽器，即一次會話結束後，該Session就失效了；
• 對服務器形成的壓力不一樣：Session是保存在服務器端的，每一個用戶都產生一個Session，假如併發訪問的用戶十分多，會產生十分多的Sssion，耗費大量的內存；而Cookie保存在客戶端，不太佔用服務器的資源；

6、HTTP協議的身份認證

• BASIC認證（基本認證）
• DIGEST（摘要認證）
• SSL客戶端認證
• FormBase認證（基於表單認證）

1.BASIC認證

BASIC 認證的認證步驟 ：

• 步驟 1：當請求的資源須要BASIC認證時，服務器會隨狀態碼 401 Authorization Required，返回帶 WWW-Authenticate 首部字段的響應。該字段內包含認證的方式（BASIC）及Request-URI安全域字符（realm）。

• 步驟 2： 接收到狀態碼 401 的客戶端爲了經過 BASIC 認證， 須要將用戶 ID 及密碼發送給服務器。 發送的字符串內容是由用戶 ID 和密碼構成， 二者中間以冒號（:） 鏈接後，再通過 Base64 編碼處理。

  假設用戶 ID 爲 guest，密碼是 guest，鏈接起來就會造成 guest:guest 這樣的字符串。 而後通過 Base64 編碼，最後的結果便是Z3Vlc3Q6Z3Vlc3Q=。 把這串字符串寫入首部字段 Authorization 後，
  發送請求。

• 步驟 3： 接收到包含首部字段Authorization請求的服務器，會對認證信息的正確性進行驗證。 如驗證經過， 則返回一條包含 Request-URI資源的響應。

BASIC 認證雖然採用Base64編碼方式，但這不是加密處理。不須要任何附加信息便可對其解碼。換言之，因爲明文解碼後就是用戶 ID和密碼，在 HTTP 等非加密通訊的線路上進行 BASIC 認證的過程當中，若是被人竊聽，被盜的可能性極高。 所以並不經常使用。

2.DIGEST 認證

爲彌補·BASIC認證存在的弱點， 從 HTTP/1.1 起就有了 DIGEST 認證。 DIGEST 認證一樣使用質詢 / 響應的方式
（challenge/response），但不會像 BASIC 認證那樣直接發送明文密碼。

所謂質詢響應方式是指， 一開始一方會先發送認證要求給另外一方， 接着使用從另外一方那接收到的質詢碼計算生成響應碼。 最後將響應碼返回給對方進行認證的方式。

由於發送給對方的只是響應摘要及由質詢碼產生的計算結果，因此比起 BASIC 認證，密碼泄露的可能性就下降了。

**DIGEST 認證的認證步驟: **

• 步驟 1：請求需認證的資源時，服務器會隨着狀態碼 401:Authorization Required，返 迴帶 WWW-Authenticate 首部字段的響應。該字段內包含質問響應方式認證所需的臨時質詢碼（隨機數，nonce） 。
  首部字段 WWW-Authenticate 內必須包含 realm 和 nonce 這兩個字段的信息。客戶端就是依靠向服務器回送這兩個值進行認證的。

  nonce 是一種每次隨返回的 401 響應生成的任意隨機字符串。該字符串一般推薦由 Base64 編碼的十六進制數的組成形式，但實際內容依賴服務器的具體實現。

• 步驟 2： 接收到 401 狀態碼的客戶端，返回的響應中包含 DIGEST 認證必須的首部字段 Authorization 信息。

  首部字段 Authorization 內必須包含 username、 realm、 nonce、 uri 和response 的字段信息。其中，realm 和 nonce 就是以前從服務器接收到的響應中的字段。

• 步驟 3： 接收到包含首部字段 Authorization 請求的服務器，會確認認證信息的正確性。 認證經過後則返回包含 Request-URI 資源的響應。而且這時會在首部字段Authentication-Info寫入一些認證成功的相關信息。

DIGEST 認證提供了高於BASIC認證的安全等級，可是和 HTTPS 的客戶端認證相比仍舊很弱。 DIGEST 認證提供防止密碼被竊聽的保護機制，但並不存在防止用戶假裝的保護機制 。所以使用範圍不大。

3.SSL 客戶端認證

從使用用戶ID和密碼的認證方式方面來說，只要兩者的內容正確便可認證是本人的行爲。但若是用戶 ID 和密碼被盜，就頗有可能第三者冒充。利用 SSL客戶端認證則能夠避免該狀況的發生。

SSL客戶端認證是藉由 HTTPS 的客戶端證書完成認證的方式。憑藉客戶端證書認證，服務器可確認訪問是否來自已登陸的客戶端。

SSL 客戶端認證的認證步驟 :

爲達到 SSL客戶端認證的目的 須要事先將客戶端證書分發給客戶端，且客戶端必須安裝此證書。

• 步驟 1：接收到須要認證資源的請求，服務器會發送 Certificate Request 報文，要求客戶端提供客戶端證書。
• 步驟 2：用戶選擇將發送的客戶端證書後，客戶端會把客戶端證書信息以 Client Certificate 報文方式發送給服務器。

• 步驟 3： 服務器驗證客戶端證書驗證經過後方可領取證書內客戶端的165公開密鑰， 而後開始HTTPS加密通訊。

SSL 客戶端認證採用雙因素認證 :

• 在多數狀況下，SSL客戶端認證不會僅依靠證書完成認證，通常會和基於表單認證組合造成一種雙因素認證（Two-factorauthentication） 來使用。

• 換言之，第一個認證因素的 SSL客戶端證書用來認證客戶端計算機，另外一個認證因素的密碼則用來肯定這是用戶本人的行爲。

• 使用 SSL客戶端認證須要用到客戶端證書。而客戶端證書須要支付必定費用才能使用。

4.基於表單認證

• 基於表單的認證方法並非在HTTP協議中定義的；
• 使用由Web應用程序各自實現基於表單的認證方式；
• 經過Cookie和Session的方式來保持用戶的狀態（具體見上）；

也就是常見的登陸：

輸入已事先登陸的用戶 ID（一般是任意字符串或郵件地址） 和密碼等登陸信息後，發送給Web應用程序，基於認證結果來決定認證是否成功。

7、HTTP的長鏈接與短鏈接

HTTP協議是基於請求/響應模式的，所以只要服務端給了響應，本次HTTP請求就結束了；HTTP的長鏈接和短鏈接本質上是TCP的長鏈接和短鏈接；

1.短鏈接

完成一次通訊以後，客戶端主動斷開TCP鏈接；

HTTP/1.0中，默認使用的是短鏈接。也就是說，瀏覽器和服務器每進行一次HTTP操做，就創建一次鏈接（三次握手），結束就中斷（四次揮手）；

2.長鏈接

完成一次通訊以後，客戶端不主動斷開 TCP鏈接，而是複用該TCP鏈接；

HTTP/1.1起，默認使用長鏈接，用以保持鏈接特性。此時通用首部字段中的Connection字段值爲：Keep-Alive；

長鏈接適用於頻繁地傳輸數據的客戶端和服務器，爲了防止過多的TCP鏈接影響服務器性能，須要對長時間不用的鏈接進行釋放；

8、代理、網關與隧道

HTTP 通訊時，除客戶端和服務器之外，還有一些用於通訊數據轉發的應用程序，例如代理、網關和隧道。它們能夠配合服務器工做。

這些應用程序和服務器能夠將請求轉發給通訊線路上的下一站服務器，而且能接收從那臺服務器發送的響應再轉發給客戶端。

1.代理

代理服務器：

代理是一種有轉發功能的應用程序，它扮演了位於服務器和客戶端「中間人」的角色，接收由客戶端發送的請求並轉發給服務器，同時也接收服務器返回的響應並轉發給客戶端。

代理服務器的基本行爲就是接收客戶端發送的請求後轉發給其餘服務器。代理不改變請求 URI，會直接發送給前方持有資源的目標服務器。

持有資源實體的服務器被稱爲源服務器，從源服務器返回的響應通過代理服務器後再傳給客戶端。

每次經過代理服務器轉發請求或響應時，會追加寫入 Via 首部信息。

使用代理服務器的理由：

利用緩存技術（稍後講解）減小網絡帶寬的流量，組織內部針對特定網站的訪問控制（牆），以獲取訪問日誌爲主要目的，等等。

代理使用方法：

代理有多種使用方法，按兩種基準分類。一種是是否使用緩存，另外一種是是否會修改報文。

• **緩存代理 **

代理轉發響應時，緩存代理（Caching Proxy）會預先將資源的副本（緩存）保存在代理服務器上。當代理再次接收到對相同資源的請求時，就能夠不從源服務器那裏獲取資源，而是將以前緩存的資源做爲響應返回。

• **透明代理 **

轉發請求或響應時，不對報文作任何加工的代理類型被稱爲透明代理（Transparent Proxy）。反之，對報文內容進行加工的代理被稱爲非透明代理。

2.網關

網關是轉發其餘服務器通訊數據的服務器，接收從客戶端發送來的請求時，它就像本身擁有資源的源服務器同樣對請求進行處理。有時客戶端可能都不會察覺，本身的通訊目標是一個網關。

網關的工做機制和代理十分類似。可是Web網關在一側使用HTTP協議，在另外一側使用另外一種協議（好比FTP、SMTP）。

• （HTTP/）服務器端網關：經過HTTP協議與客戶端對話，經過其餘協議與服務器通訊；
• （/HTTP）客戶端網關：經過其餘協議與客戶端對話，經過HTTP協議與服務器通訊；

常見的網關類型：

• （HTTP/*）服務器端Web網關；

• （HTTP/HTTPS）服務器端安全網關：即客戶端用HTTP與網關通訊，網關用HTTPS與服務器通訊；

• （HTTPs/HTTP）客戶端安全加速器網關：即客戶端用HTTPs與網關通訊，網關用HTTP與服務器通訊；

  也就是安全網關，將經過網關的不安全的HTTP轉換爲安全的HTTPS;

• 資源網關：客戶端經過HTTP鏈接到應用程序的服務器，服務器並不回送文件，而是將請求經過網關API發送給運行在服務器上的應用程序，應用程序將請求資源會送給客戶端。這樣的客戶端多是一些網絡攝像頭，電子識別系統等；

利用網關能提升通訊的安全性，由於能夠在客戶端與網關之間的通訊線路上加密以確保鏈接的安全。好比，網關能夠鏈接數據庫，使用SQL語句查詢數據。另外，在 Web 購物網站上進行信用卡結算時，網關能夠和信用卡結算系統聯動。

3.隧道

隧道可按要求創建起一條與其餘服務器的通訊線路，屆時使用 SSL等加密手段進行通訊。隧道的目的是確保客戶端能與服務器進行安全的通訊。

隧道自己不會去解析 HTTP 請求。也就是說，請求保持原樣中轉給以後的服務器。隧道會在通訊雙方斷開鏈接時結束。

經過隧道的傳輸，能夠和遠距離的服務器安全通訊。隧道自己是透明的，客戶端不用在乎隧道的存在。

9、HTTP緩存

緩存是指代理服務器或客戶端本地磁盤內保存的資源副本。利用緩存可減小對源服務器的訪問，所以也就節省了通訊流量和通訊時間。

緩存服務器是代理服務器的一種，並歸類在緩存代理類型中。換句話說，當代理轉發從服務器返回的響應時，代理服務器將會保存一份資源的副本。

緩存服務器的優點在於利用緩存可避免屢次從源服務器轉發資源。所以客戶端可就近從緩存服務器上獲取資源， 而源服務器也沒必要屢次處理相同的請求了。

1.緩存的有效期限

即使緩存服務器內有緩存，也不能保證每次都會返回對同資源的請求。由於這關係到被緩存資源的有效性問題。
當趕上源服務器上的資源更新時，若是仍是使用不變的緩存，那就會演變成返回更新前的「舊」資源了。

即便存在緩存，也會由於客戶端的要求、緩存的有效期等因素，向源服務器確認資源的有效性。若判斷緩存失效， 緩存服務器將會再次從源服務器上獲取「新」資源。

2.客戶端的緩存

緩存不只能夠存在於緩存服務器內，還能夠存在客戶端瀏覽器中。以Internet Explorer 程序爲例，把客戶端緩存稱爲臨時網絡文件（Temporary Internet File）；

瀏覽器緩存若是有效，就沒必要再向服務器請求相同的資源了，能夠直接從本地磁盤內讀取；

另外，和緩存服務器相同的一點是， 當斷定緩存過時後， 會向源服務器確認資源的有效性。若判斷瀏覽器緩存失效，瀏覽器會再次請求新資源。

10、HTTP緩存的工做方式（強制緩存與協商緩存）

1.場景一

讓服務器與瀏覽器約定一個文件過時時間——Expires

在Expires沒有過時的狀況下，客戶端（瀏覽器）發出請求時，直接使用HTTP本地緩存並返回狀態碼200，這種HTTP工做方式稱爲強制緩存；

2.場景二

讓服務器與瀏覽器在約定文件過時時間Expires的基礎上，再加一個文件最新修改時間的對比——Last-Modified與if-Modified-Since

• 狀況1：若是Expires沒有過時，瀏覽器直接使用HTTP本地緩存，即採用強制緩存；
• 狀況2：若是Expires過時了，那麼瀏覽器在請求服務器的時候，就帶上了文件最新修改時間，這個字段是在請求頭裏面加上了If-Modified-Since字段，其實該字段的值就是上次請求時服務器返回的Last-Modified字段的值；服務器會把請求頭裏文件的最新修改時間If-Modified-Since的值與服務器上的文件最新修改時間Last-Modified的值進行比較：
  • 若是If-Modified-Since 不等於Last-Modified，說明瀏覽器緩存的資源（f.js）發生改變，服務器就會去查找最新的f.js，同時再次返回Expires、f.js、Last-Modified，返回的狀態碼爲200;
  • 若是If-Modified-Since 等於Last-Modified，說明瀏覽器緩存的資源（f.js）沒有發生改變，瀏覽器能夠繼續使用HTTP本地緩存，此時服務器返回狀態碼304；這種方式稱爲協商緩存

3.場景三

讓服務器在過時時間Expires+Last-Modified的基礎上，增長一個文件惟一標識Etag與If-None-Match配成一對使用；除此以外，Expires不穩定，再加入一個Max-age來加以替代（Max-age優先級更高）；

• 在60s內，瀏覽器再也不向服務器發起請求，直接使用本地緩存這與Expires類似。
• 60s後：瀏覽器帶上If-Modified-Since和If-None-Match（也就是上次服務器返回的Etag值）發起請求，服務器會對比If-None-Match與服務器端的Etag值，這時即便瀏覽器也提供了If-Modified-Since也不會再與Last-Modified進行對比，由於Etag的優先級比Last-Modified高（更精準）；
  • 若是If-None-Match不等於Etag，說明f.js文件已被修改，服務器就會返回最新的f.js和全新的Etag與Max-age（好比60），固然也會順便把Expires與Last-Modified返回（儘管沒用）；返回的狀態碼爲200；
  • 若是If-None-Match等於Etag，說明f.js文件沒有被修改，這時服務器返回的狀態碼爲304，告訴瀏覽器繼續使用原來的本地緩存。這種方式屬於協商緩存；

有了Last-Modified爲何還要用Etag呢？

你可能會以爲使用Last-Modified已經足以讓瀏覽器知道本地的緩存副本是否足夠新，爲何還須要Etag呢？HTTP1.1中Etag的出現主要是爲了解決幾個Last-Modified比較難解決的問題：

• 一些文件也許會週期性的更改，可是他的內容並不改變(僅僅改變的修改時間)，這個時候咱們並不但願客戶端認爲這個文件被修改了，而從新GET；
• 某些文件修改很是頻繁，好比在秒如下的時間內進行修改，(比方說1s內修改了N次)，If-Modified-Since能檢查到的粒度是s級的，這種修改沒法判斷（好比淘寶每ms都會更新數據）；
• 某些服務器不能精確的獲得文件的最後修改時間；

這時，利用Etag可以更加準確的控制緩存，由於Etag是服務器自動生成或者由開發者生成的對應資源在服務器端的惟一標識符。 Last-Modified與ETag是能夠一塊兒使用的，服務器會優先驗證ETag，一致的狀況下，纔會繼續比對Last-Modified，最後才決定是否返回304。

4.強制緩存與協商緩存

強制緩存：直接使用HTTP本地緩存，此時服務器返回狀態碼200；

協商緩存：向服務器確認HTTP本地緩存的資源是否發生變化，沒變化後再使用HTTP本地緩存，此時服務器返回狀態碼304；資源發生變化直接返回最新資源，狀態碼爲200；能夠這樣理解凡是返回304狀態碼，都屬於協商緩存；

強緩存和協商緩存的區別：

緩存	獲取資源形式	狀態碼	發送請求到服務器
強緩存	從緩存讀取	200（From Cache）	否，直接從緩存讀取
協商緩存	從緩存讀取	304（Not Modified）	是，經過服務器告知瀏覽器緩存是否可用

請求頭Cache-Control的值爲no - cache時表示瀏覽器會先向服務器確認緩存的新鮮度，再決定是否使用緩存，屬於協商緩存。

5.緩存改進方案

上述的緩存方案存在一個問題：當Expires或Max-age沒有過時時，瀏覽器沒法主動確認本地緩存是否發生變化；

5.1.md5/hash緩存

經過不緩存html，爲靜態文件添加MD5或者hash標識，解決瀏覽器沒法跳過緩存過時時間主動感知文件變化的問題；具體過程爲：第一次加載靜態文件時，某位置指定加載f-hash1.js，第二次加載靜態文件時同一個位置指定加載f-hash2.js，此時瀏覽器就會從新向服務器請求數據了；

5.2.CDN緩存（最經常使用）

CDN是構建在網絡之上的內容分發網絡，依靠部署在各地的邊緣服務器，經過中心平臺的負載均衡、內容分發、調度等功能模塊，使用戶就近獲取所需內容，下降網絡擁塞，提升用戶訪問響應速度和命中率；

好比能夠把CDN理解爲各個城市的快遞分發站點，源服務器看做快遞總倉庫；

CDN緩存工做方式：

• 第一次緩存：

• 後續請求：

CDN節點會代替服務器處理瀏覽器的請求，會有幾種狀況：

• 狀況一：CDN節點緩存的文件還沒過時，因而返回304給瀏覽器，瀏覽器這次請求被攔截（協商緩存）；
• 狀況二：CDN節點發現本身緩存的文件過時了，爲了保險起見本身發送請求給服務器成功拿回了最新的數據，而後再交還給瀏覽器；

能夠發現，CDN緩存問題與HTTP緩存是同樣的。只不過CDN緩存不過時瀏覽器始終被攔截，沒法拿到最新的文件；另外的不一樣點在於CDN至關於一個平臺能夠手動登陸更新緩存，這也就變相解決了不能控制HTTP本地緩存的問題。

6.瀏覽器操做對HTTP緩存的影響

用戶操做	Expires/Cache-Control	Last-Modified/Etag
地址欄回車	有效	有效
頁面連接跳轉	有效	有效
新開窗口	有效	有效
前進、後退	有效	有效
F5刷新	無效	有效
Ctrl + F5刷新	無效	無效

由上表可知：對於Last-Modified和Etag字段來講，只有在進行Ctrl + F5強制刷新時，這兩個字段對緩存是否有效的控制纔會失效。即強制刷新後，瀏覽器不會使用本地緩存，而是直接向服務器發起請求。

11、內容協商機制

指客戶端和服務器端就響應的資源內容進行交涉，而後提供給客戶端最爲合適的資源。內容協商會以響應資源的語言，字符集，編碼方式等做爲判斷的基準。

有三種方式：

• 客戶端驅動

由客戶端發起請求，服務器發送可選項列表，客戶端做出選擇後在發送第二次請求；

• 服務器驅動

服務器檢查客戶端的請求頭部集並決定提供哪一個版本的頁面；

• 透明協商

某個中間設備（一般是緩存代理）表明客戶端進行協商；

1.服務器驅動

服務器驅動內容協商：請求首部集；

• Accept：告知服務器發送何種媒體類型；
• Accept-Language：告知服務器發送何種語言；
• Accept-Charset：告知服務器發送何種字符集；
• Accept-Encoding：告知服務器採用何種編碼；

服務器驅動內容協商：實體首部集；

• Content-Type
• Content-Language
• Content-Type
• Content-Encoding

與請求首部集一一對應；

12、斷點續傳和多線程下載

HTTP是經過在Header裏兩個參數實現的，客戶端發出請求時對應的是Range，服務器端響應時對應的是Content-Range，若是續存成功返回206，若是文件有變更返回200和新文件的內容；

1.Range

用於請求頭中，指定第一個字節的位置和最後一個字節的位置，格式爲：

//格式（左開右閉）
Range:(unit = first byte pos) - [last byte pos]

//示例
Range: bytes=5001-10000

接收到附帶 Range 首部字段請求的服務器，會在處理請求以後返回狀態碼爲 206 Partial Content 的響應。 沒法處理該範圍請求時，則會返回狀態碼 200 OK 的響應及所有資源。

斷點續傳過程

• 1.客戶端下載一個1024K的文件，已經下載了其中的512K。

• 2.網絡中斷，客戶端請求續傳，所以須要在HTTP頭中申明本次須要續傳的片斷： Range:bytes=512000~這個頭通知服務器端從文件的512K位置開始傳輸文件；

• 3.服務器收到斷點續傳請求，從文件的512K開始傳輸，而且在HTTP頭中增長：

  Content-Range:bytes 512000-/1024000

  而且此時服務端返回的HTTP狀態碼應該是206 Partial Content，而不是200；

十3、HTTPS

HTTPS使用的是TSL協議（SSL是TSL協議的一種）；

1.HTTPS的功能

• 內容加密
  • 非對稱密鑰加密：傳輸公鑰時可能被截獲並掉包，解決方案：使用第三方機構頒發的證書加密公鑰（根據服務器地址等多個信息生成，沒法被第三方僞造），瀏覽器收到後使用證書機構頒發的公鑰進行解密（前提是瀏覽器要信任同一個證書頒發機構）解密結果與用證書生成的規則再生成一個簽名對比一致就是真證書；
  • 對稱密鑰加密：中間人隨意截獲
• 身份認證
  • 數字證書
• 數據完整性

2.HTTPS的使用成本

HTTPS是一個大趨勢

• 證書費用以及更新維護

  • 證書如今不貴，也有免費的；

• HTTPS下降用戶訪問速度

  • 通過合理的優化（好比SPDY）和部署甚至能夠比HTTP1.0快，不過這也是成本之一就是了；

• 消耗CPU資源，須要增長大量機器

  • 須要屢次計算

3.HTTPS對性能的影響

• 協議交互所增長的網絡RTP（往返時延）
• 加解密相關計算的耗時

網絡耗時：
HTTP只須要經過TCP的三次握手就能創建HTTP鏈接：

而HTTPS除了TCP的三次握手外，甚至還須要耗費額外的7個RTP進行驗證

關於302自動跳轉，這是由於，好比訪問百度，咱們輸入網址全稱而是輸入baidu.com，因此會自動跳轉至HTTPS，這自己也須要耗時；

而且跳轉後，URI不同了，瀏覽器要與服務器從新經過三次握手創建TCP鏈接；

以後還要進行TLS協商，好比密鑰交換算法，對稱加密算法，內容一致性校驗算法，證書籤名算法等等；瀏覽器獲取到證書後，也須要校驗證書的有效性，好比證書是否過時，是否撤銷等等；

接着，瀏覽器首先獲取證書裏的CA域名若是該CA域名沒有命中緩存，瀏覽器須要解析域名的DNS，這個DNS解析至少耗費一個RTP；

DNS解析到IP以後就要完成三次握手，創建CA站點的TCP鏈接，這又耗費一個RTP；

再接着瀏覽器發送OCSP請求，獲取響應耗費一個RTP；

關於OCSP：在線證書狀態協議，它是維護服務器和其餘網絡資源安全性的兩種廣泛模式之一，另一個叫作CRL證書註銷列表；當用戶試圖訪問一個服務器的時候，在線證書狀態協議發送一個對於證書狀態信息的請求，服務器會回覆一個有效、過時、未知的響應；協議規定了服務器和客戶端應用程序通訊的語法；在線證書協議給了用戶到期證書一個寬限期，這樣用戶就能夠在更新證書前的一段時間繼續訪問服務器，因此這裏就須要發起一個對於證書狀態的請求，也須要消耗一個RTP

最後就是TLS徹底握手階段2，這個階段主要進行密鑰協商，耗時一個RTP；隨後進行應用層的TCP數據通訊。

計算耗時

• 瀏覽器計算耗時；
• 服務器計算耗時；

4.HTTPS常見問題

• HTTPS須要安裝證書

• 大型網站好比百度，從HTTP升級爲HTTPS比較困難（不能由於升級而下降用戶體驗這樣就本末倒置了）

• HTTPS並不能解決全部安全問題（好比XSS攻擊，木馬等），只是能更加安全的傳輸數據

5.影響HTTP網絡請求的因素

• 帶寬
• 延遲
  • 一條鏈接上只可發送一個請求；
  • 請求只能從客戶端開始，客戶端不能夠接收除響應之外的指令；
  • 請求/響應頭部不經壓縮就發送，每次互相發送相同的頭部形成的浪費不少；
  • 非強制壓縮發送；

十4、WebSocket

能夠理解爲WebSocket是爲了讓HTTP支持長鏈接而打的一個大補丁；

WebSocket是一個持久化的HTTP，而HTTP自己是非持久化的以下圖所示：（雖然有Keep-Alive）

1.WebSocket的握手

請求：

響應：

Upgrade：表示升級爲WebSocket

2.WebSocket的做用

HTTP的瓶頸

請求只能從客戶端發起，客戶端不能夠接收除了響應以外的指令；當客戶端須要監聽服務器上的內容時，在HTTP中有一些優化處理方式，經常使用的用：Ajax輪詢，Long Poll

• Ajax輪詢

原理爲，客戶端每隔幾秒就發送一次請求，詢問服務器到底有沒有新消息；如有服務器返回新消息，沒有就返回提示信息，如此循環：

• Long Poll長輪詢

與Ajax輪詢原理類似，客戶端先發出請求，直到服務器上有新數據返回以前，都再也不發送請求，如此循環：

缺陷：兩種方式都很是消耗資源，Ajax輪詢須要服務器有很快地處理速度；Long Poll須要服務器有很大容量；

• 異常狀況

WebSocket解決上上述問題

首先使用HTTP協議通知服務器升級到WebSocket協議，隨後在WebSocket協議中，服務器端是能夠主動推送數據給客戶端的，詳細過程：

WebSocket的特色

相比於HTTP的長鏈接，WebSocket具備如下特色

• 真正的全雙工方式：服務器能夠主動推送，HTTP的長鏈接仍然是客戶端主動發起請求的；

• 減小通訊量：不須要重複傳輸HTTP Header等信息；

• 持久性鏈接：只要進行一次HTTP鏈接，二者就能建立持久的WebSocket鏈接；

十5、SPDY

SPDY是HTTP的加強，在向下兼容的狀況下，在TLS層上新增一層會話層SPDY，使用這個會話層來實現SPDY協議，也就是說現有的服務格式均不用改變嗎；SPDY是對HTTP的一個更好的實現和支持；

1.HTTP的缺陷

• 單路鏈接，請求低效：最大的弊端所在：每一個TCP鏈接只能對應一個HTTP請求；也就是每一個HTTP請求只能請求一個資源；瀏覽器只能經過創建多個鏈接來解決低效問題。
• 對請求嚴格的先進先出：若是中間的某個請求處理時間比較長的話，就會阻塞後面的請求；
• 只容許由客戶端主動發起請求：客戶端只能接收服務器發出的響應，服務器沒法主動推送信息；
• HTTP的頭部冗餘：HTTP的頭在一個會話裏是反覆傳送的，中間的冗餘信息好比：User-Agent、Host的等不須要重複發送的信息也在不斷地重複發送，浪費帶寬和資源；

2.SPDY的改進

因此基於HTTP的上述缺陷，SPDY進行了如下改進：

• 多路複用請求優化：SPDY規定在一個SPDY鏈接內能夠有無限個並行的請求，即多個併發的請求共用一個TCP會話；只須要創建一個TCP鏈接就能夠傳送網頁上的全部資源；減小了時延，節省了資源，把TCP鏈接的效率發揮到了最高；
• 能夠設置請求的優先級：沒必要遵照HTTP那樣的先進先出，而是能夠優先傳輸CSS這些更重要的資源，而後再傳輸網站圖標這樣不過重要的資源。
• 支持服務器推送功能：能夠實現預加載，好比瀏覽器請求了style.css，服務器就會主動把style.js推送給瀏覽器。這樣瀏覽器請求style.js是就能夠直接使用本地緩存了；這 與WebSocket不一樣在於，這是資源的主動推送；
• SPDY壓縮了HTTP頭：捨棄了沒必要要的Header頭，能夠節省多餘數據形成的等待時間，佔據的帶寬等；
• 強制使用SSL傳輸協議：客戶端所有的請求都要通過SSL加密後才能傳輸；

直觀的影響

對於前端工程師而言，頁面優化永遠是一個課題。有了SPDY的請求優化，能夠將請求順序從新編排，這樣很大程度上緩解了頁面加載時圖片請求帶來的影響；減小了HTTP的請求；

十6、HTTP2.0

上面所講的SPDY後來被谷歌放棄了，轉而成爲了HTTP2.0的前身，基於SPDY的核心改造升級開發出了HTTP2.0。因此二者有比較多類似的地方：

1.HTTP2.0性能加強的核心：二進制分幀

在HTTPS的基礎上新增了二進制分幀層：Binary Framing，在該層上HTTP2.0會將全部的傳輸信息分割成更小的消息和幀，並對其採用二進制格式的編碼；

以下圖所示：

• 請求頭信息被封裝進了HEADERS frame中，請求報文主體被封裝進了DATA frame中；
• HTTP2.0的通訊都在一個鏈接上完成，這個鏈接能夠承載任意數量的雙向數據流。每一個數據流都以消息的形式發送，而消息由一個或多個幀組成。這些幀能夠亂序發送，而後再根據每一個幀首部的流標識符從新組裝。

2.HTTP2.0首部壓縮

HTTP2.0在服務器端和客戶端使用首部表來跟蹤和存儲以前發送的鍵值對，對於相同的數據再也不經過每次請求和響應發送，通信期間幾乎不會改變通用的鍵值對，好比：Host、User-agent等只須要發送一次；若是這個請求不包含首部，那麼首部的開銷就變爲0字節了，此時首部都自動使用以前發送請求的首部；

以下圖所示，Request # 2中只須要在HEADERS frame裏發送:path這個變化的頭部便可，其餘頭部信息直接沿用Request #1的請求頭；或者說新增或變化的頭部信息會被追加到新的首部表中，如圖中的Request #2。它在HTTP2.0的鏈接存續期內是始終存在的，由客戶端和服務器端共同地漸進地更新；

3.HTTP2.0多路複用

多路複用這也是繼承於SPDY協議的，HTTP2.0全部的通訊都在一個TCP鏈接上完成。HTTP2.0把HTTP通訊的基本單位縮小爲一個一個的幀，這些幀對應於邏輯流裏面的信息，並行的在同一個TCP鏈接上雙向交換；

TCP鏈接性能的關鍵在於低延遲。大多數HTTP鏈接的時間都很短，並且是突發性的，而TCP只在長時間傳輸鏈接，傳輸大塊數據的時候效率是最高的；HTTP2.0經過讓全部的數據流公用一個TCP鏈接能夠更有效地使用TCP鏈接，讓高帶寬也能真正地服務於HTTP的性能提高上。

但連接多資源的優點

• 能夠減小服務器創建大量連接的壓力，內存佔用更少，鏈接吞吐量變大了。

• 因爲TCP鏈接減小而使網絡擁塞情況得以改觀；

• 慢啓動時間減小，擁塞和丟包恢復速度更快；

也就是說，資源合併減小請求的方式，對於HTTP2.0來講是沒有效果，只會開發者無用的工做量而已。因此當HTTP2.0普及以後，像雪碧圖呀，文件合併等就沒有多大意義了。

4.並行雙向字節流的請求和響應

簡單點說就是能夠亂序發送，在HTTP2.0上客戶端和服務器能夠把HTTP數據的消息分解爲互不依賴的數據幀，而後亂序發送，最後在接收端把這些亂序幀從新組合起來。如圖所示，同一個鏈接有多個不一樣方向的數據流在傳輸，因此客戶端能夠一邊亂序地發送數據幀，也能夠接收服務器的響應；服務器端也是如此都是雙向的。

因此：把HTTP消息分解爲獨立的幀交錯發送，而後在另外一端從新組裝是HTTP2.0一項很重要的加強；

這一特性會發生連鎖反應帶來巨大的性能提高：

• 並行交錯地發送請求，請求之間互不影響；
• 並行交錯地發送響應，響應之間互不干擾；
• 只是用一個鏈接便可並行發送多個請求和響應；
• 消除沒必要要的延遲，減小頁面加載的時間；

5.請求優先級

HTTP2.0的這一特性也是繼承於SPDY，服務器處理不一樣的流採起不一樣的優先策略；

• 高優先級的流都應該優先發送；
• 優先級不是絕對的；
• 不一樣優先級混合也是必須的；

6.服務器推送

畢竟HTTP2.0的核心是從SPDY的基礎上衍生而來的；服務器能夠對客戶端的一個請求發送多個響應，即除了對最初請求的響應以外服務器還能夠額外向服務器推送其餘資源，而無需客戶端明確請求；如圖所示：客戶端請求了html文件，服務器就會把js與css文件推送給客戶端：

十7、WebDAV協議

WebDAV（Web-based Distributed Authoring and Versioning，基於萬維網的分佈式創做和版本控制）是一個可對 Web 服務器上的內容直接進行文件複製、編輯等操做的分佈式文件系統（可在線修改文件的網盤）。

除了建立、刪除文件等基本功能，它還具有文件建立者管理、文件編輯過程當中禁止其餘用戶內容覆蓋的加鎖功能， 以及對文件內容修改的版本控制功能。

使用 HTTP/1.1 的 PUT 方法和 DELETE 方法， 就能夠對 Web 服務器上的文件進行建立和刪除操做。 但是出於安全性及便捷性等考慮，通常不使用。

1.WebDAV 內新增的方法及狀態碼

WebDAV 爲實現遠程文件管理，向 HTTP/1.1 中追加了如下這些方法。

方法	用途
PROPFIND	獲取屬性
PROPPATCH	修改屬性
MKCOL	建立集合
COPY	複製資源及屬性
MOVE	移動資源
LOCK	資源加鎖
UNLOCK	資源解鎖

新增狀態碼：

狀態碼	含義
102 Processing	可正常處理請求，但目前是處理中狀態
207 Multi-Status	存在多種狀態
422 UnprocessibleEntity	格式正確，內容有誤
423 Locked	資源已被加鎖
424 FailedDependency	處理與某請求關聯的請求失敗，所以再也不維持依賴關係
507 InsufficientStorage	保存空間不足

**WebDAV 的請求實例 **

下面是使用 PROPFIND 方法對 http://www.example.com/file 發起獲取屬性的請求 :

PROPFIND /file HTTP/1.1
Host: www.example.com
Content-Type: application/xml; charset="utf-8"
Content-Length: 219

//...請求主體

**WebDAV 的響應實例 **

下面是針對以前的 PROPFIND 方法， 返回http://www.example.com/file 的屬性的響應。

HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: 831

//...響應主體

不過能夠使用FTP替代它；

十8、HTTP3.0

1.HTTP2.0的問題

• 隊頭阻塞：因爲只創建一個TCP鏈接，一旦出現某次傳輸出現丟包，就要等待重傳，嚴重阻礙了其餘數據的傳輸；
• 創建鏈接的握手延遲大：HTTPS和HTTP2.0除了創建TCP握手以外，還要創建TSL安全傳輸，這就出現了兩次握手延遲；對於短鏈接來講，影響沒法被移除，這些都是TCP的歷史遺留問題；

2.QUIC的特性

• 0 RTP：兩層意思，創建UDP鏈接和創建TSL安全鏈接大多數狀況只須要0 RTP；

• 沒有隊頭阻塞的多路複用

當TCP鏈接中傳輸的數據流stream2中出現丟包時，在發送端沒有重傳丟失的包以前跟在stream2後面的stream3/4就被阻塞住了；

然而UDP鏈接中，數據流彼此間沒有依賴關係，即便stream2出現丟包，也不影響其餘stream數據的傳輸；

• 前向糾錯（Front Error Collection）

每一個數據包除了它自己的數據以外，還包括了部分其餘包的內容，所以少許的丟包能夠經過其餘包的冗餘數據直接組裝，而無需重傳；這種方法雖然犧牲了每一個數據包可發送數據的上限，可是減小了由於丟包致使的數據重傳（更浪費時間）；若是丟失的包過多，就只能經過重傳來解決。

QUIC融合了UDP協議的速度性能和TCP的安全和可靠，大大優化了互聯網傳輸數據的體驗。

3.HTTP協議總結

• HTTP1.0/1.1：有鏈接沒法複用、隊頭阻塞、協議開銷大和安全因素等多個缺點；

• HTTP2.0：經過多路複用、二進制流、頭部壓縮等技術極大地提高了性能，可是仍是存在問題；

• HTTP3.0：QUIC是基於UDP實現的，是HTTP3.0的底層支持協議。該協議基於UDP又吸取了TCP的精華，實現了既快又可靠的鏈接；

十9、Web安全

1.概述

平常生活中的」安全「

• 爲何登陸的時候常常要求咱們輸入一個驗證碼？
• 在一個網站上長時間沒有操做，爲何Session會失效？

1.1.WASC的定義

全程Web Application Security Consortium：是一個由安全專家、行業顧問和諸多組織的表明組成的國際團體，負責爲WWW（萬維網）制定廣爲人知的應用安全標準。

1.2.六類Web應用安全威脅

名稱	中文名	做用
Authentication	驗證	用來確認某用戶、服務或是應用身份的攻擊手段
Authorization	受權	用來決定是否某用戶、服務或是應用具備執行請求動做必要權限的攻擊手段
Client-Side-Attacks	客戶側攻擊	用來擾亂或是探測Web站點用戶的攻擊手段
Command Execution	命令執行	在Web站點上執行遠程命令的攻擊手段（好比SQL注入）
Information Disclosure	信息泄露	用來獲取Web站點具體系統信息的攻擊手段
Logical Attacks	邏輯性攻擊	用來擾亂或是探測Web應用邏輯流程的攻擊手段

1.3.OWASP的定義

全稱Open Web Application Security Project，該組織致力於發現和解決不安全Web應用的根本緣由；它們最重要的項目之一是Web應用的十大安全隱患

總結了目前Web應用最常受到的十種攻擊手段，而且按照攻擊發生的機率進行了排序（如下爲2017年的數據）：

排名	漏洞種類	詳情
A1	注入	將不受信任的數據做爲命令或查詢的一部分發送到解析器時，會產生注入：SQL注入、NoSQL注入、OS注入和LDAP注入缺陷。
A2	失效的身份認證	經過錯誤的使用應用程序的身份認證和會話管理功能，攻擊者可以破譯密碼、密鑰或會話令牌
A3	敏感數據泄露	許多Web程序和API都沒法正確保護敏感數據，攻擊者可經過竊取或修改未加密的數據來實施信用卡詐騙、身份盜竊等犯罪行爲
A4	XML外部實體（XXE）	許多較早的或配置錯誤的XML處理器評估的XML文件中的外部實體引用。攻擊者可利用外部實體竊取內部文件、執行遠程代碼
A5	失效的訪問控制	未對經過身份驗證的用戶實施恰當的訪問控制
A6	安全配置錯誤	安全配置錯誤是最多見的安全問題，這一般是因爲不安全的默認配置、不完整的臨時配置、開源雲錯誤等形成
A7	跨站腳本（XSS）	XSS讓攻擊者可以在受害者的瀏覽器中執行腳本，並劫持用戶會話、破壞網站或將用於重定向到惡意站點
A8	不徹底的反序列化	不安全的反序列化會致使遠程代碼執行
A9	使用含有已知漏洞的組件	組件如庫、框架和其餘軟件模塊擁有和應用程序相同的權限
A10	不足的日誌記錄和監控	不足的日誌記錄和監控，以及事件響應缺失或無效的集成，使攻擊者可以進一步攻擊系統、保持持續性、篡改、提取或銷燬數據

2.驗證機制

驗證機制是Web應用程序中最簡單的一種安全機制，也是防護惡意攻擊的核心機制；

2.1.典型的身份驗證模式

驗證技術

• 基於HTML表單的驗證
• 多元機制，如組合密碼；
• 客戶端SSL證書

弱密碼

許多Web應用程序沒有或不多對用戶密碼強度進行控制；

暴力破解

登陸功能的公開性會誘使攻擊者試圖猜想用戶名和密碼，從而得到訪問應用程序的權力；

暴力破解-安全措施

• 驗證碼技術：最多見和有效的應對方式，須要注意幾個問題：

  • 驗證碼是否真實有用

  • 驗證碼的複雜度：從最開始的數字，到數字字母組合，再到谷歌奇形怪狀的字母；

  • 應對當前的」打碼「事業盛行：使用專門平臺的」打碼「服務器進行破解；對此出現了點擊型的驗證碼、滑動型的驗證碼、問答型的驗證碼等更高級的驗證碼；

• Cookie和會話檢測：有些應用程序會設置一個Cookie，如failedlogin = 0；嘗試登陸失敗，遞增該值，達到某個上限，檢測到這個值並拒絕再次處理登陸；

  • 這樣也不安全，只要客戶端的Cookie在到達服務器端前被截獲，就能被篡改；

• 雙因子認證：雙因子認證的核心是綜合What you know（我的密碼）和What you have（手機）來達到雙重認證效果；（較安全經常使用）

3.會話管理機制

• 絕大多數Web應用程序中，會話管理機制是一個基本的安全組件。會話管理機制在應用程序執行登陸功能時尤其重要，由於：它能夠在用戶經過請求提交它們的證書後，持續嚮應用程序保證任何特定用戶身份的真實性；

• 因爲會話管理機制所發揮的關鍵做用，它們就成爲了針對應用程序的惡意攻擊的主要目標；

• 若攻擊者可以破壞應用程序的會話管理，他就能輕易避開其實施的驗證機制，不須要用戶證書便可假裝成其餘應用程序用戶。

3.1.會話管理存在的漏洞

• 會話令牌生成漏洞：好比採用常見的算法生成，容易被人猜出算法名稱進行反編譯破解；

• 令牌可預測：好比隱含序列，事件依賴；

• 會話終止攻擊：會話結束後，Cookie沒有真正意義上被刪除，下次驗證還有效；

• 會話劫持攻擊：好比網絡嗅探、XSS攻擊等方式獲取用戶的會話令牌；

3.2.會話管理漏洞的防護

令牌傳輸安全

• 令牌只能經過HTTPS傳送；
• 若是使用HTTP cookie傳送令牌（大多數狀況下）應該將Cookie字段標記爲Secure，以防止用戶瀏覽器經過HTTP傳送它們；

增長軟硬會話過時

• 軟會話過時：它指的是用戶在必定的時間內與應用系統沒有交互，則會話過時也就是咱們常說的Session失效；
• 硬會話過時：它指的是用戶登陸到系統中通過必定的時間後，無論用戶作什麼，該會話都會過時（網吧上網時間到了，強制下機）；

二10、常見的網絡攻擊

1.SQL注入攻擊

1.1.SQL注入原理

• 幾乎每一個Web應用都須要使用數據庫來保存操做所須要的各類信息；
• 因此Web程序是常常會創建用戶提交數據的SQL語句；
• 最嚴重的狀況下，攻擊者可利用SQL注入，讀取甚至修改數據庫中保存的全部數據；
• 用戶能夠提交一段數據庫查詢代碼，根據程序返回結果，得到某些他想得知的數據；

這就是所謂的SQL Injection，即SQL注入；好比：

賬戶名中輸入的‘or’1 = 1會被識別爲SQL操做指令；

1.2.SQL注入危害

• 探知數據庫的具體結構，爲進一步攻擊準備；
• 泄露數據，尤爲是機密信息、帳戶信息等；
• 取得更高權限，用來修改數據甚至是內部結構；

1.3.SQL注入防護

參數化查詢

• 參數化查詢是對SQL注入根本性的防護策略，也叫作預處理語句，在創建一個包含用戶輸入的SQL語句時分爲兩步：

  • 指定查詢結構，用戶輸入預留佔位符；
  • 指定佔位符內容；

  好比使用問號?看成佔位符，這樣即便輸入了SQL語句這樣也不會被認爲是數據SQL的一部分，而是用戶輸入內容。

字符串過濾

使用正則表達式過濾傳入的參數

2.跨域腳本攻擊（XSS）

跨站腳本攻擊（Cross Site Scripting），XSS（CSS已被佔用因此叫XSS）是一種常常出如今Web應用中的計算機安全漏洞；

它容許Web用戶惡意地將代碼植入到提供給其餘用戶使用的頁面中，其餘用戶在觀看網頁時，惡意腳本就會執行；

2.1.XSS攻擊原理

• 這類攻擊一般經過注入HTML或JS等腳本發動攻擊；
• 攻擊成功後，攻擊者能夠獲得私密網頁內容和Cookie等；
• 最近幾年XSS攻擊已成爲最流行的攻擊方式；

2.2.XSS攻擊危害

• 盜取各種用戶帳號：如機器登陸帳號、用戶網銀帳號、各種管理員帳號；
• 控制數據：包括讀取、篡改、添加、刪除企業敏感數據的能力；
• 盜竊企業重要的具備商業價值的資料；
• 非法轉帳；
• 強制發送網站掛木馬；
• 控制受害者機器，讓該用戶成爲"肉機"，向其餘網站發起攻擊；

2.3.XSS攻擊真實案例

Myspace XSS攻擊事件

• 2005年，一名叫作samy的用戶發現了Myspace（社交網站）的XSS漏洞，他在用戶資料頁面插入了一些javascript腳本；
• 若是一個用戶查看了他的用戶資料，這段腳本就會被執行；
• 腳本包括兩方面：一是把Samy加爲好友，二是將上面說的腳本複製到受害者本身的用戶資料頁面中；
• 因而，全部查看受害者用戶資料的用戶也會成爲受害者；
• 一個基於存儲式XSS攻擊的蠕蟲迅速擴散，幾個小時內，Samy收到了近百萬個好友的申請；
• 爲此，Myspace被迫關站，修復反XSS過濾機制而且從全部用戶的資料中刪除含有惡意腳本的內容；

2.4.XSS分類

針對XSS的攻擊方式不一樣，能夠把XSS分爲以下三大類：

• 反射式XSS
• 存儲式XSS
• 基於DOM的XSS

反射式XSS

也稱爲非永久性XSS，目前最流行的XSS攻擊；它出如今服務器直接服務器直接使用客戶端提交的數據，如URL的數據、HTML表單中提交的數據，而且沒有對數據進行無害化處理；若是提交的數據中含有HTML控制字符而沒有被正確處理，那麼一個簡單的XSS攻擊就會發生。

典型的反射式攻擊方式可經過一個郵件或中間網站，誘餌是一個看起來可信任的站點的連接，其中包含XSS攻擊腳本，好比社交羣中常發的遊戲活動、賭博、美女連接等。若是信任的網站沒有正確處理這個腳本，用戶點擊後就會致使瀏覽器執行含有惡意攻擊的腳本。

存儲式XSS

也稱爲永久性XSS，危害更大。攻擊將攻擊腳本上傳到Web服務器上，使得全部訪問該頁面的用戶都面臨信息泄露的可能，其中也包括了Web服務器的管理員；

存儲式XSS多發生在最終顯示給其餘用戶的位置包含：

• 我的信息字段，如姓名、地址、電子郵件、電話等；
• 文檔、上傳文件及其餘數據的名稱；
• 提交給應用程序管理員的反饋或問題；
• 向其餘應用程序用戶傳送的消息、註釋、問題等；
• 在用戶之間共享的上傳文件內容；

典型的存儲式XSS攻擊過程

• 我擁有一個Web站點，該站點容許用戶發佈信息/瀏覽已發佈信息；
• 你注意到個人站點具備存儲式的XSS漏洞；
• 因而你發佈一個熱點信息，利用該漏洞獲取用戶信息，吸引其餘用戶紛紛閱讀；
• 任何其餘人瀏覽該信息，其繪畫Cookies或其餘信息都會被你盜走；

基於DOM的XSS攻擊

反射式XSS攻擊和存儲式XSS攻擊都是經過服務器提取用戶提交的數據，而且以不安全的方式將其返回給用戶；基於DOM的攻擊僅僅經過JavaScript的方式執行；

也就是說這種攻擊常發生在應用程序每次返回相同的靜態頁面（HTML文件），並經過客戶端的js文件動態生成信息，並不會與服務器交互獲取該js文件的時候；

2.5.XSS攻擊載荷

會話令牌

• XSS攻擊對廣泛的方式；
• 截取一名受害者的會話令牌（Token）,劫持他的會話，進而做爲受害者的身份來使用應用程序，執行任意操做並佔有該用戶的帳號；

虛擬置換

• 這種攻擊須要在一個Web應用程序頁面注入惡意數據，從而嚮應用程序的用戶傳送誤導性信息；

• 包括簡單的向站點注入HTML，或者使用腳本注入精心設計的內容；

  好比在淘寶的搜索結果頁面中注入一個連接，受害者點擊後跳轉到一個和淘寶很像的釣魚網頁，登陸時賬戶信息就被泄露了；

• 攻擊者實際上沒有修改保存在服務器上的內容，而是利用程序處理並顯示用戶提交的輸入方面的缺陷實現置換；

注入木馬

• 在一個明顯的攻擊中，攻擊者注入的功能向用戶顯示一個木馬登陸表單，要求他們像攻擊者控制的服務器提交他們本身的證書。

2.6.XSS防護措施

輸入驗證

• 在輸入的過程當中，若是應用程序有向後端提交處理的數據，應對這些數據進行嚴格的確認；
• 好比：數據不能太長；
• 數據僅包含某組合法字符；
• 數據與一個特殊的正則表達式匹配（好比手機號）；
• 根據應用程序但願在每一個字段中收到的數據類型，儘量限制性地對姓名、電子郵件地址、帳號等應用不一樣的確認規則；

輸出編碼

• 若是應用程序將某位用戶或第三方提交的數據複製到它的響應中，那麼應用程序應對這些數據進行HTML編碼，以淨化可能的惡意字符；
• HTML編碼指用對應的HTML實體替代字面量字符。這樣作可確保瀏覽器安全處理可能爲惡意的字符，把它們看成HTML文檔的內容而非結構處理；
• 常常形成問題的字符的HTML編碼：
  • 」 -> &quot
  • ' -> &#x27
  • < -> &lt
  • > -> &gt
  • / -> x2F

應用程序之因此結合使用輸入確認（次要）與輸出淨化（首要），緣由在於這種方法可以提供兩層防護：若是其中一層被攻破，另外一層還能提供一些保護；

3.CSRF攻擊

CSRF（Cross-site Request Forgery）跨站請求僞造，也被稱爲One Click Attack或者Session riding一般縮寫爲CSRF或者XSRF，是一種對網站的惡意利用；

儘管聽起來像跨站腳本（XSS），但它與XSS很是不一樣，而且攻擊方式幾乎相左；

3.1.CSRF攻擊原理

• XSS利用站點內的信任用戶（受害者），而CSRF經過假裝來自受信任用戶的請求來利用受信用的網站；

• 經過社會學的手段（如經過電子郵件發送一個連接）來蠱惑受害者進行一些敏感性的操做，如修改密碼、修改E-mail、轉帳等，而受害者還不知道他已經中招；

3.2.CSRF攻擊危害

• CSRF的破壞力依賴於受害者的權限；
• 若是受害者只是個普通用戶，則一個成功的CSRF攻擊會危害用戶的數據以及一些功能；
• 若是受害者具備管理員權限，則一個成功的CSRF攻擊甚至會威脅到整個網站的安全；
• 與XSS攻擊相比，CSRF攻擊每每不太流行，所以對其進行防範的資源也至關稀少，和難以防範；
• 故被認爲比XSS更具危險性，因此CSRF在業內有個響噹噹的名字——沉睡的巨人

3.3.CSRF攻擊的特色

• 攻擊通常發起在第三方網站，而不是被攻擊的網站。被攻擊的網站沒法防止攻擊發生。
• 攻擊利用受害者在被攻擊網站的登陸憑證，冒充受害者提交操做；而不是直接竊取數據。
• 整個過程攻擊者並不能獲取到受害者的登陸憑證，僅僅是「冒用」。
• 跨站請求能夠用各類方式：圖片URL、超連接、CORS、Form提交等等。部分請求方式能夠直接嵌入在第三方論壇、文章中，難以進行追蹤。

CSRF一般是跨域的，由於外域一般更容易被攻擊者掌控。可是若是本域下有容易被利用的功能，好比能夠發圖和連接的論壇和評論區，攻擊能夠直接在本域下進行，並且這種攻擊更加危險。（好比博客留言）

3.4.CSRF攻擊的過程

• 受害者登陸a.com，並保留了登陸憑證（Cookie）；
• 攻擊者引誘受害者訪問了b.com；
• b.com 向 a.com （服務器）發送了一個請求：a.com/act=xx。瀏覽器會默認攜帶a.com發放的Cookie；
• a.com接收到請求後，對請求進行驗證，並確認是受害者的憑證，誤覺得是受害者（a.com的用戶）本身發送的請求；
• a.com以受害者的名義執行了act=xx；
• 攻擊完成，攻擊者在受害者不知情的狀況下，冒充受害者，讓a.com執行了本身定義的操；

3.5.CSRF攻擊預防

CSRF一般從第三方網站發起，被攻擊的網站沒法防止攻擊發生，只能經過加強本身網站針對CSRF的防禦能力來提高安全性。

上文中講了CSRF的兩個特色：

• CSRF（一般）發生在第三方域名。
• CSRF攻擊者不能獲取到Cookie等信息，只是使用。

針對這兩點，咱們能夠專門制定防禦策略，以下：

• 阻止不明外域的訪問
  • 同源檢測
  • Samesite Cookie
• 提交時要求附加本域才能獲取的信息
  • CSRF Token
  • 雙重Cookie驗證
  • 增長確認操做
  • 從新認證

增長確認操做

• 好比轉帳功能，當用戶調用API進行轉裝的時候，彈出一個對話框，例如：你確認轉賬200元嗎？即在瀏覽器上進行敏感操做時增長確認操做，確保是用戶所爲；

從新認證

• 在作一些重要敏感的操做時，要求用戶從新輸入密碼進入二次驗證，只有正確了才進行操做；這種作法顯然更安全，但對於用戶來講不是特別友好——畢竟是增長了異一步操做；
• 因此安全和易用性，有時候不得不作出取捨；

使用Token*

CSRF的一個特徵是，攻擊者沒法直接竊取到用戶的信息（Cookie，Header，網站內容等），僅僅是冒用Cookie中的信息。

而CSRF攻擊之因此可以成功，是由於服務器誤把攻擊者發送的請求當成了用戶本身的請求。那麼咱們能夠要求全部的用戶請求都攜帶一個CSRF攻擊者沒法獲取到的Token。服務器經過校驗請求是否攜帶正確的Token，來把正常的請求和攻擊的請求區分開，也能夠防範CSRF的攻擊。

驗證過程

• 服務器端：在用戶剛登錄的時候，產生一個新的不可預知的CSRF Token，而且把此Token存放在用戶的session中。
• 在任何一個須要保護的表單中（轉帳，該密碼），增長一個隱藏的字段來從服務器端獲取和存放這個Token；
• 提交請求的時候，在服務器端檢查提交的Token與用戶Session中的Token是否一致，若是一致，繼續處理請求，不一致或者沒有的話，就返回一個錯誤的信息給用戶。
• 在用戶退出或者Session過時的時候，用戶信息（包括CSRF Token）從Session中移除而且銷燬Session。

參考資料：大話HTTP協議、《圖解HTTP》、前端安全系列之二：如何防止CSRF攻擊？