Как называются данные поступающие от приложений на вход протоколов транспортного уровня udp и tcp
Стек TCP/IP широко используется как в глобальных, так и в локальных сетях. Этот стек имеет иерархическую структуру, в которой определено 4 уровня.
Прикладной уровень стека TCP/IP соответствует трем верхним уровням модели OSI: прикладному, представления и сеансовому. Он объединяет сервисы, предоставляемые системой пользовательским приложениям. За долгие годы применения в сетях различных стран и организаций стек TCP/IP накопил большое количество протоколов и служб прикладного уровня. К ним относятся такие распространенные протоколы, как протокол
Транспортный уровень стека TCP/IP может предоставлять вышележащему уровню два типа сервиса:
• гарантированную доставку обеспечивает протокол управления передачей (Transmission Control Protocol, TCP);
• доставку по возможности, или с максимальными усилиями, обеспечивает протокол пользовательских дейтаграмм (User Datagram Protocol, UDP) . Для того чтобы обеспечить надежную доставку данных, протокол TCP предусматривает установление логического соединения, что позволяет ему нумеровать пакеты, подтверждать их прием квитанциями, в случае потери организовывать повторные передачи, распознавать и уничтожать дубликаты, доставлять прикладному уровню пакеты в том порядке, в котором они были отправлены. Благодаря этому протоколу объекты на хосте-отправителе и хосте-получателе могут поддерживать обмен данными в дуплексном режиме.
В Интернете (а значит, и в стеке протоколов TCP/IP) конечный узел традиционно называют хостом, а маршрутизатор — шлюзом. TCP дает возможность без ошибок доставить сформированный на одном из компьютеров поток байтов на любой другой компьютер, входящий в составную сеть.
Второй протокол этого уровня, UDP, является простейшим дейтаграммным протоколом, который используется тогда, когда задача надежного обмена данными либо вообще не ставится, либо решается средствами более высокого уровня — прикладным уровнем или
В функции протоколов TCP и UDP входит также исполнение роли связующего звена между прилегающими к транспортному уровню прикладным и сетевым уровнями. От прикладного протокола транспортный уровень принимает задание на передачу данных с тем или иным качеством прикладному уровню-получателю.
Нижележащий сетевой уровень протоколы TCP и UDP рассматривают как своего рода инструмент, не очень надежный, но способный перемещать пакет в свободном и рискованном путешествии по составной сети.
Программные модули, реализующие протоколы TCP и UDP, подобно модулям протоколов прикладного уровня, устанавливаются на хостах.
Сетевой уровень, называемый также уровнем Интернета, является стержнем всей архитектуры TCP/IP. Именно этот уровень, функции которого соответствуют сетевому уровню модели OSI, обеспечивает перемещение пакетов в пределах составной сети, образованной объединением нескольких подсетей. Протоколы сетевого уровня поддерживают интерфейс с вышележащим транспортным уровнем, получая от него запросы на передачу данных по составной сети, а также с нижележащим уровнем сетевых интерфейсов, о функциях которого мы расскажем далее.
Основным протоколом сетевого уровня является межсетевой протокол (Internet Protocol, IP). В его задачу входит продвижение пакета между сетями — от одного маршрутизатора к другому до тех пор, пока пакет не попадет в сеть назначения. В отличие от протоколов прикладного и транспортного уровней, протокол IP развертывается не только на хостах, но и на всех маршрутизаторах (шлюзах). Протокол IP — это дейтаграммный протокол, работающий без установления соединений по принципу доставки с максимальными усилиями. Такой тип сетевого сервиса называют также «ненадежным».
Идеологическим отличием архитектуры стека TCP/IP от многоуровневой архитектуры других стеков является интерпретация функций самого нижнего уровня — уровня сетевых интерфейсов.
Напомним, что нижние уровни модели OSI (канальный и физический) реализуют множество функций доступа к среде передачи, формированию кадров, согласованию величин электрических сигналов, кодированию и синхронизации, а также некоторые другие. Все эти весьма конкретные функции составляют суть таких протоколов обмена данными, как Ethernet, РРР и многих других.
У нижнего уровня стека TCP/IP задача существенно проще — он отвечает только за организацию взаимодействия с подсетями разных технологий, входящими в составную сеть. TCP/IP рассматривает любую подсеть, входящую в составную сеть, как средство транспортировки пакетов между двумя соседними маршрутизаторами.
Задачу организации интерфейса между технологией TCP/IP и любой другой технологией промежуточной сети упрощенно можно свести к двум задачам:
• упаковка (инкапсуляция) IP-пакета в единицу передаваемых данных промежуточной сети;
• преобразование сетевых адресов в адреса технологии данной промежуточной сети.
Такой гибкий подход упрощает решение проблемы расширения набора поддерживаемых технологий. При появлении новой популярной технологии она быстро включается в стек TCP/IP путем разработки соответствующего стандарта, определяющего метод инкапсуляции IP-пакетов в ее кадры (например, спецификация RFC 1577, определяющая работу протокола IP через сети ATM, появилась в 1994 году вскоре после принятия основных стандартов ATM). Так как для каждой вновь появляющейся технологии разрабатываются собственные интерфейсные средства, функции этого уровня нельзя определить раз и навсегда, и именно поэтому нижний уровень стека TCP/IP не регламентируется.
Каждый коммуникационный протокол оперирует некоторой единицей передаваемых данных. Названия этих единиц иногда закрепляются стандартом, а чаще просто определяются традицией. В стеке TCP/IP за многие годы его существования образовалась устоявшаяся терминология в этой области.
Потоком данных, информационным потоком, или просто потоком, называют данные, поступающие от приложений на вход протоколов транспортного уровня — TCP и UDP. Протокол TCP «нарезает» из потока данных сегменты. Единицу данных протокола UDP часто называют дейтаграммой, или датаграммой. Дейтаграмма — это общее название для единиц данных, которыми оперируют протоколы без установления соединений. К таким протоколам относится и протокол IP, поэтому его единицу данных иногда тоже называют дейтаграммой, хотя достаточно часто используется и другой термин — пакет.
В стеке TCP/IP единицы данных любых технологий, в которые упаковываются IP-пакеты для их последующей передачи через сети составной сети, принято называть также кадрами, или фреймам. При этом не имеет значения, какое название используется для этой единицы данных в технологии составляющей сети. Для TCP/IP фреймом является и кадр Ethernet, и ячейка ATM, и пакет Х.25 в тех случаях, когда они выступают в качестве контейнера, в котором IP-пакет переносится через составную сеть.
Типы адресов стека TCP/IP
Для идентификации сетевых интерфейсов используются три типа адресов:
• локальные (аппаратные, MAC, физические) адреса;
• сетевые адреса (IP-адреса);
• символьные (доменные) имена.
Локальные адреса
В большинстве технологий LAN (Ethernet, FDDI, Token Ring) для однозначной адресации интерфейсов используются МАС-адреса. Существует немало технологий (Х.25, ATM, frame relay), в которых применяются другие схемы адресации. Роль, которую играют эти адреса в TCP/IP, не зависит от того, какая именно технология используется в подсети, поэтому они имеют общее название — локальные (аппаратные) адреса.
Слово «локальный» в контексте TCP/IP означает «действующий не во всей составной сети, а лишь в пределах подсети». Именно в таком смысле понимаются здесь термины: «локальная технология» (технология, на основе которой построена подсеть) и «локальный адрес» (адрес, который используется некоторой локальной технологией для адресации узлов в пределах подсети). Напомним, что в качестве подсети («локальной сети») может выступать сеть, построенная как на основе локальной технологии, например Ethernet, FDDI, так и на основе глобальной технологии, например Х.25, Frame Relay. Следовательно, говоря о подсети, мы используем слово «локальная» не как характеристику технологии, на которой построена эта подсеть, а как указание на роль, которую играет эта подсеть в архитектуре составной сети.
Сложности могут возникнуть и при интерпретации определения «аппаратный». В данном случае термин «аппаратный» подчеркивает концептуальное представление разработчиков стека TCP/IP о подсети как о некотором вспомогательном аппаратном средстве, единственной функцией которого является перемещение IP-пакета через подсеть до ближайшего шлюза (маршрутизатора). И не важно, что реально нижележащая локаль-
ная технология может быть достаточно сложной, все ее сложности технологией TCP/IP игнорируются.
Рассмотрим, например, случай, когда в составную сеть TCP/IP входит сеть IPX/SPX. Последняя сама может быть разделена на подсети, и так же как IP-сеть, она идентифицирует свои узлы аппаратными и сетевыми IPX-адресами. Но технология TCP/IP игнорирует многоуровневое строение сети IPX/SPX и рассматривает в качестве локальных адресов узлов подсети IPX/SPX адреса сетевого уровня данной технологии (IPX-адреса). Аналогично, если в составную сеть включена сеть Х.25, то локальными адресами узлов этой сети для протокола IP будут соответственно адреса Х.25.
Сетевые IP-адреса
Чтобы технология TCP/IP могла решать свою задачу объединения сетей, ей необходима собственная глобальная система адресации, не зависящая от способов адресации узлов в отдельных сетях. Эта система адресации должна позволять универсальным и однозначным способом идентифицировать любой интерфейс составной сети. Очевидным решением является уникальная нумерация всех сетей составной сети, а затем нумерация всех узлов в пределах каждой из этих сетей. Пара, состоящая из номера сети и номера узла, отвечает поставленным условиям и может являться сетевым адресом.
В качестве номера узла может выступать либо локальный адрес этого узла (такая схема принята в стеке IPX/SPX) , либо некоторое число, никак не связанное с локальной технологией и однозначно идентифицирующее узел в пределах данной подсети. В первом случае сетевой адрес становится зависимым от локальных технологий, что ограничивает его применение. Например, сетевые адреса IPX/SPX рассчитаны на работу в составных сетях,
объединяющих сети, в которых используются только МАС-адреса или адреса аналогичного формата. Второй подход более универсален, он характерен для стека TCP/IP. В технологии TCP/IP сетевой адрес называют IP-адресом.
Заметим, что использование локального адреса в качестве номера узла имеет ряд преимуществ, именно такая схема принята в протоколе IPv6.
Доменные имена
Между доменным именем и IP-адресом узла нет никакой функциональной зависимости, поэтому единственный способ установления соответствия — это таблица. В сетях TCP/IP используется специальная система доменных имен (Domain Name System, DNS), которая устанавливает это соответствие на основании создаваемых администраторами сети таблиц соответствия. Поэтому доменные имена называют также DNS-именами. В общем случае сетевой интерфейс может иметь несколько локальных адресов, сетевых адресов и доменных имен.
Формат IP-адреса
В заголовке IP-пакета для хранения IP-адресов отправителя и получателя отводятся два поля, каждое имеет фиксированную длину 4 байта (32 бита). IP-адрес состоит из двух логических частей — номера сети и номера узла в сети.
Наиболее распространенной формой представления IP-адреса является запись в виде четырех чисел, представляющих значения каждого байта в десятичной форме и разделенных
Этот же адрес может быть представлен в двоичном формате:
10000000 00001010 00000010 00011110
А также в шестнадцатеричном формате:
Заметим, что запись адреса не предусматривает специального разграничительного знака между номером сети и номером узла. Вместе с тем при передаче пакета по сети часто возникает необходимость разделить адрес на эти две части. Например, маршрутизация, как правило, осуществляется на основании номера сети, поэтому каждый маршрутизатор, получая пакет, должен прочитать из соответствующего поля заголовка адрес назначения и выделить из него номер сети. Каким образом маршрутизаторы определяют, какая часть из 32 бит, отведенных под IP-адрес, относится к номеру сети, а какая — к номеру узла?
Можно предложить несколько вариантов решения этой проблемы.
• Простейший из них состоит в использовании фиксированной границы. При этом все 32-битное поле адреса заранее делится на две части не обязательно равной, но фиксированной длины, в одной из которых всегда будет размещаться номер сети, в другой — номер узла.
Решение очень простое, но хорошее ли? Поскольку поле, которое отводится для хранения номера узла, имеет фиксированную длину, все сети будут иметь одинаковое максимальное число узлов. Если, например, под номер сети отвести один первый байт, то все адресное пространство распадется на сравнительно небольшое (28) число сетей огромного размера (224 узлов). Если границу передвинуть дальше вправо, то сетей станет больше, но все равно все они будут одинакового размера.
Очевидно, что такой жесткий подход не позволяет дифференцированно удовлетворять потребности отдельных предприятий и организаций. Именно поэтому он не нашел применения, хотя и использовался на начальном этапе существования технологии TCP/IP (RFC 760).
• Второй подход (RFC 950, RFC 1518) основан на использовании маски, которая позволяет максимально гибко устанавливать границу между номером сети и номером узла. При таком подходе адресное пространство можно использовать для создания множества сетей разного размера.
Маска — это число, применяемое в паре с IP-адресом, причем двоичная запись маски содержит непрерывную последовательность единиц в тех разрядах, которые должны в IP-адресе интерпретироваться как номер сети. Граница между последовательностями единиц и нулей в маске соответствует границе между номером сети и номером узла в IP-адресе.
• И, наконец, способ, основанный на классах адресов (RFC 791). Этот способ представляет собой компромисс по отношению к двум предыдущим: размеры сетей хотя и не могут быть произвольными, как при использовании масок, но и не должны быть
одинаковыми, как при установлении фиксированных границ.
Вводится пять классов адресов: А, В, С, D, Е. Три из них — А, В и С — предназначены для адресации сетей, а два — D и Е — имеют специальное назначение. Для каждого класса сетевых адресов определено собственное положение границы между номером сети и номером узла.
Классы IP-адресов
Признаком, на основании которого IP-адрес относят к тому или иному классу, являются значения нескольких первых битов адреса.
• К классу А относится адрес, в котором старший бит имеет значение 0. В адресах класса А под идентификатор сети отводится 1 байт, а остальные 3 байта интерпретируются как номер узла в сети. Сети, все IP-адреса которых имеют значение первого байта в диапазоне от 1 (00000001) до 126 (01111110), называются сетями класса А. Значение 0 (00000000) первого байта не используется, а значение 127 (01111111) зарезервировано для специальных целей (см. далее). Сетей класса А сравнительно немного, зато количество узлов в них может достигать 224, то есть 16 777 216 узлов.
• К классу В относятся все адреса, старшие два бита которых имеют значение 10. В адресах класса В под номер сети и под номер узла отводится по 2 байта. Сети, значения первых двух байтов адресов которых находятся в диапазоне от 128.0 (10000000 00000000) до 191.255 (1011111111111111), называются сетями класса В. Ясно, что сетей класса В больше, чем сетей класса А, а размеры их меньше. Максимальное количество узлов в сетях класса В составляет 216 (65 536).
• К классу С относятся все адреса, старшие три бита которых имеют значение 110. В адресах класса С под номер сети отводится 3 байта, а под номер узла — 1 байт. Сети, старшие три байта которых находятся в диапазоне от 192.0.0 (11000000 00000000 00000000) до 223.255.255 (11011111 11111111 11111111), называются сетями класса С. Сети класса С наиболее распространены, и наименьшее максимальное число узлов в них равно 28 (256).
• Если адрес начинается с последовательности 1110, то он является адресом класса D и обозначает особый групповой адрес (multicast address). В то время как адреса классов А, В и С служат для идентификации отдельных сетевых интерфейсов, то есть являются индивидуальными адресами (unicast address), групповой адрес идентифицирует группу сетевых интерфейсов, которые в общем случае могут принадлежать разным сетям. Интерфейс, входящий в группу, получает наряду с обычным индивидуальным IP-адресом еще один групповой адрес. Если при отправке пакета в качестве адреса назначения указан адрес класса D, то такой пакет должен быть доставлен всем узлам, которые входят в группу.
• Если адрес начинается с последовательности 11110, то это значит, что данный адрес относится к классу Е. Адреса этого класса зарезервированы для будущих применений. Чтобы получить из IP-адреса номер сети и номер узла, требуется не только разделить адрес на две соответствующие части, но и дополнить каждую из них нулями до полных 4 байт.
Возьмем, например, адрес класса В 129.64.134.5. Первые два байта идентифицируют сеть, а последующие два — узел. Таким образом, номером сети является адрес 129.64.0.0, а номером узла — адрес 0.0.134.5.
На транспортном уровне работают 2 протокола: TCP и UDP.
UDP (User Datagram Protocol) - протокол пользовательских дейтаграмм. Является ненадежным протоколом передачи данных, потому что он не устанавливает и не поддерживает соединения с удаленными узлами. То есть он просто передает данные на нижестоящий уровень и дальнейшая судьба этих данных его не интересует.
Кроме того, он не исправляет ошибки в принятых данных. Если будут обнаружены ошибки, то данные сегменты будут просто уничтожены и без запроса повторной передачи.
Для чего тогда такой протокол нужен?
Он очень полезен там, где передаваемые данные очень критичны к задержкам. Например, при передаче видео и голоса. Там недопустимы задержки, но можно пожертвовать несколькими пакетами в случае обнаружения ошибок - человеческие ухо и глаз не способны заметить потерю нескольких пакетов (если, конечно, число таких пакетов не слишком велико).
Однако для передачи чувствительных данных он совсем не годится, например, при передаче файлов - в данном случае задержки допустимы, но файл должен быть доставлен целостным.
Протокол добавляет следующий заголовок к передаваемым данным
А сколько всего может быть таких портов?
Всего насчитывается 65535 портов. Из них с 0 по 1023 зарезервированы под стандартные приложения, такие как FTP, SMTP, SNMP и другие. Остальные порты с 1024 и по 65535 могут быть использованы для любых других приложений. Эти порты еще называют динамическими, потому что у них нет жесткой привязки к определенному приложению и могут меняться от сеанса к сеансу.
Длина дейтаграммы - определяет длину всего сегмента, включая и сам заголовок.
Контрольная сумма - используется для проверки на наличие ошибок.
Как работает проверка?
Способ довольно примитивный. Передающий компьютер вычисляет контрольную сумму всего сегмента по специальному алгоритму и помещает это значение в поле Checksum. Затем принимающий компьютер вычисляет контрольную сумму данного сегмента и сравнивает с суммой в поле Checksum. Если значения совпадают, то сегмент принимается, в противном случае уничтожается.
И что произойдет дальше?
Ничего, UDP не заботится о дальнейшей судьбе потерянных данных.
TCP (Transmission Control Protocol) - Протокол Управления Передачей. Надежный протокол передачи данных. С помощью него устанавливается и поддерживается связь с удаленными узлами, управляется скорость передачи данных, контролируются ошибки при передаче данных.
Вот как выглядит заголовок сегмента TCP
С некоторыми полями мы уже знакомы. Опишем новые поля.
Порядковый номер - каждый байт в отправленном сегменте нумеруется для того, чтобы на приеме правильно собрать все сегменты в единый поток. Кроме того, с помощью номера контролируется весь поток данных и исправляются поврежденные сегменты.
Номер подтверждения - чтобы убедиться, что все переданные сегменты достигли адресата используются номера подтверждения. Например, узел А отправил сегмент с порядковым номером 45 узлу В. Когда узел В примет сегмент с номером 45, то отправит узлу А пустой сегмент с подтверждающим номером 46. Узел А будет знать, что все в порядке и отправит следующий сегмент под номером 46.
Флаги - специальные знаки-сигналы, указывающие на состояние сессии. Например, запрос на установление соединения или запрос на разрыв соединения.
Размер окна - определяет количество байт для отправки за один раз. Принимающий узел отправит подтверждение только для последнего байта в сегменте. Таким образом не нужно отправлять подтверждение за каждый байт, экономя тем самым время и канал связи. Например, если размер окна равен 500, то передающий узел сразу же отправит 500 байт данных в сегменте. Принимающий узел, получив все 500 байт, отправит лишь одно подтверждение. Размер окна может меняться в течении всего сеанса связи для регулирования скорости передачи.
А кто устанавливает размер окна?
Оба участника соединения. Например, принимающий узел сообщает передающему узлу размер окна исходя из того, как быстро принимающий узел справляется с поступающими данными. Если он не успевает обработать данные, то уменьшает размер и окна и передающий узел обязан уменьшить объем передаваемых данных.
Чтобы лучше понять назначение всех этих полей рассмотрим принцип работы протокола на примере установления соединения.
Установление соединения (Трехэтапное квитирование)
Процесс установления связи осуществляется в 3 этапа.
Этап 1
Когда сторона А хочет установить связь со стороной В, то сторона А отправляет запрос с установленным флагом SYN. После этого узел А переходит в состояние SYN SENT. Узел В остается в состоянии LISTEN:
Вот какие данные устанавливаются в заголовке TCP (для упрощения восприятия некоторые данные опущены):
Вот как выглядит запрос в сетевом анализаторе:
Генерируется порядковый номер ISNa = 1 и формируется запрос на установление соединения. Если по истечении таймаута со стороны В не поступает никакого ответа, то узел А снова отправит запрос узлу В.
Этап 2
Когда сторона В принимает запрос SYN, то тоже генерируется порядковый номер ISNb = 200 (в реальности номер может принимать другие значения) для своего сегмента. Для формирования ответа стороне А, узел В устанавливает 2 флага: SYN и ACK. Причем в качестве номера подтверждения берется порядковый номер сегмента стороны А и увеличивается на 1, то есть 1 + 1. Это означает, что запрос успешно принят и ожидается следующий сегмент с номером 2. После того, как сегмент отправлен, узел В переходит в состояние SYN-RECEIVED, узел А остается в состоянии SYN SENT:
Вот какие данные устанавливаются в заголовке TCP:
Вот как выглядит запрос в сетевом анализаторе:
Если по истечении таймаута от узла А не поступит подтверждения, то узел В снова отправит свой запрос.
Этап 3
После того, как узел А примет сразу 2 флага SYN и ACK, причем ACK будет на 1 больше ISN узла А, то сторона А сразу отправит второй сегмент узлу В. ISN будет увеличен на 1. Флаг будет установлен на ACK со значением ISNb + 1, то есть 200 + 1
Вот какие данные устанавливаются в заголовке TCP:
Вот как выглядит запрос в сетевом анализаторе:
После этого соединение считается успешно установленным, то есть помечается как ESTABLISHED.
Отказ в установлении соединения
Если сторона В по каким-то причинам не может установить соединение со стороной А, то генерируется ответ с флагом RST, которой информирует о прекращении попыток установления связи:
Вот какие данные устанавливаются в заголовке TCP:
Вот как выглядит запрос в сетевом анализаторе:
Когда одна из сторон желает завершить сеанс связи, то формирует запрос FIN и переходит в состояние FIN_WAIT 1
Сторона В подтверждает запрос отправкой ACK и переходит в состояние CLOSE_WAIT. Сразу же вслед посылается запрос FIN. После этого узел В переходит в состояние LAST_ACK:
Сторона А подтверждает отправкой ACK и переходит в состояние CLOSED. Когда узел В примет ACK, то также перейдет в состояние CLOSED. На этом сеанс связи завершен:
Контроль над искаженными и потерянными данными
Для реализации данного механизма и используются порядковые и подтверждающие номера. Каждый сегмент нумеруется первым байтом полезной нагрузки. Затем приемник посылает подтверждающий сегмент, где указывает номер первого байта следующего сегмента. Например, первый сегмент имеет 100 байт полезной нагрузки (заголовок не учитывается), второй сегмент - 200 байт. Первому байту первого сегмента присваивается номер 1, у первого байта второго сегмента номер соответственно равен 101 (100 + 1) и так далее
Теперь посмотрим как будет проходить передача сегментов
Вот как это выглядит в сетевом анализаторе:
Если сложить ISN = 2155299270 первого сегмента с длиной данных Len = 711, то получится ISN = 2155299981 второго сегмента. Таким способом приемник формирует ACK SN для 3-го сегмента.
С этим разобрались. Но что произойдет, если данные потеряны или искажены в процессе передачи?
Представим, что сегмент дошел до получателя, однако содержит ошибки. Это проверяется с помощью контрольной суммы. Тогда приемник сбросит искаженный сегмент и отправит подтверждение только за предпоследний сегмент. Передатчик поймет, что первые 2 сегмента получены без ошибок и снова отправит 3-й сегмент
Теперь посмотрим, что произойдет, если один сегмент не дойдет до получателя. В данном случае приемник вышлет подтверждение только за принятые сегменты. А о 3-ем сегменте он вообще ничего не знает, поэтому ничего не отправит.
Передатчик будет ждать определенное время и не дождавшись подтверждения за 3-й сегмент отправит его снова
Вот так и достигается контроль над ошибками данных.
Контроль за передачей данными (Метод скользящего окна)
Протокол TCP является дуплексным, то есть может одновременно работать на прием и передачу. Для этого на приеме и передаче устанавливаются буферы.
Передающий буфер содержит переданные, но еще не подтвержденные байты, а также байты готовые для передачи.
Приемный буфер содержит принятые байты для последующей обработки.
Но для чего нужны буферы, разве не может приемник сразу же обработать поступивший сегмент?
Буферы необходимы для постановки в очередь принятые и передаваемые данные, так как производительность приёмной и передающей систем, а также самой сети разные, то велика вероятность, что система не сможет на “лету” обработать большой объем данных.
Тогда приемник просто сбросит новые поступающие данные и отправит подтверждения только на полученные и обработанные сегменты.
Передатчику придется повторно отправлять данные, пока не получит подтверждения успешного получения.
В данной ситуации приемник работает на пределе своих возможностей, а сеть постоянно загружена. Поэтому в TCP предусмотрен механизм контроля за передачей данных с помощью метода скользящего окна.
И как работает данный механизм?
В TCP заголовке имеется поле “Размер окна (Window size)”, которое указывает на то, сколько байт приемник способен принять. Иными словами это говорит о доступности буфера и наличии в нем свободного пространства для поступающих данных.
После установления соединения приемник сообщает передатчику размер окна. Например, приемник сообщил, что окно равно 5 байтам. Передатчик передаст 5 байт информации и ждет подтверждения:
В буфере передатчика в очереди на отправку стоят следующие байты, но они не будут отправлены, пока не будут подтверждены уже отправленные байты. Приемник посылает подтверждение и уведомляет о размере окна равным 5, то есть говорит: “В моем буфере есть 5 свободных мест. Пришли мне еще 5 байт.”
Окно в передающем буфере сместится на 5 байт и новая порция данных будет передана приемнику:
Теперь посмотрим, что произойдет, если приемник не успевает обработать все полученные данные и в его буфере свободное место только для 2-х байт:
Передатчик готов передать следующие 5 байт информации, так как получил подтверждение от приемника. Однако приемник также уведомил передатчик, что в приемном буфере свободно только для 2-х байт, то есть сообщает следующее: “Снижай скорость передачи. Готов принять пока 2 байта.”
И передатчик уменьшает окно и передает только 2 байта
В процессе передачи данных размер окна может постоянно меняться. Это зависит от загруженности сети и производительности передатчиков/приемников.
Что происходит, когда в буфере приемника совсем нет места?
Тогда приемник установит размер окна равным 0. Это означает прекратить передачу данных.
Как же передатчик узнает, что буфер приемника снова готов к работе?
После получения нулевого размера окна передатчик запускает специальный таймер, по истечении которого передатчик отправит пробный сегмент. Если буфер свободен, то приемник ответит на этот пробный сегмент и укажет новый размер окна, в противном случае снова укажет нулевое окно.
Итак подведем краткие итоги.
В таблице представлены сравнение протоколов UDP и TCP, а также функции, возложенные на транспортный уровень
протокол пользовательских дейтаграмм (User Datagram Protocol, UDP), описанный в стандарте RFC 768.
Протоколы TCP и UDP, как и протоколы прикладного уровня, устанавливаются на конечных узлах.
Главная задача протоколов транспортного уровня TCP и UDP заключается в передаче данных между прикладными процессами, выполняющимися на компьютерах в сети.
Рис. 17.1. Мультиплексирование и демультиплексирование на транспортном уровне
Существует и обратная задача: данные, генерируемые разными приложениями, работающими на одном конечном узле, должны быть переданы общему для всех них протокольному модулю IP для последующей отправки в сеть. Эту работу, называемую мультиплексированием, тоже выполняют протоколы TCP и UDP.
Протоколы TCP и UDP ведут для каждого приложения две системные очереди: очередь данных, поступающих к приложению из сети, и очередь данных, отправляемых этим приложением в сеть. Такие системные очереди называются портами, причем входная и выходная очереди одного приложения рассматриваются как один порт. Для идентификации портов им присваивают номера.
Если процессы представляют собой популярные системные службы, такие как FTP, telnet, HТТР, TFTP, DNS и т. п., то за ними закрепляются стандартные назначенные номера, называемые также хорошо известными (well-known) номерами портов. Так, номер 21 закреплен за серверной частью службы удаленного доступа к файлам FTP, a 23 — за серверной частью службы удаленного управления telnet. Назначенные номера из диапазона от 0 до 1023 являются уникальными в пределах Интернета и закрепляются за приложениями централизованно.
Для тех приложений, которые еще не стали столь распространенными, номера портов назначаются локально разработчиками этих приложений или операционной системой. На каждом компьютере операционная система ведет список занятых и свободных номеров портов. При поступлении запроса от приложения, выполняемого на данном компьютере, операционная система выделяет ему первый свободный номер. Такие номера называют динамическими. В дальнейшем все сетевые приложения должны адресоваться к данному приложению с указанием назначенного ему динамического номера порта. После того как приложение завершит работу, его номер возвращается в список свободных и может быть назначен другому приложению. Динамические номера являются уникальными в пределах каждого компьютера, но при этом обычной является ситуация совпадения номеров портов приложений, выполняемых на разных компьютерах. Как правило, клиентские части известных приложений (DNS, W WW, FTP, telnet и др.) получают динамические номера портов от ОС.
В том и другом случаях это могут быть как назначенные, так и динамические номера. Диапазоны чисел, которых выделяются номера TCP- и UDP-портов, совпадают: от 0 до 1023 для назначенных и от 1024 до 65 535 для динамических.
Рис. 17.2. Демультиплексирование протокола UDP на основе сокетов
Чтобы снять неоднозначность в идентификации приложений, разные копии связываются с разными IP-адресами. Для этого сетевой интерфейс компьютера, на котором выполняется несколько копий приложения, должен иметь соответствующее число IР-адресов – на рисунке это IP1 и IP2. Во всех IP-пакетах, направляемых DNS-серверу 1, в качестве -адреса указывается IP1, а DNS-серверу 2 - адрес IP2. Поэтому показанный на рисунке пакет, в поле данных которого содержится UDP-дейтаграмма с указанным номером порта 53, а в поле заголовка задан адрес IP2, буден направлен однозначно определенному адресату - DNS-серверу 2.
Протокол UDP и UDP-дейтаграммы
Рис. 17.3. Работа протокола UDP на хосте-отправителе
Заголовок UDP состоит из четырех 2-байтных полей:
номер UDP-порта отправителя;
номер UDP-порта получателя;
Далее приведен пример заголовка UDP с заполненными полями:
Source Port - 0x0035
Destination Port = 0x0411
Total length = 132 (0x84) bytes
К примеру, если контрольная сумма показывает, что в поле данных UDP-дейтаграммы произошла ошибка, протокол UDP просто отбрасывает поврежденную дейтаграмму.
Протокол TCP и TCP-сегменты
Протокол TCP предназначен для передачи данных между приложениями. Этот протокол работает на логическом соединении, что позволяет ему обеспечивать гарантированную доставку пакета, используя в качестве инструмента ненадежный дейтаграммный сервис протокола IP.
При работе на хосте-отправителе протокол TCP рассматривает информацию, поступающую к нему от прикладных процессов, как неструктурированный поток байтов (рис 17.4). Поступающие данные буферизуются средствами TCP. Для передачи на сетевой уровень из буфера «вырезается» некоторая непрерывная часть данных, которая называется сегментом и снабжается заголовком
Рис. 17.4. Формирование TCP-сегментов из потока байтов
Поясним значение однобитных полей, называемых флагами, или кодовыми битами (Code bits). Они расположены сразу за резервным полем и содержат служебную информацию о типе данного сегмента. Положительное значение сигнализируется установкой этих битов в единицу:
ACK - квитанция на принятый сегмент;
RST - запрос на восстановление соединения;
FIN - признак достижения передающей стороной последнего байта в потоке передаваемых данных
Основная задача TCP протокола – это установление надежного логического соединения.
пользовательских дейтаграмм, мультиплексирование, демультиплексирование, порт, назначенный номер порта, хорошо известные номера портов, динамический номер порта, UDP-порт, ТСР-порт, UDP-дейтаграмма, пользовательская дейтаграмма, UDP-сокет, порт источника, порт приемника, последовательный номер, подтвержденный номер, длина заголовка, резервные биты, кодовые биты, контрольная сумма, указатель срочности, параметры, заполнитель, логическое соединение, окно приема.
Как уже было отмечено, главная задача транспортного уровня заключается в передаче данных между прикладными процессами. Эту задачу решают протокол управления передачей (Transmission Control Protocol, TCP), описанный в RFC 793, и протокол пользовательских дейтаграмм (User Datagram Protocol, UDP), описанный в RFC 768. Протоколы TCP и UDP имеют много общего. Тот и другой обеспечивают интерфейс с вышележащим прикладным уровнем, передавая данные, поступающие на входной интерфейс хоста, соответствующему приложению. При этом оба протокола используют концепции «порт» и «сокет». Оба они также поддерживают интерфейс с нижележащим сетевым уровнем IP, упаковывая свои PDU в IP-накеты. Протокольные сущности TCP и UDP, как и в случае протоколов прикладного уровня, устанавливаются только на конечных узлах. Однако, как мы увидим далее, различий между TCP и UDP гораздо больше, чем сходств.
Порты
Существует и обратная задача: пакеты, которые отправляют в сеть разные приложения, работающие на одном конечном узле, обрабатываются общим для них протоколом IP. Следовательно, в стеке должно быть предусмотрено средство «сбора» пакетов от разных приложений для передачи протоколу IP. Эту работу выполняют протоколы TCP и UDP.
Процедура приема данных протоколами TCP и UDP, поступающих от нескольких различных прикладных служб, называется мультиплексированием. Обратная процедура — процедура распределения протоколами TCP и UDP поступаю щих от сетевого уровня пакетов между набором высокоуровневых служб — называется демультиплексированием (рис. 19.1).
 |
Протоколы TCP и UDP ведут для каждого приложения две очереди: очередь пакетов, поступающих к данному приложению из сети, и очередь пакетов, отправляемых данным приложением в сеть. Пакеты, поступающие на транспортный уровень, организуются операционной системой в виде множества очередей к точкам входа различных прикладных процессов. В терминологии TCP/IP такие системные очереди называются портами [35] , причем входная и выходная очереди одного приложения рассматриваются как один порт. Для однозначной идентификации портов им присваивают номера. Номера портов используются для адресации приложений.
Для тех приложений, которые еще не стали столь распространенными, чтобы закреплять за ними стандартные номера, номера портов назначаются разработчиками этих приложений или операционной системой локально в ответ на поступление запроса от приложения. На каждом компьютере операционная система ведет список занятых и свободных номеров портов. При поступлении запроса от приложения, выполняемого на данном компьютере, операционная система выделяет ему первый свободный номер. Такие номера называют динамическими.
В дальнейшем все сетевые приложения должны адресоваться к данному приложению с указанием назначенного ему номера порта. После того как приложение завершит работу, выделенный ему локальный номер порта возвращается в список свободных и может быть назначен другому приложению. Динамические номера являются уникальными в пределах каждого компьютера, но при этом обычной ситуацией является совпадение номеров портов приложений, выполняемых на разных компьютерах. Как правило, клиентские части известных приложений (DNS, WWW, FTP, telnet и др.) получают динамические номера портов от ОС.
Все, что было сказано о портах, в равной степени относится к обоим протоколам транспортного уровня (TCP и UDP). В принципе нет никакой зависимости между назначением номеров для приложений, использующих протокол TCP, и приложений, работающих с протоколом UDP. Приложения, которые передают данные на уровень IP по протоколу UDP, получают номера, называемые UDP- портами. Аналогично приложениям, обращающимся к протоколу TCP, выделяются ТСР-порты.
В том и другом случаях это могут быть как назначенные, так и динамические номера. Диапазоны чисел, из которых выделяются номера TCP- и UDP-портов, совпадают: от 0 до 1023 для назначенных и от 1024 до 65535 для динамических. Однако никакой связи между назначенными номерами TCP- и UDP-портов нет. Даже если номера TCP- и UDP-портов совпадают, они идентифицируют разные приложения. Например, одному приложению может быть назначен ТСР-порт 1750, а другому — UDP-порт 1750. В некоторых случаях, когда приложение может обращаться по выбору к протоколу TCP или UDP (например, таким приложением является DNS), ему, исходя из удобства запоминания, назначаются совпадающие номера TCP- и UDP-портов (в данном примере — это номер 53).
Читайте также: