Допустим, есть TCP-соединение, одна сторона посылает данные, другая принимает.
Пусть посылатель послал полное окно. Получатель данные принял, подтвердил, но программа данные не вычитала, поэтому окно осталось нулевого размера.
Теперь, позже, программа вычитала все данные одним махом, и получатель послал window update. Который потерялся в сети.
Теперь у посылателя нет никаких причин теребить соединение, потому что все, что он послал, подтверждено, а новых данных он послать не может, потому что считает, что окно нулевого размера. И у получателя тоже нет никаких причин что-либо перепосылать.
И что, из-за одного потерянного пакета они так и будут куковать до ближайшего keep alive, или до бесконечности, если keep alive выключен? Или я чего-то не понимаю?
По-моему, это всё крайне кривые решения. Если делать большие периоды перепосылки проб, восстановление потока может проходить крайне медленно, а если делать маленькие, это будет грузить сеть ерундой.
То есть формально решение есть, но по сути оно кривое до ужаса.
Почему бы не сделать опцию расширения типа window confirm?
Тут, кстати, есть ещё одна засада. Window size scaling устанавливается при старте соединения. Пусть были тогда уже запрошены какие-то супербуфера типа 16MB, это значит, scale 2^8 == 256, или даже выше. Это значит, что любое значение окна от 0 до 255 байт будет передано как 0, и только начиная от 256 байт будет передано как 1 (что с учётом масштаба даст 256). Это ровно из дословного понимания RFC1323 (или 7323, эта часть не менялась). Если буфера сохраняют свой исходный размер, это даст просто грубоватую реакцию, но если буфер ужать после коннекта, может заклинить безо всяких сетевых потерь. (Я бы просто не давал делать это ужатие, если соединение установилось.)
Здравствуйте, netch80, Вы писали:
N>По-моему, это всё крайне кривые решения. Если делать большие периоды перепосылки проб, восстановление потока может проходить крайне медленно, а если делать маленькие, это будет грузить сеть ерундой. N>То есть формально решение есть, но по сути оно кривое до ужаса. N>Почему бы не сделать опцию расширения типа window confirm?
Тут вообще всё просто — у тебя же с машины же идет трафик по TCP? Насколько в этом трафике скорость меньше от максимальной из-за указанной проблемы?
Я не готов так с ходу защищать TCP, но за ним вообще то стоит куча научных работ за много лет. Сам протокол работает поверх очень разных каналов от 64k-10g, locallink-спутник. И вот так с наскоку говорить, что TCP плох... Если начать всё разбирать, то получается ровно наоборот.
Здравствуйте, m2l, Вы писали:
N>>По-моему, это всё крайне кривые решения. Если делать большие периоды перепосылки проб, восстановление потока может проходить крайне медленно, а если делать маленькие, это будет грузить сеть ерундой. N>>То есть формально решение есть, но по сути оно кривое до ужаса. N>>Почему бы не сделать опцию расширения типа window confirm? m2l>Тут вообще всё просто — у тебя же с машины же идет трафик по TCP? Насколько в этом трафике скорость меньше от максимальной из-за указанной проблемы?
Вопрос некорректный, потому что описанные проблемы вообще никак не влияют на вопрос _максимальной_ скорости.
А вот на что влияют — это на применения, где нормально по много секунд не видеть никакой активности, но затем она нужна без задержек.
Например, в FIX, где один из типичных шаблонов — тишина, затем взрыв активности, затем снова тишина, ввели обязательные heartbeat сообщения и таймаут их прихода. Работает "подпорка" необходимостью послать реальные данные.
И всё равно народ после этого молится на отсутствие потерь на каналах, потому что потери дают жуткие торможения.
m2l>Я не готов так с ходу защищать TCP, но за ним вообще то стоит куча научных работ за много лет. Сам протокол работает поверх очень разных каналов от 64k-10g, locallink-спутник. И вот так с наскоку говорить, что TCP плох... Если начать всё разбирать, то получается ровно наоборот.
"Если начать всё разбирать", TCP очень во многом плох или неадекватен:
Каждый второй индусокитаец полагает, что посланное одним send() точно так же будет получено одним recv(), и объяснить этим людям, в чём они ошибаются, очень часто невозможно, а иногда и видишь протоколы, где просто невозможно определить границы сообщений. Если бы при его разработке знали, что будет такое количество кретинов, мы бы имели SCTP с самого начала. (Как и сделано, на самом деле, в IPX стеке в виде SPX и в X.25 в виде своих аналогов.)
По нему нельзя пускать синхронный поток (как голос/видео в реальном времени), малейшие потери будут приводить к локальным переполнениям, будут поступать неактуальные данные. Для этого используется UDP, реже SCTP.
Его неуправляемая политика торможения для непереполнения сети неадекватна в целом ряде применений, поэтому есть разработки типа "TCP for data centers", где эта политика отключена или заметно изменена.
На его логику управления потоком приходится наворачивать слой защиты от лавинных эффектов и эффектов синхронных колебаний (посмотрите историю алгоритмов Reno, Vegas, New Reno и тому подобных). Именно этой теме посвящено подавляющее количество упомянутых вами "научных работ". Да, эта тематика сама по себе очень ценная, но она не меняет основ (и не привязана по сути к TCP).
32-битные sequence numbers были хороши на старте Интернета, но сейчас этого откровенно недостаточно и для очень быстрых соединений (работает принципиальное ограничение IP, что max_ttl=255, а значит, поток быстрее 4GB/255 ~= 17MB/sec уже просто незаконен), и для защиты от спуфинга (слишком высока вероятность подделки). Против первого выкручиваются костылём в виде опции таймстампа. Против второго работает разве что TLS, но это защита данных в соединении, а не работоспособности самого соединения.
16-битных номеров портов недостаточно для крупных датацентров, для толстых фронтэнд-прокси, выкручиваются выдачей множественных IP адресов таким системам.
Многие стартовые концепции или признаны неработающими (urgent pointer), или отменены за неадекватностью (роль флага PSH).
Ну а про восстановление окна уже поговорили в этом треде, не буду повторяться.
Это всё не значит, что TCP не работает. Он очевидно работает, иначе бы я не смог прочитать Ваше сообщение и отправить своё Но по-нормальному нужно любую разработку в области протоколов редизайнить с нуля через 30 лет. Для TCP этот момент давно пришёл.
Здравствуйте, netch80, Вы писали:
N>Почему бы не сделать опцию расширения типа window confirm?
По-хорошему, если бы в TCP механизм надежной доставки умел работать не только для пользовательских данных, но и для служебных сообщений, то эта проблема решалась бы легко. Просто надо было бы апдейт окна, при определенных условиях (например, когда окно было нулевым, или при существенном расширении) передавать надежным путем, а не полагаться, что в потоке когда-нибудь само дойдет.
Но это трудно сделать без существенной реорганизации протокола, потому что сейчас все, что есть в пакете, кроме заколовка, является собственностью пользователя, а так пришлось бы различать. Что превратило бы TCP в SCTP
N>Тут, кстати, есть ещё одна засада. Window size scaling устанавливается при старте соединения. Пусть были тогда уже запрошены какие-то супербуфера типа 16MB, это значит, scale 2^8 == 256, или даже выше. Это значит, что любое значение окна от 0 до 255 байт будет передано как 0, и только начиная от 256 байт будет передано как 1 (что с учётом масштаба даст 256). Это ровно из дословного понимания RFC1323 (или 7323, эта часть не менялась). Если буфера сохраняют свой исходный размер, это даст просто грубоватую реакцию, но если буфер ужать после коннекта, может заклинить безо всяких сетевых потерь. (Я бы просто не давал делать это ужатие, если соединение установилось.)
Здравствуйте, m2l, Вы писали:
N>>Почему бы не сделать опцию расширения типа window confirm? m2l>Тут вообще всё просто — у тебя же с машины же идет трафик по TCP? Насколько в этом трафике скорость меньше от максимальной из-за указанной проблемы?
Тут дело не в скорости. Тут дело в том, что при определенном стечении обстоятельств вообще захрястнуть может на ровном месте.
m2l>Я не готов так с ходу защищать TCP, но за ним вообще то стоит куча научных работ за много лет. Сам протокол работает поверх очень разных каналов от 64k-10g, locallink-спутник. И вот так с наскоку говорить, что TCP плох... Если начать всё разбирать, то получается ровно наоборот.
Если почитать эти работы, то можно убнаружить, что существенная часть проблем, которые там решается, заключается в том, чтобы 1) сохранить совместимость со старыми механизмами обнаружения/сигнализирования congestion (все эти tripple ACK) и 2) чтобы улучшенная версия протокола не отняла весь канал у старой версиим, если им придется соревноваться за полосу пропускания.
С научной точки зрения все это очень познавательно и интересно, и заслуживает диссертации, но с инженерной точки зрения это звучит как, "мы сами создали себе проблему, и теперь героически ее решаем".
Поверх разнообразных каналов TCP работает, прямо скажем, весьма разнообразно. Например, если в канале теряется несколько процентов пакетов, TCP поверх такого канала работать вообще не будет. Поэтому, например, в wifi собственный механизм надежной доставки, работающий на по-пакетном уровне, иначе TCP поверх wifi не работал бы совсем. Между прочим, не знаю, как это все устроено в современных новомодных вариациях wifi, но в старом добром 11g эта wifi-ная надежная доставка пакетов съедала половину пропускной способности канала (т.е., при формальной скорости 54 mbit/s, пользователю было доступно ~22 mbit/s)
Здравствуйте, netch80, Вы писали:
N>Вопрос некорректный, потому что описанные проблемы вообще никак не влияют на вопрос _максимальной_ скорости. N>А вот на что влияют — это на применения, где нормально по много секунд не видеть никакой активности, но затем она нужна без задержек. N>Например, в FIX, где один из типичных шаблонов — тишина, затем взрыв активности, затем снова тишина, ввели обязательные heartbeat сообщения и таймаут их прихода. Работает "подпорка" необходимостью послать реальные данные. N>И всё равно народ после этого молится на отсутствие потерь на каналах, потому что потери дают жуткие торможения.
В TCP насколько кривой встроенный механизм keepalive, что долгоживущие соединения без реализации heartbeat на уровне прикладного протокола лучше вообще не использовать. У TCP может вообще несколько дней уйти на то, чтобы с помощью его родных keepalive обнаружить, что с ним никто давно уже никто не разговаривает.
N>Каждый второй индусокитаец полагает, что посланное одним send() точно так же будет получено одним recv(), и объяснить этим людям, в чём они ошибаются, очень часто невозможно, а иногда и видишь протоколы, где просто невозможно определить границы сообщений. Если бы при его разработке знали, что будет такое количество кретинов, мы бы имели SCTP с самого начала. (Как и сделано, на самом деле, в IPX стеке в виде SPX и в X.25 в виде своих аналогов.)
Так это же хорошо. Если компьютер сможет программировать каждый идиот, кто, кроме идиотов, будет его программировать?
N>По нему нельзя пускать синхронный поток (как голос/видео в реальном времени), малейшие потери будут приводить к локальным переполнениям, будут поступать неактуальные данные. Для этого используется UDP, реже SCTP.
Можно открыть параллельно десяток соединений, отправлять следующий кусочек в то из них, которое сейчас "менее занято" (или просто по кругу), а не приеме восстанавливать порядок и пропускать устаревшие кусочки
А еще у него есть такое милое свойство, что если несколько соединений делят один узкий канал, то канал может поделиться между ними очень неравномерно. Скажем, одному достанется 90% канала, а другому 10, и эта неравномерность будет сохраняться часами, и сама не рассосется.
N>На его логику управления потоком приходится наворачивать слой защиты от лавинных эффектов и эффектов синхронных колебаний (посмотрите историю алгоритмов Reno, Vegas, New Reno и тому подобных). Именно этой теме посвящено подавляющее количество упомянутых вами "научных работ". Да, эта тематика сама по себе очень ценная, но она не меняет основ (и не привязана по сути к TCP).
Я не очень уверен, что это можно сделать лучше, не имея в явном виде обратной связы от промежуточных устройств в сети.
По сути дела, у TCP есть лишь два входных сигнала для оценки нагрузки на сеть: потери пакетов и колебания RTT. Но потери пакетов могут происходить и по не связанным с переполнением сети причинам, а чтобы понять, как интерпретировать RTT, надо откуда-то знать RTT, нормальное для данного пути в ненагруженном виде, а как его узнать, с учетом того, что оно может изменяться?
N>32-битные sequence numbers были хороши на старте Интернета, но сейчас этого откровенно недостаточно и для очень быстрых соединений (работает принципиальное ограничение IP, что max_ttl=255, а значит, поток быстрее 4GB/255 ~= 17MB/sec уже просто незаконен), и для защиты от спуфинга (слишком высока вероятность подделки). Против первого выкручиваются костылём в виде опции таймстампа. Против второго работает разве что TLS, но это защита данных в соединении, а не работоспособности самого соединения.
В принципе, я не представляю, как надежно защитить работоспособность соединения, без, как минимум, криптографической подписи управляющих данных, а лучше и пользовательских данных тоже.
N>16-битных номеров портов недостаточно для крупных датацентров, для толстых фронтэнд-прокси, выкручиваются выдачей множественных IP адресов таким системам.
Тут во многом проблема не с протоколом, как таковым, а с евонным API.
Здравствуйте, Pzz, Вы писали:
N>>И всё равно народ после этого молится на отсутствие потерь на каналах, потому что потери дают жуткие торможения. Pzz>В TCP насколько кривой встроенный механизм keepalive, что долгоживущие соединения без реализации heartbeat на уровне прикладного протокола лучше вообще не использовать. У TCP может вообще несколько дней уйти на то, чтобы с помощью его родных keepalive обнаружить, что с ним никто давно уже никто не разговаривает.
Ну, умолчание в первых реализациях (4.3BSD) это 2 часа. Сейчас, по-моему, только в линуксе можно ставить произвольное время (хоть 1 секунду), остальные ограничивают снизу весьма высокими цифрами. Для дальней связи, наверно, это и хорошо, но в пределах ДЦ и секундный лаг может означать необходимость разрыва.
N>>Каждый второй индусокитаец полагает, что посланное одним send() точно так же будет получено одним recv(), и объяснить этим людям, в чём они ошибаются, очень часто невозможно, а иногда и видишь протоколы, где просто невозможно определить границы сообщений. Если бы при его разработке знали, что будет такое количество кретинов, мы бы имели SCTP с самого начала. (Как и сделано, на самом деле, в IPX стеке в виде SPX и в X.25 в виде своих аналогов.) Pzz>Так это же хорошо. Если компьютер сможет программировать каждый идиот, кто, кроме идиотов, будет его программировать?
Это хорошо до тех пор, пока сам не натыкаешься на такой продукт вторичный без возможности исправить или сменить. У нас соседний отдел наткнулся — нанятые ляо сделали протокол, грубо говоря, Modbus over TCP, но без положенного префикса длины, и отказывались признавать, что это не будет работать под реальной нагрузкой. А наши партнёры оказались завязаны на их железо. Последующий фольклор гласил, что после потери двух зубов их ответственный согласился это исправить, хотя я больше думаю, что тут преувеличение — основное воздействие пошло за проблемы именно хардвера, начиная с диких соплей при пайке.
Но за компанию они и формат сообщений нормализовали.
А некоторым и не получается тут воздействовать на партнёров, как-то выживают с такими проблемами, вводя хитрые эмпирики по детекту границ сообщений и/или ставя отдельные сервера, которые занимаются только приёмом и перепаковкой в нормальный вид.
N>>По нему нельзя пускать синхронный поток (как голос/видео в реальном времени), малейшие потери будут приводить к локальным переполнениям, будут поступать неактуальные данные. Для этого используется UDP, реже SCTP. Pzz>Можно открыть параллельно десяток соединений, отправлять следующий кусочек в то из них, которое сейчас "менее занято" (или просто по кругу), а не приеме восстанавливать порядок и пропускать устаревшие кусочки
Гм, это какой-то дикий изврат, мне кажется. Так можно и все соединения забить. Что, создавать пул spare-соединений для новой передачи, а старые заклинившие сразу рвать? По-моему, UDP проще
Pzz>А еще у него есть такое милое свойство, что если несколько соединений делят один узкий канал, то канал может поделиться между ними очень неравномерно. Скажем, одному достанется 90% канала, а другому 10, и эта неравномерность будет сохраняться часами, и сама не рассосется.
Угу, видел. Причём можно такое было получить даже на домашнем ADSL канале.
N>>На его логику управления потоком приходится наворачивать слой защиты от лавинных эффектов и эффектов синхронных колебаний (посмотрите историю алгоритмов Reno, Vegas, New Reno и тому подобных). Именно этой теме посвящено подавляющее количество упомянутых вами "научных работ". Да, эта тематика сама по себе очень ценная, но она не меняет основ (и не привязана по сути к TCP).
Pzz>Я не очень уверен, что это можно сделать лучше, не имея в явном виде обратной связы от промежуточных устройств в сети.
Pzz>По сути дела, у TCP есть лишь два входных сигнала для оценки нагрузки на сеть: потери пакетов и колебания RTT. Но потери пакетов могут происходить и по не связанным с переполнением сети причинам, а чтобы понять, как интерпретировать RTT, надо откуда-то знать RTT, нормальное для данного пути в ненагруженном виде, а как его узнать, с учетом того, что оно может изменяться?
Вот там и занимаются тем, что по этим очень косвенным данным детектируют нагрузки и переполнения. И по тому, что я слышал, достаточно хорошо получается — если до того нагрузку могло качать, как пьяного матроса в шторм, то с NewReno такие случаи возникали только при намеренной раскачивании. Но там народ реально решал системы дифуров, чтобы составить алгоритмы.
А ещё — я за этим уже лет 10 не слежу, и имён не помню — но новая поросль свичеводов начала плевать на правильность алгоритмов управления очередями при переполнении, и проблемы всплыли заново. Где-то в те времена начали как раз внедрять SACK, чтобы сетям с тупыми свичами лучше жилось.
N>>32-битные sequence numbers были хороши на старте Интернета, но сейчас этого откровенно недостаточно и для очень быстрых соединений (работает принципиальное ограничение IP, что max_ttl=255, а значит, поток быстрее 4GB/255 ~= 17MB/sec уже просто незаконен), и для защиты от спуфинга (слишком высока вероятность подделки). Против первого выкручиваются костылём в виде опции таймстампа. Против второго работает разве что TLS, но это защита данных в соединении, а не работоспособности самого соединения.
Pzz>В принципе, я не представляю, как надежно защитить работоспособность соединения, без, как минимум, криптографической подписи управляющих данных, а лучше и пользовательских данных тоже.
Пользовательские и так защищаются — в случае TLS. Проблема в том, что такой сторонней атакой можно, не получив вскрытие содержимого соединений, просто парализовать хотя бы часть из них. Тут расширение пространства SN таки помогло бы. Только как бы не оказалось, что для нынешних условий нужно уже не 64, а 128.
N>>16-битных номеров портов недостаточно для крупных датацентров, для толстых фронтэнд-прокси, выкручиваются выдачей множественных IP адресов таким системам.
Pzz>Тут во многом проблема не с протоколом, как таковым, а с евонным API.
Pzz>Я когда-то давно об этом немного писал в своем ЖЖ.
Да, читал. Вопрос в том, что если у тебя хост A (который работает прокси/фронтэндом) отправляет соединения на хост B на один и тот же порт, то ты никак не полечишь это выбором уже занятого другими порта — совпадёт вся четвёрка параметров. А это вполне типичная ситуация.
Поэтому тут для начала ставят правило пакетного фильтра, что все соединения на диапазон портов некоторого локального IP форвардятся на один конкретный порт. Когда и этого не хватает — машине назначают сразу пачку IP (я видел и такие, у которых было по 10K адресов на интерфейсе; и были проблемы в тех ОС, где на каждый пакет перебирался линейный список адресов).
Здравствуйте, netch80, Вы писали:
Pzz>>В TCP насколько кривой встроенный механизм keepalive, что долгоживущие соединения без реализации heartbeat на уровне прикладного протокола лучше вообще не использовать. У TCP может вообще несколько дней уйти на то, чтобы с помощью его родных keepalive обнаружить, что с ним никто давно уже никто не разговаривает.
N>Ну, умолчание в первых реализациях (4.3BSD) это 2 часа. Сейчас, по-моему, только в линуксе можно ставить произвольное время (хоть 1 секунду), остальные ограничивают снизу весьма высокими цифрами. Для дальней связи, наверно, это и хорошо, но в пределах ДЦ и секундный лаг может означать необходимость разрыва.
Ему бы надо бы после потерянного keepalive перейти к ретрансмиту этого самого keepalive с небольшим начальным таймаутом и экспоненциальным бэк-оффом. А он так и будет продолжать неторопясь слать свои кипалайвы раз в полчаса, пока, к концу недели, не накопит достаточное количество потерянных.
Это имеет интересное последствие, непосредственно наблюдаемое в реальном мире. Если усыпить лабтоп, а потом через N времени разбудить, то есть шанс, что на исходящие из него непонятные TCP-пакеты никто не ответит. Ни TCP reset'ом, ни ICMP'ной руганью, вообще никак. Ну например потому, что на другом конце стоит stateful firewall, а соединение давно протухло, и фаирволлу эти пакеты ничего не говорят, и поэтому он их на всякий случай просто режет.
В таком случае этот бедолага лабтоп долго еще не догадается, что соединение умерло и пора бы его бросить и открыть новое.
Pzz>>Можно открыть параллельно десяток соединений, отправлять следующий кусочек в то из них, которое сейчас "менее занято" (или просто по кругу), а не приеме восстанавливать порядок и пропускать устаревшие кусочки
N>Гм, это какой-то дикий изврат, мне кажется. Так можно и все соединения забить. Что, создавать пул spare-соединений для новой передачи, а старые заклинившие сразу рвать? По-моему, UDP проще
Этот дикий изврат хорошо известен в (очень) узком кругу, и даже имеет специальное название на английском языке. Которое я, впрочем, забыл.
Нормальный протокол, конечно, не должен давать преимуществ хитроумным программам, которые понаоткрывали кучу соединений, только чтобы себе колбасы канала побольше урвать.
UDP штука хорошая, только чтобы его применить, придется свой congestion control написать. И пойдешь в результате по цепочке TFRC->newreno->vegas и далее везде, а кончишь тем, что напишешь свой TCP (SCTP). Или не напишешь, как повезет.
Pzz>>А еще у него есть такое милое свойство, что если несколько соединений делят один узкий канал, то канал может поделиться между ними очень неравномерно. Скажем, одному достанется 90% канала, а другому 10, и эта неравномерность будет сохраняться часами, и сама не рассосется.
N>Угу, видел. Причём можно такое было получить даже на домашнем ADSL канале.
На домашнем ADSL канале оно как раз очень легко ловится, потому что этот канал очень плавненько и аккуратненько тормозит, уткнувшись в скорость модуляции, а не изображает тормоза програмно путем хитрой буферизации и манипуляции с очередью.
N>Вот там и занимаются тем, что по этим очень косвенным данным детектируют нагрузки и переполнения. И по тому, что я слышал, достаточно хорошо получается — если до того нагрузку могло качать, как пьяного матроса в шторм, то с NewReno такие случаи возникали только при намеренной раскачивании. Но там народ реально решал системы дифуров, чтобы составить алгоритмы.
Если бы получалось хорошо, то давно победил бы самый хороший вариант. Ну или два-три, для разных случаев жизни. А пока только новые варианты плодятся. Но зато на эту тему можно написать диссертацию. Я, кстати, недавно тут пролистывал одну из "научных" работ, где сравнивался "наш" алгоритм, и "их" алгоритм. Картинки, графики, все дела. Рядом нарисованы "наши" графики и "их" графики. Только в разном масштабе. Так что если в масштаб не вглядываться, можно подумать, что "наш" алгоритм работает в два раза лучше ихнего. А если мысленно привести к единому массштабу, то особой разницы и не видно.
Newreno, кстати, отличается от старого рено в основном тем, что узнав о потере пакета по сигналу от ресивера (через те самые triple ACKи), а не через таймаут, он пытается не уходить сразу на slow start, а починить ситуацию, уполовинив окно и с надеждой на лучшее. Т.е., это довольно небольшое таки отличие, и оно скорее инженерно-эмперическое, чем научное.
Ну и еще там много рассуждений на тему, как по tripple ACK'у отличить реальную потерю от reordering'а.
N>А ещё — я за этим уже лет 10 не слежу, и имён не помню — но новая поросль свичеводов начала плевать на правильность алгоритмов управления очередями при переполнении, и проблемы всплыли заново. Где-то в те времена начали как раз внедрять SACK, чтобы сетям с тупыми свичами лучше жилось.
SACK'и, они не от тупых свитчей, а чтобы при потере одного пакета из сотни посылателю не обязательно было бы останавливаться и перепосылать всю сотню. К сожалению, на потерю двух (или трех) пакетов из сотни эти самые SACK'и уже не очень рассчитаны.
Т.е., они будут улучшать ситуацию, когда связь хорошая, но изредка пакеты все же теряются. А если не совсем изредка, то хоть с SACK'ами, хоть без них TCP будет работать довольно паршиво.
N>>>32-битные sequence numbers были хороши на старте Интернета, но сейчас этого откровенно недостаточно и для очень быстрых соединений (работает принципиальное ограничение IP, что max_ttl=255, а значит, поток быстрее 4GB/255 ~= 17MB/sec уже просто незаконен), и для защиты от спуфинга (слишком высока вероятность подделки). Против первого выкручиваются костылём в виде опции таймстампа. Против второго работает разве что TLS, но это защита данных в соединении, а не работоспособности самого соединения.
Pzz>>В принципе, я не представляю, как надежно защитить работоспособность соединения, без, как минимум, криптографической подписи управляющих данных, а лучше и пользовательских данных тоже.
N>Пользовательские и так защищаются — в случае TLS. Проблема в том, что такой сторонней атакой можно, не получив вскрытие содержимого соединений, просто парализовать хотя бы часть из них. Тут расширение пространства SN таки помогло бы. Только как бы не оказалось, что для нынешних условий нужно уже не 64, а 128.
Для нынешних условий, когда криптографические примитивы припаяны прямо к процессору, хорошо бы криптографически хотя бы подписывать каждый пакет. Мне кажется, это более плодотворный подход, чем пространство SN расширять. Кроме того, если ты каким-то образом можешь подглядеть чужие пакеты, то будь эти SN хоть 1024-битными, если они возрастают предсказуемым образом, то поломать чужое соединение несложно.
Здравствуйте, netch80, Вы писали:
N> 32-битные sequence numbers были хороши на старте Интернета, но сейчас этого откровенно недостаточно и для очень быстрых соединений (работает принципиальное ограничение IP, что max_ttl=255, а значит, поток быстрее 4GB/255 ~= 17MB/sec уже просто незаконен)
Простите, туплю наверное, не могу понять свять ttl и пропускной способности Что значит больший объем не законен?
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, netch80, Вы писали:
N>>(*) 32-битные sequence numbers были хороши на старте Интернета, но сейчас этого откровенно недостаточно и для очень быстрых соединений (работает принципиальное ограничение IP, что max_ttl=255, а значит, поток быстрее 4GB/255 ~= 17MB/sec уже просто незаконен)
S>Простите, туплю наверное, не могу понять свять ttl и пропускной способности Что значит больший объем не законен?
TTL=255 (максимально допустимый, но устанавливаемый по умолчанию в большинстве современных ОС) означает, что пакет может гулять неизвестно где 4 минуты 15 секунд (4 минуты, Карл!), прежде чем достигнет адресата, при этом никто не запрещает сети прислать, например, одну копию одного и того же пакета сразу, вторую — через полминуты, третью — на самой последней секунде истечения этого TTL. (Реально из TTL вычитается hop count, но даже между континентами редко бывает более 30 хопов, так что порядок цифр не меняется.) Это не фантастика, я видел ситуации дублирования пакетов своими глазами. IP это свободно разрешает, перекладывая проблемы детекта потерь, задержек и дублирований на более высокие уровни сетевого стека.
Если за эти минуты sequence numbers пройдут полный цикл из 2**32 байт, то может оказаться, например, что в одну секунду придёт пакет с SN=123000000, посланный отправителем полсекунды назад, и SN=123000000, посланный им же 4 минуты назад. Получатель не сможет разобрать, какие из этих данных актуальные, а какие — нет, потому что единственный критерий проверки для приёма данных — что ожидаемая порция находится в диапазоне SN данного пакета (если приходит пакет 300 байт с SN=123000000, а он ждёт следующий SN=123000100, то он первые 100 байт пакета пропустит, а остальные 200 уложит в буфер, и увеличит следующий ожидаемый SN на 200).
Поэтому, чтобы иметь возможность отличать актуальные пакеты от старых, сделали timestamp option — пакет со слишком старым SN игнорируется при выходе за пределы допустимого отставания полученного штампа. Но, в отличие от SN, она не обязательна.
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, Sharov, Вы писали:
S>>Здравствуйте, netch80, Вы писали:
N>>>(*) 32-битные sequence numbers были хороши на старте Интернета, но сейчас этого откровенно недостаточно и для очень быстрых соединений (работает принципиальное ограничение IP, что max_ttl=255, а значит, поток быстрее 4GB/255 ~= 17MB/sec уже просто незаконен)
S>>Простите, туплю наверное, не могу понять свять ttl и пропускной способности Что значит больший объем не законен?
N>TTL=255 (максимально допустимый, но устанавливаемый по умолчанию в большинстве современных ОС) означает, что пакет может гулять неизвестно где 4 минуты 15 секунд (4 минуты, Карл!), прежде чем достигнет адресата, при этом никто не запрещает сети прислать, например, одну копию одного и того же пакета сразу, вторую — через полминуты, третью — на самой последней секунде истечения этого TTL. (Реально из TTL вычитается hop count, но даже между континентами редко бывает более 30 хопов, так что порядок цифр не меняется.) Это не фантастика, я видел ситуации дублирования пакетов своими глазами.
Как 254 конвертируется в 4м15с? Если он будет гулять самыми длинными маршрутами или что? Вы интересно пишите, но за логикой порой уследить непросто, особенно если в этом не специализируешься.
N>IP это свободно разрешает, перекладывая проблемы детекта потерь, задержек и дублирований на более высокие уровни сетевого стека.
Здравствуйте, Sharov, Вы писали:
S>Как 254 конвертируется в 4м15с?
255 секунд == 4 минуты 15 секунд. Тут везде может быть плюс-минус единица, как считать хопы, но это не принципиально для общей картины.
S> Если он будет гулять самыми длинными маршрутами или что?
Нет, это самыми короткими. Правило для IP4: каждый раутер, переправляющий пакет дальше, обязан уменьшить TTL на количество секунд, которые пакет провёл в его памяти, но не менее чем на 1.
Для самого длинного реально замеченного — ну, например, 40 хопов (раутеров) — останется до 215, это соответствует пределу в 3 минуты 35 секунд. Тоже крайне много.
Хотя в реальности ситуация часто ещё хуже за счёт того, что многие дешёвые реализации могут игнорировать время ожидания в очереди, или же задержки могут быть не на уровне IP. Я с таким сталкивался на одном ADSL модеме. Когда он перегревался, он начинал тормозить пакеты по 20-30 секунд. От такого ничего не защищено.
N>>IP это свободно разрешает, перекладывая проблемы детекта потерь, задержек и дублирований на более высокие уровни сетевого стека.
S>Он и так сложный, ему простительно.
Ну, тут не хочу вдаваться в теоретические аспекты и альтернативную историю. Работаем с тем, что есть.
Здравствуйте, netch80, Вы писали:
N>Хотя в реальности ситуация часто ещё хуже за счёт того, что многие дешёвые реализации могут игнорировать время ожидания в очереди, или же задержки могут быть не на уровне IP. Я с таким сталкивался на одном ADSL модеме. Когда он перегревался, он начинал тормозить пакеты по 20-30 секунд. От такого ничего не защищено.
Наверное, в прошлой жизни он был тостером, и пытался доставить пакеты с хрустящей корочкой
Но по-нормальному нужно любую разработку в области протоколов редизайнить с нуля через 30 лет. Для TCP этот момент давно пришёл.
Что значит больший объем не законен?
