整合營(yíng)銷服務(wù)商
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
ttp協(xié)議 HyperText Transfer Protocol
超文本傳送協(xié)議(HTTP)是一種通信協(xié)議, 它允許將超文本標(biāo)記語言(HTML)文檔從Web服務(wù)器傳送到Web瀏覽器。
1.http協(xié)議是建立在tcp/ip協(xié)議基礎(chǔ)上;
2.我們的web開發(fā)數(shù)據(jù)的傳輸都是依賴于http協(xié)議;
3.http協(xié)議全稱是 超文本傳輸協(xié)議;
URL(統(tǒng)一資源定位符)
Uniform Resource Locator
統(tǒng)一資源定位符
http://www.xxxxxx.com:80/index.php
協(xié)議：http(信鴿)
主機(jī)：www.xxxxxx.com
端口號(hào)：80 所有瀏覽器默認(rèn)請(qǐng)求都是80端口
資源：/index.php
HttpWatch軟件(強(qiáng)大的網(wǎng)頁數(shù)據(jù)分析工具)
Stream(流)
左邊：客戶端向服務(wù)器端發(fā)送數(shù)據(jù)流
右邊：服務(wù)器端向客戶端返回?cái)?shù)據(jù)流
http協(xié)議的-http請(qǐng)求(request)細(xì)節(jié)(客戶端向服務(wù)器端發(fā)送數(shù)據(jù)流)
客戶端連上服務(wù)器后，向服務(wù)器請(qǐng)求某個(gè)web資源，稱之為客戶端向服務(wù)器發(fā)送了一個(gè)HTTP請(qǐng)求。
一個(gè)完整的HTTP請(qǐng)求包括如下內(nèi)容：一個(gè)請(qǐng)求行、若干消息頭、以及實(shí)體內(nèi)容，其中的一些消息頭和實(shí)體內(nèi)容都是可選的，
消息頭和實(shí)體內(nèi)容之間要用空行隔開。如下所示:
基本結(jié)構(gòu)
請(qǐng)求行
消息頭
<----空行
消息體(實(shí)體內(nèi)容)
舉例:
GET /test/hello.html HTTP/1.1
【表示發(fā)送的get請(qǐng)求, 請(qǐng)求資源是/test/hello.html 】
Accept: */* 【表示客戶端可以接受任何數(shù)據(jù)】
Referer: http://localhost:80/test/abc.html 【1.表示我是從哪里來】
Accept-Language: zh-cn 【頁面語言】
User-Agent: Mozilla/4.0 【告訴服務(wù)我的瀏覽器的內(nèi)核，操作系統(tǒng)】
Accept-Encoding: gzip, deflate 【表示接受什么樣的數(shù)據(jù)壓縮格式.】
Host: localhost:80 【主機(jī):80】
Connection: Keep-Alive 【表示不要立即斷掉我們的請(qǐng)求.】
現(xiàn)在我們想知道，客戶端究竟給服務(wù)器發(fā)送的內(nèi)容
如果我這個(gè)http1.php. 不希望 192.168.1.33 這個(gè)用戶訪問.
在服務(wù)器端，我們可以通過$_SERVER來獲取我們需要的信息
重要的有:
HTTP_HOST 當(dāng)前請(qǐng)求頭中Host
REMOTE_ADDR 訪問該頁面的ip
DOCUMENT_ROOT 可以獲取 apche的主目錄
REQUEST_URI 可以獲取 請(qǐng)求的資源名
http請(qǐng)求有兩種主要的方式
get / post
GET提交，請(qǐng)求的數(shù)據(jù)會(huì)跟在URL之后例如：login.php?name=abc&password=kkk
POST提交：把提交的數(shù)據(jù)放置在是HTTP包的包體中。比如:
POST /test/reg.php HTTP/1.1
Host:
Content-Type:
Content-Length:
<--空行
name=abc&password=xyz
get和post的區(qū)別有哪些
1. GET提交的數(shù)據(jù)會(huì)在地址欄中顯示出來，而POST提交，地址欄不會(huì)改變
2. 安全性：get請(qǐng)求的數(shù)據(jù)會(huì)顯示在地址欄上, post請(qǐng)求的數(shù)據(jù)，放在http協(xié)議的消息體，post安全性高
3. 從可以提交數(shù)據(jù)的大小看:http協(xié)議本身并沒有限制數(shù)據(jù)大小。GET:特定瀏覽器和服務(wù)器對(duì)URL長(zhǎng)度有限制，
例如IE對(duì)URL長(zhǎng)度的限制是2083字節(jié)(2K+35)。對(duì)于其他瀏覽器，如Netscape、FireFox等，理論上沒有長(zhǎng)度限制，其限制取決于操作系統(tǒng)的支持。
因此對(duì)于get提交時(shí)，傳輸數(shù)據(jù)就會(huì)受到URL長(zhǎng)度的限制。post:由于不是通過URL傳值，理論上數(shù)據(jù)不受限。
4. get請(qǐng)求可以更好的添加到收藏夾;
用于HTTP請(qǐng)求中的常用頭
Accept: text/html,image/*
Accept-Charset: ISO-8859-1
Accept-Encoding: gzip,compress
Accept-Language: en-us,zh-cn
Host: www.sohu.com:80
If-Modified-Since: Tue, 11 Jul 2000 18:23:51 GMT
Referer: http://www.sohu.com/index.php
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
Cookie
Connection: close/Keep-Alive
Date: Tue, 11 Jul 2003 18:23:51 GMT
當(dāng)服務(wù)器需要知道請(qǐng)求是來自哪個(gè)ip等信息，就可通過程序獲得相應(yīng)的信息。
防止盜鏈的關(guān)鍵程序:
'HTTP_REFERER' 引導(dǎo)用戶代理到當(dāng)前頁的前一頁的地址（如果存在）。
由 user agent 設(shè)置決定。并不是所有的用戶代理都會(huì)設(shè)置該項(xiàng)，有的還提供了修改 HTTP_REFERER 的功能。簡(jiǎn)言之，該值并不可信。
<?php
if(isset($_SERVER['HTTP_REFERER'])){ //判斷是否是空值
//取出來
//判斷$_SERVER['HTTP_REFERER']是不是以本網(wǎng)站網(wǎng)址開頭的
if(strpos($_SERVER['HTTP_REFERER'],"網(wǎng)站域名")==0){
echo "你沒有盜鏈";
//語句....
}else
//跳轉(zhuǎn)到警告頁面
header("Location:warning.php");
}else{
header("Location:warning.php");
}
?>http響應(yīng)（response）服務(wù)器端向客戶端返回?cái)?shù)據(jù)流(以下的內(nèi)容都是基于服務(wù)器端向客戶端發(fā)送的信息)
簡(jiǎn)單定義: 一個(gè)Http響應(yīng)代表服務(wù)器給瀏覽器回送的數(shù)據(jù)，同時(shí)告訴瀏覽器應(yīng)當(dāng)怎樣處理數(shù)據(jù);(表示服務(wù)器響應(yīng)客戶端瀏覽器的信息)
1. 基本結(jié)構(gòu)
狀態(tài)行
消息頭信息
<--空行
實(shí)體信息
快速入門
HTTP/1.1 200 OK 【200 ok 表示客戶端請(qǐng)求成功】
Server: Microsoft-IIS/5.0 【表示告訴瀏覽器 服務(wù)器的情況 】
Date: Thu, 13 Jul 2000 05:46:53 GMT 【告訴瀏覽器請(qǐng)求的頁面的時(shí)間 】
Content-Length: 2291 【表示回送的數(shù)據(jù)有2291個(gè)字節(jié)】
Content-Type: text/html 【文檔類型】
Cache-control: private 【緩存】
<--空行
hello 實(shí)體細(xì)節(jié)
HTTP響應(yīng)的細(xì)節(jié)--狀態(tài)行
格式:HTTP版本號(hào) 狀態(tài)碼 原因敘述<CRLF>
單例:HTTP/1.1 200 OK
狀態(tài)碼用于表示服務(wù)器對(duì)請(qǐng)求的處理結(jié)果,它是一個(gè)三位的十進(jìn)制數(shù),響應(yīng)狀態(tài)碼分為5類
狀態(tài)碼 含義
100～199 表示成功接收請(qǐng)求，要求客戶端繼續(xù)提交下一次請(qǐng)求才能完成整個(gè)處理過程
200～299 表示成功接收請(qǐng)求并已完成整個(gè)處理過程，常用200
300～399 為完成請(qǐng)求，客戶需進(jìn)一步細(xì)化請(qǐng)求。例如，請(qǐng)求的資源已經(jīng)移動(dòng)一個(gè)新地址，常用302、304
400～499 客戶端的請(qǐng)求有錯(cuò)誤，常用404
500～599 服務(wù)器端出現(xiàn)錯(cuò)誤，常用 500
舉例說明Http響應(yīng)的實(shí)際應(yīng)用:
302狀態(tài)碼使用:
比如我們現(xiàn)在希望訪問a.php 頁面，讓其自動(dòng)重定向到b.php
基本用法使用
<?php
/*header("Location: 新的頁面");這句話會(huì)向客戶端發(fā)送一個(gè)302狀態(tài)碼;(發(fā)送的是兩個(gè)請(qǐng)求狀態(tài)碼,首先發(fā)送302狀態(tài)碼,告訴瀏覽器重新訪問新的頁面,
然后服務(wù)器再發(fā)送200狀態(tài)碼)/*
header("Location: http://www.sohu.com");
exit();
?>細(xì)節(jié): 302 狀態(tài)碼也可以讓其跳轉(zhuǎn)到外網(wǎng)去
404狀態(tài)碼使用:
404 最常見的狀態(tài)碼 404一般說就是該頁面不存在
304狀態(tài)碼使用:
304 碼主要是告訴瀏覽器，請(qǐng)求的資源不需要更新(理解:因?yàn)槲募呀?jīng)緩存了,就不需要更新)
<?php
echo "hello";
echo "<img src="Sunset.jpg" width="100px">"
?>以上代碼訪問了一次,再重新打開時(shí),則服務(wù)器向客戶端瀏覽器發(fā)送304狀態(tài)碼,告訴瀏覽器，請(qǐng)求的圖片不需要更新
上面說明了304的具體用法
HTTP/1.1 304 Not Modified
Date: Tue, 13 Sep 2011 02:10:38 GMT
Server: Apache/2.2.17 (Win32) PHP/5.3.5
Connection: Keep-Alive
Keep-Alive: timeout=5, max=99
ETag: "12d00000000572c-6f69-3e1d849f35000"
下面是比較詳細(xì)的一個(gè)Http響應(yīng)
Location: http://www.baidu.org/index.php
Server:apache
Content-Encoding: gzip 【內(nèi)容編碼支持gzip壓縮算法】
Content-Length: 80 【返回?cái)?shù)據(jù)大小】
Content-Language: zh-cn
Content-Type: text/html; charset=GB2312
Last-Modified: Tue, 11 Jul 2000 18:23:51 GMT 【表示瀏覽器請(qǐng)求資源，最新時(shí)間】
Refresh: 1;url=http://www.baidu.com 【告訴瀏覽器，間隔1秒，重定向到 baidu】
Content-Disposition: attachment; filename=aaa.zip
Transfer-Encoding: chunked
Set-Cookie:SS=Q0=5Lb_nQ; path=/search 【講Cookie】
Expires: -1
Cache-Control: no-cache
Pragma: no-cache
Connection: close/Keep-Alive
Date: Tue, 11 Jul 2000 18:23:51 GMT
演示如何通過Http響應(yīng)，控制瀏覽器間隔一定時(shí)間去跳轉(zhuǎn).
<?php
//header("Refresh: 3 ; url=http://www.sohu.com");
header("Refresh: 3 ; url=http://localhost/http/d.php");
?>演示如何通過Http響應(yīng)控制頁面緩存,在默認(rèn)情況下，瀏覽器會(huì)緩存頁面.
<?php
//通過header來禁用緩存(ajax )
header("Expires: -1");
header("Cache-Control: no_cache");
header("Pragma: no-cache");
echo "hello!cache";
?>//下載文件需要的頭
header("Content-type: application/octet-stream"); //告訴瀏覽器返回的是文件(即輸出MIME類型)
header("Accept-Ranges: bytes"); //告訴瀏覽器按照字節(jié)大小返回,可以不要此行語句,最好保留
header("Accept-Length: $file_size"); //文件大小
header("Content-Disposition: attachment; filename=".$file_name); //這里是客戶端彈出的對(duì)話框,對(duì)應(yīng)的文件名
演示Http實(shí)際應(yīng)用的 文件下載
代碼如下:
注于Java領(lǐng)域優(yōu)質(zhì)技術(shù)，歡迎關(guān)注
作者：滌生_Woo
本篇文章篇幅比較長(zhǎng)，先來個(gè)思維導(dǎo)圖預(yù)覽一下。
一張圖帶你看完本篇文章
1.計(jì)算機(jī)網(wǎng)絡(luò)體系結(jié)構(gòu)分層
計(jì)算機(jī)網(wǎng)絡(luò)體系結(jié)構(gòu)分層
2.TCP/IP 通信傳輸流
利用 TCP/IP 協(xié)議族進(jìn)行網(wǎng)絡(luò)通信時(shí)，會(huì)通過分層順序與對(duì)方進(jìn)行通信。發(fā)送端從應(yīng)用層往下走，接收端則從鏈路層往上走。如下：
TCP/IP 通信傳輸流
如下圖所示：
HTTP 請(qǐng)求
在網(wǎng)絡(luò)體系結(jié)構(gòu)中，包含了眾多的網(wǎng)絡(luò)協(xié)議，這篇文章主要圍繞 HTTP 協(xié)議（HTTP/1.1版本）展開。
HTTP協(xié)議（HyperText Transfer Protocol，超文本傳輸協(xié)議）是用于從WWW服務(wù)器傳輸超文本到本地瀏覽器的傳輸協(xié)議。它可以使瀏覽器更加高效，使網(wǎng)絡(luò)傳輸減少。它不僅保證計(jì)算機(jī)正確快速地傳輸超文本文檔，還確定傳輸文檔中的哪一部分，以及哪部分內(nèi)容首先顯示(如文本先于圖形)等。 HTTP是客戶端瀏覽器或其他程序與Web服務(wù)器之間的應(yīng)用層通信協(xié)議。在Internet上的Web服務(wù)器上存放的都是超文本信息，客戶機(jī)需要通過HTTP協(xié)議傳輸所要訪問的超文本信息。HTTP包含命令和傳輸信息，不僅可用于Web訪問，也可以用于其他因特網(wǎng)/內(nèi)聯(lián)網(wǎng)應(yīng)用系統(tǒng)之間的通信，從而實(shí)現(xiàn)各類應(yīng)用資源超媒體訪問的集成。 我們?cè)跒g覽器的地址欄里輸入的網(wǎng)站地址叫做URL (Uniform Resource Locator，統(tǒng)一資源定位符)。就像每家每戶都有一個(gè)門牌地址一樣，每個(gè)網(wǎng)頁也都有一個(gè)Internet地址。當(dāng)你在瀏覽器的地址框中輸入一個(gè)URL或是單擊一個(gè)超級(jí)鏈接時(shí)，URL就確定了要瀏覽的地址。瀏覽器通過超文本傳輸協(xié)議(HTTP)，將Web服務(wù)器上站點(diǎn)的網(wǎng)頁代碼提取出來，并翻譯成漂亮的網(wǎng)頁。
HTTP請(qǐng)求響應(yīng)模型
HTTP通信機(jī)制是在一次完整的 HTTP 通信過程中，客戶端與服務(wù)器之間將完成下列7個(gè)步驟：
1 建立 TCP 連接
在HTTP工作開始之前，客戶端首先要通過網(wǎng)絡(luò)與服務(wù)器建立連接，該連接是通過 TCP 來完成的，該協(xié)議與 IP 協(xié)議共同構(gòu)建 Internet，即著名的 TCP/IP 協(xié)議族，因此 Internet 又被稱作是 TCP/IP 網(wǎng)絡(luò)。HTTP 是比 TCP 更高層次的應(yīng)用層協(xié)議，根據(jù)規(guī)則，只有低層協(xié)議建立之后，才能進(jìn)行高層協(xié)議的連接，因此，首先要建立 TCP 連接，一般 TCP 連接的端口號(hào)是80；
2 客戶端向服務(wù)器發(fā)送請(qǐng)求命令
一旦建立了TCP連接，客戶端就會(huì)向服務(wù)器發(fā)送請(qǐng)求命令；
例如：GET/sample/hello.jsp HTTP/1.1
3 客戶端發(fā)送請(qǐng)求頭信息
客戶端發(fā)送其請(qǐng)求命令之后，還要以頭信息的形式向服務(wù)器發(fā)送一些別的信息，之后客戶端發(fā)送了一空白行來通知服務(wù)器，它已經(jīng)結(jié)束了該頭信息的發(fā)送；
4 服務(wù)器應(yīng)答
客戶端向服務(wù)器發(fā)出請(qǐng)求后，服務(wù)器會(huì)客戶端返回響應(yīng)；
例如： HTTP/1.1 200 OK
響應(yīng)的第一部分是協(xié)議的版本號(hào)和響應(yīng)狀態(tài)碼
5 服務(wù)器返回響應(yīng)頭信息
正如客戶端會(huì)隨同請(qǐng)求發(fā)送關(guān)于自身的信息一樣，服務(wù)器也會(huì)隨同響應(yīng)向用戶發(fā)送關(guān)于它自己的數(shù)據(jù)及被請(qǐng)求的文檔；
6 服務(wù)器向客戶端發(fā)送數(shù)據(jù)
服務(wù)器向客戶端發(fā)送頭信息后，它會(huì)發(fā)送一個(gè)空白行來表示頭信息的發(fā)送到此為結(jié)束，接著，它就以 Content-Type 響應(yīng)頭信息所描述的格式發(fā)送用戶所請(qǐng)求的實(shí)際數(shù)據(jù)；
7 服務(wù)器關(guān)閉 TCP 連接
一般情況下，一旦服務(wù)器向客戶端返回了請(qǐng)求數(shù)據(jù)，它就要關(guān)閉 TCP 連接，然后如果客戶端或者服務(wù)器在其頭信息加入了這行代碼 Connection:keep-alive ，TCP 連接在發(fā)送后將仍然保持打開狀態(tài)，于是，客戶端可以繼續(xù)通過相同的連接發(fā)送請(qǐng)求。保持連接節(jié)省了為每個(gè)請(qǐng)求建立新連接所需的時(shí)間，還節(jié)約了網(wǎng)絡(luò)帶寬。
1.通過請(qǐng)求和響應(yīng)的交換達(dá)成通信
應(yīng)用 HTTP 協(xié)議時(shí)，必定是一端擔(dān)任客戶端角色，另一端擔(dān)任服務(wù)器端角色。僅從一條通信線路來說，服務(wù)器端和客服端的角色是確定的。HTTP 協(xié)議規(guī)定，請(qǐng)求從客戶端發(fā)出，最后服務(wù)器端響應(yīng)該請(qǐng)求并返回。換句話說，肯定是先從客戶端開始建立通信的，服務(wù)器端在沒有接收到請(qǐng)求之前不會(huì)發(fā)送響應(yīng)。
2.HTTP 是不保存狀態(tài)的協(xié)議
HTTP 是一種無狀態(tài)協(xié)議。協(xié)議自身不對(duì)請(qǐng)求和響應(yīng)之間的通信狀態(tài)進(jìn)行保存。也就是說在 HTTP 這個(gè)級(jí)別，協(xié)議對(duì)于發(fā)送過的請(qǐng)求或響應(yīng)都不做持久化處理。這是為了更快地處理大量事務(wù)，確保協(xié)議的可伸縮性，而特意把 HTTP 協(xié)議設(shè)計(jì)成如此簡(jiǎn)單的。
可是隨著 Web 的不斷發(fā)展，我們的很多業(yè)務(wù)都需要對(duì)通信狀態(tài)進(jìn)行保存。于是我們引入了 Cookie 技術(shù)。有了 Cookie 再用 HTTP 協(xié)議通信，就可以管理狀態(tài)了。
3.使用 Cookie 的狀態(tài)管理
Cookie 技術(shù)通過在請(qǐng)求和響應(yīng)報(bào)文中寫入 Cookie 信息來控制客戶端的狀態(tài)。Cookie 會(huì)根據(jù)從服務(wù)器端發(fā)送的響應(yīng)報(bào)文內(nèi)的一個(gè)叫做 Set-Cookie 的首部字段信息，通知客戶端保存Cookie。當(dāng)下次客戶端再往該服務(wù)器發(fā)送請(qǐng)求時(shí)，客戶端會(huì)自動(dòng)在請(qǐng)求報(bào)文中加入 Cookie 值后發(fā)送出去。服務(wù)器端發(fā)現(xiàn)客戶端發(fā)送過來的 Cookie 后，會(huì)去檢查究竟是從哪一個(gè)客戶端發(fā)來的連接請(qǐng)求，然后對(duì)比服務(wù)器上的記錄，最后得到之前的狀態(tài)信息。
Cookie 的流程
4.請(qǐng)求 URI 定位資源
HTTP 協(xié)議使用 URI 定位互聯(lián)網(wǎng)上的資源。正是因?yàn)?URI 的特定功能，在互聯(lián)網(wǎng)上任意位置的資源都能訪問到。
5.告知服務(wù)器意圖的 HTTP 方法（HTTP/1.1）
HTTP 方法
6.持久連接
HTTP 協(xié)議的初始版本中，每進(jìn)行一個(gè) HTTP 通信都要斷開一次 TCP 連接。比如使用瀏覽器瀏覽一個(gè)包含多張圖片的 HTML 頁面時(shí)，在發(fā)送請(qǐng)求訪問 HTML 頁面資源的同時(shí)，也會(huì)請(qǐng)求該 HTML 頁面里包含的其他資源。因此，每次的請(qǐng)求都會(huì)造成無畏的 TCP 連接建立和斷開，增加通信量的開銷。
為了解決上述 TCP 連接的問題，HTTP/1.1 和部分 HTTP/1.0 想出了持久連接的方法。其特點(diǎn)是，只要任意一端沒有明確提出斷開連接，則保持 TCP 連接狀態(tài)。旨在建立一次 TCP 連接后進(jìn)行多次請(qǐng)求和響應(yīng)的交互。在 HTTP/1.1 中，所有的連接默認(rèn)都是持久連接。
7.管線化
持久連接使得多數(shù)請(qǐng)求以管線化方式發(fā)送成為可能。以前發(fā)送請(qǐng)求后需等待并接收到響應(yīng)，才能發(fā)送下一個(gè)請(qǐng)求。管線化技術(shù)出現(xiàn)后，不用等待亦可發(fā)送下一個(gè)請(qǐng)求。這樣就能做到同時(shí)并行發(fā)送多個(gè)請(qǐng)求，而不需要一個(gè)接一個(gè)地等待響應(yīng)了。
比如，當(dāng)請(qǐng)求一個(gè)包含多張圖片的 HTML 頁面時(shí)，與挨個(gè)連接相比，用持久連接可以讓請(qǐng)求更快結(jié)束。而管線化技術(shù)要比持久連接速度更快。請(qǐng)求數(shù)越多，時(shí)間差就越明顯。
1.HTTP 報(bào)文
用于 HTTP 協(xié)議交互的信息被稱為 HTTP 報(bào)文。請(qǐng)求端（客戶端）的 HTTP 報(bào)文叫做請(qǐng)求報(bào)文；響應(yīng)端（服務(wù)器端）的叫做響應(yīng)報(bào)文。HTTP 報(bào)文本身是由多行（用 CR+LF 作換行符）數(shù)據(jù)構(gòu)成的字符串文本。
2.HTTP 報(bào)文結(jié)構(gòu)
HTTP 報(bào)文大致可分為報(bào)文首部和報(bào)文主體兩部分。兩者由最初出現(xiàn)的空行（CR+LF）來劃分。通常，并不一定有報(bào)文主體。如下：
HTTP 報(bào)文結(jié)構(gòu)
2.1請(qǐng)求報(bào)文結(jié)構(gòu)
請(qǐng)求報(bào)文結(jié)構(gòu)
請(qǐng)求報(bào)文的首部?jī)?nèi)容由以下數(shù)據(jù)組成：
請(qǐng)求報(bào)文的示例，如下：
請(qǐng)求報(bào)文示例
2.2響應(yīng)報(bào)文結(jié)構(gòu)
響應(yīng)報(bào)文結(jié)構(gòu)
響應(yīng)報(bào)文的首部?jī)?nèi)容由以下數(shù)據(jù)組成：
響應(yīng)報(bào)文的示例，如下：
響應(yīng)報(bào)文示例
1.請(qǐng)求行
舉個(gè)栗子，下面是一個(gè) HTTP 請(qǐng)求的報(bào)文：
GET /index.htm HTTP/1.1 Host: sample.com
其中，下面的這行就是請(qǐng)求行，
GET /index.htm HTTP/1.1
綜合來看，大意是請(qǐng)求訪問某臺(tái) HTTP 服務(wù)器上的 /index.htm 頁面資源。
2.狀態(tài)行
同樣舉個(gè)栗子，下面是一個(gè) HTTP 響應(yīng)的報(bào)文：
HTTP/1.1 200 OK Date: Mon, 10 Jul 2017 15:50:06 GMT Content-Length: 256 Content-Type: text/html <html> ...
其中，下面的這行就是狀態(tài)行，
HTTP/1.1 200 OK
1.首部字段概述
先來回顧一下首部字段在報(bào)文的位置，HTTP 報(bào)文包含報(bào)文首部和報(bào)文主體，報(bào)文首部包含請(qǐng)求行（或狀態(tài)行）和首部字段。
在報(bào)文眾多的字段當(dāng)中，HTTP 首部字段包含的信息最為豐富。首部字段同時(shí)存在于請(qǐng)求和響應(yīng)報(bào)文內(nèi)，并涵蓋 HTTP 報(bào)文相關(guān)的內(nèi)容信息。使用首部字段是為了給客服端和服務(wù)器端提供報(bào)文主體大小、所使用的語言、認(rèn)證信息等內(nèi)容。
2.首部字段結(jié)構(gòu)
3.首部字段類型
首部字段根據(jù)實(shí)際用途被分為以下4種類型：
4.通用首部字段（HTTP/1.1）
4.1 Cache-Control
通過指定首部字段 Cache-Control 的指令，就能操作緩存的工作機(jī)制。
4.1.1 可用的指令一覽
可用的指令按請(qǐng)求和響應(yīng)分類如下：
緩存請(qǐng)求指令
緩存響應(yīng)指令
4.1.2 表示能否緩存的指令
public 指令
Cache-Control: public
當(dāng)指定使用 public 指令時(shí)，則明確表明其他用戶也可利用緩存。
private 指令
Cache-Control: private
當(dāng)指定 private 指令后，響應(yīng)只以特定的用戶作為對(duì)象，這與 public 指令的行為相反。緩存服務(wù)器會(huì)對(duì)該特定用戶提供資源緩存的服務(wù)，對(duì)于其他用戶發(fā)送過來的請(qǐng)求，代理服務(wù)器則不會(huì)返回緩存。
no-cache 指令
Cache-Control: no-cache
Cache-Control: no-cache=Location
由服務(wù)器返回的響應(yīng)中，若報(bào)文首部字段 Cache-Control 中對(duì) no-cache 字段名具體指定參數(shù)值，那么客戶端在接收到這個(gè)被指定參數(shù)值的首部字段對(duì)應(yīng)的響應(yīng)報(bào)文后，就不能使用緩存。換言之，無參數(shù)值的首部字段可以使用緩存。只能在響應(yīng)指令中指定該參數(shù)。
no-store 指令
Cache-Control: no-store
當(dāng)使用 no-store 指令時(shí)，暗示請(qǐng)求（和對(duì)應(yīng)的響應(yīng)）或響應(yīng)中包含機(jī)密信息。因此，該指令規(guī)定緩存不能在本地存儲(chǔ)請(qǐng)求或響應(yīng)的任一部分。
注意：no-cache 指令代表不緩存過期的指令，緩存會(huì)向源服務(wù)器進(jìn)行有效期確認(rèn)后處理資源；no-store 指令才是真正的不進(jìn)行緩存。
4.1.3 指定緩存期限和認(rèn)證的指令
s-maxage 指令
Cache-Control: s-maxage=604800（單位：秒）
max-age 指令
Cache-Control: max-age=604800（單位：秒）
min-fresh 指令
Cache-Control: min-fresh=60（單位：秒）
min-fresh 指令要求緩存服務(wù)器返回至少還未過指定時(shí)間的緩存資源。
max-stale 指令
Cache-Control: max-stale=3600（單位：秒）
only-if-cached 指令
Cache-Control: only-if-cached
表示客戶端僅在緩存服務(wù)器本地緩存目標(biāo)資源的情況下才會(huì)要求其返回。換言之，該指令要求緩存服務(wù)器不重新加載響應(yīng)，也不會(huì)再次確認(rèn)資源的有效性。
must-revalidate 指令
Cache-Control: must-revalidate
使用 must-revalidate 指令，代理會(huì)向源服務(wù)器再次驗(yàn)證即將返回的響應(yīng)緩存目前是否仍有效。另外，使用 must-revalidate 指令會(huì)忽略請(qǐng)求的 max-stale 指令。
proxy-revalidate 指令
Cache-Control: proxy-revalidate
proxy-revalidate 指令要求所有的緩存服務(wù)器在接收到客戶端帶有該指令的請(qǐng)求返回響應(yīng)之前，必須再次驗(yàn)證緩存的有效性。
no-transform 指令
Cache-Control: no-transform
使用 no-transform 指令規(guī)定無論是在請(qǐng)求還是響應(yīng)中，緩存都不能改變實(shí)體主體的媒體類型。這樣做可防止緩存或代理壓縮圖片等類似操作。
4.1.4 Cache-Control 擴(kuò)展
Cache-Control: private, community="UCI"
通過 cache-extension 標(biāo)記（token），可以擴(kuò)展 Cache-Control 首部字段內(nèi)的指令。上述 community 指令即擴(kuò)展的指令，如果緩存服務(wù)器不能理解這個(gè)新指令，就會(huì)直接忽略掉。
4.2 Connection
Connection 首部字段具備以下兩個(gè)作用：
控制不再轉(zhuǎn)發(fā)的首部字段
Connection: Upgrade
在客戶端發(fā)送請(qǐng)求和服務(wù)器返回響應(yīng)中，使用 Connection 首部字段，可控制不再轉(zhuǎn)發(fā)給代理的首部字段，即刪除后再轉(zhuǎn)發(fā)（即Hop-by-hop首部）。
管理持久連接
Connection: close
HTTP/1.1 版本的默認(rèn)連接都是持久連接。當(dāng)服務(wù)器端想明確斷開連接時(shí)，則指定 Connection 首部字段的值為 close。
Connection: Keep-Alive
HTTP/1.1 之前的 HTTP 版本的默認(rèn)連接都是非持久連接。為此，如果想在舊版本的 HTTP 協(xié)議上維持持續(xù)連接，則需要指定 Connection 首部字段的值為 Keep-Alive。
4.3 Date
表明創(chuàng)建 HTTP 報(bào)文的日期和時(shí)間。
Date: Mon, 10 Jul 2017 15:50:06 GMT
HTTP/1.1 協(xié)議使用在 RFC1123 中規(guī)定的日期時(shí)間的格式。
4.4 Pragma
Pragma 首部字段是 HTTP/1.1 版本之前的歷史遺留字段，僅作為與 HTTP/1.0 的向后兼容而定義。
Pragma: no-cache
Cache-Control: no-cache Pragma: no-cache
4.5 Trailer
Trailer: Expires
首部字段 Trailer 會(huì)事先說明在報(bào)文主體后記錄了哪些首部字段?？蓱?yīng)用在 HTTP/1.1 版本分塊傳輸編碼時(shí)。
4.6 Transfer-Encoding
Transfer-Encoding: chunked
4.7 Upgrade
Upgrade: TSL/1.0
用于檢測(cè) HTTP 協(xié)議及其他協(xié)議是否可使用更高的版本進(jìn)行通信，其參數(shù)值可以用來指定一個(gè)完全不同的通信協(xié)議。
4.8 Via
Via: 1.1 a1.sample.com(Squid/2.7)
4.9 Warning
該首部字段通常會(huì)告知用戶一些與緩存相關(guān)的問題的警告。
Warning 首部字段的格式如下：
Warning：[警告碼][警告的主機(jī):端口號(hào)] "[警告內(nèi)容]"([日期時(shí)間])
最后的日期時(shí)間可省略。
HTTP/1.1 中定義了7種警告，警告碼對(duì)應(yīng)的警告內(nèi)容僅推薦參考，另外，警告碼具備擴(kuò)展性，今后有可能追加新的警告碼。
5. 請(qǐng)求首部字段（HTTP/1.1）
5.1 Accept
Accept: text/html, application/xhtml+xml, application/xml; q=0.5
5.2 Accept-Charset
Accept-Charset: iso-8859-5, unicode-1-1; q=0.8
Accept-Charset 首部字段可用來通知服務(wù)器用戶代理支持的字符集及字符集的相對(duì)優(yōu)先順序。另外，可一次性指定多種字符集。同樣使用 q=[數(shù)值] 來表示相對(duì)優(yōu)先級(jí)。
5.3 Accept-Encoding
Accept-Encoding: gzip, deflate
Accept-Encoding 首部字段用來告知服務(wù)器用戶代理支持的內(nèi)容編碼及內(nèi)容編碼的優(yōu)先順序，并可一次性指定多種內(nèi)容編碼。同樣使用 q=[數(shù)值] 來表示相對(duì)優(yōu)先級(jí)。也可使用星號(hào)（*）作為通配符，指定任意的編碼格式。
5.4 Accept-Language
Accept-Lanuage: zh-cn,zh;q=0.7,en=us,en;q=0.3
告知服務(wù)器用戶代理能夠處理的自然語言集（指中文或英文等），以及自然語言集的相對(duì)優(yōu)先級(jí)，可一次性指定多種自然語言集。同樣使用 q=[數(shù)值] 來表示相對(duì)優(yōu)先級(jí)。
5.5 Authorization
Authorization: Basic ldfKDHKfkDdasSAEdasd==
告知服務(wù)器用戶代理的認(rèn)證信息（證書值）。通常，想要通過服務(wù)器認(rèn)證的用戶代理會(huì)在接收到返回的 401 狀態(tài)碼響應(yīng)后，把首部字段 Authorization 加入請(qǐng)求中。共用緩存在接收到含有 Authorization 首部字段的請(qǐng)求時(shí)的操作處理會(huì)略有差異。
5.6 Expect
Expect: 100-continue
告知服務(wù)器客戶端期望出現(xiàn)的某種特定行為。
5.7 From
From: Deeson_Woo@163.com
告知服務(wù)器使用用戶代理的電子郵件地址。
5.8 Host
Host: www.jianshu.com
5.9 If-Match
形如 If-xxx 這種樣式的請(qǐng)求首部字段，都可稱為條件請(qǐng)求。服務(wù)器接收到附帶條件的請(qǐng)求后，只有判斷指定條件為真時(shí)，才會(huì)執(zhí)行請(qǐng)求。
If-Match: "123456"
5.10 If-Modified-Since
If-Modified-Since: Mon, 10 Jul 2017 15:50:06 GMT
5.11 If-None-Match
If-None-Match: "123456"
首部字段 If-None-Match 屬于附帶條件之一。它和首部字段 If-Match 作用相反。用于指定 If-None-Match 字段值的實(shí)體標(biāo)記（ETag）值與請(qǐng)求資源的 ETag 不一致時(shí)，它就告知服務(wù)器處理該請(qǐng)求。
5.12 If-Range
If-Range: "123456"
5.13 If-Unmodified-Since
If-Unmodified-Since: Mon, 10 Jul 2017 15:50:06 GMT
首部字段 If-Unmodified-Since 和首部字段 If-Modified-Since 的作用相反。它的作用的是告知服務(wù)器，指定的請(qǐng)求資源只有在字段值內(nèi)指定的日期時(shí)間之后，未發(fā)生更新的情況下，才能處理請(qǐng)求。如果在指定日期時(shí)間后發(fā)生了更新，則以狀態(tài)碼 412 Precondition Failed 作為響應(yīng)返回。
5.14 Max-Forwards
Max-Forwards: 10
通過 TRACE 方法或 OPTIONS 方法，發(fā)送包含首部字段 Max-Forwards 的請(qǐng)求時(shí)，該字段以十進(jìn)制整數(shù)形式指定可經(jīng)過的服務(wù)器最大數(shù)目。服務(wù)器在往下一個(gè)服務(wù)器轉(zhuǎn)發(fā)請(qǐng)求之前，Max-Forwards 的值減 1 后重新賦值。當(dāng)服務(wù)器接收到 Max-Forwards 值為 0 的請(qǐng)求時(shí)，則不再進(jìn)行轉(zhuǎn)發(fā)，而是直接返回響應(yīng)。
5.15 Proxy-Authorization
Proxy-Authorization: Basic dGlwOjkpNLAGfFY5
5.16 Range
Range: bytes=5001-10000
5.17 Referer
Referer: http://www.sample.com/index.html
首部字段 Referer 會(huì)告知服務(wù)器請(qǐng)求的原始資源的 URI。
5.18 TE
TE: gzip, deflate; q=0.5
5.19 User-Agent
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101
6.1 Accept-Ranges
Accept-Ranges: bytes
6.2 Age
Age: 1200
6.3 ETag
ETag: "usagi-1234"
6.4 Location
Location: http://www.sample.com/sample.html
6.5 Proxy-Authenticate
Proxy-Authenticate: Basic realm="Usagidesign Auth"
6.6 Retry-After
Retry-After: 180
6.7 Server
Server: Apache/2.2.6 (Unix) PHP/5.2.5
首部字段 Server 告知客戶端當(dāng)前服務(wù)器上安裝的 HTTP 服務(wù)器應(yīng)用程序的信息。不單單會(huì)標(biāo)出服務(wù)器上的軟件應(yīng)用名稱，還有可能包括版本號(hào)和安裝時(shí)啟用的可選項(xiàng)。
6.8 Vary
Vary: Accept-Language
6.9 WWW-Authenticate
WWW-Authenticate: Basic realm="Usagidesign Auth"
首部字段 WWW-Authenticate 用于 HTTP 訪問認(rèn)證。它會(huì)告知客戶端適用于訪問請(qǐng)求 URI 所指定資源的認(rèn)證方案（Basic 或是 Digest）和帶參數(shù)提示的質(zhì)詢（challenge）。
7. 實(shí)體首部字段（HTTP/1.1）
7.1 Allow
Allow: GET, HEAD
7.2 Content-Encoding
Content-Encoding: gzip
7.3 Content-Language
Content-Language: zh-CN
首部字段 Content-Language 會(huì)告知客戶端，實(shí)體主體使用的自然語言（指中文或英文等語言）。
7.4 Content-Length
Content-Length: 15000
首部字段 Content-Length 表明了實(shí)體主體部分的大?。▎挝皇亲止?jié)）。對(duì)實(shí)體主體進(jìn)行內(nèi)容編碼傳輸時(shí)，不能再使用 Content-Length首部字段。
7.5 Content-Location
Content-Location: http://www.sample.com/index.html
首部字段 Content-Location 給出與報(bào)文主體部分相對(duì)應(yīng)的 URI。和首部字段 Location 不同，Content-Location 表示的是報(bào)文主體返回資源對(duì)應(yīng)的 URI。
7.6 Content-MD5
Content-MD5: OGFkZDUwNGVhNGY3N2MxMDIwZmQ4NTBmY2IyTY==
首部字段 Content-MD5 是一串由 MD5 算法生成的值，其目的在于檢查報(bào)文主體在傳輸過程中是否保持完整，以及確認(rèn)傳輸?shù)竭_(dá)。
7.7 Content-Range
Content-Range: bytes 5001-10000/10000
針對(duì)范圍請(qǐng)求，返回響應(yīng)時(shí)使用的首部字段 Content-Range，能告知客戶端作為響應(yīng)返回的實(shí)體的哪個(gè)部分符合范圍請(qǐng)求。字段值以字節(jié)為單位，表示當(dāng)前發(fā)送部分及整個(gè)實(shí)體大小。
7.8 Content-Type
Content-Type: text/html; charset=UTF-8
首部字段 Content-Type 說明了實(shí)體主體內(nèi)對(duì)象的媒體類型。和首部字段 Accept 一樣，字段值用 type/subtype 形式賦值。參數(shù) charset 使用 iso-8859-1 或 euc-jp 等字符集進(jìn)行賦值。
7.9 Expires
Expires: Mon, 10 Jul 2017 15:50:06 GMT
7.10 Last-Modified
Last-Modified: Mon, 10 Jul 2017 15:50:06 GMT
首部字段 Last-Modified 指明資源最終修改的時(shí)間。一般來說，這個(gè)值就是 Request-URI 指定資源被修改的時(shí)間。但類似使用 CGI 腳本進(jìn)行動(dòng)態(tài)數(shù)據(jù)處理時(shí)，該值有可能會(huì)變成數(shù)據(jù)最終修改時(shí)的時(shí)間。
8. 為 Cookie 服務(wù)的首部字段
8.1 Set-Cookie
Set-Cookie: status=enable; expires=Mon, 10 Jul 2017 15:50:06 GMT; path=/;
下面的表格列舉了 Set-Cookie 的字段值。
8.1.1 expires 屬性
8.1.2 path 屬性
Cookie 的 path 屬性可用于限制指定 Cookie 的發(fā)送范圍的文件目錄。
8.1.3 domain 屬性
8.1.4 secure 屬性
Cookie 的 secure 屬性用于限制 Web 頁面僅在 HTTPS 安全連接時(shí)，才可以發(fā)送 Cookie。
8.1.5 HttpOnly 屬性
8.2 Cookie
Cookie: status=enable
首部字段 Cookie 會(huì)告知服務(wù)器，當(dāng)客戶端想獲得 HTTP 狀態(tài)管理支持時(shí)，就會(huì)在請(qǐng)求中包含從服務(wù)器接收到的 Cookie。接收到多個(gè) Cookie 時(shí)，同樣可以以多個(gè) Cookie 形式發(fā)送。
9. 其他首部字段
HTTP 首部字段是可以自行擴(kuò)展的。所以在 Web 服務(wù)器和瀏覽器的應(yīng)用上，會(huì)出現(xiàn)各種非標(biāo)準(zhǔn)的首部字段。
以下是最為常用的首部字段。
9.1 X-Frame-Options
X-Frame-Options: DENY
首部字段 X-Frame-Options 屬于 HTTP 響應(yīng)首部，用于控制網(wǎng)站內(nèi)容在其他 Web 網(wǎng)站的 Frame 標(biāo)簽內(nèi)的顯示問題。其主要目的是為了防止點(diǎn)擊劫持（clickjacking）攻擊。首部字段 X-Frame-Options 有以下兩個(gè)可指定的字段值：
9.2 X-XSS-Protection
X-XSS-Protection: 1
首部字段 X-XSS-Protection 屬于 HTTP 響應(yīng)首部，它是針對(duì)跨站腳本攻擊（XSS）的一種對(duì)策，用于控制瀏覽器 XSS 防護(hù)機(jī)制的開關(guān)。首部字段 X-XSS-Protection 可指定的字段值如下:
9.3 DNT
DNT: 1
首部字段 DNT 屬于 HTTP 請(qǐng)求首部，其中 DNT 是 Do Not Track 的簡(jiǎn)稱，意為拒絕個(gè)人信息被收集，是表示拒絕被精準(zhǔn)廣告追蹤的一種方法。首部字段 DNT 可指定的字段值如下：
由于首部字段 DNT 的功能具備有效性，所以 Web 服務(wù)器需要對(duì) DNT做對(duì)應(yīng)的支持。
9.4 P3P
P3P: CP="CAO DSP LAW CURa ADMa DEVa TAIa PSAa PSDa IVAa IVDa OUR BUS IND
首部字段 P3P 屬于 HTTP 響應(yīng)首部，通過利用 P3P（The Platform for Privacy Preferences，在線隱私偏好平臺(tái)）技術(shù)，可以讓 Web 網(wǎng)站上的個(gè)人隱私變成一種僅供程序可理解的形式，以達(dá)到保護(hù)用戶隱私的目的。
要進(jìn)行 P3P 的設(shè)定，需按以下操作步驟進(jìn)行：
1. 狀態(tài)碼概述
2. 狀態(tài)碼類別
我們可以自行改變 RFC2616 中定義的狀態(tài)碼或者服務(wù)器端自行創(chuàng)建狀態(tài)碼，只要遵守狀態(tài)碼的類別定義就可以了。
3. 常用狀態(tài)碼解析
HTTP 狀態(tài)碼種類繁多，數(shù)量達(dá)幾十種。其中最常用的有以下 14 種，一起來看看。
3.1 200 OK
表示從客戶端發(fā)來的請(qǐng)求在服務(wù)器端被正常處理了。
3.2 204 No Content
3.3 206 Partial Content
表示客戶端進(jìn)行了范圍請(qǐng)求，而服務(wù)器成功執(zhí)行了這部分的 GET 請(qǐng)求。響應(yīng)報(bào)文中包含由 Content-Range 首部字段指定范圍的實(shí)體內(nèi)容。
3.4 301 Moved Permanently
永久性重定向。表示請(qǐng)求的資源已被分配了新的 URI。以后應(yīng)使用資源現(xiàn)在所指的 URI。也就是說，如果已經(jīng)把資源對(duì)應(yīng)的 URI 保存為書簽了，這時(shí)應(yīng)該按 Location 首部字段提示的 URI 重新保存。
3.5 302 Found
3.6 303 See Other
3.7 304 Not Modified
3.8 307 Temporary Redirect
臨時(shí)重定向。該狀態(tài)碼與 302 Found 有著相同的含義。
3.9 400 Bad Request
3.10 401 Unauthorized
3.11 403 Forbidden
表明對(duì)請(qǐng)求資源的訪問被服務(wù)器拒絕了。服務(wù)器端沒有必要給出詳細(xì)的拒絕理由，當(dāng)然也可以在響應(yīng)報(bào)文的實(shí)體主體部分對(duì)原因進(jìn)行描述。
3.12 404 Not Found
表明服務(wù)器上無法找到請(qǐng)求的資源。除此之外，也可以在服務(wù)器端拒絕請(qǐng)求且不想說明理由的時(shí)候使用。
3.13 500 Internal Server Error
表明服務(wù)器端在執(zhí)行請(qǐng)求時(shí)發(fā)生了錯(cuò)誤。也可能是 Web 應(yīng)用存在的 bug 或某些臨時(shí)的故障。
3.14 503 Service Unavailable
表明服務(wù)器暫時(shí)處于超負(fù)載或正在進(jìn)行停機(jī)維護(hù)，現(xiàn)在無法處理請(qǐng)求。如果事先得知解除以上狀況需要的時(shí)間，最好寫入 Retry-After 首部字段再返回給客戶端。
1. HTTP 報(bào)文實(shí)體概述
HTTP 報(bào)文結(jié)構(gòu)
大家請(qǐng)仔細(xì)看看上面示例中，各個(gè)組成部分對(duì)應(yīng)的內(nèi)容。
接著，我們來看看報(bào)文和實(shí)體的概念。如果把 HTTP 報(bào)文想象成因特網(wǎng)貨運(yùn)系統(tǒng)中的箱子，那么 HTTP 實(shí)體就是報(bào)文中實(shí)際的貨物。
我們可以看到，上面示例右圖中深紅色框的內(nèi)容就是報(bào)文的實(shí)體部分，而藍(lán)色框的兩部分內(nèi)容分別就是實(shí)體首部和實(shí)體主體。而左圖中粉紅框內(nèi)容就是報(bào)文主體。
通常，報(bào)文主體等于實(shí)體主體。只有當(dāng)傳輸中進(jìn)行編碼操作時(shí)，實(shí)體主體的內(nèi)容發(fā)生變化，才導(dǎo)致它和報(bào)文主體產(chǎn)生差異。
2. 內(nèi)容編碼
內(nèi)容編碼類型：
3. 傳輸編碼
內(nèi)容編碼是對(duì)報(bào)文的主體進(jìn)行的可逆變換，是和內(nèi)容的具體格式細(xì)節(jié)緊密相關(guān)的。
傳輸編碼也是作用在實(shí)體主體上的可逆變換，但使用它們是由于架構(gòu)方面的原因，同內(nèi)容的格式無關(guān)。使用傳輸編碼是為了改變報(bào)文中的數(shù)據(jù)在網(wǎng)絡(luò)上傳輸?shù)姆绞健?/p>
內(nèi)容編碼和傳輸編碼的對(duì)比
4. 分塊編碼
分塊編碼把報(bào)文分割成若干已知大小的塊。塊之間是緊挨著發(fā)送的，這樣就不需要在發(fā)送之前知道整個(gè)報(bào)文的大小了。分塊編碼是一種傳輸編碼，是報(bào)文的屬性。
分塊編碼與持久連接
若客戶端與服務(wù)器端之間不是持久連接，客戶端就不需要知道它在讀取的主體的長(zhǎng)度，而只需要讀取到服務(wù)器關(guān)閉主體連接為止。
當(dāng)使用持久連接時(shí)，在服務(wù)器寫主體之前，必須知道它的大小并在 Content-Length 首部中發(fā)送。如果服務(wù)器動(dòng)態(tài)創(chuàng)建內(nèi)容，就可能在發(fā)送之前無法知道主體的長(zhǎng)度。
分塊編碼為這種困難提供了解決方案，只要允許服務(wù)器把主體分塊發(fā)送，說明每塊的大小就可以了。因?yàn)橹黧w是動(dòng)態(tài)創(chuàng)建的，服務(wù)器可以緩沖它的一部分，發(fā)送其大小和相應(yīng)的塊，然后在主體發(fā)送完之前重復(fù)這個(gè)過程。服務(wù)器可以用大小為 0 的塊作為主體結(jié)束的信號(hào)，這樣就可以繼續(xù)保持連接，為下一個(gè)響應(yīng)做準(zhǔn)備。
來看看一個(gè)分塊編碼的報(bào)文示例：
分塊編碼的報(bào)文
5.多部分媒體類型
MIME 中的 multipart（多部分）電子郵件報(bào)文中包含多個(gè)報(bào)文，它們合在一起作為單一的復(fù)雜報(bào)文發(fā)送。每一部分都是獨(dú)立的，有各自的描述其內(nèi)容的集，不同部分之間用分界字符串連接在一起。
相應(yīng)得，HTTP 協(xié)議中也采納了多部分對(duì)象集合，發(fā)送的一份報(bào)文主體內(nèi)可包含多種類型實(shí)體。
多部分對(duì)象集合包含的對(duì)象如下：
6. 范圍請(qǐng)求
假設(shè)你正在下載一個(gè)很大的文件，已經(jīng)下了四分之三，忽然網(wǎng)絡(luò)中斷了，那下載就必須重頭再來一遍。為了解決這個(gè)問題，需要一種可恢復(fù)的機(jī)制，即能從之前下載中斷處恢復(fù)下載。要實(shí)現(xiàn)該功能，這就要用到范圍請(qǐng)求。
有了范圍請(qǐng)求， HTTP 客戶端可以通過請(qǐng)求曾獲取失敗的實(shí)體的一個(gè)范圍（或者說一部分），來恢復(fù)下載該實(shí)體。當(dāng)然這有一個(gè)前提，那就是從客戶端上一次請(qǐng)求該實(shí)體到這一次發(fā)出范圍請(qǐng)求的時(shí)間段內(nèi)，該對(duì)象沒有改變過。例如：
GET /bigfile.html HTTP/1.1 Host: www.sample.com Range: bytes=20224- ···
實(shí)體范圍請(qǐng)求示例
上面示例中，客戶端請(qǐng)求的是文檔開頭20224字節(jié)之后的部分。
HTTP 通信時(shí)，除客戶端和服務(wù)器外，還有一些用于協(xié)助通信的應(yīng)用程序。如下列出比較重要的幾個(gè)：代理、緩存、網(wǎng)關(guān)、隧道、Agent 代理。
1.代理
代理
HTTP 代理服務(wù)器是 Web 安全、應(yīng)用集成以及性能優(yōu)化的重要組成模塊。代理位于客戶端和服務(wù)器端之間，接收客戶端所有的 HTTP 請(qǐng)求，并將這些請(qǐng)求轉(zhuǎn)發(fā)給服務(wù)器（可能會(huì)對(duì)請(qǐng)求進(jìn)行修改之后再進(jìn)行轉(zhuǎn)發(fā)）。對(duì)用戶來說，這些應(yīng)用程序就是一個(gè)代理，代表用戶訪問服務(wù)器。
出于安全考慮，通常會(huì)將代理作為轉(zhuǎn)發(fā)所有 Web 流量的可信任中間節(jié)點(diǎn)使用。代理還可以對(duì)請(qǐng)求和響應(yīng)進(jìn)行過濾，安全上網(wǎng)或綠色上網(wǎng)。
2. 緩存
瀏覽器第一次請(qǐng)求：
瀏覽器第一次請(qǐng)求
瀏覽器再次請(qǐng)求：
瀏覽器再次請(qǐng)求
Web 緩存或代理緩存是一種特殊的 HTTP 代理服務(wù)器，可以將經(jīng)過代理傳輸?shù)某Ｓ梦臋n復(fù)制保存起來。下一個(gè)請(qǐng)求同一文檔的客戶端就可以享受緩存的私有副本所提供的服務(wù)了?？蛻舳藦母浇木彺嫦螺d文檔會(huì)比從遠(yuǎn)程 Web 服務(wù)器下載快得多。
3. 網(wǎng)關(guān)
HTTP / FTP 網(wǎng)關(guān)
網(wǎng)關(guān)是一種特殊的服務(wù)器，作為其他服務(wù)器的中間實(shí)體使用。通常用于將 HTTP 流量轉(zhuǎn)換成其他的協(xié)議。網(wǎng)關(guān)接收請(qǐng)求時(shí)就好像自己是資源的源服務(wù)器一樣。客戶端可能并不知道自己正在跟一個(gè)網(wǎng)關(guān)進(jìn)行通信。
4. 隧道
HTTP/SSL 隧道
隧道是會(huì)在建立起來之后，就會(huì)在兩條連接之間對(duì)原始數(shù)據(jù)進(jìn)行盲轉(zhuǎn)發(fā)的 HTTP 應(yīng)用程序。HTTP 隧道通常用來在一條或多條 HTTP 連接上轉(zhuǎn)發(fā)非 HTTP 數(shù)據(jù)，轉(zhuǎn)發(fā)時(shí)不會(huì)窺探數(shù)據(jù)。
HTTP 隧道的一種常見用途就是通過 HTTP 連接承載加密的安全套接字層（SSL）流量，這樣 SSL 流量就可以穿過只允許 Web 流量通過的防火墻了。
5. Agent 代理
自動(dòng)搜索引擎“網(wǎng)絡(luò)蜘蛛”
Agent 代理是代表用戶發(fā)起 HTTP 請(qǐng)求的客戶端應(yīng)用程序。所有發(fā)布 Web 請(qǐng)求的應(yīng)用程序都是 HTTP Agent 代理。
來源：簡(jiǎn)書 鏈接：https://www.jianshu.com/p/6e9e4156ece3
超文本傳輸協(xié)議（HyperText Transfer Protocol，HTTP），是互聯(lián)網(wǎng)應(yīng)用最廣泛的網(wǎng)絡(luò)協(xié)議。最初的HTTP協(xié)議設(shè)計(jì)用于發(fā)送和接收HTML。經(jīng)過發(fā)展演變成為客戶端和服務(wù)器進(jìn)行請(qǐng)求(Request)和響應(yīng)(Response)的標(biāo)準(zhǔn)協(xié)議。要了解HTTP的運(yùn)行過程，需要了解大體OSI模型
由下到上，OSI模型描述了整個(gè)網(wǎng)絡(luò)架構(gòu)中從基礎(chǔ)設(shè)置到上層應(yīng)用的框架。
HTTP是建立在TCP/IP協(xié)議之上的應(yīng)用層協(xié)議，HTTP規(guī)定了請(qǐng)求和響應(yīng)的報(bào)文格式，由TCP/IP協(xié)議簇進(jìn)行轉(zhuǎn)發(fā)，送達(dá)目標(biāo)(服務(wù)器)之后，按照HTTP協(xié)議可以解析得到報(bào)文的意義，并進(jìn)行響應(yīng)處理。
上圖描述的是一個(gè)簡(jiǎn)單的HTTP請(qǐng)求過程，其中HTTP主要起到的作用，就是告知客戶端和服務(wù)器，如何構(gòu)建報(bào)文，如何解析報(bào)文，而傳輸則交給下層TCP/IP協(xié)議進(jìn)行。此外還有一些與通信有關(guān)系的程序，也做一下介紹：
代理：接收客戶端發(fā)送的請(qǐng)求后直接轉(zhuǎn)發(fā)給其他服務(wù)器(可能會(huì)被發(fā)送到下一個(gè)代理)，不會(huì)改變URI。（如果有級(jí)聯(lián)的多臺(tái)代理服務(wù)器，當(dāng)客戶端請(qǐng)求到達(dá)第一個(gè)代理服務(wù)器時(shí)，該服務(wù)器會(huì)在自己發(fā)出的請(qǐng)求里面添加via頭部，并填上自己的相關(guān)信息，當(dāng)下一個(gè)代理服務(wù)器 收到第一個(gè)代理服務(wù)器的請(qǐng)求時(shí)，會(huì)在自己發(fā)出的請(qǐng)求里面復(fù)制前一個(gè)代理服務(wù)器的請(qǐng)求的Via頭部，并把自己的相關(guān)信息加到后面。）緩存代理：請(qǐng)求的內(nèi)容直接從代理服務(wù)器中獲取，而不必從源服務(wù)器獲取。
網(wǎng)關(guān)：作用與代理類似，但是可以改變請(qǐng)求的協(xié)議，比如講HTTP協(xié)議轉(zhuǎn)換成為私有協(xié)議或者其他協(xié)議，在兩個(gè)網(wǎng)關(guān)之間傳輸，達(dá)到加密的作用。
隧道：通過和HTTP CONNECT方法，構(gòu)建服務(wù)器和客戶端之間的通信線路，可以增加安全線
HTTP報(bào)文的構(gòu)建：
發(fā)出的請(qǐng)求信息包括以下幾個(gè)
請(qǐng)求行 方法(GET,POST等) URI(統(tǒng)一資源標(biāo)識(shí)符) HTTP/1.1，表示請(qǐng)求URI代表的資源
請(qǐng)求首部字段 Host: www.qiongsong.com Accept-Language: cn Connection: keep-alive ……
空行
其他消息體
請(qǐng)求行和標(biāo)題必須以作為結(jié)尾。空行內(nèi)必須只有而無其他空格。在HTTP/1.1協(xié)議中，所有的請(qǐng)求頭，除Host外，都是可選的。
返回的響應(yīng)消息包括下面的幾個(gè)部分
協(xié)議版本號(hào)(HTTP/1.1) 狀態(tài)碼(200、404) 狀態(tài)碼原因短語(OK)
響應(yīng)主體
HTTP1.1 中的請(qǐng)求方法有以下幾種
GET: 獲取資源
POST: 傳輸實(shí)體主體
PUT: 傳輸文件，一般不使用，因?yàn)椴粠?yàn)證機(jī)制，任何人都可以使用PUT來進(jìn)行文件上傳，可以考慮結(jié)合表征狀態(tài)轉(zhuǎn)移(REST Representational State Transfer)或者增加額外的驗(yàn)證機(jī)制來配合使用
HEAD: 獲取報(bào)文首部
DELETE: 刪除資源，與PUT一樣不帶有驗(yàn)證機(jī)制
OPTIONS：詢問支持的方法
TRACE：追蹤路徑，讓服務(wù)器端將之前的請(qǐng)求通信環(huán)回路給客戶端，主要用于跟蹤問題
CONNECT：要求用隧道協(xié)議鏈接代理，一般配合(SSL、TLS) 使用。
狀態(tài)碼則主要有以下幾種類別，每一種類別又有細(xì)分的狀態(tài)碼
1xx消息——請(qǐng)求已被服務(wù)器接收，繼續(xù)處理
2xx成功——請(qǐng)求已成功被服務(wù)器接收、理解、并接受
3xx重定向——需要后續(xù)操作才能完成這一請(qǐng)求(304為資源未修改，與3XX有一點(diǎn)差異)
4xx請(qǐng)求錯(cuò)誤——請(qǐng)求含有詞法錯(cuò)誤或者無法被執(zhí)行
5xx服務(wù)器錯(cuò)誤——服務(wù)器在處理某個(gè)正確請(qǐng)求時(shí)發(fā)生錯(cuò)誤
HTTP 的一種重要的特性就是協(xié)議本身是無狀態(tài)的，也就是服務(wù)器在接受同一個(gè)用戶發(fā)起的請(qǐng)求報(bào)文的時(shí)候，并無法知道這些請(qǐng)求是由同一個(gè)用戶發(fā)送過來，也無法得知這些請(qǐng)求的上下文關(guān)系。而我們平時(shí)瀏覽網(wǎng)頁特別是需要進(jìn)行用戶驗(yàn)證類的網(wǎng)頁，每一次要求用戶進(jìn)行身份驗(yàn)證并不合理。為解決這個(gè)問題，就發(fā)展出Cookie技術(shù)。
Cookie技術(shù)通過在請(qǐng)求和響應(yīng)報(bào)文中寫入cookie信息來控制客戶端的狀態(tài)。從服務(wù)器返回的報(bào)文中，通過set-cookie首部字段，添加cookie(由服務(wù)器生成，并通常做加密處理)，客戶端收到返回報(bào)文之后會(huì)保存cookie，當(dāng)下一次客戶端向服務(wù)器發(fā)送請(qǐng)求的時(shí)候，會(huì)在請(qǐng)求中加入cookie值后發(fā)送。服務(wù)器獲取到cookie之后，會(huì)對(duì)比之前服務(wù)器上的記錄(session)，從而對(duì)請(qǐng)求進(jìn)行狀態(tài)識(shí)別。
cookie具有長(zhǎng)度限制，不同的瀏覽器之間有細(xì)微的差異，一般不能超過4097個(gè)字節(jié)，超過這個(gè)數(shù)量的cookie在請(qǐng)求的時(shí)候，瀏覽器會(huì)直接忽略。
對(duì)于 Cookie 的安全保護(hù)是 Web 安全的一個(gè)重要因素，常見的將 Cookie 設(shè)置為 Httponly，避免js 腳本直接獲取 Cookie，同時(shí)采用加密傳輸方式來傳輸內(nèi)容，避免中間人攻擊。
性能對(duì)于傳輸協(xié)議而言至關(guān)重要，剝離底層 TCP 協(xié)議對(duì)傳輸性能的影響，在 HTTP 層面對(duì)性能影響的點(diǎn)有
現(xiàn)在最流行的 HTTP1.1 對(duì)于程序員而言，相比于 HTTP1.0 的最大改進(jìn)在于對(duì)長(zhǎng)連接的支持，HTTP1.1 默認(rèn)支持長(zhǎng)連接和請(qǐng)求流水線，可以在一個(gè) TCP 連接上傳輸多個(gè) HTTP 請(qǐng)求，減少建立連接的延遲，體現(xiàn)在報(bào)文中是 Connection:keep-alive 的默認(rèn)開啟。
而對(duì)于內(nèi)存，通過引入過期時(shí)間等，可以避免重復(fù)請(qǐng)求，提高相應(yīng)速度。
HTTP 在網(wǎng)絡(luò)上傳輸采用的是明文信息，可能會(huì)被惡意截獲從而產(chǎn)生安全問題。為了解決 HTTP 的傳輸安全性，增加了一個(gè) SSL （Secure Socket Layer）層，HTTPs = HTTP + SSL。
下面簡(jiǎn)單描述一下 HTTPs 是如何保證數(shù)據(jù)傳輸安全的。為了保證數(shù)據(jù)傳輸不被截獲，那么需要對(duì)數(shù)據(jù)進(jìn)行加密，傳輸過程中采用密文進(jìn)行傳輸。加密的方法有兩類：一類是對(duì)稱加密，密鑰只有一個(gè)，內(nèi)容通過密鑰加密后，只能通過這個(gè)密鑰解密；另一類是非對(duì)稱加密，密文通過公鑰加密后，通過另一個(gè)私鑰解密，密鑰是成對(duì)出現(xiàn)的。對(duì)稱加密算法效率較高，非對(duì)稱加密算法較為復(fù)雜同時(shí)效率也比較低。因此 HTTPs 將兩者結(jié)合起來，實(shí)現(xiàn)了在網(wǎng)絡(luò)中的安全傳輸，大致原理是，首先通過非對(duì)稱加密算法協(xié)商對(duì)稱加密的密鑰，后續(xù)通過協(xié)商出來的密鑰進(jìn)行數(shù)據(jù)的加解密和傳輸。
其中有幾點(diǎn)要補(bǔ)充說明
SSL協(xié)議不信任每個(gè)主機(jī)都能產(chǎn)生完全隨機(jī)的隨機(jī)數(shù)，如果隨機(jī)數(shù)不隨機(jī)，那么pre-master secret就有可能猜測(cè)出來，那么僅適用pre-master secret作為密鑰就不合適了，因此必須引入新的隨機(jī)因素，那么客戶端隨機(jī)數(shù)和服務(wù)器隨機(jī)數(shù)加上pre-master secret三個(gè)隨機(jī)數(shù)一同生成的密鑰就不容易被猜出了，一個(gè)偽隨機(jī)數(shù)可能完全不隨機(jī)，可是三個(gè)偽隨機(jī)數(shù)就十分接近隨機(jī)了。
意思是告知對(duì)方，采用協(xié)商后的通信密鑰進(jìn)行加密通信，之后 Encrypted Handshake Message 是發(fā)送的第一個(gè)加密數(shù)據(jù)。內(nèi)容就是把當(dāng)前（準(zhǔn)備發(fā)送Encrypted Handshake Message）前，自己收到的數(shù)據(jù)和發(fā)送的數(shù)據(jù)進(jìn)行一次簡(jiǎn)單運(yùn)算 (hash+加密)，在解密握手信息的時(shí)候，需要雙方密鑰一致，并且接收方也需要模擬計(jì)算握手信息，校驗(yàn)整個(gè)通信數(shù)據(jù)沒有被篡改，
絕對(duì)安全是一個(gè)相對(duì)說法，上面的 HTTPs 的機(jī)制是單項(xiàng)認(rèn)證，也就是保證客戶端只能訪問正確的服務(wù)器（通過證書保證）但是無法保證服務(wù)器只能被正確的客戶端訪問，要做到這一點(diǎn)需要增加雙項(xiàng)認(rèn)證，也就是客戶端也需要提供自己的證書?？蛻舳诵ｒ?yàn)服務(wù)端證書，服務(wù)端也校驗(yàn)客戶端證書，這在金融行業(yè)等會(huì)引入，例如網(wǎng)銀的USB密鑰。相對(duì)安全性會(huì)高很多。
是的，HTTPs 的主要功能就是這個(gè)，但是需要嚴(yán)格管理 CA 證書，安全問題是一步錯(cuò)、步步錯(cuò)。
可以，每一個(gè)通信的 Socket 都會(huì)協(xié)商產(chǎn)生隨機(jī)數(shù)，除非可以完全復(fù)制客戶端的 Socket 否則無法進(jìn)行重放攻擊。如果是重復(fù)提交，需要在系統(tǒng)端進(jìn)行冪等保證。
soursce:https://fzsens.github.io/web/2015/03/07/brief-http/*請(qǐng)認(rèn)真填寫需求信息，我們會(huì)在24小時(shí)內(nèi)與您取得聯(lián)系。
