Для ускорения установки соединения с доменами, на которых находятся загружаемые ресурсы, используют хинты dns-prefetch и preconnect. Дэниэл Александерсен рассказал как их правильно использовать в статье "What to <link rel=dns-prefetch> and when to use preconnect".

Самая распространённая ошибка при использовании dns-prefetch — добавление доменов, ссылки на которые уже есть в html-документе. В этом нет особого смысла, так как браузер будет устанавливать соединение во время парсинга документа. Наибольшую выгоду от использования dns-prefetch можно получить, если домен неизвестен на момент парсинга документа, например, когда установка соединения с новым доменом происходит при выполнении загруженного кода. Другой хинт — preconnect — не только резолвит доменное имя, но и устанавливает TCP-соединение. Это может быть очень полезно на мобильных устройствах.

Если хотите узнать больше подробностей про использование dns-prefetch и preconnect, рекомендую почитать статью.

P.S. Передаю спасибо @oleg_log за ссылку.

#net #performance

https://www.ctrl.blog/entry/dns-prefetch-preconnect.html

Лоит Бэллад из Cloudflare написал статью про то, как они тестируют разрабатываемые протоколы — "How to develop a practical transport protocol".

На данный момент Cloudflare участвует в разработке QUIC и HTTP/3. Отладка сетевого стека — нетривиальная задача, особенно, если речь идёт об отладке на реальных мобильных устройствах. В самом простом случае разрабатывать протокол можно на одном компьютере, используя сеть из docker-контейнеров. Но такой подход не может выявить проблемы, которые могут возникнуть в реальном мире. Поэтому для полноценного тестирования создаются специальные "лаборатории" — выделенные машины, соединённые между собой в сеть. Для эмуляции edge, 3g, lte используется netem (на Linux) и ipfw + dummynet (на FreeBSD). Меня немного позабавило, что ребята взламывают девайсы на iOS, для того, чтобы понять, как будут работать новые протоколы на реальном железе от Apple.

В общем, статья интересная. Рекомендую почитать, если хотите узнать, как разрабатываются протоколы.

#http #debug #net

https://calendar.perfplanet.com/2019/how-to-develop-a-practical-transport-protocol/

Джеймс Снелл из команды разработки ядра Node.js написал статью про текущий статус поддержки QUIC в ноде — "A QUIC Update for Node.js".

QUIC — это транспортный протокол, который лежит в основе HTTP/3. Он решает проблему плохой утилизации канала связи в сетях с высокими задержками, ускоряет установку соединения между клиентом и сервером и решает другие проблемы. На данный момент в отдельном репозитории организации Node.js полным ходом идёт его внедрение.

Для работы с новым протоколом используется новый модуль quic; будет ли он доступен разработчикам в будущем, пока окончательно не решено. Этот модуль экспортирует одну функцию createServer, с помощью которой создаются как инстанс сервера, так и клиент. Под капотом используется библиотека ngtcp2, разрабатывающаяся рабочей группой, работающей над спецификацией QUIC.

Экспериментальная поддержка QUIC, доступная всем разработчикам, должна появиться в Node.js v14. Добавление полноценной поддержки протокола запланировано в Node.js v15.

#protocol #nodejs #net

https://www.nearform.com/blog/a-quic-update-for-node-js/
https://xn--r1a.website/defront/268

Томас Штейнер в блоге web.dev написал статью про новое экспериментальное API — "WebSocketStream: integrating streams with the WebSocket API".

WebSocketStream в отличие от стандартного WebSocket API может ограничить поток входящих и исходящих сообщений в зависимости от текущей нагрузки (backpressure). Это особенно полезно для приложений, которые передают много траффика: видеоконференции, шаринг рабочего стала и т.п. В текущей версии WebSocket API реализовать backpressure для входящих сообщений невозможно, для исходящих сообщений — возможно, но только постоянно опрашивая WebSocket.bufferedAmount, что неэффективно и неэргономично.

WebSocketStream доступен только в Chrome. От команд Firefox и Safari пока не было сигналов о добавлении этой фичи.

#net #experimental

https://web.dev/websocketstream/

Роберто Витилло опубликовал в своём блоге статью про TCP — "What every developer should know about TCP".

Есть распространённое ошибочное предположение, что при отправке данных с помощью TCP пропускная способность канала связи не зависит от времени задержки. В статье объясняется, почему это не так.

При установке соединения сетевой стек операционной системы ищет наиболее подходящее количество пакетов (congestion window), которое можно отправить за один round-trip и которое не зафлудит канал получателя. Время доставки такой порции данных определяется с помощью round-trip time (RTT). Теоретическая максимальная пропускная способность зависит от этих двух показателей: Bandwidth = WinSize / RTT. Именно по этой причине сервера стараются размещать ближе к своим пользователям.

Статья написана очень понятно, рекомендую почитать всем, кто интересуется темой производительности.

#performance #net

https://robertovitillo.com/what-every-developer-should-know-about-tcp/

Кэти Хэмпениус написала большую статью про сети доставки содержимого — "Content delivery networks (CDNs)".

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

В статье разбираются фичи и протоколы, которые предоставляют современные CDN: TLS 1.3, HTTP/2, HTTP/3, минификация ресурсов, оптимизация изображений и т.п. Есть немного про тюнинг кэширования и возможные проблемы, с которыми можно столкнуться при включении HTTP/2.

Отличная статья. Рекомендую почитать всем, кто интересуется производительностью.

#performance #net

https://web.dev/content-delivery-networks/