Комментарии 136
Ещё один недостаток QUIC — затрудненный поиск неисправностей. Протокол шифрует не только данные, но и заголовок пакета, в котором они передаются. Это мешает системным администраторам оценивать работу сети и быстро устранять неполадки.
Какая же классная фича, которая усложнит жизнь анализаторам и блокировщикам трафика. И как все-таки красиво цензуру завуалировали — «быстро устранять неполадки»
С одной стороны, как пользователь, я целиком "за" шифрование и ускорение работы. С другой, как разработчик и админ, я не очень люблю бинарные протоколы и шифрованные коммуникации — текстовые и не шифрованные намного проще отлаживать, а заниматься такой отладкой всё ещё приходится намного чаще, чем хотелось бы.
При этом реальное увеличение эффективности от замены текстовых протоколов на бинарные — не настолько значительно для абсолютного большинства проектов, как кажется. Но вот гугл, который любит продвигать бинарные протоколы — это не "большинство проектов", на масштабах гугла разница действительно есть — только почему все остальные должны страдать из-за неудобных бинарных протоколов, которые лично им не так уж и полезны?
Прошу прощения, я правильно понимаю, вы не любите шифрованные коммуникации, потому что не можете их расшифровать и, эм, отлаживать их?
Я могу их расшифровать. Просто для этого требуется сделать кучу дополнительных телодвижений, что создаёт неудобства и потерю времени (например: Анализ SSL/TLS трафика в Wireshark). В принципе всё это решаемые проблемы, нужно просто создать более удобные инструменты для отладки таких протоколов, но на данный момент мы имеем то, что имеем.
А разве нельзя на уровне стандарта протокола внедрить что-то вроде «debug-mode», который бы включался и на клиенте и на сервере? И овцы и волки довольны.
Нельзя. Во-первых, любые "режимы", изменяющие логику работы протокола могут приводить к тому, что проблема наблюдается только в одном режиме, но не в другом (напр. тупо потому, что в debug mode передаётся больше данных, и пакеты из-за этого иначе фрагментируются). Во-вторых, когда "внезапно" возникает необходимость что-то проверить — обычно это связано с текущим трафиком, и не всегда есть возможность где-то включить debug mode и повторить этот трафик.
А ещё проблема может быть на внешнем сервисе, который не позволит включить Debug Mode (если же будет API для включения, им будут пользоваться в MitM-атаках).
Отладка протокола занимает ничтожное время по сравнению с общим объемом эксплуатации, и есть множество готовых инструментов для разбора бинарных пакетов — тот же Wireshark. А если сделать режим отладки с логированием расшифровки пакетов и состояний, то проблем с отладкой в полевых условиях совсем не возникает. Вам часто приходится отлаживать канальные протоколы — UART, USB или даже UDP? Потому что там принцип простой, отправил и забыл, ломаться нечему. А в TCP или Bluetooth все сложно by design, всякие состояния, условия, режимы и контексты. И дело вовсе не в формате пакета.
Есть полу-бинарные варианты кодирования, которые можно читать глазами и при этом они не особо избыточны. Это кодирование чисел в BCD и использование буквенных HEX-кодов как маркеры, сериализация в Bencode, итд… Только почему-то они не особо популярны.
Есть полу-бинарные варианты кодирования, которые можно читать глазами и при этом они не особо избыточны. Это кодирование чисел в BCD и использование буквенных HEX-кодов как маркеры, сериализация в Bencode, итд… Только почему-то они не особо популярны.
Канальные — редко. Хотя и случаются иногда ситуации (напр. когда OpenVPN в виртуалке работал как-то частично, что-то бегало нормально, а какие-то пакеты нет — вроде дело было в net.ipv4.conf.default.rp_filter, но уже точно не помню… ещё была ситуация, когда ADSL через pppd под одним дистром линуха работал, а под другим нет — вроде вылечилось через net.ipv4.tcp_ecn, но это совсем давно было, могу путать).
А вот что приходится отлаживать намного чаще, так это какой-нить RPC, завёрнутый в несколько слоёв других протоколов (https+websocket, например, или http/2). Учитывая, что пакеты этого RPC генерятся библиотеками на разных языках, добавить детальный отладочный вывод в читаемом виде формируемых пакетов не так просто. И тут на помощь обычно приходит тупой tcpdump или wireshark, который позволяет глазками достаточно оперативно обнаружить проблему — при условии, что протокол текстовый и легко читается.
Я могу более-менее понять претензию к шифрованным протоколам, но что не так с бинарными? Плагины к wireshark написать — дело пары часов (если описать только структуры и имена полей), а скорость формирования/парсинга таких пакетов возрастает на порядки.
Или возможность посмотреть заголовки в дампе через блокнот стоят того, чтобы терять столько вычислительных мощностей?
Или возможность посмотреть заголовки в дампе через блокнот стоят того, чтобы терять столько вычислительных мощностей?
Писать, устанавливать и сопровождать плагины к wireshark — не то, чем я мечтаю заниматься.
Что до скорости — в реальных приложениях скорость (де)сериализации пакетов редко является узким местом, и замена текстовых протоколов на бинарные почти никогда не даёт заметного выигрыша, который бы хоть как-то оправдал неудобства. Конечно, бывают исключения, либо когда речь о масштабах а-ля гугл, либо когда у нас очень высокопроизводительный сервис а-ля Redis/memcached, который моментально возвращает результаты из памяти (и в котором сериализация данных действительно оказывается узким местом), либо когда сервис возвращает сотни тысяч элементов в одном ответе — но всё это очень редкие частные случаи, и особенности отдельного сервиса почти никогда не оправдывают выбор бинарного протокола для всей системы. Помимо прочего, очень часто протоколы уровня приложения (вроде RPC) заворачивают в HTTP, парсинг которого достаточно сложный, занимает немало времени, и этим нивелирует любой выигрыш от передачи бинарного протокола в теле HTTP запроса/ответа.
Если посмотреть бенчмарки JSON vs BSON vs Msgpack, то разница (по скорости) между ними не настолько принципиальна, и в большей степени определяется языком/библиотеками, нежели форматом данных.
Писать, устанавливать и сопровождать плагины к wireshark — не то, чем я мечтаю заниматься.Вот вам WSGD — ничего писать не нужно, только два файла со структурами и описаниями протокола, и в итоге все красиво распарсится и будет фильтроваться фильтрами wireshark.
Что до скорости — в реальных приложениях скорость (де)сериализации пакетов редко является узким местом, и замена текстовых протоколов на бинарные почти никогда не даёт заметного выигрыша, который бы хоть как-то оправдал неудобства.Вот тут можно пронаблюдать эффективность пока нераспространённой, но уже существующей бинарной версии HTTP.
Помимо прочего, очень часто протоколы уровня приложения (вроде RPC) заворачивают в HTTP, парсинг которого достаточно сложный, занимает немало времени, и этим нивелирует любой выигрыш от передачи бинарного протокола в теле HTTP запроса/ответа.А еще очень часто на компьютерах в игры играют, это нивелирует всю пользу офисных пакетов, давайте прекратим их разработку и распространение.
Конечно, бывают исключения, либо когда речь о масштабах а-ля гуглЯ таки могу ошибаться, но любой онлайн-контент, будь он фильмом, игрой, сайтом с кучей картинок и много чем еще — уже повод задуматься о скорости инкапсуляции данных на разных уровнях.
А пусть даже и не повод — все равно остаются сервера разного масштаба которым нужно все это пережевывать. Вы можете снова указать что это не основная их нагрузка, но если двигаться в этом направлении — она вполне может и стать основной, не давая при этом никаких преимуществ кроме упрощения отладки.
И чем, если не секрет, вы отлаживаете сетевые приложения, если текстовый формат удобнее разбиения на структуры wireshark'ом?
Помимо повода задуматься о скорости есть понятие преждевременной оптимизации. Я говорю о том, что бинарные протоколы, не всегда, но во многих случаях, являются преждевременной оптимизацией — они создают сложности прямо сейчас, не принося при этом никакой заметной пользы.
И чем, если не секрет, вы отлаживаете сетевые приложения, если текстовый формат удобнее разбиения на структуры wireshark'ом?
Вы не поверите, но тот же JSON RPC 2.0 я нередко отлаживаю конструкцией echo | nc или http | jq. Очень просто, быстро и удобно — намного удобнее, чем тыкать мышкой в wireshark.
Помимо повода задуматься о скорости есть понятие преждевременной оптимизации.Вы путаете оптимизацию с архитектурой. Оптимизацию можно провести в любой момент, а вот изменить архитектуру — нет.
Вы не поверите, но тот же JSON RPC 2.0 я нередко отлаживаю конструкцией echo | nc или http | jq. Очень просто, быстро и удобно — намного удобнее, чем тыкать мышкой в wireshark.Вы не поверите, но речь идет о протоколе транспортного уровня, и сравнение с протоколом прикладного уровня как минимум неуместно.
С одной стороны цензура, а с другой — блокировка рекламы и слежки на сетевом уровне.
Я, если честно, как узнал об этом протоколе, сразу подумал о том, что они просто хотят защититься от блокировки своей рекламы. Ведь это их бизнес.
Я, если честно, как узнал об этом протоколе, сразу подумал о том, что они просто хотят защититься от блокировки своей рекламы. Ведь это их бизнес.
НЛО прилетело и опубликовало эту надпись здесь
Quic уже несколько лет прекрасно работает в Chrome.
Иногда мне кажется, что это одна из причин, почему YouTube работает так хорошо на плохих соединениях.
НЛО прилетело и опубликовало эту надпись здесь
IPv6? Когда-нибудь это случится.
У МТС — уже.
См например omsk.mts.ru/personal/mobilnaya-svyaz/uslugi/mobilnaya-svyaz/dostup-k-ipv6 (заменить omsk на свой город), причем даже
С другой стороны — в 4pda.ru/forum/index.php?showtopic=850236 до сих пор фидбэк от пользователей собирают и фиксят баги.
См например omsk.mts.ru/personal/mobilnaya-svyaz/uslugi/mobilnaya-svyaz/dostup-k-ipv6 (заменить omsk на свой город), причем даже
С 9.08.2018 включается в первоначальный пакет
С другой стороны — в 4pda.ru/forum/index.php?showtopic=850236 до сих пор фидбэк от пользователей собирают и фиксят баги.
МТС режет well known ports «в целях безопасности». Для юзера то пойдёт, но по сути кастрирован для полноценного использования.
Смотря как интерпретировать этот вопрос.
Билайн (мобильный оператор) на домашнем интернете даёт публичные IP адреса, динамические, хотя за отдельную плату можно и зафиксировать адрес.
Хотя всё равно для домашнего барахла приходится поднимать NAT.
Билайн (мобильный оператор) на домашнем интернете даёт публичные IP адреса, динамические, хотя за отдельную плату можно и зафиксировать адрес.
Хотя всё равно для домашнего барахла приходится поднимать NAT.
Не могу сейчас проверить, но кажется хорошо работает через NAT. Ну и почему бы ему не работать, DNS или NTP же работают, например.
Он работает через NAT, это какие-то приколы авторов оригинальной статьи. Кроме того, Google обещает сделать Multipath (обещал в этом году сделать, но, похоже, будет в следующем), и можно будет использовать несколько каналов в рамках одного соединения, объединяя скорость Wi-Fi и LTE, например.
Спасибо что рассказали нам свое мнение.
Без каких-либо аргументов оно особенно ценно.
В подтверждение своему диванному скептицизму зайдите в настройки хрома и выключите там поддержку квик, а то по-умолчанию у вас google, youtube и gmail работают через него (что к слову неслабо их ускоряет).
И да, это не стандарт, а протокол. Про стандартизацию в RFC в статье было.
Без каких-либо аргументов оно особенно ценно.
В подтверждение своему диванному скептицизму зайдите в настройки хрома и выключите там поддержку квик, а то по-умолчанию у вас google, youtube и gmail работают через него (что к слову неслабо их ускоряет).
И да, это не стандарт, а протокол. Про стандартизацию в RFC в статье было.
НЛО прилетело и опубликовало эту надпись здесь
Мне кажется, что вокруг quic стоит какой-то нездоровый хайп. Думаю, что это очередной мертворожденный стандарт от гугла.
А каким делает сообщество вот этот комментарий?
Автор просто припустил в лужу не имея ни знаний ни опыта в вопросе. Его личное мнение ничем не подкрепленное. Подобный коментарии может генерировать бот (даже без AI). Было бы классное если бы ХАБР не пропускал коментарии чье содержимое не содержит отпечатков умственной активности.
Ну как бы Spdy стал вполне себе стандартом HTTP/2, поэтому мне не ясен ваш скепсис в данном случае
НЛО прилетело и опубликовало эту надпись здесь
Он не умер, а был заменен на HTTP/2, причем сама гугл это сделала еще несколько лет назад объявив что SPDY будет зменен на HTTP/2 и не будет поддерживаться.
Насколько я помню оригинальный драфт HTTP/2 был основан именно на спецификации SPDY, а не разработан с нуля. Что как раз и является по моему мнению прямым переходом одного решения в новый стандарт.
Можно сколько угодно хейтить гугл и не "хотеть" что бы она диктовала, но тоже самое решение про использвание SPDY как основы для HTTP/2 было в том числе и другими крупными игроками поддержано, вроде Facebook
Будущее может и туманно в том смысле, что решения о стандартизации нет, но решение явно нужно и это видно по тому как мобильный рынок в поиске решений с медленным TCP в мобильных сетях
Ну и название придумали. Как его произносить? То ли дело «ти си пи», «ю Ди пи». А здесь? «Кью ю ай си»? Или аналог на quick?
Не очень понятно, почему этот QUIC сравнивают с TCP, а не с его аналогом и конкурентом SCTP (RFC 3286 и RFC 4960)? Вроде как возможности примерно похожие, да и предполагаемые геморрои от внедрения тоже. Единственно, что SCTP в ядра ОС уже встроили, но толку то?
а что за геморрои с SCTP?
успешно используется во многих телекомах, про особые проблемы не слышал
успешно используется во многих телекомах, про особые проблемы не слышал
А в каком месте QUIС аналог и/или конкурент SCTP? Ассоциаций нет, принцип другой. Ну и самое главное — QUIC работает поверх UDP, в то время как SCTP сам по себе.
И да, что там за геморрои-то?
И да, что там за геморрои-то?
Где можно почитать подробнее про использование SCTP в проде?
Недавно хотел поэкспериментировать с ним, так в ряде языков даже не входит в стандартную либу.
Как чуть выше было написано, используется в телекомах, но только если это довольно крупный телеком, связанный с телефонией, типа сотового оператора. Используется для SIGTRAN.
И то, это нишевое применение даже в телекоме. Больше нигде видеть не доводилось.
И то, это нишевое применение даже в телекоме. Больше нигде видеть не доводилось.
И то, это нишевое применение даже в телекоме.
Ну насчет «нишевого» я бы поспорил, его много в тяжелых телекомах, но только там, почему — ответ ниже.
Больше нигде видеть не доводилось.
Неудивительно, его разрабатывали телекомщики для телекома, а именно — чтобы SS7 по IP-сети гонять :)
Вообще, протокол достаточно интересный, кстати.
Более того, само наличие его драйвера в винде конфликтует с возможностью .NET-приложений делать http-запросы. Только не спрашивайте как так получается…
Все же действительно, принцип работы другой. В TCP все идет от концепции потока данных. В SCTP от "сообщения". В общем, можно пересмотреть передачу данных по HTTP как набор сообщений — каждое сообщение отдельный ресурс (картинка, стиль, скрипт и пр.). Наверное, в этом есть здравый смысл. Как минимум на уровне нижележащего протокола не будет такой болью потеря и переупорядочивание пакетов. Ну заказали мы две картинки, они пришли нам в другом порядке — в чем проблема?
Я очень давно не писал что-то с UDP, могу ошибаться, поправьте, если что — но, насколько я помню, в UDP очень не хватало подтверждения того, что отправленный пакет был доставлен? В сети компов, соединённых BNC, это было критично...
Можно ли апач научить работать с ним?
происходит потому, что QUIC работает в пользовательском пространстве, а не в пространстве ядра
Какой-то мутный критерий. В тот же gnu/linux можно было вполне себе встроить и проверять на одном уровне. Заодно, был бы poc и прототип как это в posix встроить.
А потом этот QUIC обрастет целым ворохом Congestion Avoidance алгоритмов и прочих нахлобучек. TCP и так уже работает совсем нетривиально…
В общем, пока как-то сыровато выглядит — если у протокола уже при рождении есть очевидные косяки.
В общем, пока как-то сыровато выглядит — если у протокола уже при рождении есть очевидные косяки.
Каковы шансы, что после успешного landing и получения промоута очередным сеньёром в гугле, этот проект закроют? Я оцениваю их примерно как вероятность, что гугль закроет свою социальную сеть. Или ньюсридер.
HTTP/2-over-QUIC стал HTTP/3
daniel.haxx.se/blog/2018/11/11/http-3
daniel.haxx.se/blog/2018/11/11/http-3
О, новый уровень абстракции чтобы решить проблемы с предыдущими. Дайте два.
В QUIC больше нет набора параметров, связанных с IP-адресами и портами сервера и клиента. Вместо них протокол работает с идентификатором соединения UUID.
Работа QUIC строится на протоколе UDPВзаимоисключающие параграфы
Очень интересная штука для мобильного трафика, от GTP можно будет отказаться.
А почему его сравнивают именно с TCP? Это же другой уровень модели OSI?
Под капотом обычный UDP, а это 5 уровень или выше.
Под капотом обычный UDP, а это 5 уровень или выше.
UDP как и TCP как и упоминавшийся выше SCTP это транспортный 4й уровень.
Хотя если имеется, что QUIC выше транспортного, тогда может быть.
Хотя если имеется, что QUIC выше транспортного, тогда может быть.
Тут вообще все в кучу
Автор бы хоть дейтаграмму TCP открыл, увидел бы что там нет IP адреса, а он уровнем ниже. И ведь статья в плюсе.
В протоколе TCP-соединение определяется IP-адресами и портами сервера и клиента. Если по какой-то причине один из этих параметров изменяется, приходится пересоздавать подключение. Отсюда вытекают сложности со стабильностью связи в мобильных сетях. Пользователь перемещается между разными сотовыми вышками и постоянно меняет IP-адрес.
Автор бы хоть дейтаграмму TCP открыл, увидел бы что там нет IP адреса, а он уровнем ниже. И ведь статья в плюсе.
И я не уверен, что IP адрес меняется при перемещении между вышками. Это ж не вайфай.
Есть ощущение, что пакетное ядро (которое допустим на макрорегион) загнётся занимаясь постоянной сменой IP адресов перемещающимся туда сюда миллионам абонентов :)
Есть ощущение, что пакетное ядро (которое допустим на макрорегион) загнётся занимаясь постоянной сменой IP адресов перемещающимся туда сюда миллионам абонентов :)
Вы заехали в тоннель, интернет пропал, выехали — подключаемся заново и получаем новый IP, как вариант.
В тоннеле связь физически пропала — открытые соединения легли, воспроизведение потоков прекратилось, закачки остановились. Никакой протокол от этого принципиально не спасёт :)
Я предполагаю, что QUIC разрабатывался для решения проблемы тех, кто очень часто пересекает госграницу, а в Европе таких немало, а жители микрогосударств пересекают её хоть раз в месяц почти поголовно. Пересекли границу — включается роуминг, соответственно меняется адрес, никакие шенгенские соглашения тут принципиально не помогут.
Я предполагаю, что QUIC разрабатывался для решения проблемы тех, кто очень часто пересекает госграницу, а в Европе таких немало, а жители микрогосударств пересекают её хоть раз в месяц почти поголовно. Пересекли границу — включается роуминг, соответственно меняется адрес, никакие шенгенские соглашения тут принципиально не помогут.
В тоннеле связь физически пропала — открытые соединения легли, воспроизведение потоков прекратилось, закачки остановились. Никакой протокол от этого принципиально не спасёт :)А теперь, пожалуйста, более формально — и найдите ошибку в ваших рассуждениях.
P.S. Она там точно есть потому что как раз от этого QUICK вполне себе спасает. Более того, в рекламном проспекте рассматривается более простой случай: вы не вьехали в тоннель, а, наоборот, пришли к себе домой, телефон радостно переключился на WiFi — а фильмец продолжает скачиваться, как ни в чём не бывало.
Хм. А сейчас разве не так? При переключении сетей будет небольшая пауза, потом пойдет докачка.
И с QUIC при переключении с мобильного инета на Wi-Fi все равно будет небольшая задержка при переустановлении соединения — старый сокет закрыть, новый открыть когда поднимется новая сеть.
Я так понимаю, они просто сделали слой абстракции, который сделает это переключение незаметным для ПО и упростит (возможно) написание кода разработчиками. Ну и с дополнительными оптимизациями, чтобы сократить паузу при переключении между сетями.
И с QUIC при переключении с мобильного инета на Wi-Fi все равно будет небольшая задержка при переустановлении соединения — старый сокет закрыть, новый открыть когда поднимется новая сеть.
Я так понимаю, они просто сделали слой абстракции, который сделает это переключение незаметным для ПО и упростит (возможно) написание кода разработчиками. Ну и с дополнительными оптимизациями, чтобы сократить паузу при переключении между сетями.
Хм. А сейчас разве не так? При переключении сетей будет небольшая пауза, потом пойдет докачка.
Только если докачка (HTTP Range) поддерживается сервером и браузером. В противном случае файл будет скачиваться с самого начала.
Хм. А сейчас разве не так? При переключении сетей будет небольшая пауза, потом пойдет докачка.Это реализуется не на уровне TCP (где это было бы сделать логично), а на более высоком уровне.
То есть TCP-соединение фейлится и скачка, на самом деле, начинается по новой. Если сервер не поддерживает HTTP Range — то будет всё скачано с самого начала.
В перспективе не будет, см. habr.com/company/vasexperts/blog/429380/#comment_19368186
Она там точно есть потому что как раз от этого QUICK вполне себе спасает.Опа-на, связь в тоннелях, оказывается, есть благодаря волшебному протоколу (QUIC без буквы «K» пишется, у вас походу спеллчекер шалит)? А я-то думал её обеспечивают GSM-репитеры. Впрочем, QUIC явно разрабатывался не для этого случая, если, конечно, имеется ввиду не тоннель под Ла-Маншем.
наоборот, пришли к себе домой, телефон радостно переключился на WiFi — а фильмец… Лучше дома на телеке посмортеть, сидя на диване, а не мучать смартфон.
… Лучше дома на телеке посмортеть, сидя на диване, а не мучать смартфон.Лучше. Если у вас есть он, этот телек. Однако телевизоров с мире — порядка полутора миллиардов, а смартфонов — больше четырёх. То есть в огромном количестве случаев на телевизоре придётся смотреть не то, что хочется/нравится вам, а что-то, что хочется нравится вашим родителям/жене/тёще… нужное подчеркнуть.
del
А при чем тут структура пакета? В протоколе TCP соединение строится между двумя конечными точками, у каждой из которых есть адрес и порт. И тот факт, что передается адрес на уровне заголовков IP, а не TCP, никак не мешает драйверу TCP учитывать его.
TCP не требуется знать IP адрес. Бывает, например, TCP over IPX.
Но ведь какой-то адрес ему все равно требуется?
Какой-то адрес обеспечивают нижележащие протоколы, например, IP.
Я не понимаю что вы пытаетесь мне сказать.
Когда мы говорим в обиходе TCP мы в действительности имеем в виду стек протоколов TCP/IP. Для примера это может быть так: Ethernet->IP->TCP->Http.
Так вот сам пакет TCP не несет информации об IP-адресе. Информация об IP-адресе содержится (внезапно) в заголовке IP-пакета.
И, например, может существовать такая связка: Ethernet->IPX->TCP->Http. И адресация будет производиться средствами IPX.
Так вот сам пакет TCP не несет информации об IP-адресе. Информация об IP-адресе содержится (внезапно) в заголовке IP-пакета.
И, например, может существовать такая связка: Ethernet->IPX->TCP->Http. И адресация будет производиться средствами IPX.
И адресация будет производиться средствами IPX.Хрен редьки не слаще — в любом случае при смене адреса (нормальная ситуация в современных сетях) соединение оборвётся.
Скажите, а где я писал что пакет TCP несет информацию об адресе?
>> Но ведь какой-то адрес ему все равно требуется?
Для самого по себе TCP — не требуется. Адресация обеспечивается нижележащими протоколами.
Для самого по себе TCP — не требуется. Адресация обеспечивается нижележащими протоколами.
Смыл в том, что IP адрес точно так же учитывается и в UDP, повех которого написан QUIC, следовательно критиковать TCP с этой позиции не имеет смысла.
Нет. Протокол UDP не устанавливает соединение, в отличии от TCP — а значит, и порваться соединение от простой смены адреса в нём не может.
Зато NAT (и, соответственно, все мобильные соединения, на которые нацелен QUIC) использует абстракцию соединения для UDP.
Вы важное слово пропустили. Полная фраза звучит так:
Зато NAT (и, соответственно, все мобильные соединения в России, на которые нацелен QUIC) использует абстракцию соединения для UDP.И да, Google почему-то не сильно переживает по поводу того, что и как, собствественно, будет произходить в России, добровольно отказавшейся от использования IPv6.
Можно про отказ в России от АйПи6 поподробнее?
Формально никто ни от чего не отказывался, но до недавнего времени вот на этой карте Россия стабильно была одной из отстающих, менее 1%. Сейчас там, вдруг, 2.32%… Что там фоне передовиков, уже переваливших за ⅓ и потихоньку приближающихся к ½ не слишком много, но да, похоже процес, наконец-то, тронулся…
При использовании IPv6 NATу не нужно следить за соединениями и QUIC работает «как надо» даже если используется NAT.
При использовании IPv6 NATу не нужно следить за соединениями и QUIC работает «как надо» даже если используется NAT.
Для клиента и сервера этот NAT в нормальных условиях прозрачен.
А почему его сравнивают именно с TCP? Это же другой уровень модели OSI?Потому модель OSI имеет такое отношение к реальным сетям, как словарь Клингонского — к английской или русской бизнес-лексике.
Под капотом обычный UDP, а это 5 уровень или выше.Какая разница что у него под капотом, если приложения от него получают те же возможности, что и от TCP?
Я считаю, что QUIC ещё не готов. К тому же, он препятствует кешированию. Извините, но
reply_header_access Alt-Svc deny all
reply_header_access alt-svc deny all
Помимо этого тесты, проведенные Google, показывают снижение числа ребуферизаций при просмотре видео на YouTube на 30%.
Да по их тестам и Gmail стал работать быстрее и лучше, наверное. А вот что они изобрели еще один «стандарт для всех» — это да, это «успех»!
Когда-то я писал свой туннель на базе UDP и столкнулся с замечательной штукой как фрагментирование UDP пакетов, которое клало сервера на обе лопатки при попытке их собрать. А это мне ещё повезло, пакеты могли просто теряться. Значит надо устроить MTU Discovery, причём для надёжности для каждого (!) сайта или гонять мелкие пакеты.
При этом, в TCP есть замечательная опция MSS, которую декларируют обе стороны, но роутер в середине может уменьшить, чтобы избавиться от фрагментации (что, кстати, все всегда делают). С UDP это не прокатит, а с QUIC тем более, что приведёт к проблемам, по сравнению с которыми задержки в TCP казались бы мелочью.
Опять же, в TCP есть куча алгоритмов, связанных с размером окна, а т.к. нам в целом всё равно нужны все пакеты и в правильном порядке, надо их заново реализовывать и лечить те же грабли, на которые уже все наступили в TCP.
При этом, в TCP есть замечательная опция MSS, которую декларируют обе стороны, но роутер в середине может уменьшить, чтобы избавиться от фрагментации (что, кстати, все всегда делают). С UDP это не прокатит, а с QUIC тем более, что приведёт к проблемам, по сравнению с которыми задержки в TCP казались бы мелочью.
Опять же, в TCP есть куча алгоритмов, связанных с размером окна, а т.к. нам в целом всё равно нужны все пакеты и в правильном порядке, надо их заново реализовывать и лечить те же грабли, на которые уже все наступили в TCP.
Протокол шифрует не только данные, но и заголовок пакета, в котором они передаются.
Вот зачем опять эти грабли?
Информационная безопасность должна накладываться только на верхнем, прикладном уровне. Иначе получается как обычно — несовместимость с NAT и прочие «подарки».
Информационная безопасность должна накладываться только на верхнем, прикладном уровне. Иначе получается как обычно — несовместимость с NAT и прочие «подарки».Извините, но NAT — это костыль. NAT сыграл свою роль и его время ушло. Тот факт, что вот прямо сейчас очень популярные и распространённые программы начинают-таки использовать технологии, несовместимые с NAT — это не хорошо. Это замечательно.
NAT это типичный пример того, что модель OSI работает. Нужно что-то изменить в нижележащих слоях? — не проблема, меняй, верхние слои не заметят.
Но как только вы начинаете накладывать шифрование или аутентификацию на слоях ниже прикладного вы получаете закономерные проблемы совместимости — изменить в этом слое уже ничего нельзя.
Но как только вы начинаете накладывать шифрование или аутентификацию на слоях ниже прикладного вы получаете закономерные проблемы совместимости — изменить в этом слое уже ничего нельзя.
Нужно что-то изменить в нижележащих слоях? — не проблема, меняй, верхние слои не заметят.Ну то есть если QUIC «для надёжности» всё шифрует и не даёт осуществлять DPI (являющийся, вообще-то, грубейшим нарушением вашей любимой «модели OSI») — то всё должно работать?
Вы уж, пожалуйста, определитесь:
Иначе получается как обычно — несовместимость с NAT и прочие «подарки».или
NAT это типичный пример того, что модель OSI работаетПотому что эти две фразы друг другу противоречат.
Но как только вы начинаете накладывать шифрование или аутентификацию на слоях ниже прикладного вы получаете закономерные проблемы совместимости — изменить в этом слое уже ничего нельзя.И не надо. Задача QUIC (как и TCP) — надёжно доставить данные. Если кто-то «снизу» хочет лазить в данные протоколов более высоких уровней — то это не «типичный пример работоспособности модели OSI», а как раз наоборот — её вопиющее нарушение. Нижележащие уровни не должны ничего знать о более высоких уровнях. Их задача — доставить данные. Шифрование этому ну аж никак не мешает.
Вы уж, пожалуйста, определитесь
Я определился. Протокол, который вводит шифрование/аутентификацию на уровне, отличном от прикладного — нарушает модель OSI. Если вы его попытаетесь использовать в стэке протоколов OSI, то получите проблемы совместимости.
Задача QUIC (как и TCP) — надёжно доставить данные. Если кто-то «снизу» хочет лазить в данные протоколов более высоких уровней — то это не «типичный пример работоспособности модели OSI», а как раз наоборот — её вопиющее нарушение. Нижележащие уровни не должны ничего знать о более высоких уровнях
Речь не про влезание снизу, а про работу на этом же уровне. Например, порубить пакет на несколько, чтобы они пролезли по каналу.
Протокол, который вводит шифрование/аутентификацию на уровне, отличном от прикладного — нарушает модель OSI.А теперь — пожалуйста, со ссылками. На документы. Первым из них, пожалуйста, что-то, что объяснит — с какого перепугу дизайн самолёта (сетей TCP/IP) должен делаться по чертежам от трактора (модель OSI, напоминаю, была разработана только и исключительно для мертворождённого стека протоколов, к TCP/IP она имеет очень отдалённое отношение изначально).
Если вы его попытаетесь использовать в стэке протоколов OSI, то получите проблемы совместимости.Какие? На NAT, пожалуйста, не ссылаться — с «базовым» NAT'ом QUIC совместим, страдает только DPI, который никаким боком в модель OSI, я извиняюсь, не лезет. То, что он отваливается — так это скорее достоинство, а не недостаток.
Какие?
Ну вот для начала — промежуточный узел не может разрезать пакет, который не пролазит по каналу.
Вы так и не ответили почем нужно работать с самолётом, используя чертежи от трактора.
Последнее, что нужно делать при разработке реальных протоколов для реальных сетей — это смотреть на OSI модель.
Ну вот для начала — промежуточный узел не может разрезать пакет, который не пролазит по каналу.А почему это является проблемой? В TCP/IP есть другой механизм решения этой проблемы. И практические исследования показали — что это лучший способ. Точно также как практические исследования OSI модели паказали, что самое лучшее, что с ней можно сделать — расказать студентам в качестве исторического курьёза, чтобы они понимали, почему теоретические построения без кода — к добру не приводят.
Последнее, что нужно делать при разработке реальных протоколов для реальных сетей — это смотреть на OSI модель.
Я не хочу сказать, что модель OSI хороша, но других пока не придумали. Если допустить, что уровни/слои не обязаны быть иерархичными, то модель вполне работоспособна и удобна.
Если допустить что уровни/слои не обязаны быть иерархичными, то становится непонятен предмет спора.
Я не хочу сказать, что модель OSI хороша, но других пока не придумалиВы не поверите, но… модель TCP/IP. Да, это реткон. Потому что агрессивной рекламе «модели OSI» нужно что-то противопоставить.
Вообще эпоха пост-правды — это невыносимо грустно. Потому что «в былые времена» указание на два факта похоронили бы «модель OSI» сразу и навсегда:
1. OSI-модель разрабатывалась не для описания чего-угодно-вообще, а для определённого стека протоколов
2. Вышеуказанный стек протоколов — умер не родившись, большая часть протоколов, разработанных под OSI модель так и не были реализованы, а те, которые были реализованы — умерли, когда их вытеснили Internet-протоколы
Но в эпоху пост-правды — это никого не смущает. Не смущает даже то, что они рассказывают о достоинствах модели OSI, пользуясь оборудованием, которое им не соответствует. Если честно — это удивляет.
Если допустить, что уровни/слои не обязаны быть иерархичными, то модель вполне работоспособна и удобна.Для чего она удобна, блин? Чтобы срачи на форумах устраивать? При разработке Internet'а она не использовалась, ни одного выжившего протокола, разработанного под эту модель, не сохранилось, реальной реализации сетей она не соответствует (потому что они не под эту модель делались).
Закопайте уже стюардессу, наконец!
Модель достаточно хорошо описывает разные уровни абстракции передачи данных, но не учитывает, что в реальных условиях некоторых уровней может и не быть, они идут не по порядку или совмещены вместе.
Стек TCP/IP никак не учитывает физический и канальный уровни, полагая, что пакеты магическим образом доставляются из точки А в точку Б. Если вы его засунете в физический канал, где больше двух точек (например, в радиоэфир или шину), то возникнет сразу куча проблем с коллизиями, синхронизацией, итд, которые TCP/IP в принципе никак не может решать.
Стек TCP/IP никак не учитывает физический и канальный уровни, полагая, что пакеты магическим образом доставляются из точки А в точку Б. Если вы его засунете в физический канал, где больше двух точек (например, в радиоэфир или шину), то возникнет сразу куча проблем с коллизиями, синхронизацией, итд, которые TCP/IP в принципе никак не может решать.
Ну как бы OSI тоже никак не говорит что на этих уровнях находится, просто постулирует их существование. Вся разница со стеком TCP/IP — в том, что последний не отделяет их друг от друга…
Вся разница TCP/IP (по аналогии с чертежами самолета) — это самолет в вакууме, он не учитывает аэропорты, пилотов, груз, итд…
Ну как бы OSI тоже никак не говорит что на этих уровнях находится, просто постулирует их существование.OSI как раз определяет, но одна беда: всё то, что они определяет — уже много лет, как отправилось на «свалку истории».
Вся разница со стеком TCP/IP — в том, что последний не отделяет их друг от друга…Вся разница со стеком TCP/IP — в том, что стек TCP/IP был «доведён до ума» и реально используется. А стек OSI (несмотря на дикое количество хайпа в 90е… скажем Microsoft Exchange изначально делался под OSI, а не под TCP/IP) — умер. Всё. Закопали. Нету.
Модель достаточно хорошо описывает разные уровни абстракции передачи данных, но не учитывает, что в реальных условиях некоторых уровней может и не быть, они идут не по порядку или совмещены вместе.Это то, о чём я говорил: у нас есть прекрасные чертежи от так и
непостроенного трактора. Они могут быть применены к имеющемуся у нас самолёту, если мы учтём, что у того нет гусениц, зато есть крылья. Вопрос: нах$я? Зачем нам пытаться прицепить к самолёту чертежи от трактора? Потому что они очень красивые и на дорогой бумаге напечатаны?
Ещё более дико выглядит замечание о том, что не стоит наш самолёт переделывать, перенося рули с хвоста вперёд — потому что наши чертежи будут ещё хуже подходить! Это может быть хорошей идеей и плохой, но уж точно не сравнением с чем-то, что мы так и не постороили нужно это определять.
Стек TCP/IP никак не учитывает физический и канальный уровни, полагая, что пакеты магическим образом доставляются из точки А в точку Б.Стек никак не разделяет физический и канальный уровень — и в этом его сила.
Если вы его засунете в физический канал, где больше двух точек (например, в радиоэфир или шину), то возникнет сразу куча проблем с коллизиями, синхронизацией, итд, которые TCP/IP в принципе никак не может решать.Именно поэтому в модели TCP/IP (которая, в отличие от модели OSI описывает реально существующие сети) есть отдельный уровень для всего этого — канальный (он же — физический). Он обеспечивает доставку пакетов внутри одной сети. Причём, что характерно, TCP/IP не волнует — как именно. Он, кстати, может иметь в себе не только много уровней, но и, вообще, использовать ажно целый Internet со всем стеком протоколов для этого (см. VTun). Вышележащие уровни всё это не волнует, их волнует только одна вещь: канальный (он уж физческий) уровень как-то передаёт информацию внутри одной сети… как — никого не волнует.
Лежащий «над ним» уровень доставляет пакеты из точки A в точку B в разных сетях (и имеет для этого разные технологии тоже). Этот уровень — уже реализован по спеке во всех компьютерах, поддерживающих TCP/IP. Что и позволяет пользователям рассматривать Internet как одну большую сеть.
Следующий уровень (который приложение может использовать, а может и нет) — обеспечивает доставку. Надёжную (TCP) или ненадёжную (UDP). И именно этот уровень меняет QUIC. И делает доставку, за счёт сквозного шифрования, надёжнее, чем TCP. Правда он использует UDP, что, действительно, не совсем хорошо — но это как раз не так принципиально: сделать реализацию «прямо на IP» можно и потом, когда технология будет обкатана и детские болезни устранены. В конце-концов UDP имеет самый минимальный overhead, какой только может быть: там нет ничего сверх IP, кроме чексуммы и пометки, позводляющей многим приложениям посылать пакеты без коллизий (если бы приложениям дали бы возможность формировать IP-пакеты напрямую, без резервирования портов, то на принимающей стороне могла бы работать только одна программа).
А уже над этими тремя уровнями — живут прикладные программы. Которые могут пользоваться транспортным уровнем и реально не могут ничего делать с нижележащими уровнями (за исключением некоторого числа «отладочных» программ, которые могут видеть оба нижележащих уровня — но требуют для этого особых привелегий).
Всё логично, просто, и, главное, соотвествует реальности. Не нужно сову на глобус натягивать. И рассказывать сказки про то, что уровней может не быть или что они могут идти в другом порядке.
Именно поэтому в модели TCP/IP (которая, в отличие от модели OSI описывает реально существующие сети) есть отдельный уровень для всего этого — канальный (он же — физический).
Хорошо, допустим. Покажите мне канальный/физический уровень при использовании TCP внутри одной машины (localhost) без сетевых карт, портов и прочих устройств связи.
Что вы хотите увидеть? Драйвер — вот он, любуйтесь. А что физических устройств нету — так их не будет, если вы и 100 виртуальных маших в VMWare замутите со сложной сетевой топологией! А роутинг — будет, можно даже BGP развести в тестовой сети…
Физический уровень — это прием и передача отдельных битов. Это дороги, мосты, площади.
Канальный уровень — это обмен битами (байтами, пакетами) между устройствами физического уровня. Это как пешеходы и автомобили.
А IP это тупо контейнер, ящик для почтовой посылки. Без канального и физического уровней он не сможет даже покинуть здание (узел связи, компьютер). Драйвер, который вы показываете — это даже не драйвер, а «заглушка», которая все принятое передает обратно.
Канальный уровень — это обмен битами (байтами, пакетами) между устройствами физического уровня. Это как пешеходы и автомобили.
А IP это тупо контейнер, ящик для почтовой посылки. Без канального и физического уровней он не сможет даже покинуть здание (узел связи, компьютер). Драйвер, который вы показываете — это даже не драйвер, а «заглушка», которая все принятое передает обратно.
Все это верно, но какое отношение оно имеет к различиям стеков OSI и TCP/IP?
Это верно только если вы используете стек протоколов OSI. И то только потому, что он вымер и его не пришлось менять, для того, чтобы как-то согласовать реальность с мертворождённой моделью.
В TCP/IP же… в реальном мире… Я уже приводил в пример VTun. Какие там, к терапевту, «дороги, мосты, площади»? Это в дополнение к лупбэку, который уже сам оппонент привёл.
Всё это разделение на 7 уровней — это для «истинно верующих». Причём если присмотреться поближе, то получаем старое доброе «верую ибо нелепо».
В TCP/IP же… в реальном мире… Я уже приводил в пример VTun. Какие там, к терапевту, «дороги, мосты, площади»? Это в дополнение к лупбэку, который уже сам оппонент привёл.
Всё это разделение на 7 уровней — это для «истинно верующих». Причём если присмотреться поближе, то получаем старое доброе «верую ибо нелепо».
Физический уровень — это прием и передача отдельных битов. Это дороги, мосты, площади.И всё это существует только в стране розовых поней и единорогов, какающих радугой.
Канальный уровень — это обмен битами (байтами, пакетами) между устройствами физического уровня. Это как пешеходы и автомобили.
Ещё раз: вы рассказывает сказки. Про несуществующую технологию. Умершую. То, что существует в реальном мире, на уровне ниже сетевого может иметь один уровень, то есть меньше двух (пример вы привели сами, блин), так и значительно больше (скажем в WiFi — там пять уровней).
Апологеты мертворождённого высера на это заявляют: нет-нет-нет, там всё хорошо, нужно только высунуть язык, прищурить глаза и оттопырить ухо, желательно правое — и вы увидите два уровня и в лупбэке (где их отродясь не бывало), так и WiFi.
Реакция нормального человека, который думает, а не заучивает мантры, будет: «ну и зачем?»
Зачем терзать своё лицо и пытаться увидеть два уровня там, где их больше или меньше — если в результате мы всё равно об этих уровнях ничего сказать не можем? В любом случае, чтобы понять, как они взаимодействуют нужно будет в конкретную технологию лезть!
Та же история и с уровнями выше транспортного.
Как уже было сказано: если допустить что уровни/слои не обязаны быть иерархичными, то становится непонятен предмет спора.
Хорошо, я расскажу еще одну сказку. Про то, как я создаю системы с сотнями тысяч узлов, где IP почти не используется. Он там есть, но от него больше проблем, чем пользы.
Посмотри сюда — Формат кадра Ethernet — тут есть все, что нужно — адрес отправителя, адрес получателя, данные, контрольная сумма. Еще можно добавить адрес подсети VLAN. И работает это в масштабах оператора связи. В моем случае сеть состоит из приборов и центральных узлов, к которым эти приборы подключаются. При желании можно и между сетями связь сделать, но такая задача у меня не стоит.
Посмотри сюда — Формат кадра Ethernet — тут есть все, что нужно — адрес отправителя, адрес получателя, данные, контрольная сумма. Еще можно добавить адрес подсети VLAN. И работает это в масштабах оператора связи. В моем случае сеть состоит из приборов и центральных узлов, к которым эти приборы подключаются. При желании можно и между сетями связь сделать, но такая задача у меня не стоит.
Пользователь перемещается между разными сотовыми вышками и постоянно меняет IP-адрес.
Этого как раз не происходит при переходе между вышками. Этого даже не должно происходить при переходе между 2g-3g-4g. В правильно работающей сети.
Мобильная связь тут, скорее, из-за перегрузки (congestion) радиоканала. И в теории quic с этой ситуацией должен справляться лучше.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
На замену TCP: протокол QUIC готов для внедрения [но не готов стать RFC]