Здравствуйте, Ovl, Вы писали:
Ovl>сравнивать модель tcp и osi некорректно, ибо они суть одно и тоже, только в osi — 7 уровней, а в tcp — ну 4 примерно
На самом деле, не совсем. ICMP не очень ложится в простую модель, где каждый слой строится над предыдущими. С одной стороны, ICMP использует IP в качестве транспорта, и в этом смысле параллелен TCP и UDP. С другой — он слишком тесно дружит с IP, чтобы считать его слоем над IP.
Забавно при этом, что строго по модели OSI ни одного живого семейства сетевых протоколов так и не было реализованно. Видимо, не все, что хорошо смотрится на бумажке, столь же хорошо работает в жизни.
Здравствуйте, vdimas, Вы писали:
V>Еще раз для тех, кто в танке. Речь о том, что во-первых, многие IP-протоколы "намертво" завязаны друг на друга, от чего и существуют объективные трудности в развитии протоколов (т.е. по уровню связанности дизайну основных IP-протоколов можно ставить двойку), во-вторых, прикладные сетевые программы, использующие IP, так же намертво привязаны именно к этому протоколу, по той же самой причине — отсутствия четкого деления на уровни. Пример с DNS и АПИ осей относительно IP — это лишь наглядная демонстрация, к какому бреду приводит некачественная архитектура сетевых протоколов.
Вы можете привести пример конкретной проблемы, которая не дает TCP/IP развиваться именно по причине чрезмерной связанности?
Вообще, если честно, Вы производите впечатление студента, которому на прошлой неделе рассказали про 7-уровневую модель OSI, и он проникся. В TCP/IP есть масса реальных проблем, но про них Вы, видимо, не в курсе, и цепляетесь к совершенно воображаемым проблемам. Тем не менее, из всего множества практически реализованный сетевых протоколов семейство TCP/IP по-видимому самое удачное. О чем, в частности, свидетельствует его живучесть.
Здравствуйте, vdimas, Вы писали:
V>Хоть я не автор, но мне конкретно не нравится IP и UDP поверх которого TCP живет. А кривая сущность под названием UDP- и TCP- порт — вообще верх безграмотности проектирования протокола. Это же надо было заложить столько ограничений прямо в базе.
Ну и в чём тут ограничения? (кроме количества бит на порт — 16 действительно мало для больших нагрузок)
V>А реализация NAT для TCP — технология которая доказанно теоретически работает с ошибками (ибо склеивает сообщения по номеру, но этот номер теоретически случайно может совпасть у сообщений двух абонентов внутренней сети), т.е. технология работает не благодаря продуманности, а скорее вопреки... За счет "авось" и дополнительных вычислений контрольных сумм.
Это где Вы такую странную реализацию NAT нашли??? Или речь про дефрагментацию перед трансляцией? Ну так во-1) TCP обычно сочетается с DF и PMTUD (вот уж где костыль), так что дефрагментация крайне редка, во-2) там не только id учитьывается.
V>Кстати, берем банальное туннелирование. Сколько раз при передаче пакета просчитывается его контрольная сумма на каждом приемнике/передатчике? Раз шесть? Ну не смешно ли? :xz:
С чего это шесть раз??? По-моему, Вас совсем не туда потянуло. Обычно — только два раза (контроль на приёме и генерация на передаче), только для внешнего заголовка.
V>А эти RFC по вкладыванию IP в другие протолы — как гимн кривой архитектуре. Ибо, если бы IP-семейство соответсвовало 7-миуровневой модели OSI, то этой тонны дополнительных стандартов можно было бы избежать.
Чушь и воронятина (tm). Ну-ка, расскажите, как в строгой модели OSI мне сделать PPP поверх SSH (зачем — ну вот надо было, получать интернет в крайне тяжёлых условиях). А никак — там идея туннелирования отсутствует как класс.
И "несоответствие" TCP/IP модели OSI имеет массу преимуществ. Например, BGP — управляет 3-м уровнем, а в реализации формально можно найти даже 7-й. В OSI надо было бы вместо аккуратной слойки IP — TCP — BGP изобретать локальный велосипед (что и делается).
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, Аноним, Вы писали:
А>>всем привет. А>>как динозавры подвисли на TCP/UDP. А>>неужели про SCTP никто не знает?
N>Ну, во-первых, его ещё нет в винде (AFAIK).
Есть, кажется, юзерландная реализация в виде библиотеки.
N> Во-вторых — я бы не сказал, что он чем-то глобально лучше и полезнее.
Есть там полезных вещей:
1) multistreaming с общим на все потоки flow and congestion control, но независимой ретрансмиссией
2) multihoming — load sharing'а нет, но есть failover, что уже хорошо.
3) message oriented — удобно
4) мелкая, но важная, приятность — отсутствие TIME_WAIT, как класса
5) расширяемость за счет структурированности на chunks, которые представляют собой TLV тройки; реакция на неизвестные типы chunk'ов программируется старшим битом типа: дропнуть и перейти к следующему chunk'у в пакете, дропнуть с ошибкой в ответ и перейти к следуюшейму чанку, дропнуть и перейти к следующему пакету, дропнуть с ошибкой и перейти к следующему пакету.
7) возможна partial reliability — при посылке сообщения можно указать время его жизни, и, если сообщение не было ack'нуто в течение этого времени, отправитель не будет его (или его куски) ретрансмитить, а пошлет вместо этого skip.
Ну и еще всякое, которое я на память не перечислю.
Нетч, что за идея откопать эту стюардессу? Я от этого треда еще полтора года назад плакал. Вот теперь всплакнул еще раз.
V>>А реализация NAT для TCP — технология которая доказанно теоретически работает с ошибками (ибо склеивает сообщения по номеру, но этот номер теоретически случайно может совпасть у сообщений двух абонентов внутренней сети), т.е. технология работает не благодаря продуманности, а скорее вопреки... За счет "авось" и дополнительных вычислений контрольных сумм.
N>Это где Вы такую странную реализацию NAT нашли??? Или речь про дефрагментацию перед трансляцией? Ну так во-1) TCP обычно сочетается с DF и PMTUD (вот уж где костыль), так что дефрагментация крайне редка, во-2) там не только id учитьывается.
Очевидно, там учитывается не только id. Но неправильная сборка фрагментов — реальность, к сожалению. Конечно, к NAT'у это не имеет непосредственного отношения, но файрволы, рандомизирующие id, и NAT (вернее PAT) способны увеличить вероятность такой проблемы.
Здравствуйте, Изя Рнет, Вы писали:
ИР>Здравствуйте, netch80, Вы писали:
ИР>Нетч, что за идея откопать эту стюардессу? Я от этого треда еще полтора года назад плакал. Вот теперь всплакнул еще раз.
Это не я. Я шёл по вчерашнему MainList.aspx и смотрел интересные заголовки. А некрофилией занялся кто-то из моих предшественников.
Когда заметил старые даты — остановился.
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, Изя Рнет, Вы писали:
ИР>>Здравствуйте, netch80, Вы писали:
ИР>>Нетч, что за идея откопать эту стюардессу? Я от этого треда еще полтора года назад плакал. Вот теперь всплакнул еще раз.
N>Это не я. Я шёл по вчерашнему MainList.aspx и смотрел интересные заголовки. А некрофилией занялся кто-то из моих предшественников. N>Когда заметил старые даты — остановился.
А. Сорри тогда за наезд.
Впрочем, можем продолжить за SCTP, например. Вдруг что-то интересное удастся обсудить, а не OSIRM, не к ночи будь помянута.
N>Чушь и воронятина (tm). Ну-ка, расскажите, как в строгой модели OSI мне сделать PPP поверх SSH (зачем — ну вот надо было, получать интернет в крайне тяжёлых условиях). А никак — там идея туннелирования отсутствует как класс.
Туннелирование — это костыль сам по себе, связан с отсутствием "родного" способа построения виртуальных сетей в IP. Более подробно в этой ветке я уже объяснял. Шифрование потока данных — отдельная тема, просто в свалили в одну выгребную яму всё подряд. Я уже делал замечание, что безопасность сейчас завязана на ИМЕНА хостов, в то время как протоколы работают по номерам хостов (IP-адресам). VPN — это классическая выгребная яма, где перемешалось всё, с целью построения костыля для достижения банального, с т.з. OSI сценария работы.
N>И "несоответствие" TCP/IP модели OSI имеет массу преимуществ. Например, BGP — управляет 3-м уровнем, а в реализации формально можно найти даже 7-й. В OSI надо было бы вместо аккуратной слойки IP — TCP — BGP изобретать локальный велосипед (что и делается).
Чушь. 7-ми уровневая архитектура — это просто 7 ролей. Реально вкладывать каналы один в другого можно практически как угодно, т.к. вышестоящим элементам однофигственно, как реализованы нижестоящие. Пример ATM — это просто классика, где уже давно всё изобретено и даны ответы на многие вопросы (далеко не все, но очень многие). Если бы разработчики IP хотя бы малость поизучали другие протоколы, прежде чем лепить своё, то такого результата можно было бы избежать.
Здравствуйте, vdimas, Вы писали:
V>Чушь. 7-ми уровневая архитектура — это просто 7 ролей. Реально вкладывать каналы один в другого можно практически как угодно, т.к. вышестоящим элементам однофигственно, как реализованы нижестоящие. Пример ATM — это просто классика, где уже давно всё изобретено и даны ответы на многие вопросы (далеко не все, но очень многие). Если бы разработчики IP хотя бы малость поизучали другие протоколы, прежде чем лепить своё, то такого результата можно было бы избежать.
Ну то есть за два года, прошедших с этого спора, ты так ничему и не научился. Похвально.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pzz, Вы писали:
V>> А кривая сущность под названием UDP- и TCP- порт — вообще верх безграмотности проектирования протокола. Это же надо было заложить столько ограничений прямо в базе. Pzz>Напротив, это очень мудрая идея. Порты (отправителя и получателя) занимают в пакете всего 4 байта. Если бы там были, не знаю, имена, процентов 10% траффика съедалось бы только под них (пакеты не такие уж и большие).
Фигня вопрос.
Можно легко сделать так чтобы с одной стороны колличество портов было не ограничено, а с другой стороны в подавляющем большинстве случаев ограничиться теми же 4мя байтами.
Просто берем старший бит очередных 2х байт и смотрим если 0 то номер порта закончился. Если 1 то смотрим следующие 2 байта.
Один черт порты с номерами больше 32767 используют редко.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Pzz, Вы писали:
V>>> А кривая сущность под названием UDP- и TCP- порт — вообще верх безграмотности проектирования протокола. Это же надо было заложить столько ограничений прямо в базе. Pzz>>Напротив, это очень мудрая идея. Порты (отправителя и получателя) занимают в пакете всего 4 байта. Если бы там были, не знаю, имена, процентов 10% траффика съедалось бы только под них (пакеты не такие уж и большие). WH>Фигня вопрос. WH>Можно легко сделать так чтобы с одной стороны колличество портов было не ограничено, а с другой стороны в подавляющем большинстве случаев ограничиться теми же 4мя байтами. WH>Просто берем старший бит очередных 2х байт и смотрим если 0 то номер порта закончился. Если 1 то смотрим следующие 2 байта. WH>Один черт порты с номерами больше 32767 используют редко.
Порты с номерами больше 32767 используют как раз весьма часто: в юниксах есть стандартный приём использования в разных целях разных диапазонов, и даже не заказывая явно номер порта можно запросить, в каком диапазоне он будет выдан. Например, нижний — 600-1023 (предназначен для автоаллокации, когда клиент явно хочет указать наличие у него прав суперпользователя — используется в ряде протоколов), lдефолтный — 1024-5000, верхний — 49152-65535. По умолчанию, например, для современных FreeBSD автовыдача идёт именно из верхнего диапазона.
С другой стороны, применений, где 16 бит недостаточно — на сейчас мало, в основном это сверхзагруженные сервера на протоколах со спецификой, где нельзя со стороны сервера использовать один и тот же порт (даже навскидку не скажу, какие это протоколы, кроме разве что голосовых потоков VoIP). Видимо, их настолько мало, что для SCTP предпочли сохранять совместимость с 16-битным sockaddr_in::sin_port, чем ломать её.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, netch80, Вы писали:
N>>Чушь и воронятина (tm). Ну-ка, расскажите, как в строгой модели OSI мне сделать PPP поверх SSH (зачем — ну вот надо было, получать интернет в крайне тяжёлых условиях). А никак — там идея туннелирования отсутствует как класс.
V>Туннелирование — это костыль сам по себе, связан с отсутствием "родного" способа построения виртуальных сетей в IP.
Родных средств там достаточно, но туннелирование — не только IP. Например, оно может связывать на уровне Ethernet (L2) два broadcast segment в один, я знаю, где это построили потому что нужно. Туннелировать можно RS-232 или даже USB. По которому опять побежит что-то другое. Туннелирование есть на L2 (L2TP, QinQ, а главное — MPLS во всех его видах и разновидностях). В общем, весь мир давно за туннелирование, только vdimas почему-то думает, что он один шагает в ногу.
V> Более подробно в этой ветке я уже объяснял. Шифрование потока данных — отдельная тема, просто в свалили в одну выгребную яму всё подряд. Я уже делал замечание, что безопасность сейчас завязана на ИМЕНА хостов, в то время как протоколы работают по номерам хостов (IP-адресам).
Ну вот и хорошо — будет 10 фронтэндов одного сайта с одним именем с общим сертификатом, но на разных IP. В чём проблема-то?
V> VPN — это классическая выгребная яма, где перемешалось всё, с целью построения костыля для достижения банального, с т.з. OSI сценария работы.
Расскажите, как именно "банально" с точки зрения OSI мне связать (пусть, предположим, везде OSI протоколы) две сети на разных континентах в один broadcast segment, как будто между ними стоит просто свич. Прошу сразу детали реализации, а не общие слова.
N>>И "несоответствие" TCP/IP модели OSI имеет массу преимуществ. Например, BGP — управляет 3-м уровнем, а в реализации формально можно найти даже 7-й. В OSI надо было бы вместо аккуратной слойки IP — TCP — BGP изобретать локальный велосипед (что и делается).
V>Чушь. 7-ми уровневая архитектура — это просто 7 ролей.
То-то многие протоколы, как SMTP, предусматривают роли одновременно нескольких уровней OSI.
V> Реально вкладывать каналы один в другого можно практически как угодно, т.к. вышестоящим элементам однофигственно, как реализованы нижестоящие.
Ну вот в случае IP оно тоже "однофигственно" — по крайней мере при соблюдении базовых условий (если реализация претендует на роль L2, она не должна заниматься надёжностью доставки кадров; и ещё несколько подобных условий).
V> Пример ATM — это просто классика, где уже давно всё изобретено и даны ответы на многие вопросы (далеко не все, но очень многие).
Главный вопрос, который они ответили — как реализовать компромисс так, чтобы было плохо обеим сторонам. Это я про размер ячейки.
V> Если бы разработчики IP хотя бы малость поизучали другие протоколы, прежде чем лепить своё, то такого результата можно было бы избежать.
Здравствуйте, netch80, Вы писали:
N>Порты с номерами больше 32767 используют как раз весьма часто: в юниксах есть стандартный приём использования в разных целях разных диапазонов, и даже не заказывая явно номер порта можно запросить, в каком диапазоне он будет выдан. Например, нижний — 600-1023 (предназначен для автоаллокации, когда клиент явно хочет указать наличие у него прав суперпользователя — используется в ряде протоколов), lдефолтный — 1024-5000, верхний — 49152-65535. По умолчанию, например, для современных FreeBSD автовыдача идёт именно из верхнего диапазона.
Тогда бы просто значения для диапозонов были бы другие и все.
В худшем случае было бы не 4 байта, а 6. Что много потеряли если бы размер пакета увиличился бы на 2 байта?
В любом случае я ничего менять не предлогаю.
Просто рассуждаю на тему сферопротокола в вакууме.
И если рассуждать до конца то ИМХО порты вобще нужно отправить в топку.
Достаточно просто сделать адреса иерархическими с копрессией как я расказал.
Тогда скажем город получил бы адрес типа 12452.643132
Домовая сеть или там датацентр 12452.643132.435734, комп в сети 12452.643132.435734.545632, программа на компе 12452.643132.435734.545632.46232
Ну были бы сейчас адреса не 6 байт, а 10-12. Много бы потеряли?
За то при такой схеме проблемы из серии кончились адреса небыло бы никогда. Ибо эти адреса масштабируются на любом уровне.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Nevidim, Вы писали:
N>Вот собственно сабж. Написать новый транспортный протокол.
А зачем? Есть, например, http://en.wikipedia.org/wiki/SCTP — там решены множество проблем TCP. И SCTP уже прекрасно поддерживается Линуксом и кучей других операционок.
Вообще, мне лично в TCP больше всего не нравится отсутствие нормальной системы коррекции ошибок. При потере одного пакета — приходится перепосылать все уже отправленые пакеты.
Здравствуйте, netch80, Вы писали:
N>С другой стороны, применений, где 16 бит недостаточно — на сейчас мало, в основном это сверхзагруженные сервера на протоколах со спецификой, где нельзя со стороны сервера использовать один и тот же порт (даже навскидку не скажу, какие это протоколы, кроме разве что голосовых потоков VoIP).
Действительно, таких ситуаций не много. В реальности на это можно наступить, когда одна и та же машина открывает много соединений к другой — при этом из 5-tuple 4 поля фиксированы. Например, http proxy в позе фронтэнда ходит к http серверу. Если учесть, что соединения будут отлеживаться в TIME_WAIT, то 65К соединений может и не хватить.
N>Видимо, их настолько мало, что для SCTP предпочли сохранять совместимость с 16-битным sockaddr_in::sin_port, чем ломать её.
SCTP эту проблему обходит иначе: во-первых, много SCTP associations (это то, к чему относятся порты) между парой машин особого смысла не имеют, поскольку внутри ассоциаций есть стримы, а во-вторых, у SCTP нет TIME_WAIT и похожих явлений.
Здравствуйте, Cyberax, Вы писали:
C>Вообще, мне лично в TCP больше всего не нравится отсутствие нормальной системы коррекции ошибок. При потере одного пакета — приходится перепосылать все уже отправленые пакеты.
Что за волшебное средство отбрасывает на пятнадцать лет назад?
2018 TCP Selective Acknowledgment Options. M. Mathis, J. Mahdavi, S.
Floyd, A. Romanow. October 1996. (Format: TXT=25671 bytes) (Obsoletes
RFC1072) (Status: PROPOSED STANDARD)
Сейчас сложно найти стек, где его не поддерживают.
C>Остальное... Ну в общем, мелочи жизни.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, netch80, Вы писали:
N>>Порты с номерами больше 32767 используют как раз весьма часто: в юниксах есть стандартный приём использования в разных целях разных диапазонов, и даже не заказывая явно номер порта можно запросить, в каком диапазоне он будет выдан. Например, нижний — 600-1023 (предназначен для автоаллокации, когда клиент явно хочет указать наличие у него прав суперпользователя — используется в ряде протоколов), lдефолтный — 1024-5000, верхний — 49152-65535. По умолчанию, например, для современных FreeBSD автовыдача идёт именно из верхнего диапазона. WH>Тогда бы просто значения для диапозонов были бы другие и все. WH>В худшем случае было бы не 4 байта, а 6. Что много потеряли если бы размер пакета увиличился бы на 2 байта?
Да ничего. Я лично за 32-битную статику. И 128-битные sequence numbers. Затрат на них немного, а пользы — дофига.
WH>В любом случае я ничего менять не предлогаю. WH>Просто рассуждаю на тему сферопротокола в вакууме.
WH>И если рассуждать до конца то ИМХО порты вобще нужно отправить в топку. WH>Достаточно просто сделать адреса иерархическими с копрессией как я расказал. WH>Тогда скажем город получил бы адрес типа 12452.643132 WH>Домовая сеть или там датацентр 12452.643132.435734, комп в сети 12452.643132.435734.545632, программа на компе 12452.643132.435734.545632.46232 WH>Ну были бы сейчас адреса не 6 байт, а 10-12. Много бы потеряли?
Известная тема. Идеи про переменную длину адреса витают уже пятьдесят лет (и, кстати, про OSI — в X.25 она таки переменная). Это даже в IPv6 применили — см. routing header — но как почти всё там, через пятую точку. Надо было не 128-битные части переставлять, а 32-битные, и не фиксировать их распределение — тогда действительно получились бы адреса переменной длины. Интернет мог бы спокойно работать с тем, что видно на его глобальном уровне — или 32, или 64, в зависимости от вкусовщины — а локальные сети спокойно бы себе строили дополнительные уровни, если им это нужно, не грузя глобальные сети.
N>2018 TCP Selective Acknowledgment Options. M. Mathis, J. Mahdavi, S.
N> Floyd, A. Romanow. October 1996. (Format: TXT=25671 bytes) (Obsoletes
N> RFC1072) (Status: PROPOSED STANDARD)
N>Сейчас сложно найти стек, где его не поддерживают.
А вот я такой стек нашёл
Буду дописывать.
C>>Остальное... Ну в общем, мелочи жизни. N>Ну не совсем мелочи.
Учитывая, что сейчас больше всего популярен HTTP с ещё большими глюками — мелочи
Здравствуйте, Cyberax, Вы писали:
N>>Вот собственно сабж. Написать новый транспортный протокол. C>А зачем? Есть, например, http://en.wikipedia.org/wiki/SCTP — там решены множество проблем TCP. И SCTP уже прекрасно поддерживается Линуксом и кучей других операционок.
Не совсем осилил сочетание двух характеристик этого протокола:
1) Connection oriented — Yes
2) Preserve message boundary — Yes
Зачем на принимающей стороне знать какими частями передающая сторона посылала данные? Этак и ответы на вопросы типа "не могу принять пакет по TCP" перестанут взывать гневные отповеди "пакетов нет!". Или я неправильно понял термин?
И до кучи: а зачем может понадобиться "Unordered delivery", которая тоже "Yes".
