~ubuntu-branches/ubuntu/trusty/websockify/trusty-updates

« back to all changes in this revision

Viewing changes to README.md

  • Committer: Package Import Robot
  • Author(s): Thomas Goirand
  • Date: 2013-02-23 01:22:51 UTC
  • Revision ID: package-import@ubuntu.com-20130223012251-3qkk1n1p93kb3j87
Tags: upstream-0.3.0+dfsg1
ImportĀ upstreamĀ versionĀ 0.3.0+dfsg1

Show diffs side-by-side

added added

removed removed

Lines of Context:
 
1
## websockify: WebSockets support for any application/server
 
2
 
 
3
websockify was formerly named wsproxy and was part of the
 
4
[noVNC](https://github.com/kanaka/noVNC) project.
 
5
 
 
6
At the most basic level, websockify just translates WebSockets traffic
 
7
to normal socket traffic. Websockify accepts the WebSockets handshake,
 
8
parses it, and then begins forwarding traffic between the client and
 
9
the target in both directions.
 
10
 
 
11
### WebSockets binary data
 
12
 
 
13
Websockify supports all versions of the WebSockets protocol (Hixie and
 
14
HyBi). The older Hixie versions of the protocol only support UTF-8
 
15
text payloads. In order to transport binary data over UTF-8 an
 
16
encoding must used to encapsulate the data within UTF-8.
 
17
 
 
18
With Hixie clients, Websockify uses base64 to encode all traffic to
 
19
and from the client. This does not affect the data between websockify
 
20
and the server.
 
21
 
 
22
With HyBi clients, websockify negotiates whether to base64 encode
 
23
traffic to and from the client via the subprotocol header
 
24
(Sec-WebSocket-Protocol). The valid subprotocol values are 'binary'
 
25
and 'base64' and if the client sends both then the server (the python
 
26
implementation) will prefer 'binary'. The 'binary' subprotocol
 
27
indicates that the data will be sent raw using binary WebSocket
 
28
frames. Some HyBi clients (such as the Flash fallback and older Chrome
 
29
and iOS versions) do not support binary data which is why the
 
30
negotiation is necessary.
 
31
 
 
32
 
 
33
### Encrypted WebSocket connections (wss://)
 
34
 
 
35
To encrypt the traffic using the WebSocket 'wss://' URI scheme you
 
36
need to generate a certificate for websockify to load. By default websockify
 
37
loads a certificate file name `self.pem` but the `--cert=CERT` option can
 
38
override the file name. You can generate a self-signed certificate using
 
39
openssl. When asked for the common name, use the hostname of the server where
 
40
the proxy will be running:
 
41
 
 
42
```
 
43
openssl req -new -x509 -days 365 -nodes -out self.pem -keyout self.pem
 
44
```
 
45
 
 
46
 
 
47
### Websock Javascript library
 
48
 
 
49
 
 
50
The `include/websock.js` Javascript library library provides a Websock
 
51
object that is similar to the standard WebSocket object but Websock
 
52
enables communication with raw TCP sockets (i.e. the binary stream)
 
53
via websockify. This is accomplished by base64 encoding the data
 
54
stream between Websock and websockify.
 
55
 
 
56
Websock has built-in receive queue buffering; the message event
 
57
does not contain actual data but is simply a notification that
 
58
there is new data available. Several rQ* methods are available to
 
59
read binary data off of the receive queue.
 
60
 
 
61
The Websock API is documented on the [websock.js API wiki page](https://github.com/kanaka/websockify/wiki/websock.js)
 
62
 
 
63
See the "Wrap a Program" section below for an example of using Websock
 
64
and websockify as a browser telnet client (`wstelnet.html`).
 
65
 
 
66
 
 
67
### Additional websockify features
 
68
 
 
69
These are not necessary for the basic operation.
 
70
 
 
71
* Daemonizing: When the `-D` option is specified, websockify runs
 
72
  in the background as a daemon process.
 
73
 
 
74
* SSL (the wss:// WebSockets URI): This is detected automatically by
 
75
  websockify by sniffing the first byte sent from the client and then
 
76
  wrapping the socket if the data starts with '\x16' or '\x80'
 
77
  (indicating SSL).
 
78
 
 
79
* Flash security policy: websockify detects flash security policy
 
80
  requests (again by sniffing the first packet) and answers with an
 
81
  appropriate flash security policy response (and then closes the
 
82
  port). This means no separate flash security policy server is needed
 
83
  for supporting the flash WebSockets fallback emulator.
 
84
 
 
85
* Session recording: This feature that allows recording of the traffic
 
86
  sent and received from the client to a file using the `--record`
 
87
  option.
 
88
 
 
89
* Mini-webserver: websockify can detect and respond to normal web
 
90
  requests on the same port as the WebSockets proxy and Flash security
 
91
  policy. This functionality is activate with the `--web DIR` option
 
92
  where DIR is the root of the web directory to serve.
 
93
 
 
94
* Wrap a program: see the "Wrap a Program" section below.
 
95
 
 
96
 
 
97
### Implementations of websockify
 
98
 
 
99
The primary implementation of websockify is in python. There are
 
100
several alternate implementations in other languages (C, Node.js,
 
101
Clojure, Ruby) in the `other/` subdirectory (with varying levels of
 
102
functionality).
 
103
 
 
104
In addition there are several other external projects that implement
 
105
the websockify "protocol". See the alternate implementation [Feature
 
106
Matrix](https://github.com/kanaka/websockify/wiki/Feature_Matrix) for
 
107
more information.
 
108
 
 
109
 
 
110
### Wrap a Program
 
111
 
 
112
In addition to proxying from a source address to a target address
 
113
(which may be on a different system), websockify has the ability to
 
114
launch a program on the local system and proxy WebSockets traffic to
 
115
a normal TCP port owned/bound by the program.
 
116
 
 
117
The is accomplished with a small LD_PRELOAD library (`rebind.so`)
 
118
which intercepts bind() system calls by the program. The specified
 
119
port is moved to a new localhost/loopback free high port. websockify
 
120
then proxies WebSockets traffic directed to the original port to the
 
121
new (moved) port of the program.
 
122
 
 
123
The program wrap mode is invoked by replacing the target with `--`
 
124
followed by the program command line to wrap.
 
125
 
 
126
    `./websockify 2023 -- PROGRAM ARGS`
 
127
 
 
128
The `--wrap-mode` option can be used to indicate what action to take
 
129
when the wrapped program exits or daemonizes.
 
130
 
 
131
Here is an example of using websockify to wrap the vncserver command
 
132
(which backgrounds itself) for use with
 
133
[noVNC](https://github.com/kanaka/noVNC):
 
134
 
 
135
    `./websockify 5901 --wrap-mode=ignore -- vncserver -geometry 1024x768 :1`
 
136
 
 
137
Here is an example of wrapping telnetd (from krb5-telnetd).telnetd
 
138
exits after the connection closes so the wrap mode is set to respawn
 
139
the command:
 
140
 
 
141
    `sudo ./websockify 2023 --wrap-mode=respawn -- telnetd -debug 2023`
 
142
 
 
143
The `wstelnet.html` page demonstrates a simple WebSockets based telnet
 
144
client.
 
145
 
 
146
 
 
147
### Building the Python ssl module (for python 2.5 and older)
 
148
 
 
149
* Install the build dependencies. On Ubuntu use this command:
 
150
 
 
151
    `sudo aptitude install python-dev bluetooth-dev`
 
152
 
 
153
* Download, build the ssl module and symlink to it:
 
154
 
 
155
    `cd websockify/`
 
156
 
 
157
    `wget http://pypi.python.org/packages/source/s/ssl/ssl-1.15.tar.gz`
 
158
 
 
159
    `tar xvzf ssl-1.15.tar.gz`
 
160
 
 
161
    `cd ssl-1.15`
 
162
 
 
163
    `make`
 
164
 
 
165
    `cd ../`
 
166
 
 
167
    `ln -sf ssl-1.15/build/lib.linux-*/ssl ssl`
 
168