HTTPの拡張CONNECTメソッド について復習する - ASnoKaze blog
HTTPにはCONNECTメソッドというものがあります、このメソッドを使ってProxyと接続しHTTPメッセージを中継してもらいます。 拡張CONNECTメソッドは、HTTPメッセージ以外のデータを中継してもらうのに使用します。特にHTTP/2やHTTP/3では特定のストリームを、データのトンネル用にするために、拡張CONNECTメソッドを使います。 例えば、WebTransport over HTTP/3なども拡張CONNECTメソッドを利用します。そのため、拡張CONNECTメソッドをサポートしてない単純なHTTP/3 ProxyとはWebTransport通信は行ったりは出来ません(Datagramらへんも絡む)。 今回は、その拡張CONNECTメソッド (Extended CONNECT Method) について見ていきます。 利用例 拡張CONNECTメソッドはもともと、WebS
spindle-localproxy というローカルHTTPプロキシを開発しました【Part2】 - セキュアスカイプラス
こんにちは、SSTでWeb脆弱性診断用のツール(スキャンツール)開発をしている坂本(Twitter, GitHub)です。 普段は診断向けのスキャンツールを開発していますが、今年(2019年)の3月～8月にかけて、SST内部で使用する独自ローカルHTTPプロキシ「spindle-localproxy」を開発しました。 本記事(Part2)では公開しても差し支えない範囲で技術的な内容を紹介します。 開発の経緯や簡単な機能説明については、 Part1 を参照してください。 (以下、特に断りがない場合は「ローカルHTTPプロキシ」を「HTTPプロキシ」と表記します。) Part2. 技術的な内容紹介 今回開発したHTTPプロキシは、診断サービスの事前調査における画面遷移図作成をサポートする社内ツールになります。 Part2 では技術選定や要件で考慮したポイント、HTTPプロキシの実装とWebSo
サーバサイドpush技術としてのWebsocketとServer-sent eventsの特徴比較 - Qiita
サーバサイドpush技術として見たときのWebsocketとServer-sent events(SSE)の特徴を整理したい。 どちらもサーバからpushできる技術 Websocketは双方向通信・SSEはサーバからクライアントへの単一方向通信 SSEはただのHTTPストリーミング WebsocketはHTTPを拡張したプロトコル 主な用途、チャット・リアルタイム通知・共同編集などリアルタイム通信 ブラウザのサポート状況 WebsocketはIE10以降のモダンブラウザが対応している SSEはIE,Edgeは対応していないが、polyfillで対応可能。 既存の開発スタックとの親和性 SSEはHTTPそのものなので、ストリームレスポンスを返せるプラットフォームなら導入が容易。素のPHPでも25行で実装可能。 Websocketは独自プロトコルなので、対応したウェブフレームワークが必要 SS
Server Sent Events(SSE)の使いどころと使い方 | GREE Engineering
Flameの箱を捨ててしまったためどうやって送り返すか困っています。@kyo_agoです。 今日は2014年6月にβ公開したGREEチャットで通信に使用しているSSEを紹介したいと思います。 SSEとは SSEとはServer-Sent Eventsの略でW3Cで提案されているhtml5関連APIの一種です。 これはサーバとの通信やJavaScript APIを中心としたもので、サーバからPush通信を行うための仕様です。 サーバからPush通信に関してはこれまでもCometやWebSocketが存在しましたが、SSEは互換性や効率などの点でそれ以外の技術に対する特徴があります。 ここからは具体的な仕様や、実際に使用した場合の感想などを紹介したいと思います。 通信方式 SSEはHTTP/1.1を使用し、Content-Type: text/event-streamで通信を行います。 基本的
ChromeがWebSockets over HTTP/2に対応したので試す (RFC8441) - ASnoKaze blog
2018/09/19追記 RFC 8441 として標準化されました 以前書いたとおり、Websockets over HTTP/2の仕様である「Bootstrapping WebSockets with HTTP/2」が現在標準化が進められている。 asnokaze.hatenablog.com これにより、複数のWebsocket通信が1つのTCPコネクションに束ねられる。 一つのページで複数WebSocketを使っていたり、複数タブを開いて各ページでWebSocketを利用しているとどうしてもコネクションの本数が多くなってしまう。様々なメリットがあるが、コネクションの数がへらせるのはサーバ側でも嬉しい部分がある。 もちろんひとつに束ねられたWebSocketをばらして処理をする必要があり、サーバやProxy側の実装が整う必要はある。 さて、このWebsockets over HTTP/
How JavaScript works: Deep dive into WebSockets and HTTP/2 with SSE + how to pick the right path
This is post # 5 of the series dedicated to exploring JavaScript and its building components. In the process of identifying and describing the core elements, we also share some rules of thumb we use when building SessionStack, a JavaScript tool for developers to identify, visualize, and reproduce web app bugs through pixel-perfect session replay. If you missed the previous chapters, you can find t
nginxをWebSocketのリバースプロキシとして使う - the glue
経緯 WebSocketを使ったアプリケーションを作ったが、ポートが80しか使えない nginxでどっちも80に流したい ポイント / はまり所 WebSocketのプロキシにはUpgradeヘッダ(HTTP 1.1)への対応が必要 Upgradeヘッダへの対応は nginx v1.3.13以降 参考: WebSocket proxying 厳しい条件から先に書く デフォルトだと30秒通信がないと切断される（！） nginxでリバースプロキシしているときだけ一定時間で接続が切れるので何かと思えば、 普通のHTTPの通信と同様に30秒（だったはず）通信がなかった場合はタイムアウトってことで自動でコネクションを切ってくれていたみたい。 ping/pongを30s以内にやればいいんだろうけど、とりあえず5分に設定。 config server { listen *:80 default_serv
リアルタイム通信で利用されるプロトコルと手法 - tech.guitarrapc.cóm
NOTE: 本記事はすでに内容が古く、今読んでも役に立つ度合いはほぼないです。 本記事は、先日社内勉強会のために準備した、Webサービスのリアルタイム通信周りのまとめシリーズ の1つを転載して公開するものです。 まだまだわかっていないことが多いので、ぜひぜひ間違っている点などにご指摘いただければと思い公開します。 ぜひぜひ優しくマサカリをいただけると泣いて喜びます！ 目次 目次 はじめに プロトコルと手法 前世代のやり方であるComet について Polling 系 Streaming 系 過渡期といわれてる手法 将来有望といわれてる手法 Polling メリット デメリット 向いているシーン Long Polling (Comet) Polling の発展版 メリット デメリット LongPolling 自体は双方向通信ではない 接続が閉じられるケース 向いているシーン Server S
あなたにWebSocketは必要ないかも | POSTD
(訳注：2015/8/4、いただいた翻訳フィードバックを元に記事を修正いたしました。) 本題に入る前に強調しておきます。WebSocketは優れた通信プロトコルです。実際私はこの RFC6455 を、 Fanout のサービスで使っている( Zurl や Pushpin といったパーツで採用しています。Fanoutではまた、 Primus （異なるリアルタイムフレームワーク間での通信を可能とするラッパー）を利用し、 XMPP-FTWインターフェース を介したWebSocket通信をサポートしています。 しかしながら私はこれまで、多くの広く普及しているアプリケーションにかなりの時間を費やし、おかげでRESTやメッセージングパターンについては多少なりとも理解が深まってきた今、実はWebSocketを実装した典型的なWebアプリケーション（もしくはWebSocketライクな抽象化レイヤ）の大部分
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer
CDNの仕組み（JANOG36）