010-HTTP協議 005-四種常見的 POST 提交數據方式 005-優化web請求一-gzip壓縮、http緩存控制和緩存校驗[Pragma、Expires、Cache-Control、max-

時間 2019-12-05

標籤 http 協議四種常見的 post 提交數據方式優化 web 請求 gzip 壓縮緩存控制校驗 pragma expires cache control max 欄目 HTTP/TCP 简体版

原文原文鏈接

1、概述

　　HTTP協議（HyperText Transfer Protocol，超文本傳輸協議）是用於從WWW服務器傳輸超文本到本地瀏覽器的傳輸協議。它可使瀏覽器更加高效，使網絡傳輸減小。它不只保證計算機正確快速地傳輸超文本文檔，還肯定傳輸文檔中的哪一部分，以及哪部份內容首先顯示(如文本先於圖形)等。html

　　HTTP是一個屬於應用層的面向對象的協議，因爲其簡捷、快速的方式，適用於分佈式超媒體信息系統。它於1990年提出，通過幾年的使用與發展，獲得不斷地完善和擴展。目前在WWW中使用的是HTTP/1.0的第六版，HTTP/1.1的規範化工做正在進行之中，並且HTTP-NG(Next Generation of HTTP)的建議已經提出。web

1.一、HTTP協議的主要特色可歸納

　　1.支持客戶/服務器模式。json

　　2.簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法經常使用的有GET、HEAD、POST。每種方法規定了客戶與服務器聯繫的類型不一樣。因爲HTTP協議簡單，使得HTTP服務器的程序規模小，於是通訊速度很快。瀏覽器

　　3.靈活：HTTP容許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。緩存

　　4.無鏈接：無鏈接的含義是限制每次鏈接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開鏈接。採用這種方式能夠節省傳輸時間。服務器

　　5.無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺乏狀態意味着若是後續處理須要前面的信息，則它必須重傳，這樣可能致使每次鏈接傳送的數據量增大。另外一方面，在服務器不須要先前信息時它的應答就較快。網絡

1.二、HTTP請求報文協議

　　HTTP請求是客戶端往服務端發送請求動做，告知服務器本身的要求。多線程

　　HTTP請求由狀態行、請求頭、請求正文三部分組成：併發

　　　　狀態行：包括請求方式Method、資源路徑URL、協議版本Version；app

　　　　請求頭：包括一些訪問的域名、用戶代理、Cookie等信息；

　　　　請求正文：就是HTTP請求的數據。

1.2.一、請求方法Method

　　HTTP/1.1協議中共定義了八種方法（有時也叫「動做」）來代表Request-URI指定的資源的不一樣操做方式：

　　　　OPTIONS - 返回服務器針對特定資源所支持的HTTP請求方法。也能夠利用向Web服務器發送'*'的請求來測試服務器的功能性。
　　　　HEAD- 向服務器索要與GET請求相一致的響應，只不過響應體將不會被返回。這一方法能夠在沒必要傳輸整個響應內容的狀況下，就能夠獲取包含在響應消息頭中的元信息。該方法經常使用於測試超連接的有效性，是否能夠訪問，以及最近是否更新。
　　　　GET - 向特定的資源發出請求。注意：GET方法不該當被用於產生「反作用」的操做中，例如在web app.中。其中一個緣由是GET可能會被網絡蜘蛛等隨意訪問。
　　　　POST - 向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。POST請求可能會致使新的資源的創建和/或已有資源的修改。
　　　　PUT - 向指定資源位置上傳其最新內容。
　　　　DELETE - 請求服務器刪除Request-URI所標識的資源。
　　　　TRACE- 回顯服務器收到的請求，主要用於測試或診斷。
　　　　CONNECT - HTTP/1.1協議中預留給可以將鏈接改成管道方式的代理服務器。
　　　　PATCH - 用來將局部修改應用於某一資源，添加於規範RFC5789。

1.2.二、post請求的請求內容類型Content-Type

　　application/x-www-form-urlencoded【默認】、application/json、multipart/form-data、text/xml

　　更多參看：005-四種常見的 POST 提交數據方式

1.2.三、客戶端接收類型

　　Accept: 接收類型；Accept-Encoding: gzip, deflate 接收編碼；Accept-Language: zh-CN,zh;q=0.9,en;q=0.8 接收語言

1.2.四、Cookie

1.2.五、Http緩存控制和緩存校驗

　　參看地址：005-優化web請求一-gzip壓縮、http緩存控制和緩存校驗[Pragma、Expires、Cache-Control、max-age、Last-Modified、用戶刷新訪問、避免過分304]

1.2.六、其餘

　　Connection：keep-alive：表示請求響應後，不會當即斷開，默認3000ms後斷開。

　　Status Code：狀態碼，200 304等

　　Remote Address：遠程地址

　　referer：指代當前請求的來源，或者上一個來源

1.三、Http響應

1.3.一、響應報文

　　服務器收到了客戶端發來的HTTP請求後，根據HTTP請求中的動做要求，服務端作出具體的動做，將結果迴應給客戶端，稱爲HTTP響應。

　　HTTP響應由三部分組成：狀態行、響應頭、響應正文；

　　　　狀態行：包括協議版本Version、狀態碼Status Code、迴應短語；

　　　　響應頭：包括搭建服務器的軟件，發送響應的時間，迴應數據的格式等信息；

　　　　響應正文：就是響應的具體數據。

　　備註：咱們主要關心而且可以在客戶端瀏覽器看獲得的是三位數的狀態碼，不一樣的狀態碼錶明不一樣的含義，其中

1xx	表示HTTP請求已經接受，繼續處理請求
2xx	表示HTTP請求已經處理完成
3xx	表示把請求訪問的URL重定向到其餘目錄
4xx	表示客戶端出現錯誤
5xx	表示服務端出現錯誤

1.3.二、常見狀態碼

200---OK/請求已經正常處理完畢

301---/請求永久重定向

302---/請求臨時重定向

304---/請求被重定向到客戶端本地緩存

400---/客戶端請求存在語法錯誤

401---/客戶端請求沒有通過受權

403---/客戶端的請求被服務器拒絕，通常爲客戶端沒有訪問權限

404---/客戶端請求的URL在服務端不存在

500---/服務端永久錯誤

503---/服務端發生臨時錯誤

1.3.三、HTTP響應模型

　　服務器收到HTTP請求以後，會有多種方法響應這個請求，下面是HTTP響應的四種模型：

單進程I/O模型：服務端開啓一個進程，一個進程僅能處理一個請求，而且對請求順序處理；

多進程I/O模型：服務端並行開啓多個進程，一樣的一個進程只能處理一個請求，這樣服務端就能夠同時處理多個請求；

複用I/O模型：服務端開啓一個進程，可是呢，同時開啓多個線程，一個線程響應一個請求，一樣能夠達到同時處理多個請求，線程間併發執行；

複用多線程I/O模型：服務端並行開啓多個進程，同時每一個進程開啓多個線程，這樣服務端能夠同時處理進程數M*每一個進程的線程數N個請求。

2、版本

HTTP/0.9

HTTP協議的最第一版本，功能簡陋，僅支持請求方式GET，而且僅能請求訪問HTML格式的資源。

HTTP/1.0

在0.9版本上作了進步，增長了請求方式POST和HEAD；再也不侷限於0.9版本的HTML格式，根據Content-Type能夠支持多種數據格式，即MIME多用途互聯網郵件擴展，例如text/html、image/jpeg等；同時也開始支持cache，就是當客戶端在規定時間內訪問統一網站，直接訪問cache便可。

可是1.0版本的工做方式是每次TCP鏈接只能發送一個請求，當服務器響應後就會關閉此次鏈接，下一個請求須要再次創建TCP鏈接，就是不支持keepalive。

HTTP/1.1

解決了1.0版本的keepalive問題，1.1版本加入了持久鏈接，一個TCP鏈接能夠容許多個HTTP請求；加入了管道機制，一個TCP鏈接同時容許多個請求同時發送，增長了併發性；新增了請求方式PUT、PATCH、DELETE等。

可是還存在一些問題，服務端是按隊列順序處理請求的，假如一個請求處理時間很長，則會致使後邊的請求沒法處理，這樣就形成了隊頭阻塞的問題；同時HTTP是無狀態的鏈接，所以每次請求都須要添加劇復的字段，下降了帶寬的利用率。

HTTP/2.0

爲了解決1.1版本利用率不高的問題，提出了HTTP/2.0版本。增長雙工模式，即不只客戶端可以同時發送多個請求，服務端也能同時處理多個請求，解決了隊頭堵塞的問題；HTTP請求和響應中，狀態行和請求/響應頭都是些信息字段，並無真正的數據，所以在2.0版本中將全部的信息字段創建一張表，爲表中的每一個字段創建索引，客戶端和服務端共同使用這個表，他們之間就以索引號來表示信息字段，這樣就避免了1.0舊版本的重複繁瑣的字段，並以壓縮的方式傳輸，提升利用率。

另外也增長服務器推送的功能，即不經請求服務端主動向客戶端發送數據。

當前主流的協議版本仍是HTTP/1.1版本。