40張圖揭秘，「鍵入網(wǎng)址發(fā)生了什么」

計算機網(wǎng)絡(luò)的重要程度不言而言，也是非常的復(fù)雜。今天我將從輸入URL這個簡單例子開始，一起探索數(shù)據(jù)包的心路歷程。先看文章的大綱。

大綱

?

1 源頭------網(wǎng)址

網(wǎng)址即平時所說的URL。就是經(jīng)常使用的以“Http://”開頭的那一串東東，其實常用的還有很多，比如 "FTP" , "FILE"等，我們所訪問的目標網(wǎng)站不同，網(wǎng)址開頭的寫法也就不同，下面列出常見的幾種URL。

URL基本格式

從上圖可知，URL 中可以包含服務(wù)器的域名，文件的路徑，收件人郵件地址，用戶名，密碼等信息?？傊甎RL想表達的是：

• 訪問時所使用的協(xié)議。"HTTP" , "FTP" , "FILE"等
• 用戶名/密碼可選
• 所需訪問或下載文件的路徑

URL的相貌我們已經(jīng)銘記于心，而且對于 URL 各個子模塊也有了基本的認識，可別小看這幾個小模塊，慢工出細活。我們拆分后仔細看看

• URL拆分
• 理解URL個元素的含義

URL的拆分

這里注意，dir 后面的文件名被省略了，這樣的話服務(wù)器會使用默認的文件名，就反復(fù)咱們定義變量的時候，如果沒有賦初值，通常會給默認值。同樣的道理，服務(wù)器也會給一個默認的文件名，不同的服務(wù)器默認的文件會不一樣，通常會是 Index.html。

這個就比較狠了，后面的"/"直接沒有，那該訪問啥呢？如果沒有路徑名，則代表訪問根目錄下面設(shè)置的默認文件。

這末尾的 whatisthis 是什么呢？在這種情況，如果服務(wù)器中存在 whatisthis 的文件，則按照文件處理。如果是 wahtsthis 為目錄，則按照目錄進行處理。

?

2 HTTP初探

通過第一步對URL的解析，知道了我們所訪問的目標是什么，接下來是不是就要請求數(shù)據(jù)了呢？在做請求之前，我們一起回憶一下HTTP的基礎(chǔ)知識

• GET

• POST

?

3 HTTP請求頭------保命天子

看到這里，我相信大家應(yīng)該了解了 HTTP 的大概樣貌。萬事兒都是有原則的，那么請求的也是有格式的，不聽話就要被打屁屁。

4 HTTP響應(yīng)-----我行我素

響應(yīng)的內(nèi)容和請求信息的內(nèi)容類似。只是響應(yīng)中的第一行內(nèi)容為狀態(tài)碼，表示執(zhí)行結(jié)果是否成功。常見的HTTP狀態(tài)碼如下圖所示

• Get和Post哪些區(qū)別
• 請求頭和響應(yīng)頭哪些位置是需要空格或者空行
• 常用響應(yīng)狀態(tài)碼和請求方法

到此，我們從表面上知道，從敲入網(wǎng)址，構(gòu)造請求消息，收到響應(yīng)，并能將美女圖片給呈現(xiàn)在眼前，這樣就完事了？不好意思，我們時刻都有一顆的去大廠的心，意味著我們不能只知道表面現(xiàn)象還要適當去了解更多的細節(jié)。

?

5 刨根

雖然瀏覽器能夠解析我們的網(wǎng)址，但是它并不具備將消息發(fā)送到網(wǎng)絡(luò)中的能力，那是誰打的輔助？當然是操作系統(tǒng)大哥，為了讓操作系統(tǒng)大哥幫忙，我們得先拜訪下操作系統(tǒng)大哥，問問需要我們提供哪些資源，需要什么，我們就全力配合它。

• IP地址

我們在瀏覽器輸入的是網(wǎng)址，但是操作系統(tǒng)需要的是IP地址，所以我們需要想辦法進行轉(zhuǎn)換。轉(zhuǎn)換的方法就需要請教 DNS 了。很簡單，我們告訴DNS，"我的域名是www.xiaolan.com，請告訴我的 IP 地址"，OK，DNS服務(wù)器很爽快，回復(fù)"你的IP地址是xxx.xxx.xxx.xxx"。那么問題來了，我們是如何向 DNS 發(fā)送的這個查詢呢？我們先來復(fù)習(xí)DNS

說了這么多，協(xié)議頭部，到底有哪些字段，其含義是什么都還不知道，那怎么去分析報文，下面我們一起再看看報文什么樣子

DNS報文基礎(chǔ)部分為DNS首部。其中包含了事務(wù)ID，標志，問題計數(shù)，回答資源計數(shù)，回答計數(shù)，權(quán)威名稱服務(wù)器計數(shù)和附加資源記錄數(shù)。

• 事務(wù)ID:報文標識，用來區(qū)分 DNS 應(yīng)答報文是對哪個請求進行響應(yīng)
• 標志:DNS 報文中標志字段
• 問題計數(shù)：DNS 查詢請求了多少次
• 回答資源記錄數(shù)：DNS 響應(yīng)了多少次
• 權(quán)威名稱服務(wù)器計數(shù): 權(quán)威名稱服務(wù)器數(shù)目
• 附加資源記錄數(shù): 權(quán)威名稱服務(wù)器對應(yīng) IP 地址的數(shù)目

• QR(Response)：查詢請求，值為0；響應(yīng)為1
• Opcode:操作碼。0表示標準查詢；1表示反向查詢；2服務(wù)器狀態(tài)請求
• AA（Authoritative）：授權(quán)應(yīng)答，該字段在響應(yīng)報文中有效。通過0,1區(qū)分是否為權(quán)威服務(wù)器。如果值為 1 時，表示名稱服務(wù)器是權(quán)威服務(wù)器；值為 0 時，表示不是權(quán)威服務(wù)器。
• TC（Truncated）：表示是否被截斷。當值為1的時候時，說明響應(yīng)超過了 512字節(jié)并已被截斷，此時只返回前512個字節(jié)。
• RD（Recursion Desired）：期望遞歸。該字段能在一個查詢中設(shè)置，并在響應(yīng)中返回。該標志告訴名稱服務(wù)器必須處理這個查詢，這種方式被稱為一個遞歸查詢。如果該位為 0，且被請求的名稱服務(wù)器沒有一個授權(quán)回答，它將返回一個能解答該查詢的其他名稱服務(wù)器列表。這種方式被稱為迭代查詢。
• RA（Recursion Available）：可用遞歸。該字段只出現(xiàn)在響應(yīng)報文中。當值為 1 時，表示服務(wù)器支持遞歸查詢。
• Z：保留字段，在所有的請求和應(yīng)答報文中，它的值必須為 0。
• rcode（Reply code）：通過返回只判斷相應(yīng)的狀態(tài)。

當值為0時，表示沒有錯誤；當值為1時，表示報文格式錯誤（Format error），服務(wù)器不能理解請求的報文；當值為 2 時，表示域名服務(wù)器失?。⊿erver failure），因為服務(wù)器的原因?qū)е聸]辦法處理這個請求；當值為 3 時，表示名字錯誤（Name Error），只有對授權(quán)域名解析服務(wù)器有意義，指出解析的域名不存在；當值為 4 時，表示查詢類型不支持（Not Implemented），即域名服務(wù)器不支持查詢類型；當值為 5 時，表示拒絕（Refused），一般是服務(wù)器由于設(shè)置的策略拒絕給出應(yīng)答，如服務(wù)器不希望對某些請求者給出應(yīng)答。

• 查詢名:一般為查詢的域名，也可能是通過IP地址進行反向查詢
• 查詢類型：查詢請求的資源類型。常見的如果為A類型，表示通過域名獲取IP。具體如下圖所示

• 查詢類：地址類型，通常為互聯(lián)網(wǎng)地址為1

資源記錄部分包含回答問題區(qū)域，權(quán)威名稱服務(wù)器區(qū)域字段、附加信息區(qū)域字段，格式如下

資源記錄部分

• 域名：所請求的域名
• 類型：與問題部分查詢類型值一直
• 類：地址類型，和問題部分查詢類值一樣
• 生存時間：以秒為單位，表示資源記錄的生命周期
• 資源數(shù)據(jù)長度：資源數(shù)據(jù)的長度
• 資源數(shù)據(jù)：按照查詢要求返回的相關(guān)資源數(shù)據(jù)

知道了DNS大概是什么，它的域名結(jié)構(gòu)和報文結(jié)構(gòu)，是時候看看到底怎么解析的以及如何保證域名的解析比較穩(wěn)定和可靠

域名結(jié)構(gòu)

• 訪問根域名服務(wù)器，這樣我們就會知道"com"頂級域名的地址
• 訪問"com"頂級域名服務(wù)器，可知道"google.com"域名服務(wù)器的地址
• 最后方位"google.com"域名服務(wù)器，就可知道"www.google.com"的IP地址

域名解析

• 客戶端發(fā)送一個 DNS 請求，請問 qq 你的IP的什么啊，同時會在本地域名服務(wù)器(一般是網(wǎng)絡(luò)服務(wù)是臨近機房)打聲招呼
• 本地收到請求以后，服務(wù)器會有個域名與IP的映射表。如果存在，則會告訴你，如果想訪問qq，那么你就訪問XX地址。不存在則會去問上級(根域服務(wù)器):"老鐵，你能告訴我 www.qq.com"的IP么
• 根 DNS 收到本地 DNS 請求后，發(fā)現(xiàn)是.com，"www.qq.com喲，這個由.com大哥管理，我馬上給你它的頂級域名地址，你去問問它就好了"
• 這個時候，本地 DNS 跑去問頂級域名服務(wù)器，"老哥，能告訴下www.qq.com"的ip地址碼",這些頂級域名負責(zé)二級域名比如qq.com
• 頂級域名回復(fù)："小本本記好，我給你 www.qq.com 區(qū)域的權(quán)威 DNS 服務(wù)器地址"，它會告訴你
• 本地DNS問權(quán)威DNS服務(wù)器："兄弟，能不能告訴我 www.qq.com 對應(yīng)IP是啥"
• 權(quán)威DNS服務(wù)器查詢后將響應(yīng)的IP地址告訴了本地 DNS，本地服務(wù)器將 IP 地址返回給客戶端，從而建立連接。

那如果我們寫段cs程序都得這么麻煩的？不不，上面的是大佬們做好，我們只需要使用相關(guān)庫就好了，這里就得說說Socket庫了。

• 創(chuàng)建套接字階段
• 管子連接到服務(wù)端套接字
• 收發(fā)數(shù)據(jù)
• 斷開并刪除套接字

那么再具體的實現(xiàn)中是怎樣的呢？

• 最上面是網(wǎng)絡(luò)應(yīng)用程序，其中包含了瀏覽器，郵件客戶端等，緊接著是Socket庫，其中一個功能就是向 DNS服務(wù)器發(fā)出請求獲取IP。
• 往下是操作系統(tǒng)大哥內(nèi)臟，其中包含了協(xié)議棧。上面是傳輸層常見的TCP和UDP，分別負責(zé) TCP 協(xié)議的收發(fā)數(shù)據(jù)和 UD P的首發(fā)數(shù)據(jù)。
• 往下是IP，控制網(wǎng)絡(luò)數(shù)據(jù)包的收發(fā)操作。主要負責(zé)將網(wǎng)絡(luò)數(shù)據(jù)包發(fā)送給通信對象。其中包含ICMP，ARP等協(xié)議。其中ICMP主要負責(zé)告知網(wǎng)絡(luò)數(shù)據(jù)包在發(fā)送的過程中產(chǎn)生的錯誤信息，ARP負責(zé)根據(jù)IP地質(zhì)查詢MAC地質(zhì)
• 再往下就是網(wǎng)卡驅(qū)動負責(zé)的硬件網(wǎng)卡了。直白點說是對網(wǎng)線的信號執(zhí)行發(fā)送接收操作

• 描述符

connnet會將描述符告訴協(xié)議棧，協(xié)議棧知道描述符后就來判斷到底使用哪個套接字去連接服務(wù)端

• 地址

這個IP地址即使剛才我們通過DNS獲取的IP地址，并將IP地址告知協(xié)議棧

• 端口

IP地址是用來區(qū)分網(wǎng)絡(luò)中各個計算機而分配的數(shù)值?？梢岳斫鉃楣簿值墓秒娫?，我們打電話過去找某人還需要知道名字吧，不然打過去找誰？這個某某人就類似端口號，根據(jù)這個端口號我們能找到具體的聯(lián)系人。所以通過IP+端口的方式確定具體的套接字。端口號那么多，到底指定多少端口？不慌，其實服務(wù)器上面使用的大部分端口都事先定義好了，比如HTTP多為80，SMPT通常為35端口。這樣子就可以正兒八經(jīng)的通信了

• 應(yīng)用程序準備好需要發(fā)送的數(shù)據(jù)
• 構(gòu)造HTTP請求信息
• 調(diào)用write委托協(xié)議棧發(fā)送數(shù)據(jù)

那連接的真正含義是什么？

• 連接意義之一是告知協(xié)議棧IP和端口

當創(chuàng)建完套接字以后，并沒有存放任何的數(shù)據(jù)，自然也就不知道和誰說話。這個時候，如果應(yīng)用程序要求發(fā)送數(shù)據(jù)，對于協(xié)議棧而言還是一臉懵逼。只有將IP和端口告知協(xié)議棧，他才會開始干活

• 連接意義二：

服務(wù)端創(chuàng)建套接字，但是不知道和誰通信。所以等待客戶端告知"我是XX，我的IP是xxx,端口號是XXX"

• 通過connect將IP地址和端口信息傳遞給協(xié)議棧的TCP模塊，它會和服務(wù)端的TCP模塊交換信息。具體交換哪些信息呢?？蛻舳藴蚀_找到服務(wù)端以后，會將頭部控制位中的SYN置為1。TCP 模塊將信息傳遞給IP模塊并委托它進行發(fā)送，服務(wù)端將接收到的IP模塊傳送給TCP模塊 ，TCP模塊根據(jù)控制信息找到端口號相同的套接字并將狀態(tài)修改為正在連接。此時將會進行響應(yīng)，響應(yīng)的過程中將ACK控制位設(shè)置為1表示已經(jīng)收到對應(yīng)的網(wǎng)絡(luò)包。TCP屬于全雙工通信，為了盡全力保證網(wǎng)絡(luò)傳輸信息的不丟失，會進行雙方確認機制。
• 此時網(wǎng)絡(luò)包到達客戶端，通過IP模塊到達TCP模塊，TCP模塊通過頭部信息確認連接服務(wù)器的這個操作是否成果。如果此時SYN為1則表示連接成功。然后將響應(yīng)中的ACK設(shè)置1告訴服務(wù)器你的響應(yīng)我收到了。這樣連接操作完成?？刂屏鞒探唤o應(yīng)用程序

?

6 應(yīng)用階段

當連接后到達應(yīng)用程序后，此時將決定我們需要發(fā)送什么數(shù)據(jù) ，怎么發(fā)數(shù)據(jù)，是按照流的方式還是逐字節(jié)發(fā)送，以及發(fā)什么內(nèi)容，這樣的多樣性對于協(xié)議棧而言是不怎么關(guān)心的。對于協(xié)議棧，它不會是收到什么數(shù)據(jù)就馬上發(fā)送，它會將數(shù)據(jù)先暫存緩沖區(qū)，如果收到數(shù)據(jù)就發(fā)送，難免會出現(xiàn)大量的小包，這樣會讓網(wǎng)絡(luò)效率下降。那對于協(xié)議棧而言，到底一次滿足多少才進行發(fā)送呢？

• 根據(jù)MTU判斷

MTU是一個網(wǎng)絡(luò)的最大長度，以太網(wǎng)中為1500字節(jié)，減去MTU的頭部長度，所能容納的最大數(shù)據(jù)長度為1460即MSS。這樣就可避免出現(xiàn)大量的小包問題

• 根據(jù)時間。

協(xié)議棧內(nèi)部有個計時器，到達時間就將網(wǎng)絡(luò)包發(fā)送出去。

如果HTTP請求消息太長了怎么辦呢？

如果能發(fā)出數(shù)據(jù)，但是我們發(fā)了數(shù)據(jù)卻不知道是否已經(jīng)收到，或者中途有沒有出現(xiàn)損失數(shù)據(jù)卻不知情。所以，引入ACK的確認機制進行可靠的傳輸。

發(fā)送一個包后，不傻等ACK的返回，而是繼續(xù)發(fā)送后續(xù)的包，這樣就充分的利用這段空閑時間。但是這樣也出現(xiàn)了一個問題，可能出現(xiàn)發(fā)送包的頻率太快以致于接收方處理不過來出現(xiàn)堆積。

7 IP

• 協(xié)議號：代表包從哪個模塊來。如果是TCP模塊則填寫06，如果是UDP模塊填寫17。

• 以太網(wǎng)類型

以太網(wǎng)類型代表后面內(nèi)容的類型，比如如果是IP地址相關(guān)則為0800

• 發(fā)送方MAC地址

MAC地址在網(wǎng)卡生產(chǎn)時就放入ROM中，取出存放于MAC頭部即可。

• 接收方MAC地址

要知道接收方的MAC地址，又需要找?guī)褪至?ARP)，在局域網(wǎng)中大喊一聲“xx這個IP地址是哪個？麻煩把你的MAC地址告訴我”，此時就有人給予回應(yīng)"這是我的IP地址，我的MAC地址是XX"，但是我們不可能每次都一頓喊，所以就有殺手锏"ARP緩存"，一次詢問后就會保存于緩存表中，下次再來如果能匹配到表就可直接獲取MAC地址。

8 網(wǎng)卡

• 檢查IP頭部，保證格式正確
• 查看接收方IP，如果接收的IP地址與客戶端發(fā)送過來IP一致則接受這個包，否則就很可能除了問題，此時IP模塊會通過ICMP將錯誤告知發(fā)送方，ICMP包含了哪些錯誤提示呢，總結(jié)如下

9 防火墻

看似一切到達服務(wù)器還比較順利，順利歸順利，但是我們的大部分項目中不得不考慮安全因素，不是什么數(shù)據(jù)包都可以隨便進來，所以必須使用某種手段過濾掉一部分數(shù)據(jù)包，這就是防火墻

比如常見明文協(xié)議HTTP使用的80端口，我們可以通過設(shè)置IP+端口的方式限制其他數(shù)據(jù)包的通行。

比如在TCP三次握手的時候會交換或者更新ack syn等信息，我們則可以通過設(shè)置相應(yīng)位置來達到我們過濾的目的

隨著用戶訪問量的劇增，單臺服務(wù)器明顯感覺到了壓力，再這樣下去用戶可能直接要干我，同事小A牛逼啊，上來就是:"上性能高一點的服務(wù)器啊"，小B也不賴：“多買幾臺服務(wù)器不就完事了？” 好，我們就聽聽小B的方案

砸錢

最初實現(xiàn)負載均衡采取的方案很直接，直接上硬件，當然也就比較貴，互聯(lián)網(wǎng)的普及，和各位科學(xué)家的無私奉獻，各個企業(yè)開始部署自己的方案，從而出現(xiàn)負載均衡服務(wù)器

• 簡單，如果是java開發(fā)工程師，只需要servlet中幾句代碼即可

• 加大請求的工作量。第一次請求給負載均衡服務(wù)器，第二次請求給應(yīng)用服務(wù)器
• 因為要先計算到應(yīng)用服務(wù)器的IP地址，所以IP地址可能暴露在公網(wǎng)，既然暴露在了公網(wǎng)還有什么安全可言

了解計算機網(wǎng)絡(luò)的你應(yīng)該很清楚如何獲取IP地址，其中比較常見的就是DNS解析獲取IP地址。用戶通過瀏覽器發(fā)起HTTP請求的時候，DNS通過對域名進行即系得到IP地址，用戶委托協(xié)議棧的IP地址簡歷HTTP連接訪問真正的服務(wù)器。這樣不同的用戶進行域名解析將會獲取不同的IP地址從而實現(xiàn)負載均衡

乍一看，和HTTP重定向的方案不是很相似嗎而且還有DNS解析這一步驟，也會解析出IP地址，不一樣的暴露？每次都需要解析嗎，當然不，通常本機就會有緩存，在實際的工程項目中通常是怎么樣的呢

• 通過DNS解析獲取負載均衡集群某臺服務(wù)器的地址
• 負載均衡服務(wù)器再一次獲取某臺應(yīng)用服務(wù)器，這樣子就不會將應(yīng)用服務(wù)器的IP地址暴露在官網(wǎng)了

這里典型的就是Nginx提供的反向代理和負載均衡功能。用戶的請求直接叨叨反向代理服務(wù)器，服務(wù)器先看本地是緩存過，有直接返回，沒有則發(fā)送給后臺的應(yīng)用服務(wù)器處理。

上面一種方案是基于應(yīng)用層的，IP很明顯是從網(wǎng)絡(luò)層進行負載均衡。TCP./IP協(xié)議棧是需要上下層結(jié)合的方式達到目標，當請求到達網(wǎng)絡(luò)層的時候。負載均衡服務(wù)器對數(shù)據(jù)包中的IP地址進行轉(zhuǎn)換，從而發(fā)送給應(yīng)用服務(wù)器

它可以解決因為數(shù)據(jù)量他打而導(dǎo)致負載均衡服務(wù)器帶寬不足這個問題。怎么實現(xiàn)的呢。它不修改數(shù)據(jù)包的IP地址，而是更改mac地址。應(yīng)用服務(wù)器和負載均衡服務(wù)器使用相同的虛擬IP

輪詢是Nginx中默認的處理負載的方式，從方式名稱應(yīng)該可以猜出輪詢即輪流的分配到后端的服務(wù)上。舉個例子來說，假設(shè)目前后端有4臺服務(wù)器，此時過來6個連接，如果采用輪詢的方式，他就是這樣工作A->1，B->2，C->3，D->4，A->5，B->6

upstream?XXX{
????????server?localhost:8081;
????????server?localhost:8082;
????????server?localhost:8083;
????}

????server?{
????????listen?80;
????????server_name?www.xiaolan.com;
????????location?/{
????????????proxy_pass?http://xxx;
????????}
????}

因為客戶端的ip地址是唯一不變的，所以，通過hash算法計算出ip地址對應(yīng)的哈希碼值，通過哈希碼值對服務(wù)器的數(shù)量進行一個求模運算。這樣就可以保證每個客戶端訪問的服務(wù)器都是保持不變的，因為hash算法的散列特點，也可以近似的當作平均分配。

upstream?H_xx{
????????ip_hash;
????????server?localhost:8081;
????????server?localhost:8082;
????????server?localhost:8083;
????}

????server?{
????????listen?80;
????????server_name?www.xiaolan.com;
????????location?/{
????????????proxy_pass?http://H_xx;
????????}

Hash算法中的散列特點，會導(dǎo)致某臺服務(wù)器請求量過高，其他服務(wù)器請求卻很少的情況。比如A服務(wù)器處理請求1000，而B服務(wù)器請求只有80，C服務(wù)器請求為20。我們希望后面的請求盡量來C服務(wù)器，所以出現(xiàn)了下面的方案

采用這種方式，Nginx會將請求發(fā)送給當前處理請求數(shù)量最少的服務(wù)器從而緩解集群的壓力

upstream?XXX{
????????leash_conn;
????????server?localhost:8081;
????????server?localhost:8082;
????????server?localhost:8083;
????}

????server?{
????????listen?80;
????????server_name?www.xiaolan.com;
????????location?/{
????????????proxy_pass?http://XXX;
????????}
????}

既然是將請求分給目前連接數(shù)最少的服務(wù)器，那好，我們看看這種情況。A服務(wù)器買的比較早，承受的并發(fā)數(shù)為200，B服務(wù)器稍微能承受的服務(wù)器并發(fā)數(shù)高一點500，C服務(wù)器能承受的并發(fā)數(shù)為1000。目前各個服務(wù)器情況如何呢？此時A服務(wù)器已經(jīng)處理了199個連接，B服務(wù)器處理了499個連接，C服務(wù)器處理了500個連接，我們當然希望接下來的請求交給C服務(wù)器處理，不然對于AB而言豈不是壓死了最后一根稻草，所以出現(xiàn)下面這種方式

通過設(shè)置權(quán)重的方式合理分配請求連接數(shù)

upstream?XXX{
????????server?localhost:8081?weight=6;
????????server?localhost:8082?weight=2;
????????server?localhost:8083?down;
????}

????server?{
????????listen?80;
????????server_name?www.xiaolan.com;
????????location?/{
????????????proxy_pass?http://xxx;
????????}
????}