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

8장은 여러종류의 리소스에 접근하는데에 http가 어떻게 사용되는지 알아본다.

알아야할 목표는 다음과 같다.

- 게이트웨이는 서로 다른 프로토콜과 어플리케이션 간의 http 인터페이스이다.

- 어플리케이션 인터페이스는 서로 다른 형식의 웹 어플리케이션이 통신하는 데 사용된다.

- 터널은 http 커넥션을 통해서 http가 아닌 트래픽을 전송하는데 사용된다.

- 릴레이는 일종의 단순한 http 프락시로, 한번에 한개의 홉에 데이터를 전달하는데 사용된다.

 

 

8.1 게이트웨이

웹의 발전으로 모든 리소스를 한개의 어플리케이션으로만으로는 처리할 수 없다고 판단함.

리소스를 받기 위한 경로를 안내하는 역할을 하는 게이트웨이를 고안함.

즉, 게이트웨이는 리소스와 어플리케이션을 연결하는 역할을 함.

 

위 그림처럼 http를 FTP로, HTTPS를 HTTP로, HTTP를 CGI로.. 프로토콜을 변환하는 역할도 한다.

 

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

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

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

 

이렇게 구별하는 이유는, 웹 게이트웨이는 한쪽은 http를 사용하고, 한쪽은 다른 프로토콜을 사용하기 때문이다.

 

8.2 프로토콜 게이트웨이

프락시에 트래픽을 바로 보내는 것과 같이, 게이트웨이에도 http 트래픽을 바로 보낼 수 있다.

말 그대로 프로토콜을 변환하는 게이트웨이임

 

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

서버 측 웹 게이트웨이는 클라이언트한테 http 요청이 서버로 들어올때 

클라이언트의 http 요청을 외래 프로토콜로 변환함.

 

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

기업 내부의 모든 웹 요청을 암호화하여 개인정보보호와 보안을 제공하는것에 게이트웨이를 사용할 수 있다.

게이트웨이가 자동으로 사용자의 모든 세션을 암호화할 것이다!

 

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

HTTPS/HTTP 게이트웨이는 보안 가속기로 유명하다.

이 게이트웨이는 보안 HTTPS 트래픽을 받아서 복호화하고, 웹서버로 보낼 일반 HTTP 요청을 만든다.

(http라서 게이트웨이와 서버간 네트워크가 안전해야함)

 

8.3 리소스 게이트웨이

게이트 웨이의 가장 일반적인 형태는 어플리케이션 서버를 구축하는 것이다.

어플리케이션 서버 = 목적지 서버 + 게이트웨이

 

위 그림에서는 2개의 클라이언트가 http를 사용하여, 어플리케이션 서버로 리소스를 쏜다.

어플리케이션 서버는 API를 통해서 서버에서 돌아가는 어플리케이션에 전달한다.

 

 

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

- 정의

공용 게이트웨이 인터페이스 (CGI)

: 최초의 서버확장이고 지금까지도 가장 널리 쓰이는 서버 확장이다

 

- CGI가 내부에서 어떤 처리를 하고 있는지는 사용자에게 보이지 않는다.

무언가를 하고 있다는 것을 아는 방법은 URL에 있는 cgi훅 뿐이다.

 

- CGI가 내부에서 어떤 처리를 하고 있는지는 사용자에게 보이지 않는거는 장단점이 있다

문제가 확장되는것을 서버까지 전달되기 전에 막을 수 있다.

외부에서 흘러들어온 문제가 서버까지 들어오게되면 서버가 뻗어버릴 수 있기 때문이다.

 

하지만 이런 분리때문에 성능관련 단점이 있다.

모든 CGI용어마다 새로운 프로세스를 만드는 부하가 꽤 크기 때문이다. (이거 때문에 Fast CGI라는것이 개발됨)

 

8.3.2 서버 확장 API

배경

CGI 프로토콜은 구동중인 HTTP 서버에 외부 인터프리터가 쉽게 접속할 수 있게 해주지만,

서버 자체의 동작을 바꾸고 싶거나 서버의 처리능력을 최고치로 끌어올리지는 못한다.

 

해결

그래서 서버 개발자는 웹개발자는 자신의 모듈을 HTTP와 직접 연결할 수 있는 강력한 인터페이스인 서버 확장 API를 만들었다.

 

유명한 서버들은 서버 확장 API를 하나씩 가지고 있고, 개발자가 서버의 동작을 변경하거나 다른 리소스에 대한 사용자 맞춤 인터페이스를 제공하는 데 쓸 수 있는 API를 가진다.

 

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

- 웹 어플리케이션이 더 많은 형식의 서비스를 제공함에 따라서, http는 어플리케이션을 연결하는 도구로 활용될 수 있다는게 확실해짐.

물론 어플리케이션을 연결하려고 하면, 데이터를 교환하려는 두 어플리케이션 사이에서 프로토콜 인터페이스를 맞추는게 까다롭긴함.

19장에서 자세히 다룬다.

 

8.5 터널

지금까지 여러 종류의 리소스에 게이트웨이를 접근하거나 어플리케이션 간에 통신하는데 http를 사용하는 여러가지 방법에 대해 알아봄

이제는 http 또 다른 방식인 웹터널에 대해 알아볼 것임

 

정의

웹 터널은 http 프로토콜을 지원하지 않는 어플리케이션에서 http 어플리케이션을 사용해 접근하는 방법을 제공함

 

웹 터널을 사용하면 http 커넥션을 통해서 http가 아닌 트래픽을 전송할 수 있고,

다른 프로토콜을 http 위에 올릴 수 있음

 

그래서 일반적인 사용법으로는 http 커넥션 안에 http가 아닌 트래픽을 얹는 목적으로 사용됨

 

8.5.1 CONNECT로 HTTP 터널 커넥션 맺기

웹 터널은 http의 CONNECT 메서드를 사용하여 커넥션을 맺음

 

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

a) 클라이언트는 게이트웨이에 터널을 연결하려고 CONNECT 요청을 보냄

b), c) TCP 커넥션 생성됨

d) http 200 Connection 으로 응답, (이때 터널연결)

이제 http 터널을 통해 전송됨 클라이언트의 모든 데이터들은 tcp 커넥션으로 바로 전달될 것이고,

서버로부터 전송된 모두 데이터 역시 http 터널을 통해서 클라이언트에게 전달될것

 

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

터널을 통해 전달되는 데이터는 게이트웨이에서 볼 수 없어서, 게이트웨이는 패킷의 순서나 흐름에 대한 어떤 가정도 못함

그래서 터널이 일단 연결되면 데이터는 언제 어디로는 흘러가버릴 수 있다.

 

또한 터널의 한쪽 끝단에서 데이터를 소비하지 않으면 터널의 다른 끝단의 데이터 생산자는 행에 걸리게 되고, 결국 교착상태가 일어날 수 있다.

 

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

 

8.5.3 SSL 터널링

웹 터널은 원래 방화벽을 통해서 암호화된 SSL 트래픽을 전달하려고 개발됨

 

원래는 많은 회사가 보안을 위해서 모든 트래픽이 패킷을 필터링하는 라우터와 프락시를 지나도록 했는데,

ssl 같은 프로토콜은 낡은 방식읭 프락시에게 처리가안되어서 통과가 안되었음

 

터널링을 통해서 ssl 트래픽을 http만 허용하는 방식으로 통과하도록 변경.

이게 ssl 터널링이라는 거임

 

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

SSL터널링은 http안에 ssl 넣어서 http 커넥션만으로 서버와 ssl 통신하는거고

http/https 게이트웨이는 프락시가 https를 이해할수 있어서 바로 연결되는것??

 

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

터널 게이트는 올바른 용도로 사용되고 있는지 검증할 방법이 없다.

그래서 443처럼 특정 포트만을 터널링할 수 있게 허용해야한다.

 

 

8.6 릴레이

http릴레이는 http명세를 완전히 준수하지는 않는 http 프락시이다.

커넥션을 맺기위에 http와 통신을 한 다음에 바이트를 맹목적으로 전달한다.

 

http는 복잡해서  맹목적으로 트래픽을 전달하는 간단한 프락시를 구현하는 방식이 유용할때가 있는데,

단순 필터링이나 진단, 컨텐츠변환을 하는데 쓰인다.

 

하지만 릴레이가 가지는 심각한 문제가 있는데,

Connection 헤더를 제대로 처리하지 못해서 keep-alive 커넥션이 hang에 걸리는 것이다.

 

즉, Connection: Keep-alive헤더를 그대로 보내버린다.

서버에서는 릴레이가 자신과 keep-alive 커넥션을 맺고 싶어하는것으로 간주하고 커넥션을 열어놓고, 확인응답을 보낸다.

릴레이는 확인응답을 클라이언트에게 전달해준다.

클라이언트는 다음요청을 보낸다.

하지만 릴레이는 서버가 커넥션을 끊어주지 않기 때문에 클라이언트의 다음요청을 받을 수 없다.

 

그래서 릴레이를 똑똑하게 만들자니 릴레이의 기본 역할을 벗어나는 행위를 하게될 수 있어서 다른 사이드이펙트가 발생할 수 있다.

그래서 릴레이를 사용할때에는 신중한 고민이 요구된다.