Чому не можна використовувати розетки для ідентифікації осіб замість файлів cookie?

Було задано ще одне питання щодо використання IP-адрес для ідентифікації окремих клієнтів. Я думаю, я розумію, чому IP-адреса недостатня. А як щодо сокета, який має більше інформації і, наскільки я розумію, є репутацією? Чи не може це потенційно використовуватись замість файлу cookie?

sockets cookies

— Громада
джерело

Розетка є станом, але http не залишає відкритим з'єднання після завантаження веб-сторінки. Він закривається приблизно через 15 секунд після завантаження всієї веб-сторінки. це вся причина, що для збереження стану вам потрібні файли cookie

— MTilsted

Розетка не є частиною даних. Ви не можете надіслати його. Ваше запитання не має сенсу.

— користувач207421

Це як запитати, чому ви не можете використовувати дієслова замість іменників ...

— user541686

@EJP: Я відповів, припускаючи, що ОП означає (source_ip, source_port, target_ip, target_port) чотириразовий замість об'єкта socket. Але ваше тлумачення теж має сенс.

— Йорг W Міттаг

Ви можете спробувати наслідувати спосіб роботи firebase для керування ідентичністю штату чи користувача без файлів cookie чи сеансу.

— JeffO

Відповіді:

Сокет ідентифікує з'єднання . Файли cookie зазвичай використовуються для ідентифікації користувача . Якщо я відкрию два вкладки браузера для SE.SE, у мене будуть два з'єднання і, отже, два сокети. Але я хочу, щоб мої налаштування зберігалися в обох. (Насправді, як правило, веб-переглядач відкриває кілька розеток для однієї сторінки, щоб пришвидшити час завантаження сторінки; я вважаю, що більшість браузерів мають максимальне значення за замовчуванням між 4 та 10 сокетами на сторінку.)

І може статися навпаки: якщо я закрию вкладку браузера, інший користувач на машині може відкрити вкладку браузера для SE.SE і може отримати той самий чотириразовий (source_ip, source_port, target_ip, target_port), і в цьому випадку , він отримає всі мої налаштування.

— Йорг W Міттаг
джерело

Варто зазначити, що з http2 (та http-pipelining) у вас, ймовірно, не буде відкрито двох розеток для SE. Ваш браузер повторно використовувати той самий сокет. Вам потрібно мати різні веб-переглядачі.

— Метью Степлз

Найпростіша локальна перевірка показує , що Chrome робить тримати один сокет відкриті на вкладку - ймовірно , тому , що вони пісочницю і він не хоче , щоб частка держава між ними - але сокетом кожної вкладки, здається, бути стійкими і запити, ймовірно , конвеєрна в цій вкладці.

— Марно

Варто також зазначити, що ви також не знаєте, що відбувається на задньому кінці. Багато балансирів навантаження припиняють підключення користувачів, а потім відкривають власні сервери на задньому кінці, що означає, що у вас може бути декілька користувачів, які діляться одним сокетом.

— Dan

@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 = великі

У наші дні у нас є веб-розетки, які можуть зберігати один відкритий сокет від вашої веб-сторінки до сервера. Отже, за допомогою веб-сокетів ви можете знову використовувати сокети для ідентифікації користувача, оскільки сам веб-сокет є стаціонарним. Але в більшості випадків вам все одно знадобиться cookie для головної сторінки html, що завантажує javascript, що запускає websocket.

— слебетмен
джерело

"HTTP-сервери, що працюють на сучасних веб-сайтах, можуть обробити набагато більше користувачів, ніж сервери на базі сокет, як SSH або ftp" [потрібна цитата]

— el.pescado

@ el.pescado: Це просто логічно. Оскільки сервери на основі сокетів підтримують пряме з'єднання, тому сервери на основі сокетів обмежені максимальною кількістю дескрипторів файлів, які ви можете відкрити (а на деяких ОС-розетках конкурують з жорстким диском для дескрипторів файлів). Якщо вам не потрібно підтримувати зв’язок живим, то ваш ліміт - це просто пропускна здатність. Зауважте, що обмеження пропускної здатності - це та сама погода, якщо ви постійно підтримуєте з'єднання. Сучасні сервери HTTP можуть обробляти мільйони запитів в секунду. Якщо їм потрібно буде зберегти ці мільйони розеток, поки ви читаєте веб-сторінку, сервер загине

— slebetman

+1 для "Таким чином, файли cookie були створені для повторного введення стану до протоколу без стану, який передається через стабільний рівень передачі, який передається через мережевий рівень без стану". Це прекрасно

— Відновіть Моніку - dirkk

Мені сподобалась ця відповідь. Це вирізає право до основи проблеми.

— Jim W

@slebetman HTTP - сервери є сокет на основі. Усі вони є. За визначенням. І файли cookie не роблять HTTP-серверів гідними. Насправді за визначенням їх немає, саме тому файли cookie кожен раз передаються клієнтом.

— Майлз Рут