История изменений

Исправление hateyoufeel, 02.02.25 17:23 (текущая версия) :

QUIC - пакость, которая, надеюсь, в чём-нить скоро помешает ркну и он её за это забанит.

Какой же ты мерзкий.

TCP нормальный протокол, а твои к нему претензии скорее всего связаны с тем, что он специально спроектирован (и настроен с ядрах ОС) так, чтобы не дать одному юзеру сожрать весь аплинк наглухо (не имея на то злых намерений).

Нет. Мои претензии к TCP следующие:

Ублюдочная идея нумерованных портов, которая должна сдохнуть;
Следующая из предыдущего ублюдочная система идентификации соединений через (sip, sport, dip, dport), что абсолютно никак не работает в мире, в котором существуют NAT и мобильные клиенты;
Отсутствие возможности разбиения данных на отдельные сообщения. Основная причина, почему почти всё сейчас работает поверх HTTP, это как раз вот это плюс первый пункт. HTTP позволяет мультиплексировать соединения и разбивать данные на отдельные сообщения без лишней головной боли;
Полная невозможность внеочередной доставки данных. Если пакет от сообщения A просрался, приложение не получит сообщение Б. Даже если оно уже доставлено на целевой хост и лежит там в памяти. Все будут ждать окончания окна и пердеть, пока пересылка не произойдёт.

К слову, последние две проблемы решает QUIC. Вторую тоже частично решает, но с некоторым скрипом.

Исправление hateyoufeel, 02.02.25 17:22:

QUIC - пакость, которая, надеюсь, в чём-нить скоро помешает ркну и он её за это забанит.

Какой же ты мерзкий.

TCP нормальный протокол, а твои к нему претензии скорее всего связаны с тем, что он специально спроектирован (и настроен с ядрах ОС) так, чтобы не дать одному юзеру сожрать весь аплинк наглухо (не имея на то злых намерений).

Нет. Мои претензии к TCP следующие:

Ублюдочная идея нумерованных портов, которая должна сдохнуть;
Следующая из предыдущего ублюдочная система идентификации соединений через (sip, sport, dip, dport), что абсолютно никак не работает в мире, в котором существуют NAT и мобильные клиенты;
Отсутствие возможности разбиения данных на отдельные сообщения. Основная причина, почему почти всё сейчас работает поверх HTTP, это как раз вот это плюс первый пункт. HTTP позволяет мультиплексировать соединения и разбивать данные на отдельные сообщения без лишней головной боли;
Полная невозможность внеочередной доставки данных. Если пакет от сообщения A просрался, приложение не получит сообщение Б. Даже если оно уже доставлено на целевой хост и лежит там в памяти. Все будут ждать окончания окна и пердеть, пока пересылка не произойдёт.

К слову, вторую и третью проблему решает QUIC. Вторую тоже частично решает, но с некоторым скрипом.

Исправление hateyoufeel, 02.02.25 17:22:

QUIC - пакость, которая, надеюсь, в чём-нить скоро помешает ркну и он её за это забанит.

Какой же ты мерзкий.

TCP нормальный протокол, а твои к нему претензии скорее всего связаны с тем, что он специально спроектирован (и настроен с ядрах ОС) так, чтобы не дать одному юзеру сожрать весь аплинк наглухо (не имея на то злых намерений).

Нет. Мои претензии к TCP следующие:

Ублюдочная идея нумерованных портов, которая должна сдохнуть;
Следующая из предыдущего ублюдочная система идентификации соединений через (sip, sport, dip, dport), что абсолютно никак не работает в мире, в котором существуют NAT и мобильные клиенты;
Отсутствие возможности разбиения данных на отдельные сообщения. Основная причина, почему почти всё сейчас работает поверх HTTP, это как раз вот это плюс первый пункт. HTTP позволяет мультиплексировать соединения и разбивать данные на отдельные сообщения без лишней головной боли;
Полная невозможность внеочередной доставки данных. Если пакет от сообщения A просрался, приложение не получит сообщение Б. Даже если оно уже доставлено на целевой хост и лежит там в памяти. Все будут ждать окончания окна и пердеть, пока пересылка не произойдёт.

К слову, вторую и третью проблему решает QUIC. Первую тоже частично решает, но с некоторым скрипом.

Исправление hateyoufeel, 02.02.25 17:21:

QUIC - пакость, которая, надеюсь, в чём-нить скоро помешает ркну и он её за это забанит.

Какой же ты мерзкий.

TCP нормальный протокол, а твои к нему претензии скорее всего связаны с тем, что он специально спроектирован (и настроен с ядрах ОС) так, чтобы не дать одному юзеру сожрать весь аплинк наглухо (не имея на то злых намерений).

Нет. Мои претензии к TCP следующие:

Ублюдочная идея нумерованных портов, которая должна сдохнуть;
Следующая из предыдущего ублюдочная система идентификации соединений через (sip, sport, dip, dport), что абсолютно никак не работает в мире, в котором существуют NAT и мобильные клиенты;
Отсутствие возможности разбиения данных на отдельные сообщения. Основная причина, почему почти всё сейчас работает поверх HTTP, это как раз вот это плюс первый пункт. HTTP позволяет мультиплексировать соединения и разбивать данные на отдельные сообщения без лишней головной боли;
Полная невозможность внеочередной доставки данных. Если пакет от сообщения A просрался, приложение не получит сообщение Б. Даже если оно уже доставлено на целевой хост и лежит там в памяти. Все будут ждать окончания окна и пердеть, пока пересылка не произойдёт.

К слову, вторую и третью проблему решает QUIC.

Исправление hateyoufeel, 02.02.25 17:18:

QUIC - пакость, которая, надеюсь, в чём-нить скоро помешает ркну и он её за это забанит.

Какой же ты мерзкий.

TCP нормальный протокол, а твои к нему претензии скорее всего связаны с тем, что он специально спроектирован (и настроен с ядрах ОС) так, чтобы не дать одному юзеру сожрать весь аплинк наглухо (не имея на то злых намерений).

Нет. Мои претензии к TCP следующие:

Ублюдочная идея нумерованных портов, которая должна сдохнуть;
Следующая из предыдущего ублюдочная система идентификации соединений через (sip, sport, dip, dport), что абсолютно никак не работает в мире, в котором существуют NAT и мобильные клиенты;
Отсутствие возможности разбиения данных на отдельные сообщения. Основная причина, почему почти всё сейчас работает поверх HTTP, это как раз вот эти два пункта. HTTP позволяет мультиплексировать соединения и разбивать данные на отдельные сообщения;
Полная невозможность внеочередной доставки данных. Если пакет от сообщения A просрался, приложение не получит сообщение Б. Даже если оно уже доставлено на целевой хост и лежит там в памяти. Все будут ждать окончания окна и пердеть, пока пересылка не произойдёт.

К слову, вторую и третью проблему решает QUIC.

Исходная версия hateyoufeel, 02.02.25 17:16:

QUIC - пакость, которая, надеюсь, в чём-нить скоро помешает ркну и он её за это забанит.

Какой же ты мерзкий.

TCP нормальный протокол, а твои к нему претензии скорее всего связаны с тем, что он специально спроектирован (и настроен с ядрах ОС) так, чтобы не дать одному юзеру сожрать весь аплинк наглухо (не имея на то злых намерений).

Нет. Мои претензии к TCP следующие:

Ублюдочная идея нумерованных портов, которая должна сдохнуть;
Отсутствие возможности разбиения данных на отдельные сообщения. Основная причина, почему почти всё сейчас работает поверх HTTP, это как раз вот эти два пункта. HTTP позволяет мультиплексировать соединения и разбивать данные на отдельные сообщения;
Полная невозможность внеочередной доставки данных. Если пакет от сообщения A просрался, приложение не получит сообщение Б. Даже если оно уже доставлено на целевой хост и лежит там в памяти. Все будут ждать окончания окна и пердеть, пока пересылка не произойдёт.

К слову, вторую и третью проблему решает QUIC.