[発表]Amazon API GatewayでWebsocketが利用可能 | Amazon Web Services
Amazon Web Services ブログ [発表]Amazon API GatewayでWebsocketが利用可能 本日より、任意のサーバーをプロビジョニングして管理することなく、Amazon API GatewayでWebSocket APIを使用して双方向通信アプリケーションを構築できます。 HTTPベースのAPIは、リクエスト/レスポンスモデルを使用して、クライアントがサービスにリクエストを送信し、サービスがクライアントに同期して応答します。 WebSocketベースのAPIは本質的に双方向です。 これは、クライアントがメッセージをサービスに送信し、サービスが独立してメッセージをクライアントに送信できることを意味します。 この双方向の振る舞いにより、クライアント/サーバーとのやりとりがより豊富になります。これは、明示的なリクエストをする必要のないクライアントにデータをプッシュ
![[発表]Amazon API GatewayでWebsocketが利用可能 | Amazon Web Services](https://cdn-ak-scissors.b.st-hatena.com/image/square/0fc257e8ac5c0a4234f0ec8727a86934bb55480e/height=288;version=1;width=512/https%3A%2F%2Fd2908q01vomqb2.cloudfront.net%2F827bfc458708f0b442009c9c9836f7e4b65557fb%2F2020%2F06%2F03%2FBlog-Post_thumbnail.png)
TCP over WebSocket & IAP - Hateburo: kazeburo hatenablog
Googleのhuproxyみたいなもので、任意のprotocolが通しやすく、Google Cloud Load BalancingのIdentity aware proxyに対応したものが欲しかったので、作ってみた。 github.com github.com GCPの中のMySQLに対して、service accountで認証して接続するイメージとしては以下のようになる。 server側 pathとforward先の設定を行うmapファイルをまずつくる mysql,10.0.x.x:3306 ssh,127.0.0.1:22 起動 $ wsgate-server --listen 0.0.0.0:8080 --map map-server.txt これで、 ws://example.com/proxy/mysql にWebSocketで通信を行うと 10.0.x.xの3306 に対し
CentOS7 + Apache でサブディレクトリに HackMD を公開する - Qiita
HackMD 超便利ですよね。PCとスマホで同時に開き、編集がリアルタイムに同期するさまを見たときは感動＆興奮しました。 そんな HackMD を職場のオンプレミス環境に導入したときの備忘録です。そのサーバーではすでに Apache Web Server が動いているので、リバースプロキシを使ってサブディレクトリに公開します。 条件 CentOS 7.4 Apache 2.4 公開URL: https://example.com/hackmd/ HackMD データ保存先: MySQL HackMD 認証方法: GitLab OAuth のみ HackMD インストール ※ 公式の README 通りに進めます Node.js, npm をインストール: sudo yum install -y nodejs npm MySQL にて HackMD 用のユーザーおよびデータベースを作成 Gi
Journey Into WebSockets Security
One subject that is often mentioned in talks about WebSockets security, is how WebSockets does not implement authentication/authorization in the protocol. This might not be as familiar because when the original research was done, there were not many applications using WebSockets. I wanted to demonstrate what this pattern looks like with an application that was using WebSockets for a critical appli
The Road to WebSockets
During the 1990s, the web rapidly grew into the dominant way to exchange information. Increasing numbers of users became accustomed to the experience of browsing the web, while browser providers constantly released new features and enhancements. The first realtime web apps started to appear in the 2000s, attempting to deliver responsive, dynamic, and interactive end-user experiences. However, at t
WebSocket大合戦：Clojure、C++、Elixir、Go、NodeJS、Ruby | POSTD
Webアプリにリアルタイムの双方向通信が必要な場合、WebSocketを選ぶのは自然なことだと思います。では、どのツールでWebSocketサーバを構築すべきでしょうか。パフォーマンスは重要ですが、開発のプロセスも見過ごしてはなりません。パフォーマンスを基準にするだけでなく、開発のしやすさも考慮に入れるべきでしょう。今回の大合戦では、Clojure、C++、Elixir、Go、NodeJS、Rubyのそれぞれの言語によって慣用的な手法で実装されたシンプルなWebSocketサーバを比較したいと思います。 テスト内容 サーバに実装するのは、 echo と broadcast の2つのメッセージのみを扱う非常に単純なプロトコルです。echoは送信クライアントに返され、ブロードキャストは全ての接続クライアントに送信されます。そしてブロードキャストが完了すると、結果メッセージが送信者に返されます。
wearewizards.io
Buy this domain. wearewizards.io 2020 Copyright. All Rights Reserved. The Sponsored Listings displayed above are served automatically by a third party. Neither the service provider nor the domain owner maintain any relationship with the advertisers. In case of trademark issues please contact the domain owner directly (contact information can be found in whois). Privacy Policy
PornhubはWebSocketを使ってAdBlockを回避している
BugReplay あるWeb開発者が、開発のためにchromeで通信内容をキャプチャしたいと考えchrome.webRequestを使ったが、WebSocket経由の通信は得られないことを発見した。さっそくこれをバグ報告した。 その後、インターネット上でわいせつ動画を頒布する大手Webサイトとして有名なPornhubの運営会社であるMindGeek社の社員がこのバグを修正しないようコメントした。 不思議に思って調べてみると、PornhubはWebSocketを使って広告データをやり取りすることで、AdBlock系のブラウザー拡張による広告除去を回避していることが判明した。 なお、この記事を公開して程なくして、AdBlock PlusとuBlock OriginはPornhubに対するWebSocket経由の広告除去も実装した。 技術的に可能であることを示すことと、実際に労力を割いてまで実
オープンソースなリアルタイムチャットシステム "respass" を3週間で作った - Sketchglass Blog
WebSocketを用いたオープンソースなリアルタイムチャットシステムrespassをリリースしました。 TL; DR 無職2人が3週間で https://respass.sketch-glass.io/ を作りました。 ソースコードはGitHub上で公開されています。 github.com 自己紹介 @minamorl 無職 Pythonエンジニア GitHub @seanchas_t 無職 C++/TypeScriptエンジニア GitHub はじめに この記事は主に技術者に向けて書かれていますが、そうでない方にも読めるような表現を重視しています。難解な用語にはなるべく注釈をいれました。技術的な話よりも「無職2人がいかにして3週間で作り上げたのか？」という開発フローの話に重きをおいたので、非技術者の方にも楽しく読んでいただけると思います。 なぜ作ったか オープンソースなチャット 近年、
ブラウザプッシュ通知とユーザー個別に内容を送信する実装方法 in GAMY - Qiita
ブラウザプッシュ通知が流行りだした Webプッシュ、ブラウザプッシュなどと呼ばれる機能はブラウザのPush APIを使い実装され、現在ChromeとFirefoxで使えるようになっています。 毎週のように新たなブラウザプッシュが送れるサービスが登場していますが、基本的には一律ですべてのユーザーに送信するものが多いように感じます。 その中でもFaceBookはユーザー個別にネイティブアプリと同様の内容でブラウザにプッシュ通知を送っています。 ユーザー個別で通知内容をカスタマイズしたいのと、 その辺のサービスを使ってロックインされると困るので、FaceBookのコードを参考にしつつ自分で実装してみました。 ChromeとFirefoxで微妙にPushの送り方が違うので、今回はGCM（Google Cloud Messaging）用の解説です。 Pushを送ってみるとこんな感じ Service
Web Push Protocol - steps to phantasien
“Generic Event Delivery Using HTTP Push” なる RFC を知った。 JavaScript の Push API をネットワークレベルでどう実現するか決めるものらしい。 Push API, システムが提供する GCM なんかのラッパーだと思い込んでいた。 Chrome の現状はそのようだけど、標準的にはスタック全体を定義しようとしている模様。 仕様を書いているのは Mozilla の人。えらい。 Web Push は HTTP/2 の上に定義されており、PUSH_PROMISE で UA にメッセージを送る。 TCP で現実的なプッシュを作れるとは思っていなかったので驚いた。 ざっと調べてみたところ GCM も TCP ベースらしい。 接続を保つべく適当な間隔で heartbeat していると、世間の資料にはある。 SMS など cell networ
あなたにWebSocketは必要ないかも | POSTD
(訳注：2015/8/4、いただいた翻訳フィードバックを元に記事を修正いたしました。) 本題に入る前に強調しておきます。WebSocketは優れた通信プロトコルです。実際私はこの RFC6455 を、 Fanout のサービスで使っている( Zurl や Pushpin といったパーツで採用しています。Fanoutではまた、 Primus （異なるリアルタイムフレームワーク間での通信を可能とするラッパー）を利用し、 XMPP-FTWインターフェース を介したWebSocket通信をサポートしています。 しかしながら私はこれまで、多くの広く普及しているアプリケーションにかなりの時間を費やし、おかげでRESTやメッセージングパターンについては多少なりとも理解が深まってきた今、実はWebSocketを実装した典型的なWebアプリケーション（もしくはWebSocketライクな抽象化レイヤ）の大部分
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - derhuerst/tcp-over-websockets: Tunnel TCP through WebSockets.
GitHub - hashrocket/websocket-shootout: A comparison of websocket servers in multiple languages and frameworks
WebRTC SFU Sora 3.0 新機能紹介 Part.3
Inside Websockets
@mono0926のマイページ - Qiita
Applicative 2016
GitHub - googlearchive/Propel: A library to support developers implementing Web Push notifications
GitHub - mercari/gaurun: General push notification server in Go
