AS2 工作原理
本文旨在针对AS2协议操作展开全面描述，主要内容包括：
- AS2是如何工作的？
- AS2系统的关键组成部分
- AS2中的信息流
AS2是如何工作的？
首先需要通过内部应用生成需要通过AS2传输给合作伙伴的文件。大多数此类文件是遵循 ANSI X12 （美国国家标准委员会）标准或者遵循 UN/EDIFACT （联合国行政、商业和运输电子数据交换）标准的电子数据交换（EDI）格式。企业内部的业务系统（如ERP系统等）会提供需要的业务数据并经由EDI系统将这些业务数据转换为标准的EDI报文或其他文件格式，此类文件会提交给AS2通信软件，以便传输给合作伙伴。
合作伙伴详细信息是针对 AS2 软件定义的，包括合作伙伴 AS2 标识符、URL 和证书。上游应用程序使用 API、共享目录、SFTP或消息等与 AS2 软件集成。
在知行之桥EDI系统中，将AS2功能封装在功能模块中，用户无需添加代码，只需要在可视化界面中配置自己和合作伙伴的AS2连接参数即可开始AS2连通性测试。
AS2 端口的关键组成
AS2端口配置
知行之桥EDI系统中的端口即功能模块，AS2端口中集成了AS2通信所需的功能，并提供可视化界面，降低操作难度。用户需要在AS2端口中配置AS2连接信息，包括：AS2标识符、密钥对以及证书。大多数组织/企业都会为 AS2 定义一个端口，有些会创建独立的端口以供测试和生产使用。组织还可以为不同的业务部门或者身份创建单独的端口，每个AS2端口都应具有描述性的AS2标识符，例如：
- CompanyA_AS2单个AS2端口，用于测试和生产，适用于大多数组织的业务需求。
- CompanyA_AS2_TEST,CompanyA_AS2_PROD两个用于测试和生产使用的AS2端口，通常用于大型组织。
- CompanyA_AS2_MANUFACTURING,CompanyA_AS2_DISTRIBUTION同一组织的不同业务部门使用的多个端口，适用于超大型组织。
证书存储区
点击知行之桥EDI系统右上角的 齿轮 图标，在 证书 选项卡下，列出了当前使用的所有证书。在这个界面中，能够创建和上传证书以及了解已有证书的基本信息，包括：名称、主题、颁发者、失效日期等。到期后轮换的证书和新证书通常由合作伙伴提前提供。
Mailboxes 邮箱
邮箱（如收件箱和发件箱）存储接收和发送的邮件。邮箱就像电子邮件文件夹，有助于组织和查看邮件。可以撰写或发送新消息，也可以下载和查看已接收的消息。每条消息还会将其 MDN 状态显示为 success 或 failed。
集成
AS2 解决方案可能会提供多个选项，以便与生成和处理文件的现有系统集成。可用的常见选项如下：
- API，例如 REST API
- SFTP 服务器
- AWS S3 存储桶集成
- 共享文件系统位置 / NFS
- 消息系统
大多数基于 SFTP、S3 或本地共享文件夹等文件的系统将具有如下目录结构。此外，可能还有传输失败的目录。
传出文件被放置的位置：例如 AS2/send// /
收到的传入文件：例如 AS2/files// /inbox/
发送后的传出文件：例如 AS2/files// /outbox/
大多数基于 REST 的 API 可能会公开 URL，如下所示。
提交消息：例如 POST /message/submit
列出收到的消息：例如 GET /message/inbox
列出发送的消息：例如 GET /message/outbox
按 ID 下载特定消息：例如 GET /message/inbox/
AS2中的消息流
发送方
1.使用安全哈希函数计算消息完整性检查 （MIC） 或消息摘要。最常用的哈希算法是 MD5、SHA-1 或 SHA-256
2.如果文档包含可压缩的数据（即不是二进制数据），则可以使用 zlib 压缩算法对文档进行压缩，以减少传输数据的大小。
3.使用发件人的私钥对文件内容进行数字签名（通常使用SHA-1 签名算法），并将文件内容和签名放入 MIME 消息中。
4.使用接收方的公钥或证书，使用文件内容和签名加密（通常使用3DES 签名算法） MIME 消息。使用现在加密的内容覆盖 MIME 消息。（请注意，解密后，上述步骤 #2 的内容将可用，包括签名和文件内容）
5.添加 AS2 协议特定的头部信息，例如 AS2-From、AS2-To 等，并将 S/MIME 消息作为 HTTP POST 传输到合作伙伴的 URL
接收方
1.检查收到的 AS2 消息头部信息，以验证收到的消息是否发送给收件人，以及发件人是否已知。
2.如果收到被进行压缩处理的文档，则文档将被 解压缩 生成原始的EDI文档。
3.使用接收方的私钥解密最外层的payload
4.验证发件人放置的数字签名，以验证发送消息的合作伙伴，并且payload未被更改
5.计算消息完整性检查（MIC），通过对收到的原始payload进行哈希处理
6.通过使用接收方的私钥对收到的 MIC 进行数字签名来创建消息处置通知 （MDN）。
7.使用HTTP响应向发送方回复MDN（即同步MDN）或者回复一个新的HTTP消息（即异步MDN）
发送方接收MDN
1.收到 MDN 后，使用合作伙伴的证书验证其签名，以确认它已由收到原始消息的已声明的合作伙伴进行数字签名和发送。
2.存储成功（或失败）的 MDN，以便进行不可否认、调查或故障排除。
说明
- 即使使用 HTTP 能够提供 AS2 的所有保证，但也可以使用 HTTPS 代替 HTTP 作为传输机制。
- 签名、加密和 MDN 不是由 AS2 规范强制实施的，各合作伙伴之间可以沟通协商是否需要使用。
- 每个合作伙伴的证书都包含其非对称密钥对的公钥，在开始通过AS2传输文件之间，通常需要企业通过电子邮件获取到其交易伙伴的公钥。
- AS2 中使用的证书不需要由第三方受信任的证书颁发机构 （CA） 签名。但是，某些行业（例如欧洲的能源行业）可能需要此类签名证书。
