HTTP 완벽 가이드 8장. 통합점_게이트웨이, 터널, 릴레이

0. 들어가기

게이트웨이: 서로 다른 프로토콜과 애플리케이션 간의 HTTP 인터페이스다.
애플리케이션 인터페이스: 서로 다른 형식의 웹 애플리케이션이 통신하는 데 사용한다.
터널: HTTP 커넥션을 통해서 HTTP가 아닌 트래픽을 전송하는 데 사용한다.
릴레이: 일종의 단순한 HTTP 프락시로, 한 번에 한 개의 홉에 데이터를 전달하는 데 사용한다.

8.1 게이트웨이

리소스와 애플리케이션을 연결하는 역할을 한다.
- 애플리케이션은 게이트웨이에게 요청을 처리해달라고 할 수 있고(HTTP 혹은 그 밖의 정의해 둔 인터페이스를 통해), 게이트웨이는 그에 응답할 수 있다.

게이트웨이는 요청을 받고 응답을 보내는 포털 같이 동작하는데, 동적인 콘텐츠를 생성하거나 데이터베이스에 질의를 보낼 수 있다.

// HTTP/FTP 서버 측 FTP 게이트웨이
HTTP 클라인트 <-> 게이트웨이 <-> FTP 서버
// HTTPS//HTTP 클라이언트 측 보안 게이트웨이
HTTPS 클라인트 <-> 게이트웨이 <-> 웹 서버
// HTTP/CGI 서버 측 애플리케이션 게이트웨이
HTTP 클라인트 <-> 웹 서버 <-> 프로그램  

클라이언트 측 게이트웨이와 서버 측 게이트웨이
- 게이트웨이는 클라이언트 측 프로토콜과 서버 측 프로토콜을 빗금(/)으로 구분해 기술한다.
  - <클라이언트 프로토콜="">/<서버 프로토콜="">
프로토콜 게이트웨이
- 프락시에 트래픽을 바로 보내는 것과 같이 게이트웨이에도 HTTP 트래픽을 바로 보낼 수 있다.
- HTTP/*: 서버 측 웹 게이트웨이
  - 서버 측 웹 게이트웨이는 클라이언트로부터 HTTP 요청이 원 서버 영역으로 들어오는 시점에 클라이언트 측의 HTTP 요청을 외래 프로토콜로 전환한다.
  - HTTP/FTP 게이트웨이 역할
    - USER와 PASS 명령을 보내서 서버에 로그인
    - 서버에서 적절한 디렉터리로 변경하기 위해 CWD 명령을 내린다.
    - 다운로드 형식을 ASCII로 설정한다.
    - MDTM으로 문서의 최근 수정 시간을 가져온다.
    - PASV로 서버에게 수동형 데이터 검색을 하겠다고 말한다.
    - RETR로 객체를 검색한다.
    - 제어 채널에서 반환된 포트로 FTP 서버에 데이터 커넥션을 맺는다. 데이터 채널이 열리는 대로, 객체가 게이트웨이로 전송
- HTTP/HTTPS: 서버 측 보안 게이트웨이
  - HTTP 클라이언트의 요청을 게이트웨이는 자동으로 사용자의 모든 세션을 암호화하여 보안 웹서버에게 전달한다.
  - HTTP 클라이언트 <-> HTTP/HTTPS 인바운드 보안 게이트웨이 <-> 보안 웹 서버
- HTTPS/HTTP: 클라이언트 측 보안 가속 게이트웨이
  - 해당 게이트웨이는 보안 HTTPS 트래픽을 받아서 복호화하고, 웹 서버로 보낼 일반 HTTP 요청을 만든다.
  - 브라우저(SSL(HTTPS)를 통한 HTTP) <-> HTTPS/HTTP 보안 가속 게이트웨이 <-> 웹 서버

8.3 리소스 게이트웨이

게이트웨이의 가장 일반적인 형태인 애플리케이션 서버는 목적지 서버와 게이트웨이를 한 개의 서버로 결합한다.
애플리케이션 서버는 HTTP를 통해서 클라이언트와 통신하고 서버 측에 있는 애플리케이션 프로그램에 연결하는 서버 측 게이트웨이다.
CGI (공용 게이트웨이 인터페이스)
- 최초의 서버 확장이자 지금까지도 가장 널리쓰이는 서버 확장이다.
- 이는 웹에서 동적인 HTML, 신용카드 처리, DB 질의 등을 제공하는 데 사용
- 초기에는 매 CGI요청마다 프로세스를 생성하기 때문에 부하가 컸지만 어느 정도 기술이 발전하면서 이런 성능 저하는 해결되었다.
서버 확장 API
- 모듈을 HTTP와 직접 연결할 수 있는 강력한 인터페이스인 서버 확장 API를 제공
- 확장 API는 프로그래머가 자신의 코드를 서버에 연결하거나 서버의 컴포넌트를 자신이 만든 것으로 교체할 수 있게 하였다.
- FPSE(FrontPage Server Extension)
  - 프론트 페이지 클라이언트로부터 전송되는 원격 프로시져 호출 명령(Remote Procedure Call, RPC)을 인식할 수 있다.
  - 이 명령은 HTTP에 편승하여 온다.

8.4 애플리케이션 인터페이스와 웹 서비스

SOAP(Simple Object Access Protocol)
- 데이터를 교환할 때 두 어플리케이션의 프로토콜 인터페이스를 맞추는 것은 까다로운 이슈였다.
- HTTP 메시지 포맷으로는 제약이 있었기 때문이다.
- 여기서 HTTP 헤더에 XML을 사용하여 정보 교환을 하는 방식을 표준으로 삼았고 이를 SOAP(Simple Object Access Protocol)이라 한다.

8.5 터널

웹 터널은 HTTP 프로토콜을 지원하지 않는 애플리케이션에 HTTP 애플리케이션을 사용해 접근하는 방법을 제공
CONNECT로 HTTP 터널 커넥션 맺기
- 웹 터널은 HTTP의 CONNECT 메서드를 사용해 커넥션을 맺는다.
- CONNECT 메서드를 활용한 게이트웨이와 터널 연결하는 방법
  - 클라이언트는 게이트웨이여 터널을 연결하려고 CONNECT 요청을 보낸다.
  - TCP 커넥션은 게이트웨이 -> 웹 서버에 커넥션 요청으로 연결을 맺는다.
  - TCP 커넥션이 맺어지면 게이트웨이는 클라이언트에게 HTTP/1.0 200 Connection Established 응답 전송
  - 터널이 연결된다. HTTP 터널을 통해 전송된 클라이언트의 모든 데이터는 TCP 커넥션을 통해 웹 서버에 전달된다.
- CONNECT 요청
```
CONNECT home.netscape.com:443 HTTP/1.0
User-Agent: Mozilla/4.0
```
- CONNECT 응답
  - 클라이언트는 요청을 전송한 다음, 게이트웨이의 응답을 기다린다.
    HTTP/1.0 200 Connection Established Proxy-agent: Netscape-Proxy/1.2
데이터 터럴링, 시간, 커넥션 관리
- 터널을 통해 전달되는 데이터는 게이트웨이에서 볼 수 없어서, 게이트웨이는 패킷의 순서나 흐름에 대한 어떤 가정도 할 수 없다.
- 게이트웨이는 커넥션이 맺어지는 대로 헤더를 포함해서 읽어들인 모든 데이터를 서버에 전송해야 한다.
- 터널의 어느 부분이든 커넥션이 끊어지면, 그 곳으로부터 온 데이터는 반대편으로 전달되고, 그 다음 커넥션이 끊어졌던 터널의 끝단 반대편의 커넥션도 프락시에 의해서 끊어진다.
SSL 터널링
- 웹 터널은 방화벽을 통해서 암호화된 SSL 트래픽을 전달하려고 개발되었다.
- SSL 트래픽을 HTTP 커넥션으로 전송하여 80포트의 HTTP만을 허용하는 방화벽을 통과 시킨다.
SSL 터널링 vs HTTP/HTTPS 게이트웨이
- HTTPS 프로토콜은 다른 프로토콜과 같은 방식으로 게이트웨이를 통과할 수 있다.
- 게이트웨이가 FTP를 처리하는 방식과 같다.
- 단점
  - 클라이언트-게이트웨이 사이에는 보안이 적용되지 않은 일반 HTTP 커넥션이 맺어져 있다.
  - 프락시가 인증을 담당하고 있기 때문에, 클라이언트는 원격 서버에 SSL 클라이언트 인증을 할 수 없다.
  - 게이트웨이는 SSL을 완벽히 지원해야 한다.
터널 인증
- HTTP의 다른 기능들은 터널과 함께 적절히 사용할 수 있다.
- 프락시 인증 기능은, 클라이언트가 터널을 사용할 수 있는 권한을 검사하는 용도로 터널에서 사용할 수 있다.
터널 보안에 대한 고려 사항
- 터널 게이트웨이는 통신하고 있는 프로토콜이 터널을 올바른 용도로 사용하고 있는지 검증할 방법이 없다.
- 터널의 오용을 최소화하기 위해서, 게이트웨이는 HTTPS 전용 포트인 443같이 잘 알려진 특정 포트만을 터널링할 수 있게 허용해야 한다.

8.6 릴레이

HTTP 명세를 완전히 준수하지 않는 간단한 HTTP 프락시다.
커넥션을 맺기 위한 HTTP 통신을 한 다음, 바이트를 전달한다.
릴레이는 Connection 헤더를 제대로 처리하지 못해서 keep-alive 커넥션이 행(hang)에 걸리는 문제점이 생긴다.
- 웹 클라이언트는 Connection: Keep-Alive 헤더를 보내서, 릴레이에 커넥션을 맺기를 원한다는 내용의 요청 메시지를 전송한다.
- 릴레이가 HTTP 요청을 받지만, Connection 헤더를 이해하지 못하므로 요청을 서버로 넘긴다.
- 웹 서버가 프락시로부터 Connection: Keep-Alive헤더를 받으면, 릴레이가 keep-alive를 하기 바란다고 잘못된 결론을 내려버린다.
  - 이 시점부터 웹 서버는 릴레이와 함께 keep-alive 통신을 하고, keep-alive의 규칙에 맞게 동작할 것이다.
- 릴레이는 웹 서버로부터 받은 Connection: Keep-Alive 헤더를 포함한 응답 메시지를 클라이언트에게 전달한다.
  - 클라이언트와 서버는 keep-alive로 통신한다고 믿고 있지만, 실제로 통신하는 릴레이는 keep-alive가 무엇인지도 모른다.
- 원서버는 릴레이가 자신에게 커넥셔능ㄹ 계속 맺고 있기를 요청했다고 믿기 때문에 커넥션을 끊지 않을것이다.
  - 따라서 릴레이는 커넥션이 끊길 때를 기다리며 계속 커넥션을 맺고(hang) 있을 것이다.
- 클라이언트가 응답 메시지를 받으면, 바로 다음 요청을 keep-alive 커넥션을 통해 릴레이에게 전송한다. 브라우저는 계속 돌고 있지만, 아무런 작업도 진행되지 않는다.

** 참고 서적: HTTP 완벽 가이드