こんにちは。私はSergey Kamardin(セルゲイ・カマルディン)です。Mail.Ru(ロシアの電子メールサービス会社)で開発者をしています。 この記事では、どのように私がGoを使って高負荷対応のWebSocketサーバを開発したかについて説明したいと思っています。 パフォーマンス最適化のアイデアやテクニックを通じて、WebSocketの知識はあるもののGoについてはほとんど知らないという方のお役に立てれば幸いです。 1. はじめに まずは開発に至った経緯について、どうして私たちがこのサーバを必要としたのかを説明しておきましょう。 Mail.Ruには多くのステートフルなシステムがあります。ユーザのeメール保存もその1つです。システム内、およびシステムイベントの状態変更を追跡する方法にはいくつかの種類がありますが、それらは主に状態変更に関するシステム通知、または周期的なシステムのポーリ
Webアプリにリアルタイムの双方向通信が必要な場合、WebSocketを選ぶのは自然なことだと思います。では、どのツールでWebSocketサーバを構築すべきでしょうか。パフォーマンスは重要ですが、開発のプロセスも見過ごしてはなりません。パフォーマンスを基準にするだけでなく、開発のしやすさも考慮に入れるべきでしょう。今回の大合戦では、Clojure、C++、Elixir、Go、NodeJS、Rubyのそれぞれの言語によって慣用的な手法で実装されたシンプルなWebSocketサーバを比較したいと思います。 テスト内容 サーバに実装するのは、 echo と broadcast の2つのメッセージのみを扱う非常に単純なプロトコルです。echoは送信クライアントに返され、ブロードキャストは全ての接続クライアントに送信されます。そしてブロードキャストが完了すると、結果メッセージが送信者に返されます。
(訳注:2015/8/4、いただいた翻訳フィードバックを元に記事を修正いたしました。) 本題に入る前に強調しておきます。WebSocketは優れた通信プロトコルです。実際私はこの RFC6455 を、 Fanout のサービスで使っている( Zurl や Pushpin といったパーツで採用しています。Fanoutではまた、 Primus (異なるリアルタイムフレームワーク間での通信を可能とするラッパー)を利用し、 XMPP-FTWインターフェース を介したWebSocket通信をサポートしています。 しかしながら私はこれまで、多くの広く普及しているアプリケーションにかなりの時間を費やし、おかげでRESTやメッセージングパターンについては多少なりとも理解が深まってきた今、実はWebSocketを実装した典型的なWebアプリケーション(もしくはWebSocketライクな抽象化レイヤ)の大部分
http://blog.johnryding.com/post/78544969349/how-to-reconnect-web-sockets-in-a-realtime-web-app 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約2時間前 John RydingのブログでWebSocketの再接続のアルゴリズムの工夫について紹介しています。 リアルタイムウェブアプリにおいて、何らかの理由でバックエンドとの接続が切れた場合、クライアントは一定間隔で再試行するというロジックを設定(参考コード)していたとします。その場合、大量のクライアントがいて、もし長い時間接続が不能であれば、再開時にバックエンドには大量のリクエストが集中することになります。 そこでJohnがお薦めするExponential Backoff
本連載では、このTech-Sketchから「コレは!」というテーマをピックアップし、加筆修正して皆様にお届けいたします。 リアルタイムWebとSocket.IO 栄えある連載第1回は、リアルタイムWebとSocket.IOについてお届けいたします。Tech-Sketchに掲載した元ネタはこちらです。 JavaScriptとDynamic HTMLによる「動的に表示内容が更新されるWebサイト」は、JavaScript内から非同期にサーバへ接続しデータを取得する技術、いわゆるAjaxが利用できるようになったことを皮切りに、爆発的に広がりました。Google Mapsなどがその代表例です。 このGoogle Mapsは、表示する場所や縮尺を変更するといった「利用者の操作」を契機として新しいデータをサーバへ取りに行く仕組みになっています。そのためサーバ側でデータが変更されたとしても、次にデータを
最近 SPDY と WebSocket がアツいですね。 再来週の SPDY & WS 勉強会 も、定員100名に対して 参加者が 247 名とかなりアツいことになっています。 その予習というわけでもないですが、最近 WebSocket を実サービスへの 導入方法を考えながら遊んでいたので、 WebSocket の負荷分散方法について 考えていることを書いておこうと思います。 ステートフルな WebSocket アプリケーション HTTP サービスは基本的にステートレスな実装になっており、リクエストが来るたびに DBサーバーや memcached などのバックエンドから情報を取得して返していました。 この構成では Web アプリ自体は完全にステートレス化することができているので、 負荷分散機はラウンドロビン等のアプリケーションを無視した負荷分散をすることができました。 しかし、 WebSo
nginx(1.3.13)でWebSocketのプロキシを試してみました 2013/2/19にnginxが正式にWebSocketに対応したとアナウンスがあったので、試しに使ってみました。 ダウンロード・インストール ここからnginx-1.3.13をダウンロードしてきて、インストールします。 インストールオプションはあえてデフォルトで $ wget http://nginx.org/download/nginx-1.3.13.tar.gz $ tar xvf nginx-1.3.13.tar.gz $ cd nginx-1.3.13 $ ./configure $ make $ sudo make install 設定ファイルの書き換え 次にnginx.confを書き換えます。構成は リバースプロキシ: 192.168.0.8:80 バックエンドサーバ: 192.168.0.2:3000
この記事は、HTML5 Advent Calendar 2012の15日目のエントリーです。 WebSocketは、Webサーバ・ブラウザ間で双方向に通信するための仕様であり、APIとプロトコルがそれぞれ以下の規格で定義されています。 API: W3C WebSocket API プロトコル: IETF RFC 6455 - The WebSocket Protocol (日本語訳) Node.js + Socket.IO のようなライブラリを使うと割と簡単にWebSocketが使えますが、中で何が起こっているかもう少し追ってみたいという動機により、tcpdump+WireSharkによるパケットキャプチャを通してWebSocket通信の中身を調べてみました。 作業環境 サーバ側、クライアント側ともホストはWindows 7 (64ビット版) で、サーバはその上の仮想マシンとして動かしてい
Looking for a high performance, powerfull process manager for a Python project I’m working on, I stumbled on Circus on this excellent benchmark blog post. After running my own benchmark tests, I agree that the Circus + Chaussette + Meinheld stack is the way to go. High concurrency, fast response time, and socket support are the features that pulled me in. I’m switching off of Supervisord, because:
Websockets 101 written on Monday, September 24, 2012 Out of curiosity I taught the Fireteam presence server websockets as a protocol in addition to the proprietary protocol it speaks out of the box. I don't really have a usecase for websocket per-se with the server, but I thought it might make it more useful for customers that want to use the event based parts of the API with HTML5 games. This pos
Welcome to the Web Application Messaging Protocol (WAMP)! WAMP is an open application level protocol that provides two messaging patterns: Routed Remote Procedure Calls and Publish & Subscribe uses different serializers for message encoding, like: JSON MessagePack FlatBuffers CBOR and many others and can run over different transports, like: WebSocket subprotocol Raw TCP Socket Unix domain socket T
はじめに エンジニアの@ryooo321です。 よろしくお願いします。 Happy Elements株式会社では勉強会が活発に行われており、 その中の1つに「1.5時間で○○を作る」エンジニア向けワークショップがあります。(毎週開催@京都) ※ ○○は毎週かわり、設計/実装方法などは自由です。 今回はワークショップ2回(計3時間)で作成したボンバーマン風ゲームの紹介を通して、 他人とリアルタイムで遊べるゲームの可能性を感じていただければと思います。 ※ 技術的にはwebsocket、canvasを利用 ※ ライブラリ/ツールとしてNode.js、CreateJS、socket.io、coffeescriptを利用 ※ 急いで作ったのでほとんどリファクタリングされていませんmm また、おまけとして サーバーサイドでのcanvas描画とwebsocketでのバイナリメッセージについて 試してみ
はじめに ブラウザ間でP2P通信が実現できれば、ブラウザ上で動作するP2Pアプリが作れて面白そうだなーと思ったのでWebSocketを使って実現してみました。仕組みについては以下で説明していきますが、私が実現した方法は限定的で実用性が低く色々と足りない部分もあるので、軽い気持ちで読んで頂けるとありがたいですw 仕組みの概要 なぜWebSocketを使うのか 従来、Webサーバとクライアント(Webブラウザ)間で非同期に通信するにはXHR(XMLHttpRequest)を用いてきました。基本的にこのXHRは以下の図のように同一ドメインとしか通信できないという制約がありました。*1 しかし、WebSocketのthe Origin-based security modelでは異なるドメインとも通信することが可能になります。WebSocketプロトコルでは、サーバとクライアント間で接続を確立する
WebSocketって何? WebSocketは、Javascriptでサーバとリアルタイム双方向通信をする仕組みです。概要は第1回 WebSocket登場までの歴史:Jettyで始めるWebSocket超入門|gihyo.jp … 技術評論社によくまとまっています。 この記事ではWebSocketサーバを実装しながら、どういうプロトコルかを解説します。サンプルコードはWebSocket Draft 76でechoサーバーを作ってみた - いろいろな何かのものを参考にさせていただいています。ありがとうございます。 ※WebSocketプロトコルは現在ドラフトの段階なので、そのうち仕様が変わる可能性があります。この記事は20111/23時点の情報です。 プロトコル概要 WebSocketで通信を行なうおおまかな流れは次のようになります。 クライアントとサーバの間でハンドシェイクを行ない、接続
長い記事なので、先に結論だけ書いておきます。WebSocketのバイナリメッセージ機能は、これまでのインターネットのあり方をひっくり返します。「そんなの知ってるよ」という方もいるとは思います。僕も理屈では分かってたつもりだけど、実際にアプリを作ってみて、具体的にそれを感じることができたので、ちょっと長いですがどういうことなのか説明してみます。 WebSocketとは # WebSocketは、HTML5関連の中でも特に注目を集めている技術の一つです。通常のHTTP通信であればクライアントからのリクエストなしにサーバーは応答しませんが、WebSocketを使うことでクライアントとサーバーの間で双方向の通信が可能となります。これを利用することで、今後様々なリアルタイム性の高いサービスを構築することが可能になるでしょう。 そんなWebSocketですが、これまで波乱の道を歩んできました。数年前か
ちょっと気になるネタだったので同様の仕組みをオープンソースで漁ってみたのでそれを元に解説したいと思います。なので厳密にはt.freeの仕組みじゃなく「WebSocketのテザリングの仕組み」になります。 時間がない人向けに結論を書くと Macのネットワーク--Websocket1--[HTML]--Websocket2--サーバ→インターネット という接続経路になってます。 技術的にはすべての通信がサーバを通過するので傍受(覗き見)することは可能と思われます。 防ぐためには、VPNを使えば傍受出来ないですし、https://接続のブラウズであれば「どこにつないでるか」は傍受できても「どんな通信を行ったか」は傍受できなくなります。 図解:webSocketのテザリング cacooの図を2つ まずt.freeなどのクライアントソフトウエアをインストールします。Macには[有線LAN]や[無線L
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く