4. Interview-Netty&Network

2020-07-21  本文已影响0人  allen锅

Java IO知识图谱

Java IO包 Java NIO包

1 OSI七层网络模型

上下层之间遵循的约定叫做"接口"，同层之间遵循的约定叫做"协议".

OSI七层参考模型&TCP/IP四层参考模型 ISO七层网络参考模型 七层协议

2 TCP/IP四层模型

TCP/IP四层模型

3 HTTP报文结构&TCP数据包

HTTP报文结构

TCP数据包结构

TCP数据包
  1. 源端口号（ 16 位）：它（连同源主机 IP 地址）标识源主机的一个应用进程。
  2. 目的端口号（ 16 位）：它（连同目的主机 IP 地址）标识目的主机的一个应用进程。这两个值加上 IP 报头中的源主机 IP 地址和目的主机 IP 地址唯一确定一个 TCP 连接。
  3. 顺序号seq（ 32 位）：用来标识从 TCP 源端向 TCP 目的端发送的数据字节流，它表示在这个报文段中的第一个数据字节的顺序号。如果将字节流看作在两个应用程序间的单向流动，则 TCP 用顺序号对每个字节进行计数。序号是 32bit 的无符号数，序号到达 2 的32次方 － 1 后又从 0 开始。当建立一个新的连接时， SYN 标志变 1 ，顺序号字段包含由这个主机选择的该连接的初始顺序号 ISN （ Initial Sequence Number ）。
  4. 确认号ack（ 32 位）：包含发送确认的一端所期望收到的下一个顺序号。因此，确认序号应当是上次已成功收到数据字节顺序号加 1 。只有 ACK 标志为 1 时确认序号字段才有效。 TCP 为应用层提供全双工服务，这意味数据能在两个方向上独立地进行传输。因此，连接的每一端必须保持每个方向上的传输数据顺序号。
  5. TCP 报头长度（ 4 位）：给出报头中 32bit 字的数目，它实际上指明数据从哪里开始。需要这个值是因为任选字段的长度是可变的。这个字段占 4bit ，因此 TCP 最多有 60 字节的首部。然而，没有任选字段，正常的长度是 20 字节。
  6. 保留位（ 6 位）：保留给将来使用，目前必须置为 0 。
  7. 控制位（ control flags ， 6 位）：在 TCP 报头中有 6 个标志比特，它们中的多个可同时被设置为 1 。依次为：
     URG ：为 1 表示紧急指针有效，为 0 则忽略紧急指针值。
     ACK ：为 1 表示确认号有效，为 0 表示报文中不包含确认信息，忽略确认号字段。
     PSH ：为 1 表示是带有 PUSH 标志的数据，指示接收方应该尽快将这个报文段交给应用层而不用等待缓冲区装满。
     RST ：用于复位由于主机崩溃或其他原因而出现错误的连接。它还可以用于拒绝非法的报文段和拒绝连接请求。一般情况下，如果收到一个 RST 为 1 的报文，那么一定发生了某些问题。
     SYN ：同步序号，为 1 表示连接请求，用于建立连接和使顺序号同步（ synchronize ）。
     FIN ：用于释放连接，为 1 表示发送方已经没有数据发送了，即关闭本方数据流。
  8. 窗口大小（ 16 位）：数据字节数，表示从确认号开始，本报文的源方可以接收的字节数，即源方接收窗口大小。窗口大小是一个 16bit 字段，因而窗口大小最大为 65535字节。
  9. 校验和（ 16 位）：此校验和是对整个的 TCP 报文段，包括 TCP 头部和 TCP 数据，以 16 位字进行计算所得。这是一个强制性的字段，一定是由发送端计算和存储，并由接收端进行验证。
  10. 紧急指针（ 16 位）：只有当 URG 标志置 1 时紧急指针才有效。TCP 的紧急方式是发送端向另一端发送紧急数据的一种方式。
    13/04/2018 Page 162 of 283
  11. 选项：最常见的可选字段是最长报文大小，又称为 MSS(Maximum Segment Size) 。每个连接方通常都在通信的第一个报文段（为建立连接而设置 SYN 标志的那个段）中指明这个选项，它指明本端所能接收的最大长度的报文段。选项长度不一定是 32 位字的整数倍，所以要加填充位，使得报头长度成为整字数。
  12. 数据： TCP 报文段中的数据部分是可选的。在一个连接建立和一个连接终止时，双方交换的报文段仅有 TCP 首部。如果一方没有数据要发送，也使用没有任何数据的首部来确认收到的数据。在处理超时的许多情况中，也会发送不带任何数据的报文段。

4 TCP三次握手~建立连接

TCP三次握手建立连接

5 TCP四次挥手~关闭连接

TCP四次挥手关闭连接

TCP连接是全双工，数据可在两个方向上同时传递。单方向的关闭叫做半关闭。

6 客户端第三次握手发送ACK后为什么要等待2MSL才关闭？

7 HTTP/TCP长短链接

持久连接

长连接优劣

短连接优劣

8 http请求响应流程

9 http协议方法和状态码

HTTP1.1使用的方法

HTTP状态码

http状态码-1** http状态码-2**&3** http状态码-4** http状态码-5**

10 HTTPS请求过程

HTTPS=HTTP + SSL

https请求过程

11 CDN原理

CDN组成系统

12 URI(统一资源标识符) & URL(统一资源定位符) & URN

URI&URL&URN

13 WebSocket底层原理及实现？

14 websocket单机最大可以支撑多少连接？

15 一个TCP连接可以对应几个http请求？几个http请求可以一起发送吗？

16 浏览器对同一host最多建立多少TCP连接？

17 单机最大TCP连接数

18 计算机网络发展的七个阶段？

计算机发展阶段

19 各种网络体系结构及其协议？

网络体系结构及其协议

20 数据传输方式分类？

电路交换与分组交换

21 MAC寻址(地址转发表)与IP寻址(路由控制表)？

MAC寻址与IP寻址

22 网络构成要素及搭建网络的设备？

网络构成要素 搭建网络的主要设备

23 TCP/IP的发展历史

TCP/IP发展历史

24 协议标准化流程

协议标准化流程

25 TCP/IP协议族组成？

TCP/IP协议族

26 TCP与UDP异同？

TCP首部格式 UDP首部格式

27 网络拓扑

网络拓扑

28 数据链路层

常用数据链路

29 公共网络分类

30 IP地址

31 IP为什么要设计为面向无连接？

32 IPv4与IPv6

33 IPv4首部&IPv6首部

IPv4首部 IPv6首部

34 DNS作用

35 ARP原理(Address Resolution Protocol)

36 RARP(Reverse Address Resolution Protocol)

37 ICMP原理

38 DHCP原理

39 NAT原理

40 提升HTTP传输速率的方法？

41 内容协商机制？

内容协商机制指的是客户端和服务器端就响应的资源内容进行交涉，然后提供给客户端最合适的资源。

42 端到端首部&逐跳首部

43 HTTP缺陷&HTTPS优势

HTTP缺陷

https好处

44 HTTP身份认证手段

45 HTTP增强协议

46 构建web内容的技术

47 web攻击技术

HTTPS攻击

HTTPS攻击多存在于中间人攻击的环境中，主要是针对HTTPS使用的压缩算法和加密算法等进行攻击。

中间人攻击流程

中间人攻击防御手段：

48 应用层协议

远程登录

文件传输

电子邮件

网络管理

多媒体通信实现技术

49 路由协议

路由控制类型

路由协议

路由控制范围跟路由协议有关，通常使用两种路由协议。

路由算法

主要路由协议

常用路由协议

50 SSO单点登录原理及实现方案？

单点登录SSO(Single Sign On)，用户在多系统环境只需要登录一次，就可以得到其关联系统的信任不用重新登录。SSO就是要解决两个问题：
用户凭证信息的存储和验证。

基于Cookie作为凭证媒介

Cookie存储在客户端，客户端登录后服务端返回加密的cookie，用户携带此cookie访问其他子系统，子系统服务端校验cookie，通过则允许登录。

基于Session

用redis存储session实现sso

SSO-分布式session

基于Token(JWT，Jason Web Token)

JWT方案服务端不存储session，服务端是无状态的，便于扩展。JWT的数据结构主要分为三个部分，Header和Payload等JSON 对象也要使用 Base64URL 算法转成字符串。

JWT的特点：
（1）JWT 默认是不加密，但也是可以加密的。生成原始 Token 以后，可以用密钥再加密一次。
（2）JWT 不加密的情况下，不能将秘密数据写入 JWT。
（3）JWT 不仅可以用于认证，也可以用于交换信息。有效使用 JWT，可以降低服务器查询数据库的次数。
（4）JWT 的最大缺点是，由于服务器不保存 session 状态，因此无法在使用过程中废止某个 token，或者更改 token 的权限。也就是说，一旦 JWT 签发了，在到期之前就会始终有效，除非服务器部署额外的逻辑。
（5）JWT 本身包含了认证信息，一旦泄露，任何人都可以获得该令牌的所有权限。为了减少盗用，JWT 的有效期应该设置得比较短。对于一些比较重要的权限，使用时应该再次对用户进行认证。
（6）为了减少盗用，JWT 不应该使用 HTTP 协议明码传输，要使用 HTTPS 协议传输。

JWT适用场景：
一次性的身份认证、api的鉴权等，这些场景能充分发挥jwt无状态以及分布式验证的优势。

JWT不适用的场景：
不要试图用jwt去代替session。这种模式下其实传统的session+cookie机制工作的更好，jwt因为其无状态和分布式，事实上只要在有效期内，是无法作废的，用户的签退更多是一个客户端的签退，服务端token仍然有效，你只要使用这个token，仍然可以登陆系统。另外一个问题是续签问题，使用token，无疑令续签变得十分麻烦，当然你也可以通过redis去记录token状态，并在用户访问后更新这个状态，但这就是硬生生把jwt的无状态搞成有状态了，而这些在传统的session+cookie机制中都是不需要去考虑的。

CAS

CAS是开源的单点登录系统，主要分为CAS client和CAS server，CAS只是说明了原理，具体实现要自己考虑。

SSO-CAS CAS序列图

基于 SAML

SAML(Security Assertion Markup Language ，安全断言标记语言）的出现大大简化了 SSO ，并被 OASIS 批准为 SSO 的执行标准 。开源组织 OpenSAML 实现了 SAML 规范。

基于网关

基于OAuth2.0

51 cookie、session、token区别？

51.1 cookie

cookie生成规则

cookie生成规则

cookie使用规则

cookie使用规则

cookie有效期

cookie优缺点

51.2 session

session生成规则

session使用规则

session有效期

session优缺点

51.3 token

token生成规则

token一般是登录时候由服务端生成，组成规则如下：

token使用规则

token有效期

token优缺点

52 OAuth2.0原理

52.1 OAuth2.0 & JWT & SSO & Shiro区别

52.2 OAuth2.0四种角色

52.3 OAuth2.0四种授权模式

授权码模式（authorization code）

功能最完整、流程最严密、最安全的授权模式，code保证了token的安全性，即使code被拦截，由于没有app_secret，也是无法通过code获得token的。

授权码模式

隐式授权码模式/简单模式（implicit）

和授权码模式类似，只不过少了获取code的步骤，是直接获取令牌token的，适用于公开的浏览器单页应用，令牌直接从授权服务器返回，不支持刷新令牌，且没有code安全保证，令牌容易因为被拦截窃听而泄露。
不支持refresh token。

密码模式（resource owner password credentials）

这种模式是最不推荐的，因为client可能存了用户密码。这种模式主要用来做遗留项目升级为oauth2的适配方案，当然如果client是自家的应用，也是可以的。支持refresh token。

客户端凭证模式（client credentials）

这种模式直接根据client的id和密钥即可获取token，无需用户参与。这种模式比较合适消费api的后端服务，比如拉取一组用户信息等，不支持refresh token，主要是没有必要。

53 IO模型(AIO & NIO & BIO(同步阻塞) & 多路复用IO)

BIO-同步阻塞IO NIO-同步非阻塞IO 多路复用IO-异步阻塞IO AIO-异步非阻塞IO

54 Java传统IO

54.1 Java IO包

Java IO包

54.2 Java IO分类

IO-操作方式分类 IO-操作对象分类

54.3 Java IO & NIO

54.4 Java NIO比传统IO的优势

55 Java NIO

55.1 Java NIO包

Java NIO包

55.2 Channel

55.3 Buffer

发送接收数据

55.4 Selector

56 Netty原理

Netty垂直架构

57 Netty为什么是高性能的？

58 Netty为什么不支持AIO而用NIO？

59 Netty服务端通信流程

Netty服务端通信流程

60 Netty客户端通信流程

Netty客户端通信流程

61 高效序列化机制

61.1 Google protobuf

protobuf特点

61.2 Facebook thrift

thrift特点

61.3 Apache Avro

61.4 kryo

61.5 FST

fst是完全兼容JDK序列化协议的系列化框架，序列化速度大概是JDK的4-10倍，大小是JDK大小的1/3左右。

61.6 hessian

61.7 json

开源的Jackson

阿里巴巴Fastjson

Google的Gson

61.8 JDK序列化

62 Netty Channel原理

62.1 Channel类图

Channel类图

62.2 Netty传输方式/协议

63 Netty Buffer原理

63.1 Buffer API

ByteBuf的作用是在Netty中通过Channel传输数据，Netty的ByteBuf相当于JDK的ByteBuffer，只是比JDK做了很多优化。Netty的Buffer API主要有两个接口：

63.2 Buffer分类

64 Netty ChannelHandler

64.1 ChannelHandler类图

ChannelHandler类图

64.2 ChannelPipeline

ChannelPipeline是ChannelHandler实例的列表，用于处理或截获通道的接收和发送数据。

64.3 ChannelHandlerContext

ChannelHandler的上下文

64.4 Channel生命周期状态模型

65 Netty编解码器codec

65.1 编码器Encoder

65.2 解码器Decoder

65.3 编解码器codec

65.4 HTTP编解码器

66 Netty对HTTP的优化

66.1 HTTP

66.2 HTTPS

66.3 WebSocket

66.4 SPDY

ChannelPipeline对SPDY的支持

66.5 Netty处理空闲连接和超时

66.6 Netty序列化机制

67 TCP粘包拆包问题

67.1 TCP为什么发生粘包拆包问题？为什么UDP不会发生粘包拆包问题？

67.2 TCP粘包拆包解决方案

67.3 Netty怎么解决粘包拆包？

68 Netty引导

68.1 引导的类图

引导的类图

68.2 引导分类

69 RESTful

69.1 RESTful定义

69.2 RESTful特点

69.3 RESTful架构

69.4 GET与POST请求区别

70 Netty源码

Bootstrap or ServerBootstrap
EventLoop
EventLoopGroup
ChannelPipeline
Channel
Future or ChannelFuture
ChannelInitializer
ChannelHandler

71 TCP拥塞控制算法

71.1 TCP四大拥塞控制策略

71.2 Reno

拥塞控制状态机(Congestion Control State Machine)

拥塞控制状态机

  1. Open状态
    Open状态是拥塞控制状态机的默认状态。这种状态下，当ACK到达时，发送方根据拥塞窗口cwnd(Congestion Window)是小于还是大于慢启动阈值ssthresh(slow start threshold)，来按照慢启动或者拥塞避免算法来调整拥塞窗口。

  2. Disorder状态
    当发送方检测到DACK(重复确认)或者SACK(选择性确认)时，状态机将转变为Disorder状态。在此状态下，发送方遵循飞行(in-flight)包守恒原则，即一个新包只有在一个老包离开网络后才发送，也就是发送方收到老包的ACK后，才会再发送一个新包。

  3. CWR状态
    发送方接收到一个显示拥塞通知时，并不会立刻减少拥塞窗口cwnd，而是每收到两个ACK就减少一个段，直到窗口的大小减半为止。当cwnd正在减小并且网络中有没有重传包时，这个状态就叫CWR(Congestion Window Reduced，拥塞窗口减少)状态。CWR状态可以转变成Recovery或者Loss状态。

  4. Recovery状态
    当发送方接收到足够(推荐为三个)的DACK(重复确认)后，进入该状态。在该状态下，拥塞窗口cnwd每收到两个ACK就减少一个段(segment)，直到cwnd等于慢启动阈值ssthresh，也就是刚进入Recover状态时cwnd的一半大小。 发送方保持 Recovery 状态直到所有进入 Recovery状态时正在发送的数据段都成功地被确认，然后发送方恢复成Open状态，重传超时有可能中断 Recovery 状态，进入Loss状态。

  5. Loss状态
    当一个RTO(重传超时时间)到期后，发送方进入Loss状态。所有正在发送的数据标记为丢失，拥塞窗口cwnd设置为一个段(segment)，发送方再次以慢启动算法增大拥塞窗口cwnd。

Loss 和 Recovery 状态的区别是:Loss状态下，拥塞窗口在发送方设置为一个段后增大，而 Recovery 状态下，拥塞窗口只能被减小。Loss 状态不能被其他的状态中断，因此，发送方只有在所有 Loss 开始时正在传输的数据都得到成功确认后，才能退到 Open 状态。

四大拥塞控制算法

Reno将拥塞控制的过程分为四个阶段：慢启动、拥塞避免、快重传和快恢复，是现有的众多拥塞控制算法的基础。

Reno四大算法

1. 慢热启动算法 – Slow Start

所谓慢启动，也就是TCP连接刚建立，一点一点地提速，试探一下网络的承受能力，以免直接扰乱了网络通道的秩序。

  1. 连接建好的开始先初始化拥塞窗口cwnd大小为1，表明可以传一个MSS大小的数据。
  2. 每当收到一个ACK，cwnd大小加一，呈线性上升。
  3. 每当过了一个往返延迟时间RTT(Round-Trip Time)，cwnd大小直接翻倍，乘以2，呈指数上升。
  4. 还有一个ssthresh（slow start threshold），是一个上限，当cwnd >= ssthresh时，就会进入“拥塞避免算法”（后面会说这个算法）。

2. 拥塞避免算法 – Congestion Avoidance

如同前边说的，当拥塞窗口大小cwnd大于等于慢启动阈值ssthresh后，就进入拥塞避免算法。算法如下：

  1. 收到一个ACK，则cwnd = cwnd + 1 / cwnd。
  2. 每当过了一个往返延迟时间RTT，cwnd大小加一。

过了慢启动阈值后，拥塞避免算法可以避免窗口增长过快导致窗口拥塞，而是缓慢的增加调整到网络的最佳值。

3. 拥塞状态时的算法

一般来说，TCP拥塞控制默认认为网络丢包是由于网络拥塞导致的，所以一般的TCP拥塞控制算法以丢包为网络进入拥塞状态的信号。对于丢包有两种判定方式，一种是超时重传RTO[Retransmission Timeout]超时，另一个是收到三个重复确认ACK。

超时重传是TCP协议保证数据可靠性的一个重要机制，其原理是在发送一个数据以后就开启一个计时器，在一定时间内如果没有得到发送数据报的ACK报文，那么就重新发送数据，直到发送成功为止。

但是如果发送端接收到3个以上的重复ACK，TCP就意识到数据发生丢失，需要重传。这个机制不需要等到重传定时器超时，所以叫做快速重传，而快速重传后没有使用慢启动算法，而是拥塞避免算法，所以这又叫做快速恢复算法。

超时重传RTO[Retransmission Timeout]超时，TCP会重传数据包。TCP认为这种情况比较糟糕，反应也比较强烈：

最为早期的TCP Tahoe算法就使用上述处理办法，但是由于一丢包就一切重来，导致cwnd重置为1，十分不利于网络数据的稳定传递。

所以，TCP Reno算法进行了优化。当收到三个重复确认ACK时，TCP开启快速重传Fast Retransmit算法，而不用等到RTO超时再进行重传：

image

4. 快速恢复算法 – Fast Recovery

TCP Tahoe是早期的算法，所以没有快速恢复算法，而Reno算法有。在进入快速恢复之前，cwnd和ssthresh已经被更改为原有cwnd的一半。快速恢复算法的逻辑如下：

image

如图所示，第五个包发生了丢失，所以导致接收方接收到三次重复ACK，也就是ACK5。所以将ssthresh设置为当时cwnd的一半，也就是6/2 = 3，cwnd设置为3 + 3 = 6。然后重传第五个包。当收到新的ACK时，也就是ACK11，则退出快速恢复阶段，将cwnd重新设置为当前的ssthresh，也就是3，然后进入拥塞避免算法阶段。

Reno拥塞控制过程

慢启动阶段，在没有出现丢包时每收到一个 ACK 就将拥塞窗口大小加一（单位是 MSS，最大单个报文段长度），每轮次发送窗口增加一倍，呈指数增长，若出现丢包，则将拥塞窗口减半，进入拥塞避免阶段；当窗口达到慢启动阈值或出现丢包时，进入拥塞避免阶段，窗口每轮次加一，呈线性增长；当收到对一个报文的三个重复的 ACK 时，认为这个报文的下一个报文丢失了，进入快重传阶段，立即重传丢失的报文，而不是等待超时重传；快重传完成后进入快恢复阶段，将慢启动阈值修改为当前拥塞窗口值的一半，同时拥塞窗口值等于慢启动阈值，然后进入拥塞避免阶段，重复上诉过程。

Reno 算法将收到 ACK 这一信号作为拥塞窗口增长的依据，在早期低带宽、低时延的网络中能够很好的发挥作用，但是随着网络带宽和延时的增加，Reno 的缺点就渐渐体现出来了，发送端从发送报文到收到 ACK 经历一个 RTT，在高带宽延时（High Bandwidth-Delay Product，BDP）网络中，RTT 很大，导致拥塞窗口增长很慢，传输速度需要经过很长时间才能达到最大带宽，导致带宽利用率降低。

Reno适用场景

适用于低延时、低带宽的网络。

71.3 Cubic

Cubic拥塞控制过程

Cubic是Linux 内核 2.6 之后的默认 TCP 拥塞控制算法，使用一个立方函数(cubic function)作为拥塞窗口的增长函数，其中，C 是调节因子，t 是从上一次缩小拥塞窗口经过的时间，Wmax 是上一次发生拥塞时的窗口大小，β是乘法减小因子。从函数中可以看出拥塞窗口的增长不再与 RTT 有关，而仅仅取决上次发生拥塞时的最大窗口和距离上次发生拥塞的时间间隔值。

Cubic 拥塞窗口增长曲线如下，凸曲线部分为稳定增长阶段，凹曲线部分为最大带宽探测阶段。如图 2 所示，在刚开始时，拥塞窗口增长很快，在接近 Wmax 口时，增长速度变的平缓，避免流量突增而导致丢包；在 Wmax 附近，拥塞窗口不再增加；之后开始缓慢地探测网络最大吞吐量，保证稳定性（在 Wmax 附近容易出现拥塞），在远离 Wmax 后，增大窗口增长的速度，保证了带宽的利用率。

当出现丢包时，将拥塞窗口进行乘法减小，再继续开始上述增长过程。此方式可以使得拥塞窗口一直维持在 Wmax 附近，从而保证了带宽的利用率。

Cubic 算法的优点在于只要没有出现丢包，就不会主动降低自己的发送速度，可以最大程度的利用网络剩余带宽，提高吞吐量，在高带宽、低丢包率的网络中可以发挥较好的性能。

但是，Cubic 同之前的拥塞控制算法一样，无法区分拥塞丢包和传输错误丢包，只要发现丢包，就会减小拥塞窗口，降低发送速率，而事实上传输错误丢包时网络不一定发生了拥塞，但是传输错误丢包的概率很低，所以对 Cubic 算法的性能影响不是很大。

Cubic 算法的另一个不足之处是过于激进，在没有出现丢包时会不停地增加拥塞窗口的大小，向网络注入流量，将网络设备的缓冲区填满，出现 Bufferbloat（缓冲区膨胀）。由于缓冲区长期趋于饱和状态，新进入网络的的数据包会在缓冲区里排队，增加无谓的排队时延，缓冲区越大，时延就越高。另外 Cubic 算法在高带宽利用率的同时依然在增加拥塞窗口，间接增加了丢包率，造成网络抖动加剧。

Cubic适用场景

适用于高带宽、低丢包率网络，能够有效利用带宽。

71.4 Vegas

Vegas拥塞控制过程

Vegas将时延 RTT 的增加作为网络出现拥塞的信号，RTT 增加，拥塞窗口减小，RTT 减小，拥塞窗口增加。具体来说，Vegas 通过比较实际吞吐量和期望吞吐量来调节拥塞窗口的大小，
期望吞吐量：Expected = cwnd / BaseRTT，
实际吞吐量：Actual = cwnd / RTT，
diff = (Expected-Actual) * BaseRTT，

BaseRTT 是所有观测来回响应时间的最小值，一般是建立连接后所发的第一个数据包的 RTT，cwnd 是目前的拥塞窗口的大小。Vegas 定义了两个阈值 a，b，当 diff > b 时，拥塞窗口减小，当 a <= diff <=b 时，拥塞窗口不变，当 diff < a 时，拥塞窗口增加。

Vegas 算法采用 RTT 的改变来判断网络的可用带宽，能精确地测量网络的可用带宽，效率比较好。但是，网络中 Vegas 与其它算法共存的情况下，基于丢包的拥塞控制算法会尝试填满网络中的缓冲区，导致 Vegas 计算的 RTT 增大，进而降低拥塞窗口，使得传输速度越来越慢，因此 Vegas 未能在 Internet 上普遍采用。

Vegas适用场景

适用于网络中只存在 Vegas 一种拥塞控制算法，竞争公平的情况。

71.5 BBR

BBR拥塞控制过程

BBR是谷歌在 2016 年提出的一种新的拥塞控制算法，已经在 Youtube 服务器和谷歌跨数据中心广域网上部署，据 Youtube 官方数据称，部署 BBR 后，在全球范围内访问 Youtube 的延迟降低了 53%，在时延较高的发展中国家，延迟降低了 80%。目前 BBR 已经集成到 Linux 4.9 以上版本的内核中。

BBR 算法不将出现丢包或时延增加作为拥塞的信号，而是认为当网络上的数据包总量大于瓶颈链路带宽和时延的乘积时才出现了拥塞，所以 BBR 也称为基于拥塞的拥塞控制算法（Congestion-Based Congestion Control）。BBR 算法周期性地探测网络的容量，交替测量一段时间内的带宽极大值和时延极小值，将其乘积作为作为拥塞窗口大小（交替测量的原因是极大带宽和极小时延不可能同时得到，带宽极大时网络被填满造成排队，时延必然极大，时延极小时需要数据包不被排队直接转发，带宽必然极小），使得拥塞窗口始的值始终与网络的容量保持一致。

由于 BBR 的拥塞窗口是精确测量出来的，不会无限的增加拥塞窗口，也就不会将网络设备的缓冲区填满，避免了出现 Bufferbloat 问题，使得时延大大降低。如图 4 所示，网络缓冲区被填满时时延为 250ms，Cubic 算法会继续增加拥塞窗口，使得时延持续增加到 500ms 并出现丢包，整个过程 Cubic 一直处于高时延状态，而 BBR 由于不会填满网络缓冲区，时延一直处于较低状态。

由于 BBR 算法不将丢包作为拥塞信号，所以在丢包率较高的网络中，BBR 依然有极高的吞吐量，如图 5 所示，在 1% 丢包率的网络环境下，Cubic 的吞吐量已经降低 90% 以上，而 BBR 的吞吐量几乎没有受到影响，当丢包率大于 15% 时，BBR 的吞吐量才大幅下降。

BBR 算法是反馈驱动的，有自主调节机制，不受 TCP 拥塞控制状态机的控制，通过测量网络容量来调整拥塞窗口，发送速率由自己掌控，而传统的拥塞控制算法只负责计算拥塞窗口，而不管发送速率（pacing rate），怎么发由 TCP 自己决定，这样会在瓶颈带宽附近因发送速率的激增导致数据包排队或出现丢包。

经过测试，在高延时、高丢包率的环境下，BBR 相对于 Cubic 算法在传输速度上有较大的提升，BBR 算法的不足之处在于设备队列缓存较大时，BBR 可能会竞争不过 Cubic 等比较激进算法，原因是 BBR 不主动去占据队列缓存，如果 Cubic 的流量长期占据队列缓存，会使得 BBR 在多个周期内测量的极小 RTT 增大，进而使 BBR 的带宽减小。

BBR适用场景

适用于高带宽、高时延、有一定丢包率的长肥网络，可以有效降低传输时延，并保证较高的吞吐量。

71.6 Remy

Remy拥塞控制过程

Remy也称为计算机生成的拥塞控制算法（computer-generated congestion-control algorithm），采用机器学习的方式生成拥塞控制算法模型。通过输入各种参数模型（如瓶颈链路速率、时延、瓶颈链路上的发送者数量等），使用一个目标函数定量判断算法的优劣程度，在生成算法的过程中，针对不同的网络状态采用不同的方式调整拥塞窗口，反复修改调节方式，直到目标函数最优，最终会生成一个网络状态到调节方式的映射表，在真实的网络中，根据特定的网络环境从映射表直接选取拥塞窗口的调节方式。

Remy 试图屏蔽底层网络环境的差异，采用一个通用的拥塞控制算法模型来处理不同的网络环境。这种方式比较依赖输入的训练集（历史网络模型），如果训练集能够全面覆盖所有可能出现的网络环境及拥塞调节算法，Remy 算法在应用到真实的网络环境中时能够表现的很好，但是如果真实网络与训练网络差异较大，Remy 算法的性能会比较差。

Remy适用场景

网络环境为复杂的异构网络，希望计算机能够针对不同网络场景自动选择合适的拥塞控制方式，要求现有的网络模型能够覆盖所有可能出现情况。

72 C10K问题及解决方案

C10K，支持10000个客户端同时连接。

73 为什么Redis的epoll是轮询而Nginx是阻塞呢？

74 RPC和HTTP分别介绍一下，有什么区别和联系？

上一篇下一篇

猜你喜欢

热点阅读