방화벽이나 리눅스 연결 추적(conntrack, 지나가는 연결을 테이블에 기록하는 기능)은 테이블이 가득 차거나, 연결 상태가 맞지 않는다고 판단하면 패킷을 버립니다.
왜 연결 추적 테이블 가득(table full), 또는 오가는 경로가 달라 한쪽 방향만 방화벽을 지남(비대칭 경로) → 그러면 방화벽이 “모르는 연결”이나 “윈도우 범위를 벗어난 시퀀스 번호”의 패킷으로 보고 폐기 → 화면에서는 테이블이 차면 새 접속이 막히고 경로가 어긋나면 그 경로의 사람만 반복 재전송 끝에 접속 끊김
주 담당 인프라팀·네트워크 인프라 · 함께 인프라팀·서버 인프라, 게임개발팀·서버 개발, 게임개발팀·클라이언트 개발
게임개발팀 할 일
서버: 테이블이 차는 경우에 대비해 로그인 대기열 시스템으로 몰리는 접속 조절, 짧은 연결을 반복하지 않게 연결 재사용(서버 간 호출 포함), 하트비트가 끊긴 연결은 먼저 정리. 클라이언트: 접속이 실패하거나 끊기면 재시도 간격을 늘려 가며 무작위로 분산(테이블이 찼을 때 한꺼번에 다시 몰리지 않게).
인프라팀 할 일
네트워크: 방화벽의 연결 추적 테이블 크기 늘리기, 게임 포트는 연결 추적에서 빼기, 왕복 경로가 같은 방화벽을 지나게 라우팅 맞추기, 방화벽의 TCP 윈도우 검사 설정 확인. 서버 장비·OS: 리눅스 테이블 크기 늘리기(nf_conntrack_max), 게임 포트는 연결 추적에서 빼기(NOTRACK), TCP 윈도우 검사 설정 확인(nf_conntrack_tcp_be_liberal), AWS는 conntrack_allowance_exceeded도 확인.
수치 감각
리눅스 conntrack 기본 한도(nf_conntrack_max)는 메모리에 따라 수만~수십만 개. 현재 개수(nf_conntrack_count)가 한도에 닿으면 로그에 “nf_conntrack: table full, dropping packet”이 남습니다.
그래프에서는
한도에 닿아 평평해짐 · conntrack 항목 수(nf_conntrack_count), 새 접속 실패 수
확인할 곳
리눅스 서버는 nf_conntrack_count와 nf_conntrack_max, dmesg의 “nf_conntrack: table full, dropping packet”, /proc/net/stat/nf_conntrack의 drop·invalid(코어마다 한 줄, 16진수)를 봄. 방화벽은 세션 테이블 사용량과 드롭 로그, AWS는 ethtool -S의 conntrack_allowance_exceeded를 봄
이러면 맞음
항목 수가 한도에서 평평해지고 같은 시각에 table full 로그와 drop, 또는 conntrack_allowance_exceeded가 늘어남. 비대칭 경로면 한도에는 여유가 있는데 invalid와 방화벽 드롭 로그가 특정 경로의 연결에서 늘어남
이러면 아님
항목 수가 한도에서 멀고 invalid·드롭 로그도 그대로면 다른 원인. 테이블은 여유가 있는데 방화벽의 CPU나 초당 패킷 수가 가득하면 “중간 장비 처리 한도 초과”
확인 수단
인프라 도구로 확인(게임 코드 불필요)
출처
Netfilter Conntrack Sysfs variablesLinux kernel nf_conntrack_max 기본값은 해시 버킷 수(메모리÷16384, 1,024~262,144), 현재 개수는 nf_conntrack_count, nf_conntrack_tcp_be_liberal은 윈도우 밖 RST만 INVALID로 처리
net/netfilter/nf_conntrack_core.cLinux kernel 테이블이 가득 차면 “nf_conntrack: table full, dropping packet” 로그를 남기고 폐기(drop 통계 증가), 연결 상태에 맞지 않는 패킷은 invalid 통계 증가