序言

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

• Http連接方式
• 請求報文
• 響應報文
• 請求響應體類型
• Cookie
• 緩存體系
• 版本差異
  這幾個點來講解Http，不當之處，歡迎各位同學評論指正，共同進步。

Http

Http超文本傳輸協議（英文：HyperText Transfer Protocol，縮寫：HTTP）是互聯網上應用最為廣泛的一種網絡協議。設計HTTP最初的目的是為了提供一種發布和接收HTML頁面的方法。通過HTTP或者HTTPS協議請求的資源由統一資源標識符（Uniform Resource Identifiers，URI）來標識。

連接類型

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

• 持久連接
  在一個TCP連接上進行數據的傳輸
• 非持久連接
  每一次請求，都建立一個TCP連接

比較：

• 持久連接：
  • 優點：無需每次請求重新建立TCP連接，節省訪問時間，同時減輕流量消耗，降低網絡負載。
  • 缺點：持久連接需要服務器對每一個連接的用戶維護一段內存來進行相應的讀寫操作，因此當用戶量較大的時候，服務器的開銷也比較大。
• 非持久連接：
  • 優點：服務器無需保存維護大量Client連接的狀態和內存，服務器開銷較小。
  • 缺點: 每次數據請求，發送，都需要建立TCP連接，相比持久連接增加了兩個RTT，同時增加了網絡的負載。

對于該采取何種請求類型，并沒有統一的標準，需要根據我們自身的實際業務需求和場景，動態靈活的調整，選擇。

Http報文格式

Http請求報文

Http請求報文格式

• 請求行
  • 請求方法字段（Get,Post,Head,Put,Delete）
  • URL
  • Http版本號
• 首部行
• 請求數據
  各類請求方法
• Get：用來獲取服務器上指定內容
• Post：向服務器提交數據
• Head：類似于Get方法，類似于get方法，但是服務器沒有實體響應，用來給開發者進行調試跟蹤
• Put：上傳數據至服務器
• Delete：用戶用來刪除服務器中數據

首部行
Http頭部列表具體可見此列表內容。此處列舉幾個常見類型。
當我們的請求方法為Get時，我們的請求主體內是為空的，但是當我們為Post的時候，需要我們提供部分數據.

請求體

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

application/x-www-form-urlencoded

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

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；其次，提交的數據按照 key1=val1&key2=val2 的方式進行編碼，key 和 val 都進行了 URL 轉碼。大部分服務端語言都對這種方式有很好的支持。例如 PHP 中，$_POST['title'] 可以獲取到 title 的值，$_POST['sub'] 可以得到 sub 數組。
很多時候，我們用 Ajax 提交數據時，也是使用這種方式。例如 JQuery 和 QWrap 的 Ajax，Content-Type 默認值都是「application/x-www-form-urlencoded;charset=utf-8」。

multipart/form-data

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

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--

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

application/json

application/json 這個 Content-Type 作為響應頭大家肯定不陌生。實際上，現在越來越多的人把它作為請求頭，用來告訴服務端消息主體是序列化后的 JSON 字符串。由于 JSON 規范的流行，除了低版本 IE 之外的各大瀏覽器都原生支持 JSON.stringify，服務端語言也都有處理 JSON 的函數，使用 JSON 不會遇上什么麻煩。
JSON 格式支持比鍵值對復雜得多的結構化數據，這一點也很有用。記得我幾年前做一個項目時，需要提交的數據層次非常深，我就是把數據 JSON 序列化之后來提交的。不過當時我是把 JSON 字符串作為 val，仍然放在鍵值對里，以 x-www-form-urlencoded 方式提交。
Google 的 AngularJS 中的 Ajax 功能，默認就是提交 JSON 字符串。例如下面這段代碼：

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

最終發送的請求是：

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

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

text/xml

XML-RPC（XML Remote Procedure Call）。它是一種使用 HTTP 作為傳輸協議，XML 作為編碼方式的遠程調用規范。典型的 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響應報文

Http響應報文

Http響應報文格式

• 狀態行
  • 版本
  • 狀態碼
  • 狀態信息
• 首部行
• 響應實體

狀態碼

響應報文的首部行，見上文

Cookie

由于Http是無狀態協議，因此為了提升客戶端和服務器的交互效率，采用了Cookie來進行記錄客戶端和服務器之間的交互。具體的實施策略就是在首次訪問服務器時，在相應報文字段中set_cookie中返回服務器針對該客戶端生成的cookie，然后將該值記錄在服務器數據庫中，之后，客戶端收到響應之后，將該值記錄在本地文件中，之后，客戶端再次訪問網絡的時候，就會將該字段攜帶，發送到服務器。

Http緩存

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

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

Http緩存結構

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

Http版本差異

Http1.1和Http1.0的區別

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

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

• 帶寬優化，增加Content-rang字段，實現斷點續傳。

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

• 消息傳遞 HTTP消息中可以包含任意長度的實體，通常它們使用Content-Length來給出消息結束標志。但是，對于很多動態產生的響應，只能通過緩沖完整的消息來判斷消息的大小，但這樣做會加大延遲。如果不使用長連接，還可以通過連接關閉的信號來判定一個消息的結束。HTTP/1.1中發送方將消息分割成若干個任意大小的數據塊，每個數據塊在發送時都會附上塊的長度，最后用一個零長度的塊作為消息結束的標志。這種方法允許發送方只緩沖消息的一個片段，避免緩沖整個消息帶來的過載。

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

• 錯誤提示 HTTP/1.0中只定義了16個狀態響應碼，對錯誤或警告的提示不夠具體。HTTP/1.1引入了一個Warning頭域，增加對錯誤或警告信息的描述。

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

Http2和Http1.1的區別

Http2是基于SPDY協議制定的協議，大幅度的提升了 web 性能，在與 HTTP/1.1 完全語義兼容的基礎上，進一步減少了網絡延遲。SPDY 是 Google 開發的基于傳輸控制協議 (TCP) 的應用層協議 ，開發組正在推動 SPDY 成為正式標準（現為互聯網草案）。SPDY 協議旨在通過壓縮、多路復用和優先級來縮短網頁的加載時間和提高安全性。
相比于Http1.1，Http2有了以下幾點改進和提升。

• HTTP/2采用二進制格式而非文本格式，頭部和內容實體封裝成幀。

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

• 使用報頭壓縮，HTTP/2降低了開銷HEAD 在傳輸的時候，通過Haffman演算法壓縮 HEAD來增加傳輸速度。

• HTTP/2讓服務器可以將響應主動“推送”到客戶端緩存中。

FTP區別

FTP和HTTP都是一種文件傳輸協議，而且運輸層使用的都是TCP協議，不同的是，FTP的文件傳輸是帶外傳輸，FTP在傳送文件或者獲取文件的時候，首先需要在創建一個TCP連接用來進行控制信息的傳輸，當有文件需要傳輸的時候，會再建立起一條TCP連接，進行數據的傳輸。數據傳輸完畢，連接將會斷掉，再次有數據傳輸的請求，將會再次有TCP的連接建立起來。FTP占用的端口號是21號。

參考文章

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