Я запускаю команду systat -tcp в умеренно загруженной системе и вижу что-то вроде этого в 5-секундном окне:
/0 /1 /2 /3 /4 /5 /6 /7 /8 /9 /10
Load Average ||||||||||||
TCP Connections TCP Packets
0 connections initiated 21062 total packets sent
153 connections accepted 16291 - data
153 connections established 125 - data (retransmit by dupack)
11 connections dropped 1 - data (retransmit by sack)
0 - in embryonic state 4271 - ack-only
5 - on retransmit timeout 0 - window probes
0 - by keepalive 217 - window updates
0 - from listen queue 0 - urgent data only
148 - control
0 - resends by PMTU discovery
TCP Timers 21057 total packets received
9752 potential rtt updates 13471 - in sequence
12437 - successful 49 - completely duplicate
763 delayed acks sent 11 - with some duplicate data
140 retransmit timeouts 14 - out-of-order
0 persist timeouts 225 - duplicate acks
0 keepalive probes 12535 - acks
0 - timeouts 0 - window probes
80 - window updates
0 - bad checksum
Почему число отправленных только подтверждений намного превышает число «отправленных отложенных подтверждений» плюс число полученных дублированных данных? Какие ситуации генерируют пакеты только для подтверждения, помимо входящих данных (которые должны проходить через таймер отложенного подтверждения) и полученных дубликатов (немедленное подтверждение). Думаю, Keepalive. Но в этой коробке нет долгоживущих простаивающих соединений. Все коротко и яростно. И там тоже есть строка поддержки активности, которая говорит ноль ...
Что мне здесь не хватает в машине tcp?
Вы, кажется, рассуждаете, что пакеты только для подтверждения должны отправляться только тогда, когда машина либо получает обман, либо когда истекает время таймера, но я не понимаю, почему это может быть правдой. Есть еще одна категория, возможно, более распространенная и важная, чем любая из них, а именно то, что окно подтверждения почти заполнено.
Если другая машина передает вам данные в потоке и отправляет достаточно пакетов, чтобы приблизиться к окну подтверждения, локальная машина отправит ему подтверждение. В общем случае, когда у него нет других данных для отправки, он отправляет пакет только для подтверждения.
Итак, почему есть отложенные подтверждения? Потому что мы не хотим подтверждать каждый отдельный пакет, который отправляет клиент: это приведет к чрезмерному обратному трафику.
Предположим, что окно recv позволит принять 10 входящих пакетов. Удаленная машина отправляет нам один. Нет необходимости подтверждать это сразу, потому что они знают, что могут прислать нам еще до 9. Если они действительно продолжают отправлять пакеты, то, когда мы приближаемся к заполнению окна, мы подтверждаем их передачу.
С другой стороны, если они отправят нам только один пакет, а затем остановятся на некоторое время, мы действительно хотим, по крайней мере, подтвердить, что получили этот один пакет, чтобы они знали, что не нужно повторно передавать его, и чтобы они знали текущее состояние пакета. окно.
Таймер отложенного подтверждения различает эти два случая: позволяет им продолжать, если они отправляют большое количество данных, не позволяя данным оставаться без подтверждения слишком долго.