引言

PostgreSQL 使用基于消息的协议在前端（也可以称为客户端）和后端（也可以称为服务器）之间进行通信。该协议通过 TCP/IP 和 Unix 域套接字支持。

《深度解析 PostgreSQL Protocol v3.0》系列技术贴，将带大家深度了解 PostgreSQL Protocol 3.0 版本（在 PostgreSQL 7.4 及更高版本中实现，有关早期协议版本的描述请参考 PostgreSQL 文档的早期版本，该系列文章不予赘述）相关的消息传输格式和格式码、消息支持的数据类型、消息的格式、协议交互流程、错误消息和通知消息、支持的子协议等，相关的代码解读基于 PostgreSQL 代码仓库的 REL_14_STABLE 分支。

PostgreSQL 单个服务器可以支持多个协议版本，可以接收和处理多个不同版本协议的客户端的请求消息。初始启动请求消息告诉服务器、客户端尝试使用的协议版本：

如果客户端请求的主要版本不受服务器支持，则连接将被拒绝（例如，如果客户端请求协议版本 4.0，而服务器端支持的协议版本不存在 4.0，此时就会发生这种情况）；

如果服务器不支持客户端请求的次要版本（例如，客户端请求版本为 3.1，但服务器仅支持 3.0，不支持 3.1 版本，此时就会发生这种情况），则服务器可以拒绝连接，或者可以使用包含其支持的最高次要协议版本的 NegotiateProtocolVersion 消息进行响应。

客户端可以选择使用服务器端指定的协议版本继续连接或中止连接。为了高效地为多个客户端提供服务，服务器为每个客户端启动一个新的进程进行请求处理。在当前实现中，在服务器检测到客户端的 Socket 连接后立即创建新的子进程进行后续的处理，比如 SSL 通信加密协商、启动消息、身份认证等流程。

一、消息传输的格式

客户端和服务器所有的交互都是通过消息流进行的。每一条消息主要由三部分组成：

• 消息类型

用于标记消息的类型，是单个字符或者 1 位的数字。消息类型长度占用 1 个字节。

• 消息长度

消息中除了消息类型之外的字节长度。消息长度占用 4 个字节。消息长度的值包含了消息长度本身的 4 个字节长度。计算方法：

（1）消息字节总长度减去 1 字节的消息类型的长度；

（2）消息内容字节总长度加上消息长度本身占用的字节数 4。

• 消息体

消息的具体 payload 内容，例如简单查询的 SQL 内容。

需要注意的是，由于历史原因，客户端发送的第一条消息（启动消息）没有消息类型的 1 个字节。服务器和客户端为了避免与消息流失去同步，通常在尝试处理消息内容之前将整个消息读入缓冲区（使用字节计数）。

如果在处理消息内容时检测到错误，就可以轻松恢复。在极端情况下（例如没有足够的内存来缓冲消息），接收器可以使用字节计数来确定在恢复读取消息之前要跳过多少输入字节长度。服务器和客户端都必须注意不要发送不完整的消息。这通常是通过在开始发送之前在缓冲区中编码整个消息来完成的。

如果在发送或接收消息的过程中发生通信故障，那么唯一明智的做法是断开连接，因为恢复消息边界同步的希望很小。

二、消息支持的数据类型

PostgreSQL Protocol v3.0 的消息中支持的数据类型只有以下 4 种：

• Intn(i)

n 位二进制表示的整数，为网络字节顺序（最高有效字节优先，MSB），n 表示该值占用的位数。

如果指定了 i，则 i 是将出现的确切值；如果未指定 i 值，该值是可变的。例如，Int16 表示一个值未指定的占用 16 位二进制位的整数（占用长度为 2 个字节，占用 16 位二进制）；Int32(42)表示一个值为 42 的占用 32 位二进制位的整数（占用长度为 4 个字节，占用 32 位二进制）。

• Intn[k]

由 k 个 n 位二进制表示的整数组成的数组。数组长度 k 始终由消息中较早的字段确定。

• String(s)

以空结尾的字符串（C-style 字符串）。字符串没有特定的长度限制。

如果指定了 s，则 s 是将出现的确切值；如果未指定 s 值，该值是可变的。例如，String 表示一个值未指定的字符串；String(“user”)表示值为 user 的字符串。

需要注意的是，服务器可以返回的字符串长度没有预定义长度的限制，因此客户端比较好的编码策略是使用可扩展缓冲区，以便可以接收适合内存大小的内容。如果这不可行，请读取整个字符串并丢弃不适合固定大小缓冲区的尾随字符。

• Byten©

n 个字节。如果字段宽度 n 不是常数，则它总是可以从消息中较早的字段确定。如果指定了 c，则 c 为该字段的精确值。例如，Byte2 表示值未指定的 2 个字节，Byte1(’\n’)表示值为’\n’的 1 个字节。

除了以上四种数据类型，其他数据类型在 PostgreSQL Protocol v3.0 的消息中均不支持。

三、消息传输的格式和格式码

在 Postgresql Protocole 中，特定数据类型的数据可以用几种不同格式中的任何一种传输。

从 PostgreSQL 7.4（PostgreSQL Protocol v3.0）开始，协议支持的数据传输支持的格式是 text（文本）和 binary（二进制），该协议为将来的扩展做好了准备。任何值传输的格式由格式代码指定。

客户端可以为每个传输的参数值和查询结果的每一列指定格式代码。text 的格式代码为 0，binary 的格式代码是 1，所有其他格式代码都保留以供将来定义。

值的 text 表示是输入/输出转换函数为特定数据类型生成/接受的字符串。在传输 text 的表示中，没有结尾空字符；如果客户端想要将接收到的值作为 C 风格字符串处理，则客户端必须自行将其加 1 个空字符。需要注意的是，text 传输格式的值不允许内嵌空字符。

整数的 binary 表示使用网络字节顺序（最高有效字节优先，MSB）。

值得特别注意的是，复杂数据类型的 binary 表示可能会在服务器版本之间发生变化；因此 text 格式通常是更便携更通用的选择。

四、消息的交互流程

PostgreSQL Protocol v3.0 的交互流程主要包括以下几种流程：

1. 启动流程

要开始会话，客户端将打开与服务器的连接并发送启动消息 StartupMessage。启动消息包括用户的名称、用户想要连接到的数据库的名称和要使用的特定协议版本（启动消息可以包括运行时参数的其他设置，但是这些参数都是可选的）。

接着，服务器使用这些信息及其配置文件（如 pg_hba.conf）的内容来确定连接是否暂时可接受，以及需要什么附加身份验证（如果有的话）。

然后，服务器发送适当的身份验证请求消息，客户端必须用适当的身份认证响应消息（如密码）回复该消息。

对于除 GSSAPI、SSPI 和 SASL 之外的所有身份验证方法，最多只有一个请求和一个响应。在某些方法中，客户端不需要响应，因此不会发生身份验证请求。对于 GSSAPI、SSPI 和 SASL，可能需要多次交换数据包才能完成身份验证。

2. 简单查询流程

一个简单查询的周期由客户端端向服务器端发送查询消息来启动。该消息包括一个以文本字符串表示的 SQL 命令。然后，服务器根据查询命令字符串的内容进行执行，执行完成发送一条或多条响应消息，最后发送 ReadyForQuery 响应消息。

ReadyForQuery 通知客户端，可以安全地发送新命令。（客户端实际上不需要在发出另一个命令之前等待 ReadyForQuery，但客户端必须负责弄清楚如果前一个命令失败，而已经发出的后一个命令成功，会发生什么情况。因此，建议的做法是客户端接收到 ReadyForQuery 消息之后再发送新命令。）

简单查询的交互流程中，也会出现一些异常情况，会得到异常的响应。例如，查询 SQL 为空字符串，则响应为 EmptyQueryResponse，后跟 ReadyForQuery。发生错误时，发出 ErrorResponse，然后发出 ReadyForQuery。ErrorResponse 会中止对查询字符串的所有进一步处理。

3. 扩展查询

扩展查询协议将上述简单查询协议分解为多个步骤。为了提高效率，可以多次重复使用 Prepare 步骤的结果。

此外，还提供了其他功能，例如可以将数据值作为单独的参数提供，而不必将它们直接插入到查询字符串中。扩展查询一般需要经过 Parse, Bind 和 Execute 步骤，中间有一些可选步骤如 Describe，Close 和 Flush。

4. Pipelining

扩展查询协议的使用允许流水线，这意味着发送一系列查询而无需等待较早的查询完成。流水线减少了完成给定系列操作所需的网络往返次数。

但是，如果其中一个步骤失败，用户必须仔细考虑所需的处理，因为稍后的查询已经在发送到服务器。

5. 函数调用（Function Call）流程

函数调用(Function Call)子协议允许客户端请求直接调用数据库的 pg_proc 系统目录中存在的任何函数。客户端必须具有函数的执行权限。

函数调用子协议是一个较早版本的遗留功能，在新代码/新版本中最好避免使用。类似的结果可以通过设置执行 SELECT function($1, …)的准备语句的值来实现。然后可以用 Bind/Execute 代替函数调用周期。

函数调用周期由客户端向端发送 FunctionCall 消息来启动。服务端根据函数调用的结果发送一条或多条响应消息，最后发送 ReadyForQuery 响应消息。ReadyForQuery 通知客户端它可以安全地发送新的查询或函数调用。

6. 取消执行中的请求流程

在处理查询期间，客户端可能会请求取消查询。出于实现效率的原因，取消请求不会直接通过正在执行查询的连接发送到服务端：不希望服务端在查询处理过程中不断检查来自客户端的新输入。取消请求应该是相对较少的，所以我们让取消流程稍微麻烦一些，以避免在正常情况下发生错误。

要发出取消请求，客户端应该打开到服务器的新连接并发送一条 CancelRequest 消息，而不是通常通过新连接发送的 StartupMessage 消息。服务器将处理此请求，然后关闭连接。出于安全原因，不直接回复取消请求消息。

7. 结束流程

正常、友好的终止过程是客户端发送 Terminate 终止消息并立即关闭连接。服务端收到此 Terminate 消息后，关闭连接并终止。

在极少数情况下（如管理员通过命令关闭数据库），服务器端可能会在没有任何客户端请求的情况下断开连接。在这种情况下，服务器端将尝试在关闭连接之前发送错误或通知消息，给出断开连接的原因。

8. COPY 操作

COPY 命令允许客户端与服务器之间进行高速批量数据传输。COPY IN 和 COPY OUT 操作都会将连接切换到不同的子协议中，该子协议将持续到操作完成。

COPY IN 是将数据从客户端传输到服务器端，COPY OUT 是将数据从服务器端传输到客户端。还有另一种与 COPY 相关的模式，称为“双向复制”，它允许客户端与服务器之间的双向高速批量数据传输。

9. 异步操作

有几种情况下，服务器端将向客户端发送客户端命令没有特别请求的消息。客户端必须随时准备好处理这些消息，即使这些消息不是为了响应查询请求。

因此，客户端在开始读取查询响应之前，至少应该检查这些情况。服务端异步发送给客户端的消息主要有两种类型：NoticeResponse 消息和 ParameterStatus 消息。

五、错误消息和通知消息

错误消息 ErrorResponse 和通知消息 NoticeResponse，通常是在服务器端处理失败或者发生异常场景时，通知客户端执行失败或者服务器端异常原因的消息。

错误消息和通知消息中可能出现的每个字段类型都有一个单字节标识，并且任何给定的字段类型在每条消息中最多出现一次。错误消息和通知消息中可能出现的字段及其含义如下表所示。

客户端负责格式化显示错误消息和通知消息的信息以满足其需要。客户端应该根据需要进行换行等，错误消息字段中出现的换行符应视为段落分隔符，而不是换行符。

六、其他子协议简介

1. 流复制协议（Streaming Replication Protocol）和逻辑流复制协议（Logical Streaming Replication Protocol）

要启动流复制，客户端在启动消息中发送 replication 参数。replication 参数为布尔值，值为 true（或 on，yes，1）告诉服务器端进入物理复制 walsender 模式，其中可以发出一组复制命令，而不是 SQL 语句。

将 database 作为 replication 参数的值传递，指示服务器端进入逻辑复制 walsender 模式，连接到 dbname 参数中指定的数据库。在逻辑复制 walsender 模式下，可以发出复制命令以及正常的 SQL 命令。在物理复制或逻辑复制 walsender 模式中，只能使用简单的查询协议。

这两种协议，主要应用于主备服务器数据同步的场景。流复制也叫物理复制，是基于对文件块的流复制，逻辑复制是基于对数据元组按照一定格式进行复制。

2. 加密协议

（1）SSL 会话加密

如果 PostgreSQL 的构建选项使用了 SSL，那么客户端和服务器端通信可以使用 SSL 加密。SSL 会话加密在攻击者可能能够捕获会话流量的环境中提供了通信安全性。

（2）GSSAPI 会话加密

如果 PostgreSQL 的构建选项是使用了 GSSAPI，则可以使用 GSSAPI 加密客户端和服务器端的通信流量。这在攻击者可能能够捕获会话流量的环境中提供了通信安全性。

本篇技术贴中第四、五、六章节的相应内容，会在后续推出的《深度解析 PostgreSQL Protocol v3.0》系列文章中为大家进行详细展开，对本系列感兴趣的小伙伴欢迎关注我们，第一时间获取更新内容噢。