tl: dr: http-трафик работает надежно и быстро, тогда как https-трафик ненадежен или очень медленный (время загрузки 2-5 минут). Подробности ниже.
Привет, сервер, у меня есть для тебя хороший. Это начало второй недели в новом месте, которое только что расширилось и включило 15-й региональный офис за неделю до моего приема на работу.
В новом офисе используется временное сотовое соединение MPLS, пока мы ждем, пока экипажи подключатся к сети. Новый офис использует то же оборудование и прошивку для MPLS, что и другие 14 офисов, проверенные несколько раз.
Веб-фильтрация и брандмауэр происходит в нашем DC, которого нет в этом новом офисе. Я хочу назвать это концентратором и распределенной сетью, но, поскольку я был нанят во время «очистки», и документация скудна, и я никогда не работал в такой сложной среде, пока я не могу быть уверен.
Эта проблема:
У пользователей есть несколько https-сайтов, которые им нужно использовать для работы. Эти сайты не будут загружаться регулярно, если это все. Если бы мне пришлось ввести число, они загрузили бы одну из 50 попыток, а затем не смогли бы загрузить следующую страницу. Странно то, что заголовки (браузера) и URL-адрес загружаются почти каждый раз, но больше ничего не загружается.
Между тем http загружается нормально.
В этом офисе (как и во всех других филиалах) есть сервер (DC, файловый сервер, DNS), и у него есть проблемы с репликацией, которые могут быть связаны с этой проблемой.
Мы проверили следующее:
Я настраивал, настраивал, играл, читал журналы, двойную / тройную проверку, звонил ISP и гуглил в течение 4 дней, теперь пробую все, что могу найти, и ничего не изменилось (хуже или лучше).
Моя последняя мысль, что это может быть медленное сотовое соединение MPLS (1-3 Мбит / с; 12 пользователей / 12 VoIP-телефонов / 1 сервер), но я продолжаю это исключать, потому что я чувствую, что это также будет присутствовать в HTTP-трафике.
Рад, что у вас есть рабочее решение для этого. Судя по тому, что вы описали, это звучит как Путь MTU Discovery Black Hole вопрос.
По сути, у вас вполне может быть маршрутизатор на вашем маршруте к Интернету с MTU ниже стандартных 1500 байт (1500, вероятно, используется вашими клиентами и веб-серверами, с которыми они общаются). Обычно это не проблема, потому что, когда маршрутизатор получает пакет, который слишком велик для отправки его интерфейса следующего перехода, он отбрасывает пакет и отправляет пакет ICMP Fragmentation Needed обратно отправителю. Этот пакет ICMP включает правильный MTU, поэтому отправитель может отправлять все будущие пакеты с правильным размером.
Проблемы возникают, если пакеты, требующие фрагментации, отбрасываются - возможно, маршрутизатор на пути пересылки имеет слишком агрессивную политику контроля доступа. Это приводит к тому, что отправитель отправляет большие пакеты, которые отбрасываются, но затем обратная связь не отправляется - отправитель просто будет продолжать попытки повторно передать пакеты.
Если вы посмотрите на это со стороны клиента, вы не увидите никакого трафика от отправителя, поэтому вы начнете отправлять зонды Keep Alive.
Как вы описали, вы часто обнаруживаете, что рукопожатие TCP и начальный запрос GET проходят успешно, потому что эти пакеты обычно небольшие. Проблема становится очевидной только после того, как отправитель должен начать отправку полноразмерных пакетов.
Если это проблема, с которой вы столкнулись, вам следует настоятельно рекомендовать тому, кто отвечает за маршрутизаторы на пути пересылки к НЕ отбросить пакеты ICMP Fragmentation Required - это может и сломает работу.
Мы нашли обходной путь (поскольку это временное соединение ... почему бы и нет). Уменьшение MTU до 1200 на рабочих станциях и сетевых интерфейсах серверов полностью устранило эту проблему и увеличило скорость примерно вдвое (с 1-3 Мбит / с до 5-7 Мбит / с).