TCP/IP (компьютерное)
Aug. 23rd, 2004 10:01 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
avva1. А могли ведь, наверное (подумалось мне как-то недавно) внести в 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 мы не переходим. В каком состоянии вообще всё это находится?
О, да кстати там и поле 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 мы не переходим. В каком состоянии вообще всё это находится?
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2004-08-24 12:26 pm (UTC)no subject
Date: 2004-08-24 12:36 pm (UTC)RFC1644 до сих пор - experimental, поэтому никто его в firewalls и не имплементирует.
no subject
Date: 2004-08-24 02:24 pm (UTC)Другими словами, все "разумные" firewalls плюют на стандарт :) Поскольку в стандарте четко сказано, что следует делать с неизвестными options - игнорировать.
И кстати - я не слышал и с трудом могу себе представить какую-либо атаку, основанную на опциях TCP. Может быть, Вы знаете?
no subject
Date: 2004-08-24 03:00 pm (UTC)Это стандарт для end systems (RFC-1123, да?), а не для firewalls. Хороший подоход к security - не пропускать то, чего не понимаете. Потому что если пускать всё, о чёи firewall не имеет ни малейшего понятия, то изрядная доля этого непонятного окажется атаками. Как говорит один мой старый приятель Рэнди Буш - я бы хотел, чтобы мои конкуренты себе такие файрволлы ставили :)
И кстати - я не слышал и с трудом могу себе представить какую-либо атаку, основанную на опциях TCP. Может быть, Вы знаете?
У меня фантазия куда как лучше :) Кроме того, как человек, который провёл достаточно времени, копаясь в ядрах разных систем, я могу только спросить - а ошибки в TCP стэках, пакетных фильтрах, NAT-ах и проч. Вы можете себе представить? Их там есть. Их там есть много. Особенно в местах, которые почти никто никогда не использует. Старое исследование (97) от Верна Паксона (http://www.lisoleg.net/lisoleg/network/vp-tcpanaly-sigcomm97.pdf) наглядно показало, что даже в широко распространённых коммерческих TCP стэках полно проблем при работе в минимальном, стандартном режиме. Я как-то не верю, что ситуация улучшилась с тех пор (по качеству современные системы всё более напоминают помойку из-за неудержимого стремления добавлять всё больше и больше разных финтифлюшек).