《圖解HTTP》

第一章、瞭解web及網路基礎

1.2 http的誕生

HTTP於1990年問世，那時候HTTP並沒有作為正式的標準被建立，被稱為HTTP/0.9

HTTP正式作為標準被公佈是在1996年5月，版本被命名為HTTP/1.0，該協議至今仍被廣泛用在伺服器端。

HTTP/1.1於1997年1月公佈，是目前主流的HTTP協議版本。

HTTP/2.0正在制定中。

1.3 TCP/IP

TCP/IP不是某個協議，而是互聯網相關的各類協議族的總稱。詳細內容參見TCP/IP詳解學習筆記

TCP/IP協議族按層次分別為以下4層：

應用層：決定了向用戶提供應用服務時的通信活動，該層包括FTP DNS HTTP

傳輸層：對上層應用層，提供處於網路連接中的兩台電腦之間的數據傳輸，該層包括TCP UDP

網路層：用來處理在網路上流動的數據包，該層規定了通過怎樣的路徑達到對方電腦並把數據包傳送給對方

鏈路層：用來處理連接網路的硬體部分，網卡 光纖

TCP/IP通信傳輸流程（http舉例）

首先作為發送端的客戶端在應用層（http協議）發出一個想看某個web頁面的http請求。接著，為了傳輸的方便，在傳輸層（tcp協議）把從應用層處收到的數據（http請求報文）進行分割，併在各個報文上打上標記序號及埠號後轉發給網路層。在網路層（ip協議）增加作為通信目的地的MAC地址後轉發給鏈路層。這樣，發往網路的通信請求就齊全了。

1.4.1 負責傳輸的IP協議

IP協議的作用是把各種數據包傳送給對方

IP地址指明瞭節點被分配到的地址，MAC地址是指網卡所屬的固定地址

1.4.2 確保可靠性的TCP協議

TCP協議為了更容易送達大數據才把數據分割，採用三次握手策略確保數據最終送達對方

三次握手策略：

發送端首先發送一個帶SYN(synchronize)標誌的數據包給對方，接收端收到後回傳一個帶有SYN/ACK標誌的數據包以示傳達確認信息。最後發送端再回傳一個帶ACK(acknowledgement)標誌的數據包代表握手結束。

1.5 負責功能變數名稱解析的DNS(Domain Name System)服務

DNS提供功能變數名稱到IP地址之間的解析服務

1.6 各種協議在http協議通信過程中的職責

按流程順序分別為：

DNS服務：把用戶輸入的功能變數名稱解析為IP地址

HTTP協議：生成針對目標web伺服器的HTTP請求報文

TCP協議：為了方便通信將HTTP請求報文分割成報文段，把每個報文段可靠的傳給對方

IP協議：搜索對方的地址，一邊中轉一邊傳送

TCP協議：從對方那裡接收報文段並按序號從組請求報文

HTTP協議：對web伺服器請求的內容的處理

1.7 URI/URL

URI(Uniform Resource Identifier)某個協議方案的資源的定位標識符

URL(Uniform Resource Locator)表示互聯網資源的具體地點

第二章、簡單的http協議

2.2 通過請求和響應的交換達成通信

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

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

2.3 HTTP是不保存狀態的協議

HTTP協議自身不對請求和響應之間的通信狀態進行保存

2.5 告知伺服器意圖的http方法

GET:用來訪問已被URI識別的資源

POST:用來傳輸實體的主體

GET方法和POST方法的區別：

1. 安全性

   • GET請求的數據會附在URL之後（就是把數據放置在HTTP協議頭中），以?分割URL和傳輸數據，參數之間以&相連，參數將明文出現在URL上，容易被他人看到，URL信息也可能會被記錄到歷史紀錄中。
   • POST請求是把提交的數據則放置在是HTTP包的包體中。

2. 數據長度：

   • HTTP協議沒有對傳輸的數據和URL長度進行限制， 但特定瀏覽器和伺服器對URL長度有限制， 因此對於GET提交時，傳輸數據就會受到URL長度的限制；
   • 由於POST操作不是通過URL傳值，理論上數據長度不受限；

3. GET請求能夠被緩存,以GET請求的URL能夠保存為瀏覽器書簽，而POST請求則都不能

4. Get是用來從伺服器上獲得數據，而Post是用來向伺服器上傳遞數據。

以下其他方法均不常用

PUT:傳輸文件 HEAD：獲得報文首部 DELETE:刪除文件 OPTUIONS:詢問支持的方法 TRACK:追蹤路徑 CONNECT：要求用隧道協議連接代理

2.7 持久連接節省通信量

持久連接的好處在於減少了TCP連接的重覆建立和斷開所造成的額外開銷，減輕伺服器端荷載。在HTTP/1.1中所有連接預設都是持久連接

持久連接使得多數請求以管線化方式發送，即能同時並行發送多個請求。

2.8 使用cookie的狀態管理

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

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

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

3.1 HTTP報文

HTTP報文大致可分為報文首部和報文主體兩塊，兩者有最初出現的空行來劃分，通常並不一定要有報文主體

3.2 請求報文和響應報文的結構

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

狀態行：包含響應結果的狀態碼，原因短語和HTTP版本

首部欄位：包含表示請求和響應的各種條件和屬性的各類首部，一般分別為：通用首部、請求首部、響應首部和實體首部。

其他：包含HTTP的RFC里未定義的首部（Cookie等）

3.3 編碼提升傳輸速率

常用的內容編碼方式有以下幾種：

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

3.5 獲取部分內容的範圍請求(Range Request)

執行範圍請求時，會用到首部欄位Range來指定資源的byte範圍

針對範圍請求，響應會返回狀態碼為206 Partial Content的響應報文

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

內容協商機制是指客戶端和伺服器端就響應的資源內容進行交涉，然後提供給客戶端最適合的資源。內容協商會以響應資源的語言、字元集、編碼方式等作為判斷的基準。如首部欄位中的Accept、Accept-Charset、Accept-Enoding、Accept-Language、Content-Language

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

4.1 狀態碼告知從伺服器端返回的請求結果

4.2 2XX成功

200 OK 表示從客戶端發來的請求在伺服器端被正常處理

204 No Content 表示伺服器接收的請求已成功處理，但返回的響應報文中不允許返回任何實體的主體部分

206 Partial Content 表示客戶端進行了範圍請求，伺服器成功執行了這部分GET請求

4.3 3XX 重定向

304 Not Modified 表示客戶端發送附帶條件的GET請求時，其訪問的資源（自上次訪問以來或者根據請求的條件）未變化

4.4 4XX客戶端錯誤

401 Bad Request 表示報文中存在語法錯誤

403 Forbidden 表示對請求資源的訪問被伺服器拒絕了

404 Not Found 表示伺服器上無法找到請求的資源

4.5 5XX 伺服器錯誤

501 Internet Sever Error 表示伺服器端在執行請求時發生了錯誤

503 Service Unavailable 表示伺服器暫時處於超負荷或正在停機維護，現無法處理請求

第五章、與http協作的web伺服器

5.1 用單個虛擬主機實現多個功能變數名稱

在相同的IP地址下，由於虛擬主機可以寄存多個不同主機名和功能變數名稱的Web網站，因此在發送HTTP請求時，必須在Host首部內完整指定主機名或功能變數名稱的URI

5.2.1 代理

代理伺服器的基本行為接收客戶端發送的請求後轉發給其他伺服器，代理不改變請求URI,轉發時需要附加Via首部欄位已標記出經過的主機信息。

使用代理伺服器的理由：

• 利用緩存技術（代理緩存）減少網路帶寬的流量
• 組織內部針對特定網站的訪問控制，以獲取訪問日誌為主要目的。

5.2.2 網關

網關能使通信線路上的伺服器提供非HTTP服務（SQL數據查詢）

5.2.3 隧道

隧道的目的是確保客戶端能與伺服器進行安全的通信

第六章、http首部

6.2.4 首部欄位一覽表

通用首部欄位

請求首部欄位

響應首部欄位

實體首部欄位

第七章、確保web安全的https

7.1http缺點

• 通信使用明文，內容可能被竊聽
• 不驗證通信方身份，有可能遭遇偽裝
• 無法證明報文的完整性，有可能已遭篡改

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

HTTPS並非應用層的一種新協議，只是HTTP通信介面部分用SSL和TLS協議代替而已，其實就是身披SSL協議這層外殼的HTTP

SSL採用一種叫做公開密鑰加密的加密處理方式

公開密鑰加密使用一對非對稱的密鑰，私有密鑰和公開密鑰，發送密文的一方使用對方的公開密鑰進行加密處理，對方收到被加密的信息後，再使用自己的私有密鑰進行解密

公開密鑰加密處理起來比共用密鑰加密方式更為複雜，因此若在通信時使用公開密鑰加密方式，效率會很低。所以HTTPS採用採用共用密鑰加密和公開密鑰加密兩者並用的混合加密機制

混合加密機制原理：

1. 使用公開密鑰加密方式安全的交換共用密鑰（在稍後的共用密鑰加密中要使用的密鑰）
2. 確保交換的秘鑰安全的前提下，使用共用密鑰加密方式通信。

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

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

9.2 消除http瓶頸的spdy

http瓶頸：

• 一條連接上只可發送一個請求
• 請求只能從客戶端開始，客戶端不可以接收除響應以外的指令
• 請求/響應首部未經壓縮就發送，首部信息越多延遲越大
• 發送冗長的首部，每次發送相同的首部造成的浪費較多
• 可任意選擇數據壓縮格式，非強制壓縮發送

消除http瓶頸方法嘗試:

• Ajax 能實時地從伺服器獲取內容，可能導致大量請求產生
• Comet 內容隨可以實時更新，但為了保留響應，一次連接的持續時間變長了，消耗更多資源
• SPDY 雖然能有效消除瓶頸，但當一個web網站使用多個功能變數名稱下的資源時，改善效果受限制

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

WebSocket協議主要特點：

• 支持由伺服器向客戶端推送數據功能
• 減少通信量，不但每次連接總開銷減少，而且首部信息也很少

為了實現WebSocket通信需要將Http的Upgrade首部欄位值設為websocket,對於之前的握手請求，返回狀態碼101 Switching Proticols.成功握手確立WebSocket連接之後，不再使用HTTP的數據幀，而採用WebSocket獨立數據幀

WebSocket API

javascript可調用“The Websocket API”內提供的websocket程式介面，以實現websocket協議下雙全工通信

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

第十一章、web的攻擊技術