Cookieの代わりにソケットを使用して個人を識別できないのはなぜですか？

IPアドレスを使用して個々のクライアントを識別することに関して別の質問がありました。IPアドレスが不十分な理由は理解できたと思います。しかし、より多くの情報があり、私が理解していることから、ステートフルなソケットはどうですか？クッキーの代わりに使用される可能性はありませんか？

ソケットは接続を識別します。Cookieは通常、ユーザーを識別するために使用されます。2つのブラウザタブをSE.SEに開くと、2つの接続、つまり2つのソケットができます。しかし、両方の設定を維持したいです。（実際、通常、ブラウザーはページのロード時間を短縮するために1ページに複数のソケットを開きます。ほとんどのブラウザーには、ページあたり4〜10ソケットのデフォルトの最大値があると思います。）

また、反対のことが起こります。ブラウザタブを閉じると、マシンの別のユーザーがブラウザタブをSE.SEに開いて、（source_ip、source_port、target_ip、target_port）の同じ4倍を取得する場合があります。 、彼は私のすべての設定を取得します。

TCPソケットはステートフルになるように設計されているため、一般にセッションの識別に使用されます。SSHやftpなどのプロトコルはまさにこれを行います。

HTTPはステートレスになるように設計されており、各接続はダウンロードされるリソースにのみ関連付けられています。リソースがダウンロードされると、HTTP要求が乗るTCPソケットが閉じられます。この最初の理由は単純さでした。しかし、副作用は、最新のWebサイトを実行しているHTTPサーバーが、SSHやftpなどのソケットベースのサーバーよりもはるかに多くのユーザーを処理できることです。

したがって、HTTPはWebページのダウンロード後にソケットを閉じるため、ソケットは使用できません。

もちろん、HTTPにはパイプラインやソケットごとに複数のリソースをダウンロードできる永続的な接続などの機能があるため、HTTPがリソースごとにソケットを閉じると言うのは単純化されます。しかし、それはただの最適化です。すべてがダウンロードされた後、ブラウザはタイムアウト後にソケットを閉じます。

HTTPは元々、HTMLファイルをダウンロードするための単純なプロトコルとして設計されました。古いブラウザは、Gopherやftpなどの他のプロトコルからHTMLファイルをダウンロードすることもできます。HTMLファイルは単なるテキストファイルであるため、HTTPをステートフルにする理由はありませんでした。

Webフォームが導入され、HTMLページがセッションを必要とし始めたサーバーWebページにデータを送り返すことができます。したがって、ステートレスネットワーク層を介して送信されるステートフル転送層を介して送信されるステートレスプロトコルに状態を再導入するために、Cookieが作成されました。したがって、完全なアプリケーション層は次のとおりです。

• イーサネット、Wifiなど=ステートレス
• IP =ステートレス
• TCP =ステートフル
• HTTP =ステートレス
• HTTP + Cookie =ステートフル

最近では、Webページからサーバーへの単一のオープンソケットを保持できるwebsocketがあります。したがって、websocket自体はステートフルであるため、websocketでは再びソケットを使用してユーザーを識別することができます。ただし、ほとんどの場合、websocketを開始するJavaScriptをロードするメインHTMLページ用のCookieが必要になります。