Module 2 → Lesson 10 → Part 1 of 8
Что происходит после нажатия Enter
Lesson contents
- Что происходит, когда вы открываете сайт
What you'll learn
Одно нажатие — много действий
Emma Lee открывает браузер и вводит https://example.com.
Затем нажимает Enter.
Через мгновение появляется страница.
Для пользователя произошло почти одно действие: ввела адрес → получила сайт.
Но браузеру пришлось последовательно решить несколько разных задач.
Очень упрощенно: URL → определить, куда обращаться → найти сетевой адрес → установить соединение → защитить соединение → отправить HTTP-запрос → получить ответ → обработать HTML, CSS, JavaScript → показать страницу.
И все это обычно происходит быстрее, чем Emma успевает задуматься:
«А где вообще находится этот сайт?»
Начнем с того, что Emma ввела не IP-адрес
Она ввела https://example.com.
Это не просто название сайта.
Это URL.
URL может содержать несколько частей.
Например: https://academy.example.com/course/lesson?id=10#part-1.
Разберем его.
- 1Scheme — https, указывает тип доступа.
- 2Host — academy.example.com, имя сетевого узла или сервиса.
- 3Path — /course/lesson, путь к ресурсу внутри веб-сервиса.
- 4Query — ?id=10, дополнительные параметры запроса.
- 5Fragment — #part-1, обычно не отправляется серверу как часть HTTP-запроса.
1. Схема
Первая часть — https:// — называется scheme, схема.
Она указывает, какой тип доступа предполагается использовать.
Здесь HTTPS означает защищенный веб-доступ по HTTP поверх криптографически защищенного соединения.
Пока этого определения достаточно.
Как именно работает HTTPS, подробно разберем в Уроке 12.
2. Имя хоста
Дальше — academy.example.com.
Это имя сетевого узла или сервиса, к которому мы хотим обратиться.
В нем можно увидеть example.com и academy.
Но пока не будем разбирать устройство доменных имен глубже.
Этому целиком посвящен Урок 11 «Домены, IP-адреса и DNS простыми словами».
Сейчас нам нужна только одна идея:
браузер должен каким-то образом превратить понятное человеку имя в информацию, позволяющую сети найти нужный сервис.
3. Путь
Следующая часть — /course/lesson — называется path, путь.
Она помогает указать, какой именно ресурс нужен внутри веб-сервиса.
Например, / может означать главную страницу, а /course/lesson — определенный раздел приложения.
4. Query parameters
Затем — ?id=10.
Это query, параметры запроса.
Они позволяют передать дополнительную информацию.
Например, ?id=10 может означать: показать объект с идентификатором 10.
В реальных приложениях query может содержать несколько параметров.
5. Fragment
И наконец — #part-1 — называется fragment, фрагмент.
Он часто используется браузером для перехода к определенному месту внутри уже полученного документа или состояния приложения.
И здесь есть интересная деталь:
fragment после `#` обычно не отправляется веб-серверу как часть HTTP-запроса.
Его обрабатывает сам браузер или код страницы.
URL — это инструкция, а не сам сайт
Полезно разделить URL и web page.
URL говорит браузеру:
что и где нужно попытаться получить.
А содержимое еще предстоит загрузить.
Это примерно как адрес ресторана:
адрес — не ужин.
Хотя иногда ожидание страницы на плохом соединении ощущается примерно одинаково долго.
Что браузер делает первым
После Enter браузер анализирует введенный адрес.
Ему нужно понять: какая схема используется; какое имя сервиса указано; какой ресурс запрашивается; присутствует ли нестандартный порт; есть ли параметры и fragment.
То есть сначала браузер превращает пользовательскую строку в понятную ему структуру.
А где порт?
В URL можно написать его явно.
Например: https://example.com:8443/.
Здесь 8443 — номер порта.
Мы уже знаем из предыдущего урока:
IP помогает найти сетевой узел, а порт — нужный сетевой сервис.
Но обычно пользователь не пишет стандартный порт вручную.
Для HTTPS браузер знает стандартное значение TCP 443, если протокол и ситуация не требуют иного транспортного механизма.
Современный Web также может использовать HTTP/3 поверх QUIC/UDP, поэтому не стоит превращать правило:
HTTPS = всегда только TCP/443
в закон природы.
Теперь браузеру нужен сетевой адрес
Emma знает example.com.
Но маршрутизаторы работают не с человеческим названием сайта как с почтовой вывеской.
Им нужна сетевая адресация.
Поэтому браузеру требуется узнать:
какой IP-адрес или адреса связаны с этим именем?
Упрощенно: example.com → ? → 203.0.113.20.
Эту задачу решает DNS.
Но сейчас не будем вскрывать всю конструкцию.
Для текущего урока достаточно:
DNS помогает получить сетевую информацию, связанную с доменным именем.
Подробно — в следующем уроке.
Причем ответ может быть не один
Имя сайта не обязано указывать на один-единственный сервер.
DNS может привести пользователя к: одному из нескольких серверов; CDN; балансировщику; инфраструктуре, выбранной для конкретного региона.
Поэтому схема:
example.com = одна физическая машина
часто неверна.
Браузер получил адрес. Что дальше?
Допустим, выяснилось: example.com → 203.0.113.20.
Теперь браузеру нужно установить сетевой обмен с нужным сервисом.
Начинается уже знакомая цепочка: Browser → операционная система → локальная сеть → router → ISP → Internet → сеть сервера.
То есть Web не использует какой-то отдельный волшебный Интернет.
Он работает поверх той же сетевой инфраструктуры, которую мы только что изучили.
Сначала транспорт
Браузеру необходимо организовать транспортный обмен с сервером.
В зависимости от используемой версии HTTP и доступных возможностей это может происходить, например, через TCP или QUIC поверх UDP.
Мы уже знакомы с обоими базовыми подходами.
Если используется TCP
Концептуально: Browser → TCP connection → Server.
Стороны устанавливают TCP-соединение.
Мы уже видели: SYN → SYN-ACK → ACK.
После этого существует транспортный канал для дальнейшего обмена.
Но HTTPS требует еще одного шага
Если URL начинается с https://, браузер не должен просто начать передавать веб-данные в открытом виде.
Перед обычным HTTP-обменом необходимо создать защищенное соединение.
Здесь появляется TLS.
Пока запомним три задачи: защитить содержимое обмена от чтения посторонними по пути; обнаруживать недопустимое изменение защищаемых данных; помочь браузеру проверить подлинность сервера с помощью сертификатов.
Как именно это происходит — отдельная большая тема Урока 12.
Сертификат появляется до страницы
Это полезно понять заранее.
Сначала браузер устанавливает защищенное взаимодействие и проверяет необходимые криптографические параметры.
И только потом внутри защищенного соединения отправляется обычный веб-запрос.
Упрощенно: TCP / QUIC → TLS / защищенное соединение → HTTP.
Реальные современные протоколы устроены немного сложнее, особенно HTTP/3, но для первой модели этого достаточно.
Теперь можно отправить HTTP-запрос
Браузер хочет получить /course/lesson?id=10.
Он формирует запрос.
Концептуально: GET /course/lesson?id=10 — и добавляет другую необходимую служебную информацию.
Например, серверу важно понимать, к какому имени хоста относится запрос.
Что такое HTTP
Основная модель очень понятна: клиент отправляет запрос серверу, а сервер возвращает клиенту ответ.
Браузер просит ресурс.
Сервер отвечает.
HTTP и HTTPS — не два совершенно разных Web
Это важное различие.
HTTP определяет:
как устроен веб-обмен запросами и ответами.
HTTPS означает использование HTTP с криптографической защитой соединения.
Упрощенно: HTTP + TLS = HTTPS.
Это намеренно упрощенная формула, но она помогает разделить роли.
Сервер получает запрос
Запрос попадает в инфраструктуру сервиса.
Она может быть очень простой: Browser → Web Server.
Или сложной: Browser → Load Balancer → Web Server → Application → Database.
Emma этого обычно не видит.
Для нее результат один:
браузер ждет ответ.
Что сервер может вернуть
Например, HTML.
Но также ответ содержит служебную информацию: статус; тип содержимого; правила кеширования; cookies; другие HTTP headers.
Подробно устройство HTTP-запросов и ответов мы разберем в следующих частях.
Страница еще не готова
Получив первый HTML, браузер часто обнаруживает внутри ссылки на дополнительные ресурсы: CSS, JavaScript, images, fonts, other data.
И начинает загружать их.
Поэтому одна открытая страница может вызвать:
десятки или сотни отдельных сетевых запросов.
Например
Первый ответ — index.html — содержит styles.css, app.js, logo.svg, avatar.jpg.
Тогда браузер делает новые запросы: GET styles.css, GET app.js, GET logo.svg, GET avatar.jpg.
Причем ресурсы не обязаны находиться на том же сервере.
- 1index.html — первый ответ сервера, начальная точка страницы.
- 2styles.css — стили оформления, отдельный запрос.
- 3app.js — код приложения, отдельный запрос.
- 4logo.svg и avatar.jpg — изображения, тоже отдельные запросы.
- 5API data — данные, которые страница может запросить дополнительно, часто с другого имени хоста.
- 6www.example.com, api.example.com, cdn.example.net — ресурсы одной страницы не обязаны приходить с одного и того же сервиса.
Один сайт может обращаться к нескольким системам
Например, www.example.com может загрузить данные с api.example.com, изображения с cdn.example.net, а еще обратиться к стороннему сервису.
Поэтому фраза:
«Я открыл один сайт»
не означает:
«Мой браузер установил ровно одно сетевое соединение с одним компьютером».
Браузер начинает строить страницу
После получения HTML браузер анализирует его структуру.
Затем: применяет CSS; выполняет необходимый JavaScript; загружает дополнительные ресурсы; рассчитывает расположение элементов; рисует результат на экране.
То есть путь заканчивается не на:
«сервер прислал HTML».
Браузеру еще нужно превратить полученные данные в интерфейс.
Веб-страница — это результат работы двух сторон
На сервере может выполняться: бизнес-логика; работа с базой данных; аутентификация; формирование ответа.
В браузере: отображение HTML; применение CSS; выполнение JavaScript; пользовательское взаимодействие.
Поэтому современный Web — это не просто:
«сервер отправил готовую картинку страницы».
А иногда часть данных уже есть локально
Браузер может хранить некоторые ранее загруженные ресурсы в cache, кеше.
Это позволяет не загружать одно и то же каждый раз заново.
Например, logo.svg может уже находиться на устройстве.
Но кеш тоже подчиняется правилам
Браузер не должен просто решить:
«Мне нравится версия сайта со вторника, оставлю ее навсегда».
Сервер может сообщать: как долго ресурс допустимо использовать; нужно ли проверить его актуальность; следует ли вообще его кешировать.
Кеширование — отдельный механизм Web, а не копилка случайных старых файлов.
И еще существуют cookies
При веб-обмене вы часто встретите cookies.
Cookies могут использоваться, например, для: сессии; настроек; других функций приложения.
Но:
cookie ≠ обязательно пароль
и:
cookie ≠ обязательно реклама.
Назначение зависит от конкретного сайта и cookie.
Сессии и безопасность cookies подробно разберем позже.
Вся цепочка в одной схеме
Emma вводит https://example.com/course.
Дальше концептуально: Browser parses URL → узнает сетевой адрес → устанавливает transport connection → создает защищенное HTTPS-соединение → отправляет HTTP request → server processes request → HTTP response → Browser получает HTML → загружает дополнительные ресурсы → строит и отображает страницу.
Именно эту цепочку мы будем постепенно раскрывать в Уроке 10.
- 1URL — Emma вводит адрес и нажимает Enter.
- 2Name resolution — браузер узнает сетевой адрес, связанный с именем сайта.
- 3IP address — найден нужный сетевой адрес назначения.
- 4TCP / QUIC — устанавливается транспортное соединение.
- 5TLS — создается криптографически защищенное соединение для HTTPS.
- 6HTTP request — браузер отправляет запрос нужного ресурса.
- 7HTTP response — сервер обрабатывает запрос и возвращает ответ.
- 8HTML + CSS + JavaScript + media — браузер получает основной документ и дополнительные ресурсы.
- 9Rendered page — браузер строит и отображает готовую страницу.
Почему это важно для безопасности
Теперь уже видно, что фраза:
«Я открыл сайт»
скрывает много отдельных решений.
Например: какое доменное имя использовано; какой IP найден; с каким сервером установлено соединение; прошла ли проверка сертификата; какой HTTP-ответ получен; какие дополнительные ресурсы загрузились.
Фишинговый сайт тоже способен: иметь красивый дизайн; использовать HTTPS; загружаться очень быстро.
Поэтому безопасность нельзя оценивать только по тому:
«страница нормально открылась».
Замок — еще не знак добрых намерений
Если браузер установил корректное HTTPS-соединение, это означает важные вещи о защищенности соединения с указанным сайтом.
Но это не означает:
владелец сайта честный.
Мошеннический сайт тоже может получить действительный TLS-сертификат для своего домена.
Поэтому позже мы научимся отдельно проверять: домен; HTTPS; сертификат; сам ресурс.
Главное, что нужно запомнить
- После ввода адреса браузер выполняет множество последовательных действий.
- URL описывает ресурс и способ обращения к нему.
- URL может содержать scheme, hostname, path, query, port и fragment.
- Fragment после `#` обычно обрабатывается браузером и не передается серверу как часть HTTP-запроса.
- Для сетевого соединения браузеру требуется получить сетевой адрес, связанный с именем сайта.
- Эту задачу помогает решать DNS.
- Затем устанавливается транспортное взаимодействие, например TCP или QUIC.
- Для HTTPS создается криптографически защищенное соединение.
- HTTP используется для обмена запросами и ответами.
- Получение первого HTML обычно не завершает загрузку страницы.
- Браузер может дополнительно загружать CSS, JavaScript, изображения и другие ресурсы.
- Один сайт может обращаться сразу к нескольким сетевым сервисам.
- Кеш позволяет повторно использовать некоторые ресурсы.
- Cookies позволяют браузеру хранить и передавать определенные данные сайта.
- Наличие HTTPS не является доказательством добросовестности самого сайта.
Что дальше
Мы ввели https://example.com, но браузеру нужен IP-адрес.
Сам Emma его не вводила.
Значит, где-то должен существовать механизм, который отвечает на вопрос:
«Какой сетевой адрес связан с этим именем?»
В рамках текущего урока не будем еще раз полностью преподавать DNS — ему посвящен следующий отдельный урок.
Сейчас разберем именно его роль в процессе открытия страницы.
Продолжаем — в следующей части — «Как браузер находит сервер».
- После ввода адреса браузер выполняет множество последовательных действий.
- URL описывает ресурс и способ обращения к нему.
- URL может содержать scheme, hostname, path, query, port и fragment.
- Fragment после # обычно обрабатывается браузером и не передается серверу как часть HTTP-запроса.
- Для сетевого соединения браузеру требуется получить сетевой адрес, связанный с именем сайта.
- Эту задачу помогает решать DNS.
- Затем устанавливается транспортное взаимодействие, например TCP или QUIC.
- Для HTTPS создается криптографически защищенное соединение.
- HTTP используется для обмена запросами и ответами.
- Получение первого HTML обычно не завершает загрузку страницы.
- Браузер может дополнительно загружать CSS, JavaScript, изображения и другие ресурсы.
- Один сайт может обращаться сразу к нескольким сетевым сервисам.
- Кеш позволяет повторно использовать некоторые ресурсы.
- Cookies позволяют браузеру хранить и передавать определенные данные сайта.
- Наличие HTTPS не является доказательством добросовестности самого сайта.
One click — many actions
Emma Lee opens the browser and types https://example.com.
Then she presses Enter.
A moment later the page appears.
For the user, almost one action happened: entered the address → got the site.
But the browser had to solve several different tasks in sequence.
Very simplified: URL → figure out where to reach → find the network address → establish a connection → secure the connection → send an HTTP request → get a response → process HTML, CSS, JavaScript → display the page.
And all of this usually happens faster than Emma manages to wonder:
"Where is this site even located?"
Let's start with the fact that Emma didn't type an IP address
She typed https://example.com.
This isn't just the name of a site.
This is a URL.
A URL can contain several parts.
For example: https://academy.example.com/course/lesson?id=10#part-1.
Let's break it down.
- 1Scheme — https, indicates the type of access.
- 2Host — academy.example.com, the name of the network node or service.
- 3Path — /course/lesson, the path to the resource within the web service.
- 4Query — ?id=10, additional request parameters.
- 5Fragment — #part-1, usually not sent to the server as part of the HTTP request.
1. Scheme
The first part — https:// — is called the scheme.
It indicates what type of access is intended to be used.
Here HTTPS means secure web access over HTTP on top of a cryptographically protected connection.
For now, this definition is enough.
How exactly HTTPS works we'll cover in detail in Lesson 12.
2. Host name
Next comes academy.example.com.
This is the name of the network node or service we want to reach.
Within it you can see example.com and academy.
But for now let's not dig deeper into how domain names are structured.
That's the entire subject of Lesson 11, "Domains, IP addresses, and DNS in plain words."
Right now we only need one idea:
the browser must somehow turn a human-readable name into information that lets the network find the right service.
3. Path
The next part — /course/lesson — is called the path.
It helps specify exactly which resource is needed within the web service.
For example, / might mean the home page, while /course/lesson might mean a specific section of the application.
4. Query parameters
Then comes ?id=10.
This is the query, the request parameters.
They let you pass additional information.
For example, ?id=10 might mean: show the object with id 10.
In real applications, a query can contain several parameters.
5. Fragment
And finally — #part-1 — is called the fragment.
It's often used by the browser to jump to a specific place within a document or application state that has already been received.
And here's an interesting detail:
the fragment after `#` is usually not sent to the web server as part of the HTTP request.
It's handled by the browser itself or the page's own code.
A URL is an instruction, not the site itself
It's useful to separate the URL and the web page.
The URL tells the browser:
what to try to get, and where.
The actual content still has to be loaded.
It's roughly like the address of a restaurant:
the address is not the dinner.
Although sometimes waiting for a page over a bad connection feels about equally long.
What the browser does first
After Enter, the browser parses the entered address.
It needs to figure out: what scheme is used; what service name is specified; what resource is being requested; whether a non-standard port is present; whether there are query parameters and a fragment.
In other words, the browser first turns the user's string into a structure it can understand.
What about the port?
You can write it explicitly in the URL.
For example: https://example.com:8443/.
Here 8443 is the port number.
We already know from the previous lesson:
IP helps find the network node, and the port finds the right network service.
But usually the user doesn't type the standard port by hand.
For HTTPS, the browser knows the standard value TCP 443, unless the protocol and the situation call for a different transport mechanism.
Modern Web can also use HTTP/3 over QUIC/UDP, so it's not worth turning the rule:
HTTPS = always only TCP/443
into a law of nature.
Now the browser needs a network address
Emma knows example.com.
But routers don't work with a human-readable site name the way a mail carrier works with a street sign.
They need network addressing.
So the browser needs to find out:
which IP address or addresses are associated with this name?
Simplified: example.com → ? → 203.0.113.20.
This task is solved by DNS.
But we won't open up the whole construction right now.
For the current lesson, it's enough that:
DNS helps get network information tied to a domain name.
In detail — in the next lesson.
And the answer may not be just one
A site name isn't required to point to a single server.
DNS can lead the user to: one of several servers; a CDN; a load balancer; infrastructure chosen for a specific region.
So the formula:
example.com = one physical machine
is often wrong.
The browser got the address. What next?
Say it turned out: example.com → 203.0.113.20.
Now the browser needs to establish a network exchange with the desired service.
The already-familiar chain begins: Browser → operating system → local network → router → ISP → Internet → server's network.
In other words, the Web doesn't use some separate magical Internet of its own.
It runs on top of the same network infrastructure we've just studied.
Transport first
The browser needs to set up a transport exchange with the server.
Depending on the HTTP version used and the capabilities available, this can happen, for example, over TCP or QUIC over UDP.
We're already familiar with both underlying approaches.
If TCP is used
Conceptually: Browser → TCP connection → Server.
The two sides establish a TCP connection.
We've already seen: SYN → SYN-ACK → ACK.
After that, a transport channel exists for further exchange.
But HTTPS requires one more step
If the URL starts with https://, the browser must not simply start sending web data in the clear.
Before the ordinary HTTP exchange, a secure connection needs to be created.
This is where TLS comes in.
For now let's remember three tasks: protect the content of the exchange from being read by outsiders along the way; detect unauthorized modification of the protected data; help the browser verify the authenticity of the server using certificates.
Exactly how this happens is a separate, large topic for Lesson 12.
The certificate appears before the page
This is useful to understand in advance.
First the browser establishes a secure interaction and verifies the necessary cryptographic parameters.
And only then, inside the secure connection, is the ordinary web request sent.
Simplified: TCP / QUIC → TLS / secure connection → HTTP.
Real modern protocols are arranged a bit more intricately, especially HTTP/3, but for a first model this is enough.
Now the HTTP request can be sent
The browser wants to get /course/lesson?id=10.
It builds a request.
Conceptually: GET /course/lesson?id=10 — and adds other necessary service information.
For example, it matters to the server which host name the request pertains to.
What HTTP is
The basic model is very clear: the client sends a request to the server, and the server returns a response to the client.
The browser asks for a resource.
The server responds.
HTTP and HTTPS aren't two completely different Webs
This is an important distinction.
HTTP defines:
how the web exchange of requests and responses is structured.
HTTPS means using HTTP with cryptographic protection of the connection.
Simplified: HTTP + TLS = HTTPS.
This is a deliberately simplified formula, but it helps separate the roles.
The server receives the request
The request arrives at the service's infrastructure.
It can be very simple: Browser → Web Server.
Or complex: Browser → Load Balancer → Web Server → Application → Database.
Emma usually doesn't see this.
For her, there's one result:
the browser waits for a response.
What the server can return
For example, HTML.
But the response also contains service information: status; content type; caching rules; cookies; other HTTP headers.
We'll cover the structure of HTTP requests and responses in detail in the following parts.
The page still isn't ready
Having received the first HTML, the browser often discovers links inside it to additional resources: CSS, JavaScript, images, fonts, other data.
And begins loading them.
So one open page can trigger:
dozens or hundreds of separate network requests.
For example
The first response — index.html — contains styles.css, app.js, logo.svg, avatar.jpg.
Then the browser makes new requests: GET styles.css, GET app.js, GET logo.svg, GET avatar.jpg.
And these resources don't have to be located on the same server.
- 1index.html — the server's first response, the page's starting point.
- 2styles.css — presentation styles, a separate request.
- 3app.js — application code, a separate request.
- 4logo.svg and avatar.jpg — images, also separate requests.
- 5API data — data the page may request additionally, often from a different host name.
- 6www.example.com, api.example.com, cdn.example.net — the resources of a single page don't have to come from the same service.
A single site can talk to several systems
For example, www.example.com might load data from api.example.com, images from cdn.example.net, and also reach out to a third-party service.
So the phrase:
"I opened one site"
doesn't mean:
"My browser established exactly one network connection with one computer."
The browser starts building the page
After receiving the HTML, the browser parses its structure.
Then it: applies CSS; runs the necessary JavaScript; loads additional resources; calculates the layout of elements; draws the result on the screen.
In other words, the path doesn't end at:
"the server sent the HTML."
The browser still needs to turn the received data into an interface.
A web page is the result of both sides' work
On the server, the following can run: business logic; work with the database; authentication; forming the response.
In the browser: rendering HTML; applying CSS; running JavaScript; user interaction.
So the modern Web isn't simply:
"the server sent a ready-made picture of a page."
And sometimes part of the data is already local
The browser can store some previously loaded resources in the cache.
This makes it possible to avoid loading the same thing again every time.
For example, logo.svg might already be on the device.
But the cache also follows rules
The browser isn't allowed to just decide:
"I like Tuesday's version of the site, I'll keep it forever."
The server can indicate: how long the resource may be used; whether its freshness needs to be checked; whether it should be cached at all.
Caching is a separate mechanism of the Web, not a random stash of old files.
And then there are cookies
During web exchange you'll often run into cookies.
Cookies can be used, for example, for: sessions; settings; other application functions.
But:
cookie ≠ necessarily a password
and:
cookie ≠ necessarily advertising.
The purpose depends on the specific site and cookie.
We'll cover sessions and cookie security in detail later.
The whole chain in one diagram
Emma enters https://example.com/course.
Next, conceptually: Browser parses URL → learns the network address → establishes transport connection → creates a secure HTTPS connection → sends HTTP request → server processes request → HTTP response → Browser receives HTML → loads additional resources → builds and displays the page.
This is exactly the chain we'll gradually unpack in Lesson 10.
- 1URL — Emma enters the address and presses Enter.
- 2Name resolution — the browser learns the network address associated with the site name.
- 3IP address — the needed destination network address is found.
- 4TCP / QUIC — a transport connection is established.
- 5TLS — a cryptographically secure connection is created for HTTPS.
- 6HTTP request — the browser sends a request for the needed resource.
- 7HTTP response — the server processes the request and returns a response.
- 8HTML + CSS + JavaScript + media — the browser receives the main document and additional resources.
- 9Rendered page — the browser builds and displays the finished page.
Why this matters for security
By now it's clear that the phrase:
"I opened a site"
hides many separate decisions.
For example: which domain name was used; which IP was found; which server the connection was established with; whether the certificate check passed; what HTTP response was received; which additional resources loaded.
A phishing site is just as capable of: having an attractive design; using HTTPS; loading very fast.
So security can't be judged only by whether:
"the page opened normally."
A padlock isn't a sign of good intentions
If the browser established a correct HTTPS connection, this means important things about the protection of the connection to the specified site.
But it doesn't mean:
the site's owner is honest.
A fraudulent site can also obtain a valid TLS certificate for its own domain.
So later we'll learn to check separately: the domain; HTTPS; the certificate; the resource itself.
The main thing to remember
- After entering an address, the browser performs many sequential actions.
- A URL describes a resource and the way to reach it.
- A URL can contain scheme, hostname, path, query, port, and fragment.
- The fragment after `#` is usually handled by the browser and not passed to the server as part of the HTTP request.
- For a network connection, the browser needs to obtain the network address associated with the site's name.
- DNS helps solve this task.
- Then a transport interaction is established, for example TCP or QUIC.
- For HTTPS, a cryptographically secure connection is created.
- HTTP is used to exchange requests and responses.
- Receiving the first HTML usually doesn't finish loading the page.
- The browser may additionally load CSS, JavaScript, images, and other resources.
- A single site can reach out to several network services at once.
- The cache allows some resources to be reused.
- Cookies let the browser store and send certain site data.
- The presence of HTTPS is not proof of the good faith of the site itself.
What's next
We entered https://example.com, but the browser needs an IP address.
Emma herself didn't type it in.
So somewhere there must be a mechanism that answers the question:
"Which network address is associated with this name?"
Within the current lesson we won't fully teach DNS all over again — it gets its own separate lesson next.
Right now we'll cover exactly its role in the process of opening a page.
Continuing — in the next part — "How the Browser Finds the Server."
- After a user enters an address, the browser performs many sequential actions.
- A URL describes a resource and how to access it.
- A URL can contain a scheme, hostname, path, query, port, and fragment.
- The fragment after a # is usually handled by the browser and not sent to the server as part of the HTTP request.
- For a network connection, the browser needs to get the network address tied to the site's name.
- DNS helps with that.
- A transport connection is then established, such as TCP or QUIC.
- For HTTPS, a cryptographically protected connection is created.
- HTTP is used to exchange requests and responses.
- Getting the first HTML usually doesn't finish loading the page.
- The browser may additionally load CSS, JavaScript, images, and other resources.
- One site can reach out to several network services at once.
- The cache lets some resources be reused.
- Cookies let the browser store and send certain site data.
- Having HTTPS is not proof that the site itself is trustworthy.
Ένα πάτημα — πολλές ενέργειες
Η Emma Lee ανοίγει το πρόγραμμα περιήγησης και πληκτρολογεί https://example.com.
Στη συνέχεια πατάει Enter.
Μετά από μια στιγμή εμφανίζεται η σελίδα.
Για τον χρήστη συνέβη σχεδόν μία ενέργεια: πληκτρολόγησε τη διεύθυνση → έλαβε τον ιστότοπο.
Όμως το πρόγραμμα περιήγησης χρειάστηκε να λύσει διαδοχικά αρκετά διαφορετικά προβλήματα.
Πολύ απλοποιημένα: URL → προσδιορισμός πού να απευθυνθεί → εύρεση διεύθυνσης δικτύου → δημιουργία σύνδεσης → προστασία της σύνδεσης → αποστολή αιτήματος HTTP → λήψη απάντησης → επεξεργασία HTML, CSS, JavaScript → εμφάνιση της σελίδας.
Και όλα αυτά συνήθως συμβαίνουν πιο γρήγορα απ' όσο προλαβαίνει η Emma να το σκεφτεί:
«Και πού βρίσκεται άραγε αυτός ο ιστότοπος;»
Ας ξεκινήσουμε με το ότι η Emma δεν πληκτρολόγησε διεύθυνση IP
Πληκτρολόγησε https://example.com.
Αυτό δεν είναι απλώς το όνομα του ιστότοπου.
Είναι URL.
Το URL μπορεί να περιέχει πολλά μέρη.
Για παράδειγμα: https://academy.example.com/course/lesson?id=10#part-1.
Ας το αναλύσουμε.
- 1Scheme — https, υποδεικνύει τον τύπο πρόσβασης.
- 2Host — academy.example.com, όνομα του κόμβου δικτύου ή της υπηρεσίας.
- 3Path — /course/lesson, διαδρομή προς τον πόρο μέσα στην υπηρεσία ιστού.
- 4Query — ?id=10, πρόσθετες παράμετροι του αιτήματος.
- 5Fragment — #part-1, συνήθως δεν αποστέλλεται στον διακομιστή ως μέρος του αιτήματος HTTP.
1. Σχήμα
Το πρώτο μέρος — https:// — ονομάζεται scheme, σχήμα.
Υποδεικνύει τον τύπο πρόσβασης που πρόκειται να χρησιμοποιηθεί.
Εδώ το HTTPS σημαίνει προστατευμένη πρόσβαση ιστού μέσω HTTP πάνω από μια κρυπτογραφικά προστατευμένη σύνδεση.
Προς το παρόν αυτός ο ορισμός αρκεί.
Πώς ακριβώς λειτουργεί το HTTPS θα το αναλύσουμε λεπτομερώς στο Μάθημα 12.
2. Όνομα Host
Στη συνέχεια — academy.example.com.
Αυτό είναι το όνομα του κόμβου δικτύου ή της υπηρεσίας στην οποία θέλουμε να απευθυνθούμε.
Σε αυτό μπορούμε να δούμε το example.com και το academy.
Όμως προς το παρόν δεν θα αναλύσουμε βαθύτερα τη δομή των ονομάτων τομέα.
Σε αυτό είναι αφιερωμένο εξ ολοκλήρου το Μάθημα 11 «Τομείς, διευθύνσεις IP και DNS με απλά λόγια».
Προς το παρόν χρειαζόμαστε μόνο μία ιδέα:
το πρόγραμμα περιήγησης πρέπει με κάποιον τρόπο να μετατρέψει το κατανοητό για τον άνθρωπο όνομα σε πληροφορία που επιτρέπει στο δίκτυο να βρει την απαιτούμενη υπηρεσία.
3. Διαδρομή
Το επόμενο μέρος — /course/lesson — ονομάζεται path, διαδρομή.
Βοηθά να προσδιοριστεί ποιος ακριβώς πόρος χρειάζεται μέσα στην υπηρεσία ιστού.
Για παράδειγμα, το / μπορεί να σημαίνει την αρχική σελίδα, ενώ το /course/lesson — μια συγκεκριμένη ενότητα της εφαρμογής.
4. Query parameters
Στη συνέχεια — ?id=10.
Αυτό είναι το query, οι παράμετροι του αιτήματος.
Επιτρέπουν τη μετάδοση πρόσθετων πληροφοριών.
Για παράδειγμα, το ?id=10 μπορεί να σημαίνει: εμφάνισε το αντικείμενο με αναγνωριστικό 10.
Σε πραγματικές εφαρμογές το query μπορεί να περιέχει πολλές παραμέτρους.
5. Fragment
Και τέλος — #part-1 — ονομάζεται fragment, θραύσμα.
Χρησιμοποιείται συχνά από το πρόγραμμα περιήγησης για τη μετάβαση σε ένα συγκεκριμένο σημείο μέσα σε ένα ήδη ληφθέν έγγραφο ή σε μια κατάσταση της εφαρμογής.
Και εδώ υπάρχει μια ενδιαφέρουσα λεπτομέρεια:
το fragment μετά το `#` συνήθως δεν αποστέλλεται στον διακομιστή ιστού ως μέρος του αιτήματος HTTP.
Το επεξεργάζεται το ίδιο το πρόγραμμα περιήγησης ή ο κώδικας της σελίδας.
Το URL είναι μια οδηγία, όχι ο ίδιος ο ιστότοπος
Είναι χρήσιμο να διαχωρίσουμε το URL και τη web page.
Το URL λέει στο πρόγραμμα περιήγησης:
τι και από πού πρέπει να προσπαθήσει να λάβει.
Ενώ το περιεχόμενο πρέπει ακόμα να φορτωθεί.
Είναι κάπως σαν τη διεύθυνση ενός εστιατορίου:
η διεύθυνση δεν είναι το δείπνο.
Αν και μερικές φορές η αναμονή μιας σελίδας σε κακή σύνδεση μοιάζει περίπου εξίσου μεγάλη.
Τι κάνει πρώτα το πρόγραμμα περιήγησης
Μετά το Enter, το πρόγραμμα περιήγησης αναλύει τη διεύθυνση που πληκτρολογήθηκε.
Χρειάζεται να κατανοήσει: ποιο scheme χρησιμοποιείται· ποιο όνομα υπηρεσίας έχει καθοριστεί· ποιος πόρος ζητείται· αν υπάρχει μη τυπική port· αν υπάρχουν παράμετροι και fragment.
Δηλαδή, πρώτα το πρόγραμμα περιήγησης μετατρέπει τη συμβολοσειρά του χρήστη σε μια δομή κατανοητή για αυτό.
Και πού είναι η θύρα;
Στο URL μπορεί κανείς να την γράψει ρητά.
Για παράδειγμα: https://example.com:8443/.
Εδώ το 8443 είναι ο αριθμός της θύρας.
Ήδη γνωρίζουμε από το προηγούμενο μάθημα:
το IP βοηθά να βρεθεί ο κόμβος δικτύου, ενώ η θύρα — η απαιτούμενη υπηρεσία δικτύου.
Όμως συνήθως ο χρήστης δεν γράφει την τυπική θύρα χειροκίνητα.
Για το HTTPS, το πρόγραμμα περιήγησης γνωρίζει την τυπική τιμή TCP 443, εφόσον το πρωτόκολλο και η κατάσταση δεν απαιτούν διαφορετικό μηχανισμό μεταφοράς.
Το σύγχρονο Web μπορεί επίσης να χρησιμοποιεί HTTP/3 πάνω από QUIC/UDP, γι' αυτό δεν αξίζει να μετατρέψουμε τον κανόνα:
HTTPS = πάντα μόνο TCP/443
σε νόμο της φύσης.
Τώρα το πρόγραμμα περιήγησης χρειάζεται μια διεύθυνση δικτύου
Η Emma γνωρίζει το example.com.
Όμως οι δρομολογητές δεν λειτουργούν με το ανθρώπινο όνομα του ιστότοπου σαν να ήταν ταχυδρομική πινακίδα.
Χρειάζονται διευθυνσιοδότηση δικτύου.
Γι' αυτό το πρόγραμμα περιήγησης χρειάζεται να μάθει:
ποια διεύθυνση IP ή διευθύνσεις σχετίζονται με αυτό το όνομα;
Απλοποιημένα: example.com → ? → 203.0.113.20.
Αυτό το πρόβλημα το λύνει το DNS.
Όμως προς το παρόν δεν θα αποκαλύψουμε ολόκληρη τη δομή.
Για το τρέχον μάθημα αρκεί:
το DNS βοηθά να ληφθεί η πληροφορία δικτύου που σχετίζεται με το όνομα τομέα.
Λεπτομερώς — στο επόμενο μάθημα.
Και μάλιστα η απάντηση μπορεί να μην είναι μία
Το όνομα του ιστότοπου δεν είναι υποχρεωμένο να δείχνει σε έναν και μοναδικό διακομιστή.
Το DNS μπορεί να οδηγήσει τον χρήστη σε: έναν από πολλούς διακομιστές· ένα CDN· έναν εξισορροπητή φορτίου (load balancer)· υποδομή επιλεγμένη για συγκεκριμένη περιοχή.
Γι' αυτό το σχήμα:
example.com = ένα φυσικό μηχάνημα
είναι συχνά λανθασμένο.
Το πρόγραμμα περιήγησης έλαβε τη διεύθυνση. Τι ακολουθεί;
Ας υποθέσουμε ότι διαπιστώθηκε: example.com → 203.0.113.20.
Τώρα το πρόγραμμα περιήγησης χρειάζεται να δημιουργήσει ανταλλαγή δικτύου με την απαιτούμενη υπηρεσία.
Ξεκινά η ήδη γνωστή αλυσίδα: Browser → λειτουργικό σύστημα → τοπικό δίκτυο → router → ISP → Internet → δίκτυο του διακομιστή.
Δηλαδή το Web δεν χρησιμοποιεί κάποιο ξεχωριστό μαγικό Internet.
Λειτουργεί πάνω στην ίδια υποδομή δικτύου που μόλις μελετήσαμε.
Πρώτα η μεταφορά
Το πρόγραμμα περιήγησης χρειάζεται να οργανώσει την ανταλλαγή μεταφοράς με τον διακομιστή.
Ανάλογα με την έκδοση HTTP που χρησιμοποιείται και τις διαθέσιμες δυνατότητες, αυτό μπορεί να γίνεται, για παράδειγμα, μέσω TCP ή QUIC πάνω από UDP.
Είμαστε ήδη εξοικειωμένοι και με τις δύο βασικές προσεγγίσεις.
Αν χρησιμοποιείται TCP
Εννοιολογικά: Browser → TCP connection → Server.
Τα δύο μέρη δημιουργούν σύνδεση TCP.
Έχουμε ήδη δει: SYN → SYN-ACK → ACK.
Μετά από αυτό υπάρχει ένα κανάλι μεταφοράς για την περαιτέρω ανταλλαγή.
Όμως το HTTPS απαιτεί ακόμα ένα βήμα
Αν το URL ξεκινά με https://, το πρόγραμμα περιήγησης δεν πρέπει απλώς να αρχίσει να μεταδίδει δεδομένα ιστού σε ανοιχτή μορφή.
Πριν από τη συνήθη ανταλλαγή HTTP είναι απαραίτητο να δημιουργηθεί μια προστατευμένη σύνδεση.
Εδώ εμφανίζεται το TLS.
Προς το παρόν ας συγκρατήσουμε τρία καθήκοντα: να προστατεύσει το περιεχόμενο της ανταλλαγής από την ανάγνωση από τρίτους στη διαδρομή· να ανιχνεύει μη επιτρεπτή τροποποίηση των προστατευόμενων δεδομένων· να βοηθήσει το πρόγραμμα περιήγησης να επαληθεύσει τη γνησιότητα του διακομιστή με τη βοήθεια πιστοποιητικών.
Πώς ακριβώς συμβαίνει αυτό — είναι ξεχωριστό μεγάλο θέμα του Μαθήματος 12.
Το πιστοποιητικό εμφανίζεται πριν από τη σελίδα
Είναι χρήσιμο να το κατανοήσουμε εκ των προτέρων.
Πρώτα το πρόγραμμα περιήγησης δημιουργεί την προστατευμένη επικοινωνία και ελέγχει τις απαραίτητες κρυπτογραφικές παραμέτρους.
Και μόνο έπειτα, μέσα στην προστατευμένη σύνδεση, αποστέλλεται το συνηθισμένο αίτημα ιστού.
Απλοποιημένα: TCP / QUIC → TLS / προστατευμένη σύνδεση → HTTP.
Τα πραγματικά σύγχρονα πρωτόκολλα είναι λίγο πιο περίπλοκα, ειδικά το HTTP/3, όμως για το πρώτο μοντέλο αυτό αρκεί.
Τώρα μπορεί να σταλεί το αίτημα HTTP
Το πρόγραμμα περιήγησης θέλει να λάβει το /course/lesson?id=10.
Διαμορφώνει το αίτημα.
Εννοιολογικά: GET /course/lesson?id=10 — και προσθέτει άλλη απαραίτητη βοηθητική πληροφορία.
Για παράδειγμα, είναι σημαντικό για τον διακομιστή να καταλαβαίνει σε ποιο όνομα host αναφέρεται το αίτημα.
Τι είναι το HTTP
Το βασικό μοντέλο είναι πολύ κατανοητό: ο πελάτης στέλνει αίτημα στον διακομιστή, και ο διακομιστής επιστρέφει απάντηση στον πελάτη.
Το πρόγραμμα περιήγησης ζητά τον πόρο.
Ο διακομιστής απαντά.
Το HTTP και το HTTPS δεν είναι δύο εντελώς διαφορετικά Web
Αυτή είναι μια σημαντική διαφορά.
Το HTTP καθορίζει:
πώς είναι δομημένη η ανταλλαγή αιτημάτων και απαντήσεων στο web.
Το HTTPS σημαίνει τη χρήση του HTTP με κρυπτογραφική προστασία της σύνδεσης.
Απλοποιημένα: HTTP + TLS = HTTPS.
Αυτός είναι ένας σκόπιμα απλοποιημένος τύπος, όμως βοηθά να διαχωριστούν οι ρόλοι.
Ο διακομιστής λαμβάνει το αίτημα
Το αίτημα φτάνει στην υποδομή της υπηρεσίας.
Μπορεί να είναι πολύ απλή: Browser → Web Server.
Ή περίπλοκη: Browser → Load Balancer → Web Server → Application → Database.
Η Emma συνήθως δεν το βλέπει αυτό.
Για εκείνη το αποτέλεσμα είναι ένα:
το πρόγραμμα περιήγησης περιμένει απάντηση.
Τι μπορεί να επιστρέψει ο διακομιστής
Για παράδειγμα, HTML.
Όμως η απάντηση περιέχει επίσης βοηθητική πληροφορία: κατάσταση (status)· τύπο περιεχομένου· κανόνες προσωρινής αποθήκευσης (caching)· cookies· άλλα HTTP headers.
Τη λεπτομερή δομή των αιτημάτων και απαντήσεων HTTP θα την αναλύσουμε στα επόμενα μέρη.
Η σελίδα δεν είναι ακόμα έτοιμη
Έχοντας λάβει το πρώτο HTML, το πρόγραμμα περιήγησης συχνά ανακαλύπτει μέσα του συνδέσμους προς πρόσθετους πόρους: CSS, JavaScript, images, fonts, other data.
Και αρχίζει να τους φορτώνει.
Γι' αυτό μία ανοιχτή σελίδα μπορεί να προκαλέσει:
δεκάδες ή εκατοντάδες ξεχωριστά αιτήματα δικτύου.
Για παράδειγμα
Η πρώτη απάντηση — index.html — περιέχει τα styles.css, app.js, logo.svg, avatar.jpg.
Τότε το πρόγραμμα περιήγησης κάνει νέα αιτήματα: GET styles.css, GET app.js, GET logo.svg, GET avatar.jpg.
Μάλιστα οι πόροι δεν είναι υποχρεωμένοι να βρίσκονται στον ίδιο διακομιστή.
- 1index.html — η πρώτη απάντηση του διακομιστή, το αρχικό σημείο της σελίδας.
- 2styles.css — στυλ εμφάνισης, ξεχωριστό αίτημα.
- 3app.js — κώδικας της εφαρμογής, ξεχωριστό αίτημα.
- 4logo.svg και avatar.jpg — εικόνες, επίσης ξεχωριστά αιτήματα.
- 5API data — δεδομένα που η σελίδα μπορεί να ζητήσει επιπλέον, συχνά από διαφορετικό όνομα host.
- 6www.example.com, api.example.com, cdn.example.net — οι πόροι μιας σελίδας δεν είναι υποχρεωμένοι να προέρχονται από την ίδια υπηρεσία.
Ένας ιστότοπος μπορεί να απευθύνεται σε πολλά συστήματα
Για παράδειγμα, το www.example.com μπορεί να φορτώσει δεδομένα από το api.example.com, εικόνες από το cdn.example.net, και επιπλέον να απευθυνθεί σε μια υπηρεσία τρίτου μέρους.
Γι' αυτό η φράση:
«Άνοιξα έναν ιστότοπο»
δεν σημαίνει:
«Το πρόγραμμα περιήγησής μου δημιούργησε ακριβώς μία σύνδεση δικτύου με έναν υπολογιστή».
Το πρόγραμμα περιήγησης αρχίζει να χτίζει τη σελίδα
Αφού λάβει το HTML, το πρόγραμμα περιήγησης αναλύει τη δομή του.
Στη συνέχεια: εφαρμόζει το CSS· εκτελεί το απαραίτητο JavaScript· φορτώνει πρόσθετους πόρους· υπολογίζει τη διάταξη των στοιχείων· σχεδιάζει το αποτέλεσμα στην οθόνη.
Δηλαδή η διαδρομή δεν τελειώνει στο:
«ο διακομιστής έστειλε HTML».
Το πρόγραμμα περιήγησης χρειάζεται ακόμα να μετατρέψει τα ληφθέντα δεδομένα σε διεπαφή.
Η ιστοσελίδα είναι αποτέλεσμα της εργασίας δύο πλευρών
Στον διακομιστή μπορεί να εκτελείται: επιχειρησιακή λογική· εργασία με τη βάση δεδομένων· ταυτοποίηση (authentication)· διαμόρφωση της απάντησης.
Στο πρόγραμμα περιήγησης: απεικόνιση του HTML· εφαρμογή του CSS· εκτέλεση JavaScript· αλληλεπίδραση με τον χρήστη.
Γι' αυτό το σύγχρονο Web δεν είναι απλώς:
«ο διακομιστής έστειλε μια έτοιμη εικόνα της σελίδας».
Και μερικές φορές μέρος των δεδομένων υπάρχει ήδη τοπικά
Το πρόγραμμα περιήγησης μπορεί να αποθηκεύει ορισμένους πόρους που έχουν ήδη φορτωθεί σε cache, προσωρινή μνήμη.
Αυτό επιτρέπει να μη φορτώνεται το ίδιο πράγμα κάθε φορά από την αρχή.
Για παράδειγμα, το logo.svg μπορεί να βρίσκεται ήδη στη συσκευή.
Όμως και η κρυφή μνήμη υπακούει σε κανόνες
Το πρόγραμμα περιήγησης δεν πρέπει απλώς να αποφασίσει:
«Μου αρέσει η έκδοση του ιστότοπου από την Τρίτη, θα την κρατήσω για πάντα».
Ο διακομιστής μπορεί να γνωστοποιεί: για πόσο καιρό επιτρέπεται να χρησιμοποιείται ο πόρος· αν χρειάζεται να ελεγχθεί η επικαιρότητά του· αν πρέπει καν να αποθηκεύεται προσωρινά.
Η προσωρινή αποθήκευση (caching) είναι ξεχωριστός μηχανισμός του Web, όχι κουμπαράς τυχαίων παλιών αρχείων.
Και επιπλέον υπάρχουν τα cookies
Κατά την ανταλλαγή στο web θα συναντήσετε συχνά cookies.
Τα cookies μπορούν να χρησιμοποιηθούν, για παράδειγμα, για: sessions· ρυθμίσεις· άλλες λειτουργίες της εφαρμογής.
Όμως:
cookie ≠ απαραίτητα κωδικός πρόσβασης
και:
cookie ≠ απαραίτητα διαφήμιση.
Ο σκοπός εξαρτάται από τον συγκεκριμένο ιστότοπο και το cookie.
Τα sessions και την ασφάλεια των cookies θα τα αναλύσουμε λεπτομερώς αργότερα.
Ολόκληρη η αλυσίδα σε ένα σχήμα
Η Emma πληκτρολογεί https://example.com/course.
Στη συνέχεια εννοιολογικά: Browser parses URL → μαθαίνει τη διεύθυνση δικτύου → δημιουργεί transport connection → δημιουργεί προστατευμένη σύνδεση HTTPS → στέλνει HTTP request → server processes request → HTTP response → το Browser λαμβάνει HTML → φορτώνει πρόσθετους πόρους → χτίζει και εμφανίζει τη σελίδα.
Ακριβώς αυτή την αλυσίδα θα την αποκαλύπτουμε σταδιακά στο Μάθημα 10.
- 1URL — η Emma πληκτρολογεί τη διεύθυνση και πατάει Enter.
- 2Name resolution — το πρόγραμμα περιήγησης μαθαίνει τη διεύθυνση δικτύου που σχετίζεται με το όνομα του ιστότοπου.
- 3IP address — βρέθηκε η απαιτούμενη διεύθυνση δικτύου προορισμού.
- 4TCP / QUIC — δημιουργείται η σύνδεση μεταφοράς.
- 5TLS — δημιουργείται κρυπτογραφικά προστατευμένη σύνδεση για το HTTPS.
- 6HTTP request — το πρόγραμμα περιήγησης στέλνει αίτημα για τον απαιτούμενο πόρο.
- 7HTTP response — ο διακομιστής επεξεργάζεται το αίτημα και επιστρέφει απάντηση.
- 8HTML + CSS + JavaScript + media — το πρόγραμμα περιήγησης λαμβάνει το κύριο έγγραφο και πρόσθετους πόρους.
- 9Rendered page — το πρόγραμμα περιήγησης χτίζει και εμφανίζει την έτοιμη σελίδα.
Γιατί αυτό είναι σημαντικό για την ασφάλεια
Τώρα πια είναι φανερό ότι η φράση:
«Άνοιξα τον ιστότοπο»
κρύβει πολλές ξεχωριστές αποφάσεις.
Για παράδειγμα: ποιο όνομα τομέα χρησιμοποιήθηκε· ποια IP βρέθηκε· με ποιον διακομιστή δημιουργήθηκε η σύνδεση· αν έγινε επιτυχώς ο έλεγχος του πιστοποιητικού· ποια απάντηση HTTP ελήφθη· ποιοι πρόσθετοι πόροι φορτώθηκαν.
Ένας ιστότοπος phishing είναι επίσης ικανός να: έχει όμορφο σχεδιασμό· χρησιμοποιεί HTTPS· φορτώνεται πολύ γρήγορα.
Γι' αυτό η ασφάλεια δεν μπορεί να αξιολογείται μόνο από το ότι:
«η σελίδα άνοιξε κανονικά».
Το λουκέτο δεν είναι ακόμα σημάδι καλών προθέσεων
Αν το πρόγραμμα περιήγησης δημιούργησε μια σωστή σύνδεση HTTPS, αυτό σημαίνει σημαντικά πράγματα για την προστασία της σύνδεσης με τον καθορισμένο ιστότοπο.
Όμως αυτό δεν σημαίνει:
ότι ο ιδιοκτήτης του ιστότοπου είναι έντιμος.
Ένας δόλιος ιστότοπος μπορεί επίσης να αποκτήσει ένα έγκυρο πιστοποιητικό TLS για τον δικό του τομέα.
Γι' αυτό αργότερα θα μάθουμε να ελέγχουμε ξεχωριστά: τον τομέα· το HTTPS· το πιστοποιητικό· τον ίδιο τον πόρο.
Το βασικό που πρέπει να θυμόμαστε
- Μετά την εισαγωγή της διεύθυνσης, το πρόγραμμα περιήγησης εκτελεί πολλές διαδοχικές ενέργειες.
- Το URL περιγράφει τον πόρο και τον τρόπο πρόσβασης σε αυτόν.
- Το URL μπορεί να περιέχει scheme, hostname, path, query, port και fragment.
- Το fragment μετά το `#` συνήθως το επεξεργάζεται το πρόγραμμα περιήγησης και δεν μεταδίδεται στον διακομιστή ως μέρος του αιτήματος HTTP.
- Για τη σύνδεση δικτύου, το πρόγραμμα περιήγησης χρειάζεται να λάβει τη διεύθυνση δικτύου που σχετίζεται με το όνομα του ιστότοπου.
- Αυτό το πρόβλημα βοηθά να λυθεί το DNS.
- Στη συνέχεια δημιουργείται η επικοινωνία μεταφοράς, για παράδειγμα TCP ή QUIC.
- Για το HTTPS δημιουργείται μια κρυπτογραφικά προστατευμένη σύνδεση.
- Το HTTP χρησιμοποιείται για την ανταλλαγή αιτημάτων και απαντήσεων.
- Η λήψη του πρώτου HTML συνήθως δεν ολοκληρώνει τη φόρτωση της σελίδας.
- Το πρόγραμμα περιήγησης μπορεί επιπλέον να φορτώνει CSS, JavaScript, εικόνες και άλλους πόρους.
- Ένας ιστότοπος μπορεί να απευθύνεται ταυτόχρονα σε πολλές υπηρεσίες δικτύου.
- Η κρυφή μνήμη επιτρέπει την επαναχρησιμοποίηση ορισμένων πόρων.
- Τα cookies επιτρέπουν στο πρόγραμμα περιήγησης να αποθηκεύει και να μεταδίδει ορισμένα δεδομένα του ιστότοπου.
- Η ύπαρξη HTTPS δεν αποτελεί απόδειξη της καλής πίστης του ίδιου του ιστότοπου.
Τι ακολουθεί
Πληκτρολογήσαμε https://example.com, όμως το πρόγραμμα περιήγησης χρειάζεται τη διεύθυνση IP.
Η ίδια η Emma δεν την πληκτρολόγησε.
Άρα, κάπου πρέπει να υπάρχει ένας μηχανισμός που απαντά στο ερώτημα:
«Ποια διεύθυνση δικτύου σχετίζεται με αυτό το όνομα;»
Στο πλαίσιο του τρέχοντος μαθήματος δεν θα διδάξουμε ξανά πλήρως το DNS — σε αυτό είναι αφιερωμένο το επόμενο ξεχωριστό μάθημα.
Τώρα θα αναλύσουμε ακριβώς τον ρόλο του στη διαδικασία ανοίγματος της σελίδας.
Συνεχίζουμε — στο επόμενο μέρος — «Πώς το πρόγραμμα περιήγησης βρίσκει τον διακομιστή».
- Αφού εισαχθεί η διεύθυνση, το πρόγραμμα περιήγησης εκτελεί πολλές διαδοχικές ενέργειες.
- Το URL περιγράφει έναν πόρο και τον τρόπο πρόσβασης σε αυτόν.
- Το URL μπορεί να περιέχει scheme, hostname, path, query, θύρα και fragment.
- Το fragment μετά το # συνήθως το διαχειρίζεται το πρόγραμμα περιήγησης και δεν αποστέλλεται στον server ως μέρος του αιτήματος HTTP.
- Για τη δικτυακή σύνδεση, το πρόγραμμα περιήγησης χρειάζεται να λάβει τη δικτυακή διεύθυνση που συνδέεται με το όνομα του ιστότοπου.
- Το DNS βοηθά σε αυτό.
- Στη συνέχεια καθιερώνεται μια σύνδεση μεταφοράς, όπως TCP ή QUIC.
- Για το HTTPS δημιουργείται μια κρυπτογραφικά προστατευμένη σύνδεση.
- Το HTTP χρησιμοποιείται για την ανταλλαγή αιτημάτων και απαντήσεων.
- Η λήψη του πρώτου HTML συνήθως δεν ολοκληρώνει τη φόρτωση της σελίδας.
- Το πρόγραμμα περιήγησης μπορεί να φορτώσει επιπλέον CSS, JavaScript, εικόνες και άλλους πόρους.
- Ένας ιστότοπος μπορεί να απευθύνεται ταυτόχρονα σε πολλές δικτυακές υπηρεσίες.
- Η cache επιτρέπει την επαναχρησιμοποίηση ορισμένων πόρων.
- Τα cookies επιτρέπουν στο πρόγραμμα περιήγησης να αποθηκεύει και να στέλνει ορισμένα δεδομένα του ιστότοπου.
- Η ύπαρξη HTTPS δεν αποδεικνύει ότι ο ίδιος ο ιστότοπος είναι αξιόπιστος.