предисловие
Первоначальной целью Интернета была передача текста (текстовый диалог). Итак, как страница представляется нам после того, как мы используем браузер для отправки запроса? Далее на картинке описан процесс перехода от URL-адреса к странице рендеринга.
1. Текстовый диалог - от запроса к ответу
(1) Браузер отправляет запрос на сервер, на котором находится веб-сайт.
(2) Сервер веб-сайта обрабатывает и анализирует Запрос после его получения.
(3) Затем вернуть браузеру соответствующий Response (ответ), который содержит исходный код страницы и другой контент.
(4) Затем браузер анализирует его и отображает веб-страницу.
На каких правилах основан процесс этого текстового диалога? просто скажи,Этот процесс связи основан на спецификации набора протоколов связи TCP/IP., чтобы завершить ряд процессов обмена информацией от клиента к серверу.
2. Введение в набор протоколов TCP/IP
1. Что такое набор протоколов TCP/IP?
Набор протоколов TCP/IP предназначен для обеспечения обмена информацией между компьютерами путем установления правил.
Две стороны, которые общаются друг с другом, должны основываться на одном и том же методе, например, какая сторона инициирует общение первой, какой язык используется для общения, и правила завершения общения должны быть определены заранее. это правило протокол. Обычно мы говорим, что набор протоколов TCP/IP — это общий термин для различных наборов протоколов, связанных с Интернетом.
Вот важное иерархическое разделение TCP/IP, которое можно разделить на 4 уровня в зависимости от уровня:Прикладной уровень, транспортный уровень, сетевой уровень и канальный уровень. (Преимущество многоуровневого распределения заключается в том, что внутреннюю структуру каждого уровня можно свободно изменять и связывать через интерфейсы каждого уровня, и если имеется только одна координация протокола, все задействованные части необходимо перепроектировать.)
2. Роль каждого функционального уровня TCP/IP
(1)прикладной уровень: определяет коммуникационные действия при предоставлении услуг приложений пользователям. Прикладной уровень отвечает за передачу данных в различных окончательных формах и напрямую взаимодействует с пользователями.Обычными протоколами являются HTTP, FTP и т. д.
(2)транспортный уровень: Отвечает за передачу текстовых данных. Транспортный уровень имеет два разных протокола: TCP (протокол управления передачей, протокол управления передачей) и UDP (протокол данных пользователя, протокол данных пользователя).
(3)Сетевой уровень: Отвечает за выделение адресов и передачу двоичных данных, основным протоколом является IP-протокол;
(4)связующий слой: Отвечает за установление цепных соединений, которые являются физической основой всей сети.Обычные протоколы включают Ethernet, ADSL и т. д.
3. Транспортный поток связи TCP/IP
Как данные передаются между функциональными уровнями TCP/IP?
(1) Сначала отправляется клиентом в качестве отправителя на прикладном уровне (протокол HTTP). HTTP-запрос (например: хотите просмотреть www.baidu.com) и создать HTTP-сообщение.
(2) Для удобства передачи данные (сообщение с запросом HTTP), полученные с прикладного уровня, разделяются на транспортном уровне (протокол TCP), а Каждый пакет помечается порядковым номером тега и номером порта и пересылается на сетевой уровень.
(3) На сетевом уровне (IP-протокол) MAC-адрес в качестве адресата связи добавляется и перенаправляется на канальный уровень.
(4) Добавьте заголовок Ethernet к этим данным и отправьте его, а сгенерированный пакет данных Ethernet будет передан принимающей стороне через физический уровень.
(5) Сервер на принимающей стороне получает данные на канальном уровне и последовательно отправляет их на верхний уровень, пока они не достигнут прикладного уровня. Только когда он передается на прикладной уровень, HTTP-запрос, отправленный клиентом, может быть действительно получен.
Когда коммуникационный процесс проходит через уровень, он должен быть помечен заголовком, к которому принадлежит уровень. Напротив, когда принимающая сторона передает данные между уровнями, соответствующий заголовок будет удаляться каждый раз, когда он проходит через уровень.
3. Коммуникационный процесс на основе TCP/IP
Диаграмма, иллюстрирующая процесс связи от запроса до представления веб-страницы (следующая диаграмма основана на протоколе IP, TCP протокол , служба DNS и процесс обмена данными по протоколу HTTP), и объясните каждый шаг:
1. Браузер вводит URL для отправки запроса
URL-адрес (Uniform Resource Locator, Унифицированный указатель ресурсов) — это адрес веб-страницы, который необходимо ввести при использовании веб-браузера и т. д. для доступа к веб-странице.
URL-адрес состоит из следующих элементов:
(2) Иерархический символ метки URL: исправлен на «//»
(3) Информация для входа: учетная информация, необходимая для доступа к ресурсам (можно опустить)
(4) Адрес сервера: обычно доменное имя, иногда IP-адрес (в реальной связи к нему необходимо получить доступ через IP-адрес, а доменное имя преобразуется в IP-адрес через DNS-сервер)
(5) Номер порта: выражается цифрами, если это значение по умолчанию для HTTP ":80", его можно не указывать.
(6) Путь: используйте символ «/», чтобы различать имена каждого каталога в пути.
(7) Запрос: параметры формы в режиме GET, начиная с символа «?», каждый параметр отделяется «&», а затем имя параметра и данные разделяются знаком «=», обычно кодируется в URL-адресе UTF8, чтобы избежать проблема конфликта персонажей
(8) Фрагмент: начиная с символа «#», используя идентификатор фрагмента, обычно можно пометить подресурсы в полученном ресурсе.
2. DNS разрешает доменное имя URL в запросе
Компьютерам могут быть назначены либо IP-адреса, либо имена хостов и доменные имена.Пользователи обычно используют имена хостов или доменные имена для доступа к компьютерам друг друга, а не напрямую через IP-адреса. Компьютерам относительно проще обрабатывать набор чисел, и появились службы разрешения доменных имен DNS. Протокол DNS обеспечивает поиск IP-адреса по имени домена (или обратный поиск имени домена по IP-адресу).
3. Протокол HTTP генерирует сообщение запроса
Протокол HTTP: протокол передачи гипертекста расположен на прикладном уровне и определяет ряд содержимого и методов связи от клиента к серверу, который завершает связь путем создания и отправки сообщений.
4. Протокол TCP обеспечивает надежную передачу потока байтов.
Протокол TCP: протокол управления передачей Transmission Control Protocol, расположенный на транспортном уровне.
(1) Услуга Byte Stream подразумевает разделение больших блоков данных на сегменты для удобства передачи. Управляется единицей пакетов данных.
(2) Услуга надежной передачи означает возможность точно и надежно передавать данные другой стороне. Протокол TCP использует такие стратегии, как трехстороннее рукопожатие для обеспечения надежности передачи (трехстороннее рукопожатие, четырехсторонняя волна будут дополнены в конце статьи).
5. IP-протокол осуществляет передачу данных на другой компьютер.
IP (интернет-протокол) Интернет-протокол расположен на сетевом уровне. Роль IP-протокола заключается в реализации передачи пакетов данных на IP-адрес другого компьютера. Связь между IP-адресами зависит от MAC-адреса (фиксированного адреса, которому принадлежит сетевая карта), и соответствующий MAC-адрес необходимо узнать по IP-адресу взаимодействующей стороны через протокол ARP.
6. После получения и разбора сообщения запроса верните ответное сообщение.
В-четвертых, TCP устанавливает соединение и разъединение (выделение добавлено).
Установление TCP-соединения (3-стороннее рукопожатие)
TCP обеспечивает коммуникационный транспорт, ориентированный на соединение.Ориентированный на соединение означает, что подготовительная работа между двумя концами выполняется до начала обмена данными. Трехстороннее рукопожатие означает, что при установлении TCP-соединения клиент и сервер должны отправить в общей сложности три отмеченных пакета для подтверждения установления соединения. Давайте посмотрим на блок-схему трехэтапного рукопожатия:
Первое рукопожатие: Клиент устанавливает бит флагаСинхронизация установлена на 1, случайным образом генерирует значение seq=J и отправляет пакет данных на серверную сторону, клиентская сторона переходит в состояние SYN_SENT и ожидает подтверждения со стороны сервера.
второе рукопожатие: После того, как сервер получит пакет данных, бит флага SYN=1 знает, что клиент запрашивает установление соединения, и серверная сторона установит бит флагаSYN и ACK установлены на 1, ack=J+1, случайным образом генерирует значение seq=K и отправляет пакет данных клиенту для подтверждения запроса на соединение, а сервер переходит в состояние SYN_RCVD.
третье рукопожатие: После того, как клиент получит подтверждение, проверьте, соответствует ли подтверждение J+1, равно ли ACK 1 и, если оно правильное, будет установлен флаг.ACK установлен на 1, ack=K+1 и отправить пакет данных на сервер.Сервер проверяет, соответствует ли ack K+1 и равен ли ACK 1. Если он правильный, соединение устанавливается успешно, и клиент и сервер входят состояние ESTABLISHED, которое завершается три раза, рукопожатие устанавливает соединение, после чего можно начинать передачу данных между клиентом и сервером.
Почему 3 рукопожатия: Первые два рукопожатия заведомо необходимы, в основном в последний раз, то есть зачем клиент хочет, чтобы сервер отправил еще одно подтверждение после получения подтверждения от сервера? Это в основномЧтобы предотвратить повторную внезапную отправку недопустимого сегмента запроса на сервер, что приведет к неправильной оценке соединения.
Рассмотрим следующую ситуацию: Клиент отправляет сегмент запроса на подключение на сервер, но он остается на некоторых узлах сети в течение длительного времени, поэтому клиент через некоторое время повторно отправляет сегмент запроса на подключение на сервер, после чего соединение устанавливается нормально. соединение освобождается. Если сегмент запроса (expired), отправленный в первый раз в это время, поступает на сервер с задержкой на какой-то период времени, то очевидно, что это уже просроченный сегмент, но сервер его ошибочно примет. что клиент снова отправил запрос на соединение, он отправляет клиенту сегмент подтверждения и соглашается установить соединение. Предполагая, что трехстороннее рукопожатие не используется, новое соединение устанавливается до тех пор, пока сервер отправляет подтверждение. Однако, поскольку клиент не выдал запрос на установление соединения на данном этапе, он проигнорирует подтверждение сервера и не отправит данные на сервер, а сервер считает, что новое соединение установлено и ожидает клиент для отправки данных. , так что сервер будет ждать, пока не будет превышено установленное значение счетчика поддержки активности, и клиент определит, что есть проблема, и закроет соединение. Это тратит много ресурсов сервера. Однако, если используется трехстороннее рукопожатие, клиент не отправляет подтверждение на сервер, поскольку сервер не получает подтверждения, он знает, что клиент не запрашивает установление соединения, и, следовательно, не устанавливает соединение. .
Отключение TCP (4 волны)
TCP-соединения являются полнодуплексными, поэтому каждое направление должно быть закрыто отдельно, Четыре взмаха рук завершают TCP-соединение, что означает, что при разрыве TCP-соединения клиент и сервер должны отправить в общей сложности 4 пакета для подтверждения разрыва соединения. Давайте посмотрим на блок-схему четырех волн:
Примечание. Отсоединенная сторона может быть клиентом или сервером. Следующий пример представляет собой запрос на прерывание, выданный клиентом.
первая волна: клиент отправляетFIN=M, который используется для закрытия передачи данных от клиента к серверу, и клиент переходит в состояние FIN_WAIT_1. Это означает «у моего клиента нет данных для отправки вам», но если у вас на сервере остались данные, которые не были отправлены, не нужно торопиться закрывать соединение, вы можете продолжать отправлять данные.
вторая волна: После того, как сервер получит FIN, он отправит его первым.ack=M+1, скажите клиенту: «Я получил ваш запрос, но я не готов, пожалуйста, продолжайте ждать моего сообщения.» В это время клиент входит в состояние FIN_WAIT_2 и продолжает ждать FIN-сообщения от сервера.
Третья волна: когда сервер определяет, что данные были отправлены, он отправит их клиенту.FIN=Nсообщение, скажите клиенту, хорошо, я закончил отправку данных здесь, и я готов закрыть соединение. Серверная часть переходит в состояние LAST_ACK.
четвертая волна: После того, как клиент получает сообщение FIN=N, он знает, что соединение можно закрыть, но все еще не верит в сеть, опасаясь, что сервер не знает, что нужно закрыть, поэтому отправляетACK=1, ACK=N+1После входа в состояние TIME_WAIT, если сервер не получает ACK, его можно передать повторно. После того, как сервер получает ACK, он знает, что соединение может быть разорвано (состояние CLOSED). Если клиент ждет 2MSL (время MSL называется самым долгим временем жизни сообщения, RFC рекомендует устанавливать его в 2 минуты) и все еще не получает ответа, это доказывает, что сервер был выключен нормально, и клиент также может закрыть связь. Наконец, четыре рукопожатия были завершены.
Зачем махать 4 раза: Протокол TCP — это ориентированный на установление соединения надежный протокол связи на транспортном уровне потока байтов. TCP – это полнодуплексный режим, что означает, что когда клиент отправляет сегмент FIN, это просто означает, что у клиента нет данных. Чтобы отправить, клиент сообщает серверу, что все его данные были отправлены, однако в это время клиент все еще может принимать данные от сервера; когда сервер возвращает сегмент ACK, это означает, что он уже знает, что у клиента нет данных для отправки Однако хост 2 по-прежнему может отправлять данные клиенту, когда сервер также отправляет сегмент FIN, это означает, что у сервера нет данных для отправки, и он сообщит клиенту, что у меня тоже нет данных для отправки. друг друга с радостью разорвут TCP-соединение.
Почему клиент TIME_WAIT ждет 2MSL: (1)Чтобы гарантировать, что последний сегмент ACK, отправленный клиентом, может достичь сервера. Сегмент ACK, скорее всего, будет потерян, поэтому сервер в состоянии LIST-ACK не сможет получить подтверждение отправленного сегмента FIN+ACK, сервер может повторно передать сегмент FIN+ACK, а клиент получит повторно переданный FIN+ACK. сегмент в течение времени 2MSL, затем клиент повторно передает подтверждение, перезапускает таймер 2MSL, и, наконец, и клиент, и сервер переходят в состояние CLOSED. (2)Предотвратить появление устаревших соединений запроса в этом соединении. Когда соединение ожидает на 2MSL, любой поздний сегмент будет отброшен, потому что соединение, определенное сокетом (сокет означает пару IP-адреса и порта, сокет) в периоде ожидания 2MSL, нельзя будет использовать снова в течение этого времени. что сегмент, задержанный перед старым соединением, не появится в следующем новом соединении.
резюме
Выше мы понимаем роль протокола TCP/IP и процесса связи, а протокол Http подробно рассмотрим позже.
использованная литература:
"Иллюстрация http"(ссылка на скачивание)
"Статья для ознакомления с протоколом TCP/IP (сетевой протокол, часть 2)"
«[Сетевой протокол] Установление и освобождение TCP-соединений»