Internet Engineering Task Force (IETF) S. Loreto
Request for Comments: 6202 Ericsson
Category: Informational P. Saint-Andre
ISSN: 2070-1721 Cisco
S. Salsano
University of Rome "Tor Vergata"
G. Wilkins
Webtide
April 2011
Known Issues and Best Practices
for the Use of Long Polling and Streaming in Bidirectional HTTP
Abstract
抽象
On today's Internet, the Hypertext Transfer Protocol (HTTP) is often used (some would say abused) to enable asynchronous, "server-initiated" communication from a server to a client as well as communication from a client to a server. This document describes known issues and best practices related to such "bidirectional HTTP" applications, focusing on the two most common mechanisms: HTTP long polling and HTTP streaming.
今日のインターネット上では、ハイパーテキスト転送プロトコル（HTTP）は、多くの場合、非同期、「サーバー開始」のサーバからクライアントへの通信だけでなく、クライアントからサーバへの通信を可能にする（一部は虐待さだと思います）が使用されています。 HTTPロングポーリングとHTTPストリーミング：この文書では、既知の問題と二つの最も一般的なメカニズムに焦点を当て、そのような「双方向HTTP」のアプリケーションに関連するベストプラクティスについて説明します。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6202.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6202で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. HTTP Long Polling . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. HTTP Long Polling Issues . . . . . . . . . . . . . . . . . 5
3. HTTP Streaming . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. HTTP Streaming Issues . . . . . . . . . . . . . . . . . . 8
4. Overview of Technologies . . . . . . . . . . . . . . . . . . . 10
4.1. Bayeux . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2. BOSH . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3. Server-Sent Events . . . . . . . . . . . . . . . . . . . . 13
5. HTTP Best Practices . . . . . . . . . . . . . . . . . . . . . 13
5.1. Limits to the Maximum Number of Connections . . . . . . . 13
5.2. Pipelined Connections . . . . . . . . . . . . . . . . . . 14
5.3. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.4. HTTP Responses . . . . . . . . . . . . . . . . . . . . . . 15
5.5. Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.6. Impact on Intermediary Entities . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. Normative References . . . . . . . . . . . . . . . . . . . 17
7.2. Informative References . . . . . . . . . . . . . . . . . . 17
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
The Hypertext Transfer Protocol [RFC2616] is a request/response protocol. HTTP defines the following entities: clients, proxies, and servers. A client establishes connections to a server for the purpose of sending HTTP requests. A server accepts connections from clients in order to service HTTP requests by sending back responses. Proxies are intermediate entities that can be involved in the delivery of requests and responses from the client to the server and vice versa.
ハイパーテキスト転送プロトコル[RFC2616]は、要求/応答プロトコルです。クライアント、プロキシ、およびサーバ：HTTPは、次のエンティティを定義します。クライアントは、HTTPリクエストを送信するために、サーバーへの接続を確立します。サーバが応答を送り返すことにより、HTTP要求を処理するために、クライアントからの接続を受け付けます。プロキシは、サーバーおよびその逆に、クライアントからの要求と応答の配信に関与することができ、中間エンティティです。
In the standard HTTP model, a server cannot initiate a connection with a client nor send an unrequested HTTP response to a client; thus, the server cannot push asynchronous events to clients. Therefore, in order to receive asynchronous events as soon as possible, the client needs to poll the server periodically for new content. However, continual polling can consume significant bandwidth by forcing a request/response round trip when no data is available. It can also be inefficient because it reduces the responsiveness of the application since data is queued until the server receives the next poll request from the client.
標準のHTTPモデルでは、サーバはクライアントとの接続を開始したり、クライアントに要求されていないHTTPレスポンスを送信することはできません。このように、サーバはクライアントに非同期イベントをプッシュすることはできません。そのため、できるだけ早く非同期イベントを受信するためには、クライアントが新しいコンテンツを定期的にサーバーをポーリングする必要があります。しかし、継続的なポーリングは、使用可能なデータがないときの旅行ラウンド要求/応答を強制することにより、かなりの帯域幅を消費することができます。サーバは、クライアントから次のポーリング要求を受信するまで、データがキューイングされているので、それはアプリケーションの応答性を低下させるので、それはまた、非効率的であることができます。
In order to improve this situation, several server-push programming mechanisms have been implemented in recent years. These mechanisms, which are often grouped under the common label "Comet" [COMET], enable a web server to send updates to clients without waiting for a poll request from the client. Such mechanisms can deliver updates to clients in a more timely manner while avoiding the latency experienced by client applications due to the frequent opening and closing of connections necessary to periodically poll for data.
このような状況を改善するために、いくつかのサーバー・プッシュプログラミングメカニズムは、近年で実装されています。多くの場合、共通のラベル「彗星」[COMET]の下にグループ化されているこれらのメカニズムは、クライアントからのポーリング要求を待たずに、クライアントへの更新を送信するためにWebサーバを有効にします。定期的にデータをポーリングするために必要な接続の頻繁な開閉のために、クライアントアプリケーションが経験する遅延を回避しながら、このようなメカニズムは、よりタイムリーに顧客に最新情報をお届けすることができます。
The two most common server-push mechanisms are HTTP long polling and HTTP streaming:
二つの最も一般的なサーバー・プッシュ・メカニズムは、HTTPロングポーリングとHTTPストリーミング、次のとおりです。
HTTP Long Polling: The server attempts to "hold open" (not immediately reply to) each HTTP request, responding only when there are events to deliver. In this way, there is always a pending request to which the server can reply for the purpose of delivering events as they occur, thereby minimizing the latency in message delivery.
HTTPロングポーリング：サーバが提供するイベントがある場合にのみ対応し、各HTTPリクエストを（すぐに返信しない）「オープンホールド」しようとします。このように、彼らが発生すると、サーバは、それによってメッセージの配信に遅延を最小限に、イベントを配信するために応答することができるために保留中の要求が常に存在します。
HTTP Streaming: The server keeps a request open indefinitely; that is, it never terminates the request or closes the connection, even after it pushes data to the client.
HTTPストリーミング：サーバーが無期限にオープン要求を保持します。つまり、それがクライアントにデータをプッシュした後も、要求を終了していないか、接続を閉じません。
It is possible to define other technologies for bidirectional HTTP; however, such technologies typically require changes to HTTP itself (e.g., by defining new HTTP methods). This document focuses only on bidirectional HTTP technologies that work within the current scope of HTTP as defined in [RFC2616] (HTTP 1.1) and [RFC1945] (HTTP 1.0).
双方向のHTTPのための他の技術を定義することが可能です。しかしながら、そのような技術は、典型的には、（新しいHTTPメソッドを定義することによって、例えば）自体をHTTPへの変更を必要とします。この文書は、[RFC2616]（HTTP 1.1）及び[RFC1945]（HTTP 1.0）で定義されるようにHTTPの現在の範囲内で動作する双方向のHTTP技術に焦点を当てています。
The authors acknowledge that both the HTTP long polling and HTTP streaming mechanisms stretch the original semantic of HTTP and that the HTTP protocol was not designed for bidirectional communication. This document neither encourages nor discourages the use of these mechanisms, and takes no position on whether they provide appropriate solutions to the problem of providing bidirectional communication between clients and servers. Instead, this document merely identifies technical issues with these mechanisms and suggests best practices for their deployment.
著者はHTTPロングポーリングとHTTPストリーミングの両方のメカニズムは、HTTPのオリジナルのセマンティックを伸ばすことと、HTTPプロトコルが双方向通信用に設計されていないことを認めます。この文書では、どちらも奨励していなかったり、これらのメカニズムの使用を阻止し、彼らは、クライアントとサーバー間の双方向通信を提供する問題に適切なソリューションを提供するかどうかにはポジションを取りません。代わりに、この文書では、単にこれらのメカニズムと技術的な問題を識別し、その展開のためのベストプラクティスを提案します。
The remainder of this document is organized as follows. Section 2 analyzes the HTTP long polling technique. Section 3 analyzes the HTTP streaming technique. Section 4 provides an overview of the specific technologies that use the server-push technique. Section 5 lists best practices for bidirectional HTTP using existing technologies.
このドキュメントの残りは以下の通り構成されています。第2節では、HTTPロングポーリング技術を分析します。第3節では、HTTPストリーミング技術を分析します。セクション4は、サーバプッシュ技術を使用して特定の技術の概要を提供します。第5節のリスト、既存の技術を用いた双方向HTTPのためのベストプラクティス。
With the traditional or "short polling" technique, a client sends regular requests to the server and each request attempts to "pull" any available events or data. If there are no events or data available, the server returns an empty response and the client waits for some time before sending another poll request. The polling frequency depends on the latency that the client can tolerate in retrieving updated information from the server. This mechanism has the drawback that the consumed resources (server processing and network) strongly depend on the acceptable latency in the delivery of updates from server to client. If the acceptable latency is low (e.g., on the order of seconds), then the polling frequency can cause an unacceptable burden on the server, the network, or both.
伝統的または「短いポーリング」手法では、クライアントはサーバーに定期的にリクエストを送信し、各要求は、任意の利用可能なイベントやデータを「プル」しようとします。イベントなしまたはデータが利用可能である場合、サーバーは、空の応答を返し、クライアントは別のポーリング要求を送信する前にいくつかの時間を待ちます。ポーリング頻度はクライアントがサーバから更新された情報を取り出すに耐えることができるの待ち時間に依存します。このメカニズムは、消費されるリソース（サーバーの処理およびネットワーク）が強く、サーバからクライアントへのアップデートの配信における許容待ち時間に依存するという欠点があります。許容されるレイテンシが低い（例えば、秒のオーダー）である場合には、ポーリング頻度は、サーバ上で許容できない負荷、ネットワーク、またはその両方を引き起こし得ます。
In contrast with such "short polling", "long polling" attempts to minimize both the latency in server-client message delivery and the use of processing/network resources. The server achieves these efficiencies by responding to a request only when a particular event, status, or timeout has occurred. Once the server sends a long poll response, typically the client immediately sends a new long poll request. Effectively, this means that at any given time the server will be holding open a long poll request, to which it replies when new information is available for the client. As a result, the server is able to asynchronously "initiate" communication.
そのような「短いポーリング」とは対照的に、「長いポーリング」は、サーバ - クライアント・メッセージ配信および処理/ネットワークリソースの使用における待ち時間の両方を最小化しようとします。サーバーは、特定のイベント、状態、またはタイムアウトが発生しただけで要求に応答することによって、これらの効率を達成します。サーバーが長いポーリング応答を送信すると、通常、クライアントはすぐに新しいロングポーリング要求を送信します。事実上、これは、任意の時点で、サーバが新しい情報がクライアントのために利用可能であるとき、それは返信先の長いポーリング要求を、開いて保持されることを意味します。その結果、サーバは、非同期通信を「開始」することができます。
The basic life cycle of an application using HTTP long polling is as follows:
次のようにHTTPロングポーリングを使用して、アプリケーションの基本的なライフサイクルは次のとおりです。
1. The client makes an initial request and then waits for a response.
1.クライアントは、最初の要求を行い、その後、応答を待ちます。
2. The server defers its response until an update is available or until a particular status or timeout has occurred.
更新が利用可能になるまで、または特定の状態またはタイムアウトが発生するまで2.サーバは、その応答を延期します。
3. When an update is available, the server sends a complete response to the client.
アップデートが利用可能な場合3.、サーバーはクライアントへの完全な応答を送信します。
4. The client typically sends a new long poll request, either immediately upon receiving a response or after a pause to allow an acceptable latency period.
4.クライアントは、一般的に許容可能な潜伏期間を許可するか、すぐに応答を受信した場合または一時停止した後、新しいロングポーリング要求を送信します。
The HTTP long polling mechanism can be applied to either persistent or non-persistent HTTP connections. The use of persistent HTTP connections will avoid the additional overhead of establishing a new TCP/IP connection [TCP] for every long poll request.
HTTPロングポーリングメカニズムは、持続的または非持続的なHTTP接続のいずれかに適用することができます。永続的なHTTP接続を使用すると、すべてのロングポーリング要求のための新しいTCP / IP接続の[TCP]を確立する追加のオーバーヘッドを回避します。
The HTTP long polling mechanism introduces the following issues.
HTTPロングポーリングメカニズムは、次の問題を紹介します。
Header Overhead: With the HTTP long polling technique, every long poll request and long poll response is a complete HTTP message and thus contains a full set of HTTP headers in the message framing. For small, infrequent messages, the headers can represent a large percentage of the data transmitted. If the network MTU (Maximum Transmission Unit) allows all the information (including the HTTP header) to fit within a single IP packet, this typically does not represent a significant increase in the burden for networking entities. On the other hand, the amount of transferred data can be significantly larger than the real payload carried by HTTP, and this can have a significant impact (e.g., when volume-based charging is in place).
ヘッダーのオーバーヘッドは：HTTPロングポーリング技術では、全てのロングポーリング要求と長いポーリング応答は、完全なHTTPメッセージであるため、メッセージフレーミングにおけるHTTPヘッダのフルセットが含まれています。小さい、まれメッセージの場合、ヘッダは送信されたデータの大部分を表すことができます。ネットワークMTU（最大転送単位）は、単一のIPパケット内に収まるように（HTTPヘッダを含む）すべての情報を許可している場合、これは通常のエンティティネットワーキングのための負担が大幅に増加を示すものではありません。一方、転送されるデータの量は、HTTPによって運ばれる実際のペイロードよりも大幅に大きくすることができ、これは重大な影響を持つことができる（例えば、体積基準の充電が所定の位置にある場合）。
Maximal Latency: After a long poll response is sent to a client, the server needs to wait for the next long poll request before another message can be sent to the client. This means that while the average latency of long polling is close to one network transit, the maximal latency is over three network transits (long poll response, next long poll request, long poll response). However, because HTTP is carried over TCP/IP, packet loss and retransmission can occur; therefore, maximal latency for any TCP/IP protocol will be more than three network transits (lost packet, next packet, negative ack, retransmit). When HTTP pipelining (see Section 5.2) is available, the latency due to the server waiting for a new request can be avoided.
最大待ち時間：ロングポーリング応答がクライアントに送信された後、サーバは別のメッセージをクライアントに送信することができます前に、次のロングポーリング要求を待つ必要があります。これは、長いポーリングの平均待ち時間は一つのネットワーク遷移の近くに位置していながら、最大待ち時間は3つのネットワーク遷移（長いポーリング応答、次長いポーリング要求、長いポーリング応答）であることを意味します。しかし、HTTPはTCP / IP上で実行されるため、パケットロスと再送が発生する可能性があります。そのため、任意のTCP / IPプロトコルの最大待ち時間は、以上の3つのネットワーク遷移（失われたパケット、次のパケット、否定ACK、再送信）になります。 HTTPパイプラインは、（5.2節を参照）が利用可能である場合には、新しい要求を待っているサーバーによるレイテンシーを回避することができます。
Connection Establishment: A common criticism of both short polling and long polling is that these mechanisms frequently open TCP/IP connections and then close them. However, both polling mechanisms work well with persistent HTTP connections that can be reused for many poll requests. Specifically, the short duration of the pause between a long poll response and the next long poll request avoids the closing of idle connections.
接続の確立：短いポーリングとロングポーリングの両方の一般的な批判は、これらのメカニズムその後、頻繁に開いているTCP / IP接続とは、それらを閉じていることです。しかし、両方のポーリングメカニズムは、多くのポーリング要求のために再利用することができます永続的なHTTP接続でうまく機能します。具体的には、長いポーリング応答と次長いポーリング要求の間の休止の短い期間は、アイドル接続の閉鎖を回避します。
Allocated Resources: Operating systems will allocate resources to TCP/IP connections and to HTTP requests outstanding on those connections. The HTTP long polling mechanism requires that for each client both a TCP/IP connection and an HTTP request are held open. Thus, it is important to consider the resources related to both of these when sizing an HTTP long polling application. Typically, the resources used per TCP/IP connection are minimal and can scale reasonably. Frequently, the resources allocated to HTTP requests can be significant, and scaling the total number of requests outstanding can be limited on some gateways, proxies, and servers.
割り当てられたリソース：オペレーティングシステムは、TCP / IP接続にし、これらの接続に優れたHTTPリクエストにリソースを割り当てます。 HTTPロングポーリングメカニズムは、各クライアントのためにTCP / IP接続とHTTP要求の両方が開いたままにされている必要があります。したがって、HTTPロングポーリングアプリケーションのサイズを決定する際、これらの両方に関連するリソースを考慮することが重要です。一般的に、TCP / IP接続ごとに使用されるリソースが最小限であると合理的に拡張することができます。多くの場合、HTTPリクエストに割り当てられたリソースが重要である、と一部のゲートウェイ、プロキシ、およびサーバ上で制限することができる未処理の要求の合計数をスケーリングすることができます。
Graceful Degradation: A long polling client or server that is under load has a natural tendency to gracefully degrade in performance at a cost of message latency. If load causes either a client or server to run slowly, then events to be pushed to the client will queue (waiting either for the client to send a long poll request or for the server to free up CPU cycles that can be used to process a long poll request that is being held at the server). If multiple messages are queued for a client, they might be delivered in a batch within a single long poll response. This can significantly reduce the per-message overhead and thus ease the workload of the client or server for the given message load.
優雅な分解：ロングポーリングクライアントやサーバー負荷の下にある優雅メッセージの待ち時間のコストでパフォーマンスが低下するために自然な傾向を持っています。負荷は、クライアントまたはサーバのどちらかがゆっくり実行する原因となる場合は、クライアントにプッシュするイベントは、長いポーリング要求を送信するために、クライアントまたはサーバが処理するのに使用することができ、CPUサイクルを解放するためにどちらか待っている（キューに入れますサーバーで開催されているロングポーリングリクエスト）。複数のメッセージがクライアントのためにキューイングされている場合は、単一の長いポーリング応答の中にバッチで配信される可能性があります。これはかなり、メッセージごとのオーバーヘッドを減らすため、与えられたメッセージ負荷のために、クライアントやサーバーの負荷を軽減することができます。
Timeouts: Long poll requests need to remain pending or "hanging" until the server has something to send to the client. The timeout issues related to these pending requests are discussed in Section 5.5.
タイムアウト：ロングポーリング要求は保留中またはサーバーがクライアントに送信するために何かを持ってまで、「ハング」のままにする必要があります。これらの保留中の要求に関連するタイムアウトの問題は、5.5節で議論されています。
Caching: Caching mechanisms implemented by intermediate entities can interfere with long poll requests. This issue is discussed in Section 5.6.
キャッシュ：中間エンティティによって実装キャッシュメカニズムは長いポーリング要求を妨げることができます。この問題は、5.6節で説明されています。
The HTTP streaming mechanism keeps a request open indefinitely. It never terminates the request or closes the connection, even after the server pushes data to the client. This mechanism significantly reduces the network latency because the client and the server do not need to open and close the connection.
HTTPストリーミングメカニズムは、無期限にオープン要求を保持します。これは、サーバーがクライアントにデータをプッシュした後も、要求を終了していないか、接続を閉じません。クライアントとサーバが接続を開閉する必要がないので、このメカニズムは、大幅にネットワークの待ち時間を短縮します。
The basic life cycle of an application using HTTP streaming is as follows:
次のようにHTTPストリーミングを使用して、アプリケーションの基本的なライフサイクルは次のとおりです。
1. The client makes an initial request and then waits for a response.
1.クライアントは、最初の要求を行い、その後、応答を待ちます。
2. The server defers the response to a poll request until an update is available, or until a particular status or timeout has occurred.
更新が利用可能になるまで、または特定の状態またはタイムアウトが発生するまで2.サーバは、ポーリング要求に対する応答を延期します。
3. Whenever an update is available, the server sends it back to the client as a part of the response.
3.アップデートが利用可能なときはいつでも、サーバーが応答の一部として、それをクライアントに送り返します。
4. The data sent by the server does not terminate the request or the connection. The server returns to step 3.
4.サーバーから送信されたデータは、要求または接続を終了しません。サーバは、ステップ3に戻ります。
The HTTP streaming mechanism is based on the capability of the server to send several pieces of information in the same response, without terminating the request or the connection. This result can be achieved by both HTTP/1.1 and HTTP/1.0 servers.
HTTPストリーミング機構は、要求または接続を終了することなく、同一の応答にいくつかの情報を送信するサーバの能力に基づいています。この結果は、HTTP / 1.1とHTTP / 1.0サーバの両方によって達成することができます。
An HTTP response content length can be defined using three options:
HTTPレスポンスのコンテンツの長さは、3つのオプションを使用して定義することができます。
Content-Length header: This indicates the size of the entity body in the message, in bytes.
Content-Lengthヘッダ：これはバイト単位で、メッセージ内のエンティティボディのサイズを示します。
Transfer-Encoding header: The 'chunked' valued in this header indicates the message will break into chunks of known size if needed.
転送-Encodingヘッダ：このヘッダに大切な「チャンク」は、必要に応じてメッセージが既知のサイズのチャンクに侵入することを示します。
End of File (EOF): This is actually the default approach for HTTP/1.0 where the connections are not persistent. Clients do not need to know the size of the body they are reading; instead they expect to read the body until the server closes the connection. Although with HTTP/1.1 the default is for persistent connections, it is still possible to use EOF by setting the 'Connection:close' header in either the request or the response, thereby indicating that the connection is not to be considered 'persistent' after the current request/response is complete. The client's inclusion of the 'Connection: close' header field in the request will also prevent pipelining.
ファイルの終わり（EOF）：接続は永続的ではありませんここでは、実際にHTTP / 1.0のデフォルトのアプローチです。クライアントは、彼らが読んでいる身体の大きさを知る必要はありません。代わりに、彼らは、サーバーが接続を閉じるまで、本体を読み取ることが予想されます。これにより、接続後に「永続的」とみなされるべきではないことを示す、要求または応答のいずれかでヘッダー：HTTP / 1.1でデフォルトは永続的な接続のためのものであるが、密接 'を設定することにより、EOFを使用することが可能です現在のリクエスト/レスポンスは完了です。 「接続：閉じる」のクライアントの要求を含めるにおけるヘッダフィールドはまた、パイプライン化を防ぐことができます。
The main issue with EOF is that it is difficult to tell the difference between a connection terminated by a fault and one that is correctly terminated.
EOFでの主な問題は、正しく終端されている障害と1で終了し、接続の違いを見分けることは困難であるということです。
An HTTP/1.0 server can use only EOF as a streaming mechanism. In contrast, both EOF and "chunked transfer" are available to an HTTP/1.1 server.
HTTP / 1.0サーバは、ストリーミング・メカニズムとしてのみEOFを使用することができます。対照的に、EOFとの両方が「転送をチャンク」HTTP / 1.1サーバに利用可能です。
The "chunked transfer" mechanism is the one typically used by HTTP/1.1 servers for streaming. This is accomplished by including the header "Transfer-Encoding: chunked" at the beginning of the response, which enables the server to send the following parts of the response in different "chunks" over the same connection. Each chunk starts with the hexadecimal expression of the length of its data, followed by CR/LF (the end of the response is indicated with a chunk of size 0).
「転送をチャンク」のメカニズムは、一般的にストリーミングのためのHTTP / 1.1のサーバで使用されるものです。 「転送エンコード：チャンク」これはヘッダを含むことによって達成されるのと同じ接続を介して異なる「チャンク」の応答の次の部分を送信するようにサーバーを可能応答の冒頭。各チャンクはCR / LF（応答の端部はサイズ0のチャンクで示される）、続いて、そのデータの長さを16進表現から始まります。
HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked
25 This is the data in the first chunk
25これは、最初のチャンク内のデータであります
1C and this is the second one
図1C及びこれが二番目です
0
０
Figure 1: Transfer-Encoding response
図1：転送エンコード応答
To achieve the same result, an HTTP/1.0 server will omit the Content-Length header in the response. Thus, it will be able to send the subsequent parts of the response on the same connection (in this case, the different parts of the response are not explicitly separated by HTTP protocol, and the end of the response is achieved by closing the connection).
同じ結果を達成するために、HTTP / 1.0サーバが応答にContent-Lengthヘッダを省略します。これにより、同じ接続上の応答の後続の部分を送信することができるであろう（この場合には、応答の異なる部分を明示的にHTTPプロトコルによって分離されていない、及び応答の端部が接続を閉じることによって達成されます） 。
The HTTP streaming mechanism introduces the following issues.
HTTPストリーミング・メカニズムは、次の問題を紹介します。
Network Intermediaries: The HTTP protocol allows for intermediaries (proxies, transparent proxies, gateways, etc.) to be involved in the transmission of a response from the server to the client. There is no requirement for an intermediary to immediately forward a partial response, and it is legal for the intermediary to buffer the entire response before sending any data to the client (e.g., caching transparent proxies). HTTP streaming will not work with such intermediaries.
ネットワーク仲介：仲介（プロキシ、透明プロキシ、ゲートウェイ、等）がサーバからクライアントへの応答の送信に関与するためにHTTPプロトコルが可能となります。そこにすぐ前方の中間部分応答のための必要はありません、との仲介は、クライアント（例えば、キャッシング透明プロキシ）にデータを送信する前に応答全体をバッファリングすることが合法的です。 HTTPストリーミングは、このような仲介では動作しません。
Maximal Latency: Theoretically, on a perfect network, an HTTP streaming protocol's average and maximal latency is one network transit. However, in practice, the maximal latency is higher due to network and browser limitations. The browser techniques used to terminate HTTP streaming connections are often associated with JavaScript and/or DOM (Document Object Model) elements that will grow in size for every message received. Thus, in order to avoid unlimited growth of memory usage in the client, an HTTP streaming implementation occasionally needs to terminate the streaming response and send a request to initiate a new streaming response (which is essentially equivalent to a long poll). Thus, the maximal latency is at least three network transits. Also, because HTTP is carried over TCP/IP, packet loss and retransmission can occur; therefore maximal latency for any TCP/IP protocol will be more than three network transits (lost packet, next packet, negative ack, retransmit).
最大待ち時間：理論的には、完璧なネットワーク上で、HTTPストリーミングプロトコルの平均値と最大待ち時間は1回のネットワーク通過です。しかし、実際には、最大待ち時間は、ネットワークとブラウザ制限による高いです。 HTTPストリーミング接続を終了するために使用されるブラウザ技術は、多くの場合、JavaScriptと/またはDOM（Document Object Model）の受信メッセージごとのサイズに成長する要素に関連付けられています。このように、クライアントでのメモリ使用量の無制限の成長を回避するためには、HTTPストリーミングの実装は時折ストリーミング応答を終了し、（ロングポーリングと本質的に同等である）新しいストリーミング応答を開始する要求を送信する必要があります。したがって、最大レイテンシは、少なくとも3つのネットワーク遷移です。 HTTPはTCP / IP上で実行されているのでまた、パケットロスと再送が発生する可能性があります。したがって、任意のTCP / IPプロトコルの最大待ち時間は、以上の3つのネットワーク遷移（失われたパケット、次のパケット、否定ACK、再送信）になります。
Client Buffering: There is no requirement in existing HTTP specifications for a client library to make the data from a partial HTTP response available to the client application. For example, if each response chunk contains a statement of JavaScript, there is no requirement in the browser to execute that JavaScript before the entire response is received. However, in practice, most browsers do execute JavaScript received in partial responses -- although some require a buffer overflow to trigger execution. In most implementations, blocks of white space can be sent to achieve buffer overflow.
クライアントのバッファリング：クライアントアプリケーションが利用可能な部分のHTTPレスポンスからのデータを作るためのクライアントライブラリのための既存のHTTPの仕様の要件はありません。各応答チャンクのJavaScriptの文が含まれている場合たとえば、全体の応答が受信される前に、JavaScriptのことを実行するためのブラウザでは要求されません。しかし、実際には、ほとんどのブラウザはJavaScriptが部分的応答で受信実行しない - いくつかの実行をトリガするために、バッファオーバーフローを必要とするが。ほとんどの実装では、ホワイトスペースのブロックは、バッファオーバーフローを達成するために送信することができます。
Framing Techniques: Using HTTP streaming, several application messages can be sent within a single HTTP response. The separation of the response stream into application messages needs to be performed at the application level and not at the HTTP level. In particular, it is not possible to use the HTTP chunks as application message delimiters, since intermediate proxies might "re-chunk" the message stream (for example, by combining different chunks into a longer one). This issue does not affect the HTTP long polling technique, which provides a canonical framing technique: each application message can be sent in a different HTTP response.
テクニックをフレーミング：HTTPストリーミングを使用して、いくつかのアプリケーションメッセージは、単一のHTTP応答内で送信することができます。アプリケーションメッセージへの応答ストリームの分離は、アプリケーションレベルではなく、HTTPレベルで実行される必要があります。特に、中間プロキシがメッセージ・ストリーム（例えば、長い方に異なるチャンクを組み合わせることにより）「再チャンク」可能性があるため、アプリケーションメッセージ区切り文字としてHTTPチャンクを使用することは不可能です。各アプリケーションメッセージが異なるHTTP応答で送信することができます：この問題は、標準的なフレーミング技術を提供するHTTPロングポーリング技術を、影響はありません。
This section provides an overview of existing technologies that implement HTTP-based server-push mechanisms to asynchronously deliver messages from the server to the client.
このセクションでは、非同期にサーバからクライアントにメッセージを配信するためにHTTPベースのサーバプッシュメカニズムを実装する既存技術の概要を説明します。
The Bayeux protocol [BAYEUX] was developed in 2006-2007 by the Dojo Foundation. Bayeux can use both the HTTP long polling and HTTP streaming mechanisms.
バイユープロトコル[BAYEUX]道場財団により2006年から2007年に開発されました。バイユーはHTTPロングポーリングとHTTPストリーミングメカニズムの両方を使用することができます。
In order to achieve bidirectional communications, a Bayeux client will use two HTTP connections to a Bayeux server so that both server-to-client and client-to-server messaging can occur asynchronously.
両方のサーバーからクライアントへと、クライアントからサーバーへのメッセージは非同期に発生することができるように双方向通信を実現するためには、バイユークライアントはバイユーサーバーに2つのHTTP接続を使用します。
The Bayeux specification requires that implementations control pipelining of HTTP requests, so that requests are not pipelined inappropriately (e.g., a client-to-server message pipelined behind a long poll request).
バイユー仕様は、要求が不適切にパイプライン化されないように、実装は、HTTPリクエストのパイプライン化を制御することを必要とする（例えば、長いポーリング要求の背後にパイプラインクライアントツーサーバメッセージ）。
In practice, for JavaScript clients, such control over pipelining is not possible in current browsers. Therefore, JavaScript implementations of Bayeux attempt to meet this requirement by limiting themselves to a maximum of two outstanding HTTP requests at any one time, so that browser connection limits will not be applied and the requests will not be queued or pipelined. While broadly effective, this mechanism can be disrupted if non-Bayeux JavaScript clients simultaneously issue requests to the same host.
実際には、JavaScriptのクライアントのために、パイプラインを超えるような制御は、現在のブラウザでは不可能です。したがって、バイユーの試みのJavaScriptの実装は、そのブラウザの接続制限が適用されず、要求がキューに入れられたか、パイプライン化されることはありませんので、いずれかの時点で2つの優れたHTTP要求の最大に自分自身を制限することによって、この要件を満たすことができます。広く有効ではあるが非バイユーJavaScriptのクライアントが同時に同じホストに要求を発行する場合は、このメカニズムを破壊することができます。
Bayeux connections are negotiated between client and server with handshake messages that allow the connection type, authentication method, and other parameters to be agreed upon between the client and the server. Furthermore, during the handshake phase, the client and the server reveal to each other their acceptable bidirectional techniques, and the client selects one from the intersection of those sets.
バイユーの接続は、接続タイプ、認証方法、およびその他のパラメータは、クライアントとサーバの間で合意することができるように握手メッセージで、クライアントとサーバーとの間で交渉されています。また、ハンドシェイクフェーズ中に、クライアントとサーバは、互いの上許容される双方向技術を明らかにする、クライアントはそれらのセットの交点から一つを選択します。
For non-browser or same-domain Bayeux, clients use HTTP POST requests to the server for both the long poll request and the request to send messages to the server. The Bayeux protocol packets are sent as the body of the HTTP messages using the "application/json" Internet media type [RFC4627].
非ブラウザまたは同じドメインバイユーの場合、クライアントが長いポーリング要求とサーバーにメッセージを送信するための要求の両方のサーバーにHTTP POSTリクエストを使用します。バイユー・プロトコル・パケットは、「アプリケーション/ JSON」インターネットメディアタイプ[RFC4627]を使用して、HTTPメッセージの本体として送信されます。
For browsers that are operating in cross-domain mode, Bayeux attempts to use Cross-Origin Resource Sharing [CORS] checking if the browser and server support it, so that normal HTTP POST requests can be used. If this mechanism fails, Bayeux clients use the "JSONP" mechanism as described in [JSONP]. In this last case, client-to-server messages are sent as encoded JSON on the URL query parameters, and server-to-client messages are sent as a JavaScript program that wraps the message JSON with a JavaScript function call to the already loaded Bayeux implementation.
クロスドメインモードで動作しているブラウザの場合、バイユーは、使用しようとするクロスオリジンリソースの共有[CORS]ように、ブラウザとサーバーのサポート、それは、通常のHTTP POST要求を使用することが可能かどうかをチェックします。このメカニズムが失敗した場合は、[JSONP]で説明したように、バイユークライアントは、「JSONP」メカニズムを使用しています。この最後のケースでは、クライアントからサーバーへのメッセージは、URLのクエリパラメータにエンコードされたJSONとして送信され、サーバからクライアントへのメッセージは、すでにロードされバイユーにJavaScriptの関数呼び出しとメッセージJSONをラップJavaScriptプログラムとして送信されます実装。
BOSH, which stands for Bidirectional-streams Over Synchronous HTTP [BOSH], was developed by the XMPP Standards Foundation in 2003-2004. The purpose of BOSH is to emulate normal TCP connections over HTTP (TCP is the standard connection mechanism used in the Extensible Messaging and Presence Protocol as described in [RFC6120]). BOSH employs the HTTP long polling mechanism by allowing the server (called a "BOSH connection manager") to defer its response to a request until it actually has data to send to the client from the application server itself (typically an XMPP server). As soon as the client receives a response from the connection manager, it sends another request to the connection manager, thereby ensuring that the connection manager is (almost) always holding a request that it can use to "push" data to the client.
同期HTTP [BOSH]以上の双方向ストリームの略BOSHは、2003年から2004年にXMPP規格財団によって開発されました。 BOSHの目的は、HTTPを介して通常のTCP接続をエミュレートすることである（TCPは、[RFC6120]に記載されているように拡張メッセージングおよびプレゼンスプロトコルで使用される標準的な接続機構です）。 BOSHは、それが実際にアプリケーションサーバ自体（通常はXMPPサーバー）からクライアントに送信するデータを持っているまで（「BOSH接続マネージャ」と呼ばれる）サーバが要求への応答を延期できるようにすることで、HTTPロングポーリングメカニズムを採用しています。すぐにクライアントが接続マネージャからの応答を受信すると、それによって、接続マネージャが（ほぼ）常にそれがクライアントに「プッシュ」データに使用することができ、要求を保持していることを確認して、接続マネージャに別のリクエストを送信します。
In some situations, the client needs to send data to the server while it is waiting for data to be pushed from the connection manager. To prevent data from being pipelined behind the long poll request that is on hold, the client can send its outbound data in a second HTTP request over a second TCP connection. BOSH forces the server to respond to the request it has been holding on the first connection as soon as it receives a new request from the client, even if it has no data to send to the client. It does so to make sure that the client can send more data immediately, if necessary -- even in the case where the client is not able to pipeline the requests -- while simultaneously respecting the two-connection limit discussed in Section 5.1.
いくつかの状況では、クライアントは、データが接続マネージャからプッシュされるのを待っている間、サーバにデータを送信する必要があります。保留されているロングポーリング要求の後ろにパイプライン化されてからデータを防ぐために、クライアントは、第二のTCP接続を介して2番目のHTTPリクエストでのアウトバウンドのデータを送信することができます。 BOSHは、それがクライアントに送信するデータがない場合でも、それはクライアントからの新しい要求を受け取ると、それは、すぐに最初の接続に保持された要求に応答するサーバーを強制します。でも、クライアントが要求パイプラインにできない場合には - - 同時にセクション5.1で説明した2つの接続の制限を尊重しながら、それはとても必要であれば、クライアントは、すぐに多くのデータを送信できることを確認しません。
The number of long poll request-response pairs is negotiated during the first request sent from the client to the connection manager. Typically, BOSH clients and connection managers will negotiate the use of two pairs, although it is possible to use only one pair or more than two pairs.
ロングポーリングリクエスト・レスポンスのペアの数は、接続マネージャにクライアントから送信された最初のリクエストの間に交渉されています。唯一の対または二つ以上のペアを使用することは可能であるが、典型的には、ボッシュクライアントと接続マネージャは、二対の使用をネゴシエートします。
The roles of the two request-response pairs typically switch whenever the client sends data to the connection manager. This means that when the client issues a new request, the connection manager immediately answers the blocked request on the other TCP connection, thus freeing it; in this way, in a scenario where only the client sends data, the even requests are sent over one connection, and the odd ones are sent over the other connection.
2要求 - 応答ペアの役割は、典型的には、クライアントは、接続マネージャにデータを送信するたびに切り替えます。これにより、クライアントは新しい要求を発行すると、接続マネージャは、直ちにので、それを解放し、他のTCP接続上でブロックされた要求に応答することを意味します。このように、唯一のクライアントがデータを送信したシナリオで、でも要求は1つの接続を介して送信され、奇数のものは、他の接続を介して送信されます。
BOSH is able to work reliably both when network conditions force every HTTP request to be made over a different TCP connection and when it is possible to use HTTP/1.1 and then rely on two persistent TCP connections.
BOSHは確実に両方のネットワーク条件が異なるTCP接続とするとき、HTTP / 1.1を使用して、2つの永続TCP接続に依存することが可能となる上で行われるすべてのHTTPリクエストを強制するときに動作することができます。
If the connection manager has no data to send to the client for an agreed amount of time (also negotiated during the first request), then the connection manager will respond to the request it has been holding with no data, and that response immediately triggers a fresh client request. The connection manager does so to ensure that if a network connection is broken then both parties will realize that fact within a reasonable amount of time.
接続マネージャは（も最初のリクエストの間で交渉）時間の合意された量のためにクライアントに送信するデータがない場合、接続マネージャは、それがデータなしで保持された要求に応答し、その応答が即座にトリガ新鮮なクライアント要求。接続マネージャは、そのネットワーク接続が切断された場合、両方の当事者は妥当な時間内にその事実を実現することを確実にするために行います。
Moreover, BOSH defines the negotiation of an "inactivity period" value that specifies the longest allowable inactivity period (in seconds). This enables the client to ensure that the periods with no requests pending are never too long.
また、BOSH（秒）、最長許容非アクティブ期間を指定し、「非アクティブ期間」値のネゴシエーションを定義します。これは、保留中の要求なしでの期間が長すぎることはありませんことを保証するために、クライアントを可能にします。
BOSH allows data to be pushed immediately when HTTP pipelining is available. However, if HTTP pipelining is not available and one of the endpoints has just pushed some data, BOSH will usually need to wait for a network round-trip time until the server is able to again push data to the client.
BOSHはHTTPパイプラインが利用可能な場合、データがすぐにプッシュすることができます。 HTTPパイプラインが利用できないと、エンドポイントの1つは、単にいくつかのデータをプッシュしている場合は、BOSHは通常、サーバーが再びクライアントにデータをプッシュできるようになるまでのネットワーク往復時間を待つ必要があります。
BOSH uses standard HTTP POST request and response bodies to encode all information.
BOSHは、すべての情報をエンコードするために、標準のHTTPのPOSTリクエストとレスポンスボディを使用しています。
BOSH normally uses HTTP pipelining over a persistent HTTP/1.1 connection. However, a client can deliver its POST requests in any way permitted by HTTP 1.0 or HTTP 1.1. (Although the use of HTTP POST with pipelining is discouraged in RFC 2616, BOSH employs various methods, such as request identifiers, to ensure that this usage does not lead to indeterminate results if the transport connection is terminated prematurely.)
BOSHは、通常、永続的なHTTP / 1.1接続を介してHTTPパイプラインを使用しています。ただし、クライアントは、HTTP 1.0またはHTTP 1.1で許可されてどのような方法でそのPOSTリクエストを提供することができます。 （パイプラインとHTTP POSTの使用は、RFC 2616で推奨されているが、BOSHは、トランスポート接続が途中で終了した場合、この使用量は不確定な結果をもたらさないことを確実にするために、そのような要求の識別子として、種々の方法を採用しています。）
BOSH clients and connection managers are not allowed to use Chunked Transfer Coding, since intermediaries might buffer each partial HTTP request or response and only forward the full request or response once it is available.
仲介は、各部分のHTTP要求または応答をバッファリングし、唯一それが利用可能になると、完全な要求や応答を転送する可能性があるためBOSHクライアントとの接続マネージャは、チャンク転送コーディングを使用することはできません。
BOSH allows the usage of the Accept-Encoding and Content-Encoding headers in the request and in the response, respectively, and then compresses the response body accordingly.
BOSHは、それぞれ、要求および応答に受け入れエンコード及びコンテンツ符号化ヘッダの使用を可能にし、それに応じて応答本体を圧縮します。
Each BOSH session can share the HTTP connection(s) it uses with other HTTP traffic, including other BOSH sessions and HTTP requests and responses completely unrelated to the BOSH protocol (e.g., Web page downloads).
各BOSHセッションは、それが他のBOSHセッションとBOSHプロトコル（例えば、Webページのダウンロード）とは全く無関係のHTTPリクエストとレスポンスを含め、他のHTTPトラフィックに使用するHTTP接続（複数可）を共有することができます。
W3C Server-Sent Events specification [WD-eventsource] defines an API that enables servers to push data to Web pages over HTTP in the form of DOM events.
W3Cサーバーに送信されEvents仕様[WD-のEventSource]はDOMイベントの形でHTTPを介してWebページにデータをプッシュするようにサーバーを可能にAPIを定義します。
The data is encoded as "text/event-stream" content and pushed using an HTTP streaming mechanism, but the specification suggests disabling HTTP chunking for serving event streams unless the rate of messages is high enough to avoid the possible negative effects of this technique as described in Section 3.2.
データは、「テキスト/イベント・ストリーム」コンテンツとして符号化され、HTTPストリーミング・メカニズムを使用してプッシュするが、仕様が示唆メッセージの速度は、この技術の可能性のある悪影響を回避するのに十分高くない限り、イベント・ストリームを提供するためチャンクHTTPを無効にされています3.2節で説明しました。
However, it is not clear if there are significant benefits to using EOF rather than chunking with regards to intermediaries, unless they support only HTTP/1.0.
EOFを使用してではなく、仲介に関してチャンクに大きなメリットがある場合、彼らは唯一のHTTP / 1.0をサポートしていない限り、しかし、それは、明確ではありません。
HTTP [RFC2616], Section 8.1.4, recommends that a single user client not maintain more than two connections to any server or proxy, in order to prevent the server from being overloaded and to avoid unexpected side effects in congested networks. Until recently, this limit was implemented by most commonly deployed browsers, thus making connections a scarce resource that needed to be shared within the browser. Note that the available JavaScript APIs in the browsers hide the connections, and the security model inhibits the sharing of any resource between frames. The new HTTP specification [HTTPBIS] removes the two-connection limitation, only encouraging clients to be conservative when opening multiple connections. In fact, recent browsers have increased this limit to 6 or 8 connections; however, it is still not possible to discover the local limit, and usage of multiple frames and tabs still places 8 connections within easy reach.
HTTP [RFC2616]、セクション8.1.4には、シングルユーザクライアントが過負荷からサーバーを防ぐために、任意のサーバーまたはプロキシに二つ以上の接続を維持し、混雑したネットワークでの予期しない副作用を回避しないことをお勧めします。最近まで、この制限は、このような接続ブラウザ内で共有されるために必要な希少資源を作り、最も一般的に展開されブラウザで実装されました。ブラウザで利用可能なJavaScriptのAPIが接続を隠し、およびセキュリティモデルは、フレーム間の任意のリソースの共有を阻害することに注意してください。新しいHTTP仕様は[HTTPBIS]のみ複数の接続を開くときに保守的であるようにクライアントを促す、二接続制限を除去します。実際には、最近のブラウザでは、6つのまたは8の接続には、この制限を増加しています。しかし、地元の限界を発見することは可能ではなく、複数のフレームとタブの使用は、まだ簡単に手の届くところに8つの接続を配置します。
Web applications need to limit the number of long poll requests initiated, ideally to a single long poll that is shared between frames, tabs, or windows of the same browser. However, the security constraints of the browsers make such sharing difficult.
Webアプリケーションは、理想的には、フレーム、タブ、または同じブラウザのウィンドウ間で共有される単一の長いポーリングに、開始した長いポーリング要求の数を制限する必要があります。しかし、ブラウザのセキュリティ制約は、このような共有を困難にします。
A best practice for a server is to use cookies [COOKIE] to detect multiple long poll requests from the same browser and to avoid deferring both requests since this might cause connection starvation and/or pipeline issues.
サーバーのためのベストプラクティスは、同じブラウザから複数のロングポーリング要求を検出すると、これが接続飢餓および/またはパイプラインの問題が発生する可能性がありますので、両方の要求を延期避けるために[COOKIE]クッキーを使用することです。
HTTP [RFC2616] permits optional request pipelining over persistent connections. Multiple requests can be enqueued before the responses arrive.
HTTP [RFC2616]は、永続的接続を介して、オプションの要求パイプライン化を可能にします。応答が到着する前に複数の要求をエンキューすることができます。
In the case of HTTP long polling, the use of HTTP pipelining can reduce latency when multiple messages need to be sent by a server to a client in a short period of time. With HTTP pipelining, the server can receive and enqueue a set of HTTP requests. Therefore, the server does not need to receive a new HTTP request from the client after it has sent a message to the client within an HTTP response. In principle, the HTTP pipelining can be applied to HTTP GET and HTTP POST requests, but using HTTP POST requests is more critical. In fact, the use of HTTP POST with pipelining is discouraged in RFC 2616 and needs to be handled with special care.
複数のメッセージが短時間にサーバーからクライアントに送信する必要がある場合、HTTPロングポーリングの場合は、HTTPパイプラインの使用は、待ち時間を短縮することができます。 HTTPパイプラインを使用すると、サーバーは、HTTPリクエストのセットを受信し、キューに入れることができます。そのため、サーバはHTTPレスポンス内のクライアントにメッセージを送信した後に、クライアントから新しいHTTPリクエストを受信する必要がありません。原則的には、HTTPパイプラインは、HTTP GETとHTTP POSTリクエストに適用されますが、HTTPのPOSTリクエストを使用することはより重要であることができます。実際には、パイプラインを持つHTTP POSTを使用すると、RFC 2616に落胆し、特別な注意を払って処理する必要があります。
There is an issue regarding the inability to control pipelining. Normal requests can be pipelined behind a long poll, and are thus delayed until the long poll completes.
パイプラインを制御することができないことに関する問題があります。通常の要求は、長いポールの後ろにパイプライン化することができ、かつ長いポーリングが完了するまで、このように延期されています。
Mechanisms for bidirectional HTTP that want to exploit HTTP pipelining need to verify that HTTP pipelining is available (e.g., supported by the client, the intermediaries, and the server); if it's not available, they need to fall back to solutions without HTTP pipelining.
HTTPパイプラインを活用したい双方向HTTPのためのメカニズムは、（例えば、クライアント、仲介、およびサーバーでサポートされている）HTTPパイプラインが利用可能であることを確認する必要があります。それは利用できない場合、彼らはHTTPパイプラインなしソリューションにフォールバックする必要があります。
Most proxies work well with HTTP long polling because a complete HTTP response will be sent either on an event or a timeout. Proxies are advised to return that response immediately to the user agent, which immediately acts on it.
完全なHTTP応答がイベントまたはタイムアウトのいずれかで送信されますので、ほとんどのプロキシはHTTPロングポーリングでうまく動作します。プロキシはすぐにそれに作用するユーザエージェントにすぐにその応答を返すことをお勧めします。
The HTTP streaming mechanism uses partial responses and sends some JavaScript in an HTTP/1.1 chunk as described in Section 3. This mechanism can face problems caused by two factors: (1) it relies on proxies to forward each chunk (even though there is no requirement for them to do so, and some caching proxies do not), and (2) it relies on user agents to execute the chunk of JavaScript as it arrives (even though there is also no requirement for them to do so).
メカニズムをHTTPストリーミングは、部分的な応答を使用し、このメカニズム第3節で説明したようにHTTP / 1.1のチャンクにいくつかのJavaScriptを送り、二つの要因によって引き起こされる問題に直面することができます：（1）それはありませんがあるにもかかわらず、（各チャンクを転送するためのプロキシに依存していますそれらの要件は、そうするために、一部のキャッシュプロキシがない）、および（2）それが到着したとしても）彼らがそうするための要件がないにもかかわらず（はJavaScriptのチャンクを実行するユーザエージェントに依存しています。
A "reverse proxy" basically is a proxy that pretends to be the actual server (as far as any client or client proxy is concerned), but it passes on the request to the actual server that is usually sitting behind another layer of firewalls. Any HTTP short polling or HTTP long polling solution will work fine with this, as will most HTTP streaming solutions. The main downside is performance, since most proxies are not designed to hold many open connections.
「リバースプロキシは、」基本的には実際のサーバー（限り任意のクライアントまたはクライアントプロキシが懸念している）であることをふり、それは通常、ファイアウォールの別の層の後ろに座っている実際のサーバへの要求を渡すプロキシです。任意のHTTP短いポーリングまたはHTTPロングポーリングソリューションは、ほとんどのHTTPストリーミングになる解決策として、これで正常に動作します。ほとんどのプロキシは、多くのオープン接続を保持するように設計されていないので、主な欠点は、パフォーマンスです。
Reverse proxies can come to grief when they try to share connections to the servers between multiple clients. As an example, Apache with mod_jk shares a small set of connections (often 8 or 16) between all clients. If long polls are sent on those shared connections, then the proxy can be starved of connections, which means that other requests (either long poll or normal) can be held up. Thus, Comet mechanisms currently need to avoid any connection sharing -- either in the browser or in any intermediary -- because the HTTP assumption is that each request will complete as fast as possible.
彼らは、複数のクライアント間でのサーバーへの接続を共有しようとすると、リバースプロキシは、悲しみに来ることができます。一例として、のmod_jkとApacheは、すべてのクライアントの間の接続（多くの場合、8または16）の小さなセットを共有します。ロングポーリングは、これらの共有接続上で送信された場合、プロキシは、他の要求（ロングポーリングまたは通常どちらかが）を保つことができることを意味し、接続が不足することができます。このように、彗星のメカニズムは、現在、任意の接続の共有を避けるために必要がある - ブラウザまたは任意の仲介のいずれかで - HTTPの前提は、各要求は可能な限り迅速に完了することですので。
One of the main reasons why both HTTP long polling and HTTP streaming are perceived as having a negative impact on servers and proxies is that they use a synchronous programming model for handling requests, since the resources allocated to each request are held for the duration of the request. Asynchronous proxies and servers can handle long polls using slightly more resources than normal HTTP traffic. Unfortunately some synchronous proxies do exist (e.g., Apache mod_jk) and many HTTP application servers also have a blocking model for their request handling (e.g., the Java servlet 2.5 specification).
HTTPロングポーリングとHTTPストリーミングの両方が、サーバやプロキシに負の影響を有するものとして知覚される主な理由の一つは、各要求に割り当てられたリソースは期間中保持されているので、彼らは、要求を処理するための同期プログラミング・モデルを使用することです要求。非同期プロキシとサーバーは、通常のHTTPトラフィックよりもわずかに多くのリソースを使用して長いポーリングを扱うことができます。残念ながら、いくつかの同期プロキシは（例えば、Apacheのmod_jkの）存在しないと、多くのHTTPアプリケーションサーバは、その要求が（例えば、Javaサーブレット2.5仕様）処理するためのブロッキングモデルを持っています。
In accordance with [RFC2616], the server responds to a request it has successfully received by sending a 200 OK answer, but only when a particular event, status, or timeout has occurred. The 200 OK body section contains the actual event, status, or timeout that occurred. This "best practice" is simply standard HTTP.
[RFC2616]に従って、サーバーは、それが成功した200 OKの回答を送信することにより、受信した要求に応答しますが、特定のイベント、状態、またはタイムアウトが発生した場合のみ。 200 OK本体部は、発生した実際のイベント、状態、またはタイムアウトが含まれています。この「ベストプラクティス」は、単に標準のHTTPです。
The HTTP long polling mechanism allows the server to respond to a request only when a particular event, status, or timeout has occurred. In order to minimize (as much as possible) both latency in server-client message delivery and the processing/network resources needed, the long poll request timeout ought to be set to a high value.
HTTPロングポーリングメカニズムは、サーバが特定のイベント、状態、またはタイムアウトが発生しただけで要求に応答することができます。 （可能な限り）サーバ - クライアント・メッセージ配信、必要な処理/ネットワーク・リソースにおける待ち時間の両方を最小にするために、長いポーリング要求タイムアウトが高い値に設定されるべきです。
However, the timeout value has to be chosen carefully; indeed, problems can occur if this value is set too high (e.g., the client might receive a 408 Request Timeout answer from the server or a 504 Gateway Timeout answer from a proxy). The default timeout value in a browser is 300 seconds, but most network infrastructures include proxies and servers whose timeouts are not that long.
ただし、タイムアウト値は慎重に選択する必要があります。この値が高すぎる設定されている場合は確かに、問題が発生する可能性があります（例えば、クライアントがサーバーから408要求タイムアウト応答またはプロキシから504ゲートウェイタイムアウトの回答を受け取ることがあります）。ブラウザのデフォルトのタイムアウト値は300秒ですが、ほとんどのネットワークインフラストラクチャは、そのタイムアウトそんなに長くはありませんプロキシおよびサーバを含みます。
Several experiments have shown success with timeouts as high as 120 seconds, but generally 30 seconds is a safer value. Therefore, vendors of network equipment wishing to be compatible with the HTTP long polling mechanism are advised to implement a timeout substantially greater than 30 seconds (where "substantially" means several times more than the medium network transit time).
いくつかの実験は、120秒という高いタイムアウトの成功を示しているが、一般的に30秒がより安全な値です。したがって、HTTP長いポーリング機構に適合するように希望ネットワーク機器のベンダーは、（ここで、「実質的に」メディアネットワーク通過時間より数倍以上を意味する）は、30秒よりも実質的に大きいタイムアウトを実装することをお勧めします。
There is no way for an end client or host to signal to HTTP intermediaries that long polling is in use; therefore, long poll requests are completely transparent for intermediary entities and are handled as normal requests. This can have an impact on intermediary entities that perform operations that are not useful in case of long polling. However, any capabilities that might interfere with bidirectional flow (e.g., caching) can be controlled with standard headers or cookies.
ロングポーリングが使用されているHTTPの仲介に知らせるためのエンドクライアントまたはホストのための方法はありません。そのため、長いポーリング要求は、仲介事業体のために、完全に透明であり、通常の要求として処理されます。これは、長いポーリングの場合には有用ではない操作を実行仲介事業体に影響を与えることができます。しかしながら、双方向の流れ（例えば、キャッシュ）に干渉する可能性のある機能は、標準ヘッダまたはクッキーで制御することができます。
As a best practice, caching is always intentionally suppressed in a long poll request or response, i.e., the "Cache-Control" header is set to "no-cache".
ベストプラクティスとして、キャッシュを常に意図的に長いポーリング要求または応答に抑制される、すなわち、「のCache-Control」ヘッダが「ノーキャッシュ」に設定されています。
This document is meant to describe current usage of HTTP to enable asynchronous or server-initiated communication. It does not propose any change to the HTTP protocol or to the expected behavior of HTTP entities. Therefore this document does not introduce new security concerns into existing HTTP infrastructure. The considerations reported hereafter refer to the solutions that are already implemented and deployed.
この文書は、非同期またはサーバー開始通信を可能にするために、HTTPの現在の使用状況を説明することを意味します。これは、HTTPプロトコルまたはHTTPエンティティの予想される動作に変更を提案していません。したがって、この文書では、既存のHTTPインフラストラクチャに新たなセキュリティ上の懸念を導入していません。以下、報告の考察は、すでに実装され、配備されている解決策を参照してください。
One security concern with cross-domain HTTP long polling is related to the fact that often the mechanism is implemented by executing the JavaScript returned from the long poll request. If the server is prone to injection attacks, then it could be far easier to trick a browser into executing the code [CORS].
クロスドメインHTTPロングポーリングの一つのセキュリティ上の懸念は、多くの場合、メカニズムはJavaScriptが長いポーリング要求から返される実行することで実現されているという事実に関連しています。サーバがインジェクション攻撃の傾向がある場合、コード[CORS]を実行するにブラウザをだましてはるかに簡単である可能性があります。
Another security concern is that the number of open connections that needs to be maintained by a server in HTTP long polling and HTTP streaming could more easily lead to denial-of-service (DoS) attacks [RFC4732].
他のセキュリティ上の問題はHTTPロングポーリングとHTTPストリーミングにサーバーによって維持される必要があり、オープン接続数がより簡単にサービス拒否（DoS）攻撃[RFC4732]につながる可能性があるということです。
[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[RFC1945]バーナーズ=リー、T.、フィールディング、R.、およびH.ニールセン、 "ハイパーテキスト転送プロトコル - HTTP / 1.0"、RFC 1945、1996年5月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006.
[RFC4732]ハンドリー、M.、レスコラ、E.、およびIAB、 "インターネットサービス拒否の注意事項"、RFC 4732、2006年12月。
[BAYEUX] Russell, A., Wilkins, G., Davis, D., and M. Nesbitt, "Bayeux Protocol -- Bayeux 1.0.0", 2007, <http://svn.cometd.com/trunk/bayeux/bayeux.html>.
【BAYEUX]ラッセル、A.、ウィルキンス、G.、デイビス、D.、およびM.ネスビット、 "バイユープロトコル - バイユー1.0.0" 2007年、<http://svn.cometd.com/trunk/bayeux /bayeux.html>。
[BOSH] Paterson, I., Smith, D., and P. Saint-Andre, "Bidirectional-streams Over Synchronous HTTP (BOSH)", XSF XEP 0124, February 2007.
[BOSH]パターソン、I.、スミス、D.、およびP.サンアンドレ、XSFのXEP 0124、2007年2月 "同期HTTP（BOSH）以上の双方向ストリーム"。
[COMET] Russell, A., "Comet: Low Latency Data for the Browser", March 2006, <http://infrequently.org/ 2006/03/comet-low-latency-data-for-the-browser/ >.
[COMET]ラッセル、A.、 "彗星：ブラウザのための低遅延データ"、2006年3月、<http://infrequently.org/ 2006/03 /彗星低レイテンシー-用データブラウザ/> 。
[COOKIE] Barth, A., "HTTP State Management Mechanism", Work in Progress, March 2011.
[COOKIE]バース、A.、 "HTTP状態管理機構"、進歩、2011年3月に作業。
[CORS] van Kesteren, A., "Cross-Origin Resource Sharing", W3C Working Draft WD-cors-20100727, latest version available at <http://www.w3.org/TR/cors/>, July 2010, <http://www.w3.org/TR/2010/WD-cors-20100727/>.
[CORS]バンKesteren氏、A.、 "クロスオリジンリソースの共有"、W3CワーキングドラフトWD-CORS-20100727、<http://www.w3.org/TR/cors/>で入手可能な最新版、2010年7月、 <http://www.w3.org/TR/2010/WD-cors-20100727/>。
[HTTPBIS] Fielding, R., Ed., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, and Message Parsing", Work in Progress, March 2011.
【HTTPBIS]フィールディング、R.、編、ゲティス、J.、モーグル、J.、ニールセン、H.、Masinter、L.、リーチ、P.、バーナーズ - リー、T.、ラフォン、Y.、エド。 、およびJ. Reschke、エド、 "HTTP / 1.1、パート1：URIを、接続、およびメッセージの解析"。、進歩、2011年3月に作業。
[JSONP] Wikipedia, "JSON with padding", <http://en.wikipedia.org/wiki/JSONP#JSONP>.
[JSONP]ウィキペディア、 "パディングとJSON"、<http://en.wikipedia.org/wiki/JSONP#JSONP>。
[RFC4627] Crockford, D., "The application/json Media Type for JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[RFC4627]クロックフォード、D.、RFC 4627、2006年7月 "JavaScriptのObject Notation（JSON）形式のためのアプリケーション/ JSONのメディアタイプ"。
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011.
[RFC6120]サンアンドレ、P.、 "拡張メッセージングおよびプレゼンスプロトコル（XMPP）：コア"、RFC 6120、2011年3月。
[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[TCP]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[WD-eventsource] Hickson, I., "Server-Sent Events", W3C Working Draft WD-eventsource-20091222, latest version available at <http://www.w3.org/TR/eventsource/>, December 2009, <http://www.w3.org/TR/2009/ WD-eventsource-20091222/>.
[WD-のEventSource]ヒクソン、I.、 "サーバー送信されたイベント"、W3CワーキングドラフトWD-のEventSource-20091222、<http://www.w3.org/TR/eventsource/>で入手可能な最新バージョン、2009年12月、 <http://www.w3.org/TR/2009/ WD-のEventSource-20091222 />。
Thanks to Joe Hildebrand, Julien Laganier, Jack Moffitt, Subramanian Moonesamy, Mark Nottingham, Julian Reschke, Martin Thomson, and Martin Tyler for their feedback.
彼らのフィードバックのためのジョー・ヒルデブラント、ジュリアンLaganier、ジャック・モフィット、サブラマニアンMoonesamy、マーク・ノッティンガム、ジュリアンReschke、マーティン・トムソン、そしてマーティン・タイラーに感謝します。
Authors' Addresses
著者のアドレス
Salvatore Loreto Ericsson Hirsalantie 11 Jorvas 02420 Finland
サルヴァトーレ・ロレートエリクソンHirsalantie 11 Jorvas 02420フィンランド
EMail: salvatore.loreto@ericsson.com
メールアドレス：salvatore.loreto@ericsson.com
Peter Saint-Andre Cisco 1899 Wyknoop Street, Suite 600 Denver, CO 80202 USA
ピーターサンアンドレのCisco 1899 Wyknoopストリート、スイート600デンバー、CO 80202 USA
Phone: +1-303-308-3282 EMail: psaintan@cisco.com
電話：+ 1-303-308-3282 Eメール：psaintan@cisco.com
Stefano Salsano University of Rome "Tor Vergata" Via del Politecnico, 1 Rome 00133 Italy
ローマ「トルヴェルガータ」ヴィアデル工科、1 00133ローマイタリアのステファノ・Salsano大学
EMail: stefano.salsano@uniroma2.it
メールアドレス：stefano.salsano@uniroma2.it
Greg Wilkins Webtide
グレッグ・ウィルキンスWebtide
EMail: gregw@webtide.com
メールアドレス：gregw@webtide.com