Почему нельзя использовать сокеты для идентификации людей вместо файлов cookie?

Другой вопрос был задан относительно использования IP-адресов для идентификации отдельных клиентов. Я думаю, что понимаю, почему IP-адрес недостаточно. Но как насчет сокета, который имеет больше информации и, насколько я понимаю, с состоянием? Не может ли это быть потенциально использовано вместо cookie?

sockets cookies

— Сообщество
источник

Сокет заполнен, но http не сохраняет соединение открытым после загрузки веб-страницы. Он закрывается примерно через 15 секунд после загрузки всей веб-страницы. это вся причина, по которой вам нужны куки, чтобы сохранить состояние

— MTilsted

Сокет не часть данных. Вы не можете отправить это о. Ваш вопрос не имеет смысла.

— user207421

Это все равно, что спросить, почему нельзя использовать глаголы вместо существительных ...

— user541686

@EJP: я ответил в предположении, что OP означает четверку (source_ip, source_port, target_ip, target_port) вместо объекта сокета. Но ваша интерпретация тоже имеет смысл.

— Йорг Миттаг

Вы можете попробовать имитировать работу firebase для управления состоянием или идентификацией пользователя без файлов cookie или сеанса.

— JeffO

Ответы:

Сокет идентифицирует соединение . Файлы cookie обычно используются для идентификации пользователя . Если я открою две вкладки браузера для SE.SE, у меня будет два соединения и, следовательно, два сокета. Но я хочу, чтобы мои настройки сохранялись в обоих случаях. (На самом деле, как правило, браузер открывает несколько сокетов для одной страницы, чтобы ускорить время загрузки страницы; я полагаю, что большинство браузеров имеют максимальное значение по умолчанию от 4 до 10 сокетов на страницу.)

И может произойти обратное: если я закрою вкладку своего браузера, другой пользователь на машине может открыть вкладку браузера для SE.SE и может получить такую же четверку (source_ip, source_port, target_ip, target_port), в этом случае Он получит все мои настройки.

— Йорг Миттаг
источник

Стоит отметить, что с http2 (и http pipelining) у вас, вероятно, не будет двух открытых сокетов для SE. Ваш браузер будет повторно использовать тот же сокет. Вам нужно будет запустить разные браузеры.

— Мэтью Стиплз

Простейшая локальная проверка показывает , что Chrome делает держать один сокет открыты на вкладку - вероятно , потому , что они песочницу и он не хочет , чтобы доля государство между ними - но сокетом каждой вкладки, кажется, быть стойкими и запросы, вероятно , конвейерная в этой вкладке.

— бесполезно

Также стоит отметить, что вы тоже не знаете, что происходит на заднем плане. Многие балансировщики нагрузки прерывают соединение пользователей и затем открывают свои собственные для внутренних серверов, что означает, что у вас может быть несколько пользователей, совместно использующих один сокет.

— Дан

@Useless IIRC SE использует либо WebSockets, либо длинный опрос (запасной вариант) для получения обновлений (новых вопросов, изменений и т. Д.), Если вы проводите здесь тестирование. Другие сайты могут вести себя по-другому - бессмысленно держать сокет открытым на неопределенный срок на статическом сайте.

— Боб

Правда, мне потребовалось несколько попыток найти действительно статичный сайт для проверки. Для этого, Chrome открывает несколько сокетов на одну вкладку, и до сих пор не использовать их между вкладками, но делает их закрыть , как только вкладка по окончании загрузки. Их легко увидеть, потому что они так долго проводят в TIME_WAIT.

— бесполезно

TCP-сокеты спроектированы с учетом состояния, поэтому в целом они используются для идентификации сеансов. Протоколы вроде SSH и ftp делают именно это.

HTTP разработан так, что он не имеет состояния, и каждое соединение связано только с ресурсом, который нужно загрузить. После загрузки ресурса сокет TCP, на котором работает HTTP-запрос, закрывается. Первоначальной причиной этого была простота. Но побочным эффектом является то, что HTTP-серверы, на которых работают современные веб-сайты, могут обрабатывать гораздо больше пользователей, чем серверы на основе сокетов, такие как SSH или ftp.

Поэтому сокеты не могут быть использованы, потому что HTTP закроет сокет после загрузки веб-страницы.

Конечно, говорить, что HTTP закроет сокет для каждого ресурса, слишком упрощенно, потому что в HTTP есть такие функции, как конвейерная передача и постоянные соединения, которые могут загружать несколько ресурсов на сокет. Но это только оптимизация. После того, как все загрузится, ваш браузер закроет сокет через некоторое время.

Первоначально HTTP был разработан как простой протокол для загрузки файлов HTML. Старые браузеры также могут загружать HTML-файлы из других протоколов, таких как Gopher и ftp. Таким образом, не было никаких причин делать HTTP сохраняющим состояние, потому что HTML-файлы - это просто текстовые файлы.

Как только веб-формы были введены и HTML-страницы могут отправлять данные обратно на сервер, веб-страницы начали нуждаться в сеансах. Таким образом, файлы cookie были созданы для повторного введения состояния в протокол без сохранения состояния, который передается через уровень передачи с отслеживанием состояния, который передается через сетевой уровень без сохранения состояния. Итак, полные прикладные уровни:

Ethernet, Wifi и т. Д. = Без сохранения состояния
IP = без гражданства
TCP = с состоянием
HTTP = без состояния
HTTP + куки = с состоянием

В наши дни у нас есть веб-сокеты, которые могут хранить один открытый сокет от вашей веб-страницы до сервера. Таким образом, с веб-сокетами вы снова можете использовать сокеты для идентификации пользователя, потому что веб-сокет сам по себе является состоянием. Но в большинстве случаев вам все равно понадобится файл cookie для главной html-страницы, которая загружает JavaScript, запускающий веб-сокет.

— slebetman
источник

«HTTP - серверы , работающие современные веб - сайты могут обрабатывать гораздо больше пользователей , чем серверы на базе сокетов , как SSH или FTP» [править]

— el.pescado

@ el.pescado: это просто логично. Так как серверы на основе сокетов поддерживают активное соединение, следовательно, серверы на основе сокетов ограничены максимальным количеством файловых дескрипторов, которые вы можете открыть (а в некоторых ОС сокеты конкурируют с жестким диском за дескрипторы файлов). Если вам не нужно поддерживать соединение, тогда ваш лимит - просто пропускная способность. Обратите внимание, что ограничение полосы пропускания - это та же погода, в которой вы поддерживаете соединение или нет. Современные HTTP-серверы могут обрабатывать миллионы запросов в секунду. Если им нужно держать эти миллионы сокетов, пока вы читаете веб-страницу, сервер умрет

— slebetman

+1 за «Таким образом, файлы cookie были созданы для повторного введения состояния в протокол без сохранения состояния, который передается через уровень передачи с отслеживанием состояния, который передается через сетевой уровень без сохранения состояния». Это прекрасно

— Восстановите Монику - Диркк

Мне понравился этот ответ. Это затрагивает суть проблемы.

— Джим В.

HTTP-серверы @slebetman основаны на сокетах. Все они есть. По определению. И куки не делают HTTP-серверы с состоянием. На самом деле по определению это не так, поэтому cookie-файлы передаются клиентом каждый раз.

— Майлз Рут