<div dir="ltr"><div>я бы не стал смешивать всё в кучу. вебсокеты это скриптовые штуки, сами себя они не читают.</div><div>а приоритет неактивных вкладок понижается.</div><div><br></div><div><br></div><div>это лишь гипотеза. но тем не менее<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">вт, 1 дек. 2020 г. в 20:53, Aln Kapa <<a href="mailto:alnkapa@gmail.com">alnkapa@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">А вот такое поведение? В какой-то момент chrome перестает что либо получать по websocket, если открыть несколько вкладок на разные сайты с одним ip.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">вт, 1 дек. 2020 г., 2:11 Maxim Dounin <<a href="mailto:mdounin@mdounin.ru" target="_blank">mdounin@mdounin.ru</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello!<br>
<br>
On Mon, Nov 30, 2020 at 11:58:59PM +0500, Илья Шипицин wrote:<br>
<br>
> привет!<br>
> <br>
> может кто сталкивался, и знает, что с этим можно сделать.<br>
> ситуация - хостинг высокой плотности, на одном IP много доменов.<br>
> домены разные, каждый со своей бизнес логикой.<br>
> <br>
> у Chrome  включается какая-то оптимизация, и типа "ну раз IP один, то я<br>
> буду весь трафик гонять через одно tcp подключение". все бы ничего, но<br>
> некоторые сайты иногда рвут соединение. а Chrome в итоге рвет не<br>
> подключение до конкретного сайта, а вообще все, которые он умудрился<br>
> связать с этим tcp подключением.<br>
> <br>
> частный пример - сайт, который иногда формирует очень длинные URL, не<br>
> помещающиеся в  дефолтный http2_max_field_fize, при возникновение такой<br>
> ситуации Chrome рвет всё до этого IP адреса.<br>
> <br>
> как-то не по христиански чтоли.<br>
> <br>
> подумалось, что аналогичных хостингов высокой плотности в рассылке может<br>
> быть достаточное количество. не первый же  я с таким столкнулся?<br>
<br>
Это называется connection reuse, правила прописаны тут:<br>
<br>
<a href="https://tools.ietf.org/html/rfc7540#section-9.1.1" rel="noreferrer noreferrer" target="_blank">https://tools.ietf.org/html/rfc7540#section-9.1.1</a><br>
<br>
В частности:<br>
<br>
   For "https" resources, connection reuse additionally depends on<br>
   having a certificate that is valid for the host in the URI.  The<br>
   certificate presented by the server MUST satisfy any checks that the<br>
   client would perform when forming a new TLS connection for the host<br>
   in the URI.<br>
<br>
То есть если хочется, чтобы соединения не reuse'ались, можно <br>
сконфигурировать разные сертификаты для разных серверов (или групп <br>
серверов).<br>
<br>
Ну либо руками возвращать 421 по необходимости, проверяя $ssl_server_name.<br>
<br>
-- <br>
Maxim Dounin<br>
<a href="http://mdounin.ru/" rel="noreferrer noreferrer" target="_blank">http://mdounin.ru/</a><br>
_______________________________________________<br>
nginx-ru mailing list<br>
<a href="mailto:nginx-ru@nginx.org" rel="noreferrer" target="_blank">nginx-ru@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" rel="noreferrer noreferrer" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-ru</a></blockquote></div>
_______________________________________________<br>
nginx-ru mailing list<br>
<a href="mailto:nginx-ru@nginx.org" target="_blank">nginx-ru@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" rel="noreferrer" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-ru</a></blockquote></div>