服務品質 (RPC)

用戶端程式可以使用 RpcBindingSetAuthInfoEx 函式，而不是 RpcBindingSetAuthInfo 函式來建立已驗證的系結。 如果這麼做，則會將指標傳遞至 RPC_SECURITY_QOS 結構，作為 RpcBindingSetAuthInfoEx的最終參數。 此結構包含服務品質的相關資訊。 用戶端程式也可以指定身分識別追蹤，並選取模擬類型。

使用RPC_SECURITY_QOS結構的Capabilities成員來設定用戶端/伺服器應用程式的驗證部分。 如果選取RPC_C_QOS_CAPABILITIES_DEFAULT，RPC 執行時間程式庫會根據 SSP 的預設值驗證用戶端或伺服器。 根據預設，Kerberos 通訊協定 SSP 會驗證用戶端和伺服器。 Microsoft 提供之所有其他 SSP 的預設值是向伺服器驗證用戶端，但不要向用戶端驗證服務器。

如果用戶端和伺服器應該一律彼此驗證，請將RPC_SECURITY_QOS結構的Capabilities成員設定為 RPC_C_QOS_CAPABILITIES_MUTUAL_AUTH。 某些安全性提供者可能不支援相互驗證。 如果為這類安全性提供者指定RPC_C_QOS_CAPABILITIES_MUTUAL_AUTH，則會在進行遠端程序呼叫時傳回錯誤。 使用 SCHANNEL SSP 時，也可以將 Capabilities 成員設定為 RPC_C_QOS_CAPABILITIES_ANY_AUTHORITY。 這個常數會指定即使簽發用戶端驗證憑證的憑證授權單位單位不在 SSP 的根憑證存放區中，SSP 仍應該驗證遠端程序呼叫。 如果 SSP 無法辨識憑證授權單位單位，則預設值為拒絕憑證。 憑證授權單位單位是發行驗證憑證的獨立公司或組織，例如 VeriSign。

應用程式也可以設定 RPC 執行時間程式庫所使用的身分識別追蹤。 程式通常會使用 靜態身分識別追蹤。 透過靜態追蹤，用戶端的認證會在呼叫 RpcBindingSetAuthInfo 函式時設定。 RPC 執行時間程式庫接著會針對系結上的所有 RPC 呼叫使用這些認證，不論呼叫執行緒或呼叫進程的身分識別變更為何。 應用程式也可以選取 動態身分識別追蹤。 動態身分識別追蹤會指示 RPC 執行時間程式庫在每個呼叫時使用呼叫執行緒的認證，而不是系結控制碼。 預設身分識別追蹤是靜態的。

如果用戶端的身分識別不會變更，靜態身分識別追蹤可能會有更好的效能特性，而且可以在每次呼叫執行緒上的身分識別是否與提供給安全性系統的身分識別相同時，儲存 RPC 執行時間。 如果呼叫執行緒的身分識別可能會在呼叫之間變更，而且伺服器需要辨識這些變更，最好是指定動態身分識別追蹤—RPC 執行時間會無訊息且有效率地追蹤您身分識別，如果身分識別變更，請代表您管理該變更。

注意

針對 ncalrpc 呼叫，靜態和動態身分識別追蹤有不同的效能特性，而且視情況而定，可能更快。

 

在 QOS 規格中，用戶端程式也可以設定伺服器程式可以代表其執行的模擬類型。 如需詳細資訊，請參閱 用戶端模擬。

RPC_SECURITY_QOS結構的版本號碼欄位應該一律設定為 RPC_C_SECURITY_QOS_VERSION。