圖解HTTP

• 第1章 了解 Web 及網(wǎng)絡(luò)基礎(chǔ)

  • TCP/IP協(xié)議族

    • TCP/IP是把與互聯(lián)網(wǎng)相關(guān)聯(lián)的協(xié)議集合起來的總稱

    • 層次化

      • 應(yīng)用層（FTP、DNS、HTTP協(xié)議）

        • 應(yīng)用層決定了向用戶提供應(yīng)用服務(wù)時的通信活動

      • 傳輸層(TCP、UDP)

        • 傳輸層對上層應(yīng)用層，提供處于網(wǎng)絡(luò)連接中的兩臺計算機(jī)之間的數(shù)據(jù)傳輸

      • 網(wǎng)絡(luò)層

        • 網(wǎng)絡(luò)層用來處理在網(wǎng)絡(luò)上流動的數(shù)據(jù)包

      • 數(shù)據(jù)鏈路層

        • 用來處理連接網(wǎng)絡(luò)的硬件部分

      • 圖示 IP 協(xié)議、 TCP 協(xié)議和 DNS 服務(wù)在使用HTTP 協(xié)議的通信過程中各自發(fā)揮了哪些作用

  • URI 和 URL

    • URI 用字符串標(biāo)識某一互聯(lián)網(wǎng)資源， 而 URL表示資源的地點（互聯(lián)網(wǎng)上所處的位置）

    • URI（ Uniform Resource Identifier，統(tǒng)一資源標(biāo)識符）

      • 絕對 URI 的格式

    • URL（Uniform Resource Locator， 統(tǒng)一資源定位符）

• 第 2 章 簡單的 HTTP 協(xié)議

  • HTTP 是不保存狀態(tài)的協(xié)議

    • TTP 是一種不保存狀態(tài)， 即無狀態(tài)協(xié)議。HTTP 協(xié)議自身不對請求和響應(yīng)之間的通信狀態(tài)進(jìn)行保存。 也就是說在 HTTP 這個級別， 協(xié)議對于發(fā)送過的請求或響應(yīng)都不做持久化處理。

      • 有了 Cookie 再用 HTTP 協(xié)議通信， 就可以管理狀態(tài)了，Cookie 技術(shù)通過在請求和響應(yīng)報文中寫入 Cookie 信息來控制客戶端的狀態(tài)

  • 告知服務(wù)器意圖的 HTTP 方法

    • GET ： 獲取資源

      • 指定的資源經(jīng)服務(wù)器端解析后返回響應(yīng)內(nèi)容。

    • POST： 傳輸實體主體

      • 雖然用 GET 方法也可以傳輸實體的主體， 但一般不用 GET 方法進(jìn)行傳輸， 而是用 POST 方法。 雖說 POST 的功能與 GET 很相似， 但POST 的主要目的并不是獲取響應(yīng)的主體內(nèi)容。

    • PUT： 傳輸文件

      • PUT 方法用來傳輸文件。 就像 FTP 協(xié)議的文件上傳一樣， 要求在請求報文的主體中包含文件內(nèi)容， 然后保存到請求 URI 指定的位置。

    • HEAD： 獲得報文首部

      • HEAD 方法和 GET 方法一樣， 只是不返回報文主體部分。 用于確認(rèn)URI 的有效性及資源更新的日期時間等。

    • DELETE： 刪除文件

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

    • OPTIONS： 詢問支持的方法

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

    • TRACE： 追蹤路徑

      • TRACE 方法是讓 Web 服務(wù)器端將之前的請求通信環(huán)回給客戶端的方法。

    • CONNECT： 要求用隧道協(xié)議連接代理

      • CONNECT 方法要求在與代理服務(wù)器通信時建立隧道， 實現(xiàn)用隧道協(xié)議進(jìn)行 TCP 通信。 主要使用 SSL（Secure Sockets Layer， 安全套層）和 TLS（Transport Layer Security， 傳輸層安全） 協(xié)議把通信內(nèi)容加 密后經(jīng)網(wǎng)絡(luò)隧道傳輸

  • 持久連接節(jié)省通信量

    • 背景：HTTP 協(xié)議的初始版本中， 每進(jìn)行一次 HTTP 通信就要斷開一次 TCP連接。隨著 HTTP 的普及， 文檔中包含大量圖片的情況多了起來

    • 解決：HTTP/1.1 和一部分的 HTTP/1.0 想出了持久連接的方法。 持久連接的特點是， 只要任意一端沒有明確提出斷開連接， 則保持 TCP 連接狀態(tài)。

    • 好處：減少了 TCP 連接的重復(fù)建立和斷開所造成的額外開銷， 減輕了服務(wù)器端的負(fù)載。 另外， 減少開銷的那部分時間， 使HTTP 請求和響應(yīng)能夠更早地結(jié)束， 這樣 Web 頁面的顯示速度也就相應(yīng)提高了。

• 第 3 章 HTTP 報文內(nèi)的 HTTP 信息

  • 請求報文及響應(yīng)報文的結(jié)構(gòu)

    • 請求行：包含用于請求的方法， 請求 URI 和 HTTP 版本。

    • 狀態(tài)行：包含表明響應(yīng)結(jié)果的狀態(tài)碼， 原因短語和 HTTP 版本。

    • 首部字段：包含表示請求和響應(yīng)的各種條件和屬性的各類首部。

  • 編碼提升傳輸速率

    • 報文主體和實體主體的差異

      • 報文（ message）：是 HTTP 通信中的基本單位， 由 8 位組字節(jié)流（octet sequence，其中 octet 為 8 個比特） 組成， 通過 HTTP 通信傳輸。

      • 實體（ entity）：作為請求或響應(yīng)的有效載荷數(shù)據(jù)（補(bǔ)充項） 被傳輸， 其內(nèi)容由實體首部和實體主體組成。

    • 壓縮傳輸?shù)膬?nèi)容編碼

      • 常用的內(nèi)容編碼有以下幾種：gzip（ GNU zip）、compress（ UNIX 系統(tǒng)的標(biāo)準(zhǔn)壓縮）、deflate（ zlib）、identity（ 不進(jìn)行編碼）

      • 執(zhí)行范圍請求時， 會用到首部字段 Range 來指定資源的 byte 范圍

  • 內(nèi)容協(xié)商返回最合適的內(nèi)容

    • 內(nèi)容協(xié)商技術(shù)有以下 3 種類型

      • 服務(wù)器驅(qū)動協(xié)商（ Server-driven Negotiation）

        • 由服務(wù)器端進(jìn)行內(nèi)容協(xié)商。 以請求的首部字段為參考， 在服務(wù)器端自動處理。

      • 客戶端驅(qū)動協(xié)商（ Agent-driven Negotiation）

        • 由客戶端進(jìn)行內(nèi)容協(xié)商的方式。 用戶從瀏覽器顯示的可選項列表中手動選擇。 還可以利用 JavaScript 腳本在 Web 頁面上自動進(jìn)行上述選 擇。

      • 透明協(xié)商（ Transparent Negotiation）

        • 是服務(wù)器驅(qū)動和客戶端驅(qū)動的結(jié)合體， 是由服務(wù)器端和客戶端各自進(jìn)行內(nèi)容協(xié)商的一種方法

• 第 4 章 返回結(jié)果的 HTTP 狀態(tài) 碼

  • 狀態(tài)碼的職責(zé)是當(dāng)客戶端向服務(wù)器端發(fā)送請求時， 描述返回的請求結(jié)果。

    • 數(shù)字中的第一位指定了響應(yīng)類別， 后兩位無分類， 響應(yīng)類別有以上 5種。只要遵守狀態(tài)碼類別的定義， 即使改變 RFC2616 中定義的狀態(tài)碼， 或服務(wù)器端自行創(chuàng)建狀態(tài)碼都沒問題。

  • 2XX 成功

    • 2XX 的響應(yīng)結(jié)果表明請求被正常處理了

    • 200 OK

      • 表示從客戶端發(fā)來的請求在服務(wù)器端被正常處理了。

    • 204 No Content

      • 該狀態(tài)碼代表服務(wù)器接收的請求已成功處理， 但在返回的響應(yīng)報文中不含實體的主體部分。 另外， 也不允許返回任何實體的主體。

        • 一般在只需要從客戶端往服務(wù)器發(fā)送信息， 而對客戶端不需要發(fā)送新信息內(nèi)容的情況下使用。

    • 206 Partial Content

      • 該狀態(tài)碼表示客戶端進(jìn)行了范圍請求， 而服務(wù)器成功執(zhí)行了這部分的GET 請求。 響應(yīng)報文中包含由 Content-Range 指定范圍的實體內(nèi)容。

  • 3XX 重定向

    • 3XX 響應(yīng)結(jié)果表明瀏覽器需要執(zhí)行某些特殊的處理以正確處理請求

    • 301 Moved Permanently

      • 永久性重定向。 該狀態(tài)碼表示請求的資源已被分配了新的 URI， 以后應(yīng)使用資源現(xiàn)在所指的 URI。 也就是說， 如果已經(jīng)把資源對應(yīng)的 URI 保存為書簽了， 這時應(yīng)該按 Location 首部字段提示的 URI 重新保存。

    • 302 Found

      • 臨時性重定向。 該狀態(tài)碼表示請求的資源已被分配了新的 URI， 希望用戶（本次） 能使用新的 URI 訪問。

        • 和 301 Moved Permanently 狀態(tài)碼相似， 但 302 狀態(tài)碼代表的資源不是被永久移動， 只是臨時性質(zhì)的。 換句話說， 已移動的資源對應(yīng)的 URI 將來還有可能發(fā)生改變。

    • 303 See Other

      • 該狀態(tài)碼表示由于請求對應(yīng)的資源存在著另一個 URI， 應(yīng)使用 GET方法定向獲取請求的資源

        • 303 狀態(tài)碼和 302 Found 狀態(tài)碼有著相同的功能， 但 303 狀態(tài)碼明確表示客戶端應(yīng)當(dāng)采用 GET 方法獲取資源， 這點與 302 狀態(tài)碼有區(qū) 別。

    • 304 Not Modified

      • 該狀態(tài)碼表示客戶端發(fā)送附帶條件的請求 2 時， 服務(wù)器端允許請求訪問資源， 但未滿足條件的情況。

        • 304 狀態(tài)碼返回時， 不包含任何響應(yīng)的主體部分。 304 雖然被劃分在 3XX 類別中， 但是和重定向沒有關(guān)系

    • 307 Temporary Redirect

      • 臨時重定向

        • 該狀態(tài)碼與 302 Found 有著相同的含義。 盡管 302 標(biāo)準(zhǔn)禁止 POST 變換成 GET， 但實際使用時大家并不遵守。307 會遵照瀏覽器標(biāo)準(zhǔn)， 不會從 POST 變成 GET。 但是， 對于處理響應(yīng)時的行為， 每種瀏覽器有可能出現(xiàn)不同的情況。

  • 4XX 客戶端錯誤

    • 4XX 的響應(yīng)結(jié)果表明客戶端是發(fā)生錯誤的原因所在

    • 400 Bad Request

      • 該狀態(tài)碼表示請求報文中存在語法錯誤。 當(dāng)錯誤發(fā)生時， 需修改請求的內(nèi)容后再次發(fā)送請求。

    • 401 Unauthorized

      • 該狀態(tài)碼表示發(fā)送的請求需要有通過 HTTP 認(rèn)證（BASIC 認(rèn)證、DIGEST 認(rèn)證） 的認(rèn)證信息。另外若之前已進(jìn)行過 1 次請求， 則表示用戶認(rèn)證失敗。

    • 403 Forbidden

      • 該狀態(tài)碼表明對請求資源的訪問被服務(wù)器拒絕了。

        • 服務(wù)器端沒有必要給出拒絕的詳細(xì)理由， 但如果想作說明的話， 可以在實體的主體部分對原因進(jìn)行描述， 這樣就能讓用戶看到了。

    • 404 Not Found

      • 該狀態(tài)碼表明服務(wù)器上無法找到請求的資源

        • 也可以在服務(wù)器端拒絕請求且不想說明理由時使用

  • 5XX 服務(wù)器錯誤

    • 5XX 的響應(yīng)結(jié)果表明服務(wù)器本身發(fā)生錯誤

    • 500 Internal Server Error

      • 該狀態(tài)碼表明服務(wù)器端在執(zhí)行請求時發(fā)生了錯誤。也有可能是 Web應(yīng)用存在的 bug 或某些臨時的故障

    • 503 Service Unavailable

      • 該狀態(tài)碼表明服務(wù)器暫時處于超負(fù)載或正在進(jìn)行停機(jī)維護(hù)， 現(xiàn)在無法處理請求。 如果事先得知解除以上狀況需要的時間， 最好寫入RetryAfter 首部字段再返回給客戶端。

• 第 5 章 與 HTTP 協(xié)作的 Web 服 務(wù)器

  • 通信數(shù)據(jù)轉(zhuǎn)發(fā)程序 ： 代理、 網(wǎng)關(guān)、 隧道

    • 代理

      • 代理是一種有轉(zhuǎn)發(fā)功能的應(yīng)用程序， 它扮演了位于服務(wù)器和客戶端“中間人”的角色， 接收由客戶端發(fā)送的請求并轉(zhuǎn)發(fā)給服務(wù)器， 同時也接收服務(wù)器返回的響應(yīng)并轉(zhuǎn)發(fā)給客戶端。

    • 網(wǎng)關(guān)

      • 網(wǎng)關(guān)是轉(zhuǎn)發(fā)其他服務(wù)器通信數(shù)據(jù)的服務(wù)器， 接收從客戶端發(fā)送來的請求時， 它就像自己擁有資源的源服務(wù)器一樣對請求進(jìn)行處理。 有時客戶端可能都不會察覺， 自己的通信目標(biāo)是一個網(wǎng)關(guān)。

    • 隧道

      • 隧道是在相隔甚遠(yuǎn)的客戶端和服務(wù)器兩者之間進(jìn)行中轉(zhuǎn)， 并保持雙方通信連接的應(yīng)用程序。

• 第 6 章 HTTP 首部

  • HTTP 報文首部

    • HTTP 請求報文

    • HTTP 響應(yīng)報文

  • HTTP 首部字段

    • HTTP 首部字段是由首部字段名和字段值構(gòu)成的， 中間用冒號“:” 分隔

  • 4 種 HTTP 首部字段類型

    • 通用首部字段（ General Header Fields）

      • 請求報文和響應(yīng)報文兩方都會使用的首部

    • 請求首部字段（ Request Header Fields）

      • 從客戶端向服務(wù)器端發(fā)送請求報文時使用的首部。 補(bǔ)充了請求的附加內(nèi)容、 客戶端信息、 響應(yīng)內(nèi)容相關(guān)優(yōu)先級等信息。

    • 響應(yīng)首部字段（ Response Header Fields）

      • 從服務(wù)器端向客戶端返回響應(yīng)報文時使用的首部。 補(bǔ)充了響應(yīng)的附加內(nèi)容， 也會要求客戶端附加額外的內(nèi)容信息。

    • 實體首部字段（ Entity Header Fields）

      • 針對請求報文和響應(yīng)報文的實體部分使用的首部。 補(bǔ)充了資源內(nèi)容更新時間等與實體有關(guān)的信息。

  • 其他首部字段

    • X-Frame-Options

      • 首部字段 X-Frame-Options 屬于 HTTP 響應(yīng)首部， 用于控制網(wǎng)站內(nèi)容在其他 Web 網(wǎng)站Frame 標(biāo)簽內(nèi)的顯示問題。 其主要目的是為了防止點擊劫持（clickjacking） 攻擊。

      • DENY ： 拒絕

      • SAMEORIGIN ： 僅同源域名下的頁面（Top-level-browsingcontext） 匹配時許可

    • X-XSS-Protection

      • 首部字段 X-XSS-Protection 屬于 HTTP 響應(yīng)首部， 它是針對跨站腳本攻擊（XSS） 的一種對策， 用于控制瀏覽器 XSS 防護(hù)機(jī)制的開關(guān)。

      • 0 ： 將 XSS 過濾設(shè)置成無效狀態(tài)

      • 1 ： 將 XSS 過濾設(shè)置成有效狀態(tài)

    • DNT

      • 首部字段 DNT 屬于 HTTP 請求首部， 其中DNT 是 Do Not Track 的簡稱， 意為拒絕個人信息被收集， 是表示拒絕被精準(zhǔn)廣告追蹤的一種方 法。

      • 0 ： 同意被追蹤

      • 1 ： 拒絕被追蹤

    • P3P

      • 首部字段 P3P 屬于 HTTP 相應(yīng)首部， 通過利用 P3P（The Platform for Privacy Preferences， 在線隱私偏好平臺） 技術(shù)， 可以讓 Web 網(wǎng)站上的個人隱私變成一種僅供程序可理解的形式， 以達(dá)到保護(hù)用戶隱私的目的

• 第 7 章 確保 Web 安全的HTTPS

  • 共享密鑰加密的困境

    • 加密和解密同用一個密鑰的方式稱為共享密鑰加密（Common key crypto system） ， 也被叫做對稱密鑰加密。

    • 可究竟怎樣才能安全地轉(zhuǎn)交？ 在互聯(lián)網(wǎng)上轉(zhuǎn)發(fā)密鑰時， 如果通信被監(jiān)聽那么密鑰就可會落入攻擊者之手， 同時也就失去了加密的意義。 另外還得設(shè)法安全地保管接收到的密鑰。

  • 使用兩把密鑰的公開密鑰加密

    • 公開密鑰加密方式很好地解決了共享密鑰加密的困難。公開密鑰加密使用一對非對稱的密鑰。 一把叫做私有密鑰（private key） ， 另一把叫做公開密鑰（public key） 。 顧名思義， 私有密鑰不能讓其他任何人知道， 而公開密鑰則可以隨意發(fā)布， 任何人都可以獲得。

    • 使用公開密鑰加密方式， 發(fā)送密文的一方使用對方的公開密鑰進(jìn)行加密處理， 對方收到被加密的信息后， 再使用自己的私有密鑰進(jìn)行解密。 利用這種方式， 不需要發(fā)送用來解密的私有鑰，也不必?fù)?dān)心密鑰被攻擊者竊聽而盜走

    • 公開密鑰加密與共享密鑰加密相比， 其處理速度要慢

  • HTTPS 采用混合加密機(jī)制

    • 在交換密鑰環(huán)節(jié)使用公開密鑰加密方式， 之后的建立通信交換報文階段則使用共享密鑰加密式。

  • 證明公開密鑰正確性的證書

    • 遺憾的是， 公開密鑰加密方式無法證明公開密鑰本身就是貨真價實的公開密鑰。為了解決上述問題， 可以使用由數(shù)字證書認(rèn)證機(jī)構(gòu)（CA Certificate Authority） 和其相關(guān)機(jī)關(guān)頒發(fā)的公開密鑰證書。

• 第 8 章 確認(rèn)訪問用戶身份的認(rèn)證

  • 核對的信息通常是

    • 密碼： 只有本人才會知道的字符串信息

    • 動態(tài)令牌： 僅限本人持有的設(shè)備內(nèi)顯示的一次性密碼

    • 數(shù)字證書： 僅限本人（ 終端） 持有的信息

    • 生物認(rèn)證： 指紋和虹膜等本人的生理信息

    • IC 卡等： 僅限本人持有的信息

  • HTTP 使用的認(rèn)證方式

    • BASIC 認(rèn)證（ 基本認(rèn)證）

    • DIGEST 認(rèn)證（ 摘要認(rèn)證）

    • SSL 客戶端認(rèn)證

    • FormBase 認(rèn)證（ 基于表單認(rèn)證）

    • 此外， 還有 Windows 統(tǒng)一認(rèn)證（Keberos 認(rèn)證、 NTLM 認(rèn)證）