前言

本書對互聯網基盤——HTTP協議進行了全面系統的介紹。做者由HTTP協議的發展歷史娓娓道來，嚴謹細緻地剖析了HTTP協議的結構，列舉諸多常見通訊場景及實戰案例，最後延伸到Web安全、最新技術動向等方面。本書的特點爲在講解的同時，輔以大量生動形象的通訊圖例，更好地幫助讀者深入理解HTTP通訊過程當中客戶端與服務器之間的交互狀況。讀者可經過本書快速瞭解並掌握HTTP協議的基礎，前端工程師分析抓包數據，後端工程師實現REST API、實現本身的HTTP服務器等過程當中所需的HTTP相關知識點本書均有介紹。html

本書適合Web開發工程師，以及對HTTP協議感興趣的各層次讀者。前端

第一章、瞭解 WEB 及網絡基礎

HTTP 的誕生後端

1989年3月，HTTP 誕生了，最初設想的理念是：藉助多文本之間互相關聯造成的超文本，連成 WWW。瀏覽器

Web 成長時代緩存

1990年11月，CERN 研發了世界上第一臺 WEB 服務器。安全

1990年，你們針對 HTML1.0 草案進行討論，因存在多處模糊的地方，草案被直接廢棄。服務器

1992年9月，日本第一個網站的主頁上線了。網絡

1993年1月，現代瀏覽器的祖先 Mosaic 問世，它之內聯等形式顯示 HTML 的圖像，迅速在世界範圍內流行開來。前端工程師

1994年12月，網景公司發佈 Netscape Navigator 1.0。分佈式

1995年，微軟發佈了 Internet Explorer 1.0 和 2.0。

駐足不前的 HTTP

HTTP 0.9 ：由於那時的 HTTP 並無正式的標準被創建，全部含有 HTTP 1.0 以前版本的意思。

HTTP 1.0 ：1996年5月正式做爲標準被公佈，並記載於 RFC1945。

HTTP 1.1 ：1997年1月公佈，最新標準版本爲 RFC2616。

網絡基礎 TCP/IP

一般使用的網絡（包括互聯網）是在 TCP/IP 協議族的基礎上運做的。而 HTTP 屬於它內部的一個子集。

TCP/IP 協議族

TCP/IP 是互聯網相關的各種協議族的總稱。

TCP/IP 的分層管理

分爲四層：

  • 應用層：決定了向用戶提供應用服務時通訊的活動，例如：FTP、DNS、HTTP。
  • 傳輸層：提供處於網絡鏈接中的兩臺計算機之間的數據傳輸，TCP、UDP。
  • 網絡層：處理在網絡上流動的數據包，規定傳輸路線。
  • 數據鏈路層：處理鏈接網絡的硬件部分。包括控制操做系統、硬件的設備驅動、網卡及光纖等物理可見部分。

分層的好處：把各層之間的接口部分規劃好後，修改某個地方時只需修改對應的層，每一個層次內部不影響其餘層。

TCP/IP 通訊傳輸流

HTTP 舉例：

與 HTTP 關係密切的協議 : IP、TCP 和DNS

  • 負責傳輸的 IP 協議

  • 確保可靠性的 TCP 協議

  • 負責域名解析的 DNS 服務

各類協議與 HTTP 協議的關係

第二章、簡單的 HTTP 協議

HTTP 協議用於客戶端和服務器之間的通訊，請求資源方成爲客戶端，提供資源響應方成爲服務器端。

請求報文是由請求方法、請求 URI、協議版本、可選的請求首部字段和內容實體構成的。

請求報文的構成：

響應報文的構成：

HTTP 是不保存狀態的協議

HTTP 是一個無狀態協議，自身不具有保存以前發送過的請求或響應的功能。

以後隨着發展，引入了 Cookie 技術。

請求 URI 定位資源

HTTP 協議使用 URI 定位互聯網上的資源。正是由於 URI 的特定功能，在互聯網上任意位置的資源都能訪問到。

告知服務器意圖的 HTTP 方法

持久鏈接節省通訊量

HTTP 協議的初始版本中，每進行一次 HTTP 通訊就要斷開一次 TCP鏈接。

持久鏈接

爲解決上述 TCP 鏈接的問題，HTTP/1.1 和一部分的 HTTP/1.0 想出了持久鏈接的方法。

持久鏈接的特色是，只要任意一端沒有明確提出斷開鏈接，則保持 TCP 鏈接狀態。

好處在於減小了 TCP 鏈接的重複創建和斷開所形成的額外開銷，減輕了服務器端的負載。

管線化

管線化技術出現後，可以作到同時並行發送多個請求，而不須要一個接一個地等待響應了。

使用 Cookie 的狀態管理

Cookie 技術經過在請求和響應報文中寫入 Cookie 信息來控制客戶端的狀態。

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

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

第三章、HTTP 報文內的 HTTP信息

HTTP 報文

用於 HTTP 協議交互的信息被稱爲 HTTP 報文。

HTTP 報文自己是由多行（用 CR+LF 做換行符）數據構成的字符串文本。

HTTP 報文大體可分爲報文首部和報文主體兩塊，一般，並不必定要有報文主體。

結構

實例

編碼提高傳輸速率

HTTP 在傳輸時能夠原樣直接傳輸，也能夠在傳輸時經過編碼提高傳輸速率，經過編碼，能有效地處理大量的訪問請求，但也消耗更多的 CPU 等資源。

報文主體和實體主體的差別

  • 報文：HTTP 通訊中的基本單位，由8位組字節流組成，經過 HTTP 通訊傳輸。
  • 實體：做爲請求或響應的有效載荷數據（補充項）被傳輸，其內容由實體首部和實體主體組成。

壓縮傳輸的內容編碼

經常使用的內容編碼有如下幾種：

  • gzip（GNU zip）
  • compress（UNIX 系統的標準壓縮）
  • deflate（zlib）
  • identity（不進行編碼）

分割發送的分塊傳輸編碼

在傳輸大容量數據時，經過把數據分割成多塊，可以讓瀏覽器逐步顯示頁面，這種把實體主體分塊的功能稱爲分塊傳輸編碼。

分塊傳輸編碼會將實體主體分紅多個部分（塊）。每一塊都會用十六進制來標記塊的大小，而實體主體的最後一塊會使用「0(CR+LF)」來標記。

發送多種數據的多部分對象集合

發送的一份報文主體內可含有多類型實體。一般是在圖片或文本文件等上傳時使用。

多部分對象集合包含的對象以下：

  • multipart/form-data：在 Web 表單文件上傳時使用。
  • multipart/byteranges：狀態碼 206，響應報文包含了多個範圍的內容時使用。

獲取部份內容的範圍請求

爲了解決加載超大圖片致使網絡中斷的狀況而實現的一種手段，叫作範圍請求。

對一份 10 000 字節大小的資源，若是使用範圍請求，能夠只請求5001~10 000 字節內的資源。

內容協商返回最合適的內容

當瀏覽器的默認語言爲英語或中文，訪問相同 URI 的 Web 頁面時，則會顯示對應的英語版或中文版的 Web 頁面。這樣的機制稱爲內容協商。

第四章、返回結果的狀態碼

HTTP 狀態碼負責表示客戶端 HTTP 請求的返回結果、標記服務器端的處理是否正常、通知出現的錯誤等工做。

狀態碼類別：

更多：HTTP 響應代碼

第五章、與 HTTP 協做的 Web 服務器

用單臺虛擬主機實現多個域名

即使物理層面只有一臺服務器，但只要使用虛擬主機的功能，則能夠搭建多個站點。

通訊數據轉發程序：代理、網關、隧道

HTTP 通訊時，除客戶端和服務器之外，還有一些用於通訊數據轉發的應用程序：

  • 代理：一種有轉發功能的應用程序，扮演了服務器和客戶端中間人的角色。
  • 網關：轉發其餘服務器通訊數據的服務器，它就像本身擁有資源的源服務器同樣對請求進行處理。

  • 隧道：將相隔甚遠的客戶端和服務器二者之間進行中轉，並保持雙方通訊鏈接的應用程序。

    保存資源的緩存

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

客戶端的緩存

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

第六章、HTTP 首部

注：這部分太多解釋，建議看原文

HTTP 請求報文

在請求中，HTTP 報文由方法、URI、HTTP 版本、HTTP 首部字段等部分構成

HTTP 響應報文

在響應中，HTTP 報文由 HTTP 版本、狀態碼（數字和緣由短語）、HTTP 首部字段 3 部分構成。

HTTP/1.1 首部字段一覽

通用首部字段：

請求首部字段：

響應首部字段：

實體首部字段：

第七章、HTTP 的缺點

主要的不足，例舉以下：

  • 通訊使用明文（不加密），內容可能會被竊聽（例如：抓包）
  • 不驗證通訊方的身份，所以有可能遭遇假裝（例如：DoS）
  • 沒法證實報文的完整性，因此有可能已遭篡改（例如：中間人攻擊）

HTTP+ 加密 + 認證 + 完整性保護=HTTPS

爲了統一解決上述這些問題，須要在 HTTP 等機制。咱們把添加了加密及認證機制的稱爲 HTTPS。

使用 HTTPS 通訊

常常會在 Web 的登陸頁面和購物結算界面等使用 HTTPS 通訊。

HTTPS 是身披 SSL 外殼的 HTTP

HTTPS 並不是是應用層的一種新協議。只是 HTTP 通訊接口部分用 SSL 和 TLS 協議代替而已。

簡言之，所謂 HTTPS，其實就是身披SSL 協議這層外殼的 HTTP。

SSL 是獨立於 HTTP 的協議，因此不光是 HTTP 協議，其餘運行在應用層的 SMTP 和 Telnet 等協議都可配合 SSL 協議使用。能夠說 SSL 是當今世界上應用最爲普遍的網絡安全技術。

相互交換密鑰的公開密鑰加密技術

SSL 採用一種叫作公開密鑰加密（非對稱加密）的加密處理方式。

HTTPS 的安全通訊機制

通訊步驟：

SSL 速度慢嗎

HTTPS 也存在一些問題，那就是當使用 SSL 時，它的處理速度會變慢。

HTTPS 比 HTTP 要慢 2 到 100 倍，由於與純文本通訊相比，加密通訊會消耗更多的CPU 及內存資源。若是每次通訊都加密，會消耗至關多的資源，平攤到一臺計算機上時，可以處理的請求數量一定也會隨之減小。

第八章、確認訪問用戶身份的認證

何爲認證

服務器爲了確認用戶的身份，一般須要覈對一些信息：

  • 密碼
  • 動態令牌
  • 數字證書
  • 生物認證
  • IC 卡

HTTP 使用的認證方式

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

第九章、基於 HTTP 的功能追加協議

消除 HTTP 瓶頸的 SPDY

Google 在 2010 年發佈了 SPDY（取自 SPeeDY，發音同 speedy），其開發目標旨在解決 HTTP 的性能瓶頸，縮短 Web 頁面的加載時間（50%）。

SPDY 的目標

陸續出現的 Ajax 和 Comet 等提升易用性的技術，必定程度上使 HTTP獲得了改善，但 HTTP 協議自己的限制也使人有些一籌莫展。爲了進行根本性的改善，須要有一些協議層面上的改動。

處於持續開發狀態中的 SPDY 協議，正是爲了在協議級別消除 HTTP所遭遇的瓶頸。

使用 SPDY 後，HTTP 協議額外得到如下功能。

  • 多路複用流：經過單一的 TCP 鏈接，能夠無限制處理多個 HTTP 請求。
  • 賦予請求優先級：能夠給請求逐個分配優先級順序。這樣主要是爲了在發送多個請求時，解決因帶寬低而致使響應變慢的問題。
  • 壓縮 HTTP 首部
  • 推送功能：支持服務器主動向客戶端推送數據的功能。
  • 服務器提示功能：服務器能夠主動提示客戶端請求所需的資源。

使用瀏覽器進行全雙工通訊的WebSocket

利用 Ajax 和 Comet 技術進行通訊能夠提高 Web 的瀏覽速度。但問題在於通訊若使用 HTTP 協議，就沒法完全解決瓶頸問題。WebSocket網絡技術正是爲解決這些問題而實現的一套新協議及 API。

WebSocket 協議

主要特色：

  • 推送功能：支持由服務器向客戶端推送數據的推送功能。
  • 減小通訊量：只要創建起 WebSocket 鏈接，就但願一直保持鏈接狀態。

期盼已久的 HTTP/2.0

特色：

Web 服務器管理文件的 WebDAV

WebDAV（基於萬維網的分佈式創做和版本控制）是一個可對 Web 服務器上的內容直接進行文件複製、編輯等操做的分佈式文件系統。

第十章、構建 Web 內容的技術

  • HTML
  • CSS
  • JavaScript
  • 動態 HTML
  • CGI
  • Servlet
  • XML
  • RSS/Atom
  • JSON

第十一章、Web 的攻擊技術

對 Web 應用的攻擊模式有如下兩種：

  • 主動攻擊：是指攻擊者經過直接訪問 Web 應用，把攻擊代碼傳入的攻擊模式
  • 被動攻擊：指利用圈套策略執行攻擊代碼的攻擊模式

因輸出值轉義不徹底引起的安全漏洞：

  • XSS 注入
  • SQL 注入
  • OS 命令注入
  • HTTP 首部注入攻擊
  • 郵件首部注入攻擊
  • 目錄遍歷攻擊

  • 遠程文件包含漏洞

    因設置或設計上的缺陷引起的安全漏洞：

  • 強制瀏覽

  • 不正確的錯誤信息處理
  • 開放重定向

因會話管理疏忽引起的安全漏洞：

  • 會話劫持
  • 會話固定攻擊
  • 跨站點請求僞造

其餘安全漏洞：

  • 密碼破解
  • 點擊劫持
  • DoS 攻擊
  • 後門程序