Э. Таненбаум - Компьютерные сети. (4-е издание) (DJVU) (1130092), страница 188
Текст из файла (страница 188)
Современные веб-серверы часто содержат сотни комбинаций типов и подтипов файлов, Новые типы файлов появляются всякий раз при установке новых программ. Вспомогательные приложения не обязательно связаны только с М1МЕ-типом аррйсайоп (приложение). Например, Аг)оЬе РЬосозЬор будет работать с (табе,гхр)юпм)гор, а Кеа1Опе Р1ауег может поддерживать аийо/т)тЗ. В ттьг)пг)отче каждая устанавливаемая на компьютер программа регистриру~~ типы, которые она хочет поддерживать, Такой механизм приводит к конфликту, когда несколько программ могут обрабатывать один и тот же полтин, например, иЫео,/гнре. Конфликт разрешается следующим образом: программа, которая регистрируется последней, затирает своей записью существующу1о ассоциацию (тип М1МЕ, вспомогательное приложение) для тех типов, которые она готова обрабатывать самостоятельно.
Следствием этого является то, что каждая уста- 700 Глава 7. Прикладной уровень навливаемая программа может изменить метод отображения браузером некоторых типов. В 1)Ы1Х этот процесс обычно не является автоматическим. Пользователь должен вручную обновлять конфигурационные файлы. Такой подход приводит к уменьшению числа неожиданных сюрпризов, но при этом у пользователя появляются дополнительных заботы. Браузеры могут работать и с локальными файлами, не запрашивая информацию с удаленных серверов. Поскольку локальные файлы не сообщают свои М1МЕ- типы, браузеру нужно каким-то хитрым образом определить, какой подключаемый модуль или вспомогательное приложение использовать для типов, отличных от встроенных (таких, как 1ех~гйгт1 или !табе>)рей).
Для поддержки локальных файлов вспомогательные модули и приложения должны быть ассоциированы как с расширениями файлов, так и с типами М1МЕ. При стандартных настройках попытка открыть файл !оо.рг1! приведет к его открытию в АсгоЬац а файл Ьаг.атос будет открыт в ЪЧогг1. Некоторые браузеры для определения типа М1МЕ используют не только данные о типе М1МЕ, но и расширение файла и даже данные, взятые из самого файла. В частности, 1пгегпег Ехр1огег по возможности старается ориентироваться на расширение файла, а не на тип М1МЕ. Здесь также возможны конфликты, поскольку многие программы страстно желают поддерживать, например, .трд.
Профессиональные программы при установке обычно выводят флажки, позволяющие выбрать поддерживаемые типы М!МЕ и расширения. Таким образом, пользователь может выбрать то, что ему требуется, и таким образом избежать случайного затирания существующих ассоциаций. Программы, нацеленные на массового потребителя, полагают, что большинство пользователей понятия не имеют о типах М1МЕ и просто захватывают все что могут, совершенно не обращая внимания на ранее установленные программы.
Расширение возможностей браузера цо поддержке новых типов файлов — это удобно, но может также привести к возникновению некоторых проблем. Когда 1пгегпес Ехр!огег получает файл с расширением ехе, он думает, что это исполняемая программа и никаких вспомогательных средств для нее не требуется.
Очевидно, следует просто запустить программу. Однако такой подход может оказаться серьезной дырой в системе защиты информации. Злоумышленнику требуется лишь создать нехитрый сайт с фотографиями, скажем, знаменитых киноактеров или спортсменов и поставить ссылки на вирусы. Один-единственный шелчок мышкой на фотографии может в этом случае привести к запуску непредсказуемой и, возможно, опасной программы, которая будет действовать на машине пользователя. Для предотвращения подобных нежелательных ситуаций 1пгегпег Ехр1огег можно настроить на избирательный запуск неизвестных программ, однако не все пользователи в состоянии справиться с настройкой браузера.
В 1)Ы1Х похожая проблема может возникнуть с основными сценариями, однако при этом требуется, чтобы пользователь сознательно стал устанавливать вспомогательную программу. К счастью, это процесс довольно сложный, и «случайноь установить что-либо практически невозможно (немногие могут сделать это и преднамеренно). Всемирная паутина (Ууууу) 701 Сторона сервера О стороне клиента сказано уже достаточно много. Поговорим теперь о стороне сервера. Как мы уже знаем, когда пользователь вводит ПИ или щелкает на гнперссылке, браузер производит структурный анализ (1И.
и интерпретирует часть, заключенную между ЬГтру/ и следующей косой чертой, как имя 1)115, которое следует искать. Вооружившись 1Р-адресом сервера, браузер устанавливает ТСР- соединение с портом 80 этого сервера. После этого отсылается команда, содержащая оставшуюся часть ()В1., в которой указывается имя файла на сервере. Сервер возвращает браузеру запрашиваемый файл для отображения.
В первом приближении веб-сервер напоминает сервер, представленный в листинге 6.1. Этому серверу, как и настоящему веб-серверу, передается нмя файла, который следует найти и отправить. В обоих случаях в основном цикле сервер выполняет следующие действия: 1. Принимает входящее ТСР-соединение от клиента (браузера). 2. Получает имя запрашиваемого файла. 3. Получает файл (с лиска). 4.
Возвращает файл клиенту. 5. Разрывает ТСР-соединение. Современные веб-серверы обладают более широкими возможностями, однако существенными в их работе являются именно перечисленные шаги. Проблема данного подхода заключается в том, что каждый запрос требует обращения к лиску для получения файла. В результате число обращений к веб-серверу за секунду ограничено максимальной скоростью обращений к диску. Среднее время доступа к высокоскоростному диску типа 5С51 составляет около 5 мс, то есть сервер может обрабатывать не более 200 обращений в секунду. Это число даже меньше, если часто запрашиваются большие файлы. Для крупных веб-сайтов это слишком мало. Очевидным способом решения проблемы является кэширование в памяти п последних запрошенных файлов.
Прежде чем обратиться за файлом к диску, сервер проверяет содержимое кэша. Если файл обнаруживается в кэше, его можно сразу выдать клиенту, не обращаясь к диску. Несмотря на то, что для эффективного кэширования требуются болыпие объемы памяти и некоторое дополнительное время на проверку каша н управление его содержимым, суммарный выигрыш во времени почти всегда оправдывает эти накладные расходы и стоимость. Следующим шагом, направленным на повышение производительности, является создание многопоточных серверов. Одна из реализаций подразумевает, что сервер состоит из входного модуля, принимающего все входящие запросы, и я обрабатывающих модулей, как показано на рис.
7.9. Все й + 1 потоков принадлежат одному и тому же процессу, поэтому у обрабатывающих модулей есть доступ к кашу в адресном пространстве процесса. Когда приходит запрос, входящий модуль принимает его и создает краткую запись с его описанием. Затем запись передается одному из обрабатывающих модулей. Другая возможная реализация подразумевает отсутствие вхолного модуля; все обрабатывающие модули пыта- 702 Глава 7. Прикладной уровень ются получить запросы, однако здесь требуется блокирующий протокол, помогающий избежать конфликтов. Машина веб-сервера Обрабатывающий модуль (поток) Входлший Исходящий запрос ответ Рис.
7.9. Многопоточный веб-сервер с входным и обрабатывающими модулями Обрабатывающий модуль вначале проверяет кэш на предмет нахождения там нужных файлов. Если они там действительно есть, ои обновляет запись, включая в нее указатель иа файл. Если искомого файла в кэше нет, обрабатывающий модуль обращается к диску и считывает файл в кэш (при этом, возможно, затирая некоторые храияшиеся там файлы, чтобы освободить место). Считанный с диска файл попадает в кэш и отсылается клиенту. Преимущество такой схемы заключается в том, что пока один или несколько обрабатывающих модулей заблокированы в ожидании окончания дисковой операции (при этом такие модули ие потребляют мощности центрального процессора), другие модули могут активно обрабатывать захваченные ими запросы.
Разумеется, реального повышения производительности за счет многопоточной схемы можно достичь, только если установить несколько дисков, чтобы в каждый момент времени можно было обращаться более чем к одному диску. Имея в обрабатывающих модулей и тт дисков, производительность можно повысить в Я раз по сравнению с одиопоточиым сервером и одним диском. Теоретически, однопоточиый сервер с в дисками тоже должен давать прирост производительиости в Й раз, однако программирование и администрирование такой схемы оказывается очень сложным, так как в этом случае невозможно использование обычных блокирующих системных вызовов йся0 для чтения с диска. Многопоточные серверы такого ограничения ие имеют, поскольку йсдй будет блокировать только тот поток, который осуществил системный вызов, а не весь процесс. Современные веб-серверы выполняют гораздо больше функций, чем просто прием имен файлов и отправка файлов.
На самом деле, реальная обработка каждого запроса может оказаться довольно сложной. По этой причине иа многих серверах каждый обрабатывающий модуль выполняет серии действий. Входной Всемирная паутина 1у1ЙМВ1) 703 модуль передает каждый входящий запрос первому доступному модулкл к„торый обрабатывает его путем выполнения некоторого подмножества указанных далее шагов в зависимости от того, что именно требуется для данного запроса. + вычисление имени запрашиваемой веб-страницы; + регистрация клиента; + осуществление контроля доступа для клиента; + осуществление контроля доступа для веб-страницы; + проверка коша; + получение запрошенной страницы с диска; + определение типа М1МЕ для включения этой информации в ответ клиенту; + аккуратное выполнение различных дополнительных задач; + возвращение ответа клиенту; + добавление записи в журнал активности сервера. Шаг 1 необходим, потому что входящий запрос может и не содержать реального имени файла в виде строкового литерала.
Например, 13ВЕ может быть вот таким: оцр:оаач~.сз.чшпб Здесь имя файла отсутствует. Этот НЕЕ необходимо дополнить неким именем файла по умолчанию. К тому же современные браузеры могут указывать язык пользователя по умолчанию (например, итальянский или английский), что позволяет серверу выбирать веб-страницу на соответствующем языке, если таковая существует. Вообще говоря, расширение имени— задача не такая уж тривиальная, как может показаться, поскольку существует множество соглашений об именовании файлов. Шаг 2 состоит в проверке идентификационных данных клиента. Это нужно для отображения страниц, недоступных для широкой публики. Мы обсудим один из способов такой проверки далее в этой главе. Шаг 3 проверяет наличие каких-либо ограничений, накладываемых на данного клиента и его местоположение.
На шаге 4 проверяются ограничения на доступ к запрашиваемой странице. Если определенный файл (например,,о1ассезз) присутствует в том же каталоге, что и нужная страница, он может ограничивать доступ к файлу. Например, можно установить доступ к странице только для сотрудников компании. Шаги 5 и 6 включают в себя получение страницы. Во время выполнения шага 6 должна быть обеспечена возможность одновременного чтения с нескольких дисков.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
