TCP backlog

1. TCP backlog란?

• 서버 소켓(listen())을 열면, 커널은 **연결 대기 큐(listen queue)**를 만듭니다.
• backlog는 그 큐의 최대 길이를 말합니다.
• 즉, 클라이언트가 SYN을 보내고 → 서버가 SYN-ACK까지 보냈지만 → 애플리케이션이 아직 accept()하지 않은 연결이 몇 개까지 쌓일 수 있느냐를 결정하는 값입니다.

👉 쉽게 말하면: “동시 접속자가 몰릴 때 대기열의 크기”

---

2. 연결 큐는 두 가지 단계가 있음

1. SYN queue (half-open queue)
   • TCP 3-way handshake 중 아직 완료되지 않은 연결 (클라 SYN, 서버 SYN-ACK 후, 클라 ACK 대기 상태).
   • 커널 파라미터: net.ipv4.tcp_max_syn_backlog.
2. accept queue (completed connection queue)
   • 3-way handshake 완료된 연결 중, 아직 애플리케이션이 accept()를 호출하지 않은 것.
   • backlog는 바로 이 큐의 크기.
   • 커널 파라미터: net.core.somaxconn이 상한으로 적용됨.

3. Redis의 tcp-backlog와 커널 상관관계

• Redis 설정:→ Redis가 listen(backlog=511)로 요청한다는 의미.
•  
  tcp-backlog 511
• 하지만 실제 유효 값은:
• 예: tcp-backlog=511, somaxconn=128 → 실제는 128.
  effective backlog = min(tcp-backlog 설정, net.core.somaxconn 값)

4. 왜 중요할까?

• 순간적으로 수천~수만 개 요청이 들어오는데 애플리케이션이 바로 accept()하지 못하면,
  • backlog 큐가 차서 새 연결 요청이 RST로 거절됨.
  • 클라이언트 측에서는 connection refused 또는 timeout 발생.
• 특히 Redis 같은 초고속 RPS 환경에서는 backlog를 넉넉히 주지 않으면 순간 피크에서 연결 실패가 많이 발생할 수 있습니다.

 

관련있는 커널 파라미터

-> net.core.somaxconn

-> net.ipv4.tcp_max_syn_backlog