5G核心网络传输层

5G核心网络传输层统一采用HTTP/2协议,应用层携带不同的服务消息.因为底层的传输方式相同,所有的服务化接口就可以在同一总线上进行传输,这种通信方式又可以理解为总线通信方式,在总线上每个NF通过各自的服务化接口对外提供服务,并允许其他获得授权的NF访问或调用自身的服务.提供服务的NF被称为NF服务提供者,访问和调用服务的NF被称为NF服务使用者.他们之间通过订阅和通知的方式进行具体的消息交互.如下图所示,服务使用者订阅服务提供者能提供的服务,服务提供者计算完成后以通知的形式返回给服务使用者.
下面我们将对这个HTTP/2协议进行详细介绍

起源

HTTP/2是2009年中期发布的，主要是为了解决现HTTP 1.1性能不好的问题才出现的。HTTP/2起源于谷歌的SPDY项目。

（ps小知识：SPDY（读作“SPeeDY”）是Google开发的基于TCP的会话层 [1] 协议，用以最小化网络延迟，提升网络速度，优化用户的网络使用体验。SPDY并不是一种用于替代HTTP的协议，而是对HTTP协议的增强。新协议的功能包括数据流的多路复用、请求优先级以及HTTP报头压缩。谷歌表示，引入SPDY协议后，在实验室测试中页面加载速度比原先快64%。）

HTTP/2为什么厉害呢？性能强劲的核心在于二进制分帧层，这个结构定义了如何封装HTTP消息并在客户端与服务器之间传输。

从上图我们可以看出，HTTP/2与第一代的不同是编码方式的转变。将所有传输的信息分割为更小的消息和帧，并采用二进制格式对他们编码。说新的二级制分帧机制改变了客户端与服务器之间交换数据的方式。

HTTP/2主要概念

为了说明这个过程，我们需要了解HTTP/2的三个概念：

数据流：已经建立的连接内的双向字节流，可以承载一条或多条消息。
消息：与逻辑请求或响应消息对应的完整的一系列帧。
帧：HTTP/2通信的最小单位，每个帧都包含帧头，至少也会标识出当前帧所属的数据流和消息。

这些概念的关系总结如下：

所有的通信都在一个TCP连接上完成，此连接可以承载任意数量的双向数据流（这个连接建立之后不会删除，一直保留，后面也会介绍到）
每个数据流都有一个唯一的标识符可选的优先级信息，用于承载双向信息。
每条信息都是一条逻辑HTTP消息（例如请求或响应），包含一个或多个数据帧。
帧是最小的通信单位，承载着特定类型的数据，如HTTP标头、消息负载，等。来自不同数据流的帧可以交错发送，然后再根据每个帧头的数据流标识符重新组装。

HTTP/2将HTTP协议通信分解为二进制编码帧的交换，这些帧对应着特定数据流中的消息。所有这些都在一个TCP连接内复用（迷糊不，一个帧里面的信息来回重复使用？）。这是HTTP/2协议所有其他功能和性能优化的基础。

请求与响应复用

那啥叫请求与响应的复用呢？

在HTTP/1中，如果客户端想提升性能，要发起多个并行请求，需要使用多个TCP连接。每次连接只交付一个响应。HTTP/2中新的二进制分帧层，实现了完整的请求和响应复用：客户端和服务器可以将HTTP消息分解为互不依赖的帧，然后交错发送，最后再在另一端将他们重新组装。（也就是说连接建立了之后不会立即销毁）

我们从图中也可以看出来在一个连接中并行传输多个数据流。举一个例子，服务器向客户端发送多个响应数据，一个数据流的头先发送之后，数据体可以在之后进行间歇性发送，当最后一个stream data发送完成之后应该有一个标识，告诉这个响应数据发送完成。

数据流优先级

HTTP/2协议为数据流定义了优先级，这也是其改进后的一个强劲功能。将HTTP消息分解为很多个独立的帧之后，我们就可以复用多个数据流中的帧，客户端和服务器交错发送和传输这些帧的顺序就称为关键的性能决定因素。为了做到这一点，HTTP/2允许每一个数据流都有一个关联的权重和依赖关系：

可以向每个数据流分配一个介于1到256之间的整数。每个数据流与其他数据流之间可以存在显式依赖关系。数据流依赖关系和权重的组合让客户端可以构建和传递“优先级树”，表明它倾向于如何接收响应，反过来，服务器可以使用此信息通过控制CPU、内存和其他资源的分配是定数据流的优先级，在资源数据可用之后，带宽分配可以确保将高优先级响应以最优方式传输至客户端。说简单点就是客户端向服务器发送1、2、3，三个请求，并告诉服务器1这个请求非常重要先给我处理，服务器根据优先级树决定对于这三个请求的CPU分配，确保将用户着急得到的信息先进行传输。

HTTP/2 内的数据流依赖关系通过将另一个数据流的唯一标识符作为父项引用进行声明；如果忽略标识符，相应数据流将依赖于“根数据流”。声明数据流依赖关系指出，应尽可能先向父数据流分配资源，然后再向其依赖项分配资源。换句话说，“请先处理和传输响应 D，然后再处理和传输响应 C”。

共享相同父项的数据流（即，同级数据流）应按其权重比例分配资源。例如，如果数据流 A 的权重为 12，其同级数据流 B 的权重为 4，那么要确定每个数据流应接收的资源比例，请执行以下操作：

将所有权重求和：4 + 12 = 16
将每个数据流权重除以总权重：A = 12/16, B = 4/16因此，数据流 A 应获得四分之三的可用资源，数据流 B 应获得四分之一的可用资源；数据流 B 获得的资源是数据流 A 所获资源的三分之一。我们来看一下上图中的其他几个动手示例：顺序为从左到右：
数据流 A 和数据流 B 都没有指定父依赖项，依赖于显式“根数据流”；A 的权重为 12，B 的权重为 4。因此，根据比例权重：数据流 B 获得的资源是 A 所获资源的三分之一。
数据流 D 依赖于根数据流；C 依赖于 D。因此，D 应先于 C 获得完整资源分配。权重不重要，因为 C 的依赖关系拥有更高的优先级。
数据流 D 应先于 C 获得完整资源分配；C 应先于 A 和 B 获得完整资源分配；数据流 B 获得的资源是 A 所获资源的三分之一。
数据流 D 应先于 E 和 C 获得完整资源分配；E 和 C 应先于 A 和 B 获得相同的资源分配；A 和 B 应基于其权重获得比例分配。

如上面的示例所示，数据流依赖关系和权重的组合明确表达了资源优先级，这是一种用于提升浏览性能的关键功能，网络中拥有多种资源类型，它们的依赖关系和权重各不相同（比如在一个网页上，我们应该先优先保障加载文本资源，然后再是图片和视频）。不仅如此，HTTP/2 协议还允许客户端随时更新这些优先级，进一步优化了浏览器性能。换句话说，我们可以根据用户互动和其他信号更改依赖关系和重新分配权重。

每个来源一个连接

这个是http/2协议所带来的重大性能提升。有了新的分帧机制后，HTTP/2 不再依赖多个 TCP 连接去并行复用数据流；每个数据流都拆分成很多帧，而这些帧可以交错，还可以分别设定优先级。因此，所有 HTTP/2 连接都是永久的，而且仅需要每个来源一个连接，随之带来诸多性能优势。（有一个问题。连接都是永久的，是不是一直会占用一部分链路资源？）

大多数 HTTP 传输都是短暂且急促的，而 TCP 则针对长时间的批量数据传输进行了优化。通过重用相同的连接，HTTP/2 既可以更有效地利用每个 TCP 连接，也可以显著降低整体协议开销。不仅如此，使用更少的连接还可以减少占用的内存和处理空间，也可以缩短完整连接路径（即，客户端、可信中介和源服务器之间的路径）这降低了整体运行成本并提高了网络利用率和容量。因此，迁移到 HTTP/2 不仅可以减少网络延迟，还有助于提高通量和降低运行成本。

连接数量减少对提升 HTTPS 部署的性能来说是一项特别重要的功能：众所周知建立基于TLS的http连接非常耗时，http/2可以减少开销较大的 TLS 连接数、提升会话重用率，以及从整体上减少所需的客户端和服务器资源

流控制

流控制是一种阻止发送方向接收方发送大量数据的机制，以免超出接收方的需求或处理能力：发送方可能非常繁忙、处于较高的负载之下，也可能仅仅希望为特定数据流分配固定量的资源。例如，客户端可能请求了一个具有较高优先级的大型视频流，但是用户已经暂停视频，客户端现在希望暂停或限制从服务器的传输，以免提取和缓冲不必要的数据。再比如，一个代理服务器可能具有较快的下游连接和较慢的上游连接，并且也希望调节下游连接传输数据的速度以匹配上游连接的速度来控制其资源利用率；等等。

上述要求会让您想到 TCP 流控制吗？您应当想到这一点；因为问题基本相同（请参阅流控制）。不过，由于 HTTP/2 数据流在一个 TCP 连接内复用，TCP 流控制既不够精细，也无法提供必要的应用级 API 来调节各个数据流的传输。为了解决这一问题，HTTP/2 提供了一组简单的构建块，这些构建块允许客户端和服务器实现其自己的数据流和连接级流控制：

流控制具有方向性。每个接收方都可以根据自身需要选择为每个数据流和整个连接设置任意的窗口大小。
流控制基于信用。每个接收方都可以公布其初始连接和数据流流控制窗口（以字节为单位），每当发送方发出 DATA 帧时都会减小，在接收方发出 WINDOW_UPDATE 帧时增大。
流控制无法停用。建立 HTTP/2 连接后，客户端将与服务器交换 SETTINGS 帧，这会在两个方向上设置流控制窗口。流控制窗口的默认值设为 65,535 字节，但是接收方可以设置一个较大的最大窗口大小（2^31-1 字节），并在接收到任意数据时通过发送 WINDOW_UPDATE 帧来维持这一大小。
流控制为逐跃点控制，而非端到端控制。即，可信中介可以使用它来控制资源使用，以及基于自身条件和启发式算法实现资源分配机制。

HTTP/2 未指定任何特定算法来实现流控制。不过，它提供了简单的构建块并推迟了客户端和服务器实现，可以实现自定义策略来调节资源使用和分配，以及实现新传输能力，同时提升网络应用的实际性能和感知性能。

例如，应用层流控制允许浏览器仅提取一部分特定资源，通过将数据流流控制窗口减小为零来暂停提取，稍后再行恢复。换句话说，它允许浏览器提取图像预览或首次扫描结果，进行显示并允许其他高优先级提取继续，然后在更关键的资源完成加载后恢复提取。

服务器推送

之前介绍过，HTTP/1.1无法从服务器主动推送信息给客户端，而这是HTTP/2 新增的另一个强大的新功能，服务器可以对一个客户端请求发送多个响应。换句话说，除了对最初请求的响应外，服务器还可以向客户端推送额外资源，而无需客户端明确地请求。

为什么在浏览器中需要一种此类机制呢？一个典型的网络应用包含多种资源，客户端需要检查服务器提供的文档才能逐个找到它们。那为什么不让服务器提前推送这些资源，从而减少额外的延迟时间呢？服务器已经知道客户端下一步要请求什么资源，这时候服务器推送即可派上用场。

事实上，如果您在网页中内联过 CSS、JavaScript，或者通过数据 URI 内联过其他资产（请参阅资源内联），那么您就已经亲身体验过服务器推送了。对于将资源手动内联到文档中的过程，我们实际上是在将资源推送给客户端，而不是等待客户端请求。使用 HTTP/2，我们不仅可以实现相同结果，还会获得其他性能优势。推送资源可以进行以下处理：

由客户端缓存
在不同页面之间重用
与其他资源一起复用
由服务器设定优先级
被客户端拒绝

PUSH_PROMISE 101

所有服务器推送数据流都由 PUSH_PROMISE 帧发起，表明了服务器向客户端推送所述资源的意图，并且需要先于请求推送资源的响应数据传输。这种传输顺序非常重要：客户端需要了解服务器打算推送哪些资源，以免为这些资源创建重复请求。满足此要求的最简单策略是先于父响应（即，DATA 帧）发送所有 PUSH_PROMISE 帧，其中包含所承诺资源的 HTTP 标头。

在客户端接收到 PUSH_PROMISE 帧后，它可以根据自身情况选择拒绝数据流（通过 RST_STREAM 帧）。（如果资源已经位于缓存中，可能会发生这种情况。）这是一个相对于 HTTP/1.x 的重要提升。相比之下，使用资源内联（一种受欢迎的 HTTP/1.x“优化”）等同于“强制推送”：客户端无法选择拒绝、取消或单独处理内联的资源。

使用 HTTP/2，客户端仍然完全掌控服务器推送的使用方式。客户端可以限制并行推送的数据流数量；调整初始的流控制窗口以控制在数据流首次打开时推送的数据量；或完全停用服务器推送。这些优先级在 HTTP/2 连接开始时通过 SETTINGS 帧传输，可能随时更新。

推送的每个资源都是一个数据流，与内嵌资源不同，客户端可以对推送的资源逐一复用、设定优先级和处理。浏览器强制执行的唯一安全限制是，推送的资源必须符合原点相同这一政策：服务器对所提供内容必须具有权威性。

标头压缩

每个 HTTP 传输都承载一组标头，这些标头说明了传输的资源及其属性。在 HTTP/1.x 中，此元数据始终以纯文本形式，通常会给每个传输增加 500–800 字节的开销。如果使用 HTTP Cookie，增加的开销有时会达到上千字节。（请参阅测量和控制协议开销。）为了减少此开销和提升性能，HTTP/2 使用 HPACK 压缩格式压缩请求和响应标头元数据，这种格式采用两种简单但是强大的技术：