Transmission control protocol что означает
Коллапс перезагрузки
p, blockquote 8,0,0,0,0 -->
p, blockquote 9,0,0,0,0 -->
Итоги
p, blockquote 50,0,0,0,0 -->
TCP для определения размера окна перегрузки, использует комбинацию двух методов, аддитивное увеличение мультипликативное уменьшение и медленный старт. Сначала работает медленный старт, затем происходит переход на аддитивное увеличение мультипликативное уменьшение. Основным сигналом перегрузки являются потеря сегментов в сети, но также существуют и другие сигналы, эта задержка сегментов и явный сигнал от маршрутизатора.
p, blockquote 51,0,0,0,0 --> p, blockquote 52,0,0,0,1 -->
На этом уровне есть два протокола, протокол UDP, который уже рассматривали и протокол TCP, который является одним из основных протоколов стека TCP/IP и интернет.
p, blockquote 3,0,0,0,0 -->
p, blockquote 4,0,0,0,0 -->
p, blockquote 5,0,0,0,0 -->
Пример переноса данных в IP-сети
На примере IP-сети (рис. 2) покажем перенос данных оконечной станции А локальной вычислительной сети (подсети) Ethernet в оконечную станцию В сети (подсети) АТМ. Как видно из рисунка в эту составную сеть еще входит сеть (подсеть) Frame Relay. В основу приведенного упрощенного описания положен пример межсетевого взаимодействия сетей Ethernet и АТМ, приведенный в работе [3] . Дополнительно в эту составную сеть введена сеть (подсеть) Frame Relay. Принцип маршрутизации и краткое описание протоколов маршрутизации в сети Интернет приведены в следующей главе. Для того, чтобы технология TCP/IP могла решать задачу объединения сетей, ей необходима собственная глобальная система адресации, не зависящая от способов адресации узлов в отдельных подсетях. Таким адресом является IP-адрес, состоящий из адреса подсети (префикса) и адреса оконечного устройства (хоста). Приведем пример адресации подсети и хоста. IP-адрес 200.15.45.126/25 означает, что 25 старших бит из выделенных 4-х байт под адресацию являются адресом подсети, а оставшиеся 7 бит означают адрес хоста в этой сети.
Как видно из предыдущих глав, глобальные сети Frame Relay и АТМ имеют различные системы нумерации, которые отличаются от системы нумерации локальной вычислительной сети (ЛВС) технологии Ethernet. Каждый компьютер Ethernet имеет уникальный физический адрес, состоящий из 48 бит. Этот адрес называется МАС-адресом и относится к канальному уровню — управлению доступом к среде MAC (Media Access Control). Для организации межсетевого взаимодействия подсетей различной технологии и адресации используются маршрутизаторы, включающие IP-пакеты. В состав этих пакетов входят глобальные IP-адреса. Каждый интерфейс маршрутизатора IP-сети и оконечного устройства включает два адреса – локальный адрес оконечного устройства подсети и IP-адрес.
Рассмотрим продвижение IP-пакета в сети (рис. 2).
- Пользователь компьютера А сети Ethernet, имеющий IP-адрес (IP-адрес 1), обращается по протоколу передачи файла FTP к компьютеру В, подключенному к сети АТМ и имеющий IP-адрес (IP-адрес 6).
- Компьютер А формирует кадр Ethernet для отправки IP-пакета. По таблице маршрутизации в компьютере А на основании IP-адресов А и В определятся маршрутизатор М1 и входящий интерфейс для передачи этого IP-пакета. При этом становится известен IP-адрес интерфейса маршрутизатора М1(IP-адрес 2).
- Компьютер А отправляет по сети Ethernet IP-пакет, инкапсулированный в кадр Ethernet и включающий следующие поля (рис. 3).
Процедура создания ассоциаций SCTP
Механизм Cookie
Прочие компоненты процедуры создания ассоциаций SCTP соответствуют большинству соглашений, используемых для соединений TCP – конечные точки обмениваются информацией о размере приемного окна, стартовых порядковых номерах и т. п. Кроме того, конечные точки могут обмениваться упомянутыми выше списками адресов, а также согласовывать количество потоков, открываемых каждой из сторон.
INIT Collision Resolution
Гарантия доставки: подтверждение получения
p, blockquote 9,0,0,0,0 -->
p, blockquote 10,0,0,0,0 -->
Гарантия доставки: повторная отправка
p, blockquote 11,0,0,0,0 -->
p, blockquote 12,0,0,0,0 -->
Предположим, что в этот раз сегмент дошел, получатель отправляет подтверждение, отправитель может передавать следующий сегмент данных.
p, blockquote 13,0,0,0,0 -->
p, blockquote 14,0,1,0,0 -->
Расширения
Формат SCTP позволяет определять новые типы блоков (chunk), поля флагов и параметров для расширения возможностей протокола. Любое расширение должно базироваться на стандартном соглашении с IETF, следовательно фирменные расширения не поддерживаются протоколом.
Значения Chunk Type разбиты на 4 группы, чтобы позволить расширениям использовать предопределенные процедуры для откликов на нераспознанные типы блоков. Варианты откликов включают: отбрасывание пакета целиком, игнорирование блока, а также игнорирование с передачей отчета. Аналогичные предопределенные отклики поддерживаются и для неопознанных значений Parameter Type.
Значения Chunk Parameter Type используют независимые диапазоны для каждого Chunk Type. На практике значения, определенные в спецификации SCTP, скоординированы таким образом, что конкретный параметр будет использовать одинаковые значения Chunk Parameter Type для всех Chunk Type. Необходимость такого выбора подтвердит практика использования протокола.
Протокол TCP: скользящее окно
Работа протокола TCP отличаются от той схемы, которую мы сейчас рассмотрели. Подтверждается не каждый сегмент, а несколько сегментов следующие друг за другом, этот механизм называется скользящее окно.
p, blockquote 15,0,0,0,0 -->
- Остановка и ожидание (Wi-Fi, канальный уровень)
- Скользящее окно (TCP, транспортный уровень)
Варианты подтверждения доставки
Рассмотрим остановку и ожидание. Отправитель передает данные и останавливается ожидая подтверждение. Получатель присылает подтверждение после этого передается следующая порция данных. Снова подтверждение, снова данные и снова подтверждение.
p, blockquote 17,0,0,0,0 -->
p, blockquote 18,0,0,0,0 -->
Другой вариант скользящее окно. В этом случае отправитель передает сразу несколько порций данных не дожидаясь подтверждения. Получатель отправляет одно подтверждение которое называется кумулятивное. Это означает, что получатель получил последнюю порцию данных и все предыдущие.
p, blockquote 19,0,0,0,0 -->
p, blockquote 20,0,0,0,0 -->
В локальных сетях, например Wi-Fi используется метод подтверждения остановка и ожидания. В крупных современных сетях с высокоскоростными каналами связи большой протяженности, например если вы хотите скачать чего-нибудь с американского сайта, такой объем данных может быть очень большой. И в этой ситуации ожидания подтверждения приводит к существенному снижению производительности.
p, blockquote 21,0,0,0,0 -->
Пример подтверждения доставки
Рассмотрим на примере работу сети.
Скользящее окно
Почему термин называется скользящее окно? Удобно представлять себе окно, которое скользит по потоку байт получаемых от приложений. У есть поток байт, разделенный на отдельные сегменты, часть сегментов уже передана, часть еще не отправлены. Для некоторых сегментов, которые уже переданы, получено подтверждение. И отправлено некоторое количество сегментов соответствующие размеру окна, для которых подтверждение не получено.
p, blockquote 23,0,0,0,0 -->
p, blockquote 24,0,0,0,0 -->
p, blockquote 26,0,0,0,0 -->
p, blockquote 27,0,0,0,0 -->
Тип подтверждения
Есть два типа подтверждения, которые могут использоваться совместно с алгоритмом скользящего окна.
- Кумулятивное подтверждение, говорит о том что получен указанный байт данных и все предыдущие. Такой подход используется в TCP по умолчанию. Сейчас из-за того что распространились высокоскоростные каналы связи большой протяженности, размер окна в TCP может быть увеличен до 1 гигабайта. Представьте, что вы передали гигабайт данных и у вас потерялся всего лишь один сегмент, который находится в середине. С помощью кумулятивного подтверждения вы можете подтвердить получение только первых 500 мегабайт, получится что вам придётся повторно передавать 500 мегабайт данных, которые уже есть у получателя.
Для устранения этой проблемы предложено выборочное подтверждение. В этом случае получатель подтверждает получение диапазона принятых байт. Он получил первые 500 мегабайт и вторые 500 мегабайт из гигабайта и не получил всего лишь один сегмент. Отправитель вместо вторых 500 мегабайт, повторно передает всего лишь один недостающий сегмент. Выборочное подтверждение эффективно при большом размере окна TCP, но выборочное подтверждение по умолчанию не используется для этого необходимо применение дополнительных полей заголовка TCP, которые называются параметрами.
p, blockquote 29,0,0,0,0 -->
p, blockquote 30,0,0,0,0 -->
p, blockquote 31,0,0,0,0 -->
Дублирование сегментов
Предположим, отправитель передал сегмент данных получателю, получатель этот сегмент принял и передал отправителю подтверждение, но при передаче подтверждения произошла ошибка. Отправитель не получил подтверждение, сработал таймер и тот же самый сегмент данных был отправлен второй раз.
p, blockquote 32,0,0,0,0 -->
p, blockquote 33,0,0,0,0 -->
p, blockquote 34,0,0,0,0 -->
p, blockquote 35,0,0,0,0 -->
p, blockquote 36,0,0,0,0 -->
В нашем примере 4 сегмента первый сегмент содержит байты от 0 до 1023, второй от 1024 до 2047 и так далее.
p, blockquote 37,0,0,0,0 -->
Нумерация байтов
При передаче отправитель включают в сегмент номер первого байта данных, которые в нем содержатся.
p, blockquote 38,0,0,0,0 -->
- Например сегмент данных, байт 0, он содержит байты с 0 до 1023.
- Получатель отправляет подтверждение и в подтверждение включает номер следующего байта, который ожидается байт 1024.
- Отправитель передает следующий сегмент, включая в него номер первого байта, сегмент данных, номер первого байта 1024 содержит данные до номера байта 2047.
- Получатель отправляет подтверждение, что он ждет байт с номером 2048, если сегменты придут в неправильном порядке, то получатель по номерам байтов всегда сможет выставить их в правильной последовательности.
Дублирование сегментов
Рассмотрим как решается ситуация с дублированием сегментов.
p, blockquote 40,0,0,0,0 -->
- Отправитель включает в сегмент номер первого передаваемого байта 1024.
- Получатель отправляет подтверждение, где говорит что ждет байт в 2048.
- Но так как подтверждение не дошло, то отправитель передает тот же самый сегмент 1024.
- Однако получатель видит, что этот сегмент у него уже есть поэтому он этот сегмент игнорирует и снова отправляет подтверждение, где говорит что он ожидает байт 2048.
Сигнал о перегрузке
Следующий вариант, как отправитель может узнать о перегрузке это явный сигнал от маршрутизатора. Однако для этого маршрутизаторы должны поддерживать отправку сигналов. Одним из возможных вариантов является технология Random Early Detection, при этом маршрутизатор с некоторой вероятностью начинает отбрасывать пакеты еще до того как буфер полностью заполнен и началась перегрузка.
p, blockquote 39,0,0,1,0 -->
В результате отправители узнают о возможной перегрузке по потере сегмента ещё до того, как она произошла, и получают возможность заранее уменьшить окно перегрузки. Но это не явный тип сигнала, технологиях Explicit Congestion Notification, обеспечивает явную отправку сигнала от маршрутизатора к отправителю, о том что в сети происходит перегрузка.
p, blockquote 40,0,0,0,0 -->
Explicit Congestion Notification (ECN)
Рассмотрим на схеме, как она работает. Отправитель передает сегмент в сеть, который доходит до маршрутизатора. Маршрутизатор находится в состоянии близкому к перегрузке, буфер заполнен, но не полностью. Для того чтобы предупредить отправителя о перегрузке в сети, маршрутизатор устанавливать специальные флаги в заголовке IP, которые говорят о том, что в сети произошла перегрузка.
p, blockquote 41,0,0,0,0 -->
p, blockquote 42,0,0,0,0 -->
Сегмент передается по сети дальше и достигает получателя. Получатель в заголовке IP видит что установлен флаг, свидетельствующий о перегрузке, для того чтобы о перегрузке узнал не только получатель, но и отправитель, получатель устанавливает соответствующие флаги уже в заголовке TCP, когда передает подтверждение.
p, blockquote 43,0,0,0,0 -->
p, blockquote 44,0,0,0,0 -->
p, blockquote 45,0,0,0,0 -->
ECN в заголовке IP
Рассмотрим, какие поля в заголовке IP и TCP используются в технологии Explicit Congestion Notification. В заголовке IP используются 2 бита в поле тип сервиса, значение 00 говорит о том, что перегрузки нет, а 11 означают что перегрузка произошла.
p, blockquote 46,0,0,0,0 -->
p, blockquote 47,0,0,0,0 -->
ECN в заголовке TCP
В заголовке TCP для этих целей используются три флага, NS, CWR, ECE.
p, blockquote 48,0,0,0,0 -->
Основные функции SCTP
SCTP представляет собой unicast-протокол, который обеспечивает обмен данными между двумя конечными точками. Отметим, что каждая из этих точек может быть представлена более чем 1 адресом IP. Протокол SCTP обеспечивает гарантию доставки, детектирование случаев отбрасывания данных, изменения порядка доставки, повреждения или дублирования данных, а также повторную передачу пакетов при возникновении необходимости. Обмен данными по протоколу SCTP происходит в полнодуплексном режиме.
Поддержка многодомных хостов в SCTP
Другим важным качеством SCTP является поддержка многодомных хостов, позволяющая создавать конечные точки SCTP с мно- жеством IP-адресов. Поддержка многодомных хостов повышает уровень “живучести” сессий в случаях возникновения сбоев в сети. В традиционных однодомных сеансах отказ в соединении с ЛВС может изолировать конечную точку, а сбой в работе магистральной сети может привести к временным проблемам на транспортном уровне, пока протокол маршрутизации IP не найдет пути в обход сбойного участка. При использовании многодомных узлов SCTP могут быть организованы резервные (избыточные) соединения с ЛВС и поддерживаются различные варианты преодоления сложностей, связанных с отказами в магистральных сетях. Использование адресов с различными префиксами может обеспечить автоматическую маршрутизацию пакетов к другому оператору. Можно использовать методы route-pinning или даже резервировать соединения с магистральными сетями, если обеспечивается контроль над сетевой архитектурой и протоколами.
Функции обмена данными в SCTP
Алгоритмы управления трафиком и предотвращения насыщения соответствуют аналогичным алгоритмам TCP. Анонсируемый размер окна показывает емкость буфера на приемной стороне, а поддерживаемое для пути окно насыщения позволяет управлять пакетами “на лету”. Алгоритмы Congestion avoidance, Fast recovery и Fast retransmit встроены в протокольные процедуры в соответствии с RFC 2581. Единственным отличием является то, что конечные точки должны обеспечивать преобразование между количеством принятых/переданных байтов и номерами TSN, поскольку нумерация TSN осуществляется для транка в целом.
Соединение TCP
TCP для передачи данных использует соединение. Соединение нужно установить перед тем, как начать передачу данных, а после того как передача данных завершена, соединение разрывается.
p, blockquote 42,0,0,1,0 -->
Задачи соединения
- Убедиться в том, что отправитель и получатель действительно хотят передавать данные друг другу
- Договориться о нумерации потоков байт. С точки зрения практической реализации нельзя всегда нумеровать данные в потоке байт с нуля. Каждый раз начальное значение для нумерации байт выбираются по определенному алгоритму и отправитель и получатель должны договориться между собой какое начальное значение они будут использовать для нумерации потока байт.
- При установке соединения происходит договоренность о некоторых параметрах соединения.
Установка соединения в TCP
p, blockquote 43,0,0,0,0 -->
p, blockquote 44,0,0,0,0 -->
p, blockquote 45,0,0,0,0 -->
p, blockquote 46,0,0,0,0 -->
Разрыв соединения в TCP
p, blockquote 47,0,0,0,0 -->
p, blockquote 48,0,0,0,0 -->
p, blockquote 49,0,0,0,0 -->
p, blockquote 50,0,0,0,0 -->
p, blockquote 51,0,0,0,0 -->
Пример реализации многопотоковой передачи
Сервер точного времени
Исходный код начинается с создания сокета сервера (IPPROTO_SCTP используется для создания сокета SCTP прямого соединения). Затем создается структура sockaddr, в которой указывается, что разрешаются соединения к любому локальному интерфейсу (используется подстановочный (wildcard) адрес INADDR_ANY). Структура sockaddr привязывается к сокету с помощью вызова bind, а потом сокет сервера переводится в состояние прослушивания (listening state). С этого момента возможны входящие соединения.
Обратите внимание на то, что протокол SCTP использует многие из тех же сокетов API, что и протоколы TCP и UDP. Некоторые дополнительные функции API реализованы в инструментах разработки lksctp (см. раздел Ресурсы).
Серверная программа ожидает в цикле нового подключения клиента. При возвращении из функции accept создается новое клиентское подключение, определяемое сокетом connSock. С помощью функции time выясняется текущее время и переводится в строку функцией snprintf. С помощью функции sctp_sendmsg (нестандартный вызов сокета) строка посылается клиенту по заданному потоку (LOCALTIME_STREAM). После того как строка с локальным временем послана, текущее время переводится в формат GMT и посылается по потоку GMT_STREAM.
Таким образом, сервер выполнил свои функции, поэтому сокет закрывается и переходит в режим ожидания нового клиентского подключения.
Клиент протокола точного времени
AIMD
В TCP для определения размера окна перегрузки используется метод аддитивного увеличения, мультипликативного уменьшения. Суть метода заключается в том, что при получении каждого подтверждения, мы прибавляем к размеру окна некоторые значения, как правило это размер одного сегмента TCP, а если перегрузка произошла, то мы умножаем размер окна на некоторые значения. Как правило это 1/2, то есть в TCP при перегрузке, размер окна уменьшается в два раза.
p, blockquote 15,0,0,0,0 -->
Размер окна AIMD
Вот график работы метода аддитивного увеличения, мультипликативного уменьшения. Мы начинаем передавать данные, поступает подтверждение,размер окна увеличивается, происходит аддитивное увеличение. Затем в сети произошла перегрузка, размер окна уменьшается в два раза, произошло мультипликативное уменьшение.
p, blockquote 17,0,0,0,0 -->
p, blockquote 18,0,0,0,0 -->
Затем данные снова передаются, размера окна при получение каждого подтверждения увеличивается на один сегмент, аддитивные увеличения. И так происходит пока не произойдет следующая перегрузка. Таким образом, размер окна у нас напоминают зубья пилы.
p, blockquote 19,0,0,0,0 -->
Будущее протокола SCTP
После включения протокола SCTP в ядро Linux 2.6 стало возможным построение и развертывание надежных сетевых приложений высокой готовности. Основываясь на протоколе IP, SCTP позволяет прозрачно заменить протоколы TCP и UDP, введя при этом дополнительные возможности: множественную адресацию, многопоточную передачу и повышенную безопасность. Сейчас, когда вы познакомились с некоторыми преимуществами протокола SCTP, вы можете исследовать другие его возможности. В проекте Linux Kernel SCTP (lksctp) имеются документация и дополнительные функции API, которые помогут вам в ваших исследованиях.
В прошлой статье мы рассматривали управление потоком в TCP, это способ предотвращения отправки в сеть слишком большого количества сегментов, которые не могут быть приняты получателем, у которого просто недостаточно и места в буфере.
p, blockquote 1,0,0,0,0 -->
p, blockquote 2,0,0,0,0 -->
Получатель, при отправке каждого подтверждения, указывает в сегменте размер окна, количество байт, которые он может принять. Отправлять больше данных в сеть не имеет смысла.
p, blockquote 3,0,0,0,0 -->
p, blockquote 4,0,0,0,0 -->
Но возможна и другая проблема. В буфере получателя может быть достаточно свободного места, но сеть, через которую передаются данные, перегружена.
p, blockquote 5,0,0,0,0 -->
p, blockquote 6,0,0,0,0 -->
Одновременно, большое количество компьютеров решили передавать данные, маршрутизаторы не способны передать такое большое количество пакетов в единицу времени и они вынуждены отбрасывать пакеты. В этом случае происходит перегрузка, отправители передают в сеть большое количество данных, однако большая часть из этих данных отбрасываются маршрутизаторами и не доходит до получателей. Таким образом, большая часть каналов сети занята, но полезные данные от отправителя до получателя почти не доходят.
p, blockquote 7,0,0,0,0 -->
TCP/IP (Transmission Control Protocol/Internet Protocol)
IP-сеть (какой является Интернет) отличается от глобальных сетей тем, что является составной сетью из подсетей, число которых измеряется тысячами. Для Интернета характерно использование стека протоколов не эталонной модели OSI, а эталонной модели TCP/IP [1] [2] . На рис. 1 представлен стек протоколов TCP/IP и его соответствие уровням модели OSI. Отличительной особенностью TCP/IP является также то, что IP-пакеты могут передаваться с использованием различных технологий составных сетей, в том числе посредством уже рассмотренных глобальных сетей Х.25, FR и ATM, которые являются самостоятельными со своими протоколами, адресацией и др. Другой особенностью является то, что эталонная модель TCP/IP в отличие от эталонной модели OSI была разработана под конкретную составную сеть (интерсеть или internet). Подсети, составляющую эту составную сеть, соединяются между собой маршрутизаторами. Такими подсетями могут быть как локальные, так и глобальные сети различных технологий.
Транспортный уровень стека TCP/IP
Транспортный уровень стека TCP/IP (уровень 3) обеспечивает передачу данных между прикладными процессами. Транспортный уровень включает два протокола TCP и UDP. Протокол управления передачей TCP (Transmission Control Protocol) является надёжным протоколом с установлением соединения, позволяющим управлять потоком, т.е. без ошибок доставлять байтовый поток с одной машины на любую другую машину составной сети. Для того чтобы обеспечить надёжную доставку данных, протокол TCP предусматривает установление логического соединения. Это позволяет ему нумеровать пакеты, подтверждать их прием квитанциями, в случае потери организовывать повторные передачи, распознавать и уничтожать дубликаты, доставлять прикладному уровню в том порядке, в котором они были отправлены. Пакеты, поступающие на транспортный уровень, организуются в виде множества очередей к точкам входа прикладных процессов. В терминологии TCP/IP такие очереди, однозначно определяющие приложение в пределах хоста, называется портами. За портами каждого стандартного приложения определён номер например, порт TCP № 21 - за протоколом передачи файла FTP (File Transport Protocol). Номер порта в совокупности с номером сети и номером конечного узла имеет название сокет (socket). Каждое логическое соединение идентифицируется парой сокетов взаимодействующих процессов. Второй протокол транспортного уровня -протокол пользователей дейтаграмм UDP (User Data Protocol) является простейшим дейтаграммным протоколом (т.е. без установления соединения). К протоколу транспортного уровня относится протокол информационной безопасности SSL/TLS. Протоколы прикладного и транспортного уровней стека уровней TCP/IP устанавливаются на оконечных станциях (хостах) сети.
Межсетевой уровень стека TCP/IP
Межсетевой уровень стека TCP/IP (уровень 2), называемый также сетевым уровнем (по модели OSI), является стержнем всей архитектуры TCP/IP. Именно этот уровень, функции которого соответствуют сетевому уровню модели OSI, обеспечивает перенос пакетов данных в пределах всей составной сети. Протоколы межсетевого уровня поддерживают интерфейсы с вышележащим транспортным уровнем, получая от него запросы на передачу данных по составной сети. Основным протоколом межсетевого уровня является межсетевой протокол IP (Internet Protocol). Он обеспечивает продвижение пакета между подсетями - от одного пограничного маршрутизатора до другого, до тех пор, пока пакет не попадёт в сеть назначения. Протокол IP так же, как и протоколы функций коммутации глобальных сетей связи (FR, ATM и др.), устанавливается не только на оконечных пунктах (хостах), но и на всех маршрутизаторах сети. Маршрутизатор представляет собой процессор, который связывает между собой две сети (подсети). Протокол межсетевого уровня работает в режиме без установления соединения (дейтаграммный режим), в соответствии с которым он не отвечает за доставку пакета до узла назначения. При потере пакета в сети протокол IP не пытается восстановить его.
Поток байт
От приложения, протокол TCP получает поток байт, который может быть очень большим. Например, вы можете скачивать из интернета файл, который составляет несколько мегабайт или несколько гигабайт. Данные файлы приходят на транспортный уровень в виде одного большого потока байт.
p, blockquote 6,0,0,0,0 -->
p, blockquote 7,0,0,0,0 -->
В протоколе TCP поток байт делится на отдельные части, которые называются сегменты. Каждый сегмент отправляется отдельно получателю. Получатель со своей стороны, принимает сегменты, собирает их в один большой поток байт и отправляет этот поток байт приложению.
p, blockquote 8,0,0,0,0 -->
Задержка сегмента
Один из возможных вариантов, задержка сегмента. В этом случае измеряется round trip time (RTT) время движения сегмента от отправителя до получателя и обратно.
p, blockquote 32,0,0,0,0 -->
p, blockquote 33,0,0,0,0 -->
Отправитель передавая сегменты, засекает RTT, измеряет средние время, и при существенном увеличении RTT уменьшается размер окна перегрузки.
p, blockquote 34,0,0,0,0 -->
p, blockquote 35,0,0,0,0 -->
Измерение времени задержки сегмента, позволяет обнаружить перегрузку до того как она произошла, но задержка может быть вызвана не только перегрузкой, но и другими причинами. Поэтому задержка сегмента не такой надежный сигнал, как его потеря.
p, blockquote 36,0,0,0,0 -->
Другая проблема заключается в том, что когда мы используем такой сигнал о перегрузке на загруженных каналах связи, то это приводит к не справедливому распределению пропускной способности. Наш компьютер начинает уменьшать размер окна перегрузки, когда увеличивается время задержки сегмента, в то же время другие компьютеры, которые используют сигнал о перегрузке потери сегмента, продолжают увеличивать размер окна пока перегрузка не произойдет.
p, blockquote 37,0,0,0,0 -->
Решением является совместное использование двух сигналов задержки и потери сегмента, такой подход используется например, в протоколе Compound TCP реализованного компанией Microsoft.
p, blockquote 38,0,0,0,0 -->
Управление скоростью передачи в TCP
p, blockquote 13,0,1,0,0 -->
С другой стороны, если мы будем отправлять в сеть большое количество сегментов, то сеть может оказаться перегруженной, маршрутизаторы начнут отбрасывать наши сегменты, их нужно будет отправлять заново и скорость передачи данных опять окажется низкой. Таким образом нам нужно определить оптимальный размер окна, для того чтобы мы могли передавать данные по сети избегая загрузки, и приложение могло принять эти данные, и записать их в свой буфер.
p, blockquote 14,0,0,0,0 -->
Обработка ошибок
Повтор передачи
Сбой в пути
Поддерживается счетчик для числа повторов передачи по конкретному адресу получателя без подтверждения успешной доставки. Когда значение этого счетчика достигает заданного порога (конфигурационный параметр), адрес объявляется неактивным и протокол SCTP начинает использовать другой адрес для передачи блоков DATA.
Кроме того, по всем неиспользуемым (дополнительным) адресам периодически передаются специальные блоки Heartbeat и поддерживается счетчик числа блоков Heartbeat, переданных без возврата соответствующего Heartbeat Ack. Когда значение счетчика достигает заданного порога (параметр конфигурации), соответствующий адрес объявляется неактивным.
Отказ в конечной точке
Для всех адресов получателя поддерживается общий счетчик числа повторов или блоков Heartbeat, переданных удаленной точке без получения от нее соответствующего подтверждения (Ack). Когда значение счетчика достигает заданного порога (параметр конфигурации) конечная точка декларируется как недостижимая и ассоциация SCTP закрывается.
Поддержка множества потоков в SCTP
Протокол TCP работает с одним потоком данных и обеспечивает для такого потока сохранение порядка доставки байтов из пото- ка. Такой подход удобен для доставки файлов или записей, но он может приводить к дополнительным задержкам при потере информации в сети или нарушении порядка доставки пакетов. При возникновении таких ситуаций протокол TCP должен дожидаться доставки всех данных, требуемых для восстановления порядка.
Другим примером является возможность использования множества потоков для доставки multimedia-документов (например, web- страниц) в рамках одной сессии. Поскольку такие документы состоят из разнотипных объектов разных размеров, многопотоковая доставка таких компонент не требует строгой упорядоченности. Однако использование множества потоков при доставке существенно повышает для потребителей привлекательность сервиса.
В то же время транспорт в рамках одного соединения SCTP обеспечивает единый механизм управления потоком и контроля насыщения, что существенно снижает нагрузку на транспортный уровень.
Протоколы TCP/IP
Ниже приводится краткое описание протокола прикладного уровня SNMP и протокола транспортного уровня TCP архитектуры TCP/IP.
Протокол прикладного уровня SNMP
Большие сети не могут быть настроены и управляться вручную в плане изменения конфигурации сети, устранения неисправности в сети, сбора параметров о качестве обслуживания. Если в сети используется оборудование разных производителей, необходимость таких средств становится особенно необходимой. В связи с этим были разработаны стандарты сетевого управления. Одним из наиболее широко используемых является простой протокол управления сетью SNMP (Simple Network Management Protocol) [4] . Приведем краткие сведения об архитектуре сетевого управления. Система сетевого управления включает инструментальные средства для решения задач управления. При этом необходимо использование уже имеющегося оборудования путем внедрения в него дополнительных аппаратных и программных средств для управления сетью. Это программное обеспечение размещается в хостах, коммуникационных процессорах и других устройствах сети. Модель сетевого управления, используемая для SNMP состоит из следующих элементов:
- станция управления, выполняющая роль интерфейса между сетевым администратором и системой сетевого управления. Станция управления позволяет осуществить мониторинг сети и управление сетью. В этой станции имеется база данных с информацией, полученной из информационных баз всех управляемых объектов сети;
- агент управления (хосты, коммутаторы и др.), которые отвечают на запросы от станции управления. Агент обеспечивает информацией станцию и без запроса;
- агент поддерживает базу данных, именуемую MIB (база управляющей информации, Management Information Base), в которой записаны конфигурация, характеристики и состояние устройств.
Обеспечение информационной безопасности протокола SNMP
В документе RFC 2574 [6] определяется модель USM (User Security Model – модель защиты пользователя) при использовании протокола SNMP. USM разрабатывалась с целью защиты от угроз следующих типов.
Протокол транспортного уровня TCP
Логическая связь относится именно к данной паре значения портов. В процессе связи каждый объект отслеживает сегменты TCP, получаемые от другой стороны или отправленные другой стороне, для того, чтобы регулировать поток сегментов и восстанавливать утерянные или поврежденные сегменты. Стандартный номер порта однозначно идентифицирует тип приложения, однако он не может однозначно идентифицировать прикладной процесс этого приложения. Одно приложение может одновременно осуществлять несколько процессов. Поэтому прикладной процесс однозначно определяется в пределах сети и в пределах отдельного компьютера парой (IP-адрес, номер порта) и называется сокетом (socket). Логическое TCP-соединение однозначно идентифицируется парой сокетов, определенных для этого соединения двумя взаимодействующими сокетами.
При работе на хост-отправителе протокол TCP рассматривает информацию, поступающую к нему от уровня приложений, как неструктурированный поток байтов. Эти данные буферируются средствами TCP. На уровень IP из буфера «вырезаются» сегменты, к которым добавляются заголовки. В состав заголовка входят сегменты SYN и ACK, служащие для установления TCP-соединения.
Окно перегрузки в TCP
p, blockquote 10,0,0,0,0 -->
p, blockquote 11,0,0,0,0 -->
Окно перегрузки, существует на стороне отправителя, его размер рассчитывается отправителем в зависимости от того, какая нагрузка на сеть, а не от того сколько данных может принять приложение. Приложение может быть готово принять много данных, но сеть загружена, в этом случае отправлять так много данных не имеет смысла.
p, blockquote 12,0,0,0,0 -->
Медленный старт
p, blockquote 22,0,0,0,0 -->
При медленном старте размер окна увеличивается на каждое подтверждение не на 1 сегмент, а на 2, благодаря этому происходит экспоненциальное увеличение размера окна. Сначала мы отправляем один сегмент, получили подтверждение, отправляем два сегмента, получили 2 подтверждения, на каждое подтверждение отправляем по два сегмента всего 4, потом 8, потом 16 и так далее. То есть несмотря на название медленный старт, размер окна увеличивается гораздо быстрее, чем при аддитивном увеличении, мультипликативном уменьшении.
p, blockquote 23,0,0,0,0 -->
Недостаток метода заключается в том, что если произошла потеря сегмента, то размер окна уменьшается до нуля. Таким образом медленный старт быстро разгоняется, но также быстро тормозится.
p, blockquote 24,0,0,0,0 -->
Медленный старт и AIMD в TCP
В TCP используется комбинация медленного старта и аддитивного увеличения мультипликативного уменьшения. Cначала используется медленный старт, для того, чтобы быстро заполнить доступную пропускную способность канала. После того, как размер окна достиг определенного значения, порог медленного старта, происходит переход на аддитивное увеличение мультипликативное уменьшение. И дальше уже используется этот метод, размер окна увеличивается медленно, но если пришел сигнал о перегрузке, размер окна уменьшается в два раза, а не снижается до нуля.
p, blockquote 25,0,0,0,0 -->
p, blockquote 26,1,0,0,0 -->
Порог медленного старта определяется следующим образом. Сначала запускается медленный старт и работает до того, пока не поступит сигнал о перегрузке, после этого размера окна при котором пришел сигнал о перегрузке делится в два раза, и это значение выбирается порогом медленно старта. Таким образом, формируется достаточный запас размера окна, для того чтобы не произошла перегрузка, которые при аддитивном увеличении скорее всего не будет достигнут, если конечно загрузка сети останется на том же самом уровне.
p, blockquote 27,0,0,0,0 -->
p, blockquote 28,0,0,0,0 -->
Если использовать потерю сегментов в качестве сигнала и перегрузки, то TCP фактически будет работать в режиме, который ведёт к перегрузке. TCP постоянно увеличивает размер окна пока перегрузка не произойдет, причем о перегрузке TCP узнает только после того, как она произошла, поэтому предотвратить ее при такой схеме нельзя.
p, blockquote 29,0,0,0,0 -->
Другая проблема называется глобальной синхронизацией TCP и TCP global synchronization, она заключается в том, что когда на маршрутизаторе на котором произошла перегрузка заканчивается место в буфере, он отбрасывает сегменты всех отправителей.
p, blockquote 30,0,0,0,0 -->
Отправитель обнаруживает потерю сегмента, понимает что произошла перегрузка уменьшает размер окна. В TCP в отличии от Ethernet или wi-fi, не встроена схема рандомизированное задержки, поэтому все отправители после уменьшения размера окна начинают передавать данные примерно в одно и то же время. В результате на маршрутизатор опять приходит большое количество пакетов, что в свою очередь ведет к перегрузке. Для того чтобы решить эти проблемы используются другие сигналы о перегрузке, которые мы сейчас рассмотрим.
p, blockquote 31,0,0,0,0 -->
Завершение работы ассоциаций SCTP
Отметим, что протокол SCTP не поддерживает “полуоткрытых” соединений, которые могут возникать в TCP, когда одна сторона показывает другой отсутствие данных для передачи, а вторая сторона может неограниченно долго продолжать передачу данных. Протокол SCTP предполагает, что после начала процедуры shutdown обе стороны прекращают передачу новых данных через ассоциацию и требуется лишь обмен пакетами, подтверждающими прием отправленных ранее данных.
Каждый блок содержит поля типа, флагов, размера, а также значение. Управляющие блоки включают различные параметры и флаги, зависящие от типа блока. Блоки данных (DATA) включают флаг управления сегментацией и сборкой, а также параметры TSN, Stream ID, Stream Sequence Number и Payload Protocol Identifier.
Параметр Payload Protocol ID включен для обеспечения возможности расширения в новых версиях протокола. Если предположить, что функции идентификации протокола и мультиплексирования по портам в будущем перестанут играть столь важную роль, как сейчас, Payload Protocol ID будет обеспечивать идентификацию протоколов, передаваемых с помощью SCTP без использования номера порта.
Сигнал о перезагрузке
Как отправитель узнает, о том что в сети произошла перегрузка? Это достаточно сложная задача, потому что сеть может быть составной, и перегрузка может происходить не на том сегменте сети, который подключен к отправителю, а на каком-то сегменте между отправителем и получателем, который находятся достаточно далеко от того и другого.
p, blockquote 20,0,0,0,0 -->
Чаще всего на практике, в качестве сигнала перегрузки используется потеря сегмента. Считается, что сейчас каналы связи уже хорошего качества и если произошла потеря сегмента, то не из-за ошибки канала, а из-за того, что сеть перегружена, поэтому нужно уменьшить размер окна, для того чтобы избежать дальнейшей перегрузки.
p, blockquote 21,0,0,0,0 -->
Заключение
p, blockquote 52,0,0,0,0 -->
TCP использует соединение между отправителем и получателем, которое необходимо установить до того, как начнется передача данных, а после завершения передачи соединение необходимо разорвать.
p, blockquote 53,0,0,0,0 -->
p, blockquote 54,0,0,0,0 -->
p, blockquote 55,0,0,0,0 --> p, blockquote 56,0,0,0,1 -->
Содержание
Читайте также: