DNS、HTTP、ICMP與shifen的探索
小伙伴們好呀，這節(jié)來分享下這個 ICMP協(xié)議 和 curl 訪問 http 網(wǎng)站時涉及到的協(xié)議。
ARP 協(xié)議補充
先補充一下上文的 ARP 協(xié)議。
80 35.374000 VMware_c0:00:08 VMware_5b:db:1a ARP 42 Who has 192.168.200.128? Tell 192.168.200.1
81 35.374560 VMware_5b:db:1a VMware_c0:00:08 ARP 42 192.168.200.128 is at 00:0c:29:5b:db:1a
圖片
MAC 地址是 6 字節(jié)，前三個是 廠商，后三個是序列號。
ICMP協(xié)議
Internet Control Message Protocol，互聯(lián)網(wǎng)控制報文協(xié)議。ping 的時候觸發(fā)。
這里直接在虛擬機上去 ping 192.168.2.187 (主機地址)
圖片
14 8.900476 192.168.200.128 192.168.2.187 ICMP 98 Echo (ping) request id=0x0904, seq=1/256, ttl=64 (reply in 15)
15 8.900943 192.168.2.187 192.168.200.128 ICMP 98 Echo (ping) reply id=0x0904, seq=1/256, ttl=128 (request in 14)可以看到，ping 請求時，這個報文的 type 是 8，表示 Echo (ping) request。
圖片
應(yīng)答時，這個 type 是 0 ，表示 (Echo (ping) reply)。
圖片
DNS 協(xié)議
域名系統(tǒng)，Domain Name System。
curl www.baidu.com訪問百度時，第一步就是這個 域名解析 了。
圖片
捕捉的包如下 ??
圖片
圖片
圖片對應(yīng) 21 的請求，可以發(fā)現(xiàn) DNS 基于 UDP（User Datagram Protocol） 用戶數(shù)據(jù)報協(xié)議。
同時有個 type 為 A 的類型，這個是請求 ipv4 地址的。
22 那里時 type : AAAA ，這個是 ipv6 地址的。
21 14.648767 192.168.200.128 192.168.200.2 DNS 73 Standard query 0x7abe A www.baidu.com
22 14.648817 192.168.200.128 192.168.200.2 DNS 73 Standard query 0xffc7 AAAA www.baidu.com以前搭建博客時，有個域名解析的環(huán)節(jié)，那會也要配置解析這個 A （后知后覺~）
下面看看 response 的數(shù)據(jù) ??
24 14.683310 192.168.200.2 192.168.200.128 DNS 132 Standard query response 0x7abe A www.baidu.com CNAME www.a.shifen.com A (ipv4地址) A (ipv4地址)
25 14.688004 192.168.200.2 192.168.200.128 DNS 156 Standard query response 0xffc7 AAAA www.baidu.com CNAME www.a.shifen.com AAAA (ipv6地址) AAAA (ipv6地址)CNAME 即 別名記錄
長知識了：百度的別名是 www.a.shifen.com
這里也是順利拿到了 ipv4 地址
圖片
吃瓜
哦嚯，無意間發(fā)現(xiàn)了大公司名字的另一層含義 ??
大家都是 shifen ??
圖片
圖片
HTTP 協(xié)議
圖片
DNS 解析成功后，拿到了這個 ip 地址，這里用的 ipv4 地址去建立 TCP 連接。
三次握手后，就發(fā)送 HTTP 請求了 ??。
29 14.714278 192.168.200.128 xxx.42 HTTP 131 GET / HTTP/1.1Get 請求如下，這個的 User-Agent 是 curl （平時見到的都是 瀏覽器 標志 ）
圖片
這個 TCP 的報文段大小是 77 ，同時 [Next Sequence Number: 78 (relative sequence number)]
圖片
響應(yīng) ??
從 30 這一條開始，這里 ACK = 78 剛好。
30 14.714429 ipv4 192.168.200.128 TCP 54 80 → 44626 [ACK] Seq=1 Ack=78 Win=64240 Len=0
31 14.733343 ipv4 192.168.200.128 TCP 1494 80 → 44626 [PSH, ACK] Seq=1 Ack=78 Win=64240 Len=1440 [TCP segment of a reassembled PDU]
32 14.733714 192.168.200.128 ipv4 TCP 54 44626 → 80 [ACK] Seq=78 Ack=1441 Win=31680 Len=0
33 14.733782 ipv4 192.168.200.128 HTTP 1395 HTTP/1.1 200 OK (text/html)主要看 31 和 33 這兩條，
PSH + ACK：用于傳輸數(shù)據(jù)并要求接收端立即交給應(yīng)用層處理。
這里數(shù)據(jù)長度超過了 MTU（Maximum Transmission Unit 最大傳輸單元）1500 個字節(jié)，要進行分片。
所以，31 中出現(xiàn) [TCP segment of a reassembled PDU]，意味著它不是完整的，只是 PDU（Protocol Data Unit 協(xié)議數(shù)據(jù)單元）的一部分。
在 33 中可以看到這個 重組TCP 的記錄 ??
[2 Reassembled TCP Segments (2781 bytes): #31(1440), #33(1341)]
圖片
接著就是 HTTP 的內(nèi)容了，和瀏覽器上看的差不多，就是 響應(yīng)行，頭，體 。就不多贅述了。
圖片
下面又是 TCP 四次揮手 的內(nèi)容了。
圖片
curl 結(jié)束后，立刻去查這個 半連接隊列 ，發(fā)現(xiàn)還在等待關(guān)閉。
圖片
等待 2MSL （linux 上 2MSL = 60s ）后，就關(guān)閉了。
sysctl net.ipv4.tcp_fin_timeout
圖片
最后，補充下這個 模型，看看之前介紹到的協(xié)議都在哪一層 ??
OSI 七層模型
+-------------------------+
7 | Application Layer | DNS，HTTP，SSH，Telnet，F(xiàn)TP 等
+-------------------------+
6 | Presentation Layer |
+-------------------------+
5 | Session Layer |
+-------------------------+
4 | Transport Layer | （段 segement）TCP，UDP
+-------------------------+
3 | Network Layer | （包 packet）ICMP，IP
+-------------------------+
2 | Data Link Layer | （幀 frame）ARP
+-------------------------+
1 | Physical Layer |
+-------------------------+TCP/IP四層
與 OSI 七層模型相比，TCP/IP 四層模型將 表示層 和 會話層 合并到了 應(yīng)用層 中，將 數(shù)據(jù)鏈路層 和 物理層 合并到了 鏈路層 中。
+-------------------------+
4 | Application Layer |
+-------------------------+
3 | Transport Layer |
+-------------------------+
2 | Internet Layer |
+-------------------------+
1 | Link Layer | 鏈路層
+-------------------------+
