[개발관련] RCP(Reverse Connection Pooling) 알아보기

개인 공부 겸 조사 내용이므로 잘못된 내용이 있을 수 있습니다. 그럴 경우 댓글로 알려주시면 감사하겠습니다.
=========================================================

일반적인 기능이라기보다는 국산 웹서버인 WebtoB와 국산 WAS JEUS의 기능이다.

공공기관 발주 RFP에서 웹서버에 대한 요구사항으로 RCP를, WAS에 대한 요구사항으로 TBWC를 요구하는 것을 볼 수 있다. RCP는 Reverse Connection Pooling으로 우리말로는 역방향 접속 방식이라고 하며 TBWC는 Transparent Backward Connection Pooling으로 명료한, 투명한 역방향 접속 방식 정도로 생각할 수 있다. (tbwc에 대해서는 자료를 많이 찾아볼 수 없었음) 이는 보안과 관련한 웹서버와 WAS의 연결 방식을 말한다. 제안서에서는 RCP를 방화벽 Port 를 Open 하지 않은 상태로 연결하는 것이라고 정의하고 있다.

역방향으로 접속하는 것이 무엇인지, Port를 Open하지 않는다는 것이 무엇인지 알기 위해서 먼저 웹서버의 역할,서버와 서버 간에 데이터를 주고받는다는 것,그리고 방화벽의 역할에 대해 이해를 할 필요가 있다.

웹서버는 웹 컨테이너의 앞 단에서 클라이언트의 요청을 받고 동적 컨텐츠를 응답하여야 하는 경우 웹 컨테이너에게 요청을 전달하는 역할을 맡는다. 필요한 경우 웹서버에서 WAS로 데이터를 전달해야 하는 것이다.
웹서버에서 WAS로 어떻게 데이터를 전달할까? 이렇게 서버와 서버 간에 데이터를 주고받는 것은 사실은 프로세스와 프로세스가 데이터를 주고 받는 것이다.(NIC를 통해 전달받은 데이터를 프로세스에 전달하는 것은 OS,커널의 역할이다).한 서버에서 다른 서버로 데이터를 전달해야할 때, 먼저 IP주소로 호스트*를 찾고 호스트 내에서 실행되고 있는 수 많은 프로세스 중 데이터를 전달해야하는 프로세스를 찾아야 한다. 이 때 프로세스를 식별할 수 있는 번호인 port번호를 이용한다. 그리고 두 프로세스가 데이터를 주고받기 위한 규약인 프로토콜(L4프로토콜인 TCP 또는 UDP)을 이용하여 데이터를 주고받을 수 있게 되는 것이다. TCP의 3-way handshake 등의 방식을 통해 두 서버가 데이터를 주고받을 수 있는 가상 경로를 생성하게 되는데 이렇게 생성된 프로세스 간 데이터를 주고받을 수 있는 통로를 소켓이라고 한다. 서버는 가상경로 생성을 위해 OS에게 특정 port에 연결 요청이 오면 연결을 해달라고 대기를 하게 된다. 이렇게 소켓을 만들기 위해서는 수신 측에서는 port를 열어두어 프로세스가 요청을 받을 수 있도록 대기를 하여야 하고( 이를 LISTEN이라고 한다. 웹 컨테이너에는 LISTEN을 위한 리스너들이 있다*) 송신측에서는 연결 요청을 해야만 한다. 한편, LISTEN 중인 경우 연결 요청을 받기 위해 해당 프로세스의 port를 열어두게 되는데 이는 보안상 위험한 부분일 수가 있다. 그래서 방화벽이 port에 대한 접근을 막거나 허용하여 보안을 강화하는 것이다.
정리해보자면,

1. 웹서버에서는 동적 처리가 필요한 요청을 WAS에게 전달해야한다.(이는 데이터를 전달하는것)
2. 프로세스간에 네트워크를 통해 데이터를 주고받으려면 반드시 소켓을 열어야 한다.
3. 소켓을 열기 위해 IP주소, port번호, 프로토콜이 필요하다.
4. 소켓을 열기 위해서는 리스너에게 연결요청을 해야한다.
5. 방화벽은 특정 port에 대한 접근(연결 요청) 을 막거나 허용할 수 있다.

클라이언트부터 DB서버까지의 일반적인 구조는 다음과 같다.(이중화된 3계층 구조)
브라우저 <-> 인터넷 <-> |외부방화벽| <-> 로드밸런서 <->웹서버(이중화) <-> |내부방화벽| <-> WAS <-> DB서버(이중화)

• 외부방화벽~내부방화벽 구간을 DMZ라고 한다. (Demilitarized Zone)

제안서에서는 RCP를 방화벽 Port 를 Open 하지 않은 상태로 연결하는 것이라고 정의하고 있다. 이는 웹 서버에서 WAS로 가는 모든 연결 요구를 내부 방화벽이 차단한다는 것을 의미한다. 소켓 생성을 위해서는 LISTEN 대기 중인 port에 접근해야 하는데 이러한 접근을 방화벽이 모두 막아버리는 것이다. 순방향이라고 부르는 일반적인 경우에는 웹서버에서 WAS로 연결 요구를 하기 때문에 WAS의 port가 Open되어 있다고 볼 수 있다. RCP방식은 웹서버에서 WAS의 port로 연결 요구를 하기 위하여 WAS의 port를 열어두는 것을 보안상 리스크가 있는 것으로 보고 그에 대해 대안으로 만든 방식인 것이다. RCP방식에서는 WAS의 인바운드 port를 모두 제한하고 아웃바운드port를 모두 개방하거나 일부만 개방하여 역방향으로 WAS에서 웹서버로 연결 요구를 진행한다. 이렇게 하면 공격자가 직접 WAS의 port에 접근할 수 없고 웹 서버의 80번 포트로만 접속할 수 있어 웹 브라우저의 단순한 명령만 가능하기 때문에 보안상 유리하다.
TBWC, Transparent Backward Connection Pooling에 대해서는 마찬가지로 WAS의 Port Open 없는 연결이라고 제안서에 기재되어 있는 것으로 보아 웹서버의 RCP에 대응하는 WAS의 역방향 접속방식을 일컫는 용어로 보인다. 결국 point는 WAS의 인바운드port를 모두 제한하여 보안성을 높이기 위한 것이라고 생각한다.WAS로 접근할 수 있는 port는 막고, 필요한 연결은 WAS에서 웹서버로 역방향으로 요청하는 것이다. 한편 RCP방식을 부정적으로 보는 시선도 존재한다. 순방향이든 역방향이든 결국은 port를 열어야하며 이렇게 방화벽을 우회하는 연결이 오히려 보안상 좋지 않다는 것이다. 그리고 RCP 방식의 아키텍쳐를 채택하는 곳은 전세계적으로도 찾아보기 힘들다고 한다. 국내 웹서버인 WebtoB와 국내 WAS인 JEUS는 RCP와 TBWC 기능을 제공하는데 같은 머신 내에서 실행할 경우 일반적인 소켓방식이 아닌 Pipe통신을 사용하여 월등한 성능 향상을 기대할 수 있다고 한다(?) 모든 것에 장,단점이 있듯이 해당 방식에도 장단점이 있는 것이라고 생각한다. 고객사에서 이러한 장단점을 고려하여 요구하는 사항일 것이므로 해당 요건을 맞춰야 할 것이다.

(실무에서 JEUS와 WebtoB가 아닌 Tomcat과 NginX조합을 사용하여 이론적으로만 익혀보게 되었다.)

------------------------------
Connection Pooling이란 무엇인가?
- Connection Pooling이라는 용어가 처음에는 DB 연결 캐시를 만드는 Database Connection Pool과 관련이 있을 것이라고 생각하였으나 다른 개념이었다.
-Thread Pool(스레드풀, 한정된 리소스때문에 제한된 개수만큼 스레드를 생성하고 작업 큐에 들어오는 작업들을 스레드가 하나씩 처리하는 것) 스레드 풀과 관련이 있는 것인가 생각해보았으나 연관이 없어보인다.
-RCP에 대한 설명중 웹서버 또는 WAS 가동 시점에 정의된 커넥션 개수만큼 역방향으로 연결한다는 내용이 있었는데 정해진 개수의 커넥션을 Pool에 생성해놓고 연결이 필요할 때마다 돌려쓰는 개념이 아닐까 유추해보았지만 명확하지 않다.
AJP는 어떤 관련이 있는가?
-AJP는 아파치와 톰캣을 연결하기 위한 프로토콜.
-인텔리제이 설정에서는 AJP port를 설정하도록 되어 있다.
-AJP port도 RCP에서 제한하는 port에 해당하는 것인지?

*호스트 : 네트워크 노드 중 IP주소가 할당된 장치를 호스트라고 한다.
*노드 : 네트워크에 연결된 모든 종류의 장치를 노드라고 한다.
*웹 컨테이너 리스너의 종류
-1)HTTP리스너 2)보안리스너 3)TCP리스너 4)UDP리스너 5)Apach리스너 6)WebtoB리스너 7)AJP13리스너 8) Tmax리스너
-이 중 6)WebtoB리스너가 일반 리스너들과는 다르게 역방향으로 동작한다.

*참고 자료
https://www.ddaily.co.kr/cloud/news/article.html?no=146806
http://www.btps.co.kr/business/down/Tmax_WebtoB.pdf
https://bluebluy.tistory.com/entry/WS%EC%99%80-WAS-%EC%97%B0%EA%B2%B0