Рекомендация для транспортного протокола больших двоичных блоков на основе TCP / IP

Question

Я планирую разработать некую систему транскодирования видео.

Одна машина имеет устройство захвата кадров и будет принимать аудио / видео сигнал от различных источников.
К этому источнику будет подключено несколько машин транскодированиямашина через гигабитный Ethernet.
Исходный компьютер будет отправлять сжатые данные аудио / видеокадров на транскодирующие машины.

Поскольку это простой односторонний транспорт, я подумал, что могу использовать HTTP.Но пропускная способность сети является проблемой.

С помощью простого поиска я нашел сообщение в Superuser .
Этот пример реального гигабитного Ethernet показывает пропускную способность только 340 Мбит / с.

Моя целевая система должна поддерживатьмногократное одновременное транскодирование видео Full HD.
Скорость передачи видео 1080P Full HD без сжатия может составлять 712 Мбит / с.Даже при сжатии это может легко насытить гигабитную сеть только на 1 или 2 каналах.

Скажем, 3 - цель.Какой протокол я использую для 3 одновременной передачи видеоданных в формате Full HD?Могу ли я использовать HTTP?Должен ли я разработать специальный многоадресный протокол?Существует ли какой-либо протокол с открытым исходным кодом и / или протокол открытой спецификации для этой цели?

Заранее спасибо.

Answer 1

Пропускная способность TCP / IP - это то, что трудно измерить, фактически не проверяя ее в ваших собственных условиях.Этот человек может видеть только пропускную способность 340 Мбит / с, но простой способ насыщения соединений с высокой пропускной способностью до максимальной скорости - это множественные параллельные передачи по TCP ... для этого также будет работать HTTP.

Реальный вопрос - двоякий... во-первых, нужно ли ваше видео прибыть в ваш транскодер в течение определенного периода времени?Если да, то какое у вас время?Во-вторых, какую полосу пропускания занимает один сжатый поток?

Наконец, помните, что вы можете использовать LACP для объединения ваших соединений Ethernet вместе с двумя или более сетевыми картами, чтобы ваш сервер мог откачивать больше данных, если вы обнаружите, чтовы ограничены одним GigE-соединением.Поговорите с вашим сетевым администратором, чтобы узнать, возможно ли это ...

РЕДАКТИРОВАТЬ ОТВЕТИТЬ НА ОБСУЖДЕНИЕ В КОММЕНТАРИЯХ:

Итак, у вас есть около 30 миллисекунд для отправки данныхдля одного кадра .... просто чтобы помочь вам с бюджетированием, если это не включает задержки транскодирования, обязательно вычтите их из 1/30 секунды ... с таким типом времени, я бы оставилПостоянно открывайте сокет TCP и просто пошагово отправляйте файлы через тот же сокет TCP ... что уменьшит ваши накладные расходы при установлении и отключении TCP ... вы можете даже иметь возможность что-то решить с обычным FTP ... простоне закрывайте сеанс FTP до тех пор, пока видео-программа не закончится ... настройка коммутатора и хостов для использования гигантских кадров (Ethernet-MTU более 1522 байтов, включая заголовки, crc и тег vlan ...) может сбрить еще несколько миллисекундот ваших номеров передачи файлов, но административные издержки jumbos могут быть проблемой ... например, когда кто-то обновляет SWзудят или маршрутизаторы, они часто забывают проверить поддержку интерфейса поставщика для jumbos ... усугубляя проблему, торговые представители продавца, которые "делают предположения" о своей поддержке jumbo frame.

Answer 2

Если вы хотите использовать многоадресную рассылку и можете переключиться на протокол UDP, тогда я предлагаю вам принять во внимание протокол RTP.Но у вас, похоже, нет целей потоковой передачи, и, кроме того, вы отправляете заархивированный файл.Для этого вполне подойдет HTTP, но если вы хотите избежать издержек, вы можете использовать 3 простых TCP-соединения без HTTP.