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>
- [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>
]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] 他の多くの[[アプリケーション層プロトコル]]とは違って、
[[接続]]の初期化のようなプロトコル上の手続きはなく、すぐに[[要求]]を送信できます。

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

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

* 接続上を流れるもの

[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接続の確立]]の項を参照してください。

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

;; [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]]]] についても、
自動的な再試行に関する規定があります。

* 同時接続数

[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]

* ヘッダー

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

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

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

* 下位層プロトコル

[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>