HTTP協議(總結)
HTTP協議
HTTP（超文字傳輸協議，HyperText Transfer Protocol)是網際網路上應用最為廣泛的一種網路協議.
這個協議最初設計是為了提供一種釋出和接受HTML頁面的方法.是用於WWW伺服器傳輸超文字到本地瀏覽器的傳輸協議.
HTTP協議定義在網路七層中的應用層,通過傳輸層的TCP協議進行傳輸,因為HTTP協議需要建立連線,所以使用TCP協議不使用UDP協議.
為了避免每次請求的都經歷握手帶來的延遲，應用層會選擇不同策略的http長連結方案
HTTP1.0
HTTP 協議老的標準是HTTP/1.0，為了提高系統的效率，HTTP 1.0規定瀏覽器與伺服器只保持短暫的連線，瀏覽器的每次請求都需要與伺服器建立一個TCP連線，伺服器完成請求處理後立即斷開TCP連線，伺服器不跟蹤每個客戶也不記錄過去的請求。
但是這樣就帶來了兩個問題連線無法複用和排頭阻塞
連線無法複用
因為每次連線都需要通過TCP的三次握手和慢啟動,三次握手在高延遲的情況下影響嚴重,慢啟動在傳輸大檔案類請求影響較大
排頭阻塞
在快取式通訊網路交換中FIFO(先進先出)佇列,所以可能出現垃圾請求影響健康請求.
HTTP1.1
為了解決HTTP1.0的設計缺陷,HTTP1.1預設使用帶流水線的持久連線,在一個TCP連線下,可以傳送多個HTTP請求和響應,減少了建立和關閉連線的消耗和延遲.
HTTP1.1還允許客戶端不用等待上一次請求返回就可以發出下一回請求,但是服務端必須按照請求的順序依次返回響應結果,以保證客戶端可以區分出請求相應的內容.
HTTP1.1與1.0的區別
**長連線
HTTP 1.1支援長連線（PersistentConnection）和請求的流水線（Pipelining）處理，在一個TCP連線上可以傳送多個HTTP請求和響應，減少了建立和關閉連線的消耗和延遲，在HTTP1.1中預設開啟Connection： keep-alive，一定程度上彌補了HTTP1.0每次請求都要建立連線的缺點。
快取處理
在HTTP1.0中主要使用header裡的If-Modified-Since,Expires來做為快取判斷的標準，HTTP1.1則引入了更多的快取控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的快取頭來控制快取策略。
頻寬優化及網路連線的使用
HTTP1.0中，存在一些浪費頻寬的現象，例如客戶端只是需要某個物件的一部分，而伺服器卻將整個物件送過來了，並且不支援斷點續傳功能，HTTP1.1則在請求頭引入了range頭域，它允許只請求資源的某個部分，即返回碼是206（Partial Content），這樣就方便了開發者自由的選擇以便於充分利用頻寬和連線。
錯誤通知的管理
在HTTP1.1中新增了24個錯誤狀態響應碼，如409（Conflict）表示請求的資源與資源的當前狀態發生衝突；410（Gone）表示伺服器上的某個資源被永久性的刪除。
Host頭處理
在HTTP1.0中認為每臺伺服器都繫結一個唯一的IP地址，因此，請求訊息中的URL並沒有傳遞主機名（hostname）。但隨著虛擬主機技術的發展，在一臺物理伺服器上可以存在多個虛擬主機（Multi-homed Web Servers），並且它們共享一個IP地址。HTTP1.1的請求訊息和響應訊息都應支援Host頭域，且請求訊息中如果沒有Host頭域會報告一個錯誤（400 Bad Request）。
SPDY:HTTP1.x的優化
SPDY的出現不是用來替代HTTP的新協議,而是用來優化了HTTP1.X.
SPDY主要的優化方面如下:
降低延遲
SPDY使用了多路複用.多路複用通過多個請求共享一個TCP連線方式,解決HOL(排頭阻塞)的問題,降低延遲的同時提高頻寬的使用效率.
請求優先順序
多路複用帶來一個新問題,在共享一個連線的情況下,一個請求阻塞可能會導致關鍵請求被阻塞,所以SPDY給每個請求設定了優先順序,這樣請求就會按照優先順序來進行響應.
Header壓縮
SDPY中壓縮請求和響應的HTTP報頭,從而減少傳輸的資料包和位元組數
伺服器啟動流
伺服器可以分發內容到客戶端,而不用客戶端再去請求伺服器資源.
HTTP2.0
HTTP2.0可以說是SDPY的升級版,但是跟SDPY有所不同,區別如下:
- HTTP2.0支援明文HTTP傳輸,但是SDPY強制使用HTTPS傳輸
- HTTP2.0報頭壓縮演算法採用HPACK 並非SDPY採用的DEFLATE
HTTP2.0與HTTP1.X的區別
**多路複用
多路複用允許同時通過單一的HTTP2連線發起多重的請求-響應訊息.
當HTTP1.X時針對於同一個域名下請求次數會有一定數量的限制.超過限制後請求會被阻塞,但是有了多路複用之後就可以實現多流並行
新的二進位制格式
HTTP2.0在應用層和傳輸層之間加了一個二進位制分幀層.通過將傳輸資訊分割為更小的訊息和幀,並對他們進行二進位制格式的編碼.
這種單連線多資源的方式,減少服務端的連線壓力,記憶體佔用更少,連線吞吐量更大.
首部壓縮
HTTP/1.1並不支援 HTTP 首部壓縮，為此 SPDY 和 HTTP/2 應運而生， SPDY 使用的是通用的DEFLATE 演算法，而 HTTP/2 則使用了專門為首部壓縮而設計的 HPACK 演算法
伺服器推送
伺服器推送是在客戶端請求之前傳送資料的機制.
當一個請求是由主頁發起的,那麼伺服器可能會響應主頁的內容、樣式表和圖片等,因為伺服器知道客戶端會用這些東西. 最大的好處可以快取,那麼就可以實現共享快取資源.
請求方法
根據HTTP標準,HTTP請求可以使用多種請求方法.
HTTP1.0定義了三種請求方法: GET, POST和HEAD 方法
HTTP1.1新增了五種請求方法:OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法
- GET 請求指定的頁面資訊,並返回實體主體
- HEAD 類似於get請求,只不過返回的響應中沒有具體的內容,用於獲取報頭
- POST 向指定資源提交資料進行處理請求(例如提交表單或者上傳檔案).資料被包含在請求體中.POST請求可能會導致新的資源的建立或已有資源的修改
- PUT 從客戶端向伺服器傳送的資料取代指定的文件內容**(與POST的區別在於等冪性,PUT是等冪的,而POST是非等冪的)**
- DELETE 請求伺服器刪除指定的頁面
- CONNECT HTTP/1.1協議中預留給能夠將連線改為管道方式的代理伺服器
- OPTIONS 允許客戶端檢視伺服器的效能
- TRACE 回顯伺服器收到的請求,主要用於測試或診斷
- PATCH 對資源應用部分修改
GET和POST的區別
- GET請求的資料會放在URL之後,以?分割URL和傳輸的資料,引數之間以&相連.POST則是把資料放在HTTP的Body中
- GET提交的資料大小有限制(因為URL的長度有限制),而POST方式提交的資料沒有限制
- GET方式需要使用Request.QueryString來獲取變數,而POST方式通過Request.Form來獲取(伺服器端獲取資料的方式)
- GET方式提交資料會帶來安全問題,比如隱私資料會直接顯示在URL中
狀態碼
狀態碼由三位數字組成,第一個數字定義了相應的類別,共分物種類別:
- 1xx : 提示資訊 – 表示請求已接收,繼續處理
- 2xx : 成功 – 表示請求已被成功接收,理解,接受
- 3xx : 重定向 – 要完成請求必須進行更進一步的操作
- 4xx : 客戶端錯誤 – 請求有語法錯誤或請求無法實現
- 5xx : 伺服器端錯誤 – 伺服器未能實現合法的請求
常見狀態碼:
- 200 OK 客戶端請求成功
- 302 Found 重定向,客戶端對新的URL發出新的Request
- 304 Not Modified 客戶端可直接使用快取檔案
- 400 Bad Request 客戶端請求有語法錯誤,不能被伺服器理解
- 403 Forbidden 伺服器收到請求,但是拒絕提供服務
- 404 Not Found 請求資源不存在
- 500 Internal Server Error 伺服器發生不可預期的錯誤
- 503 Server Unavailable 伺服器當前不能處理客戶端的請求,一段時間後可能恢復 正常
常用頭資訊
請求頭
Cache頭域
If-Modified-Since
作用: 把瀏覽器快取頁面的最後修改時間傳送到伺服器去,伺服器會把這個時間與伺服器上實際檔案的最後修改時間進行對比.如果時間一致,那麼返回304,客戶端就直接使用本地快取檔案.如果時間不一致,就會返回200和新的檔案內容.客戶端接收到之後,會把新檔案快取起來,並顯示在瀏覽器中.
If-None-Match
作用: If-None-Match和ETag一起工作,工作原理是在HTTP Response中新增ETage資訊.當用戶再次請求該資源時,將在請求頭中加入If-None-Match資訊.如果伺服器驗證資源的ETag沒有改變,將返回一個304狀態碼告訴客戶端使用本地快取檔案,否則將返回200和新的資源和Etag.
Pragma
作用: 防止頁面被快取 在HTTP/1.1中,它和Cache-Control:no-cache作用一模一樣
Cache-Control
作用: 用來指定Response-Request遵循的快取機制.如下:
- Cache-Control:Public 可以被任何快取所快取
- Cache-Control:Private 內容只快取到私有快取中
- Cache-Control:no-cache 所有內容都不會被快取
Client頭域
Accept
作用: 瀏覽器/客戶端告訴伺服器自己接受的介質型別(即Content-Type), **/*表示任何型別, type/ 表示該型別下的所有子型別
Accept-Encoding
作用: 瀏覽器申明自己接受的編碼方法,通常指定壓縮方法,是否支援壓縮,支援什麼壓縮方法(gzip,deflate) 注意這不是指字元編碼
Accept-Language
作用: 瀏覽器申明自己接收的語言 語言和字符集不同
Accept-Charset
作用: 瀏覽器宣告自己接受的字符集編碼
User-Agent
作用: 表示請求者的一些資訊,比如 瀏覽器型別和版本 作業系統 使用語言等
Cookie/Login頭域
Cookie
作用: HTTP請求傳送時,會把儲存在該請求域名下的所有cookie值傳送給Web伺服器
Entity頭域
Content-Type
作用: 表示後面的訊息體屬於什麼MIME型別.通常需要顯示地指定為text/html. 而對於基於json的REST互動,則需要配置為application/json.
Content-Length
作用: 表示訊息體的長度.可以用來判斷訊息體是否傳遞完整
Miscellaneous頭域
Referer
作用: 提供Request的上下文資訊的伺服器,告訴伺服器我是從哪個連結過來的.
Transport頭域
Connection
作用: 控制TCP連線是否斷開
例子:
- Connection: keep-alive 當一個HTTP請求結束後,TCP連線不會斷開,如果客戶端再次訪問伺服器上的網頁,會繼續使用這條TCP連線
- Connection: close 代表一個HTTP請求完成後,客戶端與伺服器之間的TCP連線會關閉,當客戶端再次傳送HTTP請求時,重新建立TCP連線
Host
作用: 請求報頭域主要用於指定被請求資源的Internet主機和埠
響應頭
Cache頭域
Date
作用: 生成訊息的具體時間和日期
Expires
作用: 瀏覽器會在指定過期時間內使用本地快取
Vary
作用: 對於未來的請求頭,應該用一個快取回覆還是向源伺服器請求一個新的回覆
Cookie/Login頭域
P3P
作用: 用於跨域設定Cookie, 這樣可以解決iframe跨域訪問cookie的問題
Set-Cookie
作用: 用於把cookie傳送到客戶端.
Entity頭域
ETag
作用: 和If-None-Match配合使用
Last-Modified
作用: 用於指示資源的最後修改日期和時間
Content-Type
作用: Web伺服器告訴客戶端自己的響應的內容的型別和字符集
Content-Length
作用: 指明實體正文的長度,以位元組方式儲存的十進位制數字來表示.
Content-Encoding
作用: Web伺服器表明自己使用什麼壓縮方法(gzip, deflate)
Content-Language
作用: Web伺服器告訴瀏覽器自己響應的物件的語言
Miscellaneous頭域
Server
作用: 指明HTTP伺服器的軟體資訊
Transport頭域
Connection
作用: 同上請求頭中Connection
Location頭域
Location
作用: 用於重定向一個新的位置,包含新的
URI和URL的區別
URI
URI 是uniform resource identifier, 統一資源識別符號,用來唯一的標識一個資源
Web上可用的每種資源如HTML文件,影象,視訊片段,程式等都是一個URI來定位
URI一般由三部分組成:
- 訪問資源的命名機制
- 存放資源的主機名
- 資源自身的名稱,由路徑標識,著重強調於資源.
URL
URL 是uniform resource locator, 統一資源定位器, 它是一種具體的URI, 即URL可以用來標識一個資源, 而且還可以指明瞭如果locate這個資源
採用URL可以用一種統一的格式來描述各種資訊資源,包括檔案,伺服器的地址和目錄等.URL一般由三部分組成:
- 協議(或稱為服務方式)
- 存在該資源的主機IP地址
- 主機資源的具體地址.如果目錄和檔名等.
URN
URN 是uniform resource name, 統一資源命名,是通過名字來標識資源
HTTP工作原理
HTTP協議定義Web客戶端如果從Web伺服器請求Web頁面,以及伺服器如何把Web頁面傳送給客戶端.HTTP協議採用了請求/響應模型.客戶端向伺服器傳送一個請求報文,請求報文包含請求的方法,URL,協議版本,請求頭部和請求資料.伺服器以一個狀態行作為響應,響應的內容包括協議的版本,成功或者錯誤程式碼,伺服器資訊,相應頭部和響應資料
以下是HTTP請求/響應的步驟:
- 客戶端連線到Web伺服器
一個HTTP客戶端,通常是瀏覽器,與Web伺服器的HTTP埠(預設為80)建立一個TCP套接字連線. - 傳送HTTP請求
通過TCP套接字,客戶端向Web伺服器傳送一個文字的請求報文,一個請求報文由請求行,請求頭部,空行和請求資料4部分組成 - 伺服器接收請求並返回HTTP響應
Web伺服器解析請求,定位請求資源.伺服器將資源複本寫到TCP套接字,由客戶端讀取.一個響應由狀態行,響應頭部,空行和響應資料4部分組成 - 釋放TCP連線
若connection模式為Close,則伺服器主動關閉TCP連線,客戶端被動關閉連線,釋放TCP連線;若connection模式為keeplive,則該連線保持一段時間,在該時間內可以繼續接受請求. - 客戶端瀏覽器解析HTML內容
客戶端瀏覽器首先解析狀態行,檢視是否請求成功,然後解析每一個響應頭,響應頭告知以下為若干位元組的HTML文件和文件的字符集.客戶端瀏覽器讀取響應資料HTML,根據HTML的語法對其進行格式化,並在瀏覽器視窗中進行顯示.
例如:在瀏覽器中輸入URL,按下回車後會經歷以下流程:
- 瀏覽器向DNS伺服器請求解析該URL中的域名所對應的IP地址
- 解析出IP地址後,根據該IP地址和預設埠80,和伺服器建立TCP連線
- 瀏覽器發出讀取檔案的HTTP請求,該請求報文作為TCP三次握手的第三個報文的資料傳送給伺服器
- 伺服器對瀏覽器請求做出響應,並把對應的HTML文字傳送給瀏覽器
- 釋放TCP連線
- 瀏覽器將該HTML文字顯示內容