使用 IP 地址訪問 Web 服務器

首先我們運行 www 目錄下的“start”批處理程序，啟動本機的 OpenResty 服務器，啟動后可以用“l(fā)ist”批處理確認服務是否正常運行。
然后我們打開 Wireshark，選擇“HTTP TCP port(80)”過濾器，再鼠標雙擊“Adapter for loopback traffic capture”，開始抓取本機 127.0.0.1 地址上的網絡數(shù)據。
第三步，在 Chrome 瀏覽器的地址欄里輸入“http://127.0.0.1/”，再按下回車鍵，等歡迎頁面顯示出來后 Wireshark 里就會有捕獲的數(shù)據包，如下圖所示。

抓包分析

下面我們就來一起分析一下"鍵入網址按下回車"后數(shù)據傳輸?shù)娜^程。
HTTP 協(xié)議是運行在 TCP/IP 基礎上的，依靠TCP/IP 協(xié)議來實現(xiàn)數(shù)據的可靠傳輸。所以瀏覽器要用 HTTP 協(xié)議收發(fā)數(shù)據，首先要做的就是建立 TCP 連接。
在地址欄里直接輸入了 IP 地址“127.0.0.1”，而 Web 服務器的默認端口是 80，所以瀏覽器就要依照 TCP 協(xié)議的規(guī)范，使用“三次握手”建立與 Web 服務器的連接。
經過 SYN、SYN/ACK、ACK 的三個包之后，瀏覽器與服務器的 TCP 連接就建立
起來了。
有了可靠的 TCP 連接通道后，HTTP 協(xié)議就可以開始工作了。于是，瀏覽器按照 HTTP 協(xié)議規(guī)定的格式，通過 TCP 發(fā)送了一個“GET / HTTP/1.1”請求報文。
隨后，Web 服務器回復了第五個包，在 TCP 協(xié)議層面確認：“剛才的報文我已經收到了”，不過這個 TCP 包 HTTP 協(xié)議是看不見的。
Web 服務器收到報文后在內部就要處理這個請求。同樣也是依據 HTTP 協(xié)議的規(guī)定，解析報文，看看瀏覽器發(fā)送這個請求想要干什么。
它一看，原來是要求獲取根目錄下的默認文件，好吧，那我就從磁盤上把那個文件全讀出來，再拼成符合 HTTP 格式的報文，發(fā)回去吧。這就是 Wireshark 里的第六個包“HTTP/1.1 200OK”，底層走的還是 TCP 協(xié)議。
同樣的，瀏覽器也要給服務器回復一個 TCP 的 ACK 確認，“你的響應報文收到了，多謝”，即第七個包。
這時瀏覽器就收到了響應數(shù)據，但里面是什么呢？所以也要解析報文。一看，服務器給我的是個 HTML 文件，好，那我就調用排版引擎、JavaScript 引擎等等處理一下，然后在瀏覽器窗口里展現(xiàn)出了歡迎頁面。
這之后還有兩個來回，共四個包，重復了相同的步驟。這是瀏覽器自動請求了作為網站圖標的“favicon.ico”文件，與我們輸入的網址無關。但因為我們的實驗環(huán)境沒有這個文件，所以服務器在硬盤上找不到，返回了一個“404 Not Found”。
至此，“鍵入網址再按下回車”的全過程就結束了。

這次最簡單的瀏覽器 HTTP 請求過程：
1.瀏覽器從地址欄的輸入中獲得服務器的 IP 地址和端口號；
2.瀏覽器用 TCP 的三次握手與服務器建立連接；
3.瀏覽器向服務器發(fā)送拼好的報文；
4.服務器收到報文后處理請求，同樣拼好報文再發(fā)給瀏覽器；
5.瀏覽器解析報文，渲染輸出頁面。

使用域名訪問 Web 服務器

剛才我們是在瀏覽器地址欄里直接輸入 IP 地址，但絕大多數(shù)情況下，我們是不知道服務器 IP地址的，使用的是域名，那么改用域名后這個過程會有什么不同嗎？

還是實際動手試一下吧，把地址欄的輸入改成“http://www.chrono.com”，重復
Wireshark 抓包過程，你會發(fā)現(xiàn)，好像沒有什么不同，瀏覽器上同樣顯示出了歡迎界面，抓到的包也同樣是 11 個：先是三次握手，然后是兩次 HTTP 傳輸。
這里就出現(xiàn)了一個問題：瀏覽器是如何從網址里知道“www.chrono.com”的 IP 地址就是
“127.0.0.1”的呢？
瀏覽器看到了網址里的“www.chrono.com”，發(fā)現(xiàn)它不是數(shù)字形式的 IP 地址，那就肯定是域名了，于是就會發(fā)起域名解析動作，通過訪問一系列的域名解析服務器，試圖把這個域名翻譯成 TCP/IP 協(xié)議里的 IP 地址。
不過因為域名解析的全過程實在是太復雜了，如果每一個域名都要大費周折地去網上查一下，那我們上網肯定會慢得受不了。
所以，在域名解析的過程中會有多級的緩存，瀏覽器首先看一下自己的緩存里有沒有，如果沒有就向操作系統(tǒng)的緩存要，還沒有就檢查本機域名解析文件 hosts
剛好，里面有一行映射關系“127.0.0.1 www.chrono.com”，于是瀏覽器就知道了域名對應的 IP 地址，就可以愉快地建立 TCP 連接發(fā)送 HTTP 請求了。
我把這個過程也畫出了一張圖，但省略了 TCP/IP 協(xié)議的交互部分，里面的瀏覽器多出了一個訪問 hosts 文件的動作，也就是本機的 DNS 解析。

真實的網絡世界

第一個實驗是最簡單的場景，只有兩個角色：瀏覽器和服務器，瀏覽器可以直接用 IP 地址找到服務器，兩者直接建立 TCP 連接后發(fā)送 HTTP 報文通信。
第二個實驗在瀏覽器和服務器之外增加了一個 DNS 的角色，瀏覽器不知道服務器的 IP 地址，所以必須要借助 DNS 的域名解析功能得到服務器的 IP 地址，然后才能與服務器通信。

如果你用的是電腦臺式機，那么你可能會使用帶水晶頭的雙絞線連上網口，由交換機接入固定網絡。如果你用的是手機、平板電腦，那么你可能會通過蜂窩網絡、WiFi，由電信基站、無線熱點接入移動網絡。
假設你要訪問的是 Apple 網站，顯然你是不知道它的真實 IP 地址的，在瀏覽器里只能使用域名“www.apple.com”訪問，那么接下來要做的必然是域名解析。這就要用 DNS 協(xié)議開始從操作系統(tǒng)、本地 DNS、根 DNS、頂級 DNS、權威 DNS 的層層解析，當然這中間有緩存，可能不會費太多時間就能拿到結果。
別忘了互聯(lián)網上還有另外一個重要的角色 CDN，它也會在 DNS 的解析過程中“插上一
腳”。DNS 解析可能會給出 CDN 服務器的 IP 地址，這樣你拿到的就會是 CDN 服務器而不是目標網站的實際地址。
因為 CDN 會緩存網站的大部分資源，比如圖片、CSS 樣式表，所以有的 HTTP 請求就不需要再發(fā)到 Apple，CDN 就可以直接響應你的請求，把數(shù)據發(fā)給你。
由 PHP、Java 等后臺服務動態(tài)生成的頁面屬于“動態(tài)資源”，CDN 無法緩存，只能從目標網站獲取。于是你發(fā)出的 HTTP 請求就要開始在互聯(lián)網上的“漫長跋涉”，經過無數(shù)的路由器、網關、代理，最后到達目的地。
目標網站的服務器對外表現(xiàn)的是一個 IP 地址，但為了能夠扛住高并發(fā)，在內部也是一套復雜的架構。通常在入口是負載均衡設備，例如四層的 LVS 或者七層的 Nginx，在后面是許多的服務器，構成一個更強更穩(wěn)定的集群。
負載均衡設備會先訪問系統(tǒng)里的緩存服務器，通常有 memory 級緩存 Redis 和 disk 級緩存Varnish，它們的作用與 CDN 類似，不過是工作在內部網絡里，把最頻繁訪問的數(shù)據緩存幾秒鐘或幾分鐘，減輕后端應用服務器的壓力。
如果緩存服務器里也沒有，那么負載均衡設備就要把請求轉發(fā)給應用服務器了。這里就是各種開發(fā)框架大顯神通的地方了，例如 Java 的 Tomcat/Netty/Jetty，Python 的 Django，還有PHP、Node.js、Golang 等等。它們又會再訪問后面的 MySQL、PostgreSQL、MongoDB等數(shù)據庫服務，實現(xiàn)用戶登錄、商品查詢、購物下單、扣款支付等業(yè)務操作，然后把執(zhí)行的結果返回給負載均衡設備，同時也可能給緩存服務器里也放一份。
應用服務器的輸出到了負載均衡設備這里，請求的處理就算是完成了，就要按照原路再走回去，還是要經過許多的路由器、網關、代理。如果這個資源允許緩存，那么經過 CDN 的時候它也會做緩存，這樣下次同樣的請求就不會到達源站了。

最后網站的響應數(shù)據回到了你的設備，它可能是 HTML、JSON、圖片或者其他格式的數(shù)據，需要由瀏覽器解析處理才能顯示出來，如果數(shù)據里面還有超鏈接，指向別的資源，那么就又要重走一遍整個流程，直到所有的資源都下載完。

小結

1.HTTP 協(xié)議基于底層的 TCP/IP 協(xié)議，所以必須要用 IP 地址建立連接；
2.如果不知道 IP 地址，就要用 DNS 協(xié)議去解析得到 IP 地址，否則就會連接失?。?br> 3.建立 TCP 連接后會順序收發(fā)數(shù)據，請求方和應答方都必須依據 HTTP 規(guī)范構建和解析報文；
4.為了減少響應時間，整個過程中的每一個環(huán)節(jié)都會有緩存，能夠實現(xiàn)“短路”操作；
5.雖然現(xiàn)實中的 HTTP 傳輸過程非常復雜，但理論上仍然可以簡化成實驗里的“兩點”模型。文章來源地址http://www.zghlxwxcb.cn/news/detail-477096.html

PS：本文是觀看極客之后的筆記。

到了這里，關于HTTP第六講——鍵入網址再按下回車，后面究竟發(fā)生了什么？的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網！