혼잡 제어로 전송량 급감 Congestion control backoff

원인 ID sk-congestion · 주 담당 인프라팀·서버 인프라 · 함께 게임개발팀·서버 개발

TCP는 손실을 혼잡 신호로 보고 전송 속도를 30~50% 줄입니다. 와이파이 손실에도 똑같이 반응합니다.

왜 보낼 양이 많을 때 와이파이나 회선에서 약간의 손실 발생 → 그러면 TCP가 전송 속도를 크게 줄이고 천천히 회복(리눅스·윈도우 기본인 CUBIC은 30% 줄임) → 화면에서는 사람 많은 곳에서 업데이트가 밀려 몰아치기·입력 지연

증상: 몰아치기, 입력 지연
요인: 지연, 정체
누가 겪나: 나만
언제: 사람이 몰릴 때
담당: 주 담당 인프라팀·서버 인프라 · 함께 게임개발팀·서버 개발
게임개발팀 할 일: 보내는 양 줄이기(관심 영역, 변경분만), 한꺼번에 몰아 보내지 않게 나눠 보내기.
인프라팀 할 일: BBR 같은 혼잡 제어로 바꾸기(tcp_congestion_control).
그래프에서는: 서서히 오르다 뚝 떨어짐 · 연결별 혼잡 윈도우(cwnd)·전송률
확인할 곳: 업데이트가 밀린 유저 연결을 ss -ti로 여러 번 떠서 cwnd·ssthresh 변화와 혼잡 제어 이름(cubic·bbr)을 보고, Send-Q가 쌓이는지 함께 봄
이러면 맞음: 손실 뒤 cwnd가 크게 줄었다가 천천히 오르기를 반복하고 줄어든 동안 Send-Q가 쌓여 몰아치기·입력 지연 제보 시각과 겹침
이러면 아님: cwnd가 넉넉한데도 밀리면 받는 쪽 윈도우(“제로 윈도우 (재전송처럼 보이는 멈춤)”)나 서버 송신 쪽
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처

RFC 9438: CUBIC for Fast and Long-Distance Networks IETF
CUBIC은 손실 때 윈도우를 0.7배(30% 감소), Reno는 0.5배, CUBIC이 리눅스·윈도우·애플 기본
TCP BBR congestion control comes to GCP – your Internet just got faster Google Cloud
손실 기반 혼잡 제어는 혼잡 때문이 아닌 손실에도 전송률을 크게 줄임, BBR은 전달률과 RTT로 판단
IP Sysctl Linux kernel
tcp_congestion_control로 새 연결의 혼잡 제어 알고리즘 선택
ss(8) — Linux manual page iproute2
-i의 cwnd·ssthresh와 혼잡 제어 알고리즘 이름
net/ipv4/tcp_diag.c (Linux v6.12) Linux kernel
ss의 Recv-Q·Send-Q 값: 리슨 소켓은 accept를 기다리는 접속 수와 backlog 한도, 연결된 소켓은 앱이 아직 안 읽은 바이트와 ACK를 받지 못한 송신 바이트