Cookieの代わりにソケットを使用して個人を識別できないのはなぜですか？
別の 質問 は、個々のクライアントを識別するためのIPアドレスの使用に関して尋ねられました。なぜIPアドレスが足りないのか理解できたと思います。しかし、より多くの情報があり、私が理解しているところからステートフルなソケットについてはどうでしょうか？ Cookieの代わりに使用することはできませんか？
ソケットは接続を識別します。通常、Cookieはユーザーを識別するために使用されます。 SE.SEへの2つのブラウザタブを開くと、2つの接続、つまり2つのソケットができます。しかし、私は自分の設定を両方で維持したいと考えています。 （実際、通常、ブラウザはページの読み込み時間を短縮するためにmultipleソケットをoneページ用に開きます。ほとんどのブラウザのデフォルトの最大値は4〜10であると思います。ページあたりのソケット。）
また、反対のことが起こる可能性もあります。ブラウザタブを閉じると、マシン上の別のユーザーがブラウザタブをSE.SEに開いて、（source_ip、source_port、target_ip、target_port）と同じ4倍になる場合があります。 、彼は私のすべての設定を取得します。
TCPソケットはステートフルになるように設計されているため、一般的にはセッションの識別に使用されます。 SSHやftpのようなプロトコルはまさにこれを行います。
HTTPはステートレスになるように設計されており、各接続はダウンロードされるリソースにのみ関連付けられています。リソースがダウンロードされた後、TCP HTTPリクエストが乗っているソケットは閉じられます。これの最初の理由は単純でした。しかし、副作用は、最新の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が必要です。