04. Connection 관리
4. Connection 관리
HTTP의 지연은 주로 기저에 있는 TCP의 지연 때문이다. HTTP 트랜잭션 자체는 매우 짧은 시간에 처리되며, 실제로는 TCP 커넥션 설정 및 데이터 전송 과정에서의 지연이 전체 성능 저하의 주 원인이 된다.
HTTP 지연의 핵심적인 TCP 지연 원인을 다음과 같이 정리할 수 있다.
1. TCP 커넥션
TCP는 연결형 프로토콜이며, 커넥션을 시작할 때 3-way handshake가 필요하다. 이 과정은 다음과 같다:
- 클라이언트 → 서버 :
SYN패킷 전송 - 서버 → 클라이언트 :
SYN+ACK패킷 응답 - 클라이언트 → 서버 :
ACK패킷 응답
이러한 handshake는 데이터 크기와 무관하게 필요하다. 특히 작은 HTTP 트랜잭션에서는 이 과정이 상대적으로 큰 지연을 유발한다. 또한, ACK 패킷이 클라이언트의 HTTP 요청 데이터를 포함하게 되는 경우도 많다.
이러한 이유로 TCP 커넥션 재사용(Keep-Alive) 을 권장한다.
2. 확인 응답 지연 (ACK Delay)
TCP는 데이터의 신뢰성 보장을 위해 확인 응답(ACK) 을 사용한다. 그러나 확인 응답은 즉시 보내지 않고, 편승(Piggybacking) 전략을 취한다:
- 같은 방향의 데이터가 곧 전송될 것으로 예상되면 최대 200ms까지 ACK 전송을 지연
- 일정 시간이 지나도 추가 데이터가 없을 경우 별도 ACK 패킷을 전송
HTTP는 요청/응답 구조이므로, 한 방향으로 패킷이 몰리는 구조를 가진다. 즉, 편승할 기회가 적고, 그 결과 ACK가 무의미하게 지연되는 경우가 발생한다.
3. TCP 슬로우 스타트
TCP는 혼잡 제어(Congestion Control) 메커니즘의 일환으로, 처음에는 전송 윈도우 크기를 작게 잡고, ACK를 수신할 때마다 점진적으로 윈도우를 늘려가는 방식을 취한다.
이를 슬로우 스타트(Slow Start) 라고 하며, 다음과 같은 특징이 있다:
- 처음 커넥션에서는 전송 가능한 데이터 양이 적다
- 여러 번의 왕복(ACK)을 통해 커넥션이 성장
- 한 번 성장한 커넥션은 더 많은 데이터를 효율적으로 전송 가능
이 때문에 이미 설정된 TCP 커넥션을 재사용하는 것이 성능에 유리하다.
4. 네이글 알고리즘 (Nagle’s Algorithm)
네이글 알고리즘은 너무 작은 TCP 패킷을 자주 보내는 것을 방지하기 위한 알고리즘이다.
동작 방식:
- 아직 전송되지 않은 데이터가 충분히 쌓이지 않았고,
- 이전 패킷의 ACK를 받지 못한 상태이면
- 데이터가 쌓일 때까지 버퍼에서 대기한다. (ACK 오면 예외적으로 발송함)
장점:
- 작은 패킷 남발로 인한 네트워크 오버헤드 방지
문제점:
- 작은 데이터의 경우, 버퍼에서 대기 시간 발생.
- 실시간성 중요한 데이터는 부적합. (작은 데이터라도 빠르게 보내야하는 경우)
또한, 네이글 알고리즘의 지연은 위에서 설명한 ACK 지연과 겹쳐질 수 있다. → 확인 응답을 기다리며 보내지 못하고, 확인 응답은 또 다른 패킷을 기다리는 악순환 발생
네이글 알고리즘을 비활성화하려면
TCP_NODELAY옵션을 사용하지만, 데이터 단편화를 유발할 수 있으므로 주의가 필요함.
5. TIME_WAIT과 포트 고갈
TCP 연결 종료 후에는 TIME_WAIT 상태가 일정 시간 유지된다.
이유:
- 동일한 4-튜플(IP, 포트 쌍)을 가진 연결이 즉시 재활용될 경우, 이전 커넥션의 지연된 패킷이 새 커넥션에 혼입되는 문제 방지
- 이 상태는 일반적으로 2MSL (Maximum Segment Lifetime × 2), 즉 약 1~2분 유지
문제 상황:
- 단시간 내에 수천~수만 개의 TCP 커넥션이 생기고 사라지는 경우
- 클라이언트 포트(0~65535)의 수가 제한되어 있으므로, 포트 고갈 현상 발생 가능
예시:
- 클라이언트가 초당 1000개의 HTTP 요청을 전송하고,
- 커넥션을 재사용하지 않는다면 → 수 초 내에 사용 가능한 포트를 모두 소진할 수 있음
대응 방안:
- 서버 측에서 가상 IP를 늘리거나, 클라이언트 측 부하 생성 장비를 분산