大家好，我是 傑哥

上篇推送網絡篇（一）：《趣談網絡協議》讀書筆記（一）中，我們進行了網絡協議的MAC層、IP層以及傳輸層這三層協議的知識掃盲梳理，和 TCP 協議的三次握手、四次揮手以及如何保證靠譜傳輸的機制的學習

本篇，接着來看《趣談網絡協議》第二部分筆記：應用層、數據中心、雲計算網絡、容器技術中的網絡以及微服務相關協議的幾部分内容吧~

• 域名先通過 DNS 服務器解析成 IP 地址
• 建立 TCP 連接（三次握手）
• 請求構建:請求行、請求首部、正文實體
• 通過二進制流發送
• TCP 層将二進制流變成報文
• TCP發送報文段，用得到回應ACK來保證可靠地到達了對方。
• TCP 發送每個報文的時候，加上自己的地址和目标地址放到 IP 頭交給 IP層傳輸
• IP 層查看是否在同一個局域網，如果是，發送 ARP 協議來請求目标 MAC 地址；如果不是，發送 ARP 協議獲取網關 MAC 地址，并把數據發送到網關
• 網關收到取出目标 IP 地址，根據路由器協議找到下一跳的路由器，獲取下一跳的路由器的 MAC 地址并發送給下一跳路由器
• 到達目标地址的局域網，于是這個局域網發送ARP 協議獲取目标地址的 MAC 地址并發送到該地址
• 目标機器發現了 MAC 地址符合，接收包，發現是 IP 協議，于是根據 IP 頭中的協議項知道上層是 TCP 協議，于是按照 TCP 協議解析TCP 的頭，放入緩存中處理并返回一個 ACK
• 解析 TCP 的端口号，HTTP 服務器監聽此端口号，目标機器将包發送給目标端口，HTTP 服務器進程響應到請求，返回找到對應資源
• 服務器構建返回報文：狀态碼、返回首部
• 讓 TCP 層将返回的 HTML 文件分為一個個小的段，加上 TCP 頭交給 IP 層按來的過程再走一遍
• 客戶端發現接收報文，交給 TCP 層根據序列号處理是否符合，然後發給相應端口
• 浏覽器監聽端口，取到狀态碼 200，解析正文
• 浏覽器根據首部返回格式解析 HTML 格式數據，渲染執行

1、請求報文構成：由請求行和首部字段以及正文實體構成

2、報文的發送：使用面向連接的方式發送，以二進制流的方式傳送給對方

3、響應報文的發送：狀态行、首部字段和正文實體

簡而言之，就是需要排隊，隊首的事件沒有處理完的時候，後面的事件都要等着

1、HTTP 1.0 的隊首阻塞

發生在客戶端

對于同一個 TCP 連接，隻有前一個請求的響應收到了，才能發送下一個請求

2、HTTP 1.1 的隊首阻塞

發生在服務端

1）無客戶端的隊首阻塞

對于同一個 TCP 連接，HTTP 1.1 允許一次發送多個請求。也就是說，不必等前一個響應收到，就可以發送下一個請求

2）存在服務端的隊首阻塞

但是，HTTP 1.1 規定，服務器端的響應的發送要根據請求被接收的順序排隊，也就是說，先接收到的請求的響應也要先發送

相對于 HTTP 1.0 來說，有以下幾點優化:

1、對 HTTP 的頭進行壓縮

在兩端建立索引表，對相同的頭隻發生索引表中的索引

2、多路複用

HTTP2.0 将 TCP 連接中，切分成多個流，每個流有自己的 ID 和優先級

對傳輸信息分割為更小的消息和幀，并采用二進制格式編碼。傳輸 Header 内容的幀為 Header 幀,傳輸正文實體的幀為 Data 幀

比如有三個請求，HTTP 2.0 會将它們分成三個流，将數據分成幀，亂序發送給 TCP 處理

3、徹底解決了隊首阻塞的問題

HTTP 2.0 無論在客戶端還是在服務器端都不需要排隊，在同一個 TCP 連接上，有多個 stream，由各個 stream 發送和接收 HTTP 請求，各個 steam 相互獨立，互不阻塞

隻要 TCP 連接沒有滿，就随時可以發送已經生成的請求或者響應的數據，幾乎在兩端都不用等，從而徹底解決了 HTTP 協議層面的隊首阻塞問題

雖然 HTTP 2.0 使得應用層實現了并行，但是到了傳輸層的 TCP 時，還是會有問題。假設兩個流在 TCP 層一前一後傳輸兩個沒有關聯的數據，流 2 的幀在前面，流 1 的幀在後面，如果前面的流 2 的幀沒有收到，後面流 1 的幀也會被阻塞，從而又會影響性能

因此考慮對 UDP 進行定制化

機制一：自定義連接

為避免重連（建立三次連接步驟）在 QUIC 協議自己的邏輯裡維護連接的機制。即，連接不再由四元組來标識，而是有一個 64 位的随機數作為 ID 來标識，而且 UDP 是無連接的，所以當 IP 地址或者端口發生變化時，隻要 ID 不變，就不需要建立連接。

機制二：自定義重傳

TCP 為了保證可靠性，使用序号和應答機制來解決順序問題和丢包問題

使用自定義重傳算法的采樣往返時間為 RTT 來定義超時，由于相同的包重傳時，序号是一樣的，那麼根據響應的 ACK ，估算的 RTT 時間可能會不準确

QUIC 的序列号是遞增的，并且還定義了一個 offset 的概念，可知道數據發送到了哪裡。那麼，隻要 offset 的包沒有來，就要重發，發送時序列号加一。如果來了，就按照 offset 拼接，還能拼成一個流

機制三：無阻塞的多路複用

即使流 2 的包需要重傳，流 3 的包也無須等待就可以發送給用戶

機制四：自定義流量控制

TCP 是使用滑動窗口協議實現的。QUIC 協議，的流量控制通過 window_update 來告訴對端，它可以接受的字節數

TCP 的 ACK 機制是基于序列号的應答，也就是說隻要前面的包沒有收到，即使收到了後面的包，也不能發送 ACK

而 QUIC 協議則是基于 offset 的，收到一個回一個 offset，那麼得到的窗口大小也就更準确

機制五：擁塞控制

QUIC 使用了 TCP 的 CUBIC 擁塞控制算法-窗口增長函數僅僅取決于連續兩次擁塞事件的時間間隔值，窗口增長完全獨立于 RTT

1、對稱加密：加密和解密使用的密鑰是相同的

2、非對稱加密：公鑰加密的信息隻能私鑰能解密，私鑰加密的信息隻有公鑰能解密

3、數字證書

說明:

HTTPS 綜合了對稱加密和非對稱加密：使用非對稱加密傳輸對稱加密的秘鑰，而雙方的通信采用對稱加密。

既保證了傳輸安全，又保證了傳輸效率

1、建立兩個連接

1）控制連接

服務端以被動的方式，打開用于 FTP 的端口 21，客戶端則主動發起連接

2）數據連接

2、兩種工作模式

站在服務器的角度來說的

1）主動模式

服務器從自己的數據端口 20 主動連接到客戶端指定的數據端口上

2）被動模式

客戶端會主動連接上服務端的數據端口

1、P2P 協議機制

無論是 HTTP 還是 FTP ，都難以解決文件下載時的單一服務器的帶寬問題

P2P，資源不再集中地存儲在某些設備上，而是分散在多台設備上，即 Peer

2、下載方式

1、通過 .torrent 文件，了解到文件的信息和 Peer 列表，進行下載

2、基于分布式哈希算法，元數據和文件數據全部分散

通過域名查詢地址

1、樹狀結構

• 根 DNS 服務器：返回頂級域 DNS 服務器的 IP 地址
• 頂級域 DNS 服務器：返回權威 DNS 服務器的 IP 地址
• 權威 DNS 服務器：返回相應主機的 IP 地址

2、解析流程

采用遞歸的方法，并通過緩存的方式增強性能

1）客戶端發起 DNS 解析流程，先訪問本地 DNS 緩存（/etc/hosts）。若無緩存，則轉到第 2）步

2）客戶端向本地 DNS 服務器（一般附近運營商的某個機房），若無緩存，則轉到第 3）步

3）本地 DNS 服務器訪問根域名服務器，根域名服務器會返回頂級 DNS 服務器的IP地址

4）本地 DNS 服務器拿到頂級 DNS 服務器 IP 地址，訪問頂級 DNS 服務器地址，返回權威域名服務器 IP 地址

5）本地 DNS 服務器拿到權威域名服務器IP地址，訪問并拿到對應 IP 地址

6）本地 DNS 服務器返回 IP 地址，客戶端發起 IP 協議請求

3、負載均衡

1）内部負載均衡

根據域名，在解析時自動選擇不同的 IP 地址

2）全局負載均衡

對各個數據中心之間的服務器進行負載均衡

4、DNS服務器問題

• 解析慢
• 更新不及時
• 因為緩存、轉發、NAT問題導緻客戶端誤會自己所在的位置和運營商，影響流量調度

由客戶端 SDK、HTTPDNS 服務器兩部分實現。采用 HTTP 請求 HTTPDNS 服務器集群，得到就近的地址

1、傳統 DNS 存在的問題

解析 DNS 過程複雜,通信次數多,解析速度很慢。為了加快解析增加的緩存,又會産生緩存更新速度不及時的問題

2、HTTPDNS 解決方案

1）解析的過程,不需要本地 DNS 服務遞歸的調用一大圈,一個 HTTP 的請求直接搞定,要實時更新的時候,馬上就能起作用

2）為了提高解析速度,本地也有緩存,緩存是在客戶端 SDK 維護的,過期時間、更新時間,都可以自己控制

3、HTTPDNS 的同步與異步解析說明

1）HTTPDNS 同步解析

• 優點：實時性好
• 缺點：如果有多個請求都發現過期的時候,同時會請求 HTTPDNS 多次,是一種浪費

2）HTTPDNS 異步解析

• 優點：可以将多個請求都發現過期的情況,合并為一個對于 HTTPDNS 的請求任務,隻執行一次,減少 HTTPDNS 的壓力
• 缺點：當前請求拿到過期數據的時候,如果客戶端允許使用過期數據,需要冒一次風險。如果過期的數據還能請求,就沒問題;如果不能請求,則失敗一次,等下次緩存更新後,再請求方能成功

1、和電商系統的分布式倉儲系統一樣，分為中心節點、區域節點、邊緣節點，将數據緩存在離用戶最近的位置

2、CDN 最擅長的是緩存靜态數據，除此之外，還可以緩存流媒體數據，這時要注意防盜鍊

3、支持動态數據緩存，可用模式有兩種：一種是邊緣計算的生鮮超市模式，另一種是鍊路優化的冷鍊運輸模式

1、數據中心分為三層。服務器連接到接入層，然後是彙聚層，接着是核心層，最外邊是邊界路由器和安全設備；

2、數據中心的所有鍊路都高可用。服務器可以綁定網卡，交換機可以堆疊，三層設備可以通過等價路由，二層設備可以通過 TRILL 協議實現高可用

1、VPN 是如何工作的？

可以将一個機構的多個數據中心通過隧道連接起來，讓機構感覺在一個數據中心裡面一樣。涉及到三種協議：乘客協議、隧道協議、承載協議

2、IPSec VPN 是基于 IP 的隧道安全隧道協議，保證信息的安全

• 機密性 -加密
• 完整性 - 生成數據摘要
• 真實性 - 身份認證

3、IpSec VPN 的 2 種協議

AH - 認證頭協議，隻能做數據摘要，不能做數據加密

ESP - 封裝安全載荷協議。能夠做數據摘要，也能夠加密

4、兩個組件

IKE - 用于 VPN 雙方進行對稱秘鑰交換的組件

SA - VPN 雙方進行連接維護的組件

5、Ipsec VPN 建立連接的過程

1）階段一：建立 IKE 自己的 SA

用來維護一個通過身份認證和安全保護的通道，為第二個階段提供服務

通過 DH 算法計算出一個 對稱秘鑰 K

a.客戶端與服務端約定兩個公開的質數p,q,并分别同時産生随機數 a,b；計算出 公鑰A，B

客戶端：p,q,a => A (A=q^a mod p ) 服務端：p,q,b => B (B=q^b mod p)

b.雙方交換 A，B

c.各自獨立算出 K

2）階段二：建立 IPsec SA

雙方生成一個随機的對稱秘鑰 M，首先使用 K 将 M 加密傳給對方，然後雙方使用M 進行數據傳輸

其中，M 是有過期時間的，過一段時間會重新生成一次

6、IP sec VPN 的工作模式與不足之處

客戶端發送明文的 IP 包都會被加上 ESP 頭 和 IP 頭，并進行了加密，到了對端之後，去掉 ESP 頭，進行解密

這種點對點的基于 IP 的 VPN，能滿足互通的要求（私密性、完整性、真實性），但是速度往往比較慢，是由底層 IP 的特性決定的

其中，

1）IP:不是面向連接的，隻是盡力而為的。即使同一個連接，也可能選擇不同的路徑；那麼，就需要不斷進行路由查找，效率太低

2）ATM：一旦連接建立，所有包都按照相同路徑傳輸。不需要進行路由查找，效率會高很多

7、MPLS(Multi-Protocol Label Switching，多協議标簽轉換)

在 IP 頭 data 之前，打一個标簽，按标簽傳輸。綜合了 IP 轉發模式和 ATM 标簽轉發模式的優勢，性能較好

8、MPLS VPN 的工作模式

其中，

1）CE 為客戶網絡；

P 為運營商網絡；

PE 為 邊緣網絡設備（連接運營商與客戶網絡）

2）VPN 報文轉發采用兩層标簽方式

a）PE - > 對端 PE，通過 MP-BGP 查找路由

b）PE -> CE。通過查找 VRF 路由表确定路由。

1、雲計算的關鍵技術是虛拟化

2、如何将虛拟機的網絡和物理機的網絡連接起來呢？

通過打開 TUN/TAP 字符設備的方式實現

3、雲中的網絡重點關注四個方面：共享、隔離、互通以及靈活

共享和互通常用的方式：橋接和 NAT;

隔離的方式：VLAN

1、用 SDN 控制整個雲裡面的網絡，就像小區保安從總控管室管理整個物業一樣，将控制面和數據面進行了分離

2、Open Switch 是一種開源的虛拟交換機的實現，它能對經過自己的網絡包做任意修改，從而使得雲對網絡的控制十分靈活，并且可以解耦物理網絡和虛拟網絡

1、雲中安全常用策略方式是使用 iptables 的規則

1）在虛拟機内部，采用 iptables 命令配置 ACL

2）在一個或多個虛拟機之間，采用安全組 單位進行過濾

2、iptables 的 5個鍊：

說明：

1）PREROUTING:當一個數據包進入一台機器時，會先拿下 mac 頭看看，是不是我的，若是，則拿下 IP 頭來

2） 若發現 IP 地址是我的，則發給上面的傳輸層，通過 INPUT

3） 如果不是，則通過 FORWARD 轉發出去

4）上層處理完之後，返回一個處理結果，這個結果通過 OUTPUT 返回

5）最終的包，都會通過 POSTROUTING 發送出去

3、iptables 的表分為 4 種

1）raw -不常用

2）manage -修改數據包，包括全部的 5 個鍊

3）nat - 虛拟、物理網絡地址的轉換

可作用于以下三個鍊：

• PREROUTING ：在數據包到達時改變目标地址
• OUTPUT：改變本地産生的數據包的目标地址
• POSTROUTING：在數據包離開時改變數據包的源地址

4）filter - 安全策略實現（過濾功能）可作用于以下三個鍊：

• INPUT：過濾所有目标地址是本機的數據包
• FORWARD:過濾所有路過本機的數據包
• OUTPUT：過濾所有由本機産生的數據包。

1、雲中的流量控制主要是通過隊列進行的。排隊規則分為兩大類：

1）無類别排隊規則

• pfifo_fast 技術
• 随機公平隊列

計算哈希值，分配（其中hash 函數會經常變化）

• 令牌桶規則

2）基于類别的排隊規則

HTB （分層令牌桶）規則

在雲中網絡 Open vSwitch 中，主要使用 HTB 将總的帶寬在一棵樹上按照配置的比例進行分配，并且在一個分支不使用流量時，借給另外的分支，從而增強帶寬利用率

1、GRE（Generic Routing Encapsulation）(通用路由封裝)

是一種 **IP-OVER-IP **的隧道技術，傳輸過程如下：

1）在 隧道 A 端封裝數據包：将 ip 包封裝在 GRE 包裡，外面加上 隧道端點的 IP 頭；

2）在隧道中傳輸；

3）在隧道 B 端進行解封裝

2、 通過隧道的方式，解決了 VLAN ID 不足的問題

3、不足

1）隧道數量問題

GRE 是一種點對點隧道，随着網絡數目增多，隧道的數目會成指數級增長

2）GRE 不支持組播

會将一個虛拟機中發出的廣播幀，廣播到所有與該隧道連接的節點

3）設備不支持

目前防火牆和三層網絡設備無法解析 GRE，因此無法對 GRE 封裝包做合适的過濾和負載均衡

4、VXLAN

和三層外再套三層的 GRE 不同，VXLAN 是從二層外面套了一個 VXLAN 的頭

每個物理機上有一個 VTEP，作為虛拟機的代理，進行包的封裝和解封裝；每個物理機上的 vtep，會加入一個組播組

說明：

虛拟機 1、2、3 屬于雲中同一個用戶的虛拟機，因此被分配相同的 VXLAN ID=101

1）虛拟機 1 要 ping 虛拟機 2 。先發送 ARP 廣播；

2）到達 VTEP1，VTEP1 将 ARP 請求封裝在 VXLAN 裡，組播出去；

3）群組中的 VTEP2 和 VTEP3 收到消息，均會解開 VXLAN 包，并在本地進行廣播；

4）VTEP2 會收到虛拟機 2 的回複；而 VTEP3 不會收到任何回複；

5）VTEP2 将 ARP 的回複封裝在 VXLAN 裡面，直接發給 VTEP1;

此時，VTEP1 知道了 虛拟機 2 歸 VTEP2 管，以後找虛拟機 2 ，直接去找 VTEP2 即可；而 VTEP2 也知道了 虛拟機1 歸 VTEP1 管，以後找 虛拟機1，直接去找 VTEP1 即可

5、Open vSwitch

可以作為隧道端口，通過設置流表規則在虛拟機網絡和物理機網絡之間進行轉換

1、容器是一種比虛拟機更加輕量級的隔離方式。主要通過 namespace 和 cgrop 技術進行資源的隔離

namespace 負責"看起來"隔離，cgroup 負責“用起來”隔離（網絡資源限制）

2、Docker 有兩種方式實現物理機與容器之間的端口映射

1）通過進程 docker-proxy，在物理機監聽端口 10080 ，将網絡包轉發到容器的端口 80

2）通過 DNAT，在物理機上添加一個 iptables 規則，将目标端口為 10080 的網絡包轉發到容器的 80 端口

是跨節點容器網絡的一種方案

1、使用 UDP 實現 Overlay 網絡的方案

1）物理機 A 的 flanneld 進程 ：将網絡包封裝在 UDP 包中，然後 物 A 、物 B 的 IP

2）發送給物理機 B 上的 flanneld 進程 ；

3）物理機 B：解開，轉發給 docker0

4）docker0 将包轉發給 容器 B，通信成功

2、兩種方案

1）UDP 在用戶态封裝

2） VXLAN 在内核态封裝

後者性能更好

1、思路

不走 Overlay 網絡，不引入另外的網絡性能損耗，将轉發，全部由三層網絡的路由轉發實現。即将物理機化身為路由器

2、主要組件

1）Felix

每台物理機上的 agent，創建、删除容器時會自動配置

2）路由廣播組件 BGP Speaker

将路由信息廣播出去，每台物理機對應一個

3）BGP 路由反射器：大規模場景

在接入交換機之間建立 BGP 連接，由BGP Speaker 将路由上報至BGP，實現大規模場景的路由廣播

4）安全策略組件

iptables的配置組件-在嵌入的處理點上設置相應的規則

3、IPIP 模式

即在兩台機器之間打一個隧道，兩台機器因為隧道變成了相鄰的機器，解決跨網段訪問問題

1、RPC 的工作流程

說明：

分為以下三個層次：

1）用戶、服務器：像本地調用一樣，專注于業務邏輯的處理即可；

2）Stub 層：處理雙方約定好的語法、語義，進行封裝、解封裝；

3）RpcRuntime 層：主要處理高性能的傳輸，以及網絡的錯誤和異常

2、NFS-網絡文件系統協議，基于 RPC 實現

含兩個服務器：

1）mounted - 挂載文件路徑

2）nfsd - 用來讀寫文件

實現在本地 mount 一個遠程的目錄到本地的一個目錄，本地用戶在這個目錄讀寫。其實操作的是遠程

1、ONE RPC 将發送與回複的參數統一壓縮為一個二進制串，有很多缺點：

1）格式要求嚴格

2）修改過于複雜

3）不面向對象

于是産生了基于文本的調用方式-基于xml的soap

2、SOAP 的三大要素

1）協議約定用 WSDL

2）傳輸協議用 HTTP

3）服務發現用 UDDI

即統一描述、發現和集成協議

RESTful （Representational Stat Transfer）- 表述性狀态轉移，是一種設計風格，基于 JSON

1、無狀态

服務端維護資源的狀态，客戶端維護會話的狀态

2、SOAP 過于複雜，而且設計時面向動作的，因而往往因為架構問題導緻并發量上不去

3、RESTful 不僅僅是一個 API，還是一種架構模式，主要面向資源提供無狀态服務，有利于橫向擴展，應對高并發

1、Dubbo的調用過程（與 RPC 模式相似）

1）會在客戶端本地啟動一個 Proxy

2）從注冊中心獲取服務器列表

3）根據路由規則和負載均衡****策略确定一個需要調用的服務器地址

4）進行編碼、序列化，形成 Dubbo 頭和序列化的方法和參數

5）交給網絡客戶端發送

6）網絡服務端接收到，解碼

7）将任務分發給某個線程池

8）線程池調用服務端的代碼邏輯

9）返回結果

2、Dubbo 的協議約定問題

1）默認的 RPC 協議是 Hessian2

2）将遠程調用序列化為二進制格式傳輸。并可進行一定的壓縮

3、Hessian2 是自描述的

原來的 RPC 協議，會提前定義一個協議文件。若協議發生變化，就要重新定義文件。而 Hessian2 是自描述的

4、Dubbo 的 RPC 傳輸問題

使用了 Netty 的網絡傳輸框架。是一個非阻塞的，基于事件的網絡傳輸框架

1、gRPC 是什麼？

gRPC 是一種二進制、性能好、跨語言、更靈活，同時可以進行服務治理的多快好省的 RPC 框架。唯一的不足就是要寫協議文件

2、gRPC 描述

1）gRPC 序列化時使用 Protocol Buffers （二進制序列化協議)，需要定一個協議文件 .proto

2）網絡傳輸時使用 HTTP2.0

3）服務治理時可以使用 基于 Envoy 的 Service Mesh

嗯，就這樣。每天學習一點，時間會見證你的強大~

歡迎大家關注我們的公衆号，一起持續性學習吧~

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!