вт, 1 дек. 2020 г. в 18:43, Maxim Dounin <mdou...@mdounin.ru>:
> Hello! > > On Tue, Dec 01, 2020 at 06:18:32PM +0500, Илья Шипицин wrote: > > > вт, 1 дек. 2020 г. в 18:13, Maxim Dounin <mdou...@mdounin.ru>: > > > > > Hello! > > > > > > On Tue, Dec 01, 2020 at 10:52:48AM +0500, Илья Шипицин wrote: > > > > > > > вт, 1 дек. 2020 г. в 04:11, Maxim Dounin <mdou...@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. > > > > > > > > > > > > > в исходниках это вот так > > > > > > > > if ((size_t) len > h2scf->max_field_size) { > > > > ngx_log_error(NGX_LOG_INFO, h2c->connection->log, 0, > > > > "client exceeded http2_max_field_size limit"); > > > > > > > > return ngx_http_v2_connection_error(h2c, > > > > NGX_HTTP_V2_ENHANCE_YOUR_CALM); > > > > } > > > > > > > > > > > > как можно в этом месте вернуть "по необходимости" 421 ? > > > > > > Нет, это фатальная ошибка для соединения, дальнейшая работа с этим > > > соединением невозможна. Возвращать 421 надо заранее, до того, как > > > придёт кривой запрос. > > > > > > > > пардон. я не понимаю, что вы предлагаете. > > можете привести пример, как сделать ? > > Если добавить что-нибудь вроде: > > if ($ssl_server_name != "example.com") { > return 421; > } > идею понял, протестируем > > во все релевантные блоки server{}, это предотвратит reuse > соединений, кроме первых запросов. Соответственно соединения > будут отдельными, и при необходимости закрыть соединение - будет > закрываться только соединение с одним сервером, а не со всеми > серверами на данном IP. > > Ну и обращаю внимание на озвученный выше и проигнорированный > вариант разных сертификатов. Он позволяет контроллировать > поведение на стороне браузера и соответственно более эффективен, > т.к. нет проблемы первых запросов. > если это вайлдкард, где я возьму разных сертификатов вообще, я расчитывал на 1) более адекватное поведение хрома (хотя о чем это я) 2) более адекватное поведение nginx с учетом пункта "1", например, вместо фатального для браузера GO AWAY, отвечать 421 > > -- > 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
