Медленная передача 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 пакетов от wireshark. Для пакетов 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)
Источник

2 ответа

Решение

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

Источник

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

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

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

Источник
Другие вопросы по тегам