Я использую firefox для посещения веб-сервера, работающего на компьютере в моей локальной сети. Я заметил, что иногда TCP не подтверждает пакеты, которые он получает. Например, в следующих захваченных пакетах:
https://docs.google.com/file/d/0B-LaBUj9KtQhS0RYNXF1RjZTa2M/edit?usp=sharing
7-й, 9-й и 11-й пакеты дублируются ACK, браузер получает TCP-пакеты 6,8 и 10, но стек TCP браузера не подтверждает полученные пакеты, почему?
Это не так.
Он просто подтверждает каждый байт потока, который совершенно другой. По какой-то причине TCP получателя (тот, на котором запущен браузер) пропускает сегмент №6. Поскольку получатель немедленно запрашивает повторную передачу, он должен получить его с несоответствием контрольной суммы.
Все последующие полученные сегменты (8, 10, 12) являются неупорядоченными сегментами и запускают дублирующиеся подтверждения, цель состоит в том, чтобы запросить повторную передачу сегмента # 6. Поскольку путь связи между получателем и отправителем испытывает некоторую задержку, отправитель замечает это немного поздно, уменьшает длину своего канала (также известное как окно перегрузки) и повторно передает данные, содержащиеся в сегменте № 6.
Затем в сегменте № 15 происходит еще одна интересная вещь: получатель не отправляет совокупное подтверждение за 8, 10, 12, а подтверждает только сегмент № 14, что означает, что он отбросил 8, 10 и 12 либо потому, что они также были подвержены данным коррупция или потому что это очень простая реализация TCP. Вы можете включить оценку контрольной суммы TCP в wireshark (здесь она не выполняется на каждом исходящем сегменте из-за того, что ОС оставляет поле контрольной суммы недопустимым для оценки картой Ethernet), и это подтверждает прежнюю интерпретацию: ошибки контрольной суммы 8, 10, 12. Там должна быть очень шумная ссылка на пути.
Оно делает.
Вы, вероятно, видите задержанное подтверждение TCP, в котором получатель может задержать до 500 мс для отправки комбинированного пакета ACK, который подтверждает получение нескольких пакетов. Это хорошо для уменьшения накладных расходов, когда у вас много пакетов и вы не особенно заботитесь о задержке.
Это может увеличить воспринимаемую задержку, и поэтому эту функцию вы видите отключенной во многих "Исправлениях TCP", которые можно найти для игр: установив для TCP_ACKNOWLEDGE_DELAY значение 0, Windows немедленно отправит все ACK вместо попыток сгруппировать их. Это имеет обратную сторону создания большего сетевого трафика, с небольшой выгодой. Это создает видимость снижения задержки, но пакеты данных не отправляются быстрее.
