若者のプロトコル離れが叫ばれて久しいが、最近プロトコルは非常にホットな分野である。 目まぐるしく進化するWebに合わせ、プロトコルの世界も着実に進化している。 今までブラウザでは出来なかった事が出来るようになり、Webサービスをより安全に使えるようになった。 そしてWebのパフォーマンスを大きく改善するためにHTTP2.0も議論されている。 Webを支えるプロトコルとして、大きく分けて３つに分けられるかと思う（私の勝手なイメージ、正確な図ではありません） Webアプリケーション ブラウザが今まで出来なかったことを出来るようにしたり、Webアプリケーションの認証・認可などの機能を提供するプロトコルなど。JSやサーバサイドプログラミングで利用したりする。 WebSocket (http://tools.ietf.org/html/rfc6455) ブラウザとWebサーバの間でソケット通信を行う
実践編 目次 オリジナルの通信プロトコルを実装してみよう(Netty 実践編1) - Taste of Tech Topics オリジナルの通信プロトコルを実装してみよう(Netty 実践編2) - Taste of Tech Topics こんにちは！新しい物好きなエンジニアのツカノです。 Vert.xがますます面白いところに入ってきましたが、今回は久しぶりのNettyシリーズです。Vert.xは通信周りにNettyを利用しており、その仕組みを理解する上でも良いかと思います。 前回シリーズを掲載した後、Nettyの世界では大きな変化がありました。ついにNettyのメジャーパージョンアップであるNetty4がリリースされました。Netty4ではパッケージ名から変わっており、直接的な互換性もありません(パッケージ名やクラス名を置き替えることで、ある程度移行できます)。そのくらい大きく変わって
Intro Google が SPDY の開発を始めたのは 2009 年で、 2012 年に HTTP2.0 のドラフトとして採用されたあたりからちょっと話題になりました。 翌 2 月には新たなプロトコル QUIC の存在が Chromium のソースからリークしたのですが、しばらくは音沙汰なく。 6 月に入ってやっと Google から公式アナウンスとドキュメント類が出ました。 去年から今年にかけて立て続けに出てくる新しいプロトコルの話。 なぜ今 Web のプロトコルが見直されるのか？ 何が問題で、なぜ Google はそれらを作り変えるのか？ SPDY や QUIC は Google の独自プロトコルだけど、それは本当にただの独自プロトコルで終わらせていいのか？ 20% ルールで作ってみた Play プロジェクトでしかないのか？ こうした新しい動きには、かならず「それまで」と「今」を踏
https://docs.google.com/document/d/1lmL9EF6qKrk7gbazY8bIdvq3Pno2Xj_l_YShP40GLQE/edit?pli=1#heading=h.h3jsxme7rovm の和訳 アドバイスを頂きました mumumu-tan さんに感謝します。 Experimenting with QUIC も併せてお読みください。 http://d.hatena.ne.jp/yoya/20130630/quic QUIC Geek FAQ QUIC Geek FAQ (for folks that know about UDP, TCP, SPDY, and stuff like that) QUIC Geek FAQ (UDP, TCP, SPDY といった要素が分かる人向け) What is QUIC? QUIC とは何ですか？ QUIC is
1.QUIC仕様の公開 以前、「Googleが仕掛ける新プロトコルQUICとは何か」のブログエントリーを書いたのが2月末の事でした。それから4か月経ち、今朝Googleが初めてQUICの公表(Chromium Blog: Experimenting with QUIC)を行いました。 IE11のSPDY/3対応が判明した直後でした。なんというタイミングでしょうか。 また、近いうち（来週？）には HTTP/2.0 の Implementation Draft が公開される予定です。8月上旬には、GoogleやMicrosoft等が集まって初めての HTTP/2.0 の相互接続試験を行う予定です。ただ今HTTP関連のプロトコルが急激に進化する真っ最中です。目が離せません。 2. で、QUICとは何なのか？ 先のChromium BlogのエントリーでQUICは、 「Quick UDP Inte
みたいなものを誰かまとめてないのかな、と思ってる。ないのかな。とりあえず自分用メモ。 概要 接続後最初の電文は client => server であるべき 理由: syn_cookies, dataready, パケット数削減 (w. SYN ACK) 最初の電文は、プロトコルの magic で始めるべき 理由: gopher://host:25/ attack バージョン番号も含めるべき 何がコンパチで何が非互換か、最初からバージョン番号の解釈を明確にしておくこと 例: HTTP extensibleな構造化の手法は３種類 デリミタ方式 TLV ASN.1 PER デリミタ方式 テキストプロトコル系で一般的。ペイロード内にデリミタが出現する場合はエスケープ。 問題は遅いこと メタ情報のみデリミタでコンテンツは length というモデルも (HTTP) デリミタの定義をはっきりさせるこ
Overview Designing first-person action games for Internet play is a challenging process. Having robust on-line gameplay in your action title, however, is becoming essential to the success and longevity of the title. In addition, the PC space is well known for requiring developers to support a wide variety of customer setups. Often, customers are running on less than state-of-the-art hardware. The
Transport layer services are conveyed to an application via a programming interface to the transport layer protocols. The services may include the following features:[4] Connection-oriented communication:[5] It is normally easier for an application to interpret a connection as a data stream rather than having to deal with the underlying connection-less models, such as the datagram model of the Use
ほとんどの人がHTTPSとSSL (Secure Sockets Layer) を結びつけて考えます。SSLは1990年代半ばにNetscape社が開発した仕組みですが、今ではこの事実はあまり正確でないかもしれません。Netscape社が市場のシェアを失うにしたがって、SSLのメンテナンスはインターネット技術タスクフォース(IETF)へ移管されました。Netscape社から移管されて以降の初めてバージョンはTransport Layer Security (TLS)1.0と名付けられ、1999年1月にリリースされました。TLSが使われだして10年も経っているので、純粋な"SSL"のトラフィックを見ることはほとんどありません。 Client Hello TLSはすべてのトラフィックを異なるタイプの"レコード"で包みます。ブラウザが出す先頭のバイト値は16進数表記で0x16 = 22。 これは
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
