質問: ポンド:websocketを処理するように構成する websocketリクエストを処理するように ポンド を構成することは可能ですか?そうでない場合、リバースプロキシの最良の代替手段は何ですか?ポンドまたは同等の軽量リバースプロキシを使用したいのですが。
回答: @ghotiの答えはうまく機能し、提案されているようにstunnelを使用することに固執するでしょうが、それでもこの問題は私を悩ませたので、詳細には触れずにいくつかの実験を行ったと主張した@jandvorakのコメントを拡張します。次の単純なpython websocketサーバーを使用しました。これは https://gist.github.com/jkp/3136208 から派生しています。import struct import socketserver from base64 import b64encode from hashlib import sha1 from mimetools import message from stringio import stringio class websocketshandler(socketserver.streamrequesthandler): magic = '258eafa5-e914-47da-95ca-c5ab0dc85b11' def setup(self): socketserver.streamrequesthandler.setup(self) print "connection established", self.client_address def handle(self): data = self.request.recv(1024).strip() headers = message(stringio(data.split('\r\n', 1)[1])) if headers.get("upgrade", none) != "websocket": return print 'handshaking...' key = headers['sec-websocket-key'] digest = b64encode(sha1(key + self.magic).hexdigest().decode('hex')) response = 'http/1.1 101 switching protocols\r\n' response += 'upgrade: websocket\r\n' response += 'connection: upgrade\r\n' response += 'sec-websocket-accept: %s\r\n\r\n' % digest self.request.send(response) length = ord(self.rfile.read(2)[1]) & 127 if length == 126: length = struct.unpack(">h", self.rfile.read(2))[0] elif length == 127: length = struct.unpack(">q", self.rfile.read(8))[0] masks = [ord(byte) for byte in self.rfile.read(4)] decoded = "" for char in self.rfile.read(length): decoded += chr(ord(char) ^ masks[len(decoded) % 4]) print decoded self.request.send(chr(129)) length = len(decoded) if length <= 125: self.request.send(chr(length)) elif length >= 126 and length <= 65535: self.request.send(126) self.request.send(struct.pack(">h", length)) else: self.request.send(127) self.request.send(struct.pack(">q", length)) self.request.send(decoded) self.finish() if __name__ == "__main__": server = socketserver.tcpserver( ("localhost", 9000), websocketshandler) try: server.serve_forever() except keyboardinterrupt: print "got ^c" server.server_close(); print "bye!" そして私はそれを http://www.websocket.org/echo.html から借りた次のhtmlと組み合わせました<!doctype html> <meta charset="utf-8" /> <title>websocket test</title> <script language="javascript" type="text/javascript"> var wsuri = "ws://localhost:9000/"; var output; function init() { output = document.getelementbyid("output"); testwebsocket(); } function testwebsocket() { websocket = new websocket(wsuri); websocket.onopen = function(evt) { onopen(evt) }; websocket.onclose = function(evt) { onclose(evt) }; websocket.onmessage = function(evt) { onmessage(evt) }; websocket.onerror = function(evt) { onerror(evt) }; } function onopen(evt) { writetoscreen("connected"); dosend("websocket rocks"); } function onclose(evt) { writetoscreen("disconnected"); } function onmessage(evt) { writetoscreen('<span style="color: blue;">response: ' + evt.data+'</span>'); websocket.close(); } function onerror(evt) { writetoscreen('<span style="color: red;">error:</span> ' + evt.data); } function dosend(message) { writetoscreen("sent: " + message); websocket.send(message); } function writetoscreen(message) { var pre = document.createelement("p"); pre.style.wordwrap = "break-word"; pre.innerhtml = message; output.appendchild(pre); } window.addeventlistener("load", init, false); </script> <h2>websocket test</h2> <div id="output"></div> </html> これはうまく機能したので、次の構成エントリを使用してポンドを中央に配置しました。listenhttp address 127.0.0.1 port 9999 service backend address 127.0.0.1 port 9000 end end end htmlのポートを9000から9999に変更しました。その後、変更すると機能しなくなりました。wiresharkでトラフィックを分析したところ、プロトコルを切り替えるhttp101リクエストが正しく転送されることがわかりました。ただし、後続の最初のwebsocketパケットがポンド単位で転送されることはありません。これは、pythonサーバースクリプトのprint出力によって確認されます。サーバースクリプトは、ポンドが中央にあるwebsocket rocksメッセージを受信しません。ポンドがwebsocketメッセージを受信するたびに、メッセージをドロップし、代わりにe414 headers: request uri too longをsyslogに書き込みます。パウンドのソースコードを見ると、これはパウンドがhttpヘッダーを解析しようとしているためと思われます。これを行うには、最初にwebsocketメッセージで見つからないeolを検索し、メッセージを無効としてドロップします。したがって、opの質問に対する答えは確かに次のように思われます。ポンドはwebsocketを実行できません。この問題についてポンドリストにメールを書きました: http://www.apsis.ch/pound/pound_list/archive/2014/2014-01/13888449240