Комитет IETF (Internet Engineering Task Force), занимающийся развитием протоколов и архитектуры интернета, завершил формирование RFC для протокола HTTP/3.0 и опубликовал связанные с ним спецификации под идентификаторами RFC 9114 (протокол) и RFC 9204 (технология сжатие заголовков QPACK для HTTP/3). Спецификация HTTP/3.0 получила статус "Предложенного стандарта", после чего начнётся работа по приданию RFC статуса чернового стандарта (Draft Standard), фактически означающего полную стабилизацию протокола и учёт всех высказанных замечаний. Одновременно опубликованы обновлённые варианты спецификаций для протоколов HTTP/1.1 (RFC 9112) и HTTP/2.0 (RFC 9113), а также...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=57309
Welcome to googlenet?
С разморозкой. Гугельнет начался с этапа отжатия 50+% браузеров.
С другой стороны лучше бы разрабы браузеров внедряли BitTorrent-протокол, чтобы скомпенсировать.
Больше мониторов богу мониторов!
VR из каминг, покайтесь.
is coming out
> внедряли BitTorrent-протоколТы хотел сказать IPFS?
Он тогда уже закончился, с захватом от 50% рынка...
Начался ещё с покупки YouTube и пихания хрома во все щели: IE, инсталляторы и т.п.
Одни статусы, толку нет.
> В настоящее время поддержка QUIC и HTTP/3.0 уже реализована во всех популярных web-браузерах
> (в Chrome, Firefox и Edge поддержка HTTP/3 включена по умолчанию, а в Safari требует включения
> настройки "Advanced > Experimental Features > HTTP/3").Правильно. Не читай, сразу пиши.
И чо? Зачем оно?
на днях вышел haproxy 2.6 - уже с http3 )))так что процесс пошел
https://github.com/haproxy/haproxy/issues/680Таки ты врешь. Статус open.
В доках (https://raw.githubusercontent.com/haproxy/haproxy/v2.6.0/doc...) упоминается поддержка HTTP/3, для включения которой нужно указать h3 в опции alpn.
Только она не включится, если не собрать с USE_QUIC и патченым OpenSSL.
> на днях вышел haproxy 2.6 - уже с http3 )))Есть нюансы https://www.haproxy.com/blog/announcing-haproxy-2-6/#http-3-...
> You’ll need to compile HAProxy with a few new options, including the USE_QUIC flag, and also link to a QUIC-compatible version of OpenSSL1. Статус пока - tech preview.
2. При сборке по умолчанию выключено.
3. Нужна патченая версия OpenSSL (потому что официальный стабильный релиз OpenSSL вертел все эти QUICи известно на чём).
Прощай, роскомблокиратор
Чем оно тебя спасёт от блокиратора?
От блокиратора спасёт только ECH, да и то не сразу.
> Потеря пакета влияет на доставку только связанного с ним потока и не останавливает доставку данных в параллельно передаваемых через текущее соединение потоках;А пакет "теряется" сам по себе, проблемы физического канала ни при чём и не влияют на другие потоки 😅
пакеты теряются всегда, так уж устроен ip
Только в одном потоке, или во всех случайным образом?
случайно конечно, если поток маленький, то и потерь может не быть, но модемное прошлое даром не прошло
А про TCP ты забыл, да? Вот в UDP, который в новом стандарте, будут теряться безвозвратно, да.
> А про TCP ты забыл, да?В TCP точно так же теряется и нужно перепосылать. И нет, это будет другой пакет.
>> А про TCP ты забыл, да?
> В TCP точно так же теряется и нужно перепосылать. И нет, это
> будет другой пакет.Это будет тот же payload. И не придуривайся, что ты не понял, о чём речь.
Я как раз очень хорошо понимаю о чём идёт речь. Пейлоад, в некоторых случаях, тоже будет другим.
проторол контроля передачи, потери учитывает и логику работы сетевого стека подстраивает, данные он передает гарантированно, или ошибки выдает, но пакеты теряет бай-дизайн.
> будут теряться безвозвратно, да.Их перепошлет сама реализация QUIC. Это лучше чем уповать на кернел. Особенно когда ископаемые из эпохи диалапа думают что окей использовать попытки повтора отсылки пакета с таймаутами измеряемыми в МИНУТАХ, так что на мобильных линках с движущимися абонентами TCP творит жесточайший трэш как только покрытие отлично от идеала, а MS еще и не переубедишь сменить congestion control. Впрочем он и в linux работает так себе, даже BBR и Codel весьма компромиссные штуки.
Там речь про смену маршрутов вроде перехода с LTE на wifi - но мне кажется оно того не стоит.
Ещё раз:> Потеря пакета ...
Где здесь "пакет теряется"? Не перестаю удивляться способности кожанных мешков коверкать прочитанное, увиденное и услышанное. Просто пипец какой-то.
> Где здесь "пакет теряется"? Не перестаю удивляться способности кожанных мешков коверкать
> прочитанное, увиденное и услышанное. Просто пипец какой-то.Я советую всё же научиться пользоваться утилитой ss, чтобы понять, что пакеты теряются всегда и везде, а вынос операции обработки этого события в userspace никак не уменьшает вероятность этого события. Более того, хочу напомнить, что изначально Google толкал BBR, но отказался от него в спецификации, а большинство реальных реализаций используют доступные уже многие годы алгоритмы CUBIC/Reno. Да, я знаю, что Google запилил даже BBRv2 (он всё ещё не релиз) и у себя использует какую-то третью реализацию, отличную от BBRv1, доступного в ядре Linux, и BBRv2, но общей картины это никак не меняет.
P.S. Миграция соединения всё же полезная "фича".
>> Где здесь "пакет теряется"? Не перестаю удивляться способности кожанных мешков коверкать
>> прочитанное, увиденное и услышанное. Просто пипец какой-то.
> Я советую всё же научиться пользоваться утилитой ss, чтобы понять, что пакеты
> теряются всегда и вездеЕще раз: "теряется" -- буквально "теряет ся" -- "теряет сам себя". Учите русский язык. Пакет не может потерять САМ СЕБЯ.
Пакет потерял сам себя, и не пришёл по адресу, по которому его отправили. Сколько там розг за такое положено? Тут уже не отвертишься, серьёзный прокол. Хорошо, если не казнят.
> Еще раз: "теряется" -- буквально "теряет ся" -- "теряет сам себя". Учите
> русский язык. Пакет не может потерять САМ СЕБЯ.Читай учебник демагога, слабый заход. Да и технически ты тоже ошибаешься. Пакеты сами по себе теряются благодаря RED.
Звенит январская вьюга,
Патч-корды хлещут упруго,
Пакеты мчатся по кругу,
И шумят сервера.
Не видят пакеты друг друга,
Проходят мимо друг друга,
Теряют пакеты друг друга,
А потом не найдут никогда.
Зачот!
> Еще раз: "теряется" -- буквально "теряет ся" -- "теряет сам себя". Учите русский язык. Пакет не может потерять САМ СЕБЯ.Брат, языки сложнее чем ты думаешь :)
> Еще раз: "теряется" -- буквально "теряет ся" -- "теряет сам себя". Учите русский язык. Пакет не может потерять САМ СЕБЯ.Тебя задорнов покусал?
>Пакет не может потерять САМ СЕБЯ.Ага, вот деньги (бюджетные) могут терять сами себя, а пакеты, значит, не могут.
Ругаться - ругать себя? (На деле непереходный глагол со значением взаимности)
Обмануться - себя обмануть? (Непереходный глагол со значением страдательности)
У моего соседа собака кусается!
Ну это они как раз любят — за хвост самоё себя пожрать.
> А пакет "теряется" сам по себе, проблемы физического канала ни при чём и не влияют на другие потоки 😅Пакеты теряются по дизайну, именно потеря пакета и является тем, что даёт сигнал отправляющему данные о том, что нужно снизить скорость. Да, есть ECN и есть delay-based алгоритмы управления потоком, но первые спустя столько-то лет до сих пор не включены по умолчанию ни в этих ваших Линуксах (два Linux'а в дефолтной конфигурации не договорятся о ECN), ни в значительной части сетевого оборудования (это вообще стыд и срам, причин не включать просто нет), а вторые по дизайну проигрывают packet-loss алгоритмам и внедрять их надо сразу и везде или городить гибридные алгоритмы, которые будут определять событие конкуренции с loss-based потоком.
Нюанс в том что в беспроводных линках пакеты теряются независимо от нагрузки на сеть. Всплеск помех выбивающий пакет в радиолинке или временная потеря сигнала движущимся абонентом попавшим в прореху покрытия не имеет никакого отношения к нагрузке на сеть - однако это легко убивает скорость TCP до диалапных величин и даже хуже.А вот такие тупари с вон тем дизайном, не способные понять что мир немного изменился и люди хотят беспроводные сети - очень работе этих сетей вредят. И теперь их слушать никто не будет, плохая работа беспроводных сетей и жалующиеся пользователи всех достали. Потому и UDP, чтобы уровень ретрансмита делать без участия вот таких экспертов. Поэтому у юзеров гуглобраузера будет первоклассный юзер экспериенс. А у вас - это уже ваши проблемы. Если вам нравится прерывающееся видео или сайты грузящиеся по беспроводке с издевательской скоростью, вы этим "счастьем" и наслаждайтесь.
> Нюанс в том что в беспроводных линках пакеты теряются независимо от нагрузки
> на сеть.Нюанс не в этом, что там не пакеты...
> Нюанс не в этом, что там не пакеты...Кэп намекает что с точки зрения TCP/IP вообще есть только пакеты и rtt. Да и беспроводные линки так то packet-switched сети в основном. В каких-то случаях это может называться в другом протоколе фреймом и проч, но суть дела не меняет. А раскручивать абстракции до I/Q модуляторов мы все же не будем: TCP/IP это вообще не видно. С его точки зрения - вон то.
и это, в какой-нибудь вафле пакеты довольно похожи на обычный эзернет, так то, если на физический уровень забить.
> Всплеск помех выбивающий пакет в радиолинке или временная потеря
> сигнала движущимся абонентом попавшим в прореху покрытия не имеет никакого отношения
> к нагрузке на сеть - однако это легко убивает скорость TCP
> до диалапных величин и даже хуже.Нет, потеря одиночного фрейма и даже нескольких не вызовет падения скорости до диалапных величин из-за: а) контроль чётности и коррекция ошибок есть на уровне протокола беспроводной сети; б) если вы не используете Reno, то восстановление произойдёт достаточно быстро.
Проблема в том (основная), что бесповодная сеть меняет символьную скорость данных, подстраиваясь под условия, и эта информация никак не коммуницируется на более высокий уровень OSI.
> Нет, потеря одиночного фрейма и даже нескольких не вызовет падения скорости до
> диалапных величинКрасивая теория, но своему снифферу я доверяю больше чем какому-то эксперту опеннета с стремным уровнем квалификации.
> из-за: а) контроль чётности и коррекция ошибок есть на уровне протокола беспроводной сети;
Кэп намекает что для TCPIP результат бинарный: протоколы под ним или выдюжили, или нет. Для TCP пакет или доставлен корректно, или нет. При том тот всплеск "не выдюжили" во первых может быть рандомный. Во вторых не связан с "congestion" и - просто не повод к снижению скорости TCP потока, о великий эксперт! Некоторые, типа CDG и BBR даже пытаются какой-то эвристикой это определять, но получается довольно компромиссно и к тому же это 2-сторонняя игра.
Еще можно выпасть на цать секунд из сети если прореха в покрытии. Хэндовер при этом не удается и модем довольно долго ищет сеть, регается в ней, и в целом это может выбить из сети на ...цать секунд. За это время TCP обычно успевает конкретно обидеться на недоставку пакетов и проапгрейдить легкий вылет до доброй минуты полного дауна. И например в реалтайм чатике в чем-то движущемся сие например подбешивает.
> б) если вы не используете Reno, то восстановление произойдёт достаточно быстро.
То-есть ss кажущий как кернел лихо отсчитывает добрых 60 секунд на перепосыл пакета был моим глюком? Да ладно? :)
> Проблема в том (основная), что бесповодная сеть меняет символьную
> скорость данных, подстраиваясь под условия, и эта информация никак
> не коммуницируется на более высокий уровень OSI.И это тоже. Впрочем вон там packet loss кой-как пытаются классифицировать - всплеск ли это или глобальный аут но честно говоря получилось оверинженернутое УГ которое навороченое но работает не особо хорошо и все-равно дурит временами.
А в сабже кстати у гугли есть идея и свой FEC делать - так то можно пролюбить 20% пакетов, починить это FEC - и хотя линк дурил, юзер этого вообще не увидит. А, представляете, FEC можно так то interleave'ить и комбинировать и это сильно улучшает надежность ценой некоторой потери скорости.
> А вот такие тупари с вон тем дизайном, не способные понять что
> мир немного изменился и люди хотят беспроводные сети - очень работе
> этих сетей вредят.Ну напиши congestion control новый, степень защитишь и на работу получше устроишься.
> Ну напиши congestion control новый, степень защитишь и на работу получше устроишься.Да вон сабж уже написали. К тому же его гугл доставит ВСЕМ. И мне и даже тому ламеру с виндой. И вообще, это тот случай когда гугл явно нанял нормальных инженеров а не вебмакак или ретардов "мытакпривыкли, диалап рулит". Сделано с кой-каким пониманием проблематики и относительно осмысленным заруливанием оной. То что у меня сильно лучше получится не факт, а TCP с его congestion трогать я бы вообще лишний раз трогать не стал. Неудобно марафон в ластах бегать.
> И теперь их слушать никто не будет, плохая
> работа беспроводных сетей и жалующиеся пользователи всех достали.Пользователи и правда в своей массе являются причиной своих же неприятностей. Это такие вот и кидают точки там, где надо тянуть кабель, врубают каналы 40MHz в диапазоне 2.4GHz и 160MHz в 5GHz, выкручивают мощность на максимум и фсё, общий ресурс скушан... а девелоперы дураки )))
> Пользователи и правда в своей массе являются причиной своих же неприятностей. Это
> такие вот и кидают точки там, где надо тянуть кабель, врубают
> каналы 40MHz в диапазоне 2.4GHz и 160MHz в 5GHz, выкручивают мощность
> на максимум и фсё, общий ресурс скушан... а девелоперы дураки )))Ну и как я протяну кабель тому поезду заезжаюшему под мост? Или почему у меня из-за вылета физики на 10 секунд поток данных на уровне TCP долежн потом стоять раком минуту? Потому что это угробище дизайнили гении с весьма абстрактным видением ситуации? Ну а гугл вот может нанять тех кто сделает "как лучше работает для большей части юзеров" вместо этого всего. Это хорошо и правильно.
Сейчас бы ожидать от пользователя степени по беспроводной передачи данных. Пока на уровне протокола не будет решена проблема совместного использования радиоэфира, ничего не будет. И да, я один из тех, кто включает всё на полную мощность, с максимальной шириной канала. Не досуг мне в рентованном доме кабели тягать, а на соседей похер — им саппорт предложит перезагрузить модем, и он пересядет на другой канал, подальше от меня. Общий ресурс, говоришь? А я по праву сильного отнял себе всё. Что делать будешь?
> Потому и UDP, чтобы уровень ретрансмита делать без участия вот таких экспертов.Я тебя разочарую, но QUIC в реальной жизни сливает TCP — https://www.fastly.com/blog/measuring-quic-vs-tcp-computatio...
И это я ещё не скидываю внутрипротокольную статистику по таким параметрам как jitter, например, где твой QUIC сливает на всех платформах.
> Я тебя разочарую, но QUIC в реальной жизни сливает TCPМне достаточно того что я в реальной жизни порой вижу как TCP ПОЛНОСТЬЮ ВЫРУБАЕТ ПОТОК ДАННЫХ НА МИНУТУ при довольно скромных отклонениях от идеала, особенно в чем-нибудь движущемся, и этот булшит творится уже цать лет, чего достаточно для искреннего пожелания нехороших вещей всем к этому причастным.
> А у вас - это уже ваши проблемы. Если вам нравится прерывающееся видео или сайты грузящиеся
> по беспроводке с издевательской скоростью, вы этим "счастьем" и наслаждайтесь.Ну шта, шта ты несёшь? История вообще не про это. Но, если тебя интересует, то данные о том, чем козырял гугл в оригинальной презентации, с данными о QUIC+BBR не пинал только ленивый. В реальной жизни они просто не подтверждались, а BBR просто за счёт агрессивности выигрывал полосу у конкурентов. Кстати, именно поэтому от него и отказались и начали пилить BBRv2, который из беты не вылезает уже пару лет (уточни, просто новостей о нём особых нет), а для себя Google изобрёл какой-то третий алгоритм, который в профильной литературе иногда называют BBRv1.5.
Но некоторые вьюноши, начитавшись восторженных статей на medium у таких же, как и они, продолжают "дрочить" после прописывания net.ipv4.tcp_congestion_control=bbr даже не имея возможности провести качественную оценку полученного результата. Но тут проблема психологическая, если им это помогает с ними, проблемами, справляться, то... почему бы и нет )))
> жизни они просто не подтверждались, а BBR просто за счёт агрессивности
> выигрывал полосу у конкурентов.Даже он так то получился компромиссным. А агрессивность хоть немного приводит его в чувство на intermittent connectivity типа беспроводки, особенно в чем-то движущемся, но даже так он таки тоже может основательно тупить если не повезло. В результате мимо пролетает пять сот способных налить тонну трафа, ни в раз не перегруженых, а TCP просто туповэйтил в это время. И спасибо если когда он через минуту вяло пульнет пакетик там сота окажется. А если нет - ну, ой, диалап тогда покажется очень быстрым по сравнению с этим вашим 4G.
Он пытается в классификацию было ли это вспердом линка или реально глобальным перегрузом но например с прорехами покрытия все-равно работает погано. Прикиньте, дыра в покрытии когда какой-нибудь поезд или авто заехал под мост или в тоннель - не перегруз сети!
> Google изобрёл какой-то третий алгоритм, который в профильной литературе иногда называют BBRv1.5.
А таки BBR хоть немного приводит
> Но некоторые вьюноши, начитавшись восторженных статей на medium у таких же, как
> и они, продолжают "дрoчить" после прописывания net.ipv4.tcp_congestion_control=bbrА еще можно подр@чить на сетевой снифер и посмотреть что реально творится в той или иной ситуации. И если я вижу что линк реально есть но TCP туповэйтит, так что link utilisation стремится пробить плинтус... кхе-кхе... я очень понимаю сабжевые инициативы и почему вон то должно сдохнуть жестокой смертью. Со всеми причастными.
> даже не имея возможности провести качественную оценку полученного результата. Но тут
> проблема психологическая, если им это помогает с ними, проблемами, справляться, то...
> почему бы и нет )))Чисто психологически меня подбешивает, особенно в реалтаймном чатике, когда 10-секундный отвал апгрейдится TCP до минуты-другой дауна, а всперды в канале роняют скорость до величин ниже диалапа, и спасибо если оно вообще когда-то разгонится потом. А то может так и остаться, думаете с хрена ли многопоточные качалки появились? Хоть немного компенсирует эту идиотию протокола.
Болтун с нулевыми техническими знаниями в вопросе. Извини, не буду утруждать себя ответом.
> Болтун с нулевыми техническими знаниями в вопросе. Извини, не буду утруждать себя ответом.Давно известно что если технические аргументы закончились, можно перейти на личность оппонента. Классика жанра. Заодно надежно выдает эксперта в области.
Протокол всё равно режут - https://ntc.party/t/http-3-quic/1823/
1) в инете всё равно делать нечего без VPN. Только в исключения добавить локалку и свою страну. Psiphon умеет. А прошаренные юзаюи Shadowsocks + базу геосайтов отсюда github.com/v2fly/domain-list-community
2) свой не режут, тот же Mail RU Group и т.п. Даже отчитываются как лучше стало на v3)
Кэп намекает что shadowsocks - TCP...
Неплохо если бы ещё и недостатки указывали: поддержка UDP некоторыми сетями, отсутствие вменяемого механизма противодействия ддос, на текущий момент работает в юзерспейсе, гугол...
> отсутствие вменяемого механизма противодействия ддосНаписали жеж: "Поддержку ... обеспечивает ... Cloudflare". Вроде всё понятно. Хочется поставить смайлик, но не знаю, какой.
Только не Cloudflare! Пожалуйста! Я уже не в силах решать проблемы, которые у меня возникают с cloudflare. Постоянный баннер: "У Вас нет доступа к этому контенту", "Вы из странной сети" или капча
Просто ненавижу это
Соглашусь. От кафлара уж очень много проблем. Что-то другое было бы лучше выбрать.
Ну конечно во всем виноваты пистолеты =) Этот облачный флаер просто выживает в условиях идиотизма законодательносго созданного на основе нежелания политиков сходить к семейному психологу :-)))
> Ну конечно во всем виноваты пистолеты =) Этот облачный флаер просто выживает
> в условиях идиотизма законодательносго созданного на основе нежелания политиков сходить
> к семейному психологу :-)))"Я не виноват, я выполнял приказ"?
> "Я не виноват, я выполнял приказ"?"А довольно улыбаетесь при этом вы тогда по какой инструкции?"
> поддержка UDP некоторыми сетямиBroken by design сети совершенно никого не интересуют.
> отсутствие вменяемого механизма противодействия ддос
С точки зрения защиты от DDoS, нет разницы между TCP и UDP. Я тебе это говорю как отпахавший over 10 лет на телеком в отделе защиты от DDoS.
> С точки зрения защиты от DDoS, нет разницы между TCP и UDP.
> Я тебе это говорю как отпахавший over 10 лет на телеком
> в отделе защиты от DDoS.В телекоме мб и нет разницы, а в остальных отраслях разные ддосы бывают, не только на исчерпание полосы.
И даже в этом случае разницы нет, трафик будет точно так же блэкхолиться на границе AS. Ты главное просигналь какой.
HTTP/2 хватит всем. А «HTTP/3» он вообще ненастоящий.
я жду, когда выйдет HTTP/4. Надо продолжать развивать протокол, и как можно чаще. Я за развитие.
RFC10xyz: "Протокол HTTP/4 определяет использование протокола QDIC (Quick DDCP Internet Connections) в качестве транспорта"
Желательно менять протокол каждый месяц.
Ведь каждый хипстер знает: всё новое - лучше!
Вместе с браузерами - каждые 3 недели.
> браузерамиПочему во множественном числе?
Что бы было разнообразие) У каждого браузера свои стандарты и фичи
Подождите, его уже уже год как стандартизировали.Что-то тут не то.
Проблема в том, что пропихивающие QUIC не говорят о его недостатках. Плюс, корявые реализации (попробуйте загрузить большой файл на Youtube из этого вашего FF) и бай-дизайн большая нагрузка на сервера и клиенты из-за выноса задачи реального времени (управление потоком данных) в userspace. Последнее обстоятельство можно сравнить с выносом операции ресэмплинга звука из ядра в pulseaudio. Сколько ора на тему того, что звук икает из-за иссякания буфера при пиковых нагрузках? Второе же с низкой производительностью файловых систем реализованных в пользовательском пространстве (привет, FUSE/NTFS). В HTTP/3 проблемы возникают аналогичные, только пользователю они сразу не заметны. Сервера действительно начинают жрать больше, а jitter в соединениях только растёт.
Think different. Это не недостатки, а новые возможности.
> Think different. Это не недостатки, а новые возможности.У thinkdifferent'ов хоть ECN включен в дефолте )))
Как в анекдоте.
Меня коучи научили, что вместо "проблема" надо говорить "вызов".
Так вот, у меня теперь "вызов" с головой
На мой дилетантский взгляд сравнение с pulseaudio не вполне корректно. Даёт наглядное (точнее - воспринимаемое ухом) представление о проблеме, но скрывает её масштаб. Обработка звука это, грубо, всего 1% нагрузки. А QUIC, если на сервере, насколько больше?
> На мой дилетантский взгляд сравнение с pulseaudio не вполне корректно. Даёт наглядное
> (точнее - воспринимаемое ухом) представление о проблеме, но скрывает её масштаб.
> Обработка звука это, грубо, всего 1% нагрузки. А QUIC, если на
> сервере, насколько больше?Дело даже не в кол-ве процессорного времени, которое необходимо потратить на обработку, а в том, что реагировать на потерю пакета из очереди необходимо в очень чётко ограниченный по времени промежуток (и аналогия со звуком тут очень даже актуальна). При выполнении этой задачи в пределах пользовательского пространства кол-во "осечек", выражающихся в опорожнении или переполнении буфера, будет больше.
То есть, после повсеместного внедрения стандарта, придётся переносить реализацию в ядро? Но Гугл не обязательно этим со всеми поделится.
> То есть, после повсеместного внедрения стандарта, придётся переносить реализацию в ядро?
> Но Гугл не обязательно этим со всеми поделится.Соль была в том, чтобы иметь реализацию в пользовательском пространстве. Мол, так алгоритм управления потоком Google сможет апдейтить просто обновляя Chrome (например). Этим алгоритмом был BBR, который не очень взлетел. Да, у него есть интересные моменты, но нет, например поддержки ECN, и проблемы с честностью (он склонен душить другие соединения). Алгоритм не взлетел, но сама идея вынести всё в userspace осталась. В теории можно перенести в ядро, но это потянет целый ворох ненужного в ядро. Только каких-нибудь подгружаемых сертификатов извне там не хватало. Вон, wireguard тащит всё в ядро, мол, управлять потоком там сподручнее и это ВОООН какой профит даёт, а google тащит аналогичные вещи в userspace и поёт о том, какой профит им это даёт.
В реальности всё проще, изначальная идея вообще для Google не очень актуальная. Им обновить веб-сервер одинаково просто с обновлением tcp_uber_protocol.ko, т.к. только обновление серверного ПО и имеет смысл из-за того, что отправитель управляет потоком, а не принимающая сторона. Мобильный же клиент особо исходящий трафик, критичный по решаемым задачам, не генерирует. Единственная интересная новая вещь - прозрачная миграция трафика между интерфейсами.
P.S. вообще на самом деле нынешний CUBIC+HYSTART+SACK+ECN почти богоподобен. Да, оно плохо подстраивается под внезапные увеличения в доступной пропуской способности беспроводных сетей, но я бы решал эту проблему пробросом информации из более низкого уровня. Например, расширить концепцию ECN сигналом явно уведомляющим об освобождении полосы. Даже в поле ECN есть неиспользующийся сигнал ECT1, который сейчас интерпретируется как равный ECT0. А городить сложные алгоритмы (BBR - самый сложный из congestion control'ов) в userspace... — ну такое себе.
> P.S. вообще на самом деле нынешний CUBIC+HYSTART+SACK+ECN почти богоподобен.На мобильном линке с движущемся транспорте он подобен разве что каре господня, когда ваше терпение поджаривают на медленном огне, глумясь над процентом утилизации линка.
> Да, оно плохо подстраивается под внезапные увеличения в доступной пропуской способности
Еще хуже когда это были соты с прорехами в покрытии и движущийся юзер, а этот кал удумал что это перегруз сети и ушел в дикие таймауты измеряемые минутами.
> сетей, но я бы решал эту проблему пробросом информации из более низкого уровня.
Ее даже немного пробрасывают вроде, но в целом оно работает дерьмово.
> интерпретируется как равный ECT0. А городить сложные алгоритмы (BBR - самый
> сложный из congestion control'ов) в userspace... — ну такое себе.BBR таки немного получше работает и такой не от хорошей жизни. Но даже он иногда вытворяет черти что, демоенстрируя издевательскую утилизацию линка.
> BBR таки немного получше работает и такой не от хорошей жизни. Но даже он иногда вытворяет черти что, демоенстрируя издевательскую утилизацию линка.Простите, но его даже не ради этого создавали. Я уже не говорю о том, что он и не может выдавать лучший вариант, т.к. его логика работы состоит в том, что периодически пытаться слать больше, чем лезет, и смотреть, что из этого получается. Дропы — не увеличиваем скорость, пролезло — можно больше.
> Простите, но его даже не ради этого создавали.А мне похрен. Если протокол не покрывает столь базовый и массовый кейс, его время в том качестве явно вышло. И настало время решений которые смогут нормально работать и в вон тех случаях. О чем и сабж.
> его логика работы состоит в том, что периодически пытаться слать больше,
> чем лезет, и смотреть, что из этого получается. Дропы — не
> увеличиваем скорость, пролезло — можно больше.И все же...
1) BBR иногда начинает иметь довольно странное мнение о доступном бандвизе линка. Вероятно, его тайминги неудачно стыкуются с перетурбациями линка, или типа того, но он может упереться рогом и юзать целые 20-30% бандвиза. Многопоточные качалки получают +1 пойнт...2) Даже он иногда может уйти в конские таймауты без должного основания. Видимо тоже случается хрень типа того что вот именно в момент перепосылки - соты не оказалось/пакет выпал, и неплохой в целом линк используется... да почти ни на сколько, протокол уходит в туповэйтинг. Если новую конекцию открыть - как из пушки прет, но уже существующая туповэйтит хоть там что. Сказано же, таймер на полчаса и все тут. И потом вы удивляетесь что кто-то хочет это переделать? :)
Есть thin linear timeouts еще, но опять же это какая-то эвристика, довольно наркоманская, и работает она тоже весьма малопредсказуемо и криво. А висящая минуту SSH сессия так то тоже бесит, если что.
> А мне похрен. Если протокол не покрывает столь базовый и массовый кейс, его время в том качестве явно вышло.У тебя каша в голове. Протокол - IP, а BBR, на который ты так наяриваешь, это алгоритм управления перегрузками (congestion control), который был реализован для TCP и для UDP/QUIC. Всё.
Но вообще, ты будешь жрать то, что тебе дают, ибо мнения тех, кто не понимает такой разницы, даже и мысли не проскакивает, чтобы спросить.
> У тебя каша в голове. Протокол - IP,Спасибо Кэп, это подразумевалось. Правда с оговоркой что TCP/IP.
> а BBR, на который так наяриваешь, это алгоритм управления перегрузками (congestion control),
> который был реализован для TCP и для UDP/QUIC. Всё.Еще раз спасибо кэп. Только...
1) В UDP/QUIC гугол во первых сможет его рихтовать в цать раз оперативнее. Хоть в каждой версии браузера.
2) Это можно оперативно раздать всяким юзерам винды и чего там еще, улучшив user experience и для них. Прожать майкрософт до внедрения BBR в ядро NT - малореально.
2) Вменяемые алгоритмы контроля будут заведомо на обоих сторонах линка. В случае TCP - окажется с той стороны какой-нибудь гадский кубик и проч - и таки нагадит. Это ж в 2 стороны работает и мы может вообще ничего слать не хотели. А то что ремота туповэйтила по таймеру минуту - мы и будем дергаться через минуту, когда они расчехлятся вообще пакет прислать.> Но вообще, ты будешь жрать то, что тебе дают, ибо мнения тех,
> кто не понимает такой разницы, даже и мысли не проскакивает, чтобы спросить.Вот то что тебя никто не будет спрашивать с твоим уровнем квалификации - я таки уверен. И кстати вот именно тебя я забуду спросить что мне жрать. То что я жру от тебя вообще никак не зависит.
> В UDP/QUIC гугол во первых сможет его рихтовать в цать раз оперативнее. Хоть в каждой версии браузера.Браузер по определению скачивает данные в основном. Наличие убер-протокола никак не поможет серверу. Надеюсь, ты это в состоянии понять?
> Это можно оперативно раздать всяким юзерам винды и чего там еще, улучшив user experience и для них. Прожать майкрософт до внедрения BBR в ядро NT - малореально.
Ты в курсе, что разработку оригинального BBR бросили? Даже сам Google пользуется чем-то другим с заметно отличной логикой. Если бы он был так хорош, то почему на него не перешли даже в самом HTTP/3?
> Браузер по определению скачивает данные в основном.В целом - да, но...
1) Чтобы сервер вообше что-то послал - сначала это надо запросить! Путем ОТПРАВКИ запроса. Если мы при этом туповэйтили минуту, сервер вообще не знал что мы от него хотим. Надеюсь, ты в состоянии это понять, великий эксперт?
2) Юзеры так то нынче совсем не прочь аплоадить фоточки и видео нефигового размера, и это кажется не даунлоад.
3) Внезапно сервера будут юзать вообще сразу и по дефолту какую-то сильно менее ретарднутую реализацию чем гребаный кубик и т.п. как в TCP. Так что и тут скорее всего мобильно-беспроводным будет лучше. И кстати либы всего этого будут апдейтить и твикать... явно резвее чем некоторые, особенно типа майкрософта.> Наличие убер-протокола никак не поможет серверу. Надеюсь, ты это в состоянии понять?
Спасибо Капитан Очевидность. Нюанс в том что Кэп упустил пару небольших моментов. Без которых все остальное уже не важно.
> Ты в курсе, что разработку оригинального BBR бросили? Даже сам Google пользуется
> чем-то другим с заметно отличной логикой. Если бы он был так хорош, то почему
> на него не перешли даже в самом HTTP/3?Он не "хорош" но "лучше чем другие в этом позорном гадюшнике" при натурных испытаниях в поле. И таки в линуксе он тоже вроде какой-то допатченый и затвиканый. А что там и где "бросили" я не знаю. В линукс кернеле не бросили - иначе он был бы оттуда выпилен как orphaned, вероятно.
Все остальное на беспроводке рабоатет еще хуже. Что-то вменяемое может еще разве что CDG, но он временами делает какие-то очень странные вещи. BBR их так то тоже пытался делать но это починили 3-4 релиза назад.
> BBR их так то тоже пытался делать но это починили 3-4 релиза назадТам из заметного только механизм pacing rate изменили... Оно никак не поменяло логику алгоритма.
> Путем ОТПРАВКИ запроса.И сколько там запрос GET занимает? В запросном канале ВСЕ алгоритмы ведут себя одинаково, они даже не уходят ни разу в потолок. Твой BBR не сможет задетектить рост RTT, а классический Cubic/Reno не получит первого дропа. Оговариваюсь про классический, т.к. сейчас везде (в Linux/Android хотя бы) уже гибридный старт, который сделал из Cubic аналог твоего BBR на начальном этапе или этапе slow start... там меряются RTT "паровозиков" из пакетов. Если же у тебя лежит канал, то обработка этого события ведётся по а) непревышению таймаута соединения (который НЕ ЗАВИСИТ от алгоритма congestion control'а; б) алгоритм сбросит тебя в режим slow start и перезапросит выборочно потерянные пакеты, если включен SACK (включен по умолчанию у всех).
Никакого другого варианта просто нет. Ты банально демонстрируешь непонимание того, как работает сетевой стек.
> А что там и где "бросили" я не знаю.Google его не использует. Он использует некую модифицированную версию (погугли "The Great Internet TCP Congestion Control Census"), отличающуюся заметно от той, что скормили в ядро Linux. Стриминговые сервисы используют Cubic или Reno+RACK, Youtube какую-то модифицированную версию BBR (но не BBRv2), даже на остальных сервисах (не серверах доставки видео) Google использует Cubic.
> Спасибо Кэп, это подразумевалось. Правда с оговоркой что TCP/IP.Нет, милок, именно IP в данном контексте.
> Ее даже немного пробрасывают вроде, но в целом оно работает дерьмово.Протокол проброса информации в студию! А то пацаны-то не знают.
> Протокол проброса информации в студию! А то пацаны-то не знают.Не знаю можно ли называть протоколом кучу эвристики и кой-какие сведения от линуксного ядра. И это, у разных протоколов достаточно разные понятия бывают, их все под 1 гребенку насчет проблем физического уровня причесать так то не очень просто. И какого-то устоявшегося механизма "для всех" нет. Более того - какой-нибудь сотовый модем это в стандартном виде вообще не отдает обычно, ну вот нет устоявшегося интерфейса для этого. Если я любопытный то конечно vendor cmd и прочей отладочной статистикой увижу и уровень сигнала в -dBm, и snr, и что там еще, но вот кернель про это все не очень в курсе.
> Не знаю можно ли называть протоколом кучу эвристики и кой-какие сведения от линуксного ядра.Проброс делается не эвристикой, а просто внесением изменений в протокол IP. Надо выделить новое поле, которое будет кодировать увеличение или уменьшение символьной скорости физического линка. Делать это никто не хочет.
> Проброс делается не эвристикой, а просто внесением изменений в протокол IP. Надо
> выделить новое поле, которое будет кодировать увеличение или уменьшение символьной скорости
> физического линка. Делать это никто не хочет.А смысл этого какой?
1) Беспроводные интерфейсы сейчас довольно адаптивные, за сменой битрейта/модуляции не ржавеет, они могут чуть не попакетно менять, выжимая из линка фактически доступный в этих условиях максимум. Какая ценность значения в хидере? Вафля вообще насколько я помню может указывать конкретный битрейт например пакетам beacons "и пофиг на остальное". То-есть минимум 10 раз в секунду девайс может бросить все, сменить битрейт/модуляцию на потребную для beacon, оформить beacon и заняться дальше передачей данных. Ах да, заподозрить об этом можно просто помониторив статистику вафли или сотового модема. Но видимо это недостойное занятие для гуру.2) Интернет вообще-то сеть, в которой я вообще-то с дофига систем коммуницирую. Допустим у меня пара десятков программ что-то делают по TCP, UDP, а может и еще чему, ICMP например. И чего в хидере вот конкретно этого данного пакета при таком раскладе писать? Бандвиз же не будет целиком вот этой вот ремоте отдан при таком раскладе. Более того - это еще и от того что будут дальше ремотные системы делать зависит. Может, половина через 5 секунд решат что накоммуницировались и отвалят. А может наоборот мег данных пульнут. Это вообще от них зависит.
> На мобильном линке с движущемся транспорте он подобен разве что каре господня,
> когда ваше терпение поджаривают на медленном огне, глумясь над процентом утилизации
> линка.Проблема в том, что ничего лучшего нет, т.к. при отсутствии проброса информации с нижележащего уровня логику определения оптимальной скорости трудно представить кроме той, что уже были реализованы (не только в CUBIC).
> Проблема в том, что ничего лучшего нет, т.к. при отсутствии проброса информации
> с нижележащего уровня логику определения оптимальной скорости трудно представить кроме
> той, что уже были реализованы (не только в CUBIC).Я вообще не представляю себе логику определения скорости линка когда я чешу в поезде и SNR и вообще наличие сот плавает в широком пределе и быстро. ИМХО там только быстрый агрессивный адаптив сможет что-то вменяемое делать.
В принципе CDG и BBR как я понял пытаются ловить перегруз линка по росту RTT. Но это у них довольно криво получается, лажа все равно иногда выходит.
> В принципе CDG и BBR как я понял пытаются ловить перегруз линка по росту RTT. Но это у них довольно криво получается, лажа все равно иногда выходит.Ловить перегруз по росту RTT пытаются уже больше 20 лет и все алгоритмы только на нём (RTT) сливают по своему определению всем остальным по всем параметрам кроме RTT. Caia (CDG) в своём дефолтном состоянии примерно равен BBR. Но, функциональнее, за счёт поддержки ECN (да, Google его не осилил в BBR) и за счёт наличия алгоритма гибридного старта (единственный, кроме Cubic, где он есть). Плюс CDG в том, что уровень его агрессивности (он двухрежимный) легко регулируется в широких пределах (в отличие от BBR), особенно в реализации Linux (родная BSD'шная убога по настройкам и нет гибридного старта). Сломать настройками в CDG мало получится, т.к. в предельном случае ты получишь продвинутый вариант классического Reno со всеми его недостатками. Но по дефолту он больше на low priority алгоритм тянет. Собственно, можешь погуглить, есть академический бенчмарк оценки алгоритмов для задачи низкоприоритетной доставки с низкими задержками. CDG там лидер.
> Ловить перегруз по росту RTT пытаются уже больше 20 лет и все
> алгоритмы только на нём (RTT) сливают по своему определению всем остальным
> по всем параметрам кроме RTT.И тем не менее, они демонстрируют хоть какое-то отдаленное подобие минимального адеквата на беспроводных линках. Впрочем т.к. это с одной стороны - а радости то? Будет у ремоты с той стороны кубик, и будет она туповэйтить каждый раз. А нам может вообще слать ничего не хотелось в это время (совершенно типовой паттерн для групчата: нам шлют сильно чаще чем мы).
> Caia (CDG) в своём дефолтном состоянии примерно равен BBR. Но, функциональнее,
> за счёт поддержки ECN (да, Google его не осилил в BBR) и за счёт наличия алгоритма
> гибридного старта (единственный, кроме Cubic, где он есть).С чисто практической точки зрения, CDG как он есть в ядре линуха, на беспроводных линках периодически вытворяет что-то странное. Заметно чаще чем BBR. В смысле, он порой приобретает странные идеи насчет скоростей с которыми может оперировать и убивает скорость буквально в разы от того что фактически доступно. После чего решительно не желает менять мнение на этот счет, хоть тресни. BBR так тоже в принципе умеет, но впадает в маразм сильно реже и быстрее прочухивается, как правило постепенно приходя в адекват сам за обозримое время.
> Плюс CDG в том, что уровень его агрессивности (он двухрежимный) легко регулируется
> в широких пределах (в отличие от BBR),Однако его странные идеи насчет скорости с которой можно пакеты слать это не очень лечит, а остальное при этом не так уж и важно. BBR же от этого лечить и не требуется в большей части случаев. Вообще, у них был на эту тему клевый баг - но они его загасили. Вроде достаточно успешно.
> особенно в реализации Linux (родная BSD'шная убога по настройкам и нет
> гибридного старта). Сломать настройками в CDG мало получится, т.к. в
> предельном случае ты получишь продвинутый вариант классического Reno со всеми
> его недостатками. Но по дефолту он больше на low priority алгоритм тянет.Как по мне - довольно странная идея для дефолтов. Но меня в нем больше всего напрягало очень странное мнение о доступных скоростях временами. Если конекцию спихнуть и новую открыть, будет шустренько. А если не спихнуть, так и будет на 1/3 скорости линка пехать. Мне что, каждый раз ему такую мануальную терапию делать? Да ну нафиг.
> Собственно, можешь погуглить, есть академический бенчмарк оценки
> алгоритмов для задачи низкоприоритетной доставки с низкими задержками. CDG там лидер.Академики живут где-то в своих кельях, и, кажется, прогуляться с мобилкой или ноутом со сниффером банально не пробовали. В гугле же есть и хипстюки с мобилками, которые могут без обиняков сообщить обитателям келий что получился все-таки булшит.
> Академики живут где-то в своих кельях, и, кажется, прогуляться с мобилкой или ноутом со сниффером банально не пробовали. В гугле же есть и хипстюки с мобилками, которые могут без обиняков сообщить обитателям келий что получился все-таки булшит.Потрудитесь полистать https://researchbank.swinburne.edu.au/file/1560d7f6-6fa3-4ad...
... теперь понимаешь, что твои тезисы на уровне шариковских?
Касательно CDG была защищена докторская пару лет назад с описанием улучшенного алгоритма. По бенчмаркам не офигенный прорыв, но многие недостатки двухрежимного гибридного алгоритма действительно улучшил ощутимо. Но, опять же, в реальной жизни вкатывание и отладка их занимает годы. Напомню, что настраивать надо в первую очередь ту сторону, которая отдаёт данные. Если ты у себя настроишь свой любимый BBR, то результата для клиентской машины будет чуть больше нуля.
> Касательно CDG была защищена докторская пару лет назад с описанием улучшенного алгоритма.Академы пэйперы пишут специфично. Их интересует не то что будет с юзером в поле, а доказательство что они и их тезис - офигенные. Замеры перекошены в эту сторону. Это НЕ ЕСТЬ объективная оценка свойств алгоритма. Иначе wannabe-доктор может степень не получить а это ему не катит. Поэтому в пейперах почти все офигенно. На бумаге.
Так что воспринимать академовские тезисы как истину в последней инстанции может только наивный чукотский юноша. Спору нет, бывают и дельные соображения. Но читать академпубликации стоит с изрядным скепсисом. На практике все может оказаться здорово иначе.
> По бенчмаркам не офигенный прорыв, но многие недостатки двухрежимного гибридного алгоритма
> действительно улучшил ощутимо. Но, опять же, в реальной жизни вкатывание и
> отладка их занимает годы.Ну и вот в реальной жизни реальная имплементация CDG в линуксе умеет делать какую-то хрень и не очень то хочет рекаверится из этого состояния. BBR от таких приколов более-менее пролечили, он все-равно иногда делает хрень но по крайней мере сам очухивается за обозримое время.
Особенно обломно в чем-то типа VPN по TCP - CDG его может удушить до дурной скорости, а потом так и будет тупить пока не рестартанешь, но это ж линк роняет, неудобно. Ах конечно академы про такие кейсы небось не думали. Дада, впн надо по удп и проч, вон тому корп фаеру и прокси это еще расскажи.
> Напомню, что настраивать надо в первую очередь ту сторону, которая отдаёт данные.
Напомню, коммуникации двухсторонние. Чтобы сервер начал что-то отдавать, клиент должен запрос прислать. Иначе кто его там знает что он вообще хотел. В этом месте не совсем тупые персонажи начнут догадываться почему столько внимания числу RTT до начала передачи данных а еще более сообразительные осознают и проблему head of line blocking.
> Если ты у себя настроишь свой любимый BBR, то результата для клиентской машины
> будет чуть больше нуля.Его в идеале с обоих сторон надо - но в случае TCP это довольно трудно достичь в общем случае. Особенно если 1 из клиентов маздай какой-то.
> Академы пэйперы пишут специфично. Их интересует не то что будет с юзером в поле, а доказательство что они и их тезис - офигенные. Замеры перекошены в эту сторону. Это НЕ ЕСТЬ объективная оценка свойств алгоритма. Иначе wannabe-доктор может степень не получить а это ему не катит. Поэтому в пейперах почти все офигенно. На бумаге.Чем публикация тестов Google лучше? Оно даже по критериям академичности не прокатывает.
> Ну и вот в реальной жизни реальная имплементация CDG в линуксе умеет делать какую-то хрень и не очень то хочет рекаверится из этого состояния.Есть такая вещь в параметрах модуля backoff_factor (у реализации BSD она иначе зовётся), попробуй её понастраивать. Можешь начать со значения 1.
> Его в идеале с обоих сторон надо - но в случае TCP это довольно трудно достичь в общем случае. Особенно если 1 из клиентов маздай какой-то.Проблемы масдая не в кубике, а в том, что там отключены tcp timestamp'ы (уточни, так ли это в последних версиях) и джиттер может привести его в состояние повышенного дропа пакетов. Но timestamp'ы и там включаются лёгким движением мыши.
> Еще хуже когда это были соты с прорехами в покрытии и движущийся
> юзер, а этот кал удумал что это перегруз сети и ушел
> в дикие таймауты измеряемые минутами.А как ты себе представляешь обработку такой ошибки? Просто пофантазируй и опиши её техническими терминами.
> А как ты себе представляешь обработку такой ошибки? Просто пофантазируй и опиши
> её техническими терминами.В идеале - качаем данные на полной скорости линка пока он есть, на лету адаптируясь к ее изменениям, быстро, реалтаймно. Ну и не качая пока линка нет.
И в конце концов стремиться надо к чему-то такому. Ну вот "агрессивный" BBR к этому немного ближе ретарднутых уродов типа кубиков всяких. Но даже он иногда делает фиг знает что, у кернела свои заскоки насчет TCP, а юзерам windows этот BBR вообще не раздашь нифига в их маздайный кернел. Я вообще не знаю умеет ли маздайный кернел в разные алгоритмы congestion control.
> В идеале - качаем данные на полной скорости линка пока он есть, на лету адаптируясь к ее изменениям, быстро, реалтаймно. Ну и не качая пока линка нет.Собственно ты словами и описываешь классический алгоритм. Задайся вопросом о том, как алгоритм может знать о скорости линка вслепую, без проброса этой информации снизу. Поверь, там уже далеко ушло от твоего понимания данного вопроса. Почитай потом, например, про проблему медленного старта (это название этапа, если что) и как её пытается решить гибридный старт (а это алгоритм). А дальше, если поймёшь вышеозначенное, уже сам начнёшь читать.
> Ну вот "агрессивный" BBR к этому немного ближе ретарднутых уродов типа кубиков всяких.
Как думаешь, долго можно оставаться нахалом в очереди? Вот так и BBR будет оставаться агрессивным ровно до тех пор, пока коса его агрессивности не столкнётся с аналогичным потоком BBR. Странно, но реальные тесты BBR показывают, что он - говно. Он обгоняет Cubic процентов на 10% только на длинном пинге c увеличенным дропом. Во всех остальных он безбожно сливает (но, оговорюсь, держит низкий пинг при максимальной для него нагрузке). В локальной сети при пинге 1 мс он проседает процентов на 30%! Можешь с лёгкостью проверить это у себя дома, благо tcp_bbr.ko есть сейчас у всех десктопных Линуксов.
> Собственно ты словами и описываешь классический алгоритм."В теории, Петька, мы с тобой миллионеры". Классийческий алгоритм в его чистом виде на беспровлдке на вот это вот по реальному поведению не похож вообще. Огибающая фактически доступного бандвиза и то что он там себе мнил - две громадные разницы. Наверное, секрет в том что уйти в сэмплирование состояния раз в минуту - идея паршивая. Особенно - для беспроводки.
> Задайся вопросом о том, как алгоритм может знать о скорости линка вслепую,
Лучший индикатор который я знаю это RTT. Я вижу вполне прямую корреляцию роста RTT c "линк перегружен" на почти всех типах линков. При том это довольно универсальная метрика. Ну вот например вафля. Может декларить 150Мбит рейт, но сделать 3 перепосылки. Или 75, но влупить за 1 раз. Если любопытно - зазырь что на этот счет Minstrel делает, но он там это делает где-то внутрях себя, а у многих других девайсов эти решения вообще фирмвар принимает по одному ему ведомым критериям. И этот фирмвар может и не вывешивать столько сведений наружу. И это, глядя на статистику minstrel'а я даже не знаю что там номинальной символьной скоростью назвать.
И вот кстати его эвристика работает довольно недурно, но вот у него таки есть доступ к весьма детальному статусу его железки. Специфично для его железки. Экспортировать ЭТО в TCP? А счастьем точно не зашибет? :)
> без проброса этой информации снизу. Поверь, там уже далеко ушло от твоего понимания
> данного вопроса.Мое понимание вон того вопроса можно узреть выше. В отличие от тебя я видел что кажет тот же минстрел в статистике. И как он скорости выбирает. И поэтому напрягаюсь даже просто назвать конкретное число как символьную скорость, чтобы в "хидер вписать" (неизвестно зачем, это же на всю толпу делится малопредсказуемым образом).
> Почитай потом, например, про проблему медленного старта (это название этапа, если
> что) и как её пытается решить гибридный старт (а это алгоритм).
> А дальше, если поймёшь вышеозначенное, уже сам начнёшь читать.А ты посмотри как вообще современные беспроводные интерфейсы работают и включи мозг на тему того что это сеть - так что я не очень понимаю какое число можно вписать в хидер IP как бандвиз и что оно должно означать.
Не, если ты по проводному эзернету, по одной TCP конекции гонишь данные, ок, там понятно. А если это 20 endpoint'ов на прыгающей как блоха беспроводке, да еще зависит от действий ремотных систем, то чего туда писать и какой смысл это все несет?
> Как думаешь, долго можно оставаться нахалом в очереди? Вот так и BBR
> будет оставаться агрессивным ровно до тех пор, пока коса его агрессивности
> не столкнётся с аналогичным потоком BBR.Тем не менее, нахальность обеспечивает ему лучший трекинг "огибающей доступного бандвиза линка". Это довольно быстро фаломорфирующая в беспроводке величина если ты не понял. Варьируется от нуля (сота пропала/линк отпал) до весьма солидных значений в сотни мегабитов и довольно резво.
> Странно, но реальные тесты BBR показывают, что он - говно.
Смотря кто и что тестировал. Кто-то вообще пробовал оттестировать следование алгоритмов огибающей реально доступного бандвиза линка и прикинуть процент утилизации того что было фактически доступно? Это довольно сложно - и я плохо представляю себе как это сделать воспроизводимо.
Понимаешь, когда качается с 1/3 доступной скорости линка или 10-секундный вылет апгрейдится до минутного - мне реально похрен что твои синтетические бенчи рисуют. И победитель для меня тот кто избавит от этого трешака.
> Он обгоняет Cubic процентов на 10% только на длинном пинге c увеличенным дропом.
Ага, блин, а теперь сядь в поезд и забенчи свой долбаный кубик оттуда на ходу. Он при минимальных прорехах покрытия вообще в тыкву превратится и тыквой и останется, навечно. И вместо "интернета" будет "мучение". Нет, даже не диалапного уровня. Правда как это сделать воспроизводимо я не знаю, с моей стороны это некое "усреднение фактического опыта". После вот таких бенчей ты может быть и осознаешь что мне не нравится в кубиках.
> Во всех остальных он безбожно сливает (но, оговорюсь, держит низкий пинг
> при максимальной для него нагрузке).И явно лучше адаптируется к изменчивым линкам. Не обваливаясь в полное дно так легко и просто как кубик.
> В локальной сети при пинге 1 мс он проседает процентов на 30%!
А в беспроводке твой кубик может и на почти бесконечность процентов слить. А сколько процентов записать протоколу почти не качающему данные вообще? :)
> Можешь с лёгкостью проверить это у себя дома, благо tcp_bbr.ko есть сейчас у
> всех десктопных Линуксов.Ну вообще-то я на беспроводных линках как раз прицельно поэкспериментировал с разными и пришел к выводу что там мне больше всего нравится BBR. И знаешь, когда чатик в поезде датыкается на минуту, меня это больше напрягает чем 10 или даже 30% бандвиза в локалке.
Ну и применительно к браузеру - я не думаю что основное применение браузеров это кач файлов с локалки, так что вон те 30% никто не увидит. Зато на беспроводке юзеры будут ощущать себя куда лучше чем сейчас.
Ты демонстрируешь полное непонимание вопроса.> Ну вообще-то я на беспроводных линках как раз прицельно поэкспериментировал с разными и пришел к выводу что там мне больше всего нравится BBR.
Ты с лёгкостью можешь нагуглить целый ряд академических работ (в том числе и от заинтересованных провайдеров), где твой тезис опровергается. Настолько безграмотную хню пишешь, что мне даже неспортивно открывать букмарки на эту тему.
> И знаешь, когда чатик в поезде датыкается на минуту...
Т.е. ты хочешь сказать, что ты можешь в этот самый момент слать UDP, а TCP в этот момент молчишь? Просто, исходник tcp.c не такой большой, покажи мне этот момент в коде.
> Ты демонстрируешь полное непонимание вопроса.Я демонстрирую то что увидел по факту в снифере и статистике сокетов. И если в энных ситуациях факты выглядят вот так - значит вот так. И какая разница что там в пейперах написано при этом?
> Ты с лёгкостью можешь нагуглить целый ряд академических работ (в том числе
> и от заинтересованных провайдеров), где твой тезис опровергается. Настолько безграмотную
> хню пишешь, что мне даже неспортивно открывать букмарки на эту тему.А это не тезис и не теория. Это констатация того что я в снифере и статистике сокетов вижу. Маленький такой нюансик.
> Т.е. ты хочешь сказать, что ты можешь в этот самый момент слать
> UDP, а TCP в этот момент молчишь? Просто, исходник tcp.c не
> такой большой, покажи мне этот момент в коде.Я хочу сказать что tcp уходит в аццкий timer, типа-борясь с типа-congestion. Которым поезд нырнувший под мост и потерявший на сколько-то секунд линк, очевидно, не является. И вот это поведение выглядит довольно идиотским. ИМХО в сабже его пролечат на корню а такие как ты будут пиндеть про "более агрессивный". А что делать, если только так адаптив к свойствам нестабильного быстро меняющегося линка околореалтаймно получается? Остальные потуги там работают как УГ.
> Я хочу сказать что tcp уходит в аццкий timer, типа-борясь с типа-congestion. Которым поезд нырнувший под мост и потерявший на сколько-то секунд линк, очевидно, не является. И вот это поведение выглядит довольно идиотским. ИМХО в сабже его пролечат на корню а такие как ты будут пиндеть про "более агрессивный". А что делать, если только так адаптив к свойствам нестабильного быстро меняющегося линка околореалтаймно получается? Остальные потуги там работают как УГ.Простите, давайте ближе к "телу". Про какой такой таймер вы говорите и в каком сниффере. В идеале я бы ждал скрин, но можно просто терминами. Я пойму.
> Если любопытно - зазырь что на этот счет Minstrel делает...Я тут внезапно понял, что ты не в курсе, как коррекция ошибок в беспроводных протоколах работает, и весь твой трёп сводится фактически к этому.
> Я тут внезапно понял, что ты не в курсе, как коррекция ошибок
> в беспроводных протоколах работает, и весь твой трёп сводится фактически к этому.Ух, конечно-конечно, о великий гуру. Есть правда маленький нюансик. Я таки накодил пару небольших беспроводных линков. Даже с FEC. Это конечно не предел мечтаний, но придает пикантности твоим предъявам.
А если бы ты не был столь глупым то заметил бы еще и что я так то указал две радикально разные ситуации, которые однако обе могут вбить TCP в асфальт. Коррекция ошибок на ситуации "всплеск помех" и "линк вообще вышибло т.к. поезд заехал под мост" реагирует все же довольно по разному.
> Коррекция ошибок на ситуации "всплеск помех" и "линк вообще вышибло т.к. поезд заехал под мост" реагирует все же довольно по разному.А на каком уровне OSI происходит коррекция ошибок?
> FEC
LDPE нормальные люди используют давно.
https://legacy.netdevconf.info/2.1/papers/compare-tcp-highwa... — не читай вывод, смотри на графики. Исследование твоего BBR в дикой природе. Как разница?
Ладно, юзай там свой BBR. Я выше уже писал, что есть категория совершенно полоумных, которые включают его на основании малограмотных советов из бложиков в Medium, а потом рассказывают, что у них кол-во таймаутов уменьшилось, скорости выросли и волосы стали гладкими и шелковистыми. Ещё раз напомню, что это из разряда психологии. У меня был один такой коллега, у которого после обновления дистрибутива сервера быстрее начинали, по его признанию, работать. Эффект держался иногда до месяца. Когда в коллективе появился аудиофил, то они нашли друг дружку. Сила самоубеждения творила с ними страшные вещи. Главное, бенчмарки не проводить грамотные 😆
Я вообще-то на беспроводках тупо поэкспериментировал и посмотрел что лучше всего будет работать. Ну и как-то в среднем по больнице больше всего понравился BBR. CDG лучше дефолтов, но увы, умеет одуревать и необоснованно душить скорость - и что хуже - не очень то вытряхиваясь из этого состояния за обозримое время.Пролюбить 10% бандвиза если это дает взамен что-то внятное типа уменьшения бесящих полных клинчей линка? Окей! Пролюбить 70% бандвиза? Надолго? После какой-то редкой но меткой последовательности событий? Не, вот это - не окей, когда оно потом само не очень то и рекаверится. Может даже в теории это быть и не должно, а на практике это таки конкретный факап, нагибающий всю идею.
> Я вообще-то на беспроводках тупо поэкспериментировал и посмотрел что лучше всего будет работать.Люди давно поэкспериментировали в реальных и виртуальных условиях и составили карту, где BBR может выигрывать. Это линки с большим равномерно (упор на это слово) распределённым дропом с пингом выше 100 мс и скоростью физ. интерфейса 200+. В остальных случаях оно или равно Cubic или гораздо хуже его (линки со скоростью меньше 10 мс).
> Пролюбить 10% бандвиза если это дает взамен что-то внятное типа уменьшения бесящих полных клинчей линка?
Создать "шторм" затупов на 30+ секунд ни один из алгоритмов не может в принципе. Он может перейти в режим slow start (и это будет видно в статистике), но это как начать соединение заново (в плане вычерчивания графика скорости).
> ... подобен разве что каре господня (-ня? -ней?), когда ваше терпение поджаривают на медленном огне, глумясь...Вы чёрта в Господом даже умудрились спутать )))
Раб божий, что ты забыл в интернете?
> Раб божий, что ты забыл в интернете?Он просто не понял мой тонкий отсыл что TCP поверх беспроводки - это просто срань господня. С BBR немного меньшая срань, но тоже далеко не предел мечтаний.
Всё это совершенные мелочи по сравнению с проблемами tcp.
> Всё это совершенные мелочи по сравнению с проблемами tcp.Ограничения TCP известны и изучены. CUBIC/Reno и все эти SACK, ECN, гибридный старт годами отлажены и отполированы. А придуманный, пускай даже и в Google, BBR оказался переусложнённым и ничем не выдающимся с функциональной стороны. Зато с кучей новых проблем...
Отлажены, отполированы, но не работают.И работать не будут. Пока промежуточные роутеры знают что-нибудь про состояние потока, они всегда будут что-нибудь портить.
> И работать не будут. Пока промежуточные роутеры знают что-нибудь про состояние потока,
> они всегда будут что-нибудь портить.Простите, а какое отношение congestion control и selective acknowledgment имеют к роутерам? Просто интересуюсь, как вы представляете их работу.
>простите, а какое отношение congestion control и selective acknowledgment имеют к роутерам?
> Просто интересуюсь, как вы представляете их работу.Если количество пакетов не совпадает с количеством ack'ов, один из NAT'ов по дороге с большой вероятностью дропает коннект.
Не говоря уже о том, что когда коннект выглядит нетипично на DPI, его приоритизируют ниже.
> Если количество пакетов не совпадает с количеством ack'ов, один из NAT'ов по
> дороге с большой вероятностью дропает коннект.Мне вот тут интересно стало, а что такое в твоём понимании TCP window scaling?
> Не говоря уже о том, что когда коннект выглядит нетипично на DPI,
> его приоритизируют ниже.Бред сивой кобылы. А приоритет выражается в понижении приоритета где? В изменении значения DSCP? Так его 4 из 5 провайдеров нижнего уровня вообще режут на первом же хопе.
> Мне вот тут интересно стало, а что такое в твоём понимании TCP
> window scaling?Какая-то TCP опция, которую файрволы по дороге переписывают так, как им заблагорассудится.
> Бред сивой кобылы. А приоритет выражается в понижении приоритета где? В изменении
> значения DSCP? Так его 4 из 5 провайдеров нижнего уровня вообще
> режут на первом же хопе.Детали работы DPI не публикуются. Эмпирически приоритизация очень хорошо заметна. Например, RTT на 22 и 443 порты в три раза меньше, чем на все остальные.
> Какая-то TCP опция, которую файрволы по дороге переписывают так, как им заблагорассудится.Очень глубокое понимание работы протокола. Кстати, именно поэтому кол-во ACK'ов не совпадает с кол-вом пакетов, но на каждый пакет есть ACK! Представть, если бы в потоке в несколько десятков гигабит надо было тут же на каждый пакет отсылать ACK. Интересная бы производительность у протокола тогда была. Вот такая вот, на первый взгляд, противоречивая фигня. Вообще попробуй разобрать любую сессию в Wireshark ради примера. Сейчас многое изменилось со времён оригинального TCP и от учебника и википедии отличается )))
> которую файрволы по дороге переписывают так, как им заблагорассудитсяНет в абсолютно подавляющем большинстве.
>> которую файрволы по дороге переписывают так, как им заблагорассудится
> Нет в абсолютно подавляющем большинстве.Sweet summer child. Всё, что можно переписать, переписывается. Не переписывается только то, что зашифровано, и именно поэтому quic по-умолчанию зашифрован.
> Sweet summer child. Всё, что можно переписать, переписывается.А кроме как языком доказать сможешь? Ну, начнём с того же TCP window scaling (раз уж его упомянули). Я просто к чему это говорю, просто эта вещь ломает работу канала. Я даже и бородатый баг с разбором проблемы среди разработчиков ядра могу привести алаверды на доказательство твоего тезиса.
> Не переписывается только то, что зашифровано, и именно поэтому quic по-умолчанию зашифрован.
Что там кроме payload защифровано, сказочник? Там та же логика управления каналом, что и у TCP, только реализованo поверх UDP. Даже алгоритмы носят имена идентичные — CUBIC/Reno/BBR :)
> Что там кроме payload защифровано, сказочник? Там та же логика управления каналом,
> что и у TCP, только реализованo поверх UDP. Даже алгоритмы носят
> имена идентичные — CUBIC/Reno/BBR :)21.1.1.4. Parameter Negotiation
The entire handshake is cryptographically protected, with the Initial
packets being encrypted with per-version keys and the Handshake and
later packets being encrypted with keys derived from the TLS key
exchange. Further, parameter negotiation is folded into the TLS
transcript and thus provides the same integrity guarantees as
ordinary TLS negotiation. An attacker can observe the client's
transport parameters (as long as it knows the version-specific salt)
but cannot observe the server's transport parameters and cannot
influence parameter negotiation.Connection IDs are unencrypted but integrity protected in all
packets.This version of QUIC does not incorporate a version negotiation
mechanism; implementations of incompatible versions will simply fail
to establish a connection.
На этом разговор и закончим, мне всё ясно.
> Детали работы DPI не публикуются.На этом можно было бы и закончить гадать...
> Например, RTT на 22 и 443 порты в три раза меньше, чем на все остальные.
А вы уверены, что софт, торчащий на тех портах, не генерирует задержку банально, которую вы упорно измеряете? И дело совершенно не в DPI, а в том, что задержка генерируемая Nginx, закономерно отличается от OpenSSH 😄
>> Детали работы DPI не публикуются.
> На этом можно было бы и закончить гадать...Можете закончить, а мне нужно данные передавать.
>> А вы уверены, что софт, торчащий на тех портах, не генерирует задержку
> банально, которую вы упорно измеряете? И дело совершенно не в DPI,
> а в том, что задержка генерируемая Nginx, закономерно отличается от OpenSSH
> 😄Я уверен, потому что я измерял задержку до RST заблокированных портов
> Я уверен, потому что я измерял задержку до RST заблокированных портовЖду однострочник, с нетерпением.
>> Я уверен, потому что я измерял задержку до RST заблокированных портов
> Жду однострочник, с нетерпением.Однострочники называются nping и hping3.
я так и знал 😆
> я так и знал 😆И что ты знал, болтун? Какая разница, чем слать пакеты?
> Однострочники называются nping и hping3.Хорошие, кстати, однострочники если хочется потыкать пакеты палочкой в нестандартном виде.
Какие проблемы то?
В начале браузеростроители ограничивают количество TCP соединений типа чтобы сервера не перегружать, а потом гуглы от скуки изобретают квик, где типа по одному соединению всё передаётся, просто хитро мультиплексируется.
А суть то в том, что они эти самые 100500 TCP соединений упихнули внутрь своего udp, и теперь сравнивают и делают выводы.На практике они конечно добились эффекта, но не за счёт мультиплексирования "каналов" внутри, а за счёт того что срезали все лишнее что им было не нужно и поменяв приоритеты.
Те был TCP, потом с помощью TLS его сделали секурным и не сломали ничего.
Тут пришёл гугл и сказал что у нас тут шифрование, потому пакеты должны ходить теперь только так, и вот благодаря этому вравниваю размера пакетов у нас профит.И так во всём.
Но по сути их работа не добавила ничего нового и не создала новых ценностей.
Вот DHT, uTP - добавили и создали.
> Какие проблемы то?Проблема в том, что скорость потока зависит от процента потерь пакетов (обратно) экспоненциально (тогда как должна линейно). А в мире есть миллиарды человек, которые сидят на соединениях, у которых 30-40% потерь -- норма жизни.
>Вот DHT, uTP - добавили и создали.
Они легко детектируются и банятся.
> Они легко детектируются и банятсяПортить вообще довольно просто. На крайний случай можно кабель вырвать вместе с портом.
> А суть то в том, что они эти самые 100500 TCP соединений
> упихнули внутрь своего udp, и теперь сравнивают и делают выводы.Ну так это...
- Пайплайнинг в тупом его виде HTTP/1.x жестко клевал по head of line blocking.
- Сетап новых соединений для уменьшения того эффекта может занять ощутимое время.В целом вебпага грузилась как уг и приходилось делать костыли типа впихивания всех ассетов в 1 файл ради скорости.
> На практике они конечно добились эффекта, но не за счёт мультиплексирования "каналов"
> внутри, а за счёт того что срезали все лишнее что им
> было не нужно и поменяв приоритеты.И еще убрав из процесса горе прожектеров с их congestion control непригодным для беспроводки.
> Те был TCP, потом с помощью TLS его сделали секурным и не сломали ничего.
Но roundtrip'ов добавили - так что вон то еще усугубилось. Оно наверное круто в датацентре с пингом до сервака менее 1мс, а если в поле с мобилкой с пингом 150 мс?!
> Но по сути их работа не добавила ничего нового и не создала новых ценностей.
Кроме того что это сможет наконец нормально работать по беспроводке.
> Вот DHT, uTP - добавили и создали.
Они так то о другом. Хотя uTP в чем-то похож, но мультиплексированием не занимается и заточен на именно фоновый низкоприоритетный трансфер, даже если надо немного пожертвовать скоростью.
У тех серьёзных ребят, у которых этот протокол внедрён и которым от него профит, это всё ведь не юзерспейсом обрабатывается, а специализированным аппаратно-программным комплексом.
> У тех серьёзных ребят, у которых этот протокол внедрён и которым от
> него профит, это всё ведь не юзерспейсом обрабатывается, а специализированным аппаратно-программным
> комплексом.Шта?
какой-нибудь Intel Quick Assist
> какой-нибудь Intel Quick AssistТы действительно полагаешь, что он имеет какое-то отношение к TCP/UDP или HTTP?
>> какой-нибудь Intel Quick Assist
> Ты действительно полагаешь, что он имеет какое-то отношение к TCP/UDP или HTTP?* какой-нибудь аналог Intel Quick Assist
> выносом операции ресэмплинга звука из ядра в pulseaudio.Вообще-то ядерная часть ALSA никогда не умела делать ресэмплинг, этим всегда занималась юзерспейсная библиотека. Ядерная часть могла только переключить DAC в режим воспроизведения другого формата, но это возможно и через pulseaudio (но выключено по умолчанию).
Спасибо за поправку. Tы прав, это делала libalsa.
Самое время беспокоиться о миллисекундах соединения, когда сотни файлов качаются несколько минут.
> Самое время беспокоиться о миллисекундах соединения, когда сотни файлов качаются несколько
> минут.Именно об этом и стоит беспокоиться. Открой режим отладки в своём браузере и посмотри, сколько соединений открывается для загрузки главной на любимом новостном ресурсе или в социалке. В устанавливаемых соединениях практически никогда не происходит события достижения лимита физической пропускной способности сети и миллисекундные задержки и накладные расходы на установление параметров соединения, DNS запросы выливаются в неторопливое открытие "глагне" даже на гигабитном канале.
P.S. но лично я бы сосредоточился на допиливании HTTP/2 и TCP. Да-да, он, TCP, до сих пор в режиме постоянной доработки и научных статей поток не иссякает на эту тему.
Расскажи зачем тебе мгновенное открытие глагне? Как это изменит твою жизнь и как вообще на этом можно заработать?
> Расскажи зачем тебе мгновенное открытие глагне? Как это изменит твою жизнь и
> как вообще на этом можно заработать?Мгновенно ничего не бывает. Загрузка глагне в несколько секунд — стыд и срам, но это проблема конeчно же на 95% веб-разработчика, а не инженера, разрабатывавшего HTTP/x
Да нет тут проблемы быстрая загрузка первой страницы никому не нужна.
> Да нет тут проблемы быстрая загрузка первой страницы никому не нужна.Конечно нет, все оптимизаторы должны идти нафиг. Рапид-девелопмент и быдлокод уже победили.
Ты так говоришь как будто это что-то плохое. Пипл то хавает, всё остальное это преждевременная оптимизация.
Вы бы знали, что пипл хавает в Африке, за отсутствием нормальной еды...
А пользователи бразуеров разве чем-то хуже в плане адаптируемости к низкокачественным кормам?
Им норм гуманитарка заходит в виде SPA. И им вот прям вот совсем пофиг что первоначальная загрузка SPA занимает несколько секунд в виде js css блоба размером на несколько мегов. Зато потом все быстро и без переходов загружается. В отличии от того же серверного рендера, который и тормозной и ресурсы сервера кушает почем зря.
> Расскажи зачем тебе мгновенное открытие глагне?А вот и ненужнисты подъехали. Тебе не нужно — не пользуйся. Всё просто!
Просто дали троллям задание оправдать блокировку протокола , а знаний на это у них не хватает . Потому и получается лекция из "Карнавальной ночи" , спор с ними - пустая трата времени .
Гугель все правильно делает медленно спускается и покрывает всё стадо.
Это только из-за того что все разбросано по разным серверам-ip-доменам даже когда в этом нет нужды, технически достаточно одного DNS запроса и одного HTTP/2 соединения.
> Именно об этом и стоит беспокоиться. Открой режим отладки в своём браузере и посмотри, сколько соединений открывается для загрузки главной на любимом новостном ресурсе или в социалке.Да, единственное решение - HTTP/3! :D
О каком развитии tcp Вы говорите если даже tcp fast_open выпилили из ВСЕХ браузеров ?Ну поддерживает у меня сайт tcp fast_open и я отслеживаю подключения с использованием этой фичи - так вот 2 (ДВА) раза за последний год это случилось.
Разумеется могу curl-ом с соответствующими ключами дёргать свой сайт и затем тащиться в Wireshark как быстро у меня повторные соединения происходят (0-RTT early_data тоже включено разумеется) :)))
Какое отношение браузеры имеют к TCP?
А, так Вы о сферических конях в вакууме писали - ну тогда понятно.Практическое применение если не интересует, то тогда да - tcp развивается :)
> А, так Вы о сферических конях в вакууме писали - ну тогда
> понятно.Браузер не реализует никакую часть из TCP, тот же multipath и congestion control активно пилят и оптимизируют. Другой вопрос совершенно в прикладном софте. Про тот же ECN я писал выше, реализовано и отлажено уже чёрт знает сколько лет, действительно полезная вещь, но убедить включить её в роутерах нереально. Microsoft и их страдания по TCP timestamp'ам вторым примером...
> Практическое применение если не интересует, то тогда да - tcp развивается :)
Ну, например, вкатили всем TCP hybrid start, сколько человек об этом знает и заметило? Однако же очень полезная вещь, которая исправляет один из родовых недостатков TCP.
> Браузер не реализует никакую часть из TCP, тот же multipath и congestion
> control активно пилят и оптимизируют.И как, много его уже в допустим винде напилили? А то их так то довольно много и они так то тоже хотят быструю загрузку вебпаг.
> И как, много его уже в допустим винде напилили?Вообще не в курсе, у меня вокруг разные сорта *nix'ов.
Сразу на HTTP 102 буду обновляться.
Правильна, нэ тарапися.
HTTP уже устарел. magnet:?xt=urn: в массы!
>HTTP уже устарелНе устарел, а вконец изгадился (точнее, заcрали)
>magnet:?xt=urn: в массы!
Пора мигрировать в Gemini. Для начала уговорить OpenNet открыть в Gemini зеркало
> Для начала уговорить OpenNet открыть в Gemini зеркалоА было бы здорово, кстати.
> Для начала уговорить OpenNet открыть в Gemini зеркалоДа сразу Youtube проси, не разменивайся на мелочёвку.
Открой для себя peertube и другие альтернативы. Там и ненужного поменьше.
"Фатальный недостаток" TCP уже много лет не даёт покоя этим людям...
Попугаи на картинках в презентации порадовали - 300ms на инициализацию TLS соединения поверх TCP, ага...
Подозрительно круглые цифры наводят на мысль...
>Возможность мгновенно установить соединение (0-RTT)Эту технологию Гугл пытался еще в HTTP/2 продавить, несмотря на массовую критику со стороны защитников privacy. Сокращение раундов согласования при установлении соединения достигается за счет сохранения на стороне браузера что-то вроде уникальных cookies, только не для HTTP, а для TLS уровня. В этом случае изощренные технологии fingerprinting'а для трекинга юзеров становятся совершенно не нужными - браузер сам говорит серверу: "Я такой-то такой-то. Помнишь меня?". Есть еще большой "плюс" технологии: в отличие от HTTP cookies, идентификатор 0-RTT не подлежит фильтрации.
В большинстве браузеров 0-RTT уже реализован, но выключен по умолчанию (кроме Chrome, естественно). Ну а теперь 0-RTT станет частью веб стандарта HTTP/3.0. Критики идут лесом. Ура, товарищи!
Как обычно в случае передовых технологий от Гугла, "бойтесь данайцев, дары приносящих"
> за счет сохранения на стороне браузера что-то вроде уникальных cookies, только не для HTTP, а для TLS уровняА как долго он хранится? Так то внутри TCP TLS сессии тоже есть идентификатор — ключ шифрования называется :-)
> А как долго он хранится? Так то внутри TCP TLS сессии тоже
> есть идентификатор — ключ шифрования называется :-)Он просто не понял в протокол, но разродился речугой, а люди вон даже лайкают... — всё как везде, людям заходят эмоции, а не технические подробности и предложения.
>Он просто не понял в протокол, но разродился речугойИстину глаголишь.
Произнеси это еще раз перед зеркалом.
😃 я оставлю этот нетехнический выпад без ответа.
>оставлю этот нетехнический выпад без ответаАккуратно свалил :-)
"Он просто не понял в протокол" - это был очень технический и подробно аргументированный выпад.
(я уже говорил, что прежде всего надо смотреться в зеркало :-)
> Аккуратно свалил :-)Почитай выше, я везде использую официальную терминологию. А ты используешь какие-то "SSL ticket". Я уже не говорю о том, что у тебя каша в голове. HTTP/2 не предполагает обязательного шифрования, а 0-rtt есть в HTTP/3 и в TLS 1.3...
Разбирать процедуру TLS 1.3 пошагово? Просто мне в википедию для этого не нужно лезть. Я по памяти её среди ночи расскажу.
P.S. 0-rtt в Firefox включен уже не помню сколько лет.
> 0-rtt в Firefox включен уже не помню сколько лет.Я тоже не помню сколько лет назад я включил в user.js
user_pref("security.tls.enable_0rtt_data", false);
>> 0-rtt в Firefox включен уже не помню сколько лет.
> Я тоже не помню сколько лет назад я включил в user.js
> user_pref("security.tls.enable_0rtt_data", false);Зачем, что конкретно ты таким способом пытаешься решить?
Надеюсь, что TorProject для тебя авторитетный источник и ты не считаешь, что у них "каша в голове"https://gitlab.torproject.org/legacy/trac/-/issues/32364
Disable 0-RTT protocol in browser. It is a major tracking vector.
security.tls.enable_0rtt_data in about:config. Also disable in other places.
Нет, это не самый авторитетный источник для меня. Далеко не самый. Давай, я тебе немного помогу с аргументацией: http://elpub.bib.uni-wuppertal.de/servlets/DerivateServlet/D...Раз уж ты не можешь сформулировать толково мысль, то я тебе укажу на очевидную ошибку в первом твоём заявлении "Эту технологию Гугл пытался еще в HTTP/2 продавить, несмотря на массовую критику со стороны защитников privacy". Это ошибочно хронологически (порядок появления стандартов HTTP/2, HTTP/3 и TLS1.3 глянь) и технически.
>у тебя каша в головеОпять очень технический выпад. А вся аргументация сводится к "мне в википедию для этого не нужно лезть. Я по памяти её среди ночи расскажу"
Ну сколько можно?
Перед тем, как выносить о ком-то суждения, посмотри в зеркало и скажи себе: "Я не единственный на Земле знаю TLS1.3 по памяти" (от звездной болезни очень помогает)
> Опять очень технический выпад.Я тебе предлагаю сформулировать тезис технической терминологией. Всё, что ты родил до сих пор, — это каша из HTTP/2 и привязанного почему-то к нему 0-rtt из TLS 1.3, что банально хронологически неверно, т.к. последний появился даже позже QUIC. Когда ты сформулируешь тезис, возможно мы продолжим разговор об обоснованности твоих фобий касательно трекинга. Там есть момент, который, очевидно, ты не понял или, что вероятнее, прочитал об этом на каком-то medium бложике.
>мы продолжим разговор об обоснованности твоих фобий касательно трекингаНе будем.
Выше я высказал свое мнение и даже привел ссылку на "medium бложик". По мне - этого достаточно.
А теперь я аккуратно сваливаю :-)
Тема privicy очень индивидуальна и субъективна. Каждый сам для себя решает.
> А теперь я аккуратно сваливаю :-)Я тоже пойду розы почеренкую лучше )))
>внутри TCP TLS сессии тоже есть идентификатор — ключ шифрования называется :-)Странно, что приходится подробно объяснять :-(
Ключ шифрования сессии - одноразовый и коротко живущий, в процессе длинной TLS сессии может несколько раз перегенерироваться.
SSL ticket (название еще не устоялось) - долгоживущий идентификатор (по крайней мере 24 часа), используемый между разными TLS сессиями при коннекте к одному и тому-же сайту (в этом и есть фишка 0-RTT). К ключам шифрования сессии отношения не имеет.
> долгоживущий идентификатор (по крайней мере 24 часа)В протоколе стандартизировали то, что сейчас каждый хайлоад костылит у себя самостоятельно — кэширование TLS-сессий. Если твоя цель избежать слежки — иным словами быть анонимным в интернете — начинать надо не с HTTP/3, а с того, что ты логинишься на одни и те же 3½ сайта в одно и то же время со своего домашнего интернета.
> кэширование TLS-сессийНе знаю, что это значит в реальности, но звучит, как одуршлачивание.
> кэширование TLS-сессийОн не владеет терминологией и смутно знает о том, для чего какой стандарт. Я предположу, что кэшированием TLS он называет PSK из TLS 1.3 %)
> Он не владеет терминологией и смутно знает о том, для чего какой стандарт.
> Я предположу, что кэшированием TLS он называет PSK из TLS 1.3 %)Нет, кэшированием TLS-сессий я называю… кэширование TLS-сессий. Тебе не приходилось в процессе ОВЛАДЕВАНИЯ терминологией сталкиваться с RFC5077?
А теперь попробуй натянуть свой тезис на вышесказанное и я поржу на кульбиты этой логики )))
> Для видеосервисов, таких как YouTubeСначала будем использовать тиски для закручивания гаек, а потом начнём вырезать в губках выемки под шестигранник, чтобы было удобнее. Сначала возьмём неподходящий инструмент, а потом будем его рихтовать под задачу, для которой он изначально не был приспособлен. Сначала будем гнать видео по HTTP, который не для этого придуман, а потом начнём выдумывать новый HTTP, приспособленный для передачи видео.
Ага, яркий пример айтишизы. Все время должен быть прогресс ради прогресса. Здорово че.D
> прогресс ради прогрессаЕсли бы.
В крупных корпорациях нынче прогресс только ради премий манагерам. А выдаются они за выведенные на рынок новые проекты, причём независимо от их качества, удобства и даже прибыльности (достаточно вспомнить "кладбище проектов Google" - а ведь за запуск этих проектов кто-то когда-то тоже получал премии).
Ютуб давным давно готов избавится от "неподходящих инструментов", останавливают юзеры, использующие всякое старье, сколько шуму было когда перестали отдавать видео по http без шифрования.
Где ж он "избавляется"? HTTP был придуман для передачи документов, которые необходимо доставить без искажений (отсюда использование TCP), тогда как для передачи видео потеря кадра некритична (кроме случаев, когда видео надо передать и сохранить, но Ютуб с сохранением видео, как известно, очень не дружит). Вместо того, чтобы просто уйти от HTTP при передаче видео, Гугл превращает HTTP в уродливого тянитолкая, используемого сразу для двух принципиально разных задач.
Честно говоря зная Гугл я больше удивлен тому что они до сих пор не шифруют все видео с помощью EME. Тут кончено возможно что кто-то начнет возмущаться, но авторам быстро объянят что это "чтобы плагиаторы не могли тырить ваши драгоценные вертикальные видосы с телефона" и все успокоятся. Ну может максимум оставят где-то в глубине настроечку "да, я лошара и хочу чтобы кто угодно мог украть моё видео", откkючающую EME.
Смысла шифровать общедоступные видео мало. Шифрование абсолютно ничему не помешает, но съест уйму вычислительных ресурсов и у зрителей и у гугла.
>Шифрование абсолютно ничему не помешаетПомешает узнать что этот конкретный клиент смотрит это конкретное видео. С шифрованием можно узнать только то, что этот конкретный клиент смотрит какое-то видео.
Kuromi, говорил про EME и пиратство. Мой ответ был именно в этом контексте.
> Сначала будем гнать видео по HTTP, который не для этого придуман, а потом начнём выдумывать новый HTTP, приспособленный для передачи видео.Обычный эволюционный итерационный процесс. Невозможно сразу заранее всё придумать навсегда.
Вообще-то, то, что оно должно быть на основе UDP, можно было понять ещё тогда (а значит, HTTP, который работает поверх TCP, уже однозначно не подходит).
> можно было понять ещё тогдаЧто ж ты не понял и не реализовал? Только не говори, что был занят комментированием новостей на опеннете.
Вот ещё я такой гадостью занимался бы.
Мне и сейчас хочется убивать долбодятлов, которые выкладывают ролик "как вскрыть корпус ноутбука" с музончиком и приглашениями подписываться, вместо краткой инструкции, которую можно пробежать глазами за несколько секунд.
Видео в браузере - это мерзость для одноклеточных.
Я по видео в браузере научился:1. ремонтировать и обслуживать автомобиль — менять масло, свечи, колёса, бортивать, пользоваться балансировщиком, дебажить проводку
2. водить автомобиль в тех условиях, про которые не учат в автошколе — экстремальные/неблагоприятные погодные явления, выход из заноса, комфортная езда в трафике/по городу, экономичная езда на большие расстояния, буксировка, езда с прицепом
3. парковать автомобиль с минимальными зазорами под любым углом, с прицепом и без
4. завязывать пояс так, чтобы при спраррингах не развязывался
5. разогреваться перед тренировкой и растягиваться после
6. всей базовой дерево- и металлообработке, вручную и с помощью инструмента
7. возводить простые конструкции из деревянного бруса
8. ухаживать за отдельными деревьями и за лесом в целом
9. тушить бытовые пожары подручными средствами
10. водить фуру (13 передач, охренеть)
11. водить трактор и пользоваться навесным оборудованием
12. прицельно стрелять из пистолета, ружья и винтовкиЭто из того, что вот прямо с ходу в голову пришло. Про бесплатные лекции ведущих универов мира по любым предметам наверное и вовсе не стоит говорить — это, видимо, вовсе для вирусов.
13. летать на боевом вертолёте.
14. летать на боевом истребителе и выходить победителем в бою.
15. летать на космическом корабле с варп-двигателем.
16. выучил несколько инопланетных языков.
Тут ты меня с голосами в твоей голове перепутал.
Это, конечно, очень хорошо, рад за тебя, но всему этому можно было научиться по книгам или статьями Интернете.
У текста есть огромное преимущество перед видео - в видео ты в каждое определённое мгновенье получаешь только ту информацию, которая в данный момент отображена в кадре, тогда как имея перед глазами текст, ты можешь найти нужное место, не дожидаясь, пока диктор дочитает до него (отмазки про слайдбар не катят, искать нужный момент ползунком - это то ещё удовольствие).
Есть ещё "нюанс". Выкладывать обучающее видео - это для тех, кто формулирует свои мысли на уровне "вот эту штуку надо вставить вот сюда и провернуть до щелчка (опосля чего по два раза дергануть за пимпочки)". Такое непростительно ни преподу "ведущего универа", ни автомеханику из сервиса в арендованном гараже. А если есть внятный текст - почему они его не публикуют, а вынуждают тратить время на просмотр видео?
> можно было научиться по книгам или статьями Интернете.Машина не заводится, но ничего, родная, погоди пару дней, я книжку прочитаю, тогда и поедем детей из школы забирать. Ага.
> У текста есть огромное преимущество перед видео
У текста нет преимуществ перед видео (обратное тоже справедливо, впрочем). Оба полезны, оба нужны и оба используются для обучения.
> Есть ещё "нюанс".
Этот нюанс называется «соломенное чучело» и является инструментом демагога.
помнится когда убунта пошла в массы, инет наводнился статьями - как установить что-то на линукс, и сводился к 1 строке - "апт инсталл что-то", порой включая гайд по установки убунты того же качества.так уж вышло, что человечство генерирует больше дерьма чем чего-то другого, и большенство кроме него не генерируют ничего, толково составленная книжка, как мануал, имеет содержание и не требует почтения от корки до корки, но бывают, и даже часто, совершенно бестолковые книжки, и мануалы и видосики особенно, в стиле мама посмотри я установил убунту или покакал, непонятно.
> Машина не заводится, но ничего, родная, погоди пару дней, я книжку прочитаю
книжку надо читать заранее, представь себе, не машина, а самолет..
Уважаемые пассажиры, мы падаем, сейчас пилот срочно гуглит что делать, ага..
> так уж вышло, что человечство генерирует больше дерьма чем чего-то другогоОткуда вы дерьмо на ютубе берёте-то? Специально ищете?
> книжку надо читать заранее,
Так уж вышло, что заранее я другую книжку читал, в которой написано было как заработать денег на машину и её техобслуживание, а две одновременно читать я не умею. Пришлось взять на себя оправданный риск.
> представь себе, не машина, а самолет..
Зачем представлять? Зашёл к соседу и спросил у него какую книжку он читал, чтобы двигатели у A380 ремонтировать в падении. Он сказал, что название книжки дословно не помнит, но суть сводится к техникам аварийной посадки на разные поверхности. Как это относится к реалиям моей жизни, не потрудишься описать?
> Обычный эволюционный итерационный процесс.Этих протоколов передачи видео и прочих (реалтайм) данных - хоть пруд пруди. Но почему-то избрали не самый прямой, точнее, самый кривой путь. Значит, это извращение кому-нибудь нужно?
Нука, расскажи как правильно надо передавать видеопоток по сети?
Adobe Flash умел передавать правильно. В HTML5 все увы, разучились.
RTSP? Ну так его пользовали чтобы файлики с видео тырить было сложнее.
Вон помню когда Ютуб переходил на HTML5 Video, Рутуб (ага!) переходил на RTSP. Первым заметили это сервисы "скачать ролик с Рутуба". Скачка работать перестала, так же как и всяческие плагины для перехвата, а сайтики для скачки через месяцок позакрывались.
Была там одна софтина вод Виндовс, котоаря таки могла, но заморчоенный больно процесс был.
Софтина называется VLC и есть не только под винду :). А делается это так: открывается поток (хоть там какой) как обычно, но врубается еще и транскод/запись а не только вывод на дисплей. И оно прекрасно складирует поток на винч. На мощном компе можно сразу же и перекодировать, на маломощном лучше не стоит.
> Софтина называется VLC и есть не только под винду :). А делается
> это так: открывается поток (хоть там какой) как обычно, но врубается
> еще и транскод/запись а не только вывод на дисплей. И оно
> прекрасно складирует поток на винч. На мощном компе можно сразу же
> и перекодировать, на маломощном лучше не стоит.Не не не, это был точно не VLC. Будь все так просто я бы запомнил. Та софтина была именно под тыринг RTSP заточена, хотя не исключаю что там могда быть какая нибудь обвязка вокруг опенсорца.
В любом случае VLC-ом это тоже тырится, собственно половина его юзежа это запись поточного видео, по довольно разным протоколам.
> Нука, расскажи как правильно надо передавать видеопоток по сети?https://www.rfc-editor.org/rfc-index.txt
Поиском по текстовому файлу пользоваться умеешь?
Абсолютное ненужно, ровно как и ipv6 и http/2.0
Расскажи, каково это — сидеть в локалочке за натом всю жизнь и никогда даже не понюхать настоящий интернет?
Очень удобно, особенно когда NAT избавляет от необходимости нюхать чьи-то пуки.
Про фаерволл слыхал? Он у тебя «Брандмауэр» называется ещё.
> Про фаерволл слыхал? Он у тебя «Брандмауэр» называется ещё.В моём зоопарке он по-разному называется. В том числе и "Брандмауэр". И что?
Ничего. Научись им пользоваться и не рассказывай глупости про НАТ.
Ничего что все современные фаерволы имеют в своей основе NAT? Ибо нет трансляции - нет соединения.
> Ничего что все современные фаерволы имеют в своей основе NAT? Ибо нет
> трансляции - нет соединения.Кто-то явно путает stateful firewall и NAT. Более того - в v6 вообще трансляция обычно экзотика. А stateful файрвол забацать вполне можно.
Cisco ASA же
Кто сказал что английское слово файерволл лучше немецкого брандмауэр?
А кто тебе давал гарантии что при ipv6 твой провайдер даст тебе нюхать интернеты напрямую?
> А кто тебе давал гарантии что при ipv6 твой провайдер даст тебе
> нюхать интернеты напрямую?При v6 нет никакого смысла душиться жабой с серыми адресами, адресов много. И еще минус железки под нат.
>> А кто тебе давал гарантии что при ipv6 твой провайдер даст тебе
>> нюхать интернеты напрямую?
> При v6 нет никакого смысла душиться жабой с серыми адресами, адресов много.
> И еще минус железки под нат.Хех, ну ты смешной, многие провайдеры так привыкли драть по сотке в месяц за выделенный IP, что не откажутся от этого даже если адресов свободных будет больше чем атомов в галактике.
Мой провайдер даёт один публичный IPv4 и /60 IPv6 в базе для домашних пользователей. На мобиле v4 через НАТ и публичный /64 v6. Но у нас тут регулятор регулярно регулирует провайдеров и жалобы клиентов разбирает.
Государственный регулятор.
Тепло и лампово. Нет, тебя не пустим, сиди в своём, настоящем (tm).
А в чём проблема-то?
Без этого счастья всё прекрасно работает.
Ну если только на одноклассники ходить, то действительно всё работает — для этого и доступ в интернет не нужен, можно хоть через провайдерский прокси туда попасть. Но я с локалками ещё в 200х наигрался.
Если для отправки данных не нужно получать ответ, получается новый способ DoS атаки. Раньше в icmp и syn подменяли адреса отправителя, а теперь и в http flood можно (ip spoofing)
Да начнутся DDoS с локалхостов и рандомных ip!
> ip spoofingНеосиляторы RFC2827 должны быть экскоммуницированы.
tldr;Показалось - бинарщина с реализацией принципа все в одном флаконе и попыткой подмять пока независимой слой TLS и все это в стиле systemd...
HTTP/2, который бинарный и стиле systemd, уже давно работает.
Скорее всего, через него вы комментарий и отправили.
HTTP/1.1 на опеннете.
Слишком новый и модный. Должен быть gopher.
> Слишком новый и модный. Должен быть gopher.Да ладно, может HTTP/0.9 вас устроит? :)
Нет! Только гофер. А комменты по UUCP.
> HTTP/2, который бинарный и стиле systemd, уже давно работает.TLS так то тоже бинарный. Как впрочем и TCP.
А текстовость HTTP1.x в паре с немного разным пониманием теми и этими одного и того же позволяет море лулзов когда атакующий умудряется вклинить что-то лишнее и начинаются эпические приколы типа request smuggling и desync во всех его ипостасях.
> Заметный прирост производительности и пропускной способности по сравнению с TCP. Для видеосервисов, таких как YouTube, применение QUIC показало сокращение операций повторной буферизации при просмотре видео на 30%.Кэп_mode: оно для этого. А остальные просто безвольно подтянутся.
На ведь правда заключается что по хорошему надо жестко внедрять что-то на вроде ZeroNet но ведь все понимают что такого не будет и мы будем сидеть на внедренных хттп/3
Только вчера пытался настроить для одного дела, проблем еще хватает. Что сказать, если даже curl юзающий cloudflare-овскую либу quiche не может к этому самому cf законнектиться через --http3 флаг)
И все это ради того чтобы снизить нагрузку на канал тытрупа на 1%. По крайней мере раньше такие "успехи" были от потенциального пропихивания тормозвик.
Кто тыкал, подскажите как браузер узнаёт что надо юзать UDP вместо TCP?
DNS type 65 для этого изобрели чтобы браузер сразу знал как куда!
Браузер сначала пробует HTTP/2, сервер ему возвращает поддержку HTTP/3 через заголовок Alt-svc, далее браузер может подключаться по H/3
О да, теперь отслеживать пользователей будет еще проще, на уровне протокола. "Мы еще многого не знаем про вас" (c) Кто-то из топ-менеджеров Microsoft
> О да, теперь отслеживать пользователей будет еще проще, на уровне протокола.Что в нем такого для отслеживания чего не было в предыдущих?
А Роскомнадзор его уже заблокировал :D
Не нужон нам этот ваш HTTP/3!
> А Роскомнадзор его уже заблокировал :D
> Не нужон нам этот ваш HTTP/3!Ложь. Единственный стандарт, блокировке которого шла речь, был ESNI. Но он, стандарт, благополучно загнулся/переродился в ECH, который никто толком не поддерживает ещё.
https://ntc.party/t/http-3-quic/1823
> https://ntc.party/t/http-3-quic/1823Простите, а какое отношение к этому имеет РКН? Или теперь всё по логике "Кошка бросила котят - это Путин винован. А пятого, пархатого, спасла Чулпан Хаматова"?
В смысле, можно отправить 1 пакет с запросом, и в ответ на адрес, указанный в заголовке UDP пакета прилетит пара мегабайт <s>свопа</s> отборнейшего js кода? Ух, тема!
Что плохого для поливитамина? Запросы посылает пользователь, вот, пусть и радуется внезапно навалившейся халяве.
Действительно. Ему сразу поток с порно льют, а он еще и не доволен.
Ну чтож, вне зависимости от того хороший протокол или плохой очевидно следующее - "внедреж" его займет уйму времени. HTTP2 только последние пару лет стало более-менее мейнстримом, и то, естественно, не везде. HTTP3 на данный момент можно заметить только на Ютубе и еще пару мест проскакивало (Для ФФ есть аддон показывающий версию протокола в строке адреса, удобно) где это явно был просто эксперимент.
Реализована в Edge. Я правильно понимаю что реализована в Edge это значит не удалена из Edge?
Теперь надеюсь тормоза из nginx его реализуют, наконец. Жду не дождусь выключить поддержку http1 и 2.
Нифига себе я пива попил - только 1.1 и тут на тебе - 3.0 - вот тебе и куик в лицо)
как выключить в ff?
http2.enabled->false
http3.enabled->false
> т.е. в ... символ CR может применяться только вместе с символом перевода строки (CRLF)о, виндозные \r\n подвезли, красота
Насколько я помню, в текстовых протоколах всегда так было. Но сервер должен быть терпим к кривым клиентам и требователен к себе, поэтому обычно от клиентов принимаются и запросы, не совсем соответствующие стандарту.
Вот потому, что вы говорите то, что не думаете, и думаете то, что не думаете, вот в клетках и сидите. И вообще, весь этот горький катаклизм, который я тут наблюдаю. И Владимир Николаевич тоже.
> Насколько я помню, в текстовых протоколах всегда так было. Но сервер должен
> быть терпим к кривым клиентам и требователен к себе, поэтому обычно
> от клиентов принимаются и запросы, не совсем соответствующие стандарту.Если почитать новости опеннета, недавние и не очень, можно узнать что жизнь довольно жестко научила многих быть придирчивее к клиентам. Иначе они начинают request smuggling затевать, фронт и бэк начинают видеть мир по разному, а дальше хацкеры делают что хотят...
Они не "виндозные".
> LF (ASCII 0x0A) используется в Multics, UNIX, UNIX-подобных операционных системах (GNU/Linux, AIX, Xenix, Mac OS X, FreeBSD и др.), BeOS, Amiga UNIX, RISC OS и других;
> CR (ASCII 0x0D) используется в 8-битовых машинах Commodore, машинах TRS-80, Apple II, системах Mac OS до версии 9 и OS-9;
> CR+LF (ASCII 0x0D 0x0A) используется в DEC RT-11 и большинстве других ранних не-UNIX- и не-IBM-систем, а также в CP/M, MP/M (англ.), MS-DOS, OS/2, Microsoft Windows, Symbian OS, протоколах Интернет.
Тише, не разрушай Легенду О Настоящем Юниксе™ И Его Юниксвее™. А то может оказаться, что его никогда и не было, и всё это легенды да шуточки из Bell Labs.
Использовать два байта в качестве разделителя для потоковых протоколов мог додуматься только настоящий академик.
Я хз, кто это выдумал, но это создаёт просто офигительный оверхед при разборе, на самом-то деле. Поэтому да, большинство разбирало по \n, а \r тупо отрезало, что и породило фигову тучу проблем.
> о, виндозные \r\n подвезли, красотаНе очень понятно зачем - лишний байт почем зря в протоколе который так то не текстовый.
В целом как в мемчике ну решили какие-то проблемы, а фундаментально проблемы блокировок, вражды и прочие социокультурные проблемы все равно больше и страшнее чем задержка открытыия сайта в 1.5 миллисекунды
Это для тебя задержка открытия сайта в 1.5 миллисекунды - не проблема.
А для макак, которые в сайт напихали пару сотен JS и CSS по две строчки в каждом, 1.5 миллисекунды умножаются на эту пару сотен, и превращаются уже в доли секунды, если не секунды.
deny udp any any eq 80
deny udp any eq 80 any
deny udp any any eq 443
deny udp any eq 443 any
permit ip any any
Ты заодно ICMP забыл запретить, клоун.
> deny udp any any eq 80
> deny udp any eq 80 any
> deny udp any any eq 443
> deny udp any eq 443 any
> permit ip any anyЛучше 67 забань. И 53, на всякий случай.
67 во внешку смысл забанить всегда есть, зачем плодить?
53 - только по индивидуальной просьбе.
> 67 во внешку смысл забанить всегда есть, зачем плодить?Да и себе его забань. Если кто сильно умный, статику настроит, остальные отдохнут от интернета, по крайней мере V4.
> 53 - только по индивидуальной просьбе.
Именно поэтому на 53 удобно вешать vpn-ы всякие, они так забавно прорубаются через фаеры, наты, гостевые-демо-неоплачено доступы и прочую лабудень :)
Китайцы вообще через DNS-серверы VPN'ы гоняли одно время. Потом как-то утихло.
А с любителями VPN'ов на 53 вполне справляется deny для TCP и жёсткий полисинг (rate limit) по UDP, DNS-то много не надо.
> Китайцы вообще через DNS-серверы VPN'ы гоняли одно время. Потом как-то утихло.Если через порт 53 UDPшный впн то это недурно работает, половина растяпоадминов даже в платном/демо доступе напрочь не парится блокировкой. Хомяки строятся, те кто поумнее без мыла пролезают. Fair enough :P.
А если в именно DNS запросах тунелять - так делают, но это очень тормозно и практикуется только в самом крайнем случае, когда все остальные опции исчерпались. А китайцы из-за мерзкого файрвола научились в очень крутые и продвинутые сетевые тулсы, намного круче любых других технологий. Думаю они просто придумали более 9000 способов делать это лучше.
> А с любителями VPN'ов на 53 вполне справляется deny для TCP
VPN так то и UDPшный бывает. Зачем TCP на 53? Наоборот, UDP, чтобы на DNS больше смахивало.
> и жёсткий полисинг (rate limit) по UDP, DNS-то много не надо.
Это уже отдельно настраивать надо, сколько админов заморачивается? Не, если вы охренеете и плотно подсядете на неделю к ним и будете торенты лить, админы, конечно, с горя заморочатся как вас оттуда убрать. И даже тупой сможет в -j DROP <проблемный хост> или что там у него, если приперло. А если не приперло... то довольно часто таки работает.
Именно в DNS-запросах пытались протаскивать. Было это лет так 7-8 назад, пришлось специфичные фильтры навешивать, чтобы заполисить (понятно, что несколько корпоративных клиентов были выходной точкой, но не отключать же их от DNS).
> Именно в DNS-запросах пытались протаскивать. Было это лет так 7-8 назад, пришлось
> специфичные фильтры навешивать, чтобы заполисить (понятно, что несколько корпоративных
> клиентов были выходной точкой, но не отключать же их от DNS).Оно такое даже опенсорсное есть, iodine чтоли, называлось. Работает, но медленно.
Ну, мы сами писали на средних курсах :D Под винду правда.
А так - возможно оно и было, я особо не изучал, но адреса DNS-серверов китайские. Длинные псевдо-имена в сторону неких доменов, в ответ тоже неразборчивые TXT.
> на 53 вполне справляется deny для TCPИ ты получаешь поломанный ДНС, который вроде обычно работает, но иногда не работает.
Бывает такое, yes. Поэтому лучше конечно жёстко полисить.
Ещё посмотрим как оно себя будет вести, когда это будут заливать старт-пакетами 0-RTT.
(запрашиваешь один коннект, считаешь ключи, заливаешь 10 гиг 0-RTT, профит?)
Ну и 2x-3x хендшейк для амплификации не очень хорошо, но всё же имеется.