LINUX.ORG.RU

websocat — клиент, сервер и прокси для WebSocket-ов

 , , ,


1

3

Вышла версия 1.0.0 программы для работы с WebSocket-ами из командной строки «websocat». Девиз программы: "netcat, curl и socat для вебсокетов".

Возможности:

  • Простой клиент и сервер для WebSocket.
  • Проксирование подключений, например, между TCP и ws://.
  • Выполнение внешних программ в качестве подключения.
  • Подключение и прослушивание AF_UNIX (в т.ч abstract) сокетов. Использование SOCK_SEQPACKET режима.
  • Преобразование строк в сообщения и обратно (включается автоматически, если не --binary).
  • Использование одного подключения несколькими клиентами.

Примеры:

  • Просто клиент и сервер:
    $ websocat wss://echo.websocket.org
    qwer
    qwer
    ^C
    
    $ websocat -s 1234
    Listening on ws://127.0.0.1:1234/
    ^C
    
  • Проброс SSH через вебсокет:
    server$ websocat --binary ws-l:0.0.0.0:8080 tcp:127.0.0.1:22
    client$ ssh -c ProxyCommand='websocat --binary - ws://myserver:8080/' user@myserver
    
  • Интеграция с nginX через UNIX-сокет:
    umask 0000
    websocat --exit-on-eof --text --unlink ws-upgrade:listen-unix:/tmp/wstest sh-c:'bash -i 2>&1'
    
        location /ws {
            proxy_read_timeout 7d;
            proxy_send_timeout 7d;
            proxy_pass http://unix:/tmp/wstest;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
        }
    

    Таким способом можно заставить websocat обслуживать безопасные (wss://) вебсокеты.

  • Аналог echo.websocket.org:
    websocat -v -t ws-l:[::]:8080 mirror:

    Похожее, но ответы идут всем подключенным клиентам:

    websocat -v -t ws-l:[::]:8080 broadcast:mirror:

---

Лицензия: MIT.

Есть предсобранные версии для Linux (i386, amd64, arm; обычные и статические), Mac и Windows, а также пакеты deb.

>>> Подробности



Проверено: jollheef ()
Последнее исправление: cetjs2 (всего исправлений: 6)

Оу, оно ещё и на расте...

CYB3R ★★★★★
()

Слушайте, а где нибудь вообще есть нормальное объяснение того как вебсокеты работают? Ну то есть за счёт чего получается что сервер может доставлять пакеты в браузер, если соединение браузера с сервером не висит постоянно, как это было с long polling. Браузер же не может тупо открыть порт и слушать, ведь файрвол в роутере не пропустит. А то везде только пишут общих чертах что сервер позволяет посылать в браузер данные https://i.imgur.com/JEcVo4t.png а как такое возможно нигде не объясняется.

Deleted
()

websocat
socat

Хорошее название.

Deleted
()
Ответ на: комментарий от Deleted

TCP соединение, по которому клиент посылает HTTP запрос на подключение к websocket, не закрывается, а используется для передачи данных по websocket протоколу.

red75prim ★★★
()
Ответ на: комментарий от mittorn

Использую такое для предоставления страницы доступа по tcp и udp:

Ужас какой. Понимаю проксировать tcp через ws. Но наоборот? Скоро будем пересылать видео дымовыми сигналами...

demrnd
()

Server mode ignores incomding URL and HTTP headers

тоесть при проксировании ws2tcp нельзя никак получить хедеры, присланные при подключении? без этого както грустно и даже пробовать смысла не вижу :(

кстати, а бенчмарки какиенибуть есть? хз с чем его сравнивать лучше, мне бы хотелось сравнить с gevent-websocket (с установленным wsaccel само собой) но я ленивая жопа

genryRar ★★
()
Последнее исправление: genryRar (всего исправлений: 1)
Ответ на: комментарий от Odalist

Кажется вот этот пацанчик, под ником «I-Love-Microsoft».

А другие? И сфера его интересов, емнип, больше про Qt и немного Python, чем про Rust.
И ты б аналогов сабжа лучше подкинул для сравнения ненужности.

Virtuos86 ★★★★★
()
Последнее исправление: Virtuos86 (всего исправлений: 1)
Ответ на: комментарий от demrnd

Я именно tcp и udp проксирую через ws, чтобы emscripten приложение имело полноценный доступ в интернет

mittorn ★★★★★
()
Ответ на: комментарий от Deleted

Суть вебсокетов в том, что сервер явно, отчётливо говорит интернету «да, я действительно хочу принимать подключения из JavaScript'а в браузерах».

Одна из проблем в интернете была (и есть?), что вредоносные JavaScript-ы в браузере отправляют типа HTTP-запрос на не-HTTP порт (например, на IRC) и тем самым рассылают спам. Все привыкли, что есть ты держишь публичный HTTP-сервер, то его нужно защитить от всяких разный чужих JavaScript'ов (при помощи Referer, Origin и т.д.), но не привыкли также подходить и к другим (не-HTTP) ресурсам. Поэтому нельзя было просто взять и разрешить обычные TCP или UDP подключения из JavaScript-а.

Следовательно, в RFC6455 был разработан специальный «танец» с HTTP Upgrade, специальным security token и немножко подзашифровынными сообщениями (только в одну сторону), чтобы WebSocket's случайно не могли подключиться к чему-то ещё, кроме WebSocket-сервера.

Режим сообщений вместо byte stream, пинги и отдельные текстовые и бинарные сообщения — это просто добавочка заодно.

vi0
() автор топика
Ответ на: комментарий от Odalist

Ох, дремучий адепт нинужно (Perl) подал голос!
Раст конечно тоже нинужен (сам по себе из-за стрёмного синтаксиса, впрочем высеры на перловке ака write_only-код не сильно лучше), но программка полезная и вполне может пригодиться, а значит нужно.

EvilFox ★★
()

Девиз программы: «netcat, curl и socat для вебсокетов»

О! Годно! Нужно!

>>> Подробности:

Building from source code

1. Install the Rust tool toolchain

2. cargo build --release.

Фу. Го*но! Ненужно!

anonymous
()

WebSocket ура!

anonymous
()
Ответ на: комментарий от spec_po_kiskam

Проброс SSH/OpenVPN скорее для сетей с цензурой/DPI; или если разрешён только 80/443 порт, а он занят веб сервером.

Для примера бэкдора смотрите третий сценарий «Интеграция с nginX через UNIX-сокет».

vi0
() автор топика
Ответ на: комментарий от vi0

Всё правильно вроде.

Но при этом оно работает и через прокси (по крайней мере через тор сообщения с сервера приходят всё равно), что удивительно.

Deleted
()
Ответ на: комментарий от Deleted

Через SOCKS-прокси должны работать не только вебсокеты, но и другие подключения (тот же SSH).

Через HTTP-прокси вебсокеты тоже могут работать, если прокси сервер реализован нормально (то есть после интерпретации и передачи HTTP-заголовка на сервер начинает просто обеспечивать двухсторонний одновременный обмен данными между TCP-сокетами).

А если HTTP-прокси кривоватый (например, только один раз читает HTTP-запрос, один раз пишет HTTP-запрос на сервер, один раз читает ответ от сервера и один раз шлёт этот ответ клиенту), то помимо WebSocket'ов и некоторые другие возможности HTTP могут не работать, например, «HTTP/1.1 100 Continue».

vi0
() автор топика
Последнее исправление: vi0 (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.