圖解HTTP

書名：圖解HTTP 類型：計算機專業書籍 作者簡介 ：上野宣，OWASP日本分會會長，TRICORDER株式會社董事長。主要從事安全諮詢、風險評估、信息安全教育等工作，著有<今晚我們一起學習郵件協議>、<今晚我們一起學習TCP/IP>、<今晚我們一起學習HTTP>等。 點評： 依稀記得2014年的時候，我曾花費了至少一個星期的時間去系統學習Http的知識，以期待對Http協議有一個全面的認知。一則是因爲http協議是一門基礎知識，到處會有使用；一則是能夠忽悠面試官，不會顯得啥都不會。 自以爲當時整理的Http知識很全面：有請求報頭合適，有響應報頭格式，有各種類型的報頭以及他們的詳細說明，有各種響應狀態碼及其含義。當然也有考慮到安全的問題，比如Https協議、各種Web攻擊等，但是也都是隻言片語，寫的很淺。 現在讀完本書才發現，這本書原來就是我當時希望看到的書，書中所涵蓋的內容，比我自己總結的內容更加全面，而且更加淺顯易懂。真是相見恨晚，或許這本書在2013年而不是2014年出版，會省去我不少事情。 所有的技術方案都是爲了解決特定的問題而存在，問題不在了也就不存在所謂的技術。所以學習技術的首要事情是：瞭解所面臨的問題。 好了，閒話不多扯了，做個筆記，下次看的時候可以更快。 1. http版本 Http於1990年問世，那時的HTTP並沒有作爲正式的標準被建立。這時的HTTP其實含有HTTP/ 1.0之前版本的意思，因此被稱爲HTTP/0.9。 HTTP正式作爲標準被公佈是在1996年的5月，版本被命名爲HTTP/1.0，並記載於RFC1945。 1997年1月公佈的HTTP/1.1是目前主流的HTTP協議版本。 HTTP2.0是HTTP協議自1999年HTTP 1.1發佈後的首個更新，主要基於SPDY協定。它由互聯網工程任務組（IETF）的Hypertext Transfer Protocol Bis（httpbis）工作小組進行開發。[2]該組織於2014年12月將HTTP/2標準提議遞交至IESG進行討論[3]，於2015年2月17日被批准。 2. http各個版本之間的區別 方面HTTP協議的出現主要是爲了解決文本傳輸的難題。 HTTP是一種不保存狀態，即無狀態（stateless）協議。HTTP協議自身不對請求和響應之間的通信狀態進行保存。也就是說在HTTP這個級別，協議對於發送過的請求或響應都不做持久化處理。 HTTP/1.1雖然是無狀態協議，但爲了實現期望的保持狀態功能，於是引入了Cookie技術。有了Cookie再用HTTP協議通信，就可以管理狀態了。 HTTP主要有這些不足：通信使用明文（不加密），內容可能會被竊聽；不驗證通信方的身份，因此有可能遭遇僞裝；無法證明報文的完整性，所以有可能已遭。Https就是爲了解決這些問題而存在。 HTTP+加密+認證+完整性保護=HTTPS。 HTTP標準的瓶頸： 一條連接上只可發送一個請求。 ●請求只能從客戶端開始。客戶端不可以接收除響應以外的指令。 ●請求/響應首部未經壓縮就發送。首部信息越多延遲越大。 ●發送冗長的首部。每次互相發送相同的首部造成的浪費較多。 ●可任意選擇數據壓縮格式。非強制壓縮發送 爲了解決這些問題就出現了SPDY協議。Http2.0基於SPDY協議實現的。 3. http協議格式 請求報文：請求報頭+空行+實體 響應報文：響應報頭+空行+實體 請求報頭：請求行+報頭（請求首部+通用首部+實體首部） 響應報頭：響應狀態行+報頭（響應首部+通用首部+實體首部） 報頭首部類型：請求首部、響應首部、通用首部、實體首部 有哪些報頭，都什麼作用，自己看。 請求方法有哪些自己看 響應狀態碼有哪些自己看 4. 代理、網關、隧道的區別 代理是黃牛，倒買倒賣，手上沾點油。不改動，服務端一定使用的是Http。比如一般的CDN服務器。 網關是一個人工服務員，對外提供統一的服務，客戶不用與各種內部接口人一一對接。網關的上游服務器可能使用的是ftp、mail等非http協議。比如三大電影運營商。 隧道也是一個祕密的暗道，其他人沒法窺探裏面的內容。比如shadowsocket 5. CA認證機構 https協議會使用非對稱加密，但非對稱加密中公開密鑰存在的身份認證問題，即怎麼證明我是我的問題。這個時候就出現了第三者：CA認證機構。所有需要使用數字簽名的網站，就把身份認證的事情交給CA來完成。 那麼CA認證機構也出現一個尷尬的問題。怎麼證明自己是自己的問題。你CA是假的怎麼辦？那麼這個時候的解決辦法就是將所有頂級的CA的公鑰在瀏覽器裏面都內置一份。對的，每個瀏覽器在出廠的時候，都會存一些CA認證機構的照片，這樣就假不了了。 6. 關於SSL SSL技術最初是由瀏覽器開發商網景通信公司率先倡導的，開發過SSL3.0之前的版本。目前主導權已轉移到IETF（Internet Engineering Task Force,Internet工程任務組）的手中。 IETF以SSL3.0爲基準，後又制定了TLS1.0、TLS1.1和TLS1.2。TSL是以SSL爲原型開發的協議，有時會統一稱該協議爲SSL。當前主流的版本是SSL3.0和TLS1.0 SSL的慢分兩種。一種是指通信慢。另一種是指由於大量消耗CPU及內存等資源，導致處理速度變慢。這個就是SSL雞肋之處。所以Https的使用就需要考慮成本的問題。 7. 服務器端考慮的幾個問題 怎麼省流量？怎麼減少機器資源的消耗？怎麼保證緩存一致性？怎麼保證可靠性？怎麼保證拓展性，保證各個業務分離？簡言之，快、穩、省、準。 8. 關於Web完全 There is a door，there is a way！ 有和外部交互的地方，那麼就存在安全問題的可能。只要外部能夠把數據送到你服務端，那麼就存在安全風險的可能。具體就可能是怎麼把數據送進去的問題了。 有的可能是通過在客戶端入手，把私貨夾帶進入；而有的是路上動手，中間人劫持；還有人是直接在服務端動手，破解你root權限；發一份釣魚郵件，先送到你內網再說，你點開了，那麼這個雷就埋好了。 當然上述都是主動劫持，還有被動劫持。那麼就是對用戶下手。 發一發釣魚網站，添加XSS跨域攻擊，把用戶的信息在不知不覺中上傳到黑客的網站上。 當然說的很輕巧，這些都是要找到代碼的漏洞，必須熟悉各種方式，然後才能知道會存在哪些bug。這條路很長很長。 差點忘了，我原來還是個程序員～

瀏覽器地址欄輸入地址到頁面渲染完成發生了什麼?  1.瀏覽器進行地址解析，獲取該地址的端口號、域名、協議、路徑等信息。  2.將解析的域名進行DNS解析。  3.通過ip地址尋找服務器地址  4.與服務器進行三次握手建立連接  5.瀏覽器發送數據，等待服務器的響應  6.服務器響應並返回數據  7.瀏覽器接收到數據  8.瀏覽器開始渲染頁面 URI與URL URI，是uniform resource identifier，統一資源標識符，用來唯一的標識一個資源。  URL是uniform resource locator，統一資源定位器，它是一種具體的URI，即URL可以用來標識一個資源，而且還指明瞭如何locate這個資源。 HTTP1.0和HTTP1.1的區別  1.長連接 -- HTTP1.1支持長連接和請求的流水線處理，在一個TCP連接上可以傳送多個HTTP請求和響應，減少了建立和關閉連接的消耗和延遲。HTTP1.0每次請求都要創建連接。  2.節約帶寬 -- HTTP1.1支持只發送header信息（不帶任何body信息），如果服務器認爲客戶端有權限請求服務器，則返回100，客戶端接收到100纔開始把請求body發送到服務器；如果返回401，客戶端就可以不用發送請求body了節約了帶寬。 HOST域 -- 在HTTP1.0中認爲每臺服務器都綁定一個唯一的IP地址，因此，請求消息中的URL並沒有傳遞主機名，HTTP1.0沒有host域。HTTP1.1的請求消息和響應消息都支持host域，且請求消息中如果沒有host域會報告一個錯誤（400 Bad Request）。  3.緩存處理 -- 在HTTP1.0中主要使用header裏的If-Modified-Since,Expires來做爲緩存判斷的標準，HTTP1.1則引入了更多的緩存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的緩存頭來控制緩存策略。  4. 錯誤通知的管理 -- 在HTTP1.1中新增了24個錯誤狀態響應碼，如409（Conflict）表示請求的資源與資源的當前狀態發生衝突；410（Gone）表示服務器上的某個資源被永久性的刪除。  HTTP1.1和HTTP2.0的區別  1.多路複用 --HTTP2.0使用了多路複用的技術，做到同一個連接併發處理多個請求，而且併發請求的數量比HTTP1.1大了好幾個數量級。 頭部數據壓縮 -- HTTP1.1不支持header數據的壓縮，HTTP2.0使用HPACK算法對header的數據進行壓縮，這樣數據體積小了，在網絡上傳輸就會更快。  2.服務器推送 -- 服務端推送是一種在客戶端請求之前發送數據的機制。網頁使用了許多資源：HTML、樣式表、腳本、圖片等等。在HTTP1.1中這些資源每一個都必須明確地請求。服務器必須等待瀏覽器做每一個請求，網絡經常是空閒的和未充分使用的。爲了改善延遲，HTTP2.0引入了server push，它允許服務端推送資源給瀏覽器，在瀏覽器明確地請求之前，免得客戶端再次創建連接發送請求到服務器端獲取。這樣客戶端可以直接從本地加載這些資源，不用再通過網絡。 五層體系結構包括：應用層、運輸層、網絡層、數據鏈路層和物理層  1.應用層：直接爲用戶的應用進程（例如電子郵件、文件傳輸和終端仿真）提供服務。  相關協議：HTTP、FTP、DNS、SMTP、Telnet等  2.運輸層：負責向兩個主機中進程之間的通信提供服務。由於一個主機可同時運行多個進程，因此運輸層有複用和分用的功能  相關協議：TCP、UDP等  3.網絡層：在位於不同地理位置的網絡中的兩個主機系統之間提供連接和路徑選擇  相關協議：IP、ICMP等  4.數據鏈路層：定義瞭如何讓格式化數據以進行傳輸，以及如何讓控制對物理介質的訪問。這一層通常還提供錯誤檢測和糾正，以確保數據的可靠傳輸。  相關協議：ARP、RARP等  5.物理層：主要定義物理設備標準，如網線的接口類型、光纖的接口類型、各種傳輸介質的傳輸速率等。它的主要作用是傳輸比特流。 三次握手：  1、第一次握手：客戶端給服務器發送一個 SYN 報文。  2、第二次握手：服務器收到 SYN 報文之後，會應答一個 SYN+ACK 報文。  3、第三次握手：客戶端收到 SYN+ACK 報文之後，會回應一個 ACK 報文。  4、服務器收到 ACK 報文之後，三次握手建立完成。  四次揮手：  1、第一次揮手：客戶端發送一個 FIN 報文，報文中會指定一個序列號。此時客戶端處於FIN_WAIT1狀態。 2、第二次握手：服務端收到 FIN 之後，會發送 ACK 報文，且把客戶端的序列號值 + 1 作爲 ACK 報文的序列號值，表明已經收到客戶端的報文了，此時服務端處於 CLOSE_WAIT狀態。 3、第三次揮手：如果服務端也想斷開連接了，和客戶端的第一次揮手一樣，發給 FIN 報文，且指定一個序列號。此時服務端處於 LAST_ACK 的狀態。  4、第四次揮手：客戶端收到 FIN 之後，一樣發送一個 ACK 報文作爲應答，且把服務端的序列號值 + 1 作爲自己 ACK 報文的序列號值，此時客戶端處於 TIME_WAIT 狀態。需要過一陣子以確保服務端收到自己的 ACK 報文之後纔會進入 CLOSED 狀態 5、服務端收到 ACK 報文之後，就處於關閉連接了，處於 CLOSED 狀態。 DNS域名解析過程：  1.在瀏覽器中輸入域名，操作系統會先檢查自己本地的hosts文件是否有這個網址映射關係，如果有，就先調用這個IP地址映射，完成域名解析。  2、如果hosts裏沒有這個域名的映射，則查找本地DNS解析器緩存，是否有這個網址映射關係，如果有，直接返回，完成域名解析。  3、如果hosts與本地DNS解析器緩存都沒有相應的網址映射關係，首先會找TCP/IP參數中設置的首選DNS服務器，在此我們叫它本地DNS服務器，此服務器收到查詢時，如果要查詢的域名，包含在本地配置區域資源中，則返回解析結果給客戶機，完成域名解析。  4、如果要查詢的域名，不由本地DNS服務器區域解析，但該服務器已緩存了此網址映射關係，則調用這個IP地址映射，完成域名解析。  5、如果本地DNS服務器本地區域文件與緩存解析都失效，則根據本地DNS服務器的設置（是否設置轉發器）進行查詢，如果未用轉發模式，本地DNS就把請求發至13臺根DNS，根DNS服務器收到請求後會判斷這個域名是誰來授權管理，並會返回一個負責該頂級域名服務器的一個IP。  6、如果用的是轉發模式，此DNS服務器就會把請求轉發至上一級DNS服務器，由上一級服務器進行解析，上一級服務器如果不能解析，或找根DNS或把轉請求轉至上上級，以此循環。不管是本地DNS服務器用是是轉發，還是根提示，最後都是把結果返回給本地DNS服務器，由此DNS服務器再返回給客戶機。 http協議格式 請求報文：請求報頭+空行+實體 響應報文：響應報頭+空行+實體 請求報頭：請求行+報頭（請求首部+通用首部+實體首部） 響應報頭：響應狀態行+報頭（響應首部+通用首部+實體首部） 報頭首部類型：請求首部、響應首部、通用首部、實體首部 資源表述性狀態轉移 根據數據抽象出來的資源，以某種表現形式，通過某種手段，在網絡中發生狀態轉移，以此來間接實現操作資源的目的。 如果一個架構符合REST原則，就稱它爲RESTful架構。  1.每一個URI代表一種資源；  2.客戶端和服務器之間，傳遞這種資源的某種表現層；  3.客戶端通過四個HTTP動詞，對服務器端資源進行操作，實現"表現層狀態轉化"。 使用 cookie 時需要考慮的問題:  1.因爲存儲在客戶端，容易被客戶端篡改，使用前需要驗證合法性  2.不要存儲敏感數據，比如用戶密碼，賬戶餘額  3.使用 httpOnly 在一定程度上提高安全性  4.儘量減少 cookie 的體積，能存儲的數據量不能超過 4kb  5.設置正確的 domain 和 path，減少數據傳輸  6.cookie 無法跨域  7.一個瀏覽器針對一個網站最多存 20 個Cookie，瀏覽器一般只允許存放 300 個Cookie  8.移動端對 cookie 的支持不是很好，而 session 需要基於 cookie 實現，所以移動端常用的是 token  使用 session 時需要考慮的問題:  1.將 session 存儲在服務器裏面，當用戶同時在線量比較多時，這些 session 會佔據較多的內存，需要在服務端定期的去清理過期的 session  2.session 是由單個服務器創建的,當網站採用集羣部署的時候，會遇到多臺 web 服務器之間如何做 session 共享的問題。  3.當多個應用要共享 session 時，除了以上問題，還會遇到跨域問題，因爲不同的應用可能部署的主機不一樣，需要在各個應用做好 cookie 跨域的處理。 4.sessionId 是存儲在 cookie 中的，假如瀏覽器禁止 cookie 或不支持 cookie,一般會把 sessionId 跟在 url 參數後面即重寫 url，所以 session 不一定非得需要靠 cookie 實現  5.移動端對 cookie 的支持不是很好，而 session 需要基於 cookie 實現，所以移動端常用的是 token  使用 token 時需要考慮的問題:  1.如果你認爲用數據庫來存儲 token 會導致查詢時間太長，可以選擇放在內存當中。比如 redis 很適合你對 token 查詢的需求。  2.token 完全由應用管理，所以它可以避開同源策略  3.token 可以避免 CSRF 攻擊  4.移動端對 cookie 的支持不是很好，而 session 需要基於 cookie 實現，所以移動端常用的是 token HTTP/1.1首部字段 1.首部字段Upgrade用於檢測HTTP協議及其他協議是否可使用更高的版本進行通信，其參數值可以用來指定一個完全不同的通信協議。 2.使用首部字段Via是爲了追蹤客戶端與服務器之間的請求和響應報文的傳輸路徑。報文經過代理或網關時，會先在首部字段Via中附加該服務器的信息，然後再進行轉發。Via首部是爲了追蹤傳輸路徑，所以經常會和TRACE方法一起使用。 3.Accept首部字段可通知服務器，用戶代理能夠處理的媒體類型及媒體類型的相對優先級 4.Accept-Charset首部字段可用來通知服務器用戶代理支持的字符集及字符集的相對優先順序。 5.Accept-Encoding首部字段用來告知服務器用戶代理支持的內容編碼及內容編碼的優先級順序 6.Accept-Language用來告知服務器用戶代理能夠處理的自然語言集（指中文或英文等），以及自然語言集的相對優先級 7.Authorization是用來告知服務器，用戶代理的認證信息（證書值） 8.Expect來告知服務器，期望出現的某種特定行爲。因服務器無法理解客戶端的期望作出回應而發生錯誤時，會返回狀態碼417 Expectation Failed。 9.From用來告知服務器使用用戶代理的用戶的電子郵件地址。通常，其使用目的就是爲了顯示搜索引擎等用戶代理的負責人的電子郵件聯繫方式 10.Host會告知服務器，請求的資源所處的互聯網主機名和端口號。Host首部字段在HTTP/1.1規範內是唯一一個必須被包含在請求內的首部字段。 11.Referer會告知服務器請求的原始資源的URI。 12.User-Agent會將創建請求的瀏覽器和用戶代理名稱等信息傳達給服務器。 13.Content-Type說明了實體主體內對象的媒體類型

今年的讀書進度整體偏慢，爲完成讀書任務，同時也想再系統的學習和回顧下工作相關的知識，對書單進行了調整，融入一些專業相關的書籍，於是打開這本來自島國的圖解http。 從事web開發，瞭解http協議是基礎，這本書的出現也是作者爲了彌補市場上http書籍的不足，相對於權威指南，tcp/ip而言這本書顯得通俗易懂，這也是作者的初衷。 書的篇幅不短，雖然把涉及http相關的知識點都講到了，例如它的發展演變、實際應用、安全等，但深度不夠，加上配了很多圖片，所以讀起來很快，比較適合初學者。 看完全書對http又整體回顧了一篇，加深了相關概念的印象，對書裏出現的那些單詞和代碼感覺那麼親切，這就是讀這類書所特有的感覺。

優點： 1. 圖文並茂，通俗易懂： 該書採用了大量的圖解和通俗易懂的語言，使得複雜的HTTP協議變得容易理解。這種方式讓讀者能夠更直觀地理解HTTP協議的工作原理和流程。 2. 全面而深入： 作者在書中涵蓋了HTTP協議的各個方面，包括請求和響應的格式、狀態碼、持久連接、安全性等內容，爲讀者提供了全面深入的瞭解。 3. 舉例生動，實用性強： 書中通過大量的實例來說明HTTP協議在實際應用中的運作方式，這些例子能夠幫助讀者更好地理解HTTP在不同場景下的應用。 4. 適合不同水平的讀者： 無論是初學者還是有一定經驗的開發人員，都能從這本書中受益。對於初學者來說，書中的圖解和通俗易懂的語言能夠幫助他們快速入門；而對於有經驗的開發人員來說，書中的深入剖析能夠幫助他們更深入地理解HTTP協議。 缺點: 1. 偏向概念解釋： 有些讀者認爲書中對HTTP協議的一些概念解釋過於詳細，而缺乏一些實際的應用場景和案例，這使得書籍顯得有些枯燥。 2. 更新速度慢： 由於HTTP協議的不斷演進和發展，書中的內容可能已經有些過時，尤其是在介紹一些新的技術和特性方面。因此，讀者在閱讀時需要注意結合其他最新資料來獲取最新的信息。 3. 深度有限： 雖然書中對HTTP協議進行了全面的介紹，但是對於一些更深層次的技術細節和高級應用場景，書中的涉及可能有些有限。讀者可能需要額外的資料來進一步瞭解這些內容。 結論： 《圖解HTTP》作爲一本介紹HTTP協議的入門書籍，具有圖文並茂、通俗易懂、全面深入的特點，適合各種水平的讀者閱讀。然而，它也存在一些不足之處，如偏向概念解釋、更新速度慢和深度有限等。讀者在閱讀時應當根據自己的實際需求和水平來選擇是否適合。

寫得好淺，概念上的理解。 不過配圖倒是很用心，不會讓人有煩躁的情緒。 本書算是課外書之類，平時翻翻就好。

全書覆蓋HTTP核心知識與延伸要點：從HTTP成長髮展史切入，基於HTTP 1.1標準，系統講解通信過程、HTTP方法、協議格式、報文結構等基礎內容，同時介紹代理、網關的作用及SPDY等擴展功能；後半部分聚焦Web安全，深入解讀HTTPS、加密機制等關鍵知識，幫助讀者構建對HTTP協議的完整認知，滿足初學者入門與有經驗開發者查漏補缺的雙重需求。 一點小小的不足就是有點年份了，現在都出http/3了

作者對http的發展史做了比較詳細的介紹，着重介紹了http1.1、https的概念與優缺點，同時對http2.0做了簡要介紹，可以作爲了解http的讀物。個人覺得網絡的知識，理解了是真的簡單，不理解是真的搞不懂。第一次讀的時候，沒讀下去，後來讀了小林圖解之後，再回來看，一切又能看懂了。不過有一點是顯而易見的：知識點是真的多啊！ 此處推薦學習“計算機網絡”的閱讀順序： 1. 《圖解tcp/ip》：這本書從計算機網絡最基礎的知識開始介紹，先介紹發展史，OSI參考模型，然後引出tcp/ip模型。接着按照數據鏈路層、網絡層、傳輸層、應用層的從下往上的順序進行介紹。 特點：幽默易懂 缺點：泛泛而談，對於面試常用知識點介紹不夠詳細。 2. 小林coding的圖解網絡：有了基本的網絡概念之後，首推小林圖解，該圖解系列可以在公衆號“小林coding”獲取。從面試常問問題的角度，按照從應用層、傳輸層、網絡層、數據鏈路層的自上往下的順序進行介紹（與《圖解tcp/ip》的介紹順序剛好相反），對http，tcp，udp，ip進行了詳細的介紹。讀完基本上對網絡協議有了一個清晰的認識。 優點：幽默易懂，圖解很形象 缺點：木有，哈哈，因爲讀完我的收穫很多，真的好喜歡這本圖解。 3. 《圖解http》：這本書可以結合小林圖解http部分一起閱讀，作爲補充讀物。

這本書推薦值居然降到了68.4，唉～ 這本書我認爲是非常適合新手來學習計算機網絡的，但這本書也確實有點問題，那就是內容太太太多了，有點太詳細了，作爲新手很可能抓不住重點，導致棄坑了，沒錯，說的就是去年第一次讀這本書的我🥹 前五章讀起來非常輕鬆，你再在瀏覽器上玩玩network 選項卡，第六章也差不多了，基本上你英語好也能看出來這些字段是什麼意思。 如果你是新手，那麼接下來的章節你只要花10分鐘速度翻一遍每個篇章的標題和第一句話的，因爲接下來的章節內容非常多，多的有點像字典了，但作爲新手你其實不用掌握這麼多的，你只要知道有這麼個名詞就行了，之後你學習或工作碰上了這些（很多都大概率碰不上），再去學就行了。 最後，學習計算機網絡，如果你只是前端開發，咱們是在應用層玩的，底層的咱別管😋差不多到傳輸層就是咱的底層了😋

這是HTTP協議的入門級圖書，適合對網絡協議感興趣的朋友們閱讀，可以俯視瀏覽到整個HTTP協議的全貌，但是對於不瞭解網絡的朋友會有一點困難。

之前看過紙質版的，於自己而言算是查漏補缺，書中很多東西還是要結合實際場景方能理解更深刻，不推薦新手直接看此書。