Проксирование сервера потокового видео HLS (.m3u8)
У меня не так уж много знаний о прокси, но я немного их понимаю, у меня есть CDN, который обслуживает мои видеофайлы в формате hls, назовем его mycdn.com, у меня также есть прокси-сервер myproxy.com, по соображениям безопасности mycdn отклоняет все запросы, которые не от myproxy, единственная причина, по которой у меня есть этот прокси, - это добавление пользовательского заголовка в каждый запрос, поэтому для каждого .m3u8 и .ts я хочу отправить некоторые пользовательские данные, проблема с этой настройкой в том, что я потребляю в 2 раза больше пропускная способность сети, предполагая, что мой клиент запрашивает 1 ГБ видео, я сначала запрашиваю его у прокси, прокси запрашивает его у CDN, CDN передает его прокси, прокси передает клиенту, по крайней мере, это то, что я чувствую, что фактически потребляет 2 ГБ данных на ГБ потокового видео, у меня есть некоторый код, написанный на nodejs, какие методы я могу использовать, чтобы не нести практически никаких затрат на пропускную способность на прокси-сервере, меня устраивают любые данные, необходимые для добавления этих дополнительных заголовков.
router.use(
'/:resolution/:videoId',
(req, res, next) => {
// @ts-ignore
req.customParams = {
resolution: req.params.resolution,
videoId: req.params.videoId,
};
next();
},
createProxyMiddleware({
target: `https://mycdn.com/somevideoid`,
changeOrigin: true,
preserveHeaderKeyCase: true,
selfHandleResponse: true,
pathRewrite: (path, req) => {
// @ts-ignore
return `/${req.customParams.resolution}/${req.customParams.videoId}`;
},
on: {
proxyRes: (proxyRes, req, res) => {
res.writeHead(proxyRes.statusCode || 400, proxyRes.headers);
proxyRes.pipe(res);
},
},
}),
);
Ответы 1
У меня также есть прокси-сервер myproxy.com, по соображениям безопасности mycdn отклоняет все запросы, исходящие не от myproxy.
Это противоречит всей цели CDN, не так ли? Вам следует пересмотреть архитектуру вашего приложения, чтобы ему вообще не требовался этот прокси. Клиенты должны иметь возможность получать данные непосредственно из вашего CDN.
единственная причина, по которой у меня есть этот прокси, - это добавление пользовательского заголовка в каждый запрос, поэтому для каждого .m3u8 и .ts я хочу отправить некоторые пользовательские данные.
Нигде в вашем коде вы не добавляете собственные заголовки...
проблема с этой настройкой в том, что я потребляю в 2 раза большую пропускную способность сети
Ну да, и это не так уж хорошо для ваших пользователей, у которых, несомненно, теперь есть бессмысленные накладные расходы из-за еще одного уровня, вставленного через ваше приложение Node.js, которое не размещается по всему миру, как это было бы с вашим CDN.
У меня есть код, написанный на nodejs, какие методы я могу использовать, чтобы не нести практически никаких затрат на пропускную способность на прокси-сервере?
Не используйте прокси. Вот и все.
Послушайте, вы практически уничтожили всю причину использования CDN, и не только эту, но и главную причину использования HLS. Если бы вы в любом случае собирались передавать видео из Node.js, вы могли бы просто обслуживать видеопотоки напрямую через HTTP, а затем пропустить все накладные расходы и добавить задержку HLS. Здесь вы пошли на худший из всех компромиссов в мире.
И опять же, нигде в вашем коде вы не добавляете заголовки. Вы переписываете URL, вот и все, что не требует проксирования. Вы могли бы добавить эти параметры на стороне клиента. В худшем случае, если бы они должны были прийти со стороны сервера, вы могли бы использовать перенаправление 307 с заголовком Location: в ответе, но даже это просто добавляет дополнительные накладные расходы. И заставлять клиента сообщать вам эту статистику игроков в каждом отдельном сегменте — это на самом деле пустая трата времени и ресурсов.
Разделите свои заботы. Позвольте CDN выполнить обслуживание файлов для вашего потока HLS. Какую бы регистрацию или другие действия вы ни делали с этими другими данными, делайте это вне канала видеопотока.
Я знаю, что я не устанавливаю заголовки сразу, но сделаю это позже, проблема в том, что я застрял на cdn, у которого нет отличной системы аутентификации токенов, это кролик-cdn, и хотя я могу встроить пользовательские данные в качестве параметров запроса, ничто не мешает конечному пользователю изменить и удалить параметры запроса, подписанный URL-адрес все равно будет работать
@SahilAsopa Каковы параметры? Почему ваш CDN заботится о них? Если ваш CDN не заботится о них, значит, вы используете их не на том уровне.
нет, мой CDN на самом деле не заботится о них, в основном для целей регистрации, мой CDN предоставляет журналы по базам URL-адресов, поэтому URL-адрес x с заголовком y потребляет nGB видео, я не контролирую своих клиентов, поскольку передаю свои URL-адреса дистрибьютору, но хотя я нашел способ сделать это с подписанными URL-адресами и понял, что эта настройка отстойна на 100 уровнях, спасибо, что подтвердили мои подозрения. ПРИВЕТ, БРЭД.
@SahilAsopa Хорошо, если это необходимо для регистрации, то вашему CDN действительно нужна эта информация, поскольку он единственный, кто действительно знает, сколько данных было отправлено. Рад слышать, что вы нашли способ включить эту информацию в подписанную часть ваших URL-адресов.
Нет необходимости в CDN, если вы обслуживаете его через прокси. Эта установка не имеет смысла.