Jack Jiang

我的最新工程MobileIMSDK:http://git.oschina.net/jackjiang/MobileIMSDK
posts - 156, comments - 13, trackbacks - 0, articles - 0

1、引言

在文章《理論聯系實際:Wireshark抓包分析TCP 3次握手、4次揮手過程》中,我們學會了用wireshark來分析TCP的“三次握手,四次揮手”,非常好用。這就是傳說中的錘子,拿著 錘子,看什么都像 釘子!在這本文中,我對將準 HTTP這顆釘子,狠狠地砸下去。。。

為了對網絡數據包的“流轉”有更加深刻的理解,我在docker(遠程)上部署一個服務,支持http方式調用。從客戶端(本地)用http方式請求其中的一個接口,并得到響應數據。同時本地通過wireshark抓包,遠程用tcpdump抓包,然后分析過程中的所有通信細節(悲劇是把美好的東西撕碎給人看,而我則是把復雜的東西撕碎了給人看)。

本文的主要內容是:先通過工具獲取HTTP通信的數據包,再來抽絲剝繭,深入傳輸層二進制的天地里,解密HTTP所有的通信細節。分析過程中,由點到面,將相關知識串接起來。市面上講HTTP協議的文章很多,但深入到傳輸層從2進制的角度來解析,則相當少見。保證全篇讀完之后,你對HTTP的理解會上升一個臺階!

本文稍長,請在看本文時保持耐心。

(本文同步發布于:http://www.52im.net/thread-2456-1-1.html

2、關于作者

饒全成:畢業于華中科技大學,中科院計算所碩士,滴滴出行后端研發工程師。微信公眾號: 碼農桃花源,個人博客:https://www.cnblogs.com/qcrao-2018/

3、系列文章

1)本文是系列文章中的第8篇,本系列文章的大綱如下:

不為人知的網絡編程(一):淺析TCP協議中的疑難雜癥(上篇)

不為人知的網絡編程(二):淺析TCP協議中的疑難雜癥(下篇)

不為人知的網絡編程(三):關閉TCP連接時為什么會TIME_WAIT、CLOSE_WAIT

不為人知的網絡編程(四):深入研究分析TCP的異常關閉

不為人知的網絡編程(五):UDP的連接性和負載均衡

不為人知的網絡編程(六):深入地理解UDP協議并用好它

不為人知的網絡編程(七):如何讓不可靠的UDP變的可靠?

不為人知的網絡編程(八):從數據傳輸層深度解密HTTP》(本文)

2)如果您覺得本系列文章過于專業,您可先閱讀《網絡編程懶人入門》系列文章,該系列目錄如下:

網絡編程懶人入門(一):快速理解網絡通信協議(上篇)

網絡編程懶人入門(二):快速理解網絡通信協議(下篇)

網絡編程懶人入門(三):快速理解TCP協議一篇就夠

網絡編程懶人入門(四):快速理解TCP和UDP的差異

網絡編程懶人入門(五):快速理解為什么說UDP有時比TCP更有優勢

3)《腦殘式網絡編程入門》也適合入門學習,本系列大綱如下:

腦殘式網絡編程入門(一):跟著動畫來學TCP三次握手和四次揮手

腦殘式網絡編程入門(二):我們在讀寫Socket時,究竟在讀寫什么?

腦殘式網絡編程入門(三):HTTP協議必知必會的一些知識

腦殘式網絡編程入門(四):快速理解HTTP/2的服務器推送(Server Push)

4)其它跟HTTP有關的文章:

從HTTP/0.9到HTTP/2:一文讀懂HTTP協議的歷史演變和設計思路

美圖App的移動端DNS優化實踐:HTTPS請求耗時減小近半

一分鐘理解 HTTPS 到底解決了什么問題

一篇讀懂HTTPS:加密原理、安全邏輯、數字證書等

小白必讀:閑話HTTP短連接中的Session和Token

IM開發基礎知識補課:正確理解前置HTTP SSO單點登陸接口的原理

從HTTP到MQTT:一個基于位置服務的APP數據通信實踐概述

基于APNs最新HTTP/2接口實現iOS的高性能消息推送(服務端篇)

Comet技術詳解:基于HTTP長連接的Web端實時通信技術

WebSocket詳解(四):刨根問底HTTP與WebSocket的關系(上篇)

WebSocket詳解(五):刨根問底HTTP與WebSocket的關系(下篇)

4、在傳輸層捕獲HTTP報文

4.1 背景介紹

我手頭現在有一個地理幾何相關的服務,它提供一組接口對外使用。其中有一個接口是Fence2Area. 使用方傳入一個圍欄(由點的列表組成,點由<經度,緯度>表示)、點的坐標系類型(谷歌地圖用的是wgs84, 國內騰訊、高德用的是soso, 而百度用的是另一套自己的坐標系),接口輸出的則是圍欄的面積。

我請求服務的“Fence2Area”接口,輸入圍欄(fence)頂點(lng, lat)坐標、坐標系類型(coordtype),輸出的則是多邊形的面積(area).

一次正常的請求示例url, 這個大家都不陌生(我用docker_ip代替真實的ip):

http://docker_ip:7080/data?cmd=Fence2Area&meta={"caller":"test","TraceId":"test"}&request={"fence":[{"lng":10.2,"lat":10.2}, {"lng":10.2,"lat":8.2}, {"lng":8.2,"lat":8.2}, {"lng":8.2,"lat":10.2}],"coordtype":2}

請求發出后,服務器進行處理,之后,客戶端收到返回的數據如下:

{

    "data": {

        "area": 48764135597.842606

    },

    "errstr": ""

}

area字段表示面積,errstr表示出錯信息,空說明沒有出錯。

4.2 抓包

在真正發送請求之前,需要進行抓包前的設置。在本地mac,我用wireshark; 而在遠程docker上,我用tcpdump工具。

mac本地:設置wireshark包過濾器,監控本地主機和遠程docker之間的通信。

ip.addr eq docker_ip

點擊開始捕獲。

遠程docker:該服務通過7080端口對外提供,使用如下命令捕獲網絡包:

tcpdump -w /tmp/testHttp.cap port 7080 -s0

4.3 請求、捕獲、分析

準備工作做完,我選了一個神圣的時刻,在本地通過瀏覽器訪問如下url:

http://docker_ip:7080/data?cmd=Fence2Area&meta={"caller":"test","TraceId":"test"}&request={"fence":[{"lng":10.2,"lat":10.2}, {"lng":10.2,"lat":8.2}, {"lng":8.2,"lat":8.2}, {"lng":8.2,"lat":10.2}],"coordtype":2}

這樣本地的wireshark和遠程的tcpdump都能抓取到HTTP網絡數據包。

【關閉服務進程】:

正式請求之前,我們先看一下幾種特殊的情形。

首先,關閉gcs服務進程,請求直接返回RST報文。

如上圖,我在請求的時候,訪問服務端的另一個端口5010, 這個端口沒有服務監聽,和關閉gcs服務進程是同樣的效果。可以看到,客戶端發送SYN報文,但直接被遠程docker RST掉了。因為服務端操作系統找不到監聽此端口的進程。

【關閉docker】:

關閉docker, 由于發送的SYN報文段得不到響應,因此會進行重試,mac下重試的次數為10次。

先每隔1秒重試了5次,再用“指數退避”的時間間隔重試,2s, 4s, 8s, 16s, 32s. 最后結束。

【重啟docker】:

先進行一次正常的訪問,隨后重啟docker。并再次在本地訪問以上url, 瀏覽器這時還是用的上一次的端口,訪問到服務端后,因為它已經重啟了,所以服務端已經沒有這個連接的消息了。因此會返回一個RST報文。

【正常請求】:

服務正常啟動,正常發送請求,這次請求成功,那是當然的,嘿嘿!

這是在mac上用wireshark捕獲的數據包,共7個包,前三個包為3次握手的包,第四個包為HTTP層發送的請求數據,第五個包為服務端的TCP 確認報文,第六個包為服務端在HTTP層發送的響應數據,第七個包為mac對第六個包的確認報文。

重點來關注后面幾個包,先看第四個包:

0x0000:  4500 0295 0000 4000 3606 623b ac17 ccdc

0x0010:  0a60 5cd4 db9b 1ba8 a59a 46ce 6d03 e87d

0x0020:  8018 1015 0ee7 0000 0101 080a 2e4c b2ef

0x0030:  0f20 3acf 4745 5420 2f64 6174 613f 636d

0x0040:  643d 4665 6e63 6532 4172 6561 266d 6574

0x0050:  613d 7b25 3232 6361 6c6c 6572 2532 323a

0x0060:  2532 3274 6573 7425 3232 2c25 3232 5472

0x0070:  6163 6549 6425 3232 3a25 3232 7465 7374

0x0080:  2532 327d 2672 6571 7565 7374 3d7b 2532

0x0090:  3266 656e 6365 2532 323a 5b7b 2532 326c

0x00a0:  6e67 2532 323a 3130 2e32 2c25 3232 6c61

0x00b0:  7425 3232 3a31 302e 327d 2c25 3230 7b25

0x00c0:  3232 6c6e 6725 3232 3a31 302e 322c 2532

0x00d0:  326c 6174 2532 323a 382e 327d 2c25 3230

0x00e0:  7b25 3232 6c6e 6725 3232 3a38 2e32 2c25

0x00f0:  3232 6c61 7425 3232 3a38 2e32 7d2c 2532

0x0100:  307b 2532 326c 6e67 2532 323a 382e 322c

0x0110:  2532 326c 6174 2532 323a 3130 2e32 7d5d

0x0120:  2c25 3232 636f 6f72 6474 7970 6525 3232

0x0130:  3a32 7d20 4854 5450 2f31 2e31 0d0a 486f

0x0140:  7374 3a20 3130 2e39 362e 3932 2e32 3132

0x0150:  3a37 3038 300d 0a55 7067 7261 6465 2d49

0x0160:  6e73 6563 7572 652d 5265 7175 6573 7473

0x0170:  3a20 310d 0a41 6363 6570 743a 2074 6578

0x0180:  742f 6874 6d6c 2c61 7070 6c69 6361 7469

0x0190:  6f6e 2f78 6874 6d6c 2b78 6d6c 2c61 7070

0x01a0:  6c69 6361 7469 6f6e 2f78 6d6c 3b71 3d30

0x01b0:  2e39 2c2a 2f2a 3b71 3d30 2e38 0d0a 5573

0x01c0:  6572 2d41 6765 6e74 3a20 4d6f 7a69 6c6c

0x01d0:  612f 352e 3020 284d 6163 696e 746f 7368

0x01e0:  3b20 496e 7465 6c20 4d61 6320 4f53 2058

0x01f0:  2031 305f 3133 5f36 2920 4170 706c 6557

0x0200:  6562 4b69 742f 3630 352e 312e 3135 2028

0x0210:  4b48 544d 4c2c 206c 696b 6520 4765 636b

0x0220:  6f29 2056 6572 7369 6f6e 2f31 322e 302e

0x0230:  3220 5361 6661 7269 2f36 3035 2e31 2e31

0x0240:  350d 0a41 6363 6570 742d 4c61 6e67 7561

0x0250:  6765 3a20 7a68 2d63 6e0d 0a41 6363 6570

0x0260:  742d 456e 636f 6469 6e67 3a20 677a 6970

0x0270:  2c20 6465 666c 6174 650d 0a43 6f6e 6e65

0x0280:  6374 696f 6e3a 206b 6565 702d 616c 6976

0x0290:  650d 0a0d 0a

我們來逐字節分析:

剩余的數據部分即為TCP協議相關的。

TCP也是20B固定長度+可變長度部分:

可變長度部分,協議如下:

剩下來的就是數據部分了。我們一行一行地看。

因為http是字符流,所以我們先看一下ascii字符集,執行命令:

man ascii

可以得到ascii碼,我們直接看十六進制的結果:

把上表的最后一列連起來,就是:

GET /data?cmd=Fence2Area&meta={%22caller%22:%22test%22,%22TraceId%22:%22test%22}&request={%22fence%22:[{%22lng%22:10.2,%22lat%22:10.2},%20{%22lng%22:10.2,%22lat%22:8.2},%20{%22lng%22:8.2,%22lat%22:8.2},%20{%22lng%22:8.2,%22lat%22:10.2}],%22coordtype%22:2} HTTP/1.1

Host: 10.96.92.212:7080

Upgrade-Insecure-Requests: 1

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.0.2 Safari/605.1.15

Accept-Language: zh-cn

Accept-Encoding: gzip, deflate

Connection: keep-alive

其中,cr nl表示回車,換行。

docker收到數據后,會回復一個ack包。第四個包的總長度為661字節,去掉IP頭部20字節,TCP頭部固定部分20字節,TCP頭部可選長度為12字節,共52字節,因此TCP數據部分總長度為661-52=609字節。另外,序列號為2778351310.

再來看第5個包,字節流如下:

0x0000:  4500 0034 d28b 4000 4006 8810 0a60 5cd4

0x0010:  ac17 ccdc 1ba8 db9b 6d03 e87d a59a 492f

0x0020:  8010 00ec e04e 0000 0101 080a 0f20 3af7

0x0030:  2e4c b2ef

剩余的數據部分即為TCP協議相關的。

TCP也是20B固定長度+可變長度部分:

可變長度部分,協議如下:

數據部分為空,這個包僅為確認包。

再來看第六個包,字節流如下:

0x0000:  4500 00f9 d28c 4000 4006 874a 0a60 5cd4

0x0010:  ac17 ccdc 1ba8 db9b 6d03 e87d a59a 492f

0x0020:  8018 00ec e113 0000 0101 080a 0f20 3af8

0x0030:  2e4c b2ef 4854 5450 2f31 2e31 2032 3030

0x0040:  204f 4b0d 0a41 6363 6573 732d 436f 6e74

0x0050:  726f 6c2d 416c 6c6f 772d 4f72 6967 696e

0x0060:  3a20 2a0d 0a44 6174 653a 2054 6875 2c20

0x0070:  3033 204a 616e 2032 3031 3920 3132 3a32

0x0080:  333a 3437 2047 4d54 0d0a 436f 6e74 656e

0x0090:  742d 4c65 6e67 7468 3a20 3438 0d0a 436f

0x00a0:  6e74 656e 742d 5479 7065 3a20 7465 7874

0x00b0:  2f70 6c61 696e 3b20 6368 6172 7365 743d

0x00c0:  7574 662d 380d 0a0d 0a7b 2264 6174 6122

0x00d0:  3a7b 2261 7265 6122 3a34 3837 3634 3133

0x00e0:  3535 3937 2e38 3432 3630 367d 2c22 6572

0x00f0:  7273 7472 223a 2222 7d

剩余的數據部分即為TCP協議相關的。TCP也是20B固定長度+可變長度部分:

可變長度部分,協議如下:

剩下來的就是數據部分了。我們一行一行地看:

把上表的最后一列連起來,就是:

HTTP/1.1 200 OK

Access-Control-Allow-Origin: *

Date: Thu, 03 Jan 2019 12:23:47 GMT

Content-Length: 48

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

{"data":{"area":48764135597.842606},"errstr":""}

Content-Length: 48,最后一行的長度即為48個字節。

最后,第七個包,字節流如下:

0x0000:  4500 0034 0000 4000 3606 649c ac17 ccdc

0x0010:  0a60 5cd4 db9b 1ba8 a59a 492f 6d03 e942

0x0020:  8010 100f 1eb9 0000 0101 080a 2e4c b314

0x0030:  0f20 3af8

剩余的數據部分即為TCP協議相關的。TCP也是20B固定長度+可變長度部分:

可變長度部分,協議如下:

至此,一次完整的http請求的報文就解析完了。感覺如何,是不是很親切?(PS: WTF?看的人都抓狂了,還親切?哈哈)

5、在應用層學習HTTP協議

上面我們把HTTP協議相關的數據從2進制層給解密了,下面我將對照上面的數據拆解結果,一步步帶你從應用層深入認識HTTP協議。

5.1 整體介紹

HTTP(Hypertext Transfer Protocol)超文本傳輸協議,是在互聯網上進行通信時使用的一種協議。說得更形象一點:HTTP是現代互聯網中使用的公共語言。它最著名的應用是用在瀏覽器的服務器間的通信。

HTTP屬于應用層協議,底層是靠TCP進行可靠地信息傳輸。

HTTP在傳輸一段報文時,會以流的形式將報文數據的內容通過一條打開的TCP連接按序傳輸。TCP接到上層應用交給它的數據流之后,會按序將數據流打散成一個個的分段。再交到IP層,通過網絡進行傳輸。另一端的接收方則相反,它們將接收到的分段按序組裝好,交給上層HTTP協議進行處理。

5.2 編碼

我們再來回顧一下:

在之前的報文拆解過程中,我們看到多了很多%22,其實,0x22是單引號"的ascii值。

一方面,URL描述的資源為了能通過其他各種協議傳送,但是有些協議在傳輸過程中會剝去一些特定的字符;

另一方面,URL還是可讀的,所以那些不可打印的字符就不能在URL中使用了,比如空格;

最后,URL還得是完整的,它需要支持所有語言的字符。

總之,基于很多原因,URL設計者將US-ASCII碼和其轉義序列集成到URL中,通過轉義序列,就可以用US-ASCII字符集的有限子集對任意字符或數據進行編碼了。

轉義的方法:百分號(%)后跟著兩個表示ASCII碼的十六進制數。比如:

所以上面在瀏覽器發送給服務器的URL進行了非“安全字符”編碼,也就不奇怪了吧?

在URL中,當上面的保留字符用在保留用途之外的場合時,需要對URL進行編碼。

5.3 MIME類型

響應數據中,我們注意到有一個首部:

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

互聯網上有數千種不同的數據類型,HTTP給每種對象都打上了MIME(Multipurpose Internet Media Extension, 多用途因特網郵件擴展)標簽,也就是響應數據中的Content-Type. MIME本來是用在郵件協議中的,后來被移植到了HTTP中。瀏覽器從服務器上取回了一個對象時,會去查看MIME類型,從而得知如何處理這種對象,是該展示圖片,還是調用聲卡播放聲音。

MIME通過斜杠來標識對象的主類型和其中的特定的子類型,下表展示了一些常見的類型,其中的實體主體是指body部分:

5.4 URI/URL/URN

URI(Uniform Resource Identifier, 統一資源標識符)表示服務器資源,URL(Uniform Resource Locator, 統一資源定位符)和URN(Uniform Resource Name, 統一資源名)是URI的具體實現。URI是一個通用的概念,由兩個主要的子集URL和URN構成,URL通過位置、URN通過名字來標識資源。

URL定義了資源的位置,表示資源的實際地址,在使用URL的過程中,如果URL背后的資源發生了位置移動,訪問者就找不到它了。這個時候就要用到URN了,它給定資源一個名字,無論它移動到哪里,都可以通過這個名字來訪問到它,簡直完美!

URL通常的格式是:

協議方案+服務器地址+具體的資源路徑

協議方案(scheme),如 http, ftp,告知web客戶端怎樣訪問資源);服務器地址,如 www.oreilly.com; 具體的資源路徑,如 index.html.

5.5 HTTP方法

HTTP支持幾種不同的請求方法,每種方法對服務器要求的動作不同,如下圖是幾種常見的方法:

HEAD方法只獲取頭部,不獲取數據部分。通過頭部可以獲取比如資源的類型(Content-Type)、資源的長度(Content-Length)這些信息。這樣,客戶端可以獲取即將請求資源的一些情況,可以做到心中有數。

1)POST用于向服務器發送數據,常見的是提交表單;

2)PUT用于向服務器上的資源存儲數據。

5.6 狀態碼

每條HTTP的響應報文都會帶上一個三位數字的狀態碼和一條解釋性的“原因短語”,通知客戶端本次請求的狀態,幫助客戶端快速理解事務處理結果,最常見的是:

200 OK 

404 Not Found

500 Internal Server Error

我們平時使用瀏覽器的時候,很多的錯誤碼其實是由瀏覽器處理的,我們感知不到。但是404 Not Found會穿透重重迷霧,來到我們面前,為何?那是因為他對我們愛的深沉啊!

客戶端可以據此狀態碼,決定下一步的行動(如重定向等)。

三位數字的第一位表示分類:

5.7 報文格式

HTTP報文實際上是由一行行的字符串組成的,每行字符串的末尾用\r\n分隔,人類可以很方便的閱讀。順便說一句,不是所有的協議都對人類這么友好的,像thrift協議,直接甩一堆字節給你,告訴你說0x0001表示調用方法,諸如此類的,你只能對著一個十六進制的數據塊一個個地去“解碼”。不可能像HTTP協議這樣,直接將字符編碼,人類可以直接讀懂。

舉個簡單的請求報文和響應報文的格式的例子:

實際上,請求報文也是可以有body(主體)部分的。請求報文是由請求行(request line)、請求頭部(header)、空行、請求數據四個部分組成。唯一要注意的一點就是,請求報文即使body部分是空的,請求頭部后的回車換行符也是必須要有的。

響應報文的格式和請求報文的格式類似:

請求報文、響應報文的起始行和響應頭部里的字段都是文本化、結構化的。而請求body卻可以包含任意二進制數據(如圖片、視頻、軟件等),當然也可以包含文本。

有些首部是通用的,有些則是請求或者響應報文才會有的。

順便提一下, 用telnet直連服務器的http端口,telnet命令會建立一條TCP通道,然后就可以通過這個通道直接發送HTTP請求數據,獲取響應數據了。

6、HTTP協議進階

6.1 代理

HTTP的代理服務器既是Web服務器,又是Web客戶端。

使用代理可以“接觸”到所有流過的HTTP流量,代理可以對其進行監視和修改。常見的就是對兒童過濾一些“成人”內容;網絡工程師會利用代理服務器來提高安全性,它可以限制哪些應用層的協議數據可以通過,過濾“病毒”等數據;代理可以存儲緩存的文件,直接返回給訪問者,無需請求原始的服務器資源;對于訪問慢速網絡上的公共內容時,可以假扮服務器提供服務,從而提高訪問速度;這被稱為反向代理;可以作為內容路由器,如對付費用戶,則將請求導到緩存服務器,提高訪問速度;可以將頁面的語言轉換到與客戶端相匹配,這稱為內容轉碼器; 匿名代理會主動從HTTP報文中刪除身份相關的信息,如User-Agent, Cookie等字段。

現實中,請求通過以下幾種方式打到代理服務器上去:

報文每經過一個中間點(代理或網關),都需要在首部via字段的末尾插入一個可以代表本節點的獨特的字符串,包含實現的協議版本和主機地址。注意下圖中的via字段。

請求和響應的報文傳輸路徑通常都是一致的,只不過方向是相反的。因此,響應報文上的via字段表示的中間節點的順序是剛好相反的。

6.2 緩存

當有很多請求訪問同一個頁面時,服務器會多次傳輸同一份數據,這些數據重復地在網絡中傳輸著,消耗著大量帶寬。如果將這些數據緩存下來,就可以提高響應速度,節省網絡帶寬了。

大部分緩存只有在客戶端發起請求,并且副本已經比較舊的情況下才會對副本的新鮮度進行檢測。最常用的請求首部是If-Modified-Since, 如果在xx時間(此時間即為If-Modified-Since的值)之后內容沒有變化,服務器會回應一個304 Not Modified. 否則,服務器會正常響應,并返回原始的文件數據,而這個過程中被稱為再驗證命中。

再驗證可能出現命中或未命中的情況:

1)未命中時,服務器回復200 OK,并且返回完整的數據;

2)命中時,服務器回復304 Not Modified。

還有一種情況,緩存被刪除了,那么根據響應狀態碼,緩存服務器也會刪除自己緩存的副本。

順帶提一句,若要在項目中使用緩存,就一定要關注緩存命中比例。若命中比例不高,就要重新考慮設置緩存的必要性了。

緩存服務器返回響應的時候,是基于已緩存的服務器響應的首部,再對一些首部字段做一些微調。比如向其中插入新鮮度信息(如Age, Expires首部等),而且通常會包含一個via首部來說明緩存是由一個緩存代理提供的。注意,這時不要修改Date字段,它表示原始服務器最初構建這條響應的日期。

HTTP通過文檔過期機制和服務器再驗證機制保持已緩存數據和服務器間的數據充分一致。

文檔過期通過如下首部字段來表示緩存的有效期:

當上面兩個字段暗示的過期時間已到,需要向服務器再次驗證文檔的新鮮度。如果這時緩存仍和服務器上的原始文檔一致,緩存只需要更新頭部的相關字段。如上表中提到的Expires字段等。

為了更好的節省網絡流量,緩存服務器可以通過相關首部向原始服務器發送一個條件GET請求, 這樣只有在緩存真正過期的情況下,才會返回原始的文檔,否則只會返回相關的首部。

條件GET請求會用到如下的字段:

6.3 cookie

cookie是服務器“貼在”客戶端身上的標簽,由客戶端維護的狀態片段,并且只會回送給合適的站點。

有兩類cookie: 

1)會話cookie、持久cookie. 會話cookie在退出瀏覽器后就被刪除了;

2)而持久cookie則保存在硬盤中,計算機重啟后仍然存在。

服務器在給客戶端的響應字段首部加上Set-cookie或Set-cookie2, 值為名字=值的列表,即可以包含多個字段。當下次瀏覽器再次訪問到相同的網站時,會將這些字段通過Cookie帶上。cookie中保留的內容是服務器給此客戶端打的標簽,方便服務進行追蹤的識別碼。瀏覽器會將cookie以特定的格式存儲在特定的文件中。

瀏覽器只會向產生這條cookie的站點發生cookie. Set-cookie字段的值會包含domain這個字段,告知瀏覽器可以把這條cookie發送給給相關的匹配的站點。path字段也是相似的功能。

如i瀏覽器收到如下的cookie:

Set-cookie: user="mary"; domain="stefno.com"

那么瀏覽器在訪問任意以stefno.com結尾的站點都會發送:

Cookie: user="mary"

6.4 實體和編碼

響應報文中的body部分傳輸的數據本質上都是二進制。我們從上面的報文數據也可以看出來,都是用十六進制數來表示,關鍵是怎么解釋這塊內容。

如果Content-Type定義是text/plain, 那說明body內容就是文本,我們直接按文本編碼來解釋;如果Content-Type定義是image/png, 說明body部分是一幅圖片,那我們就按圖片的格式去解釋數據。

Content-Length標示報文主體部分的數據長度大小,如果內容是壓縮的,那它表示的就是壓縮后的大小。另外,Content-Length在長連接的情況下,可以對多個報文進行正確地分段。所以,如果沒有采用分塊編碼,響應數據中必須帶上Content-Length字段。分塊編碼的情形中,數據被拆分成很多小塊,每塊都有大小說明。因此,任何帶有主體部分的報文(請求或是響應)都應帶上正確的Content-Length首部。

HTTP的早期版本采用關閉連接的方式來劃定報文的結束。這帶來的問題是顯而易見的:客戶端并不能分清是因為服務器正常結束還是中途崩潰了。這里,如果是客戶端用關閉來表示請求報文主體部分的結束,是不可取的,因為關閉之后,就無法獲取服務器的響應了。當然,客戶端可以采用半關閉的方式,只關閉數據發送方向,但是很多服務器是不識別的,會把半關閉當成客戶端要成服務器斷開來處理。

HTTP報文在傳輸的過程中可能會遭到代理或是其他通信實體的無意修改,為了讓接收方知道這種情況,服務器會對body部分作一個md5, 并把值放到Content-MD5這個字段中。但是,如果中間的代理即修改了報文主體,又修改了md5, 就不好檢測了。因此規定代理是不能修改Content-MD5首部的。這樣,客戶端在收到數據后,先進行解碼,再算出md5, 并與Content-MD5首部進行比較。這主要是防止代理對報文進行了無意的改動。

HTTP在發送內容之前需要對其進行編碼,它是對報文主體進行的可逆變換。比如將報文用gzip格式進行壓縮,減少傳輸時間。

常見的編碼類型如下:

當然,客戶端為了避免服務器返回自己不能解碼的數據,請求的時候,會在Accept-Encoding首部里帶上自己支持的編碼方式。如果不傳輸的話,默認可以接受任何編碼方式。

上面提到的編碼是內容編碼,它只是在響應報文的主體報文將原始數據進行編碼,改變的是內容的格式。還有另一種編碼:傳輸編碼。它與內容無關,它是為了改變報文數據在網絡上傳輸的方式。傳輸編碼是在HTTP 1.1中引入的一個新特性。

通常,服務器需要先生成數據,再進行傳輸,這時,可以計算數據的長度,并將其編碼到Content-Length中。但是,有時,內容是動態生成的,服務器希望在數據生成之前就開始傳輸,這時,是沒有辦法知道數據大小的。這種情況下,就要用到傳輸編碼來標注數據的結束的。

HTTP協議中通過如下兩個首部來描述和控制傳輸編碼:

分塊編碼的報文形式是這樣的:

每個分塊包含一個長度值(十六進制,字節數)和該分塊的數據。用于區隔長度值和數據。長度值不包含分塊中的任何序列。最后一個分塊,用長度值0來表示結束。注意報文首部包含一個Trailer: Content-MD5, 所以在緊跟著最后一個報文結束之后,就是一個拖掛。其他如,Content-Length, Trailer, Transfer-Encoding也可以作為拖掛。

內容編碼和傳輸編碼是可以結合起來使用的。

6.5 國際化支持

HTTP為了支持國際化的內容,客戶端要告知服務器自己能理解的何種語言,以及瀏覽器上安裝了何種字母表編碼算法。這通過Accept-Charset和Accept-Language首部實現。

比如:

Accept-Language: fr, en;q=0.8

Accept-Charset: iso-8859-1, utf-8

表示:客戶端接受法語(fr, 優先級默認為1.0)、英語(en, 優先級為0.8),支持iso-8859-1, utf-8兩種字符集編碼。服務器則會在Content-Type首部里放上charset.

本質上,HTTP報文的body部分存放的就是一串二進制碼,我們先把二進制碼轉換成字符代碼(如ascii是一個字節表示一個字符,而utf-8則表示一個字符的字節數不定,每個字符1~6個字節),之后,用字符代碼去字符集中找到對應的元素。

比較常見的字符集是US-ASCII: 這個字符集是所有字符集的始祖,早在1968年就發布了標準。ASCII碼的代碼值從0到127, 只需要7個bit位就可以覆蓋代碼空間。HTTP報文的首部、URL使用的字符集就是ASCII碼。可以再看下上文報文分析部分的acsii碼集。

US-ASCII是把每個字符編碼成固定的7位二進制值。UTF-8則是無固定的編碼方案。第一個字節的高位用來表示編碼后的字符所用的字節數(如果所用的字節數是5,則第一個字節前5bit都是1,第6bit是0),所需的后續的字節都含有6位的代碼值,前兩個bit位是用10標識。

舉個例子,漢字“嚴”的Unicode編碼為4E25(100111000100101), 共有15位,落在上表中的第三行,因此“嚴”的編碼就需要三個字節。將100111000100101填入上表中的c位即可。因此,嚴的UTF-8編碼是11100100 10111000 10100101,轉換成十六進制就是E4B8A5. 比如我在谷歌搜索框里搜索“嚴”字,google發出的請求如下:

https://www.google.com.hk/search?q=%E4%B8%A5&oq=%E4%B8%A5&aqs=chrome..69i57j0l5.3802j0j4&sourceid=chrome&ie=UTF-8&gws_rd=cr

q=%E4%B8%A5 這個就是搜索的詞了。

6.6 重定向與負載均衡

Web內容通常分散地分布在很多地方,這可以防止“單點故障”,萬一某個地方發生地震了,機房被毀了,那還有其他地方的機房可以提供服務。一般都會有所謂的“雙活”,“多活”,所謂狡兔三窟嘛。

這樣,用戶的請求會根據負載均衡的原則,被重定向到它應該去的地方。

HTTP重定向:

服務器收到客戶端請求后,向客戶端返回一條帶有狀態碼302重定向的報文,告訴他們應該去其他的地方試試。web站點將重定向看成一種簡單的負載均衡策略來使用,重定向服務器找到可用的負載最小的機器,由于服務器知道客戶端的地址,理論上來說,可以做到最優的重定向選擇。

當然,缺點也是顯而易見的,由于客戶端要發送兩次請求,因此會增加耗時。

DNS重定向:

DNS將幾個IP地址關聯到一個域上,采用算法決定返回的IP地址。可以是簡單的輪轉;也可以是更高級的算法,如返回負載最輕的服務器的IP地址,稱為負載均衡算法;如果考慮地理位置,返回給客戶端最近位置的地址,稱為鄰接路由算法;還有一種是繞過出現故障的地址,稱為故障屏蔽算法。

DNS服務器總是會返回所有的IP地址,但是DNS客戶端一般只會使用第一個IP地址,而且會緩存下來,之后會一直用這個地址。所以,DNS輪轉通常不會平衡單個客戶端的負載。但是,由于DNS服務器對于不同的請求,總是會返回輪轉后的IP地址列表,因此,會把負載分散到多個客戶端。

6.7 HTTP連接

HTTP連接是HTTP報文傳輸的關鍵通道。

【并行連接】:

對于一個頁面上同時出現多個對象的時候,如果瀏覽器并行地打開多個連接,同時去獲取這些對象,多個連接的TCP握手時延可以進行重疊,速度會快起來。

如一個包含3張圖片的頁面,瀏覽器要發送4次HTTP請求來獲取頁面。1個用于頂層的HTML頁面,3個用于圖片。

如果采用串行方式,那么連接時延會進行疊加:

采用并行連接之后:

但是并行連接也不絕對提升速度,如果一個頁面有數百個內嵌對象,那要啟動數百個連接,對服務器的性能也是非常大的挑戰。所以,通常瀏覽器會限制并行連接的總數據在一個較小的值,通常是4個,而且服務端可以隨意關閉客戶端超量的連接。

另一方面,如果客戶端網絡帶寬較小,每個連接都會去爭搶有限的帶寬,每個連接都會獲取較小的速度,即每個對象都會以較小的速度去加載。這樣,并行連接帶來的速度提升就會比較小,甚至沒有提升。

【持久連接】:

持久連接即HTTP的keep-alive機制。

我們知道HTTP請求是“請求-應答”模式,每次請求-應答都要新建一個連接,完成之后要斷開連接。HTTP是無狀態的,連接之間沒有任何關系。

HTTP是應用層協議,TCP是傳輸層協議。HTTP底層仍然采用TCP進行傳輸數據。TCP為HTTP提供了一層可靠的比特傳輸通道。HTTP一般交換的數據都不大,而每次連接都要進行TCP三次握手,很大一部分時間都消耗在這上面,有時候甚至能達到50%。如果能復用連接,就可以減少由于TCP三次握手所帶來的時延。

HTTP 1.1默認開啟keep-alive機制,從上面抓到的包也可以看到。這樣,數據傳輸完成之后保持TCP連接不斷開,之后同域名下復用連接,繼續用這個通道傳輸數據。服務器在響應一個請求后,可以保持這個連接keep-alive timeout的時間,在這個時間內沒有請求,則關閉此連接;否則,重新開始倒計時keep-alive timeout時間。

HTTP有keep-alive機制,目的是可以在一個TCP連接上傳輸多個HTTP事務,以此提高通信效率。底層的TCP其實也有keep-alive機制,它是為了探測TCP連接的活躍性。TCP層的keepalive可以在任何一方設置,可以是一端設置、兩端同時設置或者兩端都沒有設置。新建socket的時候需要設置,從而使得協議棧調用相關函數tcp_set_keepalive,來激活連接的keep-alive屬性。

當網絡兩端建立了TCP連接之后,閑置(雙方沒有任何數據流發送往來)時間超過tcp_keepalive_time后,服務器內核就會嘗試向客戶端發送偵測包,來判斷TCP連接狀況(有可能客戶端崩潰、強制關閉了應用、主機不可達等等)。如果沒有收到對方的回答(ack包),則會在 tcp_keepalive_intvl后再次嘗試發送偵測包,直到收到對方的ack,如果一直沒有收到對方的ack,一共會嘗試 tcp_keepalive_probes次,每次的間隔時間在這里分別是15s, 30s, 45s, 60s, 75s。如果嘗試tcp_keepalive_probes次后,依然沒有收到對方的ack包,則會丟棄該TCP連接。TCP連接默認閑置時間是2小時,一般設置為30分鐘足夠了。

【管道化連接】:

在keep-alive的基礎上,我們可以做地更進一步,在響應到達之前,我們將多條請求按序放入請求隊列,服務端在收到請求后,必須按照順序對應請求的響應。但由于網絡環境非常復雜,因此即使請求是按順序發送的,也不一定是按順序到達服務端的。而且就算是服務端按序處理的,也不一定是按序返回給客戶端,所以最好是在響應中附帶一些可以標識請求的參數。

為了安全起見,管道化的連接只適合“冪等”的請求,一般我們認為:GET/HEAD/PUT/DELETE/TRACE/OPTIONS等方法都是冪等的。

7、本文小結

以上,就是所有HTTP的通信細節了,足夠在日常開發 作中使用了。更多沒有涉及的細節可以在用到的時候再去仔細研究。

文章看完了,不知道你對HTTP的理解有沒有更上一層樓?歡迎一起交流探討。

8、參考資料

[1]【http長連接】https://www.cnblogs.com/cswuyg/p/3653263.html

[2]【http/tcp keep alive】https://segmentfault.com/a/1190000012894416

[3]【http/tcp keep alive】http://www.nowamagic.net/academy/detail/23350305

[4]【http/tcp keep alive】https://laravel-china.org/articl ... n-the-http-protocol

[5]【tcp keep alive】http://blog.51cto.com/zxtong/1788252

[6]【http權威指南】https://book.douban.com/subject/10746113/

[7]【HTTP狀態碼】https://www.cnblogs.com/starof/p/5035119.html

[8]【HTTP協議】https://www.cnblogs.com/ranyonsue/p/5984001.html

[9]【HTTP狀態分類】http://www.runoob.com/http/http-status-codes.html

[10]【url編碼】http://www.ruanyifeng.com/blog/2010/02/url_encoding.html

附錄:更多網絡編程文章

TCP/IP詳解 - 第11章·UDP:用戶數據報協議

TCP/IP詳解 - 第17章·TCP:傳輸控制協議

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

TCP/IP詳解 - 第21章·TCP的超時與重傳

技術往事:改變世界的TCP/IP協議(珍貴多圖、手機慎點)

通俗易懂-深入理解TCP協議(上):理論基礎

通俗易懂-深入理解TCP協議(下):RTT、滑動窗口、擁塞處理

理論經典:TCP協議的3次握手與4次揮手過程詳解

理論聯系實際:Wireshark抓包分析TCP 3次握手、4次揮手過程

計算機網絡通訊協議關系圖(中文珍藏版)

UDP中一個包的大小最大能多大?

P2P技術詳解(一):NAT詳解——詳細原理、P2P簡介

P2P技術詳解(二):P2P中的NAT穿越(打洞)方案詳解

P2P技術詳解(三):P2P技術之STUN、TURN、ICE詳解

通俗易懂:快速理解P2P技術中的NAT穿透原理

高性能網絡編程(一):單臺服務器并發TCP連接數到底可以有多少

高性能網絡編程(二):上一個10年,著名的C10K并發連接問題

高性能網絡編程(三):下一個10年,是時候考慮C10M并發問題了

高性能網絡編程(四):從C10K到C10M高性能網絡應用的理論探索

高性能網絡編程(五):一文讀懂高性能網絡編程中的I/O模型

高性能網絡編程(六):一文讀懂高性能網絡編程中的線程模型

技術掃盲:新一代基于UDP的低延時網絡傳輸層協議——QUIC詳解

讓互聯網更快:新一代QUIC協議在騰訊的技術實踐分享

現代移動端網絡短連接的優化手段總結:請求速度、弱網適應、安全保障

聊聊iOS中網絡編程長連接的那些事

移動端IM開發者必讀(一):通俗易懂,理解移動網絡的“弱”和“慢”

移動端IM開發者必讀(二):史上最全移動弱網絡優化方法總結

IPv6技術詳解:基本概念、應用現狀、技術實踐(上篇)

IPv6技術詳解:基本概念、應用現狀、技術實踐(下篇)

從HTTP/0.9到HTTP/2:一文讀懂HTTP協議的歷史演變和設計思路

以網游服務端的網絡接入層設計為例,理解實時通信的技術挑戰

邁向高階:優秀Android程序員必知必會的網絡基礎

全面了解移動端DNS域名劫持等雜癥:技術原理、問題根源、解決方案等

美圖App的移動端DNS優化實踐:HTTPS請求耗時減小近半

Android程序員必知必會的網絡通信傳輸層協議——UDP和TCP

IM開發者的零基礎通信技術入門(一):通信交換技術的百年發展史(上)

IM開發者的零基礎通信技術入門(二):通信交換技術的百年發展史(下)

IM開發者的零基礎通信技術入門(三):國人通信方式的百年變遷

IM開發者的零基礎通信技術入門(四):手機的演進,史上最全移動終端發展史

IM開發者的零基礎通信技術入門(五):1G到5G,30年移動通信技術演進史

IM開發者的零基礎通信技術入門(六):移動終端的接頭人——“基站”技術

IM開發者的零基礎通信技術入門(七):移動終端的千里馬——“電磁波”

IM開發者的零基礎通信技術入門(八):零基礎,史上最強“天線”原理掃盲

IM開發者的零基礎通信技術入門(九):無線通信網絡的中樞——“核心網”

IM開發者的零基礎通信技術入門(十):零基礎,史上最強5G技術掃盲

IM開發者的零基礎通信技術入門(十一):為什么WiFi信號差?一文即懂!

IM開發者的零基礎通信技術入門(十二):上網卡頓?網絡掉線?一文即懂!

IM開發者的零基礎通信技術入門(十三):為什么手機信號差?一文即懂!

IM開發者的零基礎通信技術入門(十四):高鐵上無線上網有多難?一文即懂!

IM開發者的零基礎通信技術入門(十五):理解定位技術,一篇就夠

>> 更多同類文章 ……

(本文同步發布于:http://www.52im.net/thread-2456-1-1.html


只有注冊用戶登錄后才能發表評論。


網站導航:
 
Jack Jiang的 Mail: [email protected], 聯系QQ: 413980957, 微信: hellojackjiang
魔法糖果闯关 fg电子娱乐 吉林时时技巧 2018福彩30选5开奖号码 手游狂野飙车怎么赚钱攻略 广西11选5开奖结果查 七星彩开奖公告 重庆时时彩过年放假吗 中国浙江福利彩票官网 天津体育彩票十一选五 海南七星彩结果 双色球规律杀凤尾 加拿极速飞艇开奖记录 九龙彩票安卓 淘宝店赚钱知乎 篮球彩票中奖计算方法 ppt模板可以上传到哪里赚钱