EDI传输协议选型指南：AS2、OFTP2、VAN对比与落地实践

1. 为什么你的EDI项目，最后卡在了“选哪种传输方式”这一步？

做企业间电子数据交换（EDI）的时候，我见过太多团队把精力全扑在报文格式上——X12、EDIFACT、XML映射，结果到了联调阶段才发现，真正麻烦的不是“说什么”，而是“怎么把话说出去”。对方贸易伙伴甩过来一句：“我们支持AS2，你们那边能连吗？”你如果只回一句“我们走VAN”，对方采购系统可能直接把你归到“传统供应商”那一档。

EDI的核心本质是结构化的业务数据在系统间自动流转。但“流转”两个字，背后涉及的问题是实打实的：走公网还是专网？加密用什么标准？文件到了对方手里怎么确认没被篡改？传输失败了能不能自动重传？这些问题不是报文格式能解决的，而是传输协议层的事。

这篇文章我从甲方和乙方两种视角都做过总结，把AS2、STTP、OFTP2、VAN这四种主流EDI传输方式的关键参数、适用场景和选型逻辑一次讲透。如果你是刚接触EDI的IT负责人、集成架构师，或者正在被贸易伙伴要求“接入AS2”却不知从何下手，这篇内容可以帮你少走很多弯路。

2. 先搞清楚一件事：EDI传输协议解决的本质问题

2.1 传输层与报文层，别混为一谈

很多刚入行的同事会把“AS2”和“X12”当成同一类东西，实际上差得很远。X12、EDIFACT、VDA这些是报文标准，解决的是“数据长什么样、字段怎么排”；AS2、OFTP2、SFTP这些是传输协议，解决的是“数据怎么安全地从A点到达B点”。

打个比方：报文是信封里的信纸，内容是业务语言；传输协议是快递公司，负责把信封安全准时地送到对方手里。你可以选择邮政包裹、顺丰特快或者同城闪送，对应到技术世界就是VAN、AS2、OFTP2这些不同的运输体系。

传输协议要回答的问题包括三个维度：能否确保送达、能否验证收发双方身份、能否保证数据在途不被篡改或窥探。不同的协议在这三个维度上的侧重点完全不同，所以没有绝对的好坏，只有适不适合你的业务场景。

2.2 “确认回执”这件事，决定了协议层级

我判断一个EDI传输方案是否可靠，第一个看的就是回执机制。什么叫回执？就是A把文件发出去了，B收到之后必须回一条消息告诉A“我收到了，文件完整、来源可信”。如果这条回执是自动的、加密的、不可抵赖的，那么这个方案就是企业级可用的；如果回执只是“文件已下载”这种日志级别的确认，那只能算文件传输工具，不能算EDI。

AS2的MDN（Message Disposition Notification）就是典型的加密回执，OFTP2里也有类似机制叫EERP（End-to-End Response），VAN之间则依赖各自的邮箱投递报告。回执机制的存在，让EDI传输具备了可审计、可追溯的商务级信任基础——出了问题你可以拿出日志证明“我发了，对方也收到了”，这在供应链纠纷处理中极其关键。

3. 四种主流EDI传输方式逐一拆解

3.1 AS2：互联网直连的事实标准

AS2全称Applicability Statement 2，基于HTTP/HTTPS协议，设计初衷就是用公网替代VAN专线，让企业之间可以直接建立安全的数据通道。它通过S/MIME对消息做数字签名和加密，传输完成后会返回MDN回执，而且回执本身也是签名加密的，能做到不可否认性。

我在实际项目中选AS2最重要的原因就一个字：通。几乎所有主流ERP供应商（SAP、Oracle、Microsoft等）的EDI模块原生支持AS2，大型零售商、汽车主机厂、医药分销商对AS2的接受度极高。如果你是第一次接EDI，优先考虑AS2基本不会错。

AS2关键参数：

实操经验：AS2调通的关键不在发送端，在接收端的防火墙策略。很多企业只开放了入站443端口，却忽略了出站连接、MDN异步回执需要额外端口的问题，导致消息发出去了但回执传不回来，业务侧看到的状态一直是“待确认”。这种问题排查起来很隐蔽，建议联调第一件事就是确认双向端口的连通性。

3.2 STTP：区域性行业协议，别被名字唬住

STTP这类协议在互联网上能查到的标准定义并不多，它更多是某些区域或特定行业联盟定义的“安全传输隧道协议”的统称。真实项目中出现的STTP，往往指代某个特定平台或行业协会自定义的加密文件传输方案，或者是对SFTP、FTPS等安全传输技术的行业变体称呼。

遇到贸易伙伴要求“走STTP”的时候，我的第一反应不是去查协议标准文档，而是直接让对端把他们的连接手册、端口范围、证书要求发过来。这类协议通常是某个行业平台大力推动的，比如部分汽车行业二级供应商集群、某些国家的医疗采购平台，形成了“大家都用这套配置”的生态习惯。

从技术实现角度看，STTP类方案普遍基于SSH隧道或TLS封装，安全性并不差，但它有两个明显短板：一是标准化程度不够，每家平台的细节配置都有差异，换一个伙伴就要重新适配；二是回执机制不统一，有些方案根本没有业务级的送达确认，只能通过文件轮询确认。适合业务量不大、伙伴数量少、IT维护能力有限的中小企业。

3.3 OFTP2：欧洲汽车工业的“重型卡车”

OFTP2（Odette File Transfer Protocol 2）最早由欧洲汽车行业组织ODETTE提出，后来也广泛应用于全球汽车产业链以及部分航空、物流行业。它的底层基于TCP/IP，但与AS2的最大区别是：OFTP2原生支持断点续传和多文件压缩传输，传输大文件的效率和稳定性明显优于AS2。

此外，OFTP2的回执机制EERP是端到端的，意味着从发送方到接收方的完整链路都有确认，特别适合传输大体积的工程图纸、CAD数据、批量订单。欧洲很多汽车主机厂要求一级供应商必须用OFTP2，理由就是每年要交换的数据量太大，AS2的HTTP机制在大文件场景下会显得吃力。

OFTP2关键参数：

实操时要格外注意OFTP2的SSID（Session Security ID）配置。这个标识符是通信双方的会话凭证，配置错误会导致“连接建立成功但身份验证失败”。而且OFTP2的端口在不同国家、不同伙伴的网络策略下经常被防火墙拦截，建议提前协调网络团队开通双向TCP端口，否则调试时你会误判为协议配置错误。

3.4 VAN：老而弥坚的“中间人”模式

VAN（Value-Added Network，增值网络）是EDI最早的商业化传输模式，相当于一个第三方交换平台。每家企业和VAN服务商建立连接，文件先发到VAN的“邮箱”，再由VAN转发给最终接收方。VAN解决了早期企业之间没有统一网络标准的问题——只要有VAN服务商的账号，什么协议都能接。

放到今天看，VAN的定位已经发生了明显变化。大企业普遍转向点对点的AS2/OFTP2直连以节省流量费、降低延迟；但VAN仍然在两类场景中活跃：一是贸易伙伴数量极多、且伙伴IT能力参差不齐的行业，比如大型零售商的成千上万供应商，让所有人都上AS2不现实，统一走VAN反而效率更高；二是需要VAN提供的增值服务，如格式转换、数据校验、异常报警、审计报告等。

VAN的计费逻辑是按流量和按“信封”数量收取，长期高频次传输的话成本会比较高。这也是现代企业把高频核心伙伴迁出VAN、只保留长尾伙伴走VAN的核心原因。选不选VAN，本质是在“统一接入的便利性”和“按量计费的成本”之间做权衡。

4. 企业到底怎么选？我给出一套可直接套用的决策框架

4.1 先回答四个问题，再谈协议选型

我接触过的EDI选型项目中，只要按下面四个问题过一遍需求，方向基本就出来了：

1. 伙伴集中在什么行业？对方优先要求什么协议？
   汽车行业大概率是OFTP2，零售/医药大概率是AS2，长尾小供应商可能只有VAN或WEB EDI可用。

2. 单次传输的文件有多大？传输频率多高？
   几十KB的订单报文，AS2完全够用；动辄几百MB甚至上GB的工程数据，OFTP2的断点续传优势就很关键。

3. IT运维能力如何？有专人能维护证书和密钥吗？
   AS2需要管理X.509私钥、证书轮换、MDN配置；OFTP2需要管理SSID和TLS证书。如果团队连服务器都没跑过，VAN可能是最稳妥的过渡方案。

4. 审计和合规要求有多严？
   医药、金融、汽车供应链通常要求每笔交易都有完整的审计日志和不可否认性记录，AS2和OFTP2都能满足；如果是合作伙伴内部极低频次的文件往来，SFTP加简单日志也许就够了，不必上完整EDI协议栈。

4.2 协议对比表：一眼看清差异

4.3 混合模式才是大厂常态

不要觉得选型就是二选一。成熟企业的EDI架构，往往是“一个核心平台，多种传输通道”的混合模式。例如同一条AS2通道跑所有零售/物流伙伴，OFTP2通道单独给汽车事业部的厂商，剩下的零散小伙伴全部走VAN。

这样做的好处是：核心高价值数据走直连掌握主动权，边缘长尾数据用VAN降低接入门槛，运维资源集中在少数高可用通道上。我在几个大型制造企业看到的架构几乎都是这个套路，纯用单一传输方式的反而少见。

5. 实操落地：从协议选型到上线运行的完整路径

5.1 搭建EDI传输层的标准步骤

假设你最终选了AS2为主、OFTP2为辅，落地时可以参考这个步骤顺序：

1. 搭建传输服务器/租用云实例。注意生产环境和测试环境必须隔离，证书和端口配置都要区分开。
2. 生成并交换证书。AS2需要X.509证书，自签名证书测试没问题，但生产环境强烈建议用权威CA签发，避免对方安全审核不通过。
3. 开放防火墙端口。AS2通常开放443入站，确认出站不限制；OFTP2确认3305/6619双向可通。
4. 与伙伴进行一次“Hello World”级联调：先只传一个文本文件，不签不加密，通了之后再加签名、加密、MDN，逐级加复杂度。
5. 建立监控告警。重点监控回执是否超时、重传次数是否异常、证书是否即将过期——证书过期是生产环境最常见的“突然故障”，没有提前告警就只能等业务人员发现了。

5.2 别忽视数据映射里的“温度计误差”问题

协议通了，不等于EDI就成功运转了。我见过太多项目卡在最后一步：数据映射。这个问题用温度传感器标定来类比就很好理解——铂电阻温度传感器（如PT100）的阻值和温度之间并不是简单的线性关系，工程上要通过Callendar-Van Dusen方程做非线性补偿，才能在全温区拿到准确读数。

EDI映射里也有同样的“非线性误差”：同一字段在A公司的X12报文里是“公斤”，在B公司的EDIFACT报文里可能定义成“磅”；A系统里客户编号是10位数字，B系统里同一个客户编号却带字母前缀。如果不做字段级、单位级、主数据级的对齐，就会出现“数据通了，但全是脏数据”的尴尬局面。所以传输协议只是骨架，数据映射和质量校验才是血肉。

5.3 上线前的联调检查清单

• 证书有效性：查看本端和对端证书有效期，标记到日历里做轮换计划
• 异步MDN的端口回调是否通：很多AS2坑都发生在这里
• 大文件异常中断测试：OFTP2手动断网看能否续传
• 重复消息场景：伙伴重复推送同一条订单，业务侧能否幂等处理而不产生重复订单
• 告警通知是否真的送达：测试告警邮件/Webhook，别到生产才发现通知没配置好

6. 常见问题与排查技巧实录

再单独说一个LZ踩过的坑：AS2的同步MDN和异步MDN。同步回执走的是同一个HTTP连接，配置简单但大文件传输时连接占用时间长；异步回执需要接收方主动POST一条MDN到发送方的指定端口，配置多一步，但体验明显更稳。刚开始图省事全用同步，后来5GB以上的大文件频繁超时，改异步回流后问题消失。建议生产环境直接用异步MDN，省得后期返工。

7. 关于选型的最后一点个人建议

协议选型这种事，网上各种各样的标准文章很多，但真正决定成败的往往是那几个看不见的因素：对方IT部门的配合程度、自己团队的运维耐心、业务量的真实吞吐。很多项目的适配器买得再贵，如果伙伴配合度不高，联调周期一样拖到天荒地老。

我个人在实际接触过的十几个EDI接入项目里的一种体会是：先用最小可行的方案跑通，再根据业务增长逐步加固。一开始不必追求把所有协议都支持到位，先满足最大的那个伙伴的需求，让数据流真正跑起来。等生产环境积累了运行经验，再扩展第二通道、第三通道，比一开始就铺开所有协议要稳妥得多。

最后再分享一个小技巧：无论选哪种协议，口口声声说自己“支持EDI”的云服务商很多，但真正上线时你会发现，贸易伙伴的接入要求千奇百怪——尤其是那些中小型伙伴的平台定制能力有限。预留一个“通用SFTP兜底通道”作为最后手段，关键时刻能救场。工具永远是工具，让数据流转起来才是目的。