Service Broker 通訊協定
Service Broker 使用 Broker 特定的通訊協定與遠端 Broker 進行通訊。Broker 對連接和用戶端連接的一般集區採取分開管理的方式。為了讓兩個 SQL Server 執行個體交換 Service Broker 訊息，每個執行個體都必須可以將 TCP/IP 流量傳送到其他執行個體用於 Service Broker 通訊的通訊埠。依慣例，Service Broker 通常使用通訊埠 4022 進行 Broker 對 Broker 之間的通訊。不過，確切的通訊埠會在建立端點時指定。
通訊協定層
Service Broker 採用分層的方法進行通訊。每一層都建立於基礎層之上，以協助確保可靠傳遞。此方法可讓應用程式在不瞭解遠端服務的位置或不瞭解 Broker 用於通訊的實體傳輸時運作。在大多數情況下，這些通訊協定對應用程式是透明的。然而，瞭解每個通訊協定層所扮演的角色可能有助於疑難排解應用程式的問題。
Broker 使用的最高層通訊協定是「對話通訊協定」。對話通訊協定層會處理可靠而循序的訊息傳輸。它會產生訊息的序號、產生收條訊息、將訊息傳遞至適當佇列，以及分段和重新組合訊息。對話通訊協定則處理對話的驗證和加密。
對話通訊協定使用「相鄰 Broker 通訊協定」來傳輸訊息片段。相鄰 Broker 通訊協定會處理在兩個 Broker 執行個體之間交換的網路傳輸。
相鄰 Broker 通訊協定使用「傳輸通訊協定」(如 TCP/IP) 在 Broker 與 Broker 之間移動訊息。
對話通訊協定
對話通訊協定管理交談上訊息的精確單次循序 (EOIO) 傳遞模式。此通訊協定不描述 Service Broker 訊息在網路上使用的格式，而是指定可靠交談所需的邏輯步驟。對話通訊協定會處理可靠傳遞所需的工作，包括產生和處理收條訊息。
交談的每一端都是對話通訊協定層中的端點。目錄檢視 sys.conversation_endpoints 會顯示有關對話通訊協定端點的資訊。交談的端點存在於交談的存留時間內。
相鄰 Broker 通訊協定
相鄰 Broker 通訊協定層處理兩個 SQL Server 執行個體之間的通訊機制。這一層會將每個訊息片段編碼成適於透過網路傳輸的標準格式。與對話通訊協定層不同，相鄰通訊協定層瞭解所使用的網路傳輸，並會適當地格式化訊息片段。實際上，相鄰 Broker 通訊協定層會在對話通訊協定層和傳輸通訊協定層之間提供抽象層。
每個 Service Broker 網路連接都是相鄰通訊協定層中的端點。動態管理檢視 sys.dm_broker_connections 會顯示有關 Service Broker 網路連接的資訊。在主動交換訊息時，Service Broker 會維護網路連接。如果短期內沒有透過網路傳送或接收訊息，Service Broker 便會關閉網路連接。
傳輸通訊協定
傳輸通訊協定層處理實際網路傳輸。這一層處於 Service Broker 之外。例如，傳送至執行於 SQL Server 其他執行個體中之 Broker 的訊息會使用 TCP/IP 作為傳輸通訊協定層。
Service Broker 端點會設定傳輸通訊協定的選項。依預設，SQL Server 不包含 Service Broker 端點。如需有關建立 Service Broker 端點的詳細資訊，請參閱＜如何：啟動 Service Broker 網路 (Transact-SQL)＞。
Service Broker 通訊
Service Broker 使用兩種不同類別的訊息。「循序訊息」是必須精確單次循序傳遞至應用程式的訊息。「非循序訊息」是可以立即處理的訊息，不論訊息到達的順序為何。
Service Broker 會對所有使用者定義的訊息類型、結束對話訊息和應用程式建立的錯誤訊息使用循序訊息。每個循序訊息都有序號。產生訊息的執行個體會建立訊息序號，並將序號指派給訊息。接收 Broker 使用訊息序號對其提供給應用程式的訊息進行排序。對於給定對話，應用程式總是先接收序號最低的訊息。Service Broker 還會使用訊息序號來偵測重複的訊息。當對話通訊協定層在同一對話上收到具有相同序號的兩個訊息時，對話通訊協定層會將這兩個訊息視為重複並會捨棄一個。
Service Broker 會對專用收條訊息和 Service Broker 建立的錯誤訊息使用非循序訊息。傳遞非循序訊息時，Service Broker 不採取任何特殊動作。但是請注意，Service Broker 會建立非循序訊息，以回應內送訊息。因此，如果遺失非循序訊息，則傳送者會重試原始訊息；然後，接收者會產生另一個非循序訊息。
訊息分段
Service Broker 會將外寄訊息分割成數個片段，並將內送訊息組合成原始訊息。對於較小的訊息，整個訊息會包含在一個片段中。對於較大的訊息，Service Broker 會建立許多片段。
將訊息分段有數個優點。在透過相對較慢且不可靠的網路 (如「廣域網路 (WAN)」) 進行通訊時，以較小的片段傳送較大的訊息可提升整體速度和可靠性。如果訊息的片段遺失，通訊協定僅會重新傳輸一個片段，而不是整則訊息。將較大的訊息分段還可以減少較小訊息到達目的地所需的時間量。Service Broker 可在較大訊息的片段之間傳送包含整個較小訊息的片段。這會略微減慢較大訊息的速度，以便減少較小訊息等待傳輸的時間量。
重新組合訊息時，部份訊息會儲存在目的地佇列中，或裝載目的地佇列之資料庫的傳輸佇列中 (如果目的地佇列無法使用的話)。應用程式無法接收部份訊息。部份訊息的 status 資料行設定為 2 (已停用)。此值也用於未按順序接收的訊息。
訊息收條
Service Broker 會確認接收的每則訊息。收條可確認一或數個訊息片段。如果可能，收條會包含在同一交談上傳回之訊息的標頭中。如果沒有其他準備要傳送的訊息，Service Broker 會傳回專用收條訊息。訊息收條完全由 Service Broker 處理；使用 Service Broker 的應用程式不接收這些訊息。
傳送者會保留接收者尚未確認的訊息片段。如果在系統定義的等待時間內未收到收條，傳送者會再次傳送訊息片段。如果等待時間內仍未收到收條，則 Service Broker 會以指數方式增加下次重試前的等待時間，最多可達最大等待時間。重試的初始等待時間為幾秒鐘。而最大等待時間約為一分鐘。請注意，等待時間可能會不精確，因為等待時間過期後的幾秒鐘內可能不會重試訊息片段，這要視網路流量和 SQL Server 執行個體中的其他活動而定。
如果收條遺失或延遲，接收者可能會接收重複的訊息。在此情況下，接收者會確認重複的訊息，但不會將重複的訊息傳遞至佇列。
Service Broker 使用訊息收條來提供可靠的訊息傳送，而無需分散式交易。接收者僅在將訊息或訊息片段加入至佇列之後才會傳送收條。傳送者會在傳輸佇列中保留訊息，直到該訊息的收條到達為止。雖然傳送者和接收者從不共用交易，但是通訊協定可保證傳送者不會從傳輸佇列移除訊息，直到接收者成功接收訊息為止。
訊息完整性檢查
Service Broker 用於傳輸訊息的格式包含訊息完整性檢查，以判斷給定訊息在傳輸期間是否已改變或損毀。
訊息完整性檢查是訊息內容的 MD5 簽章。SQL Server 會使用訊息的工作階段金鑰加密簽章，並將簽章包含在訊息標頭中。
訊息的目的地會解密訊息，然後將訊息中的簽章與根據接收之實際內容計算的新簽章相比較。如果簽章不符，則訊息已在傳輸期間遭損毀或竄改。訊息的完整性檢查失敗。SQL Server 會捨棄訊息且不會向傳送者確認訊息。Broker:Corrupted Message 事件類別會在訊息的完整性檢查失敗時報告資訊。
網路通訊流程
下圖呈現兩個 SQL Server 執行個體之間 Service Broker 網路通訊的高層級檢視。
.gif "兩個執行個體之間的 Broker 網路通訊")
請注意，交談是永續性的邏輯連接。交談可以在任何一段時間發生，且在這段時間內，交談可以使用任意個的網路連接。
網路連接會在兩個 Service Broker 端點之間進行。這些連接使用 TCP/IP。如果連接在短期內處於非使用中，SQL Server 會關閉網路連接。
為了傳遞訊息，Service Broker 會將訊息保留在傳送訊息之資料庫的傳輸佇列中。接收者會將訊息直接傳遞至目的地服務的佇列。如果該佇列為 OFF，則訊息會暫時保留在接收資料庫的傳輸佇列中。請注意，作業中並不涉及傳送服務的佇列，而裝載接收服務之資料庫的傳輸佇列僅會在目的地佇列為 OFF 時涉及。