여러 종류의 리소스에 접근하는데 HTTP가 어떻게 쓰이는지 알아보고, 다른 프로토콜이나 애플리케이션 간 통신에 HTTP를 어떻게 사용하는지 알아보도록 하자.
주요 키워드
- 게이트웨이: 서로 다른 프로토콜과 애플리케이션 간의 HTTP 인터페이스다.
- 애플리케이션 인터페이스: 서로 다른 형식의 웹 애플리케이션이 통신하는데 사용한다.
- 터널: HTTP 커넥션을 통해서 HTTP가 아닌 트래픽을 전송하는데 사용한다.
- 릴레이: 일종의 단순한 HTTP 프락시로, 한 번에 한 개의 홉에 데이터를 전달하는데 사용한다.
게이트웨이
HTTP의 확장과 인터페이스는 필요에 의해 발전해왔다.
웹에 더 복잡한 리소스를 올려야 할 필요가 생기면서 모든 리소스를 한 개의 애플리케이션으로만 처리할 수 없어졌다. 이러한 문제를 해결하기 위해 리소스를 받기 위한 경로를 안내하는 역할을 하는 게이트웨이를 고안해냈다.
게이트웨이는 리소스와 애플리케이션을 연결하는 역할을 한다.
게이트웨이는 HTTP 트래픽을 다른 프로토콜로 자동으로 변환하여, HTTP 클라이언트가 다른 프로토콜을 알 필요 없이 서버에 접속할 수 있게 하기도 한다.
이런 HTTP 게이트웨이는 주로 API Gateway라는 이름으로 사용되며, REST API, GraphQL 등의 다양한 API 요청을 중앙 집중적으로 관리한다. 이를 통해 보안, 인증, 요청 라우팅, 로깅, 모니터링 등 중요한 기능을 통합적으로 제어할 수 있다. 즉, 클라이언트가 복잡한 서비스 아키텍처를 알 필요 없이 단순하게 API를 호출할 수 있으며, 게이트웨이가 각 서비스에 대한 로드 밸런싱, 장애 처리, 요청 제한, 인증 등을 쉽게 관리할 수 있다.
게이트웨이의 예시
- a: 게이트웨이는 FTP URL을 가리키는 HTTP 요청을 받는다.
게이트웨이는 FTP 커넥션을 맺고, FTP 서버에 적절한 명령을 전송한다.
클라이언트는 적절한 HTTP 헤더와 함께 HTTP를 통해서 문서를 받는다.
- b: 게이트웨이는 암호화된 웹 요청을 SSL을 통해 받고, 요청을 해독해서 생성한 일반 HTTP 요청을 목적지 서버로 전달한다.
- c: 애플리케이션 서버 게이트웨이 API를 통해서 HTTP 클라이언트를 서버 측 애플리케이션 프로그램에 연결한다.
클라이언트 측 게이트웨이와 서버 측 게이트웨이
웹 게이트웨이는 한쪽에서는 HTTP로 통신하고, 다른 한쪽에서는 HTTP가 아닌 다른 프로토콜로 통신한다.
게이트웨이는 빗금(/)으로 서버와 클라이언트 측 프로토콜을 구분한다.
<클라이언트 프로토콜>/<서버 프로토콜>
용어
어디와 외래 프로토콜로 통신하는지에 따라 구분한다.
- 서버 측 게이트웨이: 클라이언트와 HTTP로 통신, 서버와 외래 프로토콜로 통신
- 클라이언트 측 게이트웨이: 클라이언트와 외래 프로토콜로 통신, 서버와 HTTP로 통신
프로토콜 게이트웨이
프락시에 트래픽을 바로 보내는 것 같이, 게이트웨이에도 HTTP 트래픽을 바로 보낼 수 있다. 예를 들어, API 요청을 중앙 집중식으로 처리하는 API 게이트웨이를 설정해 모든 트래픽이 거쳐가도록 할 수 있다.
보통, 게이트웨이를 설정하는 방법은 2가지이다.
- 브라우저에 명시적으로 게이트웨이를 설정하여 자연스럽게 트래픽이 게이트웨이를 거쳐가게 하기.
브라우저가 모든 HTTP 요청을 게이트웨이로 보내고, 게이트웨이는 이 요청을 받아 내부적으로 라우팅하거나 필요한 처리를 거친 후 응답을 반환한다.
- 게이트웨이를 대리 프락시(리버스 프락시)로 설정하기
리버스 프락시는 사용자가 직접 지정하지 않아도 자동으로 모든 요청이 게이트웨이를 통과하게 하며, 클라이언트는 내부 서버 주소를 몰라도 된다. 예를 들어, NGINX 같은 서버가 HTTP 요청을 받아 게이트웨이 역할을 수행하면서, 요청을 백엔드 서버로 전달하고, 백엔드에서 받은 응답을 클라이언트에 전송할 수 있다.
프로토콜 게이트웨이의 주된 역할은 한 프로토콜로 들어온 요청을 다른 프로토콜로 변환하고, 이를 통해 서로 호환되지 않는 시스템들이 원활하게 상호작용하도록 돕는 것이다.
HTTP/*: 서버 측 웹 게이트웨이
서버 측 웹 게이트웨이는 클라이언트의 HTTP 요청을 원 서버 영역으로 들어오는 시점에 외래 프로토콜로 변환한다.
게이트웨이는 원 서버의 FTP 포트(21번)로 FTP 커넥션을 연결하고 FTP 프로토콜을 통해서 객체를 가져온다.
게이트웨이가 하는 역할
- USER, PASS 명령을 보내 서버에 로그인
- 서버에서 적절한 디렉터리로 변경하기 위한 CWD 명령
- 다운로드 형식을 ASCII로 설정
- MDTM으로 문서 최근 수정 시간 가져오기
- PASV로 서버에게 수동형 데이터 검색을 한다고 알리기
- RETR로 객체를 검색
- 제어 채널에서 반환된 포트로 FTP 서버에 데이터 커넥션을 맺는다.
데이터 채널에서 열리는 대로 객체가 게이트웨이로 전송된다.
게이트웨이는 객체를 받는대로 HTTP 응답에 실어서 클라이언트에 전송한다.
HTTP/HTTPS: 서버 측 보안 게이트웨이
기업 내의 모든 웹 요청을 암호화함으로써 개인 정보 보호와 보안을 제공하는데 게이트웨이를 사용할 수 있다.
클라이언트는 일반 HTTP를 통해 웹을 탐색할 수 있지만 게이트웨이는 자동으로 사용자의 모든 세션을 암호화한다.
HTTPS/HTTP: 클라이언트 측 보안 가속 게이트웨이
HTTPS/HTTP 게이트웨이는 웹 서버의 앞단에 위치하고, 보이지 않는 인터셉트 게이트웨이나 리버스 프락시 역할을 한다.
이 게이트웨이는 보안 HTTPS 트래픽을 받아 복호화하고, 웹 서버로 보낼 일반 HTTP 요청을 만든다.
리소스 게이트웨이
게이트웨이의 가장 일반적인 형태인 애플리케이션 서버는 목적지 서버와 게이트웨이를 한 개의 서버로 결합한다.
애플리케이션 서버는 HTTP를 통해 클라이언트와 통신하고, 서버 측에 있는 애플리케이션 프로그램에 연결하는 서버 측 게이트웨이다.
위의 예시에서는 2개의 클라이언트가 HTTP를 통해 애플리케이션 서버로 연결한다. 서버로부터 파일이 전송되는 대신, 애플리케이션 서버는 게이트웨이의 API를 통해 요청을 서버에서 동작하는 애플리케이션에 전달한다.
애플리케이션 게이트웨이에서 유명했던 최초의 API는 공용 게이트웨이 인터페이스(CGI)였다.
특정 URL에 대한 HTTP 요청에 따라 프로그램을 실행하고, 프로그램의 출력을 수집하고, HTTP 응답으로 회신하는데 웹 서버가 사용하는 표준화된 인터페이스 집합이다.
게이트웨이를 통해야 받을 수 있는 요청이 들어오면, 서버는 헬퍼 애플리케이션(CGI 스크립트)을 생성하여 요청을 처리한다.
서버 게이트웨이 애플리케이션의 동작
공용 게이트웨이 인터페이스
CGI는 최초의 서버 확장이자, 지금까지도 널리 쓰이는 서버 확장이다.
CGI는 단순하므로, 거의 모든 HTTP 서버가 지원한다.
CGI가 내부에서 어떤 처리를 하는지는 사용자에게 보이지 않는다. 클라이언트가 CGI 애플리케이션이 무언가를 하고 있다는 것을 알 수 있는 유일한 단서는 URL에 있는 'cgi' 또는 '?' 같은 것 뿐이다.
CGI는 거의 모든 리소스 형식과 서버의 접점에 있으면서, 필요에 따라 어떤 변형이든 처리해내는 단순한 기능을 제공한다. 인터페이스는 문제가 많은 "확장"으로부터 서버를 보호한다는 점에서 좋다고 할 수 있다. (문제가 있는 확장이 서버에 들어가게 되면 에러를 발생시키고, 서버를 종료시킨다.)
하지만 이러한 분리로 인해, 성능 관련 비용이 증가하게 된다. 모든 CGI 요청마다 프로세스를 만드는데 부하가 크다. 이러한 이유로 Fast CGI가 개발되었으며, 이 인터페이스는 CGI와 유사하지만 데몬으로 동작함으로써 요청마다 새로운 프로세스를 만들게 되어 발생하는 성능 문제를 해결했다.
프로세스와 데몬(daemon)은 모두 컴퓨터에서 실행 중인 작업 단위이지만, 역할과 동작 방식에서 차이가 있다.
프로세스
- 정의: 프로세스는 프로그램이 실행되어 메모리에 올라가 실행 중인 작업을 의미한다. 운영 체제는 각 프로세스에 고유한 프로세스 ID(PID)를 할당하여 관리합니다.
- 특성:일반적인 프로그램
- 실행: 사용자가 직접 실행하는 프로그램(예: 브라우저, 텍스트 편집기 등)은 모두 프로세스다.
- 종료 시점: 일반적으로 사용자가 작업을 종료하거나 프로그램의 실행이 완료되면 프로세스는 종료된다.
- 상호작용: 사용자가 직접 상호작용하며 제어할 수 있는 경우가 많다. 예를 들어, 터미널에서 명령을 입력하여 프로세스를 시작하거나 종료할 수 있다.
데몬(Daemon)
- 정의: 데몬은 백그라운드에서 연속적으로 실행되는 프로세스로, 사용자와 직접적인 상호작용 없이 특정 서비스나 작업을 백그라운드에서 수행하는 역할을 한다.
- 특성:백그라운드 실행: 데몬은 백그라운드에서 실행되며, 사용자가 직접 제어하지 않아도 독립적으로 동작한다.
- 종료 시점: 일반적으로 시스템이 시작할 때 자동으로 시작되며, 시스템이 종료되거나 명시적으로 종료될 때까지 실행된다.
- 접미사 'd': 보통 리눅스/유닉스 시스템에서 데몬 프로세스 이름은 sshd, httpd처럼 접미사로 'd'를 붙여 구분한다.
- 서비스 제공: 데몬은 시스템 서비스(예: 네트워크 관리, 로그 기록, 데이터베이스 관리 등)를 제공한다. 예를 들어, sshd는 SSH 접속을 관리하고, httpd는 웹 서버 요청을 처리한다.
성능 면에서 일반적인 프로세스와 데몬 간의 차이는 그 역할과 실행 방식에 따라 다를 수 있지만, 본질적으로 어느 한쪽이 우수하다고 말하기는 어렵다. 성능은 주로 프로세스의 구현 방식, 시스템 자원 관리, 실행 환경에 따라 결정된다.
다만, 몇 가지 성능 관련 차이를 고려할 수 있다.
1. 프로세스와 데몬의 성능 차이 요인
- 실행 주기: 일반 프로세스는 사용자가 실행하고 종료할 때까지 한 번만 실행되므로, 필요한 자원만 사용하다가 종료된다. 반면에, 데몬은 백그라운드에서 지속적으로 실행되기 때문에 일정한 메모리와 CPU를 항상 사용한다.
- 시스템 리소스 활용: 데몬은 지속적으로 메모리와 CPU를 점유하며 실행되기 때문에, 이들이 많아지면 시스템에 부담이 될 수 있다. 일반 프로세스는 실행 중일 때만 자원을 사용하므로 리소스 점유 시간이 짧을 수 있다.
- 기능 최적화: 데몬은 보통 특정 서비스의 백그라운드 작업을 처리하는 데 최적화되어 있어, 성능이 중요한 작업에 대해 효율적으로 설계된 경우가 많다. 예를 들어, 데이터베이스 데몬이나 네트워크 데몬은 고성능을 요구하기 때문에 최적화되어 있다.
2. 언제 데몬이 더 성능에 유리한가?
- 서비스의 지속성: 지속적으로 실행되어야 하는 서비스(예: 웹 서버, 데이터베이스 서버 등)는 데몬으로 구현되어 대기 중인 상태에서 요청을 빠르게 처리할 수 있다. 사용자가 요청할 때마다 새 프로세스를 생성하는 방식보다 성능 면에서 유리하다.
- 대량의 연결 처리: 네트워크 데몬(sshd, httpd 등)은 여러 연결을 관리하기 위해 비동기 및 멀티스레딩, 멀티프로세싱 등을 사용하여 성능을 최적화한다.
3. 언제 일반 프로세스가 더 성능에 유리한가?
- 일회성 작업: 한 번 실행하고 종료되는 간단한 작업에는 일반 프로세스가 더 적합하다. 예를 들어, 특정 파일을 처리하거나 짧은 계산을 수행할 때는 데몬이 아닌 단발성 프로세스로 처리하는 것이 더 적은 리소스를 사용한다.
- 리소스 절약: 데몬이 필요하지 않은 작업을 데몬으로 실행할 경우, 백그라운드에서 불필요한 자원을 소모하게 되어 시스템 성능이 저하될 수 있다.
결론
데몬은 지속적인 서비스 제공에 최적화된 프로세스로, 대기 상태에서 즉각적으로 요청을 처리할 수 있어 서버와 같이 지속적인 처리가 필요한 경우에 성능이 우수하다.일반 프로세스는 단일 작업을 빠르게 처리하고 종료되므로, 단발성 작업에 적합하며 불필요한 리소스 사용을 피할 수 있어 효율적이다.
따라서, 성능이 더 우수한 것은 상황에 따라 다르며, 어떤 작업이 필요한지, 지속성 여부, 그리고 리소스 사용 특성에 따라 데몬과 일반 프로세스의 성능이 달라질 수 있다.
서버 확장 API
CGI 프로토콜은 구동 중인 HTTP 서버에 외부 인터프리터가 쉽게 접속할 수 있다.
그러나, 서버 자체의 동작을 바꾸고 싶거나 서버의 처리 능력을 최고치로 끌어올리고자 할 때는 서버 확장 API를 사용한다.
확장 API는 프로그래머가 자신의 코드를 서버에 연결하거나 서버 컴포넌트를 자신이 만든 것으로 교체해버릴 수 있게 한다.
애플리케이션 인터페이스와 웹 서비스
애플리케이션을 연결하면서 생기는 까다로운 이슈 중 하나는 데이터를 교환하려는 두 애플리케이션 사이에서 프로토콜 인터페이스를 맞추는 일이다. 애플리케이션을 상호 운용하다보면 HTTP 헤더로는 표현하기 힘든 복잡한 정보를 교환해야 할 수도 있다.
인터넷 커뮤니티는 각 웹 애플리케이션이 서로 통신하는데 사용할 표준과 프로토콜 집합을 개발했다. 이러한 표준은 원래 웹 서비스가 독립형 웹 애플리케이션 그 자체를 의미함에도 불구하고 웹 서비스로 불리게 되었다. 예를 들면, 원래 웹 서비스라는 용어는 독립형 웹 애플리케이션(예: 온라인 쇼핑 사이트, 포털 등)을 가리키는 데 사용되었으나, 오늘날의 웹 서비스는 서로 다른 애플리케이션이 통신하고 정보를 공유하기 위한 표준화된 방식을 의미하게 되었다. 여기서 웹 서비스는 애플리케이션이 정보를 공유하는데 사용하는 새로운 메커니즘을 의미하며, 웹 서비스는 HTTP 같은 표준 웹 기술 위에서 개발한다.
웹 서비스는 SOAP을 통해 XML을 사용하여 정보를 교환한다.
XML은 데이터 객체를 담는 데이터를 생성하고 해석하는 방식을 제공한다. SOAP은 HTTP 메시지에 XML 데이터를 담는 방식에 관한 표준이다.
현대 웹 서비스의 데이터 교환 방식은 REST, 데이터의 포맷은 JSON을 더 많이 쓴다.
터널
웹 터널은 HTTP 프로토콜을 지원하지 않는 애플리케이션에 HTTP 애플리케이션을 사용해 접근하는 방법을 제공한다.
웹 터널을 사용하면 HTTP 커넥션을 통해서 HTTP가 아닌 트래픽을 전송할 수 있고, 다른 프로토콜을 HTTP 위에 올릴 수 있다.
웹 터널을 사용하는 가장 일반적인 이유 = HTTP 커넥션 안에 HTTP가 아닌 트래픽을 얹기 위함이다.
CONNECT로 HTTP 터널 커넥션 맺기
웹 터널은 HTTP의 CONNECT 메서드를 사용하여 커넥션을 맺는다.
CONNECT 프로토콜은 많이 구현하는 확장이다.
CONNECT 메서드는 터널 게이트웨이가 임의의 목적 서버와 포트에 TCP 커넥션을 맺고, 클라이언트와 서버 간에 오는 데이터를 무조건 전달하기를 요청한다.
CONNECT 메서드가 어떻게 게이트웨이로터널을 연결하는지 보여주는 그림
- 클라이언트는 게이트웨이에 터널을 연결하려고 CONNECT 요청을 보낸다.
클라이언트의 CONNECT 메서드는 TCP 커넥션을 위해 게이트웨이에 터널 연결을 요청한다. (SSL 포트 443 + 호스트명이 orders.joes-hardware.com 으로)
- TCP 커넥션은 (b)와 (c)와 같이 생성된다.
- 커넥션이 맺어지면 게이트웨이는 클라이언트에게 응답을 전송하여 연결되었음을 알린다.(d)
- 이 시점에 터널이 연결된다.
HTTP 터널을 통해 전송된 클라이언트의 모든 데이터는 위에서 맺은 TCP 커넥션으로 바로 전달될 것이며, 서버로부터 전송된 모든 데이터 역시 HTTP 터널을 통해서 클라이언트에게 전달될 것이다.
CONNECT 문법
1. CONNECT 요청
시작줄을 제외하고는 다른 HTTP 메서드와 같다.
요청 URI는 호스트명이 대신하며, 콜론에 이어 포트를 기술한다. 호스트와 포트는 다음과 같이 기술해야 한다.
CONNECT home.netscape.com:443 HTTP/1.0
User-agent: Mozilla/4.0
시작줄 다음에는 다른 HTTP 메시지처럼 추가적인 HTTP 요청 헤더 필드가 있거나 없다.
보통 각 행은 CRLF로 끝나고, 헤더 목록의 끝은 빈줄의 CRLF로 끝난다.
2. CONNECT 응답
클라이언트는 요청을 전송한 다음, 게이트웨이의 응답을 기다린다.
일반 HTTP 메시지와 같이 200 응답 코드는 성공을 뜻한다. 편의상 응답에 있는 사유 구절은 'Connection Established'로 기술된다.
HTTP/1.0 200 Connection Established
Proxy-agent: Netscape-Proxy/1.1
일반적인 HTTP 응답과 달리 `Content-Type` 헤더를 포함할 필요는 없다. 커넥션이 메시지를 전달하는 대신 바이트를 그대로 전달하기 때문에, 컨텐츠의 형식을 기술하는 `Content-Type` 헤더를 포함할 필요가 없다.
데이터 터널링, 시간 커넥션 관리
터널을 통해 전달되는 데이터는 게이트웨이에서 볼 수 없어서 게이트웨이는 패킷의 순서나 흐름에 대한 어떠한 가정도 할 수 없다. 왜냐하면, 게이트웨이는 단순히 암호화된 데이터를 전달하는 통로 역할을 할 뿐, 데이터가 어떤 순서로 오가고 있는지, 내용이 무엇인지 알 수 없기 때문에 데이터 순서나 흐름에 대해 가정할 수 없다.
터널이 일단 연결되면 데이터는 언제 어디로든 흘러가버릴 수 있다. 즉, 터널이 설정되면 클라이언트와 서버 간의 직접적인 연결이 형성됩니다. 이후에는 클라이언트와 서버가 데이터를 주고받기 시작하며, 중간에 있는 프록시는 그저 데이터를 양쪽으로 전달만 하기 때문에, 게이트웨이는 데이터가 언제 전송될지, 어디로 전송될지에 대해 통제할 수 없으며, 데이터가 터널을 통해 자유롭게 흐를 수 있습니다.
클라이언트는 성능을 높이기 위해 CONNECT 요청을 보낸 다음, 응답을 받기 전에 터널 데이터를 전송할 수 있다. 이는 서버에 데이터를 더 빨리 보내는 방법이지만 게이트웨이가 요청에 이어서 데이터를 적절하게 처리할 수 있어야 함을 전제로 한다.
게이트웨이는 네트워크 I/O 요청이 헤더 데이터만을 반환해줄 것이라고 가정할 수 없어서, 게이트웨이는 커넥션이 맺어지는 대로 헤더를 포함해서 읽어들인 모든 데이터를 서버에 전송해야 한다. 일반적인 HTTP 요청과 달리 터널링에서는 CONNECT 요청에 응답 헤더가 포함되며, 데이터가 헤더와 함께 혼합되어 전송되기 때문이다. 게이트웨이는 이 데이터를 헤더와 본문으로 구분할 수 없으므로 모든 데이터를 그대로 서버에 전송해야 데이터가 손실없이 서버에 전송될 수 있다.
요청 후, 터널을 통해 데이터를 전송한 클라이언트는 인증 요구나 200 외의 응답이 왔을 때 요청 데이터를 다시 보낼 준비가 되어 있어야 한다.
터널의 끝단 어느 부분이든 커넥션이 끊어지면, 그 끊어진 곳으로부터 온 데이터는 반대편으로 전달된다.
그 다음 커넥션이 끊어졌던 터널의 끝단 반대편의 커넥션도 프락시에 의해 끊어질 것이다. 커넥션이 끊긴 한 쪽에 아직 전송하지 않은 데이터는 버려진다.
SSL 터널링
웹 터널은 원래 방화벽을 통해 암호화된 SSL 트래픽을 전달하려고 개발되었다. 많은 회사가 더 강력한 보안을 위해 모든 트래픽이 패킷을 필터링하는 라우터와 프락시를 지나도록 하였다. 하지만, SSL 같이 암호화된 프로토콜은 정보가 암호화되어 있기 때문에 낡은 방식의 프락시에서는 처리되지 않는다. 터널을 사용하면 SSL 트래픽을 HTTP 커넥션으로 전송하여 80 포트의 HTTP만을 허용하는 방화벽을 통과시킬 수 있다.
직접 SSL 커넥션 vs 터널링된 SSL 커넥션
SSL 트래픽이 기존 프락시 방화벽을 통과할 수 있도록 HTTP에 터널링 기능이 추가되었다. 이 터널링 기능은 HTTP 메시지에 암호화된 raw 데이터를 담고 일반 HTTP 채널을 통해 데이터를 전송한다.
- a) 보안 웹 서버인 443 포트로 SSL 트래픽이 바로 전송된다.
- b) SSL 트래픽은 일반 SSL 커넥션을 통해 전송되기 전까지는 HTTP 메시지에 담겨 HTTP 포트인 80에 전송된다.
터널은 HTTP가 아닌 트래픽이 포트를 제한하는 방화벽을 통과할 수 있게 해준다. 이는 보안 SSL 트래픽이 방화벽을 통과하는데 유용하게 사용될 수 있다. 이는 보안 SSL 트래픽이 방화벽을 통과하는데 유용하게 사용될 수 있다. 하지만 터널은 악의적인 트래픽이 사내로 유입되는 경로가 될 수도 있다.
SSL 터널링 vs HTTP/HTTPS 게이트웨이
HTTPS 프로토콜(SSL 상의 HTTP)은 다른 프로토콜과 같은 방식으로 게이트웨이를 통과할 수 있다. 원격 HTTPS 서버와 SSL 세션을 시작하는 게이트웨이를 두고 클라이언트 측의 HTTPS 트랜잭션을 수행하는 방식이다.
응답은 프락시가 받아서 복호화하고 난 후에, HTTP(HTTPS가 아닌)를 통해 클라이언트로 전송한다. 이는 게이트웨이가 FTP를 처리하는 방식과 같다.
이 방식에는 몇 가지 단점이 있다.
- 클라이언트 - 게이트웨이 사이에는 보안이 적용되지 않은 일반 HTTP 커넥션이 맺어져 있다.
- 프락시가 인증을 담당하고 있으므로, 클라이언트는 원격 서버에 SSL 클라이언트 (X509 인증서 기반의 인증)을 할 수 없다.
- 게이트웨이는 SSL을 완벽히 지원해야 한다.
이 상황에서 SSL 터널링을 사용하면, 프락시에 SSL을 구현할 필요가 없다.
SSL 세션은 클라이언트가 생성한 요청과 목적지 웹 서버 간 생성된다. 프락시 서버는 트랜잭션의 보안에는 관여하지 않고 암호화된 데이터를 그대로 터널링할 뿐이다.
터널 인증
HTTP의 다른 기능들은 터널과 함께 사용할 수 있다.
프락시 인증 기능은 클라이언트가 터널을 사용할 수 있는 권한을 검사하는 용도로 터널에서 사용할 수 있다.
게이트웨이는 터널 사용허가를 내리기 전에 프락시 인증을 할 수 있다.
Proxy-Authenticate는 프록시 서버에서 클라이언트에게 인증을 요구할 때 사용하는 HTTP 응답 헤더다. 클라이언트가 프록시 서버를 통해 인터넷이나 다른 네트워크에 접근하려고 할 때,프록시 서버가 특정한 인증 절차를 요구 할 수 있으며, 이때 Proxy-Authenticate 헤더가 사용된다.
사용되는 예시
- 사내 네트워크: 회사 내부 네트워크에서 인터넷 접근 시 인증이 필요한 경우, 프록시 서버는 내부 직원만 접근할 수 있도록 Proxy-Authenticate를 통해 인증을 요구합니다.
- 공용 네트워크 접근 통제: 공공 와이파이나 카페, 호텔 등의 네트워크에서 특정 사용자만 접근하도록 제한하려는 경우, Proxy-Authenticate를 사용해 프록시 인증을 요구할 수 있습니다.
-API 요청 제한: 프록시 서버를 경유해 특정 API에 접근할 때, API 사용자를 제한하려는 목적이 있는 경우에도 Proxy-Authenticate를 사용해 접근 제어를 할 수 있습니다.
- 보안 강화: 내부 리소스나 민감한 데이터에 접근하는 프록시 서버를 사용할 때, Proxy-Authenticate를 통해 허가된 사용자만 통신할 수 있도록 보안을 강화합니다.
Proxy-Authenticate의 인증 방식
Proxy-Authenticate는 Basic, Digest, Bearer 등 다양한 인증 방식을 지원한다.
가장 흔히 사용되는 방식은 다음과 같습니다:
- Basic 인증: 사용자 이름과 비밀번호를 Base64로 인코딩하여 전달합니다. 기본적이고 간단하지만, 보안이 취약하므로 HTTPS와 함께 사용해야 합니다.
- Digest 인증: 암호화된 인증 정보를 포함해 전송하므로 Basic 인증보다 보안이 높습니다.
- Bearer 인증: JWT 같은 토큰을 사용하는 방식으로, 주로 OAuth와 같은 인증 프로토콜에서 사용됩니다.
터널 보안에 대한 고려사항들
터널 게이트웨이는 통신하고 있는 프로토콜이 터널을 올바른 용도로 사용하고 있는지 검증할 방법이 없다.
터널의 오용을 최소화하기 위해 게이트웨이는 HTTPS 전용 포트인 443 같이 잘 알려진 특정 포트만을 터널링할 수 있게 허용해야 한다.
즉, 일반적으로 HTTPS 통신은 포트 443에서 이루어지므로, 프록시 게이트웨이는 특정 포트만 터널링을 허용하는 정책을 적용할 수 있다.
릴레이
HTTP 릴레이는 HTTP 명세를 완전히 준수하지 않는 간단한 HTTP 프락시다.
릴레이는 커넥션을 맺기 위한 HTTP 통신을 한 후, 바이트를 맹목적으로 전달한다.
HTTP는 복잡하므로 모든 헤더와 메서드 로직을 수행하지 않고 맹목적으로 트래픽을 전달하는 간단한 프락시를 구현하는 방식이 유용할 때가 있다.
하지만 이는 몇가지 단점이 존재한다.
- 잠재적으로 심각한 상호 운용 문제를 가질 수 있다는 것
- 맹목적 릴레이가 Connection 헤더를 제대로 처리하지 못해서 keep-alive 커넥션이 행에 걸리는 것