Несмотря на обилие статей про IPsec на linux, каждый раз, когда мне нужно было слушать multicast на виртуальной машине в облаке (на примере AWS), который туда нужно было туда получать через IPSec тоннель, я, сталкиваясь с какими-то проблемами в настройке, жалел, что не сделал никаких заметок в прошлый раз. В этот раз я решил записать пример конфигурации с небольшими пояснениями, и поделиться им с общественностью, в надежде, что это кому-то может быть полезным.

Несколько месяцев назад появилась новость о том что в РФ разрешили стандарт Wi-Fi 6E, и мне захотелось поделиться своим опытом пользования wi-fi 6e в РФ в домашних условиях, когда это еще не было мейнстримом.

В сфере высокочастотной торговли зачастую борются за любое уменьшение сетевой задержки, ведь это дает возможность получить информацию об изменении цены инструмента раньше остальных и отправить заявку на исполнение быстрее конкурентов по более выгодным условиям. Нередко можно встретить такие решения, как отказ от промежуточного сетевого оборудования в виде сетевого коммутатора, который мог бы обеспечить использование торгового подключения несколькими серверами сразу. Но зачем подключать каждый сервер напрямую к инфраструктуре биржи, если можно платить за один аплинк и подключить его в классический ToR(Top-of-rack) коммутатор? Конечно для уменьшения сетевой задержки, ведь современный сетевой коммутатор внесет лишние 200-500 наносекунд задержки.

Конечно можно обратиться к low-latency коммутаторам, базирующимся на FPGA матрицах, таким как серия Cisco Nexus 3550 Fusion (в прошлом Exablaze ExaLINK Fusion) или Arista 7130 Series (в прошлом Metamako MetaMux).

Точное определение времени и его синхронизация чрезвычайно важна в мире высокочастотной торговли.

Конечно же, синхронизация времени важна в общей инфраструктуре компании, думаю многие из вас встречались хотя бы раз с проблемами, вызванными некорректным временем на сервере, выполняющим ту или иную роль. Например, возможно некорректное формирование бэкапов, задержка в обработке запросов, некорректная интерпретация валидности сертификатов, ошибки аутентификации и авторизации и т. д. Тут на помощь придет NTP (Network Time Protocol) протокол, который широко распространен повсеместно, а далеко не только в HFT отрасли. Наилучшая точность синхронизации времени с помощью NTP будет порядка 1мс и то, в случае если NTP сервер находится в локальной сети с вашим сервером, а также оптимально настроен, например, дает опрашивать себя достаточно часто. Для среднего случая, когда NTP сервер будет использоваться из интернета, вы сможете добиться 10-100 мс точности, а если сетевой путь до источника времени будет совсем не идеален (зачастую колокация биржи может предоставлять только IPSec туннель в качестве доступа до вашей биржевой инфраструктуры), то и сотен миллисекунд.

Решение же торгового алгоритма об отправке заявки на биржу может и не опираться на абсолютное время.