Module 2 → Lesson 10 → Part 3 of 8
Как устанавливается соединение
Lesson contents
- Что происходит, когда вы открываете сайт
- Как браузер находит сервер
- Как устанавливается соединение
- Как начинается защищенное HTTPS-соединение
What you'll learn
Адрес найден. Но браузер еще не разговаривает с сервером
В предыдущей части Emma Lee ввела https://academy.example.com.
Браузер получил подходящий сетевой адрес, например 203.0.113.20.
Теперь он знает:
куда попытаться подключиться.
Но это еще не означает, что между браузером и сервером уже существует рабочее соединение.
Следующий этап:
организовать транспортный обмен.
Нам уже знакомы TCP и UDP
В Уроке 9 мы разобрали два основных транспортных подхода: TCP — надежный упорядоченный поток; UDP — передача отдельных датаграмм с более минимальным встроенным механизмом.
Современный Web может использовать оба направления.
Упрощенно: HTTP/1.1 или HTTP/2 работают поверх TCP.
А HTTP/3 работает поверх QUIC, которая работает поверх UDP.
Для пользователя результат может выглядеть одинаково:
открылась веб-страница.
Но сетевой путь к этому результату устроен по-разному.
Начнем с классического варианта — TCP
Представим: Browser → 203.0.113.20 → TCP/443.
Браузер хочет установить TCP-соединение с веб-сервисом.
Но серверу недостаточно знать только IP клиента.
Нам уже знакомы порты.
Например: Emma (192.168.1.25:53142) → Server (203.0.113.20:443).
Здесь 53142 — временный клиентский порт, а 443 — стандартный порт HTTPS-сервиса.
Соединение начинается с handshake
TCP не начинает обычный обмен данными совершенно внезапно.
Сначала стороны устанавливают состояние соединения.
Мы уже видели: Client отправляет SYN → Server отвечает SYN-ACK → Client отправляет ACK.
Это TCP three-way handshake.
После успешного handshake обе стороны понимают:
соединение установлено, можно продолжать обмен.
- 1SYN — клиент предлагает начать TCP-соединение.
- 2SYN-ACK — сервер подтверждает и тоже готов установить соединение.
- 3ACK — клиент подтверждает в ответ; connection established.
- 4Client IP:ephemeral_port ↔ Server IP:443 — установленное соединение идентифицируется именно этой комбинацией адресов и портов.
Что именно означает «соединение установлено»
Между Emma и сервером не появляется отдельная физическая линия.
Пакеты все так же идут через Router → ISP → Internet → Data center.
TCP-соединение существует как логическое состояние на конечных системах.
Они отслеживают: адреса; порты; последовательность данных; подтверждения; состояние соединения.
Почему handshake вообще нужен
TCP должен подготовить стороны к надежному обмену.
Например, им нужно согласовать начальное состояние и убедиться, что двусторонний обмен возможен.
Если сервер вообще не доступен: клиент отправляет SYN и не получает ответа.
Соединение не установится.
Браузер не сможет просто сделать вид, что все прошло удачно.
Соединение может не установиться по разным причинам
Например:
Сервер выключен — клиент не может достучаться до сервера вообще.
Сервис не слушает нужный порт — сервер работает, но TCP/443 недоступен.
Firewall блокирует трафик — между клиентом и сервером стоит блокирующее правило.
Нет сетевого маршрута — путь к серверу через Интернет недоступен.
Все эти ситуации пользователь может увидеть примерно одинаково:
страница не загрузилась.
Но техническая причина находится на разных уровнях.
DNS уже сработал — а сайт все равно не открывается
Это важная диагностическая мысль.
Представим: academy.example.com → 203.0.113.20 — разрешение имени прошло успешно.
Но 203.0.113.20:443 → connection failed.
Значит, искать ошибку только в DNS уже не очень логично.
Мы перешли на следующий этап цепочки.
На соединение требуется время
Даже если все работает правильно, пакеты должны физически пройти до сервера и обратно.
Для этого полезно понятие RTT — Round-Trip Time.
Упрощенно: Emma отправляет данные серверу и получает ответ обратно — это и есть один round trip.
Чем больше RTT, тем дольше могут занимать сетевые обмены, требующие нескольких последовательных шагов.
Почему расстояние имеет значение
Представим два сервера.
Сервер A находится относительно близко: RTT ≈ 15 ms.
Сервер B на другом континенте: RTT ≈ 150 ms.
Если протоколу нужно несколько последовательных обменов, дополнительная задержка начинает складываться.
Поэтому:
быстрая скорость канала и низкая задержка — не одно и то же.
Скорость и задержка отвечают на разные вопросы
Представим очень широкую дорогу.
По ней можно одновременно перевозить огромное количество грузов.
Это похоже на высокую пропускную способность.
Но если дорога длиной несколько тысяч километров, первая машина все равно не окажется на другом конце мгновенно.
Это похоже на latency.
Поэтому соединение может иметь высокую bandwidth и одновременно заметную latency.
- 1High bandwidth / high latency — широкий, но длинный сетевой путь: много данных, но каждый обмен занимает время.
- 2Lower bandwidth / low latency — более узкий, но короткий путь: меньше данных за раз, зато обмены происходят быстрее. Пропускная способность показывает, сколько данных можно передать, а задержка — как долго данные путешествуют.
Почему это чувствуется при открытии сайтов
При загрузке большого файла важна способность передавать много данных.
А при запуске нового соединения особенно заметны: RTT; количество последовательных сетевых обменов; удаленность сервера.
Именно поэтому CDN, которые мы встретили в предыдущей части, могут улучшать не только нагрузку на сервис, но и пользовательскую задержку.
А если пакет handshake потерялся?
Интернет не гарантирует доставку каждого отдельного IP-пакета.
Поэтому служебный TCP-пакет тоже может потеряться.
Например: клиент отправляет SYN, и он теряется по пути.
В этом случае TCP может повторить попытку.
Но это занимает дополнительное время.
Поэтому нестабильная сеть может выглядеть так:
сайт иногда открывается быстро, иногда долго, иногда не открывается совсем.
Timeout — сколько ждать?
Браузер и операционная система не могут ждать ответа бесконечно.
Поэтому существуют timeouts, тайм-ауты.
Например: попытка соединения → ожидание → нет пригодного ответа → timeout.
Это не обязательно означает:
сервер никогда больше не заработает.
Это означает:
в пределах данного ожидания соединение установить не удалось.
Один сервер может иметь IPv4 и IPv6
В предыдущей части браузер мог получить IPv6-адрес и IPv4-адрес.
Что выбрать?
Простой вариант:
попробовать первый адрес, а если не работает — долго ждать и только потом попробовать второй.
Не самый приятный пользовательский опыт.
Поэтому современные системы могут использовать более умную стратегию.
Несколько вариантов подключения можно проверять почти параллельно
Существуют механизмы, позволяющие не ждать слишком долго, если один вариант сетевого пути работает плохо.
Концептуально: попытка через IPv6 начинается, а чуть позже начинается и попытка через IPv4.
Рабочий вариант может быть использован быстрее.
Один известный подход называется Happy Eyeballs.
Название несколько веселее, чем средняя тема сетевого протокола.
На этом уровне детали алгоритма нам не нужны.
Главная идея:
браузер не всегда пассивно пробует один адрес за другим.
А что происходит с QUIC?
Современный Web может использовать QUIC, который работает поверх UDP.
Для HTTP/3 схема выглядит концептуально так: HTTP/3 → QUIC → UDP → IP.
Но QUIC — не просто:
«отправили несколько UDP-пакетов и надеемся на лучшее».
Он сам реализует необходимые функции: надежность; управление потоками; контроль доставки; криптографическую защиту соединения.
В QUIC безопасность тесно связана с установлением соединения
В классическом сценарии с TCP можно представить: TCP connection → TLS handshake → HTTP.
В QUIC криптографическая установка соединения интегрирована значительно теснее.
Поэтому схема UDP → QUIC → HTTP/3 не означает, что безопасность исчезла.
Наоборот, QUIC проектировался сразу с использованием TLS.
Подробности криптографии оставим следующей части.
- 1TCP path — HTTP/2 работает поверх TLS, TLS поверх TCP, TCP поверх IP: классический стек, где транспорт и защищенное соединение — отдельные уровни.
- 2QUIC path — HTTP/3 работает через QUIC с интегрированным TLS, а QUIC — поверх UDP поверх IP: криптографическая защита встроена в само установление соединения. Современные версии HTTP могут использовать разные транспортные механизмы.
Почему Web вообще меняет транспорт
Потому что важны: скорость установления соединения; устойчивость к потерям; работа нескольких потоков; мобильность пользователя; задержка.
Протоколы развиваются вместе с Интернетом.
Но фундаментальный вопрос остается тем же:
как браузеру надежно и достаточно быстро установить обмен с нужным сервером?
Соединение можно использовать повторно
Еще один важный момент.
Браузер получил HTML.
Внутри страницы есть styles.css, app.js, logo.svg.
Было бы расточительно каждый раз делать новое DNS → новое соединение → новое TLS → один маленький файл.
Поэтому уже установленное соединение можно использовать повторно, если условия это позволяют.
Connection reuse
Например: established connection → HTML → CSS → JavaScript → API data.
Это уменьшает количество лишних этапов.
HTTP/2 умеет больше
При HTTP/1.1 исторически существовали различные ограничения и способы работы с несколькими запросами.
HTTP/2 позволяет эффективнее использовать одно соединение для нескольких потоков данных.
Концептуально: одно соединение обслуживает HTML, CSS, JS и API одновременно.
Эта возможность называется multiplexing.
Это помогает не создавать отдельное TCP-соединение для каждого ресурса.
Но один TCP-поток имеет свои особенности
Если на уровне TCP теряется необходимая часть данных, восстановление этой части может влиять на данные, использующие тот же TCP-поток.
Это одна из причин, почему транспорт для HTTP продолжил развиваться.
QUIC реализует несколько логических потоков иначе.
Глубже здесь не идем — для понимания открытия сайта нам достаточно знать:
современные браузеры стараются уменьшать лишние последовательные ожидания.
Браузер может уже иметь готовое соединение
Emma открывала сайт несколько секунд назад.
Соединение еще доступно.
Тогда новый запрос может не требовать нового TCP handshake с нуля.
Это еще одна причина, почему первая загрузка и следующая загрузка могут ощущаться по-разному.
Поэтому «время загрузки сайта» состоит из нескольких времен
Упрощенно: DNS time + connection time + security setup + server processing + data transfer + browser rendering.
Если страница открывается медленно, проблема может находиться на любом из этих этапов.
Например, сервер отвечает быстро — а соединение устанавливается медленно
Представим: DNS 20 ms, Connection 900 ms, Server 30 ms.
Само приложение работает быстро.
Проблема может находиться в сетевом пути или установлении соединения.
А в другом случае: DNS 20 ms, Connection 30 ms, Server 2000 ms.
Сеть работает отлично.
Но сервер долго формирует ответ.
Для пользователя:
«сайт тормозит».
Технически причины совершенно разные.
Где мы сейчас находимся
Вся цепочка пока такая: URL → Name resolution ✓ → IP address ✓ → Transport connection ✓ → ? → HTTP request.
Перед HTTP остается критически важный этап.
Если адрес начинается с https://, браузеру нужно создать защищенное соединение и проверить, что он разговаривает с подходящим сервером.
Это уже не просто вопрос маршрута
Сеть доставила пакеты к 203.0.113.20.
Но Emma вводила academy.example.com.
Теперь браузеру нужно понять:
может ли удаленная сторона криптографически подтвердить право представлять `academy.example.com`?
Именно здесь появляются: TLS; сертификаты; центры сертификации; проверка имени; ключи шифрования.
Главное, что нужно запомнить
- Получение IP-адреса еще не означает наличие соединения с сервером.
- Для HTTP/1.1 и HTTP/2 широко используется TCP.
- TCP устанавливает соединение с помощью handshake.
- TCP-соединение является логическим состоянием конечных систем, а не отдельным физическим кабелем.
- Источник и назначение различаются комбинацией IP-адресов и портов.
- Соединение может не установиться из-за сетевой недоступности, firewall, отсутствия сервиса или других проблем.
- RTT показывает время прохождения данных туда и обратно.
- Bandwidth и latency — разные характеристики сети.
- Потеря пакетов способна увеличить время установления соединения.
- Timeout ограничивает время ожидания сетевого события.
- Клиент может использовать несколько вариантов IPv4/IPv6 и выбирать работоспособный путь без долгого последовательного ожидания.
- HTTP/3 работает поверх QUIC, а QUIC — поверх UDP.
- Использование UDP не означает отсутствие надежности или криптографической защиты в QUIC.
- Уже установленное соединение можно использовать повторно.
- Современные протоколы позволяют обслуживать несколько логических потоков через меньшее количество соединений.
- Медленная загрузка сайта может быть вызвана сетевым соединением, сервером или другими этапами — это не одна проблема.
Что дальше
Теперь браузер знает IP и установил транспортный обмен.
Но Emma ввела https://.
Значит, обычного соединения недостаточно.
Нужно решить сразу несколько вопросов:
Как убедиться, что сервер действительно представляет нужный домен?
Как договориться о ключах?
Как скрыть содержимое трафика от посторонних по пути?
Как обнаружить изменение данных?
Продолжаем — в следующей части — «Как начинается защищенное HTTPS-соединение».
- Получение IP-адреса еще не означает наличие соединения с сервером.
- Для HTTP/1.1 и HTTP/2 широко используется TCP.
- TCP устанавливает соединение с помощью handshake.
- TCP-соединение является логическим состоянием конечных систем, а не отдельным физическим кабелем.
- Источник и назначение различаются комбинацией IP-адресов и портов.
- Соединение может не установиться из-за сетевой недоступности, firewall, отсутствия сервиса или других проблем.
- RTT показывает время прохождения данных туда и обратно.
- Bandwidth и latency — разные характеристики сети.
- Потеря пакетов способна увеличить время установления соединения.
- Timeout ограничивает время ожидания сетевого события.
- Клиент может использовать несколько вариантов IPv4/IPv6 и выбирать работоспособный путь без долгого последовательного ожидания.
- HTTP/3 работает поверх QUIC, а QUIC — поверх UDP.
- Использование UDP не означает отсутствие надежности или криптографической защиты в QUIC.
- Уже установленное соединение можно использовать повторно.
- Современные протоколы позволяют обслуживать несколько логических потоков через меньшее количество соединений.
- Медленная загрузка сайта может быть вызвана сетевым соединением, сервером или другими этапами — это не одна проблема.
The address is found. But the browser isn't talking to the server yet
In the previous part, Emma Lee entered https://academy.example.com.
The browser got a suitable network address, for example 203.0.113.20.
Now it knows:
where to try to connect.
But this doesn't yet mean that a working connection already exists between the browser and the server.
The next stage:
set up a transport exchange.
We're already familiar with TCP and UDP
In Lesson 9 we covered two main transport approaches: TCP — a reliable ordered stream; UDP — delivery of individual datagrams with a much more minimal built-in mechanism.
The modern Web can use either direction.
Simplified: HTTP/1.1 or HTTP/2 work on top of TCP.
And HTTP/3 works on top of QUIC, which works on top of UDP.
For the user, the result can look the same:
the web page opened.
But the network path to that result is built differently.
Let's start with the classic option — TCP
Picture this: Browser → 203.0.113.20 → TCP/443.
The browser wants to establish a TCP connection with the web service.
But it's not enough for the server to know only the client's IP.
We're already familiar with ports.
For example: Emma (192.168.1.25:53142) → Server (203.0.113.20:443).
Here 53142 is a temporary client port, and 443 is the standard port for the HTTPS service.
The connection starts with a handshake
TCP doesn't just suddenly start an ordinary data exchange.
First, the two sides establish the connection state.
We've already seen this: Client sends SYN → Server responds with SYN-ACK → Client sends ACK.
This is the TCP three-way handshake.
After a successful handshake, both sides understand:
the connection is established, the exchange can continue.
- 1SYN — the client proposes starting a TCP connection.
- 2SYN-ACK — the server confirms and is also ready to establish the connection.
- 3ACK — the client confirms in response; connection established.
- 4Client IP:ephemeral_port ↔ Server IP:443 — the established connection is identified precisely by this combination of addresses and ports.
What "the connection is established" actually means
No separate physical line appears between Emma and the server.
The packets still travel through Router → ISP → Internet → Data center.
A TCP connection exists as a logical state on the endpoint systems.
They track: addresses; ports; the sequence of data; acknowledgments; connection state.
Why the handshake is needed at all
TCP has to prepare both sides for a reliable exchange.
For example, they need to agree on the initial state and make sure a two-way exchange is possible.
If the server isn't reachable at all: the client sends SYN and gets no response.
The connection won't be established.
The browser can't just pretend everything went fine.
The connection may fail to establish for different reasons
For example:
The server is down — the client can't reach the server at all.
The service isn't listening on the needed port — the server is running, but TCP/443 is unreachable.
A firewall is blocking traffic — there's a blocking rule standing between the client and the server.
There's no network route — the path to the server through the Internet is unavailable.
The user can see all of these situations in roughly the same way:
the page didn't load.
But the technical cause sits at different levels.
DNS already worked — but the site still won't open
This is an important diagnostic idea.
Picture this: academy.example.com → 203.0.113.20 — name resolution succeeded.
But 203.0.113.20:443 → connection failed.
So it's no longer very logical to look for the error only in DNS.
We've moved on to the next stage of the chain.
A connection takes time
Even if everything is working correctly, packets have to physically travel to the server and back.
For this, the concept of RTT — Round-Trip Time — is useful.
Simplified: Emma sends data to the server and gets a response back — that's one round trip.
The larger the RTT, the longer network exchanges that require several sequential steps can take.
Why distance matters
Picture two servers.
Server A is relatively close: RTT ≈ 15 ms.
Server B is on another continent: RTT ≈ 150 ms.
If a protocol needs several sequential exchanges, this extra delay starts to add up.
Hence:
a fast channel speed and low latency are not the same thing.
Speed and latency answer different questions
Picture a very wide road.
It can carry a huge amount of cargo at the same time.
This is similar to high bandwidth.
But if the road is several thousand kilometers long, the first car still won't appear at the other end instantly.
This is similar to latency.
So a connection can have high bandwidth and, at the same time, noticeable latency.
- 1High bandwidth / high latency — a wide but long network path: a lot of data, but each exchange takes time.
- 2Lower bandwidth / low latency — a narrower but shorter path: less data at once, but exchanges happen faster. Bandwidth shows how much data can be transferred, while latency shows how long the data travels.
Why this is felt when opening sites
When loading a large file, the ability to transfer a lot of data matters.
And when starting a new connection, what's especially noticeable is: RTT; the number of sequential network exchanges; how far away the server is.
This is exactly why CDNs, which we encountered in the previous part, can improve not only the load on the service but also the user's latency.
What if a handshake packet is lost?
The Internet doesn't guarantee delivery of every single IP packet.
So a service TCP packet can get lost too.
For example: the client sends SYN, and it gets lost along the way.
In this case, TCP can retry.
But this takes extra time.
So an unstable network can look like this:
the site sometimes opens fast, sometimes slowly, sometimes doesn't open at all.
Timeout — how long to wait?
The browser and the operating system can't wait for a response forever.
That's why timeouts exist.
For example: connection attempt → waiting → no usable response → timeout.
This doesn't necessarily mean:
the server will never work again.
It means:
the connection couldn't be established within this particular wait.
A single server can have both an IPv4 and an IPv6 address
In the previous part, the browser might have gotten both an IPv6 address and an IPv4 address.
Which one to pick?
A simple option:
try the first address, and if it doesn't work — wait a long time and only then try the second one.
Not the most pleasant user experience.
So modern systems can use a smarter strategy.
Several connection options can be checked almost in parallel
There are mechanisms that keep you from waiting too long if one network path option is working poorly.
Conceptually: an attempt over IPv6 starts, and a bit later an attempt over IPv4 starts too.
Whichever option works can be used sooner.
One well-known approach is called Happy Eyeballs.
The name is a bit more cheerful than the average networking-protocol topic.
We don't need the algorithm's details at this level.
The main idea:
the browser doesn't always passively try one address after another.
And what happens with QUIC?
The modern Web can use QUIC, which works on top of UDP.
For HTTP/3, the scheme conceptually looks like this: HTTP/3 → QUIC → UDP → IP.
But QUIC isn't just:
"sent a few UDP packets and hoped for the best."
It implements the necessary functions itself: reliability; flow control; delivery control; cryptographic protection of the connection.
In QUIC, security is tightly tied to establishing the connection
In the classic scenario with TCP, you can picture: TCP connection → TLS handshake → HTTP.
In QUIC, the cryptographic setup of the connection is integrated much more tightly.
So the scheme UDP → QUIC → HTTP/3 doesn't mean security has disappeared.
On the contrary, QUIC was designed from the start with TLS in mind.
We'll leave the cryptographic details for the next part.
- 1TCP path — HTTP/2 works on top of TLS, TLS on top of TCP, TCP on top of IP: a classic stack, where the transport and the secured connection are separate layers.
- 2QUIC path — HTTP/3 works via QUIC with integrated TLS, and QUIC is on top of UDP on top of IP: cryptographic protection is built into the connection establishment itself. Modern versions of HTTP can use different transport mechanisms.
Why the Web changes transport at all
Because what matters is: speed of establishing a connection; resilience to loss; handling multiple streams; user mobility; latency.
Protocols evolve along with the Internet.
But the fundamental question stays the same:
how can the browser reliably and quickly enough establish an exchange with the needed server?
A connection can be reused
Another important point.
The browser got the HTML.
Inside the page there's styles.css, app.js, logo.svg.
It would be wasteful to do a new DNS lookup → new connection → new TLS → one tiny file, every single time.
So an already established connection can be reused if conditions allow it.
Connection reuse
For example: established connection → HTML → CSS → JavaScript → API data.
This reduces the number of extra stages.
HTTP/2 can do more
With HTTP/1.1, various limitations and ways of handling multiple requests historically existed.
HTTP/2 makes it possible to use a single connection more efficiently for several data streams.
Conceptually: one connection serves HTML, CSS, JS, and API all at once.
This capability is called multiplexing.
This helps avoid creating a separate TCP connection for every resource.
But a single TCP stream has its own quirks
If a necessary piece of data is lost at the TCP level, recovering that piece can affect other data sharing the same TCP stream.
This is one of the reasons the transport for HTTP kept evolving.
QUIC implements several logical streams differently.
We won't go deeper here — for understanding how a site opens, it's enough to know:
modern browsers try to reduce unnecessary sequential waiting.
The browser may already have a ready connection
Emma opened the site a few seconds ago.
The connection is still available.
Then a new request may not need a fresh TCP handshake from scratch.
This is another reason the first load and the next load can feel different.
So "site load time" is made up of several times
Simplified: DNS time + connection time + security setup + server processing + data transfer + browser rendering.
If the page opens slowly, the problem can be at any of these stages.
For example, the server responds fast — but the connection is established slowly
Picture this: DNS 20 ms, Connection 900 ms, Server 30 ms.
The application itself is working fast.
The problem may be in the network path or in establishing the connection.
And in another case: DNS 20 ms, Connection 30 ms, Server 2000 ms.
The network is working great.
But the server takes a long time to put together the response.
For the user:
"the site is slow."
Technically, the causes are completely different.
Where we stand now
The whole chain so far looks like this: URL → Name resolution ✓ → IP address ✓ → Transport connection ✓ → ? → HTTP request.
There's a critically important stage left before HTTP.
If the address starts with https://, the browser needs to create a secure connection and verify that it's talking to the right server.
This is no longer just a matter of routing
The network delivered the packets to 203.0.113.20.
But Emma entered academy.example.com.
Now the browser needs to figure out:
can the remote side cryptographically prove the right to represent `academy.example.com`?
This is exactly where these appear: TLS; certificates; certificate authorities; name verification; encryption keys.
The main things to remember
- Getting an IP address still doesn't mean there's a connection to the server.
- TCP is widely used for HTTP/1.1 and HTTP/2.
- TCP establishes a connection using a handshake.
- A TCP connection is a logical state of the endpoint systems, not a separate physical cable.
- Source and destination are distinguished by the combination of IP addresses and ports.
- A connection may fail to establish because of network unreachability, a firewall, a missing service, or other problems.
- RTT shows the time for data to travel there and back.
- Bandwidth and latency are different characteristics of a network.
- Packet loss can increase the time it takes to establish a connection.
- A timeout limits how long to wait for a network event.
- A client can use several IPv4/IPv6 options and choose a working path without a long sequential wait.
- HTTP/3 works on top of QUIC, and QUIC works on top of UDP.
- Using UDP doesn't mean an absence of reliability or cryptographic protection in QUIC.
- An already established connection can be reused.
- Modern protocols make it possible to serve several logical streams through fewer connections.
- Slow site loading can be caused by the network connection, the server, or other stages — it's not one single problem.
What's next
Now the browser knows the IP and has established the transport exchange.
But Emma entered https://.
That means an ordinary connection isn't enough.
Several questions need to be resolved at once:
How can we be sure the server really represents the needed domain?
How do we agree on keys?
How do we hide the traffic's contents from outsiders along the way?
How do we detect if the data has been altered?
Let's continue — in the next part — "How a secure HTTPS connection begins."
- Getting an IP address still doesn't mean a connection to the server exists.
- TCP is widely used for HTTP/1.1 and HTTP/2.
- TCP establishes a connection through a handshake.
- A TCP connection is a logical state on the endpoints, not a separate physical cable.
- Source and destination are distinguished by a combination of IP addresses and ports.
- A connection can fail to establish because of network unreachability, a firewall, a missing service, or other problems.
- RTT shows how long it takes data to travel there and back.
- Bandwidth and latency are different network characteristics.
- Packet loss can increase how long it takes to establish a connection.
- A timeout limits how long to wait for a network event.
- A client can try several IPv4/IPv6 options and pick a working path without a long sequential wait.
- HTTP/3 runs over QUIC, and QUIC runs over UDP.
- Using UDP doesn't mean QUIC lacks reliability or cryptographic protection.
- An already-established connection can be reused.
- Modern protocols let several logical streams be served over fewer connections.
- A slow-loading site can be caused by the network connection, the server, or other stages — it's not just one problem.
Η διεύθυνση βρέθηκε. Όμως το πρόγραμμα περιήγησης δεν μιλάει ακόμα με τον διακομιστή
Στο προηγούμενο μέρος η Emma Lee πληκτρολόγησε https://academy.example.com.
Το πρόγραμμα περιήγησης έλαβε μια κατάλληλη διεύθυνση δικτύου, για παράδειγμα 203.0.113.20.
Τώρα γνωρίζει:
πού να προσπαθήσει να συνδεθεί.
Όμως αυτό δεν σημαίνει ακόμα ότι ανάμεσα στο πρόγραμμα περιήγησης και τον διακομιστή υπάρχει ήδη μια λειτουργική σύνδεση.
Το επόμενο στάδιο:
να οργανώσει την ανταλλαγή μεταφοράς.
Γνωρίζουμε ήδη τα TCP και UDP
Στο Μάθημα 9 εξετάσαμε δύο βασικές προσεγγίσεις μεταφοράς: TCP — αξιόπιστη, ταξινομημένη ροή· UDP — μετάδοση μεμονωμένων datagrams με πιο στοιχειώδη ενσωματωμένο μηχανισμό.
Το σύγχρονο Web μπορεί να χρησιμοποιεί και τις δύο κατευθύνσεις.
Απλοποιημένα: τα HTTP/1.1 ή HTTP/2 λειτουργούν πάνω από το TCP.
Ενώ το HTTP/3 λειτουργεί πάνω από το QUIC, το οποίο λειτουργεί πάνω από το UDP.
Για τον χρήστη το αποτέλεσμα μπορεί να φαίνεται ίδιο:
άνοιξε μια ιστοσελίδα.
Όμως η δικτυακή διαδρομή προς αυτό το αποτέλεσμα είναι διαφορετικά δομημένη.
Ας ξεκινήσουμε με την κλασική παραλλαγή — το TCP
Ας φανταστούμε: Browser → 203.0.113.20 → TCP/443.
Το πρόγραμμα περιήγησης θέλει να εγκαθιδρύσει σύνδεση TCP με την υπηρεσία ιστού.
Όμως δεν αρκεί ο διακομιστής να γνωρίζει μόνο την IP του πελάτη.
Γνωρίζουμε ήδη τις θύρες.
Για παράδειγμα: Emma (192.168.1.25:53142) → Server (203.0.113.20:443).
Εδώ η 53142 είναι μια προσωρινή θύρα πελάτη, ενώ η 443 είναι η τυπική θύρα της υπηρεσίας HTTPS.
Η σύνδεση ξεκινά με ένα handshake
Το TCP δεν ξεκινά την κανονική ανταλλαγή δεδομένων εντελώς ξαφνικά.
Αρχικά οι δύο πλευρές καθιερώνουν την κατάσταση της σύνδεσης.
Το έχουμε ήδη δει: ο πελάτης στέλνει SYN → ο διακομιστής απαντά με SYN-ACK → ο πελάτης στέλνει ACK.
Αυτό είναι το TCP three-way handshake.
Μετά από ένα επιτυχημένο handshake, και οι δύο πλευρές γνωρίζουν:
η σύνδεση έχει εγκαθιδρυθεί, η ανταλλαγή μπορεί να συνεχιστεί.
- 1SYN — ο πελάτης προτείνει να ξεκινήσει σύνδεση TCP.
- 2SYN-ACK — ο διακομιστής επιβεβαιώνει και είναι επίσης έτοιμος να εγκαθιδρύσει τη σύνδεση.
- 3ACK — ο πελάτης επιβεβαιώνει σε απάντηση· connection established.
- 4Client IP:ephemeral_port ↔ Server IP:443 — η εγκαθιδρυμένη σύνδεση αναγνωρίζεται ακριβώς από αυτόν τον συνδυασμό διευθύνσεων και θυρών.
Τι ακριβώς σημαίνει «η σύνδεση έχει εγκαθιδρυθεί»
Ανάμεσα στην Emma και τον διακομιστή δεν εμφανίζεται κάποια ξεχωριστή φυσική γραμμή.
Τα πακέτα εξακολουθούν να περνούν μέσα από Router → ISP → Internet → Data center.
Η σύνδεση TCP υπάρχει ως μια λογική κατάσταση στα τελικά συστήματα.
Παρακολουθούν: διευθύνσεις· θύρες· ακολουθία δεδομένων· επιβεβαιώσεις· κατάσταση της σύνδεσης.
Γιατί χρειάζεται καθόλου το handshake
Το TCP πρέπει να προετοιμάσει τις δύο πλευρές για αξιόπιστη ανταλλαγή.
Για παράδειγμα, χρειάζεται να συμφωνήσουν σε μια αρχική κατάσταση και να βεβαιωθούν ότι η αμφίδρομη ανταλλαγή είναι δυνατή.
Αν ο διακομιστής δεν είναι καθόλου διαθέσιμος: ο πελάτης στέλνει SYN και δεν λαμβάνει απάντηση.
Η σύνδεση δεν θα εγκαθιδρυθεί.
Το πρόγραμμα περιήγησης δεν μπορεί απλώς να κάνει ότι όλα πήγαν καλά.
Η σύνδεση μπορεί να μην εγκαθιδρυθεί για διάφορους λόγους
Για παράδειγμα:
Ο διακομιστής είναι απενεργοποιημένος — ο πελάτης δεν μπορεί καθόλου να τον προσεγγίσει.
Η υπηρεσία δεν «ακούει» στην απαιτούμενη θύρα — ο διακομιστής λειτουργεί, αλλά το TCP/443 δεν είναι διαθέσιμο.
Το firewall μπλοκάρει την κίνηση — ανάμεσα στον πελάτη και τον διακομιστή υπάρχει ένας κανόνας αποκλεισμού.
Δεν υπάρχει δικτυακή διαδρομή — η διαδρομή προς τον διακομιστή μέσω του Internet δεν είναι διαθέσιμη.
Όλες αυτές οι καταστάσεις μπορεί να φαίνονται στον χρήστη περίπου το ίδιο:
η σελίδα δεν φορτώθηκε.
Όμως η τεχνική αιτία βρίσκεται σε διαφορετικά επίπεδα.
Το DNS λειτούργησε ήδη — όμως ο ιστότοπος και πάλι δεν ανοίγει
Αυτή είναι μια σημαντική διαγνωστική σκέψη.
Ας φανταστούμε: academy.example.com → 203.0.113.20 — η επίλυση ονόματος ολοκληρώθηκε επιτυχώς.
Όμως 203.0.113.20:443 → connection failed.
Άρα, το να αναζητούμε το σφάλμα μόνο στο DNS δεν είναι πια πολύ λογικό.
Περάσαμε στο επόμενο στάδιο της αλυσίδας.
Η σύνδεση απαιτεί χρόνο
Ακόμα κι αν όλα λειτουργούν σωστά, τα πακέτα πρέπει να διανύσουν φυσικά τη διαδρομή μέχρι τον διακομιστή και πίσω.
Για αυτό είναι χρήσιμη η έννοια του RTT — Round-Trip Time.
Απλοποιημένα: η Emma στέλνει δεδομένα στον διακομιστή και λαμβάνει την απάντηση πίσω — αυτό είναι ένα round trip.
Όσο μεγαλύτερο είναι το RTT, τόσο περισσότερο μπορεί να διαρκούν οι δικτυακές ανταλλαγές που απαιτούν πολλά διαδοχικά βήματα.
Γιατί έχει σημασία η απόσταση
Ας φανταστούμε δύο διακομιστές.
Ο διακομιστής A βρίσκεται σχετικά κοντά: RTT ≈ 15 ms.
Ο διακομιστής B βρίσκεται σε άλλη ήπειρο: RTT ≈ 150 ms.
Αν ένα πρωτόκολλο χρειάζεται πολλές διαδοχικές ανταλλαγές, η επιπλέον καθυστέρηση αρχίζει να συσσωρεύεται.
Γι' αυτό:
η υψηλή ταχύτητα καναλιού και η χαμηλή καθυστέρηση δεν είναι το ίδιο πράγμα.
Η ταχύτητα και η καθυστέρηση απαντούν σε διαφορετικά ερωτήματα
Ας φανταστούμε έναν πολύ φαρδύ δρόμο.
Πάνω του μπορεί κανείς να μεταφέρει ταυτόχρονα τεράστια ποσότητα φορτίων.
Αυτό μοιάζει με υψηλό εύρος ζώνης.
Όμως αν ο δρόμος έχει μήκος αρκετές χιλιάδες χιλιόμετρα, το πρώτο αυτοκίνητο δεν θα βρεθεί ούτως ή άλλως στιγμιαία στην άλλη άκρη.
Αυτό μοιάζει με το latency.
Γι' αυτό μια σύνδεση μπορεί να έχει υψηλό bandwidth και ταυτόχρονα αισθητό latency.
- 1High bandwidth / high latency — φαρδιά, αλλά μακριά δικτυακή διαδρομή: πολλά δεδομένα, αλλά κάθε ανταλλαγή απαιτεί χρόνο.
- 2Lower bandwidth / low latency — πιο στενή, αλλά σύντομη διαδρομή: λιγότερα δεδομένα κάθε φορά, αλλά οι ανταλλαγές γίνονται πιο γρήγορα. Το εύρος ζώνης δείχνει πόσα δεδομένα μπορούν να μεταφερθούν, ενώ η καθυστέρηση δείχνει πόσο χρόνο ταξιδεύουν τα δεδομένα.
Γιατί αυτό γίνεται αισθητό κατά το άνοιγμα ιστότοπων
Κατά τη λήψη ενός μεγάλου αρχείου, έχει σημασία η ικανότητα μεταφοράς μεγάλου όγκου δεδομένων.
Ενώ κατά την εκκίνηση μιας νέας σύνδεσης γίνονται ιδιαίτερα αισθητά: το RTT· ο αριθμός των διαδοχικών δικτυακών ανταλλαγών· η απόσταση του διακομιστή.
Γι' αυτόν ακριβώς τον λόγο τα CDN, που συναντήσαμε στο προηγούμενο μέρος, μπορούν να βελτιώνουν όχι μόνο τον φόρτο της υπηρεσίας, αλλά και την καθυστέρηση που βιώνει ο χρήστης.
Κι αν χαθεί ένα πακέτο του handshake;
Το Internet δεν εγγυάται την παράδοση κάθε μεμονωμένου πακέτου IP.
Γι' αυτό μπορεί να χαθεί και ένα πακέτο ελέγχου του TCP.
Για παράδειγμα: ο πελάτης στέλνει SYN, και αυτό χάνεται στη διαδρομή.
Σε αυτή την περίπτωση το TCP μπορεί να επαναλάβει την προσπάθεια.
Όμως αυτό απαιτεί επιπλέον χρόνο.
Γι' αυτό ένα ασταθές δίκτυο μπορεί να φαίνεται ως εξής:
ο ιστότοπος μερικές φορές ανοίγει γρήγορα, μερικές φορές αργά, μερικές φορές δεν ανοίγει καθόλου.
Timeout — πόσο να περιμένουμε;
Το πρόγραμμα περιήγησης και το λειτουργικό σύστημα δεν μπορούν να περιμένουν απάντηση επ' αόριστον.
Γι' αυτό υπάρχουν τα timeouts, χρονικά όρια.
Για παράδειγμα: προσπάθεια σύνδεσης → αναμονή → καμία κατάλληλη απάντηση → timeout.
Αυτό δεν σημαίνει απαραίτητα:
ότι ο διακομιστής δεν θα λειτουργήσει ποτέ ξανά.
Σημαίνει:
μέσα σε αυτό το χρονικό διάστημα αναμονής, η σύνδεση δεν κατάφερε να εγκαθιδρυθεί.
Ένας διακομιστής μπορεί να έχει IPv4 και IPv6
Στο προηγούμενο μέρος το πρόγραμμα περιήγησης μπορεί να έλαβε μια διεύθυνση IPv6 και μια διεύθυνση IPv4.
Ποια να επιλέξει;
Μια απλή επιλογή:
να δοκιμάσει την πρώτη διεύθυνση, και αν δεν λειτουργεί — να περιμένει πολύ και μόνο μετά να δοκιμάσει τη δεύτερη.
Δεν είναι η πιο ευχάριστη εμπειρία χρήστη.
Γι' αυτό τα σύγχρονα συστήματα μπορούν να χρησιμοποιούν μια πιο έξυπνη στρατηγική.
Πολλές επιλογές σύνδεσης μπορούν να ελέγχονται σχεδόν παράλληλα
Υπάρχουν μηχανισμοί που επιτρέπουν να μην περιμένουμε πολύ, αν μία από τις επιλογές δικτυακής διαδρομής λειτουργεί άσχημα.
Εννοιολογικά: η προσπάθεια μέσω IPv6 ξεκινά, και λίγο αργότερα ξεκινά και η προσπάθεια μέσω IPv4.
Η επιλογή που λειτουργεί μπορεί να χρησιμοποιηθεί γρηγορότερα.
Μια γνωστή προσέγγιση ονομάζεται Happy Eyeballs.
Το όνομα είναι κάπως πιο αστείο από το μέσο θέμα ενός δικτυακού πρωτοκόλλου.
Σε αυτό το επίπεδο δεν χρειαζόμαστε τις λεπτομέρειες του αλγορίθμου.
Η βασική ιδέα:
το πρόγραμμα περιήγησης δεν δοκιμάζει πάντα παθητικά τη μία διεύθυνση μετά την άλλη.
Και τι συμβαίνει με το QUIC;
Το σύγχρονο Web μπορεί να χρησιμοποιεί το QUIC, το οποίο λειτουργεί πάνω από το UDP.
Για το HTTP/3, το σχήμα φαίνεται εννοιολογικά ως εξής: HTTP/3 → QUIC → UDP → IP.
Όμως το QUIC δεν είναι απλώς:
«στείλαμε μερικά πακέτα UDP και ελπίζουμε στο καλύτερο».
Υλοποιεί το ίδιο τις απαραίτητες λειτουργίες: αξιοπιστία· διαχείριση ροών· έλεγχο παράδοσης· κρυπτογραφική προστασία της σύνδεσης.
Στο QUIC η ασφάλεια συνδέεται στενά με την εγκαθίδρυση της σύνδεσης
Στο κλασικό σενάριο με το TCP μπορούμε να το φανταστούμε ως εξής: TCP connection → TLS handshake → HTTP.
Στο QUIC η κρυπτογραφική εγκαθίδρυση της σύνδεσης είναι ενσωματωμένη πολύ πιο στενά.
Γι' αυτό το σχήμα UDP → QUIC → HTTP/3 δεν σημαίνει ότι η ασφάλεια εξαφανίστηκε.
Αντίθετα, το QUIC σχεδιάστηκε εξαρχής με χρήση TLS.
Τις λεπτομέρειες της κρυπτογραφίας θα τις αφήσουμε για το επόμενο μέρος.
- 1TCP path — το HTTP/2 λειτουργεί πάνω από το TLS, το TLS πάνω από το TCP, το TCP πάνω από το IP: ένα κλασικό stack, όπου η μεταφορά και η προστατευμένη σύνδεση είναι ξεχωριστά επίπεδα.
- 2QUIC path — το HTTP/3 λειτουργεί μέσω QUIC με ενσωματωμένο TLS, ενώ το QUIC λειτουργεί πάνω από UDP πάνω από IP: η κρυπτογραφική προστασία είναι ενσωματωμένη στην ίδια την εγκαθίδρυση της σύνδεσης. Οι σύγχρονες εκδόσεις του HTTP μπορούν να χρησιμοποιούν διαφορετικούς μηχανισμούς μεταφοράς.
Γιατί το Web αλλάζει καν τη μεταφορά
Επειδή έχουν σημασία: η ταχύτητα εγκαθίδρυσης της σύνδεσης· η ανθεκτικότητα στις απώλειες· η λειτουργία πολλών ροών· η κινητικότητα του χρήστη· η καθυστέρηση.
Τα πρωτόκολλα εξελίσσονται μαζί με το Internet.
Όμως το θεμελιώδες ερώτημα παραμένει το ίδιο:
πώς μπορεί το πρόγραμμα περιήγησης να εγκαθιδρύσει αξιόπιστα και αρκετά γρήγορα την ανταλλαγή με τον απαιτούμενο διακομιστή;
Η σύνδεση μπορεί να επαναχρησιμοποιηθεί
Ακόμα ένα σημαντικό σημείο.
Το πρόγραμμα περιήγησης έλαβε το HTML.
Μέσα στη σελίδα υπάρχουν τα styles.css, app.js, logo.svg.
Θα ήταν σπάταλο να γίνεται κάθε φορά νέο DNS → νέα σύνδεση → νέο TLS → ένα μικρό αρχείο.
Γι' αυτό μια ήδη εγκαθιδρυμένη σύνδεση μπορεί να επαναχρησιμοποιηθεί, αν οι συνθήκες το επιτρέπουν.
Connection reuse
Για παράδειγμα: established connection → HTML → CSS → JavaScript → API data.
Αυτό μειώνει τον αριθμό των περιττών σταδίων.
Το HTTP/2 μπορεί περισσότερα
Στο HTTP/1.1 υπήρχαν ιστορικά διάφοροι περιορισμοί και τρόποι διαχείρισης πολλαπλών αιτημάτων.
Το HTTP/2 επιτρέπει την πιο αποδοτική χρήση μίας σύνδεσης για πολλές ροές δεδομένων.
Εννοιολογικά: μία σύνδεση εξυπηρετεί ταυτόχρονα HTML, CSS, JS και API.
Αυτή η δυνατότητα ονομάζεται multiplexing.
Αυτό βοηθά να μη δημιουργείται ξεχωριστή σύνδεση TCP για κάθε πόρο.
Όμως μία ροή TCP έχει τις δικές της ιδιαιτερότητες
Αν σε επίπεδο TCP χαθεί ένα απαραίτητο κομμάτι δεδομένων, η αποκατάστασή του μπορεί να επηρεάσει τα δεδομένα που χρησιμοποιούν την ίδια ροή TCP.
Αυτός είναι ένας από τους λόγους για τους οποίους η μεταφορά για το HTTP συνέχισε να εξελίσσεται.
Το QUIC υλοποιεί τις πολλαπλές λογικές ροές διαφορετικά.
Δεν προχωράμε βαθύτερα εδώ — για την κατανόηση του ανοίγματος ενός ιστότοπου μάς αρκεί να γνωρίζουμε:
τα σύγχρονα προγράμματα περιήγησης προσπαθούν να μειώνουν τις περιττές διαδοχικές αναμονές.
Το πρόγραμμα περιήγησης μπορεί να έχει ήδη έτοιμη σύνδεση
Η Emma είχε ανοίξει τον ιστότοπο πριν από λίγα δευτερόλεπτα.
Η σύνδεση είναι ακόμα διαθέσιμη.
Τότε ένα νέο αίτημα μπορεί να μην απαιτεί νέο TCP handshake από την αρχή.
Αυτός είναι ακόμα ένας λόγος για τον οποίο η πρώτη φόρτωση και η επόμενη φόρτωση μπορεί να γίνονται αισθητές διαφορετικά.
Γι' αυτό ο «χρόνος φόρτωσης ενός ιστότοπου» αποτελείται από πολλούς επιμέρους χρόνους
Απλοποιημένα: DNS time + connection time + security setup + server processing + data transfer + browser rendering.
Αν η σελίδα ανοίγει αργά, το πρόβλημα μπορεί να βρίσκεται σε οποιοδήποτε από αυτά τα στάδια.
Για παράδειγμα, ο διακομιστής απαντά γρήγορα — όμως η σύνδεση εγκαθιδρύεται αργά
Ας φανταστούμε: DNS 20 ms, Connection 900 ms, Server 30 ms.
Η ίδια η εφαρμογή λειτουργεί γρήγορα.
Το πρόβλημα μπορεί να βρίσκεται στη δικτυακή διαδρομή ή στην εγκαθίδρυση της σύνδεσης.
Ενώ σε μια άλλη περίπτωση: DNS 20 ms, Connection 30 ms, Server 2000 ms.
Το δίκτυο λειτουργεί άψογα.
Όμως ο διακομιστής χρειάζεται πολύ χρόνο για να διαμορφώσει την απάντηση.
Για τον χρήστη:
«ο ιστότοπος είναι αργός».
Τεχνικά, οι αιτίες είναι εντελώς διαφορετικές.
Πού βρισκόμαστε τώρα
Όλη η αλυσίδα μέχρι στιγμής είναι η εξής: URL → Name resolution ✓ → IP address ✓ → Transport connection ✓ → ? → HTTP request.
Πριν από το HTTP απομένει ένα κρίσιμο στάδιο.
Αν η διεύθυνση ξεκινά με https://, το πρόγραμμα περιήγησης πρέπει να δημιουργήσει μια προστατευμένη σύνδεση και να επαληθεύσει ότι μιλάει με τον κατάλληλο διακομιστή.
Αυτό δεν είναι πια απλώς ζήτημα διαδρομής
Το δίκτυο παρέδωσε τα πακέτα στο 203.0.113.20.
Όμως η Emma είχε πληκτρολογήσει το academy.example.com.
Τώρα το πρόγραμμα περιήγησης πρέπει να καταλάβει:
μπορεί η απομακρυσμένη πλευρά να αποδείξει κρυπτογραφικά το δικαίωμα να αντιπροσωπεύει το `academy.example.com`;
Ακριβώς εδώ εμφανίζονται: το TLS· τα πιστοποιητικά· οι αρχές πιστοποίησης· ο έλεγχος ονόματος· τα κλειδιά κρυπτογράφησης.
Τα βασικά που πρέπει να θυμόμαστε
- Η λήψη μιας διεύθυνσης IP δεν σημαίνει ακόμα ότι υπάρχει σύνδεση με τον διακομιστή.
- Για τα HTTP/1.1 και HTTP/2 χρησιμοποιείται ευρέως το TCP.
- Το TCP εγκαθιδρύει τη σύνδεση μέσω ενός handshake.
- Η σύνδεση TCP είναι μια λογική κατάσταση των τελικών συστημάτων, όχι ένα ξεχωριστό φυσικό καλώδιο.
- Η πηγή και ο προορισμός διακρίνονται μέσω του συνδυασμού διευθύνσεων IP και θυρών.
- Η σύνδεση μπορεί να μην εγκαθιδρυθεί λόγω δικτυακής απροσπελασιμότητας, firewall, απουσίας υπηρεσίας ή άλλων προβλημάτων.
- Το RTT δείχνει τον χρόνο διέλευσης των δεδομένων πηγαινέλα.
- Το bandwidth και το latency είναι διαφορετικά χαρακτηριστικά του δικτύου.
- Η απώλεια πακέτων μπορεί να αυξήσει τον χρόνο εγκαθίδρυσης της σύνδεσης.
- Το timeout περιορίζει τον χρόνο αναμονής ενός δικτυακού συμβάντος.
- Ο πελάτης μπορεί να χρησιμοποιεί πολλές επιλογές IPv4/IPv6 και να επιλέγει τη διαδρομή που λειτουργεί, χωρίς μεγάλη διαδοχική αναμονή.
- Το HTTP/3 λειτουργεί πάνω από το QUIC, ενώ το QUIC λειτουργεί πάνω από το UDP.
- Η χρήση του UDP δεν σημαίνει απουσία αξιοπιστίας ή κρυπτογραφικής προστασίας στο QUIC.
- Μια ήδη εγκαθιδρυμένη σύνδεση μπορεί να επαναχρησιμοποιηθεί.
- Τα σύγχρονα πρωτόκολλα επιτρέπουν την εξυπηρέτηση πολλών λογικών ροών μέσω λιγότερων συνδέσεων.
- Η αργή φόρτωση ενός ιστότοπου μπορεί να οφείλεται στη δικτυακή σύνδεση, στον διακομιστή ή σε άλλα στάδια — δεν πρόκειται για ένα μόνο πρόβλημα.
Τι ακολουθεί
Τώρα το πρόγραμμα περιήγησης γνωρίζει την IP και έχει εγκαθιδρύσει την ανταλλαγή μεταφοράς.
Όμως η Emma πληκτρολόγησε https://.
Άρα, μια συνηθισμένη σύνδεση δεν αρκεί.
Χρειάζεται να λυθούν αμέσως πολλά ερωτήματα:
Πώς να βεβαιωθούμε ότι ο διακομιστής πράγματι αντιπροσωπεύει τον απαιτούμενο τομέα;
Πώς να συμφωνήσουμε στα κλειδιά;
Πώς να κρύψουμε το περιεχόμενο της κίνησης από τρίτους στη διαδρομή;
Πώς να εντοπίσουμε την αλλοίωση δεδομένων;
Συνεχίζουμε — στο επόμενο μέρος — «Πώς ξεκινά η προστατευμένη σύνδεση HTTPS».
- Η λήψη μιας διεύθυνσης IP δεν σημαίνει ακόμη ότι υπάρχει σύνδεση με τον server.
- Το TCP χρησιμοποιείται ευρέως για HTTP/1.1 και HTTP/2.
- Το TCP καθιερώνει μια σύνδεση μέσω ενός handshake.
- Μια σύνδεση TCP είναι μια λογική κατάσταση στα άκρα, όχι ένα ξεχωριστό φυσικό καλώδιο.
- Η προέλευση και ο προορισμός διακρίνονται από τον συνδυασμό διευθύνσεων IP και θυρών.
- Μια σύνδεση μπορεί να μην καθιερωθεί λόγω δικτυακής μη προσβασιμότητας, firewall, απουσίας υπηρεσίας ή άλλων προβλημάτων.
- Το RTT δείχνει πόσο χρόνο χρειάζονται τα δεδομένα για να ταξιδέψουν και να επιστρέψουν.
- Το bandwidth και η latency είναι διαφορετικά χαρακτηριστικά δικτύου.
- Η απώλεια πακέτων μπορεί να αυξήσει τον χρόνο καθιέρωσης μιας σύνδεσης.
- Ένα timeout περιορίζει τον χρόνο αναμονής για ένα δικτυακό συμβάν.
- Ένας πελάτης μπορεί να δοκιμάσει πολλές επιλογές IPv4/IPv6 και να επιλέξει μια λειτουργική διαδρομή χωρίς μεγάλη διαδοχική αναμονή.
- Το HTTP/3 λειτουργεί πάνω από το QUIC, και το QUIC πάνω από το UDP.
- Η χρήση του UDP δεν σημαίνει ότι το QUIC στερείται αξιοπιστίας ή κρυπτογραφικής προστασίας.
- Μια ήδη καθιερωμένη σύνδεση μπορεί να επαναχρησιμοποιηθεί.
- Τα σύγχρονα πρωτόκολλα επιτρέπουν την εξυπηρέτηση πολλών λογικών ροών μέσω λιγότερων συνδέσεων.
- Η αργή φόρτωση ενός ιστότοπου μπορεί να προκληθεί από τη δικτυακή σύνδεση, τον server ή άλλα στάδια — δεν είναι ένα μόνο πρόβλημα.