You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
WebSocketの扱うサービスでは、長時間のコネクション、再接続処理、プロキシ、ロードバランサなど、インフラの面で多くの問題を抱えがちです。弊社のサービス「pixiv」の9周年企画でも、この問題に直面しました。 実際にそこで構築したインフラの事例をもとに、本運用に使えるWebSocketサーバの構成について、pixivインフラ部の南川からご紹介します。 * 9周年企画 “黒歴史”をロケットで宇宙に飛ばす pixiv黒歴史 そもそも WebSocket とは? WebSocketはTCP上で動く双方向通信のための通信規格です。 Webページの読み込みで行われているような、クライアントがサーバにデータを要求し、サーバはクライアントにレスポンスを返すというHTTPの通信ルールとは違います。サーバと長時間コネクションを確立し、Socketのようにデータのやり取りを行います。そして、コネクションを
Service Workersでプッシュ通知を受信できるようになったわけですが([1]: GCM)([2]: Web Push)、Chromeではバージョン48まではGCMで通知だけができるようになっただけで、メッセージ本体は通知を受けてからService Workerでサーバから改めて受け取るような実装をする必要があったりします。 ここで、Service Workersでは、XMLHttpRequestが使えません。その代わり、XMLHttpRequest (以下、XHR)に代わるWHATWGの仕様としてFetch APIがあり、Service WorkersではこのFetch APIを使うことになっていますので、その使い方を簡単に紹介します。 Fetch API自体は、Service Workers専用のものではなく、メインスレッドでもXHRの代わりに使うことが可能です。現時点で実装し
今年の2月に WHATWG の XMLHttpRequest (XHR) の仕様に追加された responseURL プロパティが、先日 Firefox に実装された (https://bugzil.la/998076) のでそのことについて書く。 responseURL は XHR のリクエストに対するレスポンスの URL を文字列で返すプロパティで、リダイレクトが発生した場合は最終的なリダイレクト先の URL を返すようになっている。つまり Greasemonkey の GM_xmlhttpRequest にある finalUrl で取得できる情報と同じものを取得できるプロパティだと言える。 responseURL が XHR の仕様に追加される以前の状態でも、 xhr.responseType === "document" の場合に xhr.response.URL 経由で fina
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く