| RFC-0131：FIDL 傳輸格式的設計原則 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 我們將說明固定 FIDL 線材的各種設計原則。 |
| 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年/月) | 2021-06-15 |
| 審查日期 (年/月) | 2021-09-29 |
摘要
我們會說明目前 (截至 2021 年 9 月) 固定 FIDL 線路格式的設計原則。
提振精神
FIDL 傳輸格式會指定訊息的編碼和解碼方式，以及傳輸層級中繼資料 (例如交易訊息標頭) 的格式。傳輸格式規格中隱含的理論範疇，就是理論上最適當的實作方式。就像資料結構暗示運算上的特定 Bi-O 邊界一樣，傳輸格式也是一樣。
在 Fuchsia 中，處理序間通訊 (至少控制層) 可透過 FIDL 使用或預計用於。因此，傳輸格式會對作業系統的整體目標效能產生重大影響。同樣地，在隱私權與安全性機制的多層防禦機制中，網路格式扮演了重要的角色。
「FIDL 2.0」的設計於 2017 年 3 月完成。與日後的開發相比，FIDL 2.0 是較為靜態的 FIDL 版本。另請參閱「RFC-0027：用多少付多少」來取得更多歷史背景資訊。
傳輸格式規格的目標如下1：
- 在程序之間有效率地轉移訊息。
- 一般用途：與裝置驅動程式、高階服務和應用程式搭配使用。
- 僅針對 Zircon IPC 進行最佳化，可攜性並非目標。(這個目標已超過 放鬆)。2
- 針對直接存取記憶體進行最佳化；並非機器間傳輸的目標。
- 僅針對 64 位元最佳化；32 位元環境不提供改善。
- 使用具有主機端點性的未壓縮原生資料類型、先提供元素套件，並採用正確的對齊方式，以便直接存取訊息內容。
- 與 C 結構記憶體內版面配置 (含適當的欄位排序和封裝註解) 相容。
- 結構是固定的尺寸和內嵌式；大小不定的資料是以行外方式儲存。
- 結構物不會自我說明，FIDL 檔案會描述其內容。
- 沒有結構版本管理，但介面可透過新方法來擴充通訊協定。(這個目標自放鬆起)。[^2]
- 不需計算偏移量，極少計算，可能會溢位。
- 支援快速的單傳遞編碼和驗證 (合併作業)。
- 支援快速單傳遞解碼和驗證 (合併作業)。
雖然傳輸格式的持續進化有非常具體的設計原則，其中部分原則未必包含所有原因。這個 RFC 試圖明確地寫下這些設計原則。
設計
我們會說明固定 FIDL 線材的各種設計原則。
先低階
如果出現在設計上取捨，以支援高階程式設計的工作 (或相反的) 來支援低階程式設計時，我們通常會選擇啟用低階程式設計。
FIDL 必須符合 Fuchsia 中低階通訊協定的要求；執行個體有時在 malloc 無法使用時，會在啟動過程中使用。或者，如果 FIDL 不符合這些要求，另一個做法是手動設計通訊協定。但在高階程式設計中，如果 FIDL 無法滿足需求，還有很多其他選項可以選擇，例如 Protobuf、Cap'n Proto、JSON、Yml 等。
單次通過，但未分配堆積分配量
單一傳遞中必須能夠編碼及解碼，且分配範圍不得超出堆疊空間 (即沒有動態堆積分配)。
這個原則有點高於低階用途的專長，並確保系統上的任何軟體都能完全加入 FIDL 生態系統。
由於 FIDL 提供「解碼 + 驗證」，因此單一通過要求應與同時提供去序列化和驗證的類似系統進行比較，且該系統最常在兩次票證中完成 (並透過解碼表單進行驗證)。
沒有分配需求的共識是，只要在就地 (也就是就地修改) 進行編碼和解碼即可。
與手動捲動資料結構的效率相等
編寫傳輸格式實作時，必須具有效率和手動捲動資料結構。
這是「用多少付多少」原則的專業認證原則，FIDL 不得基於提供便利性和人體工學提供服務，而犧牲效能。實際上，許多實作項目會選擇降低效率，以提供額外人體工學，但傳輸格式無法決定這項選擇。
標準化表示法
您必須使用一個不明確的 FIDL 值表示，即 FIDL 值只有一個且經過編碼的表示法，且只有一個解碼的 FIDL 值表示法。
強制採用單一呈現方式，線路格式本來就會更加嚴格，這表示實作方式預期輸入的變異數會較少，並且遵循較為直線的路徑。這有助於減少資料差異造成的意外情況，確保正確性。標準形式可讓檢查兩個值是否相等，而無須瞭解結構定義。舉例來說，memcmp 值足以滿足值類型 (對於資源類型有些複雜)。
另請參閱標準表單的撤銷頁面。
指定每個位元組
為確保傳送者沒有資料外洩到另一個程序之間，我們確保所有位元組都能有效率地週遊，且所有位元組都有指定值 (例如邊框間距必須為 0)。例如，這有助於確保不會意外跨程序邊界共用個人識別資訊 (PII)，或避免在未初始化的記憶體中外洩，記憶體可能含有指標值，這可用於解決位址空間版面配置隨機化 (ASLR)。另一個例子是「結尾垃圾」，因為所有資料和帳號代碼都必須納入考量。
在所有位置進行驗證
為達成深度防禦機制，我們希望 FIDL 傳輸格式在所有使用的位置強制執行嚴格的驗證 (例如繫結檢查、字串是格式正確的 UTF-8 程式碼單元序列、帳號代碼的正確類型和權利)。
嚴格驗證是確保平台安全性十分值得，並可協助 API 作者針對 API 結構定義設計狀態假設和不變性驗證。此外，如果沒有在較低層中進行驗證，應用程式往往會自行驗證不變，導致程式碼變得較不明確、效率通常較低，且較容易出錯。
由於嚴格驗證可能是高效能成本的來源，而且 FIDL 適合用於低階層，因此必須有效率地完成這類驗證，適合用於單次通過。
未立即使用反光功能
如果沒有明確選擇加入，對等互連就不得允許對等互連針對通訊協定、公開方法或公開類型執行反射。
例如，如果對等互連呼叫錯誤的 FIDL 方法，則會關閉連線，防止系統擷取對等點的任何資訊。建構這類功能也許是個不錯的做法，但可能會損害隱私且難以復原 (使用者將開始建構這項功能，建構測向功能)。
同樣地，缺少自述式格式的結構也符合這個原則，在生態系統中，與同儕互動會引起彼此信任感的生態系統，應避免過度揭露。(避免使用符合低階標準的自我說明格式，將可大幅提高效能)。
由於我們變更了 FIDL 傳輸格式以配合演進 (如資料表)，所以必須謹慎查看出價反射之間的平衡，並加上足以在沒有結構定義的情況下處理的平衡點。
實作
保持冷靜，並遵守原則。如 RFC-0017 中所示。
效能
大部分的 FIDL 線路指導原則都是針對效能提供，且著重於低階用途。效能是首要考量。
人體工學
人體工學沒有改變。
回溯相容性
此處所述的某些原則與 FIDL 的主要目標相衝突，也就是為穩定的 ABI 提供基礎。舉例來說，在沒有反射功能的情況下，實作回溯相容的通訊協定將充滿挑戰。此外，FIDL 傳輸格式的設計兼顧效能 (往往受到嚴謹度的影響) 與可變動性問題 (往往會有彈性的結果) 之間的平衡。但在這些事物之間取得平衡，就是所謂的樂趣。
安全性考量
此 RFC 說明瞭 FIDL 在 Fuchsia 多層式安全防護機制中扮演的角色。
隱私權注意事項
FIDL 在 Fuchsia 多層式隱私權保護策略中扮演的角色，在 RFC 中說明瞭。
測試
測試沒有任何變更。
說明文件
視需要修改：
缺點、替代方案和未知
如文字中所述。
標準表單的缺點
要求標準化形式可能會限制找出資料理想呈現的問題，並捨棄其他有趣或可採用的表單。
使用稀疏資料表時，標準化是最需要滿足的限制之一，並且會直接與格式必須效能優異的需求衝突。舉例來說，我們可以探索按照使用者提供的順序寫入成員，無需第二條即可重新訂購這些成員，滿足標準化需求條件。
先前的圖片和參考資料
如文字中所述。
-
作者：Jeff Brown jeffbrown@google.com。↩