【Sofice小司笔记】5 计算机网络，包含数据传输原理、网络各层协议详细说明、TCP/IP协议栈各常用协议说明、TCP握手挥手、可靠传输、网络加密技术

❓ 在浏览器地址栏输入一个 URL 后回车，背后发生了什么

1. 解析 URL
2. 浏览器封装 HTTP 请求报文
3. DNS 域名解析获取 IP 地址
4. 建立 TCP 连接（长链接）
5. 浏览器发送请求
6. 负责传输的 IP 协议
7. 使用 ARP 协议凭借 MAC 地址通信
8. 服务器响应请求
9. 断开 TCP 连接
10. 浏览器渲染界面

数据传输方式和交换方式

传输方式

1. 按数据传输的流向和时间关系分类

   • 单工通信：只能指定方向。广播
   • 半双工通信：双向，但不能同时。对讲机
   • 全双工通信：双向同时。电话

2. 按数据传输的顺序分类

   • 串行：易于实现。缺点是要解决收、发双方码组或字符的同步，需外加同步措施。
   • 并行：传输信道多，设备复杂，成本较高，故较少采用。

3. 按数据传输的同步方式划分

   • 同步：发送方和接收方的时钟要同步，同步符号(起始字符)＋数据块＋同步符号(结束字符）
   • 异步：在发送每一个字符代码的前面均加上一个 “起” 信号（起始位），后面均加一个 “止” 信号（终止位）。字符可以连续发送，也可以单独发送；不发送字符时，连续发送止信号。

交换方式

数据交换（Data Switching）是指在多个数据终端设备之间，为任意两个终端设备建立数据通信临时互连通路的过程。通俗来说交换是就通过某些交换中心将数据进行集中和传送，传输线路为各个用户共用，从而大大节省通信线路，降低系统费用。如果网络规模较大，则把交换设备连接在一起形成交换网络。

• 电路交换

  用户之间要传输数据时，交换中心在用户之间建立一条暂时的数据电路。电路接通后，用户双方便可传输数据，并一直占用到传输完毕拆除电路为止。电路交换引入的时延很小，而且交换机对数据不加处理，是这几种交换方式中最快的一种。因而适合传输实时性强和批量大的数据。

• 报文交换

  报文（message）是网络中交换与传输的数据单元，即站点一次性要发送的数据块。报文包含了将要发送的完整数据信息，其长短很不一致，长度不限且可变。传送过程采用存储转发的方式，中间方必须收到完整的报文并检查有无错误后才能进行转发。

• 分组交换

  分组，就是将一个大的数据包（报文）分成一个个更小的数据包，这些一个个更小的数据报就称为分组。在每个分组的首部写入发送端和接收端的地址。分组交换同样采用存储转发，不同站点的数据分组可以交织在同一线路上传输，也就是说一个报文分成了若干个分组之后，这些分组不一定都沿着同一条路径进行转发，提高了线路的利用率。当然，由于将大的报文分割成了若干小分组，所以分组交换的速度比报文交换快得多

三种交换方式比较

	电路交换	报文交换	分组交换
建立连接	需要	不需要	不需要
数据交换单位	比特流	报文	分组
传输方式	比特流直达	存储转发	存储转发
每个分组沿着规定路径	是		不是
分组按序到达	是		不是
优点	通信时延小； 实时性强； 适用范围广； 控制简单； 避免冲突	无需建立连接； 动态分配陆续； 可靠性高； 线路利用率高； 可提供多目标服务	加速传输； 简化存储管理； 减少出错几率和重发数据
缺点	建立连接时间长； 信道利用率低； 缺乏统一标准； 灵活性差	由于存储转发导致时延； 对报文大小没有限制，需要较大的存储缓存空间	由于存储转发导致时延； 工作量大，可能出现分组丢失等情况

数据交换方式的选择

• 传送数据量大，且传送时间远大于呼叫时，选择电路交换。电路交换传输时延最小。
• 当端到端的通路有很多段的链路组成时，采用分组交换传送数据较为合适
• 从信道利用率上看，报文交换和分组交换优于电路交换，其中分组交换比报文交换的时延小，尤其适用于计算机之间的突发式的数据通信（比如我们用微信发消息）

OSI七层协议模型和TCP/IP四层协议模型

五层协议模型

所谓通信协议就是通信双方都必须要遵守的通信规则。如果没有网络通信协议，计算机的数据将无法发送到网络上，更无法到达对方计算机，即使能够到达，对方也未必能读懂。有了通信协议，网络通信才能够发生。

每一层都是在下一层的基础上，通过层间接口向上一层提供一定的服务，而把 “这种服务是如何实现的” 细节对上层加以屏蔽。

• 对等层之间通信（不同开放系统中的相同层次之间的通信，对等层实体之间的信息交换）：OSI 标准为每一层的通信都严格定义了 协议数据单元 PDU的格式。 对等层之间的通信是目的，对等层实体的协作保证该层功能和服务的实现
• 相邻层之间通信（相邻的上下层之间的通信，属于局部问题）：相邻层之间的通信是手段，保证对等层实体之间的通信得以实施

物理层

两台计算机之间要进行通信，必然需要传输介质/物理媒介来连接两台计算机，这样，我们才能把数据传输过去。传输介质分为：

• 导向型传输介质：
  • 双绞线：适用于近距离
  • 同轴电缆（抗干扰性强）：适用于远距离
  • 光纤：带宽远远大于其他传输媒体
• 非导向型传输介质：
  • 无线电波
  • 微波
  • 红外线、激光

物理层的作用：就是实现计算机之间的数据传送，这个数据其实是比特流，物理层需要尽可能屏蔽掉具体传输介质和物理设备的差异， 使其上面的数据链路层不必考虑网络的具体传输介质是什么，即实现比特流的透明传输。

数据链路层

物理层只是简单的把计算机连接起来并在上面传输比特流，它还是存在着很多问题的：

• 1）物理连接是有差错和不可靠的
• 2）物理设备之间可能存在传输速度不匹配问题

也就是说仅仅靠物理层是无法保证数据传输的正确性的。

数据链路层的主要作用：加强物理层传输原始比特流的功能，将物理层提供的可能出错的物理连接改造成为逻辑上无差错的数据链路，使之对网络层表现为一条无差错的链路。在物理层提供服务的基础上，数据链路层还肩负着为网络层提供服务的责任，其最基本的服务是将来自网络层的 IP 数据报封装成帧，可靠的传输到相邻结点的目标网络层。

封装成帧

为什么需要封装成帧：前需要制定一套规则来进行 0、1 的传送，让计算能够读懂这些序列。

封装成帧就是：发送端的数据链路层接收到上层网络层传过来的 IP 数据报后，在其前后部分添加首部（包含MAC地址）、尾部，这样就构成了一个帧。接收端在收到物理层上交的比特流后，就能根据首部和尾部的标记，从收到的比特流中识别帧的开始和结束。

MAC 地址

MAC 地址就是链路层地址，长度为 6 字节（48 位），**用于唯一标识网络适配器（网卡）。**计算机之间的数据传送，就是通过 MAC 地址来唯一寻找、传送的。

一台主机拥有多少个网络适配器就有多少个 MAC 地址。例如笔记本电脑普遍存在无线网络适配器和有线网络适配器，因此就有两个 MAC 地址。

❓ 如果没有 MAC 地址，仅仅只有 IP 地址可以吗？

从理论上来说，如果 IP 地址够用，交换机也支持根据 IP 地址进行转发，我们只需要在 IP 数据报中加一个 “下一跳 IP 地址” 的字段就行了，MAC 地址确实并不是必要的。但从宏观来说，IP 地址只管上层建筑即路线规划，底层具体走的逻辑交给 MAC 地址来做，这样其实才符合 TCP/IP 协议体系这种分层的理念！所以，这种设计并非多次一举，而是为了符合最根本的设计理念。

网络层

在 计算机网络中进行通信的两个计算机之间可能会经过很多个数据链路，也可能还要经过很多通信子网。

网络层的任务：就是选择合适的网间路由和交换结点， 确保数据及时传送。 在发送数据时，网络层把运输层产生的报文段或用户数据报封装成分组和包进行传送。

IP 协议

IP 协议用于屏蔽下层物理网络的差异，为上层提供统一的 IP 数据报。IP 数据报中含有发/收方的 IP 地址。

IP 协议提供无连接的、不可靠的、尽力的数据报投递服务

• 无连接

  发送端可于任何时候自由发送数据，而接收端永远不知道自己会在何时从哪里接收到数据。每个数据报独立处理和传输， 一台主机发出的数据报序列，可能取不同的路径， 甚至其中的一部分数据报会在传输过程中丢失；

• 不可靠

  IP 协议本身不保证数据报投递的结果。 在传输的过程中，数据报可能会丢失、重复、延迟和乱序等， IP协议不对内容作任何检测，也不将这些结果通知收发双方； 数据报的丢失，通过路由器发 ICMP报文 告知； 必要时，由高层实体（如TCP）负责差错恢复动作。

• 尽力

  执行数据报的分段和封装，以适应具体的传输网络， 由最终结点的IP模块进行合段处理

  不同物理网络对传输的帧 /分组的体积有不同的规定； 当数据报长度 > **MTU（Maximun Transfer Unit，最大传输单元）**时，需对数据报分段 。

IP地址

IPV4 地址长 32 比特 / 4 字节，而 IPV6 地址占 128 比特 / 16 字节

网络类别	第一个可用的网络号	最后一个可用的网络号	每个网络中的最大主机数
A	1	126	$2^{24}-2$
B	128.1	191.255	$2^{16}-2$
C	192.0.1	223.255.255	$2^8-2$

当主机号全为 0：该网络的地址

当主机号全为 1：该网络的广播地址

127.0.0.1：环回地址，数据包就不会流向网络

❓ 为什么要分离网络号和主机号？

因为两台计算机要通讯，首先要判断是否处于同一个广播域内，即网络地址（网络号）是否相同：

• 如果网络地址相同，表明接受方在本网络上（本地网络主机），那么可以把数据包直接发送到目标主机，无需转发给其他的网络
• 网络号不相同的主机称之为远程网络主机，远程网络中的主机要相互通信必须通过本地网关（Gateway）来传递转发数据

IP 单播/广播/多播

• IP 广播：用网络的广播地址，如192.168.0.255，一般进行本地广播，路由器上设置为不转发广播包。
• IP 单播：只有一个发送方和一个接收方。单播是可以穿透路由器的。
• IP 多播（组播）：将包发送给特定组内的所有主机（可以穿透路由器），即一个发送方，特定的多个接收方

子网划分

将传统的两级 IP 地址（网络号 + 主机号）转换成粒度更小的三级 IP 地址（网络号 + 子网号 + 主机号），也就是将主机地址划分为子网号和子网内的主机号。划分子网后，对外仍表现为一个网络。

子网掩码

将某个 IP 地址划分成网络地址和主机地址两部分

以网络地址 192.168.1.0（C 类二级 IP 地址），子网掩码 255.255.255.192 为例，我们可以写成：192.168.1.0/26，表示网络号 + 子网号共 26 位。

子网掩码 255.255.255.192 中共有 26 个 1，即代表网络号 + 子网号共 26 位，而 C 类地址的网络号（加上分类号）共 24 位，由此可知，需要从 8 位主机号中借用 2 位作为子网号。由于子网网络地址被划分成 2 位，那么子网地址就有 $2^2=4$ 个，分别是 00、01、10、11，具体划分如下图：

划分后的 4 个子网如下表格：

拯救枯竭的 IPV4 地址

• 无分类 IP 地址 CIDR

  放弃 IP 地址的分类，采用任意长度分割 IP 地址的网络号和主机号。CIDR 的表现形式为 a.b.c.d/x，其中 /x 表示前 x 位属于网络号（网络前缀），网络号的长度可以根据需要变化。

• NAT 地址转换

  用于在本地网络中使用私有地址，在连接互联网时使转而使用全局 IP 地址的技术。虽然说 NAT 实际上是为正在面临地址枯竭的 IPV4 而开发的技术，不过在 IPV6 中，为了提高网络安全也在使用 NAT。

• IPV6

路由控制

为了将数据包发送给目标主机，所有主机和路由器都维护着一张路由控制表（Routing Table），该表记录着如下两个字段：

• IP 地址
• 如果想要到达这个 IP 地址，在当前路由器，数据包的下一步应该是发送到哪个路由器

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

默认路由 Default Route 就是指路由表中任何一个地址都能与之匹配的记录。如果一张路由表中包含所有的网络和子网信息，将会造成无端的浪费。这时，默认路由就是一个不错的选择。默认路由一般标记为 0.0.0.0/0 或 default

路由协议

路由控制表的形成有两种方式：

• 一种是管理员手动设置，也叫静态路由控制
• 另一种是路由器与其他路由器相互交换信息时自动刷新，也叫动态路由控制

为了让动态路由即时刷新路由控制表，在网络上互联的路由器之间必须设置好某种协议，保证正常读取路由控制信息。这种协议就称为路由协议。

人们根据路由控制的范围将路由协议大致分为两类：

• 外部网关协议 EGP（包含 RIP、OSPF 等协议）
• 内部网关协议 IGP（包含 BGP 等协议）

没有 EGP 就不可能有世界上各个不同组织机构之间的通信，没有 IGP 就不可能有机构内部的通信。

ARP 地址解析协议

ARP（Address Resolution Protocol ）协议就可以实现由 IP 地址得到 MAC 地址。

每个主机都有一个 ARP 高速缓存，里面有本局域网上的各主机和路由器的 IP 地址到 MAC 地址的映射表。

如果主机 A 知道主机 B 的 IP 地址，但是 ARP 高速缓存中没有该 IP 地址到 MAC 地址的映射，此时主机 A 通过广播的方式发送 ARP 请求分组（该分组携带自己的 IP 地址 和 MAC 地址 以及 目标主机的 IP 地址），主机 B 收到该请求后会发送 ARP 响应分组 给主机 A 告知其 MAC 地址，随后主机 A 向其高速缓存中写入主机 B 的 IP 地址到 MAC 地址的映射。

ARP请求包为广播，ARP响应包为单播

对应的，RARP 协议可以实现由 MAC地址转化为 IP 地址

ICMP 网际控制报文协议

网际控制报文协议（Internet Control Message Protocol，ICMP）

作用：解决ip协议不可靠的特点，确认网络是否能够正常工作，并且即使诊断出现异常时的原因所在

ICMP 报文是由路由器发出来的。

ICMP 报文类型

• 查询报文

  用于主机进行诊断的查询消息，ping

  • 回送应答（Echo Reply），类型：0
  • 回送请求（Echo Request），类型：8

• 差错报文

  用于通知主机出错的原因，traceroute / tracert

  • 目标不可达（Destination Unreachable），类型：3。路由器无法将 IP 数据报发送给目标地址。分为网络不可达、主机不可达、协议不可达、端口不可达、需要进行分片但设置了不分片位。
  • 原点抑制（Source Quench），类型：4。
  • 重定向或改变路由（Redirect），类型：5。如果路由器发现发送端主机使用了某个不是最优的路径发送数据，他就会返回一个 ICMP 重定向消息（ICMP Redirect Message）给这个主机，并且，在这个消息中包含了最优的路由信息和源数据。
  • 超时（Time Exceeded），类型：11。TTL减到0就发送，为了在路由控制遇到问题发生循环状况时，避免 IP 包无休止地在网络上被转发。

传输层

在从计算机 A 传数据给计算表 B 的时候，还得指定一个端口（Port），以供特定的应用程序来接受处理。即 IP 地址 + 端口号就可以唯一确定某个主机上的某个应用进程

网络层的功能：建立主机到主机的通信，而传输层的功能就是建立端口到端口的通信（也可以说是进程到进程之间的通信）

传输层最常见的两大协议是 TCP 协议和 UDP 协议，其中 TCP 协议与 UDP 最大的不同就是 TCP 提供可靠的传输，而 UDP 提供的是不可靠传输。

TCP 传输控制协议

TCP（Transmission Control Protocol） 提供面向连接，面向字节流的服务。在传送数据之前必须先建立连接，数据传送结束后要释放连接。

TCP 不提供广播或多播服务。由于 TCP 要提供可靠的，面向连接的传输服务（TCP 的可靠体现在 TCP 在传递数据之前，会有三次握手来建立连接，而且在数据传递时，有确认、窗口、重传、流量控制、拥塞控制机制，在数据传完后，还会断开连接用来节约系统资源。这不仅使协议数据单元的首部增大很多，还要占用许多处理机资源。TCP 一般用于文件传输、发送和接收邮件、远程登录等场景。

TCP 报文首部

首部固定部分各字段意义如下：

• 1 - 源端口和目的端口：各占 2 个字节，分别写入源端口和目的端口。IP 地址 + 端口号就可以确定一个进程地址

• 2 - 序号/序列号（Sequense Number，SN）：在一个 TCP 连接中传送的字节流中的每一个字节都按顺序编号。该字段表示本报文段所发送的数据的第一个字节的序号。初始序号称为 Init Sequense Number, ISN（序号/序列号这个字段很重要，大家留个印象，下文会详细讲解）

  例如，一报文段的序号是 101，共有 100 字节的数据。这就表明：本报文段的数据的第一个字节的序号是 101，最后一个字节的序号是 200。显然，下一个报文段的数据序号应当从 201 开始，即下一个报文段的序号字段值应为 201。

• 3 - 确认号 ack：期望收到对方下一个报文段的第一个数据字节的序号。若确认号为 N，则表明：到序号 N-1 为止的所有数据都已正确收到。

• 4 - 数据偏移（首部长度）：它指出 TCP 报文段的数据起始处距离 TCP 报文段的起始处有多远。这个字段实际上是指出TCP报文段的首部长度。

• 5 - 保留：占 6 位，应置为 0，保留为今后使用。

⭐ 大家看上图，保留位的右边还有 6 个控制位（重要），这是TCP 用来说明该报文段性质的：

• 紧急位 URG：当 URG = 1 时，表明此报文段中有紧急数据，是高优先级的数据，应尽快发送，不用在缓存中排队。该控制位需配合紧急指针使用（紧急指针指出本报文段中紧急数据的字节数）

  举个例子：我们需要取消一个已经发送了很长程序的运行，因此用户从键盘发出中断命令。如果不使用紧急数据，那么这个指令将存储在接收 TCP 的缓存末尾，只有在所有的数据被处理完毕后这两个字符才被交付接收方的应用进程，这样做就无法实现立即中断。

• 确认 ACK：仅当 ACK = 1 时确认号字段才有效，当 ACK = 0 时确认号无效。TCP 规定，在连接建立后所有传送的报文段都必须把 ACK 置为 1。

• 推送 PSH：当两个应用进程进行交互式的通信时，有时在一端的应用进程希望在键入一个命令后立即就能收到对方的响应。在这种情况下，TCP 就可以使用推送（push）操作。这时，发送方 TCP 把 PSH 置为 1，并立即创建一个报文段发送出去。接收方 TCP 收到 PSH = 1 的报文段，就尽快地交付接收应用进程。而不用等到整个缓存都填满了后再向上交付。

• 复位 RST：当 RST = 1 时，表明 TCP 连接中出现了严重错误（如由于主机崩溃或其他原因），必须释放连接，然后再重新建立传输连接。

• 同步 SYN：SYN = 1 表示这是一个连接请求或连接接受报文。

  当 SYN = 1 而 ACK = 0 时，表明这是一个连接请求报文段。对方若同意建立连接，则应在响应的报文段中使 SYN = 1 且 ACK = 1。

• 终止 FIN：用来释放一个连接。当 FIN = 1时，表明此报文段的发送发的数据已发送完毕，并要求释放连接。

TCP 三次握手建立连接

进行三次握手的主要作用就是为了确认双方的接收能力和发送能力是否正常、指定自己的 初始化序列号(Init Sequense Number, ISN) 为后面的可靠性传输做准备。

刚开始客户端处于 Closed 的状态，而服务端处于 Listen 状态：

CLOSED：没有任何连接状态

LISTEN：侦听来自远方 TCP 端口的连接请求

1）第一次握手：客户端向服务端发送一个 SYN 报文（SYN = 1），并指明客户端的初始化序列号 ISN(x)，即图中的 seq = x，表示本报文段所发送的数据的第一个字节的序号。此时客户端处于 SYN_Send 状态。

SYN-SENT ：在发送连接请求后等待匹配的连接请求

2）第二次握手：服务器收到客户端的 SYN 报文之后，会发送 SYN 报文作为应答（SYN = 1），并且指定自己的初始化序列号 ISN(y)，即图中的 seq = y。同时会把客户端的 ISN + 1 作为确认号 ack 的值，表示已经收到了客户端发来的的 SYN 报文，希望收到的下一个数据的第一个字节的序号是 x + 1，此时服务器处于 SYN_REVD 的状态。

SYN-RECEIVED：在收到和发送一个连接请求后等待对连接请求的确认

3）第三次握手：客户端收到服务器端响应的 SYN 报文之后，会发送一个 ACK 报文，也是一样把服务器的 ISN + 1 作为 ack 的值，表示已经收到了服务端发来的的 SYN 报文，希望收到的下一个数据的第一个字节的序号是 y + 1，并指明此时客户端的序列号 seq = x + 1（初始为 seq = x，所以第二个报文段要 +1），此时客户端处于 Establised 状态。

服务器收到 ACK 报文之后，也处于 Establised 状态，至此，双方建立起了 TCP 连接。

ESTABLISHED：代表一个打开的连接，数据可以传送给用户

❓ 为什么要三次握手

三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。

只有经过三次握手才能确认双发的收发功能都正常，缺一不可：

• 第一次握手（客户端发送 SYN 报文给服务器，服务器接收该报文）：

  客户端什么都不能确认；

  服务器确认了对方发送正常，自己接收正常；

• 第二次握手（服务器响应 SYN 报文给客户端，客户端接收该报文）：

  客户端确认了：自己发送、接收正常，对方发送、接收正常；

  服务器确认了：对方发送正常，自己接收正常；

• 第三次握手（客户端发送 ACK 报文给服务器）：

  客户端确认了：自己发送、接收正常，对方发送、接收正常；

  服务器确认了：自己发送、接收正常，对方发送、接收正常

半连接队列

服务器第一次收到客户端的 SYN 之后，就会处于 SYN_RCVD 状态，此时双方还没有完全建立其连接，服务器会把这种状态下的请求连接放在一个队列里，我们把这种队列称之为半连接队列。

当然还有一个全连接队列，完成三次握手后建立起的连接就会放在全连接队列中。如果队列满了就有可能会出现丢包现象。

SYN 洪泛攻击（DDOS攻击的一种）

SYN 攻击就是 Client 在短时间内伪造大量不存在的 IP 地址，并向 Server 不断地发送 SYN 包，Server 则回复确认包，并等待 Client 确认，由于源地址不存在，因此 Server 需要不断重发直至超时，这些伪造的 SYN 包将长时间占用半连接队列，导致正常的 SYN 请求因为队列满而被丢弃，从而引起网络拥塞甚至系统瘫痪。

❓ ISN (Initial Sequence Number) 是固定的吗

ISN 随时间而变化，因此每个连接都将具有不同的 ISN。如果 ISN 是固定的，攻击者很容易猜出后续的确认号，因此 ISN 是动态生成的。

❓ 三次握手过程中可以携带数据吗

第三次握手的时候，是可以携带数据的。但是，第一次、第二次握手绝对不可以携带数据

假如第一次握手可以携带数据的话，如果有人要恶意攻击服务器，那他每次都在第一次握手中的 SYN 报文中放入大量的数据，然后疯狂重复发 SYN 报文的话（因为攻击者根本就不用管服务器的接收、发送能力是否正常，它就是要攻击你），这会让服务器花费很多时间、内存空间来接收这些报文。

⭐ 简单的记忆就是，请求连接/接收 即 SYN = 1 的时候不能携带数据

而对于第三次的话，此时客户端已经处于 ESTABLISHED 状态。对于客户端来说，他已经建立起连接了，并且也已经知道服务器的接收、发送能力是正常的了，所以当然能正常发送/携带数据了。

❓ 如果第三次握手丢失了，客户端服务端会如何处理

服务器发送完 SYN-ACK 包，如果未收到客户端响应的确认包，也即第三次握手丢失。那么服务器就会进行首次重传，若等待一段时间仍未收到客户确认包，就进行第二次重传。如果重传次数超过系统规定的最大重传次数，则系统将该连接信息从半连接队列中删除。

注意，每次重传等待的时间不一定相同，一般会是指数增长，例如间隔时间为 1s，2s，4s，8s…

TCP 四次挥手释放连接

客户端或服务端均可主动发起挥手动作。

刚开始双方都处于ESTABLISHED 状态，假设是客户端先发起关闭请求。四次挥手的过程如下：

1）第一次挥手：客户端发送一个 FIN 报文（请求连接终止：FIN = 1），报文中会指定一个序列号 seq = u。并停止再发送数据，主动关闭 TCP 连接。此时客户端处于 FIN_WAIT1 状态，等待服务端的确认。

FIN-WAIT-1 - 等待远程TCP的连接中断请求，或先前的连接中断请求的确认；

2）第二次挥手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序号值 +1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT 状态。

CLOSE-WAIT - 等待从本地用户发来的连接中断请求；

此时的 TCP 处于半关闭状态，客户端到服务端的连接释放。客户端收到服务端的确认后，进入FIN_WAIT2（终止等待 2）状态，等待服务端发出的连接释放报文段。

FIN-WAIT-2 - 从远程TCP等待连接中断请求；

3）第三次挥手：如果服务端也想断开连接了（没有要向客户端发出的数据），和客户端的第一次挥手一样，发送 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态，等待客户端的确认。

LAST-ACK - 等待原来发向远程TCP的连接中断请求的确认；

4）第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答（ack = w+1），且把服务端的序列值 +1 作为自己 ACK 报文的序号值（seq=u+1），此时客户端处于 TIME_WAIT （时间等待）状态。

TIME-WAIT - 等待足够的时间以确保远程TCP接收到连接中断请求的确认；

注意 ！！！这个时候由服务端到客户端的 TCP 连接并未释放掉，需要经过时间等待计时器设置的时间 2MSL（一个报文的来回时间） 后才会进入 CLOSED 状态（这样做的目的是确保服务端收到自己的 ACK 报文。如果服务端在规定时间内没有收到客户端发来的 ACK 报文的话，服务端会重新发送 FIN 报文给客户端，客户端再次收到 FIN 报文之后，就知道之前的 ACK 报文丢失了，然后再次发送 ACK 报文给服务端）。服务端收到 ACK 报文之后，就关闭连接了，处于 CLOSED 状态。

❓ 为什么要四次挥手

由于 TCP 的半关闭（half-close）特性，TCP 提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力。

任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候，则发出连接释放通知，对方确认后就完全关闭了TCP连接。

通俗的来说，两次握手就可以释放一端到另一端的 TCP 连接，完全释放连接一共需要四次握手。

举个例子：A 和 B 打电话，通话即将结束后，A 说 “我没啥要说的了”，B 回答 “我知道了”，于是 A 向 B 的连接释放了。但是 B 可能还会有要说的话，于是 B 可能又巴拉巴拉说了一通，最后 B 说“我说完了”，A 回答“知道了”，于是 B 向 A 的连接释放了，这样整个通话就结束了。

TCP 可靠传输

可靠传输就是保证接收方收到的字节流和发送方发出的字节流是完全一样的

网络层是没有可靠传输机制的，尽自己最大的努力进行交付。而传输层使用 TCP 实现可靠传输，TCP 保证可靠传输的机制有如下几种：

• 校验和（Checksum）
• 序列号和确认应答机制
• 重传机制
• 流量控制（滑动窗口协议）
• 拥塞控制

重传机制

① 超时重传

超时重传就是 TCP 发送方在发送报文的时候，设定一个定时器，如果在规定的时间内没有收到接收方发来的 ACK 确认报文，发送方就会重传这个已发送的报文段。

对于发送方没有正确接收到接收方发来的 ACK 确认报文的情况，有以下两种（也就是在这两种情况下会发生超时重传）：

• 第一种情况：报文段丢失

• 第二种情况：接收方的 ACK 确认报文丢失

超时重传时间我们一般用 RTO（Retransmission Timeout） 来表示，其值应略大于RTT。如果超时重传的数据又超时了，TCP 的策略是重传的 RTO 加倍。

② 快速重传（Fast Retransmit）

快速重传机制不以时间为驱动，而是以数据驱动重传：每当接收方收到比期望序号大的失序报文段到达时，就向发送方发送一个冗余 ACK，指明下一个期待字节的序号。当发送方接收到多个冗余ACk时，就进行重传。

滑动窗口协议

① 累积确认与窗口

只有收到了上一个报文段的确认应答后才能发送下一个报文段的这种模式效率非常低下。每个报文段的往返时间越长，网络的吞吐量就越低，通信的效率就越低。

为此，TCP 引入了 窗口 的概念。窗口大小就是指无需等待确认应答，可以继续发送数据的最大值。

⭐ 窗口的实现实际上是操作系统开辟的一个缓冲区：发送方在等待确认应答报文返回之前，必须在缓冲区中保留已发送的数据。如果在规定时间间隔内收到确认应答报文，就可以将数据从缓冲区中清除。

② 发送方的滑动窗口

下图就是发送方缓存的数据，根据处理的情况分成四个部分：

• 已发送并收到 ACK 确认应答的数据
• 已发送但未收到 ACK 确认应答的数据
• 未发送但总大小在接收方处理范围内的数据
• 未发送但总大小超过接收方处理范围的数据

当发送方把数据全部发送出去后，可用窗口的大小就为 0 了，表明可用窗口耗尽，在没收到 ACK 确认之前无法继续发送数据：

当收到之前发送的数据 32~36 字节的 ACK 确认应答后，如果发送窗口的大小没有变化，则滑动窗口往右边移动 5 个字节，因为有 5 个字节的数据被确认应答，接下来 52~56 字节又变成了可用窗口，那么后续也就可以发送 52~56 这 5 个字节的数据了：

③ 接收方的滑动窗口

接收方的滑动窗口可分为三个部分：

• 已成功接收并确认的数据
• 未收到数据但可以接收的数据
• 未收到数据且不可以接收的数据（超出接收方窗口大小）

同样的，接收方的滑动窗口在成功接收并确认的数据后，窗口右移。

流量控制

重传的过程中，若主机 B 的接收缓冲区情况仍未好转，则会将大量的时间浪费在重传数据上，降低传送数据的效率。

所以引入了流量控制机制，主机 B 通过告诉主机 A 自己接收缓冲区的大小，来使主机 A 控制发送的数据量。总结来说：所谓流量控制就是控制发送方发送速率，保证接收方来得及接收。

TCP首部中窗口字段的含义是指自己接收缓冲区的剩余大小。

接收端会在发送 ACK 确认应答报文时，将自己的即时窗口大小（接收窗口 rwnd）填入，并跟随 ACK 报文一起发送出去。而发送方根据接收到的 ACK 报文中的窗口大小的值改变自己的发送速度。如果接收到窗口大小的值为 0，那么发送方将停止发送数据。并定期的向接收端发送窗口探测数据段，提醒接收端把窗口大小告诉发送端。

拥塞控制

在某段时间，对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能变差。如果网络出现拥塞，TCP 报文可能会大量丢失，此时就会大量触发重传机制，从而导致网络拥塞程度更高，严重影响传输。

❓ 流量控制和拥塞控制的区别

• 流量控制是为了让接收方能来得及接收

• 拥塞控制是为了降低整个网络的拥塞程度，防止过多的数据注入到网络中。

为了调节发送方所要发送数据的量，定义了「拥塞窗口 cwnd」的概念。拥塞窗口是发送方维护的一个状态变量，它会根据网络的拥塞程度动态变化：

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

在引入拥塞窗口概念之前，发送窗口大小和接收窗口大小基本是相等的关系（取决于接收窗口大小）。引入拥塞窗口后，发送窗口的大小就等于拥塞窗口和接收窗口的最小值。

TCP 的拥塞控制采用了四种算法：

① 慢开始

TCP 在刚建立连接完成后，如果立即把大量数据字节注入到网络，那么很有可能引起网络阻塞。好的方法是先探测一下，一点一点的提高发送数据包的数量，即由小到大逐渐增大拥塞窗口数值。cwnd 初始值为 1，每经过一个传播轮次，cwnd 加倍（指数增长）。

当然不能一直执行慢启动，这里会设置一个慢启动轮限 ssthresh 状态变量：

• 当 cwnd < ssthresh 时，继续使用慢启动算法
• 当 cwnd >= ssthresh 时，开始使用「拥塞避免算法」

② 拥塞避免

拥塞避免算法的思路是让拥塞窗口 cwnd 缓慢增大，即每经过一个往返时间 cwnd 加 1。

注意，无论是慢开始阶段还是拥塞避免，只要出现了网络拥塞（触发超时重传机制），慢开始轮限 sshresh 和 拥塞窗口大小 cwnd 的值会发生变化（乘法减小）：

• ssthresh 设为 cwnd/2
• cwnd 重置为 1

由于拥塞窗口大小重置为 1 了，所以就会重新开始执行慢启动算法。

③ 快重传和快恢复

快速重传和快速恢复算法一般同时使用。

快重传：接收方收到三个重复的 ACK 确认的时候，就会执行快重传算法（触发快速重传机制和超时重传机制的情况不同，TCP 认为触发快速重传的情况并不严重，因为大部分没丢，只丢了一小部分），快速重传做的事情有：

• cwnd = cwnd/2
• ssthresh = cwnd
• 进入快速恢复阶段

快恢复：快速恢复的思想是“数据包守恒”原则，即同一个时刻在网络中的数据包数量是恒定的，只有当“老”数据包离开了网络后，才能向网络中发送一 个“新”的数据包，如果发送方收到一个重复的 ACK，那么根据 TCP 的 ACK 机制就表明有一个数据包离开了网络，于是 cwnd 加 1。如果能够严格按照该原则那么网络中很少会发生拥塞，事实上拥塞控制的目的也就在修正违反该原则的地方。

具体来说快速恢复的主要步骤是：

• 把 cwnd 设置为 ssthresh 的值加 3，然后重传丢失的报文段，加 3 的原因是因为收到 3 个重复的 ACK，表明有 3 个“老”的数据包离开了网络。
• 再收到重复的 ACK 时，拥塞窗口 cwnd 增加 1
• 当收到新的数据包的 ACK 时，把 cwnd 设置为第一步中的 ssthresh 的值。原因是因为该 ACK 确认了新的数据，说明从重复 ACK 时的数据都已收到，该恢复过程已经结束，可以回到恢复之前的状态了，也即再次进入拥塞避免状态。

UDP 用户数据报协议

UDP（User Datagram Protocol） 在传送数据之前不需要先建立连接，远程主机在收到 UDP 报文后，不需要给出任何确认。虽然 UDP 不提供可靠交付，但在某些情况下 UDP 确是一种最有效的工作方式（一般用于即时通信），比 QQ 语音、 QQ 视频 、直播等等

UDP首部8个字节

UDP面向报文，不做任何的拆分与合并，默认只有一个 UDP 报文，这么做就会导致一个问题，UDP 报文被限制在 512 字节以内

应用层

应用层最接近于用于，它的任务就是通过应用进程间的交互来完成特定网络应用。

应用层协议定义的是应用进程间的通信和交互的规则。由于传输层传来的数据五花八门，有 html 格式的，有 mp4 格式等等，所以对于不同的网络应用需要不同的应用层协议。在互联网中应用层协议很多，如域名系统 DNS，支持万维网应用的 HTTP 协议，支持电子邮件的 SMTP 协议等等。我们把应用层交互的数据单元称为报文。

URI & URL

**URI（Uniform Resource Identifier， 统一资源标志符）**表示的是web上每一种可用的资源，如 HTML文档、图像、视频片段、程序等都由一个URI进行标识的。

**URL（Uniform Resource Locator，统一资源定位符）**是URI概念的一种实现方式，一般格式为：protocol :// hostname[:port] / path / [;parameters][?query]#fragment

URL的格式由三部分组成：

①第一部分是协议(或称为服务方式)。

②第二部分是存有该资源的主机IP地址(有时也包括端口号)。

③第三部分是主机资源的具体地址，如目录和文件名等。

DNS 域名解析协议

port：53（UDP+TCP）

域名系统（DNS，Domain Name System），将域名和 IP 地址相互映射的一个分布式数据库 (这里的分布式数据库是指，每个站点只保留它自己的那部分数据)，能够使人更方便的访问互联网，而不用去记住能够被机器直接读取的 IP 地址。

全世界域名的最高管理机构，是一个叫做 ICANN （Internet Corporation for Assigned Names and Numbers）的组织，总部在美国加州。ICANN 负责管理全世界域名系统的运作。

域名具有层次结构，从上到下依次为：根域名（在有些场合，www.xxx.com 被写成 www.xxx.com.，即最后还会多出一个点，这个点就是根域名）、顶级域名、二级域名。

DNS 可以使用 UDP 或者 TCP 进行传输，使用的端口号都为 53。大多数情况下 DNS 使用 UDP 进行传输，这就要求域名解析器和域名服务器都必须自己处理超时和重传从而保证可靠性。

域名解析方式：迭代查询，（递归查询效率低）

**DNS搜索顺序：**浏览器的缓存（固定的 DNS 缓存时间），操作系统的缓存（hosts 文件，DNS 缓存服务DNSClient），本地域名服务器，迭代解析

❓ DNS 分别在什么情况下使用 UDP 和 TCP

1）若客户端事先知道 DNS 响应报文的长度会大于 512 字节，则应当直接使用 TCP 建立连接

2）若客户端事先不知道 DNS 响应报文的长度，一般会先使用 UDP 协议发送 DNS 查询报文，若 DNS 服务器发现 DNS 响应报文的长度大于 512 字节，则多出来的部分会被 UDP 抛弃（截断 TrunCation），那么服务器会把这个部分被抛弃的 DNS 报文首部中的 TC 标志位置为 1，以通知客户端该 DNS 报文已经被截断。客户端收到之后会重新发起一次 TCP 请求，从而使得它将来能够从 DNS 服务器收到完整的响应报文。

当然了，在域名解析的时候，一般返回的 DNS 响应报文都不会超过 512 字节，用 UDP 传输即可。事实上，很多 DNS 服务器进行配置的时候，也仅支持 UDP 查询包。

在进行区域传输（辅助域名服务器与主域名服务器通信，并同步数据信息）的时候 DNS 会强制使用 TCP 协议。

HTTP 协议

HTTP：超文本传输协议（HyperText Transfer Protocol）是当今互联网上应用最为广泛的一种网络协议。所有的 WWW（万维网） 文件都必须遵守这个标准。HTTP 和 TCP/IP 协议簇中的众多协议一样，用于客户端和服务器端之间的通信。

HTTP/0.9：HTTP 于 1990 年问世，功能简陋，仅支持 GET 请求方式，并且仅能访问 HTML 格式的资源。那时的 HTTP 并没有作为正式的标准被建立，因此被被称为 HTTP 0.9。

HTTP/1.0：1996 年 5 月 HTTP 正式作为标准被公布，版本号为 HTTP 1.0。在 0.9 版本上做了进步，增加了请求方式 POST 和 HEAD；不再局限于 0.9 版本的 HTML 格式，根据 Content-Type 可以支持多种数据格式… 需要注意的是：1.0 版本的工作方式是短连接。虽说 HTTP/1.0 是初期标准，但该协议标准至今仍然在被广泛使用。

HTTP/1.1：1997 年公布的 HTTP 1.1 是目前主流的 HTTP 协议版本。当年的 HTTP 协议的出现主要是为了解决文本传输的难题，现在的 HTTP 早已超出了 Web 这个框架的局限，被运用到了各种场景里。当然，1.1 版本的最大变化，就是引入了长连接以及流水线机制（管道机制）。

HTTP 请求和响应

① HTTP 请求报文

HTTP 请求报文由 3 大部分组成：

1）请求行（必须在 HTTP 请求报文的第一行）

2）请求头（从第二行开始，到第一个空行结束。请求头和请求体之间存在一个空行）

3）请求体（通常以键值对 {key:value}方式传递数据，非必须）

HTTP 请求方法

包括（HTTP 1.1）：GET（获取资源）、POST（传输数据）、PUT（传输文件，不带验证机制）、HEAD（获取报文首部）、DELETE（删除文件，不带验证机制）、OPTIONS（查询支持的方法）、CONNECT、TRACE。

HTTP 请求头

1）Referer：表示这个请求是从哪个 URI 跳过来的。

2）Accept：告诉服务端，该请求所能支持的响应数据类型。（对应的，HTTP 响应报文中也有这样一个类似的字段 Content-Type，用于表示服务端发送的数据类型，如果 Accept 指定的类型和服务端返回的类型不一致，就会报错）

text/plain;q = 0.3 表示对于 text/plain 媒体类型的数据优先级/权重为 0.3（q 的范围 0 ~ 1）。不指定权重的，默认为 1.0。

3）Host：告知服务器请求的资源所处的互联网主机名和端口号。该字段是 HTTP/1.1 规范中唯一一个必须被包含在请求头中的字段。

4）Cookie：客户端的 Cookie 就是通过这个报文头属性传给服务端的

Cookie: JSESSIONID=15982C27F7507C7FDAF0F97161F634B5

5）Connection：表示客户端与服务连接类型；Keep-Alive 表示持久连接，close 已关闭

6）Content-Length：请求体的长度

7）Accept-Language：浏览器通知服务器，浏览器支持的语言

8）Range：对于只需获取部分资源的范围请求，包含首部字段 Range 即可告知服务器资源的指定范围

② HTTP响应报文

HTTP的响应报文也由三部分组成：

• 响应行（必须在 HTTP 响应报文的第一行）
• 响应头（从第二行开始，到第一个空行结束。响应头和响应体之间存在一个空行）
• 响应体

HTTP 状态码

HTTP 状态码负责表示客户端 HTTP 请求的的返回结果、标记服务器端处理是否正常、通知出现的错误等工作。

状态码由 3 位数字组成，第一个数字定义了响应的类别：

	类别	原因短语
1xx	Informational 信息性状态码	接收的请求正在处理
2xx	Success 成功状态码	请求正常处理完毕
3xx	Redirection 重定向状态码	需要进行附加操作以完成请求
4xx	Client Error 客户端错误状态码	服务器无法处理请求
5xx	Server Error 服务器错误状态码	服务器处理请求出错

2xx：请求正常处理完毕

• 200 OK：客户端请求成功
• 204 No Content：无内容。服务器成功处理，但未返回内容。一般用在只是客户端向服务器发送信息，而服务器不用向客户端返回什么信息的情况。不会刷新页面。
• 206 Partial Content：服务器已经完成了部分 GET 请求（客户端进行了范围请求）。响应报文中包含 Content-Range 指定范围的实体内容

3xx：需要进行附加操作以完成请求（重定向）

• 301 Moved Permanently：永久重定向，表示请求的资源已经永久的搬到了其他位置。

• 302 Found：临时重定向，表示请求的资源临时搬到了其他位置

• 303 See Other：临时重定向，应使用GET定向获取请求资源。303功能与302一样，区别只是303明确客户端应该使用GET访问

• 304 Not Modified：表示客户端发送附带条件的请求（GET方法请求报文中的IF…）时，条件不满足。返回304时，不包含任何响应主体。虽然304被划分在3XX，但和重定向一毛钱关系都没有

• 307 Temporary Redirect：临时重定向，和302有着相同含义。POST不会变成GET

4xx：客户端错误

• 400 Bad Request：客户端请求有语法错误，服务器无法理解。

• 401 Unauthorized：请求未经授权，这个状态代码必须和 WWW-Authenticate 报头域一起使用。

• 403 Forbidden：服务器收到请求，但是拒绝提供服务

• 404 Not Found：请求资源不存在。比如，输入了错误的 URL

• 415 Unsupported media type：不支持的媒体类型

5xx：服务器端错误，服务器未能实现合法的请求。

• 500 Internal Server Error：服务器发生不可预期的错误。

• 503 Server Unavailable：服务器当前处于超负载或正在停机维护，暂时不能处理客户端的请求，一段时间后可能恢复正常

HTTP 响应头

响应头也是用键值对 k：v，用于补充响应的附加信息、服务器信息，以及对客户端的附加要求等。

HTTP 连接管理

① 短连接（非持久连接）

客户端和服务器每进行一次 HTTP 会话，就建立一次连接，任务结束就中断连接，大大增加了通信量的开销。

当客户端浏览器访问的某个 HTML 或其他类型的 Web 页中包含有其他的 Web 资源（如JavaScript 文件、图像文件、CSS文件等），每遇到这样一个 Web 资源，浏览器就会重新建立一个 HTTP 会话。这种方式称为短连接（也称非持久连接）。

② 长连接（持久连接）

使用长连接的 HTTP 协议，会在响应头加入这行代码：Connection:keep-alive

在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输 HTTP 数据的 TCP 连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。Keep-Alive 不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如 Apache）中设定这个时间。实现长连接需要客户端和服务端都支持长连接。

③ 流水线（管线化）

默认情况下，HTTP 请求是按顺序发出的，下一个请求只有在当前请求收到响应之后才会被发出。由于受到网络延迟和带宽的限制，在下一个请求被发送到服务器之前，可能需要等待很长时间。

持久连接使得多数请求以流水线（管线化 pipeline）方式发送成为可能，即在同一条持久连接上连续发出请求，而不用等待响应返回后再发送，这样就可以做到同时并行发送多个请求，而不需要一个接一个地等待响应了。

无状态的 HTTP（Cookie和Session）

HTTP 协议是无状态协议。也就是说他不对之前发生过的请求和响应的状态进行管理，即无法根据之前的状态进行本次的请求处理。

由于不必保存状态，自然就减少了服务器的 CPU 及内存资源的消耗。

**Cookie：**一小段文本信息。客户端请求服务器，如果服务器需要记录该用户状态，就使用response向客户端浏览器颁发一个Cookie（响应头中加上 Set-Cookie 字段）。客户端会把Cookie保存起来，后续请求服务器的时候，带上Cookie即可。

**Session：**客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上。每个用户访问服务器都会建立一个session，用户与服务器建立连接的同时，服务器会自动为其分配一个SessionId。

❓ Session和Cookie的区别

1、数据存储位置：cookie数据存放在客户的浏览器上，session数据放在服务器上。

2、安全性：cookie不是很安全，别人可以分析存放在本地的cookie并进行cookie欺骗，考虑到安全应当使用session。

3、服务器性能：session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能，考虑到减轻服务器性能方面，应当使用cookie。

4、数据大小：单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。

5、信息重要程度：可以考虑将登陆信息等重要信息存放为session，其他信息如果需要保留，可以放在cookie中。

HTTP 断点续传

所谓断点续传指的是下载传输文件可以中断，之后重新下载时可以接着中断的地方开始下载，而不必从头开始下载。断点续传需要客户端和服务端都支持。

理很简单，其实就是 HTTP 请求头中的字段 Range 和响应头中的字段 Content-Range 的简单使用。

HTTP 的缺点

• 通信使用明文（不加密），内容可能被窃听
• 不验证通信对方的身份，因此有可能遭遇伪装
• 无法证明报文的完整性，所以有可能被篡改

HTTPS 协议

HTTP 的不安全性体现在很多方面，即 HTTP 的缺点。

• 内容被窃听：即使是加密过的通信内容，也会被窥视到，这点和未加密的通信是相同的，只能说经过加密后的内容，即便被攻击者窥视到，他也可能无法破解其中的含义罢了
• 身份被伪装：服务器伪装，客户端伪装，访问权限，无意义请求
• 报文被篡改：完整性不保证，中间人攻击（Main-in-the-Middle attack, MITM）

HTTPS 协议并非应用层的一个新协议，只是 HTTP 通信接口部分用 SSL（Secure Socket Layer）和 TLS（Transport Layer Security）协议代替而已。

另外，SSL 是独立于 HTTP 协议的，所有运行在应用层的协议都可以配合 SSL 协议使用。可以说，SSL 协议是当今世界上应用最为广泛的网络安全技术。

由于使用了加密通信， 相比于纯文本通信的 HTTP 来说，HTTPS 会消耗掉更多的 CPU 及内存资源，另外，开启 HTTPS 需要申请 SSL 证书，高额的证书申购费用会让很多网站开发者望而却步。

加密

密钥：就是钥匙，加密方有一把密钥，用来上锁，解密方也拥有一把密钥，用来解锁。而且加密方和解密方使用的密钥不一定是同一把。

对称密钥

加密和解密使用同一密钥的方式称为对称密钥加密，也称做共享密钥加密（Common Key crypto system）。

以共享密钥加密时必须将密钥也发送给对方。显然，如果通信双方都各自持有同一个密钥，且没有别人知道，则两方的通信安全是可以被保证的（除非密钥被破解），而且效率很高。

那么，最大的问题就是如何保证这个密钥的安全传输，不被外部攻击者知道。如果由服务器生成一个密钥并传输给浏览器，这个传输过程中密钥被攻击者劫持，那么之后攻击者就能用这把密钥解开双方传输的任何内容。因此一般在建立连接时用非对称加密传输共享秘钥，之后通信时再用对称加密方法，即混合加密。

非对称的密钥

加密和解密使用不同密钥。

RSA非对称秘钥加密算法

需要一个算法，正向计算容易，但逆向反推难——模运算符合这个特性：计算模简单，但反推指数难，只能穷举（当除数很大时不可取）

使用模运算即可实现加密解密过程：

合并两式得：

如何选取e和d成为关键。此时要用到欧拉定理：

这里的 $\phi (n)$ 表示：小于等于n的正整数中，有多少与n互质的数。将欧拉公式进行变换并对比上式可得下式，其中k为任意正整数

可以通过选取k，n，e，计算得到d：

计算 $\phi (n)$ 的一般方法为质因数分解，但大数质因数分解很难。但如果n是一个质数p，则有：

运用到d的计算中：

由于这里的p和q是自己选取，别人不知道，所以无法通过大数n的质因数分解得到p和q，因而无法计算出 $\phi (n)$和 d

数字签名

遗憾的是，混合加密的方式仍然还是有漏洞的。攻击者（中间人）的确无法得到浏览器生成的对称密钥 X，但攻击者完全不需要拿到服务器私有的私钥就能劫持信息！

中间人只需截获服务器发布的公钥，篡改成自己的公钥发给客户端，客户端就会用中间人的公钥加密共享秘钥，中间人再用自己的私钥解密即可获得共享秘钥。根本原因是：浏览器客户端无法确认自己收到的公钥是不是真正的网站服务器的。

❓ 如何证明浏览器客户端收到的公钥一定是该网站服务器的公钥

服务器在发布公钥和文件时，会同时用私钥将文件哈希值运算得到数字签名，放到网站上。客户端将文件的数字签名和公钥运算得到的文件哈希值与文件本身哈希值对比即可确定文件没有被篡改，并且签名来自于私钥拥有者。

但私钥拥有者不一定等于服务器，因为中间人也可生成一套公钥私钥，对文件签名。客户端验证时使用伪公钥和伪签名对文件进行验证，依旧可以通过。

数字证书

为确保客户端验证时使用的是目的服务器的公钥和数字签名，需要使用公信机构： 数字证书认证机构（Certificate Authority, CA），即客户端和浏览器都信赖的第三方机构。

网站服务器在使用 HTTPS 前，需要向 CA 申请颁发数字证书，数字证书里有证书持有者、证书持有者的公钥，前两者的数字签名等信息。服务器把数字证书明文传输给浏览器客户端，然后浏览器从证书里取出服务器的公钥就可以了。

由于计算机里默认安装了根证书，其中包括CA机构的公钥，因此数字证书具有不可为造性。

DHCP 协议

**DHCP 协议（Dynamic Host Configuration Protocol，动态主机配置协议）**实现自动配置 IP 地址、统一管理 IP 地址分配

是，混合加密的方式仍然还是有漏洞的。攻击者（中间人）的确无法得到浏览器生成的对称密钥 X，但攻击者完全不需要拿到服务器私有的私钥就能劫持信息！

中间人只需截获服务器发布的公钥，篡改成自己的公钥发给客户端，客户端就会用中间人的公钥加密共享秘钥，中间人再用自己的私钥解密即可获得共享秘钥。根本原因是：浏览器客户端无法确认自己收到的公钥是不是真正的网站服务器的。

❓ 如何证明浏览器客户端收到的公钥一定是该网站服务器的公钥

服务器在发布公钥和文件时，会同时用私钥将文件哈希值运算得到数字签名，放到网站上。客户端将文件的数字签名和公钥运算得到的文件哈希值与文件本身哈希值对比即可确定文件没有被篡改，并且签名来自于私钥拥有者。

[外链图片转存中…(img-RblhhUGk-1641461251724)]

但私钥拥有者不一定等于服务器，因为中间人也可生成一套公钥私钥，对文件签名。客户端验证时使用伪公钥和伪签名对文件进行验证，依旧可以通过。

数字证书

为确保客户端验证时使用的是目的服务器的公钥和数字签名，需要使用公信机构： 数字证书认证机构（Certificate Authority, CA），即客户端和浏览器都信赖的第三方机构。

网站服务器在使用 HTTPS 前，需要向 CA 申请颁发数字证书，数字证书里有证书持有者、证书持有者的公钥，前两者的数字签名等信息。服务器把数字证书明文传输给浏览器客户端，然后浏览器从证书里取出服务器的公钥就可以了。

[外链图片转存中…(img-ZnojGn8F-1641461251725)]

由于计算机里默认安装了根证书，其中包括CA机构的公钥，因此数字证书具有不可为造性。

DHCP 协议

**DHCP 协议（Dynamic Host Configuration Protocol，动态主机配置协议）**实现自动配置 IP 地址、统一管理 IP 地址分配