UNИX, осень 2008, 08 лекция (от 19 ноября)
Материал из eSyr's wiki.
- Диктофонная запись:
- диктофон в нагрудном кармане лектора
- диктофон на кафедре
 |
 |
 |
 |
 |
Содержание |
[править] Лекция
[править] Оффтоп
Лектор делится открытием, не имеющим напрямую отношения к теме лекции. Вышел новый дистрибутив AltLinux Desktop 4.1. Были нарекания к дизайнеру (трава, поврежденная тлей). Полоски с градиентом можно генерировать автоматически с помощью программы (штук 50) и выбрать лучший. С помощью какой программы можно генерировать фон разных размеров?
ImageMagick растровый. Можно сгенерировать картинку и ресайзить. Не умеет рисовать фигуры. Было бы неплохо сделать в векторном режиме, а затем генерировать нужного размера. Выбираешь количество, тип градиента.
Было предположение о GLE. GLE — язык написания простейших программ, рисующих картинки. Что-то вроде PostScript на человеческом языке. График синуса на координатной оси с подписями генерируется 4 строками. Все же он заточен под математическую работу. Интересно, чтобы были абстрактные фигуры.
Два расширения: ASCII svg, ASCII math. Позволяют публиковать на сайте картинки и математику. Первое — текстовое описание картинки. Второе — облегченный вариант латеха. Вставляем, включаем небольшой JavaScript, на экране — красивый результат. SVG хорошо работает в Firefox, для IE нужно что-то ставить.
Существует ли более-менее разумный компилятор простого svg?
Закрываем тему.
[править] Вступление
Открываем тему транспортного уровня стека протоколов TCP/IP. За последнее тысячелетие сведения сильно устарели. Если использовать литературу прошлого тысячелетия, можно знать не все.
[править] Теория
Что такое транспортный уровень? Такой уровень, когда мы хотим забыть о проблемах доставки. Под ним лежит сетевой уровень с проблемами идентификации и доставки пакета (маршрутизация). Маршрутизации две — IP и доступность больших систем. OSPF — протокол маршрутизации высокого уровня. Согласно правилу независимости уровней мы забываем о маршруте и говорим о потоке данных. Транспортный протокол оперирует потоками данных.
Во-первых, обеспечиваем надежность и целостность. Речь идет о том, что мы хотим забыть о том, что Интернет — штука ненадежная. Пакеты могут теряться, самозарождаться, портиться, множиться, последовательность пакетов может меняться местами. Мы хотим об этом не знать. На следующем уровне (прикладном) мы будем общаться либо с ненадежными данными, либо мы обеспечиваем надежность на транспортном уровне. Гарантируем, что данные не испортились и пришли все.
Другая задача состоит в том, чтобы работать с потоками данных, а не только с данными любого вида, которые отправляются и получаются. Идея в том, что когда несколько сеансов передачи данных, с точки зрения IP это одни и те же пакеты, с одним отправителем и получателем. Различные сеансы, потоки данных должны различаться между собой. Задача — управление потоками. Не только различать, но и управлять качеством потока.
Если есть очень мощный компьютер, подключенный к скоростной сети, а получатель — слабый компьютер с медленным подключением, может получиться следующая ситуация. Отправитель отправляет в большом количестве, отправил первый гигабайт, а получатель получил первые 10 килобайт. Хорошо иметь информацию о передаче. Может быть высокий процент потерь. Если плохое качество среды, нужно уменьшать размер пакета. Чем меньше пакет, тем меньше шансов, что он попортится.
Задача проверки потока, управления потоками — их различения, подбор оптимального режима работы.
Важным фактором является то, что начиная с интерфейсного уровня сети — сети без гарантированного времени передачи данных. Один из способов реализации такой: мы для начала потребуем от нашего получателя, чтобы он нам ответил. Мы посылаем пакет на деревню дедушке, а деревни нет (или деревня есть, а дедушки нет). Когда посылаем пакет, нужно убедиться, что получатель существует.
[править] Установка соединения
Передача с установлением соединения и без него. Первое в реальном времени, второе — нет. Перед передачей данных убеждаемся, что получатель существует. Что это гарантирует? То, что мы передаем, может куда-то попасть. Если адресат не ответил, с большой вероятностью то, что мы отправляем, никуда не попадет. Если же ответил, скорее всего, попадет.
[править] Подтверждение
В ответе можно передавать дополнительные вещи. Уже возникает некая двунаправленность. Посылаем запрос и отвечаем, что соединение установлено. Один передает, и другой. Мы можем эксплуатировать это и сделать подтверждение. Получатель сообщает, что данные приняты и нормально, или приняты, но не такие, или через некоторое время приходит ответ, что данные не получены. Или адресат ничего не сообщает, или не принял, или то, что ответил, не пришло, или еще что-то случилось.
Каждая транзакция пакета сопровождается подтверждением получения, причем корректного. Отслеживание состояния канала. Внутри каждого пакета будет контрольная сумма, ее будут проверять.
[править] Упорядочивание
Мы должны перенумеровать все пакеты данных. Отправитель нумерует, а получатель должен уметь отслеживать порядок, например, он получил не второй, а третий пакет. Должен сообщить отправителю: «Чувак, гони второй пакет».
[править] Целостность
Для отслеживания целостности нужно говорить, не повредился ли пакет. Для решения этих задач сущестуют некоторые методы. Метод вычисления контрольных сумм.
Контрольная сумма (избыточная информация).
[править] Балансировка
Отслеживание состояния канала (балансировка канала). Балансировка канала — алгоритм скользящего окна, медленный старт. Прежде чем скажем о реализованности, давайте посмотрим, какие из инструментов пригодны не всегда при передаче данных из одного места в другое.
Вычисление контрольной суммы никогда не вредно, по мнению лектора. Разве что совсем не хватает вычислительной мощности. Широковещательная трансляция — пример. Одними подтверждениями можно привести сервер в глубокое изумление. При подтверждениях с повторной передачей изумление еще более глубокое. Установление соединения с каждым из абонентов может сделать передачу невозможной — кто-то будет выключен. Если не требуется упорядочивать все данные от начала до конца, то упорядочивание может быть лишней штукой. С упорядочиванием не совсем ясно. Балансировка тоже вещь туманная. Балансировка нагрузки даже если мы хотим делать широковещание — в общем-то, вещь полезная.
[править] TCP и UDP
[править] Сравнение
В TCP все 5 пунктов реализованы:
- соединение
- подтверждение
- упорядочивание
- контрольная сумма
- балансировка
В UDP — только контрольная сумма, да и то можно отключать.
Что касается UDP, все достаточно понятно. Единственное ограничение — чтобы пакет не рассыпался по дороге. Получит или не получит адресат сообщение — неизвестно.
[править] Идентификация потоков
Прежде чем перейти к рассмотрению TCP, решим частную задачу. На уровне разделения потоков потоки должны иметь разные идентификаторы. Помимо IP получателя и отправителя должен существовать идентификатор потока.
По причинам отчасти историческим, отчасти того, как это реализовано, их три. В UDP — cond. Аппаратная абстракция — есть процессор, устройства ввода-вывода, каждое устройство — к одному порту. Когда отправляем датаграмму с компьютера, есть порт отправителя и порт получателя. Эта четвертка (два IP, два порта) идентифицирует поток данных. Есть всякие хитрости, с этим связанные, например, IP может быть не равен тому, который используется. Главное, что четвертка уникально идентифицирует поток данных.
В случае протокола TCP, обеспечивающего все, ситуация более сложная. У лектора была мысль, что в UDP порт отправителя лишний. Отправление обратно можно сделать на прикладном уровне, т.к. ответ не обязателен. В TCP же соединение двунаправленное соединение между отправителем и получателем.
Уже на этапе установления соединения получатель отвечает «Да, я жив». В ответе должен быть указан порт отправителя. В течение всего сеанса четверка идентифицирует поток данных.
[править] Упорядочивание сообщений
Наша задача не только различать потоки, но и упорядочивать. На уровне TCP есть SeqN1 (Sequence Number), SeqN2. Универсальный способ контролировать пропажу или размножение пакетов. Номер в последовательности. Одновременно и номер пакета, и размер пакета. Алгоритм простой: когда отправитель хочет установить соединение, он посылает получателю запрос (SYN), генерирует случайный SeqN1. Получатель отвечает SYN, ACK. Отправитель подтверждает (ACK), что с ним можно связываться и передавать данные. Данные размера S, передается SeqN1 + S. Дальше обычный обмен пакетами.
Пресловутый номер последовательности, с одной стороны, всегда растет, с той же стороны, он растет на размер принятых данных. Три транзакции при передаче данных отличаются от остальных. Отправитель и получатель обмениваются информацией о том, что они хотят соединяться. Если одна транзакция не прошла, и по какой-то причине отправитель отправляет следующий пакет, то получатель видит, что был еще один пакет, но он куда-то делся. На сайте Википедии есть ссылка на красивую демку, показывающую алгоритм. В конце один из абонентов скажет FIN. Трехуровневое рукопожатие. В некоторых случаях их 4. В реальности четыре сеанса передачи данных — запрос-ответ, запрос-ответ. В силу двунаправленности TCP можно совместить ответ и запрос.
Двустороннесть позволяет подтверждать. Возможны различные ошибки, требования повторной передачи.
[править] Балансировка нагрузки. Окна TCP
В алгоритме не предусмотрено ничего для балансировки канала. А она была бы не плоха, потому что пакет долго ходит по Интернету, размер одновременно передаваемого куска был как можно больше. Пока это не перегружает получателя и пакет нормально идет по сети.
Задачи балансировки — приноравливаться к состоянию канала и к состоянию получателя. Поскольку передача всегда синхронная, большую роль играет размер передаваемого пакета. Если увеличивать размер пакета, увеличивается вероятность передачи. Чем качественнее канал, тем лучше.
Примем на веру следующее утверждение — в TCP есть возможность не дожидаться подтверждения на пакет и отправлять их без подтверждения пачкой. Количество пакетов пачкой зависит от размера окна. Размер окна вначале условно равен 1 пакету. Получатель говорит, можно 100. Отправитель отправляет 2, потом 4, пока получатель не скажет «Хватит», или пока не пойдут ошибки. Определение окна — дело ОС, точнее, подсистемы TCP/IP. Какой реально размер окна, готового принять. Определяется из многих параметров.
Начинается с одного пакета. Всякий раз говорим, какой размер окна. Отправитель каждый раз должен проверять, не забил ли он окно получателя. У него есть информация о окне получателя, и о том, сколько пакетов в окне получатель уже подтвердил. Если пришли подтверждения, окно сдвинулось. Или из 100 пакетов ни одного подтверждения не пришло, сколько ни передали, они пока висят. Вычисляем разницу между подтвержденными пакетами и размере окна.
Идея скользящего окна в следующем. Есть буфер на N пакетов. Обе стороны принимающие, обе стороны отправители. Кто первый начал соединение, и кто ответил. На стороне получателя (половина соединения) есть окно в N пакетов. Туда приходят пакеты. Пришел первый пакет. Окно сдвигается. Допустим, пришел второй пакет. Окно не сдвигается. Поскольку пришел второй пакет, мы подтверждаем, но по-другому. Пришел пакет, в окно влезает, но он не первый, давай первый. Если отправитель получил подтверждение, что окно отъехало, можно отправлять дальше. Если получил подтверждение не первого пакета, нужно перепосылать. В случае, если приняты все подтверждения, кроме первого, первый просто пропал. Его нужно послать еще раз. Окно не сдвинется, пока первый пакет не придет. Окно может забиться, и по приходу первого сдвинется сразу далеко.
Подтверждения — тоже пакеты, они могут пропадать. Допустим, одно подтверждение пропало (2 пакет). Ничего не произойдет, если придет подтверждение 3 пакета. Будем считать, что Интернет — штука ненадежная. Реально получить подтверждение 20 пакета, и до этого все в порядке. Не обязательно получать подтверждение всех пакетов. Если первый пакет не получен, подтверждение будет другого вида.
Главное — получить подтверждение, отвечающее за всех. В английской Википедии есть демонстрация. Можно устанавливать процент потерянных пакетов. Таймаут. Лектор рекомендует всем погонять эту флэшку.
Что еще можно придумать к скользящему окну? Две дополнительные заморочки, но они не реализованы в TCP. Одна — Go Back — сдвигаем окно обратно. Сложность в том, что мы можем предсказать, что придут пакеты и сдвинуть окно. В некоторых случаях позволяет улучшить качество. Вторая штука — Selective Reject — мы говорим, какой конкретно пакет нужно перепослать, и перепосылаем именно его. Это все либо не реализовано, либо бессмысленно в TCP.
[править] Что лучше?
Немного разговора о том, когда применять TCP, когда UDP. TCP — синхронный протокол. Если рисовать графики, большую роль играет скорость передачи. В случае TCP мы имеем систему «пакет-подтверждение». В случае UDP можно передавать и передавать. Скорость может быть больше. Но возникают проблемы при происхождении ошибок.
В случае, если произошла ошибка на UDP, с этим разбирается приложение. Сколько приложение будет разбираться, неизвестно. В конце концов, оно пошлет на прикладном уровне пакет серверу «У меня что-то со вторым пакетом». В случае, если цена ошибки высока, скорость передачи по TCP с возникающими ошибками быстрее. Обычно обмен данными идет по TCP.
Можно запрограммировать TCP на уровне приложения, а потом плюнуть и воспользоваться TCP.
Реально UDP используется, когда весь обмен умещается в одной датаграмме. Пример — DNS-запрос. Еще при широковещательной передаче. Может быть так, что UDP лучше, а редкие ошибки проще обрабатывать на прикладном уровне. Еще пример — NFS на высоконадежной сети.
Изменения на самом деле не сильные, реально было принято еще несколько транспортных протоколов. В последний раз лектор этому учился в прошлом тысячелетии. Во многих ситуациях, например, широковещания, TCP использовать невозможно. Но неплохо было бы воспользоваться некоторыми свойствами, которых нет в UDP. Например, упорядоченность. Свойство балансировки в последнее время становится особенно важным, ввиду распространения IP-телефонии и пр. Обеспечить если не гарантированное, то ожидаемое время доставки пакета.
[править] Другие протоколы
Есть 4 протокола, найденные автором в Википедии. Реализация всего этого имеется, использоваться начнется, когда у всех будет IPv6. Нормальный QoS можно сделать только там, в IPv4 нельзя, там только один байт.
[править] RSVP (Resource Reservation Protocol)
Протокол управляющий, предназначенный, чтобы разгрести место для последующей передачи данных в высоким QoS. Для передачи видео должно быть место в памяти для этих пакетов. Естественно, TCP обработает как надо, UDP не обработает. Прежде, чем прокладывать дорогу для видеопотока, неплохо бы сообщить по дороге, что сейчас пойдет видеотрафик. Это управляющий протокол, но говорит о потоках. В чем хорошая идея? Если наше устройство поддерживает, можно надеяться, что проблемы возникнут только при сбоях аппаратуры, а ресурсы зарезервированы (или маршрутизатор скажет, что ресурсов не хватает).
[править] ECN
Как TCP справляется с ситуацией, когда отправитель отправляет слишком много? Просто выбрасывает. Пока не докатится окошко, отправитель будет слать и слать. Мы пытаемся предотвратить перегрузку сети пакетами. Нужно сказать отправителю, чтобы он сокращал поток. Принимая во внимание особенности протокола ECN, можно разработать еще пару протоколов, которые могут как-то взаимодействовать.
[править] DCCP (Datagram Conversion Control Protocol)
Происходит управление (контроль за переполнением потока датаграмм). Что-то более хитрое, чем UDP. Должна быть информация о том, что ЕСN поддерживается. Голый UDP не может воспользоваться ECN. Никакого упорядочения в случае DCCP нет, есть понятие потока как такового. Чтобы регулировать напряженность потока, используется ECN. Контроль за переполнением.
[править] SCTP
Более развесистый протокол. Не гибрид TCP и UDP. Работает с потоком байт. Не все программы хотят, чтобы им передавали поток байт от начала до конца.
Запрос на веб-страницу. Неважно, когда скачаются картинки, первыми или вторыми. Картинки могут скачиваться в любом порядке. Картинка не может быть одним пакетом. Внутри сообщения порядок важен. Внутри одного соединения может быть несколько потоков данных (внутри одного потока).
[править] Заключение
Все это было подготовлено для IPv6. Эта штука более гибкая. Все эти описанные вещи давно есть в RFC, реализованы в большинстве сетевых ядер. Проблема в том, что не все железяки умеют.
Мы можем переходить к прикладному уровню.
[править] Конспект eSyr
Транспортный уровень
В этом тысяч. сведения, отн. к прошлому тысяч., сильно устарели.
Начнём с теории. Что такое транс. уровень? Это такое место в TCP/IP, где мы хотим забыть о проблемах собст. доставки, (ибо ниже лежит IP, где реш. задачи идент. абонентов и дост. пакетов. Первая задача — адресация, вторая — маршрутизация. Марш. бывает две: по маскам, и глобальная) и хотим разг. о потоках данных. С этой т. з. транс. протокол ... речь идёт о потоках данных.
Задача транс. уровня. Как уже было сказано, мы зотим перейти на такой ур. абс., когда мы работаем с потоками данных. Во-первых, обесп. надёжность и целостность. Пакеты могут теряться, множиться, менять порядок, и мы хотим про это вообще не знать. На след. уровне, прикладном, либо мы общаемся с данными как с ненадёжными, либо мы должны обесп., что отпр. в дырку шлёт, получатель получает, и получает столько же и такие же, как и отпр.
Вторая задача трансп. уровня: работать именно с потоками данных, а не с данными любого вида, которые отпр. и принимаются. Пример с секундными стрелками и повидлом. Идея том, что когда идёт неск. одинаковых сеансов между двумя отчками, это один. сеансы. С точки зрения трансп. уровня это должны быть разные потоки данных. На самом деле, в эту же кат. входит не только необх. разл. эти потоки, но и упр. качеством этого потока: если с одной тсороны очень высокоскоростной компьютер со скоростным аплинком, а с другой тсороны — компьютер с медленным. И неплохо было бы орг. канал так, чтобы отпр. знал, сколько он должен получателю скармливать. Кроме того, при битом линке большие пакеты плохо передаются.
То, что пойдёт дальше — вариант реш. этих задач. В других сетях может быть другое решение. Например, в TCP/IP считается, что сеть без гарант. времени перед. данных.
Один из способов обесп. этого безобразия такой: мы потр. от нашего полусателя, чтобы он вообще нам ответил. Мы посылаем пакет на деревню дедушке, а выясняется, что ни деревни нет, ни дедушки. И надо эту задачу решить: если мы посылаем данные, то их должны принимать. То есть перед началом передачи орг. соединение. Перед передачей данных перед. удост., что есть получатель. Это гарантирует, что то, что мы передаём, куда-то может попасть. Во-первых, если соед. не уст., то с больщой вер. передавать данные бесполезно. Кроме того, при получ. получается ответ. То есть, канал двунапр. А раз он двунапр., то мы можем проэксп. это и затребовать подтверждение — если мы посылаем пакет, то потребуем подтв. получения.
Ещё одно свойство — упорядочивание. Если говорим о потоке данных, то должны нумеровать все потоки данных, и отпр. их нумерует, а получ. отслеж. их порядок. Для собл. целостности потока необх. учитвывать также упорядоч. пакетов.
Для обесп. целостности исп. контрольная сумма.
Для упр. потоками исп. балансировка нагрузки. Отсюда скольз. окно и быстрый старт.
Мы выпис. нек-рые инстр., которые эти задачи решают. Посмотрим, какие из инстр. пригодны не всегда?
- Вычисл. контр. суммы — вещь никогда не вредная
- Подтв. неприменимы в случае широковещания. То же и про соеднения.
- Если не треб. упорядоч. все данные от начала до конца (поток нарезан на незав. кусочки), то и упорядоч. тоже, возм., не нужно
- Балансировка, с одной стороны, отъедает ширину канала, с другой стороны, без ней грустно
Исторически было две реализ., UDP и TCP. В TCP все свойства, в UDP только Контр. сумма, и то не всегда.
UDP, User Datagramm Protocol. Каждый udp-пакет — сообщ. самодостаточное. При этом получит оно или нет, неизвестно.
Прежде, чем перейти к рассм. TCP, решим одну частную задачу, без которой тяжело орг. какой-бы то ни было транспорт.
У нас есть задача разд. потоков. Для этого src/dst IP не хватает. Поэтому помимо них должно быть магическое "идент. потока". По ист. причинам таких идент. три: ... . В UDP таких идент. два, оно наз. порт. Порт воспр. некую апп. абстракцию. При передаче указ. не только IP, но и порт как отпр., так и получателя. Эта чествёрка идентифиц. поток данных, который в случае UDP явл. одна датаграмма. При этом порт. отпр. избыточен.
В случае TCP оба порта необх. уже на этапе соединения. По этой причине в TCP обяз. должна сущ. эта четвёрка, и она идент. поток одонзнач. Кроме того, потоки надо упорядочивать. Номер в посл. отвечает за целостность потока. Он одновр. и номер, и размер. Алг. очень простой: при попытке соед. source отправляет syn-запрос и геенр. случайный seqn. Второй генерирует ack и генерирует свой seqn, потом первый посылает syn ack и к seqn1 прибавялет размер сообщения.
... (хендшейк) ...
Что касается самих подтв. Подтв. могут быть не только отн. того, что данные пришли норм., но и отн. таймаута и посврежд. Тогда нужно затр. повторную передачу. Что тут не нравится: тут не предусм. ровно ничего для балансир. канала. Она актуальна, когда пакеты ходят долго и размер передавемого куска был как можно больше. Как можно больше, пока оно не начяинает перегружать получателя и пока оно не начнёт портится. Нужно изобр. какой-то механизм, чтобы чем кач. канал, тем асинхр. может быть эта передача. К этому и перейдём. Это алг. скольз. окна. Он, кстати, описан отдельно и реализ. в нек. других протоколах.
Для начала посм., что такое медл. старт. Примем на веру след. утв: в TCP есть возм. не дожид. подтв. на один конкр. пакет и отпр. их сразу пачками. То,сколько их мы можем отпр., зависит от размера окна. Размер окна передаётся внутри подтв. и озн. след.: изн. размер. окна, условно, равен одному пакету. Получ. говорит, могу 100, отпр. говорит, 2, и так, пока не упрётся или пока е возн. ошибки. Опред. размера окна, который мы модем принять — дело стека TCP/IP. Отпр. каждый раз должен проверять, не забил ли он окно получ, это легко, так как у него есть инф. о размере окна получ. и о том, какие пакеты он получил.
Тут речь о медл. старте, но тут уже есть слова о том что окно движ.
В чём идея скольз. окна? Есть буфер на n пакетов. Пришёл первый пакет. Буфер сдвигается. Допустим, пришёл не первый пакет, а, допустим, второй. Окно никуда не сдвиг. Поск. первый не пришёл, отпр. волшебный ack, где говорится, что пакет принят, а первого нет. Отпр. ловит подтв. Ели он видит, что первый принят, то он понимает, что у него окно отъехало и тожк сдвигает его.
Но подтв. тоже могут пропадать. Если потерялось подтвр. второго пакета, а про третьего пришлоо норм. подтв., то считаем, что второй пакет получен. Если бы 2 не был получен, то у 3, 4 подтв. были бы другого вида.
Здесь лектор замолк., поск. идея понятна. Здесь лектор уже ссылается на статью в википедии про TCP.
Какие есть недост. у скольз. окна?
Когнда можно исп. TCP, когда UDP?
Даже не см. на скольз. окно, то большую роль, играет скорость передачи, и в зав. от того, польз. TCP или UDP, у нас могут быть разные выцигрыши и проигрыши на ст. системы.
В принципе UDP быстрее, но пока не начнут появл. ошибки.
Может показ., что синхр. скорость перед. медленнее, но это зав. от ...
Именно поэтому обычный обмен данными обычно по UDP.
Второй вариант это широковещание.
[править] Изм. в TCP/IP в этом тысячелетии.
Было принято ещё неск. трансп. протоколов.
Главная проблема в след.: во многих ситуациях, напр., broadcast|multicast, тем не менее, было ьбы непл. восп. нек. св-вами, которых нет в udp. Например, св-во упорядочивания. И своёство баланс. Баланс. становится важным в посл. время, поск. появилось много разных потоковых сервисов.
Что имеется из принятого в RFC:
Реализ. имеется, исп. начнётся, когда все будут исп. ipv6, ибо это и разраб. вокруг ipv6. В первую очередь, потому что там можно орг. нормальный QoS.
Для начала, протокол упр. уровня. Resource Reservation Protocol (RSVP). Предн. для того, чтобы разгр. место для передаи с высоким QoS. Напр., если мы передаём видео, то должно быть в маррутизаторах место под эти пакеты. Это прот. упр., но трансп. уровня. RFC 2205. QoS, трали-вали. В чём идея: если устр. поддерживает, мы можем не то, что забывать о том, что интернет без гарант. времени доставки, но проблемы возн. по вине аппаратуры.
Ещё одна проблема, которая всегда возн. при преедаче данных — проблема балансировки, невозн. переполнений и затыков. Для этого есть протокол ECN (Explicit Conguestion Notofication). Допустим, идёт чуть ли не UDP. Как ведёт себя TCP, если получ. не может принять данные? Он их просто выбрасывает. И пока не докатится окошко, отпр. будет их фигачить. Проблема в том, что мы пытаемся предотв. ситуацию появл. слишком большого кол. пакетов путём увел. кол. пакетов. Поэтому, согл. протоколу ECN, мы можемп прямо внутри соед. упр. скоростью пердачи данных.
Принимая во внимание ECN, можно разраб. ещё пару протоколов, можно разраб. ещё пару протоколов, которые орг. массовую рассылку без собл. всех правил TCP. Напр., DCCP. Отпр. ведётся по правилам UDP, но ведётся контроль переполнения. В особ., если есть отд. реализ. способ сигн. о Cong... . Никакого упор. в случае DCCP нет. Есть понятие потока как такового, и для того, чтобы напр. этого потока рег., польз. ECN. То есть, это такой слегка сдвинутый в сторону TCP UDP.
Ещё более разв. протокол, который объед. TCP и UDP, есть SCTP, Stream ... ... Protocol. TCP выстр. все байты в ряд. Довольно многие протоколы хотят, чтобы была правильная посл. сообщений. То есть, с одной стороны, должны следить за потоками данных, более того, можно пересылать неск. потоков в рамках одного соединения. При этом соверш. неважно, когда скач. картинки. Но порядок байтов в картинке важен. Эта штука более гибкая.
Лектор хочет только добавить, что все эти штуки есть в RFC, реализ. в подавл. числе сетевых ядер, проблема в том, что не все железяки это умеют, а дост. встретиьт одну, чтобы всем стало нехорошо.
|
|
