Здравствуйте, 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 этот момент давно пришёл.

Здравствуйте, 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 этот момент давно пришёл.