Home

Page 3
Page 3
background image

получение  такого  ответа  и  есть  косвенная  квитанция,  подтверждающая,  что  исходный  пакет  с 
запросом  успешно  получен  сервером!  Если  же  клиент  в  течение  некоторого  времени  не  получит 
ответа, это будет для него сигналом к тому, что, вероятно, пакет с запросом не достиг сервера и его 
нужно  повторить.  Т.е.  ПРИКЛАДНОЙ  ответ  в  данном  случае  является,  по  сути  косвенной 
квитанций и в генерации дополнительной квитанции силами протокола транспортного уровня НЕТ 
необходимости.  Может показаться, что сервер, отсылая ответ НЕ получает гарантии, что его пакет-
ответ доставлен, что также не хорошо, но и это не совсем так. Ведь если клиент, отправляя запрос, 
НЕ получит на него ответ, он САМ повторит свой запрос, как уж говорилось ранее, действительно, 
клиент не знает, какой именно пакет потерялся в сети: то ли его запрос, то ли ответ сервера – и в 
том и в другом случае клиент повторит свой запрос (а возможно и несколько раз) если не получит 
ответа.  Реализация  такого  механизма  неявного  контроля  доставки  в  данном  взаимодействии  НЕ 
накладывает на сервер ВООБЩЕ никаких новых обязанностей, а на клиента ложится очень простая 
задача – если ответ не пришел, послать пакет-запрос еще раз, что, очевидно, не слишком усложняет 
работу  клиента.  Если  бы  в  таком  взаимодействии  клиент  и  сервер  воспользовались  услугами 
полноценного  транспортного  протокола,  который  бы  гарантировал  доставку  данных,  это  бы 
означало, что перед тем, как клиент сможет послать запрос, необходимо установить соединение с 
сервером  (как  потом  будет  выяснено,  для  этого  необходимо  три  пакета  при  использовании 
протокола  стека TCP/IP), передать  запрос – получить  квитанцию,  получить  ответ – передать 
квитанцию,  разорвать  соединение  (как  потом  будет  выяснено,  для  этого  необходимо  еще  четыре 
пакета), таким образом, обмен между клиентом и сервером потребует 11 пакетов вместо двух! Это 
приведет  к  дополнительной  нагрузке  на  пропускную  способность  сети  и  к  дополнительным 
задержкам обмена между клиентом и сервером, что, очевидно, крайне не желательно. Итак, делаем 
важный  вывод – существуют  приложения  (прикладные  протоколы),  для  которых  гарантирование 
доставки  с  помощью  протокола  транспортного  уровня  НЕ  желательно.  Так  же  невозможно 
обеспечить  гарантии  доставки  во  взаимодействиях,  в  которых  используется  групповое 
вещание/широковещание в IP – один пакет в таком случае посылается многим (заранее неизвестно 
какому  именно  числу)  получателей,  очевидно,  говорить  о  каком  бы  то  ни  было  квитировании  в 
данном  случае  вообще  нельзя.  Так  же  к  числу  приложений,  которые  не  нуждаются  в 
гарантировании  доставки  данных  относятся,  например,  приложения  для  голосового  или  видео 
общения – в  этом  случае  потеря  некоторых  пакетов  несколько  ухудшит  качество  голоса/видео,  а 
попытки повторной отправки пакетов вообще ни к чему, так как теряется синхронность общения: 
лучше  «щелчок»  в  голосе  собеседника,  чем  пауза  на  несколько  секунд  для  исправления  этого 
щелчка, которая приведет к дискредитации самой цели работы прикладного протокола. Подведем 
итог:  типовые  приложения,  не  нуждающиеся  в  гарантировании  доставки  данных  и 
предпочитающие дейтаграммный режим работы: 

•  Приложения, предполагающие режим работы вида: небольшой запрос – небольшой ответ 
•  Приложения, использующие широковещание или групповое вещание 

•  Синхронные приложения, для которых работа в реальном времени важнее, нежели передача 

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

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

Подведем  итог:  существуют  приложения  (прикладные  протоколы),  которые  нуждаются  в 

гарантиях доставки данных, выполняемых специальным транспортным протоколом, и приложения, 
которые в таких гарантиях не нуждаются.  


Copyright © 2021 Файлообменник files.d-lan.dp.ua

Использование любых материалов сайта возможно только с разрешения автора.