《圖解http》讀書筆記

1 了解Web & 網路基礎

1.1 WWW(World Wide Web，萬維網)

• 3項WWW構建技術
  ①把SGML(通用標記語言)作為頁面的文本標記語言的HTML（HyperText Markup Language,超文本標記語言）；
  ②作為檔案傳遞協議的HTTP；
  ③指定檔案所在地的URL（Uniform Resource Locator,統一資源定位符），

1.2 網路基礎TCP/IP協議簇

通常使用的網路(包括互聯網)是在TCP/IP協議族的基礎上運作的，而HTTP屬于它內部對的一個子集，

• TCP/IP的分層管理

四層：應用層、傳輸層、網路層和資料鏈路層，

• ①負責傳輸的IP協議(Internet Protocol)

位于網路層，傳送資料包；
兩個重要條件：IP地址和MAC地址，

• ②確保可靠性的TCP(Transmission Control Protocol,傳輸控制協議)

傳輸層，提供可靠的位元組流服務；
vs UDP(User Data Protocol,用戶資料報協議)；
三次握手 - 確保資料能到達目標

• ③負責域名決議的DNS服務(Domain Name System)

  提供域名到IP地址之間的決議服務(通過域名查找IP地址，或逆向)，

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

2 About HTTP

2.1 簡單的HTTP協議(HTTP協議結構)

• 請求報文

• 回應報文

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

• HTTP是不保存狀態的協議，即無狀態協議，可以使用Cookie進行狀態管理，

• HTTP/1.1：持久連接→管線化
  持久連接使得多數請求以管線化方式發送成為可能(從前發送請求后需等待并收到回應，才能發送下一個請求)，
  HTTP1.0、HTTP1.1 和 HTTP2.0 的區別
  一文讀懂 HTTP/1HTTP/2HTTP/3

2.2 HTTP報文內的HTTP資訊

• HTTP報文
  HTTP報文大致可分為 (1)報文首部 和 (2)報文主體 兩塊，(通常并不一定要有報文主體)，

報文主體和物體主體的差異（物體主體?報文主體）

• 報文（message）
  是HTTP通信中的基本單位，由8位組位元組流（octet sequence，其中octet為8個位元）組成，通過HTTP通信傳輸，
  (以位元組為單位的意思, 1 byte（位元組）=8 bit（位）)
• 物體（entity）
  作為請求或回應的有效載荷資料（補充項）被傳輸，其內容由物體首部和物體主體組成，

http報文和物體的差別？

• 編碼提升傳輸效率

  ①壓縮傳輸的內容編碼

②分割發送的分塊傳輸編碼

2.3 回傳結果的HTTP狀態碼

• 狀態碼的五大類別

• 具體狀態碼
  100、101、200、204、206、301、302、303、304、307、400、401、403、404、500、502、503…

狀態碼 (狀態碼英文名稱)	詳解
100 (Continue)	繼續，客戶端應繼續其請求，如果服務器收到頭資訊中帶有100-continue的請求，這是指客戶端詢問是否可以在后續的請求中發送附件，在這種情況下，服務器用100(SC_CONTINUE)允許客戶端繼續或用417 (Expectation Failed)告訴客戶端不同意接受附件，這個狀態碼是 HTTP 1.1中新加入的，
101 (Switching Protocols)	切換協議，服務器根據客戶端的請求切換協議，當客戶端通過在請求里使用Upgrade報頭，以通知服務器它想改用除HTTP協議之外的其他協議時，客戶端將獲得此回應代碼，101回應代碼表示“行，我現在改用另一個協議了”，
200 (OK)
	請求成功，一般用于GET與POST請求
204 (No Content)
	無內容，服務器成功處理，但未回傳內容，在未更新網頁的情況下，可確保瀏覽器繼續顯示當前檔案
206 (Partial Content)
	該狀態碼表示客戶端進行范圍請求，服務器成功執行GET請求，回應報文中包含Content-Range指定范圍的物體內容，
301 (Moved Permanently)
xx	永久性重定向，請求的資源已被永久的移動到新URI，回傳資訊會包括新的URI，瀏覽器會自動定向到新URI，今后任何新的請求都應使用新的URI代替，（需要更新書簽）
302 (Found)
	臨時性重定向，與301類似，但資源只是臨時被移動，客戶端應繼續使用原有URI，（不會更新書簽）
303 (See Other)
	與302類似，區別是明確表示客戶端應使用GET方法定向獲取請求的資源， ps: 301、302標準是禁止將POST改為GET的，但是實際上幾乎所有的瀏覽器都會這么改，
304 (Not Modified)
	未修改，所請求的資源未修改，服務器回傳此狀態碼時，不會回傳任何資源，客戶端通常會快取訪問過的資源，通過提供一個頭資訊指出客戶端希望只回傳在指定日期之后修改的資源.
307 (Temporary Redirect)	/
	與302類似，區別是不會從POST變成GET
400 (Bad Request)
	請求報文中存在語法錯誤，需修改請求內容中再次發送，
401 (Unauthorized)
	表示發送的請求需要有通過HTTP認證(BASIC認證、DIGEST認證)的認證資訊， 回傳401必須包含一個適用請求資源的WWW-Authenticate首部用以質詢用戶資訊，初次接受會彈出認證對話視窗，
403 (Forbidden)
	表明對請求的資源的訪問被服務器拒絕了 .
404 (Not Found)
	表明服務器上無法找到請求的資源.
500 (Internal Server Error)
	表明服務器端執行請求時發生了錯誤.
502 (Bad Gateway)	/
	作為網關或者代理作業的服務器嘗試執行請求時，從遠程服務器接收到了一個無效的回應
503 (Service Unavailable)
	由于超載或系統維護，服務器暫時的無法處理客戶端的請求，延時的長度可包含在服務器的Retry-After頭資訊中

2.4 與HTTP協作的Web服務器

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

2.4.2 通信資料轉發程式：代理、網關、隧道

①代理：代理是一種有轉發功能的應用程式，接收從客戶端發送來的請求并轉發給服務器，反之，接收服務器的回應轉發給客戶端，

②網關：網關是轉發其他服務器通信資料的服務器，接收從客戶端發送來的請求并對請求進行處理，
其作業機制與代理十分相似，而網關能使通信線路上的服務器提供非HTTP協議服務，
提高安全性，客戶端 - 加密 - 網關，

③隧道：在相隔甚遠的客戶端和服務器兩者之間建立通信路線 ，并保持雙方通信連接的應用程式，

2.4.3 保存資源的快取

2.5 HTTP首部

• 4種HTTP首部欄位型別
  ①通用首部欄位
  請求保溫和回應報文兩方都會使用的首部，
  ②請求首部欄位
  從客戶端向服務器端發送請求報文時使用的首部，補充了請求的附加內容、客戶端資訊、回應內容相關優先級等資訊，
  ③回應首部欄位
  從服務器端向客戶端回傳回應報文時使用的首部，補充了回應的附加內容，也會要求客戶端附加額外的內容資訊，
  ④物體首部欄位
  針對請求報文和回應報文的物體部分使用的首部，補充了資源內容更新時間等與物體有關的資訊，

1. HTTP/1.1規范定義了如下47種首部欄位，

通用首部欄位

請求首部欄位

回應首部欄位

物體首部欄位

2. 為Cookie服務的首部欄位

3. 其他首部欄位

• X-Frame-Options：X-Frame-Options：回應首部，用于控制網站內容在其他Web網站Frame標簽內的顯示問題，主要目的是為了防止點擊劫持攻擊，
  欄位值：DENY(拒絕)，SAMEORIGIN(僅同源名下的頁面匹配時可許)，
• X-XSS-Protection：回應首部，是針對跨站腳本攻擊(XSS)的一種對策，用于控制瀏覽器XSS防護機制的開關，
  欄位值：0(將XSS過濾設定成無效狀態)，1(將XSS設定成有效狀態)
• DNT：請求首部，是Do Not Track的簡稱，意為拒絕個人資訊收集，表示拒絕被精準廣告收集
  欄位值：0(同意被追蹤)，1(拒絕被追蹤)，
• P3P：回應首部，通過P3P技術，可以讓Web網站的個人隱私變成一種僅供程式理解的形式，達到保護用戶隱私的目的，
  步驟：①創建P3P隱私；②創建PSP隱私對照檔案后，保存命名/w3c/p3p.xml；③從P3P隱私中新建Compact policies后，輸出到HTTP回應中，

3 About HTTPS - 確保Web安全的HTTPS

1. HTTP的缺點

• 通信使用明文可能會被竊聽（TCP/IP是可能本竊聽的網路）
• 不驗證通信方的身份就可能遭遇偽裝
• 無法證明報文完整性，可能已遭篡改

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

• HTTPS是身披SSL外殼的HTTP(通信的加密)

• 相互交換密鑰的公開密鑰加密技術(SSL采用這種 內容的加密 方式)

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

• 證明公開密鑰正確性的證書
  使用由數字證書認證機構（CA, Certificate Authority）和其相關機關頒發的公開密鑰證書，
  

3. HTTPS的安全通信機制

4 Web攻擊技術

1. 針對 Web 的攻擊技術

• HTTP 不具備必要的安全功能
• 在客戶端即可篡改請求

• 針對 Web 應用的攻擊模式（主動攻擊&被動攻擊）

2. 因輸出值轉義不完全引發的安全漏洞

• 跨站腳本攻擊(Cross-Site Scripting,XSS)
  是指通過存在安全漏洞的 Web 網站注冊用戶的瀏覽器內運行非法的HTML 標簽或 JavaScript 進行的一種攻擊，
  是攻擊者利用預先設定的陷阱觸發的被動攻擊，

• SQL注入攻擊（會執行非法 SQL）
  是指標對 Web 應用使用的資料庫，通過運行非法的 SQL 而產生的攻擊，

• OS命令注入攻擊
  是指通過 Web 應用，執行非法的作業系統命令達到攻擊的目的，

• http首部注入攻擊
  HTTP 首部注入攻擊(HTTP Header Injection)是指攻擊者通過在回應首部欄位內插入換行，添加任意回應首部或主體的一種攻擊，
  屬于被動攻擊模式，
  HTTP 首部注入攻擊有可能會造成以下一些影響，
  設定任何 Cookie 資訊、重定向至任意 URL、顯示任意的主體(HTTP 回應截斷攻擊)

• 郵件首部注入攻擊
  是指 Web 應用中的郵件發送功能,攻擊者通過向郵件首部 To 或 Subject 內任意添加非法內容發起的攻擊，利用存在安全漏洞的 Web 網站，可對任意郵件地址發送廣告郵件或病毒郵件，

• 目錄遍歷攻擊
  是指對本無意公開的檔案目錄，通過非法截斷其目錄路徑后，達成訪問目的的一種攻擊，這種攻擊有時也稱為路徑遍歷(Path Traversal)攻擊，

• 遠程檔案包含漏洞
  是指當部分腳本內容需要從其他檔案讀入時，攻擊者利用指定外部服務器的 URL 充當依賴檔案，讓腳本讀取之后，就可運行任意腳本的一種攻擊，

3. 因設定或設計上的缺陷引發的安全漏洞

• 強制瀏覽
  從安置在 Web 服務器的公開目錄下的檔案中，瀏覽那些原本非自愿公開的檔案，

• 不正確的錯誤訊息處理
  eg：畫面提示“郵件地址未注冊”的錯誤訊息，當輸入的郵件地址尚未在該 Web 網站上注冊時，就會觸發 這條錯誤訊息，因為倘若郵件地址存在，應該會提示“輸入的密碼有誤”之類的錯誤訊息，攻擊者利用進行不同的輸入會提示不同的錯誤資訊這條，就可用來確認輸入的郵件地址是否已在這個Web 網站上注冊過了，
  為了不讓錯誤訊息給攻擊者以啟發,建議將提示訊息的內容僅保留到“認證錯誤”這種程度即可，

• 開放重定向
  而于此功能相關聯的安全漏洞是指，假如指定的重定向 URL 到某個具有惡意的 Web 網站，那么用戶就會被誘導至那個 Web 網站，
  eg：http://example.com/?redirect=http://www.tricorder.jp
  攻擊：http://example.com/?redirect=http://hackr.jp
  用戶看到 URL 后原以為訪問 example.com，不料實際上被誘導至 hackr.jp 這個指定的重定向目標，可信度高的 Web 網站如果開放重定向功能，則很有可能被攻擊者選中并用來作為釣魚攻擊的跳板，

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

• 會話劫持
  對以竊取目標會話 ID 為主動攻擊手段的會話劫持而言，會話固定攻擊(Session Fixation)攻擊會強制用戶使用攻擊者指定的會話 ID，屬于被動攻擊，

• 會話固定攻擊

• 跨站點請求偽造
跨站點請求偽造(Cross-Site Request Forgeries,CSRF)攻擊是指攻擊者通過設定好的陷阱，強制對已完成認證的用戶進行非預期的個人資訊或設定資訊等某些狀態更新，屬于被動攻擊，

5. 其他安全漏洞

• 密碼破解（窮舉法、字典攻擊）
  從加密過的資料中匯出明文通常有以下幾種方法：通過窮舉法·字典攻擊進行類推、彩虹表、拿到密鑰、加密演算法的漏洞
• 點擊劫持
  是指利用透明的按鈕或鏈接做成陷阱，覆寫在 Web 頁面之上，然后誘使用戶在不 知情的情況下，點擊那個鏈接訪問內容的一種攻擊手段，
• DoS攻擊
  是一種讓運行中的服務呈停止狀態的攻擊，
  主要有以下兩種 DoS 攻擊方式：①集中利用訪問請求造成資源過載，資源用盡的同時，實際上服務也就呈停止狀態；②通過攻擊安全漏洞使服務停止，
  其中，集中利用訪問請求的 DoS 攻擊，單純來講就是發送大量的合法請求，服務器很難分辨何為正常請求,，何為攻擊請求,因此很難防止 DoS 攻擊，
• 后門程式
  是指開發設定的隱藏入口，可不按正常步驟使用受限功能，利用后門程式就能夠使用原本受限制的功能，
  通常的后門程式分為以下 3 種型別：開發階段作為 Debug 呼叫的后門程式、開發者為了自身利益植入的后門程式、攻擊者通過某種方法設定的后門程式，’
  可通過監視行程和通信的狀態發現被植入的后門程式，但設定在 Web 應用中的后門程式，由于和正常使用時區別不大，通常很難發現，

5 其他

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

1. Basic認證
   ①客戶端發起請求
   → ②服務端回傳401+WWW-Authenticate首部欄位（認證的方式(BASIC)+Request-URL安全域字串(realm)）
   → ③客戶端發生送用戶名密碼
   → ④服務器驗證+回傳資源

2. DIGEST認證
   ①客戶端發起請求
   → ②服務端回傳401+WWW-Authenticate首部欄位（認證的方式(DIGEST)+質問回應的方式認證所需的臨時質詢碼(亂數nonce)+realm）
   → ③客戶端請求(首部欄位Authorization (必須包含username，realm，none從，uri和response的欄位資訊)
   → ④服務器驗證+回傳資源

3. SSL客戶端認證

• 采用雙因素認證：SSL客戶端證書+密碼(用戶本人行為)
• 有必要的費用

4. 基于表單認證

• 一般會使用Cookie來管理Session（會話），
  

5.2 基于HTTP的功能追加協議

1. HTTP的瓶頸

• ①一條連接上只可發送一個請求

• ②請求只能從客戶端開始，客戶端不可以接收除回應以外的指令

• ③請求/回應首部未經壓縮就發送，資訊越多延遲越大

• ④發送冗長的首部，相同首部會浪費

• ⑤可任意選擇資料壓縮格式，非強制壓縮發送

2. Ajax的解決辦法
   Ajax 的核心技術是名為 XMLHttpRequest 的 API，通過 JavaScript 腳本語言的呼叫就能和服務器進行 HTTP 通信，借由這種手段，就能從已加載完畢的 Web 頁面上發起請求，只更新區域頁面，而利用 Ajax 實時地從服務器獲取內容，有可能會導致大量請求產生，另外， Ajax 仍未解決 HTTP 協議本身存在的問題，

3. Comet 的解決方法
   一旦服務器端有內容更新了， Comet 不會讓請求等待，而是直接給客戶端回傳回應，這是一種通過延遲應答，模擬實作服務器端向客戶端推送（Server Push）的功能，通常，服務器端接收到請求，在處理完畢后就會立即回傳回應，但為了實作推送功能， Comet 會先將回應置于掛起狀態，當服務器端有內容更新時，再回傳該回應，因此，服務器端一旦有更新，就可以立即反饋給客戶端，內容上雖然可以做到實時更新，但為了保留回應，一次連接的持續時間也變長了，期間，為了維持連接會消耗更多的資源，另外， Comet 也仍未解決 HTTP 協議本身存在的問題，

4. SPDY的設計與功能
   在TCP/IP的應用層與運輸層之間通過新加會話層的形式運作，同時通信使用SSL，
   
   使用 SPDY 后，HTTP 協議額外獲得以下功能：
   ①多路復用流
   通過單一的 TCP 連接，可以無限制處理多個 HTTP 請求，所有請求的處理都在一條 TCP 連接上完成，因此TCP 的處理效率得到提高，
   ②賦予請求優先級
   SPDY 不僅可以無限制地并發處理請求，還可以給請求逐個分配優先級順序，這樣主要是為了在發送多個請求時，解決因帶寬低而導致回應變慢的問題，
   ③壓縮HTTP首部
   壓縮 HTTP 請求和回應的首部，這樣一來，通信產生的資料包數量和發送的位元組數就更少了，
   ④推送功能
   支持服務器主動向客戶端推送資料的功能，這樣，服務器可直接發送資料，而不必等待客戶端的請求，
   ⑤服務器提示功能
   服務器可以主動提示客戶端請求所需的資源，由于在客戶端發現資源之前就可以獲知資源的存在，因此在資源已快取等情況下，可以避免發送不必要的請求，

SPDY 消除 Web 瓶頸了嗎？
希望使用 SPDY 時， Web 的內容端不必做什么特別改動，而 Web 瀏覽器及 Web 服務器都要為對應 SPDY做出一定程度上的改動，有好幾家 Web 瀏覽器已經針對 SPDY 做出了相應的調整，另外， Web
服務器也進行了實驗性質的應用，但把該技識訓入實際的 Web 網站卻進展不佳，因為 SPDY 基本上只是將單個域名（ IP
地址）的通信多路復用，所以當一個 Web 網站上使用多個域名下的資源，改善效果就會受到限制，SPDY 的確是一種可有效消除 HTTP
瓶頸的技術，但很多 Web 網站存在的問題并非僅僅是由 HTTP 瓶頸所導致，對 Web本身的速度提升，還應該從其他可細致鉆研的地方入手，比如改善 Web 內容的撰寫方式等，

5. 使用瀏覽器進行全雙工通信的 WebSocket

• 推送功能
• 減少通信量
  只要建立起 WebSocket 連接，就希望一直保持連接狀態，和 HTTP 相比，不但每次連接時的總開銷減少，而且由于 WebSocket 的首部資訊很小，通信量也相應減少了，

為了實作 WebSocket 通信，在 HTTP 連接建立之后，需要完成一次“握手”（Handshaking）的步驟：

6. 期盼已久的 HTTP/2.0

協議：SPDY、HTTP Speed＋Mobility 、Network-Friendly HTTP Upgrade

HTTP/2.0的特點：

注：HTTP Speed＋Mobility 簡寫為Speed＋Mobility，Network-Friendly HTTP Upgrade簡寫為Friendly.

7. Web 服務器管理檔案的 WebDAV
   WebDAV（Web-based Distributed Authoring and Versioning，基于萬維網的分布式創作和版本控制）是一個可對 Web 服務器上的內容直接進行檔案復制、編輯等操作的分布式檔案系統，

5.3 構建Web內容的技術

• HTML
• 動態HTML
• Web應用
  通過Web提供功能的Web應用、與web服務器和程式協作的CGI(通用網關介面)、因Java而普及的Servlet
• 資料發布的格式及語言
  ①XML(eXtensible Markup Language,可擴展標記語言)
  發布更新資訊的RSS/Atom都是發布新聞或博客日志等更新資訊檔案的格式的總稱，兩者都用到了XML，
  ②Javascript衍生的輕量級JSON(JavaScript Object Notation, JS 物件簡譜)

6 別人的文章

傻傻分不清之 Cookie、Session、Token、JWT
強快取vs協商快取
三次握手&四次握手