MS-IE (Internet Exploler) は HTTP/1.1 仕様に準拠して、HTTPリクエストを
「Keep-Alive」として要求する。
この「Keep-Alive」とは「できるならば、通信を持続させたい」というブラウザからの
要求を示している。
HTTPプロトコルといえども単なるTCP/IP通信であることには変わりがないので
通信の都度に切断／再接続を繰り返すのではなく、できれば通信が持続していたほうが
レスポンスが良くなるのは当然のことである。
さて、この「Keep-Alive」要求に対して例えば Misrocoft社が提供している IIS などでは
当然のことであるが、Keep-Alive を戻して、通信が持続されることをブラウザに通知する。

ところがこの Kepp-Alive応答は静的な HTMLや画像ファイルなどに限られていて
動的な CGI の応答の場合は、「Connection : Close」を戻して通信は持続されない。
「Connection : Close」とは、今から送信するコンテンツの送信後には、通信は遮断される、と
言う通知のことである。
CGI の応答レスポンスは総バイト数がいくつになるか不明な場合が多いので送信長を「Content-Length」として戻すことができないからである。

iSeries/i5 の場合では、実は静的なコンテンツの応答であってもつねに
「Connecttion : Close」が戻されて通信は遮断されてしまう。
従って毎回、再接続が必要となってしまう。
iSeries/i5 でも HTTP/1.1 準拠と明示されているが実はこのとおり HTTP/1.1 には
完全には準拠されていない。

EnterpriseServer Alaska Ver4.0 の場合はどうであろうか？
EnterpriseServer の場合は CGI の場合であっても全体の応答バッファー長は明確に
把握されているのでContent-Length を戻すことができる。
従って CGI の場合でも Alaska は Keep-Alive を忠実に応答して通信は、そのまま
持続されるのである。
EnterpriseServer Ver3.0 では通信は遮断されるものの、あたかも通信が持続されて
いるかのような「仮想対話環境」が実現されていたが、Ver4.0 では物理的に通信は
繋がったままであたかもPCOMM のようなクライアント／サーバー・モデルが HTTPプロトコル上で
実現されているのである。

しかし IEの動作に精通している人であれば IE の Keep-Alive は、1分間しか持続されない
ことに気づいているかも知れない。
IE は省略値では、ユーザーによる操作が何もなければ通信を1分間で切断してしまうのである。

そこで Alaska ではブラウザからの通信が遮断されると、さらなる待ち状態に入り、
再接続されると元のセッションがウェークアップして、さらに次の通信が継続されるような
仕組みとなっている。もうひとつの押さえとして、再接続が30分間ない場合は CGI は終結するようにもなっている。
もちろんこの30分間のタイムアウト値は自由にユーザーの希望によって変更することができる。

使用者にとって気づかれないことであるが、内部的に通信が持続されることによって
応答は素早いものとなり理想的なクライアント／サーバー・モデルを形成している。