TCP/IP (компьютерное)

[avva]

1. А могли ведь, наверное (подумалось мне как-то недавно) внести в TCP встроенную возможность передавать много параллельных потоков по одному каналу. Самым простым и примитивным способом: ввести в заголовок TCP поле “номер потока”, размером в байт, например (256 потоков).
О, да кстати там и поле reserved в 6 бит есть, вижу (64 потока). Дать к номеру потока доступ на уровне сокетов или других интерфейсов с помощью соответствующих расширенных функций. И пусть те аппликации, кому удобно, используют. По умолчанию всегда будет один поток, нулевой.

Зачем это нужно и почему просто не открыть несколько TCP-соединений? Несколько соединений могут легко рассинхронизироваться и вообще пойти через разные раутеры даже. Несколько потоков в одном соединении будут ползти одним потоком с точки зрения самого TCP.

Предположим, мне нужно транслировать фильм по сети, чтобы на втором конце его могли проигрывать в realtime. Что сейчас делают? Используют формат, который мультиплексирует видео- и аудио-поток вместе, так, чтобы они были синхронизированы в общем потоке. Попеременно идут фреймы видео-аудио-видео-аудио (ясно, что удельный вес видео больше). Например, формат AVI, или MPEG, или новые OGM и Matroska. Но чем плохо было бы просто пустить фильм по TCP, пометив видео и аудио как разные потоки? Посылающая программа следила бы за синхронизацией, а сам протокол TCP обеспечивал бы тот факт, что они не рассинхронизируются по пути. И не нужен отдельный файловый формат.

Ещё, наверное, всякие примеры можно придумать.

P.S. Забыл упомянуть, что, собственно, весьма примитивная поддержка этого дела в TCP есть — но только двух потоков: обычного и "срочного" (с помощью urgent pointer). Этого, ясно, недостаточно, да и семантика тут чуть другая. Я вообще-то не знаю, пользуется ли кто-то серьёзно этими самыми urgent-данными в TCP (кажется, telnet пользуется для чего-то там — и больше никого не знаю).

2. Наивный немного вопрос: а что там вообще происходит с IPv6, кто-то следит за этим делом? А то я уже, наверное, лет восемь слышу разговоры о том, что у нас вот-вот кончатся 32-битные адреса, и что мы вот-вот перейдём все на IPv6. Тем временем адреса вроде бы не кончаются (или кончаются всё-таки?) и на IPv6 мы не переходим. В каком состоянии вообще всё это находится?

Comments

[mkay422.livejournal.com]

Строго говоря, это уже будет протокол более высокого уровня (app.-level protocol). С другой стороны, такие протоколы уже есть реализованные (прячу хитрую ухмылку).

Необходимо также учитывать, что открытие множественных ТСР-сессий может быть предпочтительнее в ряде ситуаций, т.к. каждая сессия регулирует свой размер окна независимо от других.

[avva.livejournal.com]

Строго говоря, это уже будет протокол более высокого уровня

Сегодня - да, но я как раз предлагаю "спустить" эту возможность на transport layer, путём внесения её в сам протокол TCP.

Необходимо также учитывать, что открытие множественных ТСР-сессий может быть предпочтительнее в ряде ситуаций, т.к. каждая сессия регулирует свой размер окна независимо от других.

Да, это понятно.

[ullr.livejournal.com]

Это не Application, but Session layer в соответствии с OSI моделью

[averros.livejournal.com]

гммм... я тут тоже отмечусь... чтобы совсем уж полным составом :)

[cmm.livejournal.com]

> уже, наверное, лет восемь слышу разговоры о том, что у нас вот-вот кончатся 32-битные адреса, и что мы вот-вот перейдём все на IPv6. Тем временем адреса вроде бы не кончаются (или кончаются всё-таки?)

рынок регулировал-регулировал, и нарегулировал ситуацию, в которой куча народу сидит за NAT-router'ами и не жужжит.  IPv6 может особо не торопиться, насколько я понимаю.
перспектива тоже не видится мне ужасной: NAT-routing, насколько я опять же понимаю, допускает многоуровневое вложение.

[avva.livejournal.com]

Ах, какой противный рынок, тормозит наш технический прогресс ;)

[dimrub.livejournal.com]

многоуровневое вложение - да, конечно допускает. Проблемы будут у нас когда вовсю начнет внедряться сотовые 3-го поколения, где каждый телефон - IP-device. Как там с NAT - не совсем понятно. При роуминге, например, чей IP у них будет? Родной - или принимающей сети?

[xfyre.livejournal.com]

http://www.icann.org/announcements/announcement-20jul04.htm

[xfyre.livejournal.com]

в статье в компьютерре, через которую я и нашел эту ссылку, также говорится, что ICANN планирует полностью перевести сеть на IPv6 через 20 лет. откуда они взяли эту информацию - не знаю.

[avva.livejournal.com]

Мне это понравилось: "This next generation version of the Internet Protocol provides trillions more addresses than the IPv4 system that is in use by most networks today."

Т.е. технически это верно, конечно, "триллионы" новых адресов. Очень-очень много триллионов... ;)

[dbg.livejournal.com]

1. Изобретен и кое-где уже реализован SCTP (RFC 2960, RFC 3286)
2. В довольно медленном. Адреса действительно не кончаются, да в IPv6 есть нерешенных проблем.

[avva.livejournal.com]

1. Ух, какая интересная штука! спасибо, читаю ;)

[auto194419.livejournal.com]

про ipv6 - http://www.technologyreview.com/articles/print_version/wo_garfinkel010704.asp

а всё живо из-за проклятого NAT'а. если бы не он, давно бы адреса кончились.

[trurle.livejournal.com]

А почему, собственно, мультиплексирование потока данных должно поддерживаться на уровне IP пакета если вполне можно сделать на уровне транспортного протокола?

[avva.livejournal.com]

Я и предлагаю - на уровне транспортного протокола TCP, а вовсе не на уровнр IP-пакета. Ты невнимательно читаешь.

[growler.livejournal.com]

SCTP? (http://www.ietf.org/rfc/rfc2960.txt)

[avva.livejournal.com]

Ага, уже подсказали. Выглядит аппетитно.

[ktyz.livejournal.com]

слишком мало холодильников с выходом в тырнет сделали,
вот и весь вопрос.

[http://users.livejournal.com/mak_/]

ничего-ничего, не взяли холодильниками - возьмут стиральными машинами. все еще впереди.

Что означает .UPDATE.?
Программы стирки вашего стирального аппарата определяются
программным обеспечением.
Новые виды текстиля и моющих средств могут потребовать в
будущем изменения программ стирки. Тогда программное
обеспечение может быть в большинстве случаев изменено в
соответствии с этими требованиями. Чтобы произвести это
изменение (провести .update.) обращайтесь, пожалуйста, в
авторизованные изготовителем сервисные центры. Там же вы
сможете узнать расценки на изменение программ.

[dtmf-1.livejournal.com]

http://www.ieee.org

[(Anonymous)]

Оставляя в стороне вопрос о необходимости мультеплексирования TCP-потока.
Заворачивание фильма в TCP в принципе неправильно. И дважды неправильно заорачивание в общий поток изображения и звука.

Дело в том, что TCP не предназначен для передачи реалтаймового потока данных (которыми является аудио/видео). При передачи таких потоков недопустимы паузы и задержки -- если у нас потерялся пакет, но следует про него забыть и ни в коем случае не прерывать передачу остального потока дыбы найти потерянный фрагмент. Поэтому VoIP работает по UDP. Точнее RTP.

Неправильно замешивать видео и звук в общий поток -- у звука достаточно фиксированная и относительно небольшая полоса и он очень чувствителен к задержкам. Чуть что не так -- начинаются булькания, заикания.

Видео же, наоборот, занимает довольно большую полосу, но при этом гораздо менее чувствительно к задержкам и пропаданиям.

Поэтому эти два потока на роутерах при передаче имеет смысл передавать с разными дисциплинами. Но в любом случае -- лучше независимо.

[avva.livejournal.com]

Спасибо за столь подробное объяснение.

[oblomov-jerusal.livejournal.com]

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

[(Anonymous)]

Неправда.
Начнем с того, что при передаче в одном потоке механизм для синхронизации _все равно нужен_. Потому как видео -- дискретно-покадровое, а звук -- непрерывный.
в RTP на каждом пакете есть временная метка (64-бит, в формате NTP) -- проблем с синхронизацией никаких нету.

...да забыли про овраги...

[averros.livejournal.com]

Мультиплексирование нескольких потоков в одной TCP-сессии - идея замечательная, но, к сожалению, предложенный способ работать не будет :)

Причина очень проста - если получатель одного из потоков тормозит, то все остальные тоже будут блокированы. Так что реально нужно делать не только framing с идентификаторами потоков, но и раздельный flow control для каждого потока (так чтобы flow contol в самом TCP никогда не тормозил передачу).

Кроме того, нужна поддержка для создания и уничтожения потоков.

На практике ещё нужно делать enforcement of fairness между потоками - скажем, используя Fair Queueing. Иначе один поток может запросто монополизировать ресурсы сети (это невозможно если для каждого потока используется своё TCP-соединение - TCP's cooperative congestion control делит пропускную способность канала примерно поровну между TCP-соединениями (при условии достаточных оклн на приёме и передаче, и примерно одинаковой задержки из конца в конец).

а что там вообще происходит с IPv6

А ничего особо не происходит - никому он не нужен, кроме производителей router-ов. Чтобы, эта, можно было продать новые железки.

Re: ...да забыли про овраги...

[igorbor.livejournal.com]

Ну вот, прямо изо рта вынули :)

А по поводу перечисления Вами всего, что нужно добавить в мультиплексирование для того, чтобы это все работало - так это все уже сделано. TCP называется :)

[igorbor.livejournal.com]

Вообще-то основной недостаток мультиплексирования - что потоки начинают жутко зависеть друг от друга. К примеру, если смешать потоки для двух разных аппликаций и потом одна из них вдруг станет читать медленнее (или, не приведи господи, вообще помрет) - то ее данные, ожидая своего прочтения в канале, будут тормозить второй поток.

[avva.livejournal.com]

Ага, но мне показалось, что иногда это как раз может быть достоинством (как в обсуждаемом примере мультиплексирования потоков, составляющих один фильм). Впрочем, аноним мне объяснил некоторые значительные недостатки такого подхода.

[msh.livejournal.com]

IPv6 в Штатах/Европе оказались не очень нужны - ибо и интернет перестал сильно расти, и когда перешли на classless откопались огромные резервы, да и private networks теперь повсеместно.

А вот в Японии все гораздо бодрее, например, я участвовал в проекте переноса кое-чего на IPv6 в связи с тем. что одна японская мобильная сеть целиком переводит всех абонентов на IPv6

[averros.livejournal.com]

В общем-то classless (точнее, CIDR :) было прикручено как средство для уменьшения размера routing tables в бэкбонах. Памяти у cisco AGS/+ не хватало на полную таблицу... а 7000 только появились, и были глючны страшно.

Я помню массу криков о не-портабельности адресов, которая стала необходимой для аггрегации маршрутов (весь смысл CIDR :)

[--oblya.livejournal.com]

> Несколько соединений могут легко рассинхронизироваться и вообще пойти
> через разные раутеры даже.

Почему "даже" ? И одно соединение может идти через разные раутеры

[sobaker.livejournal.com]

Только что хотел сделать аналогичное замечание :)

Вообще идея мне кажется несколько надуманной, особенно мысль о подмене AVI множественными потоками в TCP.

TCP непригоден для передачи media

[sysprg.livejournal.com]

Про SCTP Вам уже написали, про вредность связывания аудио и видео - тоже: человек плохо реагирует на проблемы со звуком (рывки, пропадания звука), но легко переносит пропуск нескольких видеокадров. Добавлю, что для передачи кино и звука в реальном времени обычно используют не TCP, а RTP (протокол прикладного уровня, бегущий поверх UDP). Дело в том, что все современные аудио- и видеокодеки умеют восстанавливаться после потери отдельных кадров, а некоторые из них даже интерполируют данные для эмуляции потерянных кадров, поэтому они мало чувствительны к небольшим потерям. Кроме того, для RTP разработаны эффективные схемы FEC (Forward Error Correction) для восстановления информации в случае потери нескольких кадров в потоке. Таким образом, для аудио- и видеоданных ЗАДЕРЖКИ на приемнике намного страшнее, чем пропадание отдельных кадров. Иногда задержки страшнее, чем даже потеря 20-30% информации. TCP же приостанавливает работу столкнувшись с пропажей даже одного-единственного байта, до тех пор, пока этот байт не будет доставлен. Поэтому, TCP принципиально не подходит для передачи мультимедийной информации в реальном времени.

IPv6 в действии

[brumka.livejournal.com]

Около года назад мне пришлось столкнуться с IPv6 у клиента.

Оказывается, что крупные провайдеры, а в моём случае это был Акамай уже давно им пользуются. Однако, только для внутренних целей. Вся внутренняя инфраструктура уже пару лет как перешла на IPv6. В разных странах у них стоят так называемые edge servers которые служат раутерами IPv6 <-> IPv4. A для чего им нужен v6? Дело в том, что так как там реализована поддержка приоритетов на траффик, им (Акамаю) удобно приоретизировать траффик глобальных клиентов, чьи оффисы разбросаны по всем континентам.

Для клиентов Акамая эта услуга, естественно, "прозрачна".