Home

Page 4
Page 4
background image

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

Так как протоколы верхнего уровня могут требовать или не требовать гарантий доставки от 

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

•  Без гарантии доставки данных и без установки соединения (дейтаграммным способом) 

•  С гарантиями доставки кадров и предварительной установкой соединения 
•  Без установки соединения, но с гарантированием доставки пакетов  

В стеке TCP/IP реализован иной подход – вместо одного протокола со сложным заголовком 

переменного формата (как LLC) используется ДВА протокола: UDP (User Datagram Protocol) и TCP 
(Transmission Control Protocol). Протокол UDP НЕ  устанавливает  соединений  перед  передачей 
данных  и  не  гарантирует  доставки  данных,  протокол TCP, напротив,  устанавливает  соединение  с 
удаленным  приложением  перед  передачей  данных,  после  чего  передает  данные,  отправляя 
квитанции в ответ на эти данные. Разумеется, нам необходимо изучить оба эти протокола, так же 
ясно,  что  протокол UDP гораздо  проще,  нежели TCP. Отметим  так  же,  что  протокола host-to-host 
уровня,  который  бы  НЕ  устанавливал  соединений,  но  гарантировал  доставку  данных  (аналога 
LLC3)  в  стеке TCP/IP не  предусмотрено,  так  как  такой  подход  к  обслуживанию  данных  мало 
востребован.  Итак,  сначала  будет  изучен  протокол UDP, затем  протокол TCP, а  после  этого  мы 
приступим к рассмотрению прикладных протоколов.  

Вспомним,  что  блоки  данных  различных  уровней  часто  принято  называть  различными 

терминами, например: на канальном уровне мы говорили о кадрах, на сетевом уровне мы говорили 
о  пакетах.  Отметим,  что  термин  «пакет»  относительно  универсален  и  может  использоваться  для 
именования блока данных любого уровня модели OSI, но, тем не менее, существует более точная 
терминология.  В  свете  этого  отметим,  что  блоки  данных  протокола UDP принято  называть 
дейтаграммами  (хотя  и  блоки  данных  протокола IP так  же  нередко  называют  дейтаграммами)  но 
вместо этого длинного слова вполне можно говорить «пакет». В вот блоки данных протокола TCP 
принято называть «сегмент». Мы пока не будем особо вдаваться в причины использования данного 
термина, они станут ясны нам позднее, при детальном изучении протокола TCP, мы же пока просто 
будем пользоваться этим термином. 
 

Итак,  переходим  к  непосредственному  рассмотрению  протокола UDP. Сразу  возникает 

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

Перед  тем,  как  рассмотреть  основную  причину  необходимости  протокола UDP, обсудим 

следующий  вопрос:  кто/что  обменивается  данными  в  сети?  Отметим,  данными  обмениваются  не 
УЗЛЫ, а ПРИЛОЖЕНИЯ, запущенные на этих узлах. Пока же мы ничего не говорили о том, что 
является адресом приложения в сети – мы пока знаем лишь, каким образом производится адресация 
УЗЛОВ (IP адреса). Ясно, что на самом деле необходимо уникально адресовать ПРИЛОЖЕНИЯ в 
сети, а не узлы, но, так как адреса узлов нами уже введены (для маршрутизации) теперь достаточно 
ввести уникальную адресацию ПРИЛОЖЕНИЙ на узлах, в таком случае совокупность уникального 
адреса  узла  в  составной  сети  и  уникального  адреса  приложения  на  данном  узле  вместе  составят 
уникальный  адрес  ПРИЛОЖЕНИЯ  в  составной  сети.  Именно  адресация  приложений  на  узле  и 
представляет  собой  проблему,  решаемую  протоколом UDP (разумеется,  для  приложений,  не 
нуждающихся в установке соединений и гарантиях доставки). Действительно, адресация того, кто 
вложил  свои  данные  в IP пакет  должна  выполняться  с  помощью  соответствующего  поля IP 
заголовка – Protocol. А  основная  причина  необходимости  использования  протокола UDP – 


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

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