[メモ] TCP上（もしくはHTTP）にリトライ可能なアプリケーションプロトコルを実現する方法
HTTP/1.1の持続的接続においては、サーバがリクエストを受け取ったあとに異常終了したのか、リクエストを受け取らずに接続を閉じたのか判別することができない。このため、べき等性の保証がないアプリケーションにおいて、リトライを行うべきか否か自動的に判断できなくなる場合がしばしば発生する注。 リトライ可能か否か（ピアがメッセージの処理を開始した否か）を判別するには、より細かな情報交換を行う別種のプロトコルを採用しても良いが、複雑なプトロコルはパフォーマンスに悪影響を及ぼす可能性が高いので避けたいところである。 というわけで、以下本題。 pipeliningを行わないHTTP/1.1のような単純なリクエスト／レスポンス型プロトコルをそのままに、アプリケーションレイヤへのリクエスト到達可否を判定する手軽な方法としては、SO_LINGERを用いる方法がある。具体的には、以下のような形式でサーバを実装
「WebSocket, WebRTC, Socket API, … 最新Webプロトコルの傾向と対策」HTML5 Conference 2013 セッションレポート
「WebSocket, WebRTC, Socket API, … 最新Webプロトコルの傾向と対策」HTML5 Conference 2013 セッションレポート 吉田 啓二 2013年11月30日（土）に開催された「HTML5 Conference 2013」の、エヌ・ティ・ティ・コミュニケーションズ株式会社・小松健作さんによるセッション「WebSocket, WebRTC, Socket API,…最新Webプロトコルの傾向と対策」の内容をご紹介します。 最新のWebプロトコルが続々と誕生 1990年から10年間ほどは、HTTPというたった一つのプロトコルが、Web通信用のプロトコルとして使われていました。その後、HTML5という言葉が出てきてから、WebSocketやSPDY、HTTP/2.0、WebRTC、Raw Socket API、SCTP over UDP、QUICといった
[ニュース] 改造Firefoxで日米間6.5GbpsのWebアクセス。東大が世界最速達成
東京大学大学院情報理工学系研究科の平木敬教授らによる研究チームは27日、米国で開催されたスーパーコンピュータ関連の国際会議「Supercomputing 2009」（主催：IEEEコンピュータソサエティ）の「バンド幅チャレンジ」で実施した日米間の長距離ネットワークデータ転送実験で、小型PCを用いて、Webを介した6.5Gbpsのデータ転送速度を達成したと発表した。 このデータ転送実験は、東京大学と米国ポートランドの「Supercomputing 2009（SC09）」会場に設置した2台の小型PCと、10Gbpsの学術用ネットワークを使って実施した。小型PCの使用部品はすべて市販品で構成され、CPUは「Intel Core i7 940」、マザーボードは「ASUS Rampage II GENE」、ネットワークインターフェイスは「Chelsio S310」を使用。SSDとして使用する6個の「
High Performance Browser Networking - 愛と勇気と缶ビール
一部（？）に需要があったようなので、再掲。 実はまだ全部読んでおらず、物理層やトランスポート層の話を脱してアプリケーション層というかHTTPに来た所。 僕が主に興味を惹かれたのはTCP周りの話なので、その辺だけまとめる。読んだ本の要約？というのは、ヘタしたら著作権侵害というか内容そのものの引写しになってしまいそうで難しい。 話の前提 TCPは不安定で細い回線を前提として元々作られたプロトコルなので、現代の比較的安定した太い回線の上では非効率な部分が多々ある アプリケーションがデータ送り始める前にいわゆる3-way handshakeのための通信をえっちらおっちらやらないといけない。ここにかかる時間は、いかに帯域が広くともレイテンシに引っ張られてしまう。 この部分のロスはいわゆるHTTP keepaliveで回避できる、のだが... そうしてhandshakeした後にまたえっちらおっちらco
Adopting SPDY in Line – Part 1: An Overview « NAVER Engineers' Blog
We are constantly striving to improve the user experience of Line. Given the nature of Line as a communication tool, one way to do this is to reduce the time it takes to send and receive messages. Making the connection to our servers more efficient is one way to accomplish this. Until recently, Line had been using HTTP to transmit messages. HTTP, well known for its use in web browsers, has its str
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
2010-03-27
REST の欠点は何か