728x90
반응형
TCP 통신을 모니터링하다 보면 Zero Window라는 메시지를 볼 때가 있다. 네트워크 지연이나 데이터 전송 중단의 원인이 되기 때문에, 이 개념을 명확히 이해하는 것이 중요하다.
🔍 Zero Window란?
Zero Window는 TCP 수신 측(receiver) 의 버퍼가 가득 차서, 더 이상 데이터를 받을 수 없을 때 발생하는 상태다.
TCP는 데이터 흐름을 제어하기 위해 윈도우 크기(Window Size) 를 사용한다.
이 값은 “수신 측에서 지금 받을 수 있는 데이터의 양(바이트)”을 의미한다.
- 정상 상태: 수신 측이 버퍼에 여유가 있어 Window Size > 0
- Zero Window 상태: 버퍼가 꽉 차서 Window Size = 0
즉, 수신 측이 “잠깐! 버퍼 꽉 찼어. 데이터 전송 멈춰줘.”라고 송신 측에게 신호를 보내는 것이다.
⚙️ 동작 과정
- 정상 통신
- 수신 측은 송신 측에 “내 버퍼 여유가 8192바이트야”라고 알림.
- 송신 측은 해당 범위 안에서 데이터를 보냄.
- 버퍼 포화 발생
- 수신 측의 버퍼가 모두 차면, TCP 헤더의 Window Size를 0으로 설정.
- 송신 측은 더 이상 데이터를 보내지 않음.
- Zero Window Probe
- 송신 측은 일정 시간 후 작은 데이터(1바이트)를 보내 수신 측 상태를 확인함.
- 이를 Zero Window Probe라고 함.
- 수신 측이 여유 공간이 생기면, 다시 ACK + Window Size를 갱신하며 데이터 전송 재개.
📈 Wireshark 예시
TimeSourceDestinationInfo
| 0.500 | 10.0.0.1 | 10.0.0.2 | TCP [ACK] Window=0 |
| 1.000 | 10.0.0.1 | 10.0.0.2 | TCP ZeroWindowProbe |
| 1.002 | 10.0.0.2 | 10.0.0.1 | TCP [ACK] Window=4096 |
이처럼 Zero Window → Probe → ACK(Window > 0) 순서로 회복된다.
⚠️ 주요 원인
- 애플리케이션이 데이터를 처리하지 못해 버퍼가 가득 찬 경우
- 수신 버퍼 크기(socket buffer) 가 너무 작을 때
- CPU 부하나 I/O 병목으로 데이터 처리 지연
- 비정상적인 TCP 세션 유지 (deadlock 상태)
🚨 문제점
- 송신 측 전송이 멈추면서 지연(latency) 증가
- 대량의 Zero Window 발생 시 네트워크 혼잡
- 세션 타임아웃 및 연결 종료 위험
🧩 해결 방법
원인해결 방법
| 버퍼 크기 부족 | OS 레벨에서 TCP 수신 버퍼 크기 확대 (net.core.rmem_max 등) |
| 애플리케이션 처리 지연 | 비동기 처리 또는 멀티스레드 구조로 개선 |
| 불필요한 연결 유지 | 연결 타임아웃 관리 (keep-alive, idle timeout 조정) |
| 주기적 모니터링 필요 | Wireshark, netstat, ss, Dynatrace, Prometheus 등으로 상태 감시 |
🧠 정리
항목설명
| 정의 | TCP 수신 측 버퍼가 가득 차 전송이 일시 중단된 상태 |
| 표시 | TCP Header의 Window Size = 0 |
| 영향 | 송신자 전송 중단, 성능 저하, 지연 발생 |
| 해결 | 버퍼 크기 조정, 애플리케이션 개선, 모니터링 강화 |
728x90
반응형