まず用語を定義しましょう。
コネクション:TCPの接続を指します。一般的にはクライアントからサーバへの接続になりますが、ロードバランサからWebサーバへもコネクションがはられます。
セッション:Webサーバとブラウザの間での接続維持情報。一般的には、サーバ側でセッションオブジェクトにユーザIDなどの情報を保持し、そのIDをCookie に紐づけてクライアント側に覚えさせる。
この言葉の定義に従うと
①クライアントからLBへ接続
→この時点で、コネクションが生まれる?
(セッションとしては何をもつ?)
はい、クライアントからLBへのコネクションが生まれます。セッションはまだありません。
②LBからWebサーバへ接続
①のあと、接続がすぐに行われるわけではありません。クライアントから最初のリクエストが送られてきてから LBからWebサーバへの接続が行われます。
というのは、LBの仕様でリクエストパケットの内容に応じて、複数の Webサーバのうち、どこに接続するのかを決める場合があるからです。
また、LBからWebサーバへのコネクションは他のクライアントが利用していたものが再利用される場合があります。その場合は、新たに接続する必要はありません。
③WebサーバからLBにレスポンスを戻す
このとき、HTTP 1.1 ではコネクションをすぐに切らずに一定時間維持します。そして、そのコネクションが再利用されずに一定時間が経過すると破棄されます。
④LBからクライアントへレスポンスを戻す
→この時点で、コネクションが切断される?
このときも、HTTP 1.1 ではコネクションをすぐに切らずに一定時間維持します。そして、そのコネクションが再利用されずに一定時間が経過すると破棄されます。
クライアントから複数の同時アクセスが発生した場合、
そのアクセス1つ毎に、コネクションと、セッションが生まれると考えて良いのでしょうか。
いえ、クライアントからLBへのコネクションとLBからWebサーバへのコネクションは1対1に対応するものではありません。一般的にはクライアントからLBへのコネクションの数よりもLBからWebサーバへのコネクションのほうが少ないです。
これによって、Webサーバのスレッド数が少なくてもクライアントからの複数の同時アクセスに対応しやすくなります。
たとえば、1万台のクライアントから同時にアクセスがあってもロードバランサのキューに滞留させ、Webサーバは100個くらいのスレッドで処理させることが可能です。この場合、LBからWebサーバへの接続が再利用されるので、コンテキストスイッチが減少し、全体のスループット性能が上がります。
つまり、LBがクライアントからの接続を受け付けて待ち行列を管理してくれるので Webサーバはビジネスロジックに専念できるというわけです。
Webサーバのセッションはアプリケーションにログインするときなどに生成されます。セッション情報をWebサーバ側に保持する場合は、LBが異なるWebサーバにリクエストを振り分けると困るので、スティッキーセッションなどの技術を使用して、一つのクライアントは毎回同じWebサーバにリクエストが送られるようにします。
単なるホームページの配信などステートレスなアプリであれば、セッションはありません。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2020/03/29 08:31