я бы не стал смешивать всё в кучу. вебсокеты это скриптовые штуки, сами
себя они не читают.
а приоритет неактивных вкладок понижается.


это лишь гипотеза. но тем не менее

вт, 1 дек. 2020 г. в 20:53, Aln Kapa <alnkapa@gmail.com>:

> А вот такое поведение? В какой-то момент chrome перестает что либо
> получать по websocket, если открыть несколько вкладок на разные сайты с
> одним ip.
>
> вт, 1 дек. 2020 г., 2:11 Maxim Dounin <mdounin@mdounin.ru>:
>
>> Hello!
>>
>> On Mon, Nov 30, 2020 at 11:58:59PM +0500, Илья Шипицин wrote:
>>
>> > привет!
>> >
>> > может кто сталкивался, и знает, что с этим можно сделать.
>> > ситуация - хостинг высокой плотности, на одном IP много доменов.
>> > домены разные, каждый со своей бизнес логикой.
>> >
>> > у Chrome включается какая-то оптимизация, и типа "ну раз IP один, то я
>> > буду весь трафик гонять через одно tcp подключение". все бы ничего, но
>> > некоторые сайты иногда рвут соединение. а Chrome в итоге рвет не
>> > подключение до конкретного сайта, а вообще все, которые он умудрился
>> > связать с этим tcp подключением.
>> >
>> > частный пример - сайт, который иногда формирует очень длинные URL, не
>> > помещающиеся в дефолтный http2_max_field_fize, при возникновение такой
>> > ситуации Chrome рвет всё до этого IP адреса.
>> >
>> > как-то не по христиански чтоли.
>> >
>> > подумалось, что аналогичных хостингов высокой плотности в рассылке может
>> > быть достаточное количество. не первый же я с таким столкнулся?
>>
>> Это называется connection reuse, правила прописаны тут:
>>
>> https://tools.ietf.org/html/rfc7540#section-9.1.1
>>
>> В частности:
>>
>> For "https" resources, connection reuse additionally depends on
>> having a certificate that is valid for the host in the URI. The
>> certificate presented by the server MUST satisfy any checks that the
>> client would perform when forming a new TLS connection for the host
>> in the URI.
>>
>> То есть если хочется, чтобы соединения не reuse'ались, можно
>> сконфигурировать разные сертификаты для разных серверов (или групп
>> серверов).
>>
>> Ну либо руками возвращать 421 по необходимости, проверяя $ssl_server_name.
>>
>> --
>> Maxim Dounin
>> http://mdounin.ru/
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru@nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru