Глава 2. Прикладной уровень сетей

Принципы сетевых приложений

Ключевую часть разработки сетевых приложений составляет написание программ, которые работают на различных конечных системах и общаются друг с другом по сети. Например, веб-приложение — это две различные программы, взаимодействующие друг с другом: браузер, запущенный на хосте пользователя (настольном компьютере, ноутбуке, планшете, смартфоне и так далее), и веб-сервер, работающий на серверном хосте.

Другой пример — это одноранговые системы совместного доступа к файлам, где на каждом из хостов, который участвует в файловом обмене, запущена такая программа. В этом случае программы на различных хостах могут быть аналогичными или даже идентичными.

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

Архитектура сетевых приложений

С точки зрения разработчика приложения, архитектура сети постоянна и предлагает определенный набор служб приложениям. С другой стороны, архитектура приложения создается разработчиком этого приложения и определяет, каким образом оно будет строиться на различных конечных системах. Выбирая архитектуру приложения, разработчик, скорее всего, выберет одну из двух доминирующих архитектурных парадигм, используемых в современной разработке сетевых приложений: клиент-серверная или одноранговая (P2P).

Доминирующие архитектурные парадигмы для сетевых приложений:

• Клиент-серверная: существует 1 хост (сервер), который постоянно находится онлайн и обслуживает запросы от других хостов (клиентов). Когда веб-сервер получает запрос объекта от хоста-клиента, он в ответ отправляет запрашиваемый объект этому хосту. Заметим, что в данном виде архитектуры клиенты непосредственно не связываются друг с другом; например, в веб-приложении два браузера напрямую не обмениваются информацией. Еще одной характеристикой клиент-серверной архитектуры является то, что сервер имеет фиксированный, известный всем адрес, называемый IP-адресом (обсудим вскоре). Поскольку сервер имеет постоянный, известный адрес и всегда включен, клиент может всегда взаимодействовать с ним, отправляя пакеты на IP-адрес этого сервера.
  Некоторые из хорошо известных приложений клиент-серверной архитектуры — это Всемирная паутина, FTP, Telnet и электронная почта.
• Одноранговая (P2P) - архитектура, в которой применение серверов или центров обработки сведено до минимума или вообще до нуля. Вместо них приложения используют непосредственное взаимодействие между парой соединенных хостов, называемых пирами (также партнерами или узлами). Пирами являются обычные ПК. Т.к. они взаимодействуют без выделенного сервера, такая архитектура называется одноранговой (peer-to-peer). Примеры - файлообменные приложения, ускорители загрузок, IP-телевидение.

Преимуществом одноранговой архитектуры является ее самомасштабируемость, т.к. вычислительные/накопительные мощности системы растут по мере роста аудитории.

Проблемы одноранговой архитектуры:

1. Адаптация к сетям доступа. Большинство сетей доступа (DSL и кабельные сети) построены по ассиметричному принципу, т.е. скорость входящего трафика значительно превышает скорость исходящего. Поскольку P2P-приложения для обработки видео от ссерверов к сетям доступа смещают исодящий трафик от серверов к сетям доступа, то нагрухка на них значительно возрастает.
2. Безопасность.
3. Стимулирование юзеров к вкладу в P2P-сеть./li>

Взаимодействие процессов

Процесс - программа, запущенная на конечной системе. Когда процессы работают на одном хосте, то они взаимодействуют друг с другом с помощью средств межпроцессного взаимодествия. Как же взаимодестйвуют процессы на разных хостах?

Процессы на двух хостаз взаимодествуют друг с другом обмениваясь сообщениями через сеть. Например, в веб-приложении процесс браузера клиента обменивается сообщениями с процессом веб-сервера. В случае P2P файлообменной сети процесс одного хоста преедает файл в процесс другого хоста.

В контексте сеанса взаимодествия между парой процессов тот, который инициирует взаимодествие (т.е. первым контактирует с другим процессом в начале сеанса), обозначается как клиентский.

Процесс, который ожидает контакта для начала сеанса, называется серверными.

Интерфейс между процессом и компьютерной сетью

Процессы отправляют и принимают сообщения через программный интерфейс, называемый сокетом. Рассмотрим аналогию для лучшего понимания процессов и сокетов. Процесс аналогичен дому, а его сокет подобен двери в этом доме. Когда процесс пытается отправить сообщение другому процессу на удаленном хосте, он «проталкивает» сообщение через свою дверь (сокет). Такая отправка предполагает, что с другой стороны этой двери существует некоторая транспортная инфраструктура, которая организует доставку сообщения до двери процесса назначения. Когда сообщение прибывает на хост назначения, оно проходит через дверь принимающего процесса (через сокет). Принимающий процесс затем обрабатывает это сообщение.

Сокет - это API между сетевыми приложениями и сетью (протоколом транпортного уровня).

Разработчик управляет всем, что находится на прикладном уровне сокета, но со стороны транспортного уровня он управляет лишь:

• выбор транспортного протокола
• возможность фиксации параметров транспортного уровня (например, максимальный буфер и максимальный размер сегмента)

Адресация процессов

Когда запущенный на одном хосте процесс пытается отправить пакеты процессу, работающему на другом хосте, то необходимо знать адрес второго процесса. Для идентификации процесса-получателя необходима информация о двух вещах:

1. Адрес хоста назначения. Это IP-адрес
2. Идентфикатор процесса на хосте назначения. ID открыторого принимающего веб-сокета запушенного на хосте-получаетле. Номер порта решает эту проблему

Транспортные службы, доступные приложениям

Критерии выбора транспортного протокола

• Надежная передача данных. Потеря данных может иметь место во многих приложения, например, электроннаяя почта, передача файлов, удаленный доступ и т.д. Если протокол обеспечивает гарантированную службу доставки, то говорят, что обеспечивается надежная передача данных. Приложения, для которых потеря некоторого объема данных некритична, называются устойчивыми к потерям данных.
• Пропускная способность - скорость, с которой передающий процесс может доставлять биты принимающему процессу. Приложения, которые требует некоторой минимальной пропускной способности называются чувствительными к скорости передачи. В тоже время эластичные приложения используют доступнуб пропускную способность. К таким приложениям относятся электронная почта, передача файлов, веб-приложения.
• Время доставки. Транспортным протоколом может также гарантироваться миниматальное относительное время доставки. Например, протокол может гарантировать, что каждый бит, отправленный передающей сторонной в сокет, приходит на сокет получаетеля не более через 100мс. Примерами приложения, для которых обоснована такая гарантия - это IP-телефония, виртуальное окружения, телеконференции, а также многопользователтские игры.
• Безопасность. Например, транспортный протоколо на передающем хосте способен шифровать все данные, отправленные процессом источником, а затем на принимающем хосте расшифровывать их пред доставкой процессу получателю.

Транспортные средства, предоставляемые интернетом

TCP/IP-сети предоставляют приложениям 2 транспортных протокола - UDP и TCP.

Службы протокола TCP

TCP (Transmission Control Protocol) - это один из основных протоколов передачи данных интернета. Модель обслуживания протокола TCP включает службу установления логического соединения и службу надежной передачи данных

Ниже приведены требования к службам, предъявляемые определенными сетевыми приложениями:

Передача с установлением соединения. Происходит рукопожатие между клиентом и сервером. Протокол TCP обеспечивает обмен управляющей информацией между клиентом и сервером на транспортном уровне. Это дает клиенту и серверу возможность подготовиться к началу обмена. В итоге между сокетами клиентского и серверного процессов устанавливается TCP-соединение. Это соединение является дуплексным, т.е. оба процесса могут передавать данные друг другу в одно и то же время. Когда приложение завершит передачу, то соединение будет разорвано.

Надежная передача данных. Процессы взаимодействующие по протоколу TCP могут быть уверены, что данные будут доставлены без ошибок и в строго определенном порядке.

(Не)безопасноть протокола TCP. TCP и UDP не предоставляют службы шифрования передаваемых данных. Отправленные передающим процессом данные в сокет принимающего процесса идентичны как на этапе отправления, так и на этапе доставки. Так, например, текстовый пароль будет переходить все линии связи на пути от отправителя к получателю и потому может стать уязвимым для перехвата.

Соображения по поводу небезопасности TCP навели сообщество на разработку криптографического протокола SSL (Secure Sockets Layer), или уровеня защищенных сокетов, как доработку протокола TCP. TCP+SSL обеспечивает шифрование, контроль целостности данных и конечную аутентификацию.

1. Передающий процесс передает незашифрованные данные в свой SSL-сокет
2. SSL-cокет на передающем хосте шифрует дынные и передает их в TCP-сокет
3. TCP-сокет отправляет зашифрованные данные по сети в TCP-сокет принимающей стороны
4. TCP-сокет принимающей стороны отправляет зашифрованные данные в SSL-сокет
5. SSL-сокет принимающей стороны расшифровывает данные и посылает данные в принимающий процесс.

Службы протокола UDP

UDP представляет собой простой протокол транспортного уровня, предлагающий минимальный набор служб. UDP является протоколом без установления соединения, то есть процедуры рукопожатия перед тем, как два процесса начинают взаимодействовать, не происходит. UDP обеспечивает ненадежную передачу данных — другими словами, когда процесс отправляет сообщение в сокет UDP, нет никакой гарантии, что сообщение будет получено принимающим процессом. Более того, сообщения могут поступать в принимающий процесс в произвольном порядке.

Службы, не предоставляемые транспортными протоклами Интернета

В таблице ниже показаны популярные транспортные протоколы.

Как несложно заметить, абсолютное большинство приложений используют TCP в качестве своего базового транспортного протокла. Это свяазно с тем, что он обеспечивает надежную передачу данных, гарантируя что вс еданные в итоге доберуться до получаетлся в целостности и сохранности.

Исключением является IP-телефония, которая допускает некоторые потери данных, но требуют для своей работы некоторого минимальной скорости передачи, поэтому разработчики обычно предпочитают UDP, избегая тем самым механизма управления перегрузкой и дополнительных затрат на гарантированную доставку пакетов, присущих протоколу TCP. Возможность TCP всключается как резерв на всякий случай, т.к. многие брандмауэры настроены на блокировку UDP-трафика

Протоколы прикладного уровня

ПротоколЫ прикладного уровня, которые определяют как прикладные процессы, запущенные на различных конечных системах, передают друг другу сообщения. В частности, протокол прикладного уровня определяет:

1. Типы сообщений, которыми обмениваются процессы, например сообщения запроса или сообщения ответа
2. Синтаксис различных типов сообщений, то есть состав полей сообщения и их порядок
3. Семантика полей, то есть значение информации, содержащейся в каждом из них
4. Набор правил для определения времени и порядка передачи сообщений и получения ответов

Общедоступные протоколы описаны в документах RFC. Таким образом, если разработчик браузера следует правилам RFC по поводу протокла HTTP, то он будет способен в этом браузере загрузить любую веб-страницу, сервер которой соответсвует правилам RFC по поводу протокла HTTP.

Заметим разницу между понятиями сетевого приложения и протокола прикладного уровня.

• Всемирная путина - сетевое приложене, котороое позволяет юзерам получать документы с веб-сервера по запроса. Веб-приложение включает стандартны для форматов документов (HTML), веб-браузеров, веб-серверов (например, Apache) и протокола прикладного уровня
• Протокол для всемирной паутины прикладного уровня - HTTP - определяет формат и последовательность сообщений, которыми обмениваются браузер и сервер.