5G核心网技术基础自学系列 | 超文本传输协议

Posted 2023-01-26 COCOgsta

书籍来源：《5G核心网 赋能数字化时代》

一边学习一边整理内容，并与大家分享，侵权即删，谢谢支持！

附上汇总贴：5G核心网技术基础自学系列 | 汇总_COCOgsta的博客-CSDN博客

---

14.4.1 介绍

当今世界，人们熟悉互联网，因此用于互联网的超文本传输协议（HTTP）可能是知名的协议之一。HTTP是互联网数据通信的基础，用于“浏览Web”，提供网页的访问，其中的超链接指向其他资源，用户可以通过单击鼠标或点击屏幕轻松地访问这些资源。

HTTP是3GPP核心网络协议家族中的新成员，至少从3GPP控制面接口来看。虽然2G/3G/4G控制面在核心网络中高度依赖于GTP-C、MAP和Diameter，但5GC的控制面几乎完全依赖于HTTP。

在本节中，我们将简要介绍HTTP和HTTP如何应用在5GC的一些方面。互联网上有很多相关的教程，有兴趣的读者也可以从这些教程获取更详细的信息。

HTTP被定义为应用协议，用于分发并访问超媒体信息。HTTP的开发始于20世纪80年代末和20世纪90年代初的万维网初期，在CERN进行。HTTP的第一个记录的版本是HTTP v0.9（1991年），随后是HTTP 1.0（1996年）和HTTP 1.1（1997年）。后来的几年中，对HTTP 1.1进行了改进、澄清和更新。HTTP 1.1是第一个在互联网上普遍使用的版本，至今仍广泛使用。新版本HTTP/2已于2015年在IETF RFC 7540中进行了标准化，这是3GPP用于5GC控制面的版本。以下描述的大多数功能是HTTP 1.1和HTTP/2所共有的，但是有些3GPP所使用的功能是由HTTP/2引入的。

HTTP/2的主要目标是提高性能，以便为Web用户提供更好的体验。与HTTP 1.1相比，HTTP/2的主要优点是：支持请求和响应的完全多路复用，支持HTTP标头字段的压缩以最大限度地减少协议开销，以及支持请求优先级和服务器推送。可以注意到的是，HTTP/2没有修改HTTP的应用语义，下面描述的所有基本概念（例如HTTP方法、状态代码、URI和标头字段）都将保留。HTTP/2所做的是修改（改进）消息中携带信息的格式，以及信息在客户端和服务器间传输的方式，修改的格式对应用层并不可见。

14.4.2 基本原理

HTTP是在客户端和服务器之间运行的请求 - 响应协议，承载在TCP传输层上，确保可靠的传输。HTTP 1.1也可以通过其他传输协议进行传输，但是HTTP/2被规定只能通过TCP进行传输。3GPP已经讨论过将HTTP与QUIC传输一起使用（通过QUIC传输的HTTP也称为HTTP/3），但对于3GPP Release 15来说，QUIC还不够成熟，因而还没被3GPP采纳。与此同时，基于QUIC的HTTP的使用正在研究当中，可能在未来的3GPP 版本中被采纳。

HTTP的协议栈如图14.5所示。传输层安全性可选使用TLS保护客户端和服务器之间的HTTP通信，承载在TLS上的HTTP也称为HTTPS。TLS 在1.5节中进一步介绍。

图14.5 HTTP协议栈

当HTTP客户端要与服务器进行通信时，首先会建立与服务器上特定端口间的TCP连接。HTTP的默认端口为80。而HTTPS的默认端口为443。在5G核心网中，提供服务的NF（即充当HTTP服务器）可以在NRF中注册服务提供者的FQDN或IP地址和端口。使用服务的NF（即充当HTTP客户端的实体）可以从NRF中找到提供某一服务的服务器的FQDN，或者IP地址和可选的端口号。如果服务提供者NF没有在NRF中注册任何端口号，那么服务使用者将使用HTTP和HTTPS的默认端口号。

一旦建立了TCP连接，客户端就可以通过该TCP连接向服务器发送HTTP请求。单个TCP连接上可发送多个未完成的HTTP请求，这是HTTP/2的主要优势之一，因为它提高了在单个TCP连接上多路复用HTTP请求/响应对的可能性，与HTTP 1.1相比，HTTP/2使用的TCP连接数量更少。可以提一下的是，HTTP 1.1支持一个称为“管道化”的功能，该功能允许某种程度的多路复用，但具有严重的局限性，不如HTTP/2强大。

14.4.3 HTTP消息、方法、资源和URI

如上所述，HTTP协议遵循请求/响应模式。客户端向服务器发送请求，服务器发送响应。当今互联网的一种常见用例是：客户端是Web浏览器，服务器是运营在数据中心的计算机上的Web服务器。在5GC中，客户端和服务器都是5GC中的NF。图14.6说明了一个简单的HTTP交换。

图14.6 简单HTTP交换

HTTP请求的目标称为“资源”，由服务器提供。资源可以代表很多内容，但HTTP协议没有对其进行更详细的定义。针对网络浏览，资源可以是网页、文档或照片。在3GPP 5GC中，对SMF提供的服务而言，资源可以是PDU会话； 对PCF提供的服务而言，资源可以是策略会话； 对UDM提供的服务而言，资源可以是签约数据。每个资源由统一资源标识符（URI）来标识，URI的一种非常常见的形式是统一资源定位符（URL），它是URI的一种特殊类型，既标识资源，同时提供有关如何访问该资源的信息，比如使用诸如HTTP协议（如www.3gpp.org）来访问资源。

在5GC中，请求消息中的URI唯一标识服务提供者NF中的资源，基于服务接口的绝对URI具有以下结构：

apiRoot/apiName/apiVersion/apiSpecificResourceUriPart

我们将简要描述URI的每个部分并给举例说明。

“apiRoot”由如下几个部分串联起来：

• 方案（“http”或“https”）
• 固定字符串“://”
• 主机和可选端口（所谓的“授权”）
• 以“/”字符开头的可选的与部署相关的字符串（即API前缀）

“apiName”定义API的名称，“apiVersion”指示API的版本。“apiRoot”“apiName”和“apiVersion”合在一起定义了API的基本UR，然后每个“apiSpecificResourceUriPart”定义了相对于基本URI的资源URL。“apiSpecificResourceUriPart”的结构和内容因服务类型而异，例如对UDM而言，客户端NF向UDM发送的获取“已配置”资源（例如签约数据）的请求时，使用的URI包括SUPI，这个URI看起来像“udm1.operatorX.com/nudm-sdm/v1…

服务器在接收到HTTP请求之后，如果有权访问资源，将解析该请求并可以代表客户端执行功能，然后将响应消息返回给客户端。该响应包括这次交互的状态信息，通常包含所请求的内容（表示所请求的资源）。

在客户端发送的HTTP请求中，客户端通过URI描述了目标资源，并且还描述了客户端请求对该资源执行的特定动作，这些动作称为“HTTP方法”。通常在互联网上用于浏览Web的一种简单的HTTP方法是GET。客户端使用GET方法向服务器请求特定文档（资源），服务器在回复消息中将该文档（资源）发送给客户端。GET方法不会以任何方式修改资源。GET方法是HTTP早期历史中最早定义的方法之一，后来又添加了其他几种方资法，下面简要介绍：

GET：请求指定资源。使用GET的请求应该只用于获取数据，而对资源没有其他影响。

HEAD：只请求资源，这点与GET相似，但只请求资源的描述，而不是实际的内容。如果客户端只想了解资源的类型而不需要完整的内容，这个方法可能很有用。（到目前为止，5GC的API没有使用HEAD方法。）

PUT：要求服务器将来自客户端请求中的内容存储在提供的URI下。如果URI指向服务器上已经存在的资源、那么PUT将修改该资源； 如果URI没有指向任何现有资源，则服务器可以使用该URI创建资源。

POST：要求服务器获取客户端请求中携带的内容，并在URI标识的资源下对其进行修改。在互联网设置中，请求中的内容可能是例如对新闻文章的评论、Web表单的数据或要添加到线上数据库的事项。

PATCH：对资源进行部分修改。

DELETE：删除指定的资源。

TRACE：回显收到的请求，以便客户端可以看到中间服务器或代理进行了哪些更改。（到目前为止，5GC的API没有使用TRACE方法。）

OPTIONS：回复有关通信能力的信息。例如，对特定的URL而言，服务器支持哪些HTTP方法，可用于了解HTTP服务器支持的功能。

CONNECT：将请求连接转换为透明的TCP/IP隧道，通常有助于通过HTTP代理进行加密通信（HTTPS）。

14.4.4 RESTful设计

3GPP的目标是根据REST“样式”定义5GC的所有服务。“REST”（“代表性状态转移”的缩写）是Roy T.Fielding在2000年的论文中提出的一种软件体系结构样式，它定义了一组软件设计规则，用于设计计算机系统在互联网上的互操作性。RESTful Web服务使用统一的预定义的无状态操作，使系统能访问和操纵基于Web的资源的文本表示形式。RESTful设计的原理如下所列。3GPP TS 29.891中对这些原理进行了适应性改变，以适应5GC的使用要求。实际上，现有的声称是RESTful的API在不同程度上遵循了这些原则，3GPP的API设计同样如此。如下所述，不同的原则或多或少适用于5GC。

1）客户端/服务器：这是指客户端和服务器之间的职责划分，其中客户端将请求发送到服务器，服务器处理请求并返回响应。这样的划分使得不同的任务可以分开，例如从数据存储中生成用户界面，这样简化了单个任务并增强了可移植性和可伸缩性。

在5GC中，由于将服务定义为服务提供者NF向使用者NF提供服务，因此在很大程度上应用了客户端/服务器模式。但是，服务还可以包括从服务器到客户端的异步通知或请求，这样的模式下服务器和客户端的请求/响应角色正好相反，因此可以将其单独建模。

2）无状态：从客户端到服务器的每个请求必须包含能让服务器理解该请求的所有的必要信息，因此会话状态完全保留在客户端上，服务器不保留先前请求的历史记录/内存。服务器可以将会话状态转移到另一个服务，例如数据库，在一段时间内保持持久的会话状态。不同的服务器可以满足不同的请求，从而提高可靠性和可伸缩性。

5GC仅部分满足了“无状态”原则。在5GC中，一个假设是选择的服务器（NF）保有和资源关联的状态信息，例如，SMF将保有PDU会话的状态，AMF将保有UE移动性上下文的状态，PCF将保有活动的策略会话的状态等，但是这些是应用层状态，而底层的HTTP协议仍然可以是无状态的。

3）可缓存的：如果响应是可缓存的，则客户端可以缓存响应，并在以后将响应数据重新用于相同的请求，这使得可以避免某些交互，同样可以提高效率、改善可伸缩性和平均时延。

在5GC中，除了NRF服务外，其他服务实际上并没有满足该原则。5GC中的大多数交互都与可能频繁更改的资源有关，例如与UE移动性有关，或与用户使用某应用有关，因此，缓存相关的响应几平没有好处。NRF的响应是个例外，NF可以缓存NRF响应。

4）统一接口：基于REST的接口以资源标识为基础，允许通过这些资源的表示来操纵资源。在请求中使用URI标识各个资源。资源本身在概念上与返回给客户端的表示形式是分开的，因此，消息是自描述的，例如通过MIME类型指示格式。

通过使用统一的接口，简化了整个系统架构，并改善了交互的可见性。接口的实现也与它们提供的服务脱钩，促进了独立演进的可能。但是，统一接口有利也有弊，与那些为某个应用的特定需求进行了优化的接口相比，统一（通用）的接口通常会对效率产生负面影响。

在5GC中，在开始定义每个特定NF的服务之前，3GPP对NF服务的通用设计规则达成了一致，因此已在相当高的程度上满足了统一接口原则。通用设计原理、通用数据类型等可以在3GPP TS 29.500、3GPP TS 29.501和3GPP TS 29.571中找到。

5）分层系统：系统由不同的结构层组成，每个层组件的行为受到限制，使得这些组件无法“看到”与它们交互的直接层之外的内容。中间服务器可以通过启用负载平衡和提供共享缓存来提高系统的可伸缩性。客户端不在乎服务器如何提供响应。

在5GC中，已高度满足了该原则，即服务使用者NF不了解服务提供者NF如何提供响应。

6）按需代码（可选）：REST允许通过以小程序或脚本的形式下载并执行代码来扩展客户端功能。通过减少需要在客户端上预先实现的功能数量，简化了客户端。

3GPP不满足该原则。在3GPP技术规范中指定了5G核心网的NF行为，包括客户端和服务器端的，无须将可执行代码从NF提供者下载到NF使用者。

14.4.5 HTTP协议格式

HTTP 1.1和HTTP/2消息的协议格式有很大的不同，但是从较高的层面来看，它们遵循相似的语义，它们都有信元，这些信元携带所用的HTTP方法的信息、与请求或响应有关的其他参数以及与资源有关的可选内容，但是，HTTP 1.1和HTTP/2的术语和格式有所不同。下面我们将重点介绍一些差异，但由于HTTP/2是5GC中使用的版本，因此将描述的重点放在HTTP/2上。

HTTP 1.1消息的编码是可读的纯文本消息，不同信元（协议帧）间的分隔符也使用纯文本字符（例如空格、换行符、回车等）。HTTP/2则使用二进制协议帧，即不同信元间的分隔符使用二进制参数。HTTP/2还支持头压缩，以实现更有效的传输。与纯文本协议相比，二进制帧的协议具有某些优势，比如接收端的解析二进制帧的效率更高，接口传送二进制帧更紧凑（需要更少的IP数据包）。与文本协议（如HTTP1.1）相比，二进制帧也更不容易出错，因为它们不需要关心空格处理、大写、行尾、空白行等。但是，HTTP/2的HTTP头仍然使用文本进行编码，除非使用了头压缩。

HTTP/2消息是一个或两个HEADERS帧（用于承载HTTP头）、零个或多个DATA帧（用于承载与资源有关的实际内容）和一个可选的终结HEADERS帧（承载HTTP尾部）的组合。在HTTP 1.1中，这些部分称为标头部分和消息主体部分。

请求和响应消息始终包含HTTP/2标头的HEADERS帧，但是DATA帧仅在需要时才包含。

请求消息：

• 请求消息的HEADERS帧包括HTTP头字段和承载请求信息的所谓伪头字段。伪头字段包含HTTP方法以及目标资源（在HTTP 1.1中，这些信息包含在单个“请求行”中）。例如，在HTTP/2中要请求网页“www.3gpp.org/specificati…

  • 指示GET的“:method”伪头字段。
  • 指示“https”的“:scheme”伪头字段。
  • 包含“www.3gpp.org”的“:host”伪头字段。
  • 包含“/specifications”的“:path”伪头字段。

• 举一个5GC的例子，如果要从UDM为IMSI=1234567890的SUPI获取SM签约数据，要包含以下伪头字段：
• • “:method”表示GET。
  • “:scheme”，表示“https”。
  • “:host”，包含“udm1.operatorX.com”。
  • “:path”，包括“/nudm-sdm/v1/imsi-1234567890/sm-data”。

• HEADERS帧也可以包括HTTP头字段，该头字段包含的参数进一步描述请求。这些标头字段可以指示响应中可接受的语言、可接受的响应的编码、消息主体的内容类型和内容长度（如果包括）等。
• 请求的DATA帧可能包括要提供给服务器的内容，用于如PUT和POST方法。

响应消息：

• 响应消息包括带有“:status”伪头字段的HEADERS帧，该字段包含HTTP状态码字段。该伪头字段包含在所有响应消息中，例如“200 OK”，表示客户端的请求成功，或“400错误的请求"，表明例如由于格式错误的请求而无法处理该请求。与请求消息类似，响应消息的头框架还包括其他HTTP头字段，这些字段进一步描述了响应。这里最常见的标头字段是描述主体的标头字段，例如内容类型（MIME类型）、内容编码、内容长度、内容语言等。
• DATA帧包含服务器提供的内容，即一个请求资源的表示形式，如上面两个例子中的网页或SM（会话管理）签约数据。

图14.7所示的是使用GET方法的HTTP/2请求 - 响应的例子。

图14.7 HTTP GET方法示例

14.4.6 序列化协议

HTTP主体可以包含不同类型的信息，包括纯文本部分和二进制部分。HTTP也足够灵活，可以在主体内携带不同类型的内容。在互联网上，它通常携带文本、图片、音频等。HTTP标头字段Content-Type（内容类型）用于描述主体中包含的内容； 在单个HTTP 主体中也可以携带多种不同的内容类型。在5GC中出现的一个问题是，需要在NF之间携带结构化的3GPP特定的信元，比如3GPP参数（如SUPI、DNN、S-NSSAI等）的列表，或更复杂结构的参数（如UE签约数据）。为了在HTTP主体中携带此类信息，需要对其进行编码，编码的方式使得发送方在HTTP主体中生成的内容可以被接收方解析并提取各个信元。这些结构化的信元最好也能以纯文本格式进行编码，因为与二进制相比，文本更容易阅读，也更容易转换。为此，需要执行所谓的数据序列化，即以HTTP主体可以携带的文本格式来描述如会话管理信息、签约数据和策略规则等的结构化数据。此处的“序列化”是一种方法，它将一组结构化的3GPP数据类型转换为可包含在HTTP主体中的文本对象。

3GPP已同意使用JSON（javascript对象表示法）作为序列化格式。JSON在IETF RFC 8259中进行了描述，允许使用指定的数据类型（例如字符串、数字或数组）以文本格式将数据对象作为属性值对进行传输。下面举例说明AMF发送HTTP请求到UDM，注册为服务于某个UE的AMF。

在HTTP中，也可能需要携带二进制元素，例如AMF和SMF之间的SM NAS消息。如果HTTP消息由多部分组成，HTTP主体中的二进制部分的内容使用3GPP供应商特定的内容类型，HTTP主体中的JSON部分包含纯文本可读信元，以及对二进制数据部分的引用。

例如，当终端建立新的PDU会话时，AMF将把SM NAS消息以及附加信息（如SUPI、请求的DNN、请求的S-NSSAI、UE位置信息等）转发到SMF，这些信息携带在使用POST方法的请求消息的HTTP主体中，其中一部分由JSON编码作为“属性值对"提供，另一部分是二进制数据。从AMF到SMF的HTTP请求如下例所示：

14.4.7 接口定义语言

定义HTTP API时，通常使用接口定义语言（IDL）来描述。IDL是一种规范性的语言，支持使用正式规则来描述API，以便对资源、操作、信息元素、数据结构、数据格式等进行清晰的规范。如果HTTP请求和响应消息使用有很少正式规则的普通英语来描述，可能会出现歧义，使用IDL来正式描述API有助于避免歧义，因此，IDL的好处是可以避免因不同供应商对标准的不同解读而引起的产品互操作性问题。

IDL和供应商无关，也和实现实际产品中的API所使用的计算机编程语言无关，因此IDL适合定义API，也适合定义不同软件之间的交互，这些软件可以由不同供应商以不同程语言编写。由于IDL是具有特定结构的正式语言，因此它也可以成为软件开发中的工具，实际上它可以用于生成部分代码。

3GPP决定使用OpenAPI版本3作为IDL，来规范基于HTTP的服务。OpenAPI规范（OAS）用于正式描述RESTful API，语言本身由Linux基金会下属的组织OpenAPI Initiative（OAI）指定。使用OpenAPI的API描述可包括下列信息：

• API的通用信息。
• 使用的资源，即URI中的路径。
• 每个资源可用的方法（例如GET）。
• 每个方法和资源支持的输入和输出参数，它们的数据类型（如整数、字符串）等。

可以说，OpenAPI是关于如何指定API的规范。API的Open API规范是用可读的文本文件编写的，可以用JSON或YAML来表述API规范。3GPP之所以选择YAML作为其基于服务的接口的规范，主要是因为YAML比JSON更易于人们读写，但是，用YAML和JSON表述的OpenAPI规范几乎是等价的。

NF服务的YAML描述作为附件包括在相应的TS中（例如，AMF服务包括在3GPP TS 29.518中），YAML描述也作为单独的文件，和TS一起发布。NF服务的YAML规范往往很冗长，因为它们需要描述NF服务的所有NF服务操作以及所有支持的输入和输出参数、参数格式以及可能的参数值等。以下所示的YAML文件描述设备身份寄存器（EIR）提供的服务（包括在3GPP TS 29.511中），可能是3GPP定义的最简单的例子，此NF只提供一个服务和一个服务操作。