Назад | Перейти на главную страницу

Когда механизм TCP решает отправить ACK?

В моей локальной сети у меня есть маршрутизатор, на котором работает сервер Samba, и мой компьютер подключается к маршрутизатору.

Я проводил wirehark во время загрузки на сервер и загрузки с сервера.

Результаты wirehark показывают, что:

Как следствие, при загрузке создается около 120 000 кадров, а при загрузке - только 70 000 кадров. И скорость загрузки составляет около 12,7 МБ / с, а скорость загрузки - 20 МБ / с.

Итак, я хочу выяснить возможную причину этого.

В основном есть два механизма для уменьшения количества возвращаемых пакетов ACK - алгоритм Нэгла и отложенные ACK - оба описаны в RFC 1122. Оба являются необязательными, поэтому будут хосты, которые либо настроены не использовать их, либо не имеют соответствующей реализации. В частности, Samba можно проинструктировать отключить алгоритм Нэгла, используя socket options = TCP_NODELAY в конфигурации.

Однако разница в скорости передачи данных в восходящем / нисходящем направлениях для копий файлов SMB, скорее всего, вызвана другими причинами, а не обилием пакетов TCP ACK.

Реализация TCP подтверждает каждый второй пакет данных. Таким образом, вы должны увидеть, как правило, два полученных пакета данных, а затем отправленный ACK. Отправитель, конечно же, все равно не ждет ACK. Он будет продолжать передачу до тех пор, пока окно не заполнится, даже при отсутствии ACK.

Здесь потенциально могут действовать и другие факторы, такие как Nagle и отложенный ACK. Но не похоже, что вы видите их влияние.