/
878.txt
104 lines (81 loc) · 6.83 KB
/
878.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
[10] 複数の[[要求]]を、それぞれの[[応答]]の到着を待たずに次々に送信することを、
[DFN[[RUBYB[[[パイプライン]]]@en[pipeline]]]]化といいます。
* 仕様書
[REFS[
- [9] '''[CITE@en[RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing]] ([TIME[2014-06-07 01:59:35 +09:00]] 版) <https://tools.ietf.org/html/rfc7230#section-6.3.2>'''
- [21] [CITE@en[RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing]] ([TIME[2014-06-07 01:59:35 +09:00]] 版) <https://tools.ietf.org/html/rfc7230#section-6.6>
]REFS]
* 処理モデル
[11] [[クライアント]]は、[[持続的接続]]に対応していれば、
[[要求]]を[[パイプライン]]化することができます。すなわち、
[[要求]]に対する[[応答]]を待たずに次の[[要求]]を送信できます。 [SRC[>>9]]
[13] [[利用者エージェント]]は、[[冪等]]でない[[メソッド]]の後、
それに対する最終的な[[応答]]の[[状態符号]]を受信するまでは、
(何らかの方法で[[パイプライン]]の途中の[[要求]]の部分的な失敗を検出して回復できる場合を除き、)
[[パイプライン]]化する[['''べきではありません''']]。 [SRC[>>9]]
[15] [[クライアント]]は、すべての[[要求]]に対応する[[応答]]を受信する前に[[接続]]が閉じられた時には、
[[応答]]のない[[要求]]を再試行する[['''べきです''']]。 [SRC[>>9]]
;; [17] [[冪等]]な[[メソッド]]ではなくても再試行して良さそうな感じですが、
本当に良いのでしょうか。
[16] [[クライアント]]は、[[接続]]が失敗した
(最後の[[完全]]な[[応答]]で明示的に閉じられなかった) 後に再試行する時には、
[[接続]]を確立した直後に[[パイプライン]]化しては[['''なりません''']]。 [SRC[>>9]]
;; [19] [[TCPリセット問題]]参照。
[20] [[クライアント]]は、[[パイプライン]]化して[[要求]]を送信していた途中で
[CODE(HTTP)@en[[[close]]]] [[接続オプション]]のある[[応答]]を受信した場合、
それ以降の[[要求]]が処理されたと仮定する[['''べきではありません''']]
[SRC[>>21]]。
[12] [[鯖]]は、[[パイプライン]]化された[[要求]]がすべて[[安全]]なメソッドなら、
各[[要求]]を並列化して処理することができますが、[[応答]]は[[要求]]を受信した順序で送信しなければ[['''なりません''']]。
[SRC[>>9]]
[14] [[中間器]]は、[[パイプライン]]化された[[要求]]を受信した場合、
これを[[内向き]]に[[転送]]する際に[[パイプライン]]化して構いません。 [SRC[>>9]]
[18] [[中間器]]は、[[応答]]を受信するより前に[[内向き]]の[[接続]]が失敗した
(最後の[[完全]]な[[応答]]で明示的に閉じられなかった) 時には、
まだ[[応答]]を受信していない[[要求]]がすべて[[冪等]]な[[メソッド]]なら、
再試行しても構いません。そうでない場合には、受信した[[応答]]があれば[[転送]]した上で、
[[外向き]]の[[接続]]を閉じる[['''べきです''']]。 [SRC[>>9]]
* 歴史
- [1] ''HTTP/1.1 パイプライン化 FAQ'' <http://www2.starcat.ne.jp/~unha/projects/netlib/http/pipelining-faq.html>
- [2] ''WWWDに関連したうんちく'' <http://www.koizuka.jp/wwwd/memo.html#19990410_2>
- [3] ''ApacheのHTTP/1.1パイプライン制御のサポートについて'' <http://mm.apache.or.jp/pipermail/apache-tech/2001-April/thread.html#148>
- [4] ''Network Performance Effects of HTTP/1.1, CSS1, and PNG'' < http://www.w3.org/TR/NOTE-pipelining>
- [5] ''Esehttpd: ESE HTTP Server'' <http://ghost.math.sci.hokudai.ac.jp/esehttpd/>
- [6] ''株式会社オープンループ'' <http://www.openloop.co.jp/press/release/011031.html> パイプラインを使って [[WinIE]] を高速化させるらしい。
- [7] [[Mozilla]] 1.3 のパイプラインにはまだ不具合があるのか、 [[HTTP]] [[頭]]が見えたりごみ (多分前後の資源) が混ざったりすることがありますね。 (設定画面にもまだ不安定だよん☆て書いてあるし。)
[FIG[
[FIGCAPTION[
[8] RFC 2068・2616 (HTTP/1.1) 8.1.2.2 Pipelining
]FIGCAPTION]
> A client that supports persistent connections MAY "pipeline" its
requests (i.e., send multiple requests without waiting for each
response). A server MUST send its responses to those requests in the
same order that the requests were received.
持続接続に対応するクライアントは、その要求を「パイプライン化」しても
(つまり、複数の要求を、それぞれの応答を待たずに送っても) '''構いません'''。
サーバーは、その要求群に対する応答を、要求を受信した順序と同じ順で送らなければ'''なりません'''。
> Clients which assume persistent connections and pipeline immediately
after connection establishment SHOULD be prepared to retry their
connection if the first pipelined attempt fails. If a client does
such a retry, it MUST NOT pipeline before it knows the connection is
persistent. Clients MUST also be prepared to resend their requests if
the server closes the connection before sending all of the corresponding responses.
接続を確立したすぐ後に持続接続とパイプライン化を仮定するクライアントは、
最初のパイプライン化の試行が失敗した時にその接続を再試行する準備をする'''べきです'''。
クライアントがこの再試行をするなら、接続が持続であると知る前にパイプライン化しては'''なりません'''。
クライアントは、サーバーが対応する応答のすべてを送る前に接続を閉じたらその要求を再送信する準備もしなければ'''なりません'''。
[INS[
> Clients SHOULD NOT pipeline requests using non-idempotent methods or
non-idempotent sequences of methods (see section 9.1.2). Otherwise, a
premature termination of the transport connection could lead to
indeterminate results. A client wishing to send a non-idempotent
request SHOULD wait to send that request until it has received the
response status for the previous request.
[[クライアント]]は、[[冪等]]でない[[メソッド]]や、
[[冪等]]でない[[メソッド]]の列を使った[[要求]]を[[油送管化]]する'''べきではありません'''。
[[油送管化]]してしまうと、
[[輸送]][[接続]]を[[早期終端]]した時に不定な結果を招くこととなり得ます。
[[冪等]]でない[[要求]]を送ろうとする[[クライアント]]は、
以前の[[要求]]に対する[[応答状態]]を[[受信]]するまでその[[要求]]の[[送信]]を待つ'''べきです。
]INS]
]FIG]