HTTP協議詳解

時間 2020-07-02

標籤 http 協議詳解欄目 HTTP/TCP 简体版

原文原文鏈接

HTTP--Hyper Text Transfer Protocol，超文本傳輸協議，是一種創建在TCP上的無狀態鏈接，整個基本的工做流程是客戶端發送一個HTTP請求，說明客戶端想要訪問的資源和請求的動做，服務端收到請求以後，服務端開始處理請求，並根據請求作出相應的動做訪問服務器資源，最後經過發送HTTP響應把結果返回給客戶端。其中一個請求的開始到一個響應的結束稱爲事務，當一個事物結束後還會在服務端添加一條日誌條目。html

目錄瀏覽器

HTTP請求緩存
HTTP響應服務器
HTTP報文格式多線程
HTTP協議版本更替併發
網站訪問量ide

1、HTTP請求網站

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

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

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

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

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

備註：請求方式Method通常有GET、POST、PUT、DELETE，含義分別是獲取、修改、上傳、刪除，其中GET方式僅僅爲獲取服務器資源，方式較爲簡單，所以在請求方式爲GET的HTTP請求數據中，請求正文部分能夠省略，直接將想要獲取的資源添加到URL中。下圖所示就是GET的請求，沒有請求正文。詳細的說明在下邊。

如今大多數協議版本爲http/1.1

下圖所示爲POST請求的格式，有狀態行、請求頭、請求正文三部分。

2、HTTP響應

2.1 響應數據格式

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

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

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

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

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

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

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

具體HTTP響應實例以下圖：

2.2 常見狀態碼的含義

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

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

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

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

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

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

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

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

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

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

2.3 HTTP響應模型

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

單進程I/O模型

服務端開啓一個進程，一個進程僅能處理一個請求，而且對請求順序處理；

多進程I/O模型

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

複用I/O模型

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

複用多線程I/O模型

服務端並行開啓多個進程，同時每一個進程開啓多個線程，這樣服務端能夠同時處理進程數M*每一個進程的線程數N個請求。

3、HTTP報文格式

HTTP報文是HTTP應用程序之間傳輸的數據塊，HTTP報文分爲HTTP請求報文和HTTP響應報文，可是不管哪一種報文，他的總體格式是相似的，大體都是由起始、首部、主體三部分組成，起始說明報文的動做，首部說明報文的屬性，主體則是報文的數據。接下來具體說明。

3.1 HTTP請求報文

請求報文的起始由請求行構成（有些資料稱爲狀態行，名字不同而已，都是指的一個東西），用來講明該請求想要作什麼，由<Method>、<URL>、<Version> 三個字段組成，注意每一個字段之間都有一個空格。

其中<Method>字段有不一樣的值：

GET --- 訪問服務器的資源

POST --- 向服務器發送要修改的數據

HEAD --- 獲取服務器文檔的首部

PUT --- 向服務器上傳資源

DELETE--- 刪除服務器的資源

<URL>字段表示服務器的資源目錄定位

<Version>字段表示使用的http協議版本

首部部分由多個請求頭（也叫首部行）構成，那些首部字段名有以下，不全：

Accept 指定客戶端可以接收的內容格式類型

Accept-Language 指定客戶端可以接受的語言類型

Accept-Ecoding 指定客戶端可以接受的編碼類型

User-Agent 用戶代理，向服務器說明本身的操做系統、瀏覽器等信息

Connection 是否開啓持久鏈接（keepalive）

Host 服務器域名

...

主體部分就是報文的具體數據。

3.2 HTTP響應報文

響應報文的起始由狀態行構成，用來講明服務器作了什麼，由<Version>、<Status-Code>、<Phrase>三個字段組成，一樣的每一個字段之間留有空格；

<Status-Code> 上邊已經說明；

首部由多個響應頭(也叫首部行)組成，首部字段名以下，不全：

Server 服務器軟件名，Apache/Nginx

Date 服務器發出響應報文的時間

Last-Modified 請求資源的最後的修改時間

...

主體部分是響應報文的具體數據。

小tips：關於更多請求頭和響應頭（即首部字段名）的說明請參考http://tools.jb51.net/table/http_header

4、HTTP協議版本更替

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版本。

5、網站訪問量

IP IP訪問量

相同的公網IP計算一次，就是同一個局域網內的全部用戶訪問一個網站，可是他們都是藉助一個公網IP去訪問那個網站的（NAT），所以這也只能算做一個IP訪問量。換一次公網IP則會加1。

PV 網頁訪問量

用戶訪問的頁面數就是PV訪問量，同一個局域網的不一樣用戶，並且就算是同一個用戶，只要刷新一次網站頁面，PV訪問量就加1，三個訪問量的值每每數PV的值最大。

UV 訪客訪問量

這裏的訪客不是用戶，而是電腦，一臺電腦算一個訪客，即便是同一臺電腦的不一樣用戶，訪問同一個網站UV也只能加1，只有更換電腦纔會使UV加1，由於服務端會記錄客戶端電腦的信息。