瀏覽器訪問網站
這個僅僅是我個人對於訪問網站流程的一個理解,我相信肯定有不全面也有錯漏的地方,如果是的各位可以給我指出來讓我可以有所提高~
五層協議體系結構中各層運用到的協議:
應用層:HTTP、DNS;
傳輸層:TCP、UDP;
網路層:IP、ARP;
網路介面層:MAC。
瀏覽器訪問百度過程:
1、電腦開機,確保清空ARP、DNS等。在cmd 視窗中通過arp –a 和ipconfig /displaydns查詢ARP、DNS。
①向瀏覽器輸入百度:www.baidu.com,瀏覽器將資訊http://
www.baidu.com傳遞給應用層,到達應用層後加上應用層首部,成為HTTP GET
報文段,請求該網站根目錄下預設檔案。然後傳送到運輸層,但由於TCP
②在運輸層中使用TCP協議以建立TCP連線,封裝後傳送到網路層。TCP報文段到達網路層後再次封裝形成IP資料報,但由於百度是域名,因此在HOST檔案和DNS快取中查詢,但由於剛開機所以查詢失敗,因此將IP資料報快取,且返回應用層。
③返回應用層後啟動DNS,利用DNS請求報文查詢www.baidu.com的IP地址,傳送到運算層封裝為UDP資料報,再傳送到網路層封裝為IP資料報。再傳送到資料鏈路層查詢閘道器的MAC地址,但由於ARP快取為空,因此查詢MAC地址失敗。因此將含有DNS請求報文段的IP資料報快取,且返回網路層。
④返回網路層後啟動ARP
廣播幀傳送到集線器,然後在傳送到PC2和R1。PC2不對應該目的IP地址因此丟棄該資料幀。閘道器R1接收到該廣播幀後,傳送到物理層,在傳送到資料鏈路層,在傳送到網路層,去掉首部,判斷IP是否一致,IP地址一致則R2對應該目的IP地址,接收請求報。然後生成ARP應答包封裝成單播幀,傳送到資料鏈路層,在傳送到物理層閘道器通過單播發送到集線器返回在傳送給PC1。PC1接收到ARP應答包“10.0.153.254
在 00:0F:E2:AA:97:12
主機收到ARP響應分組後在ARP快取記憶體中寫入閘道器的IP地址到硬體地址的對映。
序號 |
源地址 |
目標地址 |
協議 |
大小 |
概要 |
187 |
78:E3:B5:A4:8A:15 |
FF:FF:FF:FF:FF:FF |
ARP |
46 |
誰是 10.0.153.254? 告訴 10.0.153.10 |
188 |
00:0F:E2:AA:97:12 |
78:E3:B5:A4:8A:15 |
ARP |
64 |
10.0.153.254 在 00:0F:E2:AA:97:12 |
在cmd 視窗中通過arp –a 查詢ARP 。
⑤得到MAC閘道器後取出快取的含有DNS請求報文段的IP資料報,封裝為單播幀,傳送到資料鏈路層,再傳送到集線器,然後傳送到R1,IP資料報排隊等待。等待結束後,R1接收該IP資料報,傳送到物理層,再傳送到資料鏈路層,再傳送到網路層。R1選擇路由器介面,然後選擇為右介面,TTL-1。便傳送將IP資料報傳送到網路層,再傳送到資料鏈路層,再傳送到物理層轉換為二進位制位元流,在傳送到下一個路由器R2,IP資料報排隊等待。
R2接收該IP資料報,傳送到物理層,再傳送到資料鏈路層,再傳送到網路層。R2選擇路由器介面,然後選擇為右介面,TTL-1。便傳送將IP資料報傳送到網路層,再傳送到資料鏈路層,再傳送到物理層轉換為二進位制位元流,再傳送到交換機。
交換機接收該IP資料報,傳送到物理層,再傳送到資料鏈路層。交換機查尋轉發表,得到DNS伺服器的接收埠。再傳送將IP資料報傳送到資料鏈路層,再傳送到物理層轉換為二進位制位元流,再傳送到DNS伺服器。
DNS伺服器依據源MAC地址進行學習然後生成DNS應答包並封裝成單播幀,按原路回送。PC1接收到DNS應答包,得到www.baidu.com的IP 地址。
序號 |
源地址 |
目標地址 |
協議 |
大小 |
概要 |
789 |
10.0.153.10:54401 |
10.0.15.11:53 |
DNS |
77 |
C: Q=baidu.com.(A) |
790 |
10.0.15.11:53 |
10.0.153.10:54401 |
DNS |
363 |
S: Q=www.baidu.com(A) A=112.80.248.74 A=112.80.248.73 |
傳送問題一條,收到答案7條,權威答案13條,附加答案2條。其中答案如下:其中答案如下:
⑥得到百度的IP地址:112.80.248.74後取出快取的含TCP連線請求的IP資料報,封裝為單播幀,轉換為位元流再發送到集線器,R1,R2,交換機,百度伺服器。百度伺服器接收到TCP連線請求,便按原路返回,傳送同意TCP連線的IP資料報。PC1接收到同意TCP連線的IP資料報後,再發出確認收到同意TCP連線的IP資料報的資料報。完成“三次握手”,成功建立TCP連線。
序號 |
源埠 |
目標埠 |
協議 |
大小 |
序列號 |
確認號 |
ACK |
SYN |
879 |
63117 |
80 |
TCP |
70 |
3873156153 |
0 |
0 |
1 |
889 |
80 |
63117 |
TCP |
70 |
3586524917 |
3873156154 |
1 |
1 |
884 |
63117 |
80 |
TCP |
58 |
3873156154 |
3586524918 |
1 |
0 |
⑦TCP連線建立後,取HTTP GET 報文段快取,將HTTP GET報文段傳送到運輸層,封裝成IP資料報,然後傳送到資料鏈路層,再發送到物理層轉換為位元流。依次傳送到集線器,R1,R2,交換機,百度伺服器。
序號 |
源埠 |
目標埠 |
協議 |
大小 |
序列號 |
確認號 |
ACK |
PSH |
885 |
63117 |
80 |
HTTP GET |
634 |
3873156154 |
3586524918 |
1 |
1 |
⑧百度伺服器接收到HTTP GET 的IP資料報後確認收到IP資料報。並依據文件標籤檔名在WWW.root 中尋找 index.htm 檔案。
序號 |
源埠 |
目標埠 |
協議 |
大小 |
序列號 |
確認號 |
ACK |
PSH |
886 |
80 |
63117 |
TCP |
64 |
3586524918 |
3873156730 |
1 |
0 |
887 |
80 |
63117 |
HTTP Text |
486 |
3586524918 |
3873156730 |
1 |
1 |
888 |
80 |
63117 |
HTTP Text |
273 |
3586525346 |
3873156730 |
1 |
1 |
序號887內容:S: HTTP/1.1 302 Moved Temporarily; Content-Type: text/html
序號888內容:S: HTTP資料包,負載資料215位元組
⑨瀏覽器解釋迴應資訊,並顯示在瀏覽器中。
序號 |
源埠 |
目標埠 |
協議 |
大小 |
序列號 |
確認號 |
ACK |
PSH |
889 |
63117 |
80 |
TCP |
58 |
3873156730 |
3586525561 |
1 |
0 |
⑩關閉瀏覽器
百度是HTTP協議,而HTTP的埠號80,TCP連線控制為保持連線,因此在抓包中無法抓取TCP連線斷開時產生的4次揮手的資料包
小提示:
其實我還是一個學生,因此一開始時候我用的是校園網然後就發現了一些問題:
1.在宿舍內使用校園網訪問百度時目標斷開不正確。
由於在宿舍內訪問校園網是通過登入iNode登入客戶端然後進行訪問網路的,因此目標埠不會是80,而是443。另外嘗試通過電腦連線WIFI進行網路訪問,發現無論目標埠號甚至是ARP請求,DNS的訪問也會有極大的差異。因此如果要求目標埠為80的話,需要選擇在不需要通過其他軟體登入上網的電腦上進行抓包。
2.TCP連結斷開的資料包無法抓取。
正常情況下TCP連結斷開會有“四次揮手”,但由於TCP的連結斷開時有伺服器控制的,而埠號為80的伺服器通常是無法進行“四次揮手”斷開連結的,因此在訪問百度抓包過程中是無法抓取“四次揮手”的資料包的。
另外正常情況下,“四次揮手”情況如下:
第一次:client to server FIN=1;第二次:server to client ACK=1;第三次:server to client FIN=1,ACK=1;第四次:client to server ACK=1。