大量接続に耐えるWebSocketアプリケーションサーバ構築のコツ - pixiv inside [archive]
WebSocketの扱うサービスでは、長時間のコネクション、再接続処理、プロキシ、ロードバランサなど、インフラの面で多くの問題を抱えがちです。弊社のサービス「pixiv」の9周年企画でも、この問題に直面しました。 実際にそこで構築したインフラの事例をもとに、本運用に使えるWebSocketサーバの構成について、pixivインフラ部の南川からご紹介します。 * 9周年企画 “黒歴史”をロケットで宇宙に飛ばす pixiv黒歴史 そもそも WebSocket とは？ WebSocketはTCP上で動く双方向通信のための通信規格です。 Webページの読み込みで行われているような、クライアントがサーバにデータを要求し、サーバはクライアントにレスポンスを返すというHTTPの通信ルールとは違います。サーバと長時間コネクションを確立し、Socketのようにデータのやり取りを行います。そして、コネクションを
![大量接続に耐えるWebSocketアプリケーションサーバ構築のコツ - pixiv inside [archive]](https://cdn-ak-scissors.b.st-hatena.com/image/square/95f08ea3414673bb0131022fbc9dc354bb7483ba/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fd%2Fdevpixiv%2F20161129%2F20161129204837.png)
Websocket Shootout: Clojure, C++, Elixir, Go, NodeJS, and Ruby
Websocket Shootout: Clojure, C++, Elixir, Go, NodeJS, and Ruby by Jack Christensen on September 1, 2016 When a web application has a requirement for real time bidirectional communication, websockets are the natural choice. But what tools should be used to build a websocket server? Performance is important, but so is the development process. A performance benchmark alone is not enough. We also need
サーバからクライアントに送信する技術 - WebSocketを中心に - Qiita
Webでのプッシュ技術 HTTPはクライアント（ブラウザ）からリクエストしてサーバからレスポンスが返る一問一答型のプロトコルなので、基本的にはサーバ側からブラウザに新着情報をリアルタイムで通知（プッシュ）できるようにはできていません。 しかしそれでもプッシュをしたいという場合にどうするかという話が出てきます。やり方には以下のようなものがあります。 ポーリング クライアントからサーバに定期的に新着を問い合わせるようにします。 最も原始的かつ確実なやり方。欠点は、最大でポーリング間隔の分だけ通知が遅延しうることです。 ロングポーリング（“COMET”） ポーリングなのですが、問い合わせを受けたサーバは新着情報がなければレスポンスを返すのをしばらく保留します。 そのあいだに新着情報が発生すれば即座にレスポンスを返しますし、一定時間経過したら何もなかったとレスポンスを返しましょう。 飛び交う通信内
WebSocket と ActionCable - Qiita
序 Rails5 Meetup 発表資料 はじめに 学生の頃に Socket.IO でゲームを作ってた Rails は業務でコントローラに API 生やす程度 rspec が全然わからん 無茶振り yuku 「mizchi なら ActionCableでなんか作れるでしょ」 なんか作った 今日の発表内容 WebSocket の現状 ActionCable 既存機能のRails5の拡張については @takashi に任せる 1. WebSocket WebSocketとは Webブラウザで扱えるTCP Socket抽象 HTTP1.1と比べて並列/高頻度イベントの効率が良い プッシュ配信 今までWebSocket が使えなかった背景 昔話 未対応ブラウザが多すぎて、フォールバック必要 まともな Fallback は、ほぼ Socket.IO の特権 ロードバランサが辛い 二度目以降のリクエス
「Socket.IO は必要か?」または「WebSocket は通るのか?」問題について 2016 年版 | blog.jxck.io
Intro 「Socket.IO 使ったほうがいいですか?」 という主旨の質問をもらった。 これは、 WebSocket が繋がらない環境に向けて、フォールバック機能を有する Socket.IO にしておいた方が良いのかという意味である。 WebSocket が出てきた当初と比べて、 Web を取り巻く状況は変わったが、変わってないところもある。 念のためと Socket.IO を使うのもよいが、「本当に必要なのか」を問うのは重要である。 Rails も ActionCable で WebSocket に対応し、ユーザも増えるかもしれないことも踏まえ、 ここで、もう一度現状について、把握している範囲で解説しておく。 "繋がらない" とは 最初に、なぜ 繋がらない ことがあるのかを、きちんと把握したい。 まず WebSocket の有史全体をみれば、繋がらないとして語られていた現象は、大きく
[Rails5]Action Cableを試してみる - Qiita
# bundle list Gems included by the bundle: * actioncable (0.1.0 849278d) * actionmailer (5.0.0.alpha c35c0c4) * actionpack (5.0.0.alpha c35c0c4) * actionview (5.0.0.alpha c35c0c4) * activejob (5.0.0.alpha c35c0c4) * activemodel (5.0.0.alpha c35c0c4) * activerecord (5.0.0.alpha c35c0c4) * activesupport (5.0.0.alpha c35c0c4) * arel (7.0.0.alpha 14df08d) * binding_of_caller (0.7.2) * builder (3.2.2)
![[Rails5]Action Cableを試してみる - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/4cad9f9a72054f43b9c79be4c2a206a45ed8b387/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCUmFpbHM1JTVEQWN0aW9uJTIwQ2FibGUlRTMlODIlOTIlRTglQTklQTYlRTMlODElOTclRTMlODElQTYlRTMlODElQkYlRTMlODIlOEImdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZ0eHQtY2xpcD1lbGxpcHNpcyZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPWEzYTRmMjUwNjI2MDYzMDI0MTQ5ODliOWE4ZWMzMGYw%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwYmlzcXVlJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz03YWNmNmMzZDE0ZGRmZDE4Zjk0NWYzNzM2Y2RhYzY5YQ%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D4faf0da41045f5ad7744b9d4ef7a95b7)
MQTTとJavaScript - @ledsun blog
MQTTってなに？ PUB/SUBプロトコルです。 HTTPと同じレイヤーです、主にTCP上で動きます。 WebSocket上でも使えます。 温度計などのセンサーの計測値を集めるM2MプロトコルとしてIBMに開発されました。 なぜMQTTなの？ 公式には 小さいコンピューター（Rasberry PiやArduinoなど）が安価に開発できる （将来）センサーを載せた小さいコンピューターがIPネットワーク上に乗る データ収集サーバーとTCP/IPで直接やりとりしたい 電力が小さく低スペックなマシンで、扱いやすいプロトコルが必要 個人的には 仕様が短い 公式の日本語仕様がある 動きを確かめられる実装が既にある の点に魅力を感じています。 MQ Telemetry Transport (MQTT) V3.1 プロトコル仕様 PUB/SUBについての簡素な説明 PUB/SUBとは、Publisher
Socket.IO: the cross-browser WebSocket for realtime apps.
Socket.IOBidirectional and low-latency communication for every platform PerformantIn most cases, the connection will be established with WebSocket, providing a low-overhead communication channel between the server and the client. ReliableRest assured! In case the WebSocket connection is not possible, it will fall back to HTTP long-polling. And if the connection is lost, the client will automatical
WebSocketを再接続するアルゴリズムの工夫 - ワザノバ | wazanova
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
Webアプリ開発者のためのHTML5セキュリティ入門
Enterprise x HTML5 Web Application Conference 2014の発表資料です。Read less
Configuring & Optimizing WebSocket Compression - igvita.com
By Ilya Grigorik on November 27, 2013 Good news, browser support for the latest draft of “Compression Extensions” for WebSocket protocol — a much needed and overdue feature — will be landing in early 2014: Chrome M32+ (available in Canary already), and Firefox and Webkit implementations should follow. Specifically, it enables the client and server to negotiate a compression algorithm and its param
2013 WebRTC node
2. はじめに • 本資料は以下の情報を参考に、作成しています。 – WebRTC 本家のサイト • http://www.webrtc.org/ – HTML5 ROCKS • http://www.html5rocks.com/en/tutorials/webrtc/basics/ – WebRTC for Beginners Muaz Khan • https://www.webrtc-experiment.com/docs/webrtc-for-beginners.html • https://github.com/muaz-khan/WebRTC-Experiment – WebRTC Conference 2013 Atlanta • http://www.webrtcworld.com/conference/west/default.aspx • http://images.
最速最強Webサーバーアーキテクチャ - Qiita
POST /post HTTP/1.1 Host: localhost Content-Type: application/x-www-form-urlencoded Content-Length: 7 foo=bar 1行目は request-line で、 method URI HTTP-version の形をしています。URIはホストを含めた絶対URIの場合と、ホストを含めない絶対パスの場合がありますが、絶対パスの方が一般的です。 2行目から空行までが request-header です。各行は field-name: field-value の形をしています。 field-name は大文字小文字を区別しません。 request-line から request-header とそれに続く空行まで、改行は CR LF になってます。Windowsでよく見る改行コードですね。 meth
GitHub - future-azure/redom: A Distributed Object based Server-Centric Web Application Framework.
Create a Redom connection class A Redom connection class is where you write the scripts to manipulate the browser-side objects from server. The Redom connection class must include module Redom::Connection. An instance of Redom connection class will be created when the connection between browser and Redom server is established. There are three methods in Redom::Connection that can be overridden to
これからの Web の話をしよう。 (次世代 Web セッション @ CROSS2013) - Block Rockin’ Codes
update 2013/1/13 終了したので録画やログを追加 intro 2013/1/18(Fri) に開催される CROSS2013 にて、「次世代 Web セッション」というセッションを担当させていただくことになりました。 次世代 Web セッション 今日はこのセッションの内容と、このセッションで自分がやりたいと思っていることについて書こうと思います。 Theme このセッションは「次世代 Web セッション」というタイトルとし、主にいま起こっている Web の変化(リアルタイム Web, HTTP2.0 の登場 など)について、 「何が起こっているのか」 「どこに向かっているのか」 を、 「プロトコル編」(1h) 「アーキテクチャ編」(1h) の 2 つのセッションに分けて議論したいと思っています。 (枠自体は 「次世代 Web セッション」の 1 つですが、内容的には 2 つの
The Web Application Messaging Protocol — Web Application Messaging Protocol version 2 documentation
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
Node.jsによるPusherクローン「Keima」をリリースしました #codefirst - みずぴー日記
http://keima.herokuapp.com/ 「えーpolling!? pollingが許されるのは小学生までだよねー、キャハハハ」というわけでpush通知にWebSocketをお使いのみなさま、こんにちは。 しかし、毎回、WebSocketを扱う機能を実装するのは、いくつかの理由で面倒ですよね! WebSocketは様々なバージョンがあるので、すべてに対応するのは面倒。 同様の理由で、個別のアプリで作り込んでしまうと、WebSocketのバージョンアップに追従するのが面倒。 WebSocketは大抵別サーバになっているので、設定が面倒。 Heroku等のPaaSではWebSocketを使えないことが多い。 (2015/1/23追記: HerokuはWebSocketをサポートするようになりました) そこで、WebSocketによるpush通知に特化したWebサービス Keima
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MQTT.IO
websocketとイミュータブルインフラ、難しい話 - Togetterまとめ
Socket.io 1.0の話
