大家好，我是 杰哥

上篇推送网络篇（一）：《趣谈网络协议》读书笔记（一）中，我们进行了网络协议的MAC层、IP层以及传输层这三层协议的知识扫盲梳理，和 TCP 协议的三次握手、四次挥手以及如何保证靠谱传输的机制的学习

本篇，接着来看《趣谈网络协议》第二部分笔记：应用层、数据中心、云计算网络、容器技术中的网络以及微服务相关协议的几部分内容吧~

一、应用层

（一）页面输入url 访问，网络会做些什么？

• 域名先通过 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 格式数据，渲染执行

（二）HTTP

1、请求报文构成：由请求行和首部字段以及正文实体构成

2、报文的发送：使用面向连接的方式发送，以二进制流的方式传送给对方

3、响应报文的发送：状态行、首部字段和正文实体

（三）队首阻塞

简而言之，就是需要排队，队首的事件没有处理完的时候，后面的事件都要等着

1、HTTP 1.0 的队首阻塞

发生在客户端

对于同一个 TCP 连接，只有前一个请求的响应收到了，才能发送下一个请求

2、HTTP 1.1 的队首阻塞

发生在服务端

1）无客户端的队首阻塞

对于同一个 TCP 连接，HTTP 1.1 允许一次发送多个请求。也就是说，不必等前一个响应收到，就可以发送下一个请求

2）存在服务端的队首阻塞

但是，HTTP 1.1 规定，服务器端的响应的发送要根据请求被接收的顺序排队，也就是说，先接收到的请求的响应也要先发送

（四）HTTP 2.0

相对于 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 协议层面的队首阻塞问题

（五）QUIC 协议

虽然 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

（六）HTTPS

1、对称加密：加密和解密使用的密钥是相同的

2、非对称加密：公钥加密的信息只能私钥能解密，私钥加密的信息只有公钥能解密

3、数字证书

说明:

HTTPS 综合了对称加密和非对称加密：使用非对称加密传输对称加密的秘钥，而双方的通信采用对称加密。

既保证了传输安全，又保证了传输效率

（七）FTP

1、建立两个连接

1）控制连接

服务端以被动的方式，打开用于 FTP 的端口 21，客户端则主动发起连接

2）数据连接

2、两种工作模式

站在服务器的角度来说的

1）主动模式

服务器从自己的数据端口 20 主动连接到客户端指定的数据端口上

2）被动模式

客户端会主动连接上服务端的数据端口

（八）P2P 协议

1、P2P 协议机制

无论是 HTTP 还是 FTP ，都难以解决文件下载时的单一服务器的带宽问题

P2P，资源不再集中地存储在某些设备上，而是分散在多台设备上，即 Peer

2、下载方式

1、通过 .torrent 文件，了解到文件的信息和 Peer 列表，进行下载

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

二、数据中心

（一）DNS

通过域名查询地址

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问题导致客户端误会自己所在的位置和运营商，影响流量调度

（二）HTTPDNS

由客户端 SDK、HTTPDNS 服务器两部分实现。采用 HTTP 请求 HTTPDNS 服务器集群，得到就近的地址

1、传统 DNS 存在的问题

解析 DNS 过程复杂,通信次数多,解析速度很慢。为了加快解析增加的缓存,又会产生缓存更新速度不及时的问题

2、HTTPDNS 解决方案

1）解析的过程,不需要本地 DNS 服务递归的调用一大圈,一个 HTTP 的请求直接搞定,要实时更新的时候,马上就能起作用

2）为了提高解析速度,本地也有缓存,缓存是在客户端 SDK 维护的,过期时间、更新时间,都可以自己控制

3、HTTPDNS 的同步与异步解析说明

1）HTTPDNS 同步解析

• 优点：实时性好
• 缺点：如果有多个请求都发现过期的时候,同时会请求 HTTPDNS 多次,是一种浪费

2）HTTPDNS 异步解析

• 优点：可以将多个请求都发现过期的情况,合并为一个对于 HTTPDNS 的请求任务,只执行一次,减少 HTTPDNS 的压力
• 缺点：当前请求拿到过期数据的时候,如果客户端允许使用过期数据,需要冒一次风险。如果过期的数据还能请求,就没问题;如果不能请求,则失败一次,等下次缓存更新后,再请求方能成功

（三）CDN

1、和电商系统的分布式仓储系统一样，分为中心节点、区域节点、边缘节点，将数据缓存在离用户最近的位置

2、CDN 最擅长的是缓存静态数据，除此之外，还可以缓存流媒体数据，这时要注意防盗链

3、支持动态数据缓存，可用模式有两种：一种是边缘计算的生鲜超市模式，另一种是链路优化的冷链运输模式

（四）数据中心

1、数据中心分为三层。服务器连接到接入层，然后是汇聚层，接着是核心层，最外边是边界路由器和安全设备；

2、数据中心的所有链路都高可用。服务器可以绑定网卡，交换机可以堆叠，三层设备可以通过等价路由，二层设备可以通过 TRILL 协议实现高可用

（五）VPN

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 端口

（二）Flannel

是跨节点容器网络的一种方案

1、使用 UDP 实现 Overlay 网络的方案

1）物理机 A 的 flanneld 进程 ：将网络包封装在 UDP 包中，然后 + 物 A 、物 B 的 IP

2）发送给物理机 B 上的 flanneld 进程 ；

3）物理机 B：解开，转发给 docker0

4）docker0 将包转发给 容器 B，通信成功

2、两种方案

1）UDP 在用户态封装

2） VXLAN 在内核态封装

后者性能更好

（三） Calico

1、思路

不走 Overlay 网络，不引入另外的网络性能损耗，将转发，全部由三层网络的路由转发实现。即将物理机化身为路由器

2、主要组件

1）Felix

每台物理机上的 agent，创建、删除容器时会自动配置

2）路由广播组件 BGP Speaker

将路由信息广播出去，每台物理机对应一个

3）BGP 路由反射器：大规模场景

在接入交换机之间建立 BGP 连接，由BGP Speaker 将路由上报至BGP，实现大规模场景的路由广播

4）安全策略组件

iptables的配置组件-在嵌入的处理点上设置相应的规则

3、IPIP 模式

即在两台机器之间打一个隧道，两台机器因为隧道变成了相邻的机器，解决跨网段访问问题

（四）RPC 概述

1、RPC 的工作流程

说明：

分为以下三个层次：

1）用户、服务器：像本地调用一样，专注于业务逻辑的处理即可；

2）Stub 层：处理双方约定好的语法、语义，进行封装、解封装；

3）RpcRuntime 层：主要处理高性能的传输，以及网络的错误和异常

2、NFS-网络文件系统协议，基于 RPC 实现

含两个服务器：

1）mounted - 挂载文件路径

2）nfsd - 用来读写文件

实现在本地 mount 一个远程的目录到本地的一个目录，本地用户在这个目录读写。其实操作的是远程

五、微服务相关协议

（一） SOAP

1、ONE RPC 将发送与回复的参数统一压缩为一个二进制串，有很多缺点：

1）格式要求严格

2）修改过于复杂

3）不面向对象

于是产生了基于文本的调用方式-基于xml的soap

2、SOAP 的三大要素

1）协议约定用 WSDL

2）传输协议用 HTTP

3）服务发现用 UDDI

即统一描述、发现和集成协议

（二）RESTful 接口协议

RESTful （Representational Stat Transfer）- 表述性状态转移，是一种设计风格，基于 JSON

1、无状态

服务端维护资源的状态，客户端维护会话的状态

2、SOAP 过于复杂，而且设计时面向动作的，因而往往因为架构问题导致并发量上不去

3、RESTful 不仅仅是一个 API，还是一种架构模式，主要面向资源提供无状态服务，有利于横向扩展，应对高并发

（三）二进制类 RPC 协议

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 的网络传输框架。是一个非阻塞的，基于事件的网络传输框架

（四）跨语言类 RPC 协议

1、gRPC 是什么？

gRPC 是一种二进制、性能好、跨语言、更灵活，同时可以进行服务治理的多快好省的 RPC 框架。唯一的不足就是要写协议文件

2、gRPC 描述

1）gRPC 序列化时使用 Protocol Buffers （二进制序列化协议)，需要定一个协议文件 .proto

2）网络传输时使用 HTTP2.0

3）服务治理时可以使用 基于 Envoy 的 Service Mesh

嗯，就这样。每天学习一点，时间会见证你的强大~

欢迎大家关注我们的公众号，一起持续性学习吧~