>>за себя). А SCTP валит всё в одну кучу. Можно, конечно, сказать, что модель OSI
>>устарела, но она, по крайней мере, обеспечивает ясность и взаимозаменяемость
>>компонентов. Впрочем, это оффтопик.
>
>Она не устарела, просто ее все-равно никто никогда не соблюдает с точностью
>до буквы.Ее НИГДЕ нет именно в точно том виде который описан
>"на бумаге".Плюс-минус лапоть в сторону ничего такого не меняет.На то и
>модель чтобы быть абстракцией.Ориентир - да.Руководство к действию?Не была им и
>не будет. Ну, положим, с первыми тремя уровнями всё более-менее хорошо:). Ибо сильно с железом связаны, там не разгуляешься. Ну а дальше — чисто софтварные приколы пошли, вот и изгаляются кто во что горазд. Программисты — народ, которому его идея важнее чужих, знаю по себе. ;)
>>Эта фича любопытная, да.
>
>Вообще протокол достаточно любопытный.И я могу понять почему его сделали.Потому что у
>TCP и у UDP есть свои проблемы.Их можно как-то через жопу
>заворкэраундить в конкретном применении но если такой протокол получит распотранение -
>тогда множеству людей не придется изобретать (с переменным успехом) свои велосипеды
>в очередной раз.
Да не так уж много проблем. Даже в самом оптимистичном (из реальных) для SCTP случае UDP и TCP всё равно будут быстрее SCTP, чисто исходя из соотношения навороченности протоколов, а, значит, у них своя ниша останется. ;)
>>Там применён, например, cookie — по сути, аналогичная схема используется в грамотных
>>фаерволах, работающих с TCP. Это именно защитная мера.
>
>Это защитная мера чисто от протокольной слабины характерной для TCP (большая часть
>протоколов семейства TCP\IP и того что по ним гуляет делалась делались
>во времена когда хакеры вообще не рассматривались как угроза, со всеми
>вытекающими).Просто протокол сделаный с учетом известных пролетов.Нормальная практика вполне - зачем
>на одни грабли вставать дважды?По сути тоже работа над ошибками как
>и затыкание дыр :)
Суть не меняется: это защитная мера. :)
>>А вот то, что шифрование в него всё же [НЕ] стали вносить,
>
>А его и не планировали, зачем оно транспортнику?Вон в IPSEC внесли.Так его
>в итоге почти никто не юзает - получилось монстрило выносящее мозг
>админам.
Зависит от реализации. В OpenBSD поднять IPSec "с нуля" в первый раз, обладая исключительно теоретической подготовокой, заняло меньше часа. Во фряхе есть толковое руководство, думаю, цифры те же. В Linux и Windows не пробовал, и желания нет, если честно. :)
>Даже в винде с их гуйным эдитором весь мозг сломаешь это
>настраивать.
Не люблю гуй за то, что потом всё равно приходится от него отвыкать: в консоли реально быстрее…
>В остальных и вовсе тот еще брейнфак.Кому как а мне проще
>какойнить опенвпн прокинуть - там все просто, понятно, на фаерах\натах не
>застревает и работает везде и без сношаний мозга :).
IPSec в моём случае работает в ядре и поэтому заметно более производительный.
>Хотя опять же
>с точки зрения OSI VPN-тунель поверх UDP или TCP вместо уровня
>под ним наверное не ахти как круто но мне то что?Зато
>оно в таком виде работает через фаерволы и наты.А вот те
>кто пытаются делать это уровнем ниже - вечно застревают...
Ну, про причины широкого распространения NAT я рассказывать не буду. ;) А фаерволу ничто не мешает пропускать VPN-траффик между указанными узлами.
И это, предлагаю завязывать, а то мы уже совсем в оффтопик какой-то пошли и вообще отыгрываем ведущих передачи «современные сети для самых маленьких» :)
