Проксирование сокетов?

Маршруты дописать.

Посмотри в сторону sendfile или переосмысления задачи.

Посмотри в сторону sendfile

Тогда уж splice, sendfile только из файлов умеет читать

netcat?

netcat

только если по принципу «чего не видно, того нет», так как там внутри read/write

Не страдайте фигней, просто сделайте это на epoll/select - всё равно ваша сеть даже на 20% одно ядро не загрузит.

Посмотри на BPF сначала. Потом городи велосипеды.

Если пришли с первого сокета, то пришли куда? В третий сокет? И нужно отправить их во второй? По человечески опиши задачу, че за софт, где стоит и что решает, на одной машине крутится всё или по сети гоняешь между разными машинами?

Если пришли с первого сокета, то пришли куда? В третий сокет?

Стоит такая задача: есть 2 сокета и мне нужно их «соеденить»

Чоткая аватарка, в точку.

вобще мне стало даже интересно: действительно ли это быстрее и во сколько раз? обычно бывает, что на первый взгляд кажется, что нечто дает ускорение во много раз, но по тестам этого не скажешь.

Пусть грамотно пишет, что сокета три, а не два, и один из них у него выступает как прокси

Или упоминает тогда, что у него два tcp сокета в одной прокси проги

Прежде чем лезть в ядерную часть, попробуй померять показатели, которые тебе нужны. Задержку, пропускную способность? Скорее всего userspace read/write/epoll хватит с головой. Там не так много выигрыша будет как тебе кажется.

libUV + UDP - быстрее некуда

Чего ты несёшь, болезный? Какое три сокета, какое тсп?

Понел.

это просто ты тупой, а все остальные поняли, что сказал ТС

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

Че-т я посмотрел, они оба только «в сторону», сокет-в-сокет они оба не должны мочь.

вопрос - можно ли это сделать не гоняя данные через userspace, т.е. средствами ядра/OS?

Именно в такой постановке (пара сокетов смотрящая в разные стороны) без user space не получится. Вы уж определитесь - или контроль/модуляция трафика, или всё проходит мимо Вас.

2 вызова splice позволяют перекинуть порцию данных из одного сокета в другой без копирования в юзерспейс

2 вызова splice позволяют перекинуть порцию данных из одного сокета в другой без копирования в юзерспейс

Не хочу Вас расстраивать, но «splice() moves data between two file descriptors … one of the file descriptors must refer to a pipe.»

Вы считаете это будет дешевле чем read()+write()?

pipe - это буфер памяти в пространстве ядра. Условие задачи было «не гоняя данные через userspace». Дешевле или нет - надо тестировать для конкретного случая.

Но дороже быть не должно, так как системных вызовов в обоих случаях два

Не знаю, годится ли тебе такое решение: во FreeBSD есть такая подсистема — netgraph. Там такое делается ну чрезвычайно просто: man ng_tee, man ng_ksocket.

Это если ты не прибит гвоздями к линуксу.

Условие задачи было «не гоняя данные через userspace».

Очевидно с целью «сэкономить».

Дешевле или нет - надо тестировать для конкретного случая.

Но дороже быть не должно, так как системных вызовов в обоих случаях два

«Готов поставить существенную сумму» что гонять splice’ами через pipe будет заметно медленнее чем read()+write() через userspace, особенно под нагрузкой. Я сильно затрудняюсь представить что там даже в теории можно такого сделать чтобы эту копию отыграть, а вот отстрелить себе ногу - миллион способов, начиная с ограниченного (и относительно маленького) размера внутреннего буфера pipe.

начиная с ограниченного (и относительно маленького) размера внутреннего буфера pipe

Его можно настроить, да и то, насколько он маленький или большой, сильно зависит от харакетра нагрузки, если прилетают блоки по килобайту раз в минуту, то и дефолтный будет большим

отстрелить себе ногу - миллион способов

Достаточно обработать ошибки, которые может вернуть splice. Но код будет сложнее, чем с read/write, спору нет

Очевидно с целью «сэкономить».

Вот пусть заимплементит и сравнит, получилось сэкономить или нет.

Его можно настроить

Таки да, подкрутили. А я и пропустил:

Different implementations have different limits for the pipe capacity.

...

In Linux versions before 2.6.11, the capacity of a pipe was the same as the system page size (e.g., 4096 bytes on i386). Since Linux 2.6.11, the pipe capacity is 16 pages (i.e., 65,536 bytes in a system with a page size of 4096 bytes). Since Linux 2.6.35, the default pipe capacity is 16 pages, but the capacity can be queried and set using the fcntl(2) F_GETPIPE_SZ and F_SETPIPE_SZ operations.

С 4к, да даже и 64к, при современных сетевых скоростях Вы бы поросли однозначно. А самое главное - ну вот не позволяет оно от этой копии избавиться, от слова никак. Вопрос только между чем копируется.

А самое главное - ну вот не позволяет оно от этой копии избавиться, от слова никак.

Есть такое

Я вспомнил, где я сталкивался со сплайсом через пайп и это было выгодно. На устройстве с жестким диском нужно было копировать файлы с флешки на диск. Ядро было старое и sendfile тогда еще не умел писать из файла в файл, но копирование через splice ускоряло процесс по сравнению с read/write

Спасибо, кажется именно то, что нужно.

надо достать FreeBSD и посмотреть, а то с 4.4-4.5 не видел ее )

спасибо, попробую тоже вариант этот, сделаю замеры.

спасибо за идею, попробую, замерю.

но копирование через splice ускоряло процесс по сравнению с read/write

Интересно было бы понять за счёт чего? Там реально zero-copy случался, или что-то ещё?

а какая разница в какой памяти буфер находится в юзерской или в кернел, если так и так данные будут скопированы через pcie в память хоста, а потом заново из памяти хоста через pcie в буфер сетевой карты(потенциально другой). А ведь по сути надо-то всего навсего ip/tcp заголовки переписать

а какая разница в какой памяти буфер находится в юзерской или в кернел, если так и так данные будут скопированы через pcie в память хоста, а потом заново из памяти хоста через pcie в буфер сетевой карты(потенциально другой).

Какой еще pcie, на кого ты свой энтерпрайз крошишь, сейчас у большинства сетевух в мире физическая часть в материнке, контроллер в CPU, а память в RAM

¯\_(ツ)_/¯

Но выигрыш был ощутимым и не требовал для регистрации фотофиниша и миллисекундных таймеров

Еще ОП нигде не упоминает, какие именно у него сокеты. Я подозреваю, что если один из сокетов не сетевой, а юниксовый, или если сетевой, но от локалхоста или виртуального интерфейса, то ситуация может отличаться от проксирования между двумя «настоящими» сетевыми сокетами.

А ведь по сути надо-то всего навсего ip/tcp заголовки переписать

Я не думаю что в общем случае это в принципе возможно: destination вовсе не обязан быть способным мгновенно потреблять всё что пришло из source, и тогда Вы точно захотите резать пакеты по-другому с целью максимизировать useful payload / headers overhead ratio. MTU может быть разный etc.

Еще ОП нигде не упоминает, какие именно у него сокеты.

Кстати, таки да. Но по любому было бы интересно если бы он отписался потом удалось что-нибудь splice’ами отыграть, или нет.

Еще ОП нигде не упоминает, какие именно у него сокеты.

Оба сокета TCP, оба смотрят наружу

Оба сокета TCP, оба смотрят наружу

А чем тогда не устраивают готовые высокопроизводительные решения для TCP-прокси?

Оба сокета TCP, оба смотрят наружу

А чем тогда не устраивают готовые высокопроизводительные решения для TCP-прокси?

И трафик какого плана - bursts раз в пятилетку, или что-то более-менее steady rate?

ТС все еще не погуглил eBPF?