В целом да, но получается, что тут сам сервер выполняет роль stun. Т.е предполагается что первая датаграма которая от клиента приша привела к резервированию порта на нате. По крайней мере в протоколе должно быть что-то типа keep alive чтобы держать его открытым (т.е аналог stun пингов).
Не, там всё хитрее. QUIC даёт уникальные идентификаторы каждому клиенту, поэтому клиент может подключаться с другого IP и с другого порта, и продолжать старое соединение. При этом можно работать сразу через несколько интерфейсов, и всё такое
Ну т.е ок ты можешь сразу с нескольких портов ходить мейнтейня одно логическое соединение. Но сервер то должен как-то иметь возможность тебе датаграмму послать так чтобы она дошла
Я это к тому что нет никакой необходимости держать UDP соединение и пинговат. Если роутер забудет UDP соединение, то новое UDP соединение всё равно продолжит старое QUIC-соединение
Если они на апликейшн левеле, то это в принципе хорошая идея. Так как даже для tcp их всё равно надо делать для долгоживущих соединений, несмотря на то, что вроде как и есть TCP keep alive.
Я опять со спорным вопросом. Если у меня нет требований к производительности и я хочу обработку ХТТП запросов построить на try/catch, чтобы из любой точки можно было быстро замкнуть… и у меня cowboy. Как лучше всего это сделать? Могу ли я например кастомное поведение использовать?