Компьютерные сети

Многоуровневая архитектура Интернета

‘Прикладной уровень’

Как показано на рис. 2.2, сетевое приложение, как правило, состоит из двух «сторон»: клиентской и серверной. Клиентская и серверная стороны находятся на разных оконечных системах и взаимодействуют путем обмена сообщениями. Так, web-браузер является клиентской стороной HTTP, в то время как программное обеспечение web-сервера представляет собой серверную сторону протокола. Роль клиентской и серверной сторон для SMTP играют соответственно передающий и принимающий почтовые серверы соответственно.
Читать далее »

Популярность: 0

Находится в разделе Протоколы прикладного уровня

Необходимо различать понятия сетевых приложений и протоколов прикладного уровня. Протоколы прикладного уровня являются частью (хотя и весьма большой) сетевых приложений. Рассмотрим два примера. Web является сетевым приложением, позволяющим пользователям получать web-документы по запросу и состоящим из множества компонентов, включая стандарт формата документов (HTML), браузеры (Netscape Navigator, Microsoft Internet Explorer и др.), web-серверы (например, Apache, Microsoft или Netscape), протоколы прикладного уровня. Протокол прикладного уровня для web носит название протокола передачи гипертекста (HyperText Transfer Protocol, HTTP) и описывает формат и порядок обмена сообщениями между клиентом и сервером (RFC 2646). Таким образом, HTTP является лишь частью web-приложения.
Читать далее »

Популярность: 0

Находится в разделе Протоколы прикладного уровня

Поток запросов

Опубликовано 11 мая, 2008

В бесплатном приложении для совместного использования файлов Gnutella задействована полностью распределенная модель распределения ресурсов. В этой модели одноранговые системы самоорганизуются в оверлейную сеть. В отличие от оверлейной сети, описанной выше, сеть приложения Gnutella имеет «плоскую», неструктурированную топологию. Все пользователи равны между собой, поскольку иерархическая структура в сети отсутствует. Рисунок 2.32 иллюстрирует графическое представление описываемой топологии. Как и в предыдущей модели, присоединение новой системы происходит с помощью узла начальной загрузки, выдающего IP-адреса одного или нескольких существующих пользователей сети. Каждая система располагает сведениями только о своих соседях, то есть системах, с которыми у нее имеется логическая связь. Для поддержки подобной оверлейной сети требуется сложный протокол, учитывающий постоянные динамические изменения структуры сети, связанные с подключениями и отключениями пользователей.
Читать далее »

Популярность: 0

Децентрализованный каталог

Опубликовано 10 мая, 2008

Для того чтобы избежать проблем, порождаемых централизацией, естественно попытаться распределить ресурсы центрального каталога между одноранговыми системами. Подобный подход был использован в системе KaZaA/FastTrack [141], завоевавшей широкую популярность в 2001-2002 годах.
Читать далее »

Популярность: 0

Централизованный каталог

Опубликовано 9 мая, 2008

Одним из наиболее прямолинейных решений проблемы поиска ресурсов является создание централизованного каталога. Подобным образом поступила компания Napster — первая коммерческая компания, реализовавшая широкомасштабную Р2Р-систему обмена МРЗ-файлами. При таком способе решения специально для осуществления поиска создается сервер или объединение серверов. Как показано на рис. 2.30, при запуске однорангового приложения оно связывается с централизованным каталогом и сообщает свой IP-адрес, а также список файлов, выделяемых в совместное использование. Таким образом, централизованный каталог представляет собой динамическую базу данных, с помощью которой все системы могут получать наиболее важную информацию друг о друге: IP-адреса и списки доступных файлов. Если активный пользователь добавляет или удаляет какой-либо объект, соответствующее изменение сразу же вносится в базу данных.
Читать далее »

Популярность: 0

Пользователь может получать объекты с web-серверов-источников, принадлежащих поставщикам ресурсов, с прокси-серверов, арендуемых Интернет-провайдерами, а также с CDN-серверов, управляемых CDN-компаниями. Тем не менее технологии распределения ресурсов этим не исчерпываются. Оказывается, обычные оконечные системы могут обмениваться объектами непосредственно друг с другом! Такому обмену, называемому одноранговым (Peer-to-Peer, Р2Р) разделением файлов, посвящено немало информационных ресурсов. Мы рассмотрим вопросы, связанные с соединением и передачей информации в контексте однорангового разделения файлов. Разумеется, технология Р2Р имеет множество других важных аспектов применения, относящихся к безопасности, конфиденциальности, анонимности и защите авторских прав.
Читать далее »

Популярность: 0

Сети распределения ресурсов

Опубликовано 7 мая, 2008

Интернет-провайдеры арендуют и устанавливают кэш-серверы, чтобы повысить качество обслуживания своих пользователей. Как было показано в подразделе «Web-кэширование» данного раздела, применение кэш-серверов способно значительно сократить время доставки наиболее востребованных ресурсов пользователям.
В конце 1990-х годов широкое распространение получила еще одна технология распределения ресурсов — технология CDN (Content Distribution Network — сети распределения ресурсов). В CDN используется иная «бизнес-модель», нежели в web-кэшировании. Если при web-кэшировании потребителями услуг являются Интернет-провайдеры, то в сетях распределения ресурсов на их месте находятся поставщики ресурсов. Тем не менее сети распределения ресурсов преследуют ту же цель — сократить время доставки ресурсов. Обычно CDN-компания функционирует по следующему плану.
1. Компания устанавливает множество (порядка сотен) CDN-серверов, распределенных в Интернете. Как правило, CDN-серверы располагаются в центрах Интернет-хостинга, принадлежащих сторонним компаниям (наподобие Exodus и Worldcom) и представляющих собой здания с большим числом хостов внутри. Обычно центры Интернет-хостинга подключены к Интернет-провайдерам нижнего звена и расположены вблизи их сетей доступа.
2. Компания копирует ресурсы своих потребителей на CDN-серверы. Когда потребитель обновляет свои ресурсы, CDN-компания заменяет старое содержимое серверов новым.
3. Компания обеспечивает такое обслуживание, при котором CDN-сервер осуществляет обработку запроса за минимальное время. Для этого выбирается либо такой CDN-сервер, который территориально наиболее близок к пользователю, либо такой, на пути к которому нет перегруженных узлов.
Любопытно отметить, что в создание CDN вовлекаются сразу несколько независимых компаний. Поставщик ресурсов (например, Yahoo!) использует услуги CDN-компании (например, Akamai). В свою очередь, CDN-компания покупает CDN-серверы у их производителей (Inktomi, IBM и др.) и устанавливает эти серверы в центрах Интернет-хостинга, принадлежащих компаниям, предоставляющим услуги Интернет-хостинга (например, Exodus). Таким образом, в создании CDN участвуют как минимум четыре компании, не считая Интернет-провайдеров!
На рис. 2.28 представлена схема взаимодействия между поставщиком ресурсов и CDN-компанией. Сначала поставщик ресурсов определяет объекты, которые он хотел бы сделать распределенными с помощью CDN (остальные объекты могут распространяться без участия CDN). Нужные объекты отсылаются узлу распределения CDN, который, в свою очередь, доставляет их на все CDN-серверы. Специально для этой цели CDN-компании иногда приобретают частные компьютерные сети. В случае, если поставщик ресурсов желает произвести обновление своих объектов, он отсылает их последние версии узлу распределения, откуда они попадают на все CDN-серверы, заменяя устаревшие объекты. Обратите внимание на то, что каждый CDN-сервер содержит объекты, принадлежащие множеству поставщиков ресурсов.
При знакомстве с технологией CDN возникает интересный вопрос. Когда браузер на хосте пользователя формирует запрос на получение объекта (идентифицируемого своим URL-адресом), каким образом браузер определяет, кому отправить этот запрос — серверу-источнику или одному из CDN-серверов? Для решения этого вопроса в CDN используется механизм DNS-перенаправления, указывающий браузерам адрес нужного сервера. Заинтересовавшемуся читателю рекомендуем обратиться к дополнительным источникам информации [256].
Рассмотрим следующий пример. Пусть поставщик ресурсов имеет имя хоста www.foo.com, а CDN-компания — cdn.com. Предположим, что поставщик ресурсов желает распределить свои GIF-файлы при помощи CDN, при этом все остальные файлы, включая базовые HTML-страницы, будут распространяться им (поставщиком) самостоятельно. Для этого поставщик изменяет все свои объекты таким образом, что ссылки на GIF-файлы предваряются фрагментом http://www.cdn.com. Например, ссылка http://www.foo.com/sports/ruth.gif после изменения приобретает вид http://www.cdn.com/www.foo.com/sports/ruth.gif. Когда браузер формирует запрос объекта ruth.gif, происходит следующее.
1. Браузер передает запрос на получение базового HTML-объекта серверу-источнику www.foo.com, который выполняет запрос и отсылает браузеру требуемый файл. Браузер производит обработку HTML-страницы и находит в ней ссылку на объект http://www.cdn.com/www.foo.com/sports/ruth.gif.
2. Браузер осуществляет DNS-поиск хоста www.cdn.com, при этом запрос передается от корневого сервера имен полномочному серверу имен хоста www.cdn.com. Последний извлекает IP-адрес хоста, сделавшего запрос, и на основе специальной внутренней карты Интернета возвращает IP-адрес CDN-сервера, который более других подходит для обслуживания запроса.
3. Ответ с IP-адресом CDN-сервера возвращается браузеру, который перенаправляет свой запрос с использованием полученного IP-адреса. Далее запрос обрабатывается и обслуживается CDN-сервером. Любой последующий запрос, адресованный хосту www.cdn.com, будет автоматически обслуживаться этим же CDN-сервером, поскольку IP-адрес www.cdn.com окажется в DNS-кэше либо на стороне клиента, либо на стороне локального сервера имен.
Читать далее »

Популярность: 0

Находится в разделе Распределение ресурсов

Совместное кэширование

Опубликовано 6 мая, 2008

Несколько территориально распределенных кэш-серверов могут объединяться и функционировать совместно. Например, локальный кэш-сервер организации можно настроить таким образом, чтобы он в случае необходимости перенаправлял запросы кэш-серверу магистрального Интернет-провайдера. Это обеспечит двухступенчатый кэш-поиск, причем обращение к серверу-источнику будет производиться только в том случае, если требуемоый объект не обнаружится ни на одном из кэш-серверов.
Читать далее »

Популярность: 0

Находится в разделе Распределение ресурсов

Web-кэширование

Опубликовано 5 мая, 2008

Web-кэш, часто называемый прокси-сервером, представляет собой сеть, которая выполняет HTTP-запросы от имени сервера-источника. Web-кэш имеет собственное дисковое устройство хранения информации, содержащее ранее запрашивавшиеся копии объектов. Как показано на рис. 2.25, браузер пользователя можно настроить таким образом, чтобы все создаваемые HTTP-запросы сначала направлялись в web-кэш (данная процедура в браузерах Microsoft и Netscape выполняется очень просто).
Читать далее »

Популярность: 0

Находится в разделе Распределение ресурсов

Распределение ресурсов

Опубликовано 4 мая, 2008

Web-ресурсы очень богаты и продолжают непрерывно пополняться. Это web-страницы (содержащие текст, изображения, Java-апплеты, фреймы и т. д.), музыкальные файлы в формате МРЗ, записанное потоковое аудио и видео, виртуальные миры. Ресурсы распределены между огромным количеством серверов, разбросанных по всему миру, и доступны миллионам пользователей.
Читать далее »

Популярность: 0

Находится в разделе Распределение ресурсов