博客推荐

网络接入协议/概念

MAC地址

实现主机到主机的通信。应用在网卡、路由器上，它使得用户可以通过电缆或无线相互连接。每一个网卡都有一个被称为MAC地址的独一无二的48位串行号，它被写在卡上的一块ROM中。在网络上的每一个计算机都必须拥有一个独一无二的MAC地址。没有任何两块被生产出来的网卡拥有同样的地址。这是因为电气电子工程师协会（IEEE）负责为网络接口控制器销售商分配唯一的MAC地址。

现实中的 MAC 地址的结构，MAC地址也叫物理地址、硬件地址，长度为 48 位，一般这样来表示 00-16-EA-AE-3C-40

它是由网络设备制造商生产时烧录在网卡的EPROM（一种闪存芯片，通常可以通过程序擦写）。其中**前 24 位（00-16-EA）代表网络硬件制造商的编号，后 24 位（AE-3C-40）是该厂家自己分配的，一般表示系列号。**只要不更改自己的 MAC 地址，MAC 地址在世界是唯一的。形象地说，MAC地址就如同身份证上的身份证号码，具有唯一性

image-20220725233921338

MAC报文头部格式

MAC 头部是以太网使用的头部，它包含了接收方和发送方的 MAC 地址等信息。

在 MAC 包头里需要发送方 MAC 地址和接收方目标 MAC 地址，用于两点之间的传输。

一般在 TCP/IP 通信里，MAC 包头的协议类型只使用：

  • 0800 ： IP 协议
  • 0806 ： ARP 协议

image-20220726105911581

路由协议

先说路由器，它的功能就是，作为一台独立的拥有IP地址和 MAC 地址的设备，并且可以帮我们把数据包做一次转发，工作在网络层，路由器的每一个端口，都有独立的 MAC 地址

路由控制表中记录着网络地址与下一步应该发送至路由器的地址。在主机和路由器上都会有各自的路由器控制表。

在发送 IP 包时，首先要确定 IP 包首部中的目标地址，再从路由控制表中找到与该地址具有相同网络地址的记录，根据该记录将 IP 包转发给相应的下一个路由器。如果路由控制表中存在多条相同网络地址的记录，就选择相同位数最多的网络地址，也就是最长匹配。

如下便是从主机A发送到主机B的过程

image-20220726091006730

ARP协议

现实中通信时，我们是只知道目标ip的，但最终发送数据包的数据链路层需要知道 MAC 地址，那么如何把IP 地址对应的 MAC 地址找到？

通过ARP协议即可获得在同一个子网下的对方的mac地址

image-20220726081415091

  • 主机会通过广播发送 ARP 请求，这个包中包含了想要知道的 MAC 地址的主机 IP 地址。
  • 当同个链路中的所有设备收到 ARP 请求时，会去拆开 ARP 请求包里的内容，如果 ARP 请求包中的目标 IP 地址与自己的 IP 地址一致，那么这个设备就将自己的 MAC 地址塞入 ARP 响应包返回给主机。

操作系统通常会把第一次通过 ARP 获取的 MAC 地址缓存起来，以便下次直接从缓存中找到对应 IP 地址的 MAC 地址。

拓展：RARP协议

ARP 协议是已知 IP 地址求 MAC 地址，那 RARP 协议正好相反，它是已知 MAC 地址求 IP 地址。例如将打印机服务器等小型嵌入式设备接入到网络时就经常会用得到

image-20220726082238774

IP协议

IP基础

IP分类

IP 在 TCP/IP 参考模型中处于第三层，也就是网络层。

网络层的主要作用是：实现主机与主机之间的通信，也叫点对点（end to end）通信。

image-20220726082611350

IP 地址（IPv4 地址）由 32 位二进制数来表示，最大值为2322^{32} ，也就是最多有43亿个ip地址可供使用

image-20220726083404974

IP地址的分配不是以主机数为单位，而是以服务器、路由器为单位分配的

IP地址的分类

image-20220726084308095

image-20220726084601401

  • 主机号全为 1 指定某个网络下的所有主机，用于广播，即在同一个链路中相互连接的主机之间发送数据包

    image-20220726085210689

  • 主机号全为 0 指定某个网络

因此在ip地址分配时，是需要去掉这两种情况的

例如C类地址可分配数为28−2=2542^8-2=254

该分类方式的缺点：

  • 同一网络下没有地址层次，无法继续划分
  • C类包含的主机数太少了，A、B类包含的主机数又太多了，无法很好的与现实情况匹配
无分类地址CIDR

不再指定分类，而是直接指定网络号的位数，如下就是CIDR地址的一个例子

image-20220726090401176

通过设置子网掩码(在传输时用于判断目标和本机是否在同一个网络里)，可以进一步划分子网

image-20220726090528235

环回地址是在同一台计算机上的程序之间进行网络通信时所使用的一个默认地址。

计算机使用一个特殊的 IP 地址 127.0.0.1 作为环回地址。与该地址具有相同意义的是一个叫做 localhost 的主机名。使用这个 IP 或主机名时，数据包不会流向网络

IP报文格式

TCP 模块在执行连接、收发、断开等各阶段操作时，都需要委托 IP 模块将数据封装成网络包发送给通信对象。

因为 HTTP 是经过 TCP 传输的，所以在 IP 包头的协议号，要填写为 06（十六进制），表示协议为 TCP

当存在多个网卡时，在填写源地址 IP 时，就需要判断到底应该填写哪个地址。这个判断相当于在多块网卡中判断应该使用哪个一块网卡来发送包。

这个时候就需要根据路由表规则，来判断哪一个网卡作为源地址 IP。

在 Linux 操作系统，我们可以使用 route -n 命令查看当前系统的路由表。

image-20220726105351882

IP协议的使用

IP 地址。现在每一台电脑，同时有自己的 MAC 地址，又有自己的 IP 地址，只不过 IP 地址是软件层面上的，可以随时修改，MAC 地址一般是无法修改的。

image-20220725233952883

如果 A 给 C 发数据包，怎么知道是否要通过路由器转发呢？

答案：子网

如果源 IP 与目的 IP 处于一个子网，直接将包通过交换机发出去。

如果源 IP 与目的 IP 不处于一个子网，就交给路由器去处理。

将源 IP 与目的 IP 分别同这个子网掩码进行与运算，相等则是在一个子网，不相等就是在不同子网

image-20220725235013386

所以如果 A 给 C 发消息，A 和 C 的 IP 地址分别 & A 机器配置的子网掩码，发现不相等，则 A 认为 C 和自己不在同一个子网，于是把包发给路由器，就不管了，之后怎么转发，A 不关心。

A 如何知道，哪个设备是路由器？

答案是通过设置默认网关

image-20220725235302149

路由器如何知道C在哪里？

通过路由表来获得

目的地址 下一跳 端口
192.168.0.0/24 0
192.168.0.254/32 0
192.168.1.0/24 1
192.168.1.254/32 1

这就很好理解了，路由表就表示，192.168.0.xxx 这个子网下的，都转发到 0 号端口，192.168.1.xxx 这个子网下的，都转发到 1 号端口。下一跳列还没有值，我们先不管

Image

刚才说的都是 IP 层，但发送数据包的数据链路层需要知道 MAC 地址，可是我只知道 IP 地址该怎么办呢？

通过ARP协议即可获得在同一个子网下的对方的mac地址

与mac地址的区别

image-20220726082828620

总结：

电脑视角：

  • 首先我要知道我的 IP 以及对方的 IP
  • 通过子网掩码判断我们是否在同一个子网
  • 在同一个子网就通过 arp 获取对方 mac 地址直接扔出去
  • 不在同一个子网就通过 arp 获取默认网关的 mac 地址直接扔出去

交换机视角：

  • 我收到的数据包必须有目标 MAC 地址
  • 通过 MAC 地址表查映射关系
  • 查到了就按照映射关系从我的指定端口发出去
  • 查不到就所有端口都发出去

路由器视角：

  • 我收到的数据包必须有目标 IP 地址
  • 通过路由表查映射关系
  • 查到了就按照映射关系从我的指定端口发出去（不在任何一个子网范围，走其路由器的默认网关也是查到了）
  • 查不到则返回一个路由不可达的数据包

如果你嗅觉足够敏锐，你应该可以感受到下面这句话：

网络层（IP协议）本身没有传输包的功能，包的实际传输是委托给数据链路层（以太网中的交换机）来实现的。

涉及到的三张表分别是

  • 交换机中有 MAC 地址表用于映射 MAC 地址和它的端口
  • 路由器中有路由表用于映射 IP 地址(段)和它的端口
  • 电脑和路由器中都有 arp 缓存表用于缓存 IP 和 MAC 地址的映射关系

这三张表是怎么来的

  • MAC 地址表是通过以太网内各节点之间不断通过交换机通信，不断完善起来的。
  • 路由表是各种路由算法 + 人工配置逐步完善起来的。
  • arp 缓存表是不断通过 arp 协议的请求逐步完善起来的。

IP 分片MTU与重组

当IP数据包大小大于MTU(数据链路层最大传输单元，如以太网为1500byte)时，IP数据包就会被分片，经过分片之后的 IP 数据报在被重组的时候，只能由目标主机进行，路由器是不会进行重组的。

image-20220726091646884

在分片传输中，一旦某个分片丢失，则会造成整个 IP 数据报作废，所以 TCP 引入了 MSS 也就是在 TCP 层进行分片不由 IP 层分片，那么对于 UDP 我们尽量不要发送一个大于 MTU 的数据报文。

IPV6

IPv6 的地址是 128 位的，这可分配的地址数量是大的惊人，说个段子 IPv6 可以保证地球上的每粒沙子都能被分配到一个 IP 地址。

亮点：

  • IPv6 可自动配置，即使没有 DHCP 服务器也可以实现自动分配IP地址，真是便捷到即插即用啊。
  • IPv6 包头包首部长度采用固定的值 40 字节，去掉了包头校验和，简化了首部结构，减轻了路由器负荷，大大提高了传输的性能。
  • IPv6 有应对伪造 IP 地址的网络安全功能以及防止线路窃听的功能，大大提升了安全性。

地址表示：

image-20220726091911637

NAT

因为IPV4的地址十分紧缺，在2011年就已经分配完毕，于是提出了网络地址转换NAT方法，用于缓解IPV4耗尽的问题。

简单的来说 NAT 就是同个公司、家庭、教室内的主机对外部通信时，把私有 IP 地址转换成公有 IP 地址。

image-20220726092202841

NATP：转换时把网络地址+端口号一起转换，即把对外通信时把多个私有 IP 地址都转换 IP 地址为公有地址 +不同的端口号作为区分

image-20220726092407061

图中有两个客户端 192.168.1.10 和 192.168.1.11 同时与服务器 183.232.231.172 进行通信，并且这两个客户端的本地端口都是 1025。

此时，两个私有 IP 地址都转换 IP 地址为公有地址 120.229.175.121，但是以不同的端口号作为区分。

于是，生成一个 NAPT 路由器的转换表，就可以正确地转换地址跟端口的组合，令客户端 A、B 能同时与服务器之间进行通信。

这种转换表在 NAT 路由器上自动生成。例如，在 TCP 的情况下，建立 TCP 连接首次握手时的 SYN 包一经发出，就会生成这个表。而后又随着收到关闭连接时发出 FIN 包的确认应答从表中被删除。

缺陷

由于 NAT/NAPT 都依赖于自己的转换表，因此会有以下的问题：

  • 外部无法主动与 NAT 内部服务器建立连接，因为 NAPT 转换表没有转换记录。
  • 转换表的生成与转换操作都会产生性能开销。
  • 通信过程中，如果 NAT 路由器重启了，所有的 TCP 连接都将被重置。

解决方案

  • 改用IPV6

  • NAT穿透技术

    内网穿透拥有这样的功能，它能够让网络应用程序主动发现自己位于 NAT 设备之后，并且会主动获得 NAT 设备的公有 IP，并为自己建立端口映射条目，注意这些都是 NAT设备后的应用程序自动完成的。

    也就是说，在 NAT 穿透技术中，NAT设备后的应用程序处于主动地位，它已经明确地知道 NAT 设备要修改它外发的数据包，于是它主动配合 NAT 设备的操作，主动地建立好映射，这样就不像以前由 NAT 设备来建立映射了。

    说人话，就是客户端主动从 NAT 设备获取公有 IP 地址，然后自己建立端口映射条目，然后用这个条目对外通信，就不需要 NAT 设备来进行转换了。

网络传输协议

DNS

提供将域名网址自动转化为IP地址的功能

DNS 中的域名都是用句点来分隔的，比如 www.server.com，这里的句点代表了不同层次之间的界限。

在域名中，越靠右的位置表示其层级越高，根域是在最顶层，它的下一层就是 com 顶级域，再下面是 server.com

image-20220726095839425

域名解析流程

根域的 DNS 服务器信息保存在互联网中所有的 DNS 服务器中。这样一来，任何 DNS 服务器就都可以找到并访问根域 DNS 服务器了。

因此，客户端只要能够找到任意一台 DNS 服务器，就可以通过它找到根域 DNS 服务器，然后再一路顺藤摸瓜找到位于下层的某台目标 DNS 服务器

解析过程：指路不带路，迭代方式

image-20220726100000517

UDP

UDP 不提供复杂的控制机制，利用 IP 提供面向「无连接」的通信服务。UDP支持一对一、一对多、多对多的交互通信

UDP 协议非常简单，头部只有 8 个字节（ 64 位），UDP 的头部格式如下

image-20220726111617154

  • 目标和源端口：主要是告诉 UDP 协议应该把报文发给哪个进程。
  • 包长度：该字段保存了 UDP 首部的长度跟数据的长度之和。
  • 校验和：校验和是为了提供可靠的 UDP 首部和数据而设计，防止收到在网络传输中受损的 UDP包。

TCP

由于IP 层是「不可靠」的，它不保证网络包的交付、不保证网络包的按序交付、也不保证网络包中的数据的完整性。因此需要TCP协议，它位于传输层，实现进程到进程的通信，提供的是**可靠传输 **(无损坏、无间隔、非冗余和不失序)，是面向连接的、可靠的、基于字节流的传输层通信协议

TCP报文格式

image-20220726104456036

首先，源端口号和目标端口号是不可少的，如果没有这两个端口号，数据就不知道应该发给哪个应用。

接下来有包的序号，在建立连接时由计算机生成的随机数作为其初始值，通过 SYN 包传给接收端主机，每发送一次数据，就「累加」一次该「数据字节数」的大小。用来解决网络包乱序问题。

还有应该有的是确认号，指下一次「期望」收到的数据的序列号，发送端收到这个确认应答以后可以认为在这个序号以前的数据都已经被正常接收。用来解决丢包的问题。

接下来还有一些控制位。例如 SYN 是发起一个连接，ACK 是回复，RST 是重新连接，FIN 是结束连接等。TCP 是面向连接的，因而双方要维护连接的状态，这些带状态位的包的发送，会引起双方的状态变更。

  • ACK：该位为 1 时，「确认应答」的字段变为有效，TCP 规定除了最初建立连接时的 SYN 包之外该位必须设置为 1 。
  • RST：该位为 1 时，表示 TCP 连接中出现异常必须强制断开连接。
  • SYN：该位为 1 时，表示希望建立连接，并在其「序列号」的字段进行序列号初始值的设定。
  • FIN：该位为 1 时，表示今后不会再有数据发送，希望断开连接。当通信结束希望断开连接时，通信双方的主机之间就可以相互交换 FIN 位为 1 的 TCP 段。

还有一个重要的就是窗口大小。TCP 要做流量控制，通信双方各声明一个窗口（缓存大小），标识自己当前的处理能力，别发送的太快，撑死我，也别发的太慢，饿死我。

除了做流量控制以外，TCP还会做拥塞控制，对于真正的通路堵车不堵车，它无能为力，唯一能做的就是控制自己，也即控制发送的速度。不能改变世界，就改变自己嘛。

数据分割MSS

如果 HTTP 请求消息比较长，超过了 MSS 的长度，这时 TCP 就需要把 HTTP 的数据拆解成一块块的数据发送，而不是一次性发送所有数据。

  • MTU：一个网络包的最大长度，以太网中一般为 1500 字节。
  • MSS：除去 IP 和 TCP 头部之后，一个网络包所能容纳的 TCP 数据的最大长度。

image-20220726105150998

image-20220726110123003

既然 IP 层会分片，为什么 TCP 层还需要 MSS 呢？

如果在 TCP 的整个报文（头部 + 数据）交给 IP 层进行分片，会有什么异常呢？

当 IP 层有一个超过 MTU 大小的数据（TCP 头部 + TCP 数据）要发送，那么 IP 层就要进行分片，把数据分片成若干片，保证每一个分片都小于 MTU。把一份 IP 数据报进行分片以后，由目标主机的 IP 层来进行重新组装后，再交给上一层 TCP 传输层。

这看起来井然有序，但这存在隐患的，那么当如果一个 IP 分片丢失，整个 IP 报文的所有分片都得重传。

因为 IP 层本身没有超时重传机制，它由传输层的 TCP 来负责超时和重传。

当接收方发现 TCP 报文（头部 + 数据）的某一片丢失后，则不会响应 ACK 给对方，那么发送方的 TCP 在超时后，就会重发「整个 TCP 报文（头部 + 数据）」。

因此，可以得知由 IP 层进行分片传输，是非常没有效率的。

所以，为了达到最佳的传输效能 TCP 协议在建立连接的时候通常要协商双方的 MSS 值，当 TCP 层发现数据超过 MSS 时，则就先会进行分片，当然由它形成的 IP 包的长度也就不会大于 MTU ，自然也就不用 IP 分片了。

经过 TCP 层分片后，如果一个 TCP 分片丢失后，进行重发时也是以 MSS 为单位，而不用重传所有的分片，大大增加了重传的效率。

TCP连接的表示

用于保证可靠性和流量控制维护的某些状态信息，这些信息的组合，包括Socket、序列号和窗口大小称为连接

因此建立一个 TCP 连接是需要客户端与服务器端达成以下三个信息的共识

image-20220726110840521

  • Socket：由 IP 地址和端口号组成
  • 序列号：用来解决乱序问题等
  • 窗口大小：用来做流量控制

唯一确定一个TCP连接: 源地址 源端口 目标地址 目标端口

  • 源地址和目的地址的字段（32位）是在 IP 头部中，作用是通过 IP 协议发送报文给对方主机。

  • 源端口和目的端口的字段（16位）是在 TCP 头部中，作用是告诉 TCP 协议应该把报文发给哪个进程

TCP最大连接数理论上限为 $ 2^{32} * 2^{16}$，但是由于每个TCP连接在计算机中都是一个文件，会受文件描述符限制和内存限制，从而远远不能到达上限

TCP连接建立-三次握手

三次握手过程

在 HTTP 传输数据之前，首先需要 TCP 建立连接，TCP 连接的建立，通常称为三次握手。

这个所谓的「连接」，只是双方计算机里维护一个状态机，在连接建立的过程中，双方的状态变化时序图就像这样。

image-20220726104849888

  • 一开始，客户端和服务端都处于 CLOSED 状态。先是服务端主动监听某个端口，处于 LISTEN 状态。

  • 客户端会随机初始化序号（client_isn），将此序号置于 TCP 首部的「序号」字段中，同时把 SYN 标志位置为 1 ，表示 SYN 报文。接着把第一个 SYN 报文发送给服务端，表示向服务端发起连接，该报文不包含应用层数据，之后客户端处于 SYN-SENT 状态。

    image-20220726112005427

    若第一次握手丢失了，也就是客户端迟迟收不到服务端的 SYN-ACK 报文（第二次握手），就会触发「超时重传」机制，重传 SYN 报文，那么最多重传几次呢？在 Linux 里，客户端的 SYN 报文最大重传次数由 tcp_syn_retries内核参数控制，这个参数是可以自定义的，默认值一般是 5。

    通常，第一次超时重传是在 1 秒后，第二次超时重传是在 2 秒，第三次超时重传是在 4 秒后，第四次超时重传是在 8 秒后，第五次是在超时重传 16 秒后。没错，每次超时的时间是上一次的 2 倍。

    当第五次超时重传后，会继续等待 32 秒，如果服务端仍然没有回应 ACK，客户端就不再发送 SYN 包，然后断开 TCP 连接。

    所以，总耗时是 1+2+4+8+16+32=63 秒，大约 1 分钟左右。

  • 服务端收到客户端的 SYN 报文后，首先服务端也随机初始化自己的序号（server_isn），将此序号填入 TCP 首部的「序号」字段中，其次把 TCP 首部的「确认应答号」字段填入 client_isn + 1, 接着把 SYN 和 ACK 标志位置为 1。最后把该报文发给客户端，该报文也不包含应用层数据，之后服务端处于 SYN-RCVD 状态。

    image-20220726112206074

    若第二次握手丢失了，客户端会认为自己的第一次握手报文丢失，会触发重传机制，同时，服务端也会收不到第三次握手的报文认为第二次握手报文(SYN+ACK)发送失败，也会触发超时重传机制

    在 Linux 下，SYN-ACK 报文的最大重传次数由 tcp_synack_retries内核参数决定，默认值是 5。

    因此，当第二次握手丢失了，客户端和服务端都会重传：

    • 客户端会重传 SYN 报文，也就是第一次握手，最大重传次数由 tcp_syn_retries内核参数决定；
    • 服务端会重传 SYN-ACK 报文，也就是第二次握手，最大重传次数由 tcp_synack_retries 内核参数决定。

  • 客户端收到服务端报文后，还要向服务端回应最后一个应答报文，首先该应答报文 TCP 首部 ACK 标志位置为 1 ，其次「确认应答号」字段填入 server_isn + 1 ，最后把报文发送给服务端，这次报文可以携带客户到服务器的数据，之后客户端处于 ESTABLISHED 状态

    image-20220726112402560

    若第三次握手丢失了，此时客户端状态已经进入到 ESTABLISH 状态，而服务端那一方迟迟收不到这个确认报文，就会触发超时重传机制，重传 SYN-ACK 报文，直到收到第三次握手，或者达到最大重传次数。

  • 服务端收到 ACK 的 ACK 之后，处于 ESTABLISHED 状态，因为它也一发一收了。

所以三次握手目的是保证双方都有发送和接收的能力

为什么一定是三次握手

  • 避免历史连接(首要原因)

    三次握手的首要原因是为了防止旧的重复连接初始化造成混乱

    下图就是一个避免历史连接的例子

    image-20220726113459224

    但如果只有两次握手，则无法避免，因为在两次握手的情况下，「被动发起方」没有中间状态给「主动发起方」来阻止历史连接，导致「被动发起方」可能建立一个历史连接，造成资源浪费

    image-20220726113637453

    因此要解决这种现象，最好就是在「被动发起方」发送数据前，也就是建立连接之前，要阻止掉历史连接，这样就不会造成资源浪费，而要实现这个功能，就需要三次握手

  • 同步双方初始序列号

    TCP 协议的通信双方， 都必须维护一个「序列号」， 序列号是可靠传输的一个关键因素，它的作用：

    • 接收方可以去除重复的数据；
    • 接收方可以根据数据包的序列号按序接收；
    • 可以标识发送出去的数据包中， 哪些是已经被对方收到的（通过 ACK 报文中的序列号知道）；

    可见，序列号在 TCP 连接中占据着非常重要的作用，所以当客户端发送携带「初始序列号」的 SYN 报文的时候，需要服务端回一个 ACK 应答报文，表示客户端的 SYN 报文已被服务端成功接收，那当服务端发送「初始序列号」给客户端的时候，依然也要得到客户端的应答回应，这样一来一回，才能确保双方的初始序列号能被可靠的同步

    image-20220726114504541

  • 避免资源浪费

总结不使用「两次握手」和「四次握手」的原因：

  • 「两次握手」：无法防止历史连接的建立，会造成双方资源的浪费，也无法可靠的同步双方序列号；
  • 「四次握手」：三次握手就已经理论上最少可靠连接建立，所以不需要使用更多的通信次数。
为什么序列号初始化需要随机生成

主要原因有两个方面：

  • 为了安全性，防止黑客伪造的相同序列号的 TCP 报文被对方接收

  • 为了防止历史报文被下一个相同四元组的连接接收（主要方面）；

    假设初始序列号都固定为0，若网络延迟，且连接四元组相同，则可能会接受历史报文(即接受已关闭的连接的报文)

    image-20220726114928744

    可以看到，如果每次建立连接，客户端和服务端的初始化序列号都是一样的话，很容易出现历史报文被下一个相同四元组的连接接收的问题

    采用随机的序列号则不会有这个问题

    image-20220726115449502

初始序列号随机生成算法

起始 ISN 是基于时钟的，每 4 微秒 + 1，转一圈要 4.55 个小时。

RFC793 提到初始化序列号 ISN 随机生成算法：ISN = M + F(localhost, localport, remotehost, remoteport)。

  • M 是一个计时器，这个计时器每隔 4 微秒加 1。
  • F 是一个 Hash 算法，根据源 IP、目的 IP、源端口、目的端口生成一个随机数值。要保证 Hash 算法不能被外部轻易推算得出，用 MD5 算法是一个比较好的选择。

可以看到，随机数是会基于时钟计时器递增的，基本不可能会随机成一样的初始化序列号。

TCP连接断开

双方都可以主动断开连接，断开连接后主机中的「资源」将被释放，四次挥手的过程如下图：

image-20220727085425063

  • 第一次挥手：客户端打算关闭连接，此时会发送一个 TCP 首部 FIN 标志位被置为 1 的报文，也即 FIN 报文，之后客户端进入 FIN_WAIT_1 状态。

    若第一次挥手丢失，则客户端讲迟迟收不到被动方的 ACK ，也就会触发超时重传机制，重传 FIN 报文，重发次数由 tcp_orphan_retries 参数控制。当重发次数超过该参数限制，就不再发送 FIN 报文，直接进入到 close 状态。

  • 第二次挥手：服务端收到该报文后，就向客户端发送 ACK 应答报文，接着服务端进入 CLOSED_WAIT 状态。客户端收到服务端的 ACK 应答报文后，之后进入 FIN_WAIT_2 状态。

    若第二次挥手丢失，则客户端就会触发超时重传机制，重传 FIN 报文，直到收到服务端的第二次挥手，或者达到最大的重传次数。

  • 第三次挥手：等待服务端处理完数据后，也向客户端发送 FIN 报文，之后服务端进入 LAST_ACK 状态。

    若第三次挥手丢失，则服务端就会重发 FIN 报文，重发次数仍然由 tcp_orphan_retries 参数控制，这与客户端重发 FIN 报文的重传次数控制方式是一样的

  • 第四次挥手：客户端收到服务端的 FIN 报文后，回一个 ACK 应答报文，之后进入 TIME_WAIT 状态，服务器收到了 ACK 应答报文后，就进入了 CLOSED 状态，至此服务端已经完成连接的关闭。

    若第四次挥手丢失，则服务端就会重发 FIN 报文，重发次数仍然由前面介绍过的 tcp_orphan_retries 参数控制

  • 客户端在经过 2MSL 一段时间后，自动进入 CLOSED 状态，至此客户端也完成连接的关闭。

你可以看到，每个方向都需要一个 FIN 和一个 ACK，因此通常被称为四次挥手。

这里一点需要注意是：主动关闭连接的，才有 TIME_WAIT 状态。

为什么挥手需要四次
  • 关闭连接时，客户端向服务端发送 FIN 时，仅仅表示客户端不再发送数据了但是还能接收数据。
  • 服务器收到客户端的 FIN 报文时，先回一个 ACK 应答报文，而服务端可能还有数据需要处理和发送，等服务端不再发送数据时，才发送 FIN 报文给客户端来表示同意现在关闭连接。

从上面过程可知，服务端通常需要等待完成数据的发送和处理，所以服务端的 ACK 和 FIN 一般都会分开发送，从而比三次握手导致多了一次

TIME_WAIT为什么是2MSL

MSL 是 Maximum Segment Lifetime，报文最大生存时间，它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。因为 TCP 报文基于是 IP 协议的，而 IP 头中有一个 TTL 字段，是 IP 数据报可以经过的最大路由数，每经过一个处理他的路由器此值就减 1，当此值为 0 则数据报将被丢弃，同时发送 ICMP 报文通知源主机。

MSL 与 TTL 的区别： MSL 的单位是时间，而 TTL 是经过路由跳数。所以 MSL 应该要大于等于 TTL 消耗为 0 的时间，以确保报文已被自然消亡。

TTL 的值一般是 64，Linux 将 MSL 设置为 30 秒，意味着 Linux 认为数据报文经过 64 个路由器的时间不会超过 30 秒，如果超过了，就认为报文已经消失在网络中了。

**TIME_WAIT 等待 2 倍的 MSL，比较合理的解释是： **

网络中可能存在来自发送方的数据包，当这些发送方的数据包被接收方处理后又会向对方发送响应，所以一来一回需要等待 2 倍的时间。比如，如果被动关闭方没有收到断开连接的最后的 ACK 报文，就会触发超时重发 FIN 报文，另一方接收到 FIN 后，会重发 ACK 给被动关闭方， 一来一去正好 2 个 MSL。可以看到 2MSL时长 这其实是相当于至少允许报文丢失一次。比如，若 ACK 在一个 MSL 内丢失，这样被动方重发的 FIN 会在第 2 个 MSL 内到达，TIME_WAIT 状态的连接可以应对。

2MSL 的时间是从客户端接收到 FIN 后发送 ACK 开始计时的。如果在 TIME-WAIT 时间内，因为客户端的 ACK 没有传输到服务端，客户端又接收到了服务端重发的 FIN 报文，那么 2MSL 时间将重新计时，在 Linux 系统里 2MSL 默认是 60 秒，那么一个 MSL 也就是 30 秒。Linux 系统停留在 TIME_WAIT 的时间为固定的 60 秒。

为什么需要TIME_WAIT状态

主动发起关闭连接的一方，才会有 TIME-WAIT 状态。

需要 TIME-WAIT 状态，主要是两个原因：

  • 防止历史连接中的数据，被后面相同四元组的连接错误的接收；

    image-20220727093228724

    因此，为了防止历史连接中的数据，被后面相同四元组的连接错误的接收，因此 TCP 设计了 TIME_WAIT 状态，状态会持续 2MSL 时长，这个时间足以让两个方向上的数据包都被丢弃，使得原来连接的数据包在网络中都自然消失，再出现的数据包一定都是新建立连接所产生的

  • 保证「被动关闭连接」的一方，能被正确的关闭；即等待足够的时间以确保最后的 ACK 能让被动关闭方接收，从而帮助其正常关闭。

    image-20220727093419068

    image-20220727093446810

TIME_WAIT 是我们的朋友，它是有助于我们的，不要试图避免这个状态，而是应该弄清楚它。

如果服务端要避免过多的 TIME_WAIT 状态的连接，就永远不要主动断开连接，让客户端去断开，由分布在各处的客户端去承受 TIME_WAIT

TCP 有一个机制是保活机制。应用程序若想使用 TCP 保活机制需要通过 socket 接口设置 SO_KEEPALIVE 选项才能够生效，如果没有设置，那么就无法使用 TCP 保活机制

这个机制的原理是这样的：定义一个时间段，在这个时间段内，如果没有任何连接相关的活动，TCP 保活机制会开始作用，每隔一个时间间隔，发送一个探测报文，该探测报文包含的数据非常少，如果连续几个探测报文都没有得到响应，则认为当前的 TCP 连接已经死亡，系统内核将错误信息通知给上层应用程序。

在 Linux 内核可以有对应的参数可以设置保活时间、保活探测的次数、保活探测的时间间隔，以下都为默认值：

1
2
3
net.ipv4.tcp_keepalive_time=7200
net.ipv4.tcp_keepalive_intvl=75  
net.ipv4.tcp_keepalive_probes=9
  • tcp_keepalive_time=7200：表示保活时间是 7200 秒（2小时），也就 2 小时内如果没有任何连接相关的活动，则会启动保活机制
  • tcp_keepalive_intvl=75：表示每次检测间隔 75 秒；
  • tcp_keepalive_probes=9：表示检测 9 次无响应，认为对方是不可达的，从而中断本次的连接。

image-20220727094519151

TCP 保活的这个机制检测的时间是有点长，我们可以自己在应用层实现一个心跳机制。

比如，web 服务软件一般都会提供 keepalive_timeout 参数，用来指定 HTTP 长连接的超时时间。如果设置了 HTTP 长连接的超时时间是 60 秒，web 服务软件就会启动一个定时器，如果客户端在完后一个 HTTP 请求后，在 60 秒内都没有再发起新的请求，定时器的时间一到，就会触发回调函数来释放该连接。

image-20220727094739588

Socket编程

TCP 连接 Socket全编程

image-20220727094929338

  • 服务端和客户端初始化 socket，得到文件描述符；
  • 服务端调用 bind，将绑定在 IP 地址和端口;
  • 服务端调用 listen，进行监听；
  • 服务端调用 accept，等待客户端连接；
  • 客户端调用 connect，向服务器端的地址和端口发起连接请求；
  • 服务端 accept 连接成功了会返回一个已完成连接的 socket，后续用来传输数据。
  • 客户端调用 write 写入数据；服务端调用 read 读取数据，就像往一个文件流里面写东西一样
  • 客户端断开连接时，会调用 close，那么服务端 read 读取数据的时候，就会读取到了 EOF，待处理完数据后，服务端调用 close，表示连接关闭。
listen函数

Linux内核中会维护两个队列：

  • 半连接队列（SYN 队列）：接收到一个 SYN 建立连接请求，处于 SYN_RCVD 状态；
  • 全连接队列（Accpet 队列）：已完成 TCP 三次握手过程，处于 ESTABLISHED 状态；

image-20220727095447231

1
int listen (int socketfd, int backlog)
  • 参数一 socketfd 为 socketfd 文件描述符
  • 参数二 backlog，这参数在历史版本有一定的变化

在早期 Linux 内核 backlog 是 SYN 队列大小，也就是未完成的队列大小。

在 Linux 内核 2.2 之后，backlog 变成 accept 队列，也就是已完成连接建立的队列长度，所以现在通常认为 backlog 是 accept 队列。

但是上限值是内核参数 somaxconn 的大小，也就说 accpet 队列长度 = min(backlog, somaxconn)。

accept函数

image-20220727095808901

  • 客户端的协议栈向服务器端发送了 SYN 包，并告诉服务器端当前发送序列号 client_isn，客户端进入 SYN_SENT 状态；
  • 服务器端的协议栈收到这个包之后，和客户端进行 ACK 应答，应答的值为 client_isn+1，表示对 SYN 包 client_isn 的确认，同时服务器也发送一个 SYN 包，告诉客户端当前我的发送序列号为 server_isn，服务器端进入 SYN_RCVD 状态；
  • 客户端协议栈收到 ACK 之后，使得应用程序从 connect 调用返回，表示客户端到服务器端的单向连接建立成功，客户端的状态为 ESTABLISHED，同时客户端协议栈也会对服务器端的 SYN 包进行应答，应答数据为 server_isn+1；
  • ACK 应答包到达服务器端后，服务器端的 TCP 连接进入 ESTABLISHED 状态，同时服务器端协议栈使得 accept 阻塞调用返回，这个时候服务器端到客户端的单向连接也建立成功。至此，客户端与服务端两个方向的连接都建立成功。

从上面的描述过程，我们可以得知客户端 connect 成功返回是在第二次握手，服务端 accept 成功返回是在三次握手成功之后。

close函数

image-20220727100043764

  • 客户端调用 close，表明客户端没有数据需要发送了，则此时会向服务端发送 FIN 报文，进入 FIN_WAIT_1 状态；
  • 服务端接收到了 FIN 报文，TCP 协议栈会为 FIN 包插入一个文件结束符 EOF 到接收缓冲区中，应用程序可以通过 read 调用来感知这个 FIN 包。这个 EOF 会被放在已排队等候的其他已接收的数据之后，这就意味着服务端需要处理这种异常情况，因为 EOF 表示在该连接上再无额外数据到达。此时，服务端进入 CLOSE_WAIT 状态；
  • 接着，当处理完数据后，自然就会读到 EOF，于是也调用 close 关闭它的套接字，这会使得服务端发出一个 FIN 包，之后处于 LAST_ACK 状态；
  • 客户端接收到服务端的 FIN 包，并发送 ACK 确认包给服务端，此时客户端将进入 TIME_WAIT 状态；
  • 服务端收到 ACK 确认包后，就进入了最后的 CLOSE 状态；
  • 客户端经过 2MSL 时间之后，也进入 CLOSE 状态；

TCP可靠性传输

重传机制

TCP 实现可靠传输的方式之一，是通过序列号与确认应答。

在 TCP 中，当发送端的数据到达接收主机时，接收端主机会返回一个确认应答消息，表示已收到消息

image-20220726132549905

理想情况如上图所示，但在真实环境中发送出的包可能会由于网络等问题而丢失，所以 TCP 针对数据包丢失的情况，会用重传机制解决

  • 超时重传

    发送时设置一个定时器，超过指定时间后没收到对方的ACK确认应答报文，则会重传。重传的场景有以下两种

    • 数据报丢失
    • 确认应答丢失

    image-20220726133953383

    那么如何设置合适的超时时间呢

    RTT：包的往返时间

    超时重传时间是以 RTO （Retransmission Timeout 超时重传时间）表示

    image-20220726134157631

    因此RTO应该略大于RTT

    image-20220726134505389

    但因为我们的网络是时常变化的，所以RTT也是经常波动变化的，因此RTO应该一个动态变化的值

    image-20220726134954315

    超时重传的缺点：超时周期相对较长

  • 快速重传(Fast Retransmit)

    不以时间为驱动 而是以数据驱动重传

    image-20220726135323617

    发送端收到了三个 Ack = 2 的确认，知道了 Seq2 还没有收到，就会在定时器过期之前，重传丢失的 Seq2。

    缺陷：重传的时候，是重传之前的一个，还是重传所有的问题。比如对于上面的例子，是重传 Seq2 呢？还是重传 Seq2、Seq3、Seq4、Seq5 呢？因为发送端并不清楚这连续的三个 Ack 2 是谁传回来的。根据 TCP 不同的实现，以上两种情况都是有可能的。可见，这是一把双刃剑。为了解决不知道该重传哪些 TCP 报文，于是就有 SACK 方法

  • SACK方法(Selective Acknowledgment 选择性确认)

    这种方式需要在 TCP 头部「选项」字段里加一个 SACK 的东西，它可以将缓存的地图发送给发送方，这样发送方就可以知道哪些数据收到了，哪些数据没收到，知道了这些信息，就可以只重传丢失的数据

    image-20220726140034405

    如果要支持 SACK，必须双方都要支持。在 Linux 下，可以通过 net.ipv4.tcp_sack 参数打开这个功能（Linux 2.4 后默认打开）

  • Duplicate SACK

    Duplicate SACK 又称 D-SACK，其主要使用了 SACK 来告诉「发送方」有哪些数据被重复接收了

    image-20220726140652792

    image-20220726140915633

    可见，D-SACK 有这么几个好处：

    1. 可以让「发送方」知道，是发出去的包丢了，还是接收方回应的 ACK 包丢了;
    2. 可以知道是不是「发送方」的数据包被网络延迟了;
    3. 可以知道网络中是不是把「发送方」的数据包给复制了;

    在 Linux 下可以通过 net.ipv4.tcp_dsack 参数开启/关闭这个功能（Linux 2.4 后默认打开）

滑动窗口

没有滑动窗口时，TCP 每发送一个数据，都要进行一次确认应答。当上一个数据包收到了应答了， 才会发送下一个

image-20220726141557019

为了解决这个问题，TCP 引入了窗口这个概念。即使在往返时间较长的情况下，它也不会降低网络通信的效率。

那么有了窗口，就可以指定窗口大小，窗口大小就是指无需等待确认应答，而可以继续发送数据的最大值。

假设窗口大小为3，则发送过程如下

image-20220726141839245

图中的 ACK 600 确认应答报文丢失，也没关系，因为可以通过下一个确认应答进行确认，只要发送方收到了 ACK 700 确认应答，就意味着 700 之前的所有数据「接收方」都收到了。这个模式就叫累计确认或者累计应答。

窗口大小是由接收方的TCP里的window字段决定，这个字段是接收端告诉发送端自己还有多少缓冲区可以接收数据。于是发送端就可以根据这个接收端的处理能力来发送数据，而不会导致接收端处理不过来。

发送方的滑动窗口

窗口还由空余位置时：

image-20220726142640053

窗口没有空余位置时，表明可用窗口耗尽，在没收到 ACK 确认之前是无法继续发送数据

image-20220726142804478

当收到ACK确认应答后，窗口右移

image-20220726142956021

接收方的滑动窗口

简单很多。但需要注意发送方的窗口大小和接收方的窗口大小并不是完全相等，接收窗口的大小是约等于发送窗口的大小的。因为滑动窗口并不是一成不变的。比如，当接收方的应用进程读取数据的速度非常快的话，这样的话接收窗口可以很快的就空缺出来。那么新的接收窗口大小，是通过 TCP 报文中的 Windows 字段来告诉发送方。那么这个传输过程是存在时延的，所以接收窗口和发送窗口是约等于的关系。

image-20220726143746565

滑动窗口如何表示

image-20220726143104584

  • SND.WND：表示发送窗口的大小（大小是由接收方指定的）；

  • SND.UNA（Send Unacknoleged）：是一个绝对指针，它指向的是已发送但未收到确认的第一个字节的序列号，也就是 #2 的第一个字节。

  • SND.NXT：也是一个绝对指针，它指向未发送但可发送范围的第一个字节的序列号，也就是 #3 的第一个字节。

  • 指向 #4 的第一个字节是个相对指针，它需要 SND.UNA 指针加上 SND.WND 大小的偏移量，就可以指向 #4 的第一个字节了。

    可用窗口大 = SND.WND -（SND.NXT - SND.UNA）

流量控制

发送方不能无脑向接收方发送数据，否则若超出了对方的处理能力范围，则会触发重传机制，无端浪费网络资源，为了解决该问题，TCP 提供一种机制可以让「发送方」根据「接收方」的实际接收能力控制发送的数据量，这就是所谓的流量控制

下面的例子先假定窗口大小是固定的，来体验一下数据收发过程

img

发送窗口和接收窗口中所存放的字节数，都是放在操作系统内存缓冲区中的，而操作系统的缓冲区，会被操作系统调整。

  • 当应用进程没办法及时读取缓冲区的内容时，窗口大小将会被下调并通知发送者，从而做到流量控制

img

  • 当服务端系统资源非常紧张的时候，操心系统可能会直接减少了接收缓冲区大小，这时应用程序又无法及时读取缓存数据，那么这时候就有严重的事情发生了，会出现数据包丢失的现象。

    image-20220726150032600

    因此，如果发生了先减少缓存，再收缩窗口，就会出现丢包的现象。为了防止这种情况发生，TCP 规定是不允许同时减少缓存又收缩窗口的，而是采用先收缩窗口，过段时间再减少缓存，这样就可以避免了丢包情况

窗口关闭

如果窗口大小为 0 时，就会阻止发送方给接收方传递数据，直到窗口变为非 0 为止，这就是窗口关闭。

风险：当发生窗口关闭时，接收方处理完数据后，会向发送方通告一个窗口非 0 的 ACK 报文，如果这个通告窗口的 ACK 报文在网络中丢失了，那麻烦就大了

image-20220726151800176

为了解决这个问题，TCP 为每个连接设有一个持续定时器，只要 TCP 连接一方收到对方的零窗口通知，就启动持续计时器。

如果持续计时器超时，就会发送窗口探测 ( Window probe ) 报文，而对方在确认这个探测报文时，给出自己现在的接收窗口大小。

image-20220726153658273

糊涂窗口综合征

如果接收方腾出几个字节并告诉发送方现在有几个字节的窗口，而发送方会义无反顾地发送这几个字节，这就是糊涂窗口综合症。要知道，我们的 TCP + IP 头有 40 个字节，为了传输那几个字节的数据，要达上这么大的开销，这太不经济了。

image-20220726153827717

所以，糊涂窗口综合症的现象是可以发生在发送方和接收方：

  • 接收方可以通告一个小的窗口
  • 而发送方可以发送小数据

于是，要解决糊涂窗口综合症，就解决上面两个问题就可以了

  • 让接收方不通告小窗口给发送方
  • 让发送方避免发送小数据

接收方常用策略：

当「窗口大小」小于 min( MSS，缓存空间/2 ) ，也就是小于 MSS 与 1/2 缓存大小中的最小值时，就会向发送方通告窗口为 0，也就阻止了发送方再发数据过来，等到接收方处理了一些数据后，窗口大小 >= MSS，或者接收方缓存空间有一半可以使用，就可以把窗口打开让发送方发送数据过来

发送方通常的策略：

使用 Nagle 算法，该算法的思路是延时处理，它满足以下两个条件中的一条才可以发送数据：

  • 要等到窗口大小 >= MSS 或是 数据大小 >= MSS
  • 收到之前发送数据的 ack 回包

只要没满足上面条件中的一条，发送方一直在囤积数据，直到满足上面的发送条件。

另外，Nagle 算法默认是打开的，如果对于一些需要小数据包交互的场景的程序，比如，telnet 或 ssh 这样的交互性比较强的程序，则需要关闭 Nagle 算法。

image-20220727141456171

  • 一开始由于没有已发送未确认的报文，所以就立刻发了 H 字符；
  • 接着，在还没收到对 H 字符的确认报文时，发送方就一直在囤积数据，直到收到了确认报文后，此时没有已发送未确认的报文，于是就把囤积后的 ELL 字符一起发给了接收方；
  • 待收到对 ELL 字符的确认报文后，于是把最后一个 O 字符发送了出去

可以看出，Nagle 算法一定会有一个小报文，也就是在最开始的时候。

可以在 Socket 设置 TCP_NODELAY 选项来关闭这个算法（关闭 Nagle 算法没有全局参数，需要根据每个应用自己的特点来关闭）

延迟确认又是什么？

事实上当没有携带数据的 ACK，它的网络效率也是很低的，因为它也有 40 个字节的 IP 头 和 TCP 头，但却没有携带数据报文。

为了解决 ACK 传输效率低问题，所以就衍生出了 TCP 延迟确认。

TCP 延迟确认的策略：

  • 当有响应数据要发送时，ACK 会随着响应数据一起立刻发送给对方
  • 当没有响应数据要发送时，ACK 将会延迟一段时间，以等待是否有响应数据可以一起发送
  • 如果在延迟等待发送 ACK 期间，对方的第二个数据报文又到达了，这时就会立刻发送 ACK

image-20220727141802448

发送方使用了 Nagle 算法，接收方使用了 TCP 延迟确认会发生如下的过程:

image-20220727142007164

这两个同时使用会造成额外的时延，这就会使得网络"很慢"的感觉。

要解决这个问题，只有两个办法：

  • 要不发送方关闭 Nagle 算法
  • 要不接收方关闭 TCP 延迟确认
拥塞控制

有了流量控制为什么还需要拥塞控制？

因为流量控制是避免「发送方」的数据填满「接收方」的缓存，但是并不知道网络的中发生了什么。在网络出现拥堵时，如果继续发送大量数据包，可能会导致数据包时延、丢失等，这时 TCP 就会重传数据，但是一重传就会导致网络的负担更重，于是会导致更大的延迟以及更多的丢包，这个情况就会进入恶性循环被不断地放大…

所以，TCP 不能忽略网络上发生的事，它被设计成一个无私的协议，当网络发送拥塞时，TCP 会自我牺牲，降低发送的数据量。

于是，就有了拥塞控制，控制的目的就是避免「发送方」的数据填满整个网络

为了在「发送方」调节所要发送数据的量，定义了一个叫做「拥塞窗口」的概念。

什么是拥塞窗口？和发送窗口有什么关系呢？

拥塞窗口 cwnd是发送方维护的一个的状态变量，它会根据网络的拥塞程度动态变化的。

我们在前面提到过发送窗口 swnd 和接收窗口 rwnd 是约等于的关系，那么由于加入了拥塞窗口的概念后，此时发送窗口的值是swnd=min(cwnd,rwnd)swnd = min(cwnd, rwnd)

拥塞窗口 cwnd 变化的规则：

  • 只要网络中没有出现拥塞，cwnd 就会增大；
  • 但网络中出现了拥塞，cwnd 就减少；

只要「发送方」没有在规定时间内接收到 ACK 应答报文，也就是发生了超时重传，就会认为网络出现了拥塞。

慢启动

即连接刚建立完成后，会逐渐提高发送的数据包数量

当发送方每收到一个 ACK，拥塞窗口 cwnd 的大小就会加 1

image-20220727082331521

有一个叫慢启动门限 ssthresh （slow start threshold）状态变量。

  • 当 cwnd < ssthresh 时，使用慢启动算法。
  • 当 cwnd >= ssthresh 时，就会使用「拥塞避免算法」

拥塞避免

一般来说 ssthresh 的大小是 65535 字节。

那么进入拥塞避免算法后，它的规则是：每当收到一个 ACK 时，cwnd 增加 1/cwnd。

接上前面的慢启动的栗子，现假定 ssthresh 为 8，当 8 个 ACK 应答确认到来时，每个确认增加 1/8，8 个 ACK 确认 cwnd 一共增加 1，于是这一次能够发送 9 个 MSS 大小的数据，变成了线性增长

image-20220727082644701

因此，拥塞避免算法是把指数增长变为了线性增长，很好的避免了拥塞。但仍然会一直增长，网络就会慢慢进入了拥塞的状况了，于是就会出现丢包现象，这时就需要对丢失的数据包进行重传。当触发了重传机制，也就进入了「拥塞发生算法」

拥塞发生

当网络出现拥塞，也就是会发生数据包重传，重传机制主要有两种：

  • 超时重传

    发生了超时重传时，会使用拥塞发生算法，这个时候，ssthresh 和 cwnd 的值会发生变化：

    • ssthresh 设为 cwnd/2，
    • cwnd 重置为 1 （是恢复为 cwnd 初始化值，我这里假定 cwnd 初始化值 1）

    image-20220727083239362

    这种方法会突然减少数据流的。这真是一旦「超时重传」，马上回到解放前。但是这种方式太激进了，反应也很强烈，容易造成网络卡顿。

  • 快速重传

    当接收方发现丢了一个中间包的时候，发送三次前一个包的 ACK，于是发送端就会快速地重传，不必等待超时再重传。

    TCP 认为这种情况不严重，因为大部分没丢，只丢了一小部分，则 ssthresh 和 cwnd 变化如下：

    • cwnd = cwnd/2 ，也就是设置为原来的一半;

    • ssthresh = cwnd;

    • 进入快速恢复算法

      • 拥塞窗口 cwnd = ssthresh + 3 （ 3 的意思是确认有 3 个数据包被收到了）；
      • 重传丢失的数据包；
      • 如果再收到重复的 ACK，那么 cwnd 增加 1；
      • 如果收到新数据的 ACK 后，把 cwnd 设置为第一步中的 ssthresh 的值，原因是该 ACK 确认了新的数据，说明从 duplicated ACK 时的数据都已收到，该恢复过程已经结束，可以回到恢复之前的状态了，也即再次进入拥塞避免状态；

      image-20220727083531523

TCP抓包

使用ping指定icmp包个数
1
2
3
# -c 3 表示发出3个ICMP包
# -I wlp5s0 表示从eth1网口发出去
ping -I wlp5s0 -c 3 47.113.189.109

image-20220727101928743

抓取ping命令数据包

要抓取上面的 ping 命令数据包，首先我们要知道 ping 的数据包是 icmp 协议，接着在使用 tcpdump 抓包的时候，就可以指定只抓 icmp 协议的数据包

1
2
3
4
5
# -i 指定抓取的网口 icmp 指定抓取icmp协议数据包 host 指定ip -nn 不解析IP和端口
tcpdump -i wlp5s0 icmp and host 47.113.189.109 -nn

# 输出格式：
# 		时间戳 协议 源地址：源端口>目的地址：目的端口 网络包详细信息

image-20220727102317798

其它常用tcpdump命令

image-20220727103158280

过滤表达式

image-20220727103330655

可见，tcpdump 虽然功能强大，但是输出的格式并不直观。

所以，在工作中 tcpdump 只是用来抓取数据包，不用来分析数据包，而是把 tcpdump 抓取的数据包保存成 pcap 后缀的文件，接着用 Wireshark 工具进行数据包分析

使用Wireshark分析保存的pcap文件

  1. 抓包到的数据保存到桌面

    1
    tcpdump -i wlp5s0 icmp and host 47.113.189.109 -nn -w ~/Desktop/ping.pcap

    image-20220727103803192

  2. 使用Wireshark打开后可以发现

    在 Wireshark 的页面里，可以更加直观的分析数据包，不仅展示各个网络包的头部信息，还会用不同的颜色来区分不同的协议，由于这次抓包只有 ICMP 协议，所以只有紫色的条目。

    接着，在网络包列表中选择某一个网络包后，在其下面的网络包详情中，可以更清楚的看到，这个网络包在协议栈各层的详细信息。

    image-20220727111505254

    • 可以在数据链路层，看到 MAC 包头信息，如源 MAC 地址和目标 MAC 地址等字段；
    • 可以在 IP 层，看到 IP 包头信息，如源 IP 地址和目标 IP 地址、TTL、IP 包长度、协议等 IP 协议各个字段的数值和含义；
    • 可以在 ICMP 层，看到 ICMP 包头信息，比如 Type、Code 等 ICMP 协议各个字段的数值和含义；

    Wireshark 用了分层的方式，展示了各个层的包头信息，把“不可见”的数据包，清清楚楚的展示了给我们

    image-20220727111556803

解密三次握手和四次挥手

image-20220727112908580

打开Wireshark分析

两个不同的TCP的三次握手

image-20220727113839669

两个不同的TCP的四次挥手(51914这个只有三次，因为服务器端数据已发送完毕了，这样就可以把 ACK 和 FIN 合并到一起发送，节省了一个包)

image-20220727113611694

Wireshark 可以用时序图的方式显示数据包交互的过程，从菜单栏中，点击 统计 (Statistics) -> 流量图 (Flow Graph)，然后，在弹出的界面中的「流量类型」选择 「TCP Flows」，可以更清晰的看到，整个过程中 TCP 流的执行过程：

image-20220727115037264

image-20220727115153230

真实情况与课本基本一致

image-20220727114214244

第一次握手丢失实验

为了模拟 TCP 第一次握手 SYN 丢包的情况，可以在拔掉服务器的网线后，立刻在客户端执行 curl 命令

客户端会重传第一次握手，每次超时时间 RTO 是指数（翻倍）上涨的，当超过最大重传次数后，客户端不再发送 SYN 包

重传次数由tcp_syn_retries内核参数确定

1
cat /proc/sys/net/ipv4/tcp_syn_retries

image-20220727115757640

image-20220727114502539

第二次握手丢失

为了模拟客户端收不到服务端第二次握手 SYN、ACK 包，可在客户端加上防火墙限制，直接粗暴的把来自服务端的数据都丢弃，防火墙的配置如下，然后在客户端执行curl

1
iptables -I INPUT -s 服务器IP -j DROP

可以发现，当第二次握手的 SYN、ACK 丢包时，客户端会超时重发 SYN 包，服务端也会超时重传 SYN、ACK 包

重传次数由tcp_synack_retries 内核参数限制的

1
cat /proc/sys/net/ipv4/tcp_synack_retries

image-20220727115827497

注意：添加 iptables 限制后， tcpdump 是否能抓到包 ，取决于 iptables 的限制条件：

  • 如果添加的是 INPUT 规则，则可以抓得到包
  • 如果添加的是 OUTPUT 规则，则抓不到包

网络包进入主机后的顺序如下：

  • 进来的顺序 Wire -> NIC -> tcpdump -> netfilter/iptables
  • 出去的顺序 iptables -> tcpdump -> NIC -> Wire
第三次握手丢失

为了模拟 TCP 第三次握手 ACK 包丢，需要在服务端配置防火墙，屏蔽客户端 TCP 报文中标志位是 ACK 的包，也就是当服务端收到客户端的 TCP ACK 的报文时就会丢弃，iptables 配置命令如下

1
iptables -I INPUT -s 客户端IP -p tcp --tcp-flag ACK ACK -J DROP

image-20220727120530774

可以发现，服务端会不断重传第二次握手。

而客户端此时已经建立了连接，会不断尝试发送消息(重试15次 由以下参数决定)

TCP 建立连接后的数据包传输，最大超时重传次数是由 tcp_retries2 指定

1
cat /proc/sys/net/ipv4/tcp_retries2

image-20220727120416710

那如果客户端不发送数据，什么时候才会断开处于 ESTABLISHED 状态的连接

这里就需要提到 TCP 的 保活机制。这个机制的原理是这样的：

定义一个时间段，在这个时间段内，如果没有任何连接相关的活动，TCP 保活机制会开始作用，每隔一个时间间隔，发送一个「探测报文」，该探测报文包含的数据非常少，如果连续几个探测报文都没有得到响应，则认为当前的 TCP 连接已经死亡，系统内核将错误信息通知给上层应用程序。

在 Linux 内核可以有对应的参数可以设置保活时间、保活探测的次数、保活探测的时间间隔，以下都为默认值：

1
2
3
net.ipv4.tcp_keepalive_time=7200
net.ipv4.tcp_keepalive_intvl=75  
net.ipv4.tcp_keepalive_probes=9
  • tcp_keepalive_time=7200：表示保活时间是 7200 秒（2小时），也就 2 小时内如果没有任何连接相关的活动，则会启动保活机制
  • tcp_keepalive_intvl=75：表示每次检测间隔 75 秒；
  • tcp_keepalive_probes=9：表示检测 9 次无响应，认为对方是不可达的，从而中断本次的连接。

也就是说在 Linux 系统中，最少需要经过 2 小时 11 分 15 秒才可以发现一个「死亡」连接。于是客户端连接就会断开连接。

TCP快速建立连接

客户端在向服务端发起 HTTP GET 请求时，一个完整的交互过程，需要 2.5 个 RTT 的时延。

由于第三次握手是可以携带数据的，这时如果在第三次握手发起 HTTP GET 请求，需要 2 个 RTT 的时延。

image-20220727134502789

在 Linux 3.7 内核版本中，提供了 TCP Fast Open 功能，这个功能可以减少 TCP 连接建立的时延。

  • 在第一次建立连接的时候，服务端在第二次握手产生一个 Cookie （已加密）并通过 SYN、ACK 包一起发给客户端，于是客户端就会缓存这个 Cookie，所以第一次发起 HTTP Get 请求的时候，还是需要 2 个 RTT 的时延；
  • 在下次请求的时候，客户端在 SYN 包带上 Cookie 发给服务端，就提前可以跳过三次握手的过程，因为 Cookie 中维护了一些信息，服务端可以从 Cookie 获取 TCP 相关的信息，这时发起的 HTTP GET 请求就只需要 1 个 RTT 的时延

image-20220727134527114

可以通过设置 net.ipv4.tcp_fastopn 内核参数，来打开 Fast Open 功能。

net.ipv4.tcp_fastopn 各个值的意义:

  • 0 关闭
  • 1 作为客户端使用 Fast Open 功能
  • 2 作为服务端使用 Fast Open 功能
  • 3 无论作为客户端还是服务器，都可以使用 Fast Open 功能

image-20220727134853105

TCP重复确认和快速重传

image-20220727140059542

  • 数据包 1 期望的下一个数据包 Seq 是 1，但是数据包 2 发送的 Seq 却是 10945，说明收到的是乱序数据包，于是回了数据包 3 ，还是同样的 Seq = 1，Ack = 1，这表明是重复的 ACK；
  • 数据包 4 和 6 依然是乱序的数据包，于是依然回了重复的 ACK；
  • 当对方收到三次重复的 ACK 后，于是就快速重传了 Seq = 1 、Len = 1368 的数据包 8；
  • 当收到重传的数据包后，发现 Seq = 1 是期望的数据包，于是就发送了个确认收到快速重传的 ACK

以上案例在 TCP 三次握手时协商开启了选择性确认 SACK，因此一旦数据包丢失并收到重复 ACK ，即使在丢失数据包之后还成功接收了其他数据包，也只需要重传丢失的数据包。如果不启用 SACK，就必须重传丢失包之后的每个数据包

TCP流量控制

现实中服务器会出现繁忙的情况，当应用程序读取速度慢，那么缓存空间会慢慢被占满，于是为了保证发送方发送的数据不会超过缓冲区大小，服务器则会调整窗口大小的值，接着通过 ACK 报文通知给对方，告知现在的接收窗口大小，从而控制发送方发送的数据大小

假设接收方处理数据的速度跟不上接收数据的速度，缓存就会被占满，从而导致接收窗口为 0，当发送方接收到零窗口通知时，就会停止发送数据

image-20220727140410128

接着，发送方会定时发送窗口大小探测报文，以便及时知道接收方窗口大小的变化。

image-20220727140519955

  • 发送方发送了数据包 1 给接收方，接收方收到后，由于缓冲区被占满，回了个零窗口通知；
  • 发送方收到零窗口通知后，就不再发送数据了，直到过了 3.4 秒后，发送了一个 TCP Keep-Alive 报文，也就是窗口大小探测报文；
  • 当接收方收到窗口探测报文后，就立马回一个窗口通知，但是窗口大小还是 0；
  • 发送方发现窗口还是 0，于是继续等待了 6.8（翻倍） 秒后，又发送了窗口探测报文，接收方依然还是回了窗口为 0 的通知；
  • 发送方发现窗口还是 0，于是继续等待了 13.5（翻倍） 秒后，又发送了窗口探测报文，接收方依然还是回了窗口为 0 的通知；

可以发现，这些窗口探测报文以 3.4s、6.5s、13.5s 的间隔出现，说明超时时间会翻倍递增。

在 Wireshark 看到的 Windows size 也就是 " win = "，这个值表示发送窗口吗？

这不是发送窗口，而是在向对方声明自己的接收窗口。

抓包文件里的「Window size value」实际上并不是真实的窗口大小，真实窗口大小的计算公式如下：

WindowSizeValue∗WindowSizeScalingFactor=CaculatedWindowSizeWindowSizeValue * WindowSizeScalingFactor = CaculatedWindow Size

如何在包里看出发送窗口的大小？

很遗憾，没有简单的办法，发送窗口虽然是由接收窗口决定，但是它又可以被网络因素影响，也就是拥塞窗口，实际上发送窗口是值是 min(拥塞窗口，接收窗口)min(拥塞窗口，接收窗口)

发送窗口和 MSS 有什么关系？

发送窗口决定了一口气能发多少字节，而 MSS 决定了这些字节要分多少包才能发完。

举个例子，如果发送窗口为 16000 字节的情况下，如果 MSS 是 1000 字节，那就需要发送 1600/1000 = 16 个包。

发送方在一个窗口发出 n 个包，是不是需要 n 个 ACK 确认报文？

不一定，因为 TCP 有累计确认机制，所以当收到多个数据包时，只需要应答最后一个数据包的 ACK 报文就可以了

TCP半连接队列和全连接队列

在 TCP 三次握手的时候，Linux 内核会维护两个队列，分别是：

  • 半连接队列，也称 SYN 队列；
  • 全连接队列，也称 accept 队列；

服务端收到客户端发起的 SYN 请求后，内核会把该连接存储到半连接队列，并向客户端响应 SYN+ACK，接着客户端会返回 ACK，服务端收到第三次握手的 ACK 后，内核会把连接从半连接队列移除，然后创建新的完全的连接，并将其添加到 accept 队列，等待进程调用 accept 函数时把连接取出来。

image-20220727161117606

Linux下查看全连接队列
  • 服务器在listen状态时
1
2
# -l 显示正在监听的socket -n 不解析服务名称 -t 只显示tcp socket
ss -lnt

image-20220727165618746

​ Recv-Q：当前全连接队列的大小，也就是当前已完成三次握手并等待服务端 accept() 的 TCP 连接；

​ Send-Q：当前全连接最大队列长度，上面的输出结果说明监听 80 端口的 TCP 服务，最大全连接长度为 4096；

  • 服务器在非listen状态时

    1
    2
    # -n 不解析服务名称 -t 只显示tcp socket
    ss -nt

    image-20220727165748732

    Recv-Q：已收到但未被应用进程读取的字节数；

    Send-Q：已发送但未收到确认的字节数；

模拟全连接队列满

使用压测工具wrk，它是一款简单的 HTTP 压测工具，它能够在单机多核 CPU 的条件下，使用系统自带的高性能 I/O 机制，通过多线程和事件模式，对目标机器产生大量的负载。

1
sudo apt install wrk

image-20220727164840862

1
2
# 表示开6个线程 3w个连接 持续压测60秒
wrk -t 6 -c 300000 -d 60s 地址:端口

当超过了 TCP 最大全连接队列，服务端则会丢掉后续进来的 TCP 连接

但实际上，丢弃连接只是 Linux 的默认行为，我们还可以选择向客户端发送 RST 复位报文，告诉客户端连接已经建立失败。

tcp_abort_on_overflow 共有两个值分别是 0 和 1，其分别表示：

  • 0 ：如果全连接队列满了，那么 server 扔掉 client 发过来的 ack ；
  • 1 ：如果全连接队列满了，server 发送一个 reset 包给 client，表示废掉这个握手过程和这个连接；

当 TCP 全连接队列满导致服务器丢掉了 ACK，与此同时，客户端的连接状态却是 ESTABLISHED，进程就在建立好的连接上发送请求。只要服务器没有为请求回复 ACK，请求就会被多次重发。如果服务器上的进程只是短暂的繁忙造成 accept 队列满，那么当 TCP 全连接队列有空位时，再次接收到的请求报文由于含有 ACK，仍然会触发服务器端成功建立连接。

所以，tcp_abort_on_overflow 设为 0 可以提高连接建立的成功率，只有你非常肯定 TCP 全连接队列会长期溢出时，才能设置为 1 以尽快通知客户端

当服务端并发处理大量请求时，如果 TCP 全连接队列过小，就容易溢出。发生 TCP 全连接队溢出的时候，后续的请求就会被丢弃，这样就会出现服务端请求数量上不去的现象。

image-20220727170459418

HTTP

基本概念

HTTP 是超文本传输协议，也就是HyperText Transfer Protocol，工作在应用层

image-20220727182224875

可分为如下三个部分理解

  • 协议：HTTP 是一个用在计算机世界里的协议。它使用计算机能够理解的语言确立了一种计算机之间交流通信的规范（两个以上的参与者），以及相关的各种控制和错误处理方式（行为约定和规范）。
  • 传输：HTTP 是一个在计算机世界里专门用来在两点之间传输数据的约定和规范
  • 「超文本」，它就是超越了普通文本的文本，它是文字、图片、视频等的混合体，最关键有超链接，能从一个超文本跳转到另外一个超文本

严格定义：HTTP 是一个在计算机世界里专门在「两点」之间「传输」文字、图片、音频、视频等「超文本」数据的「约定和规范」。

HTTP常见状态码

image-20220727182743063

HTTP常见字段

  • HOST: 客户端发送请求时，用来指定服务器的域名

    image-20220727183245157

  • Content-Length:服务器在返回数据时，会有 Content-Length 字段，表明本次回应的数据长度

    image-20220727183301128

  • Connection: 字段最常用于客户端要求服务器使用 TCP 持久连接，用于复用

    HTTP/1.1 版本的默认连接都是持久连接，但为了兼容老版本的 HTTP，需要指定 Connection 首部字段的值为 Keep-Alive，一个可以复用的 TCP 连接就建立了，直到客户端或服务器主动关闭连接。但是，这不是标准字段

    image-20220727183319694

  • Content-Encoding ：数据的压缩方法。表示服务器返回的数据使用了什么压缩格式

    image-20220727183625747

GET和POST

RFC规范

  • GET: 是从服务器获取指定的资源，这个资源可以是静态的文本、页面、图片视频等。GET 请求的参数位置一般是写在 URL 中，URL 规定只能支持 ASCII，所以 GET 请求的参数只允许 ASCII 字符 ，而且浏览器会对 URL 的长度有限制（HTTP协议本身对 URL长度并没有做任何规定）
  • POST: 根据请求负荷（报文body）对指定的资源做出处理，具体的处理方式视资源类型而不同。POST 请求携带数据的位置一般是写在报文 body 中， body 中的数据可以是任意格式的数据，只要客户端与服务端协商好即可，而且浏览器不会对 body 大小做限制

安全和幂等

  • 在 HTTP 协议里，所谓的「安全」是指请求方法不会「破坏」服务器上的资源。
  • 所谓的「幂等」，意思是多次执行相同的操作，结果都是「相同」的

因此结合RFC语义可知

  • GET 方法就是安全且幂等的，因为它是「只读」操作，无论操作多少次，服务器上的数据都是安全的，且每次的结果都是相同的。所以，可以对 GET 请求的数据做缓存，这个缓存可以做到浏览器本身上（彻底避免浏览器发请求），也可以做到代理上（如nginx），而且在浏览器中 GET 请求可以保存为书签
  • POST 因为是「新增或提交数据」的操作，会修改服务器上的资源，所以是不安全的，且多次提交数据就会创建多个资源，所以不是幂等的。所以，浏览器一般不会缓存 POST 请求，也不能把 POST 请求保存为书签

但是实际过程中，开发者不一定会按照 RFC 规范定义的语义来实现 GET 和 POST 方法。比如：

  • 可以用 GET 方法实现新增或删除数据的请求，这样实现的 GET 方法自然就不是安全和幂等。
  • 可以用 POST 方法实现查询数据的请求，这样实现的 POST 方法自然就是安全和幂等。

至于安全，无论是GET还是POST，只要采用HTTP传输都是不安全的，因为HTTP都是明文传输，所以，要避免传输过程中数据被窃取，就要使用 HTTPS 协议，这样所有 HTTP 的数据都会被加密传输

HTTP缓存技术

对于重复性的 HTTP 请求，比如每次请求得到的数据都一样的，我们可以把这对「请求-响应」的数据都缓存在本地，那么下次就直接读取本地的数据，不必在通过网络获取服务器的响应了，可大大提升性能，缓存技术主要分为如下两种：

  • 强制缓存：指的若浏览器判断出缓存没有过期，则直接使用浏览器的本地缓存，决定是否使用缓存的主动性在于浏览器这边

    image-20220727184748827

    from disk cache 表示使用了强制缓存

    实现方式： 使用Cache-Control 字段

    • 当浏览器第一次请求访问服务器资源时，服务器会在返回这个资源的同时，在 Response 头部加上 Cache-Control，Cache-Control 中设置了过期时间大小；
    • 浏览器再次请求访问服务器中的该资源时，会先通过请求资源的时间与 Cache-Control 中设置的过期时间大小，来计算出该资源是否过期，如果没有，则使用该缓存，否则重新请求服务器；
    • 服务器再次收到请求后，会再次更新 Response 头部的 Cache-Control。

  • **协商缓存：**就是与服务端协商之后，通过协商结果来判断是否使用本地缓存

    实现方式：使用ETag和If-None-Match字段，协商缓存这两个字段都需要配合强制缓存中 Cache-control 字段来使用，只有在未能命中强制缓存的时候，才能发起带有协商缓存字段的请求

    image-20220727185736597

    • 当浏览器第一次请求访问服务器资源时，服务器会在返回这个资源的同时，在 Response 头部加上 ETag 唯一标识，这个唯一标识的值是根据当前请求的资源生成的；

    • 当浏览器再次请求访问服务器中的该资源时，首先会先检查强制缓存是否过期，如果没有过期，则直接使用本地缓存；如果缓存过期了，会在 Request 头部加上 If-None-Match 字段，该字段的值就是 ETag 唯一标识；

    • 服务器再次收到请求后，

      会根据请求中的 If-None-Match 值与当前请求的资源生成的唯一标识进行比较

      • 如果值相等，则返回 304 Not Modified，不会返回资源；
      • 如果不相等，则返回 200 状态码和返回资源，并在 Response 头部加上新的 ETag 唯一标识；

    • 如果浏览器收到 304 的请求响应状态码，则会从本地缓存中加载资源，否则更新资源。

HTTP 1.1

优点：

  • 简单。报文格式就是header+body,header里的信息格式也是key-value简单形式

  • 灵活易扩展。HTTP协议里的各类请求方法、URI/URL、状态码、头字段等每个组成要求都没有被固定死，都允许开发人员自定义和扩充。

    同时 HTTP 由于是工作在应用层（ OSI 第七层），则它下层可以随意变化。

    HTTPS 也就是在 HTTP 与 TCP 层之间增加了 SSL/TLS 安全传输层，HTTP/3 甚至把 TCP 层换成了基于 UDP 的 QUIC

  • 应用广泛和跨平台

缺点：

  • 无状态

    • 好处：服务器负担小，无需额外资源记录状态信息
    • 坏处：服务器无记忆功能，在完成有关联性的操作时会非常麻烦，例如登录->添加购物车->下单->结算->支付，这系列操作都要知道用户的身份才行。但服务器不知道这些请求是有关联的，每次都要问一遍身份信息

    可使用Cookie技术解决无状态问题，通过在请求和响应报文中写入 Cookie 信息来控制状态

    image-20220727191244526

  • 明文传输

  • 不安全

    • 通信使用明文（不加密），内容可能会被窃听。比如，账号信息容易泄漏，那你号没了。
    • 不验证通信方的身份，因此有可能遭遇伪装。比如，访问假的淘宝、拼多多，那你钱没了。
    • 无法证明报文的完整性，所以有可能已遭篡改。比如，网页上植入垃圾广告，视觉污染，眼没了。

    HTTP 的安全问题，可以用 HTTPS 的方式解决，也就是通过引入 SSL/TLS 层，使得在安全上达到了极致。

性能

HTTP 协议是基于 TCP/IP，并且使用了「请求 - 应答」的通信模式，所以性能的关键就在这两点里。

  • 长连接。早期 HTTP/1.0 性能上的一个很大的问题，那就是每发起一个请求，都要新建一次 TCP 连接（三次握手），而且是串行请求，做了无谓的 TCP 连接建立和断开，增加了通信开销。为了解决上述 TCP 连接问题，HTTP/1.1 提出了长连接的通信方式，也叫持久连接。这种方式的好处在于减少了 TCP 连接的重复建立和断开所造成的额外开销，减轻了服务器端的负载。持久连接的特点是，只要任意一端没有明确提出断开连接，则保持 TCP 连接状态

    image-20220727191906457

    当然，如果某个 HTTP 长连接超过一定时间没有任何数据交互，服务端就会主动断开这个连接

  • 队头阻塞

    请求 - 应答」的模式加剧了 HTTP 的性能问题。

    因为当顺序发送的请求序列中的一个请求因为某种原因被阻塞时，在后面排队的所有请求也一同被阻塞了，会招致客户端一直请求不到数据，这也就是「队头阻塞」，好比上班的路上塞车

    image-20220727191844745

总结：HTTP/1.1 的性能一般，后续的 HTTP/2 和 HTTP/3 就是在优化 HTTP 的性能

HTTPS

基本概念

  1. HTTP 是超文本传输协议，信息是明文传输，存在安全风险的问题。HTTPS 则解决 HTTP 不安全的缺陷，在 TCP 和 HTTP 网络层之间加入了 SSL/TLS 安全协议，使得报文能够加密传输。

    image-20220727192147383

  2. HTTP 连接建立相对简单， TCP 三次握手之后便可进行 HTTP 的报文传输。而 HTTPS 在 TCP 三次握手之后，还需进行 SSL/TLS 的握手过程，才可进入加密报文传输。

  3. HTTP 的端口号是 80，HTTPS 的端口号是 443。

  4. HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的

HTTP 由于是明文传输，所以安全上存在以下三个风险：

  • 窃听风险，比如通信链路上可以获取通信内容，用户号容易没。
  • 篡改风险，比如强制植入垃圾广告，视觉污染，用户眼容易瞎。
  • 冒充风险，比如冒充淘宝网站，用户钱容易没。

HTTPS 在 HTTP 与 TCP 层之间加入了 SSL/TLS 协议，可以很好的解决了上述的风险：

  • 信息加密：交互信息无法被窃取，但你的号会因为「自身忘记」账号而没。
  • 校验机制：无法篡改通信内容，篡改了就不能正常显示，但百度「竞价排名」依然可以搜索垃圾广告。
  • 身份证书：证明淘宝是真的淘宝网，但你的钱还是会因为「剁手」而没。

可见，只要自身不做「恶」，SSL/TLS 协议是能保证通信是安全的。

HTTPS 如何解决安全问题

  • 混合加密: 现信息的机密性，解决了窃听的风险。

    image-20220727192538273

    使用公私钥(非对称加密 速度慢)获得会话秘钥(对称加密 速度快)，然后双方使用会话秘钥去进行通信。

  • 摘要算法+数字签名：保证无法篡改和确定来源

    为了保证传输的内容不被篡改，我们需要对内容计算出一个「指纹」，然后同内容一起传输给对方

    image-20220727202421919

    通过摘要算法可以确保内容不会被篡改，但是并不能保证「内容 + 哈希值」不会被中间人替换，因为这里缺少对客户端收到的消息是否来源于服务端的证明

    因此还需加上数字签名(用私钥加密 相等于持钥人(服务器)签了个名，如果能用公钥解开，则表示该信息一定是持钥人发出来的)才可以保证不被整体篡改(保证来源正确)

    image-20220727202704733

    私钥存在服务器端，公钥客户端持有，如果公钥能正常解密出私钥加密的内容，就能证明这个消息是来源于持有私钥身份的人发送的

  • 数字证书：解决身份冒充

    如果公钥也是被伪造的呢，中间人用自己的公私钥对去替换客户端的公钥，并用自己的私钥对信息加密，那不就完了。

    解决方案：把 公钥 注册到权威系统中，从而无法篡改

    image-20220727203622265

HTTPS 连接建立过程

SSL/TLS 协议基本流程：

  • 客户端向服务器索要并验证服务器的公钥。
  • 双方协商生产「会话秘钥」。
  • 双方采用「会话秘钥」进行加密通信。

前两步也就是 SSL/TLS 的建立过程，也就是 TLS 握手阶段。

下图简要概述来 TLS 的握手过程，其中每一个「框」都是一个记录（record），记录是 TLS 收发数据的基本单位，类似于 TCP 里的 segment。多个记录可以组合成一个 TCP 包发送，所以通常经过「四个消息」就可以完成 TLS 握手，也就是需要 2个 RTT 的时延，然后就可以在安全的通信环境里发送 HTTP 报文，实现 HTTPS 协议。

注：TLS1.3+优化了过程 只需要一个RTT往返时延

image-20220727211829011

所以可以发现，HTTPS 是应用层协议，需要先完成 TCP 连接建立，然后走 TLS 握手过程后，才能建立通信安全的连接。

image-20220727204648377

image-20220727204432215

1. ClientHello

首先，由客户端向服务器发起加密通信请求，也就是 ClientHello 请求。

在这一步，客户端主要向服务器发送以下信息：

（1）客户端支持的 SSL/TLS 协议版本，如 TLS 1.2 版本。

（2）客户端生产的随机数（Client Random），后面用于生成「会话秘钥」条件之一。

（3）客户端支持的密码套件列表，如 RSA 加密算法。

2. SeverHello

服务器收到客户端请求后，向客户端发出响应，也就是 SeverHello。服务器回应的内容有如下内容：

（1）确认 SSL/ TLS 协议版本，如果浏览器不支持，则关闭加密通信。

（2）服务器生产的随机数（Server Random），也是后面用于生产「会话秘钥」条件之一。

（3）确认的密码套件列表，如 RSA 加密算法。

（4）服务器的数字证书。

3.客户端回应

客户端收到服务器的回应之后，首先通过浏览器或者操作系统中的 CA 公钥，确认服务器的数字证书的真实性。

如果证书没有问题，客户端会从数字证书中取出服务器的公钥，然后使用它加密报文，向服务器发送如下信息：

（1）一个随机数（pre-master key）。该随机数会被服务器公钥加密。

（2）加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。

（3）客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供服务端校验。

上面第一项的随机数是整个握手阶段的第三个随机数，会发给服务端，所以这个随机数客户端和服务端都是一样的。

服务器和客户端有了这三个随机数（Client Random、Server Random、pre-master key），接着就用双方协商的加密算法，各自生成本次通信的「会话秘钥」。

4. 服务器的最后回应

服务器收到客户端的第三个随机数（pre-master key）之后，通过协商的加密算法，计算出本次通信的「会话秘钥」。

然后，向客户端发送最后的信息：

（1）加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。

（2）服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供客户端校验。

至此，整个 SSL/TLS 的握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的 HTTP 协议，只不过用「会话秘钥」加密内容。

数字证书签发过程

CA 签发证书的过程，如下图左边部分：

  • 首先 CA 会把持有者的公钥、用途、颁发者、有效时间等信息打成一个包，然后对这些信息进行 Hash 计算，得到一个 Hash 值；
  • 然后 CA 会使用自己的私钥将该 Hash 值加密，生成 Certificate Signature，也就是 CA 对证书做了签名；
  • 最后将 Certificate Signature 添加在文件证书上，形成数字证书；

客户端校验服务端的数字证书的过程，如下图右边部分：

  • 首先客户端会使用同样的 Hash 算法获取该证书的 Hash 值 H1；
  • 通常浏览器和操作系统中集成了 CA 的公钥信息，浏览器收到证书后可以使用 CA 的公钥解密 Certificate Signature 内容，得到一个 Hash 值 H2 ；
  • 最后比较 H1 和 H2，如果值相同，则为可信赖的证书，否则则认为证书不可信。

image-20220727205120732

HTTP2.0

先来看一下HTTP1.1的性能瓶颈：

  • 请求 / 响应头部（Header）未经压缩就发送，首部信息越多延迟越大。只能压缩 Body 的部分；
  • 发送冗长的首部。每次互相发送相同的首部造成的浪费较多；
  • 服务器是按请求的顺序响应的，如果服务器响应慢，会招致客户端一直请求不到数据，也就是队头阻塞；
  • 没有请求优先级控制；
  • 请求只能从客户端开始，服务器只能被动响应

HTTP2.0特性

image-20220727205951212

1. 头部压缩

HTTP/2 会压缩头（Header）如果你同时发出多个请求，他们的头是一样的或是相似的，那么，协议会帮你消除重复的部分。

这就是所谓的 HPACK 算法：在客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样字段了，只发送索引号，这样就提高速度了。

2. 二进制格式

HTTP/2 不再像 HTTP/1.1 里的纯文本形式的报文，而是全面采用了二进制格式，头信息和数据体都是二进制，并且统称为帧（frame）：头信息帧（Headers Frame）和数据帧（Data Frame）。

image-20220727210050071

这样虽然对人不友好，但是对计算机非常友好，因为计算机只懂二进制，那么收到报文后，无需再将明文的报文转成二进制，而是直接解析二进制报文，这增加了数据传输的效率

3. 数据流

HTTP/2 的数据包不是按顺序发送的，同一个连接里面连续的数据包，可能属于不同的回应。因此，必须要对数据包做标记，指出它属于哪个回应。

在 HTTP/2 中每个请求或响应的所有数据包，称为一个数据流（Stream）。每个数据流都标记着一个独一无二的编号（Stream ID），不同 Stream 的帧是可以乱序发送的（因此可以并发不同的 Stream ），因为每个帧的头部会携带 Stream ID 信息，所以接收端可以通过 Stream ID 有序组装成 HTTP 消息

客户端和服务器双方都可以建立 Stream， Stream ID 也是有区别的，客户端建立的 Stream 必须是奇数号，而服务器建立的 Stream 必须是偶数号。

image-20220727210222905

客户端还可以指定数据流的优先级。优先级高的请求，服务器就先响应该请求。

4. 多路复用

HTTP/2 是可以在一个连接中并发多个请求或回应，而不用按照顺序一一对应。

移除了 HTTP/1.1 中的串行请求，不需要排队等待，也就不会再出现「队头阻塞」问题，降低了延迟，大幅度提高了连接的利用率

image-20220727210309804

5. 服务器推送

HTTP/2 还在一定程度上改善了传统的「请求 - 应答」工作模式，服务端不再是被动地响应，可以主动向客户端发送消息。

比如，客户端通过 HTTP/1.1 请求从服务器那获取到了 HTML 文件，而 HTML 可能还需要依赖 CSS 来渲染页面，这时客户端还要再发起获取 CSS 文件的请求，需要两次消息往返，如下图左边部分：

image-20220727210352406

如上图右边部分，在 HTTP/2 中，客户端在访问 HTML 时，服务器可以直接主动推送 CSS 文件，减少了消息传递的次数。

HTTP2.0缺陷

HTTP/2 通过 Stream 的并发能力，解决了 HTTP/1 队头阻塞的问题，看似很完美了，但是 HTTP/2 还是存在“队头阻塞”的问题，只不过问题不是在 HTTP 这一层面，而是在 TCP 这一层。

HTTP/2 是基于 TCP 协议来传输数据的，TCP 是字节流协议，TCP 层必须保证收到的字节数据是完整且连续的，这样内核才会将缓冲区里的数据返回给 HTTP 应用，那么当「前 1 个字节数据」没有到达时，后收到的字节数据只能存放在内核缓冲区里，只有等到这 1 个字节数据到达时，HTTP/2 应用层才能从内核中拿到数据，这就是 HTTP/2 队头阻塞问题。也就是 虽然通过多个请求复用一个 TCP 连接解决了 HTTP 的队头阻塞 ，但是一旦发生丢包，就会阻塞住所有的 HTTP 请求，这属于 TCP 层队头阻塞

HTTP3.0

HTTP/2 队头阻塞的问题是因为 TCP，所以 HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP！

image-20220727210703966

UDP 发送是不管顺序，也不管丢包的，所以不会出现像 HTTP/2 队头阻塞的问题。大家都知道 UDP 是不可靠传输的，但基于 UDP 的 QUIC 协议 可以实现类似 TCP 的可靠性传输。

QUIC

1、无队头阻塞

QUIC 协议也有类似 HTTP/2 Stream 与多路复用的概念，也是可以在同一条连接上并发传输多个 Stream，Stream 可以认为就是一条 HTTP 请求。

QUIC 有自己的一套机制可以保证传输的可靠性的。当某个流发生丢包时，只会阻塞这个流，其他流不会受到影响，因此不存在队头阻塞问题。这与 HTTP/2 不同，HTTP/2 只要某个流中的数据包丢失了，其他流也会因此受影响。

所以，QUIC 连接上的多个 Stream 之间并没有依赖，都是独立的，某个流发生丢包了，只会影响该流，其他流不受影响。

image-20220727210831415

2、更快的连接建立

对于 HTTP/1 和 HTTP/2 协议，TCP 和 TLS 是分层的，分别属于内核实现的传输层、openssl 库实现的表示层，因此它们难以合并在一起，需要分批次来握手，先 TCP 握手，再 TLS 握手。

HTTP/3 在传输数据前虽然需要 QUIC 协议握手，这个握手过程只需要 1 RTT，握手的目的是为确认双方的「连接 ID」，连接迁移就是基于连接 ID 实现的。

但是 HTTP/3 的 QUIC 协议并不是与 TLS 分层，而是QUIC 内部包含了 TLS，它在自己的帧会携带 TLS 里的“记录”，再加上 QUIC 使用的是 TLS/1.3，因此仅需 1 个 RTT 就可以「同时」完成建立连接与密钥协商，如下图：

image-20220727211433945

甚至，在第二次连接的时候，应用数据包可以和 QUIC 握手信息（连接信息 + TLS 信息）一起发送，达到 0-RTT 的效果。

3、连接迁移

基于 TCP 传输协议的 HTTP 协议，由于是通过四元组（源 IP、源端口、目的 IP、目的端口）确定一条 TCP 连接，那么当移动设备的网络从 4G 切换到 WIFI 时，意味着 IP 地址变化了，那么就必须要断开连接，然后重新建立连接。而建立连接的过程包含 TCP 三次握手和 TLS 四次握手的时延，以及 TCP 慢启动的减速过程，给用户的感觉就是网络突然卡顿了一下，因此连接的迁移成本是很高的。

而 QUIC 协议没有用四元组的方式来“绑定”连接，而是通过连接 ID来标记通信的两个端点，客户端和服务器可以各自选择一组 ID 来标记自己，因此即使移动设备的网络变化后，导致 IP 地址变化了，只要仍保有上下文信息（比如连接 ID、TLS 密钥等），就可以“无缝”地复用原连接，消除重连的成本，没有丝毫卡顿感，达到了连接迁移的功能。

所以， QUIC 是一个在 UDP 之上的伪 TCP + TLS + HTTP/2 的多路复用的协议。

image-20220727211630615

QUIC 是新协议，对于很多网络设备，根本不知道什么是 QUIC，只会当做 UDP，这样会出现新的问题，因为有的网络设备是会丢掉 UDP 包的，而 QUIC 是基于UDP 实现的，那么如果网络设备无法识别这个是 QUIC 包，那么就会当作 UDP包，然后被丢弃。

所以，HTTP/3 现在普及的进度非常的缓慢，不知道未来 UDP 是否能够逆袭 TCP。

字节青训营-打开抖音互联网发生了什么