X Window 系統的標誌X Window源於1984年的麻省理工學院（目前所發布的X11發表於1987年9月）。設計者鮑伯·斯凱夫勒（BobScheifler）和吉姆·傑提斯（JimGettys）早期對核心協定的原則是“建立機制，而不是方針”，所以核心協定並未規定客戶端之間以及客戶端和使用者之間的互動規範。這部分則由其他的獨立規格所規範，如ICCCM、freedesktop.org規範，且可由所使用的特定組件工具包自動強制執行。
概觀
伺服器和客戶端之間的通訊，是由通道上的交換封包所完成。由客戶端建立連線，且由客戶端傳送第一個封包。封包中包括將要使用的位元順序、協定版本方面的資訊，以及客戶端期望伺服器使用的認證種類。伺服器以回傳封包來答覆，封包中陳述接受或拒絕連線，或要求進一步的驗證。如果接受連線，接受封包內會包含客戶端接下來和伺服器互動所需的資料。
客戶端和伺服器之間的互動範例。建立連線之後，在客戶端和伺服器的通道上，會有四種交換封包的類型：
客戶端和伺服器之間的互動範例2 回應：伺服器回應請求。但並非所有的請求都會產生回應。
3 事件：伺服器傳送事件給客戶端。如：鍵盤或滑鼠的輸入，或移動、調整、顯示視窗等。
4錯誤：如果請求無效時，伺服器會傳送一個錯誤封包。因為請求是以排隊方式處理，所以經由請求所產生的錯誤封包，並不會立即傳送出去。
請求和回應封包可以有各種長度，事件和錯誤封包的長度則固定是32位元組。
請求封包的編號順序是以伺服器的接收為順序：來自客戶端的第一個請求編號為1、第二個編號為2，依此類推。請求的序列編號中最小的有效16位元，包含在由請求所產生的回應和錯誤封包之中，如果有的話。它們也包含在事件封包中，以指出伺服器正在處理或是剛剛完成的請求序列編號。
視窗
在XWindow系統以及各種圖形化使用者界面中，視窗即為一個頂層視窗。視窗也用來指視窗內部的視窗，這類視窗是父視窗的子視窗。圖形化元件，如按鈕、選單、圖示等等，都是使用視窗來實現的。
視窗視窗里的內容並非在所有時候都能顯示出來。更精確的說，在視窗移動、調整大小、被其他視窗遮蓋、部分或整個視窗不可見時，視窗里的內容就有可能會被銷毀。更精確的說，如果X伺服器無法維護視窗內容的後備存放區（backingstore）時，這些內容就會遺失。客戶端可請求為視窗進行維護的後備存放區，但伺服器沒有義務要這樣做。因此，客戶端不可假設已得到後備存放區的維護。若視窗有一部分未指出內容時，就會傳送一個事件，通知客戶端重繪那部分內容。
每個視窗都關聯一組屬性值（Attribute），如視窗的幾何性質（大小和位置）、背景圖、是否請求了後備存放區等等。協定中還包含用來給客戶端檢閱和改變視窗屬性值的請求。
視窗可以是InputOutput（輸出入）或InputOnly（僅輸入）。前者是顯示在螢幕上用於繪圖的視窗，而後者並不顯示在螢幕上，僅用來接受輸入。
fvwm視窗的結構關於視窗的資料，可執行xwininfo程式來取得。加上-tree命令列參數，程式便會顯示子視窗的樹狀結構，連同識別子和幾何性質資料一起顯示。
圖形映射和可繪區圖形映射（pixmap）是記憶體中可用來繪圖的區域。與視窗不同，圖形映射的內容並不會自動顯示在螢幕上。不過圖形映射的內容（或部分內容）可轉換到視窗上，反之亦然。這就讓雙緩衝得以實作。大部分可在視窗上完成的圖形化操作，也可以圖形映射完成。
視窗和圖形映射被統稱為可繪區（drawable），且其資料內容都保留在伺服器上。客戶端可請求從伺服器上，將可繪區的內容轉換到客戶端，反之亦然。
圖形脈絡和字型客戶端可請求很多種圖形運算，如清空一塊區域、複製一塊區域到另一處，繪製一個點、線、矩形和文字。對清空而言，所有運算都有可能用在可繪區上（視窗和圖形映射）。
圖形脈絡（graphiccontext）包括了對圖形運算的大部分請求，圖形脈絡是一種結構，包含有圖形運算的參數。圖形脈絡包含前景色、背景色、文字的字型，以及各種圖形參數。當請求圖形運算時，客戶端就包含一個圖形脈絡。很明顯的，並非所有的圖形脈絡參數都會參與運算：例如，字型對於直線的繪製不產生作用。
核心協定規格使用了伺服器側的字型。如字型是以檔案形式存放，伺服器經由本機的檔案系統直接存取，或經由網路從字型伺服器存取。客戶端可向伺服器請求有效的字型列表，且可請求伺服器載入（沒有的話）或卸載（客戶端不再需要的話）字型。客戶端可請求關於字型的資訊（例如，ascent字型），並以指定的字型來繪製指定的字串。
xfontsel程式可讓使用者檢視字型的標記。
xfontsel 程式可讓使用者檢視字型的標記xlsfonts程式可輸出存放在伺服器上的字型列表。xfontsel程式可顯示字型的標記，並讓使用者選取字型的名稱，以在其他視窗中貼上。
目前已不再重視伺服器側字型的使用，而轉向客戶端側字型的使用。例如，藉由支援Xft或cairo程式庫，以及XRender擴充，改由客戶端（而非伺服器）繪製字型。客戶端側字型在核心協定中尚未給出規範。
資源和識別子
所有關於視窗的資料、圖形映射、字型等等，皆存放在伺服器上。客戶端知道那些物件的識別子，和伺服器互動時，物件以整數為名稱。例如，當客戶端希望建立一個視窗時，便指定一個識別子，並請求伺服器建立一個視窗。伺服器會建立一個視窗，並與指定的識別子關聯。稍後客戶端可使用這個識別子進行請求，例如在視窗上畫上一個字串。以下存在於伺服器上的物件，客戶端可藉由數值型的識別子得知：
視窗（Window）
圖形映射（Pixmap）
字型（Font）
色彩映射（Colormap）（即顏色表，稍後描述）
圖形脈絡（Graphiccontext）
這些物件就稱作資源。當客戶端請求建立某一種資源時，同時也為資源指定了一個識別子。例如，為了建立一個新視窗，客戶端指定了視窗的屬性值（親屬關係、寬、高等等）和識別子，最後識別子會和視窗關聯。
識別子是三個最高有效位為0的32位元整數。每一個客戶端都有一組自己的識別子，其可用來建立新的資源。這組識別子是由伺服器以包含在接受封包（傳送給客戶端的封包，通知已接受連線）中的兩個整數所指定的。客戶端以避免衝突的方式選取識別子：在視窗、圖形映射、字型、色彩映射、圖形脈絡之中的兩個物件，不可具有相同的識別子。
資源一經建立，其識別子就用於客戶端向伺服器請求與之有關的運算。部分運算會影響特定的資源（例如，請求移動視窗），其他的則要求存放在伺服器上的資源資料（例如，請求視窗的屬性值）。
識別子在伺服器上是獨一無二的，在多個客戶端之間也不例外。例如，即使是由兩個不同客戶端所建立的視窗，也不會同時具有相同的識別子。即使某個物件不是由自己的客戶端所建立的，只要指定相對應的識別子，就可存取另一個客戶端所建立的任何物件。
連線到同一伺服器的兩個客戶端，對同一資源可使用同一識別子。例如，若客戶端建立一個0x1e00021識別子的視窗，並傳送數值0x1e00021給其他的套用程式（透過任何有效的手法。例如，把數值存放在檔案里，且這個檔案可讓其他的套用程式輕易存取），其他的套用程式即可對同一視窗進行操作。這個例子是來自XWindow版本的Ghostview：程式建立一個子視窗，在環境變數中存放其識別子，並呼叫Ghostscript；程式繪製PostScript檔案的內容，以顯示在這個視窗上。
當建立資源的客戶端關閉與伺服器的連線時，資源就會正常的銷毀。不過在關閉連線之前，客戶端可以請求伺服器不要銷毀資源。
事件
事件是由伺服器傳送到客戶端用以通訊的封包，傳送一些客戶端可能感興趣的事情。例如，當使用者按下按鍵或點擊滑鼠時，便會傳送一個事件。事件不只用於輸入：例如，傳送的事件表明特定視窗建立了新的子視窗。
每一個事件都會涉及到視窗。例如，當使用者的指標在視窗之內並點擊時，這個事件就會涉及到那個視窗。事件封包中含有那個視窗的識別子。
客戶端可以請求伺服器傳送事件給另一個客戶端，這可用於客戶端之間的通訊。例如，當客戶端請求目前所選取的文字時，就會傳送事件給客戶端，以處理目前所持有的選取內容。
當再度觀看內容已被銷毀的區域時，有可能會傳送Expose（顯露）事件。而且在某些情況下，視窗的內容可能會被銷毀。例如，當視窗被其他視窗遮蓋住，且伺服器沒有維護後備存放區時。此時伺服器會產生一個Expose事件，以通知客戶端重繪視窗已消失的部分。
事件的範例客戶端可以設定視窗的屬性值（attribute），以指明想要接收哪些事件。例如，當視窗的內容已銷毀時，為重繪其內容，客戶端就必須接收Expose事件，以通知視窗需要再次重繪。客戶端要能接收到Expose事件，就要預先指明它所關心的事件，這部分可以適當設定視窗屬性值的事件掩碼來完成。
不同的客戶端可以請求同一視窗的事件。甚至可對同一視窗設定不同的事件掩碼。例如，某個客戶端可以只對視窗請求鍵盤事件，而另一個客戶端只對視窗請求滑鼠事件。這是可以的，因為伺服器會為每一個客戶端維護事件掩碼，而且是每一個視窗都維護一份獨立的事件掩碼。不過偶爾也有某幾類事件，只能由一個客戶端選擇。特別是，這類事件回報滑鼠按鈕的點擊，且部分變化會涉及到視窗管理器。
xev程式顯示視窗所涉及到的事件。xev-idWID可對識別子為WID的視窗要求所有可能的事件，並將其輸出。
顏色
在協定層次里，顏色使用32位元無負號整數來表示，稱為像素值。以下因素會影響顏色的顯示：
1.色彩深度
2.色彩映射（colormap），即含有紅、綠、藍強度值的表。
3.視覺類型（visualtype），指明表如何用來表示顏色。
在最簡單的情況下，色彩映射是一種每一項都含有RGB三值的表。像素值x所表示的顏色，就包含在表中第x項。如果客戶端可以改變色彩映射的內容，那這種表示法就以偽彩色（PseudoColor）視覺分類（visualclass）來標識。視覺分類中的靜態色（StaticColor）與偽彩色類似，只不過客戶端不能修改色彩映射的內容。
在此總計有六種可能的視覺分類，每一種都使用不同的方式來表示RGB像素值。PseudoColor和StaticColor即其中兩種。GrayScale和StaticGray是另外的兩種，其中最主要的差異是灰階漸層的使用。
剩下的兩種視覺分類和前述的差異在於，將像素值分成三個部分，並為紅、綠、藍的強度使用了三個獨立的表。並根據這個表來表示顏色，如下流程將像素值轉換成RGB色：
1.將像素值視為連續的位元序列
2.將位元序列分成三個部分
3.將每一個部分視為整數、並作為索引，以在這三個獨立的表中尋找到值。
這個機制需要以三個獨立的表組成色彩映射，三個原色各一個表。轉換以後仍是強度值的三聯色。使用這個表示法的視覺分類有DirectColor和TrueColor，其中的差異是客戶端不能修改後者的色彩映射。
以上六種以像素值表示顏色的機制，都需要附加一些參數來運作。這些參數可統合為視覺類型，其包含一個視覺分類和其他參數以表示顏色。每一個伺服器都有一組固定的視覺類型，每一個類型都與數值型的識別子關聯。其識別子是32位元無負號整數，和資源或元素的識別子沒有什麼不同。
當接受來自客戶端的連線時，伺服器所傳送的接受封包里含有區塊序列，每一個區塊都包含有關於某一個單一螢幕的資訊。就每一個螢幕而言，相關區塊包含著其他區塊的清單，每一個都涉及了螢幕所支援的色彩深度。就每一個螢幕所支緩的色度深度而言，這個清單中又包含視覺類型的清單。結果，每一個螢幕就關聯著各種合適的色彩深度，而且每一個螢幕的每一個色彩深度都關聯著各種合適的視覺類型。一個給定的視覺類型可用於更多的螢幕和各種不同的色彩深度。
就每一個視覺類型而言，接受封包中還包含它的識別子和它所包含的實際參數（視覺分類等），客戶端存放這些資訊，因為之後就不能再請求。此外，客戶端不能改變或建立新的視覺類型。建立新視窗的請求中，還包含有色彩深度和視覺類型的識別子，以此用來表示視窗的顏色。
色彩映射和控制螢幕的硬體（即繪圖卡）是否使用調色盤（palette）沒有關係。調色盤是一個表，也是用來表示顏色的。即使硬體並不使用調色盤，伺服器也能使用色彩映射。當硬體使用調色盤時，就只能安裝相當受限的少許色彩映射。更精確的說，當硬體根據色彩映射來顯示顏色時，就可以說是安裝了色彩映射。客戶端可請求伺服器安裝一個色彩映射。不過需要將另一個色彩映射解除安裝：其影響是視窗如果使用了解除安裝的色彩映射，就不能顯示正確的顏色，而出現怪異顏色的畫面。這個問題可以用標準色彩映射來解決，標準色彩映射是像素值和顏色之間關聯恆定的色彩映射。由於有這一性質，就可讓不同的套用程式使用標準色彩映射。
色彩映射的建立由ICCCM協定管理。標準色彩映射由ICCCM和Xlib規格管理。
元素
元素（Atoms）是用來表示字串的32位元整數。本協定的設計者之所以引入元素，是為了以簡短、大小恆定的方式表示字串：由於字串可以是任意的長度，而元素總是32位元整數。某些封包可能會多次傳送相同的字串，元素的簡短性可以削減指令所使用的封包長度，進而增進網路的使用效率。大小恆定的元素有利於大小恆為32位元組的事件：大小恆定的封包可以包含元素，卻不能包含過長的字串。
更嚴謹的說，元素是存放在伺服器上的字串的識別子，相當於資源的識別子（視窗、圖形映射等），但仍有兩個不同點。首先，元素的識別子是由伺服器選擇的，而非客戶端。換句話說，當客戶端請求建立一個新的元素時，其僅僅傳送字串給伺服器存放，而非字串的識別子；元素的識別子是由伺服器選擇，並回傳給客戶端作為回應。其次，資源和元素之間的重大差異是，元素並未與客戶端相連繫。元素一經建立，就能一直存留至伺服器結束或重置（此非資源的默認行為）。
元素是識別子，所以也是獨一無二的。不過元素和資源的識別子可以相一致。與元素關聯的字串稱作元素名。元素的名稱一經建立就不能再更改，而且不能有兩個相同名稱的元素。故一般以元素的內容作為元素的名稱：“元素ABCD”意謂著，或更精確的說，“這個元素關聯的字串是ABCD”或“元素的名稱是ABCD”。客戶端可以請求建立新的元素，且可請求指定字串的元素（識別子）。某些元素已預先定義（由伺服器以特定的識別子和字串所建立）。
元素運用於多個目的，主要與連線到同一伺服器的不同客戶端之間有關。特別是，元素用於與視窗屬性的關聯，以下詳述。
所有存在於伺服器上的元素列表，可使用xlsatoms程式輸出。尤其這個程式可以元素的名稱（元素所關聯的字串）列出每一個元素（識別子是一串數字）。
屬性
每一個視窗都有一組預先定義的屬性值（Attribute）和屬性（Property），並存放在伺服器上，客戶端可以適當的請求方式取存。屬性值是有關視窗方面的資料，如視窗的大小、位置、背景色等等。屬性則是附屬於視窗上的資料片斷。與屬性值相反，屬性在XWindow核心協定的層次中並沒有其他含意。客戶端可在視窗的屬性中存放屬性值資料。
屬性是以名稱、類型和值來描述，屬性相當於指令式程式語言的變數，套用程式可以指定名稱、類型和值來建立新的屬性。屬性和視窗關聯：兩個相同名稱的屬性可存在於兩個不同的視窗，且可具有不同的類型和值。
屬性的名稱、類型和值皆為字串；更精確的說就是元素，客戶端可藉由識別字，以存取存放在伺服器上的字串。客戶端套用程式可以元素的識別子（含有屬性的名稱）存取特定的屬性。
屬性大多用於客戶端之間的通訊。例如，名稱為WM_NAME（屬性名稱就是元素所關聯的字串"WM_NAME"）的屬性，是用來存放視窗的名稱；視窗管理器通常會讀取這個屬性，並在視窗頂部顯示名稱。
某些客戶端之間的通訊也使用了根視窗的屬性。例如，根據freedesktop視窗管理器規格視窗管理器應該在根視窗的_NET_ACTIVE_WINDOW屬性名，存放目前有效（active）視窗的識別子。X資源所含有的程式參數，同樣也是存放在根視窗的屬性里；藉由這個方式，即使分別執行在不同電腦上，所有客戶端仍可存取到那些參數。
xprop程式可輸出指定視窗的屬性，xprop-root則可輸出根視窗每一個屬性的名稱、類型和值。
映射
X Window核心協定當按下或放開按鍵時，伺服器會傳送KeyPress或KeyRelease的事件類型給適當的客戶端。這些事件包含：
按下按鍵所產生的鍵碼。
修飾鍵（Shift、Control等）和滑鼠按鍵當下的狀態。
鍵碼如何轉換成鍵符客戶端完成鍵碼至鍵符的轉換以後，表示其關聯的表就由伺服器來維護，並將表集中存放在所有客戶端都存取得到的地方。客戶端只需請求映射，並使用它對鍵碼和其修飾鍵域解碼成鍵符。客戶端也可以任意改變此一映射。
當按下修飾鍵時，就會改變另一個按鍵的解碼。常見的修飾鍵有Shift鍵：平常會產生小寫字母“a”的a鍵和Shift鍵一起按下時，就會產生一個大寫字母“A”。其他常見的修飾鍵還有“Control”、“Alt”和“Meta”。
X伺服器最多可用八個修飾鍵，不過每個修飾鍵可關聯一個以上的按鍵。例如，很多鍵盤有兩個“Shift”鍵（一左一右）。按下這兩顆按鍵時，會產生兩個不同的鍵碼，不過X伺服器會把那兩者都關聯到“Shift”修飾鍵。
X伺服器為八個修飾鍵維護一份可以認出修飾鍵的鍵碼清單。舉個例子，如果清單中的第一個修飾鍵（“Shift”修飾鍵）包含鍵碼0x37，然後有某個按鍵會產生鍵碼0x37，X伺服器就認為那個按鍵是Shift鍵。
修飾鍵映射的清單由X伺服器維護，也可以讓所有的客戶端修改。例如，客戶端可以請求將“F1鍵”加到“Shift”修飾鍵的清單中。從此，這顆按鍵的效果就如同Shift鍵一樣，不過F1仍會產生本身的鍵碼。結果，F1仍做它以前所做的（例如，按下F1時，會開啟說明視窗），不過又和Shift一樣（在文字編輯器里，按下“a”和F1，就會打出“A”）。
X伺服器也為滑鼠按鍵維護並使用修飾鍵映射，不過只能改變順序。其最大的用處就是為左撇子調換左右兩邊的按鍵。
xmodmap程式可以顯示並改變按鍵、修飾鍵和滑鼠按鍵的映射。
截取
截取（grab）即所有鍵盤或滑鼠的事件，都傳送到單一客戶端上。客戶端可以請求鍵盤、滑鼠或兩者的截取：如果伺服器履行此一請求，所有鍵盤和滑鼠的事件，都會傳送到截取中客戶端，直到解除截取為止。此時，其他的客戶端將接收不到這些事件。
請求截取時，客戶端會指定一個截取視窗：所有事件都會傳送到截取中客戶端，彷佛和截取視窗相關。不過其他的客戶端接收不到事件，即使是在截取視窗中進行選取。在此有兩種截取：
X Window核心協定立即進行截取。
被動式
只在按下預先指定的按鍵（或滑鼠按鍵）時才會進行截取，並在放開時結束。
如果游標或鍵盤是被凍結的話，其所產生的事件將會在佇列上被攔截。如果是可截取的話，其事件會轉運給截取的客戶端，而不是原本可接收到事件的視窗。游標事件可藉由事件掩碼加以排除、拋棄。客戶端可截取鍵盤、游標或兩者。截取請求中也可包含用來凍結鍵盤或滑鼠的請求。截取和凍截的不同處在於，截取改變事件的接收者，而凍結只是完全停止遞送。當裝置凍結時，它所產生的事件會存放在佇列中，並在結束凍結時照常遞送。
對於游標事件來說，額外的參數會影響到事件的遞送：事件掩碼指定要遞送或拋棄哪些類型的事件。
截取請求中還包含一組欄位，欄位用來在還沒建立截取之前，就指明傳送給截取中客戶端的事件將要發生什麼。更精確的說，客戶端可請求它們照常傳送或進行截取。這兩種情況和它們所表現出來的有所不同。例如，在第一個視窗上正常接收鍵盤事件的客戶端，可能會透過第二個視窗來請求截取鍵盤。事件將會正常傳送給第一個視窗，而未必重新導向給截取視窗，這取決於截取請求里所下的參數。
客戶端也可請求截取整個伺服器。在這種情況下，伺服器將不會處理任何請求，除了來自截取中客戶端的請求以外。
其他
還有其他的請求和事件，有一種請求是有關視窗之間的親屬關係：客戶端可請求改變視窗的父視窗，或請求關於父視窗的資訊。其他的請求則是關於選取，這部分大多由其他的協定來管理。還有的請求是關於輸入焦點和游標的形狀。客戶端也可請求將資源（視窗、圖形映射等等）的所有者殺死，這會使伺服器終止和那個所有者的連線。最後，客戶端還可傳送空運算請求給伺服器。
擴充
shape extension可讓 oclock 程式建立圓形視窗更精確的說，客戶溯可以請求所有可用的擴充的清單，擴充的封包相當於核心協定的封包。核心協定指定請求、事件和錯誤封包要包含一個指明其類型的整數（例如，建立一個新視窗的請求是號碼1）。一部分範圍的整數已保留給擴充。
授權在客戶端和伺服器剛開始建立連線的時候，伺服器的回應可以是接受、拒絕或要求驗證。驗證請求包含要使用的驗證方法的名稱。核心協定並不規範驗證程式，這部分要看所使用的驗證類型，並在伺服器傳送接受或拒絕封包之後結束。
在客戶端和伺服器之間正常互動的時候，只有在涉及基於主機的存取方式的驗證才要請求。更精確的說，客戶端可要求啟用這個方式，並請求讀入和改變主機（客戶端）（經授權的連線）的清單。一般的套用程式不使用這類請求；xhost程式使用這類請求，給使用者或Shellscript存取主機存取清單。基於主機的存取方式被認為是不安全的。
Xlib和其他的客戶端程式庫
主條目：Xlib
大部分的客戶端程式藉由Xlib客戶端程式庫與伺服器交流。特別是客戶端大多使用Xaw、Motif、GTK+、Qt之類使用到Xlib的程式庫，方便和伺服器互動。Xlib有以下作用：
1.Xlib使客戶端的回應和事件同步化：
1.Xlib函式會傳送請求區塊，直到得到合理的回應。換句話說，不使用Xlib的XWindow客戶端可傳送請求 給伺服器，並在等待回復的期間，先做其他的事。不過使用Xlib的客戶端只能呼叫Xlib函式來傳送請求，並等待回復。藉此阻斷客戶端額外的動作（除非客戶端在呼叫Xlib函式之前，就執行另一個新執行緒）。
2.當伺服器傳送的事件不同步時，Xlib會把客戶端接收到的事件存放在佇列里，客戶端程式只能以明確呼叫X11程式庫函式的方式來存取。換句話說，如果在等待事件時，會讓客戶端強制阻斷或忙碌等待。
2.Xlib不會立即傳送請求給伺服器，而是先存放在佇列中，這部分稱為輸出緩衝；輸出緩衝里的請求會在以下情況真正傳送出去：
1.程式以程式庫所提供的函式，如XFlush，明確要求。
2.程式所呼叫的函式，涉及伺服器的回應，如XGetWindowAttributes。
3.程式要求在事件佇列中的一個事件（例如，呼叫XNextEvent）和呼叫區塊（例如，XNextEvent區塊，如果佇列是空的）。
高階程式庫，如Xt（Xaw和Motif所使用的），讓客戶端程式指定與事件關聯的返回函式。程式庫維護輪詢事件佇列，並在必要時呼叫適當的函式；某些事件是在Xt內部處理，如需要重繪的視窗。
低階程式庫，如XCB，提供協定不同步存取，容許較佳的延遲隱藏。
