path: root/files/ru/web/http/connection_management_in_http_1.x/index.html

---
title: Connection management in HTTP/1.x
slug: Web/HTTP/Connection_management_in_HTTP_1.x
translation_of: Web/HTTP/Connection_management_in_HTTP_1.x
---
<div>{{HTTPSidebar}}</div>

<p class="summary">Управление соединением является ключевой темой HTTP: открытие и поддержка соединения оказывает значительное влияние на производительность веб-сайтов и веб-приложений. В HTTP/1.x имеются следующие модели: <em>краткосрочные соединения, постоянные соединения и конвейерная обработка HTTP (</em><em>HTTP pipelining). </em></p>

<p>В качестве транспортного протокола, обеспечивающего связь между клиентом и сервером, HTTP по большей части использует TCP. Это краткосрочные (short-lived) соединения: при каждой отправке запроса открывается новое соединение, которое закрывается после того, как ответ получен.</p>

<p>Такой модели присущи проблемы в отношении производительности: ресурсы приходится затрачивать на открытие каждого соединения TCP. Клиенту и сервером необходимо обмениваться несколькими сообщениями. При отправке каждого запроса приходится считаться с запаздыванием и пропускной способностью сети. Современным веб-страницам требуется выполнять множество (десятки) запросов для передачи необходимой информации, что делает данную модель неэффективной.</p>

<p>В HTTP/1.1 были созданы две новые модели.  Модель постоянного соединения оставляет соединение открытым между последовательными запросами, экономя время, требуемое для открытия новых соединений. Модель конвейерной обработки HTTP делает следующий шаг - она позволяет отсылать несколько запросов подряд, не дожидаясь ответа, что существенно сокращает время ожидания в сети.</p>

<p><img alt="Compares the performance of the three HTTP/1.x connection models: short-lived connections, persistent connections, and HTTP pipelining." src="https://mdn.mozillademos.org/files/13727/HTTP1_x_Connections.png" style="height: 538px; width: 813px;"></p>

<div class="note">
<p>В HTTP/2 внесены дополнительные модели управления соединением.</p>
</div>

<p>Важно отметить, что управление соединением в HTTP применяется к соединению между двумя последовательными узлами, и является пошаговым (<a href="/en-US/docs/Web/HTTP/Headers#hbh">hop-by-hop</a>) а не "конец-к-концу"  (<a href="/en-US/docs/Web/HTTP/Headers#e2e">end-to-end)</a>. Модель, используемая для соединения клиента с его первым прокси, может отличаться от модели соединения между прокси и конечным сервером (или любым из промежуточных серверов). Заголовки HTTP, вовлеченные в определение модели соединения, типа HTTPHeader("Connection")}} и {{HTTPHeader("Keep-Alive")}}, являются <a href="/en-US/docs/Web/HTTP/Headers#hbh">пошаговыми</a> заголовками, значения которых могут изменяться промежуточными узлами.</p>

<h2 id="Краткосрочные_соединения_Short-lived_connections">Краткосрочные соединения (Short-lived connections)</h2>

<p>Исходной моделью в HTTP, в HTTP/1.0 она же является моделью по умолчанию, являются <em>краткосрочные соединения</em> <em>(short-lived connections)</em>. Для каждого HTTP запроса используется отдельное соединение; это означает, что "рукопожатие" TCP происходит перед каждым из запросов HTTP, идущих один за другим.</p>

<p>TCP-рукопожатие само по себе затратно по времени, но TCP-соединения приспособились справляются с этой нагрузкой, превращаясь в устойчивые (или теплые) соединения. Краткосрочные соединения не используют это полезное свойство TCP, так что эффективность оказывается ниже оптимальной из-за того что передача осуществляется по новому, холодному соединению.</p>

<p>Данная модель является моделью по умолчанию в HTTP/1.0 (при отсутствии заголовка {{HTTPHeader("Connection")}}, или когда его значением является<code> close</code>). В HTTP/1.1 такая модель используется только если заголовок {{HTTPHeader("Connection")}} посылается со значением <code>close</code>.</p>

<div class="note">
<p>Если речь не идет об очень старой, не поддерживающей постоянные соединения, системе, данную модель использовать нет смысла.</p>
</div>

<h2 id="Постоянные_соединения">Постоянные соединения</h2>

<p>Краткосрочные соединения имеют два больших недостатка: требуется значительное время на установку нового соединения, и то, что эффективность TCP-соединения улучшается только по прошествии некоторого времени от начала его использования (теплое соединение). Для решения этих проблем была разработана концепция <em>постоянного соединения (persistent connection</em>), еще до появления HTTP/1.1. Его также называют <em>соединением keep-alive</em>.</p>

<p>Постоянным называют соединение, которое остается открытым некоторый период времени и может быть использовано для нескольких запросов, благодаря чему отпадает необходимость в новых рукопожатиях TCP и используются средства повышения производительности TCP. Это соединение остается открытым не навсегда: праздные соединения закрываются по истечению некоторого времени (для задания минимального времени, на протяжении которого соединение должно оставаться открытым, сервер может использовать заголовок {{HTTPHeader("Keep-Alive")}}).</p>

<p>У постоянных соединений есть свои недочеты; даже работая вхолостую, они потребляют ресурсы сервера, а при высокой нагрузке могут проводиться {{glossary("DoS attack", "DoS attacks")}}. В таких случаях большую эффективность могут обеспечить не постоянные соединения, которые закрываются как только освободятся.</p>

<p>Соединения HTTP/1.0 по умолчанию не являются постоянными. Для превращения их в постоянные надо присвоить заголовку {{HTTPHeader("Connection")}} значение, отличное от <code>close</code> - обычно <code>retry-after.</code></p>

<p>В HTTP/1.1 соединения являются постоянными по умолчанию, так что этот заголовок больше не требуется (но часто добавляется в качестве защитной меры на случай, если потребуется откат к HTTP/1.0).</p>

<h2 id="Конвейерная_обработка_в_HTTP_HTTP_pipelining">Конвейерная обработка в HTTP (HTTP pipelining)</h2>

<div class="note">
<p>Конвейерная обработка HTTP в современных браузерах не активирована по умолчанию:</p>

<ul>
 <li><a href="https://en.wikipedia.org/wiki/Proxy_server">Прокси</a> с багами все еще встречаются, что приводит к странным и непредсказуемым явлениям, которые веб-разработчикам трудно предсказать и диагностировать.</li>
 <li>Конвейерную обработку сложно правильно реализовать: объем передаваемых ресурсов, используемая <a href="https://en.wikipedia.org/wiki/Round-trip_delay_time">RTT</a> и эффективная пропускная способность имеют непосредственное влияние на те улучшения, что обеспечиваются конвейерной обработкой. Конвейерная обработка HTTP, таким образом, дает существенное улучшение не во всех случаях.</li>
 <li>Конвейерная обработка подвержена проблеме <a href="https://en.wikipedia.org/wiki/Head-of-line_blocking">HOL</a>.</li>
</ul>

<p>По этим причинам в HTTP/2 на смену конвейерной обработке пришел новый алгоритм, <em>мультиплексность (multiplexing</em>).</p>
</div>

<p>По умолчанию запросы <a href="/en/HTTP" title="en/HTTP">HTTP</a> идут последовательно. Новый запрос выдается только после того, как получен ответ на предыдущий. Из-за запаздываний в сети и ограничений на пропускную способность это может приводить к тому, что сервер <em>увидит </em>следующий запрос с существенной задержкой.</p>

<p>Конвейерная обработка это процесс отсылки последовательных запросов по одному постоянному соединению не дожидаясь ответа. Таким образом избегают задержки соединения. Теоретически, производительность можно было бы повысить также за счет упаковки двух запросов HTTP в одно и то же сообщение TCP. Типичный <a href="https://en.wikipedia.org/wiki/Maximum_segment_size">MSS</a> (Maximum Segment Size - Максимальный размер сегмента) достаточно велик, чтобы вместить несколько простых запросов, хотя требования на объем запросов HTTP продолжают расти.</p>

<p>Не все типы запросов HTTP позволяют конвейерную обработку: только методы {{glossary("idempotent")}}, а именно {{HTTPMethod("GET")}}, {{HTTPMethod("HEAD")}}, {{HTTPMethod("PUT")}} и {{HTTPMethod("DELETE")}}, можно перезапускать безопасно: в случае сбоя содержимое конвейерной передачи можно просто повторить.</p>

<p>В наши дни любой удовлетворяющий требованиям HTTP/1.1 прокси или сервер должен поддерживать конвейерную обработку, хотя на практике возникает множество ограничений, поэтому ни один из современных браузеров не активирует этот режим по умолчанию.</p>

<h2 id="Доменное_разделение_Domain_sharding">Доменное разделение (Domain sharding)</h2>

<div class="note">
<p>Не используйте этот устаревший метод без крайней необходимости; вместо этого переходите на HTTP/2. В HTTP/2 доменное разделение больше не требуется: соединение HTTP/2 соединение прекрасно работает с параллельными неприоритезированными запросами. Доменное разделение даже вредит производительности. Большинство реализаций HTTP/2 использует метод, называемый <a href="I wonder if it's related to the nobash/nobreak/nopick secret exit s of Elrond's chambers.">слиянием соединений (connection coalescing</a>) для возврата конечного доменного разделения.</p>
</div>

<p>Поскольку соединение HTTP/1.x является последовательными запросами, даже без упорядочивания, оно не может быть оптимальным без наличия достаточно большой пропускной способности. Браузеры находят решение в открытии нескольких соединений к каждому домену с отсылкой параллельных запросов. По умолчанию это когда-то было 2-3 соединения, но сейчас их число возросло примерно до 6 параллельных соединений. При попытке использовать большее количество есть риск спровоцировать защиту от <a href="/en-US/docs/Glossary/DOS_attack">DoS</a> со стороны сервера.</p>

<p>Если сервер хочет иметь более быстрый ответ от веб-сайта или приложения, он может открыть больше соединений. Например, вместо того, чтобы иметь все ресурсы на одном домене, скажем, <code>www.example.com</code>, он может распределить их по нескольким доменам, <code>www1.example.com</code>, <code>www2.example.com</code>, <code>www3.example.com</code>. Каждый из этих доменов разрешается на том же сервере, и веб-браузер откроет 6 соединений к каждому (в нашем примере число соединений возрастет до 18). Этот метод называют доменным разделением (<em>domain sharding)</em>.</p>

<p><img alt="" src="https://mdn.mozillademos.org/files/13783/HTTPSharding.png" style="height: 727px; width: 463px;"></p>

<h2 id="Заключение">Заключение</h2>

<p>Улучшение управлением соединениями дает существенное увеличение производительности в HTTP. В HTTP/1.1 и HTTP/1.0 использование постоянного соединения – по крайней мере пока оно не начинает работать вхолостую – приводит к лучшей производительности. Однако, проблемы с конвейерной обработкой привели к созданию более совершенных способов управления соединением, реализованными в HTTP/2.</p>