반응형
- 게이트웨이: 서로 다른 프로토콜과 애플리케이션 간의 HTTP 인터페이스
- 애플리케이션 인터페이스: 서로 다른 형식의 웹 어플리케이션이 통신하는데 사용
- 터널: HTTP 커넥션을 통하여 HTTP가 아닌 트래픽을 전송하는 데 사용
- 릴레이: 단순한 HTTP 프락시로, 한 번에 한 개의 홉에 데이터를 전달하는데 사용
8.1 게이트웨이
- 모든 리소스를 한 개의 애플리케이션으로만 처리할 수 없다는 것에 대한 해결책으로 게이트웨이가 고안됐다.
- 게이트웨이는 리소스와 애플리케이션을 연결하는 역할을 한다.
- 게이트웨이는 HTTP 트래픽을 다른 프로토콜로 자동으로 변환하여, HTTP 클라이언트가 다른 프로토콜을 알 필요 없이 서버에 접속할 수 있게 하기도 한다.
8.1.1 클라이언트 측 게이트웨이와 서버 측 게이트웨이
- 게이트웨이는 클라이언트 측 프로토콜과 서버 측 프로토콜을 빗금으로 구분해 기술한다.
- 서버 측 게이트웨이는 클라이언트와 HTTP 로 통신하고 서버와는 외래 프로토콜로 통신한다.
- 클라이언트 측 게이트웨이는 클라이언트와 외래 프로토콜로 통신하고, 서버와는 HTTP 로 통신한다.
8.2 프로토콜 게이트웨이
- 프락시에 트래픽을 바로 보내는 것처럼 게이트웨이에도 HTTP 트래픽을 바로 보낼 수 있다.
8.2.1 HTTP/* 서버 측 웹 게이트웨이
- 서버 측 웹 게이트웨이는 클라이언트로부터 HTTP 요청이 원 서버 영역으로 들어오는 시점에 클라이언트 측의 HTTP 요청을 외래 프로토콜로 전환한다.
- 게이트웨이는 객체를 받는 대로 HTTP 응답에 실어서 클라이언트에 전송한다.
8.2.2 HTTP/HTTPS 서버 측 보안 게이트웨이
- 기업 내부 웹 요청을 암호화함으로써 개인 정보 보호와 보안을 제공하는데 사용할 수 있다.
- 게이트웨이는 자동으로 사용자의 모든 세션을 암호화한ㄷ.ㅏ
8.2.3 HTTPS/HTTP 클라이언트 측 보안 가속 게이트웨이
- 웹 서버의 앞단에 위치하고 보이지 않는 인터셉트 게이트웨이나 리버스 프락시 역할을 한다.
- HTTPS 트래픽을 받아서 복호화하고, 웹 서버로 보낼 일반 HTTP 요청을 만든다.
- 원 서버보다 더욱 효율적으로 보안 트래픽을 복호화하는 하드웨어를 내장해서 원 서버 부하를 줄여주기도 한다.
8.3 리소스 게이트웨이
- 게이트웨이의 가장 일반적인 형태인 애플리케이션 서버는 목적지 서버와 게이트웨이를 한 개의 서버로 결합한다.
- 애플리케이션 서버는 HTTP를 통해서 클라이언트와 통신하고 서버 측에 있는 애플리케이션 프로그램에 연결하는 서버 측 게이트웨이다.
- HTTP 클라이언트를 여러 백엔드 애플리케이션으로 연결
8.3.1 공용 게이트웨이 인터페이스
- 공용 게이트웨이 인터페이스는 최초의 서버 확장이자 지금까지도 널리 쓰이는 서버 확장이다.
- CGI는 거의 모든 리소스 형식과 서버의 접점에 있으면서 필요에 따라 어떤 변형이든 처리해내는 단순한 기능을 제공한다.
- https://www.oreilly.com/openbook/cgi/ch01_01.html
- CGI를 통해 웹 서버는 프로그램을 호출하고 사용자로부터 받은 데이터(예: 사용자가 연결 중인 호스트 정보나 HTML 양식을 통해 제공된 입력)를 프로그램에 전달할 수 있다.
- 프로그램은 이 데이터를 처리하고, 서버는 프로그램의 응답을 웹 브라우저에 전달합니다.
8.3.2 서버 확장 API
- CGI 프로토콜은 구동 중인 HTTP 서버에 외부 인터프리터가 쉽게 접속할 수 있게 해주지만, 서버 자체의 동작이나 처리능력을 바꾸기 위해서는 서버 확장 API 가 필요하다.
- 이는 프로그래머가 자신의 코드를 서버에 연결하거나 서버의 컴포넌트를 자신이 만든 것으로 교체해버릴 수 있게 하였다.
8.4 애플리케이션 인터페이스와 웹 서비스
- 애플리케이션 연결 중 까다로운 이슈 중 하나는 두 애플리케이션 사이 프로토콜 인터페이스를 맞추는 일이다.
- 각 웹 애플리케이션이 서로 통신하는데 사용할 표준과 프로토콜 집합이 개발되었고, 그대로 웹 서비스로 불리게 되었다.
- 웹 서비스는 HTTP 같은 표준 웹 기술 위에서 개발한다.
- 웹 서비스는 SOAP을 통해 XML 을 사용하여 정보를 교환한다.
- SOAP(Simple Object Access Protocol)은 HTTP 메시지에 XML 데이터를 담는 방식에 대한 표준이다.
- 그러나 현재는 SOAP 보다 REST방식을 더 많이 쓰며, 데이터 포맷도 XML 보다 JSON 을 많이 쓴다.
8.5 터널
- 웹 터널은 HTTP 프로토콜을 지원하지 않는 애플리케이션에 HTTP 애플리케이션을 사용해 접근하는 방법을 제공한다.
- 웹 터널을 사용하면 HTTP 커넥션을 통해서 HTTP 가 아닌 트래픽을 전송할 수 있고, 다른 프로토콜을 HTTP 위에 올릴 수 있다.
8.5.1 CONNECT로 HTTP 터널 커넥션 맺기
- CONNECT 메서드는 터널 게이트웨이가 임의의 목적 서버와 포트에 TCP 커넥션을 맺고 클라이언트와 서버 간에 오는 데이터를 무조건 전달하기를 요청한다.
8.5.2 데이터 터널링, 시간, 커넥션 관리
- 터널을 통해 전달되는 데이터는 게이트웨이에서 볼 수 없어서, 게이트웨이는 패킷의 순서나 흐름에 대한 어떤 가정도 할 수 없다.
- 터널이 일단 연결되면, 데이터는 언제 어디로든 흘러가버릴 수 있다.
- 터널의 끝단 부분이든 커넥션이 끊어지면, 그 끊어진 곳으로부터 온 데이터는 반대편으로 전달된다. 그 다음 커넥션이 끊어졌던 터널의 끝단 반대편의 커넥션도 프락시에 의해서 끊어질 것이다.
8.5.3 SSL 터널링
- 웹 터널은 원래 방화벽을 통해서 암호화된 SSL 트래픽을 전달하려고 개발되었다.
- SSL 트래픽이 기존 프락시 방화벽을 통과할 수 있도록 HTTP 에 터널링 기능이 추가되었다.
- 터널은 HTTP 가 아닌 트래픽이 포트를 제한하는 방화벽을 통과할 수 있게 해주고 이는 보안 SSL 트래픽이 방화벽을 통과하는데 유용하게 사용된다.
8.5.4 SSL 터널링 vs. HTTP/HTTPS 게이트웨이
HTTP/HTTPS 게이트웨이의 단점
- 클라이언트-게이트웨이 사이에는 보안이 적용되지 않은 일반 HTTP 커넥션이 맺어진다.
- 프락시가 인증을 담당하고 있기 때문에, 클라이언트는 원격 서버에 SSL 클라이언트 인증을 할 수 없다.
- 게이트웨이는 SSL 을 완벽히 지원해야 한다.
위 상황에서 SSL 터널링을 사용하면, 프락시에 SSL을 구현할 필요가 없다.
8.5.5 터널 인증
- HTTP 의 다른 기능들은 터널과 함께 적절히 사용할 수 있다. 특히 프락시 인증 기능은, 클라이언트가 터널을 사용할 수 있는 권한을 검사하는 용도로 터널에서 사용한다.
8.5.6 터널 보안에 대한 고려사항들
- 터널 오용을 최소화하기 위해 게이트웨이는 HTTPS 전용 포트인 443같이 잘 알려진 특정 포트만을 터널링할수 있게 허용해야 한다.
8.6 릴레이
- HTTP 릴레이는 HTTP 명세를 완전히 준수하지 않는 간단한 HTTP 프락시다.
- 릴레이는 커넥션을 맺기 위한 HTTP 통신을 한 다음, 바이트를 맹목적으로 전달한다.
- 맹목적 전달은 단순 필터링이나 진단 혹은 콘텐츠 변환에 주로 사용된다.
반응형