Какво е TCP/TLS handshake и как браузърът установява сигурна връзка

Q: Какво е TCP handshake?

TCP handshake е тристепенен процес (SYN-->SYN-->ACK-->ACK), чрез който браузърът и сървърът установяват надеждна транспортна сесия преди да обменят данни.

Какво е TCP/TLS handshake? Това е двустепенен процес, при който браузърът първо установява надеждна транспортна връзка със сървъра (TCP), а после договаря криптиране и проверява самоличността му (TLS). Двете се изпълняват автоматично, без да знаеш за тях, при всяко зареждане на HTTPS сайт.

Вижда се на практика: отваряш адрес в браузъра, лентата за зареждане се запълва за секунда-две и сайтът се появява. Зад тази секунда обаче стоят няколко невидими размени между браузъра и сървъра, преди да пристигне дори един байт съдържание. TCP и TLS handshake са точно там – между момента, в който браузърът знае IP адреса на сървъра, и момента, в който изпраща първата HTTP заявка.

Разбирането им е важно не само теоретично. TCP и TLS handshake са пряка причина за висок TTFB (метрика, измерваща времето от заявката на браузъра до получаването на първия байт данни от сървъра) и бавно първо зареждане, и са нещо, което конкретно можеш да оптимизираш.

Какво е TCP/TLS handshake и как браузърът установява сигурна връзка

Съдържание на тази страница:

Какво се случва след DNS резолюцията?

В клъстера „Как работи уебът“ вече разгледах какво е DNS и какво е IP адрес. DNS ти дава IP адреса на сървъра. IP адресът ти казва накъде да изпратиш данните. Но преди браузърът да може да изпрати дори един HTTP байт, трябва да направи нещо друго – да установи връзка.

Точно тук влизат в действие TCP и TLS.

Важно: TCP гарантира, че връзката е надеждна. TLS гарантира, че е криптирана. Заедно те са основата на всяко HTTPS зареждане.

Какво е TCP и защо е нужен handshake?

TCP (Transmission Control Protocol) е транспортен протокол, който управлява как данните пътуват между два компютъра в мрежата. За разлика от UDP (User Datagram Protocol – бърз, лек, безконтактен протокол за транспортен слой, проектиран за скорост и ефективност при мрежови комуникации), който „изстрелва и забравя“, TCP гарантира доставката: ако пакет се изгуби по пътя, той се изпраща отново.

За да може това да работи, TCP трябва първо да установи сесия между клиента (браузъра) и сървъра. Тази сесия се установява чрез процес, наречен three-way handshake (тристепенно ръкостискане).

Без него браузърът и сървърът не знаят:

дали другата страна е активна и отговаря,
каква е максималната скорост на предаване,
как да номерират и проследяват пакетите.

Как работи TCP three-way handshake?

Процесът се извършва в точно три стъпки:

Стъпка 1. SYN (Synchronize) Браузърът изпраща пакет с флаг SYN. Той казва: „Искам да установя връзка и ето начален пореден номер на пакетите ми.“

Стъпка 2. SYN-ACK (Synchronize + Acknowledge) Сървърът отговаря: „Получих твоя SYN, потвърждавам го (ACK) и изпращам моя SYN с моя начален номер.“

Стъпка 3. ACK (Acknowledge) Браузърът потвърждава SYN на сървъра. Сесията е активна и данните могат да текат.

Целият процес отнема 1 round-trip time (RTT) – времето, необходимо на пакет да стигне до сървъра и да се върне. При сървър в друга държава това може да са 80–150 ms.

Какво е TLS и защо HTTPS го изисква?

TLS (Transport Layer Security) е криптографски протокол, наследник на SSL (Secure Sockets Layer). Всеки сайт с https:// използва TLS, за да гарантира три неща:

Свойство	Какво означава
Конфиденциалност	Данните са криптирани — трети страни не могат да ги четат
Цялост	Данните не са подменени по пътя
Автентичност	Наистина говориш с правилния сървър (потвърдено чрез сертификат)

TLS handshake се извършва след TCP handshake. Браузърът трябва първо да има активна TCP сесия, за да може да преговаря за криптиране.

Как работи TLS handshake стъпка по стъпка?

TLS 1.2 (класическият вариант)

При TLS 1.2 handshake отнема 2 round-trips (2 RTT) – към 1 RTT от TCP handshake, общото закъснение преди първия HTTP байт може да достигне 3 RTT.

Виж допълнително по въпроса: Какво е TLS handshake.

Какво е cipher suite?

Cipher suite е набор от алгоритми, договорени между браузъра и сървъра за:

Key exchange (размяна на ключове): напр. ECDHE;
Authentication (удостоверяване): напр. RSA или ECDSA;
Encryption (криптиране): напр. AES-256-GCM;
Message integrity (проверка на целостта): напр. SHA-384.

Каква е разликата между TLS 1.2 и TLS 1.3?

TLS 1.3 е текущият стандарт (от 2018 г.) и носи значителни подобрения:

Характеристика	TLS 1.2	TLS 1.3
Handshake RTT	2 RTT	1 RTT
0-RTT възобновяване	Не	Да
Поддържани cipher suites	Много (включително слаби)	Само силни
Forward Secrecy (функция за сигурност в системите за криптиране)	По избор	Задължително
Скорост	По-бавен	По-бърз

TLS 1.3 свежда handshake-а до 1 RTT вместо 2, като комбинира стъпките по-ефективно. В практиката това означава с 100–300 ms по-бързо първо зареждане на сайта при отдалечени сървъри.

Всички съвременни браузъри и сървъри поддържат TLS 1.3. Ако твоят сайт още не го използва, промяната в конфигурацията на сървъра е лесна и има директен ефект върху TTFB.

Какво е 0-RTT и кога се използва?

0-RTT (Zero Round Trip Time Resumption) е механизъм в TLS 1.3, при който браузърът може да изпрати криптирани данни веднага, без да изчаква handshake, ако е имал предишна сесия с този сървър.

Ограничения на 0-RTT:

Уязвим е на replay attacks (атаки с повторно изпращане). Затова се използва само за идемпотентни заявки (GET, но не POST).
Работи само при повторни посещения, не при първо зареждане.

След какво е TCP/TLS handshake да видим как влияе на TTFB и Core Web Vitals?

TTFB (Time To First Byte) е времето от момента на заявката до получаването на първия байт от отговора. TCP и TLS handshake директно увеличават TTFB. Те се случват изцяло преди сървърът да изпрати дори един байт HTML.

Как TCP/TLS handshake влияе на TTFB и Core Web Vitals?

Влияние върху Core Web Vitals:

LCP (Largest Contentful Paint) – висок TTFB пряко забавя LCP, тъй като браузърът не може да започне да парсва HTML докато не получи първия байт.
FCP (First Contentful Paint) също се засяга директно.
INP е по-малко засегнат, но бавните повторни заявки (API calls) могат да увеличат латентността на интеракциите.

Как да намалиш overhead от handshake?

1. Използвай TLS 1.3 Намалява TLS handshake от 2 RTT на 1 RTT. Провери в конфигурацията на сървъра или CDN си.

2. Активирай HTTP/2 или HTTP/3. HTTP/2 мултиплексира заявките върху една TCP+TLS сесия. Прави само един handshake за всички ресурси. HTTP/3 (QUIC) елиминира TCP напълно и обединява транспортния и криптографския handshake в 1 RTT.

3. Използвай CDN. CDN поставя сървъри близо до потребителите. По-малкото физическо разстояние = по-малко RTT = по-бърз handshake.

4. Keep-Alive / Connection Reuse. Браузърът може да използва вече установена TCP+TLS сесия за следващи заявки към същия сървър без повторен handshake.

Как да измериш TCP и TLS времето в Chrome DevTools?

Отвори нов Incognito прозорец (Ctrl+Shift+N).
Отвори DevTools (F12) и отиди на таб Network. Направи това преди да въведеш адреса.
Въведи URL-а и натисни Enter. Кликни върху основния HTML документ (първата заявка в списъка). В дясно намери таб Timing.

Ще видиш разбивка:

Фаза	Какво измерва
Stalled	Изчакване преди TCP връзката
DNS Lookup	DNS резолюция
Initial connection	TCP three-way handshake
SSL	TLS handshake
Waiting (TTFB)	Изчакване на отговор от сървъра
Content Download	Изтегляне на тялото на отговора

Как да измериш TCP и TLS времето в Chrome DevTools?

Ако SSL фазата е над 100–150 ms, сървърът вероятно още използва TLS 1.2. Преминаването към TLS 1.3 ще намали тази стойност значително.

Практически съвет: Сравни SSL времето на главния документ с времето на ресурси, заредени по-късно. Ако вторите нямат SSL фаза, значи браузърът успешно повторно е използвал съществуващата TLS сесия.

Заключение

Преди браузърът да изпрати дори един HTTP байт, се случват два невидими процеса:

TCP three-way handshake установява надеждна транспортна сесия (1 RTT).
TLS handshake договаря криптиране и верифицира сертификата (1 RTT при TLS 1.3, 2 RTT при TLS 1.2).

Заедно те добавят 2–3 RTT закъснение към TTFB и са пряка причина за бавно първо зареждане, особено при отдалечени сървъри. Оптимизирането им (TLS 1.3, HTTP/2, CDN, connection reuse) е едно от най-ефективните неща, които можеш да направиш за Core Web Vitals на сайта.

Пълна последователност на зареждане:

URL въведен
    │
    ▼
DNS резолюция → IP адрес
    │
    ▼
TCP handshake (1 RTT)
    │
    ▼
TLS handshake (1–2 RTT)
    │
    ▼
HTTP заявка → Отговор → HTML парсване → DOM → CSSOM → Render Tree → Paint

Следващата стъпка в клъстера: Как работи HTTP →

FAQ – Често задавани въпроси

Какво е TCP handshake?

TCP handshake е тристепенен процес (SYN–>SYN–>ACK–>ACK), чрез който браузърът и сървърът установяват надеждна транспортна сесия преди да обменят данни.

Каква е разликата между TCP и TLS handshake?

TCP handshake установява транспортната връзка (надеждност). TLS handshake се добавя върху нея и договаря криптирането (сигурност). При HTTPS се изпълняват и двата – първо TCP, после TLS.

Колко време отнема TLS handshake?

При TLS 1.3 – около 1 RTT (50–150 ms в зависимост от разстоянието до сървъра). При TLS 1.2 – около 2 RTT (100–300 ms). CDN значително намалява тези стойности.

Защо сайтовете с HTTPS се зареждат по-бавно от HTTP?

Заради допълнителния TLS handshake. Разликата обаче е минимална при TLS 1.3 и CDN и е напълно оправдана от сигурността. HTTP/2 и HTTP/3 допълнително компенсират overhead.

Какво е forward secrecy?

Forward secrecy (или perfect forward secrecy) означава, че дори ако частният ключ на сървъра бъде компрометиран в бъдеще, минали сесии не могат да бъдат декриптирани. TLS 1.3 го изисква задължително.

Какво е QUIC и как се различава от TCP+TLS?

QUIC е транспортен протокол (основата на HTTP/3), разработен от Google. Той обединява TCP и TLS в един handshake от 1 RTT (или 0-RTT при повторна връзка) и работи върху UDP вместо TCP. Резултатът: по-бърза и по-устойчива на загуба на пакети връзка.

Тази статия е част от клъстера „Как работи уебът“ в ivytechnoweb.net. Прочети и останалите теми: DNS · IP адрес · Уеб сървър · HTTP · HTML парсване · DOM · Critical Rendering Path