
каждом конкретном случае причины этого определяются спецификой протокола, встретив такие
протоколы, мы будет детально рассматривать причины такого необычного использования
клиентских портов.
Итак, подводим итоги по портам 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, т.е.