← RFC Reference

RFC 2920 – SMTP 流水线处理

为什么这个RFC存在

标准SMTP是严格的请求-响应协议。客户端发送一个命令，等待服务器响应，然后发送下一个。每个往返都会增加延迟，特别是在高延迟网络链路上。对于有50个收件人的消息，客户端仅针对RCPT TO命令就需要50个独立的往返。

RFC 2920定义了PIPELINING SMTP扩展，允许客户端批量发送多个命令而无需等待单个响应。服务器缓冲并按顺序处理这些命令，然后发送所有响应。这可以大幅减少SMTP会话的总时间。

管道化是最广泛支持的SMTP扩展之一。几乎每个现代邮件服务器都会宣告它，大多数SMTP客户端库默认使用它。

工作原理

1. 客户端发送EHLO并确认服务器在其功能列表中宣告PIPELINING。
2. 客户端将安全管道化的命令分组在一起——通常是MAIL FROM、一个或多个RCPT TO和DATA。
3. 客户端快速连续发送所有这些命令，无需等待单个回复。
4. 服务器按顺序处理每个命令并按顺序为每个命令发送一个响应。
5. 客户端读取所有响应并处理任何错误（例如被拒绝的收件人）。

SMTP示例

不使用管道化（信封需要5个往返）：

使用管道化（整个信封需要1个往返）：

关键技术细节

哪些命令可以管道化

并非所有SMTP命令都安全可管道化。RFC 2920将命令分为两类：

改变连接状态的命令（EHLO、STARTTLS、AUTH）是同步点——客户端必须等待响应才能发送任何其他内容。

错误处理

使用管道化时，批处理中的某些命令可能成功，而其他命令可能失败。客户端必须按顺序将响应与命令匹配。被拒绝的RCPT TO不会使整个事务失效——消息仍会传递给已接受的收件人。但是，如果MAIL FROM被拒绝，后续RCPT TO命令也会失败。

TCP缓冲考虑

管道化依赖于TCP的缓冲。客户端将多个命令写入套接字而不读取，相信TCP发送缓冲区可以容纳它们。对于非常大批量的RCPT TO命令（数百或数千个），客户端可能需要分组管道化以避免填满TCP缓冲区和死锁。

与STARTTLS的交互

在包含STARTTLS的EHLO响应之后，客户端不得将STARTTLS与其他命令管道化。TLS握手改变整个连接的状态，所以它是硬同步点。建立TLS后并发送新EHLO时，管道化可以恢复。

常见错误

• 将EHLO或STARTTLS与其他命令管道化。这些是同步点。将它们管道化会导致协议错误，因为服务器的响应改变后续命令所依赖的会话状态。
• 在处理错误之前不读取所有响应。如果管道化5个命令，即使第一个是错误，也必须读取全部5个响应。放弃响应流会破坏协议状态。
• 假设所有服务器都支持管道化。虽然几乎普遍，管道化是一个扩展。在使用前始终检查EHLO响应中的PIPELINING。如果没有，回退到逐个模式。
• 在MAIL FROM被拒后管道化。如果MAIL FROM被拒并且已经管道化RCPT TO命令，它们都会失败。在管道化收件人之前读取MAIL FROM响应，或准备好处理级联失败。
• 在管道中发送DATA内容。DATA命令本身可以管道化，但随后的消息正文不能。在发送消息内容之前必须等待DATA的354响应。

可传递性影响

• 多收件人消息的更快传递。管道化将N收件人消息从N+2个往返减少到信封阶段的大约2个往返。在高延迟连接上，这可以节省每条消息的秒数。
• 批量发送的更高吞吐量。通过同一连接发送许多消息时，管道化使您可以将下一条消息的信封与当前消息的数据传输重叠，最大化连接利用率。
• 缩短连接时间。较短的会话意味着较少的连接打开时间。这对于执行每连接时间限制或基于连接持续时间的速率限制的服务器很重要。
• 负载下的更好表现。管道化减少网络往返次数，这减少了发送和接收服务器上的负载。这使发送基础设施更高效。
• 按收件人拒绝仍然有效。管道化不会降低服务器拒绝个别收件人的能力。每个RCPT TO仍获得其自己的响应代码，所以退信处理方式完全相同。

Related RFCs