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

Итак,  подводим  итоги  по  портам 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, т.е.