Здравствуйте, Cyberax, Вы писали:
C>>>Дополнительно, QUIC сделан так, что предотвращает окостеневание протоколов (protocol ossification). N>>Прошу показать, как QUIC позволит устранять какие-то нормы стандарта, которые позднее признаны неадекватными и предложена замена (причём, какие именно, мы ещё не знаем). C>TCP закостенел. Его невозможно изменить. Простенький ECN (Explicit Congestion Notification) до сих пор не поддерживается всеми middlebox'ами, через 17 лет после RFC.
"C++ закостенел, потому что простейшие нормы C++11 до сих пор не поддерживаются всеми компиляторами."
"C закостенел, потому что C99 до сих пор не поддерживается всеми компиляторами, через 19 лет после стандарта."
Впрочем, будем считать, что ты ответил на вопрос. Тогда следующий — почему это вместо нормального нового стандарта TCP-like (время которого таки пришло) или SCTP (в котором есть уже почти всё нужное) нам предлагают идти калечным путём и строить что-то поверх UDP, теряя множество важных возможностей от интеграции в IP стек.
"Нормальные герои всегда идут в обход", да.
C>С QUIC так не получится, так как там шифруется практически всё. Для middlebox'ов оставили один незашифрованный бит.
Ну вот ты впал в ту же сторону, что гугл — всё, что посреди, назвать "middlebox", назначить этому ярлыку заведомо отрицательную роль и считать свою историческую роль выполненной.
Про проблемы времени жизни NAT сессий тут уже говорили, не буду повторяться.
C>Из конкретных улучшений по сравнению с TCP: C>1) PMTU полностью поднят на уровень QUIC, так как на уровне IP оно всё сдохло.
На уровне IP его, как ни странно, за последние годы починили чуть менее, чем везде.
Если в начале 2000х я постоянно боролся с ним даже как клиент, то за последние лет 5 проблемы не видно.
C>2) Multi-homing внедрён в QUIC и полностью поддерживается. Для TCP это есть только в расширении MPTCP. C>3) Продуманный механизм будущих расширений. C>4) FEC для компенсации потерянных пакетов (возможно, что в первую версию стандарта не попадёт).
И будет точно так же, как с TCP? Первая версия застынет у 90% участников.
Это если мы полагаем, что его будет использовать кто-то за пределами гугла.
C>...
N>>The "ossification" Google harps on is someone else exercising some form of non-Google control, usually by virtue of having bought or being the owner or contractor of the network or computing gear, deploying something designed to be controlled by its owner, or applying standards with the same objective. C>Бред.
Почему? Пока что всё указывает на это — гугл силой проталкивает своё крайне сырое решение, нацеленное исключительно на его интересы.
Повторится ситуация с HTTP/2, который кое-как выкрутили с двадцатой попытки, и то постоянно с проблемами (знаю места, где сначала включили его на сервере, потом выключили нафиг, ибо реализации глючные аж нимагу).
N>>Я знаю проблемы TCP. Но решение от гугла, которое притягивается за уши, может быть ещё хуже. C>Чем?
