计算机网络：应用层

发表于 分类于
HTTP协议

image.png

HTTP、HTTPS、CDN、DNS、FTP 都是应用层协议

协议 网络应用 应用层协议 支撑的运输协议 描述 应用程序体系结构 端口号
HTTP Web 超文本传输协议(HyperText Transfer Protocol, HTTP) TCP 无状态协议
Web文档的请求与响应		 客户-服务器 Web服务器：80
SMTP 电子邮件 简单邮件传输协议(Simple Mail Transfer Protocol, SMTP)
邮件访问协议：POP3		 TCP 电子邮件报文的传输 SMTP：客户-服务器 SMTP：25
POP：110
DNS 因特网的目录服务 域名系统(Domain Name System，DNS) UDP 域名空间、域名服务器、域名解析过程
主机名到IP地址转换的目录服务		 客户-服务器模型 53
FTP 文件传输 文件传输协议(FTP) TCP 客户-服务器模型 控制连接：21
数据连接：20
Telnet 远程登陆协议 Telnet TCP
SSH 安全的网路传输协议 22

1 HTTP协议

HTTP 是一种不保存状态，即无状态（stateless）协议。也就是说 HTTP 协议自身不对请求和响应之间的通信状态进行保存。服务器不维护任何有关客户端过去所发请求的消息。
HTTP 使用客户端-服务器模型，客户端向服务器发送 HTTP Request（请求），服务器响应请求并返回 HTTP Response（响应）

1.1 常用字段

  • Host字段：有了 Host 字段，就可以将请求发往「同一台」服务器上的不同网站。

  • Content-Length字段：请求正文的字节数

  • Connection：Keep-Alive（使用同一个 TCP 连接来发送和接收多个 HTTP 请求/应答，避免了连接建立和释放的开销，这个方法称为 HTTP 长连接。）

1.2 HTTP层请求类型

  • GET：用于请求获取指定资源，通常用于获取数据。

  • POST：用于向服务器提交数据，通常用于提交表单数据或进行资源的创建。

  • PUT：用于向服务器更新指定资源，通常用于更新已存在的资源。

  • DELETE：用于请求服务器删除指定资源。

  • HEAD：类似于GET请求，但只返回资源的头部信息，用于获取资源的元数据而不获取实际内容。

1.3 HTTP缓存技术

  • 强制缓存

  • 协商缓存
    image.png

1.4 HTTP/1.1、HTTP/2、HTTP/3

image.png

1.4.1 HTTP/1.1

HTTP/1.1 是请求响应模型，如果第一个发送的请求，未收到对应的响应，那么后续的请求就不会发送（PS：HTTP/1.1 管道模式是默认不使用的，所以讨论 HTTP/1.1 的队头阻塞问题，是不考虑管道模式的）

  • HTTP/1.1 中的管道（ pipeline）虽然解决了请求的队头阻塞，但是没有解决响应的队头阻塞，因为服务端需要按顺序响应收到的请求，如果服务端处理某个请求消耗的时间比较长，那么只能等响应完这个请求后， 才能处理下一个请求，这属于 HTTP 层队头阻塞。

  • HTTP/2 虽然通过多个请求复用一个 TCP 连接解决了 HTTP 的队头阻塞 ，但是一旦发生丢包，就会阻塞住所有的 HTTP 请求，这属于 TCP 层队头阻塞。

1.5 HTTP/1.0 和 HTTP/1.1 有什么区别？

  • 连接方式 : HTTP/1.0 为短连接，HTTP/1.1 支持长连接。HTTP 协议的长连接和短连接，实质上是 TCP 协议的长连接和短连接。

  • 状态响应码 : HTTP/1.1 中新加入了大量的状态码，光是错误响应状态码就新增了 24 种。比如说，100 (Continue)——在请求大资源前的预热请求，206 (Partial Content)——范围请求的标识码，409 (Conflict)——请求与当前资源的规定冲突，410 (Gone)——资源已被永久转移，而且没有任何已知的转发地址。

  • 缓存机制 : 在 HTTP/1.0 中主要使用 Header 里的 If-Modified-Since,Expires 来做为缓存判断的标准，HTTP/1.1 则引入了更多的缓存控制策略例如 Entity tag，If-Unmodified-Since, If-Match, If-None-Match 等更多可供选择的缓存头来控制缓存策略。

  • 带宽：范围请求，HTTP/1.0 中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP/1.1 则在请求头引入了range 头域，它允许只请求资源的某个部分，即返回码是 206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。

  • Host 头（Host Header）处理 :HTTP/1.1 引入了 Host 头字段，允许在同一 IP 地址上托管多个域名，从而支持虚拟主机的功能。而 HTTP/1.0 没有 Host 头字段，无法实现虚拟主机。

  • 管道网路传输：HTTP/1.0串行请求，HTTP/1.1在同一个 TCP 连接里面，客户端可以发起多个请求，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。

[!note]
服务器必须按照接收请求的顺序发送对这些管道化请求的响应，如果服务端在处理 A 请求时耗时比较长，那么后续的请求的处理都会被阻塞住，这称为==「队头堵塞」==。所以，HTTP/1.1 管道解决了请求的队头阻塞，但是没有解决响应的队头阻塞。

[!note] Host头处理

域名系统（DNS）允许多个主机名绑定到同一个 IP 地址上，但是 HTTP/1.0 并没有考虑这个问题，假设我们有一个资源 URL 是http://example1.org/home.html，HTTP/1.0的请求报文中，将会请求的是GET /home.html HTTP/1.0.也就是不会加入主机名。这样的报文送到服务器端，服务器是理解不了客户端想请求的真正网址。

因此，HTTP/1.1 在请求头中加入了Host字段。加入Host字段的报文头部将会是:

GET /home.html HTTP/1.1
Host: example1.org

这样，服务器端就可以确定客户端想要请求的真正的网址了。

1.6 HTTP/1.1 和 HTTP/2.0 有什么区别？

  • 多路复用（Multiplexing）：HTTP/2.0 在同一连接上可以同时传输多个请求和响应（可以看作是 HTTP/1.1 中长链接的升级版本），互不干扰。HTTP/1.1 则使用串行方式，每个请求和响应都需要独立的连接，而浏览器为了控制资源会有 6-8 个 TCP 连接都限制。这使得 HTTP/2.0 在处理多个请求时更加高效，减少了网络延迟和提高了性能。HTTP/2.0 的多路复用使得不同的请求可以共用一个 TCP 连接，避免建立多个连接带来不必要的额外开销，而 HTTP/1.1 中的每个请求都会建立一个单独的连接

  • 二进制帧（Binary Frames）：HTTP/2.0 使用二进制帧进行数据传输，而 HTTP/1.1 则使用文本格式的报文。二进制帧更加紧凑和高效，减少了传输的数据量和带宽消耗。

  • 头部压缩（Header Compression）：HTTP/1.1 支持Body压缩，Header不支持压缩。HTTP/2.0 支持对Header压缩，使用了专门为Header压缩而设计的 HPACK 算法，减少了网络开销。

  • 服务器推送（Server Push）：HTTP/2.0 支持服务器推送，可以在客户端请求一个资源时，将其他相关资源一并推送给客户端，从而减少了客户端的请求次数和延迟。而 HTTP/1.1 需要客户端自己发送请求来获取相关资源。

1.7 HTTP/2.0 和 HTTP/3.0 有什么区别？

  • 传输协议：HTTP/2.0 是基于 TCP 协议实现的，HTTP/3.0 新增了 QUIC（Quick UDP Internet Connections） 协议来实现可靠的传输，提供与 TLS/SSL 相当的安全性，具有较低的连接和传输延迟。你可以将 QUIC 看作是 UDP 的升级版本，在其基础上新增了很多功能比如加密、重传等等。HTTP/3.0 之前名为 HTTP-over-QUIC，从这个名字中我们也可以发现，HTTP/3 最大的改造就是使用了 QUIC。

  • 连接建立：HTTP/2.0 需要经过经典的 TCP 三次握手过程（由于安全的 HTTPS 连接建立还需要 TLS 握手，共需要大约 3 个 RTT）。由于 QUIC 协议的特性（TLS 1.3，TLS 1.3 除了支持 1 个 RTT 的握手，还支持 0 个 RTT 的握手）连接建立仅需 0-RTT 或者 1-RTT。这意味着 QUIC 在最佳情况下不需要任何的额外往返时间就可以建立新连接。

  • 队头阻塞：HTTP/2.0 多请求复用一个 TCP 连接，一旦发生丢包，就会阻塞住所有的 HTTP 请求。由于 QUIC 协议的特性，HTTP/3.0 在一定程度上解决了==队头阻塞（Head-of-Line blocking, 简写：HOL blocking）==问题，一个连接建立多个不同的数据流，这些数据流之间独立互不影响，某个数据流发生丢包了，其数据流不受影响（本质上是多路复用+轮询）。

  • 错误恢复：HTTP/3.0 具有更好的错误恢复机制，当出现丢包、延迟等网络问题时，可以更快地进行恢复和重传。而 HTTP/2.0 则需要依赖于 TCP 的错误恢复机制。

  • 安全性：HTTP/2.0 和 HTTP/3.0 在安全性上都有较高的要求，支持加密通信，但在实现上有所不同。HTTP/2.0 使用 TLS 协议进行加密，而 HTTP/3.0 基于 QUIC 协议，包含了内置的加密和身份验证机制，可以提供更强的安全性。

[! Note] 队头阻塞

  • HTTP/1.1 中的管道（ pipeline）虽然解决了请求的队头阻塞，但是没有解决响应的队头阻塞，因为服务端需要按顺序响应收到的请求，如果服务端处理某个请求消耗的时间比较长，那么只能等响应完这个请求后， 才能处理下一个请求，这属于 HTTP 层队头阻塞。

  • HTTP/2 虽然通过多个请求复用一个 TCP 连接解决了 HTTP 的队头阻塞 ，但是一旦发生丢包，就会阻塞住所有的 HTTP 请求，这属于 TCP 层队头阻塞。

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

1.8 队头阻塞

队头阻塞是指在 HTTP/2.0 中，多个 HTTP 请求和响应共享一个 TCP 连接，如果其中一个请求或响应因为网络拥塞或丢包而被阻塞，那么后续的请求或响应也无法发送，导致整个连接的效率降低。这是由于 HTTP/2.0 在单个 TCP 连接上使用了多路复用，受到 TCP 拥塞控制的影响，少量的丢包就可能导致整个 TCP 连接上的所有流被阻塞。HTTP/3.0 在一定程度上解决了队头阻塞问题，一个连接建立多个不同的数据流，这些数据流之间独立互不影响，某个数据流发生丢包了，其数据流不受影响（本质上是多路复用+轮询）。

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

1.9 Cookie和Session

HTTP协议是无状态的，而登录、购物车等需要知道用户状态。

cookie： cookie是服务器传给客户端并保存在客户端的一段信息。cookie保存在了客户端，当我们去请求一个URL时，浏览器会根据这个URL路径将符合条件的Cookie放在请求头中传给服务器。

session：Session是基于Cookie来工作，同一个客户端每次访问服务器时，只要当浏览器在第一次访问服务器时，服务器设置一个id并保存一些信息(例如登陆就保存用户信息，视具体情况)，并把这个id通过Cookie存到客户端，客户端每次和服务器交互时只传这个id，就可以实现维持浏览器和服务器的状态，而这个ID通常是NAME为sessionID的一个Cookie。

Session 的主要作用就是通过服务端记录用户的状态。典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了（一般情况下，服务器会在一定时间内保存这个 Session，过了时间限制，就会销毁这个 Session）。

Cookie 数据保存在客户端(浏览器端)，Session 数据保存在服务器端。相对来说 Session 安全性更高。如果使用 Cookie 的一些敏感信息不要写入 Cookie 中，最好能将 Cookie 信息加密然后使用到的时候再去服务器端解密。

在服务端保存 Session 的方法很多，最常用的就是内存和数据库(比如是使用内存数据库 redis 保存)。既然 Session 存放在服务器端，那么我们如何实现 Session 跟踪呢？大部分情况下，我们都是通过在 Cookie 中附加一个 Session ID 来方式来跟踪。

[!note] Cookie用途

  • 会话状态管理（如用户登录状态、购物车、游戏分数或其它需要记录的信息）
  • 个性化设置（如用户自定义设置、主题等）
  • 浏览器行为跟踪（如跟踪分析用户行为等）

[!question] 主要区别

  1. 存储位置：

  • Cookie的数据存储在客户端的浏览器中

  • Session的数据则存放在服务器上

  1. 存储容量与类型：

  • Cookie的存储容量相对较小，通常限制在4KB以内，并且只能存储字符串类型的数据。

  • Session的存储容量没有明确的限制（但考虑到服务器性能，通常不建议存放过多数据），并且它可以存储任意类型的数据。

  1. 有效期与生命周期：

  • Cookie的有效期可以在设置时指定，只要不超过设置的过期时间，它可以长期保存在客户端。

  • Session的生命周期则通常较短，它会在一定的操作时间（如30分钟）后失效，并且在用户关闭浏览器或会话结束时，Session数据会被清除。

  1. 安全性：

  • 由于Cookie存储在客户端，存在被第三方截获或篡改的风险，因此安全性相对较低。攻击者可以通过分析或伪造Cookie来欺骗系统。

  • Session数据存储在服务器上，相对更加安全，不容易被攻击者直接获取或修改。

  1. 跨域支持：

  • Cookie支持跨域名访问，即可以在不同的域名之间共享。

  • Session则通常与特定的客户端和服务器端关联，不支持跨域访问。

  1. 对服务器压力：

  • Cookie不占用服务器资源，因为数据存储在客户端。

  • Session则需要在服务器上存储数据，因此对服务器的资源占用和性能有一定影响。

一文彻底搞懂cookie和session - 知乎 (zhihu.com)
一文彻底搞清session、cookie、token的区别

1.9.1 session共享

  1. 数据库存储：

    • 将session数据存储在数据库中，而不是仅仅存储在内存中。这样，无论请求发送到哪个服务器，都可以通过查询数据库来获取session数据。
    • 这种方法需要设计好数据库表结构，并编写相应的存储和检索逻辑。

  2. 缓存系统：

    • 使用像Redis或Memcached这样的缓存系统来存储session数据。每个服务器都可以访问这个共享的缓存系统来获取和更新session数据。
    • 这种方法通常比数据库访问更快，并且能更好地处理大量并发请求。

1.10 SQL注入攻击

攻击者在HTTP请求中注入恶意的SQL代码，服务器使用参数构建数据库SQL命令时，恶意SQL被一起构造，并在数据库中执行。 用户登录，输入用户名 lianggzone，密码 ‘ or ‘1’=’1 ，如果此时使用参数构造的方式，就会出现 select * from user where name = ‘lianggzone’ and password = ‘’ or ‘1’=‘1’ 不管用户名和密码是什么内容，使查询出来的用户列表不为空。

如何防范SQL注入攻击使用预编译的PrepareStatement是必须的，但是一般我们会从两个方面同时入手。
Web端 1）有效性检验。 2）限制字符串输入的长度。服务端 1）不用拼接SQL字符串。 2）使用预编译的PrepareStatement。 3）有效性检验。(为什么服务端还要做有效性检验？第一准则，外部都是不可信的，防止攻击者绕过Web端请求) 4）过滤SQL需要的参数中的特殊字符。比如单引号、双引号。

1.11 get和post

  • 语义（主要区别）：GET 通常用于获取或查询资源，而 POST 通常用于创建或修改资源。

  • 幂等：GET 请求是幂等的，即多次重复执行不会改变资源的状态，而 POST 请求是不幂等的，即每次执行可能会产生不同的结果或影响资源的状态。（可以对 GET 请求的数据做缓存，这个缓存可以做到浏览器本身上（彻底避免浏览器发请求），也可以做到代理上（如nginx），而且在浏览器中 GET 请求可以保存为书签。）

  • 格式：GET 请求的参数通常放在 URL 中，形成查询字符串（querystring），而 POST 请求的参数通常放在请求体（body）中，可以有多种编码格式，如 application/x-www-form-urlencoded、multipart/form-data、application/json 等。GET 请求的 URL 长度受到浏览器和服务器的限制，而 POST 请求的 body 大小则没有明确的限制。不过，实际上 GET 请求也可以用 body 传输数据，只是并不推荐这样做，因为这样可能会导致一些兼容性或者语义上的问题。

  • 缓存：由于 GET 请求是幂等的，它可以被浏览器或其他中间节点（如代理、网关）缓存起来，以提高性能和效率。而 POST 请求则不适合被缓存，因为它可能有副作用，每次执行可能需要实时的响应。

  • 安全性：GET 请求和 POST 请求如果使用 HTTP 协议的话，那都不安全，因为 HTTP 协议本身是明文传输的，必须使用 HTTPS 协议来加密传输数据。另外，GET 请求相比 POST 请求更容易泄露敏感数据，因为 GET 请求的参数通常放在 URL 中。post更安全（不会作为url的一部分，不会被缓存、保存在服务器日志、以及浏览器浏览记录中）

HTTP协议（HyperText Transfer Protocol，超文本传输协议）

url(统一资源定位器 Uniform Resource Locators)

万字长文，一文搞懂TCP、IP和HTTP、HTTPS

1.12 响应报文状态码

IMG_2748(20210717-195049) 200：请求成功； 301：永久重定向；302：临时重定向； 404：无法找到此页面；405：请求的方法类型不支持； 500：服务器内部出错。

image.png

1xx 类状态码属于提示信息，是协议处理中的一种中间状态，实际用到的比较少。

2xx 类状态码表示服务器成功处理了客户端的请求，也是我们最愿意看到的状态。

  • 「200 OK」是最常见的成功状态码，表示一切正常。如果是非 HEAD 请求，服务器返回的响应头都会有 body 数据。

  • 「204 No Content」也是常见的成功状态码，与 200 OK 基本相同，但响应头没有 body 数据。

  • 「206 Partial Content」是应用于 HTTP 分块下载或断点续传，表示响应返回的 body 数据并不是资源的全部，而是其中的一部分，也是服务器处理成功的状态。部分内容返回成功，这是范围请求的状态码，表示服务器返回了所请求的部分内容。

3xx 类状态码表示客户端请求的资源发生了变动，需要客户端用新的 URL 重新发送请求获取资源，也就是重定向。

  • 「301 Moved Permanently」表示永久重定向，说明请求的资源已经不存在了，需改用新的 URL 再次访问。

  • 「302 Found」表示临时重定向，说明请求的资源还在，但暂时需要用另一个 URL 来访问。

301 和 302 都会在响应头里使用字段 Location，指明后续要跳转的 URL，浏览器会自动重定向新的 URL。

  • 「304 Not Modified」不具有跳转的含义，表示资源未修改，重定向已存在的缓冲文件，也称缓存重定向，也就是告诉客户端可以继续使用缓存资源，用于缓存控制。

4xx 类状态码表示客户端发送的报文有误，服务器无法处理，也就是错误码的含义。

  • 「400 Bad Request」表示客户端请求的报文有错误，但只是个笼统的错误。

  • 「403 Forbidden」表示服务器禁止访问资源，并不是客户端的请求出错。

  • 「404 Not Found」表示请求的资源在服务器上不存在或未找到，所以无法提供给客户端。

5xx 类状态码表示客户端请求报文正确，但是服务器处理时内部发生了错误，属于服务器端的错误码。

  • 「500 Internal Server Error」与 400 类型，是个笼统通用的错误码，服务器发生了什么错误，我们并不知道。

  • 「501 Not Implemented」表示客户端请求的功能还不支持，类似“即将开业，敬请期待”的意思。

  • 「502 Bad Gateway」通常是服务器作为网关或代理时返回的错误码，表示服务器自身工作正常，访问后端服务器发生了错误。

  • 「503 Service Unavailable」表示服务器当前很忙，暂时无法响应客户端，类似“网络服务正忙，请稍后重试”的意思。

2 HTTP和HTTPS区别

HTTPS 协议（Hyper Text Transfer Protocol Secure），是 HTTP 的加强安全版本。HTTPS 是基于 HTTP 的，也是用 TCP 作为底层协议，并额外使用 SSL/TLS 协议用作加密和安全认证。默认端口号是 443.

  • 端口号：HTTP 默认是 80，HTTPS 默认是 443。

  • 安全性和资源消耗：HTTP 协议运行在 TCP 之上，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份。HTTPS 是运行在 SSL/TLS 之上的 HTTP 协议，SSL/TLS 运行在 TCP 之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。所以说，HTTP 安全性没有 HTTPS 高，但是 HTTPS 比 HTTP 耗费更多服务器资源。

  • SEO（搜索引擎优化）：搜索引擎通常会更青睐使用 HTTPS 协议的网站，因为 HTTPS 能够提供更高的安全性和用户隐私保护。使用 HTTPS 协议的网站在搜索结果中可能会被优先显示，从而对 SEO 产生影响。

  • 使用 SSL/TLS 协议用作加密和安全认证；非对称加密交换密钥，对称加密传输消息

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

区别主要有以下四点：

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

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

  • 两者的默认端口不一样，HTTP 默认端口号是 80，HTTPS 默认端口号是 443。

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

[!note]
SSL/TLS协议作用：认证用户和服务，加密数据，维护数据的完整性的应用层协议加密和解密需要两个不同的密钥，故被称为非对称加密；加密和解密都使用同一个密钥的

为了公钥传输的信赖性问题，第三方机构应运而生——证书颁发机构（CA，Certificate Authority）。CA 默认是受信任的第三方。CA 会给各个服务器颁发证书，证书存储在服务器上，并附有 CA 的电子签名。

数字签名要解决的问题，是防止证书被伪造。第三方信赖机构 CA 之所以能被信赖，就是 靠数字签名技术 。
image.png

  • 非对称加密（公钥加密、私钥解密）

  • 对称加密

  • 证书颁发机构（CA，Certificate Authority）——数字签名技术

image.png

  • 可以通过哈希算法来保证消息的完整性；

  • 可以通过数字签名来保证消息的来源可靠性（能确认消息是由持有私钥的一方发送的）；
    image.png

2.1 HTTPS防范中间人攻击

加密：https 握手期间会通过非对称加密的方式来协商出对称加密密钥。身份校验：服务器会向证书颁发机构申请数字证书，证书中包含了服务器的公钥和其他相关信息。当客户端与服务器建立连接时，服务器会将证书发送给客户端。客户端会验证证书的合法性，包括检查证书的有效期、颁发机构的信任等。如果验证通过，客户端会使用证书中的公钥来加密通信数据，并将加密后的数据发送给服务器，然后由服务端用私钥解密

2.2 HTTPS运行流程

image.png

  • 用户在浏览器里输入一个https网址，然后连接到server的443端口。

  • 服务器必须要有一套数字证书，可以自己制作，也可以向组织申请，区别就是自己颁发的证书需要客户端验证通过。这套证书其实就是一对公钥和私钥。

  • 服务器将自己的数字证书（含有公钥）发送给客户端。

  • 客户端收到服务器端的数字证书之后，会对其进行检查，如果不通过，则弹出警告框。如果证书没问题，则生成一个密钥（对称加密），用证书的公钥对它加密。

  • 客户端会发起HTTPS中的第二个HTTP请求，将加密之后的客户端密钥发送给服务器。

  • 服务器接收到客户端发来的密文之后，会用自己的私钥对其进行非对称解密，解密之后得到客户端密钥，然后用客户端密钥对返回数据进行对称加密，这样数据就变成了密文。

  • 服务器将加密后的密文返回给客户端。

  • 客户端收到服务器发返回的密文，用自己的密钥（客户端密钥）对其进行对称解密，得到服务器返回的数据

2.2.1 TCP三次握手

2.2.2 TLS四次握手

TLS第一次握手：client -> server (Client Hello)

客户端向服务端发送：

  1. 客户端支持的协议；

  2. 已经使用的TLS版本；

  3. 随机数Random（Client Random）

  4. 支持的密码套件。

客户端发送完「Client Hello」，服务端向客户端发送的ACK确认消息，代表上面的「Client Hello」已经收到。这里也可以看出服务端是通过普通的TCP 的ACK消息去应答「Client Hello」。

TLS第二次握手：server -> client (1.Server Hello; 2.Certificate,Server key Exchange,Server Hello Done)

  1. Server Hello：

    • 服务端支持的协议；
    • 使用的TLS版本；
    • 随机数Random==（Server Random）==
    • 服务端选用的密码套件。

  2. Certificate：服务端为了证明自己的身份，会发送「Server Certificate」给客户端，这个消息里含有数字证书；

  3. Server key Exchange,Server Hello Done：目的是告诉客户端，我已经把该给你的东西都给你了，本次打招呼完毕。

::: note
数字证书签发和验证流程
:::

image.png

  • CA(证书认证机构)对公钥等信息进行Hash计算，并通过私钥加密，对证书进行签名

  • 首先客户端会使用同样的 Hash 算法获取该证书的 Hash 值 H1

  • 浏览器收到证书后可以使用 CA 的公钥解密 Certificate Signature 内容，得到一个Hash值H2

TLS第三次握手client -> server (Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message)

Client Key Exchange

客户端收到了服务端的证书及「Server Hello Done」消息后，首先通过浏览器或者操作系统中的CA公钥校验证书，校验通过后会将Client Params数据传递给服务端，其中包含自身生成的椭圆曲线公钥（Pubkey）

接着，客户端就会生成一个新的随机数 (pre-master)，用服务器的 RSA 公钥加密该随机数，通过「Client Key Exchange」消息传给服务端。

Change Cipher Spec

加密通信算法改变通知，「Change Cipher Spec」消息表示客户端已经生成密钥，并切换到对称加密模式。

Encrypted Handshake Message

  1. 告诉服务端，客户端在握手的过程中收到和发送的数据做一个摘要并用会话密钥加密发送给服务端做校验，保证TSL握手过程中报文没有被修改过；

  2. 如果服务端收到这个消息并能解密成功，就能说明对称密钥是正确的。

「Encrypted Handshake Message」消息其实不只是客户端会发送，之后服务端也会发送一个。

TLS 第四次握手server -> client (Change Cipher Spec,Encrypted Handshake Message)

（1）加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。
（2）服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供客户端校验。

HTTP vs HTTPS（应用层） | JavaGuide

字节校招一面：聊聊https 原理

2.2.3 秘钥交换算法

RSA 算法和 ECDHE 算法

2.2.4 HTTPS一定安全可靠吗

客户端通过浏览器向服务端发起 HTTPS 请求时，被「假基站」转发到了一个「中间人服务器」，于是客户端是和「中间人服务器」完成了 TLS 握手，然后这个「中间人服务器」再与真正的服务端完成 TLS 握手。

发生这种场景是有前提的，前提是用户点击接受了中间人服务器的证书。 中间人服务器与客户端在 TLS 握手过程中，实际上发送了自己伪造的证书给浏览器，而这个伪造的证书是能被浏览器（客户端）识别出是非法的，于是就会提醒用户该证书存在问题。

3 HTTP和RPC区别

RPC（即Remote Procedure Call，远程过程调用）和HTTP（HyperText Transfer Protocol，超文本传输协议），两者前者是一种方法，后者则是一种协议。两者都常用于实现服务，在这个层面最本质的区别是RPC服务主要工作在TCP协议之上（也可以在HTTP协议），而HTTP服务工作在HTTP协议之上。由于HTTP协议基于TCP协议，所以RPC服务天然比HTTP更轻量，效率更胜一筹。

HTTP和RPC的区别-腾讯云开发者社区-腾讯云 (tencent.com)

3.8 既然有 HTTP 协议，为什么还要有 RPC？ | 小林coding (xiaolincoding.com)

4 DNS

DNS（Domain Name System）域名管理系统，是当用户使用浏览器访问网址之后，使用的第一个重要协议。DNS 要解决的是域名和 IP 地址的映射问题。

[!note]
浏览器缓存，系统缓存，路由器缓存，IPS服务器缓存，根域名服务器缓存，顶级域名服务器缓存，主域名服务器缓存。一、主机向本地域名服务器的查询一般都是采用递归查询。二、本地域名服务器向根域名服务器的查询的迭代查询。

DNS：递归（通过其他服务器解析）、迭代（自己处理解析过程）
迭代查询对于客户端来说比较复杂，需要自行处理多次查询和跳转。 迭代查询可以减少DNS服务器的负载，因为客户端自行进行多次查询可以分散服务器的压力。 在实际应用中，递归查询和迭代查询各有优缺点。 递归查询可以减少客户端的复杂度，但需要DNS服务器具备较高的处理能力和带宽资源。 而迭代查询可以减轻DNS服务器的压力，但需要客户端自行进行多次查询和跳转。

4.1 DNS负载均衡

当一个网站有足够多的用户的时候，假如每次请求的资源都位于同一台机器上面，那么这台机器随时可能会崩掉。处理办法就是用DNS负载均衡技术，它的原理是在DNS服务器中为同一个主机名配置多个IP地址,在应答DNS查询时,DNS服务器对每个查询将以DNS文件中主机记录的IP地址按顺序返回不同的解析结果,将客户端的访问引导到不同的机器上去,使得不同的客户端访问不同的服务器,从而达到负载均衡的目的｡例如可以根据每台机器的负载量，该机器离用户地理位置的距离等等。

4.2 DNS劫持

DNS 劫持是一种网络攻击，它通过修改 DNS 服务器的解析结果，使用户访问的域名指向错误的 IP 地址，从而导致用户无法访问正常的网站，或者被引导到恶意的网站。DNS 劫持有时也被称为 DNS 重定向、DNS 欺骗或 DNS 污染。

5 Nginx负载均衡算法

  • 轮询：按照顺序依次将请求分配给后端服务器。这种算法最简单，但是也无法处理某个节点变慢或者客户端操作有连续性的情况。

  • IP哈希：根据客户端IP地址的哈希值来确定分配请求的后端服务器。适用于需要保持同一客户端的请求始终发送到同一台后端服务器的场景，如会话保持。

  • URL哈希：按访问的URL的哈希结果来分配请求，使每个URL定向到一台后端服务器，可以进一步提高后端缓存服务器的效率。

  • 最短响应时间：按照后端服务器的响应时间来分配请求，响应时间短的优先分配。适用于后端服务器性能不均的场景，能够将请求发送到响应时间快的服务器，实现负载均衡。

  • 加权轮询：按照权重分配请求给后端服务器，权重越高的服务器获得更多的请求。适用于后端服务器性能不同的场景，可以根据服务器权重分配请求，提高高性能服务器的利用率。

6 参考

6.1 HTTP

重磅！图文详解HTTPS协议通信全过程，结合抓包实战分析，带你一次看透HTTPS！ (qq.com)
3.3 HTTPS RSA 握手解析 | 小林coding (xiaolincoding.com)