This media is not supported in your browser
VIEW IN TELEGRAM
🔌 TCP соединение для System Design. Как всё начинается и почему так дорого?
🚚 TCP является протоколом транспортного уровня. В модели OSI располагается на уровне L4. Является базой для верхнеуровневых протоколов - HTTP, WebSocket, ...
Он обеспечивает в том числе:
✅ Гарантию доставки пакетов
✅ Гарантию сохранения порядка следования пакетов
Для реализации таких гарантий сторонам необходимо договориться о стартовых номерах - sequence number. Для этого придётся сделать 3 пересылки.
Junior level:
1. Клиент выражает своё желание установить соединение для отправки сообщений.
2. Сервер отвечает согласием и желанием отправлять сообщения со своей стороны.
3. Клиент отвечает, что согласие и желание принял.
🤝 Отсюда и возник термин "Трёхкратное рукопожатие".
Middle level:
1. Клиент отсылает пакет с:
• Проставленным флагом SYN(SYNхронизировать стартовый номер)
• Сгенерированным sequence number(client).
2. Сервер отвечает пакетом с:
• Проставленным флагом ACK: "Подтверждаю, что принял"
• Acknowledgment number = sequence number(client) + 1
• Проставленным флагом SYN и своим сгенерированным sequence number(server)
3. Клиент отвечает пакетом с:
• Проставленным флагом ACK
• Acknowledgment number = sequence number(server) + 1
• sequence number(client) + 1
После этого соединение считается установленным.
Senior level
Далее sequence number будут служить для реализации логики подтверждения доставки и упорядочения пакетов в случае, если они пришли не по порядку, потерялись. Число выбирается по определенному алгоритму. Это не полный random и не ноль. Хотя в том же wireshark для удобства рассмотрения первому sequence number присваивается 0 с пометкой "relative".
Итого
В контексте рассмотрения TCP соединения можно выделить:
✅ Преимущество протокола - создание сессии, гарантированная доставка пакетов в ней
❌ Недостаток - относительно "дорогая" процедура создания сессии.
▶️ Как часто на интервью Вас спрашивают про протоколы?
👏 - формат поста с графикой и описанием зашёл полностью
👍 - пост нормальный, больше графики
⚡️- пост нормальный, больше текста
🤔 - есть ещё идеи, напишу в комментариях
#Protocols
🚚 TCP является протоколом транспортного уровня. В модели OSI располагается на уровне L4. Является базой для верхнеуровневых протоколов - HTTP, WebSocket, ...
Он обеспечивает в том числе:
✅ Гарантию доставки пакетов
✅ Гарантию сохранения порядка следования пакетов
Для реализации таких гарантий сторонам необходимо договориться о стартовых номерах - sequence number. Для этого придётся сделать 3 пересылки.
Junior level:
1. Клиент выражает своё желание установить соединение для отправки сообщений.
2. Сервер отвечает согласием и желанием отправлять сообщения со своей стороны.
3. Клиент отвечает, что согласие и желание принял.
🤝 Отсюда и возник термин "Трёхкратное рукопожатие".
Middle level:
1. Клиент отсылает пакет с:
• Проставленным флагом SYN(SYNхронизировать стартовый номер)
• Сгенерированным sequence number(client).
2. Сервер отвечает пакетом с:
• Проставленным флагом ACK: "Подтверждаю, что принял"
• Acknowledgment number = sequence number(client) + 1
• Проставленным флагом SYN и своим сгенерированным sequence number(server)
3. Клиент отвечает пакетом с:
• Проставленным флагом ACK
• Acknowledgment number = sequence number(server) + 1
• sequence number(client) + 1
После этого соединение считается установленным.
Senior level
Далее sequence number будут служить для реализации логики подтверждения доставки и упорядочения пакетов в случае, если они пришли не по порядку, потерялись. Число выбирается по определенному алгоритму. Это не полный random и не ноль. Хотя в том же wireshark для удобства рассмотрения первому sequence number присваивается 0 с пометкой "relative".
Итого
В контексте рассмотрения TCP соединения можно выделить:
✅ Преимущество протокола - создание сессии, гарантированная доставка пакетов в ней
❌ Недостаток - относительно "дорогая" процедура создания сессии.
▶️ Как часто на интервью Вас спрашивают про протоколы?
👏 - формат поста с графикой и описанием зашёл полностью
👍 - пост нормальный, больше графики
⚡️- пост нормальный, больше текста
🤔 - есть ещё идеи, напишу в комментариях
#Protocols
👍22👏14⚡8
YouTube
Чего ожидать от HTTP/3 + Go
Видео трансляции с митапа Московского Клуба Программистов 22 мая 2024 года в Умном городе.
В докладе рассказывается про HTTP/3 в контексте языка Go.
02:15 - Предубеждение 1: HTTP/2 кардинально отличается от HTTP/3
09:20 - Предубеждение 2: HTTP/3 поверх UDP…
В докладе рассказывается про HTTP/3 в контексте языка Go.
02:15 - Предубеждение 1: HTTP/2 кардинально отличается от HTTP/3
09:20 - Предубеждение 2: HTTP/3 поверх UDP…
🧩 HTTP + Нина. Зажигательная комбинация!
😇 Мне посчастливилось улучшить понимание HTTP 2 раза.
1️⃣ Первый - послушал вживую доклад Нина Пакшиной про HTTP3.
Очень ёмко, последовательно и структурировано Нина освятила:
1) Эволюцию HTTP
2) Различие в транспорте 2 и 3 версий HTTP
3) QUIC vs TCP
4) Работу HTTP/3 в Go
Если хочешь улучшить своё понимание работы этого популярного протокола, запись доступна здесь!
2️⃣ Второй - Нина напишет на канале ряд постов про HTTP!😊
💪 Двойная польза
Да-да, реализуется тот самый двойной формат подачи, о чём писал ранее:
1) На канале размещается видео контент;
2) А также полезная информация в формате постов, для тех кому ближе чтение.
👩🏼 Нина - кто ты?
Давайте познакомимся с Ниной ближе - новым автором канала!
Нина, привет! Я знаю тебя как старшую разработчицу Go и активную участницу Московского Клуба Программистов. Ничего не перепутал? 😊
Да, все верно. Когда я присоединилась к Московскому клубу программистов, я программировала ПЛК (контроллеры для автоматизации промышленных объектов) Потом несколько лет писала на Python в онлайн ритейле. И уже три года пишу на Go!
В какой команде ты работаешь, за что отвечаешь?
На своей основной работе в Ленте Онлайн я работаю в команде операций. У меня большой стек задач, который включает сбор статистики, управление персоналом и заказами. В команде мы работаем с большим количеством микросервисов, основная часть из которых написана на Go.
Что больше всего нравится в твоей работе?
Мне нравится, что в нашей команде очень много технически сложных задач, а также современный технологический стек. Одна из моих последних разработок - это проектирование и развитие микросервиса по распределенному сбору информации статистики и расчетов параметров эффективности работы персонала.
На митапе ты сказала, что решила сделать доклад, потому что самой было интересно разобраться как в самом протоколе HTTP3, так и в его реализации на Go.
Откуда взялось такое желание?
Я работаю в IT области уже больше 13 лет. Работала в области промышленной автоматизации, кибер безопасности, онлайн ритейле. И постоянно моя работа очень тесно была связана с сетями передачи данных, а конкретно с протоколами стека TCP/IP. За развитием QUIC и HTTP/3 я слежу с 2020 года. И считаю, что за ними большое будущее как в ритейле, так и в промышленных сетях.
Стоит ли использовать HTTP/3 в своих проектах и есть ли у него перспектива?
HTTP/3 уже поддерживается почти всеми популярными браузерами и 30% сайтов в интернете работают с HTTP/3.
Вы можете ускорить взаимодействие пользователей с вашим веб-приложением. А как именно - смотрите доклад или ждите постов!
Классно!
Я уже списывался с тобой по поводу идеи по написанию серии постов про HTTP. Давай ещё раз спрошу в рамках этого небольшого интервью - как тебе идея написать несколько постов по HTTP, поделится своим видением протокола, его эволюцией? :)
Это отличная идея, в самом ближайшем посту я расскажу про первые две версии HTTP - 0.9 и 1.0, а в дальнейшем освещу особенности версий 1.1, 2.0 и 3.0.
Желаю тебе удачи! И если участникам сообщества посты заходят, чтобы смело ставили лайки за твои старания!
👏 - поддержим начинание нового автора!
Ссылка на доклад Нины
#Protocols #HTTP
😇 Мне посчастливилось улучшить понимание HTTP 2 раза.
1️⃣ Первый - послушал вживую доклад Нина Пакшиной про HTTP3.
Очень ёмко, последовательно и структурировано Нина освятила:
1) Эволюцию HTTP
2) Различие в транспорте 2 и 3 версий HTTP
3) QUIC vs TCP
4) Работу HTTP/3 в Go
Если хочешь улучшить своё понимание работы этого популярного протокола, запись доступна здесь!
2️⃣ Второй - Нина напишет на канале ряд постов про HTTP!😊
💪 Двойная польза
Да-да, реализуется тот самый двойной формат подачи, о чём писал ранее:
1) На канале размещается видео контент;
2) А также полезная информация в формате постов, для тех кому ближе чтение.
👩🏼 Нина - кто ты?
Давайте познакомимся с Ниной ближе - новым автором канала!
Нина, привет! Я знаю тебя как старшую разработчицу Go и активную участницу Московского Клуба Программистов. Ничего не перепутал? 😊
Да, все верно. Когда я присоединилась к Московскому клубу программистов, я программировала ПЛК (контроллеры для автоматизации промышленных объектов) Потом несколько лет писала на Python в онлайн ритейле. И уже три года пишу на Go!
В какой команде ты работаешь, за что отвечаешь?
На своей основной работе в Ленте Онлайн я работаю в команде операций. У меня большой стек задач, который включает сбор статистики, управление персоналом и заказами. В команде мы работаем с большим количеством микросервисов, основная часть из которых написана на Go.
Что больше всего нравится в твоей работе?
Мне нравится, что в нашей команде очень много технически сложных задач, а также современный технологический стек. Одна из моих последних разработок - это проектирование и развитие микросервиса по распределенному сбору информации статистики и расчетов параметров эффективности работы персонала.
На митапе ты сказала, что решила сделать доклад, потому что самой было интересно разобраться как в самом протоколе HTTP3, так и в его реализации на Go.
Откуда взялось такое желание?
Я работаю в IT области уже больше 13 лет. Работала в области промышленной автоматизации, кибер безопасности, онлайн ритейле. И постоянно моя работа очень тесно была связана с сетями передачи данных, а конкретно с протоколами стека TCP/IP. За развитием QUIC и HTTP/3 я слежу с 2020 года. И считаю, что за ними большое будущее как в ритейле, так и в промышленных сетях.
Стоит ли использовать HTTP/3 в своих проектах и есть ли у него перспектива?
HTTP/3 уже поддерживается почти всеми популярными браузерами и 30% сайтов в интернете работают с HTTP/3.
Вы можете ускорить взаимодействие пользователей с вашим веб-приложением. А как именно - смотрите доклад или ждите постов!
Классно!
Я уже списывался с тобой по поводу идеи по написанию серии постов про HTTP. Давай ещё раз спрошу в рамках этого небольшого интервью - как тебе идея написать несколько постов по HTTP, поделится своим видением протокола, его эволюцией? :)
Это отличная идея, в самом ближайшем посту я расскажу про первые две версии HTTP - 0.9 и 1.0, а в дальнейшем освещу особенности версий 1.1, 2.0 и 3.0.
Желаю тебе удачи! И если участникам сообщества посты заходят, чтобы смело ставили лайки за твои старания!
👏 - поддержим начинание нового автора!
Ссылка на доклад Нины
#Protocols #HTTP
🔥14👏9❤1
HTTP
Протокол HTTP (HyperText Transfer Protocol, Протокол передачи гипертекста) был опубликован в 1991 году как часть экосистемы для обмена гипертекстовыми файлами HTML, которая позже получила название WWW (World Wide Web).
HTTP — это простой протокол, главной задачей которого стала отправка с сервера клиенту документов HTML в текстовом представлении. В качестве транспортного уровня HTTP стал использовать надежный протокол TCP поверх IP.
HTTP/0.9
Самая первая версия HTTP, которая впоследствии стала называться HTTP/0.9, была очень простой и поддерживала следующий функционал:
1️⃣ Запрос от клиента с методом GET
2️⃣ Ответ с сервера с HTML данными:
HTTP/1.0
Сеть WWW начала развиваться очень активно. В конце 1994 года в WWW насчитывалось около 2,7 тысяч сайтов, а в 1996 году — уже более 100 тысяч!
При этом HTTP/0.9 был крайне ограничен в своих возможностях, поэтому в 1996 году появился стандарт HTTP/1.0 с дополненным функционалом:
1️⃣ Новые методы HEAD (получение метаданных о документе) и POST (отправка данных на сервер).
2️⃣ Поле версии протокола, которое отправлялось при каждом запросе с клиента.
3️⃣ Заголовки для запросов и ответов, отображающие дополнительные метаданные:
4️⃣ Поддержка отправки сервером документов, отличных от HTML, с помощью заголовка Content-Type.
5️⃣ Коды статусов ответов, например, 200 (Статус OK) или 418 (Я чайник):
Несмотря на серьезную доработку протокола, веб-страницы в WWW становились более сложными, насыщенными графикой, мультимедиа и интерактивными элементами. HTTP/1.0 не справлялся с возросшими требованиями, что приводило к значительным задержкам и нагрузке на серверы.
ℹ️ Именно поэтому, появилась новая версия HTTP/1.1, но о ней мы расскажем в следующем посте.
(На изображении справа первый веб-сайт в WWW)
#Protocols #HTTP
Протокол HTTP (HyperText Transfer Protocol, Протокол передачи гипертекста) был опубликован в 1991 году как часть экосистемы для обмена гипертекстовыми файлами HTML, которая позже получила название WWW (World Wide Web).
HTTP — это простой протокол, главной задачей которого стала отправка с сервера клиенту документов HTML в текстовом представлении. В качестве транспортного уровня HTTP стал использовать надежный протокол TCP поверх IP.
HTTP/0.9
Самая первая версия HTTP, которая впоследствии стала называться HTTP/0.9, была очень простой и поддерживала следующий функционал:
1️⃣ Запрос от клиента с методом GET
GET /page.html
2️⃣ Ответ с сервера с HTML данными:
<html>
Hello world!
</html>
HTTP/1.0
Сеть WWW начала развиваться очень активно. В конце 1994 года в WWW насчитывалось около 2,7 тысяч сайтов, а в 1996 году — уже более 100 тысяч!
При этом HTTP/0.9 был крайне ограничен в своих возможностях, поэтому в 1996 году появился стандарт HTTP/1.0 с дополненным функционалом:
1️⃣ Новые методы HEAD (получение метаданных о документе) и POST (отправка данных на сервер).
2️⃣ Поле версии протокола, которое отправлялось при каждом запросе с клиента.
3️⃣ Заголовки для запросов и ответов, отображающие дополнительные метаданные:
POST /image.gif HTTP/1.0
User-Agent: Windows 3.1
4️⃣ Поддержка отправки сервером документов, отличных от HTML, с помощью заголовка Content-Type.
5️⃣ Коды статусов ответов, например, 200 (Статус OK) или 418 (Я чайник):
200 OK
Date: Wed, 16, Nov 1994 10:12:34 GMT
Content-Type: text/gif
(image gif)
Несмотря на серьезную доработку протокола, веб-страницы в WWW становились более сложными, насыщенными графикой, мультимедиа и интерактивными элементами. HTTP/1.0 не справлялся с возросшими требованиями, что приводило к значительным задержкам и нагрузке на серверы.
ℹ️ Именно поэтому, появилась новая версия HTTP/1.1, но о ней мы расскажем в следующем посте.
(На изображении справа первый веб-сайт в WWW)
#Protocols #HTTP
🔥12👍4❤1⚡1
Продолжение постов об эволюции HTTP
HTTP/1.1
Новая версия HTTP/1.1 была впервые опубликована в 1997 году в RFC 2068, а в 1999 году стандартизирована в рамках RFC 2616.
HTTP/1.1 собрал в себе много важных доработок:
1️⃣ Новые методы: PUT (создание или обновление ресурса), DELETE (удаление), OPTIONS (параметры соединения), TRACE (трассировка запроса), CONNECT (установка туннеля к серверу), PATCH (частичное обновление, добавлен позже в 2010 году в RFC 5789).
Например, запрос:
2️⃣ Виртуальные хосты: до этого на одном IP-адресе мог располагаться только один веб-сайт. Обязательный заголовок Host позволяет использовать несколько веб-сайтов с одним IP-адресом:
3️⃣ Постоянные соединения (persistent connections): клиент и сервер HTTP/1.1 по умолчанию поддерживают постоянное соединение (с помощью keep-alive TCP/IP). Каждый новый запрос отправляется через это установленное соединение, что экономит время и ресурсы для каждого запроса.
4️⃣ Множество соединений (simultaneous connections): клиенты могут открывать несколько TCP-соединений к одному серверу, что позволяет параллельно загружать ресурсы и уменьшает время загрузки веб-страниц. В современных браузерах обычно используется до 6 соединений на один сайт.
5️⃣ Передача данных частями (chunked transfer encoding): HTTP/1.1 позволяет отправлять ответы частями, что особенно полезно для динамически генерируемого контента. Например, ответ отправляемый частями:
6️⃣ Конвейерная обработка (pipelining): клиент может передавать на сервер несколько запросов, не ожидая ответов. В ожидании получения дополнительных запросов сервер поддерживает соединение открытым в течение настраиваемого интервала (обычно 15 секунд). Это позволяет уменьшить накладные расходы на установление TCP-соединения.
При всех своих нововведениях HTTP/1.1 имел следующие недостатки:
1️⃣ Ограниченная производительность за счет того, что все запросы в рамках одного соединения выполнялись последовательно. Большое количество запросов в одном соединении создает очередь из запросов (request queuing), увеличивая время обработки запроса.
2️⃣ Количество одновременных соединений ограничивалось браузерами, что замедляло работу. При этом множество открытых соединений потребляло много ресурсов.
3️⃣ Head-of-line блокировка, которая возникает, когда задержка в обработке запроса/ответа блокирует обработку последующих запросов/ответов, использующих то же соединение. Такая блокировка возникает, если количество допустимых параллельных запросов в браузере исчерпано, и последующие запросы должны ждать завершения предыдущих.
4️⃣ Запросы имели огромное количество заголовков, которые дублировали друг друга и не сжимались, генерируя большое количество передаваемых данных и снижая производительность.
ℹ️ Эти недостатки были решены в версии HTTP/2.0, о которой мы расскажем в следующий раз!
❔А какие методы HTTP вы используете в своей работе?
Автор: Нина Пакшина
Нина создала свой youtube канал, где выкладывает видео, посвященное языку Go. Подписывайтесь, если актуально.
#Protocols #HTTP
HTTP/1.1
Новая версия HTTP/1.1 была впервые опубликована в 1997 году в RFC 2068, а в 1999 году стандартизирована в рамках RFC 2616.
HTTP/1.1 собрал в себе много важных доработок:
1️⃣ Новые методы: PUT (создание или обновление ресурса), DELETE (удаление), OPTIONS (параметры соединения), TRACE (трассировка запроса), CONNECT (установка туннеля к серверу), PATCH (частичное обновление, добавлен позже в 2010 году в RFC 5789).
Например, запрос:
TRACE /page HTTP/1.1
Host: example.com
Ответ:
HTTP/1.1 200 OK
Content-Type: message/http
TRACE /page HTTP/1.1
Host: example.com
2️⃣ Виртуальные хосты: до этого на одном IP-адресе мог располагаться только один веб-сайт. Обязательный заголовок Host позволяет использовать несколько веб-сайтов с одним IP-адресом:
POST /path HTTP/1.1
Host: example.com
3️⃣ Постоянные соединения (persistent connections): клиент и сервер HTTP/1.1 по умолчанию поддерживают постоянное соединение (с помощью keep-alive TCP/IP). Каждый новый запрос отправляется через это установленное соединение, что экономит время и ресурсы для каждого запроса.
4️⃣ Множество соединений (simultaneous connections): клиенты могут открывать несколько TCP-соединений к одному серверу, что позволяет параллельно загружать ресурсы и уменьшает время загрузки веб-страниц. В современных браузерах обычно используется до 6 соединений на один сайт.
5️⃣ Передача данных частями (chunked transfer encoding): HTTP/1.1 позволяет отправлять ответы частями, что особенно полезно для динамически генерируемого контента. Например, ответ отправляемый частями:
HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked
4
Test
7
Message
0
6️⃣ Конвейерная обработка (pipelining): клиент может передавать на сервер несколько запросов, не ожидая ответов. В ожидании получения дополнительных запросов сервер поддерживает соединение открытым в течение настраиваемого интервала (обычно 15 секунд). Это позволяет уменьшить накладные расходы на установление TCP-соединения.
При всех своих нововведениях HTTP/1.1 имел следующие недостатки:
1️⃣ Ограниченная производительность за счет того, что все запросы в рамках одного соединения выполнялись последовательно. Большое количество запросов в одном соединении создает очередь из запросов (request queuing), увеличивая время обработки запроса.
2️⃣ Количество одновременных соединений ограничивалось браузерами, что замедляло работу. При этом множество открытых соединений потребляло много ресурсов.
3️⃣ Head-of-line блокировка, которая возникает, когда задержка в обработке запроса/ответа блокирует обработку последующих запросов/ответов, использующих то же соединение. Такая блокировка возникает, если количество допустимых параллельных запросов в браузере исчерпано, и последующие запросы должны ждать завершения предыдущих.
4️⃣ Запросы имели огромное количество заголовков, которые дублировали друг друга и не сжимались, генерируя большое количество передаваемых данных и снижая производительность.
ℹ️ Эти недостатки были решены в версии HTTP/2.0, о которой мы расскажем в следующий раз!
❔А какие методы HTTP вы используете в своей работе?
Автор: Нина Пакшина
Нина создала свой youtube канал, где выкладывает видео, посвященное языку Go. Подписывайтесь, если актуально.
#Protocols #HTTP
🔥7💯2