Hacker News Digest

Сайт предлагает 15-недельный курс по сериалу Halt and Catch Fire (2014-2017) — вымышленной истории о людях в технологической индустрии 1980–90-х.
Цель — помочь небольшим группам устроить «клуб просмотра» и обсудить технологическое прошлое.

Структура каждого занятия

• Аперитивы — лёгкое видео «на разогрев» (необязательно).
• RFC как коан — документ IETF для размышлений.
• Эмуляция как коан — браузерная эмуляция старого компьютера.
• Темы, вопросы, чтения — что обсуждать и почитать.
• Описание — связь эпизодов с историей техники.
• Краткие содержания эпизодов — можно вместо просмотра; указаны триггеры.

Автор курса: Эшли Блюэр.
Исходники: GitHub.

• Halt and Catch Fire хвалят как «особенный» и один из лучших «техно»-сериалов, особенно за глубокие отношения и человечность.
• Отмечают реалистичность женщин в технике 80-х и точные детали Далласа того времени.
• Камерон вызывает полярные мнения: кто-то её ненавидит, кто-то считает ключевой.
• Некоторым не хватало технической точности и казалось, что драма «перегибает».
• Появилась идея устроить «книжный клуб»-просмотр с обсуждением по ходу серий.

RFC 9839 и плохой Unicode

Unicode хорош, но не все его символы. Часто приходится исключать «проблемные». Чтобы формализовать это, мы с Полом Хоффманом написали черновик, и теперь он стал RFC 9839 — всего 10 страниц, читайте, если проектируете текстовые поля.

Пример боли: JSON-поле username может содержать:

• U+0000 — нулевой байт, ломает языки;
• U+0089 — устаревший C1-контрол «HTJ»;
• U+DEAD — несвязанный суррогат, запрещён в UTF-8;
• U+7FFFF — «noncharacter», не должен передаваться.

RFC 9839 перечисляет такие категории и предлагает три готовых подмножества, которые можно просто запретить.

Не вините Дуга Крокфорда: JSON создавался раньше, когда Unicode был молод. Но теперь нужен способ явно сказать «эти символы не нужны».

PRECIS (RFC 8264, 2002) уже решал похожую задачу, но 43 страницы сложностей и привязка к конкретной версии Unicode мешают внедрению. RFC 9839 проще и тупее — и, возможно, именно поэтому пригодится.

• Участники спорят, нужно ли на уровне JSON/протокола запрещать «плохие» символы Unicode (управляющие, суррогаты, заломы направления и т. д.) или оставить это прикладной валидации.
• Одни считают, что жёсткие ограничения защищают от ошибок и атак (RTL-override, залого-текст, сломанные UTF-16-реализации).
• Другие указывают на полезные кейсы C0-символов (EOF, ESC, разделители) и опасаются, что «закрыть и забыть» приведёт к 20-летней несовместимости (эмодзи, старые файлы).
• Ссылаются на RFC 8264/9839 и PRECIS-фреймворк как готовый список «что разрешать», но подчёркивают: правило должно быть явным, а не «тихо удалять».

TCP: увеличить initcwnd снова

Google в 2011 г. подняли начальное окно TCP (initcwnd) с 1 до 10 пакетов; RFC 6928 сделало это стандартом. Сегодня, при среднем размере страницы ~2 МБ и RTT 30–100 мс, 10 пакетов (~14 КБ) всё ещё тормозит старт.

Почему расти

• 75 % HTTP-ответов ≤ 32 КБ; 10 пакетов передают лишь 40 %.
• У Google, Meta, Akamai уже 32–64 пакета без потерь.
• Современные сети: 100 Гбит, AQM, ECN, BBR — потери редки.

Риски

• Пакет потеряют лишь 0,01 % сессий при initcwnd=30.
• Re-buffering в YouTube снизился на 3 % при 30 пакетах.

Вывод
initcwnd=30–50 пакетов безопасно и ускоряет web на 5–15 %. Пора обновить RFC.

• Участники считают, что статья поверхностна и ошибочна в выводах о TCP initcwnd и BBR.
• QUIC/HTTP-3 всё равно использует алгоритмы управления перегрузкой (CUBIC, BBR); «окна нет» — миф.
• L4S позволяет получать сигналы о перегрузке без потери пакетов, помогая молодым соединениям.
• Увеличение initcwnd может лишь временно скрыть «раздутый» фронтенд-код, пока бизнес не пострадает.
• BBR и другие алгоритмы плохо переносят высокую джиттерность RTT в беспроводных сетях.
• Bufferbloat всё ещё актуален (особенно на мобильных и Wi-Fi), несмотря на улучшения в кабеле/волокне.