网络相关-学习笔记

Hello_Kitty
114 阅读11分钟

一、https

和 http 的区别，增加了 SSL/TSL 安全层；

1、SSL/TSL 安全层

  • TLS 是安全传输协议，是较为新的安全协议，它基于 SSL 发展而来，不通用；
  • SSL 安全套接层，旧一点的安全协议；
  • TLS 握手启动，是开启 HTTPS 通信的关键；

2、TSL 握手的过程

  • 客户端给出协议版本号，随机数（Client random），以及客户端支持的加密方法；
  • 服务端确认使用的加密方法，给出数字证书（内含公钥），以及服务器随机数（Server random）；
  • 客户端校验数字证书，然后生成（Premaster secret），并使用数字证书的公钥，加密此随机数。
  • 服务端用自己私钥，解密随机数（Premaster secret）；
  • 服务端和客户端根据约定方法，用三个随机数，生成（Session Key）。

如下图： image.png

3、DH 算法

定义：用于密钥分配。 因为整个握手阶段都是明文的，所以加密方法，三个随机数中的两个，都可以被获取。所以安全只靠第三个随机数（Premaster secret）。 可以选择 DH 算法，不用传递 Premaster sercet，双方传递各自参数（DH 参数），然后计算次随机数（变成了4个随机数，其中两个 DH 参数生成 Premaster secret）。 image.png

4、session key 的恢复

  • 每次 https 通讯，不需要每次都进行 TLS 连接。当 TLS 连接成功，会话不中断，session key 是可以持续使用的。
  • 当连接中断后，客户端可以用历史的 session ID 发给服务端，如果服务端此 session ID 匹配到了。那么继续使用此 session key 来使用。
  • 新版本有 session ticket 方法。用于分布式的服务器进行验证（服务端可以解密此 ticket，得出 session key）。

5、数字签名

数字证书采用了链式签名策略，根证书的公钥存在浏览器中。

  • 摘要：一堆信息经过摘要算法，得到的一段 hash 值；
    • 优点：摘要相比信息来说会很短，可以很方便判断是否一个信息；
    • 缺点：把无限的信息变为了有限的摘要，有可能碰撞；
  • 数字签名的产生：摘要经过加密，就是数字签名；
    • 第一步，信息变成明文摘要；
    • 第二步，明文摘要变成密文摘要，也称为数字签名；
    • 第三步，数字签名由是（加密算法+发送方私钥）；
  • 数字签名的验证：
    • 第一步：摘要密文变成摘要明文（通过发送方的公钥+加密算法）；
    • 第二步：根据收到的信息来计算摘要（哈希算法）；
    • 第三步：比较是否相同，如果相同，证明数据来自发送方，且无法抵赖；
  • 数字签名处理了什么问题？
    • 优点：
      • 摘要一致，保证了密文没被修改过；
      • 验签操作，可以保证发送方无法抵赖；
    • 缺点：不能知道这个发送方是不是靠谱的。

6、数字证书：

定义：用数字签名技术，对服务端公钥进行签名后得到的文件（并没有加密）。 目的：为了防止非对称加密通信过程中，被中间人拦截。服务端会将自己的证书传递给客户端。 证书中包括持有者的公钥，证书签名，有效期，加密算法，持有者等。 客户端拿到数字证书后，用内置的 CA 公钥解密证书的签名得到摘要，然后验签（此签名是 CA 私钥签的，所以可以用 CA 公钥验签）。 CA 机构：

  • 各级 CA 机构很多，下级的 CA 证书是通过上级 CA 来签名的；
  • 最后有一个根 CA 机构；
  • 优点：当二级 CA 私钥泄露，也不会影响安全性；

image.png

6、https 的优化策略

性能消耗的环节：

  • TLS 握手过程；
  • 握手成功后对称加密报文；

优化方式：

  • 升级 TLS 到1.3版本，减少握手过程；
  • 使用椭圆曲线 ECDSA 加密代替 RSA，加速 TLS 过程；
  • 会话复用：
    • session ID 和 session Key 存服务端的 hash 表中，会花可以复用，不用重复 TLS 握手；
    • session Ticket 将会话密钥存在客户端，服务器收到后解密验证有效期，然后使用，这样应对分布式服务器；
  • 会话复用过期：
    • 为了避免重放攻击，需要给会话秘钥一个过期时间；
  • 其他优化：
    • https 的计算压力较大，选择算力更强的 CPU；
    • 升级 Linux 版本；
    • 优化证书版本，ECC 证书比 RSA 体积小很多；

二、HTTP1.1

1、缺点：

  • 队头阻塞：
    • 当前面一个数据没有传输完成，后面的数据不能传播；
      • 它是纯文本协议，所以无法拆分 http 的载荷，只能顺序传播；
  • http 头部冗余；
  • 无法双向通信；

2、优点：

  • 并发请求技术，一个 domain，最多请求6个资源，避免干扰；
  • 默认开启长链接，复用同一个 TCP 链接；
    • http1.0 也可以手动设置，但是是有时间限制，一般不超过15s；
  • cache control 机制
  • 更丰富的协议头，Language，Encoding，Type 等。
    • HOST 头可以区分不同的域名，因为有很多域名解析在一个 IP 上。
    • OPTIONS 方法，用于 CORS 预解析。

3、其他

  • HTTP1.1 管道技术
    • 幂等请求才能使用，post 可能有依赖关系。
    • 请求资源的时候，可以连续发出。但是响应资源的时候，还是会按请求顺序一一返回。
    • 目前主流浏览器禁用这个方案，防止高优先级资源被低优先级阻塞。

三、HTTP/2

2015年推出的，新一代应用层协议。 前身：2010年谷歌推出的 SPDY 协议； image.png

1、重要概念

  • 流（Stream）：已建立的 TCP 连接上的双向字节流，可以承载一个或者多个消息；
  • 消息（Message）：一个完整的 HTTP 请求或者响应，由一个或多个帧组成；
  • 帧（Frame）：通信的基本单位；
  • 一个 TCP 连接上面可以传递任意数量流；

2、优点

  • 二进制分帧
    • HTTP1.1 因为传输的主要是脚本语言，所以文本协议传输更加方便。二进制协议可读性差，调试困难，牺牲了执行性能，提高了开发效率。
    • 文本格式传输需要借助 ZIP 压缩减少网络带宽，消耗 CPU 资源。
    • 在 HTTP 报文中增加了帧的概念，这样传输的数据，就可以混着来，避免 HTTP1.1 中带来的队头阻塞问题；
    • image.png
    • HTTP1.1 响应是文本格式，而 HTTP/2 把响应划分成了两个帧，图中的 HEADERS（首部）和DATA（消息负载）是帧的类型。一条HTTP响应，划分成了两个帧来传输，并且采用二进制来编码。
    • header frame 和 data frame。也就是头部帧和数据体帧。帧的传输最终在流中进行，流中的帧，头部(header)帧 和 data 帧可以分为多个片段帧，例如data帧即是可以 data = data_1 + data_2 + ... + data_n。
  • 多路复用
    • 将 HTTP 的载荷拆分为更小的块，也就是数据帧，每个帧都有一个流 ID，通过这个流 ID，可以在一个 TCP 连接上传播多个流；最后用流 ID 拼接起来。
  • 头部压缩
    • 维护一份相同的静态字典，包含常见的头部名称，以及常见的头部名称和值的组合
    • 维护一份相同的动态字典，可以动态的添加内容
    • 通过静态 Huffman 编码对传输的首部字段进行编码
  • 服务端推送
  • 优先级树
    • 用做资源的调度控制，管理优先级
      • 每个消息都有 31bit 的优先值；
      • HTML > CSS > js > 图片
  • 更好的拥塞控制策略
    • 因为只建立一个 TCP 链接，在最大贷款限制下，可以更快达到理论最大峰值，6个 tcp 连接会相互干扰。

3、缺点

  • 流量控制
    • 为了防止内存溢出，发送的请求也不会一股脑发出去，会有批量控制发出；
  • TCP 的一系列缺点
    • 慢启动
    • 队头阻塞
      • 如果一个包丢了，整个 TCP 就会停下来重传（它不知道这个是哪个 HTTP 发出的数据），如果丢包率高于2%，那么就不如 HTTP1.1，因为它最多可以6个 TCP 连接；
      • 一个包丢了，整条 TCP 就得停下来等，HTTP/2 用一个 TCP 连接，受影响很大。
    • 拥塞控制

四、HTTP/3

TCP 协议本身的一些特点，束缚了网速的提升。 image.png HTTP/2 的问题在于应用层协议，HTTP/3 放弃了 TCP，采用 udp 协议封装的 QUIC。 QUIC：Quick UDP Internet Connections QUIC 要求建立加密连接，此加密不止 http 的负载，是指整个数据流。

1、优点：

  • 处理了 TCP 阻塞问题
  • 可靠：QUIC 改造了 UDP，提供了慢启动，快速重传，拥塞控制，节奏调整等特性；
  • 无序，并发的字节流；
  • 快速握手；
    • 左边 https 完成一次连接需要 3RTT，右侧 QUIC 因为是 UDP 基础上，所以可以实现 0RTT 连接
    • image.png
  • 用 TLS1.3 安全协议，新版本安全握手更快；

image.png

2、缺点

3、QUIC 基于 UDP 如何保证可靠性

同样按照 的实现，实现了一套慢启动，拥塞控制，快速重传，超时重传等机制。

五、其他网络面试题

1、WebSocket

基于 TCP 协议的一种全双工协议。复合 W3C 标准。

与 HTTP/2 消息推送功能的区别

  • 定义不同
    • 一个是为了双工通讯，一个是为让浏览器可以提前缓存静态资源。

与 HTTP 不同点：

  • WS 用 HTTP 来建立连接，重新定于了一些 header 域；
    • Upggrade：websocket
    • Connection： Upgrade
    • 握手连接时，类型必须为 GET，版本号大于1.1
  • 不能使用代理服务器转发，只可以直连；
  • nginx 代理服务器需要修改

2、TCP

传输控制协议， FTP，DNS，Telnet，

传输头

  • 固定20个字节；
  • Sequence Number：包序号，处理网络包乱序；
  • ACK Number 标记 ack 的响应码；
  • window：滑动窗口描述；
  • Flags：
    • SYN 建立同步链接
    • ACK，应答顺序号
    • FIN，PSH，RST，URG (紧急)
  • 偏置值

SYN 超时

服务端收到一个 SYN 请求，会发送 SYN-ACK 响应，然后等待客户端发送的ACK，如果超时后，会默认重新发起 SYN-ACK。这个过程最多会重复五次，间隔也会一直递增，1,2,4,16,32共63s，这样容易被触发 SYN Flood 攻击。

拥塞控制

  • 慢启动：
    • cwnd 拥塞窗口，发送端会有一个初始值；
    • 发送方在接收确认之前，指数级扩大窗口，超时之后重新启动，直到阈值（大部分是65536）；
    • 窗口达到了阈值，那么就会开始线性增长。
    • 初始值和系统有段
  • 拥塞控制：到达阈值之后，窗口+1线性增长，如果发生拥塞，阈值变为最大值减半，并重新开发慢启动；
  • 超时重传：计时器没有按时收到响应，就重传；
  • 快速重传：当发送端收到3个 ACK（重复的），立刻重新传递，不等计时器；
    • 为何会收到重复的 ACK，1,2,3,4,5个包，当2丢了，3,4,5收到后都会返回2的 ACK 码。

3、UDP

用户数据报协议： 无连接，不可靠，无顺序，无差错控制 DHCP，DNS，SNMP等；

七层网络模型

物理层：传输比特流 0 1 链路层：传输帧，mac地址可以定位发送者和接受者 网络层：建立主机到主机的连接，ip地址去寻找网络（局域网） 传输层：建立端口到端口的连接，0-65535 应用层：直接面相用户的高级协议 image.png 一般来说 MTU 最大传输长度为1500字节，所以网络层在发送的时候，会拆分数据。 image.png

六、重点概念

1、队头阻塞：Head-of-Line blocking

某个比较慢的对象，阻止了后续对象继续执行。 一个资源完全发送完毕后，另一个资源才可以继续发送。

2、tcp 队头阻塞

定义：

HTTP 的数据对 TCP 来说，没有任何区别，当发生丢包之后，无法正确判断，之前或者之后的包传递完成。所以 HTTP3 将流 ID 从 HTTP 应用层挪到了传输层，有了流 ID，就可以在传输层上判断是否完成。

基本概念

HTTP1.1 有队头阻塞，因为它要完整的发送响应，并不能多路复用； HTTP/2 引入了帧的概念，标识资源属于哪个流，TCP 不负责这些流的区分，直接传递； 如果一个 tcp包 丢失，那么后续包都要等待重传，即使后续包和本包无关，这就是 TCP 的队头阻塞；

处理方法

让传输层有应用层流 ID，不可能去改变 TCP 协议。 创建了 QUIC 协议，他有自己的帧，流 ID 之前存放在 HTTP/2 的数据帧中，现在被下移到传输层的QUIC 帧中。 HTTP/3 从应用层中删除了流的概念，他的数据帧没有流 ID，为了支持这个新的传输层协议，创建了新的 HTTP/3 协议。

七、参考链接：

https：

www.ruanyifeng.com/blog/2014/0… developer.51cto.com/art/202103/… zhuanlan.zhihu.com/p/26559480

http3：

cloud.tencent.com/developer/a… zhuanlan.zhihu.com/p/330300133

其他

zhuanlan.zhihu.com/p/32059190 coolshell.cn/articles/19… www.cnblogs.com/lsgxeva/p/8…

avatar
文章
阅读
粉丝