HTTP
HTTP (англ. HyperText Transfer Protocol - «протокол передачі гіпертексту») - протокол прикладного рівня передачі даних, спочатку - у вигляді гіпертекстових документів (тобто документів, які можуть містити посилання, що дозволяють організувати перехід до інших документів) у форматі HTML час використовується передачі довільних даних.
Основою HTTP є технологія "клієнт-сервер", тобто передбачається існування:
Споживачів (клієнтів), які ініціюють з'єднання та надсилають запит;
Постачальників (серверів), які чекають на з'єднання для отримання запиту, роблять необхідні дії і повертають назад повідомлення з результатом.
HTTP використовується також як "транспорт" для інших протоколів прикладного рівня, таких як SOAP, XML-RPC, WebDAV.
Основним об'єктом маніпуляції в HTTP є ресурс, який вказує URI (Uniform Resource Identifier) у запиті клієнта. Зазвичай такими ресурсами є файли, що зберігаються на сервері, але ними можуть бути логічні об'єкти або щось абстрактне. Особливістю протоколу HTTP є можливість вказати в запиті та відповіді спосіб подання одного і того ж ресурсу за різними параметрами: форматом, кодуванням, мовою і т. д. (зокрема, для цього використовується заголовок HTTP). Саме завдяки можливості вказівки способу кодування повідомлення клієнт та сервер можуть обмінюватися двійковими даними, хоча цей протокол є текстовим.
HTTP – протокол прикладного рівня; аналогічними йому є FTP та SMTP. Обмін повідомленнями йде за звичайною схемою "запит-відповідь". Для ідентифікації ресурсів HTTP використовує глобальні URI. На відміну від багатьох інших протоколів, HTTP не зберігає свого стану (stateless). Це означає відсутність збереження проміжного стану між парами «запит-відповідь». Компоненти, що використовують HTTP, можуть самостійно здійснювати збереження інформації про стан, пов'язаний з останніми запитами та відповідями (наприклад, "куки" на стороні клієнта, "сесії" на стороні сервера). Браузер, який надсилає запити, може відстежувати затримки відповідей. Сервер може зберігати IP-адреси та заголовки запитів останніх клієнтів. Однак сам протокол не обізнаний з попередніми запитами та відповідями, в ньому не передбачена внутрішня підтримка стану,
Більшість протоколів передбачає встановлення TCP-сесії, під час якої один раз відбувається авторизація, та подальші дії виконуються у контексті цієї авторизації. HTTP ж встановлює окрему сесію TCP на кожен запит; у пізніших версіях HTTP було дозволено робити кілька запитів у ході однієї TCP-сесії, але браузери зазвичай вимагають лише сторінку та включені до неї об'єкти (картинки, каскадні стилі тощо), а потім відразу розривають TCP-сесію. Для підтримки авторизованого (неанонімного) доступу до HTTP використовуються cookies; причому такий спосіб авторизації дозволяє зберегти сесію навіть після перезавантаження клієнта та сервера.
При доступі до даних по FTP або за файловими протоколами тип файлу (точніше, тип даних, що містяться в ньому) визначається по розширенню імені файлу, що не завжди зручно. HTTP перед тим, як передати самі дані, передає заголовок «Content-Type: тип/підтип», що дозволяє клієнту однозначно визначити, як обробляти надіслані дані. Це особливо важливо при роботі з CGI-скриптами, коли розширення імені файлу вказує не на тип даних, що надсилаються клієнту, а на необхідність запуску даного файлу на сервері і відправки клієнту результатів роботи програми, записаної в цьому файлі (при цьому один і той же файл в залежно від аргументів запиту і власних міркувань може породжувати відповіді різних типів - у найпростішому випадку картинки у різних форматах).
Крім того, HTTP дозволяє клієнту надіслати на сервер параметри, які будуть передані запуску CGI-скрипту. Для цього в HTML були введені форми.
Структура HTTP-повідомлення
Кожне HTTP-повідомлення складається з трьох частин, які передаються у вказаному порядку:
Стартовий рядок (англ. Starting line) - визначає тип повідомлення, відрізняється для запиту та відповіді;
Заголовки (англ. Headers) - характеризують тіло повідомлення, параметри передачі та інші відомості;
Тіло повідомлення (Message Body) - безпосередньо дані повідомлення. Обов'язково має відокремлюватися від заголовків порожнім рядком.
Для версії протоколу 1.1 повідомлення запиту обов'язково має містити заголовок Host.
1. Стартовий рядок :
Стартовий рядок запиту має такий вигляд: Метод URI HTTP/Версія , де:
Метод (англ. Method) - тип запиту, одне слово великими літерами;
URI визначає шлях до запитуваного документа;
Версія (англ. Version) – пара розділених точкою цифр. Наприклад: 1.1.
Щоб запросити сторінку цієї статті, клієнт повинен передати рядок (заданий лише один заголовок):
GET /wiki/HTTP HTTP/1.1
Host: ru.wikipedia.org
Стартовий рядок відповіді сервера має такий формат: HTTP/Версія КодСтану Пояснення , де:
Версія - пара розділених точкою цифр, як у запиті;
Код стану (англ. Status Code) – три цифри. За кодом стану визначається подальший вміст повідомлення та поведінка клієнта;
Пояснення (англ. Reason Phrase) - коротке текстове пояснення до коду відповіді для користувача. Ніяк не впливає повідомлення і є необов'язковим.
Наприклад, стартовий рядок відповіді сервера на попередній запит може мати такий вигляд:
HTTP/1.0 200 OK
2. Заголовки: Заголовки HTTP (англ. HTTP Headers) - це рядки в HTTP-повідомленні, що містять розділену двокрапкою пару параметр-значення. Формат заголовків відповідає загальному формату заголовків текстових повідомлень ARPA (див. RFC 822). Заголовки повинні відокремлюватися від тіла повідомлення хоча б одним порожнім рядком. Приклади заголовків:
Server: Apache/2.2.11 (Win32) PHP/5.3.0
Last-Modified: Sat, 16 Jan 2010 21:16:42 GMT
Content-Type: text/plain; charset=windows-1251
Content-Language: ru
У прикладі вище кожен рядок є одним заголовком. При цьому те, що знаходиться до двокрапки, називається ім'ям (англ. name), а після нього - значенням (англ. value).
Усі заголовки поділяються на чотири основні групи:
General Headers («Основні заголовки») - можуть включатись у будь-яке повідомлення клієнта та сервера;
Request Headers («Заголовки запиту») – використовуються лише у запитах клієнта;
Response Headers («Заголовки відповіді») - лише відповідей від сервера;
Entity Headers («Заголовки сутності») – супроводжують кожну сутність повідомлення.
Саме в такому порядку рекомендується надсилати заголовки одержувачу.
Як сервер дізнається, з якого типу пристрою/браузера/ОС/мови ви відкриваєте веб-сайт (Наприклад, для Adaptive design): коли ви відправляєте HTTP-запит, він містить заголовки (headers) з різною інформацією. Одним із них є User-Agent. Він повідомляє: браузер, його версію та мову, движок браузера, версію движка, операційну систему.
3. Тіло повідомлення : Тіло HTTP-повідомлення (message-body), якщо воно є, використовується для передачі тіла об'єкта, пов'язаного із запитом або відповіддю. Тіло повідомлення відрізняється від тіла об'єкта (entity-body) тільки в тому випадку, коли використовується кодування передачі, що вказується полем заголовка Transfer-Encoding.
Поле Transfer-Encoding має використовуватися для вказівки будь-якого кодування передачі, застосованого додатком з метою гарантування безпечної та правильної передачі повідомлення. Поле Transfer-Encoding - це властивість повідомлення, а не об'єкта, і, таким чином, може бути додано або видалено будь-якою програмою в ланцюжку запитів/відповідей.
Правила, що встановлюють допустимість тіла повідомлення у повідомленні, відмінні для запитів та відповідей.
Присутність тіла повідомлення у запиті відзначається додаванням до заголовків запиту поля заголовка Content-Length або Transfer-Encoding. Тіло повідомлення може бути додано до запиту лише тоді, коли метод запиту допускає тіло об'єкта.
Включається або не включається тіло повідомлення до повідомлення відповіді - залежить від методу запиту, і від коду стану відповіді. Всі відповіді на запит з методом HEAD не повинні включати тіло повідомлення, навіть якщо є поля заголовка об'єкта (entity-header), що змушують повірити в присутність об'єкта. Ніякі відповіді з кодами стану 1xx (Інформаційні), 204 (Немає вмісту, No Content), та 304 (Не модифікований, Not Modified) не повинні містити тіла повідомлення. Всі інші відповіді містять тіло повідомлення, навіть якщо воно має нульову довжину.
Методи HTTP
Метод HTTP (англ. HTTP Method) - послідовність із будь-яких символів, крім керуючих та роздільників, що вказує на основну операцію над ресурсом. Зазвичай метод є коротке англійське слово, записане великими літерами. Зверніть увагу, що назва методу чутлива до регістру.
Сервер може використовувати будь-які методи, не існує обов'язкових методів для сервера або клієнта, крім того, програміст може пов'язати метод і функцію, що виконується як завгодно його фантазії. Щоб уникнути хаосу існують угоди (також REST) і стандарти. Формально якщо сервер не розпізнав вказаний клієнтом метод, він повинен повернути статус 501 (Not Implemented). Якщо серверу метод відомий, але не застосовується до конкретного ресурсу, то повертається повідомлення з кодом 405 (Method Not Allowed). В обох випадках серверу слід включити в повідомлення відповіді заголовок Allow зі списком методів, що підтримуються.
OPTIONS: Використовується для визначення можливостей веб-сервера або параметрів з'єднання для певного ресурсу. У відповідь серверу слід включити заголовок Allow зі списком методів, що підтримуються. Також у заголовку відповіді може включатися інформація про розширення, що підтримуються. Передбачається, що запит клієнта може містити тіло повідомлення для вказівки відомостей, що його цікавлять. Формат тіла та порядок роботи з ним зараз не визначено; сервер поки що має його ігнорувати. Аналогічна ситуація з тілом у відповіді сервера. Для того, щоб дізнатися про можливості всього сервера, клієнт повинен вказати в URI зірочку - «*». Запити «OPTIONS * HTTP/1.1» можуть також застосовуватися для перевірки працездатності сервера (аналогічно «пінгуванню») та тестування щодо підтримки сервером протоколу HTTP версії 1.1.
GET : Використовується для запиту на вміст зазначеного ресурсу. За допомогою методу GET можна також розпочати будь-який процес. У цьому випадку в тіло повідомлення у відповідь слід включити інформацію про хід виконання процесу. Клієнт може передавати параметри виконання запиту URI цільового ресурсу після символу «?»: GET /path/resource?param1=value1¶m2=value2 HTTP/1.1. Відповідно до стандарту HTTP, запити типу GET вважаються ідемпотентними. Окрім звичайного методу GET, розрізняють ще
Умовний GET - містить заголовки If-Modified-Since, If-Match, If-Range та подібні;
Частковий GET містить у запиті Range.
Порядок виконання таких запитів визначено стандартами окремо;
HEAD : Аналогічний метод GET, за винятком того, що у відповіді сервера відсутнє тіло. Запит HEAD зазвичай застосовується для отримання метаданих, перевірки наявності ресурсу (валідація URL) і щоб дізнатися, чи не змінився він з моменту останнього звернення. Заголовки відповіді кешуються. При розбіжності метаданих ресурсу з відповідною інформацією в кеші - копія ресурсу позначається як застаріла;
PUT: Використовується для завантаження вмісту запиту на вказаний у запиті URI. Якщо за заданим URI немає ресурсу, то сервер створює його і повертає статус 201 (Created). Якщо ж ресурс було змінено, сервер повертає 200 (Ok) або 204 (No Content). Сервер не повинен ігнорувати некоректні заголовки Content-*, які передаються клієнтом разом з повідомленням. Якщо якийсь із цих заголовків не може бути розпізнаний або неприпустимий за поточних умов, необхідно повернути код помилки 501 (Not Implemented). Фундаментальна відмінність методів POST та PUT полягає у розумінні призначень URI ресурсів. Метод POST передбачає, що за вказаним URI буде проводитися обробка вмісту, що передається клієнтом. Використовуючи PUT, клієнт припускає, що завантажуваний вміст відповідає ресурсу, що знаходиться по даному URI.
PATCH : Аналогічно PUT, але застосовується лише фрагменту ресурсу;
DELETE : Видаляє зазначений ресурс;
TRACE : Повертає отриманий запит так, що клієнт може побачити, яку інформацію проміжні сервери додають або змінюють у запиті;
CONNECT : Перетворює з'єднання запиту на прозорий TCP/IP-тунель, зазвичай, щоб сприяти встановленню захищеного SSL-з'єднання через нешифрований проксі.
Відмінності методів GET та POST
Основне полягає у способі передачі даних веб-форми обробному скрипту, а саме:
Крім того:
Кількість інформації, що передається методом GET через URL, рядок обмежена 2048 символами (мінус службова інформація браузера);
Сторінку, згенеровану методом GET, можна додати до закладок та поділитися посиланням;
Sensitive data у такому відкритому вигляді очевидно погано впливають на безпеку;
Метод POST на відміну методу GET дозволяє передавати запиту файли;
При використанні методу GET існує ризик, що пошуковий робот може виконати той чи інший відкритий запит.
Коди стану
Код стану є частиною першого рядка відповіді сервера. Він є цілим числом з трьох цифр. Перша цифра вказує клас стану. За кодом відповіді зазвичай слідує відокремлена пробілом пояснювальна фраза англійською мовою, яка роз'яснює людині причину саме такої відповіді. Приклади:
201 Webpage Created;
403 Access дозволяється тільки для registered users;
507 Insufficient Storage.
Клієнт дізнається за кодом відповіді про результати його запиту та визначає, які дії йому робити далі. Набір кодів стану є стандартом і вони описані у відповідних документах RFC. Введення нових кодів має здійснюватися лише після узгодження з IETF. Клієнт може знати всі коди стану, але він має відреагувати відповідно до класу коду.
Нині виділено п'ять класів кодів стану.
Код
Клас
Призначення
100-ті (1ХХ)
Інформаційний
(англ. informational)
Інформування про процес передачі.
У HTTP/1.0 – повідомлення з такими кодами мають ігноруватися.
У HTTP/1.1 - клієнт повинен бути готовий прийняти цей клас повідомлень як звичайну відповідь, але нічого надсилати серверу не потрібно.
Самі повідомлення від сервера містять лише стартовий рядок відповіді і, якщо потрібно, кілька специфічних відповідей полів заголовка. Проксі-сервери подібні повідомлення повинні надсилати далі від сервера до клієнта.
200-ті (2ХХ)
Успіх
(англ. Success)
Інформування про випадки успішного прийняття та обробки запиту клієнта. Залежно від статусу сервер може ще передати заголовки і тіло повідомлення.
300-ті (3ХХ)
Перенаправлення
(англ. Redirection)
Повідомляє клієнту, що для успішного виконання операції необхідно зробити інший запит (зазвичай іншим URI). З цього класу п'ять кодів 301, 302, 303, 305 і 307 відносяться безпосередньо до перенаправлень (редирект). Адреса, за якою клієнту слід зробити запит, сервер вказує в заголовку Location. При цьому допускається використання фрагментів цільового URI.
400-ті (4ХХ)
Помилка клієнта
(англ. Client Error)
Вказівки помилок з боку клієнта. При використанні всіх методів, окрім HEAD, сервер повинен повернути в тілі повідомлення гіпертекстове пояснення користувача.
500-ті (5ХХ)
Помилка сервера
(англ. Server Error)
Інформація про випадки невдалого виконання операції з вини сервера. Для всіх ситуацій, крім використання методу HEAD, сервер повинен включати в тіло повідомлення пояснення, яке клієнт відобразить користувачеві.
Чому помилка 404 відноситься до 4 - клієнтської, якщо інтуїтивно повинна бути серверною? Пояснюється це тим, що сервер працює і готовий повернути сторінку у відповідь на запит, проте сторінки за адресою, що запитується, у нього просто немає. Таким чином, провини сервера в цьому немає і передбачається друкарська помилка в URL, яка є провиною клієнта. У цьому питанні спантеличує те, що помилка 404 часто повертається, коли сторінку було переміщено або видалено, або не збігається ім'я файлу в коді і на сервері. Тоді коректніше показувати помилки 301 Moved Permanently (переміщено), що можна налаштувати в конфігурації більшості серверів, або перенаправляти інший URL, і повертати код 410 Gone (видалено). Однак, оскільки ці два варіанти потребують спеціального налаштування сервера, більшість веб-сайтів не використовують їх.
На який спосіб не може повернутися помилка 501? HTTP 501 Not Implemented серверний код відповіді на помилку вказує, що метод запиту не підтримується сервером і не може бути оброблений. Єдиними методами, які необхідні серверам для підтримки (і, отже, не повинні повертати цей код) є GET і HEAD.
Відмінності HTTP/1.1 від HTTP/2.0
HTTP3
Десятиліттями весь інтернет тримався на TCP, але він почав старіти ще наприкінці 2000-х. Його передбачувана заміна, новий транспортний протокол під назвою QUIC, настільки відрізняється від TCP за ключовими пунктами, що просто використовувати поверх нього HTTP/2 було б дуже складно. Тому сам по собі HTTP/3 – це відносно незначна зміна HTTP/2 для адаптації до нового протоколу QUIC. Ось він і містить ті фічі, які всіх захоплюють.
TCP, який ми використовували з перших днів інтернету, спочатку був створений не на максимумі ефективності, тому нам і потрібен QUIC. Наприклад, TCP вимагає рукостискання для встановлення нового з'єднання, щоб перевірити, що клієнт та сервер існують і готові обмінюватися даними. Потрібно зробити повний круговий шлях через мережу, перш ніж можна буде робити щось ще. Якщо клієнт і сервер далеко, час кругового шляху (round-trip time, RTT) може становити понад 100 мс, що призводить до відчутних затримок.
Другий приклад: TCP бачить всі дані, які передає, як один файл, або потік байтів, навіть якщо ми передаємо кілька файлів одночасно (наприклад, завантажуємо сторінку з кількома ресурсами). Насправді це означає, що, якщо пакети TCP з даними одного файлу губляться, решта файлів чекатимуть відновлення цих пакетів. Це так зване блокування початку черги – head-of-line (HoL) blocking. На практиці з цими недоліками можна боротися (інакше навіщо б ми мучилися з TCP цілих 30 років), але вони серйозно впливають на протоколи верхнього рівня, наприклад, HTTP.
Насправді нам потрібний був не HTTP/3, а TCP/2. Просто у процесі у нас сам собою вийшов HTTP/3. Все те, чого ми з таким нетерпінням чекаємо від HTTP/3 (швидке встановлення з'єднання, менше блокувань HoL, міграція з'єднання і т. д.), - насправді вже реалізовано в QUIC.
QUIC
QUIC – це універсальний транспортний протокол. Як і TCP, він може і використовуватиметься в різних сценаріях, не тільки для HTTP і завантаження сайтів. Наприклад, поверх QUIC можна прилаштувати DNS, SSH, SMB, RTP тощо. Давайте дізнаємося про QUIC трохи більше, адже саме з ним пов'язані багато помилок щодо HTTP/3.
Ви, напевно, чули, що QUIC працює поверх ще одного протоколу – UDP. Це правда, але продуктивність тут ні до чого. В ідеалі QUIC міг би бути повністю незалежним транспортним протоколом відразу над IP у стеку, як на зображенні вище.
Але тоді виникли б ті ж труднощі, що й при спробі розвивати TCP: довелося б спочатку оновити всі пристрої в інтернеті, щоб вони розпізнавали та дозволяли QUIC. На щастя, ми можемо розмістити QUIC поверх іншого поширеного протоколу транспортного рівня: UDP.
Багато хто говорить, що HTTP/3 створений поверх UDP з метою продуктивності. Нібито HTTP/3 працює швидше, тому що, як і UDP, не встановлює з'єднання і не чекає повторної передачі пакетів. Чи не вірте. Ми вже сказали, що UDP використовується протоколом QUIC, а значить і HTTP/3, сподіваючись, що так їх буде простіше розгорнути, адже UDP вже знають і використовують майже всі пристрої в інтернеті.
Розташований поверх UDP, QUIC, по суті, реалізує майже всі функції, які роблять TCP таким ефективним та популярним (нехай і трохи повільнішим) протоколом. QUIC абсолютно надійний – він використовує підтвердження отриманих пакетів та повторні передачі, щоб добрати те, що загубилося. QUIC, як і раніше, встановлює з'єднання та використовує складну систему рукостискань.
Нарешті, QUIC використовує механізми flow-control та congestion-control, які не дають відправнику перевантажити мережу чи одержувача, але уповільнюють TCP порівняно з «чистим» UDP. Щоправда QUIC реалізує ці функції розумніше та ефективніше. У ньому зібрані десятиліття досвіду та кращих практик TCP та нові функції.
HTTPS
HTTP має один недолік: дані передаються у відкритому вигляді і ніяк не захищені. На шляху з точки А до точки Б інформація в інтернеті проходить через десятки проміжних вузлів, і якщо хоч один із них під контролем зловмисника, дані можуть перехопити. Те саме може статися, коли ви користуєтеся незахищеною мережею Wi-Fi, наприклад, у кафе. Для встановлення безпечного з'єднання використовується протокол HTTPS із підтримкою шифрування.
HTTPS (аббр. від англ. HyperText Transfer Protocol Secure) - розширення протоколу HTTP для підтримки шифрування з метою підвищення безпеки. Дані у протоколі HTTPS передаються поверх криптографічних протоколів TLS або застарілого у 2015 році SSL.
HTTPS не є окремим протоколом. Це звичайний HTTP, що працює через шифровані транспортні механізми SSL та TLS. Він забезпечує захист від атак, заснованих на прослуховуванні мережного з'єднання - від сніфферських атак та атак типу man-in-the-middle, за умови, що будуть використовуватися шифруючі засоби та сертифікат сервера перевірений та йому довіряють.
За умовчанням HTTPS URL використовує 443 TCP-порт (для незахищеного HTTP - 80). Щоб підготувати веб-сервер для обробки https-з'єднань, адміністратор повинен отримати та встановити сертифікат відкритого та закритого ключа для цього веб-сервера. У TLS використовується як асиметрична схема шифрування (для вироблення загального секретного ключа), так і симетрична (для обміну даними, зашифрованими загальним ключем). Сертифікат відкритого ключа підтверджує належність цього відкритого ключа власнику сайту. Сертифікат відкритого ключа та сам відкритий ключ надсилаються клієнту під час встановлення з'єднання; закритий ключ використовується для розшифровування повідомлень від клієнта.
Існує можливість створити такий сертифікат, не звертаючись до центру сертифікації. Підписуються такі сертифікати тим самим сертифікатом і називаються самопідписаними (self-signed). Без перевірки сертифіката якимось іншим способом (наприклад, дзвінок власнику та перевірка контрольної суми сертифіката) таке використання HTTPS піддається атаці посередника.
Ця система також може бути використана для автентифікації клієнта, щоб забезпечити доступ до сервера лише авторизованим користувачам. Для цього адміністратор зазвичай створює сертифікати для кожного користувача та завантажує їх у браузер кожного користувача. Також прийматимуться всі сертифікати, підписані організаціями, яким довіряє сервер. Такий сертифікат зазвичай містить ім'я та адресу електронної пошти авторизованого користувача, які перевіряються під час кожного з'єднання, щоб перевірити особу користувача без введення пароля.
У HTTPS для шифрування використовується довжина ключа 40, 56, 128 чи 256 біт. Деякі старі версії браузерів використовують довжину ключа 40 біт (приклад тому – IE версій до 4.0), що пов'язане з експортними обмеженнями США. Довжина ключа 40 біт не є надійною. Багато сучасних сайтів вимагають використання нових версій браузерів, що підтримують шифрування з довжиною ключа 128 біт, щоб забезпечити достатній рівень безпеки. Шифрування з довжиною ключа 128 біт значно ускладнює підбір паролів та доступ до особистої інформації.
Традиційно на одній IP-адресі може працювати лише один HTTPS-сайт. Для роботи кількох сайтів HTTPS з різними сертифікатами застосовується розширення TLS під назвою Server Name Indication (SNI).
Ідентифікація у HTTPS:
Ідентифікація сервера: HTTP/TLS запити генеруються шляхом розіменування URI, унаслідок чого ім'я хоста стає відоме клієнту. На початку спілкування сервер посилає клієнту свій сертифікат, щоб клієнт ідентифікував його. Це дозволяє запобігти атакі посередника. У сертифікаті вказується сервер URI. Узгодження імені хоста та даних, зазначених у сертифікаті, відбувається відповідно до протоколу RFC2459. Якщо ім'я сервера не співпадає із зазначеним у сертифікаті, то програми користувача, наприклад браузери, повідомляють про це користувачеві. В основному браузери надають користувачеві вибір: продовжити незахищене з'єднання або перервати його.
Ідентифікація клієнта: Зазвичай сервер не має інформації про клієнта, достатньої для його ідентифікації. Однак для забезпечення підвищеної захищеності з'єднання використовується так звана 2-way authentication. При цьому сервер після підтвердження сертифіката клієнтом також запитує сертифікат. Таким чином, схема підтвердження клієнта аналогічна до ідентифікації сервера.
Джерела:
Дод. матеріал:
Last updated