本文原作者阮一峰，作者博客：ruanyifeng.com。

1、引言

HTTP 協(xié)議是最重要的互聯(lián)網(wǎng)基礎(chǔ)協(xié)議之一，它從最初的僅為瀏覽網(wǎng)頁的目的進(jìn)化到現(xiàn)在，已經(jīng)是短連接通信的事實(shí)工業(yè)標(biāo)準(zhǔn)，最新版本 HTTP/2 更是讓它再次成為技術(shù)熱點(diǎn)。

作為即時(shí)通訊開發(fā)者來說，深刻理解HTTP協(xié)議有助于在現(xiàn)今復(fù)雜移動(dòng)網(wǎng)絡(luò)環(huán)境下的優(yōu)化和最佳實(shí)踐的開展，本文將通俗易懂的地介紹 HTTP 協(xié)議的歷史演變和設(shè)計(jì)思路。

學(xué)習(xí)交流：

- 即時(shí)通訊開發(fā)交流3群：185926912[推薦]

- 移動(dòng)端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動(dòng)端IM》

（本文同步發(fā)布于：http://www.52im.net/thread-1709-1-1.html）

2、相關(guān)文章

《網(wǎng)絡(luò)編程懶人入門(七)：深入淺出，全面理解HTTP協(xié)議》

《現(xiàn)代移動(dòng)端網(wǎng)絡(luò)短連接的優(yōu)化手段總結(jié)：請(qǐng)求速度、弱網(wǎng)適應(yīng)、安全保障》

《IM開發(fā)基礎(chǔ)知識(shí)補(bǔ)課(四)：正確理解HTTP短連接中的Cookie、Session和Token》

《IM開發(fā)基礎(chǔ)知識(shí)補(bǔ)課：正確理解前置HTTP SSO單點(diǎn)登陸接口的原理》

《從HTTP到MQTT：一個(gè)基于位置服務(wù)的APP數(shù)據(jù)通信實(shí)踐概述》

《技術(shù)掃盲：新一代基于UDP的低延時(shí)網(wǎng)絡(luò)傳輸層協(xié)議——QUIC詳解》

《讓互聯(lián)網(wǎng)更快：新一代QUIC協(xié)議在騰訊的技術(shù)實(shí)踐分享》

3、HTTP/0.9

HTTP 是基于 TCP/IP 協(xié)議的應(yīng)用層協(xié)議（詳見《網(wǎng)絡(luò)編程懶人入門(一)：快速理解網(wǎng)絡(luò)通信協(xié)議（上篇）》、《網(wǎng)絡(luò)編程懶人入門(二)：快速理解網(wǎng)絡(luò)通信協(xié)議（下篇）》）。它不涉及數(shù)據(jù)包（packet）傳輸，主要規(guī)定了客戶端和服務(wù)器之間的通信格式，默認(rèn)使用80端口。

最早版本是1991年發(fā)布的0.9版。該版本極其簡(jiǎn)單，只有一個(gè)命令GET：

GET /index.html

上面命令表示，TCP 連接（connection）建立后，客戶端向服務(wù)器請(qǐng)求（request）網(wǎng)頁index.html。

協(xié)議規(guī)定，服務(wù)器只能回應(yīng)HTML格式的字符串，不能回應(yīng)別的格式：

Hello World

服務(wù)器發(fā)送完畢，就關(guān)閉TCP連接。

4、HTTP/1.0

4.1 簡(jiǎn)介

1996年5月，HTTP/1.0 版本發(fā)布，內(nèi)容大大增加（詳見 RFC1945）。

首先，任何格式的內(nèi)容都可以發(fā)送。這使得互聯(lián)網(wǎng)不僅可以傳輸文字，還能傳輸圖像、視頻、二進(jìn)制文件。這為互聯(lián)網(wǎng)的大發(fā)展奠定了基礎(chǔ)。

其次，除了GET命令，還引入了POST命令和HEAD命令，豐富了瀏覽器與服務(wù)器的互動(dòng)手段。

再次，HTTP請(qǐng)求和回應(yīng)的格式也變了。除了數(shù)據(jù)部分，每次通信都必須包括頭信息（HTTP header），用來描述一些元數(shù)據(jù)。

其他的新增功能還包括狀態(tài)碼（status code）、多字符集支持、多部分發(fā)送（multi-part type）、權(quán)限（authorization）、緩存（cache）、內(nèi)容編碼（content encoding）等。

4.2 請(qǐng)求格式

下面是一個(gè)1.0版的HTTP請(qǐng)求的例子：

GET / HTTP/1.0

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5)

Accept: */*

可以看到，這個(gè)格式與0.9版有很大變化。

第一行是請(qǐng)求命令，必須在尾部添加協(xié)議版本（HTTP/1.0）。后面就是多行頭信息，描述客戶端的情況。

4.3 響應(yīng)格式（Response）

服務(wù)器的回應(yīng)如下：

HTTP/1.0 200 OK 

Content-Type: text/plain

Content-Length: 137582

Expires: Thu, 05 Dec 1997 16:00:00 GMT

Last-Modified: Wed, 5 August 1996 15:55:28 GMT

Server: Apache 0.84

Hello World

回應(yīng)的格式是"頭信息 + 一個(gè)空行（\r\n） + 數(shù)據(jù)"。其中，第一行是"協(xié)議版本 + 狀態(tài)碼（status code） + 狀態(tài)描述"。（詳見《網(wǎng)絡(luò)編程懶人入門(七)：深入淺出，全面理解HTTP協(xié)議》）

4.4 Content-Type 字段

關(guān)于字符的編碼，1.0版規(guī)定，頭信息必須是 ASCII 碼，后面的數(shù)據(jù)可以是任何格式。因此，服務(wù)器回應(yīng)的時(shí)候，必須告訴客戶端，數(shù)據(jù)是什么格式，這就是Content-Type字段的作用。

下面是一些常見的Content-Type字段的值：

text/plain

text/html

text/css

image/jpeg

image/png

image/svg+xml

audio/mp4

video/mp4

application/javascript

application/pdf

application/zip

application/atom+xml

這些數(shù)據(jù)類型總稱為MIME type，每個(gè)值包括一級(jí)類型和二級(jí)類型，之間用斜杠分隔。

除了預(yù)定義的類型，廠商也可以自定義類型，就像下面這樣：

application/vnd.debian.binary-package

上面的類型表明，發(fā)送的是Debian系統(tǒng)的二進(jìn)制數(shù)據(jù)包。

MIME type還可以在尾部使用分號(hào)，添加參數(shù)：

Content-Type: text/html; charset=utf-8

上面的類型表明，發(fā)送的是網(wǎng)頁，而且編碼是UTF-8。

客戶端請(qǐng)求的時(shí)候，可以使用Accept字段聲明自己可以接受哪些數(shù)據(jù)格式：

Accept: */*

上面代碼中，客戶端聲明自己可以接受任何格式的數(shù)據(jù)。

MIME type不僅用在HTTP協(xié)議，還可以用在其他地方，比如HTML網(wǎng)頁：

4.5 Content-Encoding 字段

由于發(fā)送的數(shù)據(jù)可以是任何格式，因此可以把數(shù)據(jù)壓縮后再發(fā)送。

Content-Encoding字段說明數(shù)據(jù)的壓縮方法：

Content-Encoding: gzip

Content-Encoding: compress

Content-Encoding: deflate

客戶端在請(qǐng)求時(shí)，用Accept-Encoding字段說明自己可以接受哪些壓縮方法：

Accept-Encoding: gzip, deflate

4.6 缺點(diǎn)

HTTP/1.0 版的主要缺點(diǎn)是，每個(gè)TCP連接只能發(fā)送一個(gè)請(qǐng)求。發(fā)送數(shù)據(jù)完畢，連接就關(guān)閉，如果還要請(qǐng)求其他資源，就必須再新建一個(gè)連接。

TCP連接的新建成本很高，因?yàn)樾枰蛻舳撕头?wù)器三次握手，并且開始時(shí)發(fā)送速率較慢（slow start）。所以，HTTP 1.0版本的性能比較差。隨著網(wǎng)頁加載的外部資源越來越多，這個(gè)問題就愈發(fā)突出了。

為了解決這個(gè)問題，有些瀏覽器在請(qǐng)求時(shí)，用了一個(gè)非標(biāo)準(zhǔn)的Connection字段：

Connection: keep-alive

這個(gè)字段要求服務(wù)器不要關(guān)閉TCP連接，以便其他請(qǐng)求復(fù)用。

服務(wù)器同樣回應(yīng)這個(gè)字段：

Connection: keep-alive

一個(gè)可以復(fù)用的TCP連接就建立了，直到客戶端或服務(wù)器主動(dòng)關(guān)閉連接。但是，這不是標(biāo)準(zhǔn)字段，不同實(shí)現(xiàn)的行為可能不一致，因此不是根本的解決辦法。

5、HTTP/1.1

1997年1月，HTTP/1.1 版本發(fā)布，只比 1.0 版本晚了半年。HTTP/1.1進(jìn)一步完善了 HTTP 協(xié)議，一直用到了20年后的今天，直到現(xiàn)在還是最流行的版本。

5.1 持久連接

1.1 版的最大變化，就是引入了持久連接（persistent connection），即TCP連接默認(rèn)不關(guān)閉，可以被多個(gè)請(qǐng)求復(fù)用，不用聲明Connection: keep-alive。

客戶端和服務(wù)器發(fā)現(xiàn)對(duì)方一段時(shí)間沒有活動(dòng)，就可以主動(dòng)關(guān)閉連接。

不過，規(guī)范的做法是，客戶端在最后一個(gè)請(qǐng)求時(shí)，發(fā)送Connection: close，明確要求服務(wù)器關(guān)閉TCP連接：

Connection: close

目前，對(duì)于同一個(gè)域名，大多數(shù)瀏覽器允許同時(shí)建立6個(gè)持久連接。

5.2 管道機(jī)制

1.1 版還引入了管道機(jī)制（pipelining），即在同一個(gè)TCP連接里面，客戶端可以同時(shí)發(fā)送多個(gè)請(qǐng)求。這樣就進(jìn)一步改進(jìn)了HTTP協(xié)議的效率。

舉例來說，客戶端需要請(qǐng)求兩個(gè)資源。以前的做法是，在同一個(gè)TCP連接里面，先發(fā)送A請(qǐng)求，然后等待服務(wù)器做出回應(yīng)，收到后再發(fā)出B請(qǐng)求。管道機(jī)制則是允許瀏覽器同時(shí)發(fā)出A請(qǐng)求和B請(qǐng)求，但是服務(wù)器還是按照順序，先回應(yīng)A請(qǐng)求，完成后再回應(yīng)B請(qǐng)求。

5.3 Content-Length 字段

一個(gè)TCP連接現(xiàn)在可以傳送多個(gè)回應(yīng)，勢(shì)必就要有一種機(jī)制，區(qū)分?jǐn)?shù)據(jù)包是屬于哪一個(gè)回應(yīng)的。

這就是Content-length字段的作用，聲明本次回應(yīng)的數(shù)據(jù)長(zhǎng)度：

Content-Length: 3495

上面代碼告訴瀏覽器，本次回應(yīng)的長(zhǎng)度是3495個(gè)字節(jié)，后面的字節(jié)就屬于下一個(gè)回應(yīng)了。

在1.0版中，Content-Length字段不是必需的，因?yàn)闉g覽器發(fā)現(xiàn)服務(wù)器關(guān)閉了TCP連接，就表明收到的數(shù)據(jù)包已經(jīng)全了。

5.4 分塊傳輸編碼

使用Content-Length字段的前提條件是，服務(wù)器發(fā)送回應(yīng)之前，必須知道回應(yīng)的數(shù)據(jù)長(zhǎng)度。

對(duì)于一些很耗時(shí)的動(dòng)態(tài)操作來說，這意味著，服務(wù)器要等到所有操作完成，才能發(fā)送數(shù)據(jù)，顯然這樣的效率不高。更好的處理方法是，產(chǎn)生一塊數(shù)據(jù)，就發(fā)送一塊，采用"流模式"（stream）取代"緩存模式"（buffer）。

因此，1.1版規(guī)定可以不使用Content-Length字段，而使用"分塊傳輸編碼"（chunked transfer encoding）。

只要請(qǐng)求或回應(yīng)的頭信息有Transfer-Encoding字段，就表明回應(yīng)將由數(shù)量未定的數(shù)據(jù)塊組成：

Transfer-Encoding: chunked

每個(gè)非空的數(shù)據(jù)塊之前，會(huì)有一個(gè)16進(jìn)制的數(shù)值，表示這個(gè)塊的長(zhǎng)度。最后是一個(gè)大小為0的塊，就表示本次回應(yīng)的數(shù)據(jù)發(fā)送完了。

下面是一個(gè)例子：

HTTP/1.1 200 OK

Content-Type: text/plain

Transfer-Encoding: chunked

25

This is the data in the first chunk

1C

and this is the second one

3

con

8

sequence

0

5.5 其他功能

1.1版還新增了許多動(dòng)詞方法：PUT、PATCH、HEAD、 OPTIONS、DELETE。

另外，客戶端請(qǐng)求的頭信息新增了Host字段，用來指定服務(wù)器的域名：

Host: example.com

有了Host字段，就可以將請(qǐng)求發(fā)往同一臺(tái)服務(wù)器上的不同網(wǎng)站，為虛擬主機(jī)的興起打下了基礎(chǔ)。

5.6 缺點(diǎn)

雖然1.1版允許復(fù)用TCP連接，但是同一個(gè)TCP連接里面，所有的數(shù)據(jù)通信是按次序進(jìn)行的。服務(wù)器只有處理完一個(gè)回應(yīng)，才會(huì)進(jìn)行下一個(gè)回應(yīng)。要是前面的回應(yīng)特別慢，后面就會(huì)有許多請(qǐng)求排隊(duì)等著。這稱為"隊(duì)頭堵塞"（Head-of-line blocking）。

為了避免這個(gè)問題，只有兩種方法：一是減少請(qǐng)求數(shù)，二是同時(shí)多開持久連接。這導(dǎo)致了很多的網(wǎng)頁優(yōu)化技巧，比如合并腳本和樣式表、將圖片嵌入CSS代碼、域名分片（domain sharding）等等。如果HTTP協(xié)議設(shè)計(jì)得更好一些，這些額外的工作是可以避免的。

有關(guān)HTTP/1.1的詳細(xì)技術(shù)介紹，詳見《網(wǎng)絡(luò)編程懶人入門(七)：深入淺出，全面理解HTTP協(xié)議》。

6、SPDY 協(xié)議

2009年，谷歌公開了自行研發(fā)的 SPDY 協(xié)議，主要解決 HTTP/1.1 效率不高的問題。

這個(gè)協(xié)議在Chrome瀏覽器上證明可行以后，就被當(dāng)作 HTTP/2 的基礎(chǔ)，主要特性都在 HTTP/2 之中得到繼承。

7、HTTP/2

2015年，HTTP/2 發(fā)布。它不叫 HTTP/2.0，是因?yàn)闃?biāo)準(zhǔn)委員會(huì)不打算再發(fā)布子版本了，下一個(gè)新版本將是 HTTP/3。

7.1 二進(jìn)制協(xié)議

HTTP/1.1 版的頭信息肯定是文本（ASCII編碼），數(shù)據(jù)體可以是文本，也可以是二進(jìn)制。HTTP/2 則是一個(gè)徹底的二進(jìn)制協(xié)議，頭信息和數(shù)據(jù)體都是二進(jìn)制，并且統(tǒng)稱為"幀"（frame）：頭信息幀和數(shù)據(jù)幀。

二進(jìn)制協(xié)議的一個(gè)好處是，可以定義額外的幀。HTTP/2 定義了近十種幀，為將來的高級(jí)應(yīng)用打好了基礎(chǔ)。如果使用文本實(shí)現(xiàn)這種功能，解析數(shù)據(jù)將會(huì)變得非常麻煩，二進(jìn)制解析則方便得多。

7.2 多工

HTTP/2 復(fù)用TCP連接，在一個(gè)連接里，客戶端和瀏覽器都可以同時(shí)發(fā)送多個(gè)請(qǐng)求或回應(yīng)，而且不用按照順序一一對(duì)應(yīng)，這樣就避免了"隊(duì)頭堵塞"。

舉例來說，在一個(gè)TCP連接里面，服務(wù)器同時(shí)收到了A請(qǐng)求和B請(qǐng)求，于是先回應(yīng)A請(qǐng)求，結(jié)果發(fā)現(xiàn)處理過程非常耗時(shí)，于是就發(fā)送A請(qǐng)求已經(jīng)處理好的部分， 接著回應(yīng)B請(qǐng)求，完成后，再發(fā)送A請(qǐng)求剩下的部分。

這樣雙向的、實(shí)時(shí)的通信，就叫做多工（Multiplexing）。

7.3 數(shù)據(jù)流

因?yàn)?HTTP/2 的數(shù)據(jù)包是不按順序發(fā)送的，同一個(gè)連接里面連續(xù)的數(shù)據(jù)包，可能屬于不同的回應(yīng)。因此，必須要對(duì)數(shù)據(jù)包做標(biāo)記，指出它屬于哪個(gè)回應(yīng)。

HTTP/2 將每個(gè)請(qǐng)求或回應(yīng)的所有數(shù)據(jù)包，稱為一個(gè)數(shù)據(jù)流（stream）。每個(gè)數(shù)據(jù)流都有一個(gè)獨(dú)一無二的編號(hào)。數(shù)據(jù)包發(fā)送的時(shí)候，都必須標(biāo)記數(shù)據(jù)流ID，用來區(qū)分它屬于哪個(gè)數(shù)據(jù)流。另外還規(guī)定，客戶端發(fā)出的數(shù)據(jù)流，ID一律為奇數(shù)，服務(wù)器發(fā)出的，ID為偶數(shù)。

數(shù)據(jù)流發(fā)送到一半的時(shí)候，客戶端和服務(wù)器都可以發(fā)送信號(hào)（RST_STREAM幀），取消這個(gè)數(shù)據(jù)流。1.1版取消數(shù)據(jù)流的唯一方法，就是關(guān)閉TCP連接。這就是說，HTTP/2 可以取消某一次請(qǐng)求，同時(shí)保證TCP連接還打開著，可以被其他請(qǐng)求使用。

客戶端還可以指定數(shù)據(jù)流的優(yōu)先級(jí)。優(yōu)先級(jí)越高，服務(wù)器就會(huì)越早回應(yīng)。

7.4 頭信息壓縮

HTTP 協(xié)議不帶有狀態(tài)，每次請(qǐng)求都必須附上所有信息。所以，請(qǐng)求的很多字段都是重復(fù)的，比如Cookie和User Agent，一模一樣的內(nèi)容，每次請(qǐng)求都必須附帶，這會(huì)浪費(fèi)很多帶寬，也影響速度。

HTTP/2 對(duì)這一點(diǎn)做了優(yōu)化，引入了頭信息壓縮機(jī)制（header compression）。一方面，頭信息使用gzip或compress壓縮后再發(fā)送；另一方面，客戶端和服務(wù)器同時(shí)維護(hù)一張頭信息表，所有字段都會(huì)存入這個(gè)表，生成一個(gè)索引號(hào)，以后就不發(fā)送同樣字段了，只發(fā)送索引號(hào)，這樣就提高速度了。

7.5 服務(wù)器推送

HTTP/2 允許服務(wù)器未經(jīng)請(qǐng)求，主動(dòng)向客戶端發(fā)送資源，這叫做服務(wù)器推送（server push）。

常見場(chǎng)景是客戶端請(qǐng)求一個(gè)網(wǎng)頁，這個(gè)網(wǎng)頁里面包含很多靜態(tài)資源。正常情況下，客戶端必須收到網(wǎng)頁后，解析HTML源碼，發(fā)現(xiàn)有靜態(tài)資源，再發(fā)出靜態(tài)資源請(qǐng)求。其實(shí)，服務(wù)器可以預(yù)期到客戶端請(qǐng)求網(wǎng)頁后，很可能會(huì)再請(qǐng)求靜態(tài)資源，所以就主動(dòng)把這些靜態(tài)資源隨著網(wǎng)頁一起發(fā)給客戶端了。

附錄：更多網(wǎng)絡(luò)通信基礎(chǔ)資料

《TCP/IP詳解 - 第11章·UDP：用戶數(shù)據(jù)報(bào)協(xié)議》

《TCP/IP詳解 - 第17章·TCP：傳輸控制協(xié)議》

《TCP/IP詳解 - 第18章·TCP連接的建立與終止》

《TCP/IP詳解 - 第21章·TCP的超時(shí)與重傳》

《技術(shù)往事：改變世界的TCP/IP協(xié)議（珍貴多圖、手機(jī)慎點(diǎn)）》

《通俗易懂-深入理解TCP協(xié)議（上）：理論基礎(chǔ)》

《通俗易懂-深入理解TCP協(xié)議（下）：RTT、滑動(dòng)窗口、擁塞處理》

《理論經(jīng)典：TCP協(xié)議的3次握手與4次揮手過程詳解》

《理論聯(lián)系實(shí)際：Wireshark抓包分析TCP 3次握手、4次揮手過程》

《計(jì)算機(jī)網(wǎng)絡(luò)通訊協(xié)議關(guān)系圖（中文珍藏版）》

《UDP中一個(gè)包的大小最大能多大？》

《P2P技術(shù)詳解(一)：NAT詳解——詳細(xì)原理、P2P簡(jiǎn)介》

《P2P技術(shù)詳解(二)：P2P中的NAT穿越(打洞)方案詳解》

《P2P技術(shù)詳解(三)：P2P技術(shù)之STUN、TURN、ICE詳解》

《通俗易懂：快速理解P2P技術(shù)中的NAT穿透原理》

《高性能網(wǎng)絡(luò)編程(一)：?jiǎn)闻_(tái)服務(wù)器并發(fā)TCP連接數(shù)到底可以有多少》

《高性能網(wǎng)絡(luò)編程(二)：上一個(gè)10年，著名的C10K并發(fā)連接問題》

《高性能網(wǎng)絡(luò)編程(三)：下一個(gè)10年，是時(shí)候考慮C10M并發(fā)問題了》

《高性能網(wǎng)絡(luò)編程(四)：從C10K到C10M高性能網(wǎng)絡(luò)應(yīng)用的理論探索》

《不為人知的網(wǎng)絡(luò)編程(一)：淺析TCP協(xié)議中的疑難雜癥(上篇)》

《不為人知的網(wǎng)絡(luò)編程(二)：淺析TCP協(xié)議中的疑難雜癥(下篇)》

《不為人知的網(wǎng)絡(luò)編程(三)：關(guān)閉TCP連接時(shí)為什么會(huì)TIME_WAIT、CLOSE_WAIT》

《不為人知的網(wǎng)絡(luò)編程(四)：深入研究分析TCP的異常關(guān)閉》

《不為人知的網(wǎng)絡(luò)編程(五)：UDP的連接性和負(fù)載均衡》

《不為人知的網(wǎng)絡(luò)編程(六)：深入地理解UDP協(xié)議并用好它》

《不為人知的網(wǎng)絡(luò)編程(七)：如何讓不可靠的UDP變的可靠？》

《網(wǎng)絡(luò)編程懶人入門(一)：快速理解網(wǎng)絡(luò)通信協(xié)議（上篇）》

《網(wǎng)絡(luò)編程懶人入門(二)：快速理解網(wǎng)絡(luò)通信協(xié)議（下篇）》

《網(wǎng)絡(luò)編程懶人入門(三)：快速理解TCP協(xié)議一篇就夠》

《網(wǎng)絡(luò)編程懶人入門(四)：快速理解TCP和UDP的差異》

《網(wǎng)絡(luò)編程懶人入門(五)：快速理解為什么說UDP有時(shí)比TCP更有優(yōu)勢(shì)》

《網(wǎng)絡(luò)編程懶人入門(六)：史上最通俗的集線器、交換機(jī)、路由器功能原理入門》

《網(wǎng)絡(luò)編程懶人入門(七)：深入淺出，全面理解HTTP協(xié)議》

《技術(shù)掃盲：新一代基于UDP的低延時(shí)網(wǎng)絡(luò)傳輸層協(xié)議——QUIC詳解》

《讓互聯(lián)網(wǎng)更快：新一代QUIC協(xié)議在騰訊的技術(shù)實(shí)踐分享》

《現(xiàn)代移動(dòng)端網(wǎng)絡(luò)短連接的優(yōu)化手段總結(jié)：請(qǐng)求速度、弱網(wǎng)適應(yīng)、安全保障》

《聊聊iOS中網(wǎng)絡(luò)編程長(zhǎng)連接的那些事》

《移動(dòng)端IM開發(fā)者必讀(一)：通俗易懂，理解移動(dòng)網(wǎng)絡(luò)的“弱”和“慢”》

《移動(dòng)端IM開發(fā)者必讀(二)：史上最全移動(dòng)弱網(wǎng)絡(luò)優(yōu)化方法總結(jié)》

《IPv6技術(shù)詳解：基本概念、應(yīng)用現(xiàn)狀、技術(shù)實(shí)踐（上篇）》

《IPv6技術(shù)詳解：基本概念、應(yīng)用現(xiàn)狀、技術(shù)實(shí)踐（下篇）》

《從HTTP/0.9到HTTP/2：一文讀懂HTTP協(xié)議的歷史演變和設(shè)計(jì)思路》

>> 更多同類文章 ……

（本文同步發(fā)布于：http://www.52im.net/thread-1709-1-1.html）