Keep-alive란?

개요

Keep alive는 ELB 또는 ALB 등 네트워크 통신에서 많이 봤던 키워드이다. 정리해보고자 한다.

 

선행 지식

먼저 Keep alive를 이해하기 위해서 HTTP의 통신에 대한 특성을 알아볼 필요가 있다.

기본적으로 HTTP는 TCP Connection을 유지하지 않는다. 무슨 의미냐면 Connection을 Handshake를 통해 맺고 일정 시간이 지나면 Connection이 끊기기 때문에 여러 파일을 송/수신할 때 등의 상황에서 Connection을 끊고 다시 맺어야할 수도 있다는 의미이다.

간략히 Keep alive가 있고 없고의 차이는 아래 그림과 같을 것이다.

https://www.imperva.com/learn/performance/http-keep-alive/

 

그래서 왜 사용하는가?

우리가 Connection을 유지하지 않고 통신을 하고자 한다면 과정이 매우 길어질 것이고, 자원도 소모될 것이다.

예를 들어 마트에 장을 보러 가는데 한 사람당 이용할 수 있는 시간이 30분으로 제한되어 있고, 내가 구매해야 할 물품은 많다고 가정해보자. 대신 마트를 나갔다 들어오면 시간은 초기화 된다.

30분 동안 마트에서 물품을 구매하고 나갔다 다시 주차를 하고 카트를 끌고 다시 물품을 구매한다고 했을 때 1시간 또는 2시간 동안 길고 한번에 장을 보는 것보다 과정이 훨씬 길것이다.

결국 Connection을 오래 유지하는 이유는 계속해서 3 way handshake를 진행해 새로운 Connection을 맺지 않아 latency를 감소 시킬수 있고, 클라이언트 당 단일 연결을 사용해서 네트워크 리소스에 대한 부담을 줄이기 위해서다.

Keep alive 사용하는 이유

1. 네트워크 리소스 보존 : 클라이언트당 단일 연결을 사용하면 네트워크 리소스에 대한 부담이 줄어듭니다.
2. 네트워크 정체 감소 : 서버와 클라이언트 간의 TCP 연결 수를 줄이면 네트워크 정체가 줄어들 수 있습니다.
3. 대기 시간 감소 : 3방향 핸드셰이크 수를 줄이면 사이트 대기 시간이 향상될 수 있습니다. 이는 연결을 암호화하고 확인하기 위해 추가 왕복이 필요한 SSL/TLS 연결 의 경우 특히 그렇습니다.

 

https://blog.insightdatascience.com/learning-about-the-http-connection-keep-alive-header-7ebe0efa209d

 

그리고 이렇게 Connection을 오래 유지시키는 것을 Persistent Connections 라고 한다.

 

Persistent Connections

Persistent Connection은 HTTP 1.0 버전 이후 클라이언트와 서버 간의 통신을 더 빠르게 하기 위해 만들어졌다.

Connection: keep-alive

클라이언트는 서버에게 헤더에 위와 같은 내용을 포함하면 Persistent Connection을 지원한다.

HTTP 1.1에서는 Conncetion 헤더를 사용하지 않더라도 요청과 응답이 기본적으로 Persistent Connection을 지원하도록 되어 있다. 그래서 필요하지 않는 경우에만 Connection 헤더를 사용한다.

Connection: close

 

장단점

장점은 위에서 잠깐 언급한 것과  같다.

• 클라이언트와 서버 간의 지속적인 연결로 인해 새로운 연결이 줄어들고 3-Way 핸드셰이크가 줄어들어 CPU 사용량이 줄어듭니다.
• TCP 연결 수가 적기 때문에 네트워크 정체가 크게 줄어듭니다.
• 또한 요청과 응답의 HTTP 파이프라인을 활성화합니다.
• HTTPS의 경우 TLS 핸드셰이크가 줄어들기 때문에 대기 시간이 감소하고 부하가 감소한다.

단점은 아래와 같다.

• 연결을 장시간 유지하면 서버의 메모리와 소켓 자원을 많이 소비하기 때문에 다수의 클라이언트가 접속할 경우 서버의 자원 고갈을 초래할 수 있다.
• 유지된 연결 때문에 서버의 동시 접속 가능한 클라이언트 수가 제한될 수 있다.
• Keep-Alive 타임 아웃을 너무 짧게 설정하면 연결이 자주 끊어져 재연결 오버헤드가 발생할 수 있다.

 

이 외에 다른 문제점도 있다.

 

멍청한 프록시(Dumb Proxy)

만약 Proxy가 Connection 헤더를 이해하지 못한다면?

1. 웹 클라이언트는 프록시에 Connection: Keep-Alive 헤더와 함께 메시지를 전송
2. 클라이언트는 커넥션을 유지하자는 요청에 대한 응답을 확인하기 위해 기다린다.
3. Proxy는 요청받은 HTTP의 Connection 헤더를 이해하지 못한다.
4. Proxy는 Keep-Alive를 모르기 때문에 서버에 메시지를 그대로 전달한다.
5. 서버는 Keep-Alive 요청을 받았기 때문에 처리가 완료된 후에도 커넥션을 끊지 않는다.
6. Proxy는 서버와의 커넥션이 끊어지는 것을 기다리고 있기 때문에, 해당 Keep-Alive 커넥션을 통해서 오는 클라이언트의 두 번째 요청은 처리되지 않고 행에 걸린다.

그래서 비표준인 Proxy-Connection 이라는 헤더를 사용하는 차선책을 사용한다. 그러나 Proxy-Connection도 문제가 생길 수 있다. 

 

AWS ELB에선?

기본적으로 ALB는 HTTP Keep alive 값을 3,600초 또는 1시간으로 설정한다.

최소 60초 미만으로 설정할 수 없지만, 값을 최대 604800 또는 7일로 늘릴 수 있다.

클라이언트에 대한 HTTP 연결이 처음 설정될 때 HTTP client keep alive 기간을 시작한다.

연결 중에 keep alive 기간을 변경할 수 있으며, 변경 시에 기존 연결들은 기존에 설정된 값으로 연결을 유지하는 반면, 모든 새 연결은 업데이트된 keep alive 값을 받는다.

 

[참조] : 

https://www.imperva.com/learn/performance/http-keep-alive/

https://patrickryoo.tistory.com/entry/HTTP-Keep-Alive

https://etloveguitar.tistory.com/137

https://velog.io/@jihwankim94/Network-TCP-HTTP-Keep-alive

https://www.atatus.com/ask/what-is-http-keep-alive

https://docs.aws.amazon.com/elasticloadbalancing/latest/application/application-load-balancers.html

https://yeojin-dev.github.io/blog/dumb-proxy/