Pub/Subメッセージングモデルは，パブリッシュ・サブスクライブ（Publish-Subscribe）方式でメッセージを送受信するためのモデルです。 ＜この項の構成＞ (1) Pub/Subメッセージングモデルによるメッセージの送受信 (2) Pub/Subメッセージングモデルの特徴 (3) 永続化サブスクライバーの利用 Pub/Subメッセージングモデルでは，メッセージを作成して送信する送信側のクライアント（プロデューサー）をパブリッシャーといいます。また，メッセージを受信する側のクライアント（コンシューマー）をサブスクライバーといいます。 パブリッシャーから送信されたメッセージは，トピックという送信先に登録されます。トピックに登録されたメッセージは，そのトピックに対して配信を申し込んでいた一つまたは複数のサブスクライバーに配信されます。 Pub/Subメッセージングモデルでのメッセー
Go言語を使ってとっても簡単にHTTP2に対応したWebサーバを構築できる事を知りましたので勉強がてら実装してみました。 本当にとっても簡単に実装できます。 作り方の手順作り方は下記の流れです。 証明書・秘密鍵の取得Go標準のimport net/httpでWebサーバを構築http.ListenAndServeの箇所をhttp.ListenAndServeTSLに変更環境ちなみに私は下記の環境で開発しています。 Mac OS 10.12IntelliJ IDEA Community 2016.1go 1.7.1それでは順番に見ていきましょう。 テスト用サーバ証明書・秘密鍵の作成ターミナルで/usr/local/go/src/crypto/tls/にあるgenerate_cert.go --host hostnameを実行します。 ターミナルで実行 sudo go run /usr/loc
Charlie Osborne （Special to ZDNET.com） 翻訳校正： 編集部 2016-08-05 10:28 新しいプロトコルであるHTTP/2に、数千万のウェブサイトを攻撃のリスクに晒す可能性がある複数のセキュリティ問題が発見された。 サイバーセキュリティ会社Impervaは米国時間8月3日、Black Hat USAでウェブや通信システムで使用されるHTTPの最新バージョンであるHTTP/2に関連して、複数の重大なセキュリティホールが存在すると報告するレポートを公開した。 このレポート「HTTP/2: In-depth analysis of the top four flaws of the next generation web protocol」は、HTTP/2に関連する4つの脆弱性と攻撃手法について説明したものだ。現在、HTTP/2の導入数は着実に増加して
Nginxより高速、HTTP/2サーバー「H2O」：「クラウド、HTTP/2、常時TLS時代に最適化されたHTTPサーバーを目指す」 「クラウド、HTTP/2、常時TLS時代に最適化されたHTTPサーバーを目指す」というHTTPサーバーのバージョン1.6がリリースされた。前バージョンのベンチマークではNginxより性能が高い場面も見受けられる。 HTTP/2サーバー「H2O」のバージョン1.6が2015年12月4日にリリースされた。 H2Oは現在ディー・エヌ・エーに勤める奥一穂氏を中心に、2014年から開発されているWebサーバー。プロジェクトの目的として、「クラウド、HTTP/2、常時TLS時代に最適化されたHTTPサーバーを目指す」としている。H2OはMITライセンスを採用したオープンソースプロダクトで、ソースコードはGitHubで公開されている。 H2Oは、HTTP/1.0、1.1に
1. Copyright (C) 2015 DeNA Co.,Ltd. All Rights Reserved. HTTP/2時代のウェブサイト設計 DeNA Co., Ltd. Kazuho Oku 1
おはようございます。奥さん出張中の息子達との実家生活もそろそろ終了です。kjunichiです。 TL;DR https://github.com/trusterd/libtrusterd/tree/master/examples/trusterd_rs 初めに Rustも1.0がリリースされたり、rebuildfmでもRustが話題になった回もあったので、また、懲りずにやってみることにした。 libtrusterdをRustで動かそうとして学べたこと Cの文字列を扱う 以前は、 title.with_c_str(| title | unsafe { cvNamedWindow(title); } と変換していたところ、1.0以降は以下のようになった。 use with Gist Search Link https://doc.rust-lang.org/std/ffi/struct.C
1. はじめに、 今朝、こんな返事を元に kazuho さんとIPsec/TLS等バックエンド通信について議論する機会を得ました。 せっかくだから現時点での自分の考えを整理してメモとして残しておきます。 普段ちゃんとしたストーリをもったエントリーしか書いていないのですが、今回は時間がないのでちゃんとした論理的文章になっていないメモ程度のものです、あしからず。 以下、フロント側に HTTP/2 を導入した場合のバックエンド通信をどう考えるかのメモです。 2. 性能的観点 フロントにHTTP/2を導入したということは、ブラウザのHTTP HoLブロック解消が目的の一つだと思う。HTTP/2の多重化通信によってクライアントからこれまで以上の同時リクエストをさばかないといけない（だいたい初期値は同時100接続ぐらいに制限されていると思う）。 他方バックエンド側通信は、クライアント側がブラウザではな
From: Poul-Henning Kamp <phk@phk.freebsd.dk> Date: Mon, 26 May 2014 06:34:25 +0000 To: HTTP Working Group <ietf-http-wg@w3.org> Message-ID: <1282.1401086065@critter.freebsd.dk> In message <315A1736-1C33-403D-AC5F-6E488B880FAE@mnot.net>, Mark Nottingham wri tes: >The overwhelming preference expressed in the WG so far has been to work >to a tight schedule. HTTP/3 has already been discussed a bit, be
W3C HTTPワーキンググループのメーリングリストに「Please admit defeat (was: Our Schedule)」というメールが投函された。メールを投函したのは高速キャッシュサーバVarnishの開発者でありFreeBSDのカーネル開発者でもあるPoul-Henning Kamp氏。不完全な状態のHTTP/2.0を公開することはさまざまなリソースの無駄であること、HTTPのコンセプトをよりシンプルにして暗号処理やプライバシなどの問題を解決した、しっかりしたプロトコルを策定してから公開すべきだと提案している。 HTTP/2.0はGoogleの開発したSPDYと呼ばれるプロトコルをベースとした次世代のHTTPプロトコル。現在策定が進められている段階にあり、順調にいけば2015年には正式なプロトコルとして策定される見通し。しかし現在策定が進められているHTTP/2.0はいく
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
