Требования приложений. Сервисы, предоставляемые TCP и UDP
Многие комп сети, включая И, используют более 1 транспортного протокола. При разработке приложения нужно выбрать один из транспортных протоколов, к службам которого будет обращаться. Для того, чтобы сделать выбор, нужно изучить перечень служб, поддерживаемых каждый из протоколов и выбрать тот, который способен обслужить ваше приложение наилучшим образом.
Выделяются 3 основных требования, предъявляемых приложениями к транспортному уровню: надежная передача данных, гарантированная скорость передачи и обеспечение доставки данных за определенное время.
Надежная передача данных: некоторые приложения, например приложения эл почты, требуют надежной передачи данных, то есть исключения вероятности потерь данных при передаче. Но сущ вид приложений, толерантных к потерям данных (аудио и видео реального времени). Для таких приложений потеря данных не приводит к сбоям или серьезным потерям качества. Степень толерантности приложения к потере данных определяет максимальную долю данных. которая может быть потеряна, и зависит от назначения приложения и использующейся схемы кодировки.
Скорость передачи: для эффективной работы некоторым приложениям необходимо совершать передачу данных с опр скоростью (передача голосовых сообщений). Приложения, эффективность которых зависит от скорости передачи данных, называют чувствительными к скорости передачи данных.
Время передачи: Гарантированное время доставки. И-телефония, виртуальные миры, телеконференции, многопользовательские комп игры. В приложениях, не являющихся приложениями реального времени, временные ограничения на доставку данных не являются столь принципиальными.
| Приложения доставки | Потеря Данных | Скорость передачи | Ограничение на время |
| Передача файлов | Недопустима | Эластичность | Нет |
| Эл почта | Недопустима | Эластичность | Нет |
| Работа с web-документами | Недопустима | Эластичность (несколько Кбит/с) | Нет |
| Аудио и видео реального времени | Допустима | Аудио:несколько Кбит/с - 1Мбит/с Видео: 10Кбит/с-5Мбит/с | Есть, сотни миллисекунд |
| Записанное потоковое аудио и видео | Допустима | также | Есть, сотни миллисекунд |
| Интерактивные игры | Допустима | 1-10Кбит/с | Есть, сотни миллисекунд |
| Обмен сообщениями в реальном времени | Недопустима | Эластичность | Есть и нет |
Протокол TCP: опирается на установление логического соединения и надежная передача данных.
Установление логического соединения. Обеспечивает обмен управляющей инф между клиентом и сервером до начала передачи - процедура рукопожатия. После удачного завершения процедуры рукопожатия между сокетами клиента и сервера устанавливается TCP-соединения, является дуплексным (обе стороны могут одновременно передавать). После окончания обмена соединение должно быть автоматически разорвано.
Надежная передача данных. Гарантия, что все переданные данные будет доставлены адресату без ошибок, потерь и в правильном порядке. Входной и выходной потоки соответствуют.
Также включает контроль перегрузки.
Протокол UDP: Без логического соединения, процедура рукопожатия отсутствует. Обеспечивает ненадежную передачу данных - гарантии доставки нет. Не гарантирует порядок получения информации. Не предусматривает контроль перегрузок.
| Приложение | Прикладной протокол | Транспортный протокол |
| Эл почта | SMTP | TCP |
| Доступ с удаленного терминала | Telnet | TCP |
| Web | HTTP | TCP |
| Передача файлов | FTP | TCP |
| Удаленный файловый сервер | NFS | UDP или TCP |
| Потоковое мультимедиа | Обычно фирменный , например Real Networks | UDP или TCP |
| И-телефония | Обычно фирменный , например Dialpad | Как правило, UDP |
Оба протокола не гарантируют время доставки.
Протокол HTTP
В «сердце» web находится протокол гипертекста HTTP, являющийся протоколом прикладного уровня. Реализуется с помощью двух программ: клиента и сервера, которые, находясь на разных оконечных системах обмениваются HTTP-сообщениями. Порядок обмена и содержание сообщений описаны в протоколе. Протокол определяет каким образом клиенты запрашивают web-страницы, а серверы осуществляют передачу этих страниц. Когда пользователь запрашивает web-страницу, браузер посылает серверу HTTP-запрос объектов, составляющих web-страницу. Сервер получает запрос и высылает ответные сообщения, содержащие требуемые объекты. Использует TCP в качестве протокола транспортного уровня. После завершения обслуживания клиентов сервер не сохраняет о них никакой инфы. Протокол HTTP является протоколом без запоминания состояния соединения.
Поддерживает постоянные и непостоянные соединения (1.0 только непостоянные). При непостоянном TCP получает лишь 1 объект, при постоянном - все.
Время оборота (RTT) - время, для однократного обмена сегментами. Включает в себя задержку распространения, ожидания и обработки. Суммарное время ответа: удвоенное время оборота и время передачи базового HTML-файла.
Постоянные соединения: с конвейеризацией, без конвейеризации (посылает новый запрос после завершения приема текущего объекта).
Формат HTTP-сообщения: сущ 2 типа сообщения: запросы и ответы.
Запрос:
| Строка запроса | Метод | Sp | URL | sp | Версия | cr | lf |
| Строки заголовка | Имя заголовочного поля | Sp | Значение | cr | lf | ||
| Имя заголовочного поля | Sp | Значение | cr | lf | |||
| Пустая строка | cr | Lf | |||||
| Тело объекта |
Первая строка - строка запроса, следующие - строки заголовка. Строка запроса содержит 3 поля: поле метода, поле URL и поле версии HTTP. Методы GET, HEAD, POST (слово для поиска(тело)).
Строки заголовка: User-Agent - агент пользователя (тип браузера сгенерировавшего запрос), Accept-Language - строка согласования данных.
Ответ:
| Строка запроса | Метод | sp | URL | sp | Информация состояния | cr | lf |
| Строки заголовка | Имя заголовочного поля | sp | Значение | cr | lf | ||
| Имя заголовочного поля | sp | Значение | cr | lf | |||
| Пустая строка | cr | lf | |||||
| Тело объекта |
Состоит из 3 частей: строка состояния, шести строк заголовка и тела сообщения. Тело содержит требуемый объект. Строка состояния образована из 3 полей: версия протокола, код состояния, информация состояния. Строки заголовка: The Date - дата и время создания ответа, Server - каким сервером создан ответ, Last-modified - дата и время создания или последнего изменения объекта, Content-Length - размер объекта в байтах, Content-type - тип объекта.
Поля кода состояния и информация о состоянии: 200 - ОК, 400 Bad Request (не возможна интерпретация запроса), 404 Not Found (не найден), 505 HTTP Version Not Supported (указанная версия сервером не поддерживается).
Аутентификация в HTTP, cookies, условный GET в HTTP.
HTTP-сервер не запоминает инфу о состоянии соединений. Тем не менее возможность распознавания пользователей сервером весьма желательна, т.к. необходимо разграничение прав доступа к инфе, находящейся на сервере, либо предоставление пользователю собственного набора услуг. Протокол HTTP предусматривает 2 механизма идентификации пользователей: авторизацию и объекты cookie.
Авторизация: авторизация - механизм при котором сервер предлагает ввести имя пользователя и пароль доступа к своему инф пространству. Запрос производится с помощью особых заголовков и кодов состояния. (клиент формирует запрос, получает ответ с кодом 401 - Autorization Required, в спец строке WWW-Authenticate: заголовка содержится описание метода проведения авторизации, как правило ввод имени пользователя и пароля. получив такое сообщение клиент запрашивает у пользователя имя и пароль, генерирует новый запрос, со строкой Authorization: с введенными пользователем данными. Продолжает отсылать имя и пароль для всех запрашиваемых объектов (имя и пароль кэшируются). Такой механизм не позволяет организовать надежную защиту данных сервера от несанкционированного доступа.
Cookie: Объекты cookie являются альтернативным авторизации средством идентификации пользователей. Наличие компонентов: 1) заголовочная cookie-строка в ответном сообщении сервера; 2) заголовочная cookie-строка в запросе клиента; 3) cookie-файл, находящийся на стороне клиента и обрабатываемый браузером; 4) удаленная БД, расположенная на web-сайте.
При первом доступе к серверу, сервер генерирует уникальный ID и отсылает его пользователю Set-cookie:, клиент помещает эту строку в cookie-файл, при каждом повторном доступе запрос содержит строку cookie:. ТО сервер может собирать инфу о деятельности у себя пользователя: время доступа, посещенные страницы и пр. Процесс покупок. Также весьма ненадежны с точки зрения обеспечения конфиденциальности инфы.
GET с условием: Web-кэширование, т.е. сохранение уже загруженных объектов способно ощутимо сократить время загрузки web-страниц и сетевой трафик. Кэширование может осуществляться клиентом и промежуточным кэш-сервером.
Кэширование порождает новую проблему: содержимое кэшированного объекта постоянно устаревает. метод GET с условием - средство, предусмотренное протоколом HTTP позволяющее при необходимости обновлять кэшированные объекты. Содержит строку заголовка: If-Modified-Since: - осуществить пересылку объекта если с момента предыдущей пересылки Last-Modified, был изменен. Если изменения не было, то получим 304 - Not Modified с пустым телом, это означает ,что можно использовать кэшированный объект.
Протокол FTP.
FTP-сеанс представляет собой обмен файлами, находящимися на двух хостах - локальном и удаленном. Для получения доступа к удаленному хосту пользователю необходимо ввести своё имя и пароль. После получения доступа пользователь может осуществлять передачу фалов как с удаленного хоста на локальный, так и наоборот.
Модель использования: User Interfase User
Server
PI 
постоянное Client PI
команда - ответ управляющее соединение (control connection)
ФС Server Client
DTP временное DTP ФС
DTP - data transfer process
PI - protocol Interpreter
Протокол HTTP и FTP имею много общего, например в качестве протокола транспортного уровня оба используют протокол TCP. НО протокол FTP использует 2 параллельных TCP соединения: управляющее соединение (пересылка управляющей инфы между хостами: имя и пароль, команды смены текущего удаленного каталога, передача и запрос файла) и соединение данных (для передачи самих файлов). Т.к. управляющее соединение отдельно от соединения данных, передаче управляющей инфы осуществляется вне полосы.
FTP сеанс начинается с установления управляющего соединения между клиентом с удаленным хостом (сервером) через порт 21 (передача имени и пароль, команды сметы каталога и обмена файлами). Когда сервер получает команду передачи или приема файла, он устанавливает с клиентом TCP-соединение данных, осуществляет файловый обмен, и закрывает соединение. Каждое соединение позволяет передать только 1 файл, при этом управляющее открыто в течении всего сеанса. Во время FTP-сеанса серверу необходимо иметь инфу о пользователе. Как правило управляющее соединение связно со специальной учетной записью пользователя. Кроме того, сервер должен следить за текущим каталогом, в котором работает пользователь. Необходимость затрат приводит к снижению FTP-сеансов, одновременно поддерживаемых сервером. Имя команды представляет собой 4 символа в верхнем регистре, за которыми следуют параметры: USER username:, PASS password:, LIST: (запрос к серверу на передачу имен всех файлов, находящихся в текущем каталоге, передача списков файлов происходит с использованием непостоянного соединения данных), RETR filename: (передача файла с указанным именем, сервер в ответ должен установить соединение данных и начать передачу), STOR filename: (передача файла от пользователя в текущий каталог удаленного хоста). Ответ представляет собой трехзначное число, иногда сопровождаемое небольшим текстовым пояснением.
Протокол SMTP.
Электронная почта появилась едва ли не раньше И. В эпоху зарождения И-технологий, она была самым популярным из сущ приложений.
SMTPserver SMTP SMTP-server
SMTP UA
User POP3
agent IMAP IMAP
POP3 mailbox mailbox у провайдера
web
сервер
Протокол SMTP составляет основу службы электронной почты И. Он использует механизм надежной передачи транспортного уровня TCP для доставки сообщений между почтовыми серверами отправителя и получателя. SMTP требует простой 7-разрядной кодировки символов в теле сообщения. SMTP предусматривает передачу сообщений через промежуточные почтовые серверы. Если сообщение с сервером не удается установить, сообщение остается на стороне клиента, при этом через определенное время предпринимается следующая попытка установления соединения.
1) SMTP-клиент пытается установить TCP-соединение с поротом 25 сервера, если сервер не отвечает, попытка повторяется. 2) после установления соединения - обмен рукопожатиями на транспортном уровне (определение адресов почтовых ящиков отправителя и получателя). 3) передача данных.
Если у клиенты есть ещё сообщения для того же сервера, то все они пересылаются последовательно через тоже соединение.
Формат сообщений: Заголовок - адрес отправителя, получателя (From: To: - обязательные, Subject: - необязательное, тело сообщение, отделенное от заголовка пустой строкой.
бинарный объект - это не текст, в котором встречаются коды < 32, кроме CR LF.
MIME - многоцелевое расширение почты И. Заголовки MIME: Content-Type: (позволяет провести соответствующую обработку), Content-Transfer-Encoding: (тип кодирования передаваемого объекта). В настоящее время выделено 7 основных типов. Пример: text, image, application.
multipart - тело сообщения содержит разную информацию.