한국어 English 日本語简体中文繁體中文 Deutsch ไทย Tiếng Việt Русский Português (Brasil)Español Bahasa Indonesia

순차 왕복이 많은 프로토콜 (chatty) Chatty protocol / sequential round trips

원인 ID sy-chatty · 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발

조작 한 번에 서버 왕복이 여러 번 순서대로 필요하면, 핑이 그 횟수만큼 곱해집니다.

왜 상점 열기 → 목록 요청 → 가격 확인 → 구매 → 인벤토리 갱신을 각각 따로 요청 → 그러면 앞 요청의 답을 받아야 다음 요청을 보냄 → 화면에서는 핑 150ms에서 한 번 사는 데 1초 가까이. 로딩이 유난히 김

증상: 입력 지연, 접속 불가·무한 로딩
요인: 지연
누가 겪나: 특정 기능만, 나만
언제: 특정 행동을 할 때, 접속·점검 직후
담당: 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발
게임개발팀 할 일: 서버: 여러 단계를 한 번에 묶어 요청·응답하도록 프로토콜 변경(예: 구매 응답에 갱신된 인벤토리를 함께 담기). 클라이언트: 필요한 데이터를 미리 받아 두기, 결과를 기다리지 않는 UI.
수치 감각: 걸리는 시간 ≈ 왕복 수 × (핑 + 서버 처리 + 틱 대기). 5번이면 핑 150ms에서 약 0.85~1초.
그래프에서는: 처음부터 늘 높음 · 기능별 완료 시간, 조작 한 번의 왕복 수
확인할 곳: 서버 쪽 패킷 캡처(Wireshark)에서 시험 계정으로 상점 구매·로그인 같은 조작을 한 번 하는 동안 요청과 응답이 몇 번 번갈아 오가는지와 그 간격을 셈. 서버 요청 로그가 있으면 세션 ID로 묶어 요청 수와 요청별 도착·응답 시각을 봄
이러면 맞음: 조작 하나에 요청이 앞 응답을 기다렸다가 차례로 여러 번 오가고 완료 시간이 대략 왕복 수 × RTT이며 핑이 높은 지역 유저일수록 같은 기능이 비례해서 느림
이러면 아님: 왕복은 한두 번인데 응답 하나가 오래 걸리면 서버 처리·DB 쪽 원인. 핑과 상관없이 모든 유저가 똑같이 느리면 서버 부하를 봄
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처

Chatty I/O antipattern Microsoft Azure
작은 I/O 요청이 많으면 누적 지연이 응답성을 크게 떨어뜨림. 요청을 더 크고 적게 묶으라는 권고

순차 왕복이 많은 프로토콜 (chatty) Chatty protocol / sequential round trips

출처

함께 보면 좋은 원인

같은 층: 동기화 설계

같은 증상(입력 지연)의 다른 층 원인