Вот уже больше 20 лет мы открываем веб-страницы по протоколу HTTP.
Большинство пользователей никогда не задумывалось, что это такое и как оно работает. Другие знают, что где-то под HTTP есть TLS, под ним TCP, под которым IP и т. д.
А третьи – считают, что TCP – прошлый век, им хочется чего-то более быстрого, надёжного и защищённого.
В попытках изобрести идеальный протокол мы вернулись к технологиям 80-х годов и пытаемся построить на них свой дивный новый мир.
Давайте начнем погружение в тему с вопроса: зачем frontend разработчику нужно понимание сетевого взаимодействия?
При проведении технических интервью у большинства кандидатов на должность frontend-разработчика можно заметить совсем поверхностное понимание сетевого взаимодействия. Кроме того, мне не приходилось сталкиваться с вопросами по этой теме на интервью в других компаниях.
Однако направление сетевого взаимодействия очень интересно и важно. Ведь каждый день, взаимодействуя с различными сайтами и сервисами, мы передаем по сети огромное количество информации. И при этом не всегда понимаем всю схему этого процесса.
Кроме того, именно фронтенд-разработчики наиболее тесно связаны с данной тематикой.
Рассмотрим автоматизированный инструмент Google Lighthouse. Если вы фронтенд-разработчик, то наверняка хотя бы поверхностно знакомы с ним.
Данный инструмент проводит аудит качества веб-страниц, а затем создает отчет, в котором акцентирует внимание на пяти метриках:
Неудачные результаты отчета помогают найти проблемы в обслуживании сетевых ресурсов, исправление которых может положительно повлиять на производительность нашего сайта.
Интересующее нас сетевое взаимодействие относится к метрике Performance.
Сюда же можно отнести метрику производительности «Time to first byte» (TTFB), в которую входят такие аспекты, как:
Раньше показатель «Time to first byte» считался одним из основных, отслеживаемых в Google Lighthouse. В более поздних версиях он представлен как аудит под названием «Reduce initial server response time».
В показатель TTFB входит как время запроса, идущего от клиента к серверу, так и время, которое занимает путь ответа сервера клиенту (так называемое «время приёма-передачи» (Round Trip Time, RTT)).
Понятно, что TTFB в 0 мс — это несбыточная мечта. Хорошим показателем считается 200-250 мс, при таком значении пользователь чувствует молниеносную отзывчивость сайта, что положительно сказывается на UX. Если TTFB на вашем сайте больше 500 мс, стоит всерьез задуматься о сокращении этого показателя.
Одним из вариантов получить необходимую нам оптимизацию производительности сайта — уменьшить время на передачу ресурсов, т. е. улучшить серверное и сетевое взаимодействие.
Десятилетия веб развивался в этом направлении. В итоге, значительную роль в улучшении глобальной сети сыграло развитие протокола HTTP и технологий, связанных с ним.
Тернист и долог путь в HTTP/3, поэтому мной было принято решение опубликовать серию статей по истории сети, ключевым аспектом которой является развитие сетевого взаимодействия, начиная от первых моделей интернета и заканчивая современными реалиями.
В серию статей войдут темы:
Предлагаю вместе со мной с головой окунуться в модель OSI и стек протоколов TCP/IP, чтобы понять, как устроен процесс передачи данных в сети. Рассмотреть протоколы TCP/UDP, понять их особенности и отличия. Изучить историю развития HTTP, а также рассмотреть некоторые его модификации.
Данная серия выпущена по материалам доклада Павел Ефимов — Как мы докатились до HTTP/3. Огромное спасибо Паше, что поделился всеми своими наработками по данной теме.
P. S. Данный материал направлен больше на фронтенд-разработчиков, т. к. именно фронтендеры непосредственно сталкиваются с этим в своей работе. Но другим направлениям разработки эти темы также будет крайне полезны и познавательны.
Возможно, захочется почитать и это:
Большинство пользователей никогда не задумывалось, что это такое и как оно работает. Другие знают, что где-то под HTTP есть TLS, под ним TCP, под которым IP и т. д.
А третьи – считают, что TCP – прошлый век, им хочется чего-то более быстрого, надёжного и защищённого.
В попытках изобрести идеальный протокол мы вернулись к технологиям 80-х годов и пытаемся построить на них свой дивный новый мир.
❯ Зачем нужно понимание сетевого взаимодействия?
Давайте начнем погружение в тему с вопроса: зачем frontend разработчику нужно понимание сетевого взаимодействия?
При проведении технических интервью у большинства кандидатов на должность frontend-разработчика можно заметить совсем поверхностное понимание сетевого взаимодействия. Кроме того, мне не приходилось сталкиваться с вопросами по этой теме на интервью в других компаниях.
Однако направление сетевого взаимодействия очень интересно и важно. Ведь каждый день, взаимодействуя с различными сайтами и сервисами, мы передаем по сети огромное количество информации. И при этом не всегда понимаем всю схему этого процесса.
Кроме того, именно фронтенд-разработчики наиболее тесно связаны с данной тематикой.
❯ Google Lighthouse и показатель Time to first byte
Рассмотрим автоматизированный инструмент Google Lighthouse. Если вы фронтенд-разработчик, то наверняка хотя бы поверхностно знакомы с ним.
Данный инструмент проводит аудит качества веб-страниц, а затем создает отчет, в котором акцентирует внимание на пяти метриках:
- Performance — производительность
- Accessibility — доступность
- Best Practices — лучшие практики
- SEO — поисковая оптимизация
- Progressive Web App — прогрессивные web-приложения
Неудачные результаты отчета помогают найти проблемы в обслуживании сетевых ресурсов, исправление которых может положительно повлиять на производительность нашего сайта.
Интересующее нас сетевое взаимодействие относится к метрике Performance.
Сюда же можно отнести метрику производительности «Time to first byte» (TTFB), в которую входят такие аспекты, как:
- DNS-поиск;
- Соединение и согласование TLS4;
- Обработка запроса на сервере;
- Задержки сети и RTT.
Раньше показатель «Time to first byte» считался одним из основных, отслеживаемых в Google Lighthouse. В более поздних версиях он представлен как аудит под названием «Reduce initial server response time».
В показатель TTFB входит как время запроса, идущего от клиента к серверу, так и время, которое занимает путь ответа сервера клиенту (так называемое «время приёма-передачи» (Round Trip Time, RTT)).
Понятно, что TTFB в 0 мс — это несбыточная мечта. Хорошим показателем считается 200-250 мс, при таком значении пользователь чувствует молниеносную отзывчивость сайта, что положительно сказывается на UX. Если TTFB на вашем сайте больше 500 мс, стоит всерьез задуматься о сокращении этого показателя.
Одним из вариантов получить необходимую нам оптимизацию производительности сайта — уменьшить время на передачу ресурсов, т. е. улучшить серверное и сетевое взаимодействие.
❯ Десятилетия улучшений и развития веба
Десятилетия веб развивался в этом направлении. В итоге, значительную роль в улучшении глобальной сети сыграло развитие протокола HTTP и технологий, связанных с ним.
Тернист и долог путь в HTTP/3, поэтому мной было принято решение опубликовать серию статей по истории сети, ключевым аспектом которой является развитие сетевого взаимодействия, начиная от первых моделей интернета и заканчивая современными реалиями.
В серию статей войдут темы:
- Как мы докатились до OSI и TCP/IP;
- Как мы докатились до TCP/UDP;
- Как мы докатились до HTTP(0.9/1.0/1.1);
- Как мы докатились до SPDY, GQUIC, HTTP/2;
- Как мы докатились до HTTP/3 (QUIC).
Предлагаю вместе со мной с головой окунуться в модель OSI и стек протоколов TCP/IP, чтобы понять, как устроен процесс передачи данных в сети. Рассмотреть протоколы TCP/UDP, понять их особенности и отличия. Изучить историю развития HTTP, а также рассмотреть некоторые его модификации.
Данная серия выпущена по материалам доклада Павел Ефимов — Как мы докатились до HTTP/3. Огромное спасибо Паше, что поделился всеми своими наработками по данной теме.
P. S. Данный материал направлен больше на фронтенд-разработчиков, т. к. именно фронтендеры непосредственно сталкиваются с этим в своей работе. Но другим направлениям разработки эти темы также будет крайне полезны и познавательны.
TheRaven
Где статья-то?
JetBlackCodes Автор
Это была вводная статья с обоснованием почему эта тема важна для фронтенд-разработчиков
Чуть позже выложу 5 статей на темы:
Как мы докатились до OSI и TCP/IP;
Как мы докатились до TCP/UDP;
Как мы докатились до HTTP(0.9/1.0/1.1);
Как мы докатились до SPDY, GQUIC, HTTP/2;
Как мы докатились до HTTP/3 (QUIC).
они уже написаны, нужно совсем немного подождать