Чтобы сохранить порядок, TCP не передаёт игре пакеты, пришедшие позже, пока заново не получит один потерянный пакет.
Почему Один пакет теряется → Следствие Следующие пакеты уже пришли, но ждут в буфере приёма → На экране Всё замирает, а потом разом прорывается: перемотка
Основной ответственный Команда разработки · Разработка сервера · Совместно Команда разработки · Разработка клиента
Команда разработки: задачи
Сервер: передавать позиции в реальном времени по UDP, гарантированную доставку оставить только для того, без чего нельзя, разделить данные на несколько потоков (streams). Клиент: перевести сетевую часть на ту же схему, что и сервер (UDP, раздельные каналы доставки).
Цифры для ориентира
Потеря одного пакета даёт остановку минимум на время пути туда и обратно плюс ещё немного, а если потеряется и повторная передача, остановка длится от сотен ms до нескольких секунд.
На графике
Провал, затем пачка · объём приёма по соединениям, число повторных передач
Где смотреть
В захвате пакетов на стороне сервера (tcpdump, Wireshark) найти в соединении этого игрока повторно переданные пакеты и паузы вокруг них, а по серверу в целом смотреть прирост TcpRetransSegs в nstat -az
Подтверждает
Остановка начинается с повторной передачи одного пакета, а сразу после его прихода накопившиеся данные обрабатываются разом (приём держится на 0, а потом идёт пачкой)
Опровергает
К играм на UDP неприменимо. Если повторных передач нет, а остановки есть, смотреть тики сервера («Превышение бюджета тика»)
RFC 5681: TCP Congestion ControlIETF Потеря обнаруживается по 3 дублирующим ACK и запускается быстрая повторная передача, иначе приходится ждать таймер повторной передачи