LINUX.ORG.RU

Авторы Си — наркоманы?

 , , ,


1

5

Столкнулся с интересным багом. После того как разобрался, что же именно происходит, меня постигло крайнее изумление! Оказывается, в языке Си тип числовой константы зависит от формата записи.

Дистиллированный пример кода, который это демонстрирует:

#include <stdbool.h>
#include <stdio.h>

#define IS_HEX(x) \
    _Generic((x), \
        unsigned int: true, \
        long: false \
    )

#define X 0x80000001
#define I 2147483649

int main(void) {
    if(X == I)
        puts("X == I");

    if(!IS_HEX(I))
        puts("I is not hexadecimal");

    if(IS_HEX(X))
        puts("X is hexadecimal");

    return 0;
}

Все три сообщения будут выведены на экран.

Зачем это сделано? Кому от этого легче? Какие оптимизации это позволяет проворачивать, кроме оптимизации отстрела ног программистам? Непонятно! В общем, стремлюсь поделиться своим негодованием здесь и предостеречь будущие поколения от наступления на эти грабли.



Последнее исправление: dataman (всего исправлений: 1)
Ответ на: комментарий от yorshka

Не, так не пойдёт. «Жопой чую что багов нет» – это не гарантии, это херня какая-то.

Не перевирай что я писал. Я писал «логикой и поиском». Ни про какое «чую что багов нет» речи не было.

то эта политика вероятно вызвана этим фактом

Хм, может быть и этим. Но, тем не менее, такое именование очень помогает найти все упоминания конкретного поля, не путая его с полями других структур или просто именами переменных.

firkax ★★★★★
()

_Generic((x), \
unsigned int: true, \
long: false \
)

Нет, автор вот этого - наркоман.

Shadow ★★★★★
()
Последнее исправление: Shadow (всего исправлений: 1)
Ответ на: комментарий от yorshka

Нет, это как раз зря выкинули, эта конструкция имеет огромное воспитательное значение - сразу выкидывает на помойку все аргументы UB-адептов на тему указателей. Хотя, надо признать, в современном Си без особых проблем можно писать так:

int i = 5;
((struct Y*)i)->b = 42;
((struct Y*)100)->a = 0;
Что я и делал в случае нужности таких действий.

firkax ★★★★★
()
Ответ на: комментарий от yorshka

суровые бородатые профессионалы

Это ты с *BSD перепутал. И почему-то большинство там не бородаты.

Shadow ★★★★★
()
Ответ на: комментарий от firkax

сразу выкидывает на помойку все аргументы UB-адептов на тему указателей.

Как их можно выкинуть, если они в стандарте? Повторюсь в третий раз, мы говорим про язык, где конструкция NULL+0 является UB, потому что когда-то там в давние времена существовали компьютеры, в которых указатель NULL не был заполнен нулями.

yorshka
() автор топика
Ответ на: комментарий от yorshka

ну да, потому туда раст тащат, ведь си не осилили

mittorn ★★★★★
()
Ответ на: комментарий от wirewalk

Ты какую-то нерелевантную ерунду написал. А местами просто напросто враньё (например потерянный пакет не блокирует приём следующих и тем более никак не влияет на другие «потоки»).

firkax ★★★★★
()
Ответ на: комментарий от firkax

Нет, нельзя. Для стрикт алиасинга, допустим, костыле-ключик подберёшь, но вот другое УБ, которое запрещает вылазить указателями за пределы некого исходного объекта(i), вообще никак не отключается, насколько я помню.

zurg ★★
()
Последнее исправление: zurg (всего исправлений: 1)
Ответ на: комментарий от wirewalk

На C программирую регулярно

Ты не на оригинальном Си пишешь.

Впрочем, зачем привязываться именно в редакциям 70-х годов, не знаю.

firkax ★★★★★
()
Ответ на: комментарий от wirewalk

Хватит сказки гугловских маркетологов пересказывать.

firkax ★★★★★
()
Ответ на: комментарий от yorshka

Так в том и дело, что эта конструкция старше UB-фантазий и соответственно приоритетнее. А UB-фантазии, где бы они ни были написаны, вступают с ней в конфликт и соответственно должны быть отклонены.

firkax ★★★★★
()
Ответ на: комментарий от zurg

strict-aliasing включать даже не думай, тут нечего обсуждать. А вот это

другое УБ, которое запрещает вылазить указателями за пределы некого исходного объекта(i)

фантазии комитетчиков в чистом виде, не обращай внимания.

firkax ★★★★★
()
Ответ на: комментарий от firkax

эта конструкция старше UB-фантазий и соответственно приоритетнее.

Нет, это не так работает.

А UB-фантазии, где бы они ни были написаны, вступают с ней в конфликт и соответственно должны быть отклонены.

Если ты спросишь лично моё мнение по этому вопросу, то я считаю, что в языке не должно быть UB в принципе. С другой стороны, в комитете сидят говнохранители, готовые порвать жопу на британский флаг, защищая нелепые артефакты из древних времён, а авторы компиляторов готовы следовать каждой букве стандарта, написанного вышеупомянутыми персонажами. Так что ты это им рассказывай, не мне. В суровой реальности, в которой мы существуем, в стандарте языка Си есть 13 страниц с перечислением неопределённого поведения, и с этим фактом надо считаться. Либо же выкинуть Си на помойку.

yorshka
() автор топика
Ответ на: комментарий от firkax

Ты какую-то нерелевантную ерунду написал. А местами просто напросто враньё (например потерянный пакет не блокирует приём следующих и тем более никак не влияет на другие «потоки»).

«Потерянный пакет не блокирует приём следующих»

Блокирует. Не приём - доставку приложению. TCP recv buffer принимает все пакеты. Но recv() не вернёт данные после gap, пока gap не заполнится ретрансмиссией. Пакеты 1,2,3,5,6,7 пришли. 4 потерян. Приложение получит 1,2,3 - и остановится. 5,6,7 лежат в buffer, ждут 4. Это называется head-of-line blocking. Это RFC 793, section 3.7. Read the spec.

«Никак не влияет на другие потоки»

Правильно. Не влияет. Потому что «других потоков» в TCP нет. TCP - один byte stream. HoL blocking - проблема когда приложение мультиплексирует несколько логических потоков поверх одного TCP-соединения (HTTP/2). TCP не знает про потоки - он честно держит buffer до заполнения gap. Результат: один потерянный пакет держитит все мультиплексированные streams. Это не баг TCP - это то, что получается когда единственный доступный протокол не подходит для задачи.

«Нерелевантная ерунда»

Конкретно: что именно не релевантно? Middlebox ossification? - МТС и Ростелеком отбрасывают незнакомые unknown TCP options - это суровая реальность. 0-RTT? - Спутник Geostationary, 600ms RTT, три handshake round-trip до первого байта данных - это наблюдаемое поведение. Connection migration? - проверь: позвони по телефону, переключись с WiFi на LTE.
Всё это наблюдаемая реальность.

Не согласен - возражай по существу. Со ссылками. «Ерунда и враньё» это не аргумент. Как и «вайб не тот».

wirewalk
()
Ответ на: комментарий от yorshka

UB - не артефакт прошлого, а испорченный телефон. Вобщем, надо эти заявления игнорировать. Разумеется, надо при этом учитывать поведение конкретных компиляторов (знать что strict-aliasing портит доступы к памяти например).

firkax ★★★★★
()
Ответ на: комментарий от firkax

UB - не артефакт прошлого,

Нет. UB – это артефакт времён стандартизации языка, когда был вагон разных несовместимых реализацией и требовалось как-то это описать. Типа вышеупомянутого случая с ненулевым NULL или разными форматами знаковых чисел. Сейчас всего этого уже давно нет, современные системы с этой точки зрения донельзя одинаковые. Но эту говнину продолжают тащить.

Вобщем, надо эти заявления игнорировать.

Игнорировать UB не получится, тебе это выстрелит куда-нибудь.

yorshka
() автор топика
Ответ на: комментарий от Shadow

А что glib? Оно как-то сишку лечит? А вот статтипизация вместо динамической лапши - нефиговое улучшение, так что некорректное сравнение

zurg ★★
()
Ответ на: комментарий от wirewalk

Спутник Geostationary, 600ms RTT, три handshake round-trip до первого байта данных - это наблюдаемое поведение

Вот ей богу, этот пример вообще к TCP отношения не имеет. Ты ещё пожалуйся, что до Марса задержка от 3 до 15 минут, и TCP по таймауту отваливается.

Для таких случаев есть совершенно другие протоколы. Смотри RFC5050, для начала.

yorshka
() автор топика
Ответ на: комментарий от yorshka

Ты ещё пожалуйста, что до Марса задержка от 3 до 15 минут

Ты еще возрази, что мало было «три handshake round-trip до первого байта данных», надо было ваще 100500 рундтрипов запилить. Ну а чо? Мы ж не на Луну звоним, тут все близёхонько.

wirewalk
()
Ответ на: комментарий от wirewalk

Блокирует. Не приём - доставку приложению.

Приложение и не хочет чтобы ему присылали пакет без предыдущих перед ним байт. Это не недостаток протокола, это его практически основная фича, ради которой его используют. Большинству она нужна и полезна. Кому не нужна - используют другие протоколы, но это редко. Только не надо приводить в пример веб-макак из гугла с их quic-ом, там это не необходимость, а костыль к коду веб-макак.

Read the spec.

У тебя проблемы с русским языком? rfc эти я читал, и, более того, писал по ним сетевой стек (с нуля, без какого-либо кода ОС в основе вообще, включая драйвера сетевух, но это уже другая история) и постоянно пользуюсь написанным продуктом.

Потому что «других потоков» в TCP нет. TCP - один byte stream.

Нет, TCP это протокол. А поток это TCP-соединение, и их может быть много.

проблема когда приложение мультиплексирует несколько логических потоков поверх одного TCP-соединения (HTTP/2)

Да, иногда это проблема. Но виноват тут не TCP, а авторы http/2 (без вредоносного гугла тоже не обошлось).

что именно не релевантно?

Всё нижеперечисленное. Недостатками TCP это не является. И у тебя опять проблемы с русским языком, одни иносранные словечки.

«вайб не тот»

Даунские словечки тоже не следует использовать.

firkax ★★★★★
()
Ответ на: комментарий от wirewalk

Ты еще возрази, что мало было «три handshake round-trip до первого байта данных», надо было ваще 100500 рундтрипов запилить.

В подавляющем большинстве случаев это не так критично. Тем более, что у этого есть причины. К слову, в SCTP вообще four-way handshake ради безопасности и защиты от syn flood сделали. Так что да, мало.

Если хочешь сразу данные напрямую слать, TCP не для тебя.

yorshka
() автор топика
Ответ на: комментарий от yorshka

UB – это артефакт времён стандартизации языка

Я думал ты под прошлым имел ввиду 70-е годы. Ну так-то да, UB выдумали комитетчики когда стандарт сочиняли. Только это всё равно испорченный телефон. Потому как исходное

когда был вагон разных несовместимых реализацией

то есть обычное «зависит от реализации/платформы», спустя годы превратилось в «нельзя так делать а то компилятор будет есть младенцев» (ну или хотя бы испортит вам код в рандомном месте рандомным способом).

firkax ★★★★★
()
Ответ на: комментарий от yorshka

Да его гугломаркетологи покусали, видно же. У них методичка на эту тему «ужас первый байт долго» итд.

firkax ★★★★★
()
Ответ на: комментарий от firkax

то есть обычное «зависит от реализации/платформы», спустя годы превратилось в «нельзя так делать а то компилятор будет есть младенцев» (ну или хотя бы испортит вам код в рандомном месте рандомным способом).

Нет, так изначально было. Посыл был в том, чтобы язык давал по щщам за использование несовместимых фич, поэтому в списке UB есть совсем уж комические примеры типа отсутствия переноса строки в конце файла.

yorshka
() автор топика
Ответ на: комментарий от yorshka

Нет, изначально было что есть разные платформы и они местами несовместимы. А в интерпретации комитетчиков это превратилось в «давайте расставим тут капканы». Это совершенно не то же самое что несовместимые реализации.

Но на самом деле, несмотря на старания ISO, большинство UB-страшилок так и осталось просто страшилками, за которыми скрывается зависимость от реализации.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от firkax

Нет, изначально было что есть разные платформы и они местами несовместимы. А в интерпретации комитетчиков это превратилось в «давайте расставим тут капканы». Это совершенно не то же самое что несовместимые реализации.

Под «изначально» я имею ввиду момент создания стандарта. То, что было до него, можно считать за пачку немного совместимых языков, имеющих общее название Си.

yorshka
() автор топика
Ответ на: комментарий от yorshka

Так сейчас тоже есть пачка примерно совместимых языков. Вот например GNU C принимает main(unsigned int argc,), а шланг нет. Шланг плохой.

firkax ★★★★★
()
Ответ на: комментарий от firkax

Это фигня. Серьёзно, почитай историю, там куча феерического есть. Начиная с отдельных несовместимых типов указателей для разных типов, множества значений NULL. Отсюда все эти всратые артефакты, типа NULL == (void*)0 и при этом int i = 0; NULL != (void*)i.

yorshka
() автор топика
Ответ на: комментарий от firkax

Приложение и не хочет чтобы ему присылали пакет без предыдущих

Это всех приложений касается? Нет. Real-time video: ключевой кадр пришёл, delta-кадры потерялись - покажи ключевой, не жди. Но TCP заставляет ждать. Это не «основная фича», это ограничение. Фича - это когда ты можешь выбирать. TCP выбора не даёт.

Кому не нужна - используют другие протоколы

Ещё раз: какие? UDP - нужно всё строить самому. SCTP - не проходит через NAT. DCCP - не проходит через NAT. QUIC - единственный рабочий вариант, и он поверх UDP именно потому что TCP-альтернативы нет. «Используй другой протокол», да.

Не надо приводить в пример веб-макак из гугла

Ad hominem. Google обрабатывает 8.5 миллиардов запросов в день. YouTube - 500 часов видео в минуту. Если их инженеры столкнулись с проблемой и создали решение - это не «костыль веб-макак», это инженерная практика в масштабе, который ты можешь обзывать на ЛОР-е, но который определяет то, как работает интернет.

Писал сетевой стек с нуля

Тогда ты должен знать лучше всех: TCP спроектирован как reliable, ordered byte stream. Это архитектурное решение. Архитектурные решения - это компромиссы. Компромисс означает: для одних случаев идеально, для других - нет. Отрицать что компромисс существует - это религия.

Нет, TCP это протокол. А поток это TCP-соединение

Одно TCP-соединение - один byte stream. Несколько соединений - несколько byte streams. Но каждое соединение - независимое, не разделяют congestion control state, не разделяют handshake overhead, и каждое - отдельно жрёт ресурсы. Это тоже компромисс. Отдельные соединения - overhead. Одно соединение с мультиплексированием - HoL blocking. TCP не даёт третьего варианта.

Виноват не TCP, а авторы HTTP/2

HTTP/2 мультиплексирует поверх одного TCP-соединения потому что открыть несколько TCP-соединений - дорого. Handshake, congestion control cold start, per-connection overhead. Авторы HTTP/2 выбрали меньшее зло. Если бы TCP позволял несколько independent streams в одном соединении (как SCTP или QUIC) - этой проблемы бы не было. «Виноват не TCP» - это как сказать «виноват не мост, а тот кто по нему пошёл.» «Наш мост не рассчитан на людей весом больше 100 кило - не ходите,, не дышите, а лучше даже не прикасайтесь, будете сами виноваты!»

Одни иностранные словечки

Middlebox, handshake, congestion control, bufferbloat, head-of-line blocking - это терминология. RFC пишутся на английском. Спецификации - на английском. Режет слух - спеки это не твоё. Читай «Репку».

wirewalk
()
Ответ на: комментарий от wirewalk

Ещё раз: какие? UDP - нужно всё строить самому.

Вообще, не нужно. RTP уже существует.

SCTP - не проходит через NAT.

Есть официальный вариант SCTP через UDP. NAT – это всеобщая проблема, не только проблема SCTP. Я знаю, бывали случаи, когда у небольших провайдеров на NAT порты кончались, например.

Real-time video: ключевой кадр пришёл, delta-кадры потерялись - покажи ключевой, не жди. Но TCP заставляет ждать. Это не «основная фича», это ограничение. Фича - это когда ты можешь выбирать. TCP выбора не даёт.

Тебе здесь буквально не нужна гарантированная доставка, но при этом ты ноешь, что протокол с гарантированной доставкой делает тебе гарантированную доставку. Тут, кажется, уже писали про яйца и дверь.

Ad hominem. Google обрабатывает 8.5 миллиардов запросов в день. YouTube - 500 часов видео в минуту. Если их инженеры столкнулись с проблемой и создали решение - это не «костыль веб-макак», это инженерная практика в масштабе, который ты можешь обзывать на ЛОР-е, но который определяет то, как работает интернет.

Если у Гугла есть проблема, это совсем не значит, что она есть у других. Например, у Гугла есть проблема отслеживания пользователей, но у пользователей совсем нет проблемы отслеживания их гуглом. Скорее, наоборот, средний пользователь куда больше заинтересован в том, чтобы гугель за ним не следил.

Авторы HTTP/2 выбрали меньшее зло.

Авторы HTTP/2 сделали настолько классную работу, что пришлось изобретать HTTP/3. Тем временем, HTTP/2 пользуется ещё меньше людей чем IPv6.

yorshka
() автор топика
Ответ на: комментарий от yorshka

RTP уже существует

RTP поверх UDP. Без гарантий. Без congestion control. Без head-of-line management. Каждый из которых - отдельная проблема, которую TCP решает, а RTP - нет. Ты привёл протокол, который отказался от надёжности и порядка - и это ровно подтверждает мой тезис: TCP не даёт промежуточных вариантов. Либо всё, либо ничего. RTP выбрал «ничего.» QUIC выбрал «настраиваемое.» TCP - только «всё.» Выбор из одного варианта.

SCTP через UDP

UDP Encapsulation of SCTP (RFC 6951) - это заплатка поверх заплатки. SCTP-пакет заворачивается в UDP, чтобы пройти через NAT. То есть протокол, который должен был заменить TCP, вынужден прятаться внутри UDP - потому что инфраструктура его не пропускает нативно. Это не «SCTP работает,» это «SCTP работает, если притвориться UDP.» И ты считаешь это аргументом в пользу TCP?

Ноешь, что протокол с гарантированной доставкой делает тебе гарантированную доставку

Я тебе прям в конкретное место тычу пальчиком - гарантированная доставка и гарантированный порядок связаны в TCP намертво. Хочешь надёжность без порядка - нельзя. Хочешь порядок без надёжности - нельзя. Это coupling. В инженерии coupling - это не «фича,» это ограничение гибкости. Иногда оправданное. Но отрицать что это ограничение - как минимум странно

Если у Гугла есть проблема, это не значит, что она есть у других

Google - не единственный. Netflix - QUIC. Facebook - QUIC. Cloudflare - QUIC. Amazon - QUIC. TikTok - QUIC. Это не «проблема Google,» это отрасль. Но да, если ты стримишь видео на три человека через TCP - у тебя нет проблем.

Авторы HTTP/2 сделали такую классную работу, что пришлось изобретать HTTP/3

Именно. HTTP/2 наткнулся на HoL blocking в TCP. HTTP/3 заменил TCP на QUIC. Это буквально подтверждает мой тезис: TCP ограничивает - пришлось заменить транспорт. Спасибо за аргумент.

HTTP/2 пользуется меньше людей чем IPv6

Числа? Согласно W3Techs, HTTP/2 используют ~35% сайтов. IPv6 - ~40%. Разница в рамках статистической погрешности. И оба растут. Но спасибо за яркий пример «вдумчивого» анализа.

wirewalk
()
Ответ на: комментарий от wirewalk

Ты привёл протокол, который отказался от надёжности и порядка - и это ровно подтверждает мой тезис: TCP не даёт промежуточных вариантов.

А с этим разве кто-то спорит?

Тут никто не утверждает, что TCP – идеальный протокол. TCP – это протокол, который решает определённый спектр задач и решает их хорошо.

UDP Encapsulation of SCTP (RFC 6951) - это заплатка поверх заплатки. SCTP-пакет заворачивается в UDP, чтобы пройти через NAT. То есть протокол, который должен был заменить TCP, вынужден прятаться внутри UDP - потому что инфраструктура его не пропускает нативно.

SCTP никогда не должен был заменить TCP, это другой протокол для других задач. Его вообще из SS7 притащили, к стеку TCP/IP он отношения не имел.

Это не «SCTP работает,» это «SCTP работает, если притвориться UDP.» И ты считаешь это аргументом в пользу TCP?

Ты мешает в одну кучу две разных проблемы: проблему дизайна протокола и проблему промежуточной инфраструктуры. Если бы NAT не поддерживал TCP, это всё ещё не было бы проблемой TCP как протокола. Это проблема NAT как костыля.

Google - не единственный. Netflix - QUIC. Facebook - QUIC. Cloudflare - QUIC. Amazon - QUIC. TikTok - QUIC. Это не «проблема Google,» это отрасль. Но да, если ты стримишь видео на три человека через TCP - у тебя нет проблем.

Ну, да? Если ты ещё не понял, то я тебе напишу русским по синему (у меня чёрная тема лол): TCP НЕ ПОДХОДИТ ДЛЯ СТРИМИНГА ВИДЕО. Что не делает его плохо спроектированным протоколом.

Числа? Согласно W3Techs, HTTP/2 используют ~35% сайтов. IPv6 - ~40%. Разница в рамках статистической погрешности. И оба растут. Но спасибо за яркий пример «вдумчивого» анализа.

Доля HTTP/2 стагнирует, за пару лет там не добавилось. В отличие от IPv6. С другой стороны, это доля сайтов, которые его дают. Интереснее было бы посмотреть распределение по трафику. Так-то и у меня включена настройка http2 = enable; в nginx.

yorshka
() автор топика
Ответ на: комментарий от wirewalk

UDP Encapsulation of SCTP (RFC 6951) - это заплатка поверх заплатки. SCTP-пакет заворачивается в UDP, чтобы пройти через NAT. То есть протокол, который должен был заменить TCP, вынужден прятаться внутри UDP - потому что инфраструктура его не пропускает нативно. Это не «SCTP работает,» это «SCTP работает, если притвориться UDP.» И ты считаешь это аргументом в пользу TCP?

Чот я не пойму, но ведь QUIC делает по сути тоже самое - маскируется под UDP на самом деле им не являясь. И в одном случае это по твоим словам плохо, а в другом хорошо. И опять же исходя из примера QUIC, гугл вообще то не меняет интернет. Он приспосабливается к существующей инфраструктуре. Что по твоим же словам является чем то не очень хорошим. Хорошо ли сидеть на двух стульях сразу?

cobold ★★★★★
()
Ответ на: комментарий от yorshka

С этим разве кто-то спорит?

Спор был именно об этом. Исходный тезис: TCP имеет архитектурные ограничения. Ответ: «это не баг, это фича.» Если никто не спорит что ограничения есть - о чём дискуссия?

SCTP из SS7, не должен был заменить TCP

А TCP из arpa пришёл. Это не отменяет сути: SCTP предоставляет частичную упорядоченность и partial reliability - возможности, которых TCP не даёт. Происхождение протокола не делает его нерелевантным.

Проблема NAT, не проблема TCP

NAT существует потому что IPv4 адресов не хватает. IPv4 - потому что TCP/IP стек сложился исторически. Вся экосистема - взаимосвязана. Отделять «проблему протокола» от «проблемы инфраструктуры» - академическое упражнение. Инженер работает с тем что есть. А то что есть - TCP, который нельзя расширить, через NAT, который не пропускает альтернативы. Это система с positive feedback loop: TCP доминирует -> middleboxes оптимизируются под TCP -> альтернативы не проходят -> TCP доминирует. Это не проблема TCP? Это проблема экосистемы, в которой TCP - центральное звено.

TCP НЕ ПОДХОДИТ ДЛЯ СТРИМИНГА ВИДЕО. Что не делает его плохо спроектированным

Cтриминг видео - это огромная доля трафика в интернете. Если протокол, на котором построен интернет, не подходит для ~70% трафика - это как минимум повод задуматься о том, «хорошо ли он спроектирован».

Доля HTTP/2 стагнирует

HTTP/3 растёт. И он на QUIC. Тенденция: новые протоколы - мимо TCP. К чему бы это?

wirewalk
()
Ответ на: комментарий от cobold

QUIC делает то же самое - маскируется под UDP

SCTP-over-UDP - это существующий протокол, который притворяется другим, чтобы пройти через инфраструктуру. QUIC - это новый протокол, который спроектирован поверх UDP с самого начала. UDP для QUIC - не маскировка, а осознанный архитектурный выбор: «мы не можем внедрить новый транспортный протокол в ядро и в middleboxes, поэтому строим в userspace поверх единственного протокола, который пропускается.»

Гугл не меняет интернет, а приспосабливается

Именно. Приспосабливается к тому, что TCP замерз. Если бы TCP можно было развивать - QUIC бы и не понадобился. QUIC существует потому что TCP нельзя обновить. Это и есть аргумент: не «TCP плохой,» а «TCP заморожен,» варианта разморозить нет - пришлось строить новое.

wirewalk
()
Ответ на: комментарий от wirewalk

Если никто не спорит что ограничения есть - о чём дискуссия?

Не вижу тут дискуссии. Просто тебе жопу почему-то из-за TCP рвёт.

TCP из arpa пришёл.

TCP изначально должен был поверх IP работать. SCTP – нет.

NAT существует потому что IPv4 адресов не хватает.

Нет. NAT существует не из-за этого. В IPv6 адресов хватает, но NAT66 тоже существует и применяется.

Cтриминг видео - это огромная доля трафика в интернете. Если протокол, на котором построен интернет, не подходит для ~70% трафика - это как минимум повод задуматься о том, «хорошо ли он спроектирован».

Огромная, но не 70%. TCP не был спроектирован для современного интернета, тут ты прав, но это, опять же, не делает его плохим протоколом.

Это система с positive feedback loop: TCP доминирует -> middleboxes оптимизируются под TCP -> альтернативы не проходят -> TCP доминирует. Это не проблема TCP? Это проблема экосистемы, в которой TCP - центральное звено.

Это проблема экосистемы, в которой middleboxes играют значительную роль и не являются просто повторителями без внутреннего состояния. Вообще, весь стек TCP/IP глубоко проклят, тут ты прав. Но это проблема всего стека TCP/IP в целом, не только TCP. Можешь заодно заявить, что оба IPv4 и IPv6 плохо спроектированы.

yorshka
() автор топика
Ответ на: комментарий от yorshka

это проблема всего стека TCP/IP в целом, не только TCP. Можешь заодно заявить, что оба IPv4 и IPv6 плохо спроектированы.

Ладно, считай что я так и сделал.

IPv6 спроектирован с центральной мыслью в голове - «нам уже, прямо сейчас, мало! а что будет дальше? а как же кофеварки и пылесосы? а если мы еще расплодимся и заселим всю галактику? что, будем ждать новую проблему? ну уж нет, сейчас как родим 100500 адресов! (голос из зала - каждому!) да, каждому! (видимо чтобы не допустить конкуренции между всеми домашними гаджетами в пределах одной квартиры. а то как пойдут кофеварки бодаться с утюгами за адреса - ух) ну и подпилим слегка, что уж там… чтоб два раза не вставать.»
Офигенная задумка. И, главное, теперь это с нами навсегда. Радость-то какая.

wirewalk
()
Ответ на: комментарий от wirewalk

QUIC - это новый протокол, который спроектирован поверх UDP с самого начала. UDP для QUIC - не маскировка, а осознанный архитектурный выбор

А почему поверх UDP то? На TCP и UDP IP клином сошёлся? Чиселки для номера протокола закончились или в чем причина? Да и как не маскировка если по сути поточный протокол прикидывается пакетным? А теперь давайте вспомним про IPV6. Про него так любят писать в интернете о том какую долю в глобальном интернете он занимает. В нем победили NAT, управление потоком и ещё куча ништяков. Казалось бы бери и делай на нём. Заодно и действительно поучаствуешь в изменении интернета, ведь у пользователей с quic over ipv6 будет меньше ttfb, а значит с бытовой точки зрения будет быстрее Интернет и пользователь будет выбирать устройства и сервисы с поддержкой этой технологии

cobold ★★★★★
()
Ответ на: комментарий от cobold

На TCP и UDP клином сошёлся?

Да. Не по стандарту - по факту. IP protocol number field - 8 бит, 256 значений. Чиселки не закончились. Но: каждый NAT, каждый файрвол, каждый балансировщик нагрузки в цепочке между вами и сервером знает ровно два протокола: TCP (6) и UDP (17). Пакет с любым другим номером - drop. Это проверено на примере SCTP (protocol 132). SCTP работает нативно только внутри дата-центров. Через публичный интернет - нет.

Как не маскировка, если поточный протокол прикидывается пакетным?

QUIC - не поточный протокол. QUIC - это мультиплексированный протокол: несколько независимых потоков внутри одного соединения, каждый со своей приоритизацией и своими гарантиями доставки. Потеря одного пакета блокирует только один поток, а не всё соединение (head-of-line blocking - главная проблема TCP для HTTP/2). UDP-датаграмма - это не маскировка, это транспортная единица, поверх которой QUIC строит свою логику. TCP делает то же самое поверх IP - только внутри ядра.

IPv6 победил NAT, бери и делай на нём

IPv6 убирает NAT. Но IPv6 не убирает файрволы, DPI, балансировщики и middleboxes. Проблема не в адресации - проблема в том, что промежуточное оборудование парсит transport layer и пропускает только известные протоколы. IPv6 с новым transport protocol number - всё равно будет дропнут на первом же файрволе.
И главное: IPv6 - 40% adoption. QUIC через UDP работает уже сейчас на 100% IPv4+IPv6.

Пользователь будет выбирать устройства с QUIC over IPv6

Пользователь не выбирает транспортный протокол. Пользователь открывает сайт - и либо он быстрый, либо нет. QUIC поверх UDP уже даёт меньше TTFB прямо сейчас, без IPv6. IPv6 это ортогональная задача.

wirewalk
()
Ответ на: комментарий от cobold

Потому что UDP это и есть абстракция для своих протоколов поверх.

В обсуждениях бреда про некие «маскировки» участвовать неразумно.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от LINUX-ORG-RU

Подумал, что по ссылке список авторов стандарта и где посмотреть результаты тестирования их на наркотики. Табличка, соответственно — автор/вещество.

shdown ★★
()
Последнее исправление: shdown (всего исправлений: 1)
Ответ на: комментарий от Shadow

Ну конечно, подобие объектов, человеческие, а не железячные типы данных.

Просто выкинь Си и возьми нормальный язык, если тебе такое нужно. Хотя бы подмножество C++.

yorshka
() автор топика
Ответ на: комментарий от yorshka

Да я вообще на питоне всё пишу. А мог бы на яве.

Shadow ★★★★★
()
Ответ на: комментарий от shdown

hex/oct форма записи значений бит, знак не важен, приведение литерала к типу идёт по возрастающей по всем типам таким которые вмещают значение, то есть идёт чередование signed/unsigned. Запись dec подразумевает неявным образом занятый бит под знак, терять который нельзя, так что приведение литерала к типу идёт с учётом знака либо только signed либо только unsigned.

Поэтому сколько не прибавляй не увеличивай литерал 42 он всегда будет signed что-то, а вот 0x80000001 являющийся unsigned int, увеличенный до 0x80000001 станет signed long

Но, вижу тебе табличка понравилась, вот ещё «прикол»

  • if (-0x80000000 == 0x80000000) { puts("Да") }
anonymous
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.