Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Почему так медлительна Web?

Роберт Г. Московиц

Что имеется в виду, когда говорят, что Internet перегружена? Как объяснить замеченный многими специалистами факт, что доступ по протоколу FTP намного эффективнее по сравнению с Web-доступом при обращении к одному и тому же серверу. Почему так часто при попытке связаться с Web-сервером вы видите на экране “Host Connected. Waiting Reply” (“Есть контакт. Ждите ответа”)? Причина скрыта в протоколе HTTP (HyperText Transfer Protocol) WWW и в неэффективном использовании языка HTML (HyperText Markup Language) при построении Web-страниц.

В сети Web для начала сеанса связи между клиентом и Web-сервером применяют протокол TCP, который номинально контролирует заторы в сети, но для Web это не всегда верно. Поверх протокола TCP функционирует протокол передачи гипертекста HTTP, который не может извлекать несколько объектов за один просмотр. Вместо этого каждый объект определяется как URL (универсальный указатель ресурса), погруженный в базовый объект HTML, и извлекается во время отдельного сеанса HTTP. Таким образом, если страница содержит несколько встроенных указателей URL, например файлов картинок, потребуется столько же сеансов по протоколу TCP. Такая архитектура и является причиной отмечаемого многими замедления работы Internet.

Заторы в сети

Статистические данные коммутации потоков маршрутизатором Cisco 7505, расположенным между Сент-Луисом и Канзас-Сити — в не слишком оживленном “углу” Internet, — приведены в таблице. В ней поток — это один сеанс. За 39 с лишним часов прошло 58 млн потоков. Из них 55% пришлось на HTTP. Средний Web-поток длился 41 с, из них 68% — время простоя. Для пользователя, ожидающего перед экраном компьютера, — это довольно долго.

Анализ работы другого маршрутизатора, пропускающего более напряженный трафик, показал, что средний Web-поток включает 13 пакетов из 3562 байтов, из которых более 750 байтов имеют вспомогательное назначение и не несут полезной информации. Это средние значения для небольшой передачи HTTP. Значения несколько различаются для текстовых страниц и страниц, содержащих небольшие графические файлы в формате GIF, предназначенные для оформления рубрик (bullet), и пиктограммы.

Длина подобных потоков пакетов недостаточна для функционирования процедуры “медленного старта” Ван Якобсена, которая сначала посылает пакеты TCP замедленно и только после подтверждения успешного приема нескольких пакетов повышает скорость. Ускорение передачи происходит до тех пор, пока получение подтверждений не замедлится, что свидетельствует о перегрузке сети. Тогда работа опять замедляется. Сам Ван Якобсен часто говорил, что “медленный старт” годится, чтобы пасти слонов, но не мышей.

Поскольку короткие потоки пакетов не замедляются, многие пакеты теряются на магистральных маршрутизаторах, что приводит к значительному числу повторных передач. Производительность же длинных сеансов, например больших передач FTP и HTTP, понижается из-за действия процедуры “медленного старта”, которая замедляет их при переполнении канала короткими сеансами HTTP.

Задержки на сервере

Статистика показывает также слишком много коротких сеансов HTTP по отношению к общему объему передаваемых данных. Часто Web-страницы содержат множество небольших пиктограмм, извлекаемых с помощью отдельных потоков. Это оказывает значительное отрицательное воздействие на работу Web-сервера и существенно увеличивает время ожидания на стороне пользователя.

Каждый сеанс TCP требует выделения системных ресурсов (памяти) сервера в ядре TCP, называемых блоком управления транзакциями (Transaction Control Block — TCB). TCB может занимать от 8 до 32 Кбайт. Большинство Unix-систем имеет фиксированное число TCB (256, 512 или 1024). Самое главное, что TCB не может использоваться для следующего сеанса, пока не пройдут 2 мин, зарезервированные для обработки возможных затерявшихся пакетов, которые могут прийти уже после окончания сеанса. Это состояние называется TIME-WAIT (время ожидания), и его можно наблюдать с помощью команды NETSTAT.

Для Web-страницы с 9-ю пиктограммами будет занято 10 TCB. Даже если перегрузка сети не слишком задержит процесс считывания, — возможно, всего на 1 мин для всех 10 объектов HTML, — то 10 TCB будут блокированы в течение 3 мин, с учетом времени ожидания. В результате загруженный сервер не может выделять TCB для новых сеансов. Тогда пользователь и получает сообщение “Host Connected. Waiting Reply” и ждет. Это и есть основная причина жалоб пользователей на перегрузку Internet.

Сиюминутные улучшения

Улучшить рабочие характеристики Web-узла можно двояко: во-первых, увеличив число доступных TCB, во-вторых, уменьшив число объектов на странице и снизив тем самым число требуемых TCB.

Увеличение числа блоков TCB не всегда возможно и зависит от ОС, с которой вы работаете. Некоторые версии Unix поддерживают максимально возможное число TCB, а именно 32 000. Одна из таких систем — AIX фирмы IBM. ОС Solaris 2.5 фирмы Sun также обеспечивает достаточно много TCB. Но их максимум в других системах обычно равен 512.

Если позволяет сервер, постарайтесь сделать этот параметр (иногда его обозначают Max User) как можно больше, но так, чтобы не нарушить стабильности системы. Это может потребовать увеличения объема памяти и других ресурсов системы, связанных с параметром Max User. Увеличение числа TCB сразу же понизит частоту появления неприятного сообщения “Ждите ответа”, однако не снизит нагрузку на сеть.

Уменьшение же числа объектов на странице не только улучшит рабочие характеристики Web с позиции пользователя, но и сделает эффективнее саму сеть. HTML-карта может заменить несколько пиктограмм и существенно снизить реальный объем данных и сетевой трафик при одновременном увеличении общей длины потока HTML, посылаемого браузеру. Упомянутые ранее 10 объектов занимали 130 пакетов, но два объекта (страница и карта) могут занять только 66 пакетов (в предположении, что большая карта занимает на 10 пакетов больше, чем небольшая пиктограмма). Хорошо сделанная карта может выглядеть ничуть не хуже, чем набор обособленных пиктограмм.

Более основательные меры

Радикальным средством улучшения Web представляется введение новой возможности, так называемого “постоянного соединения” (persistent connection). Самое простое применение этого соединения позволит исполнять несколько команд HTTP GET за один сеанс TCP. Ожидается, что такое расширение значительно облегчит работу пользователям Web. Семь из 13 упомянутых выше пакетов будут устранены в результате использования нескольких команд GET.

Проекты предложений по внедрению этого механизма сейчас рассматриваются в инженерной проблемной группе Internet (Internet Engineering Task Force — IETF), и ожидается, что они вступят в действие в этом году. Когда появится это усовершенствование, оно, вероятно, очень быстро распространится по Internet. Как только достаточно много Web-узлов переоборудуют свои серверы на поддержку постоянных соединений, улучшение работы сетей станет заметным.




  

 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх