Здравствуйте, chaotic-kotik, Вы писали:
CK>Вот так прогресс делает некоторые специализации менее нужными. Вот раньше как было, ходил HTTP трафик по TCP, люди писали TCP сервера поверх стека ОС, преодолевали проблемы оного стека ОС (проблема 10К), использовали epoll и windows completion ports. Но QUIC работает поверх UDP, большая часть протокола в userspace, сейчас у UDP нет таких проблем как у TCP, ОС умеет через recvmsg обрабатывать миллионы UDP пакетов в секунду, поэтому нет проблемы 10К.
Проблема 10K не решается сама собой от переноса соединений в user space.
Здравствуйте, ononim, Вы писали:
C>>Проблема в том, что существующий TCP ломается у заметного количества клиентов, если не делать таких уродских хаков. O>Учитывая вводные (свой код клиента и сервера)
Откуда такая вводная? Клиент может быть совершенно любой.
Ну ладно, предположим, что мы колхозим в Chrome, а остальных отправляем в канал с обычным MTU в 1380.
O>задача определения и настройки PMTU должна тривиально решаться при помощи setsockopt(...TCP_MAXSEG...) где оно поддерживается (лялих) и чуть менее тривиально при помощи setsockopt(...TCP_NODELAY..) и ручной буферизации исходящих данных где set(TCP_MAXSEG) не работает (винда).
Вот Вася сидит в региональном отделении православного банка Рогатус&Копытус. Его локальный MTU — это 1500 байт (Ethernet), но его филиал подключён к Интернету через VPN и PPPoE, которые отъедают примерно 90 байт пакетов.
Так что PMTU получается в 1410. Гугл начинает передавать ему данные, наращивает окно и в итоге передаёт пакет в 1411 байт. Этот пакет не проходит через финальный VPN и клиент VPN отправляет в сторону Гугла сообщение ICMP о том, что пакет слишком большой.
Но не тут-то было! Так как банк — большой и очень умный, то исходящий трафик фильтруется через middlebox, который считает ICMP изобретением дьявола и блокирует его. Тем более, что трафик ещё и на сервера в Калифорнии идёт. Нельзя такого допускать, никак нельзя.
И всё, пользователь видит застывшую полосу загрузки. Через некоторый таймаут Гугл поймёт, что переборщил с размером пакетов и уменьшит его. Но тайамаут — это тормоза.
Сразу начинают придумываться идеи типа: "А что если одновременно послать один большой пакет, пока мы в фоне посылаем маленькие?". Но от этого middlebox'ам плохеет так, что они вообще соединение разрывают.
C>>Если есть идеи как это исправить в рамках существующего TCP — добро пожаловать в Гугл на семизначную зарплату. O>Боюсь гномиков разверну не под тем углом.
Они там уже не спрашивают их.
S>Соответственно, в будущей версии HTTP транспорт TCP заменят на QUIC.
Вот так прогресс делает некоторые специализации менее нужными. Вот раньше как было, ходил HTTP трафик по TCP, люди писали TCP сервера поверх стека ОС, преодолевали проблемы оного стека ОС (проблема 10К), использовали epoll и windows completion ports. Но QUIC работает поверх UDP, большая часть протокола в userspace, сейчас у UDP нет таких проблем как у TCP, ОС умеет через recvmsg обрабатывать миллионы UDP пакетов в секунду, поэтому нет проблемы 10К.
Здравствуйте, netch80, Вы писали:
N>И каким же образом этот вывод получается из сказанного ранее? N>Переход на UDP магически отменяет необходимость делать ожидание на сокетах?
я имел ввиду recvmmsg/sendmmsg + SO_REUSEPORT, на них можно построить свой QUIC стек на уровне приложения, который не будет нуждаться в ОС для мультеплексирования соединений и context switches и будет многопоточным
Здравствуйте, ononim, Вы писали:
Pzz>>Проблема 10K не решается сама собой от переноса соединений в user space. O>Ну как же. Ведь тцп стек операционки писали криворукие старперы, а модные девелоперы быстро эти пакетики разрулят на питончике, в 100500 раз быстрее. А если будет тормозить на питончике — напишут на го, вот тогда уж точно все залетает. https://www.dpdk.org/
Здравствуйте, Cyberax, Вы писали:
C>Никак. В этом случае не будет никаких гарантий, как и при соединении по обычному TCP.
Тогда это профанация навязанного протоколом обязательного "шифрования" и бессмысленная нагрузка на устройства.
C>Единственное, что подслушивать можно будет только активно через MITM.
Что усложняет отладку, но не является непреодолимым препятствием для злоумышленника.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, eskimo82, Вы писали:
E>Не взлетит по одной очевидной причине: отказ от уровней OSI приведёт к степенному росту сложности разработки и отладки.
OSI сдохла уже давно.
E>Разработка этого протокола не будет закончена никогда, а если и будет то получится УГ: могу делать все но очень плохо.
QUIC уже работает. В следующей версии ещё добавляют FEC для борьбы с потерями.
C>По факту получилось: протокол де-факто готов, работает быстрее TCP в реальных условиях и поддерживается не только Гуглом.
По факту все вышеперечисленое как раз наоборот.
Здравствуйте, Cyberax, Вы писали:
E>>>>Разработка этого протокола не будет закончена никогда, а если и будет то получится УГ: могу делать все но очень плохо. C>>>QUIC уже работает. В следующей версии ещё добавляют FEC для борьбы с потерями. E>>Он будет только начинать "уже работать" когда появится внятный и законченый стандарт. C>Так уже:
"Это есть, товарищи, случай так называемого вранья" (tm)
Читаем упомянутый драфт:
5.3. Life of a QUIC Connection
TBD.
Это не "внятный и законченный", это _ничего_ готового нет, потому что нет самого главного.
По сравнению с этим все эти простыни жизни потоков и раскладки битов — бесполезный тлен.
C> https://www.ietf.org/id/draft-ietf-quic-transport-16.txt — будет по плану ратифицирован в следующем году, во время июльской встречи IETF.
Там нечего ратифицировать.
А если ратифицируют, значит, IETF окончательно спятил, потому что протокол такого уровня и масштаба требует не меньше года на вычитку и опробование уже после того, как _вроде бы_ финальный текст готов и отлажен вплоть до запятых.
C>Что неудивительно, для QUIC применены все современные наработки по TCP. Собственно, над QUIC в Гугле работает Ван Якобсон. Надо рассказывать кто это?
У гугла потрясающая манера забирать толковых людей и превращать их работу в унылое дерьмо.
Вопрос не в том, кто там работает. Вопрос в том, на какую цель он работает и в какие рамки он загнан.
Здравствуйте, CreatorCray, Вы писали:
C>>Конкретно QUIC делается с простой целью — чтобы он не сосал, как TCP через middlebox'ы. CC>Что то мне кажется что в реале он как раз будет сосать что тот пылесос. CC>Потому что шторм UDP запросов говномиддлбоксы переваривают плохо.
Они часто UDP тупо блокируют, но тут уже ничего не поделать.
В QUIC плюс в том, что он позволяет существенно уменьшить число пакетов в секунду, по сравнению с TCP.
Здравствуйте, Cyberax, Вы писали:
C>>>Ну начнём с того, что 0-RTT connection невозможен без шифрования на уровне протокола. Но более глубокая причина в том, что одной из целей протокола было сделать middlebox'ы невозможными. Практика показала, что иначе протоколы мгновенно закостеневают. m2l>>Ты почему то за аксиому берешь что некое обозначенное тобой "закостеневают" это "плохо". C>Потому, что это плохо. Это останавливает саму возможность развития протоколов.
Логики нет в твоих словах. К примеру cloud & sdn дают развитие vxvlan. Умные устройства дают возможности для "промышленных протоколов". Через 30 лет после TCP и UDP появились SCTP и DCCP. Насчет последнего не в курсе, а SCTP активно используется. Эволюция идёт, и если появится протокол кардинально лучший — то он вытеснит существующие. Другой вопросы, что ничего кардинально лучшего нет. А "развитие" ради "развития", ну ты сам понимаешь...
m2l>>Не стесняйся, расскажи нам, что хорошего каждую неделю переделывать протоколы и форматы. Для кого это будет хорошо. И почему, если это так хорошо раньше этого не делали. C> C>"Мой дед крутил гайки ключом на 15, мой отец крутил гайки ключом на 15, и я буду крутить гайки ключом на 15!"
Действительно, он крутил на 15, а мы будет крутить на 16, через год заменим на 14, потом на 15 с половиной. Ведь это развитие! Если просто так не менять их диаметр, то будет плохо!
C>А не делали из-за того, что протоколы начали костенеть в районе 2001-го года. Я уже привёл пример с ECN.
ИМХО, ты немного не разобрался отчего оно реализовано и отключено по умолчанию. Я вот на вскидку не смог придумать кейс, где оно было бы полезно, а не вредно.
Здравствуйте, Sinclair, Вы писали:
C>>>OSI сдохла уже давно. MD>>Хммм… А мужики-то не знают! Как же она сдохла, неужели фейсбуки с контактами прямо в Ethernet-кадры данные оборачивают? S>Нет. Но работа протокола IP зависит от протокола ICMP, который работает поверх IP. Нужно объяснять, что это прямое нарушение модели?
Он и от BGP зависит. И от DHCP, который поверх UDP. И от ещё массы вещей.
Это не нарушает главного — что уровневый принцип, близкий к тому, что описан в OSI модели и ISO стеке, актуален и его упоминание и обучение необходимо для того, чтобы понимать структуру сети.
Здравствуйте, Hobbes, Вы писали:
Pzz>>Вот смотри, вот нормальное завершение TCP сессии: Pzz>>1) A->B: FIN Pzz>>2) B->A: FIN+ACK Pzz>>3) A->B: FIN+ACK
H>Зачем А передаёт FIN второй раз?
Оно передаёт ACK с соответствующим SN, которым подтверждает получение FIN от B. Флаги SYN, FIN считаются за 1 октет в правилах подсчёта SN, но только один раз за жизнь соединения.
FIN же ставится в 3-м пакете... ну а зачем его снимать, если передача от A уже закрыта?
Учтите при этом, что TCP допускает одностороннее закрытие на достаточно долгий период. Это выглядит, например, так:
1) A->B: 200 байт, SN=1000, ACK=5000
2) B->A: 0 байт, SN=5000, ACK=1200 (подтвердила приём 200 байт)
3) A->B: 0 байт, FIN, SN=1200, ACK=5000
4) B->A: 0 байт, SN=5000, ACK=1201 (подтвердила, что увидела FIN)
с этого момента соединение одностороннее; B может писать, но не читать
5) B->A: 1000 байт, SN=5000, ACK=1201
6) A->B: 0 байт, FIN, SN=1201, ACK=6000
... B продолжает слать ...
Да, такие сценарии редкие, но вполне законные. И при этом A нет смысла убирать флаг FIN, даже несмотря на то, что B его запомнила. Может, он кому-то ещё по дороге важен
Здравствуйте, Sharov, Вы писали:
N>>Иначе малейший затор создаст пакет большего размера, который уже не пройдёт. S>Почему, пакеты объединятся что ли? Или о чем речь?
Да. Формально, не пакеты, а собственно порции данных, в один пакет, который будет больше практического предела прохождения.
Здравствуйте, reversecode, Вы писали:
R>помнится там было другая проблема R>утп не контролировал полосу и отьедал ее всю
Вообще-то, µTP изначально имел congestion control, причем он был сконструирован таким образом, чтобы всегда проигрывать TCP в соревновании за полосу, чтобы не мешаться веб-траффику.
O>>>Интересно тут что-то подобное планируется или они допилят UDP добавив в него end-of-session пакет? Pzz>>В QUIC, разумеется, есть пакет, обозначающий окончание сессии. Но он зашифрованный, как и все прочие пакеты QUIC, его от любого другого не отличишь, если не знать сессионных ключей. O>Логично было бы оставить расшифрованный пакет, или добавить специальное ICMP сообщение, например. Да даже добавлять не нужно, ведь есть же ICMP port unreachable который посылается в ответ на UDP датаграмму на закрытый порт, вот его можно просто самостоятельно слать при "закрытии" QUIC потока. Оборудование подозреваю уже отработает такой пакет как положено.
QUIC основан на UDP, но реализован полностью в пространстве пользователя (ядро менять не надо), поэтому, ICMP port unreachable слать не получится (если ты не root). Кроме того, в UDP нет tcp sequence и, скорее всего, такой ICMP port unreachable можно отправить сквозь маршрутизатор с перебором всех 65536-ти портов и на шлюзе все эти сессии из таблицы NAT будут удалены...
Здравствуйте, Cyberax, Вы писали:
C>>>Дополнительно, QUIC сделан так, что предотвращает окостеневание протоколов (protocol ossification). N>>Прошу показать, как QUIC позволит устранять какие-то нормы стандарта, которые позднее признаны неадекватными и предложена замена (причём, какие именно, мы ещё не знаем). C>TCP закостенел. Его невозможно изменить. Простенький ECN (Explicit Congestion Notification) до сих пор не поддерживается всеми middlebox'ами, через 17 лет после RFC.
"C++ закостенел, потому что простейшие нормы C++11 до сих пор не поддерживаются всеми компиляторами."
"C закостенел, потому что C99 до сих пор не поддерживается всеми компиляторами, через 19 лет после стандарта."
Впрочем, будем считать, что ты ответил на вопрос. Тогда следующий — почему это вместо нормального нового стандарта TCP-like (время которого таки пришло) или SCTP (в котором есть уже почти всё нужное) нам предлагают идти калечным путём и строить что-то поверх UDP, теряя множество важных возможностей от интеграции в IP стек.
"Нормальные герои всегда идут в обход", да.
C>С QUIC так не получится, так как там шифруется практически всё. Для middlebox'ов оставили один незашифрованный бит.
Ну вот ты впал в ту же сторону, что гугл — всё, что посреди, назвать "middlebox", назначить этому ярлыку заведомо отрицательную роль и считать свою историческую роль выполненной.
Про проблемы времени жизни NAT сессий тут уже говорили, не буду повторяться.
C>Из конкретных улучшений по сравнению с TCP: C>1) PMTU полностью поднят на уровень QUIC, так как на уровне IP оно всё сдохло.
На уровне IP его, как ни странно, за последние годы починили чуть менее, чем везде.
Если в начале 2000х я постоянно боролся с ним даже как клиент, то за последние лет 5 проблемы не видно.
C>2) Multi-homing внедрён в QUIC и полностью поддерживается. Для TCP это есть только в расширении MPTCP. C>3) Продуманный механизм будущих расширений. C>4) FEC для компенсации потерянных пакетов (возможно, что в первую версию стандарта не попадёт).
И будет точно так же, как с TCP? Первая версия застынет у 90% участников.
Это если мы полагаем, что его будет использовать кто-то за пределами гугла.
C>...
N>>The "ossification" Google harps on is someone else exercising some form of non-Google control, usually by virtue of having bought or being the owner or contractor of the network or computing gear, deploying something designed to be controlled by its owner, or applying standards with the same objective. C>Бред.
Почему? Пока что всё указывает на это — гугл силой проталкивает своё крайне сырое решение, нацеленное исключительно на его интересы.
Повторится ситуация с HTTP/2, который кое-как выкрутили с двадцатой попытки, и то постоянно с проблемами (знаю места, где сначала включили его на сервере, потом выключили нафиг, ибо реализации глючные аж нимагу).
N>>Я знаю проблемы TCP. Но решение от гугла, которое притягивается за уши, может быть ещё хуже. C>Чем?
Здравствуйте, Cyberax, Вы писали:
C>Ну начнём с того, что 0-RTT connection невозможен без шифрования на уровне протокола. Но более глубокая причина в том, что одной из целей протокола было сделать middlebox'ы невозможными. Практика показала, что иначе протоколы мгновенно закостеневают.
Я попытался понять, как работает этот 0-RTT, правда довольно на бегу и в спешке, так что поправь меня, если я не прав.
У меня сложилось впечатление, при использовании 0-RTT первая порция данных от "клиента" к "серверу" посылается еще до то того как идентичность "сервера" подтверждена. Т.е., например, если у нас HTTP, то параметры HTTP GET посылаются "куда-то там", и лишь к моменту получения ответа можно проверить, что мы именно с тем и разговариваем, с кем собирались.
С TCP+TLS это было не так.
Гражданам, конструирующим всякие там REST API это следовало бы иметь ввиду. Потому что если параметры запроса секретные, то можно получить дыру в защите в неожиданном (из прошлого опыта) месте.
Здравствуйте, Ops, Вы писали:
C>>В данный момент QUIC составляет около 8% всего Интернет-трафика — https://blog.apnic.net/2018/05/15/how-much-of-the-internet-is-using-quic/ Ops>И все это гугл
Не только. Есть ещё Akamai и ряд других CDN. CloudFlare сейчас его тоже внедряет.
C>>А админов вообще не спрашивали. Если ради 1% улучшения скорости они должны будут стоять на ушах — они будут стоять на ушах. Ops>Глупости. 1% скорости на сайтах никому не нужен.
Нужен: https://blog.gigaspaces.com/amazon-found-every-100ms-of-latency-cost-them-1-in-sales/ или https://ai.googleblog.com/2009/06/speed-matters.html
Ops>Нужен трафик, тут да, гугл их и нагибает, заставляя сайты-визитки переводить на https. Но это не естественный процесс, а прогиб под прихоти монополиста.
Я не очень понимаю, кому-то НРАВИТСЯ, что их сайты-визитки могут использовать для атак на пользователя или для доставки рекламы путём переписывания HTML?
Здравствуйте, ononim, Вы писали:
C>>Проблема в том, что существующий TCP ломается у заметного количества клиентов, если не делать таких уродских хаков. O>Учитывая вводные (свой код клиента и сервера) задача определения и настройки PMTU должна тривиально решаться при помощи setsockopt(...TCP_MAXSEG...) где оно поддерживается (лялих) и чуть менее тривиально при помощи setsockopt(...TCP_NODELAY..) и ручной буферизации исходящих данных где set(TCP_MAXSEG) не работает (винда).
"Ручная буферизация" подобного рода будет надёжно работать только если уже на уровне приложения на каждую порцию получать подтверждение. Иначе малейший затор создаст пакет большего размера, который уже не пройдёт. А это такое торможение по сравнению с нормальной скоростью TCP, что мы откатимся во времена диалапа.
Так что ни "тривиально", ни "чуть менее тривиально" тут не получится.
Или управление сегментом и логика на стороне userland (которому это всё нафиг не сдалось, и вводить в каждое приложение — это примерно как перевести весь Интернет на другие протоколы), или поддержка от ядра включая слепые пробы меньших сегментов (как в Linux), или таки реализация своего L4 через библиотеку с умением этого (что QUIC и делает, в частности).
C>>Если есть идеи как это исправить в рамках существующего TCP — добро пожаловать в Гугл на семизначную зарплату. O>Боюсь гномиков разверну не под тем углом.
Тут не гномики, тут реальная задача. И она не решается.
Я не агитирую за QUIC в целом (ещё обдумать всё надо), но именно PMTUD, где оно проблема, без него решается слишком сложно и неустойчиво.
Здравствуйте, ononim, Вы писали:
O>Ненене. Не нужно никаких ICMP. Они считать что ICMP проходит — то вообще ничего не нужно, PMTU discovery придуман давно, но он не работает когда ICMP блочится. Что является корнем проблемы с PMTU. Т.о. нужно определять PMTU без использования ICMP.
Ок, пытаемся.
C>>И всё, пользователь видит застывшую полосу загрузки. Через некоторый таймаут Гугл поймёт, что переборщил с размером пакетов и уменьшит его. Но тайамаут — это тормоза. O>Это однократный таймаут, потом все пакеты такому клиенту надо слать с определенным MTU, периодически в фоне проверяя нельзя ли его подрастить. Причем оптимальный MTU должен запоминать не только гугл, но и сам клиент.
ОК, сделали (кстати, оно реально тестировалось Гуглом). Но всё равно не работает. У части клиентов странички периодически затормаживаются на несколько секунд.
Проблема в том, что IPv4 пакеты могут сами по себе фрагментироваться и пересобираться. Но вот пересборка часто глючит (см. "middlebox") или вообще запрещена, как сатанистский ритуал, порочащий доброе имя IPv4. Если установить DF, то можно потерять ответы о невозможности доставки.
И в TCP для контроля за этим есть только настройка MSS, которая согласуется только один раз в SYN-пакетах в начале. Так что вот и получается, что оно как-то всё вместе не работает.
O>Встречный вопрос: а как тогда решается данная проблема QUIC'ом? Ведь явно на тех же таймаутах. Потому что больше надежных путем нету. Потому все еще в упор не вижу преимуществ QUIC'а над тюнингом TCP.
В QUIC периодически посылаются тестовые пакеты параллельно основному соединению. Для них замеряется время в пути и при удачности измерения — размер окна переключается на них.
C>>Сразу начинают придумываться идеи типа: "А что если одновременно послать один большой пакет, пока мы в фоне посылаем маленькие?". Но от этого middlebox'ам плохеет так, что они вообще соединение разрывают. O>О да, а от QUIC'а мидлбоксы будут расслабленно плевать в потолок
Да, так как они НИЧЕГО не смогут сделать без полноценной MITM-атаки. В QUIC нет никаких зацепок для middlebox'ов, кроме одного бита (который с трудом протащили в стандарт).
Здравствуйте, CreatorCray, Вы писали:
CC>Что то мне кажется что в реале он как раз будет сосать что тот пылесос. CC>Потому что шторм UDP запросов говномиддлбоксы переваривают плохо.
там свой congestion control есть, при этом он как раз снизит нагрузку на сетевое оборудование, т.к. CC в TCP работает хреново, т.к. он работает на уровне TCP подключения, а по факту, браузер открывает множество соединений с хостом и весь CC вылетает в трубу (ну почти)
Здравствуйте, Sinclair, Вы писали:
N>>Он и от BGP зависит. И от DHCP, который поверх UDP. И от ещё массы вещей. S>Нет, не зависит. Роутить IP можно безо всякого DHCP, и без всякого BGP. То, что на практике DHCP часто используется для авто-конфигурации IP — это просто особенность нынешнего интернета. Как и использование BGP.
Всё-таки ты не о том.
В модели OSI есть 4 принципиально разных аспекта:
1. Количество и состав уровней. Этот аспект на сейчас сохраняется с несущественными изменениями (в основном в районе L2: что происходит на стыке с L1, деление LLC/MAC, и так далее).
2. Строгая направленность иерархии уровней. Убита туннелированием и криптографией, но так, что исключение подтверждает существование и смысл правила — все инверсии делаются так, что не нарушают предыдущую логику.
3. Привязка формального управления уровнем к тому же уровню. Вот тут больше всего взъедаются на OSI, но мне этот момент как раз кажется маловажным: скорее всего, тут произошла накладка в виде административного влияния каких-то старцев-маразматиков или их бюрократических эквивалентов, потому что любому нормальному человеку очевидно, что если у нас есть управляющие команды и ответы, то у нас есть полные аналоги L4...L7, и не называть их так не имеет смысла.
4. Конкретная реализация уровней (типа, G.703, FrameRelay, X.25 и так далее). Вот тут потеряно практически всё. Но и в случае IP оно теряется (кто помнит, как выглядели IPv2, IPv3, безальтернативная классовая адресация и т.п.? а ведь нам постепенно настаёт полный и окончательный v6), а навстречу идёт понимание того, в чём ISO народ был прав (и выливается в штуки типа SCTP).
И именно противоречие в том, что для первичного введения в учебнике нужен {1}, а для нормального понимания {neg(3)}, и приводит к тому, что за OSI ломаются копья.
Я по этой причине всегда говорю о "народной" или "современной" реализации модели OSI, со всеми необходимыми поправками согласно пп.1-4, с отличением от "строгой", которая была привязана к конкретному вымершему стеку.
S>На всякий случай напомню, что технически ничто не мешает нам реализовать IP поверх голубиной почты.
Не мешает. И даже с QoS, как известно. Но к общему вопросу это не имеет отношения: это просто ещё один вид транспорта ниже сетевого уровня.
Тем более что, если практически его реализовывать, очень быстро появятся L2 domains в пределах типичного расстояния полёта голубя и маршрутизаторы между ними
N>>Это не нарушает главного — что уровневый принцип, близкий к тому, что описан в OSI модели и ISO стеке, актуален и его упоминание и обучение необходимо для того, чтобы понимать структуру сети. S>Согласен. В качестве красивой картинки этот принцип стоит изучать, отдав ему 5-10 минут на лекции. А затем переходить к тому, как дизайнятся реальные протоколы, решающие реальные задачи (а не задачу "оправдать работу семи подкомитетов комитета по разработке стандарта").
Так второго сейчас и не делают. Ты воюешь с ветряными мельницами.
Обычно, стандартная семиуровневая картинка тут же проецируется на реальность, и показывается уже на примере IP.
S>Точно так же, как мы говорим о желательности отсутствия кольцевых зависимостей в модулях программы, а затем сразу переходим к тому, как скомпилировать DLL которые необходимым образом зависят друг от друга. S>Потому что класс String невозможно описать, не используя класс Type (ведь как и у всех, у него есть метод GetType()), а класс Type невозможно описать, не используя класс String (ведь у него есть String Name). S>И прагматичные цели часто заставят нас складывать эти типы в разные DLL.
Аналогия понятна, но не вижу её связи с предыдущим вопросом.
Здравствуйте, netch80, Вы писали:
N>2. Строгая направленность иерархии уровней. Убита туннелированием и криптографией, но так, что исключение подтверждает существование и смысл правила — все инверсии делаются так, что не нарушают предыдущую логику.
Уже не так. Тот же NAT ломает изоляцию между сетевым слоем и транспортным/сессионным. Причём ломает вдребезги — теряется возможность двунаправленной коммуникации, и маршрутизаторы сетевого слоя обязаны знать детали транспортного слоя. Мелочи типа DoH — уже вишенка на торте.
Современный Интернет, в итоге, выглядит совершенно отлично от идеализированного OSI. В частности, критично важные части в OSI не затронуты:
1) Механизм разрешение имён.
2) Асимметричность доступа к ресурсам.
3) Непрозрачность сетевых устройств.
4) Шифрование и инфраструктура для него.
N>4. Конкретная реализация уровней (типа, G.703, FrameRelay, X.25 и так далее). Вот тут потеряно практически всё. Но и в случае IP оно теряется (кто помнит, как выглядели IPv2, IPv3, безальтернативная классовая адресация и т.п.? а ведь нам постепенно настаёт полный и окончательный v6), а навстречу идёт понимание того, в чём ISO народ был прав (и выливается в штуки типа SCTP).
SCTP, по сути, сдох так и не родившись. Там сейчас нет ничего существенно интересного, кроме сегментации пакетов на уровне протокола и multihoming (который и для TCP тоже есть). При этом реальные железные штуки типа синхронных колец с реальным выделением гарантированной полосы для абонентов вообще не получили какого-либо успеха.
Здравствуйте, Sharov, Вы писали:
C>>Потому, что через нынешний Интернет ничего другое не пролазит. S>А зачем фб что-то другое кроме http(s)?
Например, для голосового и видеочата. Или для игр.
Здравствуйте, Sharov, Вы писали:
C>>>>Потому, что через нынешний Интернет ничего другое не пролазит. S>>>А зачем фб что-то другое кроме http(s)? C>>Например, для голосового и видеочата. Или для игр.
S>А на фига, т.е. у нас дважды кадр ip\tcp — сначала для http пакета, затем для его содрежимого. Так?
Голос и видео в реальном виде требуют синхронный тип трафика, при котором транспортные проблемы скорее приводят к потерям пакетов, чем к их задержкам. Провалы звука и изображения (в разумных пределах) восстанавливаются и легче воспринимаются, чем "плавающий" звук.
Аналогичные проблемы характерны для многих других видов взаимодействия, включая игры — если на тебя едет танк, лучше, если он "прыгнет", но вовремя (такой же эффект, как если ты сам отвернулся на пару секунд), чем если ты через полминуты получишь подробную последовательность его шагов, когда он тебя уже расстрелял.
TCP, как и всё, что бегает поверх него, обеспечивает только наливной (bulk) трафик, с защитой от потерь, но ценой задержек и переповторов. Условная гарантия доставки обеспечивается отсутствием гарантии реалтаймовости. Пропустить переповтор устаревших данных невозможно, протокол на это не рассчитан принципиально.
Таким образом, TCP и всё, что поверх него (HTTP, HTTPS) тупо непригоден для реализации синхронных взаимодействий. Для них обычно используются свои протоколы поверх UDP, и не дай бог какой-то дурак затуннелирует это поверх TCP (к сожалению, всякие openvpn такое умеют, и есть имбецильные любители настраивать такое).
С SCTP с этим лучше — у него есть возможность задавать для каждой датаграммы ограничение доставки по времени или по количеству переповторов, не подтвердили получение — фиг с ним. Но сам SCTP подозрительно мало используется.
Здравствуйте, Mr.Delphist, Вы писали:
MD>Здравствуйте, vsb, Вы писали:
vsb>>Распишешь эти 7 уровней? Вот у меня компьютер к роутеру подключен Ethernet-проводком. Отправляю я это сообщение POST-запросом на https://rsdn.org/. Давай по уровням выписывай 7 задействованных протоколов.
MD>1. Физический уровень: медь, оптика или wireless MD>2. Канальный уровень: Ethernet MD>3. Сетевой уровень: IP (четвёртый или шестой) MD>4. Транспортный уровень: TCP MD>5. Сеансовый уровень: SSL/TLS (для случая с http:// префиксом этот уровень не требуется) MD>6. Уровень представления: plaintext или gzip или ещё какой набор правил по кодированию контента MD>7. Прикладной уровень: HTTP
Не совсем так, мягко говоря.
В HTTP свой сеансовый уровень — собственно HTTP фрейминг. Здесь TLS даёт туннелирование, поэтому то, что над ним, работает своими слоями над 4-м уровнем (TLS даёт внутри себя поток октетов, такой же, как TCP). Но само TLS имеет полный комплект уровней — свой протокол и передаваемые данные, поэтому получается порядок:
4. Транспортный уровень: TCP
5(1). Сеансовый уровень: TLS — установление связи, выбор шифра, аутентификация, фрейминг, подписи пакетов...
6(1). Представление данных: HTTP поверх TLS — разделение на порции
-- Тут инверсия за счёт туннелирования в TLS
5(2). Сеансовый уровень: HTTP — фрейминг (заголовки, тело).
Далее:
6(2). Представление данных: это не просто plaintext или gzip. Это HTML, CSS и прочие. Plaintext, gzip — это артефакты сеансового уровня (если они, говоря языком HTTP, transfer-coding, а не content-coding), это чисто вопрос, как передать конкретное содержимое — со сжатием или без.
И наконец
7. Прикладной уровень: это уже не сеть как таковая, это логика браузера или сервера.
Проблема в том, что заведомо некорректное разделение между L5-L6-L7 (и понятие "протокола прикладного уровня" — на прикладном уровне, и даже на представлении данных, протоколов уже нет!) проникло даже в википедию, не говоря про множество прочих источников. А в результате получается, как в той же вики, что HTTP — на L7, а RTCP или H.245 (намеренно беру именно указанное в статье) — на L5.
Хотя разница между ними тут ничтожна.
MD>Милостивые господа, впереди новогодние праздники. Потратьте их с пользой, почитайте проф-литературу, если в обычные дни вам некогда.
Так и литература хромает нипадеццки. Тут у модели OSI проблемы на обоих концах, увы.
Здравствуйте, Sharov, Вы писали:
C>>Ага, или ещё хуже. А нафига — так ничего другого не работает. S>Это серьезно? Т.е. туннелируют в http\s трафик для игр и звука? Или я чего-то не понял?
Ага, именно так.
Здравствуйте, ononim, Вы писали:
S>>Соответственно, в будущей версии HTTP транспорт TCP заменят на QUIC. O>Помницца когда битторрент навелосипедил uTP то был ор от провайдеров потому что их оборудование не тянуло такую нагрузку, т.к. в UDP нету сессий, соотвественно вся stateful обработка трафика основывается на таймаутах.
В TCP тоже никуда не денешься от таймаутов. Последний пакет может и не прийти, на него нельзя рассчитывать. Более того, он может прийти несколько раз, и невозможно понять, какой из них самый последний.
O>Интересно тут что-то подобное планируется или они допилят UDP добавив в него end-of-session пакет?
Скорее, провайдеры допилят свое оборудование.
В QUIC, разумеется, есть пакет, обозначающий окончание сессии. Но он зашифрованный, как и все прочие пакеты QUIC, его от любого другого не отличишь, если не знать сессионных ключей.
S>>Соответственно, в будущей версии HTTP транспорт TCP заменят на QUIC.
E>Не взлетит по одной очевидной причине: отказ от уровней OSI приведёт к степенному росту сложности разработки и отладки.
Строгий стек OSI давно умер, и не участвует тут никаким боком.
Если имеется в виду "народный" стек OSI, который ложится в том числе на TCP/IP, то нарушается минимально, и принципиальных проблем тут не будет. Такого рода нарушения давно отработаны концептуально и практически на туннелировании, на TLS-over-UDP.
E>Разработка этого протокола не будет закончена никогда, а если и будет то получится УГ: могу делать все но очень плохо.
В нём есть, действительно, странные решения.
Но HTTP/2 с похожим подходом уже более-менее взлетел.
Здравствуйте, Cyberax, Вы писали:
C>Дополнительно, QUIC сделан так, что предотвращает окостеневание протоколов (protocol ossification).
Прошу показать, как QUIC позволит устранять какие-то нормы стандарта, которые позднее признаны неадекватными и предложена замена (причём, какие именно, мы ещё не знаем).
Иначе же это выглядит как откровенное бла-бла-бла с использованием баззворда, а в сторону TCP кинуто "он чужой, он плохой".
QUIC is a Google solution and Google is very keen on dumb middleware where everything is controlled by endpoints. Middleware is anything interposed between Google cloud services and Google client software, be it networking equipment, operating systems, any security or control framework. When one endpoint is Google cloud, and the other Google Chrome, or Google Android, and everything else has no control of what happens, that effectively means Google is in control. It's usually sold to the general public as putting some control in the hands of end users. Some control being the power to nullify other forms of power and put Google in the driving seat.
The "ossification" Google harps on is someone else exercising some form of non-Google control, usually by virtue of having bought or being the owner or contractor of the network or computing gear, deploying something designed to be controlled by its owner, or applying standards with the same objective.
Я знаю проблемы TCP. Но решение от гугла, которое притягивается за уши, может быть ещё хуже.
C>>>Единственное, что подслушивать можно будет только активно через MITM. Ops>>Что усложняет отладку, но не является непреодолимым препятствием для злоумышленника. C>В большинстве случаев это означает, что злоумышленник должен иметь полный контроль за каналом.
И всё это на той же централизованной схеме сертификатов?
Здравствуйте, Cyberax, Вы писали:
C>>>Так уже: N>>"Это есть, товарищи, случай так называемого вранья" (tm) N>>Читаем упомянутый драфт: C>Следующий драфт будет на следующей неделе.
"Обіцянки-цецянки" (c)
Будет или нет, а нормального времени на подумать миру просто не дают.
N>>Это не "внятный и законченный", это _ничего_ готового нет, потому что нет самого главного. N>>По сравнению с этим все эти простыни жизни потоков и раскладки битов — бесполезный тлен. C>У QUIC есть преимущество — это протокол, который уже опробован практически.
Одним гуглом, да? Даже при его толщине это просто ни о чём.
Чтобы понять все проблемы, нужны как минимум две независимые реализации, одна из которых как можно ближе к режиму "чистой комнаты" просто по спеке.
Вживую, реальные проблемы выявляются в сильно большем разнообразии условий и источников.
А для IT нормальный срок выявления, осознания проблемы и начала её решения, увы, лет 10 в обычном цикле.
N>>А если ратифицируют, значит, IETF окончательно спятил, потому что протокол такого уровня и масштаба требует не меньше года на вычитку и опробование уже после того, как _вроде бы_ финальный текст готов и отлажен вплоть до запятых. C>До июля время есть.
Время будет отсчитываться от final draft, которого ещё нет (и не надо рассказывать про "следующую неделю").
C>>>Что неудивительно, для QUIC применены все современные наработки по TCP. Собственно, над QUIC в Гугле работает Ван Якобсон. Надо рассказывать кто это? N>>У гугла потрясающая манера забирать толковых людей и превращать их работу в унылое дерьмо. N>>Вопрос не в том, кто там работает. Вопрос в том, на какую цель он работает и в какие рамки он загнан. C>Конкретно QUIC делается с простой целью — чтобы он не сосал, как TCP через middlebox'ы. Всё, больше их команду ничего не интересует. У них полная свобода творчества.
C>Единственное условие — реализуемость протокола внутри Google Chrome.
А, то есть это протокол от гугла для гугла для хождения в гугл через гугл.
Ну, если так, то я более-менее спокоен пусть гугл сам себе стреляет в ногу.
Просто в таком случае непонятно, зачем им вообще IETF.
C>>>Конкретно QUIC делается с простой целью — чтобы он не сосал, как TCP через middlebox'ы. CC>>Что то мне кажется что в реале он как раз будет сосать что тот пылесос. CC>>Потому что шторм UDP запросов говномиддлбоксы переваривают плохо. C>Они часто UDP тупо блокируют, но тут уже ничего не поделать.
C>В QUIC плюс в том, что он позволяет существенно уменьшить число пакетов в секунду, по сравнению с TCP.
Это как? При старте там может быть меньше пакетов, а во время обмена данными как сделать меньше пакетов и передать тот же объем данных?
Здравствуйте, Cyberax, Вы писали:
Ops>>А в чем польза-то? Ну сделали бы этот протокол без принудительного шифрования, а сверху пустили бы тот же TLS, когда нужно. C>Ну начнём с того, что 0-RTT connection невозможен без шифрования на уровне протокола. Но более глубокая причина в том, что одной из целей протокола было сделать middlebox'ы невозможными. Практика показала, что иначе протоколы мгновенно закостеневают.
Ты почему то за аксиому берешь что некое обозначенное тобой "закостеневают" это "плохо".
Не стесняйся, расскажи нам, что хорошего каждую неделю переделывать протоколы и форматы. Для кого это будет хорошо. И почему, если это так хорошо раньше этого не делали.
Ops>Глупости. 1% скорости на сайтах никому не нужен. Нужен трафик, тут да, гугл их и нагибает, заставляя сайты-визитки переводить на https. Но это не естественный процесс, а прогиб под прихоти монополиста.
Без https возможны вот такие фокусы с трафиком пользователя. И, насколько я понимаю, это не единичные случаи. Разумные админы сами давно стали переводить сайты на LetsEncrypt безотносительно позиции гугла по этому вопросу.
Судя по твоему ответу, системным администрированием ты никогда всерьез не занимался, но считаешь свое мнение авторитетным. Погугли Данинга-Крюгера.
Здравствуйте, Somescout, Вы писали:
S> Разница минимальна, более того со всеми подобными проблемами куда лучше справляется IPv6. Но гугля не хочет его ждать у гугли чешется NIH.
Прошу прощения, что влезаю не совсем по теме. Но у google IPv6 вполне себе включен. При этом ждать его особо не требуется — на его долю уже приходится 25% пользователей, а кое где (Бельгия) и более 50% (см. Google IPv6). РФ, конечно, традиционно в аутсайдерах, но и здесь потихоньку дело движется как со стороны провайдеров (Onlime например), так и со стороны источников контента (Яндекс например).
S> Это "три рукопожатия" на нормальном канале дадут 100-200 миллисекунд (в худшем случае!) на первом подключениии — хром будет дольше layout страницы делать.
100-200 ms это достаточно большие (уже заметные пользователю) тайминги — за них стоит побороться (особенно когда TTFB у того же ютуба составляет 20-50 ms).
P.S. И да, я тоже думаю, что QUIC в текущем виде не полетит сколь-либо массово. Скорее всего его ждет судьба SPDY, и лет через 5-7 QUIC трансформируется в какой-нибудь HTTP/2.1 и только потом потихоньку начнет получать распространение.
Здравствуйте, Vetal_ca, Вы писали:
V_>... и Geneve. V_>Но вы спорите о разных вещах. Тут проблема последней мили. Магистральные провайдеры и датацентры много чего используют, тот же IPv4 тунеллируется IPv6 а не наоборот уже давно. И прочее прочее.
Тут в другом фишка. Что гугл у себя на серверах и в своём браузере пилит свой же протокол — его право. Хотят оформить его как стандарт — почему бы и нет. Меня напрягает только маркетинг всего этого и попытки навязать это поделие туда где ему нет места. Чрезмерный маркетинг и глупости о "закостенении".
IPv6 лично у меня вообще вызывает рукалицо. Не понимаю как на базе существовавшего тогда стека можно было родить этот бред. И не внедряется он во многом из-за собственной корявости.
V_>Вопрос же про проблему последней мили последнего километра. Здесь же с зоопарком старой техники, работающей под полуметровым слоем пыли, все очень плохо.
Но работает. А не как гугл, SPDY --> HTTP/2 --> QUIC по новому стандарту в пятилетку.
Я действительно не понимаю, почему отсутствие необходимости раз в год менять железо это плохо. И зачем пытаться искусственно придумывать протоколы которые будут мешать "закостенению".
CK>Но QUIC работает поверх UDP, большая часть протокола в userspace, сейчас у UDP нет таких проблем как у TCP, ОС умеет через recvmsg обрабатывать миллионы UDP пакетов в секунду, поэтому нет проблемы 10К.
Тащемто если хотябы _немножечко_ изучить тему то обнаружится что QUIC грузит CPU сильно сильнее чем TCP.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, chaotic-kotik, Вы писали:
CK>это решается https, иначе ты можешь просто не знать, что это товой оператор так сделал, скажем на мегафоне тебе могут огромный поупап баннер на сайте показать, который на самом деле не владелец сайта туда поставил, а мегафон CK>ну и не скажешь же ты своим пользователям менять симкарты?
Да, это проблема пользователей. Без навязанного https этот баннер у них будет на большинстве сайтов, и они сами разберутся с провайдером.
Ну а твой пример с мегафоном некорректен: это у него было давно, и у малой части пользователей, сейчас про такое уже не слышно. Сейчас если кто-то где-то и балуется подобным, то это мизерная часть аудитории.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Pzz>Проблема 10K не решается сама собой от переноса соединений в user space.
Ну как же. Ведь тцп стек операционки писали криворукие старперы, а модные девелоперы быстро эти пакетики разрулят на питончике, в 100500 раз быстрее. А если будет тормозить на питончике — напишут на го, вот тогда уж точно все залетает. А если у кого все еще не залетает, то те могут эээ.. заташить этот клубок макарон* в kernel-space.
*
Новый паттерн архитектуры от гугла:
Как много веселых ребят, и все делают велосипед...
CK>>это решается https, иначе ты можешь просто не знать, что это товой оператор так сделал, скажем на мегафоне тебе могут огромный поупап баннер на сайте показать, который на самом деле не владелец сайта туда поставил, а мегафон CK>>ну и не скажешь же ты своим пользователям менять симкарты?
Ops>Да, это проблема пользователей. Без навязанного https этот баннер у них будет на большинстве сайтов, и они сами разберутся с провайдером. Ops>Ну а твой пример с мегафоном некорректен: это у него было давно, и у малой части пользователей, сейчас про такое уже не слышно. Сейчас если кто-то где-то и балуется подобным, то это мизерная часть аудитории.
Все уже давно поняли, что ты не можешь и не хочешь решать проблему подмены трафика пользователя провайдером (для этого надо всего лишь настроить https на своих сайтах и сделать автоматическое обновление сертификатов LetsEncrypt). И поэтому рассказываешь, что она не актуальна (касается мизерной части и вообще давно такого не было), перекладываешь ее решение на своих пользователей (пусть поменяют сим карты и перейдут на другого провайдера), а ответственность на Гугл (теперь всем известно, откуда твой геморрой).
Здравствуйте, Mr.Delphist, Вы писали:
MD>Здравствуйте, Cyberax, Вы писали:
C>>OSI сдохла уже давно. MD>Хммм… А мужики-то не знают! Как же она сдохла, неужели фейсбуки с контактами прямо в Ethernet-кадры данные оборачивают?
Нет. Но работа протокола IP зависит от протокола ICMP, который работает поверх IP. Нужно объяснять, что это прямое нарушение модели?
MD>P.S. Тот факт что 99% девелоперов разрабатывают application-level протоколы, вовсе не значит, что остальных 6 уровней уже более нет в природе.
В природе? Нету. OSI существует только в учебниках.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали: S>Нет. Но работа протокола IP зависит от протокола ICMP
Пардон, WAT? Работа протокола IP не зависит от ICMP. ICMP — не более чем диагностика, её наличие или отсутствие никак не влияет на работоспособность узлов. Более того, многие публичные сервисы дропают ICMP, чтобы не платить за этот трафик (если на отправителя нет пирингового соглашения) и не забивать своё оборудование лишней нагрузкой (гуглим "ICMP атака").
S>В природе? Нету. OSI существует только в учебниках.
Значит, самое время их почитать
S>Соответственно, в будущей версии HTTP транспорт TCP заменят на QUIC.
Помницца когда битторрент навелосипедил uTP то был ор от провайдеров потому что их оборудование не тянуло такую нагрузку, т.к. в UDP нету сессий, соотвественно вся stateful обработка трафика основывается на таймаутах.
Интересно тут что-то подобное планируется или они допилят UDP добавив в него end-of-session пакет?
Как много веселых ребят, и все делают велосипед...
Pzz>В TCP тоже никуда не денешься от таймаутов. Последний пакет может и не прийти, на него нельзя рассчитывать. Более того, он может прийти несколько раз, и невозможно понять, какой из них самый последний.
Это понятно. Но все же в большинстве случаев FIN/RST таки доходят, а значит бОльшая часть конекшенов освобождает ресурсы вовремя, в таймаут уходит не так много.
O>>Интересно тут что-то подобное планируется или они допилят UDP добавив в него end-of-session пакет? Pzz>В QUIC, разумеется, есть пакет, обозначающий окончание сессии. Но он зашифрованный, как и все прочие пакеты QUIC, его от любого другого не отличишь, если не знать сессионных ключей.
Логично было бы оставить расшифрованный пакет, или добавить специальное ICMP сообщение, например. Да даже добавлять не нужно, ведь есть же ICMP port unreachable который посылается в ответ на UDP датаграмму на закрытый порт, вот его можно просто самостоятельно слать при "закрытии" QUIC потока. Оборудование подозреваю уже отработает такой пакет как положено.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
Pzz>>В TCP тоже никуда не денешься от таймаутов. Последний пакет может и не прийти, на него нельзя рассчитывать. Более того, он может прийти несколько раз, и невозможно понять, какой из них самый последний. O>Это понятно. Но все же в большинстве случаев FIN/RST таки доходят, а значит бОльшая часть конекшенов освобождает ресурсы вовремя, в таймаут уходит не так много.
Вот смотри, вот нормальное завершение TCP сессии:
1) A->B: FIN
2) B->A: FIN+ACK
3) A->B: FIN+ACK
По идее, получив третий пакет в этой последовательности, роутер может забыть про сессию. Однако что будет, если третий пакет не дойдет до стороны B? В этом случае B перепошлет 2-й пакет, A перепошлет 3-й, и сессия завершится. Но это не сработает, 3 пакет дойдет до роутера где-то по-середине, удалив сессию из его таблиц, но не дойдет до стороны B. Поэтому, даже в случае TCP, роутерам приходится помнить про сессию некоторое время после ее завершения, и удалять эти записи по таймеру. Кстати, в таймерах ничего такого ужасного нет, миллион таймеров можно поддерживать с очень небольшими затратами.
O>Логично было бы оставить расшифрованный пакет, или добавить специальное ICMP сообщение, например. Да даже добавлять не нужно, ведь есть же ICMP port unreachable который посылается в ответ на UDP датаграмму на закрытый порт, вот его можно просто самостоятельно слать при "закрытии" QUIC потока. Оборудование подозреваю уже отработает такой пакет как положено.
Тогда можно будет принудительно завершать чужие сессии, не зная сессионных ключей.
Pzz>Вот смотри, вот нормальное завершение TCP сессии: Pzz>1) A->B: FIN Pzz>2) B->A: FIN+ACK Pzz>3) A->B: FIN+ACK
Pzz>По идее, получив третий пакет в этой последовательности, роутер может забыть про сессию. Однако что будет, если третий пакет не дойдет до стороны B? В этом случае B перепошлет 2-й пакет, A перепошлет 3-й, и сессия завершится. Но это не сработает, 3 пакет дойдет до роутера где-то по-середине, удалив сессию из его таблиц, но не дойдет до стороны B. Поэтому, даже в случае TCP, роутерам приходится помнить про сессию некоторое время после ее завершения, и удалять эти записи по таймеру.
В данной ситуации с потерей FIN+ACK в NAT'е вообще не вижу смысла чегото ждать. Ведь можно просто отвечать FIN+ACK-ом или даже RST на все FIN+ACKи, отсутствующие в данный момент в таблице трансляции.
Не говоря уж о том что stateful inspection FW может свободно забывать про конекшен уже на шаге 2.
Pzz> Кстати, в таймерах ничего такого ужасного нет, миллион таймеров можно поддерживать с очень небольшими затратами.
Дело не в самом таймере, а в ресурсах связанных с конекшеном и которые заморожены на время ожидания сработки этого таймера.
O>>Логично было бы оставить расшифрованный пакет, или добавить специальное ICMP сообщение, например. Да даже добавлять не нужно, ведь есть же ICMP port unreachable который посылается в ответ на UDP датаграмму на закрытый порт, вот его можно просто самостоятельно слать при "закрытии" QUIC потока. Оборудование подозреваю уже отработает такой пакет как положено. Pzz>Тогда можно будет принудительно завершать чужие сессии, не зная сессионных ключей.
Как будто сейчас этого сделать нельзя. ICMP port unreachable это _уже_ работающий механизм. Если его послать с правильными портами — висящий recv с UDP сокета обломится с ошибкой. Или последующий sendto на этот порт обломится — деталей не помню уже, т.к. сканер UDP портов, работающий по данному принципу, писал >15 лет назад
Как много веселых ребят, и все делают велосипед...
M>QUIC основан на UDP, но реализован полностью в пространстве пользователя (ядро менять не надо), поэтому
Ну и зачем вот оно такое? Сделали бы поверх UDP туннель с касторкой и гарантированной доставкой пакетов, и гоняли бы через него TCP. И UDP, а в нем еще один туннель — еще быстрее и отзывчивей. Такую систему ведь можно масштабировать фактически бесконечно.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Ops, Вы писали:
C>>QUIC можно использовать вместо TCP напрямую. Ops>Для TCP не нужны никакие сертификаты в каждом утюге, в отличие от.
Для QUIC тоже, можно просто сгенерировать эфемерные сертификаты при старте сервера.
Здравствуйте, Ops, Вы писали:
C>>Для QUIC тоже, можно просто сгенерировать эфемерные сертификаты при старте сервера. Ops>Объясни механизм. Как я могу доверять каким-то сгенеренным сертификатам без УЦ?
Никак. В этом случае не будет никаких гарантий, как и при соединении по обычному TCP. Единственное, что подслушивать можно будет только активно через MITM.
спроектированный в лабораторных условиях оказался не рабочим в реальных сетях
из за большого количества мелких пакетов pps, начали загибаться и клиентские роутеры и провайдерские узлы
а пользователи со своей стороны начали жаловаться что никакими опциями в торренте по congestion control не возможно сделать так что бы
работал и торрент и броузер
было где то еще то ли новостью то ли сам БеКо рассказывал как они это все проектировали и лажанулись с congestion control
потом конечно исправили
Здравствуйте, Ops, Вы писали:
C>>Никак. В этом случае не будет никаких гарантий, как и при соединении по обычному TCP. Ops>Тогда это профанация навязанного протоколом обязательного "шифрования" и бессмысленная нагрузка на устройства.
Нет. Как минимум, пассивные атаки работать не будут.
Дополнительно, QUIC сделан так, что предотвращает окостеневание протоколов (protocol ossification).
C>>Единственное, что подслушивать можно будет только активно через MITM. Ops>Что усложняет отладку, но не является непреодолимым препятствием для злоумышленника.
В большинстве случаев это означает, что злоумышленник должен иметь полный контроль за каналом.
S>Соответственно, в будущей версии HTTP транспорт TCP заменят на QUIC.
Не взлетит по одной очевидной причине: отказ от уровней OSI приведёт к степенному росту сложности разработки и отладки.
Разработка этого протокола не будет закончена никогда, а если и будет то получится УГ: могу делать все но очень плохо.
E>>Разработка этого протокола не будет закончена никогда, а если и будет то получится УГ: могу делать все но очень плохо. C>QUIC уже работает. В следующей версии ещё добавляют FEC для борьбы с потерями.
Он будет только начинать "уже работать" когда появится внятный и законченый стандарт.
Пока что пытаются опробовать только несовместимые между собой наколенные прототипы, но и то, судя по бенчмаркам, они уныло сосут перед TCP/IP.
Здравствуйте, netch80, Вы писали:
C>>Дополнительно, QUIC сделан так, что предотвращает окостеневание протоколов (protocol ossification). N>Прошу показать, как QUIC позволит устранять какие-то нормы стандарта, которые позднее признаны неадекватными и предложена замена (причём, какие именно, мы ещё не знаем).
TCP закостенел. Его невозможно изменить. Простенький ECN (Explicit Congestion Notification) до сих пор не поддерживается всеми middlebox'ами, через 17 лет после RFC.
С QUIC так не получится, так как там шифруется практически всё. Для middlebox'ов оставили один незашифрованный бит.
Из конкретных улучшений по сравнению с TCP:
1) PMTU полностью поднят на уровень QUIC, так как на уровне IP оно всё сдохло.
2) Multi-homing внедрён в QUIC и полностью поддерживается. Для TCP это есть только в расширении MPTCP.
3) Продуманный механизм будущих расширений.
4) FEC для компенсации потерянных пакетов (возможно, что в первую версию стандарта не попадёт).
...
N>The "ossification" Google harps on is someone else exercising some form of non-Google control, usually by virtue of having bought or being the owner or contractor of the network or computing gear, deploying something designed to be controlled by its owner, or applying standards with the same objective.
Бред.
N>Я знаю проблемы TCP. Но решение от гугла, которое притягивается за уши, может быть ещё хуже.
Чем?
Ops>>>Что усложняет отладку, но не является непреодолимым препятствием для злоумышленника. C>>В большинстве случаев это означает, что злоумышленник должен иметь полный контроль за каналом. N>И всё это на той же централизованной схеме сертификатов?
То есть? Никто не мешает использовать DNSSEC+DANE с QUIC. Или свою иерархию. В следующем стандарте будет поддержка PAKE и сильной аутентификации с паролями.
Здравствуйте, eskimo82, Вы писали:
E>>>Разработка этого протокола не будет закончена никогда, а если и будет то получится УГ: могу делать все но очень плохо. C>>QUIC уже работает. В следующей версии ещё добавляют FEC для борьбы с потерями. E>Он будет только начинать "уже работать" когда появится внятный и законченый стандарт.
Так уже: https://www.ietf.org/id/draft-ietf-quic-transport-16.txt — будет по плану ратифицирован в следующем году, во время июльской встречи IETF.
E>Пока что пытаются опробовать только несовместимые между собой наколенные прототипы, но и то, судя по бенчмаркам, они уныло сосут перед TCP/IP.
Бредим как обычно, да?
C>Так уже: https://www.ietf.org/id/draft-ietf-quic-transport-16.txt — будет по плану ратифицирован в следующем году, во время июльской встречи IETF.
Вот как будет (если будет) ратифицирован, тогда и поговорим.
C>Бредим как обычно, да?
Ты опять про свои голоса ?
C>См.: https://blog.apnic.net/2018/01/29/measuring-quic-vs-tcp-mobile-desktop/ C>Что неудивительно, для QUIC применены все современные наработки по TCP. Собственно, над QUIC в Гугле работает Ван Якобсон. Надо рассказывать кто это?
Это абсолютно монопенисуарно в текущий момент времени что там для себя колхозит гугол.
Здравствуйте, eskimo82, Вы писали:
C>>Так уже: https://www.ietf.org/id/draft-ietf-quic-transport-16.txt — будет по плану ратифицирован в следующем году, во время июльской встречи IETF. E>Вот как будет (если будет) ратифицирован, тогда и поговорим.
Ну вот, через год обращайтесь.
C>>Бредим как обычно, да? E>Ты опять про свои голоса ?
Мои голоса не бредят всякий бред.
C>>См.: https://blog.apnic.net/2018/01/29/measuring-quic-vs-tcp-mobile-desktop/ C>>Что неудивительно, для QUIC применены все современные наработки по TCP. Собственно, над QUIC в Гугле работает Ван Якобсон. Надо рассказывать кто это? E>Это абсолютно монопенисуарно в текущий момент времени что там для себя колхозит гугол.
Т.е. слился, аргументов больше нет.
По факту получилось: протокол де-факто готов, работает быстрее TCP в реальных условиях и поддерживается не только Гуглом.
Здравствуйте, netch80, Вы писали:
C>>Так уже: N>"Это есть, товарищи, случай так называемого вранья" (tm) N>Читаем упомянутый драфт:
Следующий драфт будет на следующей неделе.
N>Это не "внятный и законченный", это _ничего_ готового нет, потому что нет самого главного. N>По сравнению с этим все эти простыни жизни потоков и раскладки битов — бесполезный тлен.
У QUIC есть преимущество — это протокол, который уже опробован практически.
N>А если ратифицируют, значит, IETF окончательно спятил, потому что протокол такого уровня и масштаба требует не меньше года на вычитку и опробование уже после того, как _вроде бы_ финальный текст готов и отлажен вплоть до запятых.
До июля время есть.
C>>Что неудивительно, для QUIC применены все современные наработки по TCP. Собственно, над QUIC в Гугле работает Ван Якобсон. Надо рассказывать кто это? N>У гугла потрясающая манера забирать толковых людей и превращать их работу в унылое дерьмо. N>Вопрос не в том, кто там работает. Вопрос в том, на какую цель он работает и в какие рамки он загнан.
Конкретно QUIC делается с простой целью — чтобы он не сосал, как TCP через middlebox'ы. Всё, больше их команду ничего не интересует. У них полная свобода творчества.
Единственное условие — реализуемость протокола внутри Google Chrome.
Здравствуйте, netch80, Вы писали:
N>Впрочем, будем считать, что ты ответил на вопрос. Тогда следующий — почему это вместо нормального нового стандарта TCP-like (время которого таки пришло) или SCTP (в котором есть уже почти всё нужное) нам предлагают идти калечным путём и строить что-то поверх UDP, теряя множество важных возможностей от интеграции в IP стек. N>"Нормальные герои всегда идут в обход", да.
Это как раз понятно — слишком много сетевых железок, которые выбрасывают всё кроме TCP и UDP и никто их не выбросит. Разве это не аргумент? Вот у меня дома стоит оптический модем от провайдера, который мне даёт интернет. Нормальный провайдер у нас в стране де факто один, альтернатива ещё хуже. Модем этот я сменить не могу, не продают таких модемов в магазинах и настроек никаких у меня нет, у них там вообще своя прошивка с прошитыми параметрами. И шо мне делать с этим протоколом поверх IP? Отключать интернет и идти в пещеру? Конечно у гугла есть сила прогибать кого угодно фразой ютуб не работает, но и он не всесилен.
Здравствуйте, netch80, Вы писали:
N>Почему? Пока что всё указывает на это — гугл силой проталкивает своё крайне сырое решение, нацеленное исключительно на его интересы. N>Повторится ситуация с HTTP/2, который кое-как выкрутили с двадцатой попытки, и то постоянно с проблемами (знаю места, где сначала включили его на сервере, потом выключили нафиг, ибо реализации глючные аж нимагу).
Здравствуйте, Ops, Вы писали:
C>>Для QUIC тоже, можно просто сгенерировать эфемерные сертификаты при старте сервера.
Ops>Объясни механизм. Как я могу доверять каким-то сгенеренным сертификатам без УЦ?
Ну например, в момент первого присоединения утюга ты можешь нажать кнопку "Это точно мой утюх, мамой клянусь!", и каждый следующий раз идентичность утюга будет проверяться вполне надежно.
Здравствуйте, Pzz, Вы писали:
Pzz>Ну например, в момент первого присоединения утюга ты можешь нажать кнопку "Это точно мой утюх, мамой клянусь!", и каждый следующий раз идентичность утюга будет проверяться вполне надежно.
Во-первых, это ненадежно, утюг злоумышленника может как раз поджидать такого момента. Во-вторых, это, вероятно, уже за пределами обсуждаемого протокола — зачем тогда "шифрование" именно внутри него, если без надстроек он ничего не обеспечивает?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Hobbes, Вы писали:
Pzz>>Вот смотри, вот нормальное завершение TCP сессии: Pzz>>1) A->B: FIN Pzz>>2) B->A: FIN+ACK Pzz>>3) A->B: FIN+ACK
H>Зачем А передаёт FIN второй раз?
Здравствуйте, Ops, Вы писали:
Pzz>>Ну например, в момент первого присоединения утюга ты можешь нажать кнопку "Это точно мой утюх, мамой клянусь!", и каждый следующий раз идентичность утюга будет проверяться вполне надежно.
Ops>Во-первых, это ненадежно, утюг злоумышленника может как раз поджидать такого момента.
Этот метод считается достаточно надежным для, например, привязывания брелков к электрическим воротам, или для привязывания bluetooth устройств. Воткнуться, конечно, в нужный момент можно, но это надо очень постараться.
Ops>Во-вторых, это, вероятно, уже за пределами обсуждаемого протокола — зачем тогда "шифрование" именно внутри него, если без надстроек он ничего не обеспечивает?
Без надстроек он обеспечивает TLS-like модель безопасности, при наличии соответствующей инфраструктуры для раздачи сертификатов.
Здравствуйте, Pzz, Вы писали:
C>>4) FEC для компенсации потерянных пакетов (возможно, что в первую версию стандарта не попадёт). Pzz>Я читал гуглевскую статью, где они исследовали свой FEC на симуляторе. Пишут, что в большинстве сценариев с FEC'ом хуже, чем без него.
Ага, первая версия оказалась хуже, чем ничего: https://docs.google.com/document/d/1Hg1SaLEl6T4rEU9j-isovCo8VEjjnuCPTcLNJewj7Nk
Здравствуйте, Cyberax, Вы писали:
C>В QUIC плюс в том, что он позволяет существенно уменьшить число пакетов в секунду, по сравнению с TCP.
Это всё будет пофигу если оно не будет работать на существующем зоопарке железа, которое никто ради одного этого прокотола не станет менять.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, netch80, Вы писали:
C>>TCP закостенел. Его невозможно изменить. Простенький ECN (Explicit Congestion Notification) до сих пор не поддерживается всеми middlebox'ами, через 17 лет после RFC. N>"C++ закостенел, потому что простейшие нормы C++11 до сих пор не поддерживаются всеми компиляторами."
Нет. В случае с С++ мне достаточно одного компилятора, который работал бы. В случае с TCP мне надо, чтобы ВСЕ узлы поддерживали новую фичу, если я Google.
N>Впрочем, будем считать, что ты ответил на вопрос. Тогда следующий — почему это вместо нормального нового стандарта TCP-like (время которого таки пришло) или SCTP (в котором есть уже почти всё нужное) нам предлагают идти калечным путём и строить что-то поверх UDP, теряя множество важных возможностей от интеграции в IP стек.
Протоколы IP-уровня все сдохли, так как middlebox'ы знают только TCP и UDP.
C>>С QUIC так не получится, так как там шифруется практически всё. Для middlebox'ов оставили один незашифрованный бит. N>Ну вот ты впал в ту же сторону, что гугл — всё, что посреди, назвать "middlebox", назначить этому ярлыку заведомо отрицательную роль и считать свою историческую роль выполненной.
Она и есть заведомо отрицательная, так как (например) делает SCTP бесполезным.
C>>Из конкретных улучшений по сравнению с TCP: C>>1) PMTU полностью поднят на уровень QUIC, так как на уровне IP оно всё сдохло. N>На уровне IP его, как ни странно, за последние годы починили чуть менее, чем везде.
Не починили. Как один из видимых эффектов, DNS с DNSSEC работает нормально нынче только через TCP.
N>Если в начале 2000х я постоянно боролся с ним даже как клиент, то за последние лет 5 проблемы не видно.
Просто научились обходить.
C>>4) FEC для компенсации потерянных пакетов (возможно, что в первую версию стандарта не попадёт). N>И будет точно так же, как с TCP? Первая версия застынет у 90% участников.
Проблема с TCP в том, что если я сейчас попробую использовать мега-кул-фичу, то заметная часть клиентов сломается. QUIC постарались сделать так, что новые мега-кул-фичи будут явно отключаться при установлении соединения.
C>>Бред. N>Почему? Пока что всё указывает на это — гугл силой проталкивает своё крайне сырое решение, нацеленное исключительно на его интересы.
Закостеневание невыгодно всем, кроме производителей middlebox'ов. О каком контроле Гугла тут речь — непонятно, IETF от Гугла не зависит.
N>Повторится ситуация с HTTP/2, который кое-как выкрутили с двадцатой попытки, и то постоянно с проблемами (знаю места, где сначала включили его на сервере, потом выключили нафиг, ибо реализации глючные аж нимагу).
QUIC уже работает более как 5 лет в Chrome.
N>>>Я знаю проблемы TCP. Но решение от гугла, которое притягивается за уши, может быть ещё хуже. C>>Чем? N>Именно сыростью и однобокостью цели.
А зачем всебокий протокол?
Здравствуйте, netch80, Вы писали:
C>>Следующий драфт будет на следующей неделе. N>"Обіцянки-цецянки" (c) N>Будет или нет, а нормального времени на подумать миру просто не дают.
Что тут думать? Бежать надо!
C>>У QUIC есть преимущество — это протокол, который уже опробован практически. N>Одним гуглом, да? Даже при его толщине это просто ни о чём. https://github.com/quicwg/base-drafts/wiki/Implementations
N>Чтобы понять все проблемы, нужны как минимум две независимые реализации, одна из которых как можно ближе к режиму "чистой комнаты" просто по спеке. N>Вживую, реальные проблемы выявляются в сильно большем разнообразии условий и источников.
Уже.
C>>Конкретно QUIC делается с простой целью — чтобы он не сосал, как TCP через middlebox'ы. Всё, больше их команду ничего не интересует. У них полная свобода творчества. C>>Единственное условие — реализуемость протокола внутри Google Chrome. N>А, то есть это протокол от гугла для гугла для хождения в гугл через гугл.
Ещё Facebook'а.
N>Ну, если так, то я более-менее спокоен пусть гугл сам себе стреляет в ногу. N>Просто в таком случае непонятно, зачем им вообще IETF.
QUIC уже используют несколько крупных Интернет-гигантов.
Здравствуйте, Pzz, Вы писали:
Pzz>Этот метод считается достаточно надежным для, например, привязывания брелков к электрическим воротам, или для привязывания bluetooth устройств. Воткнуться, конечно, в нужный момент можно, но это надо очень постараться.
BT, WPS и, подозреваю, ворота с брелоками, обеспечивают это вообще на канальном уровне. А уже на уровне IP такой сценарий затруднителен, из-за меньшей локальности хостов в общем случае.
Pzz>Без надстроек он обеспечивает TLS-like модель безопасности, при наличии соответствующей инфраструктуры для раздачи сертификатов.
А в чем польза-то? Ну сделали бы этот протокол без принудительного шифрования, а сверху пустили бы тот же TLS, когда нужно.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, netch80, Вы писали:
N>4) B->A: 0 байт, SN=5000, ACK=1201 (подтвердила, что увидела FIN) N>с этого момента соединение одностороннее; B может писать, но не читать
Вот я и думал, что B уже точно-точно подтвердил приём FIN, и отправлять FIN второй раз смысла нет.
Здравствуйте, Ops, Вы писали:
Pzz>>Без надстроек он обеспечивает TLS-like модель безопасности, при наличии соответствующей инфраструктуры для раздачи сертификатов. Ops>А в чем польза-то? Ну сделали бы этот протокол без принудительного шифрования, а сверху пустили бы тот же TLS, когда нужно.
Ну начнём с того, что 0-RTT connection невозможен без шифрования на уровне протокола. Но более глубокая причина в том, что одной из целей протокола было сделать middlebox'ы невозможными. Практика показала, что иначе протоколы мгновенно закостеневают.
Здравствуйте, Masterspline, Вы писали:
C>>В QUIC плюс в том, что он позволяет существенно уменьшить число пакетов в секунду, по сравнению с TCP. M>Это как? При старте там может быть меньше пакетов, а во время обмена данными как сделать меньше пакетов и передать тот же объем данных?
Одной из проблем в Интернете является PMTU — поиск максимального размера пакета. Потому многие серверы тупо ставят что-то типа 1380 (Google) для гарантии того, что ответы пройдут через любые разумные тоннели ( https://jamesdobson.name/post/mtu/ ).
В QUIC поиск оптимального размера пакетов вынесен на уровень протокола, и сделан так, что работает оппортунистически в фоновом режиме.
Здравствуйте, Cyberax, Вы писали:
C>Одной из проблем в Интернете является PMTU — поиск максимального размера пакета. Потому многие серверы тупо ставят что-то типа 1380 (Google) для гарантии того, что ответы пройдут через любые разумные тоннели ( https://jamesdobson.name/post/mtu/ ).
А с чего вдруг это проблема? Максимум это немного (действительно ненамного) повышает нагрузку на оборудование провайдера (затраты на маршрутизацию пакетов, но визуально это заметно когда пакеты сильно меньше килобайта. Да и в любом случае геморроя с маршрутизацией UDP будет больше). А само увеличение объёмов данных можно посчитать. Посчитаем, например, оверхэд TCP для передачи 10КБ при разных размерах пакетов:
1380: 10KB/1380 ~ 7.42 ~ 8 пакетов, длинна TCP заголовка — 20 байт, 160 байт на 10KB данных
1490: 10KB/1490 ~ 6.87 ~ 7 пакетов, длинна TCP заголовка — 20 байт, 140 байт на 10KB данных
20 байт оверхэда на 10KB информации ~ 0.2% выигрыша, причём в идеальных условиях, когда на пути только ethernet с максимальным размером кадра.
C>В QUIC поиск оптимального размера пакетов вынесен на уровень протокола, и сделан так, что работает оппортунистически в фоновом режиме.
Eye-roll — сначала браузер превратили в комбайн, теперь протокол.
ЗЫ. Ютуб тупит на любом браузере далеко не из-за протокола, но лучше ведь в очередной раз поставить интернет раком, а не фиксить свои сайты.
Здравствуйте, Somescout, Вы писали:
C>>Одной из проблем в Интернете является PMTU — поиск максимального размера пакета. Потому многие серверы тупо ставят что-то типа 1380 (Google) для гарантии того, что ответы пройдут через любые разумные тоннели ( https://jamesdobson.name/post/mtu/ ). S>А с чего вдруг это проблема?
Увеличивает число пакетов. Именно число пакетов в секунду нынче является узким горлышком в железе.
При учёте пакетов не забываем отсутствие тройного рукопожатия, при 0-RTT сервер отправляет данные в первом же пакете.
S>Максимум это немного (действительно ненамного) повышает нагрузку на оборудование провайдера (затраты на маршрутизацию пакетов, но визуально это заметно когда пакеты сильно меньше килобайта. Да и в любом случае геморроя с маршрутизацией UDP будет больше).
ЩИТО?
S>ЗЫ. Ютуб тупит на любом браузере далеко не из-за протокола, но лучше ведь в очередной раз поставить интернет раком, а не фиксить свои сайты.
ЩИТО?
Здравствуйте, m2l, Вы писали:
C>>Ну начнём с того, что 0-RTT connection невозможен без шифрования на уровне протокола. Но более глубокая причина в том, что одной из целей протокола было сделать middlebox'ы невозможными. Практика показала, что иначе протоколы мгновенно закостеневают. m2l>Ты почему то за аксиому берешь что некое обозначенное тобой "закостеневают" это "плохо".
Потому, что это плохо. Это останавливает саму возможность развития протоколов.
m2l>Не стесняйся, расскажи нам, что хорошего каждую неделю переделывать протоколы и форматы. Для кого это будет хорошо. И почему, если это так хорошо раньше этого не делали.
"Мой дед крутил гайки ключом на 15, мой отец крутил гайки ключом на 15, и я буду крутить гайки ключом на 15!"
А не делали из-за того, что протоколы начали костенеть в районе 2001-го года. Я уже привёл пример с ECN.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Somescout, Вы писали:
C>>>Одной из проблем в Интернете является PMTU — поиск максимального размера пакета. Потому многие серверы тупо ставят что-то типа 1380 (Google) для гарантии того, что ответы пройдут через любые разумные тоннели ( https://jamesdobson.name/post/mtu/ ). S>>А с чего вдруг это проблема? C>Увеличивает число пакетов. Именно число пакетов в секунду нынче является узким горлышком в железе.
Разница минимальна, более того со всеми подобными проблемами куда лучше справляется IPv6. Но гугля не хочет его ждать у гугли чешется NIH.
C>При учёте пакетов не забываем отсутствие тройного рукопожатия, при 0-RTT сервер отправляет данные в первом же пакете.
Лол — QUIC показывает наилучшие результаты на broadband, а когда пугают "тремя рукопожатиями" используют примеры с таймингами чуть ли не из мобильной связи, где QUIC отсасывает. Это "три рукопожатия" на нормальном канале дадут 100-200 миллисекунд (в худшем случае!) на первом подключениии — хром будет дольше layout страницы делать.
S>>Максимум это немного (действительно ненамного) повышает нагрузку на оборудование провайдера (затраты на маршрутизацию пакетов, но визуально это заметно когда пакеты сильно меньше килобайта. Да и в любом случае геморроя с маршрутизацией UDP будет больше). C>ЩИТО?
"Маршрутизацией", посмотрите значение в словаре.
S>>ЗЫ. Ютуб тупит на любом браузере далеко не из-за протокола, но лучше ведь в очередной раз поставить интернет раком, а не фиксить свои сайты. C>ЩИТО?
ШИ ТО. Ютуб второй после твитча случай, когда программистам можно пересадить руки макаки и это не ухудшит результат. Гугль гонится за миллисекундами скорости, игнорируя что один из их основных сайтов тормозное ****.
Здравствуйте, Somescout, Вы писали:
C>>Увеличивает число пакетов. Именно число пакетов в секунду нынче является узким горлышком в железе. S>Разница минимальна, более того со всеми подобными проблемами куда лучше справляется IPv6. Но гугля не хочет его ждать у гугли чешется NIH.
В IPv6 число пакетов ровно такое же. Точнее, на практике ещё большее из-за того, что MTU руками занижают ещё сильнее.
S>Лол — QUIC показывает наилучшие результаты на broadband, а когда пугают "тремя рукопожатиями" используют примеры с таймингами чуть ли не из мобильной связи, где QUIC отсасывает. Это "три рукопожатия" на нормальном канале дадут 100-200 миллисекунд (в худшем случае!) на первом подключениии — хром будет дольше layout страницы делать.
Если обращение на страницу в другой части страны (с западного берега на восточный) — это уже почти треть секунды на RTT. Уже очень заметно.
S>>>Максимум это немного (действительно ненамного) повышает нагрузку на оборудование провайдера (затраты на маршрутизацию пакетов, но визуально это заметно когда пакеты сильно меньше килобайта. Да и в любом случае геморроя с маршрутизацией UDP будет больше). C>>ЩИТО? S>"Маршрутизацией", посмотрите значение в словаре.
ЩИТО такое "маршрутизация UDP"?
S>>>ЗЫ. Ютуб тупит на любом браузере далеко не из-за протокола, но лучше ведь в очередной раз поставить интернет раком, а не фиксить свои сайты. C>>ЩИТО? S>ШИ ТО. Ютуб второй после твитча случай, когда программистам можно пересадить руки макаки и это не ухудшит результат. Гугль гонится за миллисекундами скорости, игнорируя что один из их основных сайтов тормозное ****.
Ну да, один Somescout такой умный. Что там где тормозит, конкретно?
Здравствуйте, m2l, Вы писали:
C>>Потому, что это плохо. Это останавливает саму возможность развития протоколов. m2l>Логики нет в твоих словах. К примеру cloud & sdn дают развитие vxvlan. Умные устройства дают возможности для "промышленных протоколов". Через 30 лет после TCP и UDP появились SCTP и DCCP.
SCTP не работает в публичном Интернете из-за вездесущих middlebox'ов. В частности, на большинстве мобильных устройств.
Любое приложение, которое будет пытаться использовать SCTP пойдёт лесом примерно для так ~20% пользователей.
C>>"Мой дед крутил гайки ключом на 15, мой отец крутил гайки ключом на 15, и я буду крутить гайки ключом на 15!" m2l>Действительно, он крутил на 15, а мы будет крутить на 16, через год заменим на 14, потом на 15 с половиной. Ведь это развитие! Если просто так не менять их диаметр, то будет плохо!
Нет. Будешь крутить и дальше ключом на 15.
C>>А не делали из-за того, что протоколы начали костенеть в районе 2001-го года. Я уже привёл пример с ECN. m2l>ИМХО, ты немного не разобрался отчего оно реализовано и отключено по умолчанию.
ECN не включен из-за того, что ДО СИХ ПОР его неправильно обрабатывают middlebox'ы.
Здравствуйте, Ops, Вы писали:
Pzz>>Этот метод считается достаточно надежным для, например, привязывания брелков к электрическим воротам, или для привязывания bluetooth устройств. Воткнуться, конечно, в нужный момент можно, но это надо очень постараться.
Ops>BT, WPS и, подозреваю, ворота с брелоками, обеспечивают это вообще на канальном уровне. А уже на уровне IP такой сценарий затруднителен, из-за меньшей локальности хостов в общем случае.
Ну спросили про утюг, я и ответил про утюг. Утюг всегда локален, иначе нафиг он вообще нужен? Каждая задача должна решаться с учетом спецефических для нее потребностей.
В общем и целом, доверие должно на чем-то основываться. Использование сертификационных центров, которым все доверяют (совершенно напрасно, на мой взглад) — один из вариантов. Использование явного действия со стороны пользователя — другой возможный вариант, при условии, что пользователь действительно понимает, что он делает.
Pzz>>Без надстроек он обеспечивает TLS-like модель безопасности, при наличии соответствующей инфраструктуры для раздачи сертификатов.
Ops>А в чем польза-то? Ну сделали бы этот протокол без принудительного шифрования, а сверху пустили бы тот же TLS, когда нужно.
В том, что от внесения шифрования на уровень транспортного протокола, можно добиться существенной экономии. Например, объединяя "TLS" handshake и "TCP" handshake, можно установить соединение с шифрованием за 1-2 RTT, а не за 5-7, как в случае TCP+TLS. Объеденив "TCP" sequence numbers с криптографическим nonce, можно сэкономить несколько байт на пакет, что заметно, если пакеты маленькие (как в случае аудиопотока, например). Ну и т.д. и т.п.
Здравствуйте, CreatorCray, Вы писали:
CC>Что то мне кажется что в реале он как раз будет сосать что тот пылесос. CC>Потому что шторм UDP запросов говномиддлбоксы переваривают плохо.
Миддлбоксам придется подвинуться, потому что google chrome — это чуть менее, чем все мобильные устройства.
Здравствуйте, Pzz, Вы писали:
Pzz>В том, что от внесения шифрования на уровень транспортного протокола, можно добиться существенной экономии.
Экономия будет, если не заставлять всех шифровать все подряд. Тогда в утюг можно будет впихнуть МК на 3 рубля дешевле, что в мировых масштабах вполне существенно.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
Pzz>>В том, что от внесения шифрования на уровень транспортного протокола, можно добиться существенной экономии.
Ops>Экономия будет, если не заставлять всех шифровать все подряд. Тогда в утюг можно будет впихнуть МК на 3 рубля дешевле, что в мировых масштабах вполне существенно.
С тех пор, как сети стали радиофицированными, отказ от адекватного шифрования является дырой в защите чуть менее, чем всегда.
Хотите сэкономить 3 рубля на утюге — не надо его вообще подключать к сети.
Ops>>Экономия будет, если не заставлять всех шифровать все подряд. Тогда в утюг можно будет впихнуть МК на 3 рубля дешевле, что в мировых масштабах вполне существенно. Pzz>С тех пор, как сети стали радиофицированными, отказ от адекватного шифрования является дырой в защите чуть менее, чем всегда.
Шифрование не везде и не всегда нужно. Оно не обязательно.
Pzz>Хотите сэкономить 3 рубля на утюге — не надо его вообще подключать к сети.
Шифрование само по себе довольно дорого — это не просто данные ближайшим пакетом по DMA в сетевую карту отправить, это гораздо сложнее.
Поэтому единственно адекватным по скорости решением будет полностью аппаратное шифрование. Т.е. замена всего парка (промежуточного) железа.
PS: Ops в этом совершенно прав.
PS2: Вообщем ерунда все это. Концепция этого протокола нарушает простую истину — делай только одну вещь, но делай ее качественно.
Если этого не придерживаться, то сложность разработки и отладки возрастает как степенная функция вплоть до невозможности правильной реализации.
Поэтому на все это можно смотреть ка кна очередной красноглазый хайп среди хипстеров, но логику и природу то не обманеш.
— quic не предлагают заменить полностью на tcp
— quic предлагают подменить на tcp в http
— quic как и tcp работает на ендпоинтах, а не на всех промежуточных узлах,
поэтому я не представляю что именно вы собрались такое тяжелое гонять по http в криптографии по quic, что бы загнуть ендпоинт девайсы
— все таки гугл смотрит вперед а не на зад, и в обозримом будущем когда quic сможет получить распространение, криптография hw на девайсах я думаю уже будет, а tcp under http подтормаживает
и в этом гуглу видней, так же как они изобретали bbr
Здравствуйте, Pzz, Вы писали:
Pzz>С тех пор, как сети стали радиофицированными, отказ от адекватного шифрования является дырой в защите чуть менее, чем всегда.
В радио сетях оно УЖЕ есть, на канальном уровне. Зачем 2-й раз шифровать? Потому что так гуглу захотелось?
Pzz>Хотите сэкономить 3 рубля на утюге — не надо его вообще подключать к сети.
Ну это, к счастью, не тебе решать.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Somescout, Вы писали:
S>ШИ ТО. Ютуб второй после твитча случай, когда программистам можно пересадить руки макаки и это не ухудшит результат. Гугль гонится за миллисекундами скорости, игнорируя что один из их основных сайтов тормозное ****.
Почему тормозное? У меня очень быстро открывается и работает.
Здравствуйте, eskimo82, Вы писали:
E>PS2: Вообщем ерунда все это. Концепция этого протокола нарушает простую истину — делай только одну вещь, но делай ее качественно. E>Если этого не придерживаться, то сложность разработки и отладки возрастает как степенная функция вплоть до невозможности правильной реализации.
Этого принципа много кто не придерживается. Возьми ядро операционной системы. Вроде бы должны придерживаться микроядерного подхода, как ты говоришь. Но всё пихают в один монолит, т.к. быстрей. Возьми СУБД. Запихали JSON. При чём тут JSON и реляционная база данных? Не при чём, но удобно и быстро. Так и тут. Если это будет быстрей, сделают. Т.к. сделать надо по сути один раз, а остальные будут использовать готовую библиотеку. Концептуально может и не правильно, но на практике нормально.
Здравствуйте, Pzz, Вы писали:
Pzz>У меня сложилось впечатление, при использовании 0-RTT первая порция данных от "клиента" к "серверу" посылается еще до то того как идентичность "сервера" подтверждена. Т.е., например, если у нас HTTP, то параметры HTTP GET посылаются "куда-то там", и лишь к моменту получения ответа можно проверить, что мы именно с тем и разговариваем, с кем собирались.
Для 0-RTT нужно иметь уже установленную ассоциацию. Клиент в первом пакете посылает тогда использует сохранённую cookie от сервера (которая содержит зашифрованное сервером состояние серверного соединения), посылая её с параметрами для установки соединения.
Pzz>Гражданам, конструирующим всякие там REST API это следовало бы иметь ввиду. Потому что если параметры запроса секретные, то можно получить дыру в защите в неожиданном (из прошлого опыта) месте.
Для 0-RTT возможна Replay-атака, но данные оно раскрыть не сможет.
Здравствуйте, Pzz, Вы писали:
C>>В QUIC плюс в том, что он позволяет существенно уменьшить число пакетов в секунду, по сравнению с TCP. Pzz>С чего бы ему существенно уменьшать количество пакетов в секунду? Или ты имеешь ввиду экономию на ACK'ах?
Экономия на ACK, использование MTU на полную катушку. В Google жёстко забили MTU в 1380, расширение его до 1500 (или более!) вызовет экономию в 10%.
Здравствуйте, Ops, Вы писали:
Pzz>>В том, что от внесения шифрования на уровень транспортного протокола, можно добиться существенной экономии. Ops>Экономия будет, если не заставлять всех шифровать все подряд. Тогда в утюг можно будет впихнуть МК на 3 рубля дешевле, что в мировых масштабах вполне существенно.
Шифрование данных в масштабе утюга делается без проблем на Ардуине: https://www.wolfssl.com/
Если отключить всё ненужное, то оно вмещается в 20 килобайт кода и занимает 1 килобайт памяти на промежуточные вычисления.
Так что и утюги без проблем могут использовать шифрование.
Здравствуйте, Ops, Вы писали:
Pzz>>С тех пор, как сети стали радиофицированными, отказ от адекватного шифрования является дырой в защите чуть менее, чем всегда. Ops>В радио сетях оно УЖЕ есть, на канальном уровне. Зачем 2-й раз шифровать? Потому что так гуглу захотелось?
Нету. В WPA2 при слабом пароле можно запустить offline-атаку и расшифровать трафик.
В WPA3 это исправили, но его пока ещё никто не поддерживает.
Здравствуйте, eskimo82, Вы писали:
Pzz>>С тех пор, как сети стали радиофицированными, отказ от адекватного шифрования является дырой в защите чуть менее, чем всегда. E>Шифрование не везде и не всегда нужно. Оно не обязательно.
Оно нужно всегда.
Pzz>>Хотите сэкономить 3 рубля на утюге — не надо его вообще подключать к сети. E>Шифрование само по себе довольно дорого — это не просто данные ближайшим пакетом по DMA в сетевую карту отправить, это гораздо сложнее.
Где дорого? Текущие CPU позволяют шифровать быстрее, чем данные летят в сеть: https://calomel.org/aesni_ssl_performance.html
E>Поэтому единственно адекватным по скорости решением будет полностью аппаратное шифрование. Т.е. замена всего парка (промежуточного) железа.
Хватит бредить. Промежуточное железо ничего не должно шифровать. Этим занимается сервер и клиент, всё.
И все это гугл
C>А админов вообще не спрашивали. Если ради 1% улучшения скорости они должны будут стоять на ушах — они будут стоять на ушах.
Глупости. 1% скорости на сайтах никому не нужен. Нужен трафик, тут да, гугл их и нагибает, заставляя сайты-визитки переводить на https. Но это не естественный процесс, а прогиб под прихоти монополиста.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Cyberax, Вы писали:
C>Шифрование данных в масштабе утюга делается без проблем на Ардуине: https://www.wolfssl.com/
C>Если отключить всё ненужное, то оно вмещается в 20 килобайт кода и занимает 1 килобайт памяти на промежуточные вычисления.
C>Так что и утюги без проблем могут использовать шифрование.
У самой популярной ардуины UNO эти объемы 8к и 512 байт, чего ты лечишь?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
C>>Так что и утюги без проблем могут использовать шифрование. Ops>У самой популярной ардуины UNO эти объемы 8к и 512 байт, чего ты лечишь? https://store.arduino.cc/usa/arduino-uno-rev3
Flash Memory 32 KB (ATmega328P) of which 0.5 KB used by bootloader
SRAM 2 KB (ATmega328P)
EEPROM 1 KB (ATmega328P)
Здравствуйте, Ops, Вы писали:
C>>Нету. В WPA2 при слабом пароле можно запустить offline-атаку и расшифровать трафик. Ops>Это проблема не шифрования, а слабого пароля. А с WPS, про который тут речь, удобен любой пароль, а не только короткий/читаемый.
Нет. Это проблема шифрования, так как правильные протоколы (PAKE) это исправляют. Кстати, есть ещё и полностью открытые сети.
Здравствуйте, Cyberax, Вы писали:
C>Я не очень понимаю, кому-то НРАВИТСЯ, что их сайты-визитки могут использовать для атак на пользователя или для доставки рекламы путём переписывания HTML?
Каких атак? Пример реальных можешь привести?
Вот есть сайт визитка, на нем телефоны и карта проезда к офису, что за атаки к нему применяются?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
C>Flash Memory 32 KB (ATmega328P) of which 0.5 KB used by bootloader
C>SRAM 2 KB (ATmega328P)
C>EEPROM 1 KB (ATmega328P)
C>Как раз всё влезает.
Ну может быть rev3... Но это больше половины ресурсов на одну TLS выкинуть. Только я бы для утюга вообще тиньку брал, ибо только они с маленьким числом ног встречаются, а там все сильно скромнее.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
C>Экономия на ACK, использование MTU на полную катушку. В Google жёстко забили MTU в 1380, расширение его до 1500 (или более!) вызовет экономию в 10%.
Ну это примерно как создать новую модель автомобиля, потому что в имеющемся экземпляре серийной модели ты подложил булыжник под педаль газа.
Как много веселых ребят, и все делают велосипед...
C>>Я не очень понимаю, кому-то НРАВИТСЯ, что их сайты-визитки могут использовать для атак на пользователя или для доставки рекламы путём переписывания HTML?
Ops>Каких атак? Пример реальных можешь привести? Ops>Вот есть сайт визитка, на нем телефоны и карта проезда к офису, что за атаки к нему применяются?
Вот, например. Еще про такое безобразие писали на хабре про Beeline. Подмена http трафика провайдером — стандартная практика.
C>>Flash Memory 32 KB (ATmega328P) of which 0.5 KB used by bootloader
C>>SRAM 2 KB (ATmega328P)
C>>EEPROM 1 KB (ATmega328P)
C>>Как раз всё влезает.
Ops>Ну может быть rev3... Но это больше половины ресурсов на одну TLS выкинуть. Только я бы для утюга вообще тиньку брал, ибо только они с маленьким числом ног встречаются, а там все сильно скромнее.
Насколько я понимаю, такие немощные SOC используются там, где выход в интернет (а значит и TLS) не нужен (как контроллер в фонарике, например, чтобы на нем программно реализовать мигание в разных режимах, при стоимости процессора в 40Р и потреблении тока меньше тока утечки батарейки вполне оправданное решение).
P.S. Мне тут сказали, что 8-ми битные решения уже не котируются ни по доступности, ни по цене, ни, даже, по потреблению тока. STM32 рулят. Так что теперь Arduino — это скорее популярный форм-фактор, для которого создано много навешивающегося оборудования. Внутри используется STM32.
Здравствуйте, Masterspline, Вы писали:
M>Без https возможны вот такие фокусы с трафиком пользователя. И, насколько я понимаю, это не единичные случаи. Разумные админы сами давно стали переводить сайты на LetsEncrypt безотносительно позиции гугла по этому вопросу.
Может быть. Решается голосованием ногами — этот провайдер может и в другом нагадить, нафиг он нужен?
M>Судя по твоему ответу, системным администрированием ты никогда всерьез не занимался, но считаешь свое мнение авторитетным. Погугли Данинга-Крюгера.
Не занимался. Но у меня есть несколько сайтов, и никаких положительных изменений от перехода на https я не увидел, кроме того, что гугл не занижает их позицию. Объясни мне, компетентный, что я от этого геморроя получил, чего я не знаю?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Masterspline, Вы писали:
M>Насколько я понимаю, такие немощные SOC используются там, где выход в интернет (а значит и TLS) не нужен (как контроллер в фонарике, например, чтобы на нем программно реализовать мигание в разных режимах, при стоимости процессора в 40Р и потреблении тока меньше тока утечки батарейки вполне оправданное решение).
Инет не нужен скорее всего, а вот TCP может быть удобен. Здесь же предлагается в протокол того же уровня, что TCP, вкорячить TLS принудительно и неотключаемо.
M>P.S. Мне тут сказали, что 8-ми битные решения уже не котируются ни по доступности, ни по цене, ни, даже, по потреблению тока. STM32 рулят. Так что теперь Arduino — это скорее популярный форм-фактор, для которого создано много навешивающегося оборудования. Внутри используется STM32.
Когда нужен мелкий корпус с 16, а то и с 6-8 ногами, не требующий никакой обвязки, вариантов почти нет
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, ononim, Вы писали:
C>>Экономия на ACK, использование MTU на полную катушку. В Google жёстко забили MTU в 1380, расширение его до 1500 (или более!) вызовет экономию в 10%. O>Ну это примерно как создать новую модель автомобиля, потому что в имеющемся экземпляре серийной модели ты подложил булыжник под педаль газа.
Проблема в том, что существующий TCP ломается у заметного количества клиентов, если не делать таких уродских хаков. Если есть идеи как это исправить в рамках существующего TCP — добро пожаловать в Гугл на семизначную зарплату.
Ops>Инет не нужен скорее всего, а вот TCP может быть удобен. Здесь же предлагается в протокол того же уровня, что TCP, вкорячить TLS принудительно и неотключаемо.
QUIC это не tcp, это tcp+HTTP поверх UDP. Уверен, его могли бы сделать и над ip, но для этого пришлось бы влезать в ядро пользовательского устройства. TLS там необходим для защиты от разных DDOS и реализации 0-RTT (наверняка еще много для чего). У QUIC своя ниша и он будет в ней работать (это не слабые железки с небольшим размером RAM и без аппаратного шифрования, там tcp как был, так и останется).
M>>Без https возможны вот такие фокусы с трафиком пользователя. И, насколько я понимаю, это не единичные случаи. Разумные админы сами давно стали переводить сайты на LetsEncrypt безотносительно позиции гугла по этому вопросу.
Ops>Может быть. Решается голосованием ногами — этот провайдер может и в другом нагадить, нафиг он нужен?
M>>Судя по твоему ответу, системным администрированием ты никогда всерьез не занимался, но считаешь свое мнение авторитетным. Погугли Данинга-Крюгера.
Ops>Не занимался. Но у меня есть несколько сайтов, и никаких положительных изменений от перехода на https я не увидел, кроме того, что гугл не занижает их позицию. Объясни мне, компетентный, что я от этого геморроя получил, чего я не знаю?
Скорее всего, ничего кроме того, что никакой промежуточный провайдер не сможет анализировать твой трафик и вставлять в твои страницы свои скрипты (для показа рекламы, например). Делается это у хостеров само (включено по умолчанию, т.е. вообще ничего делать не надо, только поисковику объяснить, что ссылки надо давать на https), на своем оборудовании нужно настроить что-то типа dehydrated со своим скриптом (для этого потратить немного времени). Ну, а гугл лишь слегка поощряет переход админов сайтов на безопасные технологии (ранжирование сайтов без https, пометка их в адресной строке хрома как небезопасных), потому что без шифрования начинает твориться совсем уж беспредел. Хотя, как Хром будет реагировать, когда я в нем открою веб интерфейс управления слабенькой железки у меня же дома на каком-нибудь STM32f4 и не увидит там TLS, я не знаю.
> Объясни мне, компетентный, что я от этого геморроя получил, чего я не знаю?
Не понимаю я людей, которые что-то делают, а потом рассказывают, какая у них трудная жизнь. Если для тебя так сложно администрировать сайт, то зачем ты вообще за это взялся? Может тебе лучше заняться чем-то другим, если выполнение довольно простой работы вызывает такие сложности? Чем-то, что принесет и деньги и удовольствие.
Здравствуйте, Ops, Вы писали:
M>>Без https возможны вот такие фокусы с трафиком пользователя. И, насколько я понимаю, это не единичные случаи. Разумные админы сами давно стали переводить сайты на LetsEncrypt безотносительно позиции гугла по этому вопросу. Ops>Может быть. Решается голосованием ногами — этот провайдер может и в другом нагадить, нафиг он нужен?
А другого может и не быть. А ещё может Китай навредить — https://en.wikipedia.org/wiki/Great_Cannon
В общем, в современном мире использовать HTTP в Интернете — это халатность.
Здравствуйте, Masterspline, Вы писали:
M>Скорее всего, ничего кроме того, что никакой промежуточный провайдер не сможет анализировать твой трафик и вставлять в твои страницы свои скрипты (для показа рекламы, например). Делается это у хостеров само (включено по умолчанию, т.е. вообще ничего делать не надо, только поисковику объяснить, что ссылки надо давать на https), на своем оборудовании нужно настроить что-то типа dehydrated со своим скриптом (для этого потратить немного времени).
Только обычно это не делается, а отдельные случаи, во-первых редки, а во-вторых — проблема клиента.
M>Ну, а гугл лишь слегка поощряет переход админов сайтов на безопасные технологии (ранжирование сайтов без https, пометка их в адресной строке хрома как небезопасных), потому что без шифрования начинает твориться совсем уж беспредел. Хотя, как Хром будет реагировать, когда я в нем открою веб интерфейс управления слабенькой железки у меня же дома на каком-нибудь STM32f4 и не увидит там TLS, я не знаю.
Это какой еще беспредел-то? Десятки лет не было, а тут появился?
M>Не понимаю я людей, которые что-то делают, а потом рассказывают, какая у них трудная жизнь. Если для тебя так сложно администрировать сайт, то зачем ты вообще за это взялся? Может тебе лучше заняться чем-то другим, если выполнение довольно простой работы вызывает такие сложности? Чем-то, что принесет и деньги и удовольствие.
Может потому, что они лично мне деньги приносят? Да и не сложно это, только лишний геморрой, которого бы не было без самодурства гугла.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
C>>А другого может и не быть. А ещё может Китай навредить — https://en.wikipedia.org/wiki/Great_Cannon Ops>Ну как не быть-то? Одних сотовых провайдеров куча.
Провайдер может быть и не сотовым. И страна может быть типа Саудовской Аравии или Китая.
C>>В общем, в современном мире использовать HTTP в Интернете — это халатность. Ops>Ничем не подкрепленная глупость.
Нет, это горький результат опыта.
Здравствуйте, Cyberax, Вы писали:
Pzz>>>С тех пор, как сети стали радиофицированными, отказ от адекватного шифрования является дырой в защите чуть менее, чем всегда. Ops>>В радио сетях оно УЖЕ есть, на канальном уровне. Зачем 2-й раз шифровать? Потому что так гуглу захотелось? C>Нету. В WPA2 при слабом пароле можно запустить offline-атаку и расшифровать трафик.
Хочу еще добавить, что wifi — это не единственный радиотранспорт. И в более других с безопасностью, я подозреваю, еще хуже.
Здравствуйте, Cyberax, Вы писали:
C>Провайдер может быть и не сотовым.
Но его можно сменить как минимум на сотового, а во многих местах еще и на другого проводного. И это все в том редчайшем случае, когда провайдер таки влезает в трафик, что практически не наблюдается уже давно.
C>И страна может быть типа Саудовской Аравии или Китая.
Мне не интересна та аудитория, как и ей мои проекты. Кому интересна — те сами включат поддержку нужного протокола, без навязывания.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
Ops>Ну может быть rev3... Но это больше половины ресурсов на одну TLS выкинуть. Только я бы для утюга вообще тиньку брал, ибо только они с маленьким числом ног встречаются, а там все сильно скромнее.
У тебя ведь утюг к сети по радио подключается, правда, а не по проводному ethernet'у. Я подозреваю, мощности Power Over Ethernet для утюга немного не хватит
А если у тебя утюг подключен к сети по радио, там уже есть довольно мощный процессор. Слабый процессор не потянет современных радиопротоколов.
O>>Ну это примерно как создать новую модель автомобиля, потому что в имеющемся экземпляре серийной модели ты подложил булыжник под педаль газа. C>Проблема в том, что существующий TCP ломается у заметного количества клиентов, если не делать таких уродских хаков.
Учитывая вводные (свой код клиента и сервера) задача определения и настройки PMTU должна тривиально решаться при помощи setsockopt(...TCP_MAXSEG...) где оно поддерживается (лялих) и чуть менее тривиально при помощи setsockopt(...TCP_NODELAY..) и ручной буферизации исходящих данных где set(TCP_MAXSEG) не работает (винда).
C>Если есть идеи как это исправить в рамках существующего TCP — добро пожаловать в Гугл на семизначную зарплату.
Боюсь гномиков разверну не под тем углом.
Как много веселых ребят, и все делают велосипед...
C>>>Проблема в том, что существующий TCP ломается у заметного количества клиентов, если не делать таких уродских хаков. O>>Учитывая вводные (свой код клиента и сервера) C>Откуда такая вводная? Клиент может быть совершенно любой.
Это вводные, равнозначные вводным QUIC'а.
C>Ну ладно, предположим, что мы колхозим в Chrome, а остальных отправляем в канал с обычным MTU в 1380.
Угу.
C>Вот Вася сидит в региональном отделении православного банка Рогатус&Копытус. Его локальный MTU — это 1500 байт (Ethernet), но его филиал подключён к Интернету через VPN и PPPoE, которые отъедают примерно 90 байт пакетов. C>Так что PMTU получается в 1410. Гугл начинает передавать ему данные, наращивает окно и в итоге передаёт пакет в 1411 байт. Этот пакет не проходит через финальный VPN и клиент VPN отправляет в сторону Гугла сообщение ICMP о том, что пакет слишком большой.
Ненене. Не нужно никаких ICMP. Они считать что ICMP проходит — то вообще ничего не нужно, PMTU discovery придуман давно, но он не работает когда ICMP блочится. Что является корнем проблемы с PMTU. Т.о. нужно определять PMTU без использования ICMP.
C>Но не тут-то было! Так как банк — большой и очень умный, то исходящий трафик фильтруется через middlebox, который считает ICMP изобретением дьявола и блокирует его. Тем более, что трафик ещё и на сервера в Калифорнии идёт. Нельзя такого допускать, никак нельзя.
Да!
C>И всё, пользователь видит застывшую полосу загрузки. Через некоторый таймаут Гугл поймёт, что переборщил с размером пакетов и уменьшит его. Но тайамаут — это тормоза.
Это однократный таймаут, потом все пакеты такому клиенту надо слать с определенным MTU, периодически в фоне проверяя нельзя ли его подрастить. Причем оптимальный MTU должен запоминать не только гугл, но и сам клиент.
Встречный вопрос: а как тогда решается данная проблема QUIC'ом? Ведь явно на тех же таймаутах. Потому что больше надежных путем нету. Потому все еще в упор не вижу преимуществ QUIC'а над тюнингом TCP.
C>Сразу начинают придумываться идеи типа: "А что если одновременно послать один большой пакет, пока мы в фоне посылаем маленькие?". Но от этого middlebox'ам плохеет так, что они вообще соединение разрывают.
О да, а от QUIC'а мидлбоксы будут расслабленно плевать в потолок
Как много веселых ребят, и все делают велосипед...
O>>Учитывая вводные (свой код клиента и сервера) задача определения и настройки PMTU должна тривиально решаться при помощи setsockopt(...TCP_MAXSEG...) где оно поддерживается (лялих) и чуть менее тривиально при помощи setsockopt(...TCP_NODELAY..) и ручной буферизации исходящих данных где set(TCP_MAXSEG) не работает (винда). N>"Ручная буферизация" подобного рода будет надёжно работать только если уже на уровне приложения на каждую порцию получать подтверждение. Иначе малейший затор создаст пакет большего размера, который уже не пройдёт. А это такое торможение по сравнению с нормальной скоростью TCP, что мы откатимся во времена диалапа.
Согласен, надо подумать. К сожалению в винде отсутствует какой либо контроль над размером пакета. Но насколько я помню (оч давно уже в сетях ковырялся, возможно в современных виндах неактуально), ограничением SO_SNDBUF его ограничить таки можно.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, m2l, Вы писали:
m2l>Здравствуйте, Cyberax, Вы писали:
m2l>Логики нет в твоих словах. К примеру cloud & sdn дают развитие vxvlan. Умные устройства дают возможности для "промышленных протоколов". Через 30 лет после TCP и UDP появились SCTP и DCCP. Насчет последнего не в курсе, а SCTP активно используется. Эволюция идёт, и если появится протокол кардинально лучший — то он вытеснит существующие. Другой вопросы, что ничего кардинально лучшего нет. А "развитие" ради "развития", ну ты сам понимаешь...
... и Geneve.
Но вы спорите о разных вещах. Тут проблема последней мили. Магистральные провайдеры и датацентры много чего используют, тот же IPv4 тунеллируется IPv6 а не наоборот уже давно. И прочее прочее.
Вопрос же про проблему последней мили последнего километра. Здесь же с зоопарком старой техники, работающей под полуметровым слоем пыли, все очень плохо.
C>>И всё, пользователь видит застывшую полосу загрузки. Через некоторый таймаут Гугл поймёт, что переборщил с размером пакетов и уменьшит его. Но тайамаут — это тормоза. O>Это однократный таймаут, потом все пакеты такому клиенту надо слать с определенным MTU, периодически в фоне проверяя нельзя ли его подрастить. Причем оптимальный MTU должен запоминать не только гугл, но и сам клиент.
Кстати, MTU нужно периодически пересчитывать, потому что у промежуточного провайдера может поменяться роутинг (упал линк, данные пошли по резервному маршруту), да и пользователь через QUIC может подключиться по другому (пришел с мобилкой домой, подключился к WiFi, QUIC сессия осталась прежней). Причем, MTU клиент->сервер может отличаться от MTU сервер->клиент.
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, Somescout, Вы писали:
S>>ШИ ТО. Ютуб второй после твитча случай, когда программистам можно пересадить руки макаки и это не ухудшит результат. Гугль гонится за миллисекундами скорости, игнорируя что один из их основных сайтов тормозное ****.
vsb>Почему тормозное? У меня очень быстро открывается и работает.
Посмотрел — сейчас да, вроде поправили. Но до этого несколько месяцев открытие страницы занимало порядка 7-8 секунд и сопровождалось несколькими relayout, что неслабо раздражало (а в частности выкидывало из полноэкранного режима, если врубал его до полной загрузки страницы).
O>>Это однократный таймаут, потом все пакеты такому клиенту надо слать с определенным MTU, периодически в фоне проверяя нельзя ли его подрастить. Причем оптимальный MTU должен запоминать не только гугл, но и сам клиент. M>Причем, MTU клиент->сервер может отличаться от MTU сервер->клиент.
Это само собой. Кстати тут можно дополнить, что скорее всего скорость клиент->сервер большого значения не имеет, и гораздо важней сервер->клиент. Тогда можно сделать так: если клиент не умеет в TCP_MAXSEG то для клиент->сервер ставим MTU=1380, которое fits for all. А на сервере юзаем TCP_MAXSEG или ваще делаем кастомный TCP стек, который на таймаутах подбирает оптимальный MTU для server->client. Гугл же может пропатчить KDE под FreeBSD TCP стек на своих серверах?
А если скорость клиент->сервер все же важна, и браузер под линуксом окажется быстрее чем под виндой, то микрософт быренько реализует TCP_MAXSEG в winsock'е.
Но миром правит hype-driven-development. На тюнингованном протоколе хайпа не вырастишь, то ли дело навелосипедить новый.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Pzz, Вы писали:
Pzz>Хочу еще добавить, что wifi — это не единственный радиотранспорт. И в более других с безопасностью, я подозреваю, еще хуже.
В более других — лучше. WiMAX тому пример. Ну и сотовые сети последних поколений. При использовании такого транспорта всё будет шифроваться минимум дважды.
Здравствуйте, andyp, Вы писали:
A>В более других — лучше. WiMAX тому пример. Ну и сотовые сети последних поколений. При использовании такого транспорта всё будет шифроваться минимум дважды.
А ещё есть ZigBee (и построенный на той же технологии Thread), где всё хуже.
Здравствуйте, Cyberax, Вы писали:
C>А ещё есть ZigBee (и построенный на той же технологии Thread), где всё хуже.
У ZigBee только крючки для шифрования на MAC уровне. PAN же. Защищенные сети мутят на проприетарных девайсах с уже зашитой внутрь криптой. В открытую защищенную сеть на ZigBee не получится
C>В QUIC периодически посылаются тестовые пакеты параллельно основному соединению. Для них замеряется время в пути и при удачности измерения — размер окна переключается на них.
В UDP нету понятия соединения. Пакеты посылаются просто параллельно, и нет никаких гарантий что они все ходят по такому же маршруту.
С такой т.з. можно запустить ответчик на UDP "параллельный" TCP соединению и подстраивать TCP_MAXSEG согласно результатом от UDP.
Этот протокол вполне можно пропихнуть как стандартный UDP-хелпер для PMTU discovery, все спасибо скажут. А не вот так.
O>>О да, а от QUIC'а мидлбоксы будут расслабленно плевать в потолок C>Да, так как они НИЧЕГО не смогут сделать без полноценной MITM-атаки. В QUIC нет никаких зацепок для middlebox'ов, кроме одного бита (который с трудом протащили в стандарт).
Хватит того что там есть номер UDP порта.
Надо было копать глубже — и туннелтроваться через ICMP.
Вот тогда бы все подофигели Но это невозможно без админских прав.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, andyp, Вы писали:
A>В более других — лучше. WiMAX тому пример. Ну и сотовые сети последних поколений. При использовании такого транспорта всё будет шифроваться минимум дважды.
А разве государство не ограничивает качество шифрования в сотовых сетях на уровне "сделали вид, что все зашифровано"?
Если мы все еще говорим об утюге, то там скорее будет Bluetooth или ZigBee какой-нибудь.
Здравствуйте, Pzz, Вы писали:
Pzz>А разве государство не ограничивает качество шифрования в сотовых сетях на уровне "сделали вид, что все зашифровано"?
Государству сейчас это просто не нужно. Проще стойку рядом с оборудованием провайдера поставить и снимать уже нешифрованный трафик, что собственно и делается.
Pzz>Если мы все еще говорим об утюге, то там скорее будет Bluetooth или ZigBee какой-нибудь.
ZigBee в теории предусматривает возможность шифрования на уровне MAC. На практике оказывается, что либо имеем дело с закрытой сетью, где все устройства выдаются провайдером (и тут шифрование вполне себе может присутствовать), либо с открытой сетью, где устройства могут быть любыми, но шифрования нет.
Здравствуйте, ononim, Вы писали:
C>>В QUIC периодически посылаются тестовые пакеты параллельно основному соединению. Для них замеряется время в пути и при удачности измерения — размер окна переключается на них. O>В UDP нету понятия соединения.
Оно есть в QUIC.
O>Пакеты посылаются просто параллельно, и нет никаких гарантий что они все ходят по такому же маршруту.
Более того, в QUIC напрямую поддерживается multipath — можно передавать данные параллельно через WiFi и LTE, например.
O>С такой т.з. можно запустить ответчик на UDP "параллельный" TCP соединению и подстраивать TCP_MAXSEG согласно результатом от UDP.
А может проще тогда свой протокол сделать?
O>Этот протокол вполне можно пропихнуть как стандартный UDP-хелпер для PMTU discovery, все спасибо скажут. А не вот так.
Ещё потом добавить multipath, шифрование, назвать всё это QUIC — и будет просто супер!
C>>Да, так как они НИЧЕГО не смогут сделать без полноценной MITM-атаки. В QUIC нет никаких зацепок для middlebox'ов, кроме одного бита (который с трудом протащили в стандарт). O>Хватит того что там есть номер UDP порта.
То есть?
Здравствуйте, Ops, Вы писали:
Ops>Может быть. Решается голосованием ногами — этот провайдер может и в другом нагадить, нафиг он нужен?
это решается https, иначе ты можешь просто не знать, что это товой оператор так сделал, скажем на мегафоне тебе могут огромный поупап баннер на сайте показать, который на самом деле не владелец сайта туда поставил, а мегафон
ну и не скажешь же ты своим пользователям менять симкарты?
Здравствуйте, chaotic-kotik, Вы писали:
CK>Вот так прогресс делает некоторые специализации менее нужными. Вот раньше как было, ходил HTTP трафик по TCP, люди писали TCP сервера поверх стека ОС, преодолевали проблемы оного стека ОС (проблема 10К), использовали epoll и windows completion ports. Но QUIC работает поверх UDP, большая часть протокола в userspace, сейчас у UDP нет таких проблем как у TCP,
И каким же образом этот вывод получается из сказанного ранее?
Переход на UDP магически отменяет необходимость делать ожидание на сокетах?
CK> ОС умеет через recvmsg обрабатывать миллионы UDP пакетов в секунду,
А для TCP, значит, не умела? О какой ОС речь-то?
CK> поэтому нет проблемы 10К.
Здравствуйте, chaotic-kotik, Вы писали:
N>>И каким же образом этот вывод получается из сказанного ранее? N>>Переход на UDP магически отменяет необходимость делать ожидание на сокетах? CK>я имел ввиду recvmmsg/sendmmsg + SO_REUSEPORT,
Ага, тут вторая 'm' принципиальна.
CK> на них можно построить свой QUIC стек на уровне приложения, который не будет нуждаться в ОС для мультеплексирования соединений и context switches и будет многопоточным
Для сервера, да, в тему. Только для клиента это не очень полезно. Использовать один и тот же сокет для нескольких соединений с одним сервером — очевидный конфликт с правилами идентификации соединений, не сработает. Использовать его с разными серверами — значит, что слой IO дальше будет разбрасывать эти данные между разными сущностями (как вкладки в браузере) — тоже странное решение, мягко говоря.
O>>Ну как же. Ведь тцп стек операционки писали криворукие старперы, а модные девелоперы быстро эти пакетики разрулят на питончике, в 100500 раз быстрее. А если будет тормозить на питончике — напишут на го, вот тогда уж точно все залетает. C>https://www.dpdk.org/ C>Ась?
Набор кастомных драйверов сетевых адаптеров со своими либами, заточенные под конкретное железо, начатая по инициативе интеля vs наколенная реализация транспортного протокола поверх UDP методом "а давайте запилим, и пофиг че получится по бенчмаркам, у нас бабок много"?
Очень популистское сравнение. Но на стадных девелоперов подействует.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Cyberax, Вы писали:
C>>Конкретно QUIC делается с простой целью — чтобы он не сосал, как TCP через middlebox'ы.
CC>Что то мне кажется что в реале он как раз будет сосать что тот пылесос. CC>Потому что шторм UDP запросов говномиддлбоксы переваривают плохо.
Здравствуйте, ononim, Вы писали:
O>Набор кастомных драйверов сетевых адаптеров со своими либами, заточенные под конкретное железо, начатая по инициативе интеля vs наколенная реализация транспортного протокола поверх UDP методом "а давайте запилим, и пофиг че получится по бенчмаркам, у нас бабок много"?
Только вот по бенчмаркам получается лучше TCP. А так да, ерунда.
Здравствуйте, Cyberax, Вы писали:
C>Но не тут-то было! Так как банк — большой и очень умный, то исходящий трафик фильтруется через middlebox, который считает ICMP изобретением дьявола и блокирует его. Тем более, что трафик ещё и на сервера в Калифорнии идёт. Нельзя такого допускать, никак нельзя. C>Сразу начинают придумываться идеи типа: "А что если одновременно послать один большой пакет, пока мы в фоне посылаем маленькие?". Но от этого middlebox'ам плохеет так, что они вообще соединение разрывают. C>>>Если есть идеи как это исправить в рамках существующего TCP — добро пожаловать в Гугл на семизначную зарплату.
У меня есть идея, но не техническая, а скорее организационная. Организовать работу так, чтобы пока middlebox'ы не настроят нормально — вообще ничего не работало бы. Благо, у гугла почти что монополия на браузеры. Чтобы с одной стороны безопасников с их middlebox'ами пинали топменеджеры: "какого хрена у меня айпад не показывает видео?", а с другой — какой-нибудь ITU их пинал в духе "неправильно настроенное сетевое оборудование — это уголовное преступление, это раньше мы в сети только котиков смотрели, а теперь от интернета зависит всё. Давайте-давайте, на работу, правила чистить! Вилкой — раз-раз-раз!". Чтобы эти любители всё позапрещать забегали, как при пожаре.
Здравствуйте, ononim, Вы писали:
C>>https://www.dpdk.org/ C>>Ась? O>Набор кастомных драйверов сетевых адаптеров со своими либами, заточенные под конкретное железо, начатая по инициативе интеля vs наколенная реализация транспортного протокола поверх UDP методом "а давайте запилим, и пофиг че получится по бенчмаркам, у нас бабок много"? O>Очень популистское сравнение. Но на стадных девелоперов подействует.
Это очень хорошая вещь. По сути, она даёт приложению монопольный доступ к сетевой карте. Можете рассматривать DPDK как некий новый стандарт, вроде berkley sockets. Ничто не мешает реализовать его поддержку в уже существующих драйверах.
нет, -17 не будет финализироваться, много багрепортов выползло. До июля тестируем интероп, в июле смотрим. Плюс у меня есть планы всерьёз набросить на вентилятор, так что, если получится, то и в июле не будет финала. Но шансы 50/50.
Здравствуйте, Cyberax, Вы писали:
C>OSI сдохла уже давно.
Хммм… А мужики-то не знают! Как же она сдохла, неужели фейсбуки с контактами прямо в Ethernet-кадры данные оборачивают?
P.S. Тот факт что 99% девелоперов разрабатывают application-level протоколы, вовсе не значит, что остальных 6 уровней уже более нет в природе.
CK>я имел ввиду recvmmsg/sendmmsg + SO_REUSEPORT, на них можно построить свой QUIC стек на уровне приложения, который не будет нуждаться в ОС для мультеплексирования соединений и context switches и будет многопоточным
А что даст SO_REUSEPORT для UDP на уровне приложения?
Здравствуйте, ononim, Вы писали:
O>Набор кастомных драйверов сетевых адаптеров со своими либами, заточенные под конкретное железо, начатая по инициативе интеля vs наколенная реализация транспортного протокола поверх UDP методом "а давайте запилим, и пофиг че получится по бенчмаркам, у нас бабок много"? O>Очень популистское сравнение. Но на стадных девелоперов подействует.
Знаю одну контору, запилили на коленке кастомные дрова с прямым доступом к буферам сетевухи (чтоб без копирования памяти туда-сюда) — получился неплохой пулемёт для тестирования стрессоустойчивости сети и инфраструктуры. К сожалению, не под Windows (и не под Linux, гы). Если кто-то из мажорных игроков, типа Intel, сможет протащить нечто подобное в стандартизированную форму безотносительно ОС (и при этом без дырок в безопасности, как было в raw sockets) — это будет очень интересно.
Здравствуйте, Mr.Delphist, Вы писали:
MD>Здравствуйте, Sinclair, Вы писали: S>>Нет. Но работа протокола IP зависит от протокола ICMP MD>Пардон, WAT? Работа протокола IP не зависит от ICMP. ICMP — не более чем диагностика, её наличие или отсутствие никак не влияет на работоспособность узлов. Более того, многие публичные сервисы дропают ICMP, чтобы не платить за этот трафик (если на отправителя нет пирингового соглашения) и не забивать своё оборудование лишней нагрузкой (гуглим "ICMP атака").
Мы сейчас о хитрожопых реализациях или о стандарте?
ICMP, uses the basic support of IP as if it were a higher level protocol, however, ICMP is actually an integral part of IP, and must be implemented by every IP module.
MD>Значит, самое время их почитать
Лучше всего про модель OSI читать в учебниках по менеджменту — в разделе "отрицательные примеры влияния комитетного подхода к решению инженерных задач".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, netch80, Вы писали:
N>Он и от BGP зависит. И от DHCP, который поверх UDP. И от ещё массы вещей.
Нет, не зависит. Роутить IP можно безо всякого DHCP, и без всякого BGP. То, что на практике DHCP часто используется для авто-конфигурации IP — это просто особенность нынешнего интернета. Как и использование BGP.
На всякий случай напомню, что технически ничто не мешает нам реализовать IP поверх голубиной почты. N>Это не нарушает главного — что уровневый принцип, близкий к тому, что описан в OSI модели и ISO стеке, актуален и его упоминание и обучение необходимо для того, чтобы понимать структуру сети.
Согласен. В качестве красивой картинки этот принцип стоит изучать, отдав ему 5-10 минут на лекции. А затем переходить к тому, как дизайнятся реальные протоколы, решающие реальные задачи (а не задачу "оправдать работу семи подкомитетов комитета по разработке стандарта").
Точно так же, как мы говорим о желательности отсутствия кольцевых зависимостей в модулях программы, а затем сразу переходим к тому, как скомпилировать DLL которые необходимым образом зависят друг от друга.
Потому что класс String невозможно описать, не используя класс Type (ведь как и у всех, у него есть метод GetType()), а класс Type невозможно описать, не используя класс String (ведь у него есть String Name).
И прагматичные цели часто заставят нас складывать эти типы в разные DLL.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
нет, -17 не будет финализироваться, много багрепортов выползло. До июля тестируем интероп, в июле смотрим. Плюс у меня есть планы всерьёз набросить на вентилятор, так что, если получится, то и в июле не будет финала. Но шансы 50/50.
Здравствуйте, Mr.Delphist, Вы писали:
MD>Здравствуйте, Sinclair, Вы писали: S>>Нет. Но работа протокола IP зависит от протокола ICMP MD>Пардон, WAT? Работа протокола IP не зависит от ICMP.
Для IPv6 строго зависит, так как фрагментации на уровне IP больше нет и ICMP Packet Too Big становится критически важным.
Здравствуйте, Mr.Delphist, Вы писали:
C>>OSI сдохла уже давно. MD>Хммм… А мужики-то не знают!
Да знают уже давно. Потому и пилят всякие DoH.
MD>Как же она сдохла, неужели фейсбуки с контактами прямо в Ethernet-кадры данные оборачивают?
Они нынче делают эмуляцию TCP/IP поверх HTTPS.
Здравствуйте, Mr.Delphist, Вы писали:
MD>Здравствуйте, ononim, Вы писали:
O>>Набор кастомных драйверов сетевых адаптеров со своими либами, заточенные под конкретное железо, начатая по инициативе интеля vs наколенная реализация транспортного протокола поверх UDP методом "а давайте запилим, и пофиг че получится по бенчмаркам, у нас бабок много"? O>>Очень популистское сравнение. Но на стадных девелоперов подействует.
MD>Знаю одну контору, запилили на коленке кастомные дрова с прямым доступом к буферам сетевухи (чтоб без копирования памяти туда-сюда) — получился неплохой пулемёт для тестирования стрессоустойчивости сети и инфраструктуры. К сожалению, не под Windows (и не под Linux, гы). Если кто-то из мажорных игроков, типа Intel, сможет протащить нечто подобное в стандартизированную форму безотносительно ОС (и при этом без дырок в безопасности, как было в raw sockets) — это будет очень интересно.
Эка невидаль. Я 10 лет назад такое писал используя драйвер winpcap. Пакетики строились по RFC. Положить сеть можно было за пару минут.
Здравствуйте, Sharov, Вы писали:
C>>Они нынче делают эмуляцию TCP/IP поверх HTTPS. S>Зачем?
Потому, что через нынешний Интернет ничего другое не пролазит.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Sharov, Вы писали:
C>>>Они нынче делают эмуляцию TCP/IP поверх HTTPS. S>>Зачем? C>Потому, что через нынешний Интернет ничего другое не пролазит.
Здравствуйте, Mr.Delphist, Вы писали:
C>>OSI сдохла уже давно. MD>Хммм… А мужики-то не знают! Как же она сдохла, неужели фейсбуки с контактами прямо в Ethernet-кадры данные оборачивают?
MD>P.S. Тот факт что 99% девелоперов разрабатывают application-level протоколы, вовсе не значит, что остальных 6 уровней уже более нет в природе.
Распишешь эти 7 уровней? Вот у меня компьютер к роутеру подключен Ethernet-проводком. Отправляю я это сообщение POST-запросом на https://rsdn.org/. Давай по уровням выписывай 7 задействованных протоколов.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Sharov, Вы писали:
C>>>Потому, что через нынешний Интернет ничего другое не пролазит. S>>А зачем фб что-то другое кроме http(s)? C>Например, для голосового и видеочата. Или для игр.
А на фига, т.е. у нас дважды кадр ip\tcp — сначала для http пакета, затем для его содрежимого. Так?
Здравствуйте, netch80, Вы писали:
N>Голос и видео в реальном виде требуют синхронный тип трафика, при котором транспортные проблемы скорее приводят к потерям пакетов, чем к их задержкам. Провалы звука и изображения (в разумных пределах) восстанавливаются и легче воспринимаются, чем "плавающий" звук. N>Аналогичные проблемы характерны для многих других видов взаимодействия, включая игры — если на тебя едет танк, лучше, если он "прыгнет", но вовремя (такой же эффект, как если ты сам отвернулся на пару секунд), чем если ты через полминуты получишь подробную последовательность его шагов, когда он тебя уже расстрелял.
N>TCP, как и всё, что бегает поверх него, обеспечивает только наливной (bulk) трафик, с защитой от потерь, но ценой задержек и переповторов. Условная гарантия доставки обеспечивается отсутствием гарантии реалтаймовости. Пропустить переповтор устаревших данных невозможно, протокол на это не рассчитан принципиально.
N>Таким образом, TCP и всё, что поверх него (HTTP, HTTPS) тупо непригоден для реализации синхронных взаимодействий. Для них обычно используются свои протоколы поверх UDP, и не дай бог какой-то дурак затуннелирует это поверх TCP (к сожалению, всякие openvpn такое умеют, и есть имбецильные любители настраивать такое).
Так выше было написано, что фб для игр и звука гоняте все поверх http, который поверх tcp\ip. И в чем тогда смысл, эмуляция реалтаймовости?
Здравствуйте, vsb, Вы писали:
vsb>Распишешь эти 7 уровней? Вот у меня компьютер к роутеру подключен Ethernet-проводком. Отправляю я это сообщение POST-запросом на https://rsdn.org/. Давай по уровням выписывай 7 задействованных протоколов.
1. Физический уровень: медь, оптика или wireless
2. Канальный уровень: Ethernet
3. Сетевой уровень: IP (четвёртый или шестой)
4. Транспортный уровень: TCP
5. Сеансовый уровень: SSL/TLS (для случая с http:// префиксом этот уровень не требуется)
6. Уровень представления: plaintext или gzip или ещё какой набор правил по кодированию контента
7. Прикладной уровень: HTTP
Милостивые господа, впереди новогодние праздники. Потратьте их с пользой, почитайте проф-литературу, если в обычные дни вам некогда.
Здравствуйте, Sharov, Вы писали:
N>>Таким образом, TCP и всё, что поверх него (HTTP, HTTPS) тупо непригоден для реализации синхронных взаимодействий. Для них обычно используются свои протоколы поверх UDP, и не дай бог какой-то дурак затуннелирует это поверх TCP (к сожалению, всякие openvpn такое умеют, и есть имбецильные любители настраивать такое).
S>Так выше было написано, что фб для игр и звука гоняте все поверх http, который поверх tcp\ip.
По-моему, там написано строго противоположное:
=== cut === S>>>А зачем фб что-то другое кроме http(s)? C>>Например, для голосового и видеочата. Или для игр.
=== end cut ===
То есть им для этого _не_ нужен (не подходит) HTTP(S).
S> И в чем тогда смысл, эмуляция реалтаймовости?
Здравствуйте, Sharov, Вы писали:
S>>>А зачем фб что-то другое кроме http(s)? C>>Например, для голосового и видеочата. Или для игр. S>А на фига, т.е. у нас дважды кадр ip\tcp — сначала для http пакета, затем для его содрежимого. Так?
Ага, или ещё хуже. А нафига — так ничего другого не работает.
C>Для 0-RTT нужно иметь уже установленную ассоциацию. Клиент в первом пакете посылает тогда использует сохранённую cookie от сервера (которая содержит зашифрованное сервером состояние серверного соединения), посылая её с параметрами для установки соединения.
Это ты сейчас TLS Session tickets описал. Впрочем они не 0-RTT, и полагаю тому есть криптографические причины. Как и тому что TCP не поддерживает SO_CONNDATA — SYN атаки с ним стали бы чрезвычайно продуктивны Но гугл хочет сам походить по граблям.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
O>Это ты сейчас TLS Session tickets описал.
Не совсем. В TLS 1.2 нельзя посылать данные прямо с первого пакета.
Но что гораздо хуже, в TLS 1.2 не делается новое Diffie-Helman рукопожатие при использовании ticket'ов. Это означает, что forward secrecy нарушена. По-моему, в 1.2 вообще PFS несовместима с ticket'ами.
В TLS 1.3 это всё исправили.
O>Впрочем они не 0-RTT, и полагаю тому есть криптографические причины. Как и тому что TCP не поддерживает SO_CONNDATA — SYN атаки с ним стали бы чрезвычайно продуктивны Но гугл хочет сам походить по граблям.
SO_CONNDATA не поддерживается для обычных данных TCP в Windows.
Здравствуйте, vsb, Вы писали:
vsb>Почему всё? Предлагаешь все протоколы писать поверх HTTP?
Ты не поверишь сколько есть клоунов, для которых http является единственным из существующих.
И это не вчера началось. Еще лет десять назад было.
Здравствуйте, Cyberax, Вы писали:
C>А админов вообще не спрашивали. Если ради 1% улучшения скорости они должны будут стоять на ушах — они будут стоять на ушах. Колхозный фронтенд, да.
Подошол я тут к тимлиду
— Надо нам внедрить блокчейн
Тот дурак засомневался, говорит
— А нам зачем?
Никто тебе в бизнесе не будет менять работающую технологию пока конкретно не прижмёт. Ну или если у бизнеса есть бюджет на эксперименты.
Здравствуйте, Pzz, Вы писали:
Pzz>А разве государство не ограничивает качество шифрования в сотовых сетях на уровне "сделали вид, что все зашифровано"?
Зачем это ему? Государству нужен доступ, но в каком именно месте цепочки между абонентами, ему пофиг. Наоборот, ему выгоднее когда опсосы сами его предоставят, чем возиться с радиоперехватом. Так что шифрование именно радиоканалов ему нет смысла ограничивать.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Sheridan, Вы писали:
S>Никто тебе в бизнесе не будет менять работающую технологию пока конкретно не прижмёт. Ну или если у бизнеса есть бюджет на эксперименты.
Слово такое есть — конкуренция.
Здравствуйте, Cyberax, Вы писали:
S>>Никто тебе в бизнесе не будет менять работающую технологию пока конкретно не прижмёт. Ну или если у бизнеса есть бюджет на эксперименты. C>Слово такое есть — конкуренция.
