Здравствуйте, 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 — добро пожаловать в Гугл на семизначную зарплату.
Боюсь гномиков разверну не под тем углом.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, 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, Вы писали:
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>Боюсь гномиков разверну не под тем углом.
Они там уже не спрашивают их.
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 его ограничить таки можно.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, 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 и только потом потихоньку начнет получать распространение.
Здравствуйте, m2l, Вы писали:
m2l>Здравствуйте, Cyberax, Вы писали:
m2l>Логики нет в твоих словах. К примеру cloud & sdn дают развитие vxvlan. Умные устройства дают возможности для "промышленных протоколов". Через 30 лет после TCP и UDP появились SCTP и DCCP. Насчет последнего не в курсе, а SCTP активно используется. Эволюция идёт, и если появится протокол кардинально лучший — то он вытеснит существующие. Другой вопросы, что ничего кардинально лучшего нет. А "развитие" ради "развития", ну ты сам понимаешь...
... и Geneve.
Но вы спорите о разных вещах. Тут проблема последней мили. Магистральные провайдеры и датацентры много чего используют, тот же IPv4 тунеллируется IPv6 а не наоборот уже давно. И прочее прочее.
Вопрос же про проблему последней мили последнего километра. Здесь же с зоопарком старой техники, работающей под полуметровым слоем пыли, все очень плохо.
Здравствуйте, Vetal_ca, Вы писали:
V_>... и Geneve. V_>Но вы спорите о разных вещах. Тут проблема последней мили. Магистральные провайдеры и датацентры много чего используют, тот же IPv4 тунеллируется IPv6 а не наоборот уже давно. И прочее прочее.
Тут в другом фишка. Что гугл у себя на серверах и в своём браузере пилит свой же протокол — его право. Хотят оформить его как стандарт — почему бы и нет. Меня напрягает только маркетинг всего этого и попытки навязать это поделие туда где ему нет места. Чрезмерный маркетинг и глупости о "закостенении".
IPv6 лично у меня вообще вызывает рукалицо. Не понимаю как на базе существовавшего тогда стека можно было родить этот бред. И не внедряется он во многом из-за собственной корявости.
V_>Вопрос же про проблему последней мили последнего километра. Здесь же с зоопарком старой техники, работающей под полуметровым слоем пыли, все очень плохо.
Но работает. А не как гугл, SPDY --> HTTP/2 --> QUIC по новому стандарту в пятилетку.
Я действительно не понимаю, почему отсутствие необходимости раз в год менять железо это плохо. И зачем пытаться искусственно придумывать протоколы которые будут мешать "закостенению".
Иначе какая причина у других браузеров тормозить кроме плохой реализации.
