HTTP 완벽 가이드 스터디 (8)

통합점: 게이트웨이, 터널, 릴레이

 

https://drive.google.com/file/d/1p_Ocnox6-Wwz5rXpOvFV9GeuFUolErQ0/view?usp=sharing

• 게이트웨이 : 서로 다른 프로토콜과 애플리케이션 간의 HTTP 인터페이스
• 애플리케이션 인터페이스 : 서로 다른 형식의 웹 애플리케이션이 통신하는 데 사용
• 터널 : HTTP 커넥션을 통해서 HTTP가 아닌 트래픽 전송
• 릴레이 : 일종의 단순한 HTTP proxy. 한 번에 한 개의 홉에 데이터를 전달하는 역할

게이트웨이

리소스와 애플리케이션을 연결하는 역할

• 동적 콘텐츠 생성
• 데이터베이스 질의

 

• 서버 측 : 클라이언트와는 HTTP로 통신하고, 서버와는 외래 프로토콜로 통신한다.
• 클라이언트 측 : 클라이언트와는 외래 프로토콜로 통신하고, 서버와는 HTTP로 통신한다.

 

서버 프로토콜 변환기

HTTP/*

클라이언트로부터 hTTP 요청이 원 서버 영역으로 들어오는 시점에 클라이언트 측의 HTTP 요청을 외래 프로토콜로 전환한다.

• FTP 라면 HTTP → FTP

서버 측 보안 게이트웨이

기업 내부의 모든 웹 요청 암호화.

• HTTP/HTTPS

리소스 게이트웨이

애플리케이션 서버

• 게이트웨이의 가장 일반적인 형태.
• 목적지 서버 + 게이트웨이 ⇒ 하나의 서버
• HTTP를 통해서 클라이언트와 통신하고 서버 측에 있는 애플리케이션 프로그램에 연결하는 서버 측 게이트웨이.

Application Programming Interface

• 애플리케이션 서버는 게이트웨이의 API를 통해서 요청을 서버에서 동작하고 있는 애플리케이션에 전달한다.

CGI(Common Gateway Interface)

특정 URL에 대한 HTTP 요청에 따라 프로그램 실행, 출력 수집, HTTP 응답으로 회신하는데 웹 서버가 사용하는 표준화된 인터페이스 집합.

• 리소스 요청이 들어옴 → 헬퍼 애플리케이션 생성, 요청 처리 → 헬퍼 애플리케이션 데이터 전달받음 (요청 전체 or 쿼리스트링) → 응답 반환

CGI 내부 처리는 사용자에게 보이지 않는다.

• URL에 있는 cgi or ? 같은 걸로 판단 가능

단점

• 모든 요청마다 새로운 프로세스 생성 → 부하 발생
• 서버의 성능 제한, 서버 장비에 부담을 줌.

→ 문제를 피하고자 Fast CGI 개발

Fast CGI

데몬으로 동작 → 요청마다 프로세스 생성 및 제거로 인한 성능 저하 문제 해결

서버 확장 API

CGI 프로토콜 → 구동 중인 HTTP 서버에 외부 인터프리터가 쉽게 접속할 수 있게는 해주나, 서버 자체의 동작을 바꾸고 싶거나 서버의 처리 능력을 최고치로 끌어 올리고자 할 때 ⇒ 서버 확장 API

• 웹 개발자가 자신의 모듈을 HTTP와 직접 연결할 수 있는 강력한 인터페이스

예) FrontPage Server Extension : FrontPage 클라이언트로부터 전송되는 원격 프로시저 호출(RPC) 명령을 인식할 수 있음.

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

데이터를 교환하려는 두 애플리케이션 사이에서 프로토콜 인터페이스를 맞추는 일은 까다롭다.

• FrontPage 서버 확장 → HTTP POST 메시지 위에 덧씌워진 RPC에 대해 다룸
• WebDAV와 공동 저작 → HTTP 헤더에 XML 추가하는 방법

<aside> 💡

SOAP(Simple Object Access Protocol) HTTP 메시지에 XML 데이터를 담는 방식에 관한 표준.

</aside>

• 웹 서비스는 SOAP을 통해 XML을 사용하여 정보를 교환
  • XML : 데이터 객체를 담는 데이터를 생성하고 해석하는 방식 제공

터널

HTTP 프로토콜을 지원하지 않는 애플리케이션에 HTTP 애플리케이션을 사용해 접근하는 방법

• HTTp 커넥션으로 http가 아닌 트래픽 전송
• 다른 프로토콜 http에 올리기
• 웹 트래픽만 허용하는 방화벽이 있더라도 HTTP가 아닌 트래픽을 전송 할 수 있음.

 

 

CONNECT

Content-Type 헤더를 포함할 필요 없다.

→ 커넥션이 메시지를 전달하는 대신 바이트를 그대로 전달하기 때문에 콘텐츠의 형식을 기술할 필요없음

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

터널을 통해 전달되는 데이터는 게이트웨이에서 볼 수 없다.

클라이언트 성능 높이기

• CONNECT 요청을 보낸 다음, 응답을 받기 전에 터널 데이터를 전송 가능함.
• 전제: 게이트웨이가 요청에 이어서 데이터를 적절하게 처리할 수 있어야 함.
• 게이트웨이는 네트워크 I/O 요청이 헤더 데이터만을 반환해줄 거라고 가정할 수 없어서, 게이트웨이는 커넥션이 맺어지는 대로 헤더를 포함해서 읽어들인 모든 데이터를 서버에 전송해야 한다.

커넥션 관리

• 한 쪽의 커넥션이 끊어지면 끊어진 곳으로 부터 온 데이터는 반대편으로 전달된다.
• 끊어졌던 터널의 끝단 반대편 커넥션도 프록시에 의해 끊어질 것.
• 아직 전송되지 않은 데이터는 버려진다.

SSL 터널링

웹 터널 → 방화벽을 통해 암호화된 SSL 트래픽 전달 목적

 

첫번째 그림 : 방화벽에 SSL이 차단된다.

• HTTP가 아닌 트래픽을 제한하는 방화벽

두번째 그림 : 방화벽은 HTTP를 통해 전송된 SSL을 수락한다.

• 보안 SSL 트래픽이 방화벽을 통과하는 데 유용하게 사용될 수 있음.
• 악의적인 트래픽 유입 경로가 될 수도 있음.

 

터널 인증

클라이언트 터널 사용권한 검사 용도

 

터널 보안

• 게이트웨이는 프로토콜이 터널을 올바른 용도로 사용하고 있는지 검증할 방법이 없다.
  • 방화벽에 터널을 생성하여 게임 트래픽을 사내로 유입
  • 악의적 사용자 → 텔넷 세션 오픈 or 회사 이메일 차단 장치 우회
• 터널 오용 최소화
  • HTTPS 전용 포트 443 → 잘 알려진 특정 포트만을 터널링할 수 있게 허용해야 함.

릴레이

HTTP 명세를 완전히 준수하진 않는, 간단한 HTTP 프락시

• 커넥션 이후 맹목적인 바이트 전달.

단순 맹목적 릴레이 구현

HTTP는 복잡하기에, 모든 헤더와 메서드 로직을 수행하지 않고 단순히 맹목적으로 트래픽을 전달하도록 간단한 프락시를 구현하는 방식이 유용할 때가 있다.

• 단순 필터링, 진단 콘텐츠 변환 → 잠재적으로 심각한 상호 운용 문제 → 배포 주의

 

 

예방

• 릴레이를 똑똑하게 만들기
• 프락시의 단순함 이면 → 상호 운용 문제 발생 위험
• HTTP를 제대로 준수하는 프락시를 사용하는 것이 좋음.