Не имею глубокой компетенции работе с сетевым стеком, но имею большую практику работы с шифраторами на больших инфраструктурах.
Мне видится задача, с годным для приложений эффектом, сложно решаемой. Особенно с учётом, выполнения её на x86 архитектуре с потоком в несколько гигабит различного трафика. Во-первых, приоритет сервиса и время ожидания ответа в рамках сессии, понятия несовместимые. Пока ждём завершения важного ВКС в 4К, сессии наших приложений будут дропаться. Не годится. Во-вторых, джиттер будет скакать. В-третьих, будет ли соблюдаться очерёдность пакетов? Бывает, что при простом прохождении без нагрузки Out Of Sequence frame зашкаливал так, что на уровне TCP буферы не спасали и реально мешал работе приложений.
Наша беда не в реализации производителями СКЗИ алгоритмов шифрования, а в том, что мы не можем "прожигать" ASIC с "ГОСТом", как "буржуины" AESом. Потому для шифрование приходиться применять, по сути ПК, и о работе на скорости линии говорить не приходится.
Хороший кейс, но больше теоретический. На практике необходимо под бэкапы держать отдельный выделенный канал связи. Ведь как только в канал и на шифратор попадëт трафик передачи бэкапа весь межцодный трафик "просядет". Это же касается и критических бизнес-сервисов. Под них так же необходимо ставить дополнительные vpn- шлюзы.
Не имею глубокой компетенции работе с сетевым стеком, но имею большую практику работы с шифраторами на больших инфраструктурах.
Мне видится задача, с годным для приложений эффектом, сложно решаемой. Особенно с учётом, выполнения её на x86 архитектуре с потоком в несколько гигабит различного трафика. Во-первых, приоритет сервиса и время ожидания ответа в рамках сессии, понятия несовместимые. Пока ждём завершения важного ВКС в 4К, сессии наших приложений будут дропаться. Не годится. Во-вторых, джиттер будет скакать. В-третьих, будет ли соблюдаться очерёдность пакетов? Бывает, что при простом прохождении без нагрузки Out Of Sequence frame зашкаливал так, что на уровне TCP буферы не спасали и реально мешал работе приложений.
Наша беда не в реализации производителями СКЗИ алгоритмов шифрования, а в том, что мы не можем "прожигать" ASIC с "ГОСТом", как "буржуины" AESом. Потому для шифрование приходиться применять, по сути ПК, и о работе на скорости линии говорить не приходится.
Какие-то странные новости. Сервису Солана 100 лет в обед. По ссылке на ТАСС, вообще указано только "сотовым операторам". В общем, цель посыла ясна.
Так весь же спектр пакетов показали. Ну и на 64 байта молотит без просадки. На сайте есть полные отчёты под катом:
https://systempb.ru/company/news/mts-protestirovala-zashchishchennuyu-peredachu-dannykh-na-transportnoy-seti-moskva-sankt-peterburg-so-skorostyu-100-gbit-sek/
Добрый день!
ТХ Вы можете посмотреть на сайте продуктов компании производителя https://skzi.ru/catalog/kvazar-100/vmsh-tr/
По сути, это телеком оборудование, преобразователь протоколов локальных сетей в протокол передачи по оптическим каналам связи, с функцией шифрования.
Хороший кейс, но больше теоретический. На практике необходимо под бэкапы держать отдельный выделенный канал связи. Ведь как только в канал и на шифратор попадëт трафик передачи бэкапа весь межцодный трафик "просядет". Это же касается и критических бизнес-сервисов. Под них так же необходимо ставить дополнительные vpn- шлюзы.