這一次， 咱們聊一聊網絡

前言

網絡機制

要實現應用程序之間的交互。 咱們須要一個可以在瀏覽器和web服務器之間傳遞請求和響應的機制。 因爲請求和響應都是由0和1組成的數字信息， 因此， 咱們須要的是一種可以將數字信息搬運到指定目的地的機制。

它的基本思路是將數字信息分割成一個一個的小塊， 而後裝入一些被稱爲包的容器中來運送。

包至關於信件或者包裹，而交換機和路由器則至關於郵 局或快遞公司的分揀處理區。包的頭部存有目的地等控制信息，經過許多 交換機和路由器的接力，就能夠根據控制信息對這些包進行分揀，而後將 它們一步一步地搬運到目的地。

這個負責搬運數字信息的機制再加上瀏覽器和web服務器這些網絡應用程序， 這兩部分組成了網絡。

分工

• 瀏覽器： 負責將請求消息委託給操做系統中的網絡控制軟件。
• 協議棧： 將請求消息進行打包並加上目的地址等控制信息。
• 網卡： 將包轉換爲電信號並經過網線發送出去， 這樣， 包就進入到了網絡。
• 集線器，交換機，路由器： 網卡發送的包會通過交換機等設備到達用來接入互聯網的路由器。 網絡運營商會負責將包送到目的地。
• 接入網，網絡運營商： 互聯網的入口線路稱爲接入網， 可使用電話線， 有線電視， 光纖等多種通訊線路來做爲接入網。經過接入網進入骨幹網， 在骨幹網中存在不少運營商和大量的路由器，這些路由器相互鏈接， 組成一張巨大的網，而咱們的網絡包就在其中通過若干路由器的接力，最 終被髮送到目標 Web 服務器上。
• 防火牆： 防火牆會對進入的包進行檢查
• 緩存服務器： 網頁數據中有一部分是能夠重複利用的， 這些能夠重複利用的數據被保存在緩存服務器中， 若是要訪問的網頁數據正好在緩存服務器中， 就不須要勞煩web服務器了。 此外， 在大型網站中， 可能還配備將消息發佈到多臺web服務器上的負載均衡器， 還有可能會使用經過分佈在整個互聯網中的緩存服務器來分發內容的服務。
• web服務器： 當網絡包到達web服務器後， 數據會被解包並還原爲原始的請求消息， 而後交給web服務器程序， 和客戶端同樣， 這個操做也是由操做系統中的協議棧來完成的。接下來， web服務器會分析請求消息來封裝響應消息發回給客戶端。

探索之旅

瀏覽器生成消息

• 生成HTTP請求消息
• 向 DNS 服務器查詢域名對應的 IP 地址
• 委託協議棧發送消息

生成HTTP請求消息

當咱們在瀏覽器輸入網址（URL）後， 瀏覽器就要開始解析URL：

當訪問Web服務器時應該使用HTTP協議， 訪問FTP服務器時應該使用FTP協議。

解析完URL以後， 咱們就知道應該要訪問的目標了。這裏咱們以HTTP協議爲例。

HTTP協議

HTTP協議定義了客戶端和服務器之間交互的消息內容和步驟。

與HTTP關係密切的協議：

• 負責傳輸的IP協議：做用是把各類數據包傳送給對方。其中兩個重要條件就是IP地址和MAC地址。IP地址指明瞭節點被分配到的地址，MAC地址是指網卡所屬的固定地址。
• 確保可靠性的TCP協議：提供可靠的字節流服務。採用了三次握手策略握手過程當中使用了TCP的標誌--SYN和ACK發送端首先發送一個帶SYN標誌的數據包給對方，接收端收到後，回傳一個帶有SYN/ACK標誌的數據包以示傳達確認消息，最後發送端在回傳一個帶ACK標誌的數據包，表明握手結束。若在握手過程當中某個階段莫名中斷，TCP協議會再次以相同的順序發送相同的數據包
• 負責域名解析的DNS服務：提供域名到IP地址之間的解析服務

客戶端向服務器發送請求消息， 請求消息中包含「對什麼」和「進行怎樣的操做」兩個部分。 「對什麼」部分稱爲URI。

服務端返回響應消息。

請求消息：

• 請求行： 包含請求方法， HTTP版本， URI
• 消息頭： 每行包含一個頭字段， 用於標識請求的附加信息（如日期， 客戶端支持的數據類型， 語言， 壓縮格式， 緩存控制等）
• 消息體： 包含客戶端向服務器發送的數據。

響應消息：

• 狀態行： 包含HTTP版本， 狀態碼， 響應短語（用來解釋狀態碼）
• 消息頭
• 消息體： 包含服務器向客戶端發送的數據， 消息體的格式會經過消息頭中的 Content-Type 字段來定義 (MIME 類型)

狀態碼概要：

返回響應消息後， 瀏覽器會將數據提取出來並顯示在屏幕上。

當網頁中包含圖片時， 會在網頁中相應位置嵌入表示圖片文件的標籤的控制信息。 而後再次訪問服務器獲取圖片並顯示在預留的空間中。

因爲每條請求消息只能寫一個URI， 因此每次只能獲取一個文件。若是網頁包含三張圖片， 則會向服務器發送四條請求。

經過DNS服務器查詢服務器IP地址

咱們通常在網站輸入的都是域名， 可是在委託操做系統發送消息時，必須提供域名對應的IP地址。 所以， 在生成HTTP消息後， 接下來就是根據域名查詢IP地址。

TCP/IP網絡協議是經過IP地址來肯定通訊對象的， 所以不知道IP地址就沒法將消息發送給對方。

DNS如何查詢域名對應IP地址

根據域名查詢 IP 地址時，瀏覽器會使用 Socket 庫中的解析器。

解析器會向DNS服務器發送查詢消息（DNS服務器也有IP地址， 只不過這個 IP 地址是做爲 TCP/IP 的一個設置項目事先設置好的，不須要再去查詢了）。

DNS 服務器會從域名與 IP 地址的對照表中查找相應的記錄，並 返回 IP 地址。

固然， 一個DNS服務器的內存是有限的， 不可能存有全部域名對應的IP地址，當在本服務器上查不到時， 就會展開DNS服務器的大接力， 從而查找要查詢的信息。

有時候， 並不須要從最上級的根域開始查找， 由於DNS服務器有一個緩存功能， 能夠記住以前查詢過的域名。 緩存能夠減小查詢所需的時間。

當HTTP請求消息和DNS查詢IP地址準備就緒， 接下來就要委託操做系統來發送消息。

協議棧和網卡

• 建立套接字： 當協議棧收到委託後的第一步就是建立套接字
• 鏈接服務器
• 收發數據
• 從服務器斷開鏈接並刪除套接字
• IP與以太網的包收發操做
• 用UDP協議收發數據的操做

協議棧分爲上下兩部分：

- 上： 分爲了兩塊， 分別負責TCP和UDP協議的收發數據

- 下： 用IP協議控制網絡包收發操做的部分。

在互聯網上傳送數據時， 數據會被切分紅一個一個的網絡包， 而將網絡包發送給通訊對象的操做就是由IP來負責的。 IP中還包括ICMP協議（告知網絡包傳送過程當中的錯誤和各類控制消息）， ARP協議（根據IP地址查詢對應的以太網MAC地址）。

瀏覽器、郵件等通常應用程序收發數據時用 TCP; DNS 查詢等收發較短的控制數據時用 UDP。

建立套接字

套接字的實體就是通訊控制信息

協議棧是根據套接字中記錄的控制信息來工做的。

建立套接字時，首先分配一個套接字所需的內存空間，而後向其 中寫入初始狀態。

因爲套接字中記錄了通訊雙方的信息以及通訊處於怎樣的 狀態，因此只要經過描述符肯定了相應的套接字，協議棧就可以獲取全部 的相關信息，這樣一來，應用程序就不須要每次都告訴協議棧應該和誰進 行通訊了。

鏈接服務器

鏈接其實是通訊雙方交換控制信息。所謂控制信息，就是用來控制數據收發操做所需的一些信息，例如IP 地址 和端口號。

三次握手🤝：

• 正在鏈接： 客戶端發送網絡包（設置SYN爲1）到服務器
• 鏈接完畢： 服務器找到對應的套接字， 並返回響應， 設置SYN（接受鏈接）和ACK（網絡包可能丟失出錯， ACK用設置1來確認是否收到網絡包）。網絡包返回客戶端， 經過響應的SYN判斷是否鏈接成功
• 確認鏈接： 客戶端將ACK設置爲1發回服務器， 告訴服務器剛纔的響應包已收到。

收發數據

MTU:一個網絡包的最大長度，以太網中通常爲 1500字節。

MSS:除去頭部以後，一個網絡包所能容納的 TCP 數據的最大 長度

HTTP請求消息通常不會太長， 一個網絡包就能裝下， 但若是要提交表單數據， 可能會超出一個網絡包的容量， 此時就須要對數據進行拆分。

TCP具有確認對方是否成功收到網絡包， 以及當對方沒收到時進行重發的功能， 所以在發送網絡包以後， 接下來還要進行確認操做。

經過「序號」和「ACK 號」能夠確認接收方是否收到了網絡包。實際上網絡的錯誤檢測和補償機制很是 複雜。

協議棧會檢查收到的數據塊和 TCP 頭部的內容，判斷是否有數據丟失，若是沒有問題則返回 ACK 號。而後，協議棧將數據塊暫存到接收緩衝區中，並將數據塊按順序鏈接起來還原出原始的數據，最後將數據交給應用程序

斷開鏈接

數據發送完畢後斷開鏈接。

服務器會先發起斷開鏈接。

四次揮手👋：

• 戶端進程發出鏈接釋放報文，而且中止發送數據。釋放數據報文首部，FIN=1，其序列號爲seq=u
• 服務器收到鏈接釋放報文，發出確認報文，ACK=1，ack=u+1
• 服務器將最後的數據發送完畢後，就向客戶端發送鏈接釋放報文，FIN=1，ack=u+1。
• 客戶端收到服務器的鏈接釋放報文後，必須發出確認，ACK=1，ack=w+1，而本身的序列號是seq=u+1

UDP協議

UDP只負責單純地發送包而已，並不像 TCP 同樣會對包的送達狀態進行監控，因此協議棧也不知道有沒有發生錯誤。如下狀況能夠考慮使用UDP協議：

1. 數據很短， 用UDP發送更高效

TCP很複雜是爲了保證將數據高效且可靠地發送給對方。可是若是數據很短， 一個包就能裝下， 咱們就不用考慮哪一個包送達， 哪一個包沒有送達了， 這樣， 咱們發送數據， 根據對方的回覆來肯定是否須要重發便可。

1. 音頻和視頻數據

音頻和視頻數據中缺乏了某些包並不會產生嚴重的問題， 只是會產生一些失真或卡頓。

集線器， 交換機和路由器

HTTP 請求的方法，TCP 的確認響應和序號，客戶端和服務器之間的關係，這一 切都與包的傳輸無關。所以，全部的包在傳輸到目的地的過程當中都是獨立 的，相互之間沒有任何關聯。

• 集線器將信號發往全部線路

• 交換機根據 MAC 地址表查找 MAC 地址，而後將信號發送到相 應的端口。

  交換機的全雙工模式能夠同時發送和接收信號

  • 路由器根據「IP 地址」判斷轉發目標。

路由器的端口都具備 MAC 地址，只接收與自身地址匹配的包， 遇到不匹配的包則直接丟棄。

完成包接收操做以後，路由器就會丟棄包開頭的 MAC 頭部。MAC 頭 部的做用就是將包送達路由器，其中的接收方 MAC 地址就是路由器端口 的 MAC 地址。所以，當包到達路由器以後，MAC 頭部的任務就完成了， 因而 MAC 頭部就會被丟棄。

接入網和網絡運營商

這一部分與咱們關係不大， 就不作贅述了。

服務端

• 防火牆的結構和原理
• 負載均衡
• 緩存服務器
• 內容分發服務

防火牆

防火牆的基本思路就是隻容許發往特定服務器中的特定應用程序的包經過， 而後屏蔽其餘的包。

設置包過濾規則

經過端口號限定應用程序

經過控制位判斷鏈接方向

包過濾方式的防火牆可根據接收方 IP 地址、發送方 IP 地址、接 收方端口號、發送方端口號、控制位等信息來判斷是否容許某個 包經過。

#### 防火牆沒法抵禦的攻擊

防火牆只關心包的起點和終點， 但對包中的特定數據是沒法檢測的。

應對包內容致使的服務器問題應對措施：

• 這個問題的根源在於 Web 服務器程序的 Bug，能夠經過修復 Bug 防止宕機
• 另外一種方法就是在防火牆以外部署用來檢查包的內容並阻止有害包的設備或軟件

負載均衡

當服務器的訪問量上升時， 增長服務器線路的帶寬是有效的， 可是網絡速度是有限的， 並不能解決全部問題。

在這種狀況下， 使用多臺服務器來分擔負載的方法更有效， 這種架構統稱爲分佈式架構。

使用負載均衡器， 首先要用負載均衡器的IP地址代替Web服務器的實際地址並註冊到DNS服務器上。 這樣當要訪問咱們的Web服務器實際上要通過負載均衡器進行一次轉發。 這樣咱們只要經過在負載均衡器上來判斷咱們服務器的負載從而決定該請求由哪一個服務器來處理。

緩存服務器

除了使用多臺功能相同的Web服務器來分擔負載外， 還能夠經過將整個系統按功能分紅不一樣的服務器， 如Web服務器， 數據庫服務器。 緩存服務器就是一種按功能來分擔負載的方法。

緩存服務器是一臺經過代理機制對數據進行緩存的服務器。代理介於 Web 服務器和客戶端之間，具備對 Web 服務器訪問進行中轉的功能。當進 行中轉時，它能夠將 Web 服務器返回的數據保存在磁盤中，並能夠代替 Web 服務器將磁盤中的數據返回給客戶端。這種保存的數據稱爲緩存，緩 存服務器指的也就是這樣的功能。

正向代理

正向，代理的是客戶端； 反向，代理的是服務端。

上面的是在 Web 服務器一端部署一個代理，而後利用其緩存功能來 改善服務器的性能，還有一種方法是在客戶端一側部署緩存服務器。

正向代理剛剛出現的時候， 其目的之一就是緩存， 另外一個目的是設置防火牆。

在使用正向代理時，通常須要在瀏覽器的設置窗口中的「代理服務器」 一欄中填寫正向代理的IP地址，瀏覽器會忽略網址欄的內容，直接將全部請求發送給正向代理。

正向代理改良版————反向代理

使用正向代理須要在瀏覽器中進行設置，這能夠說 是識別正向代理的一個特徵。可是，設置瀏覽器很是麻煩，若是設置錯誤 還可能致使瀏覽器沒法正常工做。

因而咱們可使用代理服務器來接受網路上的鏈接請求，而後將請求轉發給內部網絡上的服務器，並將從服務器上獲得的結果返回給請求鏈接的客戶端。

負載均衡就是一種反向代理的應用。

透明代理

緩存服務器判斷轉發目標的方法還有一種，那就是查看請求消息的包頭 部。由於包的 IP 頭部中包含接收方 IP 地址，只要知道了這個地址，就知道用戶要訪問哪臺服務器， 這種方法稱爲透明代理。

透明代理集合了正向代理和反向代理的優勢。正常狀況下， 請求消息是從瀏覽器直接發送到Web服務器， 並不會到達透明代理。

咱們將透明代理放在請求消息從瀏覽器傳輸到Web服務器的路徑中， 當消息通過時進行攔截。 鏈接互聯網的接入網就是一個關口， 咱們能夠在這裏設置反向代理， 用戶察覺不到代理的存在， 也不會注意到HTTP消息是如何被轉發的， 所以你們更傾向於將透明代理說成是緩存。

內容分發服務

內容分發服務就是咱們常說的CDN緩存。

提供CDN緩存的廠商， 會和網絡運營商還有Web服務器運營者簽定協議，建立一些最接近用戶網絡的邊緣服務器，而後將文件緩存在這些邊緣服務器（節點）。 只要Web服務器和CDN緩存服務器創建鏈接， 那麼當客戶端訪問web服務器時， 實際上就是在訪問CDN緩存服務器。

查找最近的緩存服務器

它與DNS相結合，使用戶可以以最小的延遲訪問節點。

經過重定向服務器分配訪問目標

重定向能夠以較高的精度匹配到目標服務器， 問題是會帶來更多的請求

緩存服務器的內容更新

當web服務器更新之後， 緩存服務器的內容可能就再也不適用， 此時須要一套更新機制來更新緩存。

請求到達服務器， 響應返回瀏覽器

總結

TCP協議： 傳輸控制協議。是基於鏈接的協議，也就是說，在正式收發數據前，必須和對方創建可靠的鏈接。

IP協議： 用於將多個包交換網絡鏈接起來的，它在源地址和目的地址之間傳送一種稱之爲數據包的東西，它還提供對數據大小的從新組裝功能，以適應不一樣網絡對包大小的要求。

UDP協議： 簡單版的TCP協議， 只負責單純地發送包， 不負責監控。 適用於包很小的請求和音視頻傳輸。

問題： 爲何不直接使用域名來查詢而要使用IP地址？

答：

1. IP地址是隻有4字節的數字， 而域名則是幾十到幾百字節的字符， 這增長了路由器的負擔。
2. 域名更加好記， 而IP地址是一串數字不易記憶。

問題： 爲何是三次握手， 四次揮手？

答： 三次握手時，服務器同時把ACK和SYN放在一塊兒發送到了客戶端那裏
四次揮手時，當收到對方的FIN報文時，僅僅表示對方再也不發送數據了可是還能接收數據，己方是否如今關閉發送數據通道，須要上層應用來決定，所以，己方 ACK 和 FIN 通常都會分開發送。

問題： 正向代理和反向代理的區別

答：

一、正向代理實際上是客戶端的代理，幫助客戶端訪問其沒法訪問的服務器資源。反向代理則是服務器的代理，幫助服務器作負載均衡，安全防禦等。

二、正向代理通常是客戶端架設的，好比在本身的機器上安裝一個代理軟件。而反向代理通常是服務器架設的，好比在本身的機器集羣中部署一個反向代理服務器。

三、正向代理中，服務器不知道真正的客戶端究竟是誰，覺得訪問本身的就是真實的客戶端。而在反向代理中，客戶端不知道真正的服務器是誰，覺得本身訪問的就是真實的服務器。

四、正向代理和反向代理的做用和目的不一樣。正向代理主要是用來解決訪問限制問題。而反向代理則是提供負載均衡、安全防禦等做用。兩者均能提升訪問速度。

問題： 一次完整的HTTP請求

答：

1. 創建TCP鏈接

在HTTP工做開始以前，Web瀏覽器首先要經過網絡與Web服務器創建鏈接，該鏈接是經過TCP來完成的，該協議與IP協議共同構建Internet，即著名的TCP/IP協議族，所以Internet又被稱做是TCP/IP網絡。HTTP是比TCP更高層次的應用層協議，根據規則，只有低層協議創建以後才能進行更高層協議的鏈接，所以，首先要創建TCP鏈接，通常TCP鏈接的端口號是80。

1. 瀏覽器向Web服務器發送請求命令
2. 瀏覽器發送請求頭信息

瀏覽器發送其請求命令以後，還要以頭信息的形式向Web服務器發送一些別的信息，以後瀏覽器發送了一空白行來通知服務器，它已經結束了該頭信息的發送。

1. Web服務器應答

客戶機向服務器發出請求後，服務器會客戶機回送應答， HTTP/1.1 200 OK ，應答的第一部分是協議的版本號和應答狀態碼。

1. Web服務器發送應答頭信息

正如客戶端會隨同請求發送關於自身的信息同樣，服務器也會隨同應答向用戶發送關於它本身的數據及被請求的文檔。

1. Web服務器向瀏覽器發送數據

Web服務器向瀏覽器發送頭信息後，它會發送一個空白行來表示頭信息的發送到此爲結束，接着，它就以Content-Type應答頭信息所描述的格式發送用戶所請求的實際數據。

1. Web服務器關閉TCP鏈接

在完成這次數據通訊後，服務器會經過TCP四次揮手主動斷開鏈接。但若這次鏈接爲長鏈接，那麼瀏覽器或服務器的頭信息會加入keep-alive的信息，會保持此鏈接狀態，在有其它數據發送時，能夠節省創建鏈接的時間。