Verwenden von HTTP als RPC-Transport

RPC-over-HTTP ermöglicht Es Clientprogrammen, das Internet zum Ausführen von Prozeduren zu verwenden, die von Serverprogrammen in entfernten Netzwerken bereitgestellt werden. RPC über HTTP tunnelt seine Aufrufe über einen eingerichteten HTTP-Port. Daher können die Aufrufe netzwerkübergreifende Firewalls sowohl im Client- als auch im Servernetzwerk durchführen.

RPC über HTTP leitet seine Aufrufe an den RPC-Proxy weiter, der sich im Netzwerk des RPC-Servers befindet. Der RPC-Proxy stellt eine Verbindung mit dem RPC-Server her und verwaltet diesen. Es dient als Proxy, der Remoteprozeduraufrufe an den RPC-Server sendet und die Antworten des Servers über das Internet zurück an die Clientanwendung sendet. Dieser Vorgang wird im folgenden Diagramm veranschaulicht.

Das Diagramm zeigt eine Firewall im Netzwerk der Clientanwendung. Dies ist nicht erforderlich, damit RPC über HTTP funktioniert. Wenn das Clientnetzwerk jedoch über eine Firewall verfügt, benötigt es auch ein Proxyserverprogramm, z. B. Microsoft Proxy Server.

Wenn das Clientprogramm einen Remoteprozeduraufruf mit HTTP als Transport ausgibt, kontaktiert die RPC-Laufzeitbibliothek auf dem Client den RPC-Proxy. Je nachdem, ob der RPC-Client aufgefordert wurde, HTTP oder HTTPS (HTTP mit SSL) zu verwenden, wird Port 80 bzw. Port 443 verwendet. Der RPC-Proxy kontaktiert das RPC-Serverprogramm und stellt eine TCP/IP-Verbindung her. Der Client und der RPC-Proxy behalten ihre HTTP- oder HTTPS-Verbindung über das Internet bei. Die HTTP- oder HTTPS-Verbindung des Clients mit dem RPC-Proxy kann eine Firewall (vorbehaltlich entsprechender Zugriffsberechtigungen) durchlaufen, sofern eine vorhanden ist. Der Server kann dann den Remoteprozeduraufruf ausführen und die Verbindung über den RPC-Proxy verwenden, um an den Client zu antworten. Der RPC-Proxy ist eine ISAPI-Erweiterung, die im Kontext von IIS ausgeführt wird.

Wenn der Client oder der Server aus irgendeinem Grund die Verbindung trennt, erkennt der RPC-Proxy die Verbindung und beendet die RPC-Sitzung. Solange die Sitzung fortgesetzt wird, behält der RPC-Proxy seine Verbindungen mit dem Client und dem Server bei. Es leitet Remoteprozeduraufrufe vom Client an den Server weiter und sendet Antworten vom Server an den Client.

Das RPC-Clientprogramm kann seine RPC-Aufrufe über das Internet tunneln, indem es eine Zeichenfolgenbindung im Format erstellt:

[object_uuid@]ncacn_http:rpc_server[endpoint,HttpProxy=proxy_server:http_port,RpcProxy=rpc_proxy:rpc_port,HttpConnectionOption=UseHttpProxy]

Hierbei gilt:

• object_uuid gibt eine RPC-Objekt-UUID an. Weitere Informationen finden Sie unter Generieren von Schnittstellen-UUIDs und UUID für Zeichenfolgen.

• ncacn_http wählt die Protokollsequenzspezifikation für RPC über HTTP aus. Weitere Informationen finden Sie unter Protokollsequenzkonstanten und Zeichenfolgenbindung.

• rpc_server ist die Netzwerkadresse des Computers, der den RPC-Serverprozess ausführt. Die Serveradresse muss in einer Form angegeben werden, die vom RPC-Proxycomputer und nicht vom Client sichtbar und verständlich ist. Da der Client keine direkte Verbindung mit dem Server herstellt, muss er nicht in der Lage sein, den Namen des Servers aufzulösen oder eine Verbindung mit diesem herzustellen. Der RPC-Proxy stellt die Verbindung im Namen des Clients her, und daher muss rpc_server ein Name sein, der vom RPC-Proxy erkennbar ist.

• endpoint gibt den TCP/IP-Port an, auf den der RPC-Serverprozess auf Remoteprozeduraufrufe lauscht. Weitere Informationen finden Sie unter Suchen von Endpunkten.

• HttpProxy gibt optional einen HTTP-Proxyserver im Rpc-Clientnetzwerk an, z. B. Microsoft Proxy Server. Wenn ein Proxyserver ausgewählt ist, wird keine Portnummer angegeben. Der RPC-Stub verwendet standardmäßig Port 80, wenn SSL nicht angefordert wird, und Port 443, wenn SSL angegeben ist.

• RpcProxy gibt die Adresse und Portnummer des IIS-Computers an, der als Proxy für den RPC-Server fungiert. Sie müssen dies nur angeben, wenn sich der RPC-Serverprozess auf einem anderen Computer als der RPC-Proxy befindet. Wenn Sie keine Portnummer angeben, verwendet der RPC-Client-Stub standardmäßig Port 80, wenn SSL nicht angegeben ist, und port 443, wenn SSL (HTTPS) angegeben ist.

• Mit HttpConnectionOption können Sie optional das Verhalten von RPC beim Herstellen von HTTP-Verbindungen steuern. Der UseHttpProxy-Wert weist RPC an, seinen Datenverkehr jederzeit über den HTTP-Proxy weiterzuleiten, auch wenn die Internetoptionen für den Client im Internet Explorer auf "Proxyserver für lokale Adressen umgehen" festgelegt sind.

  Diese Option wird unter Windows 7, Windows Server 2008 R2, Windows 8.1 und Windows Server 2012 R2 mit installiertem KB2916915 unterstützt. Diese Option wird auf Windows 8 und Windows Server 2012 nicht unterstützt. Anwendungen können ermitteln, ob diese Option von der RPC-Runtime unterstützt wird, indem sie den Registrierungswert ConnectionOptionsFlag unter dem folgenden Registrierungsschlüssel überprüfen:

  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc

  Wenn das Bit 0 (LSB) dieses Registrierungswerts festgelegt ist, wird diese spezifische Option unterstützt. Andernfalls wird diese Option von der RPC-Runtime im System nicht unterstützt.

Weitere Informationen zum Erstellen von Zeichenfolgenbindungen finden Sie unter Bindung und Handles.

Das RPC-Serverprogramm kann getunnelte RPC-Aufrufe akzeptieren, indem es auf der ncacn_http Protokollsequenz lauscht.

Microsoft verfügt über zwei Hauptimplementierungen von RPC über HTTP: Version 1 und Version 2.

Version 1 (als RPC über HTTP v1 bezeichnet) wird über Windows XP unterstützt. Version 1 des RPC-Proxys wird über Windows 2000 unterstützt.

Version 2 (als RPC über HTTP v2 bezeichnet) ist die aktuelle Version.

Die beiden Versionen verfügen über unterschiedliche Funktionen und eingeschränkte Interoperabilität. Eine Zusammenfassung der Unterschiede finden Sie hier. Überlegungen zur Interoperabilität finden Sie unter Systemanforderungen und Interoperabilität für RPC über HTTP.

• RPC über HTTP v1 erfordert, dass SSL-Tunneling für alle HTTP-Proxys/Firewalls zwischen dem RPC-über-HTTP-Client und dem RPC-Proxy aktiviert ist. RPC über HTTP v1 versucht, einen SSL-Tunnel über Port 80 zu erstellen, obwohl die gesendeten Daten nicht tatsächlich SSL-verschlüsselt sind. Proxys und Firewalls lehnen solche Anforderungen in der Regel ab, es sei denn, sie sind explizit so konfiguriert, dass sie zugelassen werden. RPC über HTTP v2 hat keine solche Anforderung.
• RPC über HTTP v1 kann keine SSL-Sitzung für den RPC-Proxy einrichten. Rpc über HTTP v2 kann den gesamten RPC-über HTTP-Datenverkehr innerhalb einer SSL-Sitzung senden. Standardmäßig erfordert v2, dass die Daten innerhalb einer SSL-Sitzung gesendet werden.
• RPC über HTTP v1 kann sich nicht beim RPC-Proxy authentifizieren. RPC über HTTP v2 kann sich authentifizieren. Standardmäßig erfordert v2 eine Authentifizierung beim RPC-Proxy.
• Der RPC-Proxy v1 funktioniert nicht ordnungsgemäß, wenn der IIS-Computer, auf dem er installiert ist, Teil einer Webfarm ist. RPC-Proxy v2 funktioniert ordnungsgemäß, wenn der IIS-Computer, auf dem er installiert ist, Teil einer Webfarm ist.

Angenommen, für instance muss Ihr Clientprogramm über das Internet eine Verbindung mit einem RPC-Server auf einem Computer namens Server7.microsoft.com herstellen. Angenommen, der RPC-Proxy wird auf Major7.microsoft.com ausgeführt. Das RPC-Serverprogramm lauscht an Port 2225. Ihr Client würde die Zeichenfolgenbindung verwenden:

ncacn_http:Server7.microsoft.com[2225, RpcProxy=Major7.microsoft.com]

Wenn der RPC-Proxy den Servernamen als Server7 auflösen kann, ohne dass ein vollqualifizierter Domänenname erforderlich ist, können Sie auch Folgendes angeben:

ncacn_http:Server7 [2225, RpcProxy=Major7.microsoft.com]

Wenn das Clientnetzwerk eine Firewall und einen Internetproxyserver namens myproxy verwendet und internet Explorer auf dem Client nicht für die Verwendung dieses Proxys konfiguriert ist, müssen Sie die Zeichenfolgenbindung des Clients in Folgendem ändern:

ncacn_http:Server7.microsoft.com[,HttpProxy=myproxy:80,RpcProxy=Major7.microsoft.com:80]

Dadurch wird der Client aufgefordert, auf Server7.microsoft.com eine Verbindung mit dem RPC-Serverprogramm herzustellen. Dazu verwendet der Client zunächst Port 80 (oder Port 443, wenn SSL verwendet wird), um eine Verbindung mit myproxy herzustellen. Dadurch erhält das Clientprogramm Zugriff auf das Internet. Über das Internet stellt das Clientprogramm als Nächstes eine Verbindung mit dem RPC-Proxy auf Major7.microsoft.com her. Der RPC-Proxy stellt eine Verbindung mit dem RPC-Serverprogramm her, das auf Server7.microsoft.com ausgeführt wird.

Wenn das Clientnetzwerk eine Firewall verwendet und der RPC-Proxy nicht direkt erreicht werden kann, kann die Clientzeichenfolgenbindung geändert werden, um eine Verbindung schneller herzustellen:

ncacn_http:Server7.microsoft.com[RpcProxy=Major7.microsoft.com:80,HttpConnectionOption=UseHttpProxy]

Mit der HttpConnectionOption können Sie das Verhalten von RPC beim Herstellen von HTTP-Verbindungen steuern. Der UseHttpProxy-Wert weist RPC an, seinen Datenverkehr jederzeit über den HTTP-Proxy weiterzuleiten, auch wenn die Internetoptionen für den Client im Internet Explorer auf "Proxyserver für lokale Adressen umgehen" festgelegt sind. Dadurch wird der Client aufgefordert, über den HTTP-Proxy eine erzwungene Verbindung mit dem RPC-Proxy herzustellen. Dadurch wird die Zeit zum Herstellen einer Verbindung beschleunigt, da jede Verzögerung bei der Suche nach dem RPC-Server vor der Verwendung des HTTP-Proxys umgangen wird.

Wenn die Option HttpConnectionOption verwendet wird und internet Explorer auf dem Client nicht für die Verwendung dieses HTTP-Proxys konfiguriert ist, können Verbindungen mit RPC_S_INVALID_NETWORK_OPTIONS fehlschlagen.

Die überwiegende Mehrheit der Computer ist heute für das Webbrowsen konfiguriert. Daher müssen die meisten Clients den HttpProxy nicht angeben, da er aus den Internetkonnektivitätseinstellungen abgerufen wird.