【我的向】《HTTP圖解》閱後小結

前言

計算機網絡課程的學習已是在大二下學期的時候了，過去了半年多，有不少東西彷佛都忘記了QAQ。何況當時上課的時候就感受專業術語多，不少知識也難以理解，可是仍是硬着頭皮學了下來，現在閱讀《HTTP圖解》這本書發現很好理解，可是須要增強印象還得本身總結與實踐，因此寫了這篇文章。

網絡基礎

最初的念想
藉助多文檔之間的關聯造成的超文本連成可互相參閱的萬維網。

三項WWW構建技術:

1. SGML做爲頁面的文本標記語言的HTML（HTML5已不在SGML基礎上）
2. 做爲文檔傳遞協議的HTTP
3. 指定文檔所在地址的URL

HTTP（超文本傳輸協議，書上說稱爲超文本轉移協議更嚴謹）
破殼日：1989年3月
客戶端到服務器通訊的流程是創建在HTTP協議之上的。

TCP/IP的協議模型

在每次進行信息傳輸的時候，信息都要從高層傳到底層，會通過不斷的「包裝」。再從對方的底層傳到高層，這時會不斷的「拆包裝」。
在這之中也會用到各個層的一些很重要的協議，在一次HTTP請求發送中：
應用層（應用層、表示層、會話層）：HTTP、DNS
傳輸層：TCP
網絡層：IP、ARP
其中DNS協議用於解析域名，TCP協議用於肯定目標計算機資源端口，IP協議用於肯定目標計算機的IP地址，ARP協議用於把IP地址轉換爲真正的物理地址MAC。

TCP協議
TCP提供可靠的字節流服務，會把數據分割成報文段進行發送。
TCP用SYN和ACK標誌來確認對方是否成功送達：
1.發送端發送：SYN。
2.接收端接收後，發送SYN和ACK。
3.發送端接收後，再次發送ACK，握手結束。

綜上，當咱們從瀏覽器輸入一個URL後，發生了這些事：
客戶端想瀏覽URL爲 http://www.mochiko.cn 的頁面，HTTP協議生成請求頁面資源報文，TCP協議把HTTP請求報文分割爲多個文段，把文段可靠的傳給對方。隨後IP協議搜索對方的地址，一遍中轉，一遍傳送。（省略了網絡層如下的了）隨後TCP協議把收到的報文段從新組合成原來的順序，而後HTTP協議把WEB服務器請求的內容進行處理，並返回請求的結果和內容。

wireshark抓包結果可看到，首先發生了三次握手，創建起了TCP連接。隨後發出HTTP請求，TCP再把報文分紅了四段發送，其中收到了三個數據接收回復，最後HTTP返回200 OK表示成功發送完了主頁的HTML文件。

在這次抓包中，這裏的x=0,y=0,第二次x=1，第三次，x=y=1，符合圖中的規則。

URL
URI 統一資源標識符（在《HTTP權威指南》裏面對URI的解釋更充分一點）

協議方案名://登陸信息@服務器地址:端口號/帶層次的文件路徑?查詢字符串#片斷標識符

初識HTTP

• HTTP協議用於客戶端和服務器端之間的通訊，請求一定由客戶端發出，服務器端被動回覆。
• HTTP協議不保存狀態，是無狀態協議。
• HTTP協議使用URI定位互聯網資源。

請求報文

開頭GET是請求服務器的類型，即方法，隨後的「/」表示請求訪問的資源對象。最後的HTTP1.1是版本號。

請求報文結構：

響應報文

開頭是HTTP的版本，200是狀態碼，OK是短語。下面（沒截）還帶有HTML的主體代碼。

響應報文結構：

HTTP方法

GET：獲取資源
指定的資源通過服務器解析後返回相應內容，即文本直接返回，CGI返回通過執行後的結果。

POST: 傳輸實體主題
PUT和GET功能類似，可是POST的主要目的不是獲取響應的主題內容

PUT：傳輸文件
像FTP文件上傳同樣，要把請求報文主題包含在文件內容，保存在請求URI的指定位置上。
HTTP/1.1的PUT自身不帶驗證，任何人均可以上傳，存在安全性問題，通常不使用。若配合WEB應用程序的驗證機制或架構設計採用REST標準則可能開放使用。

HEAD：得到報文首部
和GET方法同樣，但不返回報文主體部分。用於確認URI有效性和資源更新的日期等。

DELETE：刪除文件
與PUT相反的方法，一樣存在安全性問題。

OPTIONS：詢問支持的方法
查詢針對請求URI指定的資源支持方法。
1.1版本才支持。

TRACE：追蹤路徑
讓WEB服務器端將以前的請求通訊環回給客戶端，發送請求把Max-Forwards首部字段填入數值，每通過一個服務器端就把該數字減1，是0時中止傳輸。容易引起XST攻擊，一般不會用到。
1.1版本才支持。

CONNECT：用隧道協議鏈接代理
主要用SSL和TSL協議把通訊內容加密經網絡隧道傳輸。
1.1版本才支持。

其餘特性

持久連接節省通訊量
HTTP 1.1和部分HTTP 1.0提供持久連接，只要任意一段沒有提出斷開連接，就保持TCP連接狀態。

能夠查看抓包數據，發送成功一個請求後沒有斷開TCP鏈接，此圖也適用於管線化的說明，同時發送幾個HTTP請求。

管線化
從前必需要收到響應才發送新的請求，而管線化技術不須要等待，能夠同時發送多個請求。

Cookie管理狀態
由於HTTP是無狀態的協議，因此須要Cookie來管理狀態：
1.客戶端發送請求。
2.服務器對這個客戶端生成一個Cookie，保存下來，併發送回去。
3.客戶端保存這個Cookie。
4.客戶端第二次發送請求，帶着Cookie一塊兒發送。
5.服務器堅持Cookie，分析出是剛纔那個客戶端。

瞭解HTTP

HTTP報文自己是由多行（CR+LF換行符）數據構成的文本。[這點上頭的示例報文很明顯了]。

壓縮內容編碼
原貌傳輸速度沒有壓縮後的編碼速度快，可是相應會消耗資源。
常見編碼有：

1. gzip(GUN zip)
2. compress
3. deflate
4. identity

報文主體和實體主體
報文主體用於傳輸請求或者響應實體主體。

分塊傳輸編碼
把實體主體分紅多個部分，每一塊用十六進制標記塊大小，最後一塊用「0（CR+LF）」標記。

發送多種數據多對象集合
MINE機制容許多個不一樣類型的二進制數據以ASCII碼指明。
多部分對象集合包含：
1.multipart/form-data
2.multipart/byteranges
3.multipart/form-data
用boundary字符串（指定各個實體開始和結束加入--）劃分多部分對象集合類型。

range獲取指定範圍數據

圖爲一個大圖的GET請求，Range表示請求933343~2151819之間的字節

針對範圍請求，會有206狀態碼返回。若服務器沒法響應，就是返回200狀態碼。

Accept內容協商
包括服務器驅動協商，客戶端驅動協商和透明協商
Accept
Accept-Charset
Accept-Encoding
Accept-Language
Content-Language

協做HTTP的WEB服務器

虛擬主機
物理層面只有一臺服務器，利用虛擬主機能夠實現爲多個域名提供各自的服務。
DNS服務把域名解析爲IP地址，服務器假如託管了多個域名，必需要弄清楚究竟是訪問了哪一個。即應在HTTP報文Host首部標記清楚。

HTTP通訊除了客戶端和服務器之間，還有一些用於通訊數據轉發的應用程序：代理、網關、隧道配合工做。
代理
具備轉發功能的應用程序，服務器與客戶端之間的中間角色。

網關
轉發其餘服務器通訊數據的服務器，即與非HTTP協議進行通訊。

隧道
相隔甚遠的客戶端和服務器二者之間進行中轉，並保持雙方通訊鏈接。

代理
接收客戶端發送請求轉發給其餘服務器，代理不改變請求URI,直接發送給前方擁有資源的目標服務器。
每次通過一個代理，會追加寫入Via首部信息。
緩存代理：轉發響應會把預先資源的副本保存在代理服務器上，有一個期限，下次請求能夠直接返回。（緩存還能夠留在瀏覽器中，叫作臨時網絡文件）
透明代理：轉發不對報文作任何加工（反之則是非透明代理）。

狀態碼和短語

1XX Information

接受的請求正在處理

2XX Success

請求正常處理完畢

200 OK
客戶端發來的請求被正常處理了，返回的信息由於方法不一樣而不一樣。

204 No Content
客戶端發來的請求被正常處理了，但不包含實體的主體部分。

206 Partial Content
客戶端進行了範圍請求，且服務器正確執行了請求，響應報文中包含由Content-Range指定範圍的主體。

3XX Redirection

重定向，須要進行附加操做

301 Move Permanently
永久性重定位，狀態碼錶示請求的資源已經被分配了新的URI，之後應用如今指定的URI。若是URI保存書籤了，也應該按照Location首部字段提示保存。

輸入URL最後不加/會產生301狀態碼

302 Not Found
臨時性重定向，請求的資源被分配了新的URI，但願用戶用新的URI訪問。

303 See Other
與302有相同的功能，可是303明確表示客戶端用GET方法獲取資源。

304 Not Modified
客戶端發送附帶條件的GET請求：If-Match、If-Modified-Since、If-None-Match、If-Range、If-Unmodified-Since，服務器容許請求資源，但因發生請求不知足條件而返回。

307 Temporary Redirect
臨時重定向，與302 Found相同含義。307不會從POST變成GET，不過要看具體瀏覽器。

4XX Client Error

客戶端錯誤

400 Bad Request
請求報文中存在語法錯誤。

401 Unauthorized
發送請求須要經過HTTP認證的認證信息。頭部必須包含一個WWW-Authentiate首部質詢用戶信息

403 Forbidden
訪問請求資源被拒絕。

404 Not Found
沒法找到資源或者服務器拒絕請求且不想說明理由。

5XX Server Error

500 Internal Service Error
服務器在執行請求時發生了錯誤。

503 Service Unvaliable
服務器暫時超載或正在進行停機維護，沒法進行處理。若事先知道時間，返回Retry-after字段。

HTTP/1.1通用首部字段

即響應報文和請求報文均可以用的字段
Cache-Control
操做緩存，參數可選，逗號分隔
public：其餘用戶也能夠利用緩存。
private：特定用戶能夠利用緩存。
no-cache：不是不緩存，是客戶端不接受緩存過的響應，因此緩存服務器必需要把請求轉發出去。若對它賦值（如no-cache=Location），表示客戶端接收到這個參數的響應報文後不能使用緩存。
no-store：按時請求或響應中包含機密信息。規定緩存不能在本地存儲請求或響應的部分。
s-maxage： 功能和max-age相同，但這個適用於多位用戶使用的公共緩存服務器。
max-age： 單位秒，緩存時間比指定時間數值小則接收數據。HTTP/1.1還存在Expires首部字段，會優先處理max-age，而HTTP/1.0中max-age會被忽略。
min-fresh：緩存服務器返回至少還未過指定時間的緩存資源。
max-stale：過時緩存資源也接收。
only-if-cached：客戶端僅在緩存服務器本地緩存目標資源的狀況下返回，若請求緩存服務器本地緩存無反應，返回504。
must-revalidate：代理向源服務器再次驗證即將返回響應緩存是否有效。沒法鏈接服務器返回504。用這條會忽略max-stale。
proxy-revalidate：全部緩存服務器在收到客戶端指令請求返回時，再次驗證緩存有效性。
no-transform：請求或相應中都不能改變主體媒體類型。

Connection

1. 控制再也不轉發給代理的首部字段
2. 管理持久鏈接：HTTP/1.1默認是持久連接，想斷開鏈接指定Connection:Close。舊版本默認是非持久，因此須要指明Connection：Keep-Alive。

   Connection:再也不轉發的首部字段名
   Connection:close

Date
建立HTTP報文的日期時間

Pragma
歷史遺留字段，爲了兼容而存在
Pragma:no-cacheyao要求中間緩存服務器不返回緩存。

Trailer
事先說明在報文主體後記錄了哪些首部字段。

Transfer-Encoading
規定報文主體採用的編碼方式。進隊分塊傳輸編碼有效。

Upgrade
檢測HTTP協議及其餘協議是否可以使用高版本進行通訊，參數能夠指定一個徹底不一樣的通訊協議。

Via
追蹤客戶端與服務器之間的請求和響應報文的傳輸路徑。

Warning從1.0版本的Retry-After演變過來的，一般會告知用戶一些緩存相關的問題警告。1.1版本定義了7種警告：110 Response is stale 代理返回已過過時資源111 Revalidation failed 代理再驗證資源有效失敗112 Disconnection operation 斷開鏈接操做113 Heuristic expiration 試探性過時，響應試用期超過24小時199 Miscellaneous warning 任意的警告內容214 Transformation applied 代理對內容編碼或媒體類型執行了某些處理299 Miscellaneous persistent warning 任意的警告內容