本文提出了一個旨在幫助指導設計分布式計算系統各模塊功能的原則，稱之為端到端原則。該原則表明，考慮到在底層提供功能的成本，這些實現在系統底層的功能可能是多余的或沒有提供什么價值。本文討論的例子包括比特錯誤恢復、基于加密的安全、重復信息抑制、系統崩潰恢復以及交付確認，性能是當前在底層支持這些功能的唯一理由。

簡介

定義功能之間的適當界限也許是系統設計師的主要活動，為功能實現選擇合適位置的指導原則是系統設計者最重要的工具之一。本文討論的這組原則已經用了很多年，但既沒有被明確識別，也沒有有力的論證。然而，數據通信網絡作為計算機系統的組成部分的出現，使該原則的論點更加鮮明，其適用情況和理由更加明顯。本文明確闡述了這一原則，以便研究其性質，看看到底有多普遍。該原則訴諸于應用需求，并提供了在分層系統中在上層實現功能的理由，使其更接近使用該功能的應用。接下來我們首先考慮這一原則的通信網絡版本。

在一個包括通信的系統中，通常在通信子系統周圍定義模塊邊界，并在其和系統其他部分之間定義牢固的接口。這么做的時候，會發現一個功能列表，其中每個功能都可能以幾種方式中的任何一種來實現: 由通信子系統實現，由其調用者實現，聯合實現，或者也許這個功能是多余的，又或者每個人都做自己的版本。在考慮不同選擇時，應用需求為一類原則提供了基礎，其內容如下:

相關功能只有站在通信系統終端的應用知識的幫助下才能完整正確的實施。因此，提供該功能作為通信系統本身的特征是不可能的。(有時，通信系統提供的不完整版本的功能可能有用，可以提高性能）。

我們將這種反對在底層實現功能的原則稱為"端到端原則"，下面幾節將詳細研究該原則。首先介紹一個使用該原則的典型案例研究(可靠數據傳輸)，然后展示同一論點可以應用于哪些功能的范圍。就數據通信系統而言，這個范圍包括加密、重復信息檢測、信息排序、保證信息交付、檢測主機崩潰和送達保證。在更廣泛的背景下，該原則似乎適用于計算機操作系統的許多其他功能，包括文件系統。然而，為了使研究跟容易，我們只考慮更具體的數據通信背景。

端到端考量

考慮"可靠文件傳輸"問題。文件通過文件系統存儲在計算機A的磁盤存儲器中，主機A通過數據通信網絡與主機B相連，后者也有文件系統和磁盤存儲器，目標是將文件無損的從主機A的存儲空間轉移到主機B的存儲空間。在這種情況下，應用程序是文件傳輸程序，一部分在主機A運行，一部分在主機B運行。為了討論這個過程中對文件完整性的可能威脅，我們假設涉及以下具體步驟:

在主機A上，文件傳輸程序調用文件系統從磁盤上讀取文件，文件駐留在若干個軌道上，文件系統以獨立于磁盤格式的固定大小的塊將其傳遞給文件傳輸程序。

同樣在主機A上，文件傳輸程序要求數據通信系統使用某種通信協議傳輸文件，該協議將數據分割成包，數據包大小通常與文件塊大小和磁盤軌道大小不同。

數據通信網將數據包從計算機A傳送到計算機B。

在主機B上，數據通信程序將數據包從數據通信協議中取出來，并將所含數據交給文件傳輸應用程序的第二部分，即在主機B內操作的部分。

在主機B上，文件傳輸程序要求文件系統將接收到的數據寫到主機B的磁盤上。

基于該模型所涉及的步驟，細心的設計者可能會關注以下一些事務威脅:

該文件雖然最初正確寫入到主機A的磁盤上，但由于由于磁盤存儲系統中的硬件故障，現在讀取可能包含不正確的數據。

文件系統、文件傳輸程序或數據通信系統可能在主機A或主機B上緩沖和復制文件數據時出錯。

硬件處理器或其本地內存在主機A或主機B進行緩沖和復制時可能會出現短暫錯誤。

通信系統可能會丟失或改變包中的位，或者丟失整個包，或者多次傳送某個包。

任何一個主機在執行未知數量(可能是全部)的事務后，都可能在事務執行的中途崩潰。

那么，一個可靠文件傳輸應用程序將如何應對這一系列威脅？一種方法可能是使用重復拷貝、超時和重試、仔細定位錯誤檢測的冗余、崩潰恢復等來強化每個步驟，目標是將單獨威脅的概率降低到一個可接受的小概率。不幸的是，系統對抗第二個威脅需要編寫正確的程序，這項任務相當困難，而且并非所有必須考慮的程序都是由文件傳輸應用的開發者編寫的。如果進一步假設所有這些威脅的概率相對較低，低到允許系統完成有用的工作，那么非要采取把所有事情做三遍這樣的蠻力反制措施就顯得不太經濟了。

另一種方法可被稱為"端到端檢查和重試"。假設作為應對第一種威脅的輔助手段，每個文件都存儲一個校驗和，該校驗和具有足夠的冗余度，可以將文件中未被發現的錯誤的機會減少到一個可接受的概率。然后，作為最后的附加步驟，主機B中的文件傳輸應用程序將文件副本從磁盤存儲系統中讀回內存，重新計算校驗和，并將此值送回主機A，在那里與原始文件校驗和進行比較。只有當兩個校驗和一致時，文件傳輸應用程序才會宣布該事務已提交。如果比較失敗，則說明出了問題，可以嘗試重試。

如果故障真的相當罕見，這種技術通常會在第一次嘗試時發揮作用，偶爾可能需要第二次甚至第三次嘗試。人們可能會認為在同一個文件傳輸嘗試中出現兩次或更多故障，表明系統的某些部分需要修復。

現在我們考慮一個常見建議，即通信系統在內部提供可靠數據傳輸保證。通信系統可以通過提供可選擇的冗余來實現，例如數據包校驗、序列號檢查和內部重試機制等。在大部分情況下，未檢測到的比特錯誤的概率可以減少到理想水平。問題是，通信系統方面的這種嘗試是否對可靠文件傳輸應用有幫助。

答案是，第四種威脅可能已經被消除了，但可靠文件傳輸應用程序仍然必須對抗其余的威脅，所以仍應根據文件的端到端校驗提供重試。而如果這樣做了，在通信系統中為提供可靠數據傳輸保證所花費的額外努力只是減少了文件傳輸應用的重試頻率，對結果的必然性或正確性沒有影響，因為無論數據傳輸系統是否特別可靠，端到端校驗和重試都能保證文件的正確傳輸。

因此，結論是: 為了實現可靠文件傳輸，執行傳輸的應用程序必須提供針對文件傳輸的、端到端的可靠性保證，在這種情況下，要有檢測故障的校驗和以及重試/提交計劃。對于數據通信系統來說，不遺余力的做到特別可靠，并不能減少應用程序確保可靠性的負擔。

一個過于真實的例子

最近MIT出現了一個有趣的例子，說明人們可能遇到的陷阱。一個網絡系統涉及幾個由網關連接的本地網絡，從一個網關到下一個網關的每一跳都使用了數據包校驗，其假設是對正確通信的主要威脅是傳輸過程中的比特損壞。應用開發者知道這種校驗，認為網絡提供了可靠的傳輸，而沒有意識到傳輸的數據在存儲在每個網關時是不受保護的。一臺網關計算機出現了某個瞬時錯誤，當把數據從輸入緩沖區復制到輸出緩沖區時，一個字節對被交換了，其頻率大約為每百萬字節中有一個這樣的交換。在一段時間內，一個操作系統的許多源文件反復通過有缺陷的網關傳輸。其中一些源文件被字節交換破壞了，文件所有者被迫進行最終的端到端錯誤檢查，即與舊文件進行手工比較和糾正。

性能方面

然而，如果得出結論說較低層級不應該在可靠性方面發揮任何作用，那就太簡單了。考慮一個不太可靠的網絡，每發送一百條信息就會丟掉一條，那么上述簡單策略(即傳輸文件，然后檢查文件是否正確到達)隨著文件長度的增加，表現會更差。文件的所有數據包正確到達的概率隨著文件長度的增加而呈指數級下降，因此傳輸文件的預期時間隨著文件長度的增加而呈指數級增長。顯然，在較低層級上做出一些努力來提高網絡可靠性，可以對應用性能產生重大影響。但是，這里的關鍵思想是，較低層級不需要提供"完美"的可靠性。

因此，在數據通信系統內投入可靠性措施的工作量被認為是基于性能的工程權衡，而不是對正確性的要求。請注意，性能在這里有幾個方面。如果通信系統太不可靠，文件傳輸應用的性能就會受到影響，因為端到端校驗失敗后要經常重試。如果通信系統用內部可靠性措施來加強，這些措施也有性能成本，其形式是冗余數據所損失的帶寬，以及在傳送數據之前等待內部一致性檢查所增加的延遲。如果考慮到無論通信系統變得多么可靠，文件傳輸應用的端到端檢查仍然必須實施，那么就沒有理由在這個方向上走得太遠。適當"權衡"需要仔細思考，例如可以從設計通信系統開始，以提供很少的成本和工程努力所帶來的可靠性，然后評估其錯誤水平，以確保與文件傳輸層面可接受的重試頻率一致。在應用層以下的任何一點上，爭取實現可以忽略不計的錯誤率可能并不重要。

基于性能來證明將功能放在低級子系統中的合理性，必須謹慎行事。有時，通過對問題的徹底研究，在高層級上也可以實現同樣或更好的性能提升。如果在低級子系統中執行某個功能，只需對已經包含在低級子系統中的機器進行最小的擾動，那么在低級子系統中執行這個功能可能更有效率，但相反的情況也會發生，也就是說，在低級子系統中執行這個功能可能會花費更多。原因有兩個，首先，由于低級子系統是許多應用所共有的，那些不需要該功能的應用無論如何都會為其付出代價。第二，低級子系統可能沒有高層級的信息，所以無法有效完成工作。

性能權衡通常相當復雜。再次考慮在不可靠網絡上進行可靠文件傳輸的問題，提高數據包可靠性的技術通常是某種帶有重試機制的協議，并且對每個包進行錯誤檢查，這種機制既可以在通信子系統中實現，也可以在可靠文件傳輸應用中實現。例如，可靠文件傳輸中的接收器可以定期計算迄今為止收到的文件部分的校驗和，并將其傳回給發送者，發送方可以重新傳輸任何錯誤部分。

端到端原則并沒有告訴我們應該把早期檢查放在哪里，任何一層都可以做這個性能增強的工作。將早期重試協議放在文件傳輸應用中可以簡化通信子系統，但可能會增加總體成本，因為通信子系統是在應用之間共享的，現在每個應用都必須提供自己的可靠性增強機制。將早期重試協議放在通信子系統中可能更有效，因為可以在網絡內部逐跳執行，減少糾正故障的延遲。同時，可能有些應用會發現自己實現增強的成本太高，但卻沒有選擇余地。為了做出明智選擇，需要大量和系統實現相關的信息。

其他端到端原則案例

送達保證

在低級子系統支持分布式應用，提供本質上必須在應用層實現的功能，可能是在浪費精力，這個基本論點適用于除可靠數據傳輸之外的各種功能。這個觀點最古老也許也是最廣為人知的案例是傳輸確認，數據通信網絡可以很容易的將傳遞給接收者的每條信息所對應的確認返回給發送者。例如，ARPANET，每當傳遞一個信息，都會返回一個稱為"請求下一個信息"(RFNM, Request For Next Message)[1]的包。盡管這種確認在網絡中作為某種擁塞控制機制可能有用(早期的ARPANET會在收到RFNM之前拒絕接收來自同一個發送端的新消息)，但ARPANET的應用程序從來沒有覺得該機制有多大用處，因為知道信息是否被送達目標主機并不十分重要，應用程序真正想知道的是目標主機是否對消息進行了處理，在消息送達后但在被處理之前可能會發生各種問題，真正需要的確認是端到端的確認，這只能由目標應用發起，告訴發送端"我完成了"，或者"我沒做"。

另一個獲得即時確認的策略是使目標主機足夠完善，當它收到消息時，同時肩負起保證消息被目標應用所處理的責任，這種方法可以消除某些(但不是所有)應用對端到端確認的需求。對于那些要求目標主機完成的處理只有在其他主機完成類似處理后才能進行的應用，仍然需要端到端確認，這種應用需要兩階段提交協議[5,10,15]，這是一種更復雜的端到端確認機制。另外，如果目標應用可能會失敗或拒絕進行要求的處理，可能結果是產生一個失敗確認，那么仍然需要實現端到端確認機制。

數據安全傳輸

另一個可以應用端到端原則的領域是數據加密，有三點原因。首先，如果數據傳輸系統執行加密和解密，就必須相信它能安全的管理所需的加密密鑰。其次，數據是透明的，因此，當數據進入目標節點并被傳送到目標應用時，容易受到影響。最后，消息的真實性仍然必須由應用程序檢查。如果應用程序執行端到端加密，就可以獲得所需的認證檢查，可以按照需求管理密鑰，而且數據永遠不會暴露在應用程序之外。

因此，為了滿足應用需求，通信子系統沒有必要對所有流量進行自動加密。然而，通信子系統對所有流量的自動加密可能是為了確保其他事情: 防止行為不端的用戶或應用程序故意傳輸不應暴露的信息。所有數據在進入網絡時自動加密是系統設計者用來確保信息不會泄漏到系統外的另一個防火墻。然而請注意，這與系統對用戶進行驗證從而保證對特定數據的訪問權是不同的需求。這種網絡級加密可以相當簡單，所有主機都可以用相同的密鑰，并經常改變密鑰。沒有用戶級密鑰，從而簡化了密鑰管理問題。該技術與應用級認證及加密是互補的，兩種機制都不能完全滿足所有需求。

重復消息抑制

一個更復雜的場景是重復信息的抑制。某些通信網絡被設計為消息或消息的一部分可能會被傳遞兩次，這通常是由于網絡內的超時觸發故障檢測和重試機制的結果。網絡可以提供監控和抑制此類重復消息的能力，或者只是簡單的傳遞這些消息。人們可能會想到，應用程序會發現處理這種可能會傳遞兩次相同消息的網絡是非常麻煩的事情。這的確很麻煩，不幸的是，即使網絡抑制了重復消息，應用程序本身也可能在自己的失敗/重試程序中意外的產生重復請求。這些應用層的重復消息在通信系統看來是不同的消息，所以無法抑制。抑制必須由應用本身來完成，應用需要知道如何檢測自己造成的重復消息。

一個必須在高層處理的重復抑制的常見例子是，當遠程系統沒有對用戶操作做出相應，用戶對此感到困惑時，會發起一次新的操作。另一個例子是，大多數通信應用涉及到應對多站點事務中某一端的系統崩潰的規定: 當崩潰的系統再次啟動時，重新建立事務。不幸的是，對系統崩潰的可靠檢測是有問題的，因為可能只是丟了一個包或確認消息被延遲了。如果是這樣，重試的請求就是一個重復的請求，只有應用程序才可以發現。因此，端到端論點再次出現: 如果應用層無論如何都要有一個抑制重復的機制，該機制也可以抑制通信網絡內部產生的任何重復，所以該功能不需要在底層實現，同樣的基本推理也適用于可以被完全忽略的信息以及重復信息。

保證FIFO消息傳遞

確保消息以相同順序發送通常是通信子系統的另一項功能，實現這種先進先出(FIFO)行為的機制保證了在同一虛擬鏈路上發送的消息的順序。沿著獨立的虛擬鏈路發送的消息，或通過通信子系統外的中間進程發送的消息，可能會以不同于發送順序的順序到達。分布式應用中，某個節點可以發起請求，在幾個不同的目的地點發起某個操作，這就無法利用先進先出的排序特性來保證請求的操作以正確的順序發生。相反，必須通過一個比通信子系統更高層的獨立機制控制操作的順序。

事務管理

現在，我們已經將端到端原則應用于SWALLOW分布式數據存儲系統的構建中[15]，顯著減少了開銷。SWALLOW提供了被稱為存儲庫的數據存儲服務器，可用于遠程存儲和檢索數據。訪問存儲庫的數據通過向其發送消息來完成，該消息指定了要訪問的對象、版本和訪問類型(讀/寫)，如果是寫訪問，還要加上要寫的值。底層消息通信并不抑制重復消息，因為: a)對象標識符加上版本信息足以檢測重復的寫入，b)重復的讀請求消息的效果只是產生一個重復響應，調用方很容易監測并丟棄。因此可以極大簡化低級別消息通信協議。

底層消息通信系統也不提供交付確認。寫入請求的調用方需要的確認是數據被安全的存儲，這種確認只能由SWALLOW系統的高層提供。對于讀請求，交付確認是多余的，因為包含讀取值的響應已經足夠了。通過消除交付確認，傳輸的消息數量減少了一半，從而對主機負載和網絡負載都產生了很大影響，提高了性能。這個思路也被用于開發遠程訪問磁盤記錄的實驗性協議[6]，減少低級協議中的路徑長度對于保持遠程磁盤訪問的良好性能非常重要。

確定目標

使用端到端原則有時需要對應用需求進行微妙的分析。例如，考慮一個承載分組語音連接(即數字電話會話)的計算機通信網絡，對于那些傳輸語音包的連接，端到端原則的一個適用版本是: 如果通信系統的低層試圖在比特級完成完美的通信，可能會在數據包交付中引入不受控制的延遲，例如，要求重傳損壞的數據包，并在早期數據包被正確重傳之前推遲交付。這種延遲對需要以恒定速率向接收方提供數據的語音應用來說是一種干擾。最好的辦法是接受輕微損壞的數據包，甚至用靜音、前一個數據包的復制品或噪音來取代。語音的自然冗余，加上高水平糾錯程序，甚至其中一個對話著說一聲"對不起，有人掉了一個杯子。請你再說一遍好嗎？"(如果這種情況比較少的話)，都可以處理這種丟包的情況。

然而，這種強端到端原則適合于特定應用(兩個人的實時對話)，而不是通用原則(例如一般語音)。如果考慮語音信息系統，在該系統中，語音包被存儲在文件中，以便接收者以后收聽，那么情況就不一樣了。將數據包傳送到存儲介質中的短暫延遲并不具有特別的破壞性，因此在低層實現可靠性而引入延遲就是可接受的選項。更重要的是，在錄音信息中獲得盡可能多的準確性，實際上對應用是有幫助的，因為收件人在聽錄音的時候，不可能要求發件人重復某個句子。另一方面，在存儲系統作為語音通信的接收端時，端到端原則確實適用于數據包排序和重復抑制。因此，端到端原則并不是絕對的，而是有助于應用和協議設計分析的準則，人們必須謹慎確定該原則適用于哪些場景。

歷史，以及在其他系統領域的應用

本文引用的個別端到端案例并非原創，而是多年積累下來的。第一個案例中的有問題的中間傳遞確認案例是M.I.T.兼容時間共享系統(M.I.T. Compatible Time-Sharing System)的"wait"信息，每當用戶輸入一個命令時，系統就會在用戶終端上打印出來[3]。(該信息在系統早期有一定價值，當時崩潰和通信故障非常頻繁，中間確認提供了一些需要的保證，即一切都很好）。

與加密有關的端到端原則是由Branstad在1973年的一篇論文[2]中首次公開討論的，估計軍事安全界在那之前就進行了保密討論。Diffie和Hellman[4]以及Kent[8]更深入地發展了這些觀點，Needham和Schroeder[11]為此設計了改進的協議。

Gray[5]、Lampson和Sturgis[10]以及Reed[13]的兩階段提交協議使用了一種端到端的論證方式來證明其有效性。它們是端到端的協議，其正確性不依賴于通信系統內的可靠性、FIFO排序或重復抑制，任何可能的問題也可能由其他系統組件故障引入。Reed在關于去中心化原子操作的博士論文的第二章中明確提出了這個論點[14]。

端到端原則常被應用于系統的錯誤控制和糾錯。例如，根據政策和法律要求，銀行系統通常提供高級別審計程序，這些高層次審計程序不僅會發現高層次錯誤(如對錯誤的賬戶進行提款)，還會發現低層次的錯誤(如基礎數據管理系統中的協調錯誤)。因此，相對于絕對消除這種協調錯誤的昂貴算法，可能某種只是該錯誤出現頻率較低的低成本算法要更合適。在航空預訂系統中，可以依靠代理人不斷嘗試，忍受系統崩潰和延遲，直到預訂被確認或被拒絕。因此，保證未確認的預訂請求在系統崩潰后仍然可以恢復的較低級別的恢復程序并不重要。在電話交換機中，可能導致單個呼叫掉線的故障被認為不值得提供明確的恢復，因為如果有必要，呼叫者可能會再次發起呼叫[7]。所有這些設計方法都是端到端原則被應用于自動恢復的例子。

網絡協議界關于數據報、虛擬鏈路和無連接協議的辯論，大部分是關于端到端的爭論。模塊化論點推崇可靠的、FIFO排序的、重復抑制的數據流，認為這是一個容易構建的系統組件，該觀點有利于虛擬鏈路。端到端論點聲稱，集中提供這些功能的每個版本對某些應用來說是沒有意義的，這些應用會發現從數據報開始構建自己版本的功能會更容易。

20世紀50年代，系統分析員開發了一個非通信應用中的端到端原則版本，他們的職責包括在大量磁帶卷上讀寫文件。屢次試圖定義和實現"可靠的磁帶子系統"的努力屢屢失敗，因為不穩定的磁帶機，不可靠的系統操作者，以及系統崩潰，都對任何狹隘的可靠性措施產生了影響。最終，每個應用都提供了自己的應用相關的檢查和恢復策略，并假定低級別的錯誤檢測機制最多只能減少高級別檢查失敗的頻率，這已經成為標準做法。Multics文件備份系統[17]就是這樣的例子，它建立在磁帶子系統格式的基礎上，提供了非常強大的錯誤檢測和糾正功能，并以記錄標簽和每個文件的多個副本的形式提供了自己的錯誤控制。

用于支持精簡指令集計算機(RISC)架構的論點與端到端觀點類似。RISC的論點是，架構的客戶將通過準確實現原始工具所需的指令來獲得更好的性能。計算機設計者如果試圖預測客戶對某一深奧功能的要求，很可能無法100%滿足目標需求，客戶最終還是會重新實現該功能。(感謝M. Satyanarayanan提供了這個例子）。

Lampson在支持"開放操作系統"[9]的論點中使用了一個類似于端到端原則的論據作為理由。Lampson反對將任何功能作為下層模塊的永久實現，而是認為該功能可以由下層模塊提供，但應該總是可以被應用程序的特殊版本所替代。其理由是，對于你能想到的任何功能，至少有些應用程序會發現，為了正確滿足自己的需求，必須自己實現這個功能。這種推理導致Lampson提出了"開放"系統，整個操作系統由一個庫中的可替換例程組成，這種方法直到最近才在專用于單一應用的計算機中變得可行。可能的情況是，大規模操作系統中大量典型的功能確定的管理功能只是經濟壓力的產物，因為要求對昂貴的硬件進行復用，因此需要受控的管理功能。事實上，最近大多數系統"內核化"項目，部分的集中于將功能從低級系統中解耦[16,12]。盡管其靈感來自于不同的正確性論證，但副作用是產生了一個對應用程序來說更加靈活的操作系統，而這正是端到端原則的主旨所在。

結論

在選擇通信子系統所提供的功能時，端到端原則是一種"奧卡姆剃刀"。因為通信子系統經常在使用該子系統的應用被知道之前就被指定，設計者可能會被誘惑通過承擔更多功能來"幫助"用戶，對端到端原則的認識可以幫助減少這種誘惑。

如今，談論"分層"的通信協議很時髦，但沒有明確標準來分配各層功能。這種分層對于提高模塊化程度是可取的。端到端的爭論可以被看作是組織這種分層系統的合理原則的一部分。我們希望本文的討論有助于為"適當的"分層的爭論增加實質內容。

審核編輯：郭婷