|
Отладка HTTP-соединения при помощи CommView
Технические особенности передачи данных по протоколу передачи гипертекста (HTTP) зачастую остаются загадкой для пользователя и даже для администратора вебсервера. При помощи инструмента TamoSoft CommView (пробную версию можно скачать бесплатно с сайта производителя) мы попробуем установить, в чём может быть проблема при передаче данных клиент-сервер.
Для начала мы рассмотрим непосредственно основы обмена данных по HTTP. Этот протокол использует другой широко распространённый протокол TCP/IP. Это означает, что при установлении соединения клиент и сервер совершают трёхэтапный обмен пакетами прежде, чем начать передачу полезной информации. Сначала клиент отсылается серверу пакет TCP с установленным флагом SYN, сервер отвечает на него пакетом с флагами SYN и ACK, на что, наконец, клиент подтверждает установку соединения пакетом с флагом ACK.
Монитор трафика CommView предоставляет очень много информации по проходящим через выбранный сетевой интерфейс данным, поэтому необходимо ограничить их, воспользовавшись установкой правил. Выберем закладку "Правила", в ней "IP-адреса" и введём IP-адрес сервера saytostroy.ru - 72.10.166.146 (его можно получить, воспользовавшись утилитой nslookup, об этом написано в статье "Почему не открывается сайт?"). В качестве параметров выберем "Действие: захват" и "В любом направлении", см. рисунок:
Теперь, если начать захват передаваемых пакетов (кнопка "Начать захват"), в закладке "Текущие IP-соединения" отобразится список соединений клиент-сервер, а в закладке "Пакеты" отобразится список переданных пакетов. Разумеется, чтобы появились эти данные, необходимо попытаться открыть в браузере сайт saytostroy.ru.
Что же мы видим в закладке "Пакеты" CommView? Появилась пара сот записей в направлениях клиент-сервер и сервер-клиент. Если выбрать любую строчку в списке пакетов, на специальной панели отобразится вся полезная информация по данному пакету. Структура этой информации такова: Протокол - Параметры протокола. Если выбрать первый пакет, направленный серверу (он должен быть и первым в списке), то раскрыв вкладку TCP, в поле Flags мы увидим установленный флаг SYN:
Можно увидеть и ряд других вкладок в информации о пакете, их набор полностью зависит от типа Вашего соединения. Например, на рисунке присутствует вкладка Ethernet II, что говорит о передаче данных в сети по выделенной линии типа ethernet. Так же присутствует протокол маршрутизации GRE. Это отличная сфера для исследования новичками в сетевых технологиях.
Но вернёмся к нашему соединению. Мы установили, что первые три пакеты нацелены на установление надёжного соединения клиент-сервер, и если они зафиксированы в нашем мониторе CommView по обозначенной схеме, значит, по крайней мере соединение благополучно установлено:
На рисунке IP-адрес клиента размыт нарочно, но на Вашем компьютере будет отображён Ваш IP-адрес.
Если эти три пакета не прошли в нужном порядке, значит, присутствует проблема в сети. Например, Ваш IP-адрес может быть блокирован на оборудование вебсервера, в этом случае не придёт ответный пакет SYN-ACK. Подтвердить эту ситуацию повторная передача пакета с флагом SYN, которая скорее всего состоится в случае неудачной первой отправки. Соответственно, обратную блокировку, от клиента к серверу на Вашем компьютере, подтвердит отсутствие пакетов к серверу. Впрочем, ситуация может оказаться гораздо сложнее и адресата могут достигать лишь часть пакетов, фильтруясь по произвольному правилу, мы эти случаи не рассматриваем.
Далее наш браузер передаёт запрос вебсерверу по протоколу HTTP. Если разных никаких данных прикладного уровня не передавалось, то теперь они появились, что видно по наличию в информации о пакете дополнительной вкладки - HTTP:
Мы видим, что браузер (в приведённом примере FireFox, его идентификатор процесса указан во вкладке Ethernet II) использовал метод GET для получения странички с сайта saytostroy.ru. Полный запрос браузера в текстовом виде выглядит следующим образом:
GET / HTTP/1.1
Host: saytostroy.ru
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: ru-ru,ru;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Можно провести дополнительный эксперимент, передав серверу ровно эти же данные, воспользовавшись консольной утилитой telnet:
C:>telnet saytostroy.ru 80
И затем приведённые выше данные. Не забудьте в конце кода запроса дважны нажать Enter, иначе сервер не поймёт, что запрос сформирован. Число 80 является стандартным номером порта протокола HTTP. В ответ должны появиться данные на языке разметки HTML, обрабатываемые браузером.
В списке перехваченных пакетов вслед за запросом идёт пакет с установленным флагом ACK протокола TCP, но без HTTP, что говорит клиенту (в данном случае браузеру) о том, что пакет в обработке и скоро поступят запрошенные данные. А затем идёт и сам пакет с данными с флагом ACK:
Мы вновь получили целый ряд служебных полей, наиболее важным из которых является Result code - это код ошибки HTTP. Если Вы пока не знаете этих кодов, можно воспользоваться его краткой расшифровкой в поле Result string. В данном случае всё прошло нормально и данные переданы, о чём свидетельствует строка "OK". А в стандарте протокола HTTP прописаны следующие диапозоны ошибок:
- 100-199 - Информационный. Сообщает клиенту, что запрос клиента принят и обрабатывается.
- 200-299 - Запрос клиента обработан успешно, сервер отправил клиенту запрашиваемый документ.
- 300-399 - Запрос клиента изменён и клиенту нужно предпринять некоторые действия для удовлетворения измененного запроса. Чаще всего это означает переадресацию на другой адрес документа.
- 400-499 - Проблемы при попытке выполнить запрос.
- 500-599 - Ошибки сервера. Это чаще всего связано с исполнением сценариев на сервере.
Теперь Вы можете диагносцировать ошибку на вебсервере, если таковая сообщается протоколом HTTP.
Данные, полученные от сервера, скрываются в поле Data. Чтобы их просмотреть, нужно заглянуть в другую вкладку, где отображается содержимое пакета в текстовом и шестнадцатеричном виде.
Для чистоты эксперимента мы не рассматривали многих важных моментов протоколов TCP, IP и HTTP, но не следует забывать о них. К примеру, в последнем рассмотренном нами пакете скорее всего Вы получите лишь часть веб-страницы, потому что пакет был фрагментирован и в пакете дошла лишь часть страницы. Это связано с пропускной способностью канала. Данные передаются небольшими кусками, размер которых зависит от типа канала и его конфигурации.
Кроме того, мы положились на то, что одновременно с веревром ведётся только одна передача, установлено лишь одно соединение, хотя зачастую это не так - например, изображения, баннеры и плавающие фреймы могут загружаться параллельно с запрашиваемой страницей. Для того, чтобы чётко установить последовательность передачи пакетов, необходимо обращаться к полям Sequence и Acknowledgement протокола TCP.
В пакете, отправляемом от узла А к узлу Б устанавливается номер Sequence, выбранный узлом А:
Sequence: 0x33A9FEE4 (866778852)
Acknowledgement: 0x00000000 (0)
Здесь мы видим, что поле Acknowledgement содержит нулевое значение, это связано с тем, что для примера я привёл первый переданный пакет. В ответ узел Б передаёт узлу А следующую пару полей:
Sequence: 0x46D56DCD (1188392397)
Acknowledgement: 0x33A9FEE5 (866778853)
Легко увидеть, что поле Acknowledgement нового пакета на единицу больше поля Sequence предыдущего. В новом пакете так же сформировано поле Sequence для того, чтобы узел А дал ему подтверждение, занеся в поле Acknowledgement и увеличив на единицу.
Эти и другие вопросы протоколов я оставляю на рассмотрение читателей. Существуют документы, стандартизирующие эти моменты, они носят название RFC. В интернете есть и русские переводы этих стандартов.
Надеюсь, что сведения, приведённые в статье, помогли Вам получить представление о передаче данных по TCP/IP-HTTP и найти ошибки при передаче вебстраниц.
|
|
|
