Представьте простую ситуацию, когда веб-приложение электронной коммерции вызывает конечную точку API, которая возвращает информацию о заказе клиента. На уровне приложения это выглядит довольно простой операцией. Но под капотом происходит многое. Во-первых, клиент запрашивает DNS для получения IP-адреса, связанного с конечной точкой API. DNS может вернуть адрес балансировщика нагрузки, а не адрес конкретного сервера приложений. Затем операционная система определяет, как пакеты должны быть отправлены на этот IP-адрес. Он может выбрать отправку через локальную сеть, провайдера интернет-услуг (ISP) или несколько других маршрутизаторов. Конечная цель — чтобы пакеты данных достигли сети назначения. Наиболее распространенным протоколом для этого является HTTP. Однако перед отправкой запроса HTTP клиенту обычно необходимо установить соединение с сервером назначения. С традиционным HTTPS это означает установку TCP-соединения. В этом типе соединения клиент и сервер выполняют рукопожатие, обмениваясь некоторыми начальными пакетами, чтобы обе стороны знали, что соединение установлено. Затем клиент и сервер выполняют рукопожатие TLS. Только после этого запрос HTTP может быть безопасно отправлен. Балансировщик нагрузки его принимает, выбирает здоровый экземпляр приложения и перенаправляет запрос. Приложение выполняет свою работу и отправляет ответ обратно по тому же пути. Все это относится к области сетей. Из-за его повсеместности сети становятся чрезвычайно важной дисциплиной для разработчиков.