目前國內講解HTTP協議的書是在太少了，記憶中有兩本被譽為經典的書《HTTP權威指南》與《TCP/IP詳解，卷1》，但內容晦澀難懂，學習難度較大。其實，HTTP協議并不復雜，理解起來也不會花費太多學習成本，這本書的出現就及時緩解了該問題。對基礎及核心部分的深入學習是成為一名專業技術人員的前提，以不變應萬變才是立足之本。此外，這本書也是我的2016年度讀書計劃中的一本，它和《圖解TCP/IP》一起作為計算機網絡基礎部分為我溫故知新了一把，謝謝作者和譯者，畫了這么多圖解讓我們理解。

   

　　目前國內講解HTTP協議的書是在太少了，記憶中有兩本被譽為經典的書《HTTP權威指南》與《TCP/IP詳解，卷1》，但內容晦澀難懂，學習難度較大。其實，HTTP協議并不復雜，理解起來也不會花費太多學習成本，這本書的出現就及時緩解了該問題。對基礎及核心部分的深入學習是成為一名專業技術人員的前提，以不變應萬變才是立足之本。此外，這本書也是我的2016年度讀書計劃中的一本，它和《圖解TCP/IP》一起作為計算機網絡基礎部分為我溫故知新了一把，謝謝作者和譯者，畫了這么多圖解讓我們理解。

一、HTTP協議初探

　　1.1 各種協議與HTTP協議的關系

　　1.2 請求處理響應模型

　　HTTP協議規定，請求從客戶端發出，最后服務端響應應該請求并返回。

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

　　響應報文：由協議版本、狀態碼、用以解釋狀態碼的原因短語、可選的響應首部字段以及實體主體構成。

　　

　　1.3 HTTP是一種無狀態協議

　　HTTP協議對于發送過的請求或響應都不做持久化處理：協議本身并不保留之前一切的請求或響應報文的信息，這是為了更快地處理大量事務，確保協議的可伸縮性，而特意把HTTP協議設計成如此簡單的。HTTP/1.1雖然是無狀態協議，但為了實現期望的保持狀態功能，于是引入Cookie技術。有了Cookie再用HTTP協議通信，就可以管理狀態了。

　　Cookie根據服務器端發送的響應報文內的一個叫做Set-Cookie的首部字段信息，通知客戶端保存Cookie。當下次客戶端再往該服務器發送請求時，客戶端自動在請求報文中加入Cookie值后發送出去。服務端發現客戶端發送過來的Cookie后，會去檢查究竟是從哪一個客戶端發來的連接請求，然后對比服務器上的記錄，最后得到之前的狀態信息。

　　1.4 告知服務器意圖的HTTP方法

　　（1）GET：獲取資源

　　（2）POST：傳輸實體主體 → POST的主要目的并不是獲取響應的主體內容

　　（3）PUT：傳輸文件 → 就像FTP協議的文件上傳一樣，要求在請求報文的主體中包含文件內容，然后保存到請求URI指定的位置

但是，鑒于HTTP/1.1的PUT方法自身不帶驗證機制，任何人都可以上傳文件，所以存在安全性問題，因此一般的Web網站不使用該方法。

　　（4）HEAD：獲得報文首部 → HEAD與GET一樣，只是不返回報文主體部分，用于確認URI的有效性及資源更新的日期時間等等。

　　（5）DELETE：刪除文件 → DELETE與PUT相反，DELETE按請求URI刪除指定資源。

但是，HTTP/1.1的DELETE方法本身與PUT方法一樣不帶驗證機制，所以一般的Web網站也不使用DELETE方法。　　

　　（6）OPTIONS：詢問支持的方法 → 查詢針對請求URI指定的資源所支持的方法（例如該資源支持GET、POST、PUT等）。

　　（7）TRACE：追蹤路徑 → 讓Web服務器端將之前的請求通信環回給客戶端的方法。（不常用，容易引發XST攻擊）

　　（8）CONNECT：要求用隧道協議連接代理 → 要求在與代理服務器通信時建立隧道，實現用隧道協議進行TCP通信。主要使用SSL和TLS協議把通信內容加密后經過網絡隧道傳輸。

CONNECT方法的格式：CONNECT 代理服務器名：端口號 HTTP版本

　　1.5 持久連接

　　在HTTP協議的初始版本中，每進行一次HTTP通信就要斷開一次TCP連接。因此，每次的請求都會造成無謂的TCP連接建立與斷開，增加通信量的開銷。為了解決這個問題，HTTP/1.1想出了持久連接（也稱為HTTP keep-alive），其特點是：只要任意一端沒有明確提出斷開連接，則保持TCP連接狀態。

持久連接的好處在于減少了TCP連接的重復建立和斷開所造成的額外開銷，減輕了服務器的負載，也使得HTTP請求和響應能夠更早地結束，這樣Web頁面的顯示速度也就相應的提高了。在HTTP/1.1中，所有的連接默認都是持久連接。　　

二、HTTP報文詳解

　　用于HTTP協議交互的信息就被稱為HTTP報文，請求段的叫做請求報文，響應端的叫做響應報文。HTTP報文本身是由多行（用CR+LF作換行符）數據構成的字符串文本。

　　2.1 HTTP報文結構

　　（1）HTTP報文大致可以分為報文首部和報文主體兩塊

　　（2）請求報文和響應報文的結構實例

　　2.2 部分內容的范圍請求

　　通常下載一個大文件時如果遇到網絡中斷的情況，那就必須重頭開始，因此為了解決上述問題，就需要一種可恢復的機制。所謂恢復就是指從之前下載的中斷處恢復下載。要實現該功能需要制定下載的實體范圍，這就叫范圍請求（Range Request）。

　　對一份10000字節大小的資源，如果使用范圍請求，可以只請求5001~10000字節內的資源。執行范圍請求時，就會用到Range來指定資源的byte范圍。

　　2.3 內容協商機制

　　內容協商機制就是指在客戶端和服務端就響應的資源內容進行交涉，然后提供給客戶端最為合適的資源。內容協商會議響應資源的語言、字符集、編碼方式等作為判斷的基準。

So，有哪些判斷的基準呢？

Accept

Accept-Charset

Accept-Encoding

Accept-Language

Content-Language

　　2.4 HTTP狀態碼

　　HTTP狀態碼負責表示客戶端HTTP請求的返回結果、標記服務器端的處理是否正常、通知出現的錯誤等工作。借助狀態碼，用戶可以知道服務器端是正常處理了請求，還是出現了錯誤。

　　（1）2XX 成功 → 表明請求被正常處理了，如200 OK，204 No Content，206 Partial Content

　　（2）3XX 重定向 → 表明瀏覽器需要執行某些特殊的處理以正確處理請求。如301 Moved Permanently（永久移動），302 Found（臨時移動），303 See Other（資源的URI已更新，是否能臨時按新的URI訪問）、304 Not Modified（資源已找到，但未符合條件請求）、307 Temporary Redirect（臨時重定向）

　　（3）4XX 客戶端錯誤 → 表明客戶端是發生錯誤的原因所在。如400 Bad Request（請求報文中存在語法錯誤），401 Unauthorized（認證失敗或未認證）、403 Forbidden（不允許訪問這個資源）、404 Not Found（服務器上沒有請求的資源）。

　　（4）5XX 服務器錯誤 → 表明服務器本身發生錯誤。如500 Internal Server Error（服務器端在執行請求時發生了錯誤，也可能是Web應用存在的Bug或某些臨時的故障），503 Service Unavailable（表明服務器暫時處于超負載或正在停機維護，無法處理請求）。

　　2.5 HTTP首部

　　　HTTP/1.1規范定義了如下47種首部字段：

　　（1）通用首部字段

　　（2）請求首部字段　

　　（3）響應首部字段

　　（4）實體首部字段

三、確保Web安全

　　3.1 HTTPS

　　在HTTP協議中有可能存在信息竊聽或者身份偽裝等安全問題，即使已經過加密處理的通信，也會被窺視到通信內容。例如：使用一些抓包軟件如Packet Capture或Sniffer就可以抓取相同段上的通信。使用HTTPS（HTTP Secure）通信機制就可以有效地防止這些問題。

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

　　HTTPS并非是應用層的一種新協議，只是HTTP通信接口部分用SSL（Secure Socket Layer）和TLS（Transport Layer Security）協議代替而已。通常情況下，HTTP直接和TCP通信，當使用SSL時，則演變成先和SSL通信，再由SSL和TCP通信了。簡而言之，所謂HTTPS，其實就是身披SSL協議這層外殼的HTTP。

　　SSL是獨立于HTTP的協議，所以不光是HTTP協議，其他運行在應用層的SMTP和Telnet等協議均可配合SSL協議使用。可以說，SSL是當今世界上應用最為廣泛的網絡安全技術。在采用了SSL之后，HTTP就擁有了HTTPS的加密、證書和完整性保護這些功能。

　　既然HTTPS安全可靠，那為何所有的Web網站不一直使用HTTPS？

一是因為與純文本通信相比，加密通信會消耗更多的CPU以及內存資源。如果每次通信都加密，會消耗相當多的資源，平攤到一臺計算機上時，能夠處理的請求數量必定會隨之減少。

二是購買證書的開銷也很大，要進行HTTPS通信，證書是必不可少的，而使用的證書必須要向認證機構（CA）購買。通常，一年的授權費用需要600人民幣左右。　　

所以，如果是非敏感信息一般都使用HTTP通信，只有在包含個人信息等敏感數據時，才會使用HTTPS加密通信。

　　3.2 確認訪問用戶身份的認證

　　某些Web頁面只想讓特定的人瀏覽，或者干脆本人可見。未達到這個目標，必不可少的就是認證功能。

　　HTTP/1.1使用的認證方式如下：

　　（1）BASIC認證（基本認證） → 不夠靈活，達不到多數Web網站期望的安全性等級（直接發送明文密碼BASE64編碼），因此它并不常用。

　　（2）DIGEST認證（摘要認證） → 采用質詢響應方式，相比BASIC認證，密碼泄露的可能性就降低了。

　　（3）SSL客戶端認證 → 借助HTTPS的客戶端證書完成認證，憑借客戶端證書認證，服務器可確認訪問是否來自已登錄的客戶端。

　　（4）FormBase認證（基于表單認證）

通常情況下，一種安全的保存方法是：先利用密碼加鹽（Salt）的方式增加額外信息，再使用散列（Hash）函數計算出散列值后保存。

四、Web的攻擊技術

　　4.1 針對Web應用的攻擊模式

　　（1）主動攻擊：攻擊者通過直接訪問Web應用，把攻擊代碼傳入的攻擊模式。最具典型的攻擊就是 SQL注入攻擊和OS命令注入攻擊。

　　（2）被動攻擊：利用圈套策略執行攻擊代碼地攻擊模式，在被動攻擊過程中，攻擊者不直接對目標Web應用訪問發起攻擊。

　　4.2 跨站腳本攻擊（XSS）

　　跨站腳本攻擊（Cross-Site Scripting,XSS）是指通過存在安全漏洞的Web網站注冊用戶的瀏覽器內運行非法的HTML標簽或者JavaScript腳本進行攻擊的一種攻擊。

　　跨站腳本攻擊可以造成以下影響：

　　（1）利用虛假輸入表單騙取用戶個人信息。

　　（2）利用腳本竊取用戶的Cookie值，被害者在不知情的情況下，幫助攻擊者發送惡意請求。

　　（3）顯示偽造的文章或者圖片。

　　4.3 SQL注入攻擊

 　　SQL注入（SQL Injection）是指針對Web應用使用的數據庫，通過運行非法的SQL而產生的攻擊。該安全隱患有可能引起極大地威脅，有時會直接導致個人信息及機密信息的泄露。

　　SQL注入攻擊有可能造成以下影響：

　　（1）非法查看或篡改數據庫內的數據。

　　（2）規避認證。

　　（3）執行和數據庫服務器業務關聯的程序等。

　　4.4 OS命令注入攻擊

　　OS命令注入攻擊是指通過Web應用，執行非法的操作系統命令達到攻擊的目的。只要在能調用Shell函數的地方就有存在被攻擊的風險。

　　4.5 HTTP首部注入攻擊

　　HTTP首部注入攻擊是指攻擊者通過在響應首部字段內插入換行，添加任意響應首部或主題的一種攻擊。屬于被動攻擊模式。

　　4.6 因會話管理疏忽引發的安全漏洞

　　（1）會話劫持：攻擊者通過某種手段拿到了用戶的會話ID，并非法使用此會話ID偽裝成用戶，達到攻擊的目的。

　　（2）會話固定攻擊：強制用戶使用攻擊者指定的會話ID，屬于被動攻擊。

　　（3）跨站點請求偽造（Cross-Site Request Forgeries，CSRF）：攻擊者通過設置好的陷阱，強制對已完成認證的用戶進行非預期的個人信息或設定信息等某些狀態更新，屬于被動攻擊。

　　CSRF有可能造成以下影響：

1、利用已通過認證的用戶權限更新設定信息等；

2、利用已通過認證的用戶權限購買商品；

3、利用已通過認證的用戶權限在留言板上發表言論等；

　　4.7 DoS攻擊

　　DoS攻擊（Denial of Service attack）是一種讓運行中的服務呈停止狀態的攻擊。有時也叫作服務停止或拒絕服務攻擊。主要有以下兩種DoS攻擊方式：

　　（1）集中利用訪問請求造成資源過載，資源用盡的同時，實際上也就呈停止狀態。

　　單純來講，就是發送大量的合法請求，服務器很難分辨何為正常請求，何為攻擊請求，因此很難防止DoS攻擊。多臺計算機發起的DoS攻擊成為DDoS攻擊（Distributed Denial of Service attack），DDoS攻擊通常利用那些感染病毒的計算機作為攻擊者的攻擊跳板。

　　（2）通過攻擊安全漏洞使服務停止。