TWI634773B - 高效能訊息傳輸方法 - Google Patents

Abstract

本發明提出一種高效能訊息傳輸方法，該方法包括：令傳送端將欲傳送檔案以封裝格式封裝，進而產生訊息封裝檔；令該訊息封裝檔透過第一傳輸協定傳送至接收端；於該訊息封裝檔傳送至該接收端後，令該傳送端透過第二傳輸協定發送一通知訊息至該接收端；以及該接收端藉由該通知訊息取得該訊息封裝檔之儲存位置後，令該接收端下載該訊息封裝檔以進行檢核，再由該接收端傳送回覆訊息至該傳送端。本發明之高效能訊息傳輸方法同時採用兩種通訊協定，並結合資料封裝方法，藉以滿足大量傳輸、大檔案傳輸、不可否認性、高效能等特性。

Description

高效能訊息傳輸方法

本發明係關於一種訊息傳輸技術，詳而言之，係關於一種具備完整性和高效能之訊息傳輸方法。

目前在全球網際網上的資料交換協定，各有其先天限制，有些傳輸協定具有「資料完整性」以及「訊息來源之不可否認性」之特定，有些傳輸協定則可滿足大檔案傳輸，然若要兼顧「資料完整性」及「訊息來源之不可否認性」，同時又要滿足「大量傳輸」及「大檔案傳輸」時，則會有效能問題。

現行針對「資料完整性」以及「訊息來源之不可否認性」之需求，可仰賴PKI技術進行資料的簽章處理，之後再進行資料傳輸，且若同時有多個檔案，則可進行壓縮或打包再進行簽章作業，但在此方式下，若接收端接收檔案後，僅要針對當中的某個檔案處理，則仍需對整份已包裝好的檔案進行處理，使得處理過程會有額外耗能的情況。

舉例來說，ebMS(ebXML Message Service)交易協定可提供全球電子商業用戶在網際網路上一種透通、安全且一致性的電子商業資訊交換環境，使得各產業間於電子貿易 文件在水平交換時，能夠使用安全且一致性的標準所訂定之規格。惟，ebMS2.0協定在訊息交換時，有無法傳輸大檔案的先天限制，亦即在考量安全、一致性下，卻無法有大檔案傳輸的效能。此外，採用此協定時，若訊息經由中介節點，則無法進行端對端(end-to-end)之認證，故缺乏確認訊息來源之不可否認性的功能。

另外，現在資料在傳輸完成時，除非接收端自行開發程式進行處理，也就是，在接收到最後一個封包時立即進行處理，否則一般是以輪詢(Polling)方式，每隔一段時間檢查資料夾，若確定檔案傳輸完成時才會進行後續作業，惟輪詢方式缺乏效率，輪詢的時間區間過小，會耗費不必要的CPU資源，但若時間區間過大，則有不夠即時的缺陷。

由上可知，如何找出一種訊息傳輸技術，期盼可具備資料完整性及訊息來源之不可否認性等需求外，又同時可兼顧大量傳輸及大檔案傳輸等效能，藉以提供一種安全、高效能的傳輸機制，此實為目前本技術領域人員急迫解決之技術問題。

鑒於上述習知技術之缺點，本發明之目的係提出一種資料傳輸方法，透過兩種傳輸協定以及資料封裝，藉此符合「資料完整性」、「訊息來源之不可否認性」、「大量傳輸」以及「大檔案傳輸」之傳輸需求。

為達成前述目的及其他目的，本發明係提出一種高效能訊息傳輸方法，該方法包括：令傳送端將欲傳送檔案以 封裝格式封裝，進而產生訊息封裝檔；令該訊息封裝檔透過第一傳輸協定傳送至接收端；於該訊息封裝檔傳送至該接收端後，令該傳送端透過第二傳輸協定發送一通知訊息至該接收端；以及該接收端藉由該通知訊息取得該訊息封裝檔之儲存位置後，令該接收端下載該訊息封裝檔以進行檢核，再由該接收端傳送回覆訊息至該傳送端。

於一實施例中，該第一傳輸協定為大檔傳輸協定，該第二傳輸協定為雙向認證之交換協定。

於另一實施例中，該接收端無法由該通知訊息取得該訊息封裝檔時，令該接收端傳送包含該接收端之簽章值以及檔案不存在之訊息封包。

於又一實施例中，該通知訊息包括該傳送端之簽章值以及該訊息封裝檔之中介資料，且其中，該中介資料包括指紋資料、時戳及/或識別碼。

於再一實施例中，該檢核之進行係包括計算該訊息封裝檔中各附檔之雜湊值，以與該通知訊息中該指紋資料進行比對。另外，該檢核之進行係還包括比對該傳送端之簽章值以及該訊息封裝檔內對應之簽章值。

於又一實施例中，該欲傳送檔案分為主訊息和附檔，且其中，該附檔係透過雜湊演算法以得到該附檔之雜湊數，且於該雜湊數置入該主訊息後進行數位簽章。

於另一實施例中，該訊息封裝檔包括該主訊息之原文、使用該原文簽章計算但不含該原文之數位簽章及/或該附檔，且該封裝格式為多用途互聯網郵件擴展 (Multipurpose Internet Mail Extensions，MIME)。

相較於習知技術，本發明提出之高效能訊息傳輸方法，同時利用兩種通訊協定，藉此達到大量傳輸、大檔案傳輸以及高效能等需求，具體來說，為了滿足大量傳輸、大檔案傳輸之特性，可透過例如FTP、FTPS或SFTP，先行將已封裝檔案傳送至接收端，接著透過例如ebMS通訊協定來通知接收端取得封裝檔案並進行處理，因為採用ebMS通訊協定可符合傳輸安全性和一致性等需求，故運用兩種通訊協定，藉此達到本發明所述之高效率訊息傳輸。

21‧‧‧範圍

31‧‧‧主訊息

S11~S14‧‧‧步驟

S41~S48‧‧‧流程

S51~S562‧‧‧流程

第1圖係本發明之高效能訊息傳輸方法的步驟圖；第2圖係本發明之高效能訊息傳輸方法有關MIME訊息結構的關係示意圖；第3圖係本發明之高效能訊息傳輸方法有關MIME訊息中主訊息與附檔的關係示意圖；第4圖係本發明之高效能訊息傳輸方法中傳送端與接收端有關檔案傳送與訊息傳遞的處理流程圖；以及第5圖係本發明之高效能訊息傳輸方法中傳送端與接收端有關檢核與驗證的處理流程圖。

以下藉由特定的具體實施形態說明本發明之技術內容，熟悉此技藝之人士可由本說明書所揭示之內容輕易地瞭解本發明之優點與功效。然本發明亦可藉由其他不同的具體實施形態加以施行或應用。

現行企業為了提升效率，公司內外部須進行訊息交換。本發明所述之訊息可以檔案型式存放，而訊息的類別可依其關係，定義為「主訊息」及與其「附檔」。為了同時滿足「大量傳輸」、「大檔案傳輸」、「完整性」、「不可否認性」、「保證傳輸」、「高效能」等特性，本發明提出一種訊息傳輸方法，主要包含兩個部份：傳送訊息的格式以及傳送訊息的方式。

傳送訊息的格式係指檔案如何簽章與封裝，藉此滿足資料完整性和不可否認性。本發明之訊息係以檔案型式存放，訊息依其關係為主訊息及/或其附檔，附檔的資訊，利用雜湊演算法，取出附檔之雜湊值，之後放入主訊息中進行封裝，而主訊息的簽章是利用PKI技術進行處理，儲存成Detached特性的簽章格式，最後，可將主訊息、主訊息之簽章值(不含主訊息原文)及附檔利用MIME(Multipurpose Internet Mail Extensions)的資料交換標準進行封裝。

傳送訊息係指檔案如何執行傳輸，藉此滿足保證傳輸、大量傳輸以及大檔案傳輸。本案提出將兩種類型通訊協定結合，選擇具大檔傳輸以及雙向交換認證等特性的傳輸協定，滿足傳輸大檔案，並配合即時通知處理，通知接收端立即訊息處理。

請參照第1圖，係為本發明之高效能訊息傳輸方法的步驟圖，主要說明傳送端與接收端兩者間如何有效率地傳送大檔案，且可確保傳輸安全性和一致性等需求。

於步驟S11中，令傳送端將欲傳送檔案以封裝格式封 裝以產生訊息封裝檔。首先，欲傳送將先進行封裝以產生一訊息封裝檔，檔案的封裝格式與方式，是配合傳輸協定，同時考量資料完整性以及訊息傳送之不可否認性。

具體來說，欲傳送檔案可被分為主訊息和附檔，其中，附檔透過雜湊演算法可得到附檔之雜湊數，接著，此雜湊數被置入主訊息後進行數位簽章，即透過PKI技術進行數位簽章。

接著，利用用途互聯網郵件擴展(Multipurpose Internet Mail Extensions，MIME)之封裝格式來封裝相關訊息，因而訊息封裝檔將包括主訊息之原文、使用該原文簽章計算但不含該原文之數位簽章及/或附檔，其中，主訊息之原文會與其簽章值分離，也就是說，使用原文完成簽章計算後，並不會將原文包含在簽章訊息中。

於步驟S12中，該訊息封裝檔透過第一傳輸協定傳送至接收端。於本步驟中，傳送端會透過第一傳輸協定，將訊息封裝檔傳送至接收端，於此所述之第一傳輸協定將是利於大檔案或大量傳輸的傳輸協定，例如檔案傳輸協定(File Transfer Protocol，FTP)、FTPS(FTP over SSL)或SFTP(SSH FTP)。

於步驟S13中，於該訊息封裝檔傳送至該接收端後，該傳送端透過第二傳輸協定發送一通知訊息至該接收端。於本步驟中，待訊息封裝檔傳送至接收端後，傳送端會發送一通知訊息至接收端，此通知訊息用於告知接收端可進行檔案存取及處理，亦即通知接收端檔案已送達，接收端 可存取檔案並確認正確與否。

傳送通知訊息時，此時非採用可用於傳輸大檔案的第一傳輸協定，而是採用可確保雙向交換認證之傳輸協定，即此處所述之第二傳輸協定，舉例來說，第二傳輸協定可為ebMS(ebXML Message Service)通訊協定。

具體來說，通知訊息可包括傳送端之簽章值以及訊息封裝檔之中介資料，傳送端之簽章值可供接收端進行簽章認證，而訊息封裝檔之中介資料可供接收端進行檔案正確與否的檢核，其中，中介資料可包括指紋資料、時戳及/或識別碼。接收端可利用中介資料之指紋資料，驗證訊息封裝檔中的指紋是否相同，藉此確保資料完整性，而判斷時戳是否過長以及識別碼是否重覆，可確保大檔案資料與通知訊息可相互對應，此有利於避免中間人攻擊或重覆處理訊息。

於步驟S14中，該接收端藉由該通知訊息取得該訊息封裝檔之儲存位置後，令該接收端下載該訊息封裝檔以進行檢核，再由該接收端傳送回覆訊息至該傳送端。於此所述的檢核，包括接收端是否有收到訊息封裝檔、附檔資料正確與否以及訊息簽章比對。

接收端是否有收到訊息封裝檔之檢核，係指接收端應由通知訊息取得訊息封裝檔，倘若接收端無法由通知訊息取得訊息封裝檔時，則接收端可傳送包含接收端之簽章值以及檔案不存在之訊息封包至傳送端，藉以要求傳送端再進行訊息封裝檔之傳送。

附檔資料正確與否之檢核，目的是要確認檔案內容不被竄改。檢核時，接收端會計算訊息封裝檔中各附檔之雜湊值，接著與收到之通知訊息中指紋資料進行比對，指紋資料如前所述，為利用雜湊演算法由附檔所取得之雜湊值者，接收端透過雜湊值與指紋資料之比對，確認檔案內容正確性。

訊息簽章比對之檢核，目的是作為雙方傳輸認證之用，亦即，接收端會比對傳送端之簽章值以及訊息封裝檔內對應之簽章值，若兩者相同，則表示所收到訊息未遭竄改。

本發明所提出之高效能訊息傳輸方法，結合新的封裝方式以及同時利用兩種通訊協定，以同時滿足大量傳輸、大檔案傳輸、完整性、不可否認性、保證傳輸、高效能等特性。

大量傳輸是指傳遞大量多筆訊息，訊息可以檔案型式存放，例如同時傳送超過100個檔案的數量。大檔案傳輸是指所傳遞的訊息，檔案所佔之位元組數相當多，舉例來說，例如傳送超過100MB的檔案。

資料完整性是指確保在檔案傳輸過程中，檔案內的資料不會被竄改。不可否認性是指訊息傳送與訊息接收之不可否認性，也就是說，確保傳送端無法否認檔案確實由其傳送，以及確保接收端無法否認其已接收檔案。保證傳輸是指傳送端能確定接收端已接收。

為了達成上述特性，在檔案傳輸的各階段(例如前、中、後階段)所額外產生的記憶體、CPU、頻寬等耗用可最 小化，再者，檔案在傳輸完成時，接收端無需以輪詢的方式確保檔案傳輸完成，如此傳輸機制下，更凸顯出其屬高效能之傳輸模式。

如前所述，本發明之高效能訊息傳輸方法透過新的封裝方式，可滿足資料完整性和訊息傳送之不可否認性，下面將說明本發明所提出的封裝方法。

為滿足資料完整性以及訊息傳送之不可否認性，本發明所用之資料封裝方法是以PKI技術對訊息進行簽章作業。具體來說，可藉由雜湊演算法串接「主訊息」與其「附檔」之間的關聯性，並且對「主訊息」進行簽章作業，最後，可將「主訊息」、「簽章值」與其「附檔」，利用MIME的資料交換標準進行封裝。

為提升效率，傳送端僅會將「主訊息」進行簽章作業，「附檔」則不進行簽章作業，其中，「附檔」利用雜湊演算法取得該附檔之雜湊值，以作為其指紋資料，此指紋資料放進「主訊息」中，成為主訊息內容的一部分，另外，僅針對「主訊息」利用PKI技術進行數位簽章之處理，即傳送端以其私鑰進行簽章，接收端以傳送端的公鑰進行驗章。

當「主訊息」利用PKI技術進行簽章時，儲存成Detached特性的簽章格式，例如PKCS1、PKCS7或XML等簽章格式。之後，利用MIME封裝相關訊息，也就是說，將「主訊息」之原文與其簽章值分離，於使用「主訊息」之原文完成簽章計算後，原文不會被包含在簽章訊息內。接著將原文與不含原文之簽章訊息，利用MIME的資料交 換標準將「主訊息」之原文、使用原文簽章計算但不含原文之簽章訊息以及「附檔」依序進行封裝。

另外，也可利用MIME來封裝多筆訊息，亦即若有多個檔案，可使用相同方式進行處理，藉此提升I/O效能。另外，將「主訊息」之原文、使用原文簽章計算但不含原文之簽章訊息以及「附檔」依序進行封裝，在接收端接收訊息時，可依據MIME的資料標準，只取出所需資料進行處理，故可提升效能。

請參照第2圖，係為本發明之高效能訊息傳輸方法有關MIME訊息結構的關係示意圖。如圖所示，在MIME訊息(MIME message)中，包括多個部分(multi-part)，如圖中範圍21所示，三個Body Part是一組的，第一個Body Part是Payload訊息，第二個Body Part是針對第一個Body Part的PKCS#7 Detached簽章值，第二個Body Part是包括附檔(Attached File)的擴充，可夾多個檔案，每一個附檔都是一個Body Part。因此，整個MIME訊息中可包含多組如上述之多個Body Part組成的訊息結構。

請參照第3圖，係為本發明之高效能訊息傳輸方法有關MIME訊息中主訊息與附檔的關係示意圖。如圖所示，以一組多個Body Part組成的訊息結構為例，第一Body Part為主訊息，第二個Body Part為簽章值，其餘為附檔，如圖中Attached File(1)、Attached File(2)、Attached File(3)所示。

如前所述，「附檔」會利用雜湊演算法取得該附檔之雜湊值，以作為其指紋資料，此指紋資料放進「主訊息」 中，成為主訊息內容的一部分。因此，可由圖中各附檔取得雜湊值(Hash value(1)、Hash value(2)、Hash value(3))，上述雜湊值會被置入主訊息，如圖中已置入雜湊值的主訊息31所示。

另外，本發明所使用之資料傳輸方法是結合兩種類型通訊協定，即包括「大檔傳輸協定」及「雙向認證之交換協定」。大檔傳輸協定是指適合用來傳輸大檔的通訊協定，例如FTP(File Transfer Protocol，FTP)、SFTP(SSH FTP)或FTPS(FTP over SSL)，而本發明提出之資料封裝方式，將大量檔案與其簽章值封裝成大檔。雙向認證之交換協定是指在傳送端傳送訊息給接收端後，接收端在接收或處理後回覆Ack的通訊協定，且訊息之資料內容及Ack內容皆需包含利用PKI技術進行簽章之簽章值，以利於雙方驗證。目前具此特性的交換協定，例如ebMS協定。

同時利用上述兩種協定，傳送端在利用「大檔傳輸協定」傳送訊息封裝檔完成後，立即將與此大檔有關的中介資料(metadata)，使用「雙向認證之交換協定」將中介資料作為訊息傳送，並在接收端接收後，以相同協定回覆Ack。更具體來說，傳送端在利用大檔傳輸協定傳送完成後，立即將與此大檔有關的中介資料以及傳送端自身的簽章值傳送至接收端，接收端在處理後會回覆含接收端自身的簽章值的Ack，如此可滿足「訊息接收之不可否認性」之需求。

傳送端在利用大檔傳輸協定傳送完成後，立即將與此大檔有關的中介資料，即包含與此大檔有關的指紋資料、 時戳及識別碼，使用此協定以通知訊息(event)的型式傳送，接收端可驗證通知訊息內之指紋資料與訊息封裝檔之指紋資料是否相同，另外確認時戳是否過長以及識別碼是否重覆，藉此確保大檔資料與通知訊息可相互對應，並避免中間人攻擊或重覆處理訊息。

傳送端在接收到Ack後，也可確保資料已正確傳輸，如此可滿足「保證傳輸」特性。接收端可選擇是否將處理結果放入Ack中，若有放入Ack中，傳送端也可得知訊息否正常處理，若資料未正常處理，可根據Ack內容進行相對應之作業。傳送的通知訊息，可包含與此訊息封裝檔有關的中介資料，中介資料的資料位元組數量可能遠小於原始檔案的位元組大小，雖有上述作業，但小量的檔案在此傳輸作業上仍能滿足「高效率」之特性。

傳送端在檔案傳輸完成後，利用通知訊息通知接收端，接收端無需自行開發程式，檢核協定封包是否為最後一個封包，也無需以輪詢方式確認封包是否傳送完畢，故可有效減少不必要的效能耗費，即時回覆的Ack也可讓傳送端確保資料已接收/處理完成，此可提升自動化程度。

請參照第4和5圖，分別說明本發明之高效能訊息傳輸方法中傳送端與接收端有關檔案傳送與訊息傳遞的處理流程圖，以及本發明之高效能訊息傳輸方法中傳送端與接收端有關檢核與驗證的處理流程圖。對於本發明所提出之通訊協定對談機制，接下來將透過實例說明，有關「大檔傳輸協定」係選用SFTP，而「雙向認證之交換協定」則選 用ebMS，透過下面流程圖，來說明傳送端與接收端有關檔案傳送與訊息傳遞以及檢核與驗證等流程。

如第4圖所示，係說明傳送端與接收端有關檔案傳送與訊息傳遞的處理流程圖，其中，接收端還可分為前端處理和後端處理，接收端前端處理係指與傳送端之間的通訊處理，接收端後端處理則指接收端內部的資料處理。

於流程S41中，傳送端封裝欲傳輸之檔案。傳送端將欲傳送的訊息以訊息封裝格式封裝成一個訊息封裝檔，封裝方式可採用前述先將主訊息以PKI進行簽章作業，並利用MIME的資料交換標準進行封裝。

於流程S42中，傳送端運用SFTP上傳封裝檔(訊息封裝檔)。為了具備大檔傳輸特性，於此採用SFTP傳輸協定來傳送封裝檔。

於流程S43中，接收端接收上傳之封裝檔。因為是採用SFTP傳輸協定，故傳送端可有效率地傳送封裝檔至接收端。

於流程S44中，接收端完成接收上傳封裝檔，此時接收端會回覆訊息至傳送端，通知已完成接收。

於流程S45中，傳送端發出訊息抵達之事件通知。於封裝檔成功上傳後，傳送端可透過ebMS協定發出一個訊息，訊息內容包含傳送端的簽章值以及封裝檔的中介資料。這裡所述事件通知即是前述之通知訊息，其目的用於告知接收端封裝檔已傳送完成，接收端可接著進行處理。

於流程S46中，接收端接收訊息抵達之事件通知。此 流程即接收端收到通知訊息。

於流程S47中，接收端產生事件驅動後端處理。到本流程之前，接收端所執行流程皆為前端處理，即與傳送端之間的訊息溝通，於本流程中，接收端在知悉收到通知訊息，將驅動接收端執行後端處理。

於流程S48中，接收端後端執行訊息處理。亦即，接收端接收到透過ebMS協定之通知訊息後，接收端會進行後續處理，具體來說，接收端由通知訊息取得檔案路徑，利用檔案路徑自檔案系統(file system)擷取對應的封裝檔，以執行訊息處理作業。

本實施例主要說明透過兩種不同通訊協定，先將封裝好的大檔傳送至接收端，並通知接收端有關大檔的資訊(例如中介資料)，使得接收端取得大檔並進行處理，此時在不考量突發狀況下，接收端順利取得來自傳送端之檔案，接收端可將處理情況回應給傳送端。

若考量有其他突發問題下，接收端後端可進行例如檔案健全或簽章檢核等程序，如第5圖所示，係說明傳送端與接收端有關檢核與驗證的處理流程圖，其中，此部分檢核主要在接收端後端進行。

於流程S51中，接收端後端判斷是否存在檔案。此流程是接續第4圖中流程S48，由於接收端可透過通知訊息取得檔案路徑，因而此步驟是判斷封裝檔是否存在。若是檔案不存在，則可透過ebMS協定回應一個檔案不存在的Ack給傳送端，Ack值包含接收端簽章值及哪一個檔案不 存在之資訊。傳送端接收到查無檔案之通知後，可執行訊息重發的處理流程。

如圖所示，若存在，則前進流程S52，若不存在，則透過接收端前端發出查無檔案之回應訊息，另外傳送端可接收查無檔案之回應訊息，如圖中流程S511和S512所示。

於流程S52中，接收端後端判斷是否有附檔。在前一流程中，若是檔案存在，接收端讀取對應的訊息封裝檔案，並進一步判斷是否有附檔。若有，則前進流程S53，需再驗證附檔是否有問題，若無，則直接前進流程S55。

於流程S53中，接收端後端計算附檔之指紋資料。本流程即在有附檔下，先針對每一個附檔計算雜湊值，也就是於此所述之指紋資料。

於流程S54中，接收端後端將前一流程中附檔之指紋資料與訊息本文(通知訊息)內指紋資料進行比對，也就是將附檔與通知訊息兩者中取得指紋資料進行比對，經比對後(流程S541)，若不相符，則前進流程S542，產生附檔指紋不符訊息，即回應一個附件指紋不符的Ack至傳送端，若比對相符，則前進流程S55。

於流程S55中，接收端後端計算訊息本文簽章值。本流程主要判斷通知訊息是否無誤，針對通知訊息之原文計算簽章值，並與封裝檔內對應的簽章值比對(流程S551)，如不符，則前進流程S552，產生驗章不符訊息，若比對相符，則可回覆訊息接收成功的Ack給傳送端。

於流程S56中，接收端後端執行應用系統處理，並回 覆傳送端，如於流程S561所示之接收端回覆訊息已接收之回應訊息，以及於流程S562中，接收端接收訊息已接收之回應訊息。

綜上所述，本發明之高效能訊息傳輸方法，透過利用兩種通訊協定，藉此達到大量傳輸、大檔案傳輸以及高效能等需求。為了滿足大量傳輸、大檔案傳輸之特性，可選擇如FTP、FTPS或SFTP等協定，將已封裝檔案先傳送至接收端，接著透過如ebMS通訊協定來通知接收端取得封裝檔案並進行處理，因採用ebMS通訊協定可符合傳輸安全性和一致性等需求，故運用兩種通訊協定，再搭配本發明所述之封裝方式，將可使發明之訊息傳輸方式具備大量傳輸、大檔傳輸、完整性、不可否認性、保證傳輸、高效能等特性。

上述實施形態僅例示性說明本發明之原理及其功效，而非用於限制本發明。任何熟習此項技藝之人士均可在不違背本發明之精神及範疇下，對上述實施形態進行修飾與改變。因此，本發明之權利保護範圍，應如後述之申請專利範圍所列。

Claims (10)

1. 一種高效能訊息傳輸方法，該方法包括：令傳送端將欲傳送檔案以封裝格式封裝，進而產生訊息封裝檔；令該訊息封裝檔透過第一傳輸協定傳送至接收端；於該訊息封裝檔傳送至該接收端後，令該傳送端透過第二傳輸協定發送一通知訊息至該接收端；以及該接收端藉由該通知訊息取得該訊息封裝檔之儲存位置後，令該接收端下載該訊息封裝檔以進行檢核，再由該接收端傳送回覆訊息至該傳送端。
2. 如申請專利範圍第1項所述之高效能訊息傳輸方法，其中，該第一傳輸協定為大檔傳輸協定，該第二傳輸協定為雙向認證之交換協定。
3. 如申請專利範圍第1項所述之高效能訊息傳輸方法，其中，令該接收端無法由該通知訊息取得該訊息封裝檔時，該接收端傳送包含該接收端之簽章值以及檔案不存在之訊息封包。
4. 如申請專利範圍第1項所述之高效能訊息傳輸方法，其中，該通知訊息包括該傳送端之簽章值以及該訊息封裝檔之中介資料。
5. 如申請專利範圍第4項所述之高效能訊息傳輸方法，其中，該中介資料包括指紋資料、時戳或識別碼。
6. 如申請專利範圍第5項所述之高效能訊息傳輸方法，其 中，該檢核之進行係包括計算該訊息封裝檔中各附檔之雜湊值，以與該通知訊息中該指紋資料進行比對。
7. 如申請專利範圍第1項所述之高效能訊息傳輸方法，其中，該檢核之進行係包括比對該傳送端之簽章值以及該訊息封裝檔內對應之簽章值。
8. 如申請專利範圍第1項所述之高效能訊息傳輸方法，其中，該欲傳送檔案分為主訊息和附檔，且其中，該附檔係透過雜湊演算法以得到該附檔之雜湊數，且於該雜湊數置入該主訊息後進行數位簽章。
9. 如申請專利範圍第8項所述之高效能訊息傳輸方法，其中，該訊息封裝檔包括該主訊息之原文、使用該原文簽章計算但不含該原文之數位簽章或該附檔。
10. 如申請專利範圍第9項所述之高效能訊息傳輸方法，其中，該封裝格式為多用途互聯網郵件擴展(Multipurpose Internet Mail Extensions，MIME)。