HA Proxy 白帯シリーズ(1) ちょっと必要にかられて HA Proxy のドキュメントを勝手に翻訳（1）〜 1.Quick reminder about HTTP の 1.1. The HTTP transaction model を訳す 〜

どうも、英語を中学一年生からやり直したいかっぱこと川原 洋平(@inokara) です。

はじめに

ちょっと必要にかられて HA Proxy のドキュメントを勝手に訳してみるこのシリーズ第一弾。今回は以下の章を訳してみました。

• The HTTP transaction model

尚、内容につきましては参考程度に…。例によって Powerd by Google 翻訳となっております。有難うございます。不備等ありましたらコメント頂けましたら幸いです。

1. Quick reminder about HTTP

When haproxy is running in HTTP mode, both the request and the response are fully analyzed and indexed, thus it becomes possible to build matching criteria on almost anything found in the contents.

HAProxy が HTTPモードで動作する場合、リクエストとレスポンスの両方が解析されインデックスされるので（リクエストとレスポンス）の内容の殆どを一致させることが可能となります。

However, it is important to understand how HTTP requests and responses are formed, and how HAProxy decomposes them. It will then become easier to write correct rules and to debug existing configurations.

しかし、HTTP リクエストとレスポンスを形成する方法を理解することが重要であり、どのようにして HA Proxy は それらを分解するのかを知ることで正しい設定を記述することと既存の構成をデバッグすることが容易になります。

1.1 The HTTP transaction model

The HTTP protocol is transaction-driven. This means that each request will lead to one and only one response. Traditionally, a TCP connection is established from the client to the server, a request is sent by the client on the connection, the server responds and the connection is closed. A new request will involve a new connection :

HTTPプロトコルはトランザクション·ドリブンである。これは、各リクエストは 1 つだけレスポンスにつながることを意味します。伝統的に TCP 接続がクライアントからサーバに確立され、リクエストは接続上でクライアントによって送信され、サーバーが応答し、接続が閉じられる。新しい要求が新しい接続を必要とします。

[CON1] [REQ1] ... [RESP1] [CLO1] [CON2] [REQ2] ... [RESP2] [CLO2] ... 

In this mode, called the “HTTP close” mode, there are as many connection establishments as there are HTTP transactions. Since the connection is closed by the server after the response, the client does not need to know the content length.

このモードでは “HTTP close” モードと呼ばれ、これらの接続は多くの HTTP トランザクションがあるようなものです。接続が応答した後にサーバーによって閉じられているので、クライアントはコンテンツ長を知る必要がありません。

Due to the transactional nature of the protocol, it was possible to improve it to avoid closing a connection between two subsequent transactions. In this mode however, it is mandatory that the server indicates the content length for each response so that the client does not wait indefinitely. For this, a special header is used: “Content-length”. This mode is called the “keep-alive” mode :

プロトコルのトランザクションの性質によって 2 つのトランザクション間で接続を閉じることを避けることで改善することが出来ました。しかし、このモードではクライアントが無制限に待機しないようにサーバーは各応答のコンテンツ長を示すことが必須となります。この為に特別なヘッダ（Content-length）が使用されます。このモードは “keep-alive” モードと呼ばれています。

[CON] [REQ1] ... [RESP1] [REQ2] ... [RESP2] [CLO] ... 

Its advantages are a reduced latency between transactions, and less processing power required on the server side. It is generally better than the close mode, but not always because the clients often limit their concurrent connections to a smaller value.

“keep-alive” モードの利点はトランザクション間の遅延の低減、サーバー側の処理能力が小さくて済むということです。また、一般的には “HTTP close” モードよりも優れていますが、クライアントは多くの同時接続数を小さな値に制限されますので、常に優れているわけではありません。（注意：チョー意訳）

A last improvement in the communications is the pipelining mode. It still uses keep-alive, but the client does not wait for the first response to send the second request. This is useful for fetching large number of images composing a page :

最後の一つがパイプラインモードです。基本的には “keep-alive” 使用していますが、クライアントは次の要求を送信するために最初の応答を待ちません。これはページを構成する多数の画像を取得するのに便利です。（訳注：これが下図の tunnel モードのことかと思われる）

[CON] [REQ1] [REQ2] ... [RESP1] [RESP2] [CLO] ... 

This can obviously have a tremendous benefit on performance because the network latency is eliminated between subsequent requests. Many HTTP agents do not correctly support pipelining since there is no way to associate a response with the corresponding request in HTTP. For this reason, it is mandatory for the server to reply in the exact same order as the requests were received.

ネットワーク遅延がそれに続く要求の間で除去されているので、明らかに性能面で多大な利点を持っています。しかし、HTTP では対応する要求と応答を関連付ける方法がない為、多くの HTTP エージェントが正しくパイプラインをサポートしていません。それは、サーバーが要求を受信したのと全く同じ順序で返信することが必須である理由からです。

By default HAProxy operates in keep-alive mode with regards to persistent connections: for each connection it processes each request and response, and leaves the connection idle on both sides between the end of a response and the start of a new request.

デフォルトでは HAProxy は永続的な接続に関しては、keep-alive モードで動作します。各接続はリクエストとレスポンスを処理し応答の終わりと新しい要求の開始との間の両側に接続アイドルを残します。

HAProxy supports 5 connection modes :
– keep alive : all requests and responses are processed (default)
– tunnel : only the first request and response are processed, everything else is forwarded with no analysis.
– passive close : tunnel with “Connection: close” added in both directions.
– server close : the server-facing connection is closed after the response.
– forced close : the connection is actively closed after end of response.

HA Proxy は 5 つの接続モードをサポートしています。

ってな感じです

ざっくりとまとめると HA Proxy は…

• Keep Alive モードがデフォルトの挙動
• トンネルモードってのもあるけどクライアントがサポートしていない
• Keep Alive が有効になっている場合にはヘッダには Content-length を付けてコンテンツの長さを知る必要がある

元記事はこちらです。