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 ()

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

pyroman ()
Ответ на: комментарий от 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)
Ответ на: комментарий от pyroman

Суть вебсокетов в том, что сервер явно, отчётливо говорит интернету «да, я действительно хочу принимать подключения из 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 ()
Ответ на: комментарий от spec_po_kiskam

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

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

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

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

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

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

vi0 ()
Последнее исправление: vi0 (всего исправлений: 1)