<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">вт, 1 дек. 2020 г. в 18:43, Maxim Dounin <<a href="mailto:mdounin@mdounin.ru">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 Tue, Dec 01, 2020 at 06:18:32PM +0500, Илья Шипицин wrote:<br>
<br>
> вт, 1 дек. 2020 г. в 18:13, Maxim Dounin <<a href="mailto:mdounin@mdounin.ru" target="_blank">mdounin@mdounin.ru</a>>:<br>
> <br>
> > Hello!<br>
> ><br>
> > On Tue, Dec 01, 2020 at 10:52:48AM +0500, Илья Шипицин wrote:<br>
> ><br>
> > > вт, 1 дек. 2020 г. в 04:11, Maxim Dounin <<a href="mailto:mdounin@mdounin.ru" target="_blank">mdounin@mdounin.ru</a>>:<br>
> > ><br>
> > > > 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>
> > то я<br>
> > > > > буду весь трафик гонять через одно tcp подключение". все бы ничего,<br>
> > но<br>
> > > > > некоторые сайты иногда рвут соединение. а Chrome в итоге рвет не<br>
> > > > > подключение до конкретного сайта, а вообще все, которые он умудрился<br>
> > > > > связать с этим tcp подключением.<br>
> > > > ><br>
> > > > > частный пример - сайт, который иногда формирует очень длинные URL, не<br>
> > > > > помещающиеся в  дефолтный http2_max_field_fize, при возникновение<br>
> > такой<br>
> > > > > ситуации Chrome рвет всё до этого IP адреса.<br>
> > > > ><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" 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 по необходимости, проверяя<br>
> > $ssl_server_name.<br>
> > > ><br>
> > ><br>
> > > в исходниках это вот так<br>
> > ><br>
> > >     if ((size_t) len > h2scf->max_field_size) {<br>
> > >         ngx_log_error(NGX_LOG_INFO, h2c->connection->log, 0,<br>
> > >                       "client exceeded http2_max_field_size limit");<br>
> > ><br>
> > >         return ngx_http_v2_connection_error(h2c,<br>
> > > NGX_HTTP_V2_ENHANCE_YOUR_CALM);<br>
> > >     }<br>
> > ><br>
> > ><br>
> > > как можно в этом месте вернуть "по необходимости" 421 ?<br>
> ><br>
> > Нет, это фатальная ошибка для соединения, дальнейшая работа с этим<br>
> > соединением невозможна.  Возвращать 421 надо заранее, до того, как<br>
> > придёт кривой запрос.<br>
> ><br>
> ><br>
> пардон. я не понимаю, что вы предлагаете.<br>
> можете привести пример, как сделать ?<br>
<br>
Если добавить что-нибудь вроде:<br>
<br>
    if ($ssl_server_name != "<a href="http://example.com" rel="noreferrer" target="_blank">example.com</a>") {<br>
        return 421;<br>
    }<br></blockquote><div><br></div><div>идею понял, протестируем<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
во все релевантные блоки server{}, это предотвратит reuse <br>
соединений, кроме первых запросов.  Соответственно соединения <br>
будут отдельными, и при необходимости закрыть соединение - будет <br>
закрываться только соединение с одним сервером, а не со всеми <br>
серверами на данном IP.<br>
<br>
Ну и обращаю внимание на озвученный выше и проигнорированный <br>
вариант разных сертификатов.  Он позволяет контроллировать <br>
поведение на стороне браузера и соответственно более эффективен, <br>
т.к. нет проблемы первых запросов.<br></blockquote><div><br></div><div>если это вайлдкард, где я возьму разных сертификатов</div><div><br></div><div><br></div><div><br></div><div>вообще, я расчитывал на <br></div><div><br></div><div>1) более адекватное поведение хрома (хотя о чем это я)</div><div>2) более адекватное поведение nginx с учетом пункта "1", например, вместо фатального для браузера GO AWAY, отвечать 421<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
-- <br>
Maxim Dounin<br>
<a href="http://mdounin.ru/" rel="noreferrer" target="_blank">http://mdounin.ru/</a><br>
_______________________________________________<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></div>