HTTP Client CP, DB외에 Connection Pool을 사용하는 곳

관련 내용

DB에서 ConnectionPool을 사용하는 이유와 사용 방법

 

Client ConnectionPool을 사용하는 또 다른 이유

복잡한 HTTPS TLS Handshake 과정

개요 목적

DB외에도 ConnectionPool을 사용하는 HTTP Client CP에 대해서 알아보자. 왜 커넥션 풀이 필요한지, 커넥션 풀이 어떻게 문제를 해결하는 지 알아본다.

HTTP Client CP를 사용하는 이유

HTTP 통신을 하기 위해선, Client와 Server가 TCP/IP 프로토콜을 통해 연결되어야 한다. TCP/IP 커넥션 절차 안에는 다양한 과정이 있어서, 연결과 해제에 시간과 자원이 많이 든다. Connection을 보관하는 HTTPClient CP를 사용해 이러한 절차와 자원을 절약할 수 있다. 먼저 복잡한 연결(3-way-handshake)와 해제(4-way-handshake) 절차에 대해서 알아보자

커넥션 연결 3-Way Handshake

클라이언트와 서버 모두, 데이터를 전송할 준비가 되어 있다는 것을 보장하기 위해 3-Way Handshake 과정을 실행한다. 연결성을 보장하지만, 확인해야 하는 절차가 많다는 단점이 있다.

<절차>

• syn(클라이언트 연결 요청 서버에 syn 보냄) 
• syn+ack(서버가 syn을 받고 받았다는 신호인 ack를 더해 클라로 전달) 
• ack(클라이언트는 서버 응답을 받았다는 신호로 받은 ack를 다시 보낸다) 

커넥션 종료 4-Way Handshake

TCP통신의 커넥션 종료의 신뢰성을 보장하기 위해 4-Way Handshake를 사용한다. 단점으로는, 이러한 반복된 절차들이 쌓이게 되면, 성능 저하가 일어난다.

<절차>

1. 클라이언트가 Fin 플래그를 서버에 전송한다.
2. FIN플래그를 받은 서버는 ACK를 보내고, 사용 중인 프로세스가 모두 종료 명령을 내리고, 연결을 종료할 준비를 하는 CLOSE_WAIT 상태가 된다.
3. 서버가 연결을 종료할 준비가 완료되면, 서버는 FIN플래그를 전송한다.
4. FIN플래그를 받은 클라이언트는 해제 완료 의미인 ACK를 보내고 TIME_WAIT으로 변경된다.
   1. TIME_WAIT - 마지막으로 보낸 ACK메세지가 서버에 도착하지 않을 경우를 대비해서 소켓을 바로 닫아두는 것이 아니라, 시간을 가진다. 만약 서버에서 마지막으로 보낸 ACK(해제 완료)가 오지 않는다면, TIME_WAIT 동안에 다시 서버가 FIN 클라가 ACK를 보내서 안전한 연결 종료를 보장한다.

1. ACK를 받은 서버는 즉시, 연결 종료 상태가 되고, 클라이언트는 TIME_WAIT시간 동안 클라이언트에게 아무 응답이 없으면 연결 종료 상태가 된다.(아무 응답이 없다는 것은 서버가 마지막 ACK를 잘 받았다는 의미)

TIME_WAIT 자원 고갈 문제

TIME_WAIT을 통해서 신뢰성 있는 연결 종료를 할 수 있지만, 자원 고갈 문제가 있다. TIME_WAIT 동안은 해당 소켓에 다른 커넥션이 연결되는 것을 막는다. TIME_WAIT에 걸린 소켓이 많아지면, 서버의 소켓 고갈로 연결이 지연되는 문제가 발생한다.

HTTPClient CP로 문제 해결

HTTPClient CP를 사용하면, 클라이언트의 요청을 처리한 후에 바로 종료하는 것이 아니라, 해당 connection으로 idle connection을 생성한다. 이 connection을 connection pool에 넣어두고, timeout(일반적으로 90초)이 발생하기 전에, 같은 클라이언트로부터 요청이 오면 해당 connection을 재활용해서 사용한다. 그래서 CP를 사용하면, 클라이언트의 요청이 올 때마다, 커넥션을 연결, 종료하는 절차와 시간 낭비를 줄일 수 있다.

---

<Reference>

https://etloveguitar.tistory.com/111

https://velog.io/@averycode/네트워크-TCPUDP와-3-Way-Handshake4-Way-Handshake

https://m.blog.naver.com/PostView.nhn?blogId=cache798&logNo=130039539454&proxyReferer=https:%2F%2Fwww.google.com%2F