[要約] 要約： RFC 6202は、双方向HTTPでのロングポーリングとストリーミングの使用に関する既知の問題とベストプラクティスを提供しています。目的： このRFCの目的は、双方向HTTPでのロングポーリングとストリーミングの使用に関する問題を特定し、最適な実装方法を提案することです。
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
双方向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ストリーミングの2つの最も一般的なメカニズムに焦点を当てています。
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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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」[Comet]の下にグループ化されることが多いため、クライアントからの投票リクエストを待たずにWebサーバーがクライアントに更新を送信できるようにします。このようなメカニズムは、データを定期的に投票するために必要な接続を頻繁に開閉して閉鎖するため、クライアントアプリケーションが経験する遅延を回避しながら、よりタイムリーにクライアントに更新を提供できます。
The two most common server-push mechanisms are HTTP long polling and HTTP streaming:
最も一般的な2つのサーバープッシュメカニズムは、HTTP Long Pollingと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 Long Polling：サーバーは、各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 Long Pollingを使用したアプリケーションの基本的なライフサイクルは次のとおりです。
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（最大送信ユニット）がすべての情報（HTTPヘッダーを含む）が単一のIPパケットに収まることを許可している場合、これは通常、ネットワーキングエンティティの負担の大幅な増加を表していません。一方、転送されたデータの量は、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.
最大レイテンシ：長い世論調査の応答がクライアントに送信された後、サーバーは次の長い投票リクエストを待機する必要があります。これは、長いポーリングの平均遅延は1つのネットワークトランジットに近いが、最大レイテンシは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.
コンテンツレングスヘッダー：これは、メッセージ内のエンティティ本体のサイズをバイトで示します。
Transfer-Encoding header: The 'chunked' valued in this header indicates the message will break into chunks of known size if needed.
転送エンコードヘッダー：このヘッダーで評価されている「チャンク」は、必要に応じてメッセージが既知のサイズのチャンクに分割されることを示します。
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の主な問題は、障害によって終了した接続と正しく終了する接続の違いを伝えることが困難であることです。
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のみを使用できます。対照的に、HTTP/1.1サーバーでは、EOFと「チャンク転送」の両方が利用可能です。
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サーバーで通常使用されるメカニズムです。これは、応答の開始時にヘッダー「転送エンコード：チャンク」を含めることによって達成されます。これにより、サーバーは同じ接続の上に異なる「チャンク」で応答の次の部分を送信できます。各チャンクは、データの長さの16進表現から始まり、その後にCR/LFが続きます（応答の終わりはサイズ0のチャンクで示されます）。
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そしてこれが2番目のものです
0
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サーバーは、応答のコンテンツ長ヘッダーを省略します。したがって、同じ接続で応答の後続の部分を送信できます（この場合、応答の異なる部分は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（ドキュメントオブジェクトモデル）要素に関連付けられていることがよくあります。したがって、クライアントのメモリ使用量の無制限の成長を回避するために、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プロトコル[Bayeux]は、2006年から2007年にDojo Foundationによって開発されました。Bayeuxは、HTTP Long Pollingと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.
双方向通信を実現するために、BayeuxクライアントはBayeuxサーバーへの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).
Bayeuxの仕様では、実装が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のクライアントにとって、現在のブラウザではパイプラインのこのような制御は不可能です。したがって、BayeuxのJavaScriptの実装は、一度に最大2つの未解決のHTTP要求に制限することにより、この要件を満たそうとします。広く効果的ですが、このメカニズムは、Bayeux以外の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.
Bayeux接続は、クライアントとサーバーの間で交渉され、接続タイプ、認証方法、およびクライアントとサーバーの間で合意される他のパラメーターを可能にします。さらに、ハンドシェイクフェーズ中、クライアントとサーバーは、許容できる双方向のテクニックを互いに明らかにし、クライアントはそれらのセットの交差点から1つを選択します。
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].
非ブラウザーまたは同じドメインBayeuxの場合、クライアントは長い投票リクエストとサーバーにメッセージを送信するリクエストの両方について、サーバーにHTTP投稿リクエストを使用します。Bayeuxプロトコルパケットは、「Application/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.
クロスドメインモードで動作しているブラウザの場合、Bayeuxはクロスオリジンリソース共有[COR]を使用しようとします[CORS]ブラウザとサーバーがサポートするかどうかを確認し、通常のHTTP POSTリクエストを使用できるようにします。このメカニズムが失敗した場合、Bayeuxクライアントは[JSONP]で説明されているように「JSONP」メカニズムを使用します。この最後のケースでは、クライアントからサーバーへのメッセージがURLクエリパラメーターでエンコードされたJSONとして送信され、サーバーからクライアントメッセージは、既にロードされたBayeuxへの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 Standards Foundationによって開発されました。Boshの目的は、HTTPを介した通常のTCP接続をエミュレートすることです（TCPは、[RFC6120]で説明されているように、拡張可能なメッセージングおよび存在プロトコルで使用される標準接続メカニズムです）。Boshは、サーバー（「Bosh Connection Manager」と呼ばれる）を許可することにより、HTTPの長いポーリングメカニズムを使用して、アプリケーションサーバー自体（通常はXMPPサーバー）からクライアントに送信するデータが実際にあるまで要求に対する応答を延期します。クライアントが接続マネージャーから応答を受信するとすぐに、接続マネージャーに別のリクエストを送信し、接続マネージャーが（ほぼ）データをクライアントに「プッシュ」するために使用できる要求を（ほぼ）保持していることを保証します。
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.
状況によっては、クライアントは、接続マネージャーからデータがプッシュされるのを待っている間に、サーバーにデータを送信する必要があります。保留中の長い投票要求の背後にデータがパイプ化されるのを防ぐために、クライアントは2番目の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.
クライアントからConnection Managerに送信された最初のリクエスト中に、長い投票リクエスト応答ペアの数が交渉されます。通常、Boshのクライアントと接続マネージャーは、2つのペアの使用を交渉しますが、1つのペアまたは2ペアを超えるペアのみを使用することは可能です。
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は、ネットワーク条件がすべてのHTTPリクエストを別のTCP接続で強制し、HTTP/1.1を使用してから2つの永続的なTCP接続に依存する可能性がある場合の両方で確実に動作することができます。
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 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によって許可されているあらゆる方法で、投稿リクエストを配信できます。（Pipelingで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.
Boshのクライアントと接続マネージャーは、各部分的なHTTP要求または応答をバッファリングし、利用可能になったら完全なリクエストまたは応答を転送する可能性があるため、チャンク転送コーディングを使用することはできません。
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セッションやHTTPリクエストやResponseを含む他の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サーバーセントイベント仕様[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.
ただし、HTTP/1.0のみをサポートしない限り、仲介者に関してチャンクするのではなく、EOFを使用することに大きな利点があるかどうかは明らかではありません。
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.
セクション8.1.4のHTTP [RFC2616]は、サーバーが過負荷にならないようにし、混雑したネットワークでの予期しない副作用を回避するために、1人のユーザークライアントがサーバーまたはプロキシに2つ以上の接続を維持しないことを推奨しています。最近まで、この制限は最も一般的に展開されているブラウザによって実装されていたため、ブラウザ内で共有する必要がある接続が希少なリソースになりました。ブラウザで利用可能なJavaScript APIが接続を非表示にし、セキュリティモデルがフレーム間のリソースの共有を阻害することに注意してください。新しいHTTP仕様[HTTPBIS]は、2つの接続制限を削除し、複数の接続を開くときにクライアントが保守的であることのみを奨励します。実際、最近のブラウザはこの制限を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アプリケーションは、同じブラウザのフレーム、タブ、またはWindows間で共有される1つの長い世論調査に理想的には、開始された長い投票リクエストの数を制限する必要があります。ただし、ブラウザのセキュリティ制約により、このような共有が困難になります。
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 [Cookie]を使用して、同じブラウザからの複数の長い投票要求を検出し、接続の飢vやパイプラインの問題を引き起こす可能性があるため、両方のリクエストの延期を避けることです。
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 Long Pollingの場合、HTTPパイプラインの使用は、短期間でクライアントに複数のメッセージをクライアントに送信する必要がある場合に遅延を減らすことができます。HTTPパイプラインを使用すると、サーバーは一連のHTTPリクエストを受信してエンキューできます。したがって、サーバーは、HTTP応答内でクライアントにメッセージを送信した後、クライアントから新しいHTTP要求を受信する必要はありません。原則として、HTTPパイプラインはHTTP GETおよびHTTP POSTリクエストに適用できますが、HTTP POSTリクエストを使用することがより重要です。実際、PipeliningでHTTP投稿の使用は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 Long Pollingでうまく機能します。プロキシは、その応答をすぐにユーザーエージェントに返すことをお勧めします。ユーザーエージェントはすぐに機能します。
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を送信します。このメカニズムは2つの要因によって引き起こされる問題に直面する可能性があります。彼らがそうするための要件、およびいくつかのキャッシュプロキシはそうではありません）、そして（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.
リバースプロキシは、複数のクライアント間でサーバーへの接続を共有しようとすると、悲しみになります。例として、Apache with Mod_jkは、すべてのクライアント間で小さな接続セット（多くの場合8または16）を共有します。これらの共有接続に長い世論調査が送信される場合、プロキシは接続に飢えている可能性があります。つまり、他の要求（長い世論調査または通常）を支えることができます。したがって、cometメカニズムは現在、各リクエストができるだけ早く完了するという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 Long PollingとHTTPストリーミングの両方がサーバーとプロキシにマイナスの影響を与えると認識される主な理由の1つは、各リクエストに割り当てられたリソースが期間にわたって保持されるため、リクエストに同期プログラミングモデルを使用することです。リクエスト。非同期プロキシとサーバーは、通常のHTTPトラフィックよりもわずかに多くのリソースを使用して、長い世論調査を処理できます。残念ながら、いくつかの同期プロキシが存在し（例：Apache Mod_jk）、多くのHTTPアプリケーションサーバーには、リクエスト処理のためのブロッキングモデルもあります（たとえば、Java Servlet 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リクエストタイムアウトの回答を受け取ることができます。ブラウザのデフォルトのタイムアウト値は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仲介者に長い投票が使用されていることを信号を送る方法はありません。したがって、長い世論調査のリクエストは、中間エンティティでは完全に透明であり、通常の要求として処理されます。これは、長い投票の場合に役立たない操作を実行する仲介エンティティに影響を与える可能性があります。ただし、双方向の流れ（キャッシュなど）を妨げる可能性のある機能は、標準のヘッダーまたはCookieで制御できます。
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".
ベストプラクティスとして、キャッシュは常に長い世論調査の要求または応答で意図的に抑制されます。つまり、「キャッシュ制御」ヘッダーは「ノーキャッシュ」に設定されます。
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の長いポーリングに関するセキュリティの懸念の1つは、長い投票リクエストから返された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] Berners-Lee、T.、Fielding、R。、およびH. Nielsen、「HyperText Transfer Protocol-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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「HyperText Transfer Protocol-HTTP/1.1」、RFC 2616、1999年6月。
[RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006.
[RFC4732] Handley、M.、Rescorla、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] Russell、A.、Wilkins、G.、Davis、D。、およびM. Nesbitt、 "Bayeux Protocol -Bayeux 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] Paterson、I.、Smith、D。、およびP. Saint-Andre、「同期HTTP（BOSH）上の双方向ストリーム」、XSF XEP 0124、2007年2月。
[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] Russell、A。、「comet：Browserの低いレイテンシーデータ」、2006年3月、<http://infrequelenty.org/ 2006/03/comet-low-latency-data-for-the-browser/>>。
[COOKIE] Barth, A., "HTTP State Management Mechanism", Work in Progress, March 2011.
[Cookie] Barth、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] Van 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] Fielding、R.、Ed。、Gettys、J.、Mogul、J.、Nielsen、H.、Masinter、L.、Leach、P.、Berners-Lee、T.、Lafon、Y.、ed。、およびJ. Reschke、ed。、「HTTP/1.1、パート1：URIS、接続、およびメッセージの解析」、2011年3月に進行中の作業。
[JSONP] Wikipedia, "JSON with padding", <http://en.wikipedia.org/wiki/JSONP#JSONP>.
[jsonp] wikipedia、「json with padding」、<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] Crockford、D。、「JavaScriptオブジェクト表記（JSON）のアプリケーション/JSONメディアタイプ」、RFC 4627、2006年7月。
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011.
[RFC6120] Saint-Andre、P。、「拡張可能なメッセージと存在プロトコル（XMPP）：Core」、RFC 6120、2011年3月。
[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[TCP] Postel、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] Hickson、I。、「サーバーセントイベント」、W3CワーキングドラフトWD-Eventsource-20091222、最新バージョン<http://www.w3.org/tr/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.
ジョー・ヒルデブランド、ジュリエン・ラガニエ、ジャック・モフィット、スブラマニアン・ムーネイミー、マーク・ノッティンガム、ジュリアン・レシュケ、マーティン・トムソン、マーティン・タイラーのフィードバックに感謝します。
Authors' Addresses
著者のアドレス
Salvatore Loreto Ericsson Hirsalantie 11 Jorvas 02420 Finland
Salvatore Loreto Ericsson Hirsalantie 11 Jorvas 02420フィンランド
EMail: salvatore.loreto@ericsson.com
Peter Saint-Andre Cisco 1899 Wyknoop Street, Suite 600 Denver, CO 80202 USA
ピーターセントアンドレシスコ1899 Wyknoop Street、Suite 600 Denver、Co 80202 USA
Phone: +1-303-308-3282
EMail: psaintan@cisco.com
Stefano Salsano University of Rome "Tor Vergata" Via del Politecnico, 1 Rome 00133 Italy
ステファノ・サルサノ大学ローマ大学デル・ポリトニコ経由の「トー・ヴェルガタ」、1ローマ00133イタリア
EMail: stefano.salsano@uniroma2.it
Greg Wilkins Webtide
グレッグ・ウィルキンスはwebtide
EMail: gregw@webtide.com