序言

最近在做博客的遷移，從Segmentfault遷移到簡書，很早之前在Segmentfault出了一個(gè)系列的《當(dāng)我們談網(wǎng)絡(luò)，談些什么》專題，得到了比較好多反響和認(rèn)可。準(zhǔn)備更仔細(xì)深入的再來做一起，更深入，更全面的來講解網(wǎng)絡(luò)知識(shí)。涉及Http，DNS,TCP，UDP，網(wǎng)絡(luò)層，鏈路層，無線網(wǎng)絡(luò)，移動(dòng)網(wǎng)絡(luò)，網(wǎng)絡(luò)安全加密等。之前的一系列側(cè)重點(diǎn)在于對于整體體系的學(xué)習(xí)和把握，結(jié)合之前的文章，將對網(wǎng)絡(luò)有更深層次的理解。本系列會(huì)更偏向于其中的知識(shí)，覆蓋的知識(shí)面會(huì)更廣。對于整體體系的學(xué)習(xí)可以參考之前系列文章。作為第一篇，首先要講的是Http，將從

• Http連接方式
• 請求報(bào)文
• 響應(yīng)報(bào)文
• 請求響應(yīng)體類型
• Cookie
• 緩存體系
• 版本差異
  這幾個(gè)點(diǎn)來講解Http，不當(dāng)之處，歡迎各位同學(xué)評(píng)論指正，共同進(jìn)步。

Http

Http超文本傳輸協(xié)議（英文：HyperText Transfer Protocol，縮寫：HTTP）是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議。設(shè)計(jì)HTTP最初的目的是為了提供一種發(fā)布和接收HTML頁面的方法。通過HTTP或者HTTPS協(xié)議請求的資源由統(tǒng)一資源標(biāo)識(shí)符（Uniform Resource Identifiers，URI）來標(biāo)識(shí)。

連接類型

Http傳輸層采用的TCP協(xié)議，其具備兩種兩節(jié)方式。

• 持久連接
  在一個(gè)TCP連接上進(jìn)行數(shù)據(jù)的傳輸
• 非持久連接
  每一次請求，都建立一個(gè)TCP連接

比較：

• 持久連接：
  • 優(yōu)點(diǎn)：無需每次請求重新建立TCP連接，節(jié)省訪問時(shí)間，同時(shí)減輕流量消耗，降低網(wǎng)絡(luò)負(fù)載。
  • 缺點(diǎn)：持久連接需要服務(wù)器對每一個(gè)連接的用戶維護(hù)一段內(nèi)存來進(jìn)行相應(yīng)的讀寫操作，因此當(dāng)用戶量較大的時(shí)候，服務(wù)器的開銷也比較大。
• 非持久連接：
  • 優(yōu)點(diǎn)：服務(wù)器無需保存維護(hù)大量Client連接的狀態(tài)和內(nèi)存，服務(wù)器開銷較小。
  • 缺點(diǎn): 每次數(shù)據(jù)請求，發(fā)送，都需要建立TCP連接，相比持久連接增加了兩個(gè)RTT，同時(shí)增加了網(wǎng)絡(luò)的負(fù)載。

對于該采取何種請求類型，并沒有統(tǒng)一的標(biāo)準(zhǔn)，需要根據(jù)我們自身的實(shí)際業(yè)務(wù)需求和場景，動(dòng)態(tài)靈活的調(diào)整，選擇。

Http報(bào)文格式

Http請求報(bào)文

Http請求報(bào)文格式

• 請求行
  • 請求方法字段（Get,Post,Head,Put,Delete）
  • URL
  • Http版本號(hào)
• 首部行
• 請求數(shù)據(jù)
  各類請求方法
• Get：用來獲取服務(wù)器上指定內(nèi)容
• Post：向服務(wù)器提交數(shù)據(jù)
• Head：類似于Get方法，類似于get方法，但是服務(wù)器沒有實(shí)體響應(yīng)，用來給開發(fā)者進(jìn)行調(diào)試跟蹤
• Put：上傳數(shù)據(jù)至服務(wù)器
• Delete：用戶用來刪除服務(wù)器中數(shù)據(jù)

首部行
Http頭部列表具體可見此列表內(nèi)容。此處列舉幾個(gè)常見類型。
當(dāng)我們的請求方法為Get時(shí)，我們的請求主體內(nèi)是為空的，但是當(dāng)我們?yōu)镻ost的時(shí)候，需要我們提供部分?jǐn)?shù)據(jù).

請求體

POST 提交數(shù)據(jù)方案，包含了 Content-Type 和消息主體編碼方式兩部分。常見的Content-type有如下幾種類型。

application/x-www-form-urlencoded

這應(yīng)該是最常見的 POST 提交數(shù)據(jù)的方式了。瀏覽器的原生 <form> 表單，如果不設(shè)置 enctype 屬性，那么最終就會(huì)以 application/x-www-form-urlencoded 方式提交數(shù)據(jù)。請求類似于下面這樣（無關(guān)的請求頭在本文中都省略掉了）：

POST http://www.example.com HTTP/1.1
Content-Type: application/x-www-form-urlencoded;charset=utf-8
title=test&sub%5B%5D=1&sub%5B%5D=2&sub%5B%5D=3

首先，Content-Type 被指定為 application/x-www-form-urlencoded；其次，提交的數(shù)據(jù)按照 key1=val1&key2=val2 的方式進(jìn)行編碼，key 和 val 都進(jìn)行了 URL 轉(zhuǎn)碼。大部分服務(wù)端語言都對這種方式有很好的支持。例如 PHP 中，$_POST['title'] 可以獲取到 title 的值，$_POST['sub'] 可以得到 sub 數(shù)組。
很多時(shí)候，我們用 Ajax 提交數(shù)據(jù)時(shí)，也是使用這種方式。例如 JQuery 和 QWrap 的 Ajax，Content-Type 默認(rèn)值都是「application/x-www-form-urlencoded;charset=utf-8」。

multipart/form-data

這又是一個(gè)常見的 POST 數(shù)據(jù)提交的方式。我們使用表單上傳文件時(shí)，必須讓 <form> 表單的 enctype 等于 multipart/form-data。直接來看一個(gè)請求示例：

POST http://www.example.com HTTP/1.1
Content-Type:multipart/form-data; boundary=----WebKitFormBoundaryrGKCBY7qhFd3TrwA

------WebKitFormBoundaryrGKCBY7qhFd3TrwA
Content-Disposition: form-data; name="text"

title
------WebKitFormBoundaryrGKCBY7qhFd3TrwA
Content-Disposition: form-data; name="file"; filename="chrome.png"
Content-Type: image/png

PNG ... content of chrome.png ...
------WebKitFormBoundaryrGKCBY7qhFd3TrwA--

這個(gè)例子稍微復(fù)雜點(diǎn)。首先生成了一個(gè) boundary 用于分割不同的字段，為了避免與正文內(nèi)容重復(fù)，boundary 很長很復(fù)雜。然后 Content-Type 里指明了數(shù)據(jù)是以 multipart/form-data 來編碼，本次請求的 boundary 是什么內(nèi)容。消息主體里按照字段個(gè)數(shù)又分為多個(gè)結(jié)構(gòu)類似的部分，每部分都是以 --boundary 開始，緊接著是內(nèi)容描述信息，然后是回車，最后是字段具體內(nèi)容（文本或二進(jìn)制）。如果傳輸?shù)氖俏募?，還要包含文件名和文件類型信息。消息主體最后以 --boundary-- 標(biāo)示結(jié)束。關(guān)于 multipart/form-data 的詳細(xì)定義，請前往 rfc1867 查看。
這種方式一般用來上傳文件，各大服務(wù)端語言對它也有著良好的支持。
上面提到的這兩種 POST 數(shù)據(jù)的方式，都是瀏覽器原生支持的，而且現(xiàn)階段標(biāo)準(zhǔn)中原生 <form> 表單也只支持這兩種方式（通過 <form> 元素的 enctype 屬性指定，默認(rèn)為 application/x-www-form-urlencoded。其實(shí) enctype 還支持 text/plain，不過用得非常少）。
隨著越來越多的 Web 站點(diǎn)，尤其是 WebApp，全部使用 Ajax 進(jìn)行數(shù)據(jù)交互之后，我們完全可以定義新的數(shù)據(jù)提交方式，給開發(fā)帶來更多便利。

application/json

application/json 這個(gè) Content-Type 作為響應(yīng)頭大家肯定不陌生。實(shí)際上，現(xiàn)在越來越多的人把它作為請求頭，用來告訴服務(wù)端消息主體是序列化后的 JSON 字符串。由于 JSON 規(guī)范的流行，除了低版本 IE 之外的各大瀏覽器都原生支持 JSON.stringify，服務(wù)端語言也都有處理 JSON 的函數(shù)，使用 JSON 不會(huì)遇上什么麻煩。
JSON 格式支持比鍵值對復(fù)雜得多的結(jié)構(gòu)化數(shù)據(jù)，這一點(diǎn)也很有用。記得我?guī)啄昵白鲆粋€(gè)項(xiàng)目時(shí)，需要提交的數(shù)據(jù)層次非常深，我就是把數(shù)據(jù) JSON 序列化之后來提交的。不過當(dāng)時(shí)我是把 JSON 字符串作為 val，仍然放在鍵值對里，以 x-www-form-urlencoded 方式提交。
Google 的 AngularJS 中的 Ajax 功能，默認(rèn)就是提交 JSON 字符串。例如下面這段代碼：

var data = {'title':'test', 'sub' : [1,2,3]};
$http.post(url, data).success(function(result) {
    ...
});

最終發(fā)送的請求是：

POST http://www.example.com HTTP/1.1 
Content-Type: application/json;charset=utf-8
{"title":"test","sub":[1,2,3]}

這種方案，可以方便的提交復(fù)雜的結(jié)構(gòu)化數(shù)據(jù)，特別適合 RESTful 的接口。各大抓包工具如 Chrome 自帶的開發(fā)者工具、Firebug、Fiddler，都會(huì)以樹形結(jié)構(gòu)展示 JSON 數(shù)據(jù)，非常友好。但也有些服務(wù)端語言還沒有支持這種方式，例如 php 就無法通過 $_POST 對象從上面的請求中獲得內(nèi)容。這時(shí)候，需要自己動(dòng)手處理下：在請求頭中 Content-Type 為 application/json 時(shí)，從 php://input 里獲得原始輸入流，再 json_decode 成對象。一些 php 框架已經(jīng)開始這么做了。

text/xml

XML-RPC（XML Remote Procedure Call）。它是一種使用 HTTP 作為傳輸協(xié)議，XML 作為編碼方式的遠(yuǎn)程調(diào)用規(guī)范。典型的 XML-RPC 請求是這樣的：

POST http://www.example.com HTTP/1.1 
Content-Type: text/xml

<?xml version="1.0"?>
<methodCall>
    <methodName>examples.getStateName</methodName>
    <params>
        <param>
            <value><i4>41</i4></value>
        </param>
    </params>
</methodCall>

Http響應(yīng)報(bào)文

Http響應(yīng)報(bào)文

Http響應(yīng)報(bào)文格式

• 狀態(tài)行
  • 版本
  • 狀態(tài)碼
  • 狀態(tài)信息
• 首部行
• 響應(yīng)實(shí)體

狀態(tài)碼

響應(yīng)報(bào)文的首部行，見上文

Cookie

由于Http是無狀態(tài)協(xié)議，因此為了提升客戶端和服務(wù)器的交互效率，采用了Cookie來進(jìn)行記錄客戶端和服務(wù)器之間的交互。具體的實(shí)施策略就是在首次訪問服務(wù)器時(shí)，在相應(yīng)報(bào)文字段中set_cookie中返回服務(wù)器針對該客戶端生成的cookie，然后將該值記錄在服務(wù)器數(shù)據(jù)庫中，之后，客戶端收到響應(yīng)之后，將該值記錄在本地文件中，之后，客戶端再次訪問網(wǎng)絡(luò)的時(shí)候，就會(huì)將該字段攜帶，發(fā)送到服務(wù)器。

Http緩存

通過HTTP緩存，可以有效減輕服務(wù)器壓力，同時(shí)可以提升訪問速率，減少對于寬帶的浪費(fèi)。
http緩存是基于HTTP的瀏覽器文件級(jí)緩存機(jī)制。即針對文件的重復(fù)請求情況下，瀏覽器可以根據(jù)協(xié)議頭判斷從服務(wù)器端請求文件還是從本地讀取文件，chrome控制臺(tái)下的Frames即展示的是瀏覽器的http文件級(jí)緩存。以下是瀏覽器緩存的整個(gè)機(jī)制流程。主要是針對重復(fù)的http請求，在有緩 存的情況下判斷過程主要分3步：

1. 判斷expires，如果未過期，直接讀取http緩存文件，不發(fā)http請求，否則進(jìn)入下一步。
2. 判斷是否含有etag，有則帶上if-none-match發(fā)送請求，未修改返回304，修改返回200，否則進(jìn)入下一步。
3. 判斷是否含有l(wèi)ast-modified，有則帶上if-modified-since發(fā)送請求，無效返回200，有效返回304，否則直接向服務(wù)器請求。

Http緩存結(jié)構(gòu)

如果通過etag和last-modified判斷，即使返回304有至少有一次http請求，只不過返回的是304的返回內(nèi)容，而不是文件內(nèi)容。所以合理設(shè)計(jì)實(shí)現(xiàn)expires參數(shù)可以減少較多的瀏覽器請求。

Http版本差異

Http1.1和Http1.0的區(qū)別

• 可擴(kuò)展性增加了幾個(gè)頭部字段，HTTP/1.1增加了OPTIONS方法，它允許客戶端獲取一個(gè)服務(wù)器支持的方法列表。為了與未來的協(xié)議規(guī)范兼容，HTTP/1.1在請求消息中包含了Upgrade頭域，通過該頭域，客戶端可以讓服務(wù)器知道它能夠支持的其它備用通信協(xié)議，服務(wù)器可以據(jù)此進(jìn)行協(xié)議切換，使用備用協(xié)議與客戶端進(jìn)行通信。

• 緩存，增加Etag等字段提升使得Cach機(jī)制更加的靈活。

• 帶寬優(yōu)化，增加Content-rang字段，實(shí)現(xiàn)斷點(diǎn)續(xù)傳。

• 長連接，HTTP 1.1支持長連接（PersistentConnection）和請求的流水線（Pipelining）處理，在一個(gè)TCP連接上可以傳送多個(gè)HTTP請求和響應(yīng)，減少了建立和關(guān)閉連接的消耗和延遲。

• 消息傳遞 HTTP消息中可以包含任意長度的實(shí)體，通常它們使用Content-Length來給出消息結(jié)束標(biāo)志。但是，對于很多動(dòng)態(tài)產(chǎn)生的響應(yīng)，只能通過緩沖完整的消息來判斷消息的大小，但這樣做會(huì)加大延遲。如果不使用長連接，還可以通過連接關(guān)閉的信號(hào)來判定一個(gè)消息的結(jié)束。HTTP/1.1中發(fā)送方將消息分割成若干個(gè)任意大小的數(shù)據(jù)塊，每個(gè)數(shù)據(jù)塊在發(fā)送時(shí)都會(huì)附上塊的長度，最后用一個(gè)零長度的塊作為消息結(jié)束的標(biāo)志。這種方法允許發(fā)送方只緩沖消息的一個(gè)片段，避免緩沖整個(gè)消息帶來的過載。

• Host頭域，在HTTP1.0中認(rèn)為每臺(tái)服務(wù)器都綁定一個(gè)唯一的IP地址，因此，請求消息中的URL并沒有傳遞主機(jī)名（hostname）。但隨著虛擬主機(jī)技術(shù)的發(fā)展，在一臺(tái)物理服務(wù)器上可以存在多個(gè)虛擬主機(jī)（Multi-homed Web Servers），并且它們共享一個(gè)IP地址。

• 錯(cuò)誤提示 HTTP/1.0中只定義了16個(gè)狀態(tài)響應(yīng)碼，對錯(cuò)誤或警告的提示不夠具體。HTTP/1.1引入了一個(gè)Warning頭域，增加對錯(cuò)誤或警告信息的描述。

• 更友好精細(xì)化的內(nèi)容協(xié)商。HTTP引入了一個(gè)品質(zhì)因子（quality values）的概念來表示不同版本的可用性，它的取值從0.0到1.0。例如一個(gè)母語是英語的人也能講法語、甚至還學(xué)了點(diǎn)丹麥語，那么他的瀏覽器可用作如下配置：Accept-Language: en, fr;q=0.5, da;q=0.1。這時(shí)，服務(wù)器會(huì)優(yōu)先選取品質(zhì)因子高的值對應(yīng)的資源版本作為響應(yīng)。

Http2和Http1.1的區(qū)別

Http2是基于SPDY協(xié)議制定的協(xié)議，大幅度的提升了 web 性能，在與 HTTP/1.1 完全語義兼容的基礎(chǔ)上，進(jìn)一步減少了網(wǎng)絡(luò)延遲。SPDY 是 Google 開發(fā)的基于傳輸控制協(xié)議 (TCP) 的應(yīng)用層協(xié)議 ，開發(fā)組正在推動(dòng) SPDY 成為正式標(biāo)準(zhǔn)（現(xiàn)為互聯(lián)網(wǎng)草案）。SPDY 協(xié)議旨在通過壓縮、多路復(fù)用和優(yōu)先級(jí)來縮短網(wǎng)頁的加載時(shí)間和提高安全性。
相比于Http1.1，Http2有了以下幾點(diǎn)改進(jìn)和提升。

• HTTP/2采用二進(jìn)制格式而非文本格式，頭部和內(nèi)容實(shí)體封裝成幀。

• HTTP/2是完全多路復(fù)用的，而非有序并阻塞的——只需一個(gè)連接即可實(shí)現(xiàn)并行（指一個(gè)連接(connection)一次只提交一個(gè)請求的效率比較高, 多了就會(huì)變慢。 HTTP/1.1 試過用流水線(pipelining)來解決這個(gè)問題, 但是效果并不理想(數(shù)據(jù)量較大或者速度較慢的響應(yīng), 會(huì)阻礙排在他后面的請求)，而Http2通過在頭部添加了StreamID字段可有效的解決這個(gè)問題。

• 使用報(bào)頭壓縮，HTTP/2降低了開銷HEAD 在傳輸?shù)臅r(shí)候，通過Haffman演算法壓縮 HEAD來增加傳輸速度。

• HTTP/2讓服務(wù)器可以將響應(yīng)主動(dòng)“推送”到客戶端緩存中。

FTP區(qū)別

FTP和HTTP都是一種文件傳輸協(xié)議，而且運(yùn)輸層使用的都是TCP協(xié)議，不同的是，F(xiàn)TP的文件傳輸是帶外傳輸，F(xiàn)TP在傳送文件或者獲取文件的時(shí)候，首先需要在創(chuàng)建一個(gè)TCP連接用來進(jìn)行控制信息的傳輸，當(dāng)有文件需要傳輸?shù)臅r(shí)候，會(huì)再建立起一條TCP連接，進(jìn)行數(shù)據(jù)的傳輸。數(shù)據(jù)傳輸完畢，連接將會(huì)斷掉，再次有數(shù)據(jù)傳輸?shù)恼埱?，將?huì)再次有TCP的連接建立起來。FTP占用的端口號(hào)是21號(hào)。

參考文章

九種瀏覽器緩存方法知多少
Http狀態(tài)碼
HTTP/1.1與HTTP/1.0的區(qū)別
HTTP/2 新特性淺析