Пошук несправностей веб-сайту шляхом вивчення HTTP-трафіку, Різне, Програмування, статті

Active Server Pages (ASP) компанії Microsoft є попередником ASP.NET. ASP був простим скриптовою движком, в якому не вистачало інструментарію, настільки використовуваного розробниками ASP.NET сьогодні, і більшою мірою це відладчик. Налагодження скрипта ASP зазвичай полягала в заповненні коду виразами Response.Write, щоб вивести значення змінних в різних точках часу життєвого циклу скрипта. Налагодження сторінки ASP.NET набагато простіше завдяки відладчику Visual Studio, який дозволяє вам встановити точки зупинки, прошагать по виконуваному коду, використовувати вікна Watch – вікно для перегляду значень змінних, в той час як вони змінюються, а також вікно Intermediate для обчислення виразів під час налагодження.

Хоча відладчик Visual Studio значно поліпшив процес налагодження, існують випадки, коли відладчик серверної сторони не приносить багато користі. У певних випадках проблема полягає не в серверному коді, а в тому, що посилається від клієнта на сервер (або навпаки). Такі випадки нерідко зустрічаються при створенні веб-додатків, заснованих на AJAX, так як дані, якими обмінюються клієнт і сервер під час часткового сторінкового постбека, впливають на код, виполеннний на серверній стороні, а також на спосіб оновлення сторінки у відповідь. Дана техніка також дуже придатна при налагодженні сторінок, які виконують різні команди Response.Redirect, грунтуючись на різних параметрах, або при спробі визначення чому зображення, відео або зовнішнє вміст не завантажується коректно на веб-сторінці.


На відміну від відладчика серверного коду, вивчення HTTP-трафіку, посланого між клієнтом і сервером, звичайно виконується на стороні клієнта – а саме, від браузера, а не з Visual Studio. Fiddler – Це безкоштовний і відмінний інструмент для налагодження HTTP-трафіку. Дана стаття надає огляд Fiddler і демонструє спосіб його використання в допомогу до налагодження. Читайте далі, щоб дізнатися більше про це!


Навіщо потрібно переглядати HTTP-трафік


Кожен раз, коли оглядач здійснює запит на веб-сервер – будь це для веб-сторінки, зображення в межах веб-сторінки, CSS-файл, зовнішній JavaScript-файл, виклик веб-сервісу або все що завгодно – Це виконується у вигляді HTTP-запиту від оглядача на веб-сервер. У HTTP-запиті оглядач посилає на сервер назва ресурсу, який йому необхідний (наприклад, Default.aspx), і також іншу опціональну інформацію. Наприклад, при відсилання форми оглядач також висилає назви і значення полів даної форми. При отриманні даного повідомлення веб-сервер шукає даний ресурс і повертає його вміст. Ці дані можуть бути двійковій інформацією (для зображення, MP3, ZIP файлу і т.д.), статичної текстовою інформацією в текстовому файлі або HTML-сторінці, або динамічно-згенерованим текстовим вмістом, як у випадку з веб-сторінкою ASP.NET або веб-сервісом. Оглядач потім відображає повернуті дані, грунтуючись на їх тип.


Інформація нижнього рівня, що переміщується між клієнтом і сервером, звичайно “правильна” і працює, як належить. Зазвичай коли існує проблема в сторінці ASP.NET, вона полягає в коді фонового класу даної сторінки. У таких випадках відладчик Visual Studio є кращим інструментом по знаходженню та виправлення проблеми. Але в інших випадках проблема чи її пояснення не містяться в коді серверної частини, а знаходяться в інформації, обмінюваної між клієнтом і сервером. Для таких випадків дослідження трафіку, переміщуваного між клієнтом і сервером, є хорошим інструментом виявлення джерел проблеми.


Уявіть собі наступну проблему: у вас є сторінка ASP.NET з формою, яка містить елементи управління TextBox, Button і Label. Ідея полягає в тому, що користувач вводить якесь значення в TextBox і посилає форму, після чого на екрані відображається деяка інформація в елементі Label. Таку функціональність можна реалізувати шляхом створення обробника для події Click елемента Button і написання деякого коду для відображення відповідної інформації в елементі Label, грунтуючись на призначеному для користувача введення в TextBox. Після того, як ви напишете даний код, ви вирішите його протестувати, і якщо ви введете текст в TextBox і потім натиснете на кнопку, сторінка виконає постбек, і бажані дані будуть відображені на сторінці. Ще трохи протестувавши у вас щось може піти не так – все начебто працює, як належить, якщо користувач посилає заповнену форму, натиснувши кнопку (Button), але якщо ви натиснете клавішу Enter в той час як фокус буде на TextBox, то сторінка виконає постбек, але елемент Label нічого не відобразить. Ще більш дивним є те, що це все відбувається при тестуванні з Internet Explorer. Цікаво, чому?


Вашим першим кроком на шляху до вирішення даної проблеми може бути використання отладчика Visual Studio. Ви встановите точку зупинки в обробниках події Page_Load і Click. Це доведе вам, що сторінка була відіслана назад при натисканні на кнопку Button або в момент, коли користувач натисне клавішу Enter, маючи фокусування на елементі TextBox, і розкриє вам факт, що обробник події Click елемента Button виконується тоді, коли кнопка явно натиснута (а не в разі натискання клавіші Enter). Але такий тип налагодження надає нам відповіді на питання, чому ми маємо таку різницю в поведінці.


Це такий тип проблеми, де аналіз HTTP-трафіку, посланого між клієнтом і сервером, як раз є рішенням. Якщо ви порівняєте HTTP-трафік, посланий при натисканні кнопки на формі, і той, що був посланий при натисканні клавіші Enter, то ви помітите, що оглядач не відсилає назву і значення кнопки в другому випадку, але відсилає цю пару значень у випадку з кнопкою на формі. Для того, щоб ASP.NET знав про те, що була натиснута кнопка на формі, і отже викликав подія Click, від оглядача повинні бути відіслані назву і значення кнопки. Дана різниця пояснює спостережуване поведінку.


Зазначений вище приклад є рідкісним і конкретним випадком, коли дослідження HTTP-трафіку є першорядним рішенням вдалою налагодження проблеми. Тим не менш, такий тип аналізу дуже придатний у багатьох сценаріях. Дослідження HTTP-трафіку зазвичай є найпершою річчю, яку потрібно зробити при налагодженні веб-додатки, що підтримує AJAX. Аналіз HTTP-трафіку корисний у випадках, коли спостерігається наявність небагатьох перенаправлень з однієї сторінки на іншу, для того щоб встановити, які сторінки були відвідані і яка інформація була послана кожній з них. Аналогічно, аналіз HTTP-трафіку придатний у визначенні причин несправності зображень чи відсутності зовнішнього вмісту. Наприклад, якщо файл зображення або CSS-файл знаходяться в каталозі, який недоступний через дозволів або правил авторизації (URL authorization rules), то оглядач відобразить іконку несправного зображення, або ж не застосує правила CSS-файла. Щоб визначити причину цього, ви можете досліджувати HTTP-відповідь, повернений від даних зовнішніх файлів при запиті оглядача, де ви явно побачите те, що дані не могли бути отримані через проблеми з правами (або з якоїсь іншої причини).


Дослідження HTTP-трафіку за допомогою Fiddler


Fiddler – Це безкоштовний інструмент HTTP-налагодження, створений компанією Microsoft. Fiddler працює з хостингом браузера, але також з легкістю працює з Internet Explorer. (Дана стаття демонструє роботу Fiddler з Internet Explorer. Для того, щоб працювати з іншими браузерами, я рекомендую вам прочитати відповідну літературу.)


Для того, щоб почати працювати з Fiddler, відвідайте домашню сторінку Fiddler і встановіть програму, завантаживши її з цієї сторінки. Будучи встановленим, Fiddler доступний з Internet Explorer, а саме за допомогою меню Tools. Запуск Fiddler відкриє вам нове вікно, яке відстежує всі HTTP-запити (HTTP request), виконані браузером і відображені в лівій частині вікна. Вибір запиту зі списку виведе його деталі в праву частину вікна. В детальний опис включений звіт про продуктивність, а також інформація про запит (дані, надіслані з клієнта на сервер) і відповідь (дані, надіслані від сервера до клієнта).


Наступний малюнок демонструє Fiddler в дії. Ліва частина перераховує різні HTTP-запроcи (HTTP request). Я почав з відвідування сторінки www.google.com і потім здійснив пошук “ASP.NET”. (Різні виклики до clients1.google.com for / complete / search? hl = en … є AJAX-запити до автозаполняемому полю пошуку домашньої сторінки Google). Після перегляду результатів пошуку я натиснув на посилання www.asp.net. Оглядач завантажує домашню сторінку даного сайту, а також зовнішніх файлів, пов’язаних з сайтом: CSS-файли (. Css), JavaScript-файли (файли. Js, WebResource.axd і ScriptResource.axd), і файли зображень. Вибір запиту в лівій частині відображає деталі у правій. Оригінальний запит до www.google.com обраний в лівій частині, а статистика відображається у правій.




Fiddler є незамінним додатком і кожен розробник повинен мати його в своєму інструментарії. Єдиний недолік, який практично кожен разработік зустрічає на своєму шляху при роботі з Fiddler, це те, що Fiddler не може досліджувати HTTP-трафік, посланий до локального хосту (localhost). Доброю новиною є те, що існує декілька обхідних шляхів, якими ви можете скористатися щоб змусити Fiddler почати досліджувати HTTP-запроcи (HTTP request) до локального хосту (localhost). Цитата з поширених питань по Fiddler:


Чому я не бачу трафік, посланий до http://localhost або http://127.0.0.1?


IE7 і. NET Framework жорстко-запрограмовані таким чином, що вони не посилають запитів до Localhost допомогою будь-яких проксі, а оскільки Fiddler якраз є проксі, то він не отримає даний трафік.

Цей факт можна обійти використовуючи назву вашої локальної станції в якості імені хоста замість Localhost або 127.0.0.1. Тому, замість введення http://localhost:8081/mytestpage.aspx введіть http://machinename:8081/mytestpage.aspx.


Також існують і інші шляхи примусу Fiddler до роботи з localhost, і про це вам варто прочитати відповідну літературу.








Дослідіть Fiddler для оцінки продуктивності вашого веб-сайту
На додаток до дослідження необробленого HTTP-трафіку, Fiddler також придатний для аналізу продуктивності вашого веб-сайту. Якщо ви турбуєтеся про те, що будь-яка сторінка довго завантажується, то вам варто використовувати Fiddler, щоб побачити, є який-небудь зовнішній ресурс, який є причиною цього. Кожен запит, перерахований в лівій частині, включає розмір завантажуваного вмісту (в бітах), і список запитів може бути відсортований по даній колонці. Якщо коротко, ви можете відразу помітити невиправдано великі запити, такі як великі файли зображень або JavaScript-файли, які можна піддати компресії. Закладка Statistics (Статистика) в правій частині демонструє загальну кількість надісланих та отриманих бітів для обраних запитів в лівій частині.

Закладка Statistics (Статистика) в правій частині демонструє загальну кількість надісланих та отриманих біт для вибраннизх запитів в лівій частині. На додаток до загального числа бітів в закладці Statistics ви також знайдете реальні дані про час, який необхідно було витратити на виконання обраних запитів, біти розділені типом вмісту і приблизний час завантаження в різних географічних місцях з різною швидкістю (DSL або modem).


Закладка “Session Inspector” (Інспектор сесії) відображає інформацію про те, чи був запит стиснутий компресією на сервері до того, як він був відісланий клієнту. Якщо не була застосована HTTP-компресія (HTTP compression) , То ви можете вибрати одну із стандартних технік HTTP-компресії (GZIP або DEFLATE) і побачити скільки бітів будуть зекономлені при реалізації компресії.


Використання Fiddler для аналізу HTTP-трафіку клієнтських додатків


Якщо у вас є клієнтські програми, які виконують запити Web-Service, очищають екран або виконують будь-які інші види HTTP-запроcов, то ви можете використовувати Fiddler під час налагодження для того, щоб дослідити дані запити та відповіді. Коротенько, вам необхідно запустити Fiddler і потім оновити код вашого клієнтського додатка таким чином, щоб воно використовувало Fiddler в якості проксі. Наступний код виконує все це:

“Створіть клас, який викликає веб-сервіс
Dim service As New MyWebServiceProxyClass()

“Використовуйте Fiddler в якості проксі
service.Proxy = New WebProxy(“127.0.0.1”, 8888)

“Виконайте HTTP-запроc
service.MethodToInvoke(…)


І це все! Включивши даний код ваш запит веб-сервісу буде перенаправлений через Fiddler і ви побачите запит і відповідь в Fiddler. Зручно, не чи правда? Для отримання більш докладної інформації про цю техніку, а також інструкції по налаштуванню Fiddler на роботу з оглядачами типу Firefox, вам варто ознайомитися зі статтями на цю тему.


Висновок


Багато проблем веб-сайтів найлегше вирішити, використовуючи відладчик Visual Studio. Тим не менш, існує безліч несправностей, які неможливо розпізнати через помилки коду серверної сторони, але замість цього вам необхідно працювати з інформацією, обмінюваної між клієнтом і сервером. Для таких несправностей дослідження трафіку між клієнтом і сервером є ключем до розгадки проблеми. Доброю новиною є те, що існує Fiddler – відмінний безкоштовний інструмент для дослідження HTTP-трафіку.


Веселого програмування!

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*