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

FreeBSD медленная передача - проблема масштабирования RFC 1323?

Я думаю, что у меня может быть проблема с масштабированием окна (RFC 1323), и я надеюсь, что кто-то сможет просветить меня о том, что происходит.

Сервер: FreeBSD 9, apache22, обслуживает статический zip-файл размером 100 МБ. 192.168.18.30
Клиент: Mac OS X 10.6, Firefox 192.168.17.47
Сеть: Только переключатель между ними - подсеть 192.168.16 / 22 (в этом тесте у меня также есть dummynet-фильтрация, имитирующая время пинга 80 мс для всего IP-трафика. Я видел почти идентичные трассировки с "реальной" настройкой, с реальной интернет-трафик / задержка также)

Вопросы:

Это нормально?
В пакете № 2 указан размер окна 65535 и масштаб 512?
Уменьшает ли пакет № 5 размер окна, чтобы он мог использовать масштаб 512 и при этом сохранить общий расчетный размер окна около 64 КБ?
Почему масштаб окна такой высокий?

Вот первые 6 пакетов от wirehark. Для пакетов 5 и 6 я включил подробную информацию, показывающую размер окна и коэффициент масштабирования, используемые для передачи данных.

No. Time Source Destination Protocol Length Info

108 6.699922 192.168.17.47 192.168.18.30 TCP 78 49190 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=8 TSval=945617489 TSecr=0 SACK_PERM=1

115 6.781971 192.168.18.30 192.168.17.47 TCP 74 http > 49190 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=512 SACK_PERM=1 TSval=2617517338 TSecr=945617489

116 6.782218 192.168.17.47 192.168.18.30 TCP 66 49190 > http [ACK] Seq=1 Ack=1 Win=524280 Len=0 TSval=945617490 TSecr=2617517338

117 6.782220 192.168.17.47 192.168.18.30 HTTP 490 GET /utils/speedtest/large.file.zip HTTP/1.1

118 6.867070 192.168.18.30 192.168.17.47 TCP 375 [TCP segment of a reassembled PDU]

Подробности:

Transmission Control Protocol, Src Port: http (80), Dst Port: 49190 (49190), Seq: 1, Ack: 425, Len: 309
Source port: http (80)
Destination port: 49190 (49190)
[Stream index: 4]
Sequence number: 1 (relative sequence number)
[Next sequence number: 310 (relative sequence number)]
Acknowledgement number: 425 (relative ack number)
Header length: 32 bytes
Flags: 0x018 (PSH, ACK)
Window size value: 130
[Calculated window size: 66560]
[Window size scaling factor: 512]
Checksum: 0xd182 [validation disabled]
Options: (12 bytes)
No-Operation (NOP)
No-Operation (NOP)
Timestamps: TSval 2617517423, TSecr 945617490
[SEQ/ACK analysis]
TCP segment data (309 bytes)

1.) 512 на самом деле не является высоким масштабом окна - он просто говорит о сдвиге предлагаемого размера окна влево на 9 бит. Установка размера окна на 130 (в противном случае очень и очень низкое значение), а затем применение коэффициента масштабирования 512 дает вам 66560 (130 << 9).

2.) 100M - это, вероятно, слишком маленький файл. Тот факт, что масштабы согласовывались, говорит о том, что дела идут нормально. Попробуйте использовать файл большего размера, чтобы лучше наблюдать за поведением. По крайней мере, вы получите лучшее представление о реальной пропускной способности.

3.) Также имейте в виду, что поведение определенных клиентов может фактически переопределить поведение ОС - например, встроенный FTP-клиент в Solaris используется для ограничения размера окна до 64 КБ независимо от того, как была настроена ОС.

Я получил сообщение от команды системного администратора, что эта проблема была вызвана какой-то проблемой с сетевым драйвером VMWare, который не соблюдает / не играет хорошо с настройками sysctl. Пропускная способность с той же настройкой на физическом оборудовании имеет пропускную способность с разумным процентом для канала, а не 1/10 или меньше, что мы видели с VMware.