1 files changed, 13 insertions, 13 deletions
diff --git a/files/ru/web/http/connection_management_in_http_1.x/index.html b/files/ru/web/http/connection_management_in_http_1.x/index.html
index 4b75db2059..7b27e036fe 100644
--- a/files/ru/web/http/connection_management_in_http_1.x/index.html
+++ b/files/ru/web/http/connection_management_in_http_1.x/index.html
@@ -19,27 +19,27 @@ translation_of: Web/HTTP/Connection_management_in_HTTP_1.x
 <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>
+<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>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>
+<p>Если речь не идёт об очень старой, не поддерживающей постоянные соединения, системе, данную модель использовать нет смысла.</p>
 </div>
 
 <h2 id="Постоянные_соединения">Постоянные соединения</h2>
 
-<p>Краткосрочные соединения имеют два больших недостатка: требуется значительное время на установку нового соединения, и то, что эффективность TCP-соединения улучшается только по прошествии некоторого времени от начала его использования (теплое соединение). Для решения этих проблем была разработана концепция <em>постоянного соединения (persistent connection</em>), еще до появления HTTP/1.1. Его также называют <em>соединением keep-alive</em>.</p>
+<p>Краткосрочные соединения имеют два больших недостатка: требуется значительное время на установку нового соединения, и то, что эффективность TCP-соединения улучшается только по прошествии некоторого времени от начала его использования (тёплое соединение). Для решения этих проблем была разработана концепция <em>постоянного соединения (persistent connection</em>), ещё до появления HTTP/1.1. Его также называют <em>соединением keep-alive</em>.</p>
 
-<p>Постоянным называют соединение, которое остается открытым некоторый период времени и может быть использовано для нескольких запросов, благодаря чему отпадает необходимость в новых рукопожатиях TCP и используются средства повышения производительности TCP. Это соединение остается открытым не навсегда: праздные соединения закрываются по истечению некоторого времени (для задания минимального времени, на протяжении которого соединение должно оставаться открытым, сервер может использовать заголовок {{HTTPHeader("Keep-Alive")}}).</p>
+<p>Постоянным называют соединение, которое остаётся открытым некоторый период времени и может быть использовано для нескольких запросов, благодаря чему отпадает необходимость в новых рукопожатиях TCP и используются средства повышения производительности TCP. Это соединение остаётся открытым не навсегда: праздные соединения закрываются по истечению некоторого времени (для задания минимального времени, на протяжении которого соединение должно оставаться открытым, сервер может использовать заголовок {{HTTPHeader("Keep-Alive")}}).</p>
 
-<p>У постоянных соединений есть свои недочеты; даже работая вхолостую, они потребляют ресурсы сервера, а при высокой нагрузке могут проводиться {{glossary("DoS attack", "DoS attacks")}}. В таких случаях большую эффективность могут обеспечить не постоянные соединения, которые закрываются как только освободятся.</p>
+<p>У постоянных соединений есть свои недочёты; даже работая вхолостую, они потребляют ресурсы сервера, а при высокой нагрузке могут проводиться {{glossary("DoS attack", "DoS attacks")}}. В таких случаях большую эффективность могут обеспечить не постоянные соединения, которые закрываются как только освободятся.</p>
 
 <p>Соединения HTTP/1.0 по умолчанию не являются постоянными. Для превращения их в постоянные надо присвоить заголовку {{HTTPHeader("Connection")}} значение, отличное от <code>close</code> - обычно <code>retry-after.</code></p>
 
@@ -51,17 +51,17 @@ translation_of: Web/HTTP/Connection_management_in_HTTP_1.x
 <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/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>
+<p>По этим причинам в HTTP/2 на смену конвейерной обработке пришёл новый алгоритм, <em>мультиплексность (multiplexing</em>).</p>
 </div>
 
-<p>По умолчанию запросы <a href="/en/HTTP" title="en/HTTP">HTTP</a> идут последовательно. Новый запрос выдается только после того, как получен ответ на предыдущий. Из-за запаздываний в сети и ограничений на пропускную способность это может приводить к тому, что сервер <em>увидит </em>следующий запрос с существенной задержкой.</p>
+<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 в одно и то же сообщение 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>
 
@@ -75,10 +75,10 @@ translation_of: Web/HTTP/Connection_management_in_HTTP_1.x
 
 <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>Если сервер хочет иметь более быстрый ответ от веб-сайта или приложения, он может открыть больше соединений. Например, вместо того, чтобы иметь все ресурсы на одном домене, скажем, <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>
+<p>Улучшение управлением соединениями даёт существенное увеличение производительности в HTTP. В HTTP/1.1 и HTTP/1.0 использование постоянного соединения – по крайней мере пока оно не начинает работать вхолостую – приводит к лучшей производительности. Однако, проблемы с конвейерной обработкой привели к созданию более совершенных способов управления соединением, реализованными в HTTP/2.</p>