title: HTTP The Definitive Guide - 08. Integration Points: Gateways, Tunnels, and Relays
date: 2022-11-23
tags:
- Network
- HTTP
Introduction
GDSC에서 해당 서적을 통해 HTTP를 공부하는 스터디에 참가하고 있다.
HTTP 이전의 내용은 개인적으로 공부하며 채울 예정이다.
이번 Chapter는 08장 Integration Points: Gateways, Tunnels, and Relays 이다.
Purpose
Gateway와 Tunnel, Relay에 대해 학습한다.
Gateway
Web에서 더 복잡한 Resource를 이용하고자 하는 수요가 증가하였으며, 단일 Application으로 처리할 수 없는 수준이 되었다. 이 때문에 Gateway가 만들어졌다.
Gateway는 DB Query를 수행하거나 동적 Content 생성 등의 작업을 할 수 있다.
Client-Side and Server-Side Gateway
Gateway는 HTTP와 다른 Protocol을 이용할 수 있도록 한다.
Proxy에서 여러 HTTP Version을 사용할 수 있다는 점에서 Gateway라고 생각할 수 있으나, HTTP만 취급하기에 Proxy라고 구분할 수 있다.
Gateway에서 지원하는 Protocol은 <client-protocol>/<server-protocol> 방식으로 표현한다.
- Client-Side Gateway -
*/HTTP로, Server의 HTTP와 Client의 다른 Protocol을 중개한다. - Server-Side Gateway -
HTTP/*로, Client의 HTTP와 Server의 다른 Protocol을 중개한다.
Protocol Gateway
Proxy와 동일하게 설정 파일을 수정하여 Gateway를 명시하여 사용할 수 있다.
일반적으로 Gateway는 설정 파일에 명시하거나, Intercepting Proxy처럼 중간에 가로채거나, Surrogate로써 이용한다.
Server-Side Gateway
Server-Side Gateway는 Client의 HTTP Request를 Server의 Protocol에 맞게 변환하여 Server에 Request를 보낸다.
위 그림은 Client와 FTP Server가 통신할 때 Gateway의 동작을 간단히 나타낸 것이다.
Gateway와 Server의 통신이 끝나면 Gateway는 Client에 HTTP Response를 보낸다.
Server-Side Security Gateway
Gateway는 보안을 높이기 위해 사용하기도 한다.
위 그림에서 Client는 HTTP Request를 보내며, Gateway는 이를 암호화하여 Server에 보낸다.
Client-Side Security Accelerator Gateway
HTTPS의 발전으로 인하여 HTTPS/HTTP Gateway는 자주 사용되었다.
Intercepting Gateway나 Surrogate처럼 작동한다.
Client는 Gateway의 존재를 모르며, Gateway에서 복호화를 하여 Server에 HTTP Message를 보낸다.
이러한 Gateway는 복호화를 위해 사용하기에 Server에서 복호화를 하는 것보다 훨씬 빠르다.
물론 HTTPS Message가 HTTP Message로 변환되기에, Gateway에서 Server로 보내는 경로는 외부의 침입이 불가능한 안전한 Network에서 진행되어야 한다.
Resource Gateway
지금까지 본 Gateway는 Server의 앞에 있는 형태이나, 일반적으로는 Server와 Gateway를 합친 하나의 Application Server로 이용한다.
Application Server는 Server-Side Gateway와 결합이 되어 있으며, Gateway는 API의 형태로 동작한다.
최초의 Application Gateway API는 CGI (Common Gateway Interface)이다.
CGI는 특별한 URL에 대한 HTTP Request를 받아 Program을 실행하며, Program의 Output을 모아 Response로 보낸다.
서적을 집필할 당시 몇 년 동안은 상용 Web Server는 Server와 Application을 연결할 수 있는 정교한 Interface를 제공하였다.
위 그림은 Server와 Gateway를 결합할 때의 Mechanism이다.
Server는 Request를 받으며, Helper Application을 이용하여 Request를 처리한다.
처리 후 Response를 Server에 보내주며, Server는 다시 Client에 Response를 보낸다.
Application Interface and Web Service
CGI는 동적 HTML 생성, 신용 카드 처리, DB Query 등을 위해 주로 사용되었다.
CGI는 Server에 의존하지 않는 Application이기에 어떠한 언어를 사용하더라도 구현이 가능하였으며, 간단하기에 대부분의 HTTP Server가 이를 지원하였다.
유저는 CGI의 존재 여부를 알 수 없다. URI의 cgi 혹은 ?를 통해 CGI가 존재할 것으로 예측만 가능하다.
CGI 덕분에 Server에서는 복잡한 처리를 CGI로 대체하여 유지보수가 간편하였다.
또한 CGI가 없었다면 여러 Extension이 필요할 것이며, 이러한 Extension으로 인하여 문제가 생길 수 있었기에 이를 막아주기도 하였다.
CGI는 항상 좋은 것은 아니다.
별개의 Application이며 Helper Application 생성 등으로 인하여 Overhead가 발생한다.
이를 해결하기 위해 CGI와 유사한 Fast CGI가 개발되었다.
CGI와 유사하지만, 영구적인 Daemon을 이용하기에 새로운 Process를 할당하지 않아도 되기에 Overhead가 크게 줄어들었다.
Server Extension API
Server 자체의 동작이나 Server의 성능을 높이기 위해서는 CGI로는 해결할 수 없다.
이러한 이유로 Server 개발자들은 Server와 직접 통신할 수 있으며 성능이 좋은 Server Extension API를 제공한다.
Extension API를 이용하여 Server Code의 일부를 변경하거나 추가하여 개발자들의 Code로 대체할 수 있다.
주로 사용하는 대부분의 Server는 이러한 Extension API를 제공한다.
이를 이용하여 더욱 유연한 Server 개발이 가능하다.
현재는 거의 사용하지 않지만, 서적 집필 당시 높은 점유율을 보이던 Microsoft의 FPSE (FrontPage Server Extension)는 FrontPage 작성을 위한 Service를 지원한다.
FPSE는 Client가 보낸 RPC (Remote Procedure Call)을 해석할 수 있다.
FPSE에 대한 부분은 Chapter 19에서 자세히 다룬다.
Application Interface and Web Service
Resource Gateway를 이용하면 Server와 Application간의 통신을 해결할 수 있으며, Application이 다양한 Service를 제공함에 따라 Resource Gateway는 하나의 기반이 되고 있다.
다만, Application간의 Protocol Interface를 협상하여 사용하는 부분은 까다롭다.
Application간의 데이터 교환을 위해 HTTP Header에 추가적인 정보가 들어가야 하며, 이를 위해 HTTP Protocol을 확장하는 여러 방식은 Chapter 19에서 자세히 다룬다.
Service는 SOAP (Simple Object Access Protocol)를 통해 XML (Extensible Markup Language)을 이용하여 정보를 교환한다.
XML은 Resource에 대한 정보를 만들거나 해석하는 방법을 알려준다.
SOAP는 이러한 XML 정보를 HTTP Message에 넣기 위한 표준이다.
Tunnel
지금까지는 HTTP Message와 관련된 것들에 대해 다루었다.
HTTP Application에서 HTTP가 아닌 방식으로도 통신이 가능하며, 이를 Web Tunnel이라 한다.
Tunnel을 이용하면 HTTP Connection을 이용하여 Non-HTTP Traffic을 전송할 수 있다. 이때 Piggyback 또한 가능하다.
일반적으로 Tunnel을 사용하는 이유는 Web Traffic만 허용하는 Firewall을 통해 Non-HTTP Traffic을 보낼 수 있기 때문이다.
Establishing HTTP Tunnel with CONNECT
CONNECT Method를 이용하면 TCP Connection을 맺을 수 있다.
CONNECT Method의 Request는 다른 Method의 HTTP Message와 큰 차이는 없다.
다만, Start Line에 명시하는 URI의 경우 Hostname과 Port를 명시한다.
Connection이 맺어지면 Response로 Status Code 200을 받는다.
Reason Phrase에도 일반적으로 Connection Established라는 문구가 포함된다.
Connection만 맺기에 다른 Method와는 다르게 Content-Type Header가 없다.
Data Tunneling
Gateway는 Tunnel 내부의 데이터를 확인할 수 없다.
Tunnel이 생성되면 양방향에서 언제든 데이터를 보낼 수 있으며, Data의 Dependency가 존재할 수 있기에 한쪽에서 보낸 데이터는 바로 처리해야 한다.
데이터를 바로 처리하지 않고 놔둘 경우, 송신 측에서 문제가 발생하여 Deadlock으로 이어질 수 있다.
성능 문제로 인하여 CONNECT Request를 보낸 후, Response를 받기 전에 Tunnel이 생성되었다고 가정하고 데이터를 전송할 수 있다.
또한 Tunnel이 존재할 수 있기에 Gateway에서는 언제나 Network I/O 발생 시 Header 데이터만 들어온다고 가정해서는 안 되며, Connection이 맺어지면 바로 데이터를 전달해야 한다.
인증 문제나 Tunnel이 생성되지 않았다는 Response를 받을 수 있으며, 이러한 이유로 인해 Request를 다시 보낼 준비가 되어있어야 한다.
데이터 전송 도중 한쪽에서 Connection이 끊어지면 해당 데이터를 전송한 후 Proxy에 의해 Connection이 끊어진다.
양쪽에서 Connection이 끊어진 순간 전달되지 않은 데이터는 사라진다.
SSL Tunneling
Tunnel이 처음 개발된 이유는 SSL Traffic 때문이다.
암호화된 Message이기에 Proxy가 이를 해석하지 못하며, Firewall을 통과하지 못하였다.
Tunnel을 이용하면 Proxy의 해석 없이 Firewall을 통과할 수 있다.
(a)는 Client와 Server 사이에 SSL Connection만 맺는 것이다.
(b)는 HTTP Connection에 Tunnel을 설치하여 암호화된 데이터를 보낸 후, 이를 SSL Connection을 이용하여 Server에 보내는 것이다.
물론 Tunnel이 늘 안전한 것은 아니다. 데이터를 검사할 수 없기에 악의적인 무언가가 Tunnel을 이용하여 전송되는 것을 막을 수 없다.
SSL Tunneling vs HTTP/HTTPS Gateway
HTTPS는 HTTP에 SSL Session을 얹어 보안을 더 챙기는 Protocol이라고 볼 수 있다. Gateway가 FTP를 다루는 방식과 동일하다.
Client는 Gateway에 HTTP Message를 보내며, Gateway는 이를 암호화하여 HTTPS Transaction을 실시한다.
Client와 Gateway 사이는 안전하지 않은 HTTP를 이용하고, Proxy가 인증을 담당하기에 Client는 Server와 SSL 인증을 진행할 수 없으며, Gateway가 SSL을 완전하게 지원해야 하는 문제가 발생한다.
SSL Tunneling은 Proxy에 추가적인 기능을 구현하도록 요구하지 않는다.
Client와 Server 사이에 SSL Tunnel을 설치하며, Proxy는 이를 중개만 한다.
서적을 집필할 당시는 HTTPS가 표준이 아니었으며, 아마 위의 문제들을 해결하였기에 HTTPS가 널리 보급이 된 것으로 추측한다.
Tunnel Authentication
Tunnel을 설치할 때 인증 절차를 추가하여 안전한 Connection을 맺을 수 있다.
Tunnel Security
Gateway는 CONNECT Method로 받은 것이 실제로 Tunneling 해야 하는 Protocol인지 알 수 없다.
유저가 악의적으로 Tunnel을 설치하면 Server에 문제가 발생할 수 있다.
이러한 문제를 최소화하기 위해서 Gateway는 HTTPS 전용 Port인 443과 같이 잘 알려진 Port에 대한 Tunneling만 허용해야 한다.
Relay
Chapter 04에서 Dumb Proxy에서 발생하는 Blind Relay를 확인하였다.
Relay라는 개념이 드디어 등장하며, HTTP 사양을 완전히 만족하지 않는 간단한 Proxy이다.
HTTP가 복잡하기에 Traffic을 그냥 전달하는 간단한 Proxy를 구현하여 이용할 수 있으며, 이때 Blind Relay 문제가 발생할 수 있는 것이다.
Conclusion
Gateway는 단순 Protocol을 변환하는 작업뿐만 아니라, Server의 복잡한 작업을 일부 덜어주기도 한다.
Server라고 생각하였지만 실제로는 Gateway가 동작하는 부분도 존재할 것이다.
서적의 초기에 Tunnel을 가볍게 다루었는데, 그때는 이를 왜 이용하는지 이해를 못 하였다.
당시 Tunnel에 대해 자세한 설명이 있었다면 Proxy의 동작을 잘 모르기에 여전히 이해하지 못하였을 가능성이 높으며, 책을 다시 보지 않는 한 Tunnel을 제대로 이해하지 못하고 넘어갔을 것이다.
Relay에 대해서는 Blind Relay 위주로 설명하였는데, 차라리 Chapter 04에서 설명을 하고 해당 Chapter에서는 Gateway와 Tunnel만 다루는 것이 더 낫다고 본다.
'Network' 카테고리의 다른 글
| HTTP The Definitive Guide - 10. HTTP-NG (0) | 2022.12.01 |
|---|---|
| HTTP The Definitive Guide - 09. Web Robots (0) | 2022.11.30 |
| HTTP The Definitive Guide - 07. Caching (0) | 2022.11.22 |
| HTTP The Definitive Guide - 06. Proxies (0) | 2022.11.18 |
| HTTP The Definitive Guide - 05. Web Servers (0) | 2022.11.10 |