序言

最近在做博客的遷移二鳄，從Segmentfault遷移到簡(jiǎn)書赴涵，很早之前在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)在于對(duì)于整體體系的學(xué)習(xí)和把握炒瘸，結(jié)合之前的文章千扔，將對(duì)網(wǎng)絡(luò)有更深層次的理解。本系列會(huì)更偏向于其中的知識(shí)，覆蓋的知識(shí)面會(huì)更廣东臀。對(duì)于整體體系的學(xué)習(xí)可以參考之前系列文章邓厕。作為第一篇，首先要講的是Http，將從

• Http連接方式
• 請(qǐng)求報(bào)文
• 響應(yīng)報(bào)文
• 請(qǐng)求響應(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頁(yè)面的方法筝野。通過HTTP或者HTTPS協(xié)議請(qǐng)求的資源由統(tǒng)一資源標(biāo)識(shí)符（Uniform Resource Identifiers，URI）來標(biāo)識(shí)粤剧。

連接類型

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

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

比較：

• 持久連接：
  • 優(yōu)點(diǎn)：無需每次請(qǐng)求重新建立TCP連接焕议，節(jié)省訪問時(shí)間，同時(shí)減輕流量消耗弧关，降低網(wǎng)絡(luò)負(fù)載盅安。
  • 缺點(diǎn)：持久連接需要服務(wù)器對(duì)每一個(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ù)請(qǐng)求蝙寨，發(fā)送，都需要建立TCP連接嗤瞎，相比持久連接增加了兩個(gè)RTT墙歪，同時(shí)增加了網(wǎng)絡(luò)的負(fù)載。

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

Http報(bào)文格式

Http請(qǐng)求報(bào)文

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

• 請(qǐng)求行
  • 請(qǐng)求方法字段（Get,Post,Head,Put,Delete）
  • URL
  • Http版本號(hào)
• 首部行
• 請(qǐng)求數(shù)據(jù)
  各類請(qǐng)求方法
• 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)我們的請(qǐng)求方法為Get時(shí)，我們的請(qǐng)求主體內(nèi)是為空的必盖，但是當(dāng)我們?yōu)镻ost的時(shí)候拌牲，需要我們提供部分?jǐn)?shù)據(jù).

請(qǐng)求體

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ù)液茎。請(qǐng)求類似于下面這樣（無關(guān)的請(qǐng)求頭在本文中都省略掉了）：

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ù)端語(yǔ)言都對(duì)這種方式有很好的支持。例如 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è)請(qǐng)求示例：

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 很長(zhǎng)很復(fù)雜芽狗。然后 Content-Type 里指明了數(shù)據(jù)是以 multipart/form-data 來編碼，本次請(qǐng)求的 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ì)定義碴萧，請(qǐng)前往 rfc1867 查看乙嘀。
這種方式一般用來上傳文件虎谢，各大服務(wù)端語(yǔ)言對(duì)它也有著良好的支持婴噩。
上面提到的這兩種 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)在越來越多的人把它作為請(qǐng)求頭凭疮，用來告訴服務(wù)端消息主體是序列化后的 JSON 字符串哭尝。由于 JSON 規(guī)范的流行材鹦，除了低版本 IE 之外的各大瀏覽器都原生支持 JSON.stringify桶唐，服務(wù)端語(yǔ)言也都有處理 JSON 的函數(shù)尤泽，使用 JSON 不會(huì)遇上什么麻煩熊咽。
JSON 格式支持比鍵值對(duì)復(fù)雜得多的結(jié)構(gòu)化數(shù)據(jù)横殴，這一點(diǎn)也很有用衫仑。記得我?guī)啄昵白鲆粋€(gè)項(xiàng)目時(shí)文狱，需要提交的數(shù)據(jù)層次非常深瞄崇，我就是把數(shù)據(jù) JSON 序列化之后來提交的杠袱。不過當(dāng)時(shí)我是把 JSON 字符串作為 val楣富，仍然放在鍵值對(duì)里纹蝴，以 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ā)送的請(qǐng)求是：

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ù)端語(yǔ)言還沒有支持這種方式次询，例如 php 就無法通過 $_POST 對(duì)象從上面的請(qǐng)求中獲得內(nèi)容屯吊。這時(shí)候盒卸，需要自己動(dòng)手處理下：在請(qǐng)求頭中 Content-Type 為 application/json 時(shí)蔽介，從 php://input 里獲得原始輸入流虹蓄，再 json_decode 成對(duì)象武花。一些 php 框架已經(jīng)開始這么做了体箕。

text/xml

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

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ù)器針對(duì)該客戶端生成的cookie祠汇，然后將該值記錄在服務(wù)器數(shù)據(jù)庫(kù)中可很，之后根穷，客戶端收到響應(yīng)之后屿良，將該值記錄在本地文件中尘惧，之后啥么，客戶端再次訪問網(wǎng)絡(luò)的時(shí)候悬荣，就會(huì)將該字段攜帶疙剑，發(fā)送到服務(wù)器嚼蚀。

Http緩存

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

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

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

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

Http版本差異

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

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

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

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

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

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

• Host頭域，在HTTP1.0中認(rèn)為每臺(tái)服務(wù)器都綁定一個(gè)唯一的IP地址抵皱，因此绞愚，請(qǐng)求消息中的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)碼畔派，對(duì)錯(cuò)誤或警告的提示不夠具體。HTTP/1.1引入了一個(gè)Warning頭域润绵，增加對(duì)錯(cuò)誤或警告信息的描述线椰。

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

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

Http2是基于SPDY協(xié)議制定的協(xié)議笨蚁，大幅度的提升了 web 性能，在與 HTTP/1.1 完全語(yǔ)義兼容的基礎(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)頁(yè)的加載時(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è)請(qǐng)求的效率比較高, 多了就會(huì)變慢。 HTTP/1.1 試過用流水線(pipelining)來解決這個(gè)問題, 但是效果并不理想(數(shù)據(jù)量較大或者速度較慢的響應(yīng), 會(huì)阻礙排在他后面的請(qǐng)求)宙项，而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ù)恼?qǐng)求，將會(huì)再次有TCP的連接建立起來我衬。FTP占用的端口號(hào)是21號(hào)叹放。

參考文章

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