在本篇AS2協議指南中，將帶您了解AS2的完整定義，并提供開始使用AS2的所需信息，包括：

什么是AS2？

AS2的背景

AS2的優點

AS2的工作原理

AS2實施

AS2與AS1、AS3和AS4對比

AS2，是一種B2B消息傳輸協議，用于將文件從一個企業傳輸到另一個企業。

AS2是一種通用的EDI傳輸協議，其傳輸的數據應用于全球數百萬企業。AS2常應用于零售商，如亞馬遜和沃爾瑪。AS2詳細說明了如何使用HTTP/S（安全超文本傳輸協議）通過Internet安全地傳輸數據。AS2是第二代EDI協議，由InternetEngineeringTaskForce(IETF)在2002年創建，以取代使用電子郵件協議進行安全數據傳輸的AS1。

AS2由德拉蒙德集團（DrummondGroup）提供支持，這是一個專門認證AS2軟件的組織。如果您和您的交易伙伴都使用Drummond認證過的AS2產品，即可完成安全連接以交換EDI數據。

與許多其他文件傳輸協議的軟件不同，由Drummond認證的AS2軟件供應商每年需針對一組安全配置文件進行兩次互操作性測試，確保任何互操作性問題都能在測試期間發現并解決，避免影響生產環境。如果選擇非Drummond認證的AS2解決方案，由于缺乏互操作性測試，可能會遇到與交易伙伴的交互問題，甚至遇到數據安全問題。

AS2支持使用HTTP/S在互聯網上進行安全數據傳輸，由于互聯網接入的普遍性，它比許多其他協議更容易使用。AS2涉及兩臺服務器，以點對點的方式在線連接，用于安全的、與有效負載無關的B2B消息交換。

AS2協議有三個核心特性：

安全性：在AS2中，敏感數據可通過TLS/SSL傳輸層得到保護，亦可通過S/MIME在負載層中得到保護。AS2使用S/MIME協議將EDI數據封裝在一個安全的“信封”中，并通過網絡發送。

完整性：消息是使用數字證書簽名的，可確保發送方的身份和消息的完整性。數字證書也會對消息進行加密，以確保只有正確的一方接收EDI消息，并且在傳輸過程中沒有人可以攔截它們。

不可否認性：數據的接收方在成功接收到消息后需要返回一個簽名消息，即MDN回執，其中包含消息完整性檢查(MIC)。

眾所周知，沃爾瑪通過AS2支持EDI，并推動其在零售業中更廣泛的大規模采用。

AS2由IEFT于2022年創建，以取代他們在1990年代初期創建的AS1。

由于零售和消費品(CPG)行業的主要參與者支持AS2，AS2的應用在2000年代初期迅速增長。沃爾瑪是第一家要求其供應商使用AS2協議的主要零售商。亞馬遜、Target、Lowe’s、Bed、BathBeyond和其他數千家企業也紛紛效仿。

他們表明，他們可以通過AS2直連繞過昂貴的傳統增值網絡(VAN)，降低成本并實現近乎實時傳輸的EDI通信?，F在，包括醫療保健在內的許多其他行業都使用AS2協議，因為AS2符合HIPAA法律要求。

為什么要選擇AS2呢？對于許多企業來說,選擇AS2主要是為了滿足更大客戶或者交易伙伴的要求，此外，站在業務和技術的角度來看，AS2是一個有著諸多優勢的通用協議。對于許多企業來說，通過AS2進行的EDI電子數據交換是非常值得投資的。

通過使用Internet網絡進行EDI文件傳輸，AS2降低了昂貴的VAN和傳統EDI的交易成本。

通過EDI擴展連接更多交易伙伴；憑借較低的成本和通用的網絡連接，AS2允許與全球幾乎沒有EDI基礎的交易伙伴一起實施EDI。

無需手動處理訂單，節省大量時間。

通過將手動流程轉變為自動化流程來消除錯誤。

通用解決方案–AS2已建立并經過測試，可以直接使用，因此無需再費時重新研究發明。對于數以百萬計的企業而言，這就是它勝過其他EDI協議的原因。

利用網絡：如果企業可以通過網絡安全地共享數據，那么您已經擁有了AS2的大部分基礎配置。

無限的EDI數據–通過Web的交易規模沒有實際限制，AS2支持超大文件傳輸的功能。

7×24連接，停機時間短–只要服務器保持正常運行，AS2就可以保持正常運行。

靈活性：AS2中的HTTP/S和S/MIME簽名和加密技術被廣泛使用并定期維護

PayloadAgnostic–AS2可用于傳輸任何類型的文件。雖然EDIX12、EDIFACT和XML很常見，但可以傳輸任何雙方認可的格式。

那么，AS2是如何工作的呢？它遵循一個相當簡單的過程，AS2為EDI數據提供了一個“信封”，以便使用HTTP/S通過Web（和其他基于TCP/IP的網絡）安全地發送數據。

發送方使用AS2軟件傳輸消息：

1.EDI文件準備

準備標準EDI格式報文，以通過AS2發送（AS2可以發送任何格式的文件，這里以標準EDI報文為例）

2.AS2打包

通過AS2來發送該EDI報文，通過AS2發送的文件一般會（但非必須）經歷以下三步打包：

壓縮：可以使用壓縮算法壓縮文件以減小傳輸數據的大?。蛇x項）

簽名：通常使用發送方的私鑰證書對數據進行簽名，以確保發送方作為文件創建者的身份

加密：通常使用接收方的公鑰證書進行加密，因此只有正確的接收方才能解密文件。AS2使用安全/多用途網絡郵件擴展(S/MIME)協議將郵件包裝在安全信封中。

3.消息傳遞

將打包的數據通過HTTP/S安全地傳輸消息。

4.AS2拆包

接收服務器需要始終保持在線狀態（如果在發送消息時接收方的服務器處于離線狀態，則發送方將收到錯誤消息），以偵聽發送給它的消息。如果數據已加密，則使用接收方的私鑰證書解密。如果已簽名，則使用發件方的公鑰證書驗證簽名，以驗證發送方的身份。如果文件已壓縮，則將其解壓縮。

5.EDI處理

AS2將拆包后的EDI文件傳遞給處理數據的任何后端進程，以執行其他附加的業務邏輯。

6.MDN回復（接收方）

接收方使用AS2或EDI軟件提取消息并將消息確認回執發送給發送方。

7.MDN處理（發送方）

發送方驗證MDN簽名并將返回的內容消息完整性檢查(MIC)與最初計算的內容進行比較

為確保每條消息都到達其目的地，EDI中提供了四層回執。其中三個是所有EDI協議共有的，AS2增加了第四個，即MDN。

1.通信狀態：確認在網絡級別接收到數據
2.MDN：消息確認回執(MDN)確認消息已成功從”信封”中提取，并且收到的有效負載與從客戶端傳輸的有效負載相匹配。（由AS2添加）
3.功能確認：確認接收到有效消息（例如，打開EDI信封并包含有效的EDI文件）。也稱為997/999(X12)或CONTRL(EDIFACT)。
4.業務確認：確認消息的內容，并確認它已經以適當的方式得到處理（例如，采購訂單確認同意履行采購訂單中的訂單）

關鍵點：

AS2最常用于傳輸EDI報文，但實際可以處理任何文件類型

AS2信封可能包含另一個含實際業務文件的信封（例如ANSIX12EDI）

與傳統EDI一樣，您可以使用工具從內部系統中提取數據，并將其轉換為適當EDI標準報文，然后再發送

然后，您可以以相同的方式處理您發送和接收的數據

為了加快傳輸速度，AS2支持壓縮以減小每條消息的大小

您可以用AS2與每個交易伙伴的EDI直接連接，或者使用增值網絡(VAN)。

在直連EDI（也稱為點對點EDI）中，使用商定的協議（在本例中為AS2）與每個交易伙伴建立連接。系統的所有權及其部件和連接的管理由通信各方來維護（企業也可以在云環境中托管其EDI環境，例如AmazonEC2）。

VANs充當中間人，在通信協議和交易伙伴之間翻譯EDI消息，無論您的交易伙伴使用哪種協議，您都可以使用自己的單一協議–例如，如果您只使用AS2，但歐洲交易伙伴除了使用AS2之外還使用OFTP2和AS4.

VANs可以提供對您的EDI文件的托管管理、數據的可視化和擴展報告–但要付費。VANs作為一項持續服務運行，雖然VANs可能會降低您的初始成本，但處理每一個文件（甚至是行項目）都會收取費用。

傳統上，VANs是缺乏EDI資源或知識來支持EDI的小型企業的唯一選擇，但隨著EDI技術的成熟和EDI軟件的出現，直連EDI的成本也逐漸降低，越來越多地企業選擇使用直連EDI。VANs可能會降低初裝成本，但會為處理的每個文件甚至行項目收取費用。如果您的交易量較少，并且只偶爾使用EDI，那么您的成本可能會比較低，但隨著業務量與日俱增，服務費也將持續增長。如果您未來有計劃增加交易伙伴，并預期會有更高的數據交易量，直連EDI解決方案的成本會低得多。

當然還有其他的考慮因素，例如企業對設置、交易伙伴的要求、安全性等把控，需要結合企業自身和交易伙伴的具體要求進行選擇。

直連EDI

VANEDI

使用AS2可以通過互聯網發送和接收商業數據。如果想保護這個通往網絡的入口，就像鎖上門一樣，防火墻是最常見的方法。兩個主要安全選項是:

使用非軍事區(DMZ)–所有AS2流量都從一個端口進入，運行AS2的服務器與企業內部服務器只進行單向通信。你可以將它想象成一個雙門氣閘，將AS2流量與您的內部服務器隔離開來，消除了對每個供應商的特定安全解決方案的需求。

AS2使用超文本傳輸協議(HTTP)，可以通過SSL證書進行專門保護。大多數網站已經或正在從傳統的HTTP遷移到HTTPS，因此HTTPS正在成為標準。

在知行之橋中，我們建議使用數字證書加密所有EDI交易，以驗證每筆交易和每個交易伙伴的身份。只有擁有私鑰證書的交易伙伴才能接收消息和訪問AS2，從而防止數據在傳輸過程中被截獲。

生成數字證書有兩個主要選項：

使用證書頒發機構(CA)的證書，例如在Envision或Verisign申請，來管理證書、驗證證書并吊銷過期的證書

使用帶有內置證書功能的EDI應用程序來“自簽名”數字證書——知行之橋帶有完整的內置證書功能

除非您的交易伙伴的安全策略另有規定，使用SSL連接，最常見的方法是從CA機構購買SSL證書，并同時使用SSL證書進行簽名和加密。來自可信任CA機構的SSL證書會向web服務器上的匿名訪問者驗證您的身份，但自簽名證書在AS2更常見，因為通信雙方之間的現有信任關系已經建立(并且可以免費創建證書)。

通過使用接收方的公鑰證書，AS2消息內容被加密以保護數據。只有接收方才能使用他們的私鑰證書解密內容。

在通過AS2傳輸數據時加密數據，您和您的交易伙伴的EDI軟件必須使用并支持相同的加密算法。熱門選項包括：

168BitTripleDES(3DES)(3DES)，默認使用

AES（未普遍采用）

您和您的交易伙伴可以對傳輸的數據簽名以證明其真實性。AS2支持以下選項：

不簽名–不推薦，因為沒有身份驗證

SHA-1

SHA-2（也稱為SHA-256）-2018年推出的SHA-1的替代品，更常見但尚未普遍采用

AS2標準現在建議使用SHA-2，但您可能還需要同時支持SHA-1以用于不同的交易伙伴。

簽名是AS2傳輸的一個重要功能。簽名證明發送方的身份并包含使用SHA-1或SHA-2算法計算的MIC（消息完整性檢查）。當接收方驗證簽名時，該MIC將與接收方在簽名消息的正文上計算的MIC進行比較。如果MIC在簽名中發送并在有效負載上計算匹配，則發送方可以確信數據沒有被篡改。

消息確認回執(MDN)確認交易伙伴收到了文件，提供“不可否認性”或不可否認的回執。有五個處理MDN的選項，包括：

沒有MDN–這是一個糟糕的選擇，零審計跟蹤，并可能導致傳輸的誤報。

普通MDN–未簽名的回執立即返回給發送方，以顯示消息回執。這也是一個糟糕的選擇，因為很容易被冒充。

簽名MDN–立即返回并簽名，提供最可靠的審計線索。

異步普通MDN–稍后發送的普通回執，非立即發送

異步簽名MDN–稍后發送的簽名回執，非立即發送。這在消息較大的情況下很有用，因為發送方可能不希望在等待返回需要更長時間生成的MDN時保持初始連接打開。

發送方需要為接收方指定MDN形式，因此您需要確保您的軟件支持以上所有的五個選項，因為每個交易伙伴可能需要不同的回執（MDN）。

此外，MDN包含根據接收到的初始傳輸有效負載計算的MIC。當原始發送方驗證MDN時，該MIC將與最初通過AS2傳輸計算的MIC進行比較，因此發送方接收到有效負載被打包接收的保證。在消息和MDN上使用簽名創建了MDN的不可否認性(NRR)，這被認為是交付的合法證明。

除了正確實施AS2協議外，您還需要確定與每個交易伙伴交換的EDI標準和報文——無論是EDIFACTINVOIC發票、X12850采購訂單、HIPAAEDI患者準入證還是其他任何業務報文。

知行之橋AS2端口是最簡單易用的且經Drummond認證的解決方案。它支持所有主要類型的EDI標準和交易，同時提供內置端口，用于與80多種主流工具和應用程序進行強大的數據集成。