Я работаю в большом центре обработки данных, и мне поручили устранять неполадки и проблемы с веб-сервером Windows (IIS), который действует как портал для клиента центра обработки данных. Этот сервер портала находится в DMZ в локальном центре обработки данных.
У меня нет доступа к рабочему столу портала, и я полагаюсь на стороннего администратора, который будет работать со мной, чтобы провести тестирование и сообщить о состоянии портала. Он говорит мне, что программные брандмауэры или другие фильтры не настроены.
Хотя большинство удаленных веб-страниц работают нормально, некоторые URL-адреса, которые портал должен обслуживать, не загружаются. Я установил wirehark в портальной системе и сделал снимок одного из сбоев. Я использовал IE для доступа к одному из рассматриваемых удаленных веб-серверов. Я мог видеть, как TCP SYN-ACK возвращается с удаленного сервера, но после того, как несколько HTTP GET не смогли получить ответ, сервер портала отправит сброс.
(ответ на ответ 1: Из захвата, сделанного за пределами межсетевого экрана;
Internet Protocol,
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
<snip>
Transmission Control Protocol
<snip>
Flags: 0x18 (PSH, ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
Похоже, ECN отключен.)
Веб-мастер удаленного веб-сервера уверяет меня, что ни один сайт не блокируется. У меня был снимок, сделанный за пределами локального брандмауэра, поэтому проблем быть не должно.
Другой технический специалист настроил ноутбук и использовал IP-адрес портала (мы отключили портал для тестирования). Ноутбук загружает URL-адрес, как ожидалось. Я попытался загрузить Firefox, чтобы убедиться, что HTTP GET не сформирован неправильно. Тот же сбой, что и с IE.
Итак, похоже, это не удаленный веб-сервер или сеть, потому что с ноутбуком не было проблем.
На данный момент я не знаю, какие еще вопросы задавать или какие тесты делать.
Окончательное решение этой проблемы было найдено в настройках сетевого адаптера на сервере портала. В частности, параметры TCP в реестре. Я сделал полный сброс с помощью netsh (netsh int ip reset resetlog.txt). Эти параметры были определены как наиболее интересные;
"TcpMaxDataRetransmissions" = dword: 0000000a "DefaultTTL" = dword: 00000040 "Tcp1323Opts" = dword: 00000003 "TcpWindowSize" = dword: 00a00000
(Удалите или измените. В настоящее время это ОГРОМНЫЙ размер окна, 10 МБ. Если вы хотите оставить этот параметр жестко запрограммированным, установите его на FAF0 (чуть меньше 64240 байт)).
"GlobalMaxTcpWindowSize" = dword: 00a00000
После выполнения операции netsh URL-адрес, с которым произошел сбой, работал должным образом.
К сожалению, информации для удаленного «анализа» проблемы или предложения чего-либо недостаточно. Есть шанс получить помощь от одного из моих коллег из США: www.wildpackets.com. Они могут проконсультироваться с вами, предоставить вам оценку нашего программного обеспечения или отправить кого-нибудь на место для выполнения работы.
С уважением, Линус
отключить ECN (заполнение бла-бла-бла, потому что сообщение было слишком коротким)