[HTTP 완벽 가이드] 8장 : 통합점-게이트웨이, 터널, 릴레이

8.1 게이트웨이

• 게이트웨이는 웹에 더 복잡한 리소스를 올려야 할 필요가 생기면서, 모든 리소스를 한 개의 애플리케이션으로만 처리할 수 없다는 문제를 해결하기 위해 생겨났다.
• 게이트웨이는 리소스를 받기위한 경로를 연결하는 연결을 한다
• 웹 게이트웨이의 세 가지 예
  1. HTTP/FTP 서버 측 FTP 게이트웨이
  2. HTTPS/HTTP 클라이언트 측 보안 게이트웨이
  3. HTTP/CGI 서버 특 애플리케이션 게이트웨이

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

• 웹 게이트웨이의 표시 : <클라이언트 프로토콜>/<서버 프로토콜>
• 서버 측 게이트웨이는 클라이언트와 HTTP로 통신하고, 서버와는 외래 프로토콜로 통신한다
• 클라이언트 측 게이트웨이는 클라이언트와 외래 프로토콜로 통신하고, 서버와는 HTTP로 통신한다

8.2 프로토콜 게이트웨이

 

 

→ 브라우저는 일반 HTTP 트래픽은 원 서버로 바로 보낸다. 하지만 FTP URL을 포함한 요청은 gw1.joes-hardware.com 게이트웨이로 HTTP요청을 보낸다. 게이트웨이는 클라이언트 측의 요청을 FTP 요청으로 변환하여 처리한 뒤 클라이언트에게 그 결과를 HTTP 로 전송한다

 

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

1. USER와 PASS 명령을 보내서 서버에 로그인한다
2. 서버에서 적절한 디렉터리로 변경하기 위해 CWD 명령을 내린다
3. 다운로드 형식을 ASCII로 설정한다
4. MDTM으로 문서의 최근 시간을 가져온다
5. PASV로 서버에게 수동형 데이터 검색을 하겠다고 말한다
6. RETR로 객체를 검색한다
7. 제어 채널에서 반환된 포트로 FTP서버에 데이터 커넥션을 맺는다. 데이터 채널이 열리는 대로, 객체가 게이트웨이로 전송된다

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

→ 클라이언트는 일반 HTTP를 사용하여 웹을 탐색할 수 있지만, 게이트웨이는 자동으로 사용자의 모든 세션을 암호화할 것이다

 

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

• 이 게이트웨이는 보안 HTTPS 트래픽을 받아서 복호화하고, 웹 서버로 보낼 일반 HTTP 요청을 만든다
• 게이트웨이와 원 서버 간의 암호화하지 않은 트래픽을 전송하기 때문에, 게이트웨이와 원 서버 간에 있는 네트워크가 안전한지 확인을 확실히 하고 사용해야 한다

8.3 리소스 게이트웨이

• 애플리케이션 서버는 HTTP를 통해서 클라이언트와 통신하고 서버 측에 있는 애플리케이션 프로그램에 연결하는 서버 측 게이트웨이다
• 두 개의 클라이언트가 HTTP를 사용하여 애플리케이션 서버로 연결하면 애플리케이션 서버는 게이트웨이의 API(Application Programming Interface)를 통해서 요청을 서버에서 동작하고 있는 애플리케이션에 전달한다.
• CGI(Common Gateway Interface) : 특정 URI에 대한 HTTP요청에 따라 프로그램을 실행하고, 프로그램의 출력을 수집하고, HTTP 응답으로 회신하는데 웹 서버가 사용하는 표준화된 인터페이스 집합
• 게이트웨이를 통해야 받을 수 있는 리소스 요청이 들어오면, 서버는 헬퍼 애플리케이션을 생성하여 요청을 처리한다. 요청 처리 후, 클라이언트로 전달할 응답이나 응답 데이터를 서버에 반환한다.

8.3.1 공용 게이트웨이 인터페이스

• CGI 애플리케이션이 서버와 분리되면서 펄(Perl), TcL, C, 다양한 셸 언어를 포함하여 수 많은 언어로 구현할 수 있게 되었다.
• 인터페이스는 문제가 많은 확장으로부터 서버를 보호한다. 문제가 있는 확장이 서버 자체에 들어가면, 에러를 발생시키고 서버를 뻗게 할 것이기 때문이다.

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

• 애플리케이션이 상호 운용응 하다 보면 HTTP 헤더로는 표현하기 힘든 복잡한 정보를 교환해야 할 수도 있다
• 웹 서비스는 애플리케이션이 정보를 공유하는 데 사용하는 새로운 메커니즘(표준과 프로토콜 집합)을 의미한다. 웹 서비스는 HTTP같은 표준 웹 기술 위에서 개발한다.
• 웹 서비사는 SOAP을 통해 XML을 사용하여 정보를 교환한다
  • XML : eXtensible Markup Language, 데이터 객체를 담는 데이터를 생성하고 해석하는 방식 제공
  • SOAP : Simple Object Access protocol , HTTP메시지에 XML데이터를 담는 방식에 관한 표준

8.5 터널

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

 

8.5.1 CONNECT로 HTTP 터널 커넥션 만들기

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

1. 클라이언트는 게이트웨이에 터널을 연결하려고 CONNECT 요청을 보낸다.
2. TCP 커넥션이 생성 완료되면, 게이트웨이는 클라이언트에 HTTP 200 Connection Established 응답을 전송한다.
3. 이 시점에 터널이 연결된다.
4. 이 시점부터 커넥션이 끊길 때까지 모든 데이터가 일방향으로 전달된다

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

• 클라이언트는 성능을 높이기 위해 CONNECT 요청을 보낸 다음, 응답을 받기 전에 터널 데이터를 전송할 수 있다.

8.5.3 SSL 터널링

• 터널을 사용하면 SSL 트래픽을 HTTP 커넥션으로 전송하여 80 포트의 HTTP 만을 허용하는 방화벽을 통과시킬 수 있다
• 터널링 기능은 HTTP 메시지에 암호화된 날 데이터를 담고 일반 HTTP 채널을 통해 데이터를 전송한다

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

• SSL 터널링을 사용하면, 프락시에 SSL을 구현할 필요가 없다. SSL세션은 클라이언트가 생성한 요청과 목적지(보안이 적용된) 웹 서버 간에 생성된다. 프락시 서버는 트랜잭션의 보안에는 관여하지 않고 암호화된 데이터를 그대로 터널링할 뿐이다

8.5.5 터널 인증

8.6 릴레이

• HTTP 릴레이는 HTTP명세를 준수하지 않는 간단한 HTTP프락시이다
• 릴레이 문제
  1. 웹 클라이언트는 Connection: Keep-Alive 헤더를 보내서 릴레이와 Keep-Alive 상태를 유지하기를 원한다
  2. 릴레이는 이해하지 못해 그대로 서버에 전달한다
  3. 서버는 릴레이가 릴레이와의 Keep-Alive 상태를 유지하기를 원한다고 생각한다
  4. 릴레이는 받은 Keep-Alive 를 그대로 클라이언트에 전달한다
  5. 클라이언트는 릴레이와 Keep-Alive 를 유지한다고 생각한다
  6. 클라이언트는 릴레이에게 다음 요청을 보낸다
  7. 릴레이는 서버와의 커넥션을 계속 유지하고 있으므로 커넥션이 닫히기만을 기다린다
  8. 브라우저는 계속 돌고 있지만, 아무런 작업도 진행되지 않는다