8장. 통합점: 게이트웨이, 터널, 릴레이

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

8.1. 게이트웨이

웹이 발전함에 따라 복잡한 리소스를 올려야 하는 일이 많아짐 

👉 모든 리소스를 한 개의 애플리케이션으로 처리하는 것이 불가능해짐

👉 리소스를 받기 위한 경로를 안내하는 게이트웨이가 만들어짐

 

게이트웨이

1. 리소스와 애플리케이션을 연결 (애플리케이션은 게이트웨이에게 요청을 처리해달라고 할 수 있고 게이트웨이는 그에 응답할 수 있음)
2. 동적인 컨텐츠를 생성하거나 DB에 질의를 보낼 수 있음
3. HTTP 트래픽을 다른 프로토콜로 자동 변환해 HTTP 클라이언트가 서버에 접속할 수 있게 해줌

8.1.1. 클라이언트 측 게이트웨이와 서버 측 게이트웨이

웹 게이트웨이는 한쪽에서는 HTTP로 통신하고 다른 한쪽에서는 다른 프로토콜로 통신

게이트웨이는 클라이언트 측 프로토콜과 서버 측 프로토콜을 빗금(/)으로 구분해 기술

<클라이언트 프로토콜>/<서버 프로토콜> 

서버 측 게이트웨이는 클라이언트와 HTTP로 통신하고, 서버와는 외래 프로토콜로 통신

클라이언트 측 게이트웨이는 클라이언트와 외래 프로토콜로 통신하고, 서버와는 HTTP로 통신

8.2. 프로토콜 게이트웨이

게이트웨이에 HTTP 트래픽을 바로 전송할 수 있다.

👉 브라우저에 명시적으로 게이트웨이를 설정해 트래픽이 게이트웨이를 거쳐 가게 하거나, 게이트웨이를 대리 서버(리버스 프락시)로 설정할 수도 있다

설정 예

1. 브라우저에서 gw1.joes-hardware.com을 HTTP/FTP 게이트웨이로 설정
2. 브라우저는 FTP 서버에 FTP 명령을 보내는 대신, HTTP/FTP 게이트웨이인 gw1.joes-hardware.com의 8080포트에 HTTP 명령을 보냄

브라우저 동작 과정

1. 브라우저는 일반 HTTP 트래픽은 원 서버로 전송
2. FTP URL을 포함한 요청은 gw1.joes-hardware.com 게이트웨이로 HTTP 요청 보냄
3. 게이트웨이는 클라이언트 측의 요청을 FTP 요청으로 변환해 처리한 뒤 결과는 클라이언트에게 HTTP로 전송

8.2.1. HTTP/*: 서버 측 게이트웨이

서버 측 웹 게이트웨이는 클라이언트로부터 HTTP 요청이 원 서버로 들어오면 클라이언트 측의 HTTP 요청을 외래 프로토콜로 전환

 

게이트웨이가 하는 일

1. USER와 PASS 명령을 보내 서버에 로그인
2. 서버에서 적절한 디렉터리로 변경하기 위해 CWD 명령 내림
3. 다운로드 형식을 ASCII로 설정
4. MDTM으로 문서의 최근 수정 시간 가져옴
5. PASV로 서버에게 수동형 데이터 검색 하겠다고 말함
6. RETR로 객체 검색 (RETR: FTP 프로토콜에 정의된 명령어, 읽어오다/검색하다 라는 뜻을 가짐, 클라이언트가 서버에게 파일 전송 요청할 때 사용)
7. 제어 채널에서 반환된 포트로 FTP 서버에 데이터 커넥션을 맺음, 데이터 채널이 열리는 대로 객체가 게이트웨이로 전송

8.2.2. HTTP/HTTPS: 서버 측 보안 게이트웨이

게이트웨이는 일반 클라이언트의 HTTP 요청을 사내망과 같은 환경에서 모두 암호화하여 개인정보 보호와 보안을 제공하는 역할을 수행할 수 있다

8.2.3. HTTPS/HTTP: 클라이언트 측 보안 가속 게이트웨이

HTTPS/HTTP 게이트웨이는 보안 가속기임

HTTPS/HTTP 게이트웨이는 웹 서버의 앞단에 위치해 보이지 않는 인터셉트 게이트웨이나 대리 서버 역할을 함

보안 HTTPS 트래픽을 받아 복호화하고, 웹 서버로 보낼 일반 HTTP 요청을 만듬

원 서버보다 효율적으로 보안 트래픽을 복호화하는 암호화 하드웨어를 내장해 원 서버의 부하를 줄여줌

But, 게이트웨이와 원 서버 간의 암호화하지 않은 트래픽을 전송하기에 게이트웨이와 원 서버 간 네트워크가 안전한지 확인해야 함

8.3. 리소스 게이트웨이

일반적인 형태의 애플리케이션 서버는 목적지 서버와 게이트웨이를 한 개의 서버로 결합

애플리케이션 서버는 HTTP를 통해 클라이언트와 통신하고 서버 측 애플리케이션 프로그램에 연결하는 서버 측 게이트웨이임

 

연결 예시

1. 클라이언트는 HTTP를 사용해 애플리케이션 서버와 연결
2. 애플리케이션 서버는 게이트웨이의 애플리케이션 프로그래밍 인터페이스(API)를 통해 요청을 서버에서 동작하는 애플리케이션에 전달

애플리케이션 케이트웨이의 최초 API는 공용 게이트웨이 인터페이스(GCI)였음

GCI: 웹 서버가 사용하는 표준화된 인터페이스 집합

GCI의 역할

1. 특정 URL에 대한 HTTP 요청에 따라 프로그램 실행
2. 프로그램 출력 수집
3. HTTP 응답으로 회신

서버 게이트웨이 애플리케이션 동작 과정

1. 리소스 요청 들어오면 서버는 헬퍼 애플리케이션을 생성해 요청 처리
2. 헬퍼 애플리케이션은 필요 데이터를 전달받음
3. 헬퍼 애플리케이션은 클라이언트로 전달할 응답이나 응답 데이터를 서버에 반환

8.3.1. 공용 게이트웨이 프로세스

공용 게이트웨이 인터페이스(CGI)는 최초의 서버 확장이자 지금까지도 가장 널리 쓰이는 서버 확장임.

👉 웹에서 동적인 HTML, 신용카드 처리, DB 질의 등을 제공하는 데 사용

CGI 애플리케이션은 서버와 분리되며 수많은 언어로 구현할 수 있게 됨, 거의 모든 HTTP 서버가 지원함

CGI가 내부에서 동작하는 과정은 사용자가 볼 수 없음

CGI는 거의 모든 리소스 형식과 서버의 접점에 있으며 필요에 따라 어떤 변형이든 처리해내는 단순한 기능 제공

인터페이스는 문제가 많은 확장으로부터 서버를 보호한다는 점에서 훌륭하다고 할 수 있지만 분리로 인해 성능 비용 발생

👉 모든 CGI 요청마다 새로운 프로세스 만드는 데 부하가 생기고, CGI를 사용하는 서버 성능을 제한해 서버 장비에 부담을 줌

❗️ 이러한 문제를 피하기 위해 Fast CGI가 개발됨, Fast CGI는 데몬으로 동작함으로써 성능 저하 문제 해결

 

8.3.2. 서버 확장 API

CGI 프로토콜은 서버 자체의 동작을 바꾸거나 서버의 처리능력을 최고치로 끌어올려주지는 못함

👉 서버 개발자는 웹 개발자가 자신의 모듈을 HTTP와 직접 연결할 수 있는 서버 확장 API를 제공

확장 API는 프로그래머가 자신의 코드를 서버에 연결하거나 서버의 컴포넌트를 자신이 만든 것으로 교체할 수 있게 함

대부분의 서버는 개발자에게 확장 API를 한 개 이상 제공

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

데이터를 교환하는 두 애플리케이션 사이에서 프로토콜 인터페이스를 맞추는 것은 까다로운 일

애플리케이션이 상호 운용 하다보면 HTTP 헤더로는 표현하기 힘든 정보를 교환하게 됨

👉 HTTP 확장 예 등은 다른장에서 다룸

인터넷 커뮤니티는 각 웹 애플리케이션이 서로 통신하는데 사용할 표준과 프로토콜 집합을 개발

👉 이러한 표준은 웹 서비스로 불림

 

웹 서비스

1. 애플리케이션이 정보를 공유하는데 사용하는 새로운 매커니즘
2. SOAP(Simple Object Access Protocol)를 통해 XML(eXtensible Markup Language)을 사용해 정보 교환
3. XML은 데이터 객체를 담는 데이터를 생성하고 해석하는 방식을 제공
4. SOAP은 HTTP 메시지에 XML 데이터를 담는 방식에 관한 표준

8.5. 터널

웹 터널: HTTP 프로토콜을 지원하지 않는 애플리케이션에 HTTP 애플리케이션을 사용해 접근하는 방법 제공

웹 터널을 사용하면 HTTP 커넥션을 통해 HTTP가 아닌 트래픽을 전송하고, 다른 프로토콜을 HTTP 위에 올릴 수 있음

(터널은 클라이언트와 게이트웨이 사이에 놓임)

8.5.1. CONNECT로 HTTP 터널 커넥션 맺기

웹 터널은 HTTP의 CONNECT 메서드를 사용해 커넥션 맺음

CONNECT 메서드 👉 터널 게이트웨이가 임의의 목적 서버와 포트에 TCP 커넥션을 맺고 클라이언트와 서버 간에 오는 데이터를 무조건 전달하기를 요청

CONNECT 메서드가 게이트웨이로 터널 연결하는 과정

1. 클라이언트는 터널을 연결하기 위해 게이트웨이에 CONNECT 요청, 클라이언트의 CONNECT 메서드는 TCP 커넥션을 위해 게이트웨이에 터널 연결 요청
2. 클라이언트와 서버 사이에 TCP 커네션이 생성됨
3. 게이트웨이는 클라이언트에게 HTTP 200 Connection Established 응답 전송
4. 이 시점에 터널 연결. HTTP 터널 통해 전송된 클라이언트의 모든 데이터는 위에서 맺은 TCP 커넥션으로 전달되고, 서버로부터 전송된 데이터들도 HTTP 터널 통해 클라이언트에게 전달됨

CONNECT 요청

CONNECT 메서드는 시작줄 제외 다른 HTTP 메서드와 같음. 요청 URI는 호스트 명이 대신하며 클론에 이어 포트를 기술

CONNECT home.netscape.com:443 HTTP/1.0
User-agent: Mozilla/4.0

시작줄 다음에는 추가적인 HTTP 요청 헤더 필드가 있거나 없음. 각 행은 CRLF로 끝나고 헤더 목록의 끝은 빈 줄의 CRLF로 끝남

 

CONNECT 응답

HTTP/1.0 200 Connection Established
Proxy-agent: Netscape-Proxy/1.1

커넥션이 메시지를 전달하는 대신 바이트를 그대로 전달하기 때문에 컨텐츠의 형식을 기술하는 Content-Type 헤더를 포함할 필요는 없음.

8.5.2. 데이터 터널링, 시간, 커넥션 관리

터널을 통해 전달되는 데이터는 게이트웨이에서 볼 수 없기에 게이트웨이는 패킷의 순서나 흐름을 알 수 없다.

클라이언트는 성능 향상 위해 CONNECT 요청 후에 응답 받기 전에 터널 데이터 전송할 수 있음

👉 게이트웨이가 데이터를 적절하게 처리할 줄 알아야 함

게이트웨이는 커넥션이 맺어지는 대로 헤더를 포함해 읽어들인 모든 데이터를 서버에 전송해야 함

터널의 끝단 어느 부분이든 커넥션이 끊어지면, 그 곳으로부터 온 데이터는 반대편으로 전달됨.

그 다음 반대편 커넥션도 프락시에 의해 끊어짐. 커넥션이 끊긴 쪽에 아직 전송하지 않은 데이터는 버려짐

8.5.3. SSL 터널링

웹 터널을 사용하면 SSL 트래픽을 HTTP 커넥션으로 전송해 80 포트의 HTTP만을 허용한느 방화벽을 통과시킬 수 있음

SSL 트래픽이 기존 프락시 방화벽을 통과할 수 있도록 HTTP에 터널링 기능 추가됨

👉 HTTP 메시지에 암호화된 데이터를 담고 일반 HTTP 채널 통해 데이터 전송

터널링된 SSL 커넥션에서는 SSL 트래픽은 일반 SSL 커넥션을 통해 전송되기 전까지는 HTTP 메시지에 담겨 HTTP 포트인 80에 전송된다 (터널은 443 포트에 전송해야 할 SSL 트래픽을 기존 HTTP 커넥션을 통해 전송)

터널은 HTTP 가 아닌 트래픽이 포트를 제한하는 방화벽을 통과할 수 있게 해줌

8.5.4. SSL 터널링 VS HTTP/HTTPS 게이트웨이

HTTPS 프로토콜은 다른 프로토콜과 같은 방식으로 게이트웨이를 통과할 수 있음

👉 원격 HTTPS 서버와 SSL 세션을 시작하는 게이트웨이를 두고 클라이언트 측의 HTTPS 트랜잭션을 수행하는 방식

응답은 프락시가 받아서 복호화한 후에 HTTP를 통해 클라이언트로 전송

 

해당 방식의 단점

1. 클라이언트-게이트웨이 사이에 보안이 적용되지 않은 일반 HTTP 커넥션이 맺어져 있음
2. 프락시가 인증을 담당하고 잇어 클라이언트는 원격 서버에 SSL 클라이언트 인증(X509 인증서 기반의 인증)을 할 수 없음
3. 게이트웨이는 SSL을 완벽히 지원해야 함

SSL 세션은 클라이언트가 생성한 요청과 목적지(보안이 적용된) 웹 서버 간에 생성됨.

프락시 서버는 트랜잭션의 보안에는 관여하지 않고 암호화된 데이터를 그대로 터널링함

8.5.5. 터널 인증

HTTP의 다른 기능들은 터널과 함께 사용될 수 있음

특히 프락시 인증 기능은 클라이언트가 터널을 사용할 수 있는 권한을 검사하는 용도로 터널에서 사용할 수 있음

8.5.6. 터널 보안에 대한 고려사항들

터널 게이트웨이는 통신하고 있는 프로토콜이 터널을 올바른 용도로 사용하고 있는지 검증할 방법이 없음

터널의 오용을 막기 위해, 게이트웨이는 HTTPS 전용 포트인 443 같은 특정 포트만 터널링할 수 있게 허용해야 함

8.6. 릴레이

HTTP 릴레이는 HTTP 명세를 완전히 준수하지는 않는 간단한 HTTP 프락시

커넥션을 맺기 위한 HTTP 통신을 한 다음, 바이트를 무조건 전달

맹목적 릴레이의 문제점: 맹목적 릴레이는 Connection 헤더를 이해하지 못하기 때문에 keep-alive 커넥션이 행(hang)에 걸리게 된다

👉 클라이언트와 서버는 keep-alive로 통신하고 있다고 믿지만 릴레이는 keep-alive를 모르기 때문에 원 서버가 보내는 데이터를 모두 클라이언트에게 그대로 전달하고 커넥션이 끊기기를 기다린다. 하지만 원 서버는 릴레이가 커넥션을 계속 맺는 것에 동의했다고 생각하기에 커넥션을 계속 맺게(hang) 된다. 클라이언트는 다음 요청을 keep-alive 커넥션을 통해 릴레이에게 전달하는데 릴레이는 같은 커넥션으로 다른 요청이 오는 것을 예측하지 못한다. 따라서 브라우저는 계속 돌아가지만 아무런 작업도 진행되지 않는다