圖解http協議

第一章 瞭解Web及網絡能基礎

一、HTTP是什麼

HyperText Transfer Protocol 超文本傳輸協議

二、HTTP當前使用較多的版本

http 1.1

三、TCP/IP協議族

1、協議族 解決了如下的問題 進而指定的一系列規則
一、怎樣探測到通訊的目標 目標
二、由哪一邊發起通訊 發
三、使用哪種語言進行通訊 發送中
四、怎樣結束通訊 發送完
2、TCP/IP的分層管理
應用層：向用戶提供應用服務時的通訊活動 FTP HTTP DNS
傳輸層：提供處於網絡鏈接的兩臺計算機之間的數據傳輸 TCP UDP
網絡層： 數據包經過怎樣的路徑到達目標地址 IP ARP RARP
鏈路層：用來處理網絡的硬件部分 網卡

四、與HTTP協議關係密切的IP TCP DNS

IP地址 指明瞭節點被分配到的地址
MAC地址 網卡所屬的固定地址
使用ARP協議憑藉MAC地址進行通訊
1、確保可靠性的TCP協議
TCP傳輸協議
在TCP/IP協議中，TCP協議提供可靠的鏈接服務，採用三次握手創建一個鏈接。
第一次握手：創建鏈接時，客戶端發送syn包(syn=j)到服務器，並進入SYN_SEND狀態，等待服務器確認；
第二次握手：服務器收到syn包，必須確認客戶的SYN（ack=j+1），同時本身也發送一個SYN包（syn=k），即SYN+ACK包，此時服務器進入SYN_RECV狀態；
第三次握手：客戶端收到服務器的SYN＋ACK包，向服務器發送確認包ACK(ack=k+1)，此包發送完畢，客戶端和服務器進入ESTABLISHED狀態，完成三次握手。 完成三次握手，客戶端與服務器開始傳送數據.

下面是一個TCP三次握手的實例
IP 192.168.1.116.3337 > 192.168.1.123.7788: S 3626544836:3626544836
IP 192.168.1.123.7788 > 192.168.1.116.3337: S 1739326486:1739326486 ack 3626544837
IP 192.168.1.116.3337 > 192.168.1.123.7788: ack 1739326487,ack 1

第一次握手：192.168.1.116發送位碼syn＝1,隨機產生seq number=3626544836的數據包到192.168.1.123,192.168.1.123由SYN=1知道192.168.1.116要求創建聯機;

第二次握手：192.168.1.123收到請求後要確認聯機信息，向192.168.1.116發送ack number=3626544837,syn=1,ack=1,隨機產生seq=1739326486的包;

第三次握手：192.168.1.116收到後檢查ack number是否正確，即第一次發送的seq number+1,以及位碼ack是否爲1，若正確，192.168.1.116會再發送ack number=1739326487,ack=1，192.168.1.123收到後確認seq=seq+1,ack=1則鏈接創建成功。
負責域名解析的DNS
Domain Name System 提供域名到ip的解析服務

五、URL的格式

http://user:pass@www.example....
協議：http https
登陸信息:指定用戶名和密碼從服務器端獲取資源時必須的登陸信息
服務器地址：域名
服務器端口號：
帶層次的文件路徑：用來指定資源在服務器的位置
查詢字符串：可選
片斷標識符：可選 文檔內的某個位置

第二章 簡單的HTTP協議

HTTP方法

GET：獲取資源

POST：傳輸實體主體

PUT 向服務器傳輸文件

HEAD 得到報文首部

DELETE 刪除服務器上的文件

OPTIONS 詢問服務器支持的方法
一種應用的場景 發送非簡單的cors請求時 瀏覽器會首先發送options方法來詢問服務器支持的方法。參見https://segmentfault.com/a/11...

http中的長鏈接

HTTP1.1和HTTP1.0相比較而言，最大的區別就是增長了持久鏈接支持(貌似最新的 http1.0 能夠顯示的指定 keep-alive),但仍是無狀態的，或者說是不能夠信任的。在http1.0中使用Connection:keep-alive來標記此次請求是長鏈接的請求。
因此 若是web服務器端看到這裏的值爲「Keep-Alive」，或者看到請求使用的是HTTP 1.1（HTTP 1.1默認進行持久鏈接），它就能夠利用持久鏈接的優勢，當頁面包含多個元素時（例如Applet，圖片），顯著地減小下載所須要的時間。
長鏈接vs短鏈接
所謂長鏈接指創建SOCKET鏈接後不論是否使用都保持鏈接，但安全性較差，
所謂短鏈接指創建SOCKET鏈接後發送後接收完數據後立刻斷開鏈接，通常銀行都使用短鏈接

使用cookie的狀態管理

HTTP是無狀態的協議 不對以前發生過的請求和響應的狀態進行管理
瀏覽器第一次向服務器發起請求

瀏覽器第二次向該服務器發送請求

下面是步驟1 2 3分別對應的報文
一、請求報文
GET /reader/HTTP/1.1
HOST:hackr.jp
二、響應報文
HTTP/1.1 200 OK
Date:Tur,12 jul 2012 07:12:20 GMT
Server Apache
<set-cookie:sid=12211212121 ;path=/ expires=wed,10-0ct-12 >
Content-Type:text/plain charset=UTF-8
三、請求報文
GET /image /http/1.1
Host : hacker.jsp
Cokkie:sid=12211212121

第三章 HTTP報文內的HTTP信息

報文的結構

報文首部 報文主體（用於傳輸請求或響應的實體主體）

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

請求報文的結構
報文首部：請求行（方法 URI http版本） 請求首部字段 通用首部字段 實體首部字段 報文主體
響應報文的結構
報文首部：狀態行（狀態碼 緣由短語 http版本） 響應首部字段 通用首部字段 實體首部字段 報文主體

第四章 服務器返回響應的狀態碼

狀態碼的類別

2xx 成功

200 ok 客戶端發過來的請求被正常的處理

204 No Content 服務器接受的請求已被成功的處理 可是沒有內容返回

好比說  瀏覽器發出的put   delete   方法  服務器成功的處理了請求  可是不會返回任何的內容

206 partial Content 客戶端進行了範圍請求 並且服務器成功的處理了這個請求 在服務器的響應中包含由

Content-Range  指定範圍的實體內容

3xx 重定向

301 Moved Permanently 永久性重定向 表示客戶請求的文檔在其餘地方，必須在響應頭部Location字段中指明新的永久性的URI。這個操做會將瀏覽器的書籤也會改變

302 Found 臨時重定向 此次的訪問地址改變 可是瀏覽器中的書籤不會被改變

304 Not Modified
可能會出如今如下的幾種狀況：
一、針對請求中的if-modified-Since 若是服務器沒有更新 就會返回304 更新了就200
若是客戶端在請求一個文件的時候，發現本身緩存的文件有 Last Modified ，那麼在請求中會包含 If Modified Since ，這個時間就是緩存文件的 Last Modified 。所以，若是請求中包含 If Modified Since，就說明已經有緩存在客戶端。只要判斷這個時間和當前請求的文件的修改時間就能夠肯定是返回 304 仍是 200 。對於靜態文件，例如：CSS、圖片，服務器會自動完成 Last Modified 和 If Modified Since 的比較，完成緩存或者更新。可是對於動態頁面，就是動態產生的頁面，每每沒有包含 Last Modified 信息，這樣瀏覽器、網關等都不會作緩存，也就是在每次請求的時候都完成一個 200 的請求。
二、當用戶第一次訪問某個靜態資源的時候，服務器會返回
狀態碼：200
首部字段：Etag:dadmsdadks23
實體：相應的內容

當用戶第二次請求該靜態資源的時候會發送
首部字段：if-None-Math:w/dadmsdadks23
若是這個靜態資源的實體值仍然爲dadmsdadks23 就會返回304

4xx 客戶端錯誤

400 Bad Request 該狀態碼 表示瀏覽器發起的請求中存在語法錯誤
401 Unauthorized 這個請求須要 HTTP認證
403 Forbidden 此次的請求被服務器拒絕了
404 Not Found 瀏覽器發起的請求的資源在服務器上沒有找到

5xx服務器錯誤

500 Internal Server Error 服務器內部發生了錯誤
503 Service Unavailable 服務器不可用

第五章 與http協做的web服務器

通訊數據轉發程序 代理 網管 隧道

代理 有轉發功能的應用程序 扮演了位於服務器和客戶端 「中間人」的角色
網管 接受從客戶端發送過來的請求 它就像本身擁有子單元的源服務器同樣對請求進行處理
隧道 客戶端和服務器之間進行中轉 並保持雙方通訊鏈接的應用程序

第六章 HTTP首部

HTTP首部的種類

請求首部 響應首部 通用首部 實體首部

請求首部

一、Accept：text/plain,application/xhtml+xml,application/xml;q=0.3
通知服務器，我（客戶端）可以處理的媒體類型及權重(0-1) 不指定權重的時候默認是1
二、Accept-charset:iso-8859-5,unicode-1-1;q=0.8
通知服務器，我（客戶端）可以支持的字符集 及權重(0-1)
三、Accept-Ecoding:gzip,deflate
通知服務器，我（客戶端）可以支持的內容編碼
四、Accept-Language:zh-cn,zh;q=0.7,en-us,en;q=0.3
通知服務器，我（客戶端）可以處理的自燃語言集及權重(0-1)
五、Authorization: Basic dwVub3N1jasasjai=
通知服務器，我（客戶端）的認證信息。一般須要服務器認證的客戶端會在收到響應401 未受權的時候再發出帶有這樣首部的一個請求 從而向服務器發送認證的相關信息
六、Expect:100-continue
通知服務器，我（客戶端）指望的出現的某種特定的行爲 當服務器沒法理解客戶端的指望作出響應時 相應的狀態碼爲417 Expectation Failed
七、Host
通知服務器，我（客戶端）請求的資源在 服務器的主機名和端口號
八、if-match:123456 <etag_value>
條件請求 服務器接收到這樣的條件請求時 只有判斷條件爲真的時候 纔會處理請求
（1）For GET 和 HEAD 方法，搭配 Range首部使用，能夠用來保證新請求的範圍與以前請求的範圍是對同一份資源的請求。若是 ETag 沒法匹配，那麼須要返回 416 (Range Not Satisfiable，範圍請求沒法知足) 響應。
九、if-None-Match <etag_value>
當且僅當服務器上沒有任何資源的 ETag 屬性值與這個首部中列出的相匹配的時候，服務器端會才返回所請求的資源，響應碼爲 200
十、Range:byte=5001-10000
告知服務器 主須要返回 從第5001-10000字節的資源
十一、refer：http://www.hacker.jp/index.html
告知服務器發起請求的 原始資源的URI 域名+資源名
十二、User-Agent：Mozilla/5.0(windows NT)
告知服務器 我（客戶端）訪問服務器時正在使用的瀏覽器的版本

響應首部字段

一、Accept-Ranges：bytes
告知客戶端，我（服務器）可以處理的請求範圍
二、Age：600 //這個緩存向源服務器確認過 如今已通過去10分鐘了
告知客戶端，我（服務器）在多久以前建立了響應（秒） 表示消息對象在緩存代理服務器中存貯的時長
三、ETag: <etag_value>
服務器會爲每份資源添加ETag 可以告知客戶端這個實體的標識 將資源以字符串的形式做爲惟一的標識，當資源更新的時候 字符串也須要更新
四、Location:http://www.newLocation.com
配合狀態碼 301 302 將瀏覽器引導到新的地址 進而實現重定向
五、Retry-After：120 //告訴客戶端你等2分鐘以後再發送請求
配合狀態碼503（服務器不可用）一塊兒使用
六、Server：Apache/2.2.1
告知客戶端，我（服務器）的信息

通用首部字段

一、Cache-control 如下是它可能的取值
緩存請求指令
no-cache----不要讀取緩存中的文件，要求向WEB服務器從新請求 區別於no-store
no-store----請求和響應都禁止被緩存
max-age：60----表示當訪問此網頁後的1分鐘內不會去服務器請求，

這個功能與Expires相似，只是Expires是根據某個特定日期值作比較。一但緩存者自身的時間不許確.則結
    果可能就是錯誤的，而max-age,顯然無此問題.。Max-age的優先級也是高於Expires的。

only-if-cached ---- 告知緩存者,我但願內容來自緩存，我並不關心被緩存響應,是不是新鮮的
緩存響應指令
public---- 可向任意方 提供響應的緩存
private---- 僅向特定的用戶返回響應
no-cache---- 能夠緩存，可是隻有在跟WEB服務器驗證了其有效後，才能返回給客戶端 可使用可是須要確認
no-store ---- 請求和響應都禁止被緩存
max-age:60 ----- 本響應包含的對象的過時時間 這個響應對象再有1分鐘就過時了
二、Connection
這個字段有兩個做用

[1]控制再也不轉發給代理的首部字段 connection:Upgrade

[2]管理持久鏈接 connection:close
在http1.1版本的鏈接默認都是持久鏈接。當服務器想要斷開鏈接的時候 指定connection:close
三、Date:日期
建立報文的日期
四、via
能夠追蹤客戶端與服務器之間的請求和響應報文的傳輸路徑，報文在通過代理和網關時，會先在首部字段上附加該信息，而後再進行轉發。

五、Trailer：Expires
表示的是在報文主體 以後還有的首部字段

實體首部

一、Allow:GET,HEAD
服務器通知客戶端 我（服務器）可以支持的HTTP方法
二、Content-Encoding：gzip
會告知服務器或者客戶端 實體主體的部分的編碼
三、Content-Language:zh-CN
會告知服務器或者客戶端 實體主體的使用的語言
三、Content-Length:1500
會告知服務器或者客戶端 實體的長度
四、Content-Type：text/html;charset=UTF-8
說明了實體主體內容的媒體類型
五、Expires：Date類型
資源失效的一個日期
六、Last-Modified:Date
指明資源最終修改的時間

http中爲cookie設置的首部

一、set-cookie：響應報文中 服務器向客戶端設置cookieset-cookie有如下的屬性值：[1]expires：date指定cookie的過時時間，若是沒有爲cookie的expire賦值的話 cookie的有效期僅限於會話期間[2]secure 沒有值限制web網頁僅在https安全鏈接時 才能夠發送cookie[3]httpOnly 沒有值這個屬性會使js沒法更改cookie