🔌 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

⭐️Анонс проектирования файлового хранилища

Состоялась серия System Design Interview с коллегами, посвященная проектированию сервисов-аналогов dropbox/google drive.

Как и в случае с youtube такой массовый заход на одну задачу позволит лучше погрузиться в её тематику.
Благодаря изучению набора становится понятней, что:
1️⃣ Идеального решения не существует;
2️⃣ Каждый интервьюер расставляет свои акценты;
3️⃣ Интервьюер не обязательно знает больше твоего и других интервьюеров :)

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

✅ Такое массовое изучение одной темы увеличивает шансы на успешное прохождение.
▶️ Совсем скоро будет выложен первый разбор. Тот самый 1ый стрим с Максимом :) Стараюсь дополнить само решение комментариями так чтобы в добавок к основной нити, что вёл кандидат(и у него это отлично получилось!) выстроить ещё один обучающий слой в виде заметок, пожеланий.

😊 А какая задача из System Design Вам нравится больше всего?

#Interview #Pack

📦 Файловое хранилище спроектировано. Полюбуйтесь!

✴️ Чёткое проектирование по шагам. Кандидат видел основную линию дизайна. Делал отсылки к дополнительному функционалу. Один из которых - построение аналитическое подсистемы - в конце и реализовал.

🎟 Из фишек самого видео - вставлены визуальные памятки наступления очередных этапов. Добавлены заметки на полях в качестве дополнительного обучающего слоя чтобы польза от просмотра видео для Вас была максимальной.

😊 Приятного и полезного просмотра!

❓ Как считаете, реализация какой части функциональных требований оказалось самой сложной?

https://youtu.be/t4akRxFCAHc

#Interview

📣 Архитектурная ката на финишной прямой!

🎢 Собираемся в команды и поехали 23.06.2024 в 15:00!

🧾 План мероприятия:
1) Общая встреча участников и организаторов. Знакомство. Распределение по командам.
2) Презентация задачи.
3) Q/A секция - уточняющие вопросы от команд, ответы.
4) Проектирование.
5) Презентация решений.

Регистрация заканчивается с наступлением 20.06.2024.

🎬 Для тех, кто не сможет принять участие - запись планируется.

И, всё-же, в онлайн гораздо круче) Поэтому ждём участников любого уровня. Главное, чтобы с горящими глазами🤩

✍️ Отмечайся в чате System_Design_Chat. Вначале ответь боту кто ты.
Затем:
1) Хочу участвовать в Архитектурной Кате 23.06.2024
2) Готов быть лидером команды

👍 - ставь палец, если идея нравится)

#ArchitecturalKata

⭐️ Стартовал архитектурный хакатон ARCHI.Tech от ВТБ

🎓 Вчера состоялся митап-открытие. На нём организаторы описали ожидаемый результат от решения будущей основной задачи, которую предоставят 28.06.24.
Также показали своё решение демо задачи. И разминочную задачу, за которую можно получить дополнительные 3 балла.

📝 Мы сразу же собрались командой и создали скелет решения.
Старались освятить все пункты ожидаемого результата:
1) Функциональная структура
2) Архитектура данных
3) Архитектура системы
4) API взаимодействия с пользователем
5) API взаимодействия компонентов
6) Архитектура развёртывания

⚙️ Причесать решения нужно успеть до 28.06. До этого числа можно и зарегистрироваться.

❓ А ты участвовал в хакатонах? Как считаешь, какая от них польза?

⚡️ Если задача интересна и хочешь увидеть её разбор, ставь лайк, соберёмся после хакатона.

#Hackathon

🧩 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

Протокол 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

Да начнётся Saint Highload++ 2024!

💪 Высокие нагрузки - это про нас!

📆 Закончилась 2ух дневная конференция по высоконагруженным отказоустойчивым распределенным системам Saint HighLoad++. На которой мне посчастливилось побывать 😊

🔆 На канале мы проводим System Design Interview по таким системам. Сделали уже 1ую архитектурную кату. Публикуем посты по этой тематике. Пора выполнить обещание и описать прохождение этой релевантной для канала конференции.

✏️ Сделал это в форме habr статьи.

▶️ Приятного чтения :)

❓ Как часто посещаете конференции и зачем?

#Articles

Продолжение постов об эволюции 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

🎗 Как мы попали в финал Архитектурного Хакатона от ВТБ

▶️ О Хакатоне мне сообщила Нина. Желание поучаствовать материализовалось в клике мышкой на слове "Регистрация" буквально сразу же.

🆒 На площадке была возможность собрать команду из участников. Хотя, можно выполнять задания одному. После создания команды "System_Design_World" разослал приглашения.

🌠 Команда
Хакатон мы также обсуждали сообществом в чате канала. На ранних этапах команде помогал Игорь, Саша. Позже Светлана.
Core командой стали:
1) Я - Владимир, бэк
2) Элеонора, которая приняла приглашение на платформе. Крутой аналитик.
3) Сулейман, с которым знакомы уже давно. Крутой бэк, архитектор.

💪 Разминочное задание - 2/3
За сделанное необязательное разминочное задание нам дали увесистые 2 балла из 3ёх возможных. Мы обсудили что можно улучшить на финальном задание.
Казалось бы, 1 недостающий до идеала балл - это не так уж и много. С другой стороны - это не полученные 33% от лучшего результата 🤔

🕧 Ready?...
18:00, вечер пятницы. Старт 24 часового таймера для решения финальной задачи!
Когда-нибудь проектировал систему за 24 часа?

По текущему рейтингу мы знали, что немало команд выполнило разминочное задание. Получается, что есть команды, нацеленные на успех. Плюс, могут подтянуться "тёмные лошадки", - кто копил силу для финала.
Мы асинхронно накидали на общую доску базовые элементы. А их нужно не мало, т.к. задача оценивается по многим параметрам.
Утром встретились на 2 часа. Затем асинхронно доделывали. На разборе разминочной задачи мы поняли, что необходимо улучшиться в визуальном представление сделанной работы. Что получилось сделать на этот раз. Мы пыхтели до последнего. И в 17:57 выгрузили итоговую презентацию на платформу.

🎁 Важнее - участие. Или нет?
Я шёл на Хакатон ради участия, практики. Хотя, предполагались и денежные призы для 9ых финалистов☝️
Кажется, что это приятный бонус, если дошёл до призового места. Он не был моей целью. Какая же была неожиданность, когда ко мне на следующий день(в воскресенье) постучался представитель Хакатона и позвал на 5 минутный питч для финалистов 😎

5️⃣ Успеть за 5 минут
Думаю, что за этот тайминг получилось рассказать максимум про все основные компоненты, сценарии использования созданной системы. А после ответить на интересующие вопросы.
Самым последним из них был: "Назовите сильные и слабые стороны Вашего решения?". Интуитивно понял, что нужно начинать со слабой(один из кейсов мы как-раз обсудили - что сделаем сейчас для быстрого старта и что потом можем улучшить), а закончить описанием сильных сторон.

🎇 Итог
Конкуренция была мощной. Мы заняли 15 место среди 90 команд. До 9ых призёров нам не хватило какого-то балла :) Торжественное награждение состоялось в этот же день после презентации решений финалистов. Какую грандиозную работу по оценки решений в короткий срок проделали коллеги-организаторы!

💡 Позднее на "After Party" мы поздравляли призёров, смотрели решения друг друга. И это круто - чувствовать открытость людей IT сообщества идти навстречу друг другу, показывать свои решения, обогащаться знаниями! 😊

🔜 В будущем опубликую интервью с членами-команды System_Design_World об их профессиональном опыте, мотивации, впечатлениях от прошедшего мероприятия.

❓ А Вы участвовали в Хакатонах? Какую пользу от них видите для себя?