CICS Web サポートによる持続接続の処理方法

HTTP サーバーとしての Web クライアントと CICS® の間、または HTTP クライアントとサーバーとしての CICS の間で接続が確立されると、デフォルトでは、 CICS は接続を持続接続として開いたままにしようとします。

CICS が HTTP サーバーの場合、持続接続は以下の状況で閉じられます。

  • Web クライアントからの要求を処理するユーザー作成アプリケーションが、クライアントに対して接続を閉じることを要求する (WEB SEND コマンドの CLOSESTATUS(CLOSE) オプションを指定)。
  • Web クライアントは、接続を閉じるよう CICS に要求します (Connection: close ヘッダーによって通知されます)。
  • Web クライアントが、Connection: Keep-Alive ヘッダーを送信しない HTTP/1.0 クライアントである。
  • タイムアウト期間に達した (これは、接続が失敗したこと、または Web クライアントが接続を意図的に終了したことを示しています)。
  • CICS 領域は、持続接続の最大数に指定された制限に達し、各応答の受信後に接続を閉じるように Web クライアントに要求しています。 接続スロットリングについて詳しくは、「 CICS as an HTTP server: Connection throttling for inbound HTTP connections 」を参照してください。
  • 領域内のタスク数が持続接続の制限を超えている。
  • 定期的に、共用 IP エンドポイントで listen している領域間で作業をより効率的に共用できるようにするため。
  • TCPIPSERVICE はクローズされます。

それ以外の場合、 CICS は、Web クライアントがさらに要求を送信できるように、持続接続を開いたままにします。 クライアントとの持続接続がある場合、 CICS は、Web エラー・プログラムを介してエラー応答が送信された後も接続を開いたままにします。 例外は、 CICS が応答に対して 501 (Method Not Implemented) 状況コードを選択する場合です。この場合、接続は CICSによってクローズされます。 CICS は、領域内のタスクの数が持続接続の制限を超えた場合に、新規接続に非持続のマークを付けます。

一部の TCP/IP 統計は、HTTP 接続がどの程度持続的であるかを示します。 詳しくは、 接続パーシスタンス統計を参照してください。

CICS Web サポートの TCPIPSERVICE リソース定義では、TCPIPSERVICE 定義の SOCKETCLOSE 属性および MAXPERSIST 属性をゼロとして指定してはなりません。 SOCKETCLOSE にゼロを設定すると、HTTP サーバーとしての CICS は、Web クライアントからデータを受信した直後に接続をクローズします。ただし、それ以上のデータが待機している場合は除きます。 MAXPERSIST にゼロを設定すると、 CICS は、すべての Web クライアントが CICSからの各応答を受信した後に接続を閉じる必要があることを意味します。 これらの状態のいずれにおいても、持続接続を維持することはできません。 現在外部要求を処理していない CICS 領域 (テスト環境など) でこれらの属性に特別な要件がある場合にのみ、これらの属性にゼロ設定を使用してください。

CICS が HTTP クライアントの場合、持続接続は以下の状況で閉じられます。
  • サーバーは、接続を閉じるように CICS に要求します (Connection: close ヘッダーを送信する HTTP/1.1 サーバー、または Connection: Keep-Alive ヘッダーの送信に失敗する HTTP/1.0 サーバーによって通知されます)。
  • ユーザー・アプリケーション・プログラムは、サーバーに接続をクローズするように要求します ( WEB SEND または WEB CONVERSE コマンドで CLOSESTATUS (CLOSE) オプションを指定します)。

ユーザー・アプリケーション・プログラムが、サーバーが接続の終了を要求したかどうかをテストする必要がある場合は、 READ HTTPHEADER コマンドを使用して、サーバーからの最後のメッセージの Connection: close ヘッダーを探すことができます。 サーバーが接続のクローズを要求しても、アプリケーション・プログラムがまだ WEB CLOSE コマンドを発行していない場合、 CICS は接続をクローズしますが、接続に関連するデータ (サーバーから受信した最後の応答とその HTTP ヘッダーを含む) を維持します。 アプリケーション・プログラムは、WEB CLOSE コマンドを発行するか、またはタスクの最後に達するまで、そのデータを使用し続けることができます。

ユーザー・アプリケーション・プログラムが WEB CLOSE コマンドを発行して接続の使用を終了したときに、接続がまだ開いている場合、 CICS は必ずしもその接続を閉じるとは限りません。 接続に接続プーリングが指定されていない場合、または接続が接続プーリングに適した状態ではない場合、 CICS は接続を閉じます。 ただし、接続をオープンするために使用された URIMAP リソースに接続プールが指定されていて、接続が良好な状態にある場合、 CICS は接続をクローズしません。 代わりに、 CICS は接続を休止接続のプールに入れ、別のアプリケーション・プログラムまたは同じアプリケーション・プログラムの別のインスタンスが同じサーバーに接続するために再利用することができます。 接続プールについて詳しくは、「 CICS as an HTTP client: Connection pooling for outbound HTTP connections 」を参照してください。

HTTP クライアントとしての CICS が HTTP/1.0 サーバーと通信している場合、 CICS は、HTTP メッセージで Connection: Keep-Alive ヘッダーを自動的に送信します。 接続を要求したアプリケーション・プログラムがこれらのヘッダーを送信する必要はありません。 Keep-Alive は、持続接続が必要であることをサーバーに通知します。

HTTP サーバーとしての CICS : インバウンド HTTP 接続の接続スロットル

複数の Web クライアントが CICS への長期間持続接続を HTTP サーバーとしてセットアップし、それらの接続を頻繁に使用する場合、接続を処理する CICS 領域が過負荷になり、パフォーマンス上の問題が発生する可能性があります。 この問題が発生した場合は、接続スロットリングをセットアップして、ポートを共用して同じサービスを提供する他の CICS 領域に過剰な Web クライアントを接続させることができます。

接続スロットリングを使用すると、 CICS 領域が特定のポートに対して受け入れる持続 HTTP 接続の数に制限を設定できます。 この制限に達し、さらに Web クライアントが要求を送信する場合、 CICS は、各応答とともに Connection: close ヘッダーを送信して、新しいクライアントが接続を閉じることを要求します。 CICS 領域への持続接続を既に持っている Web クライアントは、持続接続を維持することができます。 新規クライアントは、再接続時に、ポートを共用する別の CICS 領域に接続し、その制限に達していない場合、そこで持続接続を維持することができます。 制限に達した CICS 領域は、その領域への持続接続を持つ Web クライアントが接続を閉じると、新しい持続接続の受け入れを再開します。

接続スロットリングは、ポートの TCPIPSERVICE リソース定義の MAXPERSIST 属性で管理されます。 デフォルト設定の MAXPERSIST (NO) は、 CICS 領域が受け入れる持続接続の数に制限がないことを意味します。 接続スロットリングをセットアップするには、 CICS 領域が同時に処理できる持続接続の数に基づいて、MAXPERSIST 属性に適切な値を指定します。 この設定は HTTP および HTTPS プロトコルにのみ適用され、他のプロトコルには適用されません。

HTTP/1.1 サーバーは通常、持続接続を許可する必要があるため、長期間持続接続が原因でパフォーマンス上の問題が発生した CICS 領域でのみ接続スロットルをセットアップしてください。 MAXPERSIST のゼロ設定は、 CICS 領域が持続接続を許可しないことを意味し、 HTTP/1.1 仕様に準拠していません。 ゼロの設定を使用するのは、現在外部要求を処理していない CICS 領域 (テスト環境など) でその設定に特別な要件がある場合のみにしてください。 MAXPERSIST にゼロより大きい値を指定すると、HTTP サーバーとしての CICS は引き続き HTTP/1.1 仕様に準拠します。デフォルトの動作は持続接続を許可することであり、Web クライアントは持続接続を取得できない場合は Connection: close ヘッダーを受け取ります。 ただし、持続接続を拒否することは、HTTP/1.1 サーバーの通常のプラクティスとしては推奨されないことを知っておく必要があります。 また、Web クライアントが目的の持続接続の取得に失敗すると、Web クライアント自身のパフォーマンスが影響を受けることがあります。

HTTP クライアントとしての CICS : アウトバウンド HTTP 接続の接続プール

デフォルトでは、 CICS は、 CICS アプリケーションが接続の使用を終了した後、またはサービス・リクエスター・アプリケーションが Web サービス要求を行って応答を受信した後、あるいは HTTP EP アダプターがビジネス・イベントを発行した後に、クライアント HTTP 接続を閉じます。 接続プールをセットアップすると、接続をクローズする代わりに、 CICS は接続を休止状態のプールに入れることができます。 休止接続は、同じアプリケーションが再使用することも、同じホストとポートに接続する別のアプリケーションが再使用することも可能です。 接続プールは、 CICS Web サポート・アプリケーション、Web サービス・アプリケーション、または HTTP EP アダプターの複数の呼び出しが特定のホストおよびポートに接続要求を行う場合、または Web サービス・アプリケーションが複数の要求および応答を行う場合に、パフォーマンス上の利点をもたらします。

接続プーリングをセットアップするには、クライアント HTTP 接続の URIMAP リソース定義の SOCKETCLOSE 属性を指定します。 クライアント HTTP 接続をプールするには、 CICS アプリケーション・プログラムは INVOKE SERVICE または WEB OPEN コマンドで URIMAP リソースを指定する必要があり、 CICS Web サポート・アプリケーションは WEB CLOSE コマンドを発行して接続の使用を明示的に終了する必要があります。 サーバーが CICS に接続のクローズを要求した場合、またはアプリケーション・プログラムが WEB SEND または WEB CONVERSE コマンドで CLOSESTATUS (CLOSE) オプションを指定してサーバーに接続のクローズを要求した場合、接続をプールすることはできません。 また、 CICS は、オープン接続をプールに入れる前に、その接続の状態を検査します。例えば、最後の HTTP 応答が正常でなかった場合など、接続が検出されたり、不良状態であると疑われたりした場合には、接続はプールされません。

アプリケーションが URIMAP リソースを使用してクライアント HTTP 接続を行う場合、 CICS は、そのホストおよびポートのプール内で休止接続が使用可能かどうかを検査し、使用可能な場合は、新規接続を開くのではなく、その休止接続をアプリケーションに提供します。 アプリケーションは新しい接続を使用するのとまったく同じようにプール接続を再使用するので、接続は使用後に再びプールすることができます。 接続が再利用されずに SOCKETCLOSE 属性で指定した時間制限に達すると、 CICS はその接続を破棄します。 CICS は、 CICS 領域の MAXSOCKETS に達した場合、接続の URIMAP リソースを破棄した場合、またはサーバーが CICS に接続のクローズを要求した場合にも、プール内の休止接続をクローズします。