0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學習在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認識你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

系統(tǒng)設(shè)計的端到端原則

星星科技指導(dǎo)員 ? 來源:DeepNoMind ? 作者:俞凡 ? 2023-06-15 17:28 ? 次閱讀

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

簡介

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

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

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

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

端到端考量

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

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

同樣在主機A上,文件傳輸程序要求數(shù)據(jù)通信系統(tǒng)使用某種通信協(xié)議傳輸文件,該協(xié)議將數(shù)據(jù)分割成包,數(shù)據(jù)包大小通常與文件塊大小和磁盤軌道大小不同。

數(shù)據(jù)通信網(wǎng)將數(shù)據(jù)包從計算機A傳送到計算機B。

在主機B上,數(shù)據(jù)通信程序?qū)?shù)據(jù)包從數(shù)據(jù)通信協(xié)議中取出來,并將所含數(shù)據(jù)交給文件傳輸應(yīng)用程序的第二部分,即在主機B內(nèi)操作的部分。

在主機B上,文件傳輸程序要求文件系統(tǒng)將接收到的數(shù)據(jù)寫到主機B的磁盤上。

基于該模型所涉及的步驟,細心的設(shè)計者可能會關(guān)注以下一些事務(wù)威脅:

該文件雖然最初正確寫入到主機A的磁盤上,但由于由于磁盤存儲系統(tǒng)中的硬件故障,現(xiàn)在讀取可能包含不正確的數(shù)據(jù)。

文件系統(tǒng)、文件傳輸程序或數(shù)據(jù)通信系統(tǒng)可能在主機A或主機B上緩沖和復(fù)制文件數(shù)據(jù)時出錯。

硬件處理器或其本地內(nèi)存在主機A或主機B進行緩沖和復(fù)制時可能會出現(xiàn)短暫錯誤。

通信系統(tǒng)可能會丟失或改變包中的位,或者丟失整個包,或者多次傳送某個包。

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

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

另一種方法可被稱為"端到端檢查和重試"。假設(shè)作為應(yīng)對第一種威脅的輔助手段,每個文件都存儲一個校驗和,該校驗和具有足夠的冗余度,可以將文件中未被發(fā)現(xiàn)的錯誤的機會減少到一個可接受的概率。然后,作為最后的附加步驟,主機B中的文件傳輸應(yīng)用程序?qū)⑽募北緩拇疟P存儲系統(tǒng)中讀回內(nèi)存,重新計算校驗和,并將此值送回主機A,在那里與原始文件校驗和進行比較。只有當兩個校驗和一致時,文件傳輸應(yīng)用程序才會宣布該事務(wù)已提交。如果比較失敗,則說明出了問題,可以嘗試重試。

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

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

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

因此,結(jié)論是: 為了實現(xiàn)可靠文件傳輸,執(zhí)行傳輸?shù)膽?yīng)用程序必須提供針對文件傳輸?shù)?、端到端的可靠性保證,在這種情況下,要有檢測故障的校驗和以及重試/提交計劃。對于數(shù)據(jù)通信系統(tǒng)來說,不遺余力的做到特別可靠,并不能減少應(yīng)用程序確??煽啃缘呢摀?。

一個過于真實的例子

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

性能方面

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

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

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

性能權(quán)衡通常相當復(fù)雜。再次考慮在不可靠網(wǎng)絡(luò)上進行可靠文件傳輸?shù)膯栴},提高數(shù)據(jù)包可靠性的技術(shù)通常是某種帶有重試機制的協(xié)議,并且對每個包進行錯誤檢查,這種機制既可以在通信子系統(tǒng)中實現(xiàn),也可以在可靠文件傳輸應(yīng)用中實現(xiàn)。例如,可靠文件傳輸中的接收器可以定期計算迄今為止收到的文件部分的校驗和,并將其傳回給發(fā)送者,發(fā)送方可以重新傳輸任何錯誤部分。

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

其他端到端原則案例

送達保證

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

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

數(shù)據(jù)安全傳輸

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

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

重復(fù)消息抑制

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

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

保證FIFO消息傳遞

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

事務(wù)管理

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

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

確定目標

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

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

歷史,以及在其他系統(tǒng)領(lǐng)域的應(yīng)用

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

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

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

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

網(wǎng)絡(luò)協(xié)議界關(guān)于數(shù)據(jù)報、虛擬鏈路和無連接協(xié)議的辯論,大部分是關(guān)于端到端的爭論。模塊化論點推崇可靠的、FIFO排序的、重復(fù)抑制的數(shù)據(jù)流,認為這是一個容易構(gòu)建的系統(tǒng)組件,該觀點有利于虛擬鏈路。端到端論點聲稱,集中提供這些功能的每個版本對某些應(yīng)用來說是沒有意義的,這些應(yīng)用會發(fā)現(xiàn)從數(shù)據(jù)報開始構(gòu)建自己版本的功能會更容易。

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

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

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

結(jié)論

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

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

審核編輯:郭婷

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學習之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報投訴
  • 存儲器
    +關(guān)注

    關(guān)注

    38

    文章

    7492

    瀏覽量

    163842
  • 計算機
    +關(guān)注

    關(guān)注

    19

    文章

    7494

    瀏覽量

    87961
  • 數(shù)據(jù)包
    +關(guān)注

    關(guān)注

    0

    文章

    261

    瀏覽量

    24396
收藏 人收藏

    評論

    相關(guān)推薦

    NetApp宣布推出全新的中NVMe AFF A320系統(tǒng)

    NetApp今日宣布推出NetApp ONTAP 9.6、全新的中NVMe AFF A320存儲系統(tǒng)以及更豐富的服務(wù)產(chǎn)品組合,旨在幫
    發(fā)表于 05-11 07:55 ?2513次閱讀

    基于WiMAX接入技術(shù)的網(wǎng)絡(luò)架構(gòu)

    基于WiMAX接入技術(shù)的網(wǎng)絡(luò)架構(gòu) 本文首先分析了WiMAX技術(shù)的市場驅(qū)動力和影響其成功部署的關(guān)鍵因素,隨后介紹了一個基于WiMAX接入技術(shù)的
    發(fā)表于 10-20 21:03 ?734次閱讀

    實時控制系統(tǒng)解決方案

    文章重點對傳輸層網(wǎng)絡(luò)通信協(xié)議TCP/UDP進行了分析,并從滿足遠程工業(yè)控制中可靠性和實時性要求出發(fā),在UDP之上給出了RCP和QSP這兩個層次來實現(xiàn)基于UDP協(xié)議的新的控制系統(tǒng)結(jié)
    發(fā)表于 12-27 16:43 ?23次下載
    <b class='flag-5'>端</b><b class='flag-5'>到</b><b class='flag-5'>端</b>實時控制<b class='flag-5'>系統(tǒng)</b>解決方案

    PMC率先推出支持對稱模式的10G-EPON系統(tǒng)級芯片

    PMCS近日宣布推出支持對稱模式的10G-EPON光纖接入系統(tǒng)級芯片(SoC)解決方案,繼續(xù)保持其在光纖戶領(lǐng)域的領(lǐng)先地位。
    發(fā)表于 03-12 09:13 ?1099次閱讀

    物聯(lián)網(wǎng)解決方案

    英特爾打造核心技術(shù)物聯(lián)網(wǎng)解決方案
    發(fā)表于 12-28 18:12 ?0次下載

    SDN中的時延

    隨著大規(guī)模SDN的不斷發(fā)展,用來管理和衡量網(wǎng)絡(luò)性能的指標也越來越重要。時延就是其中重要的部分,針對該指標已經(jīng)提出了很多計算的方法,主要分為主動探測和被動探測,但是各有優(yōu)缺點。因此,提出一種主動
    發(fā)表于 12-06 15:32 ?0次下載
    SDN中的<b class='flag-5'>端</b><b class='flag-5'>到</b><b class='flag-5'>端</b>時延

    的自動駕駛研發(fā)系統(tǒng)介紹

    Nvidia是比較早做控制車輛工作的公司,其方法訓(xùn)練CNN模型完成從單個前向攝像頭的圖像像素車輛控制的映射。 其系統(tǒng)自動學習一些處理
    的頭像 發(fā)表于 07-13 09:30 ?4943次閱讀
    <b class='flag-5'>端</b><b class='flag-5'>到</b><b class='flag-5'>端</b>的自動駕駛研發(fā)<b class='flag-5'>系統(tǒng)</b>介紹

    基于的自動駕駛系統(tǒng)只能做demo嗎

    只配做demo嗎?由劍橋大學團隊創(chuàng)辦的Wayve無人駕駛軟件公司卻不這么認為。
    的頭像 發(fā)表于 12-26 10:39 ?509次閱讀

    的IO鏈接解決方案

    的IO鏈接解決方案
    發(fā)表于 05-10 10:43 ?1次下載
    <b class='flag-5'>端</b><b class='flag-5'>到</b><b class='flag-5'>端</b>的IO鏈接解決方案

    構(gòu)建的流程體系

    所謂流程的架構(gòu)體系,就是一套有層次的流程管理體系。這種層次體現(xiàn)在由上至下、由整體
    的頭像 發(fā)表于 06-01 15:09 ?2032次閱讀
    構(gòu)建<b class='flag-5'>端</b><b class='flag-5'>到</b><b class='flag-5'>端</b>的流程體系

    NVMe解決方案簡介

    電子發(fā)燒友網(wǎng)站提供《NVMe解決方案簡介.pdf》資料免費下載
    發(fā)表于 08-17 09:59 ?0次下載
    <b class='flag-5'>端</b><b class='flag-5'>到</b><b class='flag-5'>端</b>NVMe解決方案簡介

    低噪聲放大器輸入和輸出匹配原則是什么?阻抗匹配的目的是什么?

    低噪聲放大器輸入和輸出匹配原則是什么?阻抗匹配的目的是什么? 低噪聲放大器輸入和輸出匹配原則
    的頭像 發(fā)表于 10-20 14:55 ?2171次閱讀

    什么是通信?

    在嵌入式系統(tǒng)領(lǐng)域,無論是在汽車、航空航天還是工業(yè)應(yīng)用中,確保關(guān)鍵數(shù)據(jù)安全準確地傳輸至關(guān)重要。為了應(yīng)對這一挑戰(zhàn),一種被稱為通信的安全措施已經(jīng)成為一項基本
    的頭像 發(fā)表于 11-24 11:07 ?1409次閱讀

    測試用例怎么寫

    編寫測試用例是確保軟件系統(tǒng)從頭到尾能夠正常工作的關(guān)鍵步驟。以下是一個詳細的指南,介紹如何編寫
    的頭像 發(fā)表于 09-20 10:29 ?455次閱讀

    爆火的如何加速智駕落地?

    自動駕駛,唯有?)技術(shù)通過消除模塊間數(shù)據(jù)傳遞中的信息損耗和延遲,以神經(jīng)網(wǎng)絡(luò)驅(qū)動感知
    的頭像 發(fā)表于 11-26 13:17 ?261次閱讀
    爆火的<b class='flag-5'>端</b><b class='flag-5'>到</b><b class='flag-5'>端</b>如何加速智駕落地?