Chapter 8. Integration Points: Gateways, Tunnels, and Relays
(해석 또는 이해가 잘못된 부분이 있다면 댓글로 편하게 알려주세요.)
✏️ 원문 번역
Application Interfaces and Web Services
We’ve discussed resource gateways as ways for web servers to communicate with applications. More generally, with web applications providing ever more types of services, it becomes clear that HTTP can be part of a foundation for linking together applications. One of the trickier issues in wiring up applications is negotiating the protocol interface between the two applications so that they can exchange data—often this is done on an application-by-application basis.
-
지금까지 웹 서버가 응용 프로그램과 통신하기 위해 사용되는 리소스 게이트웨이에 대해 알아보았습니다.
-
웹 애플리케이션이 점점 다양한 서비스를 제공하게 됨에 따라 HTTP가 응용 프로그램을 연결하는 기반이 될 수 있다는 사실이 분명해졌습니다
-
응용 프로그램을 연결할 때 까다로운 점 중 하나는 데이터 교환을 위해 두 응용 프로그램간 프로토콜 인터페이스를 합의해야 할 필요가 있다는 것입니다.
-
보통 이것은 응용 프로그램과 응용 프로그램 사이에서 이루어지는 경우가 많습니다.
To work together, applications usually need to exchange more complex information with one another than is expressible in HTTP headers. A couple of examples of extending HTTP or layering protocols on top of HTTP in order to exchange customized information are described in Chapter19. “FrontPage Server Extensions for Publishing Support” in Chapter19 talks about layering RPCs over HTTP POST messages, and “WebDAV and Collaborative Authoring” talks about adding XML to HTTP headers.
-
응용 프로그램은 함께 동작하기 위해 HTTP 헤더가 표현하는 정보보다 더 복잡한 정보들을 교환해야 합니다.
-
커스터마이징된 정보들을 교환하기 위해 확장 HTTP를 사용하거나 HTTP 위에 다른 프로토콜을 올리는 예시는 Chapter 19에서 설명합니다.
-
Chapter 19의 "FrontPage Server Extensions for Publishing Support"에서는 HTTP POST 메시지 위에 RPC를 올려 통신하는 방식을 소개합니다.
-
또한 "WebDAV and Collaborative Authoring" 섹션에서는 HTTP 헤더에 XML을 추가한 형태를 소개합니다.
The Internet community has developed a set of standards and protocols that allow web applications to talk to each other. These standards are loosely referred to as web services, although the term can mean standalone web applications (building blocks) themselves. The premise of web services is not new, but they are a new mechanism for applications to share information. Web services are built on standard web technologies, such as HTTP.
-
인터넷 사회는 웹 응용 프로그램간 통신을 허용하는 표준과 프로토콜 셋을 정의하였습니다.
-
이러한 표준을 느슨하게는 웹 서비스라고 부릅니다. 하지만 어떤 독립적인 웹 응용 프로그램(Building Block) 자체를 의미하기도 합니다.
-
웹 서비스라는 전제는 전혀 새로운 것이 아니지만 응용 프로그램이 정보를 공유하는 새로운 매커니즘입니다.
-
웹 서비스는 HTTP와 같은 표준 웹 기술을 기반으로 구축됩니다.
Web services exchange information using XML over SOAP. The Extensible Markup Language (XML) provides a way to create and interpret customized information about a data object. The Simple Object Access Protocol (SOAP) is a standard for adding XML information to HTTP messages.
-
웹 서비스는 SOAP 위에서 XML을 사용하여 정보를 주고받습니다.
-
Extensible Markup Language(XML)은 데이터 오브젝트에 대해 커스터마이징된 정보들을 생산하고 해석하는 수단을 제공합니다.
-
Simple Object Access Protocol(SOAP)는 HTTP 메시지에 XML 정보를 추가하기 위한 표준입니다.
Tunnels
We’ve discussed different ways that HTTP can be used to enable access to various kinds of resources (through gateways) and to enable application-to-application communication. In this section, we’ll take a look at another use of HTTP, web tunnels, which enable access to applications that speak non-HTTP protocols through HTTP applications.
-
앞서 HTTP 게이트웨이를 통해 다양한 종류의 리소스에 접근하고 응용 프로그램간 서로 통신하기 위한 여러 가지 방법에 대해 이야기했습니다.
-
이번 섹션에서는 HTTP의 또다른 용도인 웹 터널(Web Tunnel)에 대해 설명합니다.
-
웹 터널은 HTTP 응용 프로그램을 통해 non-HTTP 프로토콜을 사용하는 응용 프로그램에 접근할 수 있게 합니다.
Web tunnels let you send non-HTTP traffic through HTTP connections, allowing other protocols to piggyback on top of HTTP. The most common reason to use web tunnels is to embed non-HTTP traffic inside an HTTP connection, so it can be sent through firewalls that allow only web traffic.
-
웹 터널은 HTTP 연결을 통해 non-HTTP 트래픽을 전달할 수 있게 합니다.
-
HTTP 위에 다른 프로토콜을 piggybacking 하는 것입니다.
** piggybacking : 내용을 덧붙여서 전송 -
웹 터널을 사용하는 가장 흔한 이유는 non-HTTP 트래픽을 HTTP 연결 안에 임베딩하여 오직 웹 트래픽만을 허용하는 방화벽을 통과하기 위함입니다.
Establishing HTTP Tunnels with CONNECT
Web tunnels are established using HTTP’s CONNECT method. The CONNECT protocol is not part of the core HTTP/1.1 specification,† but it is a widely implemented extension. Technical specifications can be found in Ari Luotonen’s expired Internet draft specification, “Tunneling TCP based protocols through Web proxy servers,” or in his bookWeb Proxy Servers, both of which are cited at the end of this chapter.
-
웹 터널은 HTTP의 CONNECT 메서드를 사용하여 설정됩니다.
-
CONNECT 프로토콜은 HTTP/1.1 명세의 핵심 요소가 아니지만, 보편적으로 구현되어 있는 확장 프로토콜입니다.
-
기술적인 명세는 Ari Luotonen의 인터넷 초안에 대한 명세인 "Tunneling TCP based protocols through Web proxy servers"나 그의 저서인 "Proxy servers"를 통해 확인할 수 있습니다.
-
두 가지 모두 이번 챕터의 마지막 부분에서 인용하고 있습니다.
The CONNECT method asks a tunnel gateway to create a TCP connection to an arbitrary destination server and port and to blindly relay subsequent data between client and server.
- CONNECT 메서드는 임의의 목적 서버와 포트에 대한 TCP 연결을 생성하고 클라이언트와 서버 사이에서 데이터를 그대로(별도의 처리없이) 중계하도록 터널 게이트웨이에 요청합니다.
Figure8-10 shows how the CONNECT method works to establish a tunnel to a gateway:
• In Figure8-10a, the client sends a CONNECT request to the tunnel gateway. The client’s CONNECT method asks the tunnel gateway to open a TCP conection (here, to the host named orders.joes-hardware.com on port 443, the normal SSL port).
• The TCP connection is created in Figure8-10b and Figure8-10c.
• Once the TCP connection is established, the gateway notifies the client (Figure8-10d) by sending an HTTP 200 Connection Established response.
• At this point, the tunnel is set up. Any data sent by the client over the HTTP tunnel will be relayed directly to the outgoing TCP connection, and any data sent by the server will be relayed to the client over the HTTP tunnel.
-
Figure 8-10은 CONNECT 메서드가 게이트웨이에 터널을 생성하는 방식을 나타냅니다.
-
Figure 8-10a에서 클라이언트는 CONNECT 요청을 터널 게이트웨이에 전송합니다. 클라이언트의 CONNECT 메서드는 터널 게이트웨이에게 TCP 연결을 열 것을 요청합니다. 예제의 경우 호스트의 이름은 orders.joes-hardware.com이고, 포트 번호는 일반적인 SSL 포트인 443입니다.
-
Figure 8-10b와 Figure 8-10c에서 TCP 연결이 생성됩니다.
-
TCP 연결 설정이 완료되면 게이트웨이는 클라이언트에게 HTTP 200 Connection Established 응답을 전송하여 알립니다. (Figure 8-10d)
-
이때 터널이 설정됩니다. 클라이언트가 HTTP 터널에 흘려보내는 모든 데이터는 그대로 발신 TCP 연결에 중계됩니다. 서버가 전달하는 모든 데이터도 HTTP 터널을 따라 클라이언트에게 중계될 것입니다.
The example in Figure8-10 describes an SSL tunnel, where SSL traffic is sent over an HTTP connection, but the CONNECT method can be used to establish a TCP connection to any server using any protocol.
-
Figure 8-10의 예시는 SSL 트래픽을 HTTP 연결 위로 전달하기 위한 SSL 터널을 나타낸 것입니다.
-
물론 CONNECT 메서드는 어떤 프로토콜을 사용하는 서버든 TCP 연결을 설정하는 데 사용될 수 있습니다.
✏️ 요약
Web Services
- 웹 응용 프로그램간 통신을 허용하는 표준 및 프로토콜 셋
- 독립적인 웹 응용 프로그램(Building Block)
- HTTP와 같은 표준 웹 기술 기반으로 구축
- SOAP 위에서 XML을 사용하여 정보를 주고받는 방식 사용 <- 지금은 잘 안 쓰는 방식
- SOAP : Simple Object Access Protocol, HTTP 메시지에 XML 정보를 추가하기 위한 표준
- XML : Extensible Markup Language
Tunnels
: HTTP 연결을 통해 non-HTTP 트래픽을 piggybacking 하여 전달할 수 있게 하는 수단
- 웹 트래픽만을 허용하는 방화벽을 통과할 수 있음
- 확장된 HTTP 메서드 CONNECT를 게이트웨이에 전달하여 설정(서버로부터 200 Connection Established 응답이 돌아오는 시점에 터널 생성)
- 서버가 어떤 프로토콜이든 상관없이 CONNECT로 TCP 연결 설정 가능
