클라우드 서버에 붙은 방화벽(보안 그룹)도 연결을 추적하고 유휴 연결의 추적 항목은 정해진 시간 뒤 만료됩니다. 로드밸런서 없이 바로 붙는 서버에서도 가만히 있던 플레이어의 접속이 끊길 수 있습니다.
왜 보안 그룹이 게임 연결을 추적하는 설정(특정 주소만 허용, 나가는 규칙 제한, NLB 경유 등) → 그러면 한동안 유휴 상태인 연결의 추적 항목이 만료되고 그 뒤 오는 패킷을 보안 그룹이 조용히 버림 → 화면에서는 자리 비움 뒤 다시 움직이면 반응이 없다가 접속 끊김. 서버 프로그램은 한참 모름
클라이언트: 가장 짧은 유휴 타임아웃의 절반 이하 간격으로 하트비트 보내기(TCP 350초라면 175초 이하, UDP 스트림 180초라면 90초 이하), 끊기면 자동 재접속. 서버: 하트비트에 응답하고 일정 시간 못 받으면 연결을 먼저 정리, 세션 토큰으로 이어 받기.
인프라팀 할 일
인스턴스의 연결 추적 시간(TcpEstablishedTimeout) 확인·필요하면 늘리기(UDP는 180초가 최대라 못 늘림), 추적이 생기지 않는 보안 그룹 구성 검토(게임 포트는 모든 주소 허용, 나가는 규칙은 전체 허용. NLB를 거치는 연결은 그래도 추적됨), 새 세대 인스턴스로 옮길 때 유휴 시험.
수치 감각
AWS 기준 Nitro v6 인스턴스 유형은 유휴 TCP 연결의 추적 항목을 기본 350초 뒤 지웁니다(그 밖의 유형은 5일). UDP는 요청과 응답이 여러 번 오간 흐름(스트림) 180초, 한 방향으로만 갔거나 요청·응답이 한 번뿐인 흐름 30초가 기본입니다.
그래프에서는
연결이 한꺼번에 끊김 · 끊김 수, 끊기기 전 유휴 시간
확인할 곳
인스턴스의 연결 추적 시간 설정과 보안 그룹 규칙(추적이 생기는 구성인지)을 확인하고, 끊긴 연결의 유휴 시간을 모아 봄. 끊긴 직후 서버에서 ss -tnoi로 그 연결이 ESTABLISHED로 남아 재전송 타이머(timer:(on,…))가 돌고 backoff가 커지는지 봄
이러면 맞음
끊긴 연결의 유휴 시간이 TCP 350초, UDP 스트림 180초, UDP 한 방향 30초 바로 뒤에 몰리고 서버 쪽 소켓은 끊김을 감지하지 못한 채 ESTABLISHED로 남음(서버가 보낼 데이터가 있으면 재전송만 반복)
이러면 아님
보안 그룹이 추적하지 않는 구성(게임 포트를 모든 주소에 허용, 나가는 규칙 전체 허용, NLB를 거치지 않음)이면 이 원인이 아님. NLB를 거치면 “로드밸런서 유휴 타임아웃”과 값을 비교