HTTP協議簡介詳解 HTTP協議發展 原理 請求方法 響應狀態碼 請求頭 請求首部 java模擬瀏覽器客戶端服務端
協議簡介
協議,自然語言裡面就是契約,也是雙方或者多方經過協商達成的一致意見;
契約也即類似於合同,自然有甲方123...,乙方123...,哪些能做,哪些不能做;
通訊協議,也即是雙方通過網路通訊必須遵從的一組約定;
計算機網路的本質在於傳遞資料,協議自然是針對於資料的結構格式以及傳送規則的約定;
之前介紹過計算機網路的發展,其中TCP/IP協議棧共分為四層,兩個程式端點資料的傳輸是U字形的
應用層
傳輸層
網路層
網路介面層
HTTP是工作在應用層的協議,所謂的工作在哪層,只不過是對底層的封裝程度而已;
HTTP協議是什麼
HTTP協議是Tim(計算機發展系列提到過)發明的,也正是他完成了全球資訊網三大基礎技術的設計：命名方案（URI），通訊協議（HTTP）和用來表示資訊的標記語言（HTML）;
回過神來仔細想想web的發展過程,web是B/S結構的,瀏覽器(B)通過網路向伺服器(S)請求資料,
有了TCP/IP協議以及Socket程式設計,你可以很容易的完成伺服器與請求方的資料溝通;
但是資訊的傳遞的重點在於資訊本身,而不是這一次的資料交換,必須要能夠相互理解;
因為單純的資料交流並沒有任何意義,必須有對話的基礎,那就是"語言";
就好像你(請求方)在說普通話,水果店老闆(伺服器)在講英語,你們從早上交流到晚上可能並沒有有效的傳遞任何資訊;
所以HTTP協議就是這樣一種用於瀏覽器客戶端與伺服器交流的一種"語言";
他規定了對話的語法以及格式,有了HTTP協議,客戶端和伺服器端就可以相互理解對方,才能達到資訊交換的目的;
既然HTTP是為了WEB創造的,自然是請求獲取的一個過程,而且當時就是HTML
所以最初他就是這麼簡單,獲取一個名為XXX的HTML檔案
GET /index.html
1991年Tim寫了一篇關於HTTP的協議的文章,被看做是HTTP/0.9
HTTP-Hypertext Transfer protocol ,超文字傳輸協議,他的名字完整的對自己進行了釋義:傳輸超文字HTML檔案的協議;
HTTP協議的發展
最初的版本,看起來可能比較簡陋,他只能單獨的請求資料,連是不是請求出錯了都無法感知,顯然,這不可能持續滿足需求;
1996年 HTTP/1.0 版本釋出
不再限制內容的格式只能是HTML,任何格式都可以;
除了GET還引入了POST 和 HEAD 豐富了瀏覽器客戶端和伺服器的互動
HTTP請求和相應的格式資訊也更加豐富,還增加了狀態碼等等內容
1997年1月，HTTP/1.1 版本釋出，只比 1.0 版本晚了半年,1.1是1.0的升級優化版,重點在於完善優化
這也是目前一直在用的一個版本
HTTP協議的格式
HTTP預設的埠號為80，HTTPS的埠號為443,HTTP協議包括請求和響應
其中CRLF是回車換行
此圖片來自於<計算機網路> ,首部也就是前面圖中的頭部 一個意思
請求和響應都包括:行/頭部/主體
請求行包括:方法/URL/版本號
響應行包括:版本號/狀態碼/描述
請求頭和響應頭都是KEY:VALUE的鍵值對形式,個數為n
頭部可以分成三個部分:請求/響應頭欄位、通用頭欄位、實體頭欄位。
其中通用頭欄位和實體頭欄位部分內容也在響應部分有相同的定義。
請求體通常不用,響應體也不一定用;
HTTP請求方法
HTTP請求方法有下面幾種,常用的有GET、POST請求.
| GET | 請求指定的頁面資訊，並返回實體主體。 |
| POST | 向指定資源提交資料進行處理請求（例如提交表單或者上傳檔案）。資料被包含在請求體中。POST請求可能會導致新的資源的建立和/或已有資源的修改。 |
| HEAD | 類似於get請求，只不過返回的響應中沒有具體的內容，用於獲取報頭 |
| PUT | 從客戶端向伺服器傳送的資料取代指定的文件的內容。 |
| DELETE | 請求伺服器刪除指定的資源。 |
| CONNECT | HTTP/1.1協議中預留給能夠將連線改為管道方式的代理伺服器。 |
| OPTIONS | 允許客戶端檢視伺服器的效能。 |
| TRACE | 回顯伺服器收到的請求，主要用於測試或診斷,還回測試的請求報文 |
HTTP狀態碼
三位數字表示,第一位表示型別
1XX 訊息，伺服器收到請求，需要請求者繼續執行操作
2XX 成功，操作被成功接收並處理
3XX 重定向，需要進一步的操作以完成請求
4XX 客戶端錯誤，請求包含語法錯誤或無法完成請求
5XX 伺服器錯誤，伺服器在處理請求的過程中發生了錯誤
| 100 | Continue | 繼續。客戶端應繼續其請求 |
| 101 | Switching Protocols | 切換協議。伺服器根據客戶端的請求切換協議。只能切換到更高階的協議，例如，切換到HTTP的新版本協議 |
| 200 | OK | 請求成功。一般用於GET與POST請求 |
| 201 | Created | 已建立。成功請求並建立了新的資源 |
| 202 | Accepted | 已接受。已經接受請求，但未處理完成 |
| 203 | Non-Authoritative Information | 非授權資訊。請求成功。但返回的meta資訊不在原始的伺服器，而是一個副本 |
| 204 | No Content | 無內容。伺服器成功處理，但未返回內容。在未更新網頁的情況下，可確保瀏覽器繼續顯示當前文件 |
| 205 | Reset Content | 重置內容。伺服器處理成功，使用者終端（例如：瀏覽器）應重置文件檢視。可通過此返回碼清除瀏覽器的表單域 |
| 206 | Partial Content | 部分內容。伺服器成功處理了部分GET請求 |
| 300 | Multiple Choices | 多種選擇。請求的資源可包括多個位置，相應可返回一個資源特徵與地址的列表用於使用者終端（例如：瀏覽器）選擇 |
| 301 | Moved Permanently | 永久移動。請求的資源已被永久的移動到新URI，返回資訊會包括新的URI，瀏覽器會自動定向到新URI。今後任何新的請求都應使用新的URI代替 |
| 302 | Found | 臨時移動。與301類似。但資源只是臨時被移動。客戶端應繼續使用原有URI |
| 303 | See Other | 檢視其它地址。與301類似。使用GET和POST請求檢視 |
| 304 | Not Modified | 未修改。所請求的資源未修改，伺服器返回此狀態碼時，不會返回任何資源。客戶端通常會快取訪問過的資源，通過提供一個頭資訊指出客戶端希望只返回在指定日期之後修改的資源 |
| 305 | Use Proxy | 使用代理。所請求的資源必須通過代理訪問 |
| 306 | Unused | 已經被廢棄的HTTP狀態碼 |
| 307 | Temporary Redirect | 臨時重定向。與302類似。使用GET請求重定向 |
| 400 | Bad Request | 客戶端請求的語法錯誤，伺服器無法理解 |
| 401 | Unauthorized | 請求要求使用者的身份認證 |
| 402 | Payment Required | 保留，將來使用 |
| 403 | Forbidden | 伺服器理解請求客戶端的請求，但是拒絕執行此請求 |
| 404 | Not Found | 伺服器無法根據客戶端的請求找到資源（網頁）。通過此程式碼，網站設計人員可設定"您所請求的資源無法找到"的個性頁面 |
| 405 | Method Not Allowed | 客戶端請求中的方法被禁止 |
| 406 | Not Acceptable | 伺服器無法根據客戶端請求的內容特性完成請求 |
| 407 | Proxy Authentication Required | 請求要求代理的身份認證，與401類似，但請求者應當使用代理進行授權 |
| 408 | Request Time-out | 伺服器等待客戶端傳送的請求時間過長，超時 |
| 409 | Conflict | 伺服器完成客戶端的PUT請求是可能返回此程式碼，伺服器處理請求時發生了衝突 |
| 410 | Gone | 客戶端請求的資源已經不存在。410不同於404，如果資源以前有現在被永久刪除了可使用410程式碼，網站設計人員可通過301程式碼指定資源的新位置 |
| 411 | Length Required | 伺服器無法處理客戶端傳送的不帶Content-Length的請求資訊 |
| 412 | Precondition Failed | 客戶端請求資訊的先決條件錯誤 |
| 413 | Request Entity Too Large | 由於請求的實體過大，伺服器無法處理，因此拒絕請求。為防止客戶端的連續請求，伺服器可能會關閉連線。如果只是伺服器暫時無法處理，則會包含一個Retry-After的響應資訊 |
| 414 | Request-URI Too Large | 請求的URI過長（URI通常為網址），伺服器無法處理 |
| 415 | Unsupported Media Type | 伺服器無法處理請求附帶的媒體格式 |
| 416 | Requested range not satisfiable | 客戶端請求的範圍無效 |
| 417 | Expectation Failed | 伺服器無法滿足Expect的請求頭資訊 |
| 500 | Internal Server Error | 伺服器內部錯誤，無法完成請求 |
| 501 | Not Implemented | 伺服器不支援請求的功能，無法完成請求 |
| 502 | Bad Gateway | 充當閘道器或代理的伺服器，從遠端伺服器接收到了一個無效的請求 |
| 503 | Service Unavailable | 由於超載或系統維護，伺服器暫時的無法處理客戶端的請求。延時的長度可包含在伺服器的Retry-After頭資訊中 |
| 504 | Gateway Time-out | 充當閘道器或代理的伺服器，未及時從遠端伺服器獲取請求 |
| 505 | HTTP Version not supported | 伺服器不支援請求的HTTP協議的版本，無法完成處理 |
HTTP頭部-通用頭欄位
請求和響應都會用到的頭部欄位
- Cache-Control 指定請求和響應遵循的快取機制
- Connection 控制不在轉發給代理的首部也就是有些首部資訊通過他控制刪除後轉發,另外就是是否持久連線1.1預設持久
- Date 報文建立的日期和時間 http1.1使用RFC1123中規定的格式
- Pragma 遺留欄位 形式唯一 Pragma:no-cache,雖是通用,但僅用於請求,要求所有中間伺服器不返回快取的資源
- Trailer 事先說明報文主體之後記錄了哪些頭欄位
- Transfer-Encoding 傳輸報文主體時採用的編碼方式
- Upgrade 檢測HTTP協議以及其他協議是否可以使用更高版本通訊,引數還可以指定一個完全不同的通訊協議
- Via 追蹤客戶端和伺服器之間的請求和響應報文的傳輸路徑
- Warning 告知使用者一些與快取相關的問題的警告
HTTP頭部-請求頭欄位
從客戶端向伺服器端傳送請求時使用到的頭欄位,補充了請求的附加內容,客戶端資訊,響應內容優先順序等資訊
1.Accept
告知伺服器,能夠處理的媒體型別以及媒體型別的相對優先順序 可使用type/subtype的形式,一次指定多種型別
比如 text/html,text/plain,text/css………
2.Accept-Charset
告知伺服器,能夠處理的字符集以及字符集的相對優先順序
也可以一次指定多個
3.Accept-Encoding
告知伺服器,支援的內容編碼以及內容編碼的相對優先順序,可以一次性指定多種內容編碼 gzip,compress,deflate,identity
4.Accept-Language
告知伺服器,能夠處理的自然語言集,比如中文 英文 ,以及自然語言的相對優先順序,可以一次性指定多種自然語言集
5.Authorization
告知伺服器,認證資訊
6.Expect
告知伺服器,期望出現的某種特定行為
7.From
告知伺服器,電子郵件地址
8.Host
告知伺服器,請求資源的主機名以及埠號,Host是請求頭欄位裡面,HTTP1.1唯一一個要求必須有的欄位
形如If-Xxx的請求頭欄位,都是條件欄位,伺服器會判斷這個條件,只有條件為真的時候才會執行請求
9.If-Match
告知伺服器,匹配資源所用的實體標記ETag的值 如果使用*號,伺服器將忽略不在比較
10.If-Modified-Since
告知伺服器,指定的日期後資源發生了更新,伺服器會接受響應 ,引數為日期時間
11.If-None-Match
與If-Match原理一樣,取值相反
12.If-Range
屬於附帶條件之一 欄位值若是跟ETag或者更新日期時間匹配一致,那麼作為範圍請求處理,否則返回全部資源
13.If-Unmodified-Since
原理同If-Modified 取值相反
14.Max-Forwards
通過TRACE或者OPTIONS,傳送包含此欄位的請求,以十進位制形式指定可經過的伺服器最大數目
15.Proxy-Authorization
認證相關
16.Range
對於只獲取部分資源的範圍請求,告知伺服器資源的指定範圍,伺服器接收Range處理後還會返回206 無法處理則會忽視,返回200以及全部資源
17.Referer
告知伺服器請求的原始資源的URI
18.TE
告知伺服器,客戶端能夠處理的響應的傳輸編碼方式以及相對優先順序,注意是傳輸,傳輸中編碼
19.User-Agent
建立請求的瀏覽器和使用者代理名稱等資訊傳達給伺服器
HTTP頭部-響應頭欄位
從伺服器端返回響應時用到的頭部欄位,補充了響應的附加內容
1.Accept-Ranges
告知客戶端,伺服器是否能夠處理範圍請求,如果不能值為none,Accept-Ranges:none;否則是bytes
2.Age
告知客戶端,源伺服器在多久前建立了響應,欄位值單位為s,如果是快取伺服器值為快取後的響應再次發起認證到認證完成的時間值,代理建立響應必須加上Age
3.Etag
告知客戶端實體標識,可以將資源以字串形式唯一標識的方式,伺服器會給每個資源建立ETag值,資源更新,Etag也需要更新
4.Location
將響應接收方引導至某個請求URI位置不同的資源,基本上欄位會配合3XX,幾乎所有的瀏覽器接收到Location響應都會強制嘗試對已經提示的資訊進行重定向
5.Proxy-authenticate
代理伺服器需要的認證資訊傳送給客戶端
6.Retry-After
告知客戶端,多久後重新請求,主要配合503或者3xx Redirect響應一起使用
7.Server
告知客戶端,伺服器上安裝的HTTP伺服