Auto fixes

1 files changed, 3 insertions, 3 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 16ce498108..4b75db2059 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
@@ -41,7 +41,7 @@ translation_of: Web/HTTP/Connection_management_in_HTTP_1.x
 
 <p>У постоянных соединений есть свои недочеты; даже работая вхолостую, они потребляют ресурсы сервера, а при высокой нагрузке могут проводиться {{glossary("DoS attack", "DoS attacks")}}. В таких случаях большую эффективность могут обеспечить не постоянные соединения, которые закрываются как только освободятся.</p>
 
-<p>Соединеня HTTP/1.0 по умолчанию не являются постоянными. Для превращения их в постоянные надо присвоить заголовку {{HTTPHeader("Connection")}} значение, отличное от <code>close</code> - обычно <code>retry-after.</code></p>
+<p>Соединения HTTP/1.0 по умолчанию не являются постоянными. Для превращения их в постоянные надо присвоить заголовку {{HTTPHeader("Connection")}} значение, отличное от <code>close</code> - обычно <code>retry-after.</code></p>
 
 <p>В HTTP/1.1 соединения являются постоянными по умолчанию, так что этот заголовок больше не требуется (но часто добавляется в качестве защитной меры на случай, если потребуется откат к HTTP/1.0).</p>
 
@@ -51,7 +51,7 @@ 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/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>
@@ -73,7 +73,7 @@ translation_of: Web/HTTP/Connection_management_in_HTTP_1.x
 <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>Поскольку соединение 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>