Comments 33
Мне одному надоели статьи на хабре про вайкод и ВыПыЕн? Просто каждая рекомендация именно про это, притом ряд статей выглядит как что-то оторванное от реальности, к примеру статьи про vless + cloudflare (который уже 100500 раз блочат в рф) для обхода бс
Липов Андрей Юрьевич, перелогиньтесь
Забавно, что автор данной статьи один из тех немногих, под чьим постом ваше справедливое недовольство выглядит несколько неуместным
На cloudflair работаю визовые центры, которыми пользуются россияне внутри РФ. Так просто ты все не заблочишь.
Проблемы индейцев шерифа не волнуют. Даже наоборот, шериф доволен будет, нефиг по заграницам шастать.
Плюс ещё такие блокировки больших хостеров и CDN зачастую и имеют поверх дополнительные списки «белых» SNI, с которыми пускают в их диапазоны, для сильно нужных ресурсов.
Превращение своей лояльной/нейтральной аудитории в бесправных индейцев такой себе план. Хотели бы, заблокали, но это подъем волн возмущения, как с моб. интернетом
Вы кажется полностью проспали события N последних лет в стране.
>это подъем волн возмущения, как с моб. интернетом
Повозмущались и что дальше? Затерпели.
В моем городе белые списки уже год как работают. Каждый день в районе 5-6 вечера мобильный интернет переводится на белые списки. Бывает, что и весь день.
А что, кого-то накажут? "Визовые центры деградировали, РКН твёрдо и чётко заявил, что они не блокировали". В конце концов, даже из 53%, имеющих загранпаспорт, не менее половины ездят только в страны, где визовый центр не нужен.
Зарегистрирован вчера в 15:26
Два VoLTE девайса (чтоб EVS был) и ИИ для TTS/STT. Этакая реинкарнация диалапа.
О... Спасибо за статью. Я тут думал над резервным каналом при белых списках
MiraclePtrUsr с возвращением?
serverless была одной из первых идей, но так и не получилось реализовать самостоятельно.
Спасибо за ссылку и подробный обзор.
Готовимся?
А в какую сумму обходится использование serverless-функций?
Калькулятор выдаёт около 500 рублей для 720 вызовов по 3600 секунд, но хотя бы трафик должен укладываться в бесплатную квоту.
Если gRPC API облака доступен с клиентского устройства, то функция используется только в самом начале в момент установления подключения, и после этого клиент и сервер шлют данные друг другу вообще напрямую, не используя функцию. Если недоступен - тогда да, функция используется для отправки данных от клиента к серверу и постоянно будет активен хотя бы один инстанс.
Какой такой сервер и какое отношение он имеет к serverless функциям?
Читайте внимательно описание в статье.
На VPS ставится серверная часть, на клиент - клиентская. Поскольку клиент и сервер не могут достучаться друг до друга напрямую (IP сервера не в белых списках), они оба подключаются по вебсокетам к облаку, где serverless-функция помогает им обменяться ID вебсокетных подключений от облачного Gateway API, после чего они могут слать пакеты друг другу через этот самый Gateway API. А если у клиента Gateway, то serverless функция ещё используется для того чтобы слать данные от клиента к VPS.
*а если у клиента endpoint API Gateway’а недоступен
(потерялась часть предложения куда-то)
Я правильно понимаю: клиент дергает лямбду, лямбда дергает сервер. Сервер регистрирует connection на GW и возвращает id лямбде которая прокидывает его клиенту и клиент с помощью этого id пушит message на GW которые GW пересылает на сервер, без участия лямбды? Или сервер всегда держит активный connection на GW но тогда как о нем узнает лямбда?
При этом судя по коду поддерживается фоллбек, когда message идут по одному на лямбду и та пересылает их сама на каждый вызов? Интересно а как сохраняется стейт лямбды между вызовами? Там connid хранятся в global, они по идее должны просто затиратся между вызовами лямбды.
Лямбда умирает не сразу, она может жить определенное время в горячем режиме между запросами, и это время хранит стейт в тех самых глобальных переменных - в рантайме яндекса они не обнуляются между запросами.
Грубо говоря, как-то так:
Сервер подключается к API Gateway, лямбда обрабатывает событие и отвечает ему «ID твоего подключения XXXX, запомни его», сервер запоминает
Клиент подключается к API Gateway. Если есть горячая лямбда со стейтом, то она шлет клиенту ID подключения к серверу, а серверу ID клиента, и дальше они общаются напрямую.
Другой вариант - лямбда заснула, клиент подключается к API Gateway, лямбда просыпается без стейта. Она стучится к серверу по HTTP и говорит «напомни мне, какой там у тебя ID», сервер напоминает, и дальше все как в пункте 2.
Если клиент не имеет доступа к API самого API Gateway, то он просит лямбду пересылать его данные к серверу, лямбда узнает у сервера ID его вебсокетного подключения (или уже знает его) и дальше начинает пересылать данные, короче как пунктах 2 и 3.
Короче говоря, стейт хранится на сервере, и «чистая» лямбда может стукнуться к серверу по HTTP и восстановить себе стейт.
А они доступны на белых списках или там тоже рандом без общего списка "разрешенных" префиксов?
Не всё здесь пробовал, но так скажем ЧЕРНЫЕ ЛИСТЫ тот же DNSTT не обходит, во всяком случае на мегафоне
А если надо для режима обычного нечебурнета, то и обычного влесс реалити и прочего хватает с головой
Невероятно приятно увидеть фразу «работает как говно» и сразу понять, что статья написана без применения ИИ (имитации интеллекта). Спасибо!
Anything's is a tunnel If You're Brave Enough
Немного извращений из мира прокси и VPN