HTTP協議一覽

時間 2020-06-11

標籤 http 協議一覽欄目 HTTP/TCP 简体版

原文原文鏈接

HTTP協議並非對等的，須要客戶端和服務端，經過請求和響應模型實現。web

請求報文的結構

請求方法
請求的URI
協議版本
可選的請求首部字段
內容實體

響應報文的結構

協議版本
狀態碼
解釋狀態碼的緣由短語
可選的響應首部字段
主體

HTTP是無狀態協議

對HTTP來講，每一個請求響應都是獨立的，不關心請求之間的聯繫。
HTTP是經過Cookie技術來保存用戶狀態的。apache

Cookie

服務器經過Set-Cookie首部字段信息設置一個Cookie值，（服務器本身也會保存這個值）通知客戶端要保存這個Cookie值，客戶端在下次請求時自動在請求頭中加入Cookie值後發送。服務器對比這個Cookie就知道這個那個用戶發來的請求了。瀏覽器

方法種類

http 1.0 1.1 都支持的：緩存

GET
POST
PUT
DELETE
HEAD：獲取報文頭

http1.1新增的：安全

OPTIONS:查詢服務器支持的方法種類, OPTIONS * HTTP/1.1
TRACE:追蹤路徑，會引起跨站追蹤CST攻擊，通常不使用。
CONNECT：要求使用隧道協議鏈接代理

僅http1.0支持，也就是被http/1.1淘汰了：服務器

LINK
UNLINK

長鏈接 keep-alive

又叫持久鏈接，好處是減小了TCP鏈接和斷開的次數。
在http/1.1中默認是長鏈接了websocket

管線化 pipelining

管線化，就是同時發送多個請求。至關於一個鏈接中的串行請求響應，變成並行的。併發

HTTP報文結構

報文首部
空行
報文主體

其中請求報文首部又分爲app

請求行：方法、URI、HTTP版本
請求首部
通用首部
實體首部

響應報文首部又包含：webapp

狀態行：狀態碼、緣由短語、版本
響應首部
通用首部
實體手部

內容編碼

壓縮傳輸
gzip
compress
deflate
identity(不進行編碼)

分塊傳輸編碼

Chunked Transfer Coding

多部分對象集合

multipart/form-data
multipart/byterabge
boundary=xxx
能夠套嵌使用

範圍請求

斷點重連
Range: bytes=5001-10000

內容協商

Accept
Accept-Charset
Accept-Encoding
Accept-Language
Content-Language

服務器驅動協商
客戶端驅動協商
透明協商

狀態碼

RFC2616定義的狀態碼40種，WebDAV 擴展了一些狀態碼
WebDAV（Web-based Distributed Authoring and Versioning, 基於萬維網的分佈式創做和版本控制），至關於http/1.1的加強版，主要用於操做文件，好比網盤場景。

1xx 信息類，表示正在處理中

2xx 成功

200 成功
204 No content : 沒有內容。不會返回任何實體的主體，瀏覽器的頁面不會發生更新。
206 Partial Content : 部份內容。用於範圍請求

3xx 重定向

301 Moved Permanently : 永久重定向。若是此頁面收藏了標籤的話，瀏覽器可能會自動把標籤中的地址改成Location中的地址
302 Found：臨時重定向，可用於頁面地址修改後的發佈，若是地址寫錯了能夠改過來，能夠隨時修改。若是用301，用戶瀏覽器的標籤可能會保存錯誤的地址，這時就不太好處理。
303 See Other: 與302類似，可是明確要求客戶端用Get方法
304 Not Modified：與重定向無關。頁面不會更新，而是使用瀏覽器中的緩存。通常會在條件請求的返回中出現。條件請求：If-Modified-Since，If-Unmodified-since, If_Range, If-Match, If-None-Match。
307 Temperary Redirect：臨時重定向，不會將請求方法改成GET。

4xx 客服端異常

400 ：請求的報文的語法錯誤
401 Unauthorized：未受權，會同時返回 WWW-Authenticate，瀏覽器上會彈出認證框
403 Forbidden：拒絕訪問
404 Not Found ：資源沒找到

5xx 服務端異常

500 Internal Server Error : 服務器內部錯誤
501 Service Unavailable : 服務不可用，通常指服務器過載

Web服務器

一個服務器應用部署多個不一樣域名的應用

一個服務器應用（如一個Tomcat）如何部署多個不一樣域名的web站點嗎，而且端口都是默認端口？
首先DNS確定要爲主機IP綁定兩個域名，
當請求進入Tomcat中後如何區分這兩個域名呢？經過請求頭Host字段的域名來區分，Tomcat的server.xml的<Host>標籤須要配置

<Host name="www.111.com"  appBase="webapps" unpackWARs="true" autoDeploy="true">
    <Context path="" docBase="onefolder" debug="0" reloadable="true" />     
    <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log." suffix=".txt" pattern="%h %l %u %t "%r" %s %b" />
</Host>

<Host name="www.222.com"  appBase="webapps" unpackWARs="true" autoDeploy="true">
    <Context path="" docBase="twofolder" debug="0" reloadable="true" />
    <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log." suffix=".txt" pattern="%h %l %u %t "%r" %s %b" />
</Host>

通訊數據轉發程序

代理

代理：接收請求後轉發給其餘服務器（不改變請求的URI？）

緩存代理
透明代理、非透明代理

網關

網關：與代理的功能很類似，也是轉發請求。主要區別是網關能夠改變請求的URI，使用非http協議請求後續的服務器。

隧道

隧道：在請求端與遠距離的服務器創建安全的傳輸通道。

確認訪問用戶身份的認證

能夠經過哪些特徵證實本身呢？

我知道密碼
我有動態令牌
我有數字證書
個人生物特徵認證，人臉、指紋、虹膜
我提供個人身份證，或其餘證件

HTTP使用的認證方式

BASIC認證
DIGEST認證
SSL客戶端認證
FormBase認證

Windows的統一認證：Kerberos認證、NTLM認證

BASIC認證

原理：

客戶端發送請求
服務端返回 401 Unauthorized; 並附帶WWW-Authenticate: Basic realm="請輸入用戶名和密碼"
客戶端會彈出認證框讓用戶輸入用戶名和密碼，輸入把user:pass進行Base64編碼XXX，放到請求頭Authorization: Basric XXX，發送給服務端。
服務端進行反編碼後驗證用戶名密碼，若是驗證經過返回200，若是驗證失敗返回401。

缺點：
用戶密碼是明文傳輸，極不安全。

DIGEST認證

原理：不直接傳輸用戶名密碼，而是作散列以後進行傳輸。

客戶端發送請求
發出質詢：服務器返回401，響應頭WWW-Authenticate: Digest realm="DIGEST", nonce="XXXXX=xxxx",algorithm=MD5, qop="auth"
客戶端根據質詢計算出響應碼：Authorization: Digest realm="DIGEST" username="zhangsan", nonce="原nonce",uri="/digest", algorithm=MD5, response="xxxxx", nc=00000001, cnonce="xxxxx"
服務端進行驗證,返回200或401，成功時返回認證信息Authentication-Info響應頭。根據username來查到真實密碼，而後進行相同的MD5過程，而後對比是否與請求中的相同來進行判斷。

SSL客戶端認證

須要客戶端安裝證書
原理：

客戶端發請求
服務器除了會返回本身的證書外，還會發送Certificate Request報文，要求客戶端提供證書
客戶端發送Client Certificate報文
服務端驗證經過後，拿到客戶端的公鑰，用客戶端公鑰加密響應信息

SSL客戶端認證採用雙因素認證：加上了表單認證

基於表單的認證

自實現的表單認證方式

Session管理

經過Cookie保存Session_Id, 注意要將此Cookie加上httponly 屬性，防止跨站腳本攻擊XSS。
Session_Id是與用戶密碼關聯的。
用戶密碼的保存注意要salt+hash後保存，salt最好隨機生成，這樣能夠保證相同密碼的密文密碼也是不一樣的，更難以破解。

HTTP的擴展

1.Ajax: 局部刷新

2.Comet的解決方法

經過延遲應答來模擬服務器推送的功能。
缺點是顯而易見的，須要保持鏈接不斷，會消耗更多的資源。

3.SPDY

Google在2010年發佈了SPDY，旨在解決HTTP的性能瓶頸，縮短頁面加載時間。那麼，HTTP有哪些瓶頸呢?

一條鏈接上只能發送一個請求
請求只能從客戶端開始，無法從服務器進行推送
請求的首部太冗長，而且每次都發送相同的首部

SPDY的目標

修改HTTP協議自己！
SPDY沒有徹底改寫HTTP，而是在HTTP和SSL之間加入了一層SPDY層，能夠稱爲會話層。
主要的功能：

多路複用：用一條TCP鏈接併發處理多個HTTP請求。HTTP鏈接也是一個吧？
賦予請求優先級：在併發請求時，爲每一個請求分配優先級。
壓縮HTTP首部
推送功能
服務器提示功能：主動提示客戶端來請求所需的資源。

SPDY的問題

須要瀏覽器和Web服務器作出相應的調整。
SPDY只是將單個域名的通訊進行了多路複用，當一個網站上使用多個域名下的資源時，改善效果會打折扣。

4.瀏覽器的全雙工通訊的WebSocket

WebSocket 是Web瀏覽器與Web服務器之間全雙工通訊標準。
WebSocket也是創建在HTTP基礎上的協議，所以鏈接的發起方任然是客戶端，一旦創建鏈接，就能夠雙向發送數據了！

特色：

推送功能
減小了通訊量：首部信息很小

過程：
握手-請求：須要添加幾個請求頭。

Upgrade: websocket
Sec-WebSocket-Key: 健值
Sec-WebSocket-Protocol: 子協議

握手-響應：

返回101 Switching Protocols 狀態碼
Upgrade: websocket
Sec-WebSocket-Accept: 由請求中的健值來生成。

經過HTTP創建WebSocket鏈接以後，再也不使用HTTP的數據幀，而是使用WebSocket獨立的數據幀！！格式：ws://xxx.com/xxx

WebSocket API
js能夠調用此API。

var socket = new WebSocket('ws://example.com:8080/updates');
socket.onopen = function(){
    setInterval(function(){
        if(socket.bufferedAmount == 0){
            socket.send(getUpdateData());
        }
    });
}