Apache Traffic Server 6.2 - en to ja translation catalogue (34 entries)

en: **Blacklist Plugin**
ja: **ブラックリストプラグイン**

en: **Simplified HTTP Transaction**
ja: **簡略化された HTTP トランザクション**

en: **Traffic Server Internals**
ja: **Traffic Server の内部構造**

en: **Traffic Server with Plugins**
ja: **プラグインと Traffic Server**

en: *Header manipulation plugins*, such as filtering, basic authorization, or redirects, usually have a global hook to the DNS lookup or the read request header states. If specific actions need to be done to the transaction further on, then the plugin adds itself to a transaction hook. *Transformation plugins* require a global hook to check all transactions for transformability followed by a *transform hook*, which is a type of transaction hook used specifically for transforms.
ja: フィルタリング、ベーシック認証、リダイレクトを行うような *ヘッダー操作プラグイン* は通常 DNS ルックアップやリクエストヘッダの読込みの状態へのグローバルフックを持ちます。この先トランザクションに対して特定のアクションが実行される必要がある場合、プラグインは自身をトランザクションフックに追加します。 *トランスフォームプラグイン* は全トランザクションが、変換のために特別に使用されるトランザクションフックのタイプである *トランスフォームフック* により変換可能か確認するために、グローバルフックを必要とします。

en: A :ref:`developer-plugins-roadmap` with an overview of the functionality provided by the Traffic Server API.
ja: Traffic Server API により提供される機能の概要を伴う :ref:`developer-plugins-roadmap`

en: A plugin may consist of just one static continuation that is called whenever certain events happen. Examples of such plugins include ``blacklist-1.c``, ``basic-auth.c``, and ``redirect-1.c``. Alternatively, a plugin might dynamically create other continuations as needed. Transform plugins are built in this manner: a static parent continuation checks all transactions to see if any are transformable; when a transaction is transformable, the static continuation creates a type of continuation called a **vconnection**. The vconnection lives as long as it takes to complete the transform and then destroys itself. This design can be seen in all of the sample transform plugins. Plugins that support new protocols also have this architecture: a static continuation listens for incoming client connections and then creates transaction state machines to handle each protocol transaction.
ja: プラグインは特定のイベントが発生する度に毎回呼び出される、たった一つの静的な継続から成立する可能性があります。このようなプラグインの例として ``blacklist-1.c``、 ``basic-auth.c`` そして ``redirect-1.c`` があります。あるいは、プラグインは必要に応じ他の継続を動的に作成する可能性があります。トランスフォームプラグインはこの方法で作られています。静的な親継続は全トランザクションが変換可能でないか確認するためにチェックを行い、トランザクションが変換可能な際は静的な継続は **vconnection** と呼ばれる継続の型を作成します。 vconnection は変換が完了するまで生存し続け、その後破棄されます。この設計は全てのサンプルのトランスフォームプラグインに見られます。新しいプロトコルのサポートを行うプラグインも、このアーキテクチャを持ちます。静的な継続はやって来るクライアントコネクションを listen し、その後各プロトコルのトランザクションを処理するため、トランザクションステートマシンを作成します。

en: **API Hooks Corresponding to States**
ja: **API フックと状態の関係**

en: How plugins can hook onto and modify/extend Traffic Server's HTTP processing.
ja: プラグインがフックを入れて、 Traffic Server の HTTP 処理を変更 / 拡張する方法

en: API Hooks Corresponding to States Listed in
ja: リストの状態に対応した API フック

en: An HTTP transaction consists of a client request for a web document and Traffic Server's response. The response could be the requested web server content or it could be an error message. The content could come from the Traffic Server cache or Traffic Server might fetch it from the origin server. The following diagram shows some states in a typical transaction - specifically, the scenario wherein content is served from cache.
ja: HTTP トランザクションはウェブドキュメントに対するクライアントリクエストと Traffic Server のレスポンスから成立します。レスポンスは要求されたウェブサーバーのコンテンツになるかも知れないし、エラーメッセージになるかも知れません。コンテンツは Traffic Server のキャッシュから配信されるかも知れませんし Traffic Server がオリジンサーバーから取得するであろうものから配信されるかも知れません。以下の図は典型的なトランザクション、特にコンテンツがキャッシュから配信される際のシナリオにおける幾つかの状態を示したものです。

en: Continuation objects are used throughout Traffic Server. Some might live for the duration of the Traffic Server process, while others are created (perhaps by other continuations) for specific needs and then destroyed. :ref:`TSInternals` (below) shows how the major components of Traffic Server interact. Traffic Server has several **processors**, such as *cache processor* and *net processor*, that consolidate cache or network I/O tasks. Processors talk to the event system and schedule work on threads. An executing thread calls back a continuation by sending it an event. When a continuation receives an event, it wakes up, does some work, and either destroys itself or goes back to sleep & waits for the next event.
ja: 継続オブジェクトは Traffic Server 全体で使用されます。その幾つかは Traffic Server プロセスが実行中ずっと生存する可能性がありますが、他のものは特定の要求に合わせて（おそらくは他の継続によって）生成され、その後破棄されます。 :ref:`TSInternals` （下記）は Traffic Server の主要なコンポーネントがどのように影響し合うのかを示しています。 Traffic Server は、キャッシュやネットワーク I/O タスクを統合する *キャッシュプロセッサー* と *ネットプロセッサー* のような幾つかの **プロセッサー** を持ちます。プロセッサーはイベントシステムと対話し、スレッド上の作業をスケジュールします。実行スレッドは継続にイベントを送信することで継続をコールバックします。継続がイベントを受信した際、起動し、幾つかの処理を行い、自身を破棄するか再び眠り次のイベントを待ちます。

en: The asynchronous event mode. This is the design paradigm used throughout Traffic Server; plugins must also follow this design. It includes the callback mechanism for Traffic Server to "wake up" your plugin and put it to work.
ja: 非同期イベントモード。 Traffic Server 全体で用いられる設計パラダイムです。プラグインもこの設計に従っていなければなりません。これは Traffic Server がプラグインを "起こして" 処理を実行するコールバックメカニズムを含みます。

en: This chapter provides a foundation for designing and writing plugins. Reading this chapter will help you to understand:
ja: この章ではプラグインの設計と書き方の基礎について説明します。この章を読むことは下記の理解の手助けになるでしょう。

en: Blacklist Plugin
ja: ブラックリストプラグイン

en: HTTP Transaction
ja: HTTP トランザクション

en: Instead, Traffic Server provides special event-driven mechanisms for efficiently scheduling work: the event system and continuations. The **event system** is used to schedule work to be done on threads. A **continuation** is a passive, event-driven state machine that can do some work until it reaches a waiting point; it then sleeps until it receives notification that conditions are right for doing more work. For example, HTTP state machines (which handle HTTP transactions) are implemented as continuations.
ja: 代わりに、効率的な処理のスケジューリングのために Traffic Server は特殊なイベント駆動メカニズム、イベントシステムと継続を提供します。 **イベントシステム** はスレッド上で行われる処理のスケジューリングに使用されます。 **継続** は待機点に到達するまで幾つかの処理を実行可能な、受動的なイベント駆動ステートマシンです。これは更なる処理を行うのに適した状態の通知を受け取るまでスリープします。例として、 HTTP ステートマシン（ HTTP トランザクションを処理するもの）は継続として実装されます。

en: In the diagram above, Traffic Server accepts the client connection, reads the request headers, looks up the origin server's IP address, and looks for the requested content in the cache. If the content is not in the cache (a "miss"), then Traffic Server opens a connection to the origin server and issues a request for the content. If the content is in the cache (a "hit"), then Traffic Server checks it for freshness.
ja: 上の図において、 Traffic Server はクライアントコネクションを accept し、リクエストヘッダーを読込み、オリジンサーバの IP アドレスをルックアップし、キャッシュ上でリクエストされたコンテンツを検索します。キャッシュにコンテンツがない場合（ "ミス" ）、 Traffic Server はオリジンサーバへのコネクションを open し、コンテンツのリクエストを発行します。キャッシュにコンテンツがある場合（ "ヒット" ）、 Traffic Server はフレッシュネスをチェックします。

en: Plugins are typically implemented as continuations. All of the sample code plugins (except ``hello-world``) are continuations that are created when Traffic Server starts up; they then wait for events that trigger them into activity.
ja: プラグインは一般的に継続として実装されます。（ ``hello-world`` を除く）プラグインのサンプルコードの全ては Traffic Server 起動時に作成される継続です。それらはその後、活動するきっかけとなるイベントを待ちます。

en: To manage concurrency from having many simultaneous client connections. For example, a server could create one thread for each connection, allowing the operating system (OS) to control switching between threads.
ja: 同時に大量のクライアントコネクションを持つことによる平行性を管理するため。例として、OS にスレッドの切り替えを制御させることでコネクション毎に一つのスレッドを作成できます。

en: Simplified HTTP Transaction
ja: 簡略化された HTTP トランザクション

en: The example in this section (below) explains how a plugin typically intervenes and extends Traffic Server's processing of an HTTP transaction. Complete details about hooking on to Traffic Server processes are provided in :ref:`developer-plugins-hooks-and-transactions`.
ja: この節（の下）の例ではプラグインの典型的な介入と Traffic Server の HTTP トランザクション処理の拡張方法について説明します。 Traffic Server の処理へのフックに関する完全な詳細は :ref:`developer-plugins-hooks-and-transactions` にあります。

en: To take advantage of the concurrency available with multiple CPUs and multiple I/O devices.
ja: 複数 CPU と複数 I/O デバイスが使用可能な平行性の利点を得るため

en: Traffic Server HTTP State Machine
ja: Traffic Server HTTP ステートマシン

en: Traffic Server Internals
ja: Traffic Server 内部構造

en: Traffic Server is a multi-threaded process. There are two main reasons why a server might use multiple threads:
ja: Traffic Server はマルチスレッドで動作するプロセスです。サーバがマルチスレッドを使用する主な理由は二つあります。

en: Traffic Server calls the Blacklist plugin right after the origin server DNS lookup. The plugin checks the requested host against a list of blacklisted servers; if the request is allowed, then the transaction proceeds. If the host is forbidden, then the Blacklist plugin sends the transaction into an error state. When the HTTP state machine gets to the "send reply header" state, it then calls the Blacklist plugin to provide the error message that's sent to the client.
ja: Traffic Server はオリジンサーバの DNS ルックアップの直後にブラックリストプラグインを呼び出します。このプラグインはリクエストされたホストをブラックリストに載ったサーバのリストと照合します。リクエストが許可される場合、トランザクションは進みます。ホストが許可されない場合、ブラックリストプラグインはトランザクションをエラー状態に送ります。 HTTP ステートマシンが "send reply header" 状態を取得した際、ブラックリストプラグインはクライアントへ送信するエラーメッセージを提供する為に呼び出します。

en: Traffic Server performs sophisticated HTTP caching and proxying. Important features include checking for alternates and document freshness, filtering, supporting cache hierarchies, and hosting. Traffic Server handles thousands of client requests at a time and each request is handled by an HTTP state machine. These machines follow a complex state diagram that includes all of the states required to support Traffic Server's features. The Traffic Server API provides hooks to a subset of these states, chosen for their relevance to plugins. You can view the API hooks and corresponding HTTP states in the :ref:`http-txn-state-diagram`.
ja: Traffic Server は高度な HTTP キャッシュとプロキシを行います。重要な特徴としてオルタネイトとドキュメントのフレッシュネスのチェック、フィルタリング、階層的キャッシュのサポート、そしてホスティングを含みます。 Traffic Server は同時に数千のクライアントリクエストを処理し、各リクエストは HTTP ステートマシンにより処理されます。これらのマシンは Traffic Server の機能をサポートするために要求される状態の全てを含む、複雑な状態遷移図に従います。 Traffic Server API は、プラグインとの関連を選択されたこれらの状態のサブセットへのフックを提供します。 :ref:`http-txn-state-diagram` でAPI フックと関係する HTTP 状態が見られます。

en: Traffic Server uses multiple threads for the first reason. However, Traffic Server does not use a separate OS thread per transaction because it would not be efficient when handling thousands of simultaneous connections.
ja: Traffic Server は最初の理由の為に複数スレッドを使用します。しかしながら数千の同時コネクションを処理する際に効率が悪くなるため、 Traffic Server はトランザクション処理毎の OS スレッドの分離を行いません。

en: Traffic Server with Plugins
ja: プラグインと Traffic Server

en: Traffic Server's HTTP processing, with an overview of the HTTP state machine.
ja: HTTP ステートマシンの概要を伴う Traffic Server の HTTP 処理

en: Types of Hooks
ja: フックのタイプ

en: When you write plugins, there are several ways to send events to continuations. For HTTP plugins, there is a "hook" mechanism that enables the Traffic Server HTTP state machine to send your plugin wakeup calls when needed. Additionally, several Traffic Server API functions trigger Traffic Server sub-processes to send events to plugins: ``TSContCall``, ``TSVConnRead``, ``TSCacheWrite``, and ``TSMgmtUpdateRegister``, to name a few.
ja: プラグインを書く際、継続にイベントを送信する方法は幾つか存在します。 HTTP プラグインについては、 HTTP ステートマシンが必要に応じてプラグインを起こす呼び出しを送信することを可能にする "フック" のメカニズムが存在します。加えて、幾つかの Traffic Server API 関数、 ``TSContCall``、 ``TSVConnRead``、 ``TSCacheWrite`` そして ``TSMgmtUpdateRegister`` は Traffic Server サブプロセスがプラグインにイベントを送信するきっかけとなります。

en: You use hooks as triggers to start your plugin. The name of a hook reflects the Traffic Server state that was *just completed*. For example, the "OS DNS lookup" hook wakes up a plugin right *after* the origin server DNS lookup. For a plugin that requires the IP address of the requested origin server, this hook is the right one to use. The Blacklist plugin works in this manner, as shown in the :ref:`BlackListPlugin` diagram below.
ja: プラグインを開始するトリガーとしてフックを使用できます。フックの名前はちょうど完了した Traffic Server 状態を示します。例えば、 "OS DNS lookup" フックはオリジンサーバの DNS ルックアップの直 *後* にプラグインが動作します。 リクエストされたオリジンサーバの IP アドレスを要求するプラグインのため、このフックは使用するのが正しいです。ブラックリストプラグインは下図の :ref:`BlackListPlugin` で示す通り、この方法で動作します。
