《圖解HTTP》讀書筆記

1. 瞭解WEB及網絡基礎

HTTP是TCP/IP協議族的一個子集，是在TCP/IP的基礎上運做的

計算機要與網絡設備之間的通訊，雙方就必須基於相同的方式。好比如何探測到通訊目標、有哪邊先發起通訊、怎麼結束通訊等。全部的一切都是一種規則，這種規則就是協議

1.1 TCP/IP的分層管理

TCP/IP協議族按層次分別爲如下4層：

• 應用層：決定了向用戶提供服務時通訊的活動，好比ftp, dns, http協議
• 傳輸層：提供處於網絡鏈接中的兩臺計算機之間的數據傳輸。TCP, UDP
• 網絡層：用來處理網絡上流動的數據包，肯定傳輸路線
• 數據鏈路層：用來處理鏈接網絡的硬件部分。包括控制操做系統、硬件的設備驅動、網卡

# 客戶端發送請求
HTTP客戶端 -> TCP -> IP -> 鏈路層
# 客戶端接受請求
鏈路層 -> IP -> TCP -> HTTP客戶端
# 服務端發送數據
HTTP服務器 -> TCP -> IP -> 鏈路層
# 服務端接受數據
鏈路層 -> IP -> TCP -> HTTP服務器

舉例來講：就是頁面發送請求(應用層) -> 把從應用層接收到的數據(HTTP請求報文)進行分割，並在各個報文打上標記及端口號(傳輸層) -> 增長做爲通訊目的地的MAC地址後轉發鏈路層(網絡層) -> 發送真正的請求(鏈路層)

1.2 與HTTP關係密切的協議：IP/TCP/DNS

1. 負責傳輸的IP協議(Internet Protocol)，IP是一種協議的名稱，並不是IP地址，要確保正確的傳輸到對方的計算機上，則須要知足各類條件，其中兩個重要的條件就是mac地址和ip地址，沒有那臺計算機能掌握全面的互聯網中的細節，這就須要多臺計算機作中轉，而進行中轉時，會利用下一站中轉設備的MAC地址來搜索下一個目標。這是會採用ARP協議(Address Resolution Protocol)，這是一種解析地址的協議，能根據IP查詢MAC地址。 具體的步驟以下:

發送端請求IP -> ARP解析成MAC地址 -> 找到相關路由 ->  ARP解析成MAC地址 -> 找到相關路由 -> ... -> 目的地

1. 確保可靠性的TCP協議

TCP位於傳輸層，提供可靠的字節流服務。將大塊數據分割成報文段爲單位的數據包進行管理，而可靠的傳輸服務是指，可以將數據準確可靠的傳給對方。

爲了能準確的到達目標，TCP協議採起了三次握手策略，握手過程當中採用了TCP的標誌SYN和ACK

發送端發送SYN -> 接收端回傳SYN/ACK(用來傳達確認信息) -> 發送端發送SYN + 數據包(握手結束)

若是以上任何一個步驟終端，會再次以相同的順序發送數據包

1.3 負責域名解析的DNS服務(應用層)

DNS協議經過提供的域名查找IP地址，或者逆向從IP地址反查域名的服務

# 訪問某個頁面
DNS解析成IP -> HTTP協議生成請求報文 -> TCP切割報文，三次握手保證傳輸的可靠性 -> IP協議搜索對方地址，一邊中轉一遍傳送
(最終能夠利用TCP/IP通訊協議向用戶進行回傳)

1.4 URI和URL

URL(Uniform Resource Locator) 統一資源定位符，好比http://cnblogs.com

URI(Uniform Resource Identifier) 統一資源標識符

Identifier表示可標識對象。也成爲標識符。

URI用字符串標識某一互聯網資源，而URL表示資源的地點。可見URL是URI的子集

# 一個標準的URI
http://user:pass@www.example.com:80/dir/index.html?uid=1#ch1

2. 簡單的HTTP協議

2.1 HTTP協議用於客戶端和服務端之間的通訊

HTTP協議能明確的肯定哪端是服務端，哪端是客戶端。先從客戶端創建通訊，服務端沒有接收到請求前不會發送響應。

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

# 簡單的請求頭
GET /index.html HTTP/1.1
HOST: hackr.jp

以上簡單的請求頭規定了請求方法，請求資源，HTTP版本

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

# 簡單的響應體
HTTP/1.1 200 OK
Date: Tue, 10 Jul 2012 06:50:16 GMT
Content-Length: 362
Content-Type: text/html

2.3 HTTP是不保存狀態的協議

HTTP是一種不保存狀態，即無狀態的協議。也就是說協議對於發送過得請求或者響應都不作持久化處理

爲了實現指望的保持狀態的功能，因而引入了cookie技術。有了cookie再用HTTP協議通訊，就能夠管理狀態了

2.4 請求URI定位資源

若是不是訪問特定資源，而是訪問這個服務器，可使用一個*來代替URI

OPTIONS * HTTP/1.1

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

GET

POST 傳輸實體主題

PUT 傳輸文件

HEAD 得到報文首部

DELETE 刪除文件

OPTIONS 用來查詢支持的方法

TRACE 追蹤路徑

客戶端經過trace方法能夠查詢發送出去的請求是怎樣被加工修改/篡改的。這是由於請求想要鏈接到源目標服務器可能會經過代理中轉，trace方法就是用來確認鏈接過程當中發生的一系列操做

CONNECT 要求用隧道協議鏈接代理

2.6 使用方法下達命令

指定請求的資源定期望產生某種行爲。方法中有GET, POST, HEAD等

2.7 持久鏈接節省通訊量

爲解決上述TCP鏈接的問題，HTTP/1.1和一部分的HTTP/1.0想出了持久鏈接keep-alive，持久鏈接的特色是隻要任意一端沒有明確提出斷開鏈接，則保持TCP鏈接狀態。

創建TCP鏈接 ->SYN -> SYN/ACK -> ACK 
-> HTTP請求 -> HTTP響應 -> HTTP請求 -> HTTP響應... 
-> FIN -> ACK -> FIN -> ACK -> 斷開TCP鏈接

2.8 使用Cookie的狀態管理

HTTP無狀態協議，它不對以前發生過的請求和響應作狀態管理。也就是說沒法根據以前的狀態進行本次請求處理

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

響應報文中一個叫Set-Cookie的首部字段信息，通知客戶端保存cookie，當下次客戶端再往改服務器發送請求時，客戶端會自動在請求報文中加入cookie

3. HTTP報文內HTTP信息

3.1 HTTP報文

請求報文

響應報文

報文自己是由多行數據構成的字符串文本

3.2 請求報文以及響應報文的結構

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

狀態行：包含代表響應結果的狀態碼，緣由短語和HTTP版本

首部字段：包含表示請求和響應的各類條件和屬性的各種首部

3.3 編碼提高傳輸速率

傳輸過程當中經過編碼提高傳輸速率，經過在傳輸時編碼，能有效處理大量的訪問請求。可是編碼的操做會消耗更多的CPU

HTTP報文的主體用於傳輸請求或響應實體主題

一般的編碼有：

gzip
compress
deflate
identify

HTTP會對較大的實體進行分割，將實體主體分紅多個部分。每一塊都會用十六進制來標記塊的大小

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

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

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

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

在HTTP報文中使用多部分對象集合時，須要在首部字段里加上Content-Type。

3.5 獲取部份內容的範圍請求

要實現該功能須要指定下載的實體範圍。指定範圍發送的請求叫範圍請求(Range Request)

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

獲取5001-10000字節的部分
Range: bytes=5001-10000

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

請求報文中某些首部字段就是判斷的基準

Accept
Accept-Charset
Accept-Encoding
Accept-Language
Content-Language

4. 返回結果的HTTP狀態碼

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

4.2 2XX成功

200 OK
204 No Content
206 Partial Content

4.3 3XX重定向

301 Moved Permanently
302 Found
303 See Other
304 Not Modified 不包含任何響應的主體部分

4.4 客戶端錯誤

400 Bad Request 請求報文中存在語法錯誤
401 Unauthorized 表示發送的請求須要經過HTTP認證
403 Forbidden 服務器拒絕訪問
404 Not Found 服務器上找不到資源

4.5 5XX服務器錯誤

500 Interal Server Error 服務端執行請求發生bu
503 Service Unavailable 服務器暫時處於超負載或正在進行停機維護，如今沒法處理請求

5. 與HTTP協做的Web服務器

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

HTTP1.1規範容許一臺HTTP服務器搭建多個WEB站點。即便物理層只有一臺服務器，但只要使用虛擬主機的功能，則能夠假想已經擁有多臺服務器

在相同的IP地址下，因爲虛擬主機能夠寄存多個不一樣主機名和域名的Web網站，所以在發送HTTP請求時，必須在Host首部內完成指定主機名或域名的URI

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

代理服務器的基本行爲就是接受客戶端發送的請求後轉發給其餘服務器。代理不改變請求URI，會直接發送給前方持有資源目標服務器

每次通過代理服務器轉發請求或響應時，會追加寫入Via首部信息

緩存代理：代理轉發響應時，緩存代理會預先將資源的副本保存在代理服務器上。當再次接收到相同請求時，就不會從源服務器那裏獲取資源。而是將緩存返回。

5.3 保存資源的緩存

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

緩存不只能夠存在客戶端瀏覽器中。還能夠存在於服務器中。把客戶端緩存稱爲臨時網絡文件Temporary Internet File

6.http首部

6.1 HTTP報文首部

首部內容爲客戶端和服務器端分別處理請求和響應提供所須要的信息。

請求報文首部包含

1. 請求行（方法，URI，HTTP版本）
2. 請求首部字段
3. 通用首部字段
4. 實體首部字段

響應報文包括

1. 狀態行（HTTP版本，狀態碼）
2. 請求首部字段
3. 通用首部字段
4. 實體首部字段

6.2 HTTP首部字段

在HTTP協議通訊交互中使用到的首部字段，不限於RFC2616中定義的47種首部字段。還有Cookie, Set-Cookie, Content-Disposition等在其餘RFC中定義的首部字段。

6.3 HTTP/1.1通用首部字段

1. Cache-Control

多個指令之間經過，分隔。首部字段

Cache-Control: private, max-age=0, no-cache

• public 明確表示其餘用戶也可使用緩存
• private 特定的用戶可使用緩存
• no-cache 禁用緩存，防止從緩存中返回過時資源
• no-store 暗示請求和響應中包含機密信息
• max-age 設置緩存時間。若是超過這個緩存時間就須要將請求轉發給源服務器

1. Connection

• 控制再也不轉發給代理的首部字段

GET / HTTP / 1.1
Upgrade: HTTP/1.1
Connection: Upgrade
# Upgrade首部字段將再也不轉發

• 管理持久鏈接

Connection: Keep-Alive

1. Date

表示建立HTTP報文的日期和時間

1. Pragma

6.4 請求首部字段

請求首部字段是從客戶端往服務器端請求報文中所使用的字段，用於補充請求的附加信息、客戶端信息、對響應內容相關的優先級等

1. Accept 首部字段可通知服務器，用戶代理可以處理的媒體類型或文件類型

2. Accept-Charset 客戶端支持接收的字符集

3. Accept-Encoding 客戶端支持的內容編碼，可一次性指定多種編碼

4. Accept-Language 用來告知服務器用戶代理可以處理的天然語言集

5. Authorization 用來告知服務器用戶代理認證信息

6. Expect 用來告知服務器指望出現的某種特定行爲

7. Host 請求的資源所處的互聯網主機名和端口號

8. If-Match 服務器接收到附帶條件後，只有判斷指定條件爲真時，纔會接受請求

9. User-Agent 將建立請求的瀏覽器和用戶代理名稱等信息傳達給服務器。

6.5 響應首部字段

響應首部字段是由服務器端向客戶端返回響應報文中所使用的字段

1. Accept-Ranges 告知客戶端是否能處理範圍請求，以指定服務器端某個部分的資源

2. Age 告知客戶端源服務器多久前建立了響應

3. ETag 將資源以字符串形式作惟一性標誌的方式，當資源更新時，ETag值也會更新。

4. Location 能夠將響應接受方引導至某個與請求URI位置不一樣的資源

5. Proxy-Authenticate 會把由代理服務器所要求的認證信息發送給客戶端

6. Retry-After 告知客戶端應該在多久以後再次發送請求

7. Server 告知客戶端當前服務器上安裝的HTTP服務器程序信息(Apache/2.2.17 Unix)

8. Vary 源服務器會向代理服務器傳達關於本地緩存使用方法的命令

9. WWW-Authenticate 用於HTTP訪問認證

6.6 實體首部字段

實體首部字段是包含在請求報文和響應報文中的實例部分所使用的首部。

1. Allow 通知客戶端可以支持的全部的HTTP方法

2. Content-Encoding 通知客戶端對實體的主體部分選用的內容編碼方式

3. Content-Language 通知客戶端實體的主體部分的天然語言

4. Content-Length 通知客戶端實體主題部分的大小(字節)

5. Content-Location 給出報文主體部分相對應的URI

6. Content-MD5 對報文主體執行MD5算法，再經過Base64編碼後將結果寫入Content-MD5字段值

7. Content-Range 返回響應時使用的首部字段

8. Content-Type 說明了實體主題內對象的媒體類型

9. Expires 通知客戶端資源的失效日期

10. Last-Modified 通知客戶端資源的最終修改時間

6.7 爲Cookie服務的首部字段

當服務器準備開始管理客戶端狀態時，會事先告知各類信息

1. Set-Cookie 設置cookie
   • NAME=VALUE
   • expires
   • path
   • domain
   • secure
   • HttpOnly
2. Cookie 告知服務器，攜帶客戶端的Cookie

7. 確保Web安全的HTTPS

7.1 HTTP的缺點

• 通訊使用明文，可能會被竊聽
  經過和SSL(Secure Socket Layer)或者TLS(Transport Layer Security)的組合使用，加密HTTP的通訊內容。與SSL組合使用的HTTP稱爲HTTPS

• 不驗證通訊方的身份，可能遭遇假裝
  SSL不只提供加密處理，並且還使用了一種被稱爲證書的手段，能夠用於肯定方。

• 沒法證實報文的完整性

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

8.確認訪問用戶身份認證

8.1 何爲認證

HTTP/1.1 使用的認證方式以下所示

• BASIC認證
• DIGEST認證
• SSL客戶端認證
• FormBase認證

8.2 BASIC認證

基本步驟

須要basic認證 -> 服務端401 Authrization Required -> WWW-Authenticate -> ID和密碼發送給服務器（base64編碼） -> 服務端密碼認證

8.3 DIGEST認證

採用質詢/響應方式

認證要求 -> 質詢碼 -> 響應碼

8.4 SSL客戶端認證

SSL客戶端認證是藉由HTTPS的客戶端證書完成認證的方式，憑藉客戶端證書認證，服務端可確認訪問是否來自於已登陸的客戶端。

8.5 基於表單的認證

基於表單的認證方法並非在HTTP協議中定義的。客戶端會向服務器上的web應用程序發送登陸信息，按登陸信息的驗證結果認證

9. 基於HTTP的功能追加

9.1 基於HTTP的協議

9.2 消除HTTP瓶頸的SPDY

HTTP的瓶頸

• 一條鏈接上只可發送一個請求
• 請求只能從客戶端開始。客戶端不能夠接收除響應之外的指令
• 請求響應首部未通過壓縮就發送
• 發送冗長的首部。每次互相發送相同的首部形成浪費較多
• 可任意選擇數據壓縮格式。非強制壓縮發送

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

鏈接的發起方還是客戶端。一旦確立通訊，不論服務器仍是客戶端，任意一方均可直接向對方發送報文。

10. 構建web內容技術

本章是web開發基礎，略

11. Web的攻擊技術

11.1 針對web的攻擊技術

從瀏覽器那接收到的HTTP請求的所有內容，均可以在客戶端自由的變動，篡改。因此web應用可能會接收到與預期數據不相同的內容。

• 主動攻擊
• 被動攻擊

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

XSS: 經過存在安全漏洞的web網站註冊用戶的瀏覽器內運行非法的HTML標籤或JavaScript進行的一種攻擊

// 常見狀況一
input中輸入帶有非法字符的代碼
// 常見狀況二
URL中的查詢參數帶有非法代碼

SQL注入是指針對web應用使用的數據庫，經過運行非法的SQL產生的攻擊

OS攻擊

HTTP首部注入攻擊：在HTTP響應首部字段內插入換行，添加任意響應首部或主體的一種攻擊

%0D%0A表明HTTP的換行符

郵件首部注入攻擊：攻擊者經過向郵件首部To或Subject內任意添加非法內容發起的攻擊

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

1. session劫持

2. CSRF 跨站請求僞造

跨站點請求僞造攻擊是指攻擊者經過設置好的陷阱，強制對已完成認證的用戶進行非預期的我的信息或設定信息等某些狀態的更新