OSI 七层网络模型

• 物理层

物理层负责数据的物理传输，计算机输入输出的只能是 0 1 这样的二进制数据，但是在真正的通信线路里有光纤、电缆、无线各种设备。光信号和电信号，以及无线电磁信号 在物理上是完全不同的，如何让这些不同的设备能够理解、处理相同的二进制数据，这就是物理层要解决的问题。

• 链路层

链路层就是将数据进行封装后交给物理层进行传输，主要就是将数据封装成数据帧，以 帧为单位通过物理层进行通信，有了帧，就可以在帧上进行数据校验，进行流量控制。 链路层会定义帧的大小，这个大小也被称为最大传输单元。像 HTTP 要在传输的数据上 添加一个 HTTP 头一样，数据链路层也会将封装好的帧添加一个帧头，帧头里记录的一 个重要信息就是发送者和接受者的 MAC 地址。MAC 地址是网卡的设备标识符，是唯一 的，数据帧通过这个信息确保数据送达到正确的目标机器。

• 网络层

网络层 IP 协议使得互联网应用根据 IP 地址就能访问到目标服务器，请求离开 App 后， 到达运营服务商的交换机，交换机会根据这个 IP 地址进行路由转发，可能中间会经过很 多个转发节点，最后数据到达目标服务器。 网络层的数据需要交给链路层进行处理，而链路层帧的大小定义了最大传输单元，网络 层的 IP 数据包必须要小于最大传输单元才能进行网络传输，这个数据包也有一个 IP 头， 主要包括的就是发送者和接受者的 IP 地址。

• 传输层

IP 协议不是一个可靠的通信协议，不会建立稳定的通信链路，并不会确保数据一定送达。要保证通 信的稳定可靠，需要传输层协议 TCP。 TCP 协议是一种面向连接的、可靠的、基于字节流的传输层协议。TCP 作为一个比较基础的通讯协 议，有很多重要的机制保证了 TCP 协议的可靠性和强壮性： 使用序号，对收到的 TCP 报文段进行排序和检测重复的数据 无错传输，使用校验和检测报文段的错误 使用确认和计时器来检测和纠正丢包或者延时 流量控制，避免主机分组发送得过快而使接收方来不及完全收下 拥塞控制，发送方根据网络承载情况控制分组的发送量，以获得高性能同时避免拥塞崩溃丢失包的重传。

TCP 建立连接的 3 次握手：

1. App 先发送 SYN=1，Seq=X 的报文，表示 请求建立连接，X 是一个随机数；

2. 服务器收到这个报文后，应答 SYN=1， ACK=X+1，Seq=Y 的报文，表示同意建立 连接；

3. App 收到这个报文后，检查 ACK 的值为自 己发送的 Seq 值 +1，确认建立连接，并发 送 ACK=Y+1 的报文给服务器；服务器收到 这个报文后检查 ACK 值为自己发送的 Seq 值 +1，确认建立连接。至此，App 和服务器 建立起 TCP 连接，就可以进行数据传输了。

TCP 关闭连接 4 次挥手：

1. 客户端向服务器端发送一个 FIN，请求关 闭数据传输。

2. 当服务器接收到客户端的 FIN 时，向客户 端发送一个 ACK，其中 ACK 的值等于 FIN + SEQ。

3. 然后服务器向客户端发送一个 FIN，告诉 客户端应用程序关闭。

4. 当客户端收到服务器端的 FIN 是，回复一 个 ACK 给服务器端。其中 ACK 的值等于 FIN + SEQ。

• 会话层

会话层就是负责建立、管理和终止表示层实体之间的通信会话。该层的通信由不同设备中的应用程序之间的服务请求和响应组成。

• 表示层

表示层提供各种用于应用层数据的编码和转换功能,确保一个系统的应用层发送的数据能被另一个系统的应用层识别。如果必要，该层可提供一种标准表示形式，用于将计算机内部的多种数据格式转换成通信中采用的标准表示形式。数据压缩和加密也是表示层可提供的转换功能之一。

• 应用层

最靠近用户的一层，是为计算机用户提供应用接口，也为用户直接提供各种网络服务。我们常见应用层的网络服务协议有：HTTP，HTTPS，FTP，POP3、SMTP 等。

HTTP 协议

HTTP 请求的 7 种方法

Get：只读请求，请求处理过程不应该产生副作用，即 web 应用不应该因为 get 请求而发生任何状 态改变。

Head：和 get 方法一样，但是只返回响应头。

Post：提交请求。

Put：上传请求。

Delete：删除 URL 标识的资源。

Trace：回显服务器收到的请求，用以测试或者诊断。

Options：请求服务器返回支持的所有 HTTP 请求方法，测试服务器是否正常。

HTTP 响应的 5 种状态

1xx 消息——请求已被服务器接收，继续处理

2xx 成功——请求已成功被服务器接收、理解、并接受

3xx 重定向——需要后续操作才能完成这一请求

4xx 请求错误——请求含有词法错误或者无法被执行

5xx 服务器错误——服务器在处理某个正确请求时发生错误

HTTP 协议版本

HTTP/1.0 中，客户端和服务器之 间交换的每个请求 / 响应都会创建 一个新的 TCP 连接，这意味着所 有请求之前都需要进行 TCP 握手 连接，因此所有请求都会产生延 迟。

HTTP/1.1 试图引入保持连接的概念来解决这些问题，它允许客户端复用 TCP 连接，从 而分摊了建立初始连接和针对多个请求缓慢启动的成本。但任意时点上每个连接只能执 行一次请求 / 响应交换。

HTTP/2 引入了 HTTP“流”的概念，允许将不同的 HTTP 并发地复用到同一 TCP 连接 上， 使浏览器更高效地复用 TCP 连接。HTTP/2 解决了单个 TCP 连接的使用效率低的 问题，现在可以通过同一连接同时传输多个请求 / 响应。但是，TCP 并不理解 HTTP 流， 当多个 HTTP 请求复用一个 TCP 连接，如果前面的请求/响应没有处理完，后面的请求/响 应也无法处理，也就是会出现队头堵塞现象。

HTTP/3 不是使用 TCP 作为会话的 传输层，而是使用 QUIC （一种新 的互联网传输协议）。该协议在传 输层将流作为一等公民引入。多个 QUIC 流共享相同的 QUIC 连接， 因此不需要额外的握手和慢启动来 创建新的 QUIC 流。但 QUIC 流是 独立的，因此在大多数情况下，只 影响一个流的丢包不会影响其他流， 这是因为 QUIC 数据包封装在 UDP 数据包。

epoll 实现 IO 多路复用

IO(输入输出)的对象可以是文件(file)， 网络(socket)，进程之间的管道(pipe)，在 linux 系统中，都用文件描述符(fd)来表示。

IO 多路复用是指一个 Selector 同时监听多个输入输出，epoll 是一种 I/O 事件通知机制，是 linux 内核实现 IO 多路复用的一个实现。是一种当文件描述符的内核缓冲区非空的时候，发出可读信号进行通知，当写缓冲区不满的时候，发出可写信号通知的机制。

操作系统通过中断监听输入输出，比如当网卡把数据写入到内存后，网卡向 CPU 发出一个中断信号，操作系统便能得知有新数据到来，再通过网卡中断程序去处理数据。

epoll 的工作机制：

epoll 的两种触发方式：水平触发和边缘触发

• 水平触发的时机

读操作：只要缓冲内容不为空，水平触发模式返回读就绪。

写操作：只要缓冲区还不满，水平触发模式会返回写就绪。

当被监控的文件描述符上有可读写事件发生时，epoll_wait()会通知处理程序去读写。如果这次没有把数据一次性全部读写完(如读写缓冲区太小)，那么下次调用 epoll_wait()时，它还会通知你在上没读写完的文件描述符上继续读写，当然如果你一直不去读写，它会一直通知你。如果系统中有大量你不需要读写的就绪文件描述符，而它们每次都会返回，这样会大大降低处理程序检索自己关心的就绪文件描述符的效率。

• 边缘触发的时机

读操作：

当缓冲区由不可读变为可读的时候。

当有新数据到达时，即缓冲区中的待读数据变多的时候。

当缓冲区有数据可读，且应用进程对相应的描述符进行 EPOLL_CTL_MOD 修改 EPOLLIN 事件时。

写操作：

当缓冲区由不可写变为可写时的时候。

当有旧数据被发送走，即缓冲区中的内容变少的时候。

当缓冲区有空间可写，且应用进程对相应的描述符进行 EPOLL_CTL_MOD 修改 EPOLLOUT 事件时。

当被监控的文件描述符上有可读写事件发生时，epoll_wait()会通知处理程序去读写。如果这次没有把数据全部读写完(如读写缓冲区太小)，那么下次调用 epoll_wait()时，它不会通知你，也就是它只会通知你一次，直到该文件描述符上出现第二次可读写事件才会通知你。这种模式比水平触发效率高，系统不会充斥大量你不关心的就绪文件描述符。