다음을 통해 공유


HTTP를 RPC 전송으로 사용

RPC over-HTTP를 사용하면 클라이언트 프로그램이 인터넷을 사용하여 먼 네트워크의 서버 프로그램에서 제공하는 프로시저를 실행할 수 있습니다. HTTP를 통한 RPC는 설정된 HTTP 포트를 통해 호출을 터널합니다. 따라서 해당 호출은 클라이언트 및 서버 네트워크 모두에서 네트워크 방화벽을 교차할 수 있습니다.

HTTP를 통한 RPC는 해당 호출을 RPC 서버의 네트워크에 있는 RPC 프록시로 라우팅합니다. RPC 프록시는 RPC 서버에 대한 연결을 설정하고 유지 관리합니다. 프록시 역할을 하여 RPC 서버에 원격 프로시저 호출을 디스패치하고 인터넷을 통해 서버의 회신을 클라이언트 애플리케이션으로 다시 보냅니다. 이 프로세스는 다음 다이어그램에 설명되어 있습니다.

rpc http에 대한 rpc 서버와 인터넷 정보 서버 간의 상호 작용

이 다이어그램은 클라이언트 애플리케이션 네트워크의 방화벽을 보여줍니다. HTTP를 통한 RPC가 작동하려면 이 작업이 필요하지 않습니다. 그러나 클라이언트 네트워크에 방화벽이 있는 경우 Microsoft 프록시 서버와 같은 프록시 서버 프로그램도 필요합니다.

클라이언트 프로그램이 HTTP를 전송으로 사용하여 원격 프로시저 호출을 실행하면 클라이언트의 RPC 런타임 라이브러리가 RPC 프록시에 연결됩니다. RPC 클라이언트가 HTTP 또는 HTTPS(SSL을 사용하는 HTTP) 포트 80 또는 포트 443을 사용하도록 요청되었는지에 따라 각각 사용됩니다. RPC 프록시는 RPC 서버 프로그램에 연결하고 TCP/IP 연결을 설정합니다. 클라이언트와 RPC 프록시는 인터넷을 통해 HTTP 또는 HTTPS 연결을 유지 관리합니다. RPC 프록시에 대한 클라이언트의 HTTP 또는 HTTPS 연결은 방화벽(적절한 액세스 권한이 있는 경우)을 통과할 수 있습니다. 그런 다음 서버는 원격 프로시저 호출을 실행하고 RPC 프록시를 통해 연결을 사용하여 클라이언트에 회신할 수 있습니다. RPC 프록시는 IIS 컨텍스트에서 실행되는 ISAPI 확장입니다.

어떤 이유로든 클라이언트 또는 서버의 연결이 끊어지면 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 RPC 개체 UUID를 지정합니다. 자세한 내용은 인터페이스 UUID 및 문자열 UUID 생성을 참조 하세요.

  • ncacn_http HTTP를 통한 RPC에 대한 프로토콜 시퀀스 사양을 선택합니다. 자세한 내용은 프로토콜 시퀀스 상수문자열 바인딩을 참조하세요.

  • rpc_server RPC 서버 프로세스를 실행하는 컴퓨터의 네트워크 주소입니다. 서버 주소는 클라이언트가 아닌 RPC 프록시 컴퓨터에서 볼 수 있고 이해할 수 있는 형태로 지정해야 합니다. 클라이언트는 서버에 직접 연결하지 않으므로 서버 이름을 resolve 연결하거나 연결할 필요가 없습니다. RPC 프록시는 클라이언트를 대신하여 연결을 설정하므로 rpc_server RPC 프록시에서 인식할 수 있는 이름이어야 합니다.

  • 엔드포인트 는 RPC 서버 프로세스가 원격 프로시저 호출을 위해 수신 대기하는 TCP/IP 포트를 지정합니다. 자세한 내용은 엔드포인트 찾기를 참조하세요.

  • HttpProxy 는 필요에 따라 RPC 클라이언트 네트워크의 HTTP 프록시 서버(예: Microsoft 프록시 서버)를 지정합니다. 프록시 서버를 선택하면 포트 번호가 지정되지 않고, SSL이 요청되지 않은 경우 RPC 스텁은 기본적으로 포트 80을 사용하고, SSL이 지정된 경우 포트 443을 사용합니다.

  • RpcProxy는 RPC 서버의 프록시 역할을 하는 IIS 컴퓨터의 주소 및 포트 번호를 지정합니다. RPC 서버 프로세스가 RPC 프록시와 다른 컴퓨터에 있는 경우에만 이를 지정하면 됩니다. 포트 번호를 지정하지 않으면 기본적으로 RPC 클라이언트 스텁은 SSL이 지정되지 않은 경우 포트 80을 사용하고 SSL(HTTPS)이 지정된 경우 포트 443을 사용합니다.

  • HttpConnectionOption 은 필요에 따라 HTTP 연결을 만들 때 RPC의 동작을 지시할 수 있습니다. UseHttpProxy 값은 클라이언트가 인터넷 Explorer "로컬 주소에 대한 프록시 서버 무시"로 설정된 인터넷 옵션이 있는 경우를 포함하여 항상 Http 프록시를 통해 트래픽을 라우팅하도록 RPC에 지시합니다.

    이 옵션은 KB2916915가 설치된 Windows 7, Windows Server 2008 R2, Windows 8.1 및 Windows Server 2012 R2에서 지원됩니다. 이 옵션은 Windows 8 및 Windows Server 2012 지원되지 않습니다. 애플리케이션은 다음 레지스트리 키 아래에 있는 ConnectionOptionsFlag 레지스트리 값을 확인하여 RPC 런타임에서 이 옵션을 지원하는지 확인할 수 있습니다.

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc

    이 레지스트리 값의 비트 0(LSB)이 설정된 경우 이 특정 옵션이 지원됩니다. 그렇지 않으면 이 옵션은 시스템의 RPC 런타임에서 지원되지 않습니다.

문자열 바인딩을 만드는 방법에 대한 자세한 내용은 바인딩 및 핸들을 참조하세요.

RPC 서버 프로그램은 ncacn_http 프로토콜 시퀀스에서 수신 대기하여 터널링된 RPC 호출을 수락할 수 있습니다.

Microsoft에는 HTTP를 통한 RPC의 두 가지 주요 구현인 버전 1 및 버전 2가 있습니다.

버전 1(HTTP v1을 통한 RPC라고 함)은 Windows XP를 통해 지원됩니다. RPC 프록시 버전 1은 Windows 2000을 통해 지원됩니다.

버전 2(HTTP v2를 통한 RPC라고 함)는 현재 버전입니다.

두 버전에는 서로 다른 기능과 제한된 상호 운용성이 있습니다. 차이점에 대한 요약은 여기에 제공됩니다. 상호 운용성 고려 사항은 HTTP를 통한 RPC에 대한 시스템 요구 사항 및 상호 운용성을 참조하세요.

  • HTTP v1을 통한 RPC를 사용하려면 HTTP 클라이언트를 통한 RPC와 RPC 프록시 간의 모든 HTTP 프록시/방화벽에서 SSL 터널링을 사용하도록 설정해야 합니다. HTTP v1을 통한 RPC는 전송하는 데이터가 실제로 SSL 암호화되지 않더라도 포트 80을 통해 SSL 터널을 빌드하려고 시도합니다. 프록시 및 방화벽은 일반적으로 허용하도록 명시적으로 구성하지 않는 한 이러한 요청을 거부합니다. HTTP v2를 통한 RPC에는 이러한 요구 사항이 없습니다.
  • HTTP v1을 통한 RPC는 RPC 프록시에 대한 SSL 세션을 설정할 수 없습니다. HTTP v2를 통한 RPC는 SSL 세션 내에서 HTTP 트래픽을 통해 모든 RPC를 보낼 수 있습니다. 기본적으로 v2는 SSL 세션 내에서 데이터를 보내야 합니다.
  • HTTP v1을 통한 RPC는 RPC 프록시에 인증할 수 없습니다. HTTP v2를 통한 RPC는 인증할 수 있습니다. 기본적으로 v2에는 RPC 프록시에 대한 인증이 필요합니다.
  • RPC 프록시 v1이 설치된 IIS 컴퓨터가 웹 팜의 일부인 경우 제대로 작동하지 않습니다. RPC 프록시 v2는 설치된 IIS 컴퓨터가 웹 팜의 일부인 경우 제대로 작동합니다.

참고

Microsoft 인터넷 Explorer 클라이언트 프로그램의 컴퓨터에 설치되어 있고 클라이언트가 문자열 바인딩에 HttpProxy를 지정하지 않으면 RPC 클라이언트 스텁은 클라이언트 컴퓨터의 레지스트리에서 HttpProxy 항목을 검색합니다. 프록시를 찾으면 레지스트리 항목에 지정된 프록시를 사용합니다.

 

instance 경우 클라이언트 프로그램이 인터넷을 통해 Server7.microsoft.com 컴퓨터의 RPC 서버에 연결해야 한다고 가정합니다. 또한 RPC 프록시가 Major7.microsoft.com 실행한다고 가정해 보겠습니다. RPC 서버 프로그램은 포트 2225를 수신 대기합니다. 클라이언트는 문자열 바인딩을 사용합니다.

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

RPC 프록시가 정규화된 도메인 이름을 요구하지 않고 서버 이름을 Server7로 resolve 수 있는 경우 다음을 지정할 수도 있습니다.

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

클라이언트 네트워크에서 방화벽과 myproxy라는 인터넷 프록시 서버를 사용하고 클라이언트의 인터넷 Explorer 해당 프록시를 사용하도록 구성되지 않은 경우 클라이언트의 문자열 바인딩을 다음으로 수정해야 합니다.

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

이렇게 하면 클라이언트가 Server7.microsoft.com RPC 서버 프로그램에 연결하도록 지시합니다. 이를 위해 클라이언트는 먼저 포트 80(또는 SSL을 사용하는 경우 포트 443)을 사용하여 myproxy에 연결합니다. 이렇게 하면 클라이언트 프로그램에 인터넷에 대한 액세스 권한이 부여됩니다. 클라이언트 프로그램은 인터넷을 사용하여 Major7.microsoft.com RPC 프록시에 연결합니다. RPC 프록시는 Server7.microsoft.com 실행되는 RPC 서버 프로그램에 대한 연결을 설정합니다.

클라이언트 네트워크에서 방화벽을 사용하고 RPC 프록시에 직접 연결할 수 없는 경우 연결을 더 빠르게 설정하기 위해 클라이언트 문자열 바인딩을 다음으로 수정할 수 있습니다.

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

HttpConnectionOption을 사용하면 HTTP 연결을 만들 때 RPC의 동작을 지시할 수 있습니다. UseHttpProxy 값은 클라이언트가 인터넷 Explorer "로컬 주소에 대한 프록시 서버 무시"로 설정된 인터넷 옵션이 있는 경우를 포함하여 항상 Http 프록시를 통해 트래픽을 라우팅하도록 RPC에 지시합니다. 이렇게 하면 클라이언트가 Http 프록시를 통해 RPC 프록시에 강제로 연결합니다. 이렇게 하면 HTTP 프록시를 사용하기 직전에 RPC 서버 검색 지연을 무시하므로 연결 설정 시간이 단축됩니다.

HttpConnectionOption 옵션을 사용하고 클라이언트의 인터넷 Explorer 해당 Http 프록시를 사용하도록 구성되지 않은 경우 RPC_S_INVALID_NETWORK_OPTIONS 연결이 실패할 수 있습니다.

오늘날 대부분의 컴퓨터는 웹 검색을 위해 구성됩니다. 따라서 대부분의 클라이언트는 인터넷 연결 설정에서 검색되므로 HttpProxy를 지정할 필요가 없습니다.