>完整计网总结：[三万字计网知识点梳理](https://blog.csdn.net/qq_37205708/article/details/94126978) # 计算机网络分层次的体系结构 [TOC]  | 层次 | 功能 | 常见协议/标准 | 协议数据单元（PDU） | | --- | --- |--- | --- | | 应用层 | 为应用软件提供接口，使应用程序能够使用网络服务 | http(80)、ftp(20连接、21传输数据)、smtp(25)、telnet(23)、dns(53) | message（报文）) | | 表示层 | 负责数据的解码和编码、加密和解密、压缩和解压缩 | 常见标准如 ASCII JPEG | message| | 会话层 | 负责建立、管理和终止表示层实体之间的会话连接，在系统之间协调通信过程 | 提供 3 种通信方式：单工、半双工、全双工 | message | | 运输层 | 负责建立端到端的连接，保证报文在端到端之间的传输 | TCP/UDP | segment（数据段）| | 网络层 | 将分组从源端传送到目的端，提供网络互联（路由选择） | IP、ARP、ICMP、RIP、OSPF | packet（数据包） | | 数据链路层 | 将分组数据封装成帧，提供节点到节点的传输方式 | PPP、CSMA/CD | frame（帧） | | 物理层 | 在媒体上传输比特，提供机械的和电气的归约 | \ | bit（比特） | 关于 TCP/IP 四层模型的网际层和网络接口层的解释： - **网际层** 对应 OSI 参考模型的 **网络层**，主要解决主机到主机的通信问题 - **网络接口层** 对应 OSI 参考模型的 **物理层** 和 **数据链路层**，负责监视数据在主机和网络之间的交换 # 域名解析过程 一、主机向本地域名服务器的查询一般都采用 **递归查询（recursive query）**，递归查询返回的查询结果或者是所要查询的 IP 地址，或者是报错，表示无法查询到所需的 IP 地址 二、本地域名服务器向根域名服务器的查询通常是采用 **迭代查询（iterative query）**，迭代查询的结果要么是所要查询的 IP 地址，要么是下一个要查询的域名服务器的 IP 地址  域名服务器的分类  - 根域名服务器（root name server）：最高层次的域名服务器，所有的根域名服务器都知道 所有的顶级域名服务器的域名和 IP 地址 - 顶级域名服务器：负责管理在该顶级域名服务器注册的所有二级域名，当收到 DNS 查询请求时， 就给出相应的回答（可能是最后的结果，也可能是下一步应当找的域名服务器的 IP 地址） - 权限域名服务器：负责一个区的域名服务器，当一个权限域名服务器还不能给出最后的 查询回答时，就会告诉发出查询请求的 DNS 用户，下一步应当找哪一个权限域名服务器 - 本地域名服务器（local name server）：当一台主机发出 DNS 查询请求时，这个查询请求报文就发送给本地域名服务器，每一个互联网服务提供者 ISP，或一个大学，都可以拥有一个本地域名服务器 # TCP&UDP ## TCP&UDP概述 TCP（Transmission Control Protocol） 又叫传输控制协议。 TCP 协议是 **面向连接的，可靠的，基于字节流的传输协议**。在基于 TCP 进行通信时，通信双方需要先建立一个 TCP 连接，建立连接需要经过三次握手，断开连接的时候需要经过四次挥手。 UDP（User Datagram Protocol） 又叫用户数据报协议。 UDP 是一个 **无连接的、不可靠、基于数据报的传输协议**。UDP 只是报文的搬运工，不会对报文进行任何拆分和拼装操作。 | 应用 | 应用层协议 | 运输层协议 | | --- | --- | --- | | 名字转换 | DNS（域名系统） | UDP | | 文件传送 | TFTP（简单文件传送协议） | UDP | | 路由选择协议 | RIP（路由信息协议） | UDP | | IP 地址配置 | DHCP（动态主机配置协议） | UDP | | 网络管理 | SNMP（简单网络管理协议） | UDP | | 远程文件服务器 | NFS（网络文件系统） | UDP | | IP 电话 | 专用协议 | UDP | | 流式多媒体通信 | 专用协议 | UDP | | 多播 | IGMP（网际组管理协议） | UDP | | 电子邮件 | SMTP（简单邮件传送协议） | TCP | | 远程终端接入 | TELNET（远程终端协议） | TCP | | 万维网 | HTTP（超文本传送协议） | TCP | | 文件传送 | FTP（文件传送协议） | TCP | ## 三次握手与四次挥手 首先得明白 TCP 报文段首部格式  - 序号：4字节 \[0-2^32 – 1\] 序号增加到 2^32 – 1 后下一个序号又回到 0。TCP 是面向字节流的，在一个 TCP 连接中传送的字节流中的每一个字节都按顺序编号，整个要传送的字节流的起始序号必须在连接建立时设置。例如，一个 segment 的序号字段值是 301，而携带的数据共有 100 字节，那么最后一个字节的序号是 400 - 确认号：期望收到对方下一个 segment（报文段）的第一个数据字节的序号 若确认号 = N，则表明到序号 N – 1 为止的所有数据都已经正确收到 ### 三次握手  1.客户端发送 SYN 报文段请求建立连接；且初始化一个序号 seq = x 2.服务器收到连接请求报文段后，如果同意建立连接，则发送一个 SYN + ACK 报文段；且初始化一个序号 seq = y 3.客户端收到服务器的确认后，还需要向服务器发送一个 ACK 报文段，至此连接已经建立。 ### 四次挥手  请求断开连接的既可以是客户端也可以是服务器，这里假设使客户端请求断开连接 1.客户端发送一个标志位 FIN 为 1 的报文段 2.服务器收到后回一个 ACK，并检查是否还有数据需要传输 3.服务器没有数据需要传输了，则发送给客户端一个 FIN + ACK 报文段 4.客户端再回一个 ACK，经过 2MSL（最长报文段寿命）的等待后才会关闭连接，而服务器只要收到这个 ACK 就会马上关闭连接；如果未收到则有一个超时重传机制。 ## Questions <span style="font-size: 20px; font-family: 楷体; font-weight: bold;">1.为什么不能两次握手建立连接？</span> Answer：3 次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。        现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机 S 和 C 之间的通信，假定 C 给 S 发送一个连接请求分组，S 收到了这个分组，并发送了确认应答分组。按照两次握手的协定，S 认为连接已经成功地建立了，可以开始发送数据分组。可是，C 在 S 的应答分组在传输中被丢失的情况下，将不知道 S 是否已准备好，不知道 S 建立什么样的序列号，C 甚至怀疑 S 是否收到自己的连接请求分组。在这种情况下，C 认为连接还未建立成功，将忽略 S 发来的任何数据分组，只等待连接确认应答分组。而 S 在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。 <span style="font-size: 20px;font-family: 楷体; font-weight: bold;">2.为什么建立连接的时候是三次握手，而关闭连接是四次？</span> Answer：因为当 Server 端收到 Client 端的 SYN 连接请求报文后，可以直接发送 SYN+ACK 报文。其中 ACK 报文是用来应答的，SYN 报文是用来同步的。但是关闭连接时，当 Server 端收到 FIN 报文时，很可能并不会立即关闭 SOCKET，所以只能先回复一个 ACK 报文，告诉 Client 端，"你发的 FIN 报文我收到了"。只有等到我 Server 端所有的报文都发送完了，我才能发送 FIN 报文，因此不能一起发送。故需要四步挥手。 <span style="font-size: 20px;font-family: 楷体; font-weight: bold;">3.关闭连接时为什么要等待 2MSL？</span> Answer：保证 A 发送的最后一个 ACK 报文段能够到达 B。 这个 ACK 报文段有可能丢失，从而使处在 LAST-ACK 状态的 B 收不到对已发送的 FIN+ACK 报文段的确认。B 会超时重传这个 FIN+ACK 报文段，而 A 就能在 2MSL 时间内收到这个重传的 FIN+ACK 报文段。接着 A 重传一次确认，重新启动 2MSL 计时器。直到 A 和 B 都正常进入 CLOSED 状态。 如果没有 TIME-WAIT 状态，B 收不到确认就无法按正常步骤进入 CLOSED 状态。 <span style="font-size: 20px;font-family: 楷体; font-weight: bold;">4.如果已经建立了连接，但是客户端出现了故障怎么办？</span> Answer：除了等待计时器外，TCP 还设有一个保活计时器（keepalive timer）。设想有这样的情况：客户已主动与服务器建立了 TCP 连接，但后来客户端的主机突然出现故障。显然，服务器之后就不能再收到客户发来的数据。因此就需要措施使服务器不白等。 服务器每收到一次客户的数据，就重置保活计时器，时间的设置一般是两小时。若两小时没有收到客户的数据，服务器就发送一个探测报文段，以后每隔 75 秒发送一次，若一连发送 10 个探测报文段后仍无客户的响应，服务器就认为客户端出现了故障，接着就关闭这个连接。 ## TCP 拥塞控制 拥塞控制是防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载，是一个全局性的过程。 TCP 进行拥塞控制的算法有四种：慢开始（slow-start）、拥塞避免（congestion avoidance）、快重传（fast retransmit）、快恢复（fast recovery）。  cwnd（congestion window）：发送方维持一个叫做拥塞窗口的状态变量，拥塞窗口的大小取决于网络的拥塞程度，并且动态变化，发送方让自己的发送窗口等于拥塞窗口。 <br /> 1、慢开始：为了防止拥塞窗口 cwnd 的增长引起网络阻塞，还需要另外一个变量—慢开始门限 ssthresh. i.当 cwnd < ssthresh 时，使用上述慢开始算法； ii.当 cwnd > ssthresh 时，停止使用慢开始算法，改用拥塞避免算法； iii.当 cwnd = ssthresh 时，既可使用慢开始算法，也可使用拥塞避免算法 慢开始的 “慢” 并不是指 cwnd 的增长速率慢，而是指在 TCP 开始发送报文段时先设置 cwnd = 1， 试探一下网络，然后再逐渐增大 cwnd（每轮加倍） <br /> 2、拥塞避免：思路是使 cwnd 缓慢地增大，每经过一个往返时间 RTT 就把发送方的 cwnd 加 1，因此有 “加法增大” 的特点。 <br /> 3、快重传：快重传可以让发送方尽早知道发生了个别报文段的丢失  快重传算法要求接收方立即发送确认，而不是等自己发送数据时才捎带确认（注意理解这句话）。 即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认。 比如图中确认了 M1 和 M2 后，M3 没有收到却收到了 M4，按照快重传算法，接收方必须立即发送对 M2 的重复确认，以便让发送方及早知道接收方没有收到报文段 M3。发送方接着发送 M5 和 M6，接收方收到后仍然要分别发出对 M2 的重复确认。这样，发送方共收到了接收方的 4 个对 M2 的确认，其中后 3 个都是重复确认。快重传算法规定，发送方只要一连收到 3 个重复确认，就应当立即重传（即“快重传”），这样就不会出现超时，发送方也不就不会误认为出现了网络拥塞。 <br /> 4、快恢复：Reno 版本 当发送发连续接收到三个重复确认时，就执行 “乘法减小” 算法，把慢启动开始门限（ssthresh）和 cwnd 减半，然后执行拥塞避免算法，使拥塞窗口缓慢增大。 # HTTP ## 状态码 **1XX 信息，服务器收到请求，需要请求者继续执行操作** - 100 Continue，客户端应继续其请求 - 101 Switching Protocols， 服务器根据客户端的请求切换协议。只能切换到更高级的协议，例如，切换到 HTTP 的新版本协议 **2XX 成功，操作被成功接收并处理** * 200 OK，表示从客户端发来的请求在服务器端被正确处理 * 204 No content，表示请求成功，但响应报文不含实体的主体部分 * 205 Reset Content，表示请求成功，但响应报文不含实体的主体部分，但是与 204 响应不同在于要求请求方重置内容 * 206 Partial Content，进行范围请求 **3XX 重定向，需要进一步的操作以完成请求** * 301 moved permanently，永久性重定向，表示资源已被分配了新的 URL * 302 found，临时性重定向，表示资源临时被分配了新的 URL * 303 see other，表示资源存在着另一个 URL，应使用 GET 方法获取资源 * 304 not modified，所请求的资源未修改，可在缓存中读取 * 307 temporary redirect，临时重定向，和 302 含义类似，但是期望客户端保持请求方法不变向新的地址发出请求 **4XX 客户端错误，请求包含语法错误或无法完成请求** * 400 bad request，请求报文存在语法错误 * 401 unauthorized，表示发送的请求需要有通过 HTTP 认证的认证信息 * 403 forbidden，表示对请求资源的访问被服务器拒绝 * 404 not found，表示在服务器上没有找到请求的资源 **5XX 服务器错误，服务器在处理请求的过程中发生了错误** * 500 internal sever error，表示服务器端在执行请求时发生了错误 * 501 Not Implemented，表示服务器不支持当前请求所需要的某个功能 * 503 service unavailable，表明服务器暂时处于超负载或正在停机维护，无法处理请求 ## HTTP/1.1 与 HTTP/1.0 的区别 1. **缓存处理**，在 HTTP1.0 中主要使用 header 里的 If-Modified-Since,Expires 来做为缓存判断的标准，HTTP1.1 则引入了更多的缓存控制策略例如 Entity tag，If-Unmodified-Since, If-Match, If-None-Match 等更多可供选择的缓存头来控制缓存策略。 2. **带宽优化及网络连接的使用**，HTTP1.0 中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能， HTTP1.1 则在请求头引入了 range 头域，它允许只请求资源的某个部分，即返回码是 206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。 3. **错误通知的管理**，在 HTTP1.1 中新增了 24 个错误状态响应码，如 409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。 4. **Host 头处理**，在 HTTP1.0 中认为每台服务器都绑定一个唯一的 IP 地址，因此，请求消息中的 URL 并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个 IP 地址。HTTP1.1 的请求消息和响应消息都应支持 Host 头域，且请求消息中如果没有 Host 头域会报告一个错误（400 Bad Request）。 5. **长连接**，HTTP 1.1 支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理，在一个 TCP 连接上可以传送多个 HTTP 请求和响应，减少了建立和关闭连接的消耗和延迟，在 HTTP1.1 中默认开启 Connection： keep-alive，一定程度上弥补了 HTTP1.0 每次请求都要创建连接的缺点。 >网上的资料说各浏览器厂商一般都不会开启 Pipelining，因为这项技术本身存在一些缺陷，比如队头阻塞。 ## HTTP2.0 [参考链接](https://github.com/InterviewMap/CS-Interview-Knowledge-Map/blob/master/Network/Network-zh.md) 在 HTTP 1.X 中，为了性能考虑，我们会引入雪碧图、将小图内联、使用多个域名等等的方式。这一切都是因为浏览器限制了同一个域名下的请求数量，当页面中需要请求很多资源的时候，**队头阻塞（Head of line blocking）** 会导致在达到最大请求数量时，剩余的资源需要等待其他资源请求完成后才能发起请求 我们来梳理下 HTTP 请求的几种方式  * 图中第一种请求方式，就是单次发送 request 请求，收到 response 后再进行下一次请求，显示是很低效的。 * 于是 HTTP/1.1 提出了<span style="font-family:楷体;font-weight: 700;">管线化技术（pipelining）</span>，就是如图中第二中请求方式，一次性发送多个 request 请求。 * 然而 pipelining 在接收 response 返回时，也必须依顺序接收，如果前一个请求遇到了阻塞，后面的请求即使已经处理完毕了，仍然需要等待阻塞的请求处理完毕。这种情况就如图中第三种，第一个请求阻塞后，后面的请求都需要等待，这也就是 <span style="font-family:楷体;font-weight: 700;">队头阻塞(Head of line blocking)</span> * 为了解决上述阻塞问题，HTTP/2.0 中提出了 <span style="font-family:楷体;font-weight: 700;">多路复用（Multiplexing）</span>技术，使得多个 HTTP 请求可以复用同一个 TCP 连接。其原理大致如下：将一个 TCP 连接分为若干个流（Stream），每个流中可以传输若干消息（Message），每个消息由若干最小的二进制帧（Frame）组成。也就是将每个 request-response 拆分为了细小的二进制帧 Frame，这样即使一个请求被阻塞了，也不会影响其他请求，如图中第四种情况所示。 ## 二进制传输 HTTP 2.0 中所有加强性能的核心点在于此。在之前的 HTTP 版本中，我们是通过文本的方式传输数据。在 HTTP 2.0 中引入了新的编码机制，所有传输的数据都会被分割，并采用二进制格式编码。  ## 多路复用（Multiplexing） 在 HTTP 2.0 中，有两个非常重要的概念，分别是帧（frame）和流（stream）。 帧代表着最小的数据单位，每个帧会标识出该帧属于哪个流，流也就是多个帧组成的数据流。 多路复用，就是在一个 TCP 连接中可以存在多条流。换句话说，也就是可以发送多个请求，对端可以通过帧中的标识知道属于哪个请求。通过这个技术，可以避免 HTTP 旧版本中的队头阻塞问题，极大地提高传输性能。  ## Header 压缩（Header Compression） 在 HTTP 1.X 中，我们使用文本的形式传输 header，在 header 携带 cookie 的情况下，可能每次都需要重复传输几百到几千的字节。 在 HTTP 2.0 中，使用了 HPACK 压缩格式对传输的 header 进行编码，减少了 header 的大小。并在两端维护了索引表，用于记录出现过的 header ，后面在传输过程中就可以传输已经记录过的 header 的键名，对端收到数据后就可以通过键名找到对应的值。 ## 服务端 Push（Server Push） 在 HTTP 2.0 中，服务端可以在客户端某个请求后，主动推送其他资源。 可以想象以下情况，某些资源客户端是一定会请求的，这时就可以采取服务端 push 的技术，提前给客户端推送必要的资源，这样就可以相对减少一点延迟时间。当然在浏览器兼容的情况下你也可以使用 prefetch 。 # HTTPS http 默认采用 80 作为通讯端口，对于传输采用不加密的方式，https 默认采用 443，对于传输的数据进行加密传输。 ## 密码学基础 **明文**：明文指的是未被加密过的原始数据。 **密文**：明文被某种加密算法加密之后，会变成密文，从而确保原始数据的安全。密文也可以被解密，得到原始的明文。 **密钥**：密钥是一种参数，它是在明文转换为密文或将密文转换为明文的算法中输入的参数。密钥分为对称密钥与非对称密钥，分别应用在对称加密和非对称加密上。 ## 对称加密 对称加密又叫做私钥加密，即信息的发送方和接收方使用同一个密钥去加密和解密数据。对称加密的特点是算法公开、加密和解密速度快，适合于对大数据量进行加密。 其加密过程如下：**明文 + 加密算法 + 私钥 => 密文** 解密过程如下：**密文 + 解密算法 + 私钥 => 明文** 对称加密中用到的密钥叫做私钥，私钥表示个人私有的密钥，即该密钥不能被泄露。 其加密过程中的私钥与解密过程中用到的私钥是同一个密钥，这也是称加密之所以称之为“对称”的原因。由于对称加密的算法是公开的，所以一旦私钥被泄露，那么密文就很容易被破解，所以对称加密的缺点是密钥安全管理困难。 ## 非对称加密 非对称加密也叫做公钥加密。非对称加密与对称加密相比，其安全性更好。对称加密的通信双方使用相同的密钥，如果一方的密钥遭泄露，那么整个通信就会被破解。而非对称加密使用一对密钥，即公钥和私钥，且二者成对出现。私钥被自己保存，不能对外泄露。公钥指的是公共的密钥，任何人都可以获得该密钥。用公钥或私钥中的任何一个进行加密，用另一个进行解密。 被公钥加密过的密文只能被私钥解密，过程如下： **明文 + 加密算法 + 公钥 => 密文， 密文 + 解密算法 + 私钥 => 明文** 被私钥加密过的密文只能被公钥解密，过程如下： **明文 + 加密算法 + 私钥 => 密文， 密文 + 解密算法 + 公钥 => 明文** 由于加密和解密使用了两个不同的密钥，这就是非对称加密“非对称”的原因。 非对称加密的缺点是加密和解密花费时间长、速度慢，只适合对少量数据进行加密。 在非对称加密中使用的主要算法有：RSA、Elgamal、Rabin、D-H、ECC（椭圆曲线加密算法）等。 ## HTTPS 通信过程 HTTPS 协议 = HTTP 协议 + SSL/TLS 协议，在 HTTPS 数据传输的过程中，需要用 SSL/TLS 对数据进行加密和解密，需要用 HTTP 对加密后的数据进行传输，由此可以看出 HTTPS 是由 HTTP 和 SSL/TLS 一起合作完成的。 >TLS（Transport Layer Security，安全传输层协议）可以认为就是 SSL（Secure Socket Layer，安全套阶层）的标准化后的名称，在传输层提供对网络连接加密的功能 主要是它们所支持的加密算法不同，所以 TLS 与 SSL3.0 不能互操作。虽然 TLS 与 SSL3.0 在加密算法上不同，但是在我们理解 HTTPS 的过程中，我们可以把 SSL 和 TLS 看做是同一个协议。 **HTTPS 为了兼顾安全与效率，同时使用了对称加密和非对称加密**。数据是被对称加密传输的，对称加密过程需要客户端的一个密钥，为了确保能把该密钥安全传输到服务器端，采用非对称加密对该密钥进行加密传输，总的来说，**对数据进行对称加密，对称加密所要使用的密钥通过非对称加密传输**  HTTPS在传输的过程中会涉及到三个密钥： - 服务器端的公钥和私钥，用来进行非对称加密 - 客户端生成的随机密钥，用来进行对称加密 一个 HTTPS 请求实际上包含了两次 HTTP 传输，可以细分为 8 步。 1. 客户端向服务器发起 HTTPS 请求，连接到服务器的 443 端口 2. 服务器端有一个密钥对，即公钥和私钥，是用来进行非对称加密使用的，服务器端保存着私钥，不能将其泄露，公钥可以发送给任何人。 3. 服务器将自己的公钥发送给客户端。 4. 客户端收到服务器端的公钥之后，会对公钥进行检查，验证其合法性，如果发现发现公钥有问题，那么 HTTPS 传输就无法继续。严格的说，这里应该是验证服务器发送的数字证书的合法性。如果公钥合格，那么客户端会生成一个随机值，这个随机值就是用于进行对称加密的密钥，我们将该密钥称之为 client key，即客户端密钥，这样在概念上和服务器端的密钥容易进行区分。然后用服务器的公钥对客户端密钥进行非对称加密，这样客户端密钥就变成密文了，至此，HTTPS 中的第一次 HTTP 请求结束。 5. 客户端会发起 HTTPS 中的第二个 HTTP 请求，将加密之后的客户端密钥发送给服务器。 6. 服务器接收到客户端发来的密文之后，会用自己的私钥对其进行非对称解密，解密之后的明文就是客户端密钥，然后用客户端密钥对数据进行对称加密，这样数据就变成了密文。 7. 然后服务器将加密后的密文发送给客户端。 8. 客户端收到服务器发送来的密文，用客户端密钥对其进行对称解密，得到服务器发送的数据。这样 HTTPS 中的第二个 HTTP 请求结束，整个 HTTPS 传输完成。 ## SSL 协议的不足 1. 因为 SSL 协议设计初衷是对 Web 站点及网上交易进行安全性保护，使消费者明白正在和谁进行交易要比使商家知道谁正在付费更为重要，为了不致于由于安全协议的使用而导致网络性能大幅下降， SSL 协议并不是默认地要求进行客户鉴别，这样做虽然有悖于安全策略，但却促进了 SSL 的广泛应用。 2. 针对这个问题，可在必要的时候配置 SSL 协议，使其选择对客户端进行认证鉴别。 3. SSL 协议需要在握手之前建立 TCP 连接，因此不能对 UDP 应用进行保护。如果要兼顾 UDP 协议层之上的安全保护，可以采用 IP 层的安全解决方案。 4. 由于 SSL 只对应用数据进行保护，数据包的 IP 头和 TCP 头仍然暴露在外，通过检查没有加密的 IP 源和目的地址以及 TCP 端口号或者检查通信数据量，一个通信分析者依然可以揭示哪一方在使用什么服务，有时甚至揭露商业或私人关系的秘密。 5. 除非 SSL 的工程实现大部分驻留在硬件中，否则主密钥将会存留在主机的主存储器中，这就意味着任何可以读取 SSL 进程存储空间的攻击者都能读取主密钥，因此，不可能面对掌握机器管理特权的攻击者而保护 SSL 连接，这个问题要依靠用户管理策略来解决。 # CDN 工作原理浅析 [参考链接1](https://blog.csdn.net/coolmeme/article/details/9468743) [参考链接2](https://www.jianshu.com/p/1dae6e1680ff)  使用了 CDN 缓存的网站的访问流程如下： 1.用户向浏览器输入 `www.web.com` 这个域名，浏览器第一次发现本地没有 dns 缓存，则向网站的 DNS 服务器请求； 2.网站的 DNS 域名解析器设置了 CNAME，指向了 `www.web.51cdn.com`，请求指向了 CDN 网络中的智能 DNS 负载均衡系统； 3.智能 DNS 负载均衡系统解析域名，把对用户响应速度最快的 IP 节点返回给用户； 4.用户向该 IP 节点（CDN 服务器）发出请求； 5.由于是第一次访问，CDN 服务器会向原 web 站点请求，并缓存内容； 6.请求结果发给用户。 CDN 网络是在用户和服务器之间增加 Cache 层，如何将用户的请求引导到 Cache 上获得源服务器的数据，主要是通过接管 DNS 实现，这就是 CDN 的最基本的原理。 <br> 每个 CDN 节点由两部分组成:**负载均衡设备** 和 **高速缓存服务器** 负载均衡设备负责每个节点中各个 Cache 的负载均衡，保证节点的工作效率;同时，负载均衡设备还负责收集节点与周围环境的信息，保持与全局负载 DNS 的通信，实现整个系统的负载均衡。 <br> CDN 的管理系统是整个系统能够正常运转的保证。它不仅能对系统中的各个子系统和设备进行实时监控，对各种故障产生相应的告警，还可以实时监测到系统中总的流量和各节点的流量，并保存在系统的数据库中，使网管人员能够方便地进行进一步分析。通过完善的网管系统，用户可以对系统配置进行修改。 <br> 理论上，最简单的 CDN 网络有一个负责全局负载均衡的 DNS 和各节点一台 Cache，即可运行。DNS 支持根据用户源 IP 地址解析不同的 IP，实现就近访问。为了保证高可用性等，需要监视各节点的流量、健康状况等。一个节点的单台 Cache 承载数量不够时，才需要多台 Cache，多台 Cache 同时 工作，才需要负载均衡器，使 Cache 群协同工作。 >CDN 的就近策略是如何实现的？也许跟路由选择算法有关，这就好像单源最短路径问题，求各 CDN 节点到客户端的最短距离 CDN 服务商在全国各个省份部署计算节点，CDN 加速将网站的内容缓存在网络边缘,不同地区的用户就会访问到离自己最近的相同网络线路上的 CDN 节点，当请求达到 CDN 节点后，节点会判断自己的内容缓存是否有效，如果有效，则立即响应缓存内容给用户，从而加快响应速度。如果 CDN 节点的缓存失效，它会根据服务配置去我们的内容源服务器获取最新的资源响应给用户，并将内容缓存下来以便响应给后续访问的用户。**因此，一个地区内只要有一个用户先加载资源，在 CDN 中建立了缓存，该地区的其他后续用户都能因此而受益**。