네트워크 최적화

게임 트래픽 우선순위 (DSCP QoS)

RocketUp은 게임 트래픽에 우선순위 태그(DSCP)를 부여합니다. 먼저 Windows의 대역폭 예약(NonBestEffortLimit)을 0으로 낮춰 앱이 가용 대역폭을 즉시 쓸 수 있게 하고, 이어서 게임 UDP 패킷을 DSCP EF(46, Expedited Forwarding — 실시간 트래픽 표준값)로 마킹하는 QoS 정책을 만듭니다. 가정용(비도메인) 네트워크에서도 마킹이 적용되도록 'Do not use NLA' 설정도 함께 켭니다.

중요한 것은 이 효과가 조건부라는 점을 코드가 정직하게 다룬다는 것입니다. DSCP 마킹은 '경로상의 공유기/ISP가 DSCP를 존중할 때만' 실제 우선순위로 작동합니다. 그래서 DSCP 태깅은 부가 기능으로 설계되어, 이것이 실패해도 전체 최적화가 실패로 처리되지 않습니다(대역폭 예약 해제가 성공 기준).

안전을 위해 변경 전 값을 모두 백업하고, 한 번의 롤백으로 대역폭 예약·DSCP 정책·NLA 설정을 원래대로 되돌립니다. 별도로 RocketUp 자체 통신(게임 프로세스가 아닌 앱 트래픽)에만 적용하는 안전한 DSCP 마킹 경로도 있어, 게임 실행 파일 자체는 건드리지 않습니다(안티치트 안전).

적응형 지터 버퍼

패킷이 일정한 간격으로 도착하지 않는 지터(jitter)는 러버밴딩과 스킬 반응 지연의 주요 원인입니다. RocketUp의 지터 버퍼는 고정 배수(예: 평균의 2.5배) 대신, 네트워크의 실제 변동성에 맞춰 버퍼 크기를 동적으로 산정합니다.

내부적으로는 지터의 EWMA 평균과 EWMA 분산(변동성)을 함께 추정하고, 목표 지연을 '평균 + 3×표준편차'로 잡습니다(도착 시각의 약 99%를 포용하는 통계적 여유, RFC 3550 계열 접근). 네트워크가 안정적이면 버퍼를 줄여 지연을 낮추고, 버스티(들쭉날쭉)하면 버퍼를 키워 늦게 도착한 패킷의 유실을 줄입니다. 최종 값은 2ms~120ms 범위로 제한해 과도한 지연이나 무의미한 값을 방지합니다.

MTU 자동 탐색

MTU(한 번에 보낼 수 있는 최대 패킷 크기)가 경로에 맞지 않으면 패킷이 조각나거나 버려져 지연·재전송이 늘어납니다. RocketUp은 ICMP ping에 '조각내지 않음(DF, DontFragment)' 플래그를 걸고, 패킷이 통과하는 최대 크기를 이진 탐색으로 찾습니다.

탐색은 네트워크 종류를 먼저 감지해 합리적인 시작값을 사용합니다(Wi-Fi·테더링 1200, 이더넷 1500). 각 시도에서 페이로드 크기를 'MTU − 28바이트(IP 20 + ICMP 8)'로 계산해 보내고, 성공하면 더 크게, 'PacketTooBig'이거나 타임아웃이면 더 작게 범위를 좁혀 576~1500 사이에서 최적값에 수렴합니다(최대 20회, 무한 루프 방지).

정직성이 이 모듈의 핵심 설계입니다. 탐색이 실제로 성공한 경우에만 최적 MTU를 보고하고, 모든 시도가 실패하면 값을 0으로 두고 실패 원인을 명확히 남깁니다(임의의 그럴듯한 수치를 지어내지 않음). 적용은 netsh로 영구(persistent)+현재 세션(active)을 함께 시도하며, 실패 시 관리자 권한 필요 가능성을 안내합니다.

버퍼블로트 진단과 라우터 SQM(CAKE)

버퍼블로트는 회선이 바쁠 때(다운로드 중) 지연이 급증하는 현상으로, 평상시 핑이 좋아도 게임 중 순간 렉을 만듭니다. RocketUp은 유휴 상태 핑과 다운로드 부하 상태 핑을 각각 측정해 그 차이(부하 중 지연 증가분)를 계산하고 A+~F 등급으로 진단합니다.

근본 해결은 PC가 아니라 공유기에서 이뤄집니다. 그래서 OpenWrt 계열 공유기를 대상으로 CAKE SQM 스크립트를 생성합니다. 이 스크립트는 측정 속도의 92%(다운)/90%(업)로 셰이핑해 큐가 공유기가 아닌 CAKE에서 제어되게 하고, 비대칭 회선용 ack-filter, 기기별 공평 분배(nat dual-srchost/dual-dsthost), 링크 캡슐화 오버헤드 보정, 지연민감 트래픽 분리(diffserv4)를 적용합니다.

자동 적용은 엄격한 안전 파이프라인을 따릅니다. SSH '키 인증'만 사용하고(비밀번호 자동화는 보안상 안 함), sqm 패키지가 없으면 자동 설치하지 않고 안내만 하며, 적용 전 /etc/config/sqm을 스냅샷 백업합니다. 적용 후 연결과 부하 중 지연을 다시 측정해 순수 결정 엔진이 '유지 vs 롤백'을 판정하고, 악화·끊김이면 스냅샷으로 정확 복원합니다. 여러 PC가 같은 공유기를 동시에 건드리지 못하도록 로컬 세마포어 + 라우터측 원자적 락도 둡니다. 자동이 불가능한 환경에서는 단계별 수동 안내로 폴백합니다.

실시간 자동 튠 (게임 감지 → 게이트웨이 핑 → 권고)

RocketUp은 리그 오브 레전드 실행을 감지하면 백그라운드에서 실시간 자동 튠 엔진을 돌립니다. 약 6초 주기로 게이트웨이(공유기)에 여러 번 핑을 보내 RTT·지터·손실을 표본으로 모으고, 최근 10개 표본 윈도로 네트워크 안정성을 평가합니다.

평가 결과에 따라 앱 레벨 파라미터를 권고합니다. 예를 들어 지터가 크거나 손실이 있으면 지터 버퍼를 키우고, 안정적이면 줄여 지연을 낮춥니다. 페이싱(패킷 분산 간격)도 불안정할수록 더 촘촘하게 조정합니다. 안정성 모델 자체는 '미래의 핑 스파이크를 N초 전에 예측'한다고 주장하지 않습니다 — 클라이언트에는 그런 선행 신호가 없기 때문입니다. 대신 버퍼블로트/혼잡으로 인한 '열화 시작'을 감지해 확률적 위험도(러버밴딩 가능 등)로만 표현합니다.

가장 중요한 안전 원칙은, 게임 도중에는 레지스트리·NIC 같은 시스템 설정을 강제로 바꾸지 않는다는 것입니다. 자동 튠은 순수 로직 기반의 앱 파라미터 조정과 로그/이벤트 권고만 합니다. 시스템 재최적화는 연속 '불안정'이 여러 번(기본 3회) 이어질 때에만 '권고'로 올리며, 실제 적용 여부는 사용자 판단에 맡깁니다.

라우터 벤더 식별과 맞춤 QoS 안내

공유기마다 QoS 메뉴 위치와 이름이 다르기 때문에, RocketUp은 게이트웨이 관리자 페이지를 HTTP로 조회해 응답 헤더(Server 등)와 본문의 시그니처로 제조사를 식별합니다. ipTIME(EFM), TP-Link, ASUS, NETGEAR, Linksys, 그리고 OpenWrt/LuCI를 구분합니다.

식별에 성공하면 해당 벤더에 맞는 QoS/대역폭 우선순위 설정 단계를 안내합니다. 예컨대 ipTIME은 '고급설정 → 트래픽 관리 → QoS'로, ASUS는 'Adaptive QoS'로, TP-Link는 'Advanced → QoS'로 게임 기기를 높은 우선순위에 두도록 구체적 경로를 제시합니다. OpenWrt로 식별되면 앞서 설명한 CAKE SQM 자동 적용 경로로 연결됩니다.

여기서도 경계가 분명합니다. RocketUp은 공유기에 자동 로그인하거나 설정을 임의로 바꾸지 않습니다. 펌웨어 버전에 따라 메뉴와 동작이 달라 실하드웨어 검증 없이는 위험하기 때문입니다. 대신 관리자 페이지 URL과 검증된 단계 안내를 제공하고, 식별에 실패하면 'QoS/대역폭 메뉴를 찾아 게임 기기를 상위 우선순위로'라는 일반 안내로 폴백합니다.