Что представляет собой процесс чтения URL-запроса в одной статье

предисловие

Когда мы вводим URL-адрес доступа в браузере, и браузер возвращает нам страницу ответа, на что похож внутренний процесс? Далее я объясню, что такое процесс WEB-запроса со следующих аспектов:

• кеш браузера
• Разрешение доменного имени DNS
• TCP-соединение
• HTTP-запрос и ответ

Механизм кеширования браузера

Первым шагом в размещении здесь механизма браузера является рассмотрение того, что если в браузере есть кэшированные данные, когда браузер снова отправляет запрос на целевой URL-адрес, если срок действия данных не истек, он будет напрямую использовать данные, кэшированные браузер вместо Требуется запрос к серверу. Следующий анализ относится кГлубокое понимание механизма кэширования браузераза знакомство, спасибо.

Метод связи между браузером и сервером — это метод ответа, то естьБраузер инициирует HTTP-запрос — сервер отвечает на запрос. После того, как браузер впервые инициирует запрос к серверу и получит результат запроса, он решит, следует ли кэшировать результат в соответствии с идентификатором кэша заголовка HTTP в ответном сообщении следующим образом:

• Каждый раз, когда браузер инициирует запрос, он сначала запрашивает результат запроса и идентификатор кеша в кеше браузера.
• Каждый раз, когда браузер получает возвращенный результат запроса, он сохраняет результат и идентификатор кеша в кеше браузера.

Мы делим кешированные результаты на две части в зависимости от того, нужно ли нам повторно инициировать HTTP-запрос к серверу, которыеПринудительное кэширование (также называемое локальным кэшированием)иСогласовать кеш, конечно, это всего лишь два названия, некоторые делят тайник наExpires/Cache-controlиLast-Modifed/EtagЭти два спектакля по сути одинаковы. Что касается того, где находится кеш браузера, мы раскроем его позже.

Принудительное кэширование (также называемое локальным кэшированием)

Принудительное кэширование — это процесс поиска закэшированного результата и закэшированного идентификатора из кеша браузера и принятия решения о том, использовать ли закешированный результат в соответствии с правилами кэширования результата. Принудительное кэширование далее делится на следующие аспекты:

• Если кешированный результат и кешированный идентификатор не существуют, а принудительное кеширование не удалось, снова отправьте запрос непосредственно на сервер.

  

• Результат запроса и идентификатор кеша существуют, но результат недействителен и просрочен, а принудительный кеш не работает, используйте согласованный кеш (последующий анализ)

  

• Если результат запроса и идентификатор кеша существуют, и срок действия результата не истек, кеш принудительно вступает в силу, и результат возвращается напрямую.

  

Правила принудительного кэширования

Когда браузер отправляет запрос на сервер, сервер помещает правило кэширования в HTTP-заголовок сообщения ответа HTTP и возвращает его браузеру вместе с результатом запроса.Поля, управляющие принудительным кэшированием:ExpiresиCache-Control,вCache-ControlСравниватьExpiresвысокий приоритет,Когда два существуют одновременно, Cache-Control имеет более высокий приоритет.

Expires

Expires: Wed, 21 Aug 2018 08:26:05 GMT

Expires — это поле, используемое HTTP/1.0 для управления кэшированием веб-страницы. Его значение — время истечения срока действия кэша, возвращаемого сервером. Здесь указана абсолютная дата. Если время клиента меньше значения Expires, кешированный результат будет использоваться напрямую.

Expires — это поле HTTP/1.0. Теперь браузеры по умолчанию используют HTTP/1.1. Expires заменено на Cache-Control

Cache-Control

В HTTP/1.1 Cache-Control в основном используется для управления кэшированием веб-страниц, и его основные значения:

• public : весь контент кэшируется (кэшируется как клиент, так и прокси-сервер)
• private: весь контент может кэшироваться только клиентом, значение по умолчанию для Cache-Control.
• без кеша: клиент кэширует содержимое, но нужно ли использовать кеш, нужно проверить путем согласования кеша
• no-store: Весь контент не будет кэшироваться, т. е. не используется ни принудительный кеш, ни согласованный кеш.
• max-age=xxx (xxx — число): содержимое кэша истечет через xxx секунд,Вот относительное значение

Согласовать кеш

Согласование кеша означает, что после принудительного отказа кеша браузер инициирует запрос к серверу с идентификатором кеша, а сервер отправляет запрос на сервер на основе идентификатора кеша.идентификатор кешаПроцесс принятия решения о продолжении использования кэша. В основном делится на следующие две ситуации:

Первый: кеш согласования вступает в силу и возвращает 304

Примечание. Код состояния 304 указывает, что когда клиент отправляет запрос с условиями (условия включают такие поля, как If-Match, If-Modified-Since, If-None-Match и т. д.), сервер разрешает запросу доступ к ресурс, но условия не соблюдены. Код состояния 304 возвращается без какой-либо части тела ответа.

Второй: договориться об аннулировании кеша, вернуть 200 и результат запроса

Что приводит к тому, что кеш согласования вступает в силу или дает сбой

Поля управления кэшем согласованияLast-Modified/If-Modified-Since и Etag/If-None-Match.Etag/If-None-Match имеет более высокий приоритет, чем Last-Modified/If-Modified-Since

• Last-Modified

Представляет время последней модификации ресурса на сервере, который может быть статическим или динамическим содержимым.Как правило, идентификатор кеша, отправляемый сервером клиенту при первом запросе.

last-modified: Fri, 20 Apr 2018 10:10:50 GMT

• If-Modified-Since

Когда клиент снова отправляет запрос, он содержит значение Last-Modified, возвращенное последним запросом.Сервер получает запрос и находит поле If-Modified-Since.Если время последней модификации ресурса сервера превышает значение If-Modified-Since, будет возвращен новый ресурс, а код состояния равен 200. В это время это указывает на то, что согласованный кеш недействителен, а предыдущий кеш больше не используется. В противном случае возвращаемся к 304, ресурс не обновлялся, кеш согласования вступает в силу, а кеш браузера продолжает использоваться.

if-Modified-Since: Fri, 20 Apr 2018 10:10:50 GMT

• Etag

Etag — это уникальный номер текущего файла ресурсов, который возвращается, когда сервер отвечает на запрос.

• If-None-Match

Когда клиент снова инициирует запрос, он несет уникальный номер, возвращенный последним запросом.После того, как сервер получает запрос, он сравнивает значение поля If-None-Match со значением Etag ресурса на сервере.Если оно соответствует, он возвращает 304, указывая, что ресурс не обновлен, согласованный кеш действует, и файл кеша будет продолжать использоваться. Обновите, снова верните файл ресурсов, код состояния 200

кеш браузера

Кэш браузера делится наиз кеша памятиикеш жесткого диска (из кеша диска):

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

Действия пользователя и кеш

• С F5 браузер будет обходить локальный кеш (принудительный кеш), но согласованный кеш все равно будет работать
• Используйте Ctrl + F5 для принудительного обновления, браузер пропустит локальный кеш и кеш согласования и позволит серверу вернуть последние ресурсы.

Обзор механизма кэширования браузера

Принудительное кэширование имеет приоритет над кэшированием по согласованию. На следующей диаграмме показан процесс кэширования в браузере:

Примечание: Когда мы обращаемся к запросу в первый раз, в браузере нет кеша. В это время нам нужно получить его с сервера. Процесс подключения к серверу и получения ресурсов включает в себя следующее разрешение доменного имени DNS , TCP-соединения, HTTP-запросы и т. д. Механизм кеширования браузера здесь ставится на первое место, учитывая, что если клиент обращается к одному и тому же запросу несколько раз, он в первую очередь проверяет кеш браузера.

Разрешение доменного имени DNS

Мы знаем, что Интернет публикует и запрашивает ресурсы через URL-адреса, а доменное имя в URL-адресе необходимо преобразовать в IP-адрес, чтобы установить соединение с удаленным хостом.Как преобразовать доменное имя в IP-адрес относится к области разрешения DNS.

DNS (система доменных имен) — это английская аббревиатура от системы доменных имен. Это система именования компьютеров и сетевых служб, организованная в иерархию доменов. Она используется в сетях TCP/IP. Предоставляемая ею услуга заключается в преобразовании имен узлов и доменов имена в IP адрес работают

Иерархический DNS-сервер имен

В зависимости от роли, которую играет сервер доменных имен, серверы доменных имен можно разделить на следующие типы:

• корневой сервер имен

Корневой сервер имен является сервером имен самого высокого уровня и наиболее важным сервером имен. Всем корневым серверам имен известны доменные имена и IP-адреса всех серверов имен верхнего уровня.

• Сервер доменных имен верхнего уровня (т. е. сервер TLD)

Эти нагрузки сервера имен управляют всеми доменами второго уровня, зарегистрированными на этом сервере имен верхнего уровня.

• авторитетный сервер имен

Например:dns9.hichina.com предоставлен Aliwan.com, dns10.hichina.com и т. д., предоставленные Tencent DNSPod.f1g1ns1.dnspod.net, f1g1ns2.dnspod.net и т. д., авторитетный сервер доменных имен, на который вы подали заявку и создали сами, и т. д.

• локальный сервер имен

Фактически локальные серверы имен не принадлежат к иерархии серверов имен., но это очень важно для системы доменных имен.Когда хост отправляет запрос запроса DNS, сообщение запроса запроса сначала отправляется на локальный сервер доменных имен. У каждого интернет-провайдера (локального поставщика доступа в Интернет) есть локальный сервер имен.

Процесс разрешения доменного имени DNS

Процесс запроса на разрешение доменного имени DNS делится на следующие этапы:

Шаг 1. Проверьте, есть ли разрешенный IP-адрес, соответствующий этому доменному имени, в кеше браузера.

Браузер проверит, есть ли в кеше разрешенный IP-адрес, соответствующий доменному имени, и если он есть в кеше, процесс парсинга завершится. Имя домена кеша браузера также ограничено, ограничен не только размер кеша браузера, но и время кеша, обычно от нескольких минут до нескольких часов.Ограничение времени для кэширования доменного имени может быть установлено через атрибут TTL Разумные настройки.

Шаг 2. Проверьте, есть ли результат разрешения, соответствующий этому доменному имени, в кеше операционной системы.

Если кеш браузера пользователя недоступен, браузер проверит, есть ли результат разрешения DNS, соответствующий доменному имени, в кеше операционной системы. На самом деле в операционной системе тоже будет процесс разрешения доменного имени.В Windows можно пройтиC:\Windows\System32\drivers\etc\hostsфайл для установки, в Linux эта конфигурация/etc/hosts. В этих двух файлах вы можете преобразовать любое доменное имя в любой доступный IP-адрес.

Шаг 3: Запрос к локальному серверу (LDNS)

Если предыдущие два процесса не могут быть разрешены, операционная система отправит доменное имя на установленный здесь LDNS, который является сервером доменных имен в локальной области. Этот DNS обычно предоставляется в качестве службы разрешения DNS для вашего локального доступа в Интернет. Например, если вы выходите в Интернет в школе, то локальный DNS-сервер находится в вашей школе. Фактически здесь выполняется около 80% работы по разрешению доменных имен, и LDNS берет на себя основную работу по разрешению доменных имен.

Шаг 4: LDNS не поражен, перейдите непосредственно к серверу доменных имен корневого сервера, чтобы запросить разрешение

Корневой сервер имен является сервером имен самого высокого уровня и наиболее важным сервером имен. Всем корневым серверам имен известны доменные имена и IP-адреса всех серверов имен верхнего уровня.

Шаг 5. Сервер корневых доменных имен возвращает адрес основного сервера доменных имен (сервер gTLD) запрошенного домена локальному серверу доменных имен.

gTLD — это упомянутый выше международный сервер доменных имен верхнего уровня.например .com,.сп и так далее.

Шаг 6. Локальный сервер доменных имен отправляет запрос на сервер рДВУ, возвращенный на предыдущем шаге.

Шаг 7: Примите запрошенный запрос сервера доменных имен верхнего уровня и верните полномочный сервер (сервер имен), соответствующий этому доменному имени.

Этот уполномоченный сервер является сервером доменных имен, который вы зарегистрировали, например сервер доменных имен Aliwan.com, доменное имя, на которое вы подаете заявку здесь, после чего задача разрешения доменного имени выполняется сервером поставщика доменного имени.

Шаг 8: полномочный сервер запросит сохраненную таблицу сопоставления доменных имен и IP-адресов и вернет

При нормальных обстоятельствах целевая IP-запись получается в соответствии с доменным именем, а значение TTL возвращается на сервер доменных имен DNS-сервера. Для возвращенных IP и TTL локальный сервер доменных имен кэширует соответствующую связь между доменным именем и IP, а время кэширования контролируется значением TTL.

Шаг 9: Возвращаем результат разрешения пользователю, пользователь кэширует его в локальном системном кеше в соответствии со значением TTL, и процесс разрешения доменного имени завершается.

Метод запроса во время разрешения доменного имени DNS

• рекурсивный запрос

Запрос хоста к локальному серверу доменных имен, как правило, является рекурсивным запросом, поэтому рекурсивный запрос таков: если локальный сервер доменных имен, к которому обращается хост, не знает IP-адрес запрошенного доменного имени, то локальное доменное имя заменит хост в качестве DNS-клиента. Продолжайте отправлять пакеты запроса на другие корневые серверы имен доменов, вместо того чтобы позволить хосту выполнить следующий запрос самостоятельно.

• итеративный запрос

Запрос локального сервера имен к корневому серверу имен обычно представляет собой повторяющийся запрос. Итеративный запрос: когда корневой сервер имен доменов получает сообщение с запросом итеративного запроса, отправленное локальным сервером имен доменов, он либо сообщает запрашиваемый IP-адрес, либо сообщает локальному серверу имен доменов, какой сервер доменных имен запрашивать следующим, и затем отправляет запрос локальному серверу доменных имен, который делает последующие запросы.

Кэш в DNS

После процесса разрешения доменного имени DNS результаты разрешения кэшируются. Результаты в основном кэшируются в двух местах: одно — на локальном сервере доменных имен, а другое — на локальном компьютере пользователя. Эти два кэша контролируются значением TTL и размер локального кэша.

Диаграмма процесса разрешения доменных имен DNS

Говорят, что «картинка стоит тысячи слов», следующая картинка подробно описывает процесс разрешения доменного имени DNS.

TCP-соединение

Прежде чем браузер отправит HTTP-запрос, необходимо установить TCP/IP-соединение между браузером и сервером.Каждое соединение TCP однозначно определяется двумя конечными точками (то есть двумя сокетами) на обоих концах соединения.Конечные точки соединения TCP называются сокетами.. Как определено в RFC 793, номер порта, связанный с IP-адресом, образует сокет. TCP-соединение в основном делится наУстановление соединения (трехстороннее рукопожатие), передача данных, отключение (четырехстороннее рукопожатие), на следующем рисунке показан процесс связи TCP

Следующий справочник по анализу объединяет анализ TCP в «TCP/IP Detailed Explanation Volume 1» и «Computer Network — Xie Xiren Edition».

Несколько понятий в заголовке сегмента TCP

Прежде чем говорить о трехстороннем рукопожатии TCP и четырехсторонней волне, давайте сосредоточимся на нескольких управляющих битах и ​​начальных порядковых номерах в заголовке сегмента сообщения, относящегося к соединениям TCP, которые помогут нам в последующем анализе. к заголовку сегмента TCP см. «Подробное объяснение TCP/IP, том 1» или связанные с ним статьи.

Номер подтверждения

Ожидается, что номер подтверждения получит следующий сегмент другой стороны.Порядковый номер первого байта данных. Например, если B правильно получает сегмент, отправленный A, значение поля его порядкового номера равно 501, а длина данных составляет 200 байт (порядковый номер 501 ~ 700), что указывает на то, что B правильно получил сообщение, отправленное A, до тех пор, пока не порядковый номер 700. Данные. Следовательно, B ожидает получить следующий порядковый номер данных от A, равный 701, поэтому B устанавливает номер подтверждения равным 701, что выражается как ACK = 701. В заключение, **если номер подтверждения = N, это означает, что все данные до N - 1 были получены правильно

Подтвердить подтверждение

Флаг ACK используется для подтверждения получения

Синхронный СИН

Порядковый номер синхронизации, используемый для инициирования соединения.Поле бита SYN первого сегмента, отправляемого от клиента к серверу, активируется при установке нового соединения.

Прекратить FIN

Используется для освобождения соединения, когда FIN = 1, указывает, что данные отправителя этого сегмента были отправлены, и запрашивает освобождение транспортного соединения.

серийный номер

TCP ориентирован на поток байтов, каждый байт в потоке байтов, передаваемом в соединении TCP, нумеруется последовательно, и весь передаваемый поток байтов нумеруется последовательно.начальный порядковый номерДолжен быть установлен, когда соединение установлено, здесьначальный порядковый номерЭто происходит во время процесса трехстороннего рукопожатия TCP.Начальный порядковый номер (ISN). В "Подробное объяснение TCP/IP, том 1: протокол" упоминается, что в соединении сегмент TCP может иметь задержку прибытия и путаницу в порядке после прохождения через сеть. Чтобы решить эту проблему, необходимо тщательно выбрать начальный серийный номер, современные системы обычно используют полуслучайный метод выбора начального серийного номера для обеспечения определенной степени безопасности

Здесь подчеркивается, что номер подтверждения предназначен для получателя.Получатель надеется получить порядковый номер первого байта данных следующего сегмента отправителя, а порядковый номер, инициализированный SYN, предназначен для отправителя.На этом этапе и отправитель, и получатель отправляют свои собственные начальные порядковые номера. В конце концов, протокол TCP может реализовать полнодуплексную связь между клиентом и сервером.

первое рукопожатие

Когда клиент намеревается установить TCP-соединение, он отправляет сообщение на сервер.Сегмент запроса на соединение (то есть сегмент SYN с установленным флагом SYN)Установите бит синхронизации в заголовке SYN = 1 и случайным образом выберите одинначальный серийный номерпоследовательность = х.TCP предусматривает, что сегмент SYN (то есть сегмент с SYN = 1) не может передавать данные, но потребляет порядковый номер, в это время клиентский процесс TCP переходит в состояние SYN-SENT (синхронизация отправлена)

второе рукопожатие

После того, как сервер получит сегмент запроса на соединение, если он согласен установить соединение, он отправит подтверждение клиенту.В сегменте подтверждения (сегмент SYN+ACK) бит SYN и бит ACK должны быть установлены в 1 , а номер подтвержденияack = x + 1, указывающий серийный номер, который сервер ожидает получить от клиента. В то же время он также случайным образом выбирает себе начальный порядковый номер seq = y.Обратите внимание, что этот сегмент также не может передавать данные, но также использует порядковый номер.. В это время процесс TCP-сервера входитСтатус SYN-RCVD (синхронизировано получено)

третье рукопожатие

После того, как клиент получит подтверждение, отправленное сервером, он должен снова дать подтверждение серверу. ACK сегмента подтверждения устанавливается равным 1, а номер подтвержденияack = y + 1.И собственный порядковый номер seq = x + 1, стандарт TCP предусматривает, что ACK-сегмент может нести данные, но если он не несет данных, он не имеет порядкового номера сообщения.В этом случае порядковый номер следующий сегмент данных по-прежнему seq = x + 1. Это то, что TCP-соединение было установлено, клиент переходит в состояние ESTABLISHED (соединение установлено), и сервер также входит в состояние ESTABLISHED после получения подтверждения.

Почему TCP-соединения выполняются три раза, а не два или четыре раза?

Этот вопрос больше всего понравился Чжиху, и более простое и понятное утверждение выглядит следующим образом:

三次握手：
A:“喂，你听得到吗？”
B:“我听得到呀，你听得到我吗？”
A:“我能听到你，今天balabala……”

两次握手：
A:“喂，你听得到吗？”
B:“我听得到呀”
A:“喂喂，你听得到吗？”
B:“草，我听得到呀！！！！”
A:“你TM能不能听到我讲话啊！！喂！”
B:“……”

四次握手：
A:“喂，你听得到吗？”
B:“我听得到呀，你听得到我吗？”
A:“我能听到你，你能听到我吗？”
B:“……不想跟傻逼说话”

Цель трехэтапного рукопожатия состоит не только в том, чтобы взаимодействующие стороны поняли, что соединение устанавливается, но и в том, чтобы использовать параметры пакета данных для переноса специальной информации для обеспечения надежности канала между двумя сторонами связи. Ссылка:Ууху. Call.com/question/24…

помахал четыре раза

первая волна

Клиент отправляет на серверСегмент освобождения соединения (то есть сегмент с флагом FIN, установленным в 1), и снова прекратить отправку данных, клиент устанавливает бит управления завершением FIN заголовка освобождаемого соединением сегмента в 1, а его порядковый номер равен seq = u, что равно порядковому номеру последнего байта ранее переданные данные плюс 1. В этот момент клиент вводитСтатус FIN-WAIT-1 (завершить ожидание 1), дождитесь подтверждения от B. Обратите внимание, что TCP предусматривает, что даже если сегмент FIN не несет данных, он использует порядковый номер.

вторая волна

После того, как сервер получил сегмент освобождения соединения, он отправляет подтверждение, номер подтверждения ack = u + 1, а собственный порядковый номер сегмента v, равный порядковому номеру последнего байта данных, ранее переданных Добавьте 1. Затем сервер переходит в состояние CLOSE-WAIT (ожидание закрытия). В это время установлено TCP-соединение.наполовину закрытыйСтатус, то есть у клиента нет данных для отправки, но если сервер отправляет данные, то клиент все равно должен их получить. Соединение от сервера к клиенту не закрыто, и это состояние может длиться некоторое время.

После того, как клиент получает подтверждение от сервера, он входит вFIN-WAIT-2 (завершить ожидание 2)Статус, ожидание сегмента освобождения соединения, отправленного сервером

Третья волна

Если у сервера больше нет данных для отправки клиенту, его прикладной процесс уведомляет сервер о разрыве соединения. В это время сегмент освобождения соединения, отправленный сервером, должен иметь FIN = 1. Теперь предположим, что порядковый номер сервера равен w (в полузакрытом состоянии B мог отправить еще какие-то данные). Сервер также должен повторить номер подтверждения ack = u + 1, который был отправлен в последний раз. В это время B входит в состояние LAST-ACK (последнее подтверждение) и ожидает подтверждения от A.

четвертая волна

После того, как клиент получит от сервера сообщение об освобождении соединения, он должен его подтвердить. ACK устанавливается равным 1 в сегменте подтверждения, а номер подтверждения ack = w + 1. А его собственный порядковый номер — seq = u + 1 (по стандарту TCP ранее отправленный FIN-сегмент потребляет порядковый номер). затем введитеTIME-WAIT (время ожидания) состояние. В это время TCP-соединение не было разорвано, и клиент переходит в состояние CLOSED после ожидания времени, установленного счетчиком времени, равным 2MSL.

Почему он машет четыре раза?

A: hi,我要关闭连接了
B: 好的，我收到了，我不接受你的数据了
B: hi,我也想关闭连接了
A: 好的，我不接收你的数据了。

Клиент сначала отправляет серверу запрос на закрытие, указывая, что клиент больше не отправляет данные, и сервер подтверждает это, однако в это время сервер также может отправить сообщение клиенту. сервер, сервер также отправит клиенту запрос на закрытие, затем клиент подтвердит

Полузакрытие TCP

Как упоминалось выше, TCP имеет полузакрытое состояние, хотя для некоторых приложений требуется эта функция, но это не является распространенным явлением. Полузакрытие TCP означает, что когда одна сторона завершила передачу данных и отправила FIN другой стороне, но все еще надеется получить данные от другой стороны, пока другая сторона не отправит ей FIN, в этом если он находится в полузакрытом состоянии TCP.

Почему клиент должен ждать состояния 2MSL в состоянии TIME-WAIT

Состояние TIME_WAIT также известно как состояние ожидания 2MSL. В этом состоянии TCP будет ожидать в два раза больше максимального времени жизни сегмента (MSL), что иногда называют двойным ожиданием. Это позволяет TCP повторно отправить окончательный ACK, чтобы избежать потери, а окончательный ACK повторно отправляется не потому, что TCP повторно передал ACK (они не используют порядковые номера и не передаются повторно TCP), а потому, что связь Другая сторона повторно передала свой FIN. (он потребляет порядковый номер)

Краткий анализ перехвата пакетов Wireshell

Ниже приводится краткий анализ захвата пакетов с использованием Wireshell. Ниже приводится краткое описание трехэтапного рукопожатия и четырехстороннего волнового процесса. Дополнительные сведения о захвате пакетов см. в соответствующих статьях. по IP-адресу192.168.43.187и54.190.14.101Например анализ.

трехстороннее рукопожатие

Четырехволновой процесс

HTTP-запрос и ответ

После того, как браузер установит TCP-соединение с сервером, он может начать инициировать HTTP-запросы.Клиент начинает отправлять HTTP-запросы на сервер в соответствии с заданным форматом.После получения запроса сервер анализирует HTTP-запрос, обрабатывает бизнес-логика и возвращает HTTP-ответ клиенту,Как показано ниже:

Сообщение HTTP-запроса и ответное сообщение

Сообщение HTTP-запроса имеет ту же структуру, что и сообщение-ответ. Оно разделено на заголовок сообщения и тело сообщения. Тело сообщения-запроса в основном состоит из данных, отправляемых на сервер, а тело сообщения-ответа — это клиент. , Требуемые данные ответа

Содержимое заголовка сообщения запроса и сообщения ответа состоит из следующего содержимого:

• Строка запроса: содержит метод, использованный для запроса, URI запроса и версию HTTP.
• Строка состояния: содержит код состояния, фразу причины и версию HTTP, указывающую результат ответа.
• Поля заголовков: Содержат различные заголовки, представляющие различные условия и атрибуты запросов и ответов.
• Другое: включить заголовки (файлы cookie), не определенные в HTTP RFC и т. д.

PS: Для получения дополнительной информации о полях заголовка HTTP см.«Иллюстрированный HTTP»

Общие методы запроса HTTP

Наиболее часто используемые методы запросов в HTTP в основном включают: GET, POST, PUT, DELETE.

• GET: запросить данные из указанного ресурса
• POST: используется для передачи тела объекта и создания ресурса
• PUT: используется для создания или обновления ресурсов.
• DELETE: используется для удаления указанного ресурса

Код состояния HTTP возвращаемого результата

Вот некоторые распространенные коды состояния:

• 2ХХ успехов:
  • 200 OK Запрос клиента был нормально обработан сервером
  • 204 Нет содержимого: запрос был успешно обработан, но ресурсы не могут быть возвращены.
• 3XX редирект
  • 302Обнаружено временное перенаправление, запрошенный ресурс был назначен новому URI. Есть надежда, что пользователи смогут получить доступ, используя новый URI.
  • 304 Not Modified: когда клиент отправляет условный запрос, сервер разрешает запросу доступ к ресурсу, но если условие не выполняется после выполнения запроса, он возвращает 304 напрямую, а ответ не содержит никакой части тела ответа. .
• 4XX ошибка клиента
  • 400 Bad Request В сообщении запроса содержится синтаксическая ошибка.
  • 401 Отправленный запрос требует аутентификации через HTTP
  • 403 Forbidden Сервер отказывает в доступе к запрошенному ресурсу
  • 404 Not Found Ресурс не существует на сервере. Веб-страница не существует.
• 5ХХ ошибка сервера
  • 500: На сервере произошла внутренняя ошибка.
  • 503: Сервер временно перегружен или отключен для обслуживания и не может сейчас обрабатывать запросы.
  • 504: (Время ожидания шлюза) Сервер действовал как шлюз или прокси, но не получил своевременный запрос от вышестоящего сервера.

резюме

Вышеприведенное объясняет процесс запроса URL в браузере, начиная сКэш браузера -> Разрешение доменного имени DNS -> TCP-соединение -> HTTP-запрос и ответАнализируются эти четыре этапа.Веб-запрос условно разбивается на несколько процессов.Конечно,должно быть много деталей,которые не были замечены.Если есть вопросы,пишите.

Ссылки и благодарности

• Глубокое понимание механизма кэширования браузера
• Примечания: Извлечение данных через DNS при атаке SQL Injection
• Глубокое погружение в веб-технологию Java (пересмотренное издание)
• Компьютерная сеть Xie Xiren Edition
• Объяснение TCP/IP, том 1: Протоколы
• Почему TCP — это трехстороннее рукопожатие, а не двух- или четырехстороннее? -Знаю почти
• Графический HTTP