Chapter 8. Integration Points: Gateways, Tunnels, and Relays
(해석 또는 이해가 잘못된 부분이 있다면 댓글로 편하게 알려주세요.)
✏️ 원문 번역
Preface
The Web has proven to be an incredible tool for disseminating content. Over time, people have moved from just wanting to put static documents online to wanting to share ever more complex resources, such as database content or dynamically generated HTML pages. HTTP applications, like web browsers, have provided users with a unified means of accessing content over the Internet.
-
웹은 콘텐츠를 배포하는 훌륭한 도구로 입증되었습니다.
-
시간이 흐름에 따라 사람들은 단순히 정적인 문서를 온라인상에 배포하는 것을 넘어 데이터베이스 콘텐츠나 동적으로 생성되는 HTML 페이지 등 더 복잡한 리소스를 공유하기를 원하기 시작했습니다.
-
웹 브라우저와 같은 HTTP 응용 프로그램은 사용자가 인터넷을 통해 콘텐츠를 접근할 수 있는 통합된 수단을 제공하고 있습니다.
HTTP also has come to be a fundamental building block for application developers, who piggyback other protocols on top of HTTP (for example, using HTTP to tunnel or relay other protocol traffic through corporate firewalls, by wrapping that traffic in HTTP). HTTP is used as a protocol for all of the Web’s resources, and it’s also a protocol that other applications and application protocols make use of to get their jobs done.
-
HTTP는 HTTP 위에 무언가를 얹어야 하는 응용 프로그램 개발자의 기본 소양이 되었습니다.
-
가령 이들은 기업의 방화벽을 통과한 다른 프로토콜의 트래픽을 터널링하거나 중계하기 위해 해당 트래픽을 HTTP로 감싸는 등의 작업을 수행할 것입니다.
-
HTTP는 모든 웹 리소스를 위한 프로토콜입니다.
-
동시에 다른 응용 프로그램과 프로토콜이 그들의 작업을 완수하기 위해 사용하는 프로토콜이기도 합니다.
This chapter takes a general look at some of the methods that developers have come up with for using HTTP to access different resources and examines how developers use HTTP as a framework for enabling other protocols and application communication.
-
이 챕터에서는 개발자가 HTTP를 사용하여 다양한 리소스에 접근하기 위해 사용할 만한 일반적인 방법론을 살펴봅니다.
-
그리고 개발자가 다른 프로토콜 및 응용 프로그램과 통신하기 위한 프레임워크로써 HTTP를 사용하는 방법을 살펴봅니다.
In this chapter, we discuss:
• Gateways, which interface HTTP with other protocols and applications
• Application interfaces, which allow different types of web applications to communicate with one another
• Tunnels, which let you send non-HTTP traffic over HTTP connections
• Relays, which are a type of simplified HTTP proxy used to forward data one hop at a time
- 구체적으로는 다음의 내용을 다룹니다.
- Gateways(게이트웨이) : HTTP를 다른 프로토콜 및 응용 프로그램과 연결하는 인터페이스
- Application Interface(앱 인터페이스) : 한 유형의 웹 응용 프로그램이 다른 유형의 웹 응용 프로그램과 통신할 수 있게 하는 매개체
- Tunnels(터널) : HTTP 연결을 통해 non-HTTP 트래픽을 전송할 수 있게 하는 장치
- Relays(릴레이) : 데이터를 한 번에 한 hop만큼 전송하는 데 사용되는 간소화된 HTTP 프록시
Gateways
The history behind HTTP extensions and interfaces was driven by people’s needs. When the desire to put more complicated resources on the Web emerged, it rapidly became clear that no single application could handle all imaginable resources.
-
HTTP 확장판과 인터페이스는 사람들의 필요에 의해 등장하였습니다.
-
웹상에 더 복잡한 리소스를 게시하고자 하는 욕구가 생겨나면서, 하나의 웹 응용 프로그램만으로는 모든 리소스를 제어할 수 없다는 사실이 분명해지게 되었습니다.
To get around this problem, developers came up with the notion of a gateway that could serve as a sort of interpreter, abstracting a way to get at the resource. A gateway is the glue between resources and applications. An application can ask (through HTTP or some other defined interface) a gateway to handle the request, and the gateway can provide a response. The gateway can speak the query language to the database or generate the dynamic content, acting like a portal: a request goes in, and a response comes out.
-
문제를 해결하기 위해 개발자들은 일종의 번역기 역할을 하는 게이트웨이의 개념을 고안하여 리소스에 접근하는 방법을 추상화 하였습니다.
-
게이트웨이는 리소스와 응용 프로그램을 이어 붙이는 역할을 수행합니다.
-
응용 프로그램이 HTTP나 다른 인터페이스를 통해 게이트웨이에게 요청을 처리하도록 요청하면 게이트웨이가 응답을 제공할 수 있습니다.
-
게이트웨이는 데이터베이스에 쿼리를 전달하거나 동적 콘텐츠를 생성하여 하나의 포털처럼 동작할 수도 있습니다. 요청이 들어가고 응답이 나오는 방식입니다.
Figure 8-1 depicts a kind of resource gateway. Here, the Joe’s Hardware server is acting as a gateway to database content—note that the client is simply asking for a resource through HTTP, and the Joe’s Hardware server is interfacing with a gateway to get at the resource.
-
Figure 8-1은 리소스 게이트웨이의 한 유형을 나타냅니다.
-
아래 예시에서 Joe's Hardware 서버는 데이터베이스 콘텐츠에 대한 게이트웨이처럼 동작하고 있습니다.
-
클라이언트는 HTTP를 통해 리소스를 요청하였고 Joe's Hardware 서버가 게이트웨이를 인터페이스 하여 리소스를 가져오고 있다는 점에 주목합니다.
Some gateways automatically translate HTTP traffic to other protocols, so HTTP clients can interface with other applications without the clients needing to know other protocols (Figure 8-2).
-
어떤 게이트웨이는 HTTP 트래픽을 자동으로 다른 프로토콜로 전환합니다.
-
따라서 HTTP 클라이언트는 다른 프로토콜을 알지 못해도 다른 응용 프로그램과 인터페이스 할 수 있습니다. (Figure 8-2)
Figure 8-2 shows three examples of gateways:
• In Figure 8-2a, the gateway receives HTTP requests for FTP URLs. The gateway then opens FTP connections and issues the appropriate commands to the FTP server. The document is sent back through HTTP, along with the correct HTTP headers.
• In Figure 8-2b, the gateway receives an encrypted web request through SSL, decrypts the request,* and forwards a normal HTTP request to the destination server. These security accelerators can be placed directly in front of web servers(usually in the same premises) to provide high-performance encryption for origin servers.
• In Figure 8-2c, the gateway connects HTTP clients to server-side application programs, through an application server gateway API. When you purchase from e-commerce stores on the Web, check the weather forecast, or get stock quotes, you are visiting application server gateways.
Figure 8-2는 게이트웨이의 세 가지 예시를 나타냅니다.
-
Figure 8-2a에서 게이트웨이는 FTP URL에 대한 HTTP 요청을 받습니다. 게이트웨이는 FTP 연결을 열어 FTP 서버에 적절한 명령을 실행합니다. 문서는 적절한 HTTP 헤더와 함께 HTTP로 클라이언트에 되돌아갑니다.
-
Figure 8-2b에서 게이트웨이는 SSL을 통해 암호화된 웹 요청을 받아 그것을 해석하고 일반적인 HTTP 요청으로 Destination Server에 전달합니다. 이러한 보안 가속기는 웹 서버 바로 앞에 위치하여 원본 서버에 수준 높은 암호화를 제공할 수 있습니다.
-
Figure 8-2c에서 게이트웨이는 애플리케이션 서버 게이트웨이 API를 통해 HTTP 클라이언트를 서버 사이드 응용 프로그램에 연결합니다. 웹에서 이커머스로 무언가를 구매하거나 기상 예보를 확인할 때, 혹은 주가를 조회할 때 애플리케이션 서버 게이트웨이를 방문하게 됩니다.
Client-Side and Server-Side Gateways
Web gateways speak HTTP on one side and a different protocol on the other side. Gateways are described by their client- and server-side protocols, separated by a slash:
<client-protocol>/<server-protocol>
-
웹 게이트웨이의 경우 한쪽은 HTTP로, 한쪽은 다른 프로토콜로 이야기합니다.
-
따라서 Client-Side와 Server-Side 프로토콜을 슬래시 단위로 나누어 게이트웨이를 표현할 수 있습니다.
So a gateway joining HTTP clients to NNTP news servers is an HTTP/NNTP gateway. We use the terms “server-side gateway” and “client-side gateway” to describe what side of the gateway the conversion is done for:
• Server-side gateways speak HTTP with clients and a foreign protocol with servers (HTTP/*).
• Client-side gateways speak foreign protocols with clients and HTTP with servers(*/HTTP).
-
HTTP 클라이언트가 NNTP 뉴스 서버에 접속하기 위한 게이트웨이는 HTTP/NNTP 게이트웨이입니다.
-
"Server-Side 게이트웨이", "Client-Side 게이트웨이"라는 용어는 게이트웨이의 어느 쪽 사이드에서 변환이 이루어지는지를 나타냅니다.
-
즉 Server-Side 게이트웨이(HTTP/*)는 HTTP 클라이언트와 다른 프로토콜을 사용하는 서버를 나타냅니다.
-
반대로 Client-Side 게이트웨이(*/HTTP)는 다른 프로토콜을 사용하는 클라이언트와 HTTP를 사용하는 서버를 나타냅니다.
✏️ 요약
HTTP as Framework for Other Protocols
- Gateway(게이트웨이) : HTTP를 다른 프로토콜이나 응용 프로그램과 연결하는 인터페이스
- Tunnels(터널) : HTTP 연결을 통해 non-HTTP 트래픽을 전송하는 장치
- Relays(릴레이) : 데이터를 한 번에 한 hop만큼 전송하는 장치
Gateway Examples
[1] HTTP/FTP Gateway
- 클라이언트가 HTTP를 통해 요청 전송
- 게이트웨이가 FTP 연결을 열어 적절한 명령을 실행한 후 HTTP 문서 반환
[2] HTTPS/HTTP Gateway
- 클라이언트가 HTTPS를 통해 암호화된 요청 전송
- 게이트웨이가 요청을 복호화하여 원본 서버에 전달
[3] HTTP/CGI Gateway
- 클라이언트가 HTTP를 통해 요청 전송
- 게이트웨이가 클라이언트를 응용 프로그램에 연결
✏️ 감상
CGI, Common Gateway Interface
오늘 읽은 내용 중에 유독 Figure 8-2c 부분이 잘 와닿지 않았다. 이유는 간단하다. 내가 CGI가 무엇인지 잘 몰라서 그랬다. 이참에 부족한 개념을 보충한다 생각하고 인터넷에서 CGI에 대해 이것저것 찾아보았다.
CGI는 Common Gateway Interface의 약자다. 한마디로 서로 다른 응용 프로그램이 소통하기 위해 보편적으로 사용할 수 있는 매개체라는 뜻이다. 책에서도 언급되었듯이 동적으로 변화하는 콘텐츠에 대한 니즈가 증가하면서 자연스럽게 CGI의 필요성 또한 대두되었다. CGI를 통해 HTTP 서버와 다른 응용 프로그램 사이에서 정보를 주고받을 수 있다면, 사용자가 요청한 데이터를 응용 프로그램에서 가공한 후 동적으로 콘텐츠를 생성하여 반환할 수 있기 때문이다.
예를 들어 HTTP 서버가 CGI 게이트웨이를 통해 요청을 보내면, CGI 프로그램이 데이터베이스에 쿼리를 요청하여 결과를 받아올 수 있다. 이렇게 생성된 결과는 HTTP 서버가 돌려받아서 클라이언트에 전달한다. 동적인 콘텐츠를 제공할 수 있게 된 것이다.
그럼 CGI랑 WAS의 차이점은 뭘까
그 다음에 나는 이런 의문이 들었다. 분명 CGI의 역할은 내가 스프링부트로 만든 서버와 비슷해 보였다. 그런데 스프링부트로 만든 서버는 WAS(Web Application Server)의 역할을 하는 것으로 알고 있다. 그럼 CGI와 WAS는 비슷한 개념일까?
결론부터 말하자면 당연히 CGI와 WAS는 다른 개념이다. 엄밀하게는 다른 개념이라기보다 WAS가 CGI의 발전된 형태라고 보는 것이 더 맞는 듯하다.
CGI 방식은 클라이언트가 요청을 전송할 때마다 독립적인 CGI 프로세스를 생성한다. 따라서 많은 수의 요청을 감당하기에 부하가 매우 크다는 단점이 있다. 이 문제를 해결하기 위해 등장한 것이 바로 확장 CGI다. 확장 CGI 방식은 단일 프로세스 내에서 스레드를 생성해 요청을 처리하므로 상대적으로 부하가 적다. Servlet이나 JSP가 가장 대표적인 확장 CGI라고 볼 수 있다.
웹 서버가 CGI라는 규약을 통해 응용 프로그램과 통신을 하는 것이 기존의 방식이었다면, WAS는 "웹 서버"와 응용 프로그램의 역할을 하는 "웹 컨테이너"를 모두 포함하고 있다. 즉 클라이언트가 요청을 보내면 웹 서버가 웹 컨테이너에 그것을 전달하고 동적으로 무언가를 처리한다. 결과는 다시 웹 서버로 전달되고 최종적으로 클라이언트에 도달한다. 스프링부트가 WAS처럼 동작한다고 이야기하는 이유는 내부적으로 Tomcat이라고 하는 WAS가 동작하고 있기 때문이다.
