[2부 8장] 통합점: 게이트웨이, 터널 릴레이

[kmswlee]

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

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

---

게이트웨이

• 모든 리소스를 한 개의 애플리케이션으로만 처리할 수 없다는 것은 분명해졌다. 개발자들은 이 문제에 대한 해결책으로, 인터프리터 같이 리소스를 받기 위한 경로를 안내하는 역할을 하는 게이트웨이를 고안해냈다.
• 게이트웨이는 리소스와 애플리케이션을 연결하는 역할을 한다.
• 애플리케이션은 게이트웨이에게 요청을 처리해달라고 할 수 있고, 게이트웨이는 그에 응답할 수 있다.
• 게이트웨이는 요청을 받고 응답을 보내는 포털 같이 동작하는데, 동적인 콘텐츠를 생성하거나 데이터베이스에 질의를 보낼 수 있다.

• 게이트웨이는 FTP URL을 가리키는 HTTP 요청을 받는다.
• 게이트웨이는 FTP 커넥션을 맺고 FTP 서버에 적절한 명령을 전송한다.
• 클라이언트는 적절한 HTTP 헤더와 함께 HTTP를 통해서 문서를 받는다.

---

클라이언트 측 게이트웨이와 서버측 게이트웨이

• 웹 게이트웨이는 한쪽에서는 HTTP로 통신하고 다른 한쪽에서는 HTTP가 아닌 다른 프로토콜로 통신한다.
• 게이트웨이는 클라이언트 측 프로토콜과 서버 측 프로토콜을 빗금(/)으로 구분해 기술한다.
  <클라이언트 프로토콜>/<서버 프로토콜>
• 서버 측 게이트웨이는 클라이언트와 HTTP로 통신하고, 서버와는 외래 프로토콜로 통신한다.
• 클라이언트 측 게이트웨이는 클라이언트와 외래 프로토콜로 통신하고, 서버와는 HTTP로 통신한다.

---

프로토콜 게이트웨이

• HTTP 트래픽을 바로 보낼 수 있다. 브라우저에 명시적으로 게이트웨이를 설정하여 자연스럽게 트래픽이 게이트웨이를 거쳐 가게 하거나, 게이트웨이를 대리 서버(리버스 프락시)로 설정할 수도 있다.

• 일반적인 HTTP 트래픽에는 영향을 끼치지 않는다.
• 브라우저는 일반 HTTP 트래픽은 원 서버로 바로 보낸다.
• FTP URL을 포함한 요청은 게이트웨이로 HTTP 요청을 보낸다.
• 게이트웨이는 클라이언트 측의 요청을 FTP 요청으로 변환하여 처리한 뒤 클라이언트에게 그 결과를 HTTP로 전송한다.

---

HTTP/*: 서버 측 웹 게이트웨이

• 서버 측 웹 게이트웨이는 클라이언트로부터 HTTP 요청이 원 서버 영역으로 들어오는 시점에 클라이언트 측의 HTTP 요청을 외래 프로토콜로 전환한다.
• 게이트웨이는 원 서버의 FTP 포트(21 PORT)로 FTP 커넥션을 연결하고 FTP 프로토콜을 통해서 객체를 가져온다.
• 게이트웨이는 다음과 같은 일을 한다.
  • USER와 PASS 명령을 보내서 서버에 로그인한다.
  • 서버에서 적절한 디렉토리로 변경하기 위해 CWD 명령을 내린다.
  • 다운로드 형식을 ASCII로 설정한다.
  • MDTM으로 문서의 최근 수정 시간을 가져온다.
  • PASV로 서버에게 수동형 데이터 검색을 하겠다고 말한다.
• 게이트웨이는 객체를 받는 대로 HTTP 응답에 실어서 클라이언트에 전송할 것이다.

---

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

• 기업 내부의 모든 웹 요청을 암호화함으로써 개인 정보 보호와 보안을 제공하는데 게이트웨이를 사용할 수 있다.
• 클라이언트는 일반 HTTP를 사용하여 웹을 탐색할 수 있지만, 게이트웨이는 자동으로 사용자의 모든 세션을 암호화할 것이다.

---

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

• HTTPS/HTTP 게이트웨이는 보안 가속기로 유명하다.
• HTTPS/HTTP 게이트웨이는 웹 서버의 앞단에 위치하고, 보이지 않는 인터셉트 게이트웨이나 리버스 프락시 역할을 한다.
• 이 게이트웨이는 보안 HTTPS 트래픽을 받아서 복호화하고, 웹 서버로 보낼 일반 HTTP 요청을 만든다.
• 이 게이트웨이는 원 서버보다 더욱 효율적으로 보안 트래픽을 복호화하는 암호화 하드웨어를 내장해서 원 서버의 부하를 줄여주기도 한다.
• 하지만 이 게이트웨이와 원 서버간의 암호화하지 않은 트래픽을 전송하기 때문에, 게이트웨이와 원 서버간에 있는 네트워크가 안전한지 확인이 필요하다.

---

리소스 게이트웨이

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

• 애플리케이션 게이트웨이에서 유명했던 최초의 API는 공용게이트웨이 인터페이스(CGI)였다.
• CGI는 특정 URL에 대한 HTTP 요청에 따라 프로그램을 실행하고, 프로그램의 출력을 수집하고, HTTP 응답으로 회신하는데 웹 서버가 사용하는 표준화된 인터페이스 집합이다.

• 게이트웨이를 통해야 받을 수 있는 리소스 요청이 들어오면, 서버는 헬퍼 애플리케이션을 생성하여 요청을 처리한다.
• 헬퍼 애플리케이션은 필요한 데이터를 전달 받는다.
• 전달받은 데이터는 요청 전체이거나 사용자가 데이터베이스에서 실행시키려는 질의 같은 것이다.
• 그 다음, 바로 클라이언트로 전달할 응답이나 응답 데이터를 서버에 반환한다.
• 서버와 게이트웨이는 별개의 애플리케이션이기 때문에 각각 가지고 있는 책임은 분명히 나뉘어 있다.

---

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

• CGI는 최초의 서버 확장이자 지금까지도 널리 쓰이는 서버 확장이다.
• 이는 웹에서 동적인 HTML, 신용카드 처리, 데이터베이스 질의 등을 제공하는 데 사용한다.
• CGI가 내부에서 어떤 처리를 하는지는 사용자에게 보이지 않는다.
• 사용자의 시각에서는 CGI가 내부적으로 일반적인 요청을 만드는 것일 뿐이다.

---

서버 확장 API

• CGI 프로토콜은 구동중인 HTTP 서버에 외부 인터프리터가 쉽게 접속할 수 있게는 해주지만, 서버 자체의 동작을
  바꾸고 싶거나 서버의 처리능력을 최고치로 끌어 올리고자 서버 확장 API를 제공하였다.
• 확장 API는 프로그래머가 자신의 코드를 서버에 연결하거나 서버의 컴포넌트를 자신이 만듣 것으로 교체해버릴 수 있게 하였다.

---

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

• 웹 서비스는 SOAP을 통해 XML을 사용하여 정보를 교환한다.
• XML은 데이터 객체를 담는 데이터를 생성하고 해석하는 방식을 제공한다.
• SOAP은 HTTP 메시지에 XML 데이터를 담는 방식에 관한 표준이다.

---

터널

• 웹 터널은 HTTP 프로토콜을 지원하지 않는 애플리케이션에 HTTP 애플케이션을 사용해 접근하는 방법을 제공한다.
• 웹 터널을 사용하면 HTTP 커넥션을 통해서 HTTP가 아닌 트래픽을 전송할 수 있고, 다른 프로토콜을 HTTP 위에 올릴 수 있다.
• 웹 터널을 사용하는 이유는 HTTP 커넥션 안에 HTTP가 아닌 트래픽을 얹기 위해서이다.

---

CONNECT로 HTTP 터널 커넥션 맺기

• 터널은 HTTP의 CONNECT 메서드를 사용하녀 커넥션을 맺는다.
• CONNECT 프로토콜은 HTTP/1.1 명세에 자세히는 나와있지 않다.
• CONNECT 메서드는 터널 게이트웨이가 임의의 목적 서버와 포트에 TCP 커넥션을 맺고 클라이언트와 서버 간에 오는 데이터를 무조건 전달하기를 요청한다.
• CONNECT 요청
  • CONNECT 문법은 다음과 같다.
    • CONNECT home.netscape.com:433 HTTP/1.0
      User-agent: Mozilla/4.0
• CONNECT 응답
  • HTTP/1.0 200 Connection Established
    Proxy-agent: Netscape-Proxy/1.1

---

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

• 터널을 통해 전달되는 데이터는 게이트웨이에서 볼 수 없어서, 게이트웨이는 패킷의 순서나 흐름에
  어떤 가정도 할 수 없다.
• 터널이 일단 연결되면, 데이터는 언제 어디로든 흘러가버릴 수 있다.
• 클라이언트는 성능을 높이기 위해 CONNECT 요청을 보낸 다음, 응답을 받기 전에 터널 데이터를 전송할 수 있다.
• 하지만 이는 게이트웨이가 요청에 이어서 데이터를 적절하게 처리할 수 있어야함을 전제로 깔고 있다.
• 게이트웨이는 네트워쿠 I/O 요청이 헤더 데이터만을 반환해줄 거라고 가정할 수 없어서, 게이트웨이는 커넥션이 맺어지는 대로 헤더를 포함해서 읽어들인 모든 데이터를 서버에 전송해야 한다.
• 터널의 끝단 어느 부분이든 커넥션이 끊어지면, 그 끊어진 곳으로부터 온 데이터는 반대편으로 전달된다.
• 그 다음 커넥션이 끊어졌던 터널의 끝단 반대편의 커넥션도 프락시에 의해서 끊어질 것이다.
• 커넥션이 끊긴 한쪽에 아직 전송하지 않은 데이터는 버려진다.

---

SSL 터널링

• 터널을 사용하면 SSL 트래픽을 HTTP 커넥션으로 전송하여 80 포트의 HTTP만을 허용하는 방화벽을 통과 시킬수 있다.
• SSL 트래픽이 기존 프락시 방화벽을 통과할 수 있도록 HTTP 터널링 기능이 추가되었다.
• 이 터널링 기능은 HTTP 메시지에 암호화된 데이터를 담고 일반 HTTP 채널을 통해 데이터를 전송한다.

• 직접SSL 커넥션 vs 터널링된 SSL 커넥션

---

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

• HTTPS 프로토콜은 원격 HTTPS 서버와 SSL 세션을 시작하는 게이트웨이를 두고 클라이언트 측의 HTTPS 트랜잭션을 수행하는 방식이다.
• 응답은 프락시로 받아서 복호화하고 난 후에, HTTP를 통해 클라이언트로 전송한다.
• 이 접근의 단점
  • 클라이언트-게이트웨이 사이에는 보안이 적용되지 않은 일반 HTTP 커넥션이 맺어져 있다.
  • 프락시가 인증을 담당하고 있기 때문에, 클라이언트는 원격 서버에 SSL 클라이언트을 할수 없다.
  • 게이트웨이는 SSL을 완벽히 지원해야 한다.
• 이 상황에서 SSL 터널링을 사용하면, 프락시에 SSL을 구현할 필요가 없다.
• SSL 세션은 클라이언트가 생성한 요청과 목적지 웹 서버간에 생성된다.

---

터널 인증

---

릴레이

• HTTP 명세를 완전히 준수하지 않는 간단한 HTTP 프락시다.
• 릴레이는 커넥션을 맺기 위한 HTTP 통신을 한 다음, 바이트를 맹목적으로 전달한다.
• 단순 필터링이나 진단 혹은 콘텐츠 변환을 하는데 사용되기도 한다.
• 일반적인 문제중 하나는, 맹목적 릴레이가 Connection 헤더를 제대로 처리하지 못해서 keep-alive 커넥션이 행(hang)에 걸리는 것이다.

[kmswlee]

프록시, 리버스 프록시 관련 참고 링크
https://narup.tistory.com/238
https://sujinhope.github.io/2021/06/13/Network-%ED%94%84%EB%A1%9D%EC%8B%9C(Proxy)%EB%9E%80,-Forward-Proxy%EC%99%80-Reverse-Proxy.html

[kmswlee]

게이트웨이 vs 프록시 서버
https://velog.io/@hyun-jii/%ED%94%84%EB%A1%9D%EC%8B%9CProxy-vs-%EA%B2%8C%EC%9D%B4%ED%8A%B8%EC%9B%A8%EC%9D%B4Gateway

[ruthetum]

gRPC gateway