68.txt

[535] [[HTTP]] 通信の直接の当事者間の[[仮想回路]]を、
[DFN[[RUBYB[[[接続]]]@en[connection]]]]といいます。

[564] [[接続]]の両端は[[クライアント]]と[[鯖]]ですが、[[串]]が介在する場合、
一方又は両方が[[串]]となることもあります。

* 仕様書

[REFS[
- [515] '''[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>'''
-- [539] [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.1>
-- [548] [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.4>
-- [553] [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.5>
- [3] [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-3.3.3>
- [512] [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-5.6>
- [108] [CITE@en[RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing]] ([TIME[2015-04-23 00:49:39 +09:00]] 版) <https://tools.ietf.org/html/rfc7230#section-9.1>
- [577] [CITE@en[RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content]] ([TIME[2014-08-07 05:54:02 +09:00]] 版) <https://tools.ietf.org/html/rfc7231#section-6.6.4>
- [45] [CITE@en[RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)]] ([TIME[2015-05-15 10:14:54 +09:00]] 版) <https://tools.ietf.org/html/rfc7540#section-2.2>
- [47] [CITE@en[RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)]] ([TIME[2015-05-15 10:14:54 +09:00]] 版) <https://tools.ietf.org/html/rfc7540#section-3>
- [73] [CITE@en[RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)]] ([TIME[2015-05-15 10:14:54 +09:00]] 版) <https://tools.ietf.org/html/rfc7540#section-5.4>
- [76] [CITE@en[RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)]] ([TIME[2015-05-15 10:14:54 +09:00]] 版) <https://tools.ietf.org/html/rfc7540#section-7>
- [82] [CITE@en[RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)]] ([TIME[2015-05-15 10:14:54 +09:00]] 版) <https://tools.ietf.org/html/rfc7540#section-8.1.4>
- [90] [CITE@en[RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)]] ([TIME[2015-05-15 10:14:54 +09:00]] 版) <https://tools.ietf.org/html/rfc7540#section-9.1>
- [109] [CITE@en[RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)]] ([TIME[2015-05-15 10:14:54 +09:00]] 版) <https://tools.ietf.org/html/rfc7540#section-10.1>
- [111] [CITE@en[RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)]] ([TIME[2015-05-15 10:14:54 +09:00]] 版) <https://tools.ietf.org/html/rfc7540#section-10.2>
- [115] [CITE@en[RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)]] ([TIME[2015-05-15 10:14:54 +09:00]] 版) <https://tools.ietf.org/html/rfc7540#section-10.8>
]REFS]

* HTTP の版

[566] [[接続]]がどのように処理されるかは、[[HTTPの版]]によって異なっています。
[[HTTPの版]]は、[[接続]]上を流れる[[HTTPメッセージ]]の[[先頭行]]に示されています。

[10] 理論上は[[要求]]ごと、あるいは[[応答]]ごとに異なる[[プロトコルの版]]を記述することもできますが、普通はそのようなことはありません。そのような状況で[[受信者]]がどう処理するべきかは不明です。

[11] [[鯖]]がおかしな[[メッセージ]]を返したことによって[[接続]]の途中で
[[HTTP/0.9]] [[メッセージ]]が出現したと判断し、おかしな動作をする
[[Webブラウザー]]もありました。

;; [[HTTP/0.9]>>7]参照。

* 接続の開始

[530] [[接続]]は、[[クライアント]]が[[鯖]] (または[[串]]) 
に対して下位層プロトコルの[[接続]]を確立することにより、開始されます。
[[鯖]]は下位層プロトコルと [[OS]] 等の [[API]] ([[ソケット]]など)
の規定に基づき予め[[接続]]を受け付ける状態で待っている必要があります。

[531] [[接続]]先の[[鯖]]は、他の[[インターネット]]の[[アプリケーション層プロトコル]]と同じように、
[[URL]] などによって指定された[[ドメイン名]]や [[IPアドレス]]などと[[ポート番号]]とを使って識別されます。

;; [532] [CODE(URI)@en[[[http:]]]] の項も参照してください。

[533] [[串]]は、[[利用者エージェント]]の設定などの実装依存の方法で指定されます。
[[串]]が指定されている場合は、[[接続]]先は[[鯖]]ではなく、[[串]]となります。

;; [534] 多くの[[Webブラウザー]]は、 [[proxy.pac]] による指定に対応しています。

[19] [[串]]に[[名前解決]]を委ねる場合を除き、通常は[[ホスト]]部の[[名前解決]]を行い、
[[IPアドレス]]を取得し、それを[[接続]]先の[[鯖]]とします。[[名前解決]]は [[DNS]]
によって行うのが基本ですが、 [CODE[[[/etc/hosts]]]] や [[NetBIOS]] 
など当該システムが実装している他の[[名前解決]]の仕組みが用いられることもあります。

;; [[名前解決]]を参照。

;; [[インターネット]]の [[DNS]] による[[名前解決]]と [CODE[[[localhost]]]]、
それに [[IPアドレス]]による直接指定を除くと、
システム依存の[[名前解決]]方式に依存した接続先の指定は[[相互運用]]不能です。

[536] [[HTTP/1.1]] [[以下]]では、他の多くの[[アプリケーション層プロトコル]]とは違って、
[[接続]]の初期化のようなプロトコル上の手続きはなく、すぐに[[要求]]を送信できます。

[568] [[接続]]が確立されると、[[クライアント]]は[[鯖]]に[[要求]]を送信します。
その送信のタイミングは特に規定されていませんが、通常は即座に送信します。
後述の通り、[[鯖]]は通常タイムアウトを設定しており、一定時間内に[[要求]]が送信されなければ、
エラーとして扱います。

[20] [[クライアント]]が[[名前解決]]に失敗した場合や下位層プロトコルの[[接続]]の確立に失敗した場合は、
当然ながら [[HTTP接続]]を利用することはできず、[[要求]]を送信できません。

[110] [[HTTP/2]] over [[TLS]] は [[ALPN]] によりプロトコルを明示でき、
また[[暗号化]]のため [[TCP]] 上のバイト列を制御することが難しいため、
[[cross-protocol attack]] は困難です [SRC[>>111]]。

[112] [[HTTP/2]] over [[TLS]] は[[接続序文]]により [[HTTP/1.1]] [[以下]]の実装の誤動作を防ごうとしていますが、
非 [[HTTP]] [[プロトコル]]に対する [[cross-protocol attack]] を防ぐものではありません [SRC[>>111]]。

[113] [[Webブラウザー]]は [[port blocking]] により他の[[プロトコル]]が使うことが多い[[ポート]]へのアクセスを拒み、
[[cross-protocol attack]] を難しくしています。

;; [114] [CODE(MIME)@en[[[multipart/form-data]]]] により[[フォームデータ]]を [[HTTP]]
で送信することで、 [[cross-protocol attack]] が試みられることがあります。

* 接続の並行性

[87] [[HTTP/1.1]] [[以下]]では、1つの[[接続]]で同時に送受信できる[[応答]]は1つだけです。
1つの[[文書]]に埋め込まれた複数の[[画像]]が存在する場合など、
[[クライアント]]側の処理性能の向上のためには複数の[[接続]]を[[並列]]に確立する必要があります。

[88] [[HTTP/1.0]] の [[keep-alive]] や [[HTTP/1.1]] の[[持続的接続]]や[[パイプライン]]化を用いると
1つの[[接続]]を再利用して次の[[応答]]を受信することができ、 [[TCP接続]]の再[[確立]]や次の[[要求]]の送受信の時間を節約できますが、
前の[[応答]]が完了するまで次の[[応答]]は送信できませんから、
すぐに[[レンダリング]]開始したいなら、やはり複数の[[接続]]が必要となります。

[89] しかし[[接続]]数が多すぎると[[サーバー]]や[[ネットワーク]]に過剰な負荷を与えてしまう虞があるため、
[[クライアント]]は適当な上限を設けるべきです。

[550] 旧仕様の [[RFC 2616]] までは、ある[[クライアント]]からある[[鯖]] (や[[串]])
への同時接続数は2[[以下]]とするべきだとされていました [SRC[>>549]]。

[REFS[
- [549] [CITE@en[RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1]] ([TIME[2014-06-07 01:51:52 +09:00]] 版) <http://tools.ietf.org/html/rfc2616#page-47>
]REFS]

[551] [[RFC 7230]] は、[[応用]]によっては非現実的なので、特定の上限は設けないが、
[[クライアント]]は[[接続]]を開くのには保守的であるようにと求めています [SRC[>>548]]。

[552] 多くの [[Webブラウザー]]は、00年代前半までは [[RFC]] の上限を既定値とし、
設定によっては更に増やすこともできるようになっていました。
しかしその後 [[Ajax]] の普及などに伴い徐々に制限が緩和されています。

[REFS[
- [6] [CITE[AnyEvent::HTTP - search.cpan.org]] ([TIME[2014-10-22 08:11:41 +09:00]] 版) <http://search.cpan.org/dist/AnyEvent-HTTP/HTTP.pm#%24AnyEvent%3A%3AHTTP%3A%3AMAX_PER_HOST>
]REFS]

[91] [[HTTP/2]] では[[持続的接続]]が基本動作となっており、
[[クライアント]]は必要が無いと判断するまで[[接続]]を閉じずにいることが期待されています
[SRC[>>90]]。[[クライアント]]は 1つの[[接続]]で複数の[[ストリーム]]を使って[[並行]]して[[応答]]を受信できます。
[[クライアント]]は、[[プロキシ]]を含む[[サーバー]]への[[接続]]を、
[[ホスト]]と[[ポート]]の組に対して複数開く[['''べきではありません''']] [SRC[>>90]]。

;; [116] これは[[サーバー]]が[[利用者]]の動作を追跡しやすくすることになり、
注意が必要です。 [SRC[>>115]]

[93] [[HTTP/2]] [[クライアント]]は、異なる値を [[SNI]] に指定する場合や異なる [[TLS]]
[[クライアント証明書]]を指定する場合は、同じ [[IPアドレス]]と [[TCPポート]]に対して複数の[[接続]]を開いて構いません。
しかし同じ指定で複数の[[接続]]を開くことは避ける[['''べきです''']]。 [SRC[>>90]]

;; [103] 逆に複数の[[ホスト]]が同じ[[接続]]を共有する場合 (>>96) があります。

[92] [[HTTP/2]] [[クライアント]]は、既存の[[接続]]が[[ストリーム識別子]]空間を使い果たしつつある場合や、
[[TLSセッション]]の鍵の更新のため必要な場合、
[[エラー]]を検出した場合には、代替となる[[接続]]を新たに開くことができます [SRC[>>90]]。

* 接続の再利用

[94] [[HTTP/1.0]] [[keep-alive]]、[[HTTP/1.1]] [[持続的接続]]、[[HTTP/2]]
では、同じ[[接続]]を複数の[[要求]]と[[応答]]の組の送受信に再利用できます。

[95] [[HTTP/1.0]] と [[HTTP/1.1]] でどのような場合に[[接続]]を再利用できるのかは、
明確な規定がありません。

[96] [[HTTP/2]] の[[起源サーバー]]への接続は、直接のものであれ [CODE(HTTP)@en[[[CONNECT]]]]
[[トンネル]]経由であれ、 [[authority]] が異なっていても当該[[起源サーバー]]が
[[authoritative]] である限り、再利用できます。 [SRC[>>90]]

[97] 具体的には、 [[TLS]] 無しの [[TCP]] では、[[ホスト]]が同じ [[IPアドレス]]に[[解決]]されることをいいます。 [SRC[>>90, >>108, >>109]]
(もちろん[[ポート番号]]も一致する必要があります。)

[98] [CODE(URI)@en[[[https]]]] では、 [[TCP]] のみの場合の条件に加え、
[[サーバー証明書]]が新しい [[TLS接続]]の場合と同様の検査を満足しなければ[['''なりません''']]。
[SRC[>>90, >>108, >>109]]

;; [99] [[SAN]] や[[ワイルドカード証明書]]を使うと、同じ[[証明書]]で複数の
[[authority]] に対応できます。

;; [102] 複数の[[ホスト]]へ同じ[[接続]]を利用できる本規定と、
同時接続の禁止 (>>91) がどう関係するのかは不明です。

;; [117] [[起源]]を超えて[[サーバー]]が[[利用者]]の行動を追跡しやすくなりますから、
注意が必要です [SRC[>>115]]。

[104] [[サーバー]]の構成によっては、 [[SNI]] で指定された[[ホスト]]によって[[中間器]]が異なる[[起源サーバー]]を選択する場合など、
[[クライアント]]が (機密かもしれない) [[要求]]を誤った[[サーバー]]に送ってしまう可能性もあります。
[[サーバー]]は、[[クライアント]]に[[接続]]を再利用してほしくない場合、
[[authoritative]] でないことを [CODE(HTTP)[[[421]]]]
[[応答]]によって表明できます。 [SRC[>>90]]

;; [105] [[クライアント]]は事前に判定できないので、[[要求]]が他者に漏洩してしまう可能性があるわけですが、
良いのでしょうか... [[クラウド]]サービスの共通の[[逆串]]などで[[証明書]]まで共有していても異なる[[起源サーバー]]に接続されることはあるでしょうから、その場合[[クラウド]]サービス提供者は確実に
[CODE(HTTP)[[[421]]]] [[応答]]を返すよう注意が必要です。

[106] [[HTTP/2]] [[プロキシ]]を使う[[クライアント]]は、
すべての[[要求]]を同じ[[接続]]に送信します [SRC[>>90]]。

* 接続上を流れるもの

[401] 通常の [[HTTP]] の通信では、[[HTTPメッセージ]]が[[接続]]上を送受信されます。

[523] [[HTTPメッセージ]]は、[[要求メッセージ]]または[[応答メッセージ]]です。
現在の [[HTTP]] では[[クライアント]]から[[鯖]]へと送信されるのが[[要求]]、
[[鯖]]から[[クライアント]]へ送信されるのが[[応答]]と決まっています。

[FIG(sequence)[
:C:[[クライアント]]
:S:[[鯖]]
:C ## S:[[接続の確立]]
:C -> S:[[要求]]
:S -> C:[[応答]]
:C ## S:[[接続]]を閉じる
]FIG]

[522] [[持続的接続]]機能を使うと、1つの[[接続]]で複数の[[要求]]と[[応答]]の組をやりとりすることができます。

;; [9] [[持続的接続]]は [[HTTP/1.1]] では標準機能となっています。
([[HTTP/1.0]] では [[Keep-Alive]] は実験的に追加された機能でした。)
詳しくは[[持続的接続]]を参照。

[513] [[要求]]と[[応答]]の対応関係は、明示されません。
[[要求]]が送信されたのと同じ順に[[応答]]が送信されます。 [SRC[>>512]]

;; [524] ですから、下位層プロトコルは順序を保証するものである必要があります。

[525] [[応答]]は、必ず[[要求]]に対する反応として送信されます。
[[要求]]がないのに[[応答]]が送信されることは、原則としてありません。

;; [526] 例外的に、[[接続]]をはじめてから何も送られないままタイムアウトした場合など、
特別に[[応答]]が送信され、ただちに[[接続]]が閉じられるケースがあります。

[569] [[応答]]が送信されるタイミングは、特に規定されていません。
[[鯖]]が[[要求]]の末尾まで読み終えるよりも先に送信される可能性もありますし、
[[要求]]がすべて読み終わってからしばらく経ってようやく送信される可能性もあります。
[[要求]]が送信され始めるより前に[[応答]]が返されることもあるかもしれません。
[[long poll]] では、[[応答]]の送信開始や送信完了までの待機時間が長いかもしれません。

[44] [[クライアント]]は通常タイムアウトを設定しており、一定時間内に[[応答]]の一部または全部が返されなければ、
通信エラーとみなします。タイムアウトまでの[[時間]]は、[[アプリケーション]]の性質や[[サーバー]]や[[クライアント]]の用途、
想定される[[ネットワーク]]の状態など様々な因子に依存するため、一概には決められません。

[514] [CODE(HTTP)[[[1xx]]]] [[応答]]が最終[[応答]]より前に送信される場合には、
1つの[[要求]]に複数の[[応答]]が対応することとなります。 [SRC[>>512]]

[FIG(sequence)[
:C:[[クライアント]]
:S:[[鯖]]
:C -> S:[[要求]]
:S -> C:[CODE(HTTP)[[[1xx]]]] [[応答]]
:S -> C:[CODE(HTTP)[[[1xx]]]] [[応答]]
:S -> C:[[最後の応答]]
]FIG]

;; [527] [[要求]]送信後に[[接続]]が閉じられた場合など例外的なケースを除けば、
[[要求]]には必ず[[応答]]が送られます。

[570] [[要求]]に [CODE(HTTP)[[[100-continue]]]] が指定されている場合には、
[[要求]]の[[ヘッダー部]]を読み終えた時点で[[鯖]]が [CODE(HTTP)[[[100]]]]
[[応答]]を返し、その後[[要求]]の[[メッセージ本体]]を処理してから最終的な[[応答]]を返すことが期待されています。
(詳しくは [CODE(HTTP)[[[100-continue]]]] を参照してください。)

[528] [[メッセージ]]の境界は、[[メッセージ]]自体によって、または[[接続]]が閉じられることにより識別されます。下位層プロトコルは[[オクテット列]]の送受信のみが要求されています。

;; [529] 詳しくは[[メッセージ]]と[[メッセージ本体]]の項を参照してください。

[546] [[パイプライン]]化により、[[要求]]に対する[[応答]]の到着を待たずに次の[[要求]]を送ることもできます。

;; 詳しくは[[HTTPパイプライン]]の項を参照してください。

[579] [[要求]]が[[非妥当]]である場合や、[[要求]]の[[要求行]]や[[ヘッダー]]、
あるいは[[メッセージ本体]]の途中で[[鯖]]が処理できないと判断した場合、
[[鯖]]が[[要求]]をすべて読み終わる前や[[クライアント]]が[[要求]]を送信し終わる前に[[鯖]]がエラー
([CODE(HTTP)[[[400]]]] や [CODE(HTTP)[[[413]]]] や [CODE(HTTP)[[[505]]]] など) を返したり、
[[接続]]を閉じたりすることがあります。

[402] [CODE(HTTP)@en[[[CONNECT]]]] [[メソッド]]に対して [CODE(HTTP)[[[2xx]]]]
[[応答]]が返された場合、[[メッセージ]]はそこで終端され、
以後は[[トンネル]]となります。詳しくは [CODE(HTTP)@en[[[CONNECT]]]]
の項を参照してください。

[562] [CODE(HTTP)@en[[[Upgrade:]]]] によって[[プロトコル]]が切り替えられる場合、
[[鯖]]によって [CODE(HTTP)[[[101]]]] が返され、それよりも後は新しい[[プロトコル]]に切り替わります。
詳しくは [CODE(HTTP)@en[[[Upgrade:]]]] や [[WebSocket接続の確立]]、
[[WebSocket接続]]の項を参照してください。

;; [38] [[パイプライン化]]と [CODE(HTTP)@en[[[CONNECT]]]] や [CODE(HTTP)@en[[[Upgrade:]]]]
の組み合わせは思わぬ副作用を生むかもしれません。例えば別のプロトコルに切り替わる前に[[クライアント]]がデータを送信していると、
[[鯖]]がそれをどう解釈するかが曖昧となり、[[セキュリティー]]や[[相互運用性]]の問題を引き起こすことがあります。
[[RFC 7472]] や [[HTTPS]] の歴史の項も参照。

;; [43] [[クライアント]]が対応していない [CODE(HTTP)[[[101]]]]
[[応答]]を受信した場合の[[クライアント]]の処理は、[CODE(HTTP)[[[101]]]]
を参照してください。

[572] [[メッセージ]]を構成するデータの送信速度は、一様でなくても構いません。
例えば、[[鯖]]が [CODE(MIME)@en[[[multipart/x-mixed-replace]]]] [[応答]]を返す場合、
ある程度の時間をあけて複数の[[本体部分]]を送信し続けることになります。

;; もちろん、実装によってはタイムアウトがありますから、
あまりにも長時間データの送信が行われないと、エラーとみなして[[接続]]が閉じられることがあります。

[573] 用途によっては、[[メッセージ本体]]が事実上無限である場合もあります。
その場合は、相手側によって[[接続]]が閉じられたり、
ネットワークエラーなど外部的な要因で[[接続]]が閉じられたりしない限り、
データの送信が継続されます。

;; [574] ですから、 [[HTTP]] の実装は、[[メッセージ]]が有限の長さを持つことを仮定することはできません。

* 接続を閉じる

[558] [[クライアント]]、[[鯖]]、[[串]]はいずれも任意の時点で[[接続]]を閉じて構いません
[SRC[>>553]]。

[576] [[鯖]]は過負荷時に [WEAK[([CODE(HTTP)[[[503]]]] を返すか、または)]]
直ちに[[接続]]を閉じても構いません [SRC[>>577]]。

[567] ただし [[HTTP/1.0]] では、 [CODE(HTTP)@en[[[Keep-Alive]]]] が有効な場合を除き、
[[メッセージ]]の終わりで[[接続]]も閉じることになっています。

[540] [[接続]]はいつでも予告なく閉じられることがあります [SRC[>>539]]
から、[[実装]]は、[[接続]]の終了に対して[[頑強]]でなければなりません。

[537] [[持続的接続]]の終了は、 [CODE(HTTP)@en[[[Connection:]] [[close]]]]
によって表します。詳しくは [CODE(HTTP)@en[[[close]]]] や[[持続的接続]]の項を参照してください。

[4] [[接続]]を閉じることは、[[メッセージ本体]]の終了を知らせるために使うことがあります。
[[メッセージ本体]]の項を参照してください。

[561] [[鯖]]は、下位層プロトコルの特性により[[メッセージ]]の一部又は全部が失われないように注意して[[接続]]を閉じる必要があります。
詳しくは[[TCPリセット問題]]を参照してください。

;; [571] [CODE(HTTP)@en[[[CONNECT]]]] の項も参照してください。

** エラーによる接続の終了

[5] [[メッセージ本体]]が存在し、 [CODE(HTTP)@en[[[Transfer-Encoding:]]]]
[[ヘッダー]]の最後の[[転送符号化]]が [CODE(HTTP)@en[[[chunked]]]]
以外である[[要求メッセージ]]を受け取った時は、 [CODE(HTTP)[[[400]]]]
[[応答]]を返して[[接続]]を閉じなければ[['''なりません''']] [SRC[>>3]]。

[510] [CODE(HTTP)[[[Content-Length:]]]] が無視されない場合で、
複数あったり[[非妥当]]だったりする場合は、
[[接続]]を閉じなければ[['''なりません''']] [SRC[>>3]]。

[511] [CODE(HTTP)[[[Content-Length:]]]] が無視されない場合で、
その長さの[[メッセージ本体]]を受け取らずに[[接続]]が閉じられたり、
[[タイムアウト]]したりした時には、[[接続]]を閉じなければ[['''なりません''']] [SRC[>>3]]。

[538] 下位ネットワークの障害や[[接続]]の当事者のシステム上の障害などによって、
[[メッセージ]]の途中で[[接続]]が中断されたり、
何の送受信も発生しないまま長時間経過したりすることがあります。
こうした場合の処理については、[[メッセージ]]や[[メッセージ本体]]の項を参照してください。

[547] [[パイプライン化]]している場合で途中で[[接続]]が閉じられたときの処理は、
[[HTTPパイプライン]]の項を参照してください。

[40] [[サーバー]]の[[死活監視]]を行うソフトウェアの中には、 [[TCP]]
レベルでの検査を行うものもあります。これは [[TCP接続]]が[[確立]]できることを確認すると、
すぐに切断するものです。この場合 [[HTTPメッセージ]]を送受信することなく[[接続]]が終了しますから、
[[サーバー]]はそのような場合も適切に処理できる必要があります。

[559] [[鯖]]は、[[クライアント]]が再試行すると期待して[[接続]]を閉じるよりは、
できれば[[持続的接続]]を維持して、一時的な過負荷は[[トランスポート層]]の[[フロー制御]]に任せる[['''べきです''']]
(閉じて再試行させる方が[[輻輳]]を悪化させるかもしれません) [SRC[>>553]]。

[560] [[クライアント]]は[[メッセージ本体]]の送信中に[[接続]]を監視して、
[[鯖]]が受信を望まず[[接続]]を閉じようとしていることがわかれば、
すぐに転送をやめて[[接続]]を閉じる[['''べきです''']] [SRC[>>553]]。

;; [580] [CODE(HTTP)[[[100]]]] や [CODE(HTTP)[[[413]]]] も参照してください。

[578] [[串]]は[[上流]]から[[非妥当]]な[[応答]]を受け取った時、
[[転送]]するかわりに [CODE(HTTP)[[[502]]]] [[応答]]を返すことができます。
[CODE(HTTP)@en[[[Content-Length:]]]] が[[非妥当]]な場合は更に[[接続]]を閉じなければならないこともあります。
詳しくは [CODE(HTTP)[[[502]]]] を参照してください。

** タイムアウト

[554] [[鯖]]は普通は[[タイムアウト]]を設定しており、
活性状態でない[[接続]]をそれ以上維持しません。 [SRC[>>553]]

[555] [[串]]は、[[クライアント]]が同じ[[串]]により多く[[接続]]して来るであろうことから、
[[タイムアウト]]を大きめにするかもしれません。 [SRC[>>553]]

[556] [[クライアント]]も[[タイムアウト]]を設定して、
必要のない[[接続]]をそれ以上維持しないかもしれません。

[557] [[タイムアウト]]したい[[クライアント]]や[[鯖]]は、
当該[[接続]]を [[graceful close]] する[['''べきです''']] [SRC[>>553]]。
[[実装]]は定期的に[[接続]]を閉じる信号を監視して、
適宜応答する[['''べきです''']] [SRC[>>553]]。

[12] [[鯖]]によっては、[[HTTP/1.0]] [[応答]]を送り終えた後もしばらく[[接続]]を閉じないものがあるといわれています。

* 要求の再試行

[541] [[実装]]は、[[接続]]が閉じられた時に回復しないといけないかもしれないことを想定しておく[RUBYB[べき]@en[ought to]]です
[SRC[>>539]]。

[542] [[クライアント]]は、[[内向き]]の[[接続]]が意図せず閉じられたとき、
中断された[[要求]]群がすべて[[冪等]]なメソッドだった場合には、
新しい[[接続]]を開いてその[[要求]]を自動的に再転送して構いません。 [SRC[>>539]]

[544] [[利用者エージェント]]は、何らかの手段で[[要求]]が本当は[[冪等]]であると分かっている場合や元の[[要求]]が適用されなかったと分かっている場合を除き、
[[冪等]]でない[[メソッド]]の[[要求]]を自動的に再試行しては[['''なりません''']]。
[SRC[>>539]]

[545] [[クライアント]]は、失敗した自動再試行を自動的に再試行する[['''べきではありません''']]
[SRC[>>539]]。

[543] [[串]]は、[[冪等]]でない[[要求]]を自動的に再試行しては[['''なりません''']]
[SRC[>>539]]。

;; [565] [CODE(HTTP)@en[[[Expect:]] [[100-continue]]]] についても、
自動的な再試行に関する規定があります。

[83] [[HTTP/2]] では、次の場合、[[クライアント]]は[[要求]]が処理されていないことが保証されます [SRC[>>82]]。
[FIG(list)[
- [84] [CODE(HTTP)@en[[[GOAWAY]]]] [[フレーム]]で示された最大[[ストリーム識別子]]よりも大きな[[ストリーム識別子]]の[[ストリーム]]の[[要求]]は、
処理されていません。
- [85] [CODE(HTTP)@en[[[RST_STREAM]]]] [[フレーム]]で[[誤り符号]]
[CODE(HTTP)@en[[[REFUSED_STREAM]]]] が指定されていれば、その[[ストリーム]]の[[要求]]は処理されていません。
]FIG]

[86] これらの処理されていない[[要求]]は、失敗ではなく、
[[クライアント]]は[[冪等]]か否かに関わらず自動的に再試行して構いません [SRC[>>82]]。

[107] [CODE(HTTP)[[[421]]]] [[応答]]を受信した[[クライアント]]は、
[[冪等]]か否かに関わらず自動的に再試行して構いません [SRC[>>90]]。

* ヘッダー

[521] [CODE(HTTP)@en[[[Connection:]]]] [[ヘッダー]]は、[[接続]]の取り扱いを指定するものです。

[21] [CODE(HTTP)@en[[[Expect:]] [[100-continue]]]] はデータの送信のタイミングについて指示するものです。

;; [CODE(HTTP)@en[[[100-continue]]]] 参照。

* HTTP/2 接続

[46] [DFN[[RUBYB[接続]@en[connection]]]]は、2つの[[エンドポイント]]の間の[[トランスポート層]]の[[接続]]です [SRC[>>45]]。

[48] [[HTTP/2接続]]は、 [[TCP接続]]上で動作する[[アプリケーション層プロトコル]]です
[SRC[>>47]]。

;; [49] とはいえ、[[TLS]] が間に挟まることもあります。

[64] [CODE(URI)@en[[[https:]]]] [[URL]] への接続については、 [[HTTPS]] を参照。

[66] [[TLS handshake]] が完了したら、[[クライアント]]と[[サーバー]]は、共に
[[connection preface]] を送信しなければ[['''なりません''']] [SRC[>>47]]。

[65] [CODE(URI)@en[[[http:]]]] [[URL]] への接続については、 >>51 を参照。

[67] [CODE(HTTP)@en[[[Alt-Svc:]]]] などで事前に[[サーバー]]が [[HTTP/2]]
に対応していると知っている場合は、 [CODE(URI)@en[[[http:]]]] [[URL]]
への接続時に、はじめから [[HTTP/2]] を用いることができます。
[[クライアント]]は、 [[connection preface]] を送信しなければ[['''なりません''']]。
その後すぐに[[フレーム]]を送信できます。[[サーバー]]は、
[[connection preface]] を送信しなければ[['''なりません''']]。 [SRC[>>47]]

;; [69] この方法が広く実装されるかどうかは不明です。

;; [68] 以前 [[HTTP/2]] に対応していたからといって、将来も [[HTTP/2]]
に対応しているとは限りません。 [SRC[>>1]] 前のアクセスで [[HTTP/2]]
だったか否かによって次回の接続方法を決めるべきではありません。

[70] [[利用者エージェント]]が各方法で [[HTTP/2]] を利用する(できる)か否かは、
[[figerprinting vector]] です。

[71] [[エンドポイント]]は、各[[接続]]の次の情報を保持します。
[FIG(list members)[
:[[エンドポイント]]種別:自身が[[クライアント]]であるか、[[サーバー]]であるかのいずれかです。
:[[HTTPストリーム]]群:[[接続]]内にある0個[[以上]]の[[HTTPストリーム]]の情報です。
]FIG]

[72] >>60 の場合を除き、初期状態では[[ストリーム]]はありません。

[74] [[接続エラー]]により、[[接続]]が閉じられることがあります。
また[[エンドポイント]]はいつでも[[接続]]を閉じることができます [SRC[>>73]]。
接続を閉じる時は [CODE[[[GOAWAY]]]] [[フレーム]]を送信する[['''べきです''']] [SRC[>>73]]。

;; [[接続エラー]]を参照。

[75] [[TCP接続]]が閉じられたり [[RST]] されたりした時に [[open]]
や [[half-closed]] の[[状態]]だった[[ストリーム]]は、
自動的に再試行することはできません [SRC[>>73]]。

[77] [[誤り符号]] [DFN[[CODE[[[ENHANCE_YOUR_CALM]]]]]] ([CODE[[[0xb]]]])
は、 [[過負荷]]を引き起こしかねない動作を [[peer]] が示したことを表します [SRC[>>76]]。

[78] [[誤り符号]] [DFN[[CODE[[[INADEQUATE_SECURITY]]]]]] ([CODE[[[0xc]]]])
は、下位層輸送路が最小セキュリティー要件を満たさないことを示します [SRC[>>76]]。

[79] [[誤り符号]] [DFN[[CODE[[[HTTP_1_1_REQUIRED]]]]]] ([CODE[[[0xd]]]])
は、 [[HTTP/2]] ではなく [[HTTP/1.1]] が必要であることを示します [SRC[>>76]]。

[80] [[ストリーム]]の処理については、[[ストリーム]]や[[フレーム]]を参照。

[81] [[メッセージ]]の送受信については、[[HTTPメッセージ]]、
[[HTTP要求]]、[[HTTP応答]]を参照。

[FIG(short list)[
- [[HTTP/2クライアント]]
- [[HTTP/2サーバー]]
- [[接続エラー]]
- [[HTTPS]]
-- [[ALPN]]
- [[フロー制御]]
]FIG]

** [CODE(HTTP)@en[Upgrade: h2c]]

[51] [[HTTP/2]] は、 [CODE(HTTP)@en[[[Upgrade:]] [[h2c]]]]
により [[HTTP]] over [[TCP]] から [[HTTP/2]] over [[TCP]]
へと移行する方法を規定しています。

;; [52] この方法が広く実装されるかどうかは不明です。

[50] [[クライアント]]は、 [CODE(URI)@en[[[http:]]]] [[URL]]
にアクセスする場合、 [[HTTP/1.1]] [[要求]]の [CODE(HTTP)@en[[[Upgrade:]]]]
[[ヘッダー]]に、 [CODE(HTTP)@en[[[h2c]]]] と指定します [SRC[>>47]]。

[53] その場合、[CODE(HTTP)@en[[[HTTP2-Settings:]]]] [[ヘッダー]]をちょうど1つ指定しなければ[['''なりません''']] [SRC[>>47]]。

;; [54] 必然的に [CODE(HTTP)@en[[[Connection:]]]] [[ヘッダー]]に
[CODE(HTTP)@en[[[Upgrade]]]] と [CODE(HTTP)@en[[[HTTP2-Settings]]]]
を指定することになります。

;; [55] [[要求]]に [[payload body]] があれば、それも [[HTTP/2]] に切り替わる前に送る必要があります。
次の[[要求]]を送れるようになるまでの遅延を嫌う場合は、
[CODE(HTTP)@en[[[OPTIONS]]]] [[要求]]をかわりに送ることができます。 [SRC[>>47]]

[57] [[サーバー]]は、[[HTTP/2]] に対応していれば、 [CODE(HTTP)[[[101]]]]
[[応答]]を返します。その末尾の[[空行]]の直後から [[HTTP/2]] [[フレーム]]を送信できます。
[SRC[>>47]]

[56] [[サーバー]]は、 [[HTTP/2]] に対応していなければ、
[CODE(HTTP)@en[[[Upgrade:]]]] を無視して通常通り [[HTTP/1.1]] で[[応答]]を返すことになります。

[61] [[サーバー]]は、 [[TLS]] 上の [[HTTP]] なら [CODE(HTTP)@en[[[Upgrade:]] [[h2c]]]]
を無視しなければならないと考えられます。

[62] [[サーバー]]は、[[要求]]に [CODE(HTTP)@en[[[HTTP2-Settings:]]]] [[ヘッダー]]が複数あるか、
1つもなければ、[[HTTP/2]] に切り替えては[['''なりません''']] [SRC[>>47]]。

[63] [[サーバー]]は、[[HTTP/2]] に切り替える場合、
[CODE(HTTP)@en[[[HTTP2-Settings:]]]] [[ヘッダー]]の値を通常の 
[CODE[[[SETTINGS]]]] [[フレーム]]と同じように解釈します。
[CODE(HTTP)[[[101]]]] [[応答]]が [[implicit acknowledgement]] となるため、
[[explicit acknowledgement]] は不要です。 [SRC[>>47]]

[58] [[HTTP/2]] に切り替えた場合、[[サーバー]]が最初に送る[[フレーム]]は、
[CODE[[[SETTINGS]]]] [[フレーム]]の [[server connection preface]] 
でなければ[['''なりません''']] [SRC[>>47]]。

[59] [[クライアント]]は、[CODE(HTTP)[[[101]]]] [[応答]]を受信したら、
[CODE[[[SETTINGS]]]] [[フレーム]]を含む [[connection preface]]
を送信しなければ[['''なりません''']] [SRC[>>47]]。

[60] [[HTTP/2]] に切り替わった場合、切り替え前の [[HTTP/1.1]] [[要求]]は、
[[ストリーム識別子]] [CODE[[[1]]]]、[[既定優先度値]]を割り当てられます。
[[ストリーム]] [CODE[1]] は、暗示的に[[クライアント]]から[[サーバー]]へと
"[[half-closed]]" された状態となります。[[サーバー]]は、
切り替え前の [[HTTP/1.1]] [[要求]]に切り替え後に[[応答]]しなければ[['''なりません''']]。
この[[応答]]には[[ストリーム]] [CODE[1]] を使います。 [SRC[>>47]]

* 下位層プロトコル

[516] [[HTTP]] の[[メッセージ]]は下位の ([[トランスポート層]]や[[セッション層]]の)
[[プロトコル]]に依存しておらず、[[信頼できる]]輸送路であって、
[[要求]]の順序を保存した配送と[[応答]]の順序を保存した配送のみを要求しています [SRC[>>515]]。

[2] 実際には [[HTTP]] は、下位層プロトコルとして、
[FIG(list)[
- [517] [[TCP]]
- [518] [[SSL]] または [[TLS]] ([[HTTPS]] 参照。)
- [[Unix domain socket]]
- [[SOCKS]]
]FIG]
... のいずれかを用います。

;; [7] [[UPnP]] では [[UDP]] が使われます ([[SSDP]])。

;; [37] [[HTTP over SCTP]] も提案されましたが、関心を集められませんでした。

[519] [[HTTP]] の[[要求]]や[[応答]]の構造と下位層プロトコルのデータ単位との対応関係は、
[[HTTP]] の仕様書の[[適用範囲]]外とされています [SRC[>>515]]。

;; [520] それ、[[アプリケーション層プロトコル]]の重要なところじゃないのでしょうか。。。

** TCP

[17] [[three-way handshake]] を経て [[TCP]] [[接続]]が確立された後に [[TCP]]
によって伝送される[[オクテット列]]が [[HTTP接続]]の[[オクテット列]]です。
なお [[TCP]] [[セグメント]]の境界は [[HTTP接続]]に反映されません。
[[TCP]] [[セグメント]]の境界と [[HTTP接続]]上の[[メッセージ]]境界と一致しているとは限りません。

[18] [[HTTP接続]]を閉じる、あるいは閉じられるとは、 [[TCP]] [[接続]]を閉じる、あるいは閉じられることを意味します。
[[HTTP接続]]を閉じると [CODE[[[FIN]]]] [[セグメント]]が送信されることになります。
[CODE[[[FIN]]]] [[セグメント]]を受信すると [[HTTP接続]]が相手に閉じられたことを表します。
その他に [CODE[[[RST]]]] や[[タイムアウト]]など [[TCP]] プロトコル上の規定や実装によって正常でない形で接続が閉じられることもあります。

[16] [[TCP]] [[緊急データ]]と [[HTTP]] の関係は明文化されていません。

[33] [[TCP]] [CODE[[[PSH]]]] フラグの取り扱いについて [[HTTP]] 特有の規定は特にありません。
(例えば[[HTTPメッセージ]]の最後で [CODE[[[PSH]]]] フラグを立てなければならないというようなことは特にありません。)

[34] なお、通常は [[HTTP]] over [[TCP]] と [[HTTP]] over [[TLS]] over [[TCP]]
は別の[[ポート]]を使いますが、両方を同じ[[ポート]]で受け付けられないこともありません
(両者は区別可能です)。

[EG[
[35] [[IPP]] over [[HTTP]] と [[IPP]] over [[HTTPS]] はどちらも[[既定のポート番号]]
[CODE[[[631]]]] を共有しており、両方を受け付ける実装もあります [SRC[>>36]]。

[REFS[
- [36] [CITE@en[RFC 7472 - Internet Printing Protocol (IPP) over HTTPS Transport Binding and the 'ipps' URI Scheme]] ([TIME[2015-03-04 12:23:14 +09:00]] 版) <https://tools.ietf.org/html/rfc7472#section-4.3>
]REFS]
]EG]

[41] [[HTTP]] over [[TCP]] は、 [CODE(URI)@en[[[http:]]]] [[URL]] によって表されます。

** TLS

[14] [[SSL]] や [[TLS]] での利用については、 [[HTTPS]] を参照。

[42] [[HTTP]] over [[TLS]] over [[TCP]] は、 [CODE(URI)@en[[[https:]]]] [[URL]] によって表されます。

** Unix ドメインソケット

[15] (同じ [[Unix]] 環境上で動作する) [[逆串]]から[[アプリケーション鯖]]への通信などに
[[Unixドメインソケット]]を使う場合があります。

[30] [[鯖]]が予め[[ソケット]]を作成しておき、[[クライアント]]がこれに[[接続]]することで、
当該[[ソケット]]を使った読み書きが [[HTTP接続]]となります。[[ソケット]]による[[接続]]を閉じる、
または閉じられると、 [[HTTP接続]]が閉じる、あるいは閉じられることとなります。

;; [8] [[HTTP]] に特化した仕様書は特にありません。

[29] 次のような実装例があります。

[REFS[
- [26] [CITE[Curl: HTTP connection to unix socket]] ([[Bart Whiteley (bwhiteley_at_novell.com)]] 著, [TIME[2010-12-20 03:05:05 +09:00]] 版) <http://curl.haxx.se/mail/lib-2008-04/0279.html>
- [28] [CITE[Module ngx_http_proxy_module]] ([TIME[2015-02-26 15:57:24 +09:00]] 版) <http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass>
- [27] [CITE@en[Starlet + Server::Stater で UNIX domain socketに対応しました - Hateburo: kazeburo hatenablog]] ([TIME[2015-03-07 17:04:32 +09:00]] 版) <http://kazeburo.hatenablog.com/entry/2013/11/26/002727>
]REFS]

** SOCKS

[22] [[SOCKS proxy]] ([[SOCKS]] [[プロトコル]]による [[TCP/IP]] [[トンネル]])
を介して [[HTTP]] [[クライアント]]から [[HTTP]] [[鯖]]に[[接続]]することがあります。

[25] 多くの[[Webブラウザー]]その他の [[HTTP]] [[クライアント]]が、[[串]]の一種として
[[SOCKS]] に対応しています。また [[socksify]] や [[tsocks]] のようなソフトウェアによって通常の
[[TCP/IP]] [[接続]]が [[SOCKS]] の[[接続]]に置き換えられることもあります。

[23] 他の [[TCP]] [[アプリケーション]]と同様に、[[SOCKS]] [[鯖]]が[[接続]]するべき
[[IPアドレス]]または[[ホスト名]]と [[TCP]] [[ポート]]を指定して[[接続]]を確立します。
以後 [[SOCKS]] [[プロトコル]]上の送受信データが [[HTTP接続]]となります。
[[SOCKS]] の[[接続]]が閉じる、あるいは閉じられると、 [[HTTP接続]]が閉じる、
あるいは閉じられることとなります。

[32] [[SOCKS]] の下位層の [[TCP/IP]] [[ネットワーク]]エラーその他の原因で [[SOCKS]]
[[接続]]が異常に閉じられることがあります。

;; [24] [[HTTP]] に特化した仕様書は特にありません。

* MIME 型

[563] [[接続]]そのものではありませんが、[[接続]]上の[[要求]]の列または[[応答]]の列を表す
[[MIME型]] [CODE(MIME)@en[[[application/http]]]] があります。

;; [CODE(MIME)@en[[[application/http]]]] 参照。

* URL

[31] [CODE(URI)@en[[[http:]]]], [CODE(URI)@en[[[https:]]]] を参照。

* 歴史

[FIG(quote)[
[FIGCAPTION[
[1] [[HTTP]] ([[RFC 1945]] 1.2, [[RFC 2068]] 1.3, [[RFC 2616]] 1.3)
]FIGCAPTION]

>
:connection:A transport layer virtual circuit established between two [DEL[[INS[{1945}]] application]]
programs for the purpose of communication.

:接続:2つの[DEL[応用]]プログラム間の通信目的で確立される[[転送層]]仮想回路。
]FIG]

[575] [CITE@en[Re: Fetch: HTTP authentication and CORS]]
( ([[Jonas Sicking]] 著, [TIME[2013-05-05 14:39:46 +09:00]] 版))
<http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0502.html>

[581] [CITE@en[RFC 6202 - Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP]]
( ([TIME[2014-07-20 07:14:03 +09:00]] 版))
<http://tools.ietf.org/html/rfc6202#section-5.1>

[582] [CITE@en[draft-mogul-http-ooo-00 - Support for out-of-order responses in HTTP]]
( ([TIME[2014-10-18 15:27:44 +09:00]] 版))
<https://tools.ietf.org/html/draft-mogul-http-ooo-00>

[13] [CITE@en[draft-zhu-http-fullduplex-08 - Implications of Full-Duplex HTTP]]
([TIME[2014-10-20 09:40:59 +09:00]] 版)
<https://tools.ietf.org/html/draft-zhu-http-fullduplex-08>

[39] [CITE[Part2 - browsersec - Browser Security Handbook, part 2 - Browser Security Handbook - Google Project Hosting]]
([TIME[2015-03-31 16:43:55 +09:00]] 版)
<https://code.google.com/p/browsersec/wiki/Part2#Simultaneous_connection_limits>