婷婷基地五月,A片免费高清在线观看,五月天爱爱网,免费a级黄片,成人毛片基地,日本韓淫屄一区二区三区,丁香五月国产,日本黄色色情视频

? 今天用 postman 發(fā)了請求

GET http://www.flashhost.com/check

只返回了一個字符串

success

整個過程的網絡包，用 wireshark 全都抓下來了

用簡單的方式寫在下面就是這個樣子滴

A?和 B 分別代表我本機的 IP 和遠程服務的 IP 地址

黑色代表包的方向是 A?-> B，藍色則相反

三次握手

A->B? ?TCP? ?[SYN]

A<-B? ?TCP? ?[SYN,ACK]

A->B? ?TCP? ?[ACK]

HTTP 請求

A->B? ?HTTP? GET / HTTP/1.1

A<-B? ?TCP? ? [ACK]

A<-B? ?HTTP? 200(text/plain)

A->B? ?TCP? ? [ACK]

Keep-Alive

A->B? ?TCP? ? [TCP Keep-Alive]

A<-B? ?TCP? ? [TCP Keep-Alive ACK]

A->B? ?TCP? ? [TCP Keep-Alive]

A<-B? ?TCP? ? [TCP Keep-Alive ACK]

...（幾分鐘后）

A->B? ?TCP? ? [TCP Keep-Alive]

A<-B? ?TCP? ? [TCP Keep-Alive ACK]

四次揮手

A<-B? ?TCP? ? [FIN,ACK]

A->B? ?TCP? ? [ACK]

A->B? ?TCP? ? [FIN,ACK]

A<-B? ?TCP? ? [ACK]

這么多包，我看心情點開了 A->B 發(fā)送的第一個 HTTP 協(xié)議的包

A->B? ?HTTP? GET / HTTP/1.1

在 wireshark 里查看它的詳情

aa aa aa aa?aa?aa bb?bb bb bb bb bb 08 00 45 00 01 1d 6d 7e 40 00 80 06 00 00 c0 a8 1f a4 6e f2 44 04 db 08 00 50 2c 85 bd c9 05 ae c5 63 50 18 02 02 94 52 00 00 47 45 54 20 63 68 65 63 6b 20 48 54 54 50 2f 31 2e 31 0d 0a 0d 0a

沒錯，這一長串用 16 進制表示的數(shù)據，就是從網卡直接發(fā)出去的數(shù)據，一個字節(jié)都沒有省略

來，給你一分鐘時間肉眼拆一下包

一

分

鐘

思

考

時

間

哈哈，還是我來吧

數(shù)據鏈路層

aa aa aa aa?aa?aa bb?bb?bb?bb?bb?bb?08 00 45 00 01 1d 6d 7e 40 00 80 06 00 00 c0 a8 1f a4 6e f2 44 04 db 08 00 50 2c 85 bd c9 05 ae c5 63 50 18 02 02 94 52 00 00 47 45 54 20 63 68 65 63 6b 20 48 54 54 50 2f 31 2e 31 0d 0a 0d 0a

最開頭是數(shù)據鏈路層，使用的協(xié)議是?Ethernet?以太網協(xié)議，協(xié)議格式如下：

原地址（6字節(jié)）：aa?aa?aa?aa?aa?aa（mac地址）
目標地址（6字節(jié)）：bb?bb?bb?bb?bb?bb（mac地址）
類型（2字節(jié)）：08 00（ipv4）
數(shù)據：45 00 01 ... ... ...

原地址和目標地址其實是?mac 地址，這里我用了假的，怕你們人肉我哈哈

類型是指其上一層，也就是后面的數(shù)據部分的協(xié)議類型，這里的??08 00 指的是 IP 協(xié)議（ipv4）

后面對于數(shù)據鏈路層來說，就是一堆數(shù)據了，它不關心是什么

網絡層

我們把數(shù)據鏈路層去掉，也就相當于?拆包

aa aa aa aa?aa?aa bb?bb?bb?bb?bb?bb?08 00?45 00 01?1d 6d 7e 40 00 80 06 00 00 c0 a8 1f a4 6e f2 44 04 db 08 00 50 2c 85 bd c9 05 ae c5 63 50 18 02 02 94 52 00 00 47 45 54 20 63 68 65 63 6b 20 48 54 54 50 2f 31 2e 31 0d 0a 0d 0a

拆包后的開頭部分就是網絡層，使用的協(xié)議當然就是上面數(shù)據鏈路層指定的 IP 協(xié)議，它的數(shù)據格式如下：

信息太多，只提取幾個關鍵的信息

協(xié)議：06（TCP）
源地址：c0 a8 1f a4（IP地址：192.168.31.164）
目的地址：6e f2 44 04（IP地址：110.242.68.4）
數(shù)據：db 08 00 50?... ... ...

其實和上面數(shù)據鏈路層的分析過程一樣，關鍵信息還是這些，協(xié)議表示上一層也就是數(shù)據部分的協(xié)議是 TCP 協(xié)議，源地址和目的地址不再是 mac，在網絡層就表示 IP 地址了。

這里的地址為啥不用假的呢？因為源地址是我局域網的地址你知道了也沒用，目的地址是百度，哈哈你去人肉吧~

收~

我們接著拆...

傳輸層

再次去掉網絡層的 IP 協(xié)議的首部

aa aa aa aa?aa?aa bb?bb?bb?bb?bb?bb?08 00?45 00 01?1d 6d 7e 40 00 80 06 00 00 c0 a8 1f a4 6e f2 44 04?db 08 00 50 2c 85 bd c9 05 ae c5 63 50 18 02 02 94 52 00 00 47 45 54 20?63 68 65 63 6b 20 48 54 54 50 2f 31 2e 31 0d 0a 0d 0a

剩下的開頭部分，就到了數(shù)據傳輸層，由于在網絡層中已經指出，其上一層的數(shù)據部分是 TCP 協(xié)議，所以接下來用 TCP 協(xié)議的格式來分析就好了

TCP?協(xié)議大家都知道，超級多的細節(jié)，這里不展開，仍然提取關鍵信息，走主流程

源端口：db 08（端口號：56072）
目的端口：00 50（端口號：80）
數(shù)據：47 45 54 20?... ..

這里的源和目的不再是 mac 地址，也不再是 IP 地址了，因為此時包已經到達了目標機器，需要找具體對應的進程，所以這里是端口號。

同樣由于進程自己知道將以什么樣的協(xié)議，來解讀數(shù)據部分，所以這里也沒有上層協(xié)議的指定，因為這已經是應用程序的事了。

我們接著拆...

應用層

再次去掉傳輸層的 TCP 協(xié)議的首部

aa aa aa aa?aa?aa bb?bb?bb?bb?bb?bb?08 00?45 00 01?1d 6d 7e 40 00 80 06 00 00 c0 a8 1f a4 6e f2 44 04?db 08 00 50 2c 85 bd c9 05 ae c5 63 50 18 02 02 94 52 00 00?47 45 54 20?63 68 65 63 6b 20 48 54 54 50 2f 31 2e 31 0d 0a 0d 0a

就來到了我們最熟悉的應用層，使用的協(xié)議是什么呢？因為我知道我請求的服務是提供 HTTP 協(xié)議的 web 服務，同時我發(fā)送的也是 HTTP 協(xié)議的數(shù)據，所以使用的協(xié)議當然就是 HTTP 協(xié)議啦~

請求行：47 ... 0a（GET /check HTTP/1.0 \r\n）
請求頭：無
請求體：無
最后：0d 0a（\r\n）

難怪熟悉，只看結構確實簡單，且容易理解，都可以轉換成字符來解讀

今天沒做什么，就是拆了個包

其實我手動拆包的過程，也是各種硬件或軟件拆包的過程，就是將數(shù)據的指針不斷往后移動而已。

然后每一層都有不同的協(xié)議來解讀，剛剛上述過程的協(xié)議，只是我向一個提供 http 協(xié)議的 web 服務器發(fā)請求所用到的各層協(xié)議，不過這也是最常見的了，所以今天就簡單帶你抓個包梳理下。

留個小問題，網絡分層不是還有個 物理層 么？為啥文中沒有寫呢？

我們下期再見！

等

忘了我還做了個小動畫，放上來吧

其實這個動畫你看完了啥用沒有，我只是想

抓了個包，搞懂了網絡

三次握手

HTTP 請求

Keep-Alive

四次揮手

數(shù)據鏈路層

網絡層

傳輸層

應用層