Home

Page 10
Page 10
background image

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

Итак,  подводим  итоги  по  портам TCP и UDP. Важно  отметить,  что TCP и UDP порты  НЕ 

совпадают,  т.е.  одно  приложение  может  занимать TCP порт 3445, при  этом  другое  приложение 
может  занимать UDP порт 3445. Таким  образом,  при  использовании  стека TCP/IP возможно 
одновременное  использование  на  одном  узле  до 131072 приложений – 65535 приложений, 
нуждающихся в гарантиях доставки (адресуемых с помощью протокола TCP) и 65535 приложений, 
нуждающихся  в  отправке  дейтаграмм  (адресуемых  с  помощью UDP). Еще  раз  подчеркиваем,  что 
все рассмотренные выше концепции работы с портами касаются в равной мере как UDP портов, так 
и TCP портов.  

Как  узнать,  какие UDP порты  прослушиваются  процессами,  запущенными  на  локальном 

узле,  т.е.  как  узнать,  на  какие  порты  локального  узла  можно  отправлять  дейтаграммы 
приложениям?  Для  этого  в  большинстве  операционных  систем,  поддерживающих TCP/IP 
присутствует  утилита netstat.exe, которая  может  отображать  используемые  в  настоящее  время 
порты TCP и UDP. Эта  утилита  присутствует  и  в Windows, далее,  когда  мы  будем  на  практике 
закреплять  рассматриваемые  сейчас  вопросы,  мы  продемонстрируем  студентам  работу  с  этой 
утилитой. 

 
Вернемся  к  рассмотрению  функций  протокола UDP и  заголовка  протокола UDP. Мы 

рассмотрели  первое  четырехбайтовое  слово  заголовка UDP, но,  как  уже  говорилось  выше, 
заголовок UDP имеет фиксированную длину, равную 8 байт. Изобразим заголовок UDP полностью, 
а затем поясним остальные поля. 
 

Source Port

Destination Port

Length

Checksum

 
Третье  поле  заголовка – Length, оно  показывает  длину  всей  дейтаграммы,  включая  заголовок  и 
данные,  передаваемые  после  заголовка,  следовательно,  минимальное  значение  этого  поле – 8. 
Фактически  особо  комментировать  тут  нечего – данное  поле  предназначено  для  облегчения 
приемной  стороне  правильной  обработки  принятой  дейтаграммы.  Однако,  наличие  такого  поля – 
явная  избыточность – вычитая  из  значения  поля Total Length IP заголовка,  умноженное  на 4 
значение  поля IHL можно  получить  значение  длины UDP дейтаграммы,  совпадающее  с 
передаваемым  в  заголовке UDP. Последнее  поле  заголовка UDP – контрольная  сумма.  Перед 
рассмотрением  того,  как  именно  рассчитывается  эта  контрольная  сумма,  полезно  вспомнить 
стратегию защиты данных контрольными суммами в стеке TCP/IP. Вспомним, что все современные 
базовые  сетевые  технологии  защищают  передаваемые  кадры  канального  уровня  контрольными 
суммами,  следовательно,  в  таких  кадрах  можно  передавать  произвольные  данные,  не  прибегая  к 
дополнительным  мерам  по  обеспечению  достоверности  этих  данных.  Вспомним,  что  стек TCP/IP 
проектировался  достаточно  давно,  когда  самыми  популярными  линиями  связи  были  ненадежные 
аналоговые  ненагруженные/нагруженные  линии  связи,  в  качестве  протокола  канального  уровня 
нередко  использовался    SLIP,  который  НЕ  защищает  содержимое  (т.е. IP пакет)  контрольной 
суммой.  Таким  образом,  исторически  сложилось,  что  стек TCP/IP должен  был  самостоятельно 
заботиться  о  снабжении  передаваемых  данных  контрольными  суммами.  Ясно,  что  самое  простое 
решение, приходящее в голову – снабжение заголовка IP контрольной суммой, рассчитываемой по 
ВСЕМУ  пакету – крайне  не  эффективно,  так  как  при  маршрутизации IP пакетов  происходит 
изменение  заголовка IP, что  автоматически  приведет  к  необходимости  каждому  маршрутизатору 
пересчитывать контрольную сумму по ВСЕМУ пакету. Вспомним, как решается эта проблема: если 
IP заголовок все же меняется (от этого никуда не деться), а защищать его контрольной суммой тем 
не  менее  необходимо,  как  и  необходимо  защищать  контрольной  суммой  неизменное  в  процессе 
маршрутизации  содержимое  пакета,  то  можно  снабдить IP заголовок  контрольной  суммой, 
рассчитываемой  только  для  этого  самого  заголовка,  а  непосредственное  содержимое IP пакета 
(UDP, ICMP, TCP) можно  защитить  собственными  контрольными  суммами,  которые  будут 
рассчитываться для заголовка и данных соответствующих протоколов. Как мы помним, заголовок 
IP  содержит  поле  контрольной  суммы,  рассчитываемое  только  для  заголовка IP, т.е. 


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

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