Keep-Alive를 같은 단어로 묶지 않고, HTTP·TCP 두 계층에서 푸는 문제가 다르다는 점과 운영 트레이드오프를 같이 보는지 가르려는 질문이다.
HTTP Keep-Alive는 같은 TCP 연결 위에서 여러 요청·응답을 이어 처리하게 해 매 요청마다 핸드셰이크 비용을 다시 치르지 않게 한다. TCP Keep-Alive는 연결이 비어 있는 동안 주기적으로 probe 패킷을 보내 반대편이 살아 있는지 확인하고, 끊긴 좀비 연결을 가려낸다. 즉 둘은 같은 단어를 쓰지만 푸는 문제가 달라서, HTTP 쪽은 지연·CPU를, TCP 쪽은 자원 회수와 장애 감지를 떠안는다. 어느 쪽이든 timeout이 길수록 소켓 점유와 공격 표면이 커지고, 짧을수록 재연결 비용이 자주 발생하므로 nginx·LB·앱 서버 같은 계층의 timeout 값을 어긋나지 않게 맞추는 게 본 작업이 된다.
프록시·앱 서버의 idle timeout이 어긋나 502/504가 나던 문제를 풀어 본 경험이 있다면 계층별 정합성 사례로 연결할 수 있다
Keep-Alive timeout을 늘렸다 줄이며 소켓·지연 균형을 잡아 본 적이 있다면 운영 트레이드오프 관점에서 말할 수 있다
TCP Keep-Alive로 좀비 커넥션을 회수해 본 경험이 있다면 HTTP 쪽 노브로는 해결되지 않는 자리를 짚을 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.