문제 25 — SYN 플러드와 연결 고갈 방어: SYN 쿠키·백로그·accept 큐 vs SYN 큐

게임 로그인 서버가 공개 포트로 TCP 연결을 받는다. 어느 순간 정상 사용자들이 "접속이 안 된다"고 몰려오는데, 서버 CPU·애플리케이션은 멀쩡하고 accept() 로는 새 연결이 거의 안 들어온다. netstat 을 보면 SYN_RECV 상태의 반쯤 열린 연결이 수만 개다.

다음을 설명하라.

1. 3-way 핸드셰이크와 두 개의 큐: 커널이 연결을 수립하는 동안 half-open 연결(SYN 큐)과 완성된 연결(accept 큐)을 어떻게 관리하는가? SYN_RECV 상태는 무엇이며, 애플리케이션의 accept() 는 어느 큐에서 꺼내는가?

2. SYN 플러드 공격의 원리: 공격자가 SYN 만 보내고 최종 ACK 를 안 보내면(또는 위조 출발지 IP 로 보내면) 왜 정상 사용자가 접속하지 못하게 되는가? 어떤 자원이 고갈되는가?

3. SYN 쿠키(SYN cookies): SYN 큐를 아예 쓰지 않고 half-open 상태를 서버가 기억하지 않으면서도 핸드셰이크를 완성하는 원리를 설명하라. 서버는 무엇을 초기 시퀀스 번호에 인코딩하는가? SYN 쿠키의 한계(옵션 손실 등)는?

4. 운영 방어: net.core.somaxconn, tcp_max_syn_backlog, tcp_syncookies, 연결 rate limiting, SYN 프록시/앞단 로드밸런서, 방화벽 등 실무에서 쓰는 방어 수단을 정리하고, 게임 로그인 서버 맥락에서 어떤 조합을 택할지 논하라.

5. 애플리케이션 레벨과의 구분: 이 문제(커널 TCP 핸드셰이크 계층의 half-open 고갈)와, 애플리케이션이 accept 후 인증·핸드셰이크를 처리하는 단계의 고갈(slowloris 류, accept 큐/워커 고갈)은 어떻게 다른가? 각각 어디서 방어해야 하는가?