人気のWebサイトが非常に複雑なセッション関連データをCookieに保存するのはなぜですか？それはどういう意味ですか？

Web開発者として、私たちは皆、セッションがHTTPのステートレスな性質に関連する問題を克服するのに役立つことを知っています。一意のセッションID を作成してブラウザーに送信します。ブラウザーが同じIDを送り返すと、ユーザーを簡単に識別できます。

これらはすべて簡単に聞こえますが、どの言語でも実装するのはそれほど複雑ではありません。

いま

私が撮った次のスクリーンショットを見てください。これらは、人気のあるWebサイトが保存するCookieの種類を示しています。複数のセッションIDを保存しているように見えるか、非常に多くのCookieを設定して実際のIDを非表示にしようとしているようです。または、何でも。

Gmail（ログイン前）

Gmail（ログイン後）

フェイスブック

StackExchange

（心配しないでください、あなたは私のセッションを盗むことはできません-それは古くて不完全です:)）

だから、私の質問は-この複雑さはどのような目的に役立つのでしょうか？これらの異なるCookieの意味（一般的に）と、それらが設定されている目的を説明してください。最後に、自分のアプリでそれをどのように行うことができるか（そして、そうすべきかどうか）のヒント。

もう1つの質問：多くの場合、Cookieの値はURLエンコードされているように見えますが、なぜですか？

1. 特定のデータをデータベースのセッションテーブルに保存することが実用的でない場合があります。特定のデータが更新された場合は多くのことを、それはデータベースをたくさん行き詰まらにも可能性があります。その場合で、データがあまり重要でない場合は、別のCookieに保存する方が適切です。

2. （1）が発生した場合、Cookieあたり4kbの制限に対処する必要があるため、Cookie内のすべてのセッションデータを1つのCookieに保存することはお勧めできません。

3. 必要な最小数のCookieですべてを保存できると便利ですが、プロジェクトの複雑さの懸念により、これは困難です。一部のアプリケーションは、複数のチームによって開発されています。1つのWebサーバーとして見えるものは、実際にはWebサーバーのいくつかの異なるクラスターと通信し、サイトの異なるセクションをそれぞれ独自のCookie のセットを持つ異なるクラスターにルーティングするプロキシです。

4. クッキーは安いです。あなたはルールの例外です-誰も彼らが持っているクッキーの数を確認するために彼らのクッキーストアを調べません。また、クライアント側のすべてのセッションデータを可能な限り少ないCookie に結合しようとしても、パフォーマンス上のメリットはほとんどありません。