Skip to main content
QUICK REVIEW

[論文レビュー] HTTP Mailbox - Asynchronous RESTful Communication

Sawood Alam, Charles L. Cartledge|arXiv (Cornell University)|Jan 1, 2013
Peer-to-Peer Network Technologies参考文献 30被引用数 3
ひとこと要約

HTTP Mailbox は、ストアアンドフォワード方式のメールボックス抽象化を介して、PATCH、PUT、DELETE を含むすべての HTTP メソッドをサポートする RESTful で非同期的なメッセージングシステムを提供する。これにより、受信者が利用不能であってもクライアントがメッセージを送信できる。高い信頼性(0.01% のエラー率)を達成し、パイプライン処理とグループメッセージングをサポートすることで、分散システムにおけるネットワークオーバーヘッドを削減する。

ABSTRACT

Traditionally, general web services used only the GET and POST methods of HTTP while several other HTTP methods like PUT, PATCH, and DELETE were rarely utilized. Additionally, the Web was mainly navigated by humans using web browsers and clicking on hyperlinks or submitting HTML forms. Clicking on a link is always a GET request while HTML forms only allow GET and POST methods. Recently, several web frameworks/libraries have started supporting RESTful web services through APIs. To support HTTP methods other than GET and POST in browsers, these frameworks have used hidden HTML form fields as a workaround to convey the desired HTTP method to the server application. In such cases, the web server is unaware of the intended HTTP method because it receives the request as POST. Middleware between the web server and the application may override the HTTP method based on special hidden form field values. Unavailability of the servers is another factor that affects the communication. Because of the stateless and synchronous nature of HTTP, a client must wait for the server to be available to perform the task and respond to the request. Browser-based communication also suffers from cross-origin restrictions for security reasons. We describe HTTP Mailbox, a mechanism to enable RESTful HTTP communication in an asynchronous mode with a full range of HTTP methods otherwise unavailable to standard clients and servers. HTTP Mailbox also allows for multicast semantics via HTTP. We evaluate a reference implementation using ApacheBench (a server stress testing tool) demonstrating high throughput (on 1,000 concurrent requests) and a systemic error rate of 0.01%. Finally, we demonstrate our HTTP Mailbox implementation in a human-assisted Web preservation application called “Preserve Me!" and a visualization application called "Preserve Me! Viz".

研究の動機と目的

  • Web サービスにおける同期的でステートレスな HTTP の制限、特に標準ブラウザで利用できない PATCH、PUT、DELETE などの完全な HTTP メソッドの欠如を解消すること。
  • HTML やブラウザの制限により、非 GET/POST メソッドの使用が制限されるクライントの障壁を克服すること。
  • 送信者と受信者を分離し、サーバー障害時でもメッセージの配信を保証する、信頼性の高い非同期通信レイヤーを提供すること。
  • メッセージのパイプライン処理とブロードキャスト/マルチキャストのサポートにより、ポイントツーポイント HTTP 通信と比較してネットワークオーバーヘッドを削減し、スケーラビリティを向上させること。

提案手法

  • メッセージ(リクエスト/レスポンス)を中央のメールボックス URI に HTTP POST で送信し、それらをメッセージ本文にカプセル化する。
  • メッセージを永続化して非同期的に配信するストアアンドフォワードモデルを採用し、送信者と受信者を分離する。
  • application/http MIME タイプを使用して複数のメッセージを1つの HTTP POST リクエストに束ねることで、メッセージのパイプライン処理を実現する。
  • 1つのメールボックス送信により複数の受信者にメッセージを送信できる仕組みを提供することで、マルチキャストおよびブロードキャストメッセージングを可能にする。
  • HTTP GET を使用してメッセージを取得し、次/前/最初/最後の URI リンクを介してチェーン形式でメッセージを受信者がアクセスする。
  • 高並列処理下での取得パフォーマンス最適化のため、レスポンスのページネーション(計画中)を実装する。

実験結果

リサーチクエスチョン

  • RQ1制限されたクライント環境でも、すべての HTTP メソッドをサポートする標準 HTTP の上に、RESTful で非同期的なメッセージングシステムを構築できるか?
  • RQ2高い並列処理や途切れの生じるネットワーク環境下でも、そのシステムのパフォーマンスと信頼性はどのようにスケーリングするか?
  • RQ3パイプライン処理とグループメッセージングは、ポイントツーポイント HTTP 通信と比較して、ネットワークオーバーヘッドをどの程度削減できるか?
  • RQ4中央集権的なメールボックスを経由する間接的な仕組みが、メッセージ配信の遅延とシステム可用性に与える影響はどの程度か?

主な発見

  • 83,000 件を超える送信および取得操作を高並列処理下で実行した参照実装では、システム全体のエラー率がわずか 0.01% にとどまった。
  • システムは高いスループットを示し、1,000 件の同時リクエストを効率的に処理でき、並列処理レベル 1 での GET リクエストのラウンドトリップ時間は 300–400 ms であった。
  • application/http MIME タイプを用いたメッセージパイプライン処理は、特にグループメッセージングのシナリオでネットワークサイクルを顕著に削減した。
  • システムは送信者と受信者を効果的に分離し、受信者が利用不能であってもブロッキングなしでメッセージ配信を可能にした。
  • HTTP Mailbox モデルにより、ブラウザやサーバーの制限により以前は利用できなかった RESTful HTTP メソッド(例:PATCH、PUT)を完全に活用できるようになった。
  • 実装は「Preserve Me!agger」というウェブ保存アプリケーションに成功裏に統合され、実世界での有用性が実証された。

より良い研究を、今すぐ始めましょう

論文設計から論文執筆まで、研究時間を劇的に削減しましょう。

クレジットカード登録不要

このレビューはAIが作成し、人間の編集者が確認しました。