Transcription
Привет! Это запись первого созвона моего закрытого сообщества, в котором я выступаю в качестве ментора. Провожу еженедельные созвоны и отвечаю на вопросы. Если тебе нужна помощь в погружении в IT, не хватает общения с такими же начинающими разработчиками и опытного ментора рядом, то переходи по ссылкам в описании. Мы тебя ждём!
Что касается созвонов, я хотел бы сделать упор на созвоны в таком формате, чтобы мы разбирали наиболее частые вопросы на собесах. То есть, очевидно, что полезная инфа здесь будет та, которую вы будете применять на работе. Здесь будет тут очевидно, но лучше сделать упор на том, что часто спрашивают и наиболее частые темы. Элементарно, по списочная база — основа основ. Что для фронтенда, что для бэкенда будет в тот момент, когда пользователь заходит в браузер, вбивает адрес ресурса и нажимает Enter. Эту тему нужно знать всем с определённой степенью глубины. Опять же, степень глубины, в котором вы погружаетесь в вопрос, определяет уровень ваших навыков. Вопрос частый, спрашивают его часто. Ну и, как бы, как по мне, это must have, что должен знать каждый. Поэтому давайте начнём. Значит, поехали! С пользователем мы сегодня пройдём весь путь от того момента, как он зашёл в браузер, и до того момента, как уже что-то получил в нём отобразилось.
Итак, у нас есть пользователь. Ему нужен некий интернет-ресурс. Что может являться ресурсом? Давайте посмотрим. Ресурсом может являться стандартная HTML страничка. То есть, например, вот главная страница Гугла, как здесь. Да. Ресурсом может быть какой-нибудь JSON. То есть, если мы, допустим, в браузер зашли, вбили там GET-запрос в какую-то APIшку нашего бэкенда напрямую, мы можем получить JSON. Он у нас отобразится там в формате строки. XML, JSON — то есть всё, что сервер в целом может отдать строкой, мы можем запросить и отобразить. Дальше файлы, видео. Ну, тут понятно.
Смотрим. Пользователь зашёл. Первое, что он делает — открывает адресную строку и вбивает туда URI ресурса. Что такое URI ресурса? Важно не URL, а URI. Это весь адрес, включая endpoint и GET-параметры. То есть, здесь мы видим GET-параметр `User=Max`. Это именно URI. Что из этого будет URL? Всё, что конца доменного имени. То есть, `google.com` до слыша — это URL.
Давайте посмотрим, из чего у нас состоит наш адрес ресурса или URI. Первое, что мы видим — это протокол. Какие у нас протоколы могут быть в браузере непосредственно? Ну, понятно, HTTP и HTTPS. То есть, протокол передачи гипертекста HTTP обычный, HTTPS — серверный, то есть защищённый с сертификатами. Кроме того, мы можем сюда написать `file` и получить ресурс, который находится на нашем локальном компьютере. То есть, протокол `file`. Пишем двоеточие слэш слэш и дальше адрес на нашем локальном компе. То есть, открыть какой-нибудь PDF-ник мы можем это сделать.
Далее, составная часть — это доменное имя. Доменное имя или хост, как его ещё называют, это человеко-понятное название IP-адреса. То есть, мы знаем, что все компьютеры в интернете, будь то клиенты, серверы, имеют свой уникальный адрес. Ну, как уникальный, либо свой адрес, либо этот IP-адрес провайдера и прочие. То есть, то, что наружу торчит. Но IP-адреса у нас имеют конечный вид. То есть, какой IPv4 — это четыре числа, разделённых точкой, от 0 до 256. IPv6 — вот такая вообще, которая, соответственно, непонятная. Да. Очевидно, что пользователям в сети неудобно этим пользоваться, и нужны человека-понятные названия ресурсов. У нас крутой бренд Яндекс. Нам нужно, чтобы пользователь быстро получил ресурс, доступ к нашему ресурсу по понятному названию. Поэтому мы регистрируем доменное имя.
Дальше, query параметры и адрес ресурса, то есть endpoint. Что в данном случае является endpoint? В данном случае является слэш. То есть, мы запрашиваем ресурс с сервера, который находится по адресу `google.com`, то есть по этому хосту, и запрашиваем то, что он отдаёт нам вот по корневому endpoint, то есть по слэшу. Далее, в URI есть могут быть, точнее, GET-параметры. Это опциональные параметры, с помощью которых мы можем получить какие-нибудь ресурсы с фильтрацией, определить себя как пользователя. В GET-параметрах, ну, это вот в качестве просто примера. Здесь параметр `User=Max`.
Окей, с URI всё. Теперь пройдемся по домену. Что такое домен? А домен состоит из так называемых уровней. Прежде всего, `.com` — это домен первого уровня или доменная зона. То есть, мы регистрируем наш сайт, мы его регистрируем в какой-то доменной зоне. Может быть, `.ru`, `.com`, `.org`. Там миллиард их на самом деле. То есть, пицца, короче, можете гуглить ради интереса, их там огромное количество. Мы регистрируем в одной из доменных зон. Дальше, домен второго уровня — это непосредственно то, что мы регистрируем, когда регистрируем наш сайт. То есть, мы покупаем и регистрируем там на себя, на ИП, на фирму, регистрируем домен второго уровня. То есть, в данном случае это точка Google. Это домен второго уровня. И домен третьего уровня — это опциональная штука, которая может быть, может не быть. Вот здесь, допустим, `www`. `www` — это на самом деле тоже рудимент, это устаревшая штука. Так уже никто не пишет. Сейчас мы все заходим, пишем `google.com`, и вот эти вот `www` не пишем. Э-э, нужна была раньше для того, чтобы просто показать, что данный ресурс принадлежит типа worldwide web, то есть сети интернет. И это домен третьего уровня. Также, ну, очень часто, вот допустим, в корпоративной среде встречается, там, например, `mail.google.com`, не знаю, там `support.google.com`. Всё это домены третьего уровня или субдомены, таким образом их называют.
Так, с этим разобрались. То есть, мы ввели доменное имя. Но мы знаем, для того, чтобы получить по протоколу HTTP или HTTPS данные сервера, то есть ресурсы сервера, нам нужно установить с ним TCP-соединение. А для этого нам нужен IP-шник. Но IP-шник — это здесь нет. Мы ввели `google.com`. Что нам нужно? Сейчас задача нашего браузера из доменного имени вычленить IP-шник. Каким образом это делается? Вообще, здесь вступает роль DNS — система доменных имён. По факту, что она из себя представляет? Систему из большого количества серверов, на которых хранятся доменные записи. Что такое доменная запись? Да, это просто соответствие домена конкретному IP-адресу. В Азии, где-то там, в РФ, может быть, даже типа вот в рамках РФ по областям. Для этого мы используем всегда один домен. То есть, пользователи из разных регионов могут постучаться по этому домену, но данные запросят с другого IP-адреса, допустим, не с того, который у нас там был изначально. Вот. Значит, DNS-сервера хранят себе доменные записи — это соответствие домена и IP-адреса.
Каким образом браузер получает IP-адрес из доменного имени? Сначала он идёт в свой кэш. То есть, если мы уже обращались к этому ресурсу, то IP-адрес, скорее всего, уже сохранён в кэше браузером. Здесь важный момент, который стоит запомнить. С этим могут быть связаны некоторые проблемы. То есть, представьте ситуацию: вы запросили ресурс какого-то адреса с доменным именем, браузер наш туда сходил, успешно получил данные, зашивал IP-адрес. Но команда, допустим, которая разрабатывала этот сервис, взяла и перенесла его нахрен на другой сервак с другим IP-адресом. Ваш браузер зашивал эти данные, и, соответственно, вы с некоторой долей вероятности получите ошибку. Вот. Дальше, если в кэше лежит, соответственно, IP-адрес нашего домена, то мы непосредственно идём уже в наш сервак и получаем данные. То есть, устанавливаем TCP-соединение и получаем данные. Но если IP-адреса нет в кэше, то здесь вступает в игру как раз-таки система DNS-серверов.
Что происходит в общем случае? Наш браузер обращается к системе DNS-серверов, которая состоит, соответственно, вот из такой штуки. В начале у нас стоит DNS resolver. Его задача — ходить в разные DNS-сервера и искать, соответственно, запись, которая содержит `google.com`, то есть искать IP-адрес с этой доменной записью, с этим доменным именем. Что делает в общем случае DNS resolver? Сначала он идёт в корневой DNS-сервер. То есть, справа у нас DNS-сервера. Корневой DNS-сервер смотрит на домен первого уровня, то есть на доменную зону. Видит там `.com`. Говорит: "Ага, у тебя `.com`, значит, иди на DNS-сервер, который обслуживает доменную зону `.com`". DNS resolver принимает этот ответ и идёт на Top Level Domain Server, как раз сервер, который обслуживает `.com`. То есть, тут может быть `.ru` и прочее, неважно. Дальше resolver идёт, соответственно, с запросом сюда. Top Level Domain Server уже находит адрес DNS-сервера, который содержит как раз-таки доменную запись `google.com`. Вот именно с Google. Говорит ему: "Тебе нужно на такой-то сервак". Resolver идёт в DNS-сервер, который содержит уже эту доменную запись. Этот сервер отдаёт ему IP-адрес. Resolver возвращает нам это всё в браузер, и мы уже можем установить TCP-соединение с нашим сервером.
Здесь сразу возникает вопрос: казалось бы, серваков, да, каждый ли раз это всё происходит? Но чаще всего нет, и в большинстве случаев нет. Потому что у нашего провайдера, который даёт нам, собственно говоря, доступ в интернет, также есть на своей стороне DNS-сервера, которые кэшируют всё это дело у себя. То есть, условно, у меня там есть мой провайдер MGTS или кто-то ещё. Скорее всего, `google.com` стопудово будет закаширован. Всю эту цепочку проходить не придётся. Но если у нас какой-то очень редкий ресурс, то, скорее всего, цепочку мы пройдём.
Окей, мы получили. Давайте отметим. Теперь у нас есть IP-адрес нашего, то есть `google.com`, и его IP-адрес. Теперь мы можем установить TCP-соединение непосредственно с сервером и запросить ресурсы. Ресурс какой у нас? Напомню, по URI слэш, да, с GET-параметром `User=Max`. Мы идём в сервер запрашивать ресурсы. У нас был протокол HTTPS, например, да. То есть, если мы по умолчанию в объём какой-то домен, наш браузер подставит туда HTTPS. На серверах используются порты. Порты, по сути, это вот, если представить, что сервер — это дом, то порт — это подъезд. То есть, условно, по 443 порту там стоит ама, не знаю, выкручивает лампочку. Во втором подъезде там по 445 порту суд где-то в углу. Вот. То есть, порт показывает, по факту, расположение программы на нашем сервере. По умолчанию на HTTPS — 443 порт, на HTTP — 80 порт.
Окей, мы заходим. Нас встречает веб-сервер. Задача веб-сервера какая? Во-первых, ну, тут может быть на самом деле миллиард реализаций. Это могут быть балансировщики, стандартные веб-сервера вроде Nginx, но роль у них такая, или App Gateway, например, какой-нибудь там Kentech ещё что-то. О них мы поговорим чуть позже, не пугайтесь сложных названий. Веб-сервер, что делает? Принимает запросы. Во-первых, балансирует между нашими приложениями, а во-вторых, направляет наш запрос туда, куда нужно. Корректный Application Server. Что такое Application Server? Вы пишете, да, в основном здесь все пришли, кто собирается так или иначе тут связать свою жизнь с бэкендом, строить свою карьеру. Вы знаете кучу фреймворков: Flask, там, http, Django, Хирон и прочее. Так вот, Application Server — это фактически и есть наш Flask-сервер, Django-сервер, любой другой. То есть, наше приложение. Их может быть несколько. Задача веб-сервера — направить наш запрос по определённому, ну, в определённое место. То есть, например, на этом порту, в данном случае, у нас крутится Application Server, тут с какой-нибудь Django, да, и наш запрос `google.com` как раз-таки должен прилететь именно сюда. За это отвечает вот этот вот веб-сервер. Вот эта вот часть.
Мы получили запрос на нашем Application Server. У нас на стороне бэкенда их может быть куча. То есть, сейчас задача Application Server собрать, обработать данные, сформировать ответ и отправить ответ. В этом процессе может быть куча-куча подпроцессов. То есть, наш Application Server, вот этот вот, который обрабатывает как раз-таки запрос на `google.com` по слэшу, принял запрос, пошёл вот в этот сервер. Тут, допустим, было Django, а тут, например, FastAPI. Получил отсюда какие-то данные. Этот сервер пошёл сюда. То есть, видим, у нас 8081 порт, во втором — всё это разные приложения. Ну, это на самом деле херовый пример, потому что здесь большая связанность серверов, они общаются синхронно. Но это больше для иллюстрации. Этот сервер принял запрос и пошёл по цепочке получать данные отсюда. Этот сервер отсюда. Этот сервер вообще из внешней какой-то системы получил данные. По цепочке возвращается ответ с необходимыми данными, прилетает всё вот в этот Application Server, с которого всё началось. Дальше запрос либо рендерится HTML, то есть, если мы запросили HTML, либо там формируется какой-то JSON. Сложный. Вот при инициации вот этих всех запросов тут может быть куча огромного количества бизнес-логики с походами в базу данных. То есть, мы видим здесь возле каждого сервера база данных своя нарисована. Куча-куча-куча логики.
Про Application Server мы 100% будем говорить на следующих созвонах, когда будем рассматривать шаблоны проектирования, и там разберём всё подробнее про монолиты, микросервисы и прочее. Но в общем случае задача как раз-таки Application Server'ов, одного или нескольких, собрать данные, которые были запрошены, чтобы отдать корректный ресурс. Как только сервер наш, энд — это фактически наш энд — завершил всё это дело, всю обработку, собрал все данные необходимые, он отдаёт HTTP-response. Что есть важного в HTTP-response? Ну, собственно говоря, сам ресурс — это контент, HTML, там, JSON, неважно что, и статус-код. Из основного, что делают статус-коды? Они фактически определяют поведение клиента при полученных, собственно говоря, статус-кодах. То есть, у нас пришёл 200 OK — значит, сервер корректно обработал запрос, вернул ответ, и всё прошло заебись. Если, например, сервер отдал нам 404 — то запрашиваемый ресурс не найден. Сразу могу сказать, что 404 зачастую отбивается вот на этом этапе. То есть, веб-сервер непосредственно хранит себе там какое-то количество роутинга. То есть, получается, разрешённые endpoint'ы, куда мы можем, куда могут прийти запросы от пользователей, потому что нет смысла загонять наш запрос в Application Server, если такого адреса вообще нет. Я там написал, не знаю, `google.com` и по клавиатуре провёл пальцем. Нет смысла загонять сюда запрос, это невалидный запрос заранее. Поэтому наш веб-сервер может отбить 404 и сказать: "Давай, типа, иди на хуй, дурак". Ресурс переехал на другой адрес — трёхсотые статус-коды. Ну, где я написал 3xx, там может быть 301, 302 и прочее. Может быть, опять же, на уровне веб-сервера, но часто бывает на уровне Application Server. Дальше четырёхсотые статус-коды — ошибка в запросе клиента. Например, вернёмся к нашему URI. Я здесь свёл GET-параметр `User=Max`. Здесь я мог написать `User=123`, а наш сервер делает валидацию, вот именно Application Server делает валидацию GET-параметра User, и он ожидает увидеть там только строку, а мы туда передали число. Он скажет: "Нет, дружище, ты дурак и иди нахер" с четырёхсотым статус-кодом. И наш, соответственно, фронтенд-клиент, браузер, отображает то, что, соответственно, должен по этому ответу от сервера. Если у нас вот здесь херовая архитектура, на большая связанность сервисов, очевидно, что если вот здесь вот на этом сервере, на третьем Application Server, что-то пойдёт не так, произойдёт ошибка обработки данных, то всё упадёт. Ошибка сервера при обработке запроса — это всегда пятисотки. Сервер упал, там, не знаю, закончилась оперативная память на физическом сервере. Вот это наш физический сервер так нарисован. 502 какая-нибудь будет. Важно, всё, что начинается с 5xx — всё ошибка на стороне сервера. Пятисотки нужно минимизировать. То есть, наша задача, как бы, бэкендеров — минимизировать количество пятисоток. Пятисотка равно баг, хуёвое поведение. Вот. Дальше мы сформировали ответ. Всё это проходит обратно через веб-сервер. То есть, он играет такую роль обратного прокси-сервера и, соответственно, отдаём ответ клиенту.
Что хочу сказать по поводу клиентов? То есть, в данном случае, это по факту вот стандартной архитектуры, да. Что можно сказать? Здесь клиентом может быть кто угодно на самом деле. Вы можете не использовать браузер, а использовать, например, терминал, использовать там утилиту `curl`, ввести запрос, и вы уже будете клиентом. По факту, вот эта вся цепочка, скорее всего, для вас будет работать. Наверное, кто-нибудь уже слышал штука для тестирования API. Часто используется тестировщиками. То есть, программка отдельная, которая фактически тоже является клиентом. Она более продвинутая, может туда подкладывать там какие-нибудь сертификаты, всякую херню настраивать и пользоваться ей. Дальше, кто ещё может быть клиентом? Мы здесь посмотрели вот на уровне Application Server'ов, что здесь фактически то взаимодействие не подписал, но давайте будем думать, что это так. Взаимодействие по POST. А взаимодействие по POST — это взаимодействие через протокол HTTP или HTTPS. Поэтому, что мы можем сказать, что вот это приложение является клиентом, а это приложение является сервером.
Так, давайте ещё скажу по поводу того, как отвечать на вопрос на этом собеседовании. Смотрите, как правило, интервьюер что делает? Он спрашивает вас в общем случае: "Типа, ты зашёл в браузер, там ввёл доменное имя, нажал Enter, там, сигнальщика никогда". То есть, например, вы взяли, прогнали по порядочным имени, вот, например, по точнее URI ресурса, по домену, сказали про TCP-соединение, что мы не можем, допустим, по домену получить данные сервера, потому что нам надо установить TCP-коннект, для этого нам нужен IP-адрес. Сказали, что такое доменная запись. Дальше пошли, а вот про кэш браузера сказали, пошли в систему DNS-серверов. Тут вот какая херовая ошибка, которая часто возникает: люди пытаются прогнать свой ответ через весь стек TCP/IP. То есть, говорят на уровне протоколов, что вот здесь происходит. Нахуй не надо. Никогда так не делайте. У вас есть шанс выстрелить себе в колено 100 раз. Если вы все, конечно, уверены, хотите показать большие яйца, там, что у вас Computer Science база охеренная, давайте, но, бля, я бы этого делать не советовал. В большинстве случаев. Вот. То есть, остановились, рассказали в общем серверов, про кэширование на стороне провайдеров можно сказать. Это хорошая вещь. Про проблематику, вот которую я озвучил, тоже можно сказать. Ну, когда мы меняем IP-адрес с кэшированием, имею в виду. Дальше сказали про TCP-соединение. Тут что можно получить сразу в ответку: "Ты такой говоришь: 'В чём, дружище, разница между TCP и UDP?'" И ты такой: "Ой". Что такое? Об этом мы поговорим в других видео, в других созвонах, точнее, разберу подробно, не подробно. Посмотрим по сетевой модели OSI, пройдемся, я думаю, и разберём. Но если коротко, и ну, коротко желательно тут не отвечать, а чуть-чуть поглубже этот момент стоит изучить. Но если коротко, UDP у нас не гарантирует, не даёт гарантии доставки. TCP даёт гарантии доставки. Тут, когда устанавливается соединение с клиентом, там тройное рукопожатие, типа: "Сервер, ты меня слушаешь?" Он тебе говорит: "Да, я тебя слушаю", и начинаете гонять пакеты данных. Вот. Но это стоит посмотреть, это мы ещё потом разберём. Но опять же, не закапывай себя. Говорите то, что в чём уверены на 100%. Не придумывайте лишнего. Про Application Server говорите обязательно. Про промежуточные звенья, то есть про веб-сервер, можете даже не говорить. Про балансировщики, которые могут быть, ну, бля, какую-нибудь общую фразу вкиньте, типа: "Там может быть балансировщик нагрузки, который распределяет наши запросы от пользователей по нескольким там инстансам". Что, но часто встречается веб-сервер, который как раз-таки отвечает, ну, является единой точкой входа по 443 порту и направляет наш запрос в корректный Application Server в соответствии с роутингом. Роутинг показывает, а какому Application Server'у соответствует вот этот вот URI, где он тут, вот этот URI. Вот про Application Server'ы мы поговорим потом, потому что тут говорить не переговорить. Поэтому как-то так. Давайте вопросы закидывайте. Всё ли понятно, что непонятно, разберём. Погнали.
А вопрос по цепочке вот этих серверов в DNS, она получается увеличивает время загрузки сайта, если сайт не находится в кэше провайдера? Да. Ну, как смотри, загрузки сайта с точки зрения того, что пока тебе придёт корректный, ну, срез доменное имя на твой IP-адрес. Но как правило, это всё зашивается серверов. Причём там провайдер уже смотрит какие-то другие DNS-сервера, и наверняка там всё будет зашито с долей вероятности. Ну, фактически, да, но задержка эта минимальна. То есть, вы этого не почувствуете, это точно. Потому что система DNS-серверов общается на достаточно низком уровне там протоколов TCP, поэтому это всё происходит моментально. Основные косты на загрузку вот здесь, то есть скорость вашего интернета плюс работа всей вот этой вот ебаторики с огромным количеством Application Server'ов, запросы херовые в базу данных, что-то ещё. Но как-то так.
Application Server'ы — это получается цепочка или пазл? То есть, они взаимосвязаны, и нельзя пропустить из одного сервера, допустим, пройти сразу во второй или третий? И в данном случае, на самом деле, всё может быть. Вот типа один и всё. То есть, это, ну, либо микросервисы, которые общаются там синхронно или асинхронно. Я говорю, поговорим про Application Server'ы. То есть, Application Server, опять же, я говорю, это ваше приложение. То есть, ваш проект на Django, на FastAPI, на чём-то ещё. Он может быть один вполне себе, и тогда никакой цепочки не будет. Тут будет приложение, база данных и всё.
Окей, спасибо. Давайте ещё, если вопросов нет, дайте хоть обратную связь. Ну, в принципе, понятно. Ю. Ну, вопросов нет. Понятно слабо. Нужно было глубже, может быть, как думаете? Говорить фидбек, потому что надо понимать. Ну, я вот сейчас на этапе освоения вообще в целом сетевых технологий, сетевых протоколов. Поэтому, ну, для меня так, картинка, такой черновик хороший получился. То есть, я примерно понял всю картину. Да, буду углубляться в моменты, вот это всё, чтобы более глубже понимать элементы. А так, общая картина ясна. Всё понял. Тоже самое, но про то, что рассказал, в принципе, я этого не знал, и довольно понятно всё. Да, на это как раз и был упор на самом деле. Вот эту штуку они везде дают. Получается, вот эта вот модель, а то есть, бывает отклонение, да, то есть, бывают исключения какие-то? А, да. Ну, типа, элементарно, смотри, тут может быть DNS-сервер твоего провайдера, и он сразу знает, на каком DNS-сервере находится `google.com`. То есть, эта цепочка может не происходить. Но в общем случае их трое, да? То есть, Root Server, да. Всё окей. Да. А, повтори, пожалуйста, когда она может не происходить? Залагало чуть-чуть. Когда DNS-сервера вашего провайдера уже знают, на каком DNS-сервере хранится `google.com`, вот эта вот доменная запись. Всё. А кэш вот браузера как-то может с этим взаимодействовать? Или это какая-то просто... Смотри, как разработчики кэш мы можем управлять на самом деле достаточно гибко, особенно в клиентском приложении. Но все это, это будем. Поэтому лучше про это даже не думать и забить. Вот. Ещё, то есть, я слышал про вроде с этим как связан, но он не относится к вот тут. А, понял. Это непосредственно база данных, к которой обращаются Application Server'ы. Как правило, изредко к ней обращаются фронтенд, то есть какое-нибудь приложение на React. Но часто такое вы точно не встретите. Поэтому в общем случае это вот сюда. Об этом говорю, не торопитесь, дойдём. Ну, всё, в принципе, всё понятно. А можно ещё вопрос по поводу кэша? Вот мы отправляем запрос, да, вот если это доменное имя, вот `google.com`, оно у провайдера есть, то мы как бы перескакиваем DNS, да? Или как это происходит? Мы перескакиваем DNS-сервера только в том случае, если есть в браузере. Если а в браузере, и да. А если то есть пользователь, если уже заходил на этот сайт, да, да, да. А если как бы его в браузере нет, то мы DNS не перескакиваем, потому что мы идём в DNS провайдера. Это как бы тоже сервера, и на них хранятся инфа. Всё, спасибо. Так, ещё что-нибудь хотите обсудить? У нас ещё в принципе есть тайминги. Мы уложились вообще отлично в полчаса. Я даже думаю, и URI, допустим, теоретически, вот на скриншоте было, где, где этот, ну, указано. Давай сейчас. То есть, теоретически, если у нас будет `https://www.google.com` — это же в том твой endpoint? Смотри, URI ещё часто называют endpoint, то есть конечной точкой, куда должен зайти запрос. Тут слэш. Вот этот вот слэш — это и есть. Если мы его не ведём, браузер на самом деле автоматически его подложит. Да. Вот. То есть, смотрите, ещё что может быть. Допустим, мы там зашли, как раньше было модно, на всяких сайтах на PHP, вот в этих вот форумах, ну, из десятых годов, `index.html`. Вот такое вы по-любому где-нибудь встретили уже 100% в свою бытность. Вот. HTML стандартная, когда мы запрашиваем HTML с корневой, так сказать, точкой входа в наш сайт. Вот это URI. А админ-панелька тоже получается query params делается? Admin panel? С нет. Смотри, слэш Admin — это endpoint. Query params — это вот всё, что после знака вопроса — это GET-параметры. Это как один из способов передачи. Понял, понял. А это вот именно endpoint, то есть конечная точка, куда должен зайти наш запрос. Знаете, что ещё могу тогда кинуть? Есть веб-сервер, как он понимает, что нужно отбить 404? Есть, например, у нас есть Nginx. У него есть какой-то конфиг, регулярные выражения слышали такое? Регулярки? Да. Вот с помощью регулярных выражений элементарно можно настроить, то какие, соответственно, пути, какие endpoint'ы, какие URI поддерживает наш сервер. То есть, на уровне прокси-сервера, обратного прокси-сервера или веб-сервера мы это дело настраиваем. То есть, если там пришла какая-то, он понимает, что в регулярку он не входит, настраивается регулярное выражение, в регулярку это не входит, и мы на этом этапе это всё дело отбиваем. А если вот, допустим, мы в проекте или на нашем сайте решили добавить защиту DDoS, а куда она непосредственно будет входить — в Application Server или она будет как-то сначала перед... Смотрите, как правило, ну, это что такое защита? Как правило, какие-нибудь WAF, так называемые, или какая-нибудь роутинг. Это всё делается на уровне инфраструктуры. А я просто думал, что сайт слишком долго прогружается, что он типа проверяет где-то на уровне DNS-сервера, либо вот где-нибудь перед самим, перед тем, как запустить на веб-сервер, он проверяет там типа адрес, ну, как-то не знаю, пробивает примерно, что ты не робот или ты не бот, который очередной раз заходит. Ну, здесь опять же, я говорю, тут возможность реализации миллион. У тебя вполне возможно, что разрешённые IP-адреса могут быть. То есть, вполне возможно, ты можешь сказать, что я хочу, чтобы в меня ходили только люди, допустим, из Англии. Это получается внутри как раз инфраструктуры получается? Вот где вот это квадрат со всем получается, там проверяется, допустим, вот откуда человек, с какой стороны, по его адресу, где угодно, да? Ну, как правило, на уровне инфраструктуры все стараются отбивать на ранних этапах. Почему? Потому что запрос может быть внос инфраструктуры, чтобы не допустить его, ну, или уровня какого-то балансировщика нагрузки, веб-сервера того же Nginx, чтобы не допустить запрос в Application Server, прежде всего, чтобы не давать на него нагрузку, потому что основная нагрузка как раз-таки ложится на него, нагрузку на базу данных, и не допустить потенциально херовый запрос, который что-нибудь нам ломает. Понял. Принцип — это получается самая такая популярная вариация. На самом деле вариантов, если мы говорим про микросервисы, там как правило, App Gateway вместе с этими веб-серверами, кто-то тот же использует в качестве AP Gateway. Но я говорю, про это поговорим чуть позже. Сейчас нет смысла поверхностно накидывать вам сложных слов, чтобы у вас не поехала крыша. Как-то так. Ещё есть вопросы? Понятно. Спасибо. Всё, я думаю, походу всё. Всем удачи, хороших выходных, хорошего вечера. Всем пока. Спасибо. Спасибо.