Здесь также возможны конфликты, поскольку многие программы страстно желают поддерживать, например, .mpg. Профессиональные программы при установке обычно выводят флажки, позволяющие выбрать поддерживаемые типы MIME и расширения. Таким образом, пользователь может выбрать то, что ему требуется, и таким образом избежать случайного затирания существующих ассоциаций. Программы, нацеленные на массового потребителя, полагают, что большинство пользователей понятия не имеют о типах MIME и просто захватывают все, что могут, совершенно не обращая внимания на ранее установленные программы.
Расширение возможностей браузера по поддержке новых типов файлов — это удобно, но может также привести к возникновению некоторых проблем. Когда браузер на компьютере с Windows получает файл с расширением exe, он думает, что это исполняемая программа и никаких вспомогательных средств для нее не требуется. Очевидно, следует просто запустить программу. Однако такой подход может оказаться серьезной дырой в системе защиты информации. Злоумышленнику требуется лишь создать нехитрый сайт с фотографиями, скажем, знаменитых киноактеров или спортсменов, и поставить ссылки на вирусы. Один-единственный щелчок мышкой на фотографии может в этом случае привести к запуску непредсказуемой и, возможно, опасной программы, которая будет действовать на машине пользователя. Для предотвращения подобных нежелательных ситуаций Firefox и другие программы настроены на избирательный запуск неизвестных программ, однако не все пользователи понимают, что безопасный выбор важнее удобного.
Сторона сервера
О стороне клиента сказано уже достаточно много. Поговорим теперь о стороне сервера. Как мы уже знаем, когда пользователь вводит URL или щелкает на гиперссылке, браузер производит структурный анализ URL и интерпретирует часть, заключенную между http:// и следующей косой чертой, как имя DNS, которое следует искать. Вооружившись IP-адресом сервера, браузер устанавливает TCP-соединение с 80 портом этого сервера. После этого отсылается команда, содержащая оставшуюся часть URL, в которой указывается путь к странице на сервере. Сервер возвращает браузеру запрашиваемый файл для отображения.
В первом приближении простой веб-сервер напоминает сервер, представленный в листинге 6.1. Этому серверу, как и настоящему веб-серверу, передается имя файла, который следует найти и отправить по сети. В обоих случаях в основном цикле сервер выполняет следующие действия:
1. Принимает входящее TCP-соединение от клиента (браузера).
2. Получает путь к странице, являющийся именем запрашиваемого файла.
3. Получает файл (с диска).
4. Высылает содержимое файла клиенту.
5. Разрывает TCP-соединение.
Современные веб-серверы обладают более широкими возможностями, однако существенными в их работе являются именно перечисленные шаги, предпринимаемые в случае запроса контента, содержащегося в файле. В том случае, если контент является динамическим, третий шаг может быть заменен запуском программы (определенной по пути), возвращающей контент.
Однако веб-серверы реализуются иным способом, для того чтобы они отвечали на множество запросов за одну секунду. Одна из проблем, связанных с простым способом реализации, заключается в том, что доступ к файлам часто затруднен. Считывание с диска идет слишком медленно по сравнению с работой программы, и одни и те же файлы могут считываться с диска несколько раз из-за вызовов операционной системы. Другая проблема заключается в том, что одновременно не могут обрабатываться несколько запросов. Файл может быть большим, и пока он передается, другие запросы блокируются.
Очевидным способом решения проблемы является кэширование в памяти n последних запрошенных файлов или определенного количества гигабайт контента. Прежде чем обратиться за файлом к диску, сервер проверяет содержимое кэша. Если файл обнаруживается в кэше, его можно сразу выдать клиенту, не обращаясь к диску. Несмотря на то что для эффективного кэширования требуются большие объемы памяти и некоторое дополнительное время на проверку кэша и управление его содержимым, суммарный выигрыш во времени почти всегда оправдывает эти накладные расходы и стоимость.
Одним из способов решения проблемы последовательной обработки запросов является создание многопоточных( multithreaded) серверов. Одна из реализаций подразумевает, что сервер состоит из входного модуля, принимающего все входящие запросы, и k обрабатывающих модулей, как показано на рис. 7.9. Все k + 1 потоков принадлежат одному и тому же процессу, поэтому у обрабатывающих модулей есть доступ к кэшу в адресном пространстве процесса. Когда приходит запрос, входящий модуль принимает его и создает краткую запись с его описанием. Затем запись передается одному из обрабатывающих модулей.
Читать дальше
Конец ознакомительного отрывка
Купить книгу