高频面试题： http协议的详解

番茄炒蛋加鸡腿进步哥
67 阅读28分钟

http协议的概括

osi模型

开放式系统互联模型（英语：Open Systems Interconnection Model，缩写：OSI；简称为OSI模型）是一种概念模型，由国际标准化组织提出，一个试图使各种计算机在世界范围内互连为网络的标准框架。定义于ISO/IEC 7498-1。

该模型将通信系统中的数据流划分为七个层，从分布式应用程序数据的最高层表示到跨通信介质传输数据的物理实现。每个中间层为其上一层提供功能，其自身功能则由其下一层提供。功能的类别通过标准的通信协议在软件中实现。其中，第 1 到第 4 层与网络通信技术相关，而第 5 到第 7 层则与用户应用程序有关。

http协议

概括

超文本传输协议（HTTP）是一个用于传输超媒体文档（例如 HTML）的应用层协议。它是为 Web 浏览器与 Web 服务器之间的通信而设计的，但也可以用于其他目的。HTTP 遵循经典的客户端—服务端模型，客户端打开一个连接以发出请求，然后等待直到收到服务器端响应。HTTP 是无状态协议，这意味着服务器不会在两个请求之间保留任何数据（状态）。

工作原理

HTTP协议定义Web客户端如何从Web服务器请求Web页面，以及服务器如何把Web页面传送给客户端。HTTP协议采用了请求/响应模型。客户端向服务器发送一个请求报文，请求报文包含请求的方法、URL、协议版本、请求头部和请求数据。服务器以一个状态行作为响应，响应的内容包括协议的版本、成功或者错误代码、服务器信息、响应头部和响应数据。

  1. 客户端连接到web浏览器
    1. 一个HTTP客户端，通常是浏览器，与Web服务器的HTTP端口（默认为80）建立一个TCP套接字连接。
    2. tcp连接（三次握手四次挥手）
  1. 发送http连接
    1. 通过TCP套接字，客户端向Web服务器发送一个文本的请求报文
    2. 一个请求报文由请求行、请求头部、空行和请求数据4部分组成。
  1. 服务器接受请求并返回HTTP响应
    1. Web服务器解析请求，定位请求资源。服务器将资源复本写到TCP套接字，由客户端读取。
    2. 一个响应由状态行、响应头部、空行和响应数据4部分组成。
  1. 释放TCP连接
    1. 若connection 模式为close，则服务器主动关闭TCP连接，客户端被动关闭连接，释放TCP连接;若connection 模式为keepalive，则该连接会保持一段时间，在该时间内可以继续接收请求;
  1. 客户端浏览器解析html内容
    1. 客户端浏览器首先解析状态行，查看表明请求是否成功的状态代码。然后解析每一个响应头，响应头告知以下为若干字节的HTML文档和文档的字符集。客户端浏览器读取响应数据HTML，根据HTML的语法对其进行格式化，并在浏览器窗口中显示。
浏览器解析请求的过程
  1. 浏览器向 DNS 服务器请求解析该 URL 中的域名所对应的 IP 地址;
  2. 解析出 IP 地址后，根据该 IP 地址和默认端口 80，和服务器建立TCP连接;
  3. 浏览器发出读取文件(URL 中域名后面部分对应的文件)的HTTP 请求，该请求报文作为 TCP 三次握手的第三个报文的数据发送给服务器;
  4. 服务器对浏览器请求作出响应，并把对应的 html 文本发送给浏览器;
  5. 释放 TCP连接（四次挥手）;
  6. 浏览器将该 html 文本并显示内容;

报文

请求行（request line）、请求头部（header）、空行和请求数据四个部分组成。

HTTP响应也由四个部分组成，分别是：状态行、消息报头、空行和响应正文。

请求方式和状态码

请求方式
  1. GET 方法请求一个指定资源的表示形式，使用 GET 的请求应该只被用于获取数据。
  2. HEAD 方法请求一个与 GET 请求的响应相同的响应，但没有响应体。
  3. POST 方法用于将实体提交到指定的资源，通常导致在服务器上的状态变化或副作用。
  4. PUT 方法用有效载荷请求替换目标资源的所有当前表示。
  5. DELETE 方法删除指定的资源。
  6. CONNECT 方法建立一个到由目标资源标识的服务器的隧道。
  7. OPTIONS 方法用于描述目标资源的通信选项。
  8. TRACE 方法沿着到目标资源的路径执行一个消息环回测试。
  9. PATCH 方法用于对资源应用部分修改。

状态码

  • 1xx：指示信息--表示请求已接收，继续处理
  • 2xx：成功--表示请求已被成功接收、理解、接受
  • 3xx：重定向--要完成请求必须进行更进一步的操作
  • 4xx：客户端错误--请求有语法错误或请求无法实现
  • 5xx：服务器端错误--服务器未能实现合法的请求

get和post的区别

  • GET在浏览器回退时是无害的，而POST会再次提交请求。
  • GET请求会被浏览器主动cache，而POST不会，除非手动设置。
  • GET请求只能进行url编码，而POST支持多种编码方式。
  • GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。
  • GET请求在URL中传送的参数是有长度限制的，而POST没有。
  • 对参数的数据类型，GET只接受ASCII字符，而POST没有限制。
  • GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。
  • GET参数通过URL传递，POST放在Request body中

简单请求和复杂请求

简单请求

某些请求不会触发 CORS 预检请求。在废弃的 CORS 规范中称这样的请求为简单请求

简单请求是指仅使用HTTP头信息中的信息（如GET，POST等）进行请求，并且没有使用特殊的HTTP头字段的请求。

简单请求不会触发预检请求，可以直接发送到服务器端进行处理。

对于简单请求，例如使用 GET 或 POST 方法且没有自定义请求头，浏览器会自动添加 Origin 头部，发送跨域请求时，服务端可以通过 Access-Control-Allow-Origin 头部来授权。在这种情况下，跨域请求会被浏览器允许，而不需要进行预检请求。

简单请求的触发条件如下：

  1. 请求方法只能是GET、POST或HEAD。
  2. 请求头中的内容只能是Accept、Accept-Language、Content-Language、Content-Type（且值只能是 application/x-www-form-urlencoded、multipart/form-data 或 text/plain）和 Range。
  3. 请求中没有使用ReadableStream流。
  • 如果请求是使用 XMLHttpRequest 对象发出的，在返回的 XMLHttpRequest.upload 对象属性上没有注册任何事件监听器；也就是说，给定一个 XMLHttpRequest 实例 xhr，没有调用 xhr.upload.addEventListener()，以监听该上传请求。
复杂请求（预检请求）

非简单请求即为复杂请求。复杂请求我们也可以称之为在实际进行请求之前，需要发起预检请求的请求。

复杂请求的触发条件不满足简单请求的条件，因此需要发送预检请求。预检请求是一种HTTP OPTIONS请求，用于通知服务器客户端希望发送的实际请求的参数和特性。服务器会返回一个带有Access-Control-Allow-Origin头字段的响应，用于告知客户端是否允许发送实际请求。如果允许，客户端将发送实际请求。

预检请求会携带一些自定义的头部信息，例如 Access-Control-Request-Method、Access-Control-Request-Headers 等，以告知服务器实际请求所需要的权限。服务器在接收到预检请求后，可以根据预检请求中的信息，返回相应的响应头部信息，表示是否允许跨域请求。

需要注意的是，预检请求的响应会被浏览器缓存，下次发送相同的复杂请求时，会直接使用缓存中的响应，而不会再发送预检请求。

预检请求与重定向

并不是所有浏览器都支持预检请求的重定向。如果一个预检请求发生了重定向，一部分浏览器将报告错误

对于不支持预检请求的浏览器，可以

  1. 发出一个简单请求（使用 Fetch API 中的 Response.url 或 XMLHttpRequest.responseURL）以判断真正的预检请求会返回什么地址。
  2. 发出另一个请求（真正的请求），使用在上一步通过 Response.url 或 XMLHttpRequest.responseURL 获得的 URL。
预检请求和凭据

CORS 预检请求不能包含凭据。预检请求的响应必须指定 Access-Control-Allow-Credentials: true 来表明可以携带凭据进行实际的请求。

对于附带身份凭证的请求，服务器不得设置 Access-Control-Allow-Origin的值为“*”。

这是因为请求的首部中携带了Cookie信息，如果 Access-Control-Allow-Origin的值为“*”，请求将会失败。而将 Access-Control-Allow-Origin的值设置为 http://foo.example（请求源），则请求将成功执行。

URL与URI

  • URI：Universal Resource Identifier，统一资源标识符：
    1. URI是一个用来标识抽象或物理资源的紧凑字符串，通过这个标识可以访问一个唯一的资源。
    2. 这里的“资源”表示的是web上每一种可用的资源，如HTML文档、图像、视频片段、程序等，它们可以都由唯一的一个URI字符串进行标识，具体的标识规则由我们自己确定。放到现实中，资源可以类比一个独一无二的人、动物、物体，而URI类似于身份证或者DNA（反正是要独一无二的，它可以使任何规则）。
  • URL：Universal Resource Locator，统一资源定位符
    1. URL一个通过位置来标识资源的字符串，是目前网络资源的主要访问机制的。
    2. 一个标准的URL必须包括：protocol、host、port、path、parameter、anchor，例如，动物住址协议://地球/中国/浙江省/杭州市/西湖区/某大学/14号宿舍楼/525号寝/张三.人，这样通过该资源的位置可以以定位该资源。
    3. 可以看出来，URL是通过位置来确定一个资源的，因此URL是URI的子集，或者说URL是URI的一种实现方式！
  • URN：Universal Resource Name ，统一资源名称。
    1. 通过特定命名空间中的唯一名称或ID来标识资源。上面说的身份证、DNA就是类似于URN。

http的特点

综上所述：

  1. 简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。
  2. 灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。
  3. 无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。
  4. 无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。
  5. 支持B/S及C/S模式。

协议的发展

http0.9

只有 GET 命令，没有 HEADER 等描述数据的信息

http1.0

增加了很多命令，如 POST、PUT 等

增加了状态码和 HEADER 相关信息

增加了缓存

http1.1

持久连接，不会关闭 TCP 连接

增加了 pipeline,可以在同一个 TCP 连接里面发送多个 http 请求,但是串行的。

增加了头部 host，即可以在同一台服务器(物理服务器)上同时跑多个 web 服务。

http2

头部信息压缩

在HTTP2.0中，使用了HPACK（HTTP2头部压缩算法）压缩格式对传输的header进行编码，减少了header的大小。并在两端维护了索引表，用于记录出现过的header，后面在传输过程中就可以传输已经记录过的header的键名，对端收到数据后就可以通过键名找到对应的值。

推送功能

在请求 html 的同时，服务器端可以主动把 html 里面所引用到的 css 和 js 文件推送到客户端，这样 html、css 和 js 的发送就是并行的而不是串行的，整体的传输效率和性能就提高了不少。

在HTTP2.0中，服务器可以对一个客户端的请求发送多个响应。如果一个请求是由你的主页发送的，服务器可能会响应主页内容、logo以及样式表，因为他知道客户端会用到这些东西。这样不但减轻了数据传送冗余步骤，也加快了页面响应的速度，提高了用户体验。

推送的缺点：所有推送的资源都必须遵守同源策略。换句话说，服务器不能随便将第三方资源推送给客户端，而必须是经过双方的确认才行。

二进制分帧

所有传输的数据都会被分割，并采用二进制格式编码。

多路复用

HTTP 消息被分解为独立的帧，而不破坏消息本身的语义，交错发出去，在另一端根据流标识符和首部将他们重新组装起来。 通过该技术，可以避免 HTTP 旧版本的队头阻塞问题，极大提高传输性能。

在HTTP1.x中，我们经常会使用到雪碧图、使用多个域名等方式来进行优化，都是因为浏览器限制了同一个域名下的请求数量，当页面需要请求很多资源的时候，队头阻塞（Head of line blocking）会导致在达到最大请求时，资源需要等待其他资源请求完成后才能继续发送。

HTTP2.0中,基于二进制分帧层，HTTP2.0可以在共享TCP连接的基础上同时发送请求和响应。HTTP消息被分解为独立的帧，而不破坏消息本身的语义，交错发出去，在另一端根据流标识符和首部将他们重新组装起来。 通过该技术，可以避免HTTP旧版本的队头阻塞问题，极大提高传输性能。

  • 公平多路复用（例如两个渐进的 JPEGs）：12121212
  • 加权多路复用（2是1的两倍）：22122122121
  • 反向顺序调度（例如2是密钥服务器推送的资源）：22221111
  • 部分调度（流1被中止且未完整发送）：112222

http3

http3以下的协议会存在队头阻塞问题

队头阻塞

HTTP/1.1 是一个纯文本协议，它只在有效荷载（payload）的前面附加头（headers）。它不会进一步区分单个（大块）资源与其他资源。HTTP/1.1相比较于HTTP/1.0来说，最主要的改进就是引入了持久连接(keep-alive)。HTTP/1.1允许在持久连接上使用请求管道，是相对于持久连接的又一性能优化。

所谓请求管道，就是在HTTP响应到达之前，可以将多条请求放入队列，当第一条HTTP请求通过网络流向服务器时，第二条和第三条请求也可以开始发送了。在高时延网络条件下，这样做可以降低网络的环回时间，提高性能。但是，对于管道连接还是有一定的限制和要求的，其中一个比较关键的就是服务端必须按照与请求相同的顺序回送HTTP响应。这也就意味着，如果一个响应返回发生了延迟，那么其后续的响应都会被延迟，直到队头的响应送达。这就是所谓的HTTP队头阻塞。

HTTP队头阻塞的问题在HTTP/2中得到了有效的解决。HTTP/2废弃了管道化的方式，而是创新性的引入了帧、消息和数据流等概念。客户端和服务器可以把 HTTP 消息分解为互不依赖的帧，然后乱序发送，最后再在另一端把它们重新组合起来。因为没有顺序了，所以就不需要阻塞了，就有效的解决了HTTP队头阻塞的问题。但是，HTTP/2仍然会存在TCP队头阻塞的问题，那是因为HTTP/2其实还是依赖TCP协议实现的。TCP传输过程中会把数据拆分为一个个按照顺序排列的数据包，这些数据包通过网络传输到了接收端，接收端再按照顺序将这些数据包组合成原始数据，这样就完成了数据传输。但是如果其中的某一个数据包没有按照顺序到达，接收端会一直保持连接等待数据包返回，这时候就会阻塞后续请求。这就发生了TCP队头阻塞。

如果 TCP 数据包2在网络中丢失，但数据包1和数据包3已经到达，会发生什么情况？请记住，TCP并不知道它正在承载 HTTP/2，只知道它需要按顺序传递数据。因此，它知道数据包1的内容可以安全使用，并将这些内容传递给浏览器。然而，它发现数据包1中的字节和数据包3中的字节（放数据包2 的地方）之间存在间隙，因此还不能将数据包3传递给浏览器。TCP 将数据包3保存在其接收缓冲区（receive buffer）中，直到它接收到数据包2的重传副本（这至少需要往返服务器一次），之后它可以按照正确的顺序将这两个数据包都传递给浏览器。换个说法：丢失的数据包2 队头阻塞（HOL blocking）数据包3！

您可能不清楚为什么这是个问题，所以让我们更深入地研究图7中 HTTP 层的 TCP 包中的实际内容。我们可以看到，TCP 数据包2只携带流id 2（CSS文件）的数据，数据包3同时携带流1（JS文件）和流2的数据。在 HTTP 级别，我们知道这两个流是独立的，并且由数据帧（DATA frame）清楚地描述出来。因此，理论上我们可以完美地将数据包3传递给浏览器，而不必等待数据包2到达。浏览器将看到流id为1的数据帧，并且能够直接使用它。只有流2必须被挂起，等待数据包2的重新传输。这将比我们从 TCP 的方式中得到的效率更高，TCP 的方式最终会阻塞流1和流2。

另一个例子是数据包1丢失，但是接收到2和3的情况。TCP将再次阻止数据包2和3，等待1。但是，我们可以看到，在HTTP/2级别，流2的数据（CSS文件）完全存在于数据包2和3中，不必等待数据包1的重新传输。浏览器本可以完美地解析/处理/使用 CSS 文件，但却被困在等待 JS 文件的重新传输。TCP 不知道 HTTP/2 的独立流（streams）这一事实意味着 TCP 层队头阻塞（由于丢失或延迟的数据包）也最终导致 HTTP 队头阻塞！

HTTP/1.1的管道化持久连接也是使得同一个TCP链接可以被多个HTTP使用，但是HTTP/1.1中规定一个域名可以有6个TCP连接。而HTTP/2中，同一个域名只是用一个TCP连接。

所以，在HTTP/2中，TCP队头阻塞造成的影响会更大，因为HTTP/2的多路复用技术使得多个请求其实是基于同一个TCP连接的，那如果某一个请求造成了TCP队头阻塞，那么多个请求都会受到影响。

那为什么还要使用2.0？

虽然数据包丢失确实发生在网络上，但还是比较少见的。特别是在有线网络中，包丢失率只有 0.01%。即使是在最差的蜂窝网络上，在现实中，您也很少看到丢包率高于2%。这与数据包丢失和抖动（网络中的延迟变化）通常是突发性的这一事实结合在一起的。包丢失率为2%并不意味着每100个包中总是有2个包丢失（例如数据包 42 和 96）。

这里还需要引入RRT的概念。网络延迟又称为 RTT(Round Trip Time)。他是指一个请求从客户端浏览器发送一个请求数据包到服务器，再从服务器得到响应数据包的这段时间。RTT 是反映网络性能的一个重要指标。TCP三次握手的过程客户端和服务器之间需要交互三次，那么也就是说需要消耗1.5 RTT。另外，如果使用的是安全的HTTPS协议，就还需要使用TLS协议进行安全数据传输，这个过程又要消耗一个RTT(TLS不同版本的握手机制不同，这里按照最小的消耗来算)。所以HTTP1.0的频繁TCP链接同样会造成大量网络资源消耗。

回到TCP队头阻塞。由于2.0“协议僵化"的问题，HTTP/3选择了一种新的技术方案，那就是基于UDP做改造，这种技术叫做QUIC。解决方案很简单：我们“只是”需要让传输层知道不同的、独立的流！这样，如果一个流的数据丢失，传输层本身就知道它不需要阻塞其他流。让 QUIC 知道不同的流（streams）是非常简单的。QUIC 受到 HTTP/2 帧方式（framing-approach）的启发，还添加了自己的帧（frames）；在本例中是流帧（STREAM frame）。流id（stream id）以前在 HTTP/2 的数据帧（DATA frame）中，现在被下移到传输层的 QUIC 流帧（STREAM frame）中。这也说明了如果我们想使用 QUIC，我们需要一个新版本的 HTTP 的原因之一：如果我们只在 QUIC 之上运行 HTTP/2，那么我们将有两个（可能冲突的）“流层”（stream layers）。相反，HTTP/3 从 HTTP 层删除了流的概念（它的数据帧（DATA frames）没有流id），而是重新使用底层的 QUIC 流。

与 HTTP/2 的数据帧（DATA frames）非常相似，QUIC 的流帧（STREAM frames）分别跟踪每个流的字节范围。这与 TCP 不同，TCP 只是将所有流数据附加到一个大 blob 中。像以前一样，让我们考虑一下如果 QUIC 数据包2丢失，而 1 和 3 到达会发生什么。与 TCP 类似，数据包1中流1（stream 1）的数据可以直接传递到浏览器。然而，对于数据包3，QUIC 可以比 TCP 更聪明。它查看流1的字节范围，发现这个流帧（STREAM frame）完全遵循流id 1的第一个流帧 STREAM frame（字节 450 跟在字节 449 之后，因此数据中没有字节间隙）。它可以立即将这些数据提供给浏览器进行处理。然而，对于流id 2，QUIC确实看到了一个缺口（它还没有接收到字节0-299，这些字节在丢失的 QUIC 数据包2中）。它将保存该流帧（STREAM frame），直到 QUIC 数据包2的重传（retransmission）到达。再次将其与 TCP 进行对比，后者也将数据流1的数据保留在数据包3中！

类似的情况发生在另一种情形下，数据包1丢失，但2和3到达。QUIC 知道它已经接收到流2（stream 2）的所有预期数据，并将其传递给浏览器，只保留流1（stream 1）。我们可以看到，对于这个例子，QUIC 确实解决了 TCP 的队头阻塞！

不过，这种方式有几个重要的后果。最有影响的是 QUIC 数据可能不再以与发送时完全相同的顺序发送到浏览器。对于 TCP，如果您发送数据包1、2和3，它们的内容将以完全相同的顺序发送到浏览器（这就是导致队头阻塞的第一个原因）。然而，对于 QUIC，在上面的第二个示例中，在数据包1丢失的情况下，浏览器首先看到数据包2的内容，然后是数据包3的最后一部分，然后是数据包1的（重传），然后是数据包3的第一部分。换言之：QUIC 在单个资源流中保留了顺序，但不再跨单个流（individual streams）进行排序。

所以QUIC也没完全解决阻塞问题，只是在队头阻塞预防和资源加载性能之间取平衡。

http3的特点

  • 基于QUIC协议：HTTP/3.0使用基于UDP的QUIC协议来传输数据，相比于TCP协议，QUIC协议可以提供更快的连接建立和传输速度，减少了网络延迟和丢包率。
  • 线头阻塞(HOL)问题的解决更为彻底，让不同的流之间真正的实现相互独立传输，互不干扰。
  • 集成了TLS加密：HTTP/3.0集成了TLS加密，从而保护了网络传输的安全性。
  • 0-RTT连接：HTTP/3.0支持0-RTT连接，即客户端可以在没有建立连接的情况下向服务器发送请求，从而进一步减少了网络延迟和页面加载时间。
  • 切换网络时的连接保持：
  • 当前移动端的应用环境，用户的网络可能会经常切换，比如从办公室或家里出门，WiFi断开，网络切换为3G或4G。基于TCP的协议，由于切换网络之后，IP会改变，因而之前的连接不可能继续保持。而基于UDP的QUIC协议，则可以内建与TCP中不同的连接标识方法，从而在网络完成切换之后，恢复之前与服务器的连接。

基于udp如何保证连接的可靠性

  • 前向纠错（Forward Error Correction，FEC）：HTTP/3.0使用FEC技术来纠正数据包的丢失，即在发送数据包的同时，发送一些冗余数据，接收方可以利用这些冗余数据来还原丢失的数据包，从而提高数据的可靠性。
  • 重传机制：HTTP/3.0在QUIC协议中实现了自己的重传机制，即当发生数据包丢失或者损坏时，会进行重传，以确保数据的可靠传输。
  • 拥塞控制：HTTP/3.0基于QUIC协议实现了自己的拥塞控制机制，可以根据网络情况自适应地调整数据传输的速率，以避免网络拥塞和数据包丢失。

http和https

HTTPS：是以安全为目标的 HTTP 通道，简单讲是 HTTP 的安全版，即 HTTP 下加入 SSL 层，HTTPS 的安全基础是 SSL，因此加密的详细内容就需要 SSL。SSL（Secure Sockets Layer）安全套接层协议，目的是保证数据传输的安全和完整。TLS（Transport Layer Security）传输层安全是 SSL 的非专有版本。SSL 位于应用层和传输层之间。处理的对象是数据流，加密算法是 RC4(对称加密)。

  • https 协议需要到 ca 申请证书，一般免费证书较少，因而需要一定费用。
  • http 是超文本传输协议，信息是明文传输，https 则是具有安全性的 ssl 加密传输协议。
  • http 和 https 使用的是完全不同的连接方式，用的端口也不一样，前者是 80，后者是 443。
  • http 的连接很简单，是无状态的；HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，比 http 协议安全。

SSL和TSL

传输层安全性协议（英语：Transport Layer Security，缩写：TLS）前身称为安全套接层（英语：Secure Sockets Layer，缩写：SSL）是一种安全协议，目的是为互联网通信提供安全及数据完整性保障。

SSL包含记录层（Record Layer）和传输层，记录层协议确定传输层数据的封装格式。传输层安全协议使用X.509认证，之后利用非对称加密演算来对通信方做身份认证，之后交换对称密匙作为会话密匙（Session key）。这个会谈密匙是用来将通信两方交换的资料做加密，保证两个应用间通信的保密性和可靠性，使客户与服务器应用之间的通信不被攻击者窃听。

TLS协议的优势是与高层的应用层协议（如HTTP、FTP、Telnet等）无耦合。应用层协议能透明地运行在TLS协议之上，由TLS协议进行建立加密通道需要的协商和认证。应用层协议传送的数据在通过TLS协议时都会被加密，从而保证通信的私密性。

TLS协议是可选的，必须配置客户端和服务器才能使用。主要有两种方式实现这一目标：一个是使用统一的TLS协议端口（例如：用于HTTPS的端口443）；另一个是客户端请求服务器连接到TLS时使用特定的协议机制（例如：电子邮件常用的STARTTLS）。一旦客户端和服务器都同意使用TLS协议，他们通过使用一个握手过程协商出一个有状态的连接以传输数据。通过握手，客户端和服务器协商各种参数用于建立安全连接：

TLS在互联网上为HTTP等应用程序提供身份验证、加密、完整性，其基础是公钥基础设施。这是因为公钥基础设施普遍商业运营。TLS协议的设计在某种程度上能够使主从架构应用程序通讯预防窃听、干扰和消息伪造。

TLS包含几个基本阶段：

  1. 对等协商支持的TLS版本，和支持的密码包。
  2. 基于非对称密钥的身份认证，通常是基于PKI证书的身份认证。服务器将其X.509证书发送给客户端，由客户端验证服务器的身份。如果服务器要验证客户端的证书，则客户端可能会将客户端证书发送给服务器。通常仅验证服务器，不验证客户端。
  3. 基于对称密钥的数据加密。客户端生成随机数作为会话密钥，并使用服务器公钥（服务器公钥在服务器证书中）加密会话密钥，最后将已加密的会话密钥发送给服务器。由服务器的私钥解密出会话密钥。最后使用此会话密钥加密数据。TLS也可以使用预共享密钥（PSK）作为对称密钥。

在第二步基于非对称加密的身份认证中，可能存在中间人攻击的情况，需要引入消息摘要（同时使用双方的公私钥）和CA证书解决。

参考

期待你的关注

www.cnblogs.com/ranyonsue/p…

www.cnblogs.com/biyeymyhjob…

juejin.cn/post/720584…

developer.mozilla.org/zh-CN/docs/…

juejin.cn/post/722957…

avatar
文章
阅读
粉丝