你要的HTTP協議（上）

協議是指規則（如：如何探測到通訊目標，由哪一邊發起通訊，使用哪一種語言通訊，怎樣結束通訊等規則）的約定。web創建在HTTP協議（超文本傳輸協議）之上通訊的。

1.最初的設計理念：藉助多文檔之間相互關聯造成的超文本，連成可相互參閱的WWW(World wide web)。可以讓遠隔兩地的研究者們共享知識。因而提出三項構建技術：HTML(頁面的文本語言)、HTTP(做爲文檔傳遞的協議)、URL(統一資源定位符，制定文檔所在的地址)。

2.發送端：應用層(HTTP報文) --> 傳輸層(將HTTP報文分割並給每部分加上傳輸層首部變爲TCP報文) --> 網絡層(給TCP報文加上網絡層首部變成IP報文) --> 數據鏈路層(給IP報文加以太網首部成爲最終報文)
接收端：數據鏈路層(去掉以太網首部) --> 網絡層(去掉網絡層首部) --> 傳輸層(去掉傳輸層首部) --> 應用層(接收到最終的HTTP請求)

3.可靠的字節流服務：
字節流服務：將大塊數據分割爲以報文段爲單位的數據包進行管理。
可靠：可以把數據準備無誤的傳輸給對方（採用三次握手策略來保證）
TCP協議的三次握手：發送端發送帶有SYN(synchronize)標誌的數據包給接收端。接收端收到後回傳一個帶有SYN/ACK標誌的數據包以示傳達確認信息。最後發送端再發送一個帶有ACK標誌的數據包表明握手結束。

4.DNS：位於應用層的協議，提供經過域名查找IP地址，也能夠經過IP地址逆向反查域名的服務。

5.客戶端發送請求報文，請求報文由請求行（包括請求方法、請求URI和HTTP協議版本）、請求首部字段（包含通用首部、請求首部、實體首部）和內容實體構成。
服務器端接收到請求後以響應的形式返回，響應報文由狀態行（包含響應狀態的狀態碼、緣由短語和HTTP版本）、響應首部字段（包含通用首部、響應首部、實體首部）以及響應實體構成。
這兩種報文的前兩部分都屬於報文頭部信息，實體內容屬於報文實體，報文頭部和報文實體之間以空行隔開（CR+LF）。一些說明以下：
1)通用首部：請求和響應雙方都會用到的首部
2)實體首部：針對請求和響應報文的實體部分使用的首部，補充了資源內容更新時間等與實體有關的信息。

6.HTTP是一種不保存狀態（無狀態）的協議，其並不對請求和響應之間的通訊狀態進行保存，也不對發送過的請求和響應作持久化處理。這是爲了快速的處理大量的事務，確保協議的可伸縮性。

7.持久鏈接：
在http協議的初始版本中，每進行一次HTTP請求就要鏈接並斷開一次TCP，到下次請求的時候再次進行一次TCP鏈接與斷開。現現在傳輸的內容愈來愈多，爲了減小服務器的負荷，http便提出了持久鏈接的想法。其指在任意一端沒有明確斷開鏈接，則保持TCP鏈接狀態。（請求頭的connection:keep-alive字段）減小了TCP鏈接的重複創建和斷開所形成的額外開銷，減輕了服務器的負荷。

8.管線化：同時併發的發送多個請求，而不須要一個接一個地等待響應了。

9.報文主體和實體主體：
報文這是通訊中的基本單位，由8位組字節流組成
實體是有效的載荷數據，其內容由首部和主體組成，這是二者之間的概念的區別，可是實際上兩者指的是同一個東西，只有在對其進行編碼時主體的內容發生了變化後二者會產生差別

10.HTTP狀態碼描述返回的請求結果。狀態碼以三位數字和緣由短語組成，數字中的第一位指定了響應類別，後兩位無分類。響應類型有5種

1XX（信息性狀態碼）：接收的請求正在處理
2XX（成功狀態碼）：請求正常處理完畢
3XX（重定向狀態碼）：須要進行附加操做以完成請求
4XX（客戶端錯誤狀態碼）：服務器沒法處理請求
5XX（服務器錯誤狀態碼）：服務器處理請求出錯

如下說明經常使用得分幾種狀態碼：
204：請求已被成功處理，但沒有資源可返回（通常用於只須要從客戶端發送請求至服務器端，而不須要對客戶端發送新信息內容的狀況下使用）
206：表示客戶端進行了範圍請求，且服務器端成功處理了這部分請求。響應報文中包含Content-Range指定範圍的實體內容

301：永久性重定向。表示請求的資源已經被從新分配了URI。如：請求http://test.com/user的URI時忘記給最後加'/'就會產生301的狀態碼
302：臨時性重定向。但願本次請求可以使用新的URI請求。
303：請求對應着一個新的URI，應該使用GET請求從新請求。與302有着相同的功能，但明確表示應該使用GET請求
301/302/303狀態碼不少瀏覽器都會將請求方法改成GET並刪除報文內的主體，雖然標準規定301和302禁止改變請求方法，但實際使用時大多瀏覽器都這麼作
304：客戶端發送附帶條件的請求，服務器端容許請求訪問資源，且服務器端的資源並未改變，可使用客戶端緩存。此狀態碼返回時不包含任何響應主體
附帶條件的請求表示請求頭中包含：if-Match、if-None-Match、if-Modified-Since、if-Range。if-Unmodified-Since中任一個字段的請求
307：臨時重定向。與302有着相同的含義，但遵照瀏覽器標準，不會改成GET請求

400：表示請求報文中存在語法錯誤，予以有誤或者請求參數不正確
401：表示請求須要有經過HTTP認證呢過的認證信息，若以前請求過一次則表示用戶認證失敗，瀏覽器初次接收到401會彈出認證用的對話窗口
403：表示請求資源的訪問被服務器拒絕了，服務器若是想給出拒絕的理由能夠在主體內容中對緣由進行描述。
404：表示服務器上沒法找到請求的資源，能夠用在服務器拒絕請求又不想說明理由的場合
405：表示服務器不支持使用該請求方法請求指定資源
412：表示客戶端附帶條件的請求與資源的實體標記不匹配，服務器將不會執行請求
415：表示請求傳給服務器端的實體內容並非服務器端所支持的媒體類型
417：通常發生在客戶端帶有Expect請求頭的時候指望服務器出現特定的行爲而服務器沒法理解時將返回417

500：表示服務器在執行請求時發生了錯誤
503：表示服務器暫時處於超負載或正在進行停機維護，如今沒法處理請求

對於302/303/307的理解:
首先303和307是http1.1規範的產物,在http1.0的時候只有302的狀態碼,規範規定:客戶端發出的請求服務器返回302的狀態碼,若是請求是post,禁止在用戶未容許的狀況下再次發送請求,由於post請求是非冪等的,下次請求的環境可能已經發生了變化。而廣大瀏覽器均沒有遵照此規範,都是收到302的狀態碼後將請求改成get再次請求響應的Location裏的URI。
因爲規範中的302瀏覽器均爲遵照,因而在http1.1的規範中新提出303和307的狀態碼。瀏覽器目前行爲就實現了303的規範,若是收到303的狀態碼就將請求改成get再次請求Location裏的URI
307則指出須要在響應實體中包含信息，以便不能處理307狀態碼的用戶有能力在新URI中發起重複請求，也就是說，把重定向的頁面展現給用戶，讓用戶去點重定向URI連接

我的認爲在http1.1中,理論上來講302應該是被廢棄的,由於307和302的說法並沒有二意,多是爲了兼容302還在業界的大量使用吧

11.HTTP1.1規範容許利用虛擬主機（virtual host）的功能在同一臺HTTP服務器上搭建多個Web站點。若相同的域名部署在同一臺服務器上，使用DNS服務解析域名後會獲得相同的IP地址，因此在
發送HTTP請求時必須在Host首部內完整指定主機名和域名URI。

12.用於通訊數據轉發的應用程序，如代理、網關、隧道
1)代理：一種具備轉發功能的應用程序，扮演位於服務器和客戶端之間的「中間人」的角色，能夠將客戶端的請求轉發給服務器，也能夠將服務器的響應轉發給客戶端。使用代理的場景：減小網絡帶寬、針對特定網站的訪問控制。
a.緩存代理（利用緩存技術減小網絡帶寬流量），預先將資源的副本緩存在代理服務器上
b.透明代理（不對請求報文或響應報文作任何處理）
c.非透明代理
2)網關：轉發其餘服務器通訊數據的服務器（工做機制與代理十分類似），它就像本身擁有資源的服務器（源服務器：擁有實體資源的的服務器），能夠對客戶端發送來的請求進行處理。
a.經過網關將HTTP協議的請求轉化爲非HTTP協議的通訊
b.提升通訊的安全性
3)隧道：一種在相距甚遠的客戶端和服務器端之間進行中轉（透明傳輸，並不會解析HTTP請求），並保持雙方通訊鏈接的應用程序。經過時會使用SSL加密手段進行通訊

13.HTTP報文首部：報文首部字段有字段名和字段值的結構組成中間用":"分隔，字段值對應於單個首部能夠有多個值，如2：
1)Content-Type: text/html 表示報文主體的對象類型，
2)Keep-Alive: timeoue=15, max=100

14.HTTP報文通用首部相關字段說明

1)Cache-Control
    a.做爲請求時的字段
    no-cache: 強制向服務器再次驗證，爲了防止緩存中返回過時的資源，其實此字段表示不緩存過時的資源，緩存會向源服務器進行有效期確認後處理資源，使用緩存則須要通過協商緩存來驗證決定
    no-store: 暗示請求和響應中包含機密信息，規定不能在本地緩存請求或響應中的任一部分
    max-age: 值的單位爲秒，資源的緩存時間比指定時間小的時候，客戶端將接收緩存的資源，若是其值爲0時表示緩存服務器須要將請求轉發給源服務器
    min-fresh: 值的單位爲秒，要求緩存服務器返回至少還未過指定改時間的緩存資源，如其指定爲60s，過了60s的緩存資源將不會做爲響應返回了
    max-stale: 單位爲秒，只可接收緩存資源，即便是過時但未超過其指定的時間值的資源也接收
    only-if-cached: 表示客戶端僅在緩存服務器在本地緩存了目標資源的狀況下才會要求其返回，也就是說緩存服務器不從新加載響應，也再也不次確認資源的有效性
    must-revalidate: 緩存服務器會再次向源服務器請求即將返回的緩存資源是否有效，若緩存服務器沒法連通源服務器獲取資源則將返回給客戶端504的狀態碼，會忽略max-stale字段
    proxy-revalidate: 表示緩存服務器在向客戶端返回響應前必須再次驗證資源緩存的有效性
    no-transfrom: 規定不管在請求仍是響應中，緩存都不能改變主題的媒體類型，可防止緩存或代理壓縮圖片等類的操做
    #cache-extension: 用來擴展Cache-Control首部字段內的字段名，若是緩存服務器不能理解擴展的字段則會忽略，如擴展一個community字段：Cache-Control: community="UCT"

    b.做爲響應時的字段
    no-cache: 表示緩存服務器不能對資源進行緩存
    no-store: 暗示請求和響應中包含機密信息，規定不能在本地緩存請求或響應中的任一部分
    max-age: 響應首部中包含max-age字段時緩存服務器將再也不對資源的有效性進行確認，其值表示資緩存的最長時間

2)Connection有兩個做用：控制再也不轉發給代理的首部字段、管理持久鏈接
    客戶端請求時或服務端返回響應時，使用Connection首部字段可控制再也不轉發給代理的首部字段，如Connection: Upgrade表示刪掉Upgrade這個字段
    HTTP/1.1版本的默認鏈接都是持久鏈接，當某一段明確想要斷開鏈接時，則指定Connection的值爲close

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

4)Pragma：做爲HTTP/1.0向後兼容的字段，也屬於通用首部字段，只用在客戶端發送的請求中，表示客戶端要求中間服務器不返回緩存的資源

5)Warning：告知用戶一些與緩存相關的問題的警告，其格式爲：
    Warning: [警告碼][警告的主機:端口][警告內容]([日期時間])

15.請求首部相關字段：用於補充請求的附加信息、客戶端信息、對響應內容相關的優先級

1)Accept: 通知服務器用戶代理可處理的媒體類型及媒體類型的優先級。能夠用type/subtype這種格式的的形式，如文本類型 Accept: text/html, text/plain; q = 0.8 ...
2)Accept-Charset: 通知服務器用戶代理可處理的字符集及字符集的優先級。
3)Accept-Encoding: 通知服務器用戶代理可處理的內容集及內容編碼的優先級。如：Accept-Encoding: gzip, deflate  另外，也能夠指定「*」表示通配符，指定任意的編碼格式
4)Accept-Language: 通知服務器用戶代理可處理的天然語言集及天然語言集的優先級。如：Accept-Language: zh-cn, zh;q=0.8, en-us, en;q=0.6
5)Authorization: 告知服務器用戶代理的認證信息
6)Expect: 使用此字段告訴服務器指望出現某種特定的行爲，若是服務器不能理解客戶端指望則迴應發生錯誤時返回417的狀態碼
7)From: 使用此頭部告訴服務器正在使用用戶代理的這位用戶的電子郵箱地址，有時候由於用戶代理的不一樣，會將此字段放在User-Agent中
8)Host: 此字段告知服務器請求資源所在的互聯網的主機名和端口號，這是HTTP/1.1規範中惟一一個必須包含在請求內的首部字段。這是由於有可能不少域名部署在同一臺服務器上的不一樣
虛擬機中，在請求發至服務器中，請求中的主機名會用IP代替，若是這時此IP下部署着多個域名，那麼服務器就沒法理解到底是哪一個域名對應的請求，這時Host就顯得頗有用了，若是服務器的未設定主機名，則傳一個空值便可。
9)If-Match: 形如If-XXX這種的請求均可稱爲條件請求，服務器接收到這種請求後，只有判斷條件爲真，纔會執行請求。若附帶條件與資源的實體標記不匹配時 會返回412 precondition failed的狀態碼。若此字段的值爲"*"，服務器將會忽略ETag的值，只要資源存在就執行請求
10)If-Modified-Since: 若服務器的資源在此字段指定的時間以後更新了，服務器會執行請求，不然會返回304 Not Modified的狀態碼。若是要獲取資源的更新時間則確認響應頭中的Last Modified字段可獲取。
瀏覽器在第一次訪問資源時，服務器返回資源的同時，在response header中添加 Last-Modified的header，值是這個資源在服務器上的最後修改時間，瀏覽器接收後緩存文件和header。
瀏覽器下一次請求這個資源，瀏覽器檢測到有 Last-Modified這個header，因而在請求時添加If-Modified-Since這個header，值就是Last-Modified中的值；服務器再次收到這個資源請求，會根據 If-Modified-Since 中的值與服務器中這個資源的最後修改時間對比，若是沒有變化，返回304和空的響應體，直接從緩存讀取，若是If-Modified-Since的時間小於服務器中這個資源的最後修改時間，說明文件有更新，因而返回新的資源文件和200
11)If-None-Match: 表示此字段與請求資源的實體標記（ETag）不一致時但願處理請求，這與If-Match相反。在GET與HEAD請求中，使用此字段可獲取最新的資源。
使用此字段可獲取最新資源的原理以下：在第一次請求時服務器響應中添加ETag信息，客戶端將ETag值存儲，再次發送請求時將ETag值發送給服務器，服務器驗證ETag是否改變，若改變則說明資源已經更新，則會處理請求，不然就返回304狀態碼
12)If-Range: 告知服務器若是此字段的值和請求資源的ETag值一致時就返回範圍請求，不一致就返回全體資源。若不使用If-Range，若是服務器端資源更新字ETag值也將發生變化，則客戶端
已持有的一部分資源將無效，此時服務器將返回412的狀態碼，而致使客戶端再次請求，這樣便花費了兩倍的時間。
13)If-Unmodified-Since: 與If-Modified-Since字段相反，告知服務器若是資源在此時間點以後未發生更新才處理請求，不然返回412狀態碼
14)Max-Forwards: 表示可經過的代理服務器個數，請求每通過一個代理服務器此值就減1，直到代理服務器收到後此值爲0時就再也不作轉發處理而是直接返回響應。利用此字段能夠調試某臺代理服務器是否出現了故障
15)Proxy-Authorization: 客戶端接收到代理服務器發來的認證質詢時，將會發送包含此字段的請求，以告知服務器認證的信息。這與帶Authorization字段的認證很相似，只不過此認證行爲
發生這是發生在客戶端和代理之間
16)Range: 對於獲取資源的部分請求每每會附帶這樣的請求頭，如：Range: bytes=5001-10000表示獲取資源第5001字節至10000字節之間的範圍，若處理請求返回後將返回206的狀態碼，若
沒法處理請求將返回200的狀態碼及所有資源
17)Referer: 告知服務器是從哪一個頁面連接過來的
18)Te: 告知服務器客戶端可以處理的傳輸編碼方式以及相對優先性，此字段與Accept-Encoding很像，但此字段是用於傳輸編碼的
19)User-Agent: 將用戶代理的字符串等信息傳達給服務器

16.響應首部相關字段：補充響應的附加信息、服務器信息等，以及對客戶端的附加要求等

1)Accepts-Range: 告知客戶端服務器可否處理範圍請求，值爲bytes和none之間可選
2)Age: 告知客戶端源服務器在多久前建立了響應，字段值的單位秒。若該字段由緩存服務器建立，則Age值表示緩存後的響應再次發起認證到認證完成的時間值
3)ETag: 告知客戶端請求的資源的實體標識，服務器會爲每份資源分配對應的ETag值，另外，當資源更新時，對應的ETag值也將隨之更新
強ETag：不管實體發生多麼細微的變化，ETag值都將發生變化
弱ETag：只用於提示資源是否相同，有資源發生了根本變化，產生了差別時ETag纔會隨之變化，這是會在字段最開始附加W/
4)Location: 使用此字段可將響應接收方引導至某個與請求URI位置不一樣的資源，可配合3XX的狀態碼提供重定向的URI，幾乎全部瀏覽器在接收到包含Location字段的響應後都將強制性第嘗試對以提示的重定向資源進行訪問
5)Proxy-Authenticate: 此字段把代理服務器所要求的認證信息發送給客戶端，此認證發生在客戶端與代理服務器之間。
6)Retry-After: 告知客戶端應在多久後再次發送請求，通常可配合狀態碼503一塊兒使用。可指定肯定的時間或者在此時間（單位爲秒）以後再發送請求。
7)Server: 當前服務器上安裝的HTTP服務器應用程序的信息，這不僅僅會標出應用軟件的名稱，還可能包含版本號和安裝時啓用的可選項
8)Vary: 用在客戶端或者緩存服務器上緩存機制作緩存的時候，此字段的內容來自於請求頭中的相關信息，如：Vary: Accept-Encoding, User-Agent。在緩存服務器中，對首次請求到的響應作了緩存，當下次有請求過來時，緩存瀏覽器將會Accept-Encoding、User-Agent兩個請求頭的的內容個做爲判斷是否應該返回緩存數據，當同一請求的緩存數據中的Accept-Encoding和
User-Agent與請求頭中的Accept-Encoding和User-Agent內容相匹配時就返回緩存
9)WWW-Authenticate:

17.實體首部報文：包含在請求報文和響應報文中的實體部分所使用的首部，用於補充實體內容的更新等於實體相關的信息

1)Allow: 通知客戶端指定資源支持的HTTP請求的全部方法，若是客戶端使用了不容許的請求方法會返回405 Method Not Allowed的狀態碼
2)Content-Encoding: 告知客戶端服務器對實體的主體內容選用的內容編碼方式。此內容編碼是指在不丟失實體信息的前提下所進行的壓縮
3)Content-Language: 實體主體內容使用的天然語言
4)Content-Length: 表示實體主體部分的大小，單位爲字節。若是對實體進行了編碼，則不會使用Content-Length字段
5)Content-Location: 表示報文主體相對應的URI，此字段以Location不一樣，Location表示重定向請求的目的地址（或者新建立的文件的URL），其對應的是響應，而Content-Location對應的是要返回的實體內容部分
6)Content-MD5: 服務器端將報文主體通過MD5算法再使用base64編碼後傳輸給客戶端，客戶端經過一樣的方法處理後與此字段的值進行對比來判斷報文是否準確。此方法不能判斷報文主體是否被惡意篡改，由於報文主體被篡改的話，Content-MD5的值也將會被改變
7)Content-Range: 針對範圍請求返回的響應，值表示當前發送的部分其整個實體的大小，單位爲字節
8)Content-Type: 和首部字段Accept同樣，說明主體內容的媒體類型
9)Expires: 告知客戶端資源失效的日期和時間。當首部字段含有Cache-Control指定的max-age時會優先處理max-age指令
10)Last-Modified: 資源上一次的修改時間

18.Cookie：

1)Set-Cookie: 響應首部字段，當服務器準備開始管理客戶端的狀態時，會實現告訴各類信息，一下說明此首部各字段的含義
    NAME=VALUE: 賦予Cookie的名稱和值
    expires=DATE: Cookie的有效期（若不明確指定則默認爲瀏覽器關閉前爲止）
    path=PATH: 指定ceCookie在那些路徑下可使用，僅在子路徑可以使用（不指定則默認指定爲文檔所在的文件目錄）
    domain=domain: 指定Cookie在哪一個域名下可使用（若不指定則默認爲服務器所在的域名）
    Secure: 僅在HTTPS協議下才會回收Cookie
    HttpOnly: 加以限制，使Cookie不能被客戶端JavaScript腳本訪問
2)Cookie: 將接收到的Cookie返回給服務器端

19.其餘首部字段：HTTP首部字段時能夠擴展的。

1)X-Frame-Options: 屬於響應首部，控制此網站的其餘Web站點的frame標籤內的顯示問題，防止點擊劫持攻擊。
    DENY: 拒絕
    SAMEORIGIN: 僅在同源域名下的頁面匹配是容許加載
2)X-XSS-Protection: 屬於響應首部，針對跨站腳本的攻擊對策，用於控制瀏覽器XSS防禦機制的開關
    0: 將XSS過濾設置爲無效狀態
    1: 將XSS過濾設置爲有效狀態
3)DNT: 屬於請求首部，（Do Not Track），拒絕我的信息被收集，這是拒絕被精準廣告追蹤的一種方法。須要Web服務器對DNT作支持
    0: 贊成被追蹤
    1: 拒絕被追蹤
4)P3P: 屬於響應首部，將Web程序上的我的信息變成一種僅供程序可理解的形式

文中如有表述不妥或是知識點有誤之處，歡迎留言指正批評！