Gateway
게이트웨이
웹의 발전으로 모든 리소스를 한개의 어플리케이션으로만으로는 처리할 수 없다 리소스를 받기 위한 경로를 안내하는 역할을 하는 게이트웨이를 고안했다 게이트웨이는 리소스와 어플리케이션을 연결하는 역할을 한
프로토콜 게이트웨이
프락시에 트래픽을 바로 보내는 것과 같이, 게이트웨이에도 http 트래픽을 바로 보낼 수 있다. 프로토콜을 변환하는 게이트웨이이다
(HTTP)CLIENT -> HTTP/FTP -> (FTP)SERVERHTTPS/HTTP() 보안 가속 게이트웨이
Server : 모든 웹 요청을 암호화하여 개인정보보호와 보안을 제공하는것에 게이트웨이를 사용할 수 있다.
게이트웨이가 자동으로 사용자의 모든 세션을 암호화할 것이다
Client : HTTPS/HTTP 게이트웨이는 보안 가속기로 유명하다.
이 게이트웨이는 보안 HTTPS 트래픽을 받아서 복호화하고, 웹서버로 보낼 일반 HTTP 요청을 만든다.
공용 게이트웨이 인터페이스
공용 게이트웨이 인터페이스 (CGI)
최초의 서버확장이고 지금까지도 가장 널리 쓰이는 서버 확장이다
CGI가 내부에서 어떤 처리를 하고 있는지는 사용자에게 보이지 않는다.
무언가를 하고 있다는 것을 아는 방법은 URL에 있는 cgi훅 뿐이다.
하지만 이런 분리때문에 성능관련 단점이 있다. 모든 CGI용어마다 새로운 프로세스를 만드는 부하가 꽤 크기 때문이다.
서버 확장 API
CGI 프로토콜은 구동중인 HTTP 서버에 외부 인터프리터가 쉽게 접속할 수 있게 해주지만, 서버 자체의 동작을 바꾸고 싶거나 서버의 처리능력을 최고치로 끌어올리지는 못한다. 그래서 서버 개발자는 웹개발자는 자신의 모듈을 HTTP와 직접 연결할 수 있는 강력한 인터페이스인 서버 확장 API를 만들었다.
유명한 서버들은 서버 확장 API를 하나씩 가지고 있고, 개발자가 서버의 동작을 변경하거나 다른 리소스에 대한 사용자 맞춤 인터페이스를 제공하는 데 쓸 수 있는 API를 가진다.
웹 어플리케이션이 더 많은 형식의 서비스를 제공함에 따라서, http는 어플리케이션을 연결하는 도구로 활용될 수 있다는게 확실해졌다
터널
웹 터널은 http 프로토콜을 지원하지 않는 어플리케이션에서 http 어플리케이션을 사용해 접근하는 방법을 제공한다 웹 터널을 사용하면 http 커넥션을 통해서 http가 아닌 트래픽을 전송할 수 있고, 일반적인 사용법으로는 http 커넥션 안에 http가 아닌 트래픽을 얹는 목적으로 사용된다
CONNECT로 HTTP 터널 커넥션 맺기
웹 터널은 http의 CONNECT 메서드를 사용하여 커넥션을 맺는다 CONNECT 메서드는 터널 게이트웨이가 임의의 목적 서버와 포트에 TCP 커넥션을 맺고, 클라이언트와 서버간에 오는 데이터를 무조건 전달하기를 요청함
데이터 터널링, 시간, 커넥션 관리
터널을 통해 전달되는 데이터는 게이트웨이에서 볼 수 없어서, 게이트웨이는 패킷의 순서나 흐름에 대한 어떤 가정도 못한다 또한 터널의 한쪽 끝단에서 데이터를 소비하지 않으면 터널의 다른 끝단의 데이터 생산자는 행에 걸리게 되고, 결국 교착상태가 일어날 수 있다. 게이트웨이는 커넥션이 맺어지는 대로 헤더를 포함해서 읽어들인 모든 데이터를 서버에 전송해야한다.
SSL 터널링
웹 터널은 원래 방화벽을 통해서 암호화된 SSL 트래픽을 전달하려고 개발되었다 원래는 많은 회사가 보안을 위해서 모든 트래픽이 패킷을 필터링하는 라우터와 프락시를 지나도록 했는데, ssl 같은 프로토콜은 낡은 방식의의 프락시에게 처리가안되어서 통과가 안되었다 터널링을 통해서 ssl 트래픽을 http만 허용하는 방식으로 통과하도록 변경
SSL 터널링 vs HTTP/HTTPS 게이트웨이
SSL 터널링을 사용하면, 프락시에 SSL을 구현할 필요가 없다. SSL세션은 클라이언트가 생성한 요청과 목적지(보안이 적용된) 웹 서버 간에 생성된다. 프락시 서버는 트랜잭션의 보안에는 관여하지 않고 암호화된 데이터를 그대로 터널링할 뿐이다
릴레이
http릴레이는 http명세를 완전히 준수하지는 않는 http 프락시이다. 커넥션을 맺기위에 http와 통신을 한 다음에 바이트를 맹목적으로 전달한다.
http는 복잡해서 맹목적으로 트래픽을 전달하는 간단한 프락시를 구현하는 방식이 유용할때가 있는데, 단순 필터링이나 진단, 컨텐츠변환을 하는데 쓰인다.
하지만 릴레이가 가지는 심각한 문제가 있는데, Connection 헤더를 제대로 처리하지 못해서 keep-alive 커넥션이 hang에 걸리는 것이다.
Connection: Keep-alive헤더를 그대로 보내버린다. 서버에서는 릴레이가 자신과 keep-alive 커넥션을 맺고 싶어하는것으로 간주하고 커넥션을 열어놓고, 확인응답을 보낸다.
릴레이는 확인응답을 클라이언트에게 전달해준다. 클라이언트는 다음요청을 보낸다. 하지만 릴레이는 서버가 커넥션을 끊어주지 않기 때문에 클라이언트의 다음요청을 받을 수 없다.
Last updated