Pull to refresh

Comments 20

Спасибо, хорошая статья.

К сожалению, SCTP очень слабо распространяется в WEB, несмотря на все плюшки, его основная ниша — это телекоммуникации (SIGTRAN).
UFO just landed and posted this here
Бизнес, бизнес. Ввели вы IPv6 на день раньше конкурента Васи — и половина ваших клиентов утекла к нему, потому что ваш сайт не открывается. Кто захочет первым подставиться?
UFO just landed and posted this here
Настоящий бизнес не ждёт пассивно пока кто-то первым подставится, а сам проводит исследования и работает с вендорами чтобы те пофиксили свои глюки. Пример: доклад Tore Anderson на недавней конференции RIPE61 — ripe61.ripe.net/presentations/162-ripe61.pdf
никуда они не пойдут, у Васи не хватит белых адресов ipv4
Вася как-нибудь обойдётся одним IP-адресом, хорошим лоад-балансингом и разными доменами для разных сервисов. Зато маршрут у него всегда будет работать.
У Васи сдохнут железки от нагрузки на NAT
Мне кажеться, что вместо натов придется фаерволы городить, с жуткими правилами.
UFO just landed and posted this here
UFO just landed and posted this here
Сканирование сети на предмет _хостов_, а не открытых портов. TCP/UDP-портов как было 65535, так и осталось :) Если вы знаете адрес жертвы, то разницы никакой.
UFO just landed and posted this here
Вам еще долго прийдется тащить IPv6 -> IPv4 NAT иначе вам будет доступна только очень ограниченная часть интернета.
Интересно, а кто сказал, что мы постепенно переходим с TCP на SCTP? В статье IPv6 противопоставляется IPv4 точно также, как и SCTP TCP. Лучше добавить, что тем же макаром можно обеспечить discovery поддержки со стороны сервера альтернативных протоколов без ущерба для производительности.
Да, на SCTP, можно считать, что никто пока не переходит, кроме отдельных приложений.
А знаете, почему? :) Потому что в самой распространенной операционной системе какие-либо нативные средства для работы с SCTP появились только в .NET 4 — туда включили sctpDrv. Тем не менее, постепенно переводить софт на SCTP не мешало бы.
Потому что большинству приложений просто не нужны фичи sctp вроде сохранения границ сообщения, «многопоточности», мультихоуминга. Всё, что нужно — это двунаправленный поток байтов с гарантией сохранения порядка байтов и надёжности доставки. Проблемы незащищённости соединения, конечно, есть, но это немного другой разговор.
Мне кажется, мультихоуминг ни одному приложению не повредит :)
Да и отсутствие ошибок типа HOLB, а также SYN-flood атак тоже явно будет плюсом.
> Потому что большинству приложений просто не нужны фичи sctp вроде сохранения границ сообщения

Почти любой протокол application уровня поверх TCP занимается тем, что образует свой механизм по разделению байтового потока TCP на PDU. Так что я бы на вашем месте поостерегся бы делать такие утверждения.
Sign up to leave a comment.

Articles

Change theme settings