TCP / IP RST отправляется по-разному в разных браузерах

Question

В Mac OS X (10.6), если я запускаю загрузку видео с YouTube и тяну кабель Ethernet примерно на 5 секунд, а затем снова подключаю его, я получаю разные результаты в зависимости от браузера. С Opera и Chrome после подключения кабеля обратно видео продолжает загружаться. Но с Safari и Firefox этого не происходит.

Используя Wireshark для просмотра трафика, я обнаружил, что Opera и Chrome просто получают первый пакет от YouTube после того, как кабель снова подключен, но Safari и Firefox устанавливают флаг RST (0x4) в заголовке TCP, и нет больше трафика.

Я могу установить концентратор между устройством и интернет-соединением, проблема исчезнет, ​​и все четыре браузера продолжат загружать видео, когда кабель снова подключен к концентратору. Опять же, просматривая журналы Wireshark, видно, что машина не видит близкое соединение Mulitcast и просто происходит задержка в прохождении пакетов.

Так что, похоже, что если Safari и Firefox увидят, что Multicast-соединение закрывается, а затем увидят данные по тому же соединению, они отправят RST.

Мой вопрос - почему? Каков правильный курс действий, и почему 2/4 браузеров делают это одним способом, в то время как другие 2/4 делают это другим способом? Есть ли где-нибудь в коде, что я могу видеть, где это происходит в Firefox, например?

Большое спасибо.

Answer 1

Когда вы тянете за кабель, ваш интерфейс отключается, и последующие пакеты должны получить «ICMP NO ROUTE TO HOST». Тогда дело за приложением, что с этим делать: ты сдаешься немедленно или ждешь дольше? Похоже, Firefox и Safari не ждут дольше.

Когда вы оставляете концентратор на месте, ваш компьютер не знает, что он потерял маршрут к хосту, поэтому сообщение не появляется.

НТН,

Answer 2

Кажется, что Firefox и Safari удаляют TCP-соединение из своего списка открытых соединений, когда они видят закрытое многоадресное соединение.

Как только TCP-соединение закрыто, разумное поведение при попытке отправить на него пакетыэто отправить пакет RST.

Answer 3

Я понимаю, что это старый вопрос, но я полагаю, что необходима более подробная информация, поскольку у меня возникли подобные проблемы, и у меня было много проблем с поиском каких-либо ресурсов.

Основано на моем опыте и исследованииавтором факультета компьютерных наук Университета Калгари было установлено, что в отношении ответов пакетов TCP RST:

... что поведение браузера уровня приложения является основнымвклад в глобальную тенденцию ненормального поведения TCP.В частности, причиной этой проблемы являются нарушения в реализации и управлении постоянными HTTP-соединениями.Исправление поведения TCP популярного веб-браузера, скорее всего, устранит большинство этих аномалий TCP RST.

По сути, это означает, что браузеры по-разному реализуют поведение сброса TCP, и в результате вы видите другое поведение.Более того, похоже, что разные операционные системы также по-разному реализуют заголовки TCP RST , поэтому даже использование одного и того же браузера в другой ОС может привести к несколько иным результатам, поэтому может быть добавление промежуточного концентратора для разрешенияпроблема.

Я считаю, что эта проблема в трекере ошибок Chromium связана с , почему Chrome работает .Аналогичная вещь была введена в Firefox в 2010 году

Если для новой группы сокетов соединение выполняется слишком долго, выполните один резервный запрос сокета, чтобы повторить попытку соединения.Это уменьшает задержку при потере пакета.

Некоторые браузеры будут агрессивно разрывать соединение с одним RST-пакетом (IE 11 / Safari 9/10 по крайней мере из моих тестов).Google Chrome (протестированная версия v56), основанный на данных в chrome: // net-internals, по-видимому, использует тот же сокет для повторной попытки после получения ошибки ERR_CONNECTION_RESET -103.Затем он повторяет несколько раз, пока не добьется успеха.Я считаю, что это интеллектуальное повторное поведение может быть причиной того, что некоторые браузеры перезапускают потерянные соединения.Хотя он может не реализовывать соответствующий RFC или Spec (я не могу найти точный, он может быть для HTTP / 1.1 или просто Сброс TCP )

Мой опыт сегодня включал Keep Aliveнаходясь в Apache, за WAF / балансировщиком нагрузки Big-IP F5, который маршрутизировал трафик на основе шаблона URL-адреса одной из двух групп виртуальных серверов.Отключение поддержки активности в Apache решило нашу проблему с возвращением пакетов TCP RST и прерыванием соединений.