RFC-0218：IOBuffer：適合有效率的 IO 共用記憶體物件

摘要

我們提議採用新的 IOBuffer 核心基本類型，透過共用記憶體和選用的核心中介作業，提升通訊和分散式 IO 使用情境的安全性、便利性和效能。

提振精神

Fuchsia 作業系統的大部分實作項目都位於使用者空間，分布在多個通訊程序和元件之間。這項刻意設計的選擇通常會比單體系統中的對等實作項目需要更多程序和執行緒，特別是當對等功能直接在單體核心中實作時。雖然這種分散式方法在安全性、開發和更新能力方面具有顯著優勢，但重要影響是，在 Fuchsia 中，許多作業都需要 IPC，而單一核心只需要系統呼叫和狀態讀取/寫入。此外，使用現有 Fuchsia 管道和通訊端基本體的 IPC 涉及多個系統呼叫、模式切換、執行緒躍點和資料副本，才能完成端對端作業。這項額外負荷對通訊和 IO 工作負載的影響可能很大，尤其是涉及大量資料、高頻率和/或低延遲作業的工作負載。

原則上，共用記憶體可用於避免部分或所有這類額外負荷，同時保留 Fuchsia 使用者空間隔離模型的優點。不過，原始共用記憶體有許多限制，在許多情況下難以實現安全、有效率且可靠的通訊，尤其是在涉及多個用戶端、信任或可靠程度不同，或是共用資源的情況下。

部分挑戰包括：

• 安全性和正確性：直接存取共用記憶體通訊模式很難防範誤用或濫用，否則會造成大量額外負擔或複雜性。重要的是，與任意記憶體存取相比，系統呼叫的驗證程序較為簡單。
• 同步處理：直接記憶體存取除了架構記憶體模型外，還提供有限的同步處理機制。
• 生命週期和工作階段：記憶體存取範圍可能難以推斷，且現有基本型別難以強制執行。

這項提案是務實的做法，可解決上述和其他挑戰，並運用 Zircon 對等物件模型改善工作階段管理，以及將核心做為可信的中介機構，強制執行義務。

利害關係人

協助人員：

• cpu@google.com

審查者：

• adanis@google.com
• rashaeqbal@google.com
• fmeawad@google.com
• gmtr@google.com
• maniscalco@google.com
• johngro@google.com
• abarth@google.com
• cpu@google.com

已諮詢：

• miguelfrde@google.com
• puneetha@google.com
• mseaborn@google.com
• mcgrathr@google.com
• quiche@google.com
• mvanotti@google.com
• brunodalbo@google.com

社交：

RFC 經過設計審查，並與 Fuchsia Performance、Diagnostics 和 Zircon Performance Tools WG 進行疊代。

設計

IOBuffer (IOB) 設計引進新型記憶體物件，可有效進行通訊和分散式 IO。這個新物件會將多個記憶體區域封裝成單一連貫的實體，具有不同的屬性和角色，並提供實用的生命週期管理、存取控制和核心仲介作業。

IOB 是具有兩個端點的對等物件組合。端點提供的生命週期管理和信號傳輸功能，與其他對等物件 (例如管道、插座、FIFO 和事件配對) 類似。除了一般端點控制代碼權限提供的存取控制項之外，每個記憶體區域的存取權也可以針對每個端點個別設定，以支援精細的安全屬性。

可設定的核心中介作業支援更強大的安全屬性，其中記憶體存取作業是透過核心系統呼叫代表使用者執行，核心會做為可信賴的中介者，一律遵循要求的存取規則。中介作業會犧牲部分額外負荷，換取穩健性和安全性，同時維持比其他通訊基本型別更低的端對端額外負荷。

相較於由其他離散物件組成的類似結構，這種彈性組合包含生命週期管理、記憶體區域封裝、可設定的存取控制項和核心介面作業，可支援各種共用記憶體通訊和 IO 模式，並提升安全性及便利性。

目標

本提案的高階目標如下：

• 減少通訊和 I/O 的記憶體配置、系統呼叫和排程負擔，縮小單體系統的效能差距。
• 簡化共用記憶體生命週期管理和同步處理。
• 必要時強制執行嚴格的安全不變量。
• 為未來的核心和使用者空間介面奠定基礎。

Endpoints

每個 IOB 都有兩個端點，分別是 Ep0 和 Ep1。IOB 端點控制代碼可能會重複，並由多個程序共用。只要至少有一個端點控制代碼存在，IOB 就會保留基礎記憶體物件，提供與其他對等物件類似的生命週期語意。

記憶體區域

IOB 會封裝一或多個記憶體區域的集合，這些區域具有獨立的屬性和存取控制項，可支援通訊協定中每個區域的預期角色。舉例來說，不同區域可用於鍵/值儲存、用戶端協調、狀態管理和資料酬載轉移等用途。

存取權控管

IOB 建立期間，系統會為每個端點和區域組合設定記憶體存取權。每個端點在各個區域可能會有不同的存取權。驗證作業時，區域存取權控管機制會與端點的控制代碼權限合併。作業的有效權限可能比控制代碼權限更嚴格，但不得超過控制代碼權限允許的範圍。

記憶體存取也可能透過核心調解，而不需要對應。

下表列出與區域相關的三種存取權控管。每個區域可獨立設定對應 (使用者) 和中介 (核心) 存取控制項，而端點權限則來自啟動作業的控制代碼。

端點 Epn 的對應或中介作業有效存取權 eRn 和 eWn 計算方式如下：

中介存取權控管和方向性

使用者和核心存取控制之間有細微的差異，前者是絕對意義上的讀取或寫入存取控制，後者則是在邏輯或方向意義上運作。舉例來說，核心媒介的讀取作業可能涉及更新區域中的記帳資料結構，以指出從緩衝區讀取的資料量。就這個意義而言，唯讀存取權不會阻止核心更新記帳，而是表示只允許邏輯讀取作業和相關的記帳更新。

範例

下圖為 IOB 的示意圖，其中有三個記憶體區域，以及邏輯函式。端點 Ep0 和 Ep1 分別邏輯指派給伺服器和用戶端角色。

1. 區域 0「控制」：
   • Ep0：RW 對應存取權。
   • 第 1 集：RO 對應存取權。
   • 用途：伺服器會在這個區域中寫入不可分割的變數，以發布狀態並協調用戶端的活動。
2. 區域 1「字串對應」：
   • Ep0：RO 對應存取權。
   • Ep1：中介 WO 存取權。
   • 用法：用戶端會使用核心中介作業來內部化字串，伺服器會使用對應以無鎖定方式解讀字串。由於用戶端存取權僅限於中介服務，因此用戶端不得竄改字串對應，只能新增項目，進而消除伺服器潛在的檢查時間和使用時間危害。
3. 區域 2「資料環形緩衝區」：
   • Ep0：RW 對應存取權。
   • Ep1：RW 對應存取權。
   • 用途：用戶端和伺服器都會透過對應直接存取這個區域，使用雙方同意的通訊協定，並接受潛在的完整性問題。

創作

呼叫 zx_iob_create 並設定一組選項，即可建立 IOB。

zx_status_t zx_iob_create(uint64_t options,
                          const zx_iob_region_t* regions,
                          uint32_t region_count,
                          zx_handle_t* ep0_out,
                          zx_handle_t* ep1_out);

參數

• options 保留供日後擴充功能使用。

• regions 是指向 zx_iob_region_t 區域說明陣列的指標。

• region_count 會指定區域陣列中的元素數量。

• ep0_out、ep1_out 是 IOB 端點初始控制代碼的輸出參數。

地區說明

區域的幾何和設定是由 zx_iob_region_t 區域說明結構指定。基本結構包含所有區域類型通用的欄位。

struct zx_iob_region_t {
  uint32_t type;
  uint32_t access;
  uint64_t size;
  zx_iob_discipline_t discipline;
  union {
    zx_iob_region_private_t private_region;
    uint8_t max_extension[4 * 8];
  };
};

• type 會指定區域類型和支援該區域的記憶體物件。

  • 類型 0：私人區域。
  • 類型 1 以上：保留供日後使用。

• access 會為每個端點指定存取權控管修飾符。記憶體存取規範「可能」會指定哪些存取位元組合有效，以支援安全性或正確性屬性。

  • 位元 0：Ep0 的 uR0 對應。
  • 位元 1：Ep0 的 uW0 對應。在某些系統上可能表示 uR0。
  • 位元 2：Ep0 的 kR0 中介存取權。
  • 位元 3：Ep0 的 kW0 中介存取權。
  • 位元 4：Ep1 的 uR1 對應。
  • 位元 5：Ep1 的 uW1 對應。在某些系統上可能表示 uR1。
  • 位元 6：Ep1 的 kR1 媒介存取權。
  • 第 7 位元：Ep1 的 kW1 仲介存取權。
  • [8..31]：保留供日後使用。

• size 是以位元組為單位的區域要求大小。系統會將大小向上取整至系統頁面大小邊界。使用 zx_object_get_info 和主題 ZX_INFO_IOB_REGIONS 判斷區域的實際大小。

• discipline 會指定要用於核心仲介作業的記憶體存取規範。

區域類型 0：私人

指定由 IOB 專屬的私有記憶體物件支援的區域。這個記憶體物件只能透過擁有 IOB 的作業和對應項存取。

struct zx_iob_region_private_t {
  uint64_t options;
};

• options 保留供日後使用。

區域類型 1 以上：保留供日後使用

未來的擴充功能可能包括共用區域類型，其中多個 IOB 會共用相同的記憶體物件，以支援有效率的多代理程式協調。

對應

IOB 的記憶體區域是透過呼叫 zx_vmar_map_iob 對應。這個呼叫與 zx_vmar_map 的語意相似。

zx_status_t zx_vmar_map_iob(zx_handle_t vmar,
                            zx_vm_option_t options,
                            size_t vmar_offset,
                            zx_handle_t ep,
                            uint32_t region_index,
                            uint64_t region_offset,
                            size_t region_len,
                            zx_vaddr_t* addr_out);

參數

• vmar 是 VMAR 的控制代碼，可將區域對應至 VMAR。
• options 等同於 zx_vmar_map 的 options 參數。系統僅支援下列選項。
• vmar_offset 等同於 zx_vmar_map 的 vmar_offset 參數。
• ep 是包含要對應區域的端點。
• region_index 是要對應的記憶體區域索引。
• region_offset 等於 zx_vmar_map 的 vmo_offset 參數。
• region_len 等於 zx_vmar_map 的 len 參數。
• addr_out 是傳回對應虛擬位址的輸出參數。

支援的選項：

• ZX_VM_SPECIFIC
• ZX_VM_SPECIFIC_OVERWRITE
• ZX_VM_OFFSET_IS_UPPER_LIMIT
• ZX_VM_PERM_READ
• ZX_VM_PERM_WRITE
• ZX_VM_MAP_RANGE

其他選項保留供日後使用，並在指定時傳回 ZX_ERR_INVALID_ARGS。

對應私有區域在功能上與對應不可調整大小的 VMO 相同。如果對應超出記憶體物件結尾，且未設定 ZX_VM_ALLOW_FAULTS，則會傳回 ZX_ERR_BUFFER_TOO_SMALL。

region_offset 和 region_len 參數是地圖 API 的最佳做法，這項最佳做法的動機包括：

• 支援會攔截對應呼叫的清除器。使用明確範圍可簡化主動對應區域的追蹤作業。
• 支援沙箱，可明確管理位址空間放置位置和區域覆寫。
• 一般來說，使用 ZX_VM_SPECIFIC_OVERWRITE 時應避免發生意外衝突。

VMAR 作業

對應的區域通常支援 VMAR 作業，例如 zx_vmar_protect、zx_vmar_op_range、zx_vmar_destroy。區域的存取規範「可能」會修改或限制這些作業，詳情請參閱規範規格。

物件資訊查詢

IOB 支援依 zx_object_get_info 查詢物件屬性和記憶體區域。傳回的詳細資料包括支援每個區域的記憶體物件主要屬性，可用於驗證和安全防護。

主題 ZX_INFO_IOB

傳回整體 IOB 執行個體的相關資訊。

struct zx_iob_info_t {
  uint64_t options;
  uint32_t region_count;
  uint8_t padding1[4];
};

成員

• options 是傳遞至 zx_iob_create 的 options 參數值。
• region_count 是 IOB 中的區域數量。

主題 ZX_INFO_IOB_REGIONS

以 zx_iob_region_info_t region description 元素陣列的形式，傳回 IOB 各區域的相關資訊。

struct zx_iob_region_info_t {
  zx_iob_region_t region;
  zx_koid_t koid;
};

• region 是區域說明，可能已交換存取位元。
• koid 是基礎記憶體物件的 koid。

存取修飾符位元會交換，因此 Ep0 存取位元會反映進行查詢的端點存取權，而 Ep1 位元則會反映其他端點的存取權，這樣一來，您就能判斷本機和遠端控制代碼的存取權，而不必知道建立時哪些控制代碼是 Ep0 和 Ep1。

主題 ZX_INFO_PROCESS_VMOS

為確保與現有記憶體歸因機制的連續性，本主題會將支援 IOB 區域的記憶體物件視為一般 VMO，包括控點和對應項目的可存取性。

如果是私有區域類型，支援記憶體物件會指派不同的 KOID，且預設會與擁有 IOB 共用相同名稱。存取控管機制「可能」會覆寫或修改私人區域的預設名稱。

中介存取權

IOB 支援可設定的核心介導式記憶體區域存取權。相較於直接存取，透過中介存取可使用核心做為可信的中介層，提供更嚴格的資料完整性和其他不變量。核心保證會遵循存取規範為記憶體區域指定的存取規則。

中介讀取、寫入等作業

中介作業是由 IOB 讀取、寫入和輔助系統呼叫執行，這些作業會在日後的擴充功能中指定。存取領域可以定義新的 IOB 系統呼叫，或覆寫先前定義的呼叫，但使用方式必須在語意上保持一致。一般目標是定義幾個可重複使用的系統呼叫，以因應多種用途。

權限

IOB 預設擁有下列權利：

• ZX_RIGHTS_BASIC = (ZX_RIGHT_TRANSFER | ZX_RIGHT_DUPLICATE | ZX_RIGHT_WAIT | ZX_RIGHT_INSPECT)
• ZX_RIGHTS_IO = (ZX_RIGHT_READ | ZX_RIGHT_WRITE)
• ZX_RIGHTS_PROPERTY
• ZX_RIGHTS_MAP
• ZX_RIGHTS_SIGNAL
• ZX_RIGHTS_SIGNAL_PEER

屬性

IOB 支援 ZX_PROP_NAME，可提供診斷和歸因資訊。

IOB 可能支援區域存取領域定義的其他屬性。

訊號

IOB 支援同業和使用者信號，可提醒使用者注意重要情況。日後的擴充功能可能會定義可設定的信號。

ZX_IOB_PEER_CLOSED

當其他端點的最後一個參照釋出時，端點上會引發 ZX_IOB_PEER_CLOSED。端點的控制代碼和從端點建立的對應，都算作此用途的參照。

ZX_USER_SIGNAL_*

使用者可以舉起 ZX_USER_SIGNAL_*，表示有重要情況。

核心仲裁存取規範

為利於中介作業，核心必須知道如何正確存取記憶體區域。區域記憶體存取規則和設定稱為存取規範，可能包括：

• 記帳位置和格式。
• 覆寫/失敗政策。
• 浮水印和逾時設定。
• 記憶體順序和柵欄需求。

違規記錄說明

存取領域是使用可擴充的說明結構指定，並以 32 位元標頭指定說明的類型和格式。

#define ZX_IOB_DISCIPLINE_TYPE_NONE (0)

struct zx_iob_discipline_t {
  uint32_t type;
  union {
    uint8_t max_extension[4 * 15];
  };
};

未來 RFC 中可能定義的學科包括：

• 生產者 / 消費者環形緩衝區
• ID / Blob 對應表
• 鍵 / 值儲存空間
• 分散 / 收集記憶體副本
• 目錄項目快取

實作

初步實作是支援追蹤和記錄客戶的基礎步驟。以下說明的個案研究，將說明定義 IOB 功能的動機，以及為滿足用途需求而可能進行的擴充。

系統事件追蹤

IOB 的目的是支援下列項目，為更安全有效率的系統事件追蹤奠定基礎：

• 將工作階段協調、中繼資料和事件收集作業完全移至 IOB 區域，即可減少執行階段的額外負擔，並在初始設定後，免除調度執行緒和管道 IPC 的需求。
• 啟用 FDIO 和 FIDL 等低階設施的檢測，方法是排除 IOB 核心 API 以外的依附元件。
• 透過允許核心安全回收追蹤事件緩衝區，提升強健性，避免與 RFC 0181：無鎖可捨棄 VMO 搭配使用時發生嚴重 OOM 狀況。

系統追蹤記錄 IOB 可能會使用下列設定：

• 角色：
  • Ep0：Trace Manager
  • 第 1 集：Trace Provider
• 區域 0：追蹤類別位元向量
  • 類型：私人
  • 存取：
  • Ep0：uR0、uW0 (R/W)
  • Ep1: uR1 (RO)
  • 違規記錄：無
  • 用途：代表已啟用追蹤類別的 uint64_t 位元向量陣列。
• 區域 1：追蹤類別
  • 類型：私人
  • 存取：
  • Ep0：uR0、uW0 (R/W)
  • 第 1 集：kW1 (僅限中介新增項目)
  • 學科：未來的 ID/Blob 分配器學科。
  • 用途：代表追蹤供應商所用每個追蹤類別的類別位元的連續 ID/字串對應。
• 第 2 區：內部化字串
  • 類型：私人
  • 存取：
  • Ep0：uR0、uW0 (R/W)
  • 第 1 集：kW1 (僅限中介新增項目)
  • 學科：未來的 ID/Blob 分配器學科。
  • 用途：代表追蹤事件名稱和其他常用名稱的內部化字串，是依序排列的 ID/字串對應。
• 區域 3：低速率 / 靜態中繼資料
  • 類型：私人
  • 存取：
  • Ep0：uR0、uW0 (R/W)
  • Ep1：uR1、uW1 (R/W)
  • 規範：未來的多重生產者/單一消費者環狀緩衝區規範。
  • 用途：適用於低速率 / 靜態追蹤事件的無鎖環形緩衝區，例如執行緒名稱。通常需要這些事件，才能正確解讀高速率緩衝區中的其他追蹤事件。
• 區域 4：高速率追蹤記錄事件
  • 類型：私人
  • 存取：
  • Ep0：uR0、uW0 (R/W)
  • Ep1：uR1、uW1 (R/W)
  • 規範：未來的多重生產者/單一消費者環狀緩衝區規範。
  • 用途：無鎖環形緩衝區，適用於高率追蹤事件。在循環緩衝區模式下，可容許資料遺失。

系統記錄

IOB 的目的是支援下列項目，為更安全有效率的系統記錄奠定基礎：

• 隔離不同元件和/或嚴重程度的記錄，避免跨元件和跨嚴重程度的記錄檔輪替。
• 避免處理未主動觀察的記錄。
• 不再使用分派執行緒處理嚴重程度變更。
• 以元件為單位管理及追蹤資源 (記憶體)。

涉及的執行者如下：

1. 記錄產生器：發出記錄的元件。
2. 記錄管理員 (歸檔者)：將所有生產端的記錄檔路徑傳送至所有取用端。
3. 記錄檔消費者：連線至記錄檔管理員，並讀取合併的記錄檔串流。

系統記錄 IOB 可能會使用下列設定：

• 角色：
  • Ep0：記錄管理員 (Archivist)
  • 第 1 集：記錄產生器 (某些元件)
• 區域 0：控制項
  • 類型：私人
  • 存取：
  • Ep0：uR0、uW0 (R/W)
  • Ep1: uR1 (RO)
  • 違規記錄：無
  • 用途：儲存執行階段設定，例如最低嚴重性。視記憶體管理需求而定，也可能儲存記錄循環緩衝區的大小上限相關資訊。
• 區域 1：字串表
  • 類型：私人
  • 存取：
  • Ep0：uR0 (RO)
  • Ep1：kW1 (WO)
  • 學科：未來的 ID/Blob 分配器學科。
  • 用途：代表常用記錄字串、標記、鍵、中繼資料的內部化字串，是依序排列的 ID/字串對應。
• 區域 2：記錄循環緩衝區
  • 類型：私人
  • 存取：
  • Ep0：uR0、uW0 (R/W) (為 R/W/C 指標寫入，並寫入傳輸中計數器)
  • Ep1：kW1 (WO)
  • 規範：未來的多重生產者/單一消費者環狀緩衝區規範。
  • 用途：用於記錄檔記錄的無鎖環形緩衝區。在循環緩衝區模式下，可容許資料遺失。我們計畫先從生產者開始，進行核心仲介寫入，然後從管理員直接讀取。如果效能有需要，製作人可能會改為直接存取。

導入步驟

導入程序會依序執行下列開發步驟：

1. 在 @next 屬性下導入 IOB 介面：
   • 實作基本 IOB 調度器。
   • 實作系統呼叫和常見驗證。
2. 在分支中，以 IOB 為基礎設計追蹤和記錄的原型，以及必要的 IOB 擴充功能。
3. 為必要擴充功能撰寫並批准 RFC。
4. 實作擴充功能並移除 @next 屬性。
5. 根據 IOB 重新設定追蹤和記錄功能，將現有用戶端軟轉換至新介面。

效能

如要驗證效能是否有所提升，請先比較類似作業的端對端延遲時間和負擔，再淘汰及移除目前的追蹤/記錄實作項目。持續進行的基準測試可能包括緩衝區記憶體來源 (VM 負荷)、主要作業的延遲/並行測試，以及分配測試，以驗證穩定狀態的記憶體消耗屬性。

人體工學

相較於需要結合 VMO、事件和 IPC 物件才能模擬類似功能，IOB 的設計更容易理解。相較於多個物件的組合，IOB 端點的生命週期也更容易一致管理，且相較於 VMO，記憶體存取規則也更容易強制執行。

回溯相容性

IOB 只會為語言導入新的控制代碼型別，影響 FIDL 檔案來源相容性和 ABI 線路格式相容性，不會影響回溯相容性。

安全性考量

共用記憶體用途一律存在潛在的安全漏洞。大多數 IOB 用途不會產生共用 VMO 未受影響的新危害。不過，由於權限和記憶體存取生命週期的規則更加嚴格，IOB 可降低特定錯誤的風險。

將刪節和檢查時間複製到使用時間危害

在共用記憶體用途中，有一種重要的軟體錯誤類別，稱為「檢查時間到使用時間的危害」(TOCTOU)。TOCTOU 危害是由於檢查某個狀態與使用檢查結果之間的競爭狀況所造成，因此狀態可能會在檢查與使用結果之間失效。

在開放式共用記憶體用途中，避免 TOCTOU 危害可能很困難，通常需要將資料從共用記憶體區域複製出來，以免在驗證期間或之後遭到修改。即使採用複製作業，也必須小心防止複製省略，因為除非使用特定介入措施，否則編譯器可能會將副本最佳化，並直接在共用記憶體區域運作。

核心仲介作業可確保核心遵循中繼資料更新、酬載轉移和存取記憶體順序的規則，進而簡化 TOCTOU 危害的緩解程序。舉例來說，使用環狀緩衝區機制時，核心保證不會覆寫記錄的內容，直到消費者更新環狀緩衝區記帳，確認可以安全地執行這項操作為止，因此不需要在驗證前複製酬載。

儘管如此，使用者仍有責任正確套用記憶體順序和原子性，或語言專屬的對等項目，以防因最佳化而導致正確性風險。為減輕使用者負擔，Fuchsia SDK 將納入支援語言的程式庫，針對每個定義的領域實作正確的存取常式。學科規格也會提供足夠的詳細資料，確保安全且正確地套用存取規則。

隱私權注意事項

IOB 不會帶來新的隱私權考量，IPC 和共用記憶體用途已適用相關考量。系統事件追蹤和記錄的初始用途仍須遵守相同的隱私權義務。

測試

測試包括：

• IOB 的核心測試。
• 針對新類型的控制代碼類型驗證進行 FIDL 一致性測試。
• 擴充 Fuchsia 追蹤系統測試，納入 IOB 專屬功能。
• 擴大系統記錄測試範圍，納入 IOB 專屬功能。

不依附於基礎實作詳細資料的現有追蹤和記錄測試，應可繼續運作並通過測試。

說明文件

說明文件更新包括：

• 系統呼叫參照。
• 核心概念。
• FIDL 控制代碼類型。

缺點、替代方案和未知事項

這項提案的實作成本相對較低，因為這項功能是以現有的虛擬記憶體和對等調度器機制為基礎建構而成。這項獨特功能以非對稱存取權、核心媒介區域存取權，以及關閉時取消對應功能為中心。

既有技術和參考資料

• Fuchsia 追蹤系統
• Fuchsia 追蹤格式
• RFC 0181：無鎖可捨棄的 VMO
• 實作無鎖定的 R/W 環狀緩衝區