Hacker News Digest

TCP — невидимый герой интернета, обеспечивающий надежную передачу данных вопреки его ненадежности. В то время как IP-адрес доставляет пакеты на нужный компьютер, TCP через порты направляет их правильным приложениям, как письма в квартиры одного здания. Протокол скрывает от разработчиков хаос сети: потерю, повреждение, дублирование и переупорядочивание пакетов, позволяя приложениям просто работать.

Ключевые механизмы TCP — контроль потока и перегрузки — предотвращают коллапс сети. Контроль потока через буфер приема и "окно" определяет, сколько данных может обработать получатель. Контроль перегрузки избегает повторной отправки потерянных пакетов, усугубляющих congestion collapse. В 1986 году интернет замедлился до 40 бит/с из-за этой проблемы. TCP с механизмами "back off" спасает сеть от саморазрушения, позволяя нам наслаждаться стабильным соединением.

• TCP считается оптимальным решением для надежного потока данных над ненадежным дейтаграммным уровнем, но имеет ограничения: маленькое окно для современных скоростей и проблемы с безопасностью.
• Альтернативы (SCTP, QUIC, RUDP) обсуждаются как решения для мультиплексирования потоков и улучшения производительности, но сталкиваются с проблемами поддержки и сложности.
• Технически возможно создание собственных протоколов поверх IP, но маршрутизаторы и NAT часто требуют TCP/UDP или блокируют другие протоколы.
• Простота TCP объясняется ограничениями старых компьютеров, а управление перегрузкой тогда было неочевидным решением.
• HTTP/3 (QUIC) набирает популярность как замена TCP для веба, но его сложность вызывает опасения.

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), несмотря на улучшения в кабеле/волокне.