Udostępnij za pośrednictwem

Używanie protokołu HTTP jako transportu RPC

  • Artykuł

RPC-over-HTTP umożliwia programom klienckim korzystanie z Internetu do wykonywania procedur dostarczanych przez programy serwera w odległych sieciach. RPC przez HTTP przesyła swoje wywołania za pośrednictwem ustalonego portu HTTP. W związku z tym jego wywołania mogą przekraczać zapory sieciowe zarówno w sieciach klienta, jak i serwera.

RPC za pośrednictwem protokołu HTTP kieruje wywołania serwera proxy RPC znajdującego się w sieci serwera RPC. Serwer proxy RPC ustanawia i utrzymuje połączenie z serwerem RPC. Służy jako serwer proxy, wysyłając zdalne wywołania procedur do serwera RPC i wysyłając odpowiedzi serwera z powrotem przez Internet do aplikacji klienckiej. Ten proces przedstawiono na poniższym diagramie.

interakcję między serwerem RPC i serwerem informacji internetowych dla RPC przez protokół HTTP

Diagram przedstawia zaporę w sieci aplikacji klienckiej. Nie jest to wymagane do działania RPC za pośrednictwem protokołu HTTP. Jeśli jednak sieć kliencka ma zaporę, będzie ona również potrzebować programu serwera proxy, takiego jak Serwer proxy firmy Microsoft.

Gdy program kliencki uruchamia zdalne wywołanie procedury przy użyciu protokołu HTTP jako transportu, biblioteka czasu wykonywania RPC na kliencie kontaktuje się z serwerem proxy RPC. W zależności od tego, czy klient RPC został poproszony o użycie protokołu HTTP czy HTTPS (HTTP z SSL), używany jest odpowiednio port 80 lub port 443. Serwer proxy RPC kontaktuje się z programem serwera RPC i ustanawia połączenie TCP/IP. Klient i serwer proxy RPC utrzymują swoje połączenie HTTP lub HTTPS przez Internet. Połączenie HTTP lub HTTPS klienta z serwerem proxy RPC może przechodzić przez zaporę (pod warunkiem odpowiednich uprawnień dostępu), jeśli istnieje. Następnie serwer może wykonać zdalne wywołanie procedury i użyć połączenia za pośrednictwem serwera proxy RPC, aby odpowiedzieć klientowi. Proxy RPC jest rozszerzeniem ISAPI działającym w kontekście IIS.

Jeśli klient lub serwer rozłączy się z jakiegokolwiek powodu, serwer proxy RPC wykryje go i zakończy sesję RPC. Tak długo, jak sesja będzie kontynuowana, serwer proxy RPC będzie utrzymywać połączenia z klientem i serwerem. Przekazuje zdalne wywołania procedury od klienta do serwera i wysyła odpowiedzi z serwera do klienta.

Program klienta RPC może tunelować wywołania RPC za pośrednictwem Internetu, tworząc powiązanie w formie ciągu znaków.

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

Gdzie:

  • object_uuid określa identyfikator UUID obiektu RPC. Aby uzyskać więcej informacji, zobacz Generowanie identyfikatorów UUID interfejsu oraz identyfikatorów UUID dla ciągów .

  • ncacn_http wybiera specyfikację sekwencji protokołu dla RPC za pośrednictwem protokołu HTTP. Aby uzyskać więcej informacji, zobacz Protocol Sequence Constants i String Binding.

  • rpc_server to adres sieciowy komputera wykonującego proces serwera RPC. Adres serwera musi być określony w postaci widocznej i zrozumiałej przez komputer proxy RPC, a nie przez klienta. Ponieważ klient nie łączy się bezpośrednio z serwerem, nie musi być w stanie rozpoznać nazwy serwera ani nawiązać z nim połączenia. Serwer proxy RPC nawiąże połączenie w imieniu klienta, a w związku z tym rpc_server musi być nazwą rozpoznawalną przez serwer proxy RPC.

  • punktu końcowego określa port TCP/IP, na który proces serwera RPC nasłuchuje wywołań procedur zdalnych. Aby uzyskać więcej informacji, zobacz Znajdowanie punktów końcowych.

  • httpproxy opcjonalnie określa serwer proxy HTTP w sieci klienta RPC, na przykład Microsoft Proxy Server. Jeśli wybrano serwer proxy, żaden numer portu nie jest określony, klaska RPC domyślnie używa portu 80, jeśli protokół SSL nie jest żądany, a port 443, jeśli określono protokół SSL.

  • RpcProxy określa adres i numer portu komputera z usługą IIS, który działa jako serwer proxy dla serwera RPC. Należy to określić tylko wtedy, gdy proces serwera RPC znajduje się na innym komputerze niż serwer proxy RPC. Jeśli nie określisz numeru portu, to osad klienta RPC domyślnie używa portu 80, gdy protokół SSL nie jest określony, a portu 443, gdy protokół SSL (HTTPS) jest określony.

  • HttpConnectionOption opcjonalnie umożliwia sterowanie zachowaniem RPC podczas nawiązywania połączeń HTTP. Wartość UseHttpProxy nakazuje RPC kierowanie ruchu przez serwer proxy HTTP przez cały czas, w tym także wtedy, gdy klient ma w programie Internet Explorer ustawioną opcję „Pomiń serwer proxy dla adresów lokalnych”.

    Ta opcja jest obsługiwana w systemach Windows 7, Windows Server 2008 R2, Windows 8.1 i Windows Server 2012 R2 z zainstalowanym KB2916915. Ta opcja nie jest obsługiwana w systemach Windows 8 i Windows Server 2012. Aplikacje mogą określić, czy ta opcja jest obsługiwana przez środowisko uruchomieniowe RPC, sprawdzając ConnectionOptionsFlag wartość rejestru znajdującą się pod następującym kluczem rejestru:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc

    Jeśli ustawiono bit 0 (LSB) tej wartości rejestru, ta konkretna opcja jest obsługiwana; w przeciwnym razie ta opcja nie jest obsługiwana przez środowisko uruchomieniowe RPC w systemie.

Aby uzyskać więcej informacji na temat tworzenia wiązań łańcuchów, zobacz Binding and Handles.

Program serwera RPC może akceptować tunelowane wywołania RPC poprzez odbieranie w sekwencji protokołu ncacn_http.

Firma Microsoft ma dwie główne implementacje RPC za pośrednictwem protokołu HTTP: wersja 1 i wersja 2.

Wersja 1 (nazywana RPC za pośrednictwem protokołu HTTP v1) jest obsługiwana za pośrednictwem systemu Windows XP. Wersja 1 serwera proxy RPC jest obsługiwana przez system Windows 2000.

Wersja 2 (nazywana RPC za pośrednictwem protokołu HTTP w wersji 2) jest bieżącą wersją.

Obie wersje mają różne możliwości i ograniczoną współdziałalność. Poniżej przedstawiono podsumowanie różnic. Aby zapoznać się z zagadnieniami dotyczącymi interoperacyjności, zobacz wymagania systemowe i współdziałanie dla RPC przez HTTP.

  • RPC przez HTTP v1 wymaga włączenia tunelowania SSL na wszystkich serwerach proxy i zaporach między klientem RPC przez HTTP a serwerem proxy RPC. RPC za pośrednictwem protokołu HTTP w wersji 1 próbuje skompilować tunel SSL przez port 80, mimo że dane, które wysyła, nie są w rzeczywistości szyfrowane za pomocą protokołu SSL. Serwery proxy i zapory zwykle odrzucają takie żądania, chyba że są jawnie skonfigurowane tak, aby zezwalały na nie. RPC przez HTTP v2 nie ma takiego wymagania.
  • RPC za pośrednictwem protokołu HTTP v1 nie może ustanowić sesji SSL na serwerze proxy RPC. RPC przez HTTP v2 może wysyłać cały ruch RPC przez HTTP w ramach sesji SSL; wersja 2 domyślnie wymaga wysyłania danych w ramach sesji SSL.
  • RPC za pośrednictwem protokołu HTTP v1 nie może uwierzytelnić się na serwerze proxy RPC. RPC za pośrednictwem protokołu HTTP w wersji 2 może się uwierzytelniać; domyślnie wersja 2 wymaga uwierzytelniania serwera proxy RPC.
  • Serwer proxy RPC w wersji 1 nie działa poprawnie, gdy maszyna usług IIS, na której jest zainstalowana, jest częścią farmy sieci Web. Serwer proxy RPC w wersji 2 działa prawidłowo, gdy maszyna usług IIS, na której jest zainstalowana, jest częścią farmy sieci Web.

Notatka

Jeśli Microsoft Internet Explorer jest zainstalowany na komputerze klienta, a klient nie określa HttpProxy w jego powiązaniu ciągu, stub klienta RPC przeszuka rejestr na komputerze klienckim w poszukiwaniu wpisu HttpProxy. Jeśli go znajdzie, użyje serwera proxy określonego we wpisie rejestru.

 

Załóżmy na przykład, że program kliencki musi połączyć się przez Internet z serwerem RPC na komputerze o nazwie Server7.microsoft.com. Ponadto załóżmy, że serwer proxy RPC działa na Major7.microsoft.com. Program serwera RPC nasłuchuje portu 2225. Klient będzie używać wiązania ciągu znaków.

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

Jeśli serwer proxy RPC może rozpoznać nazwę serwera jako Serwer7, bez wymagania w pełni kwalifikowanej nazwy domeny, można również określić:

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

Jeśli sieć klienta używa zapory i internetowego serwera proxy o nazwie myproxy, a program Internet Explorer na kliencie nie jest skonfigurowany do używania tego serwera proxy, należy zmodyfikować powiązanie ciągu klienta na:

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

Spowoduje to przekierowanie klienta do nawiązania połączenia z programem serwera RPC w Server7.microsoft.com. W tym celu klient najpierw użyje portu 80 (lub portu 443, jeśli jest używany protokół SSL), aby nawiązać połączenie z usługą myproxy. Zapewni to programowi klienckim dostęp do Internetu. Korzystając z Internetu, program kliencki następnie łączy się z serwerem proxy RPC na Major7.microsoft.com. Serwer proxy RPC nawiąży połączenie z programem serwera RPC uruchomionym na Server7.microsoft.com.

Jeśli sieć kliencka używa zapory i jeśli serwer proxy RPC nie może zostać nawiązany bezpośrednio, w celu szybszego nawiązania połączenia można zmodyfikować powiązanie parametrów klienta:

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

HttpConnectionOption umożliwia kierowanie zachowania RPC podczas nawiązywania połączeń HTTP. Wartość UseHttpProxy nakazuje RPC kierować swój ruch przez serwer proxy HTTP przez cały czas, w tym także wtedy, gdy klient ma ustawione Opcje internetowe w programie Internet Explorer na "Ominięcie serwera proxy dla adresów lokalnych". To nakazuje klientowi wymuszenie połączenia z serwerem proxy RPC za pośrednictwem serwera proxy HTTP. Przyspiesza to czas nawiązywania połączenia, ponieważ pomija wszelkie opóźnienia wyszukiwania serwera RPC bezpośrednio przed użyciem serwera proxy HTTP.

Jeśli jest używana opcja HttpConnectionOption, a program Internet Explorer na kliencie nie jest skonfigurowany do używania tego serwera proxy HTTP, połączenia mogą zakończyć się niepowodzeniem z RPC_S_INVALID_NETWORK_OPTIONS.

Zdecydowana większość komputerów jest obecnie skonfigurowana do przeglądania sieci Web. W związku z tym większość klientów nie musi określać HttpProxy, ponieważ zostanie on pobrany z ustawień łączności z Internetem.