쿠키 대신 개인을 식별하기 위해 소켓을 사용할 수없는 이유는 무엇입니까?

개별 클라이언트를 식별하기 위해 IP 주소 사용에 관한 또 다른 질문 이있었습니다. IP 주소가 왜 부족한지 이해합니다. 그러나 더 많은 정보를 가지고 있고 내가 이해하는 것에서 소켓은 어떻습니까? 쿠키 대신에 잠재적으로 사용될 수 없습니까?

sockets cookies

— 커뮤니티
소스

소켓은 상태가 가득 차 있지만 http는 웹 페이지를 다운로드 한 후 연결을 열어 두지 않습니다. 전체 웹 페이지가 다운로드 된 후 약 15 초 후에 닫힙니다. 이것은 상태를 유지하기 위해 쿠키가 필요한 전체 이유입니다

— MTilsted

소켓은 데이터가 아닙니다. 보낼 수 없습니다. 귀하의 질문은 이해가되지 않습니다.

— user207421

명사 대신 동사를 사용할 수없는 이유를 묻는 것과 같습니다.

— user541686

@ EJP : OP는 소켓 객체 대신 (source_ip, source_port, target_ip, target_port) 4 배를 의미한다고 가정했습니다. 그러나 당신의 해석도 의미가 있습니다.

— Jörg W Mittag

쿠키 나 세션없이 Firebase가 상태 또는 사용자 ID를 관리하는 방식을 시도하고 모방 할 수 있습니다.

— JeffO

답변:

소켓은 연결을 식별 합니다 . 쿠키는 일반적으로 사용자 를 식별하는 데 사용됩니다 . SE.SE에 대해 두 개의 브라우저 탭을 열면 두 개의 연결과 두 개의 소켓이 있습니다. 그러나 내 설정이 두 설정 모두에서 유지되기를 원합니다. (실제로 브라우저는 페이지 로딩 시간을 단축하기 위해 한 페이지에 여러 개의 소켓을 엽니 다 . 대부분의 브라우저는 페이지 당 4-10 소켓 사이의 기본 최대 값을 가지고 있다고 생각합니다.)

브라우저 탭을 닫으면 시스템의 다른 사용자가 SE.SE에 대한 브라우저 탭을 열 수 있고 동일한 4 배 (source_ip, source_port, target_ip, target_port)를 얻을 수 있습니다. , 그는 내 모든 설정을 갖습니다.

— 요 르그 W 미타 그
소스

http2 (및 http 파이프 라이닝)를 사용하면 SE에 두 개의 소켓이 열려 있지 않을 것입니다. 브라우저는 동일한 소켓을 재사용합니다. 다른 브라우저를 실행해야합니다.

— Matthew Steeples

사소한 로컬 확인은 Chrome 이 탭마다 하나의 소켓을 열어 두는 것으로 나타냅니다. 아마 샌드 박스가 있고 소켓간에 상태를 공유하고 싶지 않기 때문에 각 탭의 소켓은 영구적 인 것으로 보이며 해당 탭 내에서 요청이 파이프 라인 될 수 있습니다.

— 쓸모없는

백엔드에서도 무슨 일이 일어나고 있는지 모른다는 점도 주목할 가치가 있습니다. 많은로드 밸런서는 사용자 연결을 종료 한 다음 백엔드 서버에 대한 자체 개방을 의미하므로 여러 사용자가 단일 소켓을 공유 할 수 있습니다.

— Dan

@Useless IIRC SE는 WebSockets 또는 long-polling (fallback)을 사용하여 여기서 테스트 할 경우 업데이트 (새 질문, 편집 등)를 가져옵니다. 다른 사이트는 다르게 동작 할 수 있습니다. 정적 사이트에서 소켓을 무한정 열린 상태로 유지하는 것은 그리 중요하지 않습니다.

— Bob

사실, 확인해야 할 정적 인 사이트를 찾으려면 몇 번의 시도가 필요했습니다. 이를 위해, 크롬 탭에 여러 개의 소켓을 열고, 여전히 탭 사이를 다시 사용하지 않지만 않습니다 탭이 완성 로딩이되면 가까운 그들. TIME_WAIT에 너무 오래 걸리기 때문에 쉽게 볼 수 있습니다.

— 쓸모없는

TCP 소켓은 상태 저장이 가능하도록 설계되어있어 일반적으로 세션을 식별하는 데 사용됩니다. SSH 및 ftp와 같은 프로토콜이이를 정확하게 수행합니다.

HTTP는 상태 비 저장을 위해 설계되었으며 각 연결은 다운로드 할 리소스에만 연결됩니다. 리소스가 다운로드되면 HTTP 요청이 진행되는 TCP 소켓이 닫힙니다. 그 이유는 단순성이었습니다. 그러나 부작용은 최신 웹 사이트를 실행하는 HTTP 서버가 SSH 또는 ftp와 같은 소켓 기반 서버보다 훨씬 많은 사용자를 처리 할 수 있다는 것입니다.

따라서 웹 페이지를 다운로드 한 후 HTTP가 소켓을 닫으므로 소켓을 사용할 수 없습니다.

물론 HTTP는 소켓 당 여러 리소스를 다운로드 할 수있는 파이프 라이닝 및 영구 연결과 같은 기능을 가지고 있기 때문에 HTTP가 리소스 당 소켓을 닫는다는 것은 지나치게 단순화하고 있습니다. 그러나 그것은 단지 최적화입니다. 모든 것이 다운로드되면 브라우저는 시간 초과 후 소켓을 닫습니다.

HTTP는 원래 HTML 파일을 다운로드하기위한 간단한 프로토콜로 설계되었습니다. 오래된 브라우저는 Gopher 및 ftp와 같은 다른 프로토콜에서 HTML 파일을 다운로드 할 수도 있습니다. 따라서 HTML 파일은 단순한 텍스트 파일이므로 HTTP를 상태 저장으로 만들 이유가 없습니다.

일단 웹 양식이 도입되고 HTML 페이지가 세션을 필요로하기 시작한 서버 웹 페이지로 데이터를 다시 보낼 수 있습니다. 따라서 쿠키는 상태 비 저장 네트워크 계층을 통해 전송되는 상태 저장 전송 계층을 통해 전송되는 상태 비 저장 프로토콜에 상태를 다시 도입하기 위해 만들어졌습니다. 따라서 전체 애플리케이션 계층은 다음과 같습니다.

이더넷, Wifi 등 = 상태 비 저장
IP = 상태 비 저장
TCP = 상태 저장
HTTP = 상태 비 저장
HTTP + 쿠키 = 상태 저장

요즘에는 웹 페이지에서 서버로 하나의 열린 소켓을 유지할 수있는 웹 소켓이 있습니다. 따라서 웹 소켓 자체는 상태 저장 기능이므로 웹 소켓을 사용하면 소켓을 다시 사용하여 사용자를 식별 할 수 있습니다. 그러나 대부분의 경우 여전히 웹 소켓을 시작하는 자바 스크립트를로드하는 기본 HTML 페이지에 대한 쿠키가 필요합니다.

— 썰매
소스

"현대 웹 사이트를 실행하는 HTTP 서버는 SSH 또는 ftp와 같은 소켓 기반 서버보다 훨씬 더 많은 사용자를 처리 할 수 있습니다"[인용 필요]

— el.pescado

@ el.pescado : 논리적입니다. 소켓 기반 서버는 실시간 연결을 유지하므로 소켓 기반 서버는 열 수있는 최대 파일 디스크립터 수로 제한됩니다 (일부 OS에서는 소켓이 파일 디스크립터 용 하드 디스크와 경쟁). 연결을 유지할 필요가 없다면 제한은 대역폭입니다. 대역폭 제한은 연결 상태를 유지하는 날씨와 같습니다. 최신 HTTP 서버는 초당 수백만 건의 요청을 처리 할 수 있습니다. 웹 페이지를 읽는 동안 수백만 개의 소켓을 유지해야한다면 서버는 죽을 것입니다

— slebetman

"이 쿠키는 상태 비 저장 네트워크 계층을 통해 전송되는 상태 저장 전송 계층을 통해 전송되는 상태 비 저장 프로토콜로 상태를 다시 도입하기 위해 만들어졌습니다." 그것은 아름답다

— Reinstate Monica-dirkk

나는이 답변을 좋아했다. 문제의 핵심으로 바로 넘어갑니다.

— Jim W

@slebetman HTTP 서버 는 소켓 기반입니다. 그들 모두입니다. 정의에 의해. 쿠키는 HTTP 서버를 상태 저장으로 만들지 않습니다 . 실제로 쿠키의 정의는 그렇지 않기 때문에 쿠키는 매번 클라이언트에 의해 전송됩니다.

— Miles Rout