Использование HTTP в качестве транспорта RPC
RPC-over-HTTP позволяет клиентским программам использовать Интернет для выполнения процедур, предоставляемых серверными программами в удаленных сетях. RPC через туннели HTTP осуществляет вызовы через установленный порт HTTP. Таким образом, его вызовы могут пересекать сетевые брандмауэры как в клиентских, так и в серверных сетях.
RPC по протоколу HTTP направляет свои вызовы к прокси-серверу RPC, расположенному в сети сервера RPC. Прокси-сервер RPC устанавливает и поддерживает подключение к серверу RPC. Он служит прокси-сервером, отправляя удаленные вызовы процедур на сервер RPC и отправляя ответы сервера обратно через Интернет в клиентское приложение. Этот процесс показан на следующей схеме.
На схеме показан брандмауэр в сети клиентского приложения. Это не обязательно для работы RPC по протоколу HTTP. Однако если у клиентской сети есть брандмауэр, также потребуется программа прокси-сервера, например Microsoft Proxy Server.
Когда клиентская программа выполняет удаленный вызов процедуры, используя HTTP в качестве транспортного протокола, библиотека времени выполнения RPC на клиенте обращается к прокси-серверу RPC. В зависимости от того, был ли клиенту RPC задействован порт HTTP или HTTPS (HTTP с SSL), используется либо порт 80, либо порт 443 соответственно. Прокси-сервер RPC обращается к программе сервера RPC и устанавливает подключение TCP/IP. Клиент и прокси-сервер RPC поддерживают подключение HTTP или HTTPS через Интернет. Http-подключение клиента или HTTPS к прокси-серверу RPC может передаваться через брандмауэр (при условии соответствующих разрешений доступа), если он присутствует. Затем сервер может выполнить удаленный вызов процедуры и использовать подключение через прокси-сервер RPC для ответа клиенту. Прокси-сервер RPC — это расширение ISAPI, работающее в контексте IIS.
Если клиент или сервер отключается по какой-либо причине, прокси-сервер RPC обнаружит его и завершит сеанс RPC. Пока сеанс продолжается, прокси-сервер RPC будет поддерживать свои подключения к клиенту и серверу. Он перенаправит удаленные вызовы процедур с клиента на сервер и отправляет ответы с сервера клиенту.
Клиентская программа RPC может выполнять туннелирование вызовов RPC через Интернет, создавая строковую привязку следующего вида:
[object_uuid@]ncacn_http:rpc_server[endpoint,HttpProxy=proxy_server:http_port,RpcProxy=rpc_proxy:rpc_port,HttpConnectionOption=UseHttpProxy]
Где:
object_uuid указывает UUID объекта RPC. Дополнительные сведения см. в разделах Генерация интерфейсов UUID и Строковый UUID.
ncacn_http выбирает спецификацию последовательности протоколов для RPC по протоколу HTTP. Дополнительные сведения см. в разделе Константы последовательности протоколов и строковая привязка.
rpc_server — это сетевой адрес компьютера, выполняющего процесс сервера RPC. Адрес сервера должен быть указан в форме, видимой и понятной прокси-компьютером RPC, а не клиентом. Так как клиент не подключается непосредственно к серверу, ему не нужно разрешать имя сервера или устанавливать подключение к нему. Прокси-сервер RPC установит подключение от имени клиента и, следовательно, rpc_server должно быть именем, распознаваемым прокси-сервером RPC.
конечная точка указывает TCP/IP порт, который процесс сервера RPC прослушивает для удаленных вызовов процедур. Дополнительные сведения см. в статье Поиск конечных точек.
HttpProxy при необходимости указывает http-прокси-сервер в сети клиента RPC, например Microsoft Proxy Server. Если выбран прокси-сервер и номер порта не указан, заглушка RPC по умолчанию использует порт 80, если SSL не запрашивается, и порт 443, если SSL указан.
RpcProxy указывает адрес и номер порта компьютера IIS, который выступает в качестве прокси-сервера на серверЕ RPC. Это необходимо указать, только если процесс сервера RPC находится на компьютере, отличном от прокси-сервера RPC. Если номер порта не указан, заглушка клиента RPC по умолчанию использует порт 80, если SSL не указан, и использует порт 443, если указан протокол SSL (HTTPS).
HttpConnectionOption при необходимости позволяет направлять поведение RPC при выполнении HTTP-подключений. Значение UseHttpProxy указывает RPC всегда направлять его трафик через Http прокси-сервер, включая случаи, когда у клиента в Internet Explorer настроены параметры интернет-соединения с опцией "Обход прокси-сервера для локальных адресов".
Этот параметр поддерживается в Windows 7, Windows Server 2008 R2, Windows 8.1 и Windows Server 2012 R2 с установленными KB2916915. Этот параметр не поддерживается в Windows 8 и Windows Server 2012. Приложения могут определить, поддерживается ли этот параметр средой выполнения RPC, проверив значение реестра ConnectionOptionsFlag, расположенное в следующем разделе реестра:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc
Если установлен бит 0 (LSB) этого значения реестра, то этот конкретный параметр поддерживается; в противном случае этот параметр не поддерживается средой выполнения RPC в системе.
Дополнительные сведения о создании строковых привязок см. в разделе Привязка и обработка.
Программа сервера RPC может принимать туннелированные вызовы RPC, прослушивая последовательность протоколов ncacn_http.
Корпорация Майкрософт имеет две основные реализации RPC по протоколу HTTP: версия 1 и версия 2.
Версия 1 (называемая RPC по протоколу HTTP версии 1) поддерживается с помощью Windows XP. Версия 1 прокси-сервера RPC поддерживается до Windows 2000.
Версия 2 (называется RPC по протоколу HTTP версии 2) — текущая версия.
Две версии имеют разные возможности и ограниченную совместимость. Краткое описание различий представлено здесь. Рекомендации по взаимодействию см. в разделе Требования к системе и взаимодействие для RPC по протоколу HTTP.
- RPC по протоколу HTTP версии 1 требует, чтобы SSL-туннелирование было включено на всех HTTP прокси-серверах и брандмауэрах между клиентом RPC через HTTP и RPC-прокси-сервером. RPC по протоколу HTTP версии 1 пытается создать SSL-туннель через порт 80, несмотря на то, что данные, которые он отправляет, на самом деле не зашифрованы SSL. Прокси-серверы и брандмауэры обычно отклоняют такие запросы, если их не настроили явно. RPC по протоколу HTTP версии 2 не имеет такого требования.
- RPC по протоколу HTTP версии 1 не может установить сеанс SSL для прокси-сервера RPC. RPC по протоколу HTTP версии 2 может отправлять весь RPC через HTTP-трафик в сеансе SSL; По умолчанию версия 2 требует отправки данных в сеансе SSL.
- RPC по протоколу HTTP версии 1 не может пройти проверку подлинности в прокси-сервере RPC. RPC версии 2 по протоколу HTTP способен аутентифицировать; по умолчанию, версия 2 требует аутентификации для прокси-сервера RPC.
- Прокси-сервер RPC версии 1 не работает правильно, если компьютер IIS, на котором он установлен, является частью веб-фермы. Прокси-сервер RPC версии 2 работает правильно, когда компьютер IIS, на котором он установлен, является частью веб-фермы.
Заметка
Если на компьютере клиентской программы установлен Microsoft Internet Explorer, и клиент не указывает HttpProxy в своей строковой привязке, заглушка RPC выполнит поиск в реестре клиентского компьютера для записи HttpProxy. Если он находит его, он будет использовать прокси-сервер, указанный в записи реестра.
Предположим, например, клиентской программе необходимо подключиться через Интернет к серверу RPC на компьютере с именем Server7.microsoft.com. Кроме того, предположим, что прокси-сервер RPC работает на Major7.microsoft.com. Программа сервера RPC прослушивает порт 2225. Клиент будет использовать строку привязки:
ncacn_http:Server7.microsoft.com[2225, RpcProxy=Major7.microsoft.com]
Если прокси-сервер RPC может разрешить имя сервера как Server7, не требуя полного доменного имени, можно также указать:
ncacn_http:Server7 [2225, RpcProxy=Major7.microsoft.com]
Если в клиентской сети используется брандмауэр и прокси-сервер Интернета с именем myproxy, а Internet Explorer на клиенте не настроен для использования этого прокси-сервера, необходимо изменить строку привязки клиента следующим образом:
ncacn_http:Server7.microsoft.com[,HttpProxy=myproxy:80,RpcProxy=Major7.microsoft.com:80]
Это позволяет клиенту подключаться к серверной программе RPC на Server7.microsoft.com. Для этого клиент сначала будет использовать порт 80 (или порт 443, если используется SSL) для подключения к myproxy. Это даст клиентской программе доступ к Интернету. С помощью Интернета клиентская программа далее подключается к прокси-серверу RPC на Major7.microsoft.com. Прокси-сервер RPC установит подключение к программе сервера RPC, работающей на Server7.microsoft.com.
Если клиентская сеть использует брандмауэр и если прокси-сервер RPC не может быть достигнут напрямую, чтобы установить подключение быстрее, привязка строки клиента может быть изменена следующим образом:
ncacn_http:Server7.microsoft.com[RpcProxy=Major7.microsoft.com:80,HttpConnectionOption=UseHttpProxy]
HttpConnectionOption позволяет направлять поведение RPC при выполнении HTTP-подключений. Значение UseHttpProxy указывает RPC всегда маршрутизировать трафик через прокси-сервер HTTP, включая случаи, когда у клиента в параметрах Интернета Internet Explorer установлено значение "Обход прокси-сервера для локальных адресов." При этом клиент принудительно подключается к прокси-серверу RPC через http-прокси. Это ускоряет время установления подключения, так как оно избегает любых задержек при поиске сервера RPC непосредственно перед использованием прокси-сервера HTTP.
Если используется параметр HttpConnectionOption, а Internet Explorer на клиенте не настроен для использования этого Http-прокси, подключения могут завершиться ошибкой RPC_S_INVALID_NETWORK_OPTIONS.
Подавляющее большинство компьютеров сегодня настроены для просмотра в Интернете. Поэтому большинству клиентов не нужно указывать HttpProxy, так как он будет получен из параметров подключения к Интернету.