2.5 HTTPS
数字签名：发送端将消息使⽤ hash 函数⽣成摘要，并使⽤私钥加密后得到"数字签名"，并将其附在消息之后。接收端使⽤公钥对"数字签名"解密，确认发送端身份，之后对消息使⽤ hash 函数处理并与接收到的摘要对⽐，确认消息是否被修改。
数字证书 ：数字中⼼ CA 使⽤私钥对⽤户的公钥和相关信息⼀起加密，⽣成"数字证书"。发送端在发送时除了需要数字签名，还需要附上数字证书。接收端使⽤ CA 公钥解开数字证书，拿到⽤户的公钥，则可证明该数字签名是真实发送端发送的。
证书吊销列表 (CRL) ：⼀个结构化数据⽂件，该⽂件包含证书颁发机构 (CA) 已经吊销的证书的序列号及其吊销⽇期等。 证书吊销列表分发点 (CDP) ：是含在数字证书中的⼀个可以供各种应⽤软件⾃动下载的最新的 CRL 的位置信息。CDP ⼀般是⼀个可以访问 http ⽹址。 证书状态在线查询协议（OCSP）：是⽤于实时查询数字证书在某⼀时间是否有效的标准。
HTTP 与 HTTPS 有哪些区别？
● 安全性：HTTP 是超⽂本传输协议，信息是明⽂传输，存在安全⻛险的问题。HTTPS 在 TCP 和
HTTP 之间加⼊了 SSL/TLS 安全协议，使得报⽂能够加密传输。
● 连接步骤：TCP 三次握⼿之后便可进⾏ HTTP 的报⽂传输。⽽ HTTPS 在 TCP 三次握⼿之后，还需进⾏ SSL/TLS 的握⼿过程，才可进⼊加密报⽂传输。
● 速度、资源：根据上述分析，HTTP速度快，使⽤资源少；HTTPS速度慢，使⽤资源多。
● 端⼝号：HTTP 的端⼝号是 80，HTTPS 的端⼝号是 443。
● HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的。
SSL/TLS
SSL/TLS协议的基本思路是采⽤公钥加密法，也就是说，客户端先向服务器端索要公钥，然后⽤公钥加密信息，服务器收到密⽂后，⽤⾃⼰的私钥解密。
作⽤：
- 所有信息都是加密传播，第三⽅⽆法窃听。
- 具有校验机制，⼀旦被篡改，通信双⽅会⽴刻发现。
- 配备身份证书，防⽌身份被冒充。
如何保证公钥不被篡改？
解决⽅法：将公钥放在数字证书中。只要证书是可信的，公钥就是可信的。
公钥加密计算量太⼤，如何减少耗⽤的时间？
每⼀次对话（session），客户端和服务器端都⽣成⼀个"对话密钥"（session key），⽤它来加密信息。由于"对话密钥"是对称加密，所以运算速度⾮常快，⽽服务器公钥只⽤于加密"对话密钥"本身，这样就减少了加密运算的消耗时间。
TCP 与 HTTPS 握⼿顺序
「HTTPS 是先进⾏ TCP 三次握⼿，再进⾏ TLSv1.2 四次握⼿」，⽽「HTTPS 中的 TLS 握⼿过程可以同时进⾏三次握⼿」，这个场景是可能存在的，但是需要同时满⾜下⾯这两个条件才可以： - 客户端和服务端已经完成过⼀次通信；
- TLS 版本是 1.3 （TLSv1.3 会话恢复机制，在重连 TLvS1.3 只需要 0-RTT）；
- 客户端和服务端都开启了 TCP Fast Open 功能（第⼀次通信服务端设置cookie选项，之后客户端保存并在后续再次连接时使⽤，可传递cookie建⽴连接并传输数据）。
RSA 密钥交换算法
第⼀次握⼿：客户端发出请求（ClientHello）
⾸先，客户端（通常是浏览器）先向服务器发出加密通信的请求，这被叫做ClientHello请求。在这⼀步，客户端主要向服务器提供以下信息。
- ⽀持的协议版本，⽐如TLS 1.0版。
- ⼀个客户端⽣成的随机数，稍后⽤于⽣成"对话密钥"。
- ⽀持的加密⽅法，⽐如RSA公钥加密。
- ⽀持的压缩⽅法。
第⼆次握⼿：服务器回应（SeverHello） 服务器收到客户端请求后，向客户端发出回应，这叫做SeverHello。服务器的回应包含以下内容。 - 确认使⽤的加密通信协议版本。如果浏览器与服务器⽀持的版本不⼀致，服务器关闭加密通信。
- 服务器⽣成的随机数，稍后⽤于⽣成"对话密钥"。
- 确认使⽤的加密⽅法。
- 服务器证书。除了上⾯这些信息，如果服务器需要确认客户端的身份，就会再包含⼀项请求，要求客户端提供"客户端证书"。
第三次握⼿：客户端回应
客户端收到服务器回应以后，⾸先验证服务器证书。如果证书不是可信机构颁布、或者证书中的域名与实际域名不⼀致、或者证书已经过期，就会向访问者显示⼀个警告，由其选择是否还要继续通信。如果证书没有问题，客户端就会从证书中取出服务器的公钥。然后，向服务器发送下⾯三项信息。 - ⼀个随机数。该随机数⽤服务器公钥加密，防⽌被窃听。
- 编码改变通知，表示随后的信息都将⽤双⽅商定的加密⽅法和密钥发送。
- 客户端握⼿结束通知，表示客户端的握⼿阶段已经结束。这⼀项同时也是前⾯发送的所有内容的
hash值，⽤来供服务器校验。此时客户端和服务器就同时有了三个随机数，接着双⽅就⽤事先商定的加密⽅法，各⾃⽣成本次会话所⽤的同⼀把"会话密钥"。此外，如果前⼀步服务器要求客户端证书，客户端会在这⼀步发送证书及相关信息。
第四次握⼿：服务器的最后回应服务器收到客户端的第三个随机数pre-master key之后，计算⽣成本次会话所⽤的"会话密钥"。然后，向客户端最后发送下⾯信息。 - 编码改变通知，表示随后的信息都将⽤双⽅商定的加密⽅法和密钥发送。
- 服务器握⼿结束通知，表示服务器的握⼿阶段已经结束。这⼀项同时也是前⾯发送的所有内容的
hash值，⽤来供客户端校验。⾄此，整个握⼿阶段全部结束。接下来，客户端与服务器进⼊加密通信，就完全是使⽤普通的HTTP协议，只不过⽤"会话密钥"加密内容。如何⾃动切换到 HTTPS 的？ - 最原始的使⽤ 302 跳转。但这样做有⼀个明显的安全漏洞， 很可能都没到 302 跳转的时候就被劫持了。
- 使⽤ HSTS 。⽀持 HSTS 的服务端，可以强制访问它的浏览器使⽤ HTTPS 协议。
使⽤ RSA 密钥协商算法的最⼤问题是不⽀持前向保密。因为客户端传递随机数（⽤于⽣成对称加密密钥的条件之⼀）给服务端时使⽤的是公钥加密的，服务端收到到后，会⽤私钥解密得到随机数。所以⼀旦服务端的私钥泄漏了，过去被第三⽅截获的所有 TLS通讯密⽂都会被破解。为了解决这个问题，后⾯就出现了 ECDHE 密钥协商算法，我们现在⼤多数⽹站使⽤的正是 ECDHE 密钥协商算法。
ECDHE 密钥交换算法
ECDHE 密钥协商算法是 DH 算法演进过来的，DH 算法是⾮对称加密算法， 因此它可以⽤于密钥交换，该算法的核⼼数学思想是离散对数。
RSA 和 ECDHE 握⼿过程的区别：
● RSA 密钥协商算法「不⽀持」前向保密，ECDHE 密钥协商算法「⽀持」前向保密；
● 使⽤了 RSA 密钥协商算法，TLS 完成四次握⼿后，才能进⾏应⽤数据传输，⽽对于 ECDHE 算
法，客户端可以不⽤等服务端的最后⼀次 TLS 握⼿，就可以提前发出加密的 HTTP 数据，节省了
⼀个消息的往返时间；
2.6 DNS
整体流程：浏览器搜索⾃身的 DNS 缓存、搜索操作系统的 DNS 缓存、读取本地的 Host ⽂件和向本地 DNS 服务器进⾏查询等。
DNS 服务器查询共有两类：
- 递归查询：当 A 向 B 查询某个域名的 IP 地址时，如果 B 不知道被查询的域名的 IP 地址，那么
B 会替 A 向更上层的服务器发起查询，将查询结果返回 A。 - 迭代查询：当 A 向 B 查询某个域名的 IP 地址时，如果 B 不知道被查询的域名的 IP 地址，B 会告诉 A 下⼀步应该向哪个服务器查询，由 A ⾃⼰去查。
⼀般来说，主机向本地域名服务器的查询是递归查询，⽽本地域名服务器向根域名服务器的查询是迭代查询。
2.7 IP
IP协议（头部20字节）使⽤逐跳的⽅式确定通信路径，为上层协议提供⽆状态、⽆连接、不可靠的服务。
● ⽆状态 是指 IP 通信双⽅不同步传输数据的状态信息，因此所有IP数据报的发送、传输和接收都是相互独⽴、没有上下⽂关系的，这种服务最⼤的缺点是⽆法处理乱序和重复的IP数据报。
● ⽆连接 是指 IP 通信双⽅都不⻓久地维持对⽅的任何信息，上层协议每次发送数据的时候，都必须明确指定对⽅的IP地址。
● 不可靠 是指 IP 协议不能保证 IP 数据报准确地到达接收端，即使检测到 IP 数据报发送失败，则通知上层协议发送失败，⽽不会试图重传。IP 转发处理步骤：
- 检查数据报头部的TTL值，如果等于0则丢弃该数据报；
- 查看数据报头部的严格源路由选择选项。如果该项被设置，则检测数据报的⽬标IP地址是否是本机的某个IP地址。如果不是，则发送⼀个ICMP源站选路失败报⽂给发送端。如果有必要，则给源端发送⼀个ICMP重定向报⽂，以告诉它⼀个更合理的下⼀跳路由器；
3. 将TTL值减⼀； - 处理IP头部选项。如果有必要，则执⾏IP分⽚操作。
2.8 WebSocket
握⼿过程
- 浏览器、服务器建⽴ TCP 连接，三次握⼿
- TCP 连接成功后，浏览器通过 HTTP 协议向服务器传送 WebSocket ⽀持的版本号等信息
- 服务器收到客户端的握⼿请求后，同样采⽤ HTTP 协议回馈数据
- 当收到了连接成功的消息后，通过 TCP 通道进⾏传输通信
WebSocket 与 HTTP 的关系
相同点： - 都是基于 TCP 的、可靠的传输协议
- 都是应⽤层协议
不同点： - WebSocket 是双向通信协议，模拟 Socket 协议，可以双向发送或接受信息。HTTP 是单向的
- WebSocket 是需要握⼿进⾏建⽴连接的联系：
WebSocket 在建⽴握⼿时，数据是通过 HTTP 传输的。但是建⽴之后，在真正传输的时候是不需要HTTP 协议的WebSocket 与 Socket 关系。 - Socket 其实并不是⼀个协议，⽽是为了⽅便使⽤ TCP 或 UDP ⽽抽象出来的⼀层，是位于应⽤层和传输层之间的⼀组接⼝。当两台主机通信时，必须通过 Socket 连接，Socket 则利⽤ TCP/IP
协议建⽴ TCP 连接。TCP 连接则更依靠于底层的 IP 协议，IP 协议的连接则依赖于链路层等更低
层次。 - WebSocket 则是⼀个典型的应⽤层协议。
WebSocket 与 HTML5 的关系
WebSocket API 是 HTML5 标准的⼀部分，但这并不代表 WebSocket ⼀定要⽤在 HTML 中，或者只能在基于浏览器的应⽤程序中使⽤。实际上，许多语⾔、框架和服务器都提供了 WebSocket ⽀持。
2.9 DHCP
DHCP（ 动态主机配置协议 ）是⼀个局域⽹的⽹络协议。指的是由服务器控制⼀段IP地址范围，客户机登录服务器时就可以⾃动获得服务器分配的IP地址和⼦⽹掩码。DHCP 客户端进程监听的是 68 端⼝号，DHCP 服务端进程监听的是 67 端⼝号。
4 个步骤：
● 客户端⾸先发起 DHCP 发现报⽂（DHCP DISCOVER） 的 IP 数据报，由于客户端没有 IP 地址，也不知道 DHCP 服务器的地址，所以使⽤的是 UDP ⼴播通信，其使⽤的⼴播⽬的地址是
68 255.255.255.255（端⼝ 67） 并且使⽤ 0.0.0.0（端⼝ 68） 作为源 IP 地址。DHCP 客户端将该
IP 数据报传递给链路层，链路层然后将帧⼴播到所有的⽹络中设备。
● DHCP 服务器收到 DHCP 发现报⽂时，⽤ DHCP 提供报⽂（DHCP OFFER） 向客户端做出响
应。该报⽂仍然使⽤ IP ⼴播地址 255.255.255.255，该报⽂信息携带服务器提供可租约的 IP 地
址、⼦⽹掩码、默认⽹关、DNS 服务器以及 IP 地址租⽤期。
● 客户端收到⼀个或多个服务器的 DHCP 提供报⽂后，从中选择⼀个服务器，并向选中的服务器发送 DHCP 请求报⽂进⾏响应，回显配置的参数。
● 最后，服务端⽤ DHCP ACK 报⽂对 DHCP 请求报⽂进⾏响应，应答所要求的参数。
⼀旦客户端收到 DHCP ACK 后，交互便完成了，并且客户端能够在租⽤期内使⽤ DHCP 服务器分配的 IP 地址 如果租约的 DHCP IP 地址快到期后，客户端会向服务器发送 DHCP 请求报⽂：
● 服务器如果同意继续租⽤，则⽤ DHCP ACK 报⽂进⾏应答，客户端就会延⻓租期。
● 服务器如果不同意继续租⽤，则⽤ DHCP NACK 报⽂，客户端就要停⽌使⽤租约的 IP 地址。
可以发现，DHCP 交互中，全程都是使⽤ UDP ⼴播通信。如果 DHCP 服务器和客户端不是在同⼀个局域⽹内，路由器⼜不会转发⼴播包，为了解决这⼀问题，就出现了 DHCP 中继代理。有了 DHCP 中继代理以后，对不同⽹段的 IP 地址分配也可以由⼀个 DHCP服务器统⼀进⾏管理。
● DHCP 客户端会向 DHCP 中继代理发送 DHCP 请求包，⽽ DHCP 中继代理在收到这个⼴播包以
后，再以单播的形式发给 DHCP 服务器。
● 服务器端收到该包以后再向 DHCP 中继代理返回应答，并由 DHCP 中继代理将此包⼴播给 DHCP客户端 。因此，DHCP 服务器即使不在同⼀个链路上也可以实现统⼀分配和管理IP地址.
2.10 NET
由于绝⼤多数的⽹络应⽤都是使⽤传输层协议 TCP 或 UDP 来传输数据的。因此，可以把 IP 地址 + 端⼝号⼀起进⾏转换。这样，就⽤⼀个全球 IP 地址就可以了，这种转换技术就叫⽹络地址与端⼝转换NAPT。这种转换表在 NAT 路由器上⾃动⽣成。例如，在 TCP 的情况下，建⽴ TCP 连接⾸次握⼿时的 SYN 包⼀经发出，就会⽣成这个表。⽽后⼜随着收到关闭连接时发出 FIN 包的确认应答从表中被删除。由于 NAT/NAPT 都依赖于⾃⼰的转换表，因此会有以下的问题：
● 外部⽆法主动与 NAT 内部服务器建⽴连接，因为 NAPT 转换表没有转换记录。
● 转换表的⽣成与转换操作都会产⽣性能开销。
● 通信过程中，如果 NAT 路由器重启了，所有的 TCP 连接都将被重置。
解决的⽅法：
● 第⼀种改⽤ IPv6：IPv6 可⽤范围⾮常⼤，以⾄于每台设备都可以配置⼀个公有 IP 地址，就不搞那么多花⾥胡哨的地址转换了，但是 IPv6 普及速度还需要⼀些时间。
● 第⼆种 NAT 穿透技术：客户端主动从 NAT 设备获取公有 IP 地址，然后⾃⼰建⽴端⼝映射条⽬，并⽤这个条⽬对外通信，就不需要 NAT 设备来进⾏转换了。
2.11 IGMP
IGMP 是因特⽹组管理协议，⼯作在主机（组播成员）和最后⼀跳路由之间。IGMP 报⽂向路由器申请 加⼊和退出组播组，默认情况下路由器是不会转发组播包到连接中的主机，除⾮主机通过 IGMP 加⼊到 组播组，主机申请加⼊到组播组时，路由器就会记录 IGMP 路由器表，路由器后续就会转发组播包到对 应的主机了。IGMP 报⽂采⽤ IP 封装，IP 头部的协议号为 2，⽽且 TTL 字段值通常为 1，因为 IGMP 是⼯作在主机与连接的路由器之间。 常规查询与响应⼯作机制
● 路由器会周期性发送⽬的地址为 224.0.0.1（表示同⼀⽹段内所有主机和路由器） IGMP 常规查询报⽂。
● 主机收到这个查询，随后会启动「报告延迟计时器」，计时器的时间是随机的，通常是 0~10 秒，计时器超时后主机就会发送 IGMP 成员关系报告报⽂（源 IP 地址为⾃⼰主机的 IP 地址，⽬的 IP 地址为组播地址）。如果在定时器超时之前，收到同⼀个组内的其他主机发送的成员关系报告报⽂，则⾃⼰不再发送，这样可以减少⽹络中多余的 IGMP 报⽂数量。
● 路由器收到主机的成员关系报⽂后，就会在 IGMP 路由表中加⼊该组播组，后续⽹络中⼀旦该组播地址的数据到达路由器，它会把数据包转发出去。离开组播组⼯作机制
● 主机 1 要离开组 224.1.1.1，发送 IGMPv2 离组报⽂，报⽂的⽬的地址是 224.0.0.2（表示发向⽹段内的所有路由器）
● 路由器 收到该报⽂后，以 1 秒为间隔连续发送 IGMP 特定组查询报⽂（共计发送 2 个），以便确认该⽹络是否还有 224.1.1.1 组的其他成员。
● 主机 3 仍然是组 224.1.1.1 的成员，因此它⽴即响应这个特定组查询。路由器知道该⽹络中仍然存在该组播组的成员，于是继续向该⽹络转发 224.1.1.1 的组播数据包。否则不会再向这个⽹段转发该组播地址的数据包。