typos fix

Author: drypa

ru/03.1.md

@@ -23,7 +23,7 @@
 
 Мы всегда используем URL для доступа к веб-страницам, но знаете ли вы как работает URL?
 
-URL расшифровывется как Uniform Resource Locator, в переводе на русский - единый указатель ресурса. URL служит стандартизированным способом записи адреса ресурса в сети Интернет. Структура URL в общем виде выглядит следующим образом:
+URL расшифровывается как Uniform Resource Locator, в переводе на русский - единый указатель ресурса. URL служит стандартизированным способом записи адреса ресурса в сети Интернет. Структура URL в общем виде выглядит следующим образом:
 
     <схема>://<хост>:<порт>/<URL‐путь>?<параметры>#<якорь>
     <схема> назначение базового протокола (например, HTTP, HTTPS, ftp)
@@ -43,12 +43,12 @@ DNS-это аббревиатура  Domain Name System -  система до
 
 Для понимания принципов работы DNS давайте подробно рассмотрим процесс разрешения имен DNS.
 
-1. После того, как вы введете доменное имя в вашем браузере (например  `www.qq.com`), операционная система должна проверить, существует ли сопоставление IP адреса данному доменному имени в файле hosts на вашем компьютере, если такое соответсвие найдено, разрешение имени завершается.
-2. Если соотвествие в hosts не найдено, операционная система должна проверить локальный кэш DNS. Если в локальном кэше соответствие найдено, то разрешение доменного имени завершается.
-3. Если соответсвие не найдено ни в hosts ни в кэше DNS, операционная система находит первый по списку сервер DNS, обозначенный в настройках TCP/IP,  который, как правило, является локальным DNS сервером. Когда локальный DNS-сервер получает запрос, он проверяет, содержится ли запрашиваемое доменное имя в локальной конфигурации региональных ресурсов, а затем возвращает результаты клиенту. Это разрешение DNS является авторитетным.
+1. После того, как вы введете доменное имя в вашем браузере (например  `www.qq.com`), операционная система должна проверить, существует ли сопоставление IP адреса данному доменному имени в файле hosts на вашем компьютере, если такое соответствие найдено, разрешение имени завершается.
+2. Если соответствие в hosts не найдено, операционная система должна проверить локальный кэш DNS. Если в локальном кэше соответствие найдено, то разрешение доменного имени завершается.
+3. Если соответствие не найдено ни в hosts ни в кэше DNS, операционная система находит первый по списку сервер DNS, обозначенный в настройках TCP/IP,  который, как правило, является локальным DNS сервером. Когда локальный DNS-сервер получает запрос, он проверяет, содержится ли запрашиваемое доменное имя в локальной конфигурации региональных ресурсов, а затем возвращает результаты клиенту. Это разрешение DNS является авторитетным.
 4. Если локальный DNS не содержит информацию о доменном имени и соответствия не найдены в кэше, локальный DNS сервер возвращает этот результат клиенту. Это разрешение DNS не является авторитетным.
 5. Если локальный DNS не смог разрешить данное доменное имя локальной конфигурацией региональных ресурсов или кэшем, он переходит к следующему шагу, зависящему от локальных настроек DNS сервера. Если локальный DNS не является рекурсивным, он отправляет запрос к корневому DNS серверу, а затем возвращает IP адреса DNS серверов верхнего уровня, которые могут знать доменное имя `.com` в нашем примере. Если первый DNS сервер верхнего уровня ничего не знает о запрашиваемом имени, он отправляет запрос следующему верхнеуровневому DNS и так происходит до тех пор, пока кто-нибудь из них не узнает доменное имя. Затем DNS сервер верхнего уровня запрашивает у DNS сервера следующего уровня информацию о домене `qq.com`, затем находит информацию о домене `www.qq.com` на других серверах.
-6. Если DNS сервер является рекурсивным, он отправляет запрос DNS серверу более высоко уровня. Если DNS сервер более высокого уровня также не знает имя домена, он продолжает посылать запрос на более высокий уровень. Если локальныйй DNS является рекурсивным, разрешенное в IP адрес доменное имя возвращается к локальному DNS серверу, который, в свою очередь, отправляет его клиенту.
+6. Если DNS сервер является рекурсивным, он отправляет запрос DNS серверу более высоко уровня. Если DNS сервер более высокого уровня также не знает имя домена, он продолжает посылать запрос на более высокий уровень. Если локальный DNS является рекурсивным, разрешенное в IP адрес доменное имя возвращается к локальному DNS серверу, который, в свою очередь, отправляет его клиенту.
 
 ![](images/3.1.dns_inquery.png?raw=true)
 
@@ -70,7 +70,7 @@ HTTP является протоколом независимой обработ
 
 ### HTTP запрос (информация о браузере)
 
-Все пакеты запросов состоят из трех частей: строка запроса, заголовок запроса и тело запроса. Между заголовкам запроса и телом запроса идет онда пустая строка.
+Все пакеты запросов состоят из трех частей: строка запроса, заголовок запроса и тело запроса. Между заголовкам запроса и телом запроса идет одна пустая строка.
 
     GET /domains/example/ HTTP/1.1      // request line: request method, URL, protocol and its version
     Host：www.iana.org             // имя домена
@@ -94,7 +94,7 @@ HTTP является протоколом независимой обработ
 **Обратите внимание, что метод GET не имеет тела запроса, а метод POST имеет**
 
 Есть много методов, которые можно использовать для взаимодействия с серверами по HTTP. Четыре основных метода, которые мы будем использовать, это GET, POST, PUT, DELETE. Эти четыре метода означают запрос, изменение, добавление и удаление соответственно. GET и POST используются в HTTP чаще всего. GET добавляет данные в URL и использует `?` в качестве разделителя данных, а `&` в качестве разделителя аргументов. Например: `EditPosts.aspx?name=test1&id=123456`.
-POST помещает данные в теле запроса, поскольку URL имеет ограничение длины, заданное браузером, так что POST может предоставить гораздо больше данных, чем метод GET. Например, когда мы отправляем на сервер логин и пароль, то весьма не желательно, чтобы эта информация содержалась в URL запроса, поэтому, логичнее было бы использовать для передачи таких данных метод POST, чтобы сделать их невидимыми.
+POST помещает данные в теле запроса, поскольку URL имеет ограничение длины, заданное браузером, так что POST может предоставить гораздо больше данных, чем метод GET. Например, когда мы отправляем на сервер логин и пароль, то весьма нежелательно, чтобы эта информация содержалась в URL запроса, поэтому, логичнее было бы использовать для передачи таких данных метод POST, чтобы сделать их невидимыми.
 
 ### HTTP ответ (сведения от сервера)