Какую оптимизацию можно сделать, введя URL

сервер JavaScript браузер DNS

Длинная статья, разберитесь в роли мер по оптимизации.

Главное в этой статье — как сделать так, чтобы пользователи быстрее увидели первую экранную страницу, а основные влияющие факторы — задержка и трудоемкость парсинга и рендеринга. Часть безопасности на самом деле является частью оптимизации. Сосредоточимся на сетевой части.

Общий процесс: разрешение доменного имени DNS, установление TCP-соединения, загрузка ресурсов и разрешение страницы. Оптимизацию, описанную в статье, попытаемся ограничить текущим процессом анализа.

1. Разрешение доменного имени DNS

Вообще говоря, URL-адрес, который мы вводим, является доменным именем, и для идентификации объекта TCP/IP использует IP-адрес для уникальной идентификации подключения хоста к Интернету, а DNS поможет нам завершить сопоставление доменного имени с IP-адресом. работай. кwww.aaa.comНапример, процесс парсинга выглядит примерно так:

Обработать

  • Браузер

    • Браузер запрашивает кеш браузера, нет.

  • собственный слой

    • Клиент браузера запрашивает у системы IP-адрес сервера, вызывает программу разрешения DNS на машине и проверяет, имеет ли его локальный файл hosts это отношение сопоставления доменных имен, и нет.
    • Посмотрел собственный кеш преобразователя DNS, нет.

  • кеш маршрутизатора

    • Также может быть слой кэша маршрутизатора.

  • локальный DNS-сервер

    • Программа локального разрешения DNS инициирует запрос к локальному DNS-серверу, который обычно является предпочтительным DNS-сервером, установленным в параметрах TCP/IP.Он знает IP-адрес и обычно использует протокол UDP.
    • Запрос локального DNS-сервера находится в файле локальной зоны, №.
    • Локальный DNS-сервер запрашивает DNS-кеш на наличие, нет.
    • Локальный DNS-сервер будет определять, отправлять ли запрос на DNS-сервер верхнего уровня (правила разрешения те же) или напрямую на корневой DNS-сервер (зная IP-адрес корневого DNS-сервера) в зависимости от того, является ли сервер пересылки задавать.

  • с DNS-сервером

    • При получении запроса корневой DNS-сервер не разрешает адреса напрямую, но знает адрес одного сервера в каждом домене верхнего уровня (например,comсервер доменных имен). В режиме итеративного запроса IP-адрес этого DNS-сервера домена верхнего уровня возвращается на локальный DNS-сервер.
    • После того, как локальный DNS-сервер извлечет информацию о DNS-сервере домена верхнего уровня, он отправит ему запрос. После того, как DNS-сервер домена верхнего уровня получит запрос, он сначала запросит свой собственный кеш, если нет, то он будет отвечать за сервер доменных имен второго уровня (например,aaa.comсервера доменных имен) на локальный DNS-сервер и так далее, пока не будет найдена информация о сопоставлении целевого доменного имени или запрос не завершится ошибкой.
    • После того, как информация о сопоставлении найдена, она возвращается на локальный компьютер, а промежуточные слои кэшируются.

  • режим запроса:

    • Рекурсивный метод: проверить полностью, не возвращая информацию, и возвращать информацию только после получения окончательного результата.
    • Итеративный метод: это метод прямого запроса между указанным выше локальным DNS-сервером и другими серверами доменных имен, который находит адрес сервера, который может быть известен, возвращает этот адрес и повторно отправляет запрос на разрешение.
    • Общий метод по умолчанию — рекурсия с локального компьютера на локальный DNS-сервер и итеративный запрос между DNS-серверами.

оптимизация

Конечно, оптимизация под DNS заключается в сокращении времени разрешения DNS, в связи с наличием механизма кеширования браузера нам нужно оптимизировать только первое посещение (хотя мы сейчас только запрашиваем html-файл, но все равно будет в html-файле, который мы хотим запросить позже css/js/img и т. д.), то есть соответствующим образом уменьшить количество доменных имен, подлежащих разрешению, с учетомДругие механизмы оптимизацииВы можете публиковать страницы и внутристраничные ресурсы на 2-4 доменных имени.

2. Установите соединение

TCP-соединение

Что ж, браузер, наконец, получил IP-адрес сервера, клиент хочет общаться с сервером и передавать сообщения между ними, необходимо открыть соединение TCP (протокол транспортного уровня).

Обработать

  • Клиент создает сокет и отправляет запрос на установление соединения на целевой порт сервера.Сегмент данных содержит битовый код SYN (флаг установления соединения) = 1, случайный номер seq (порядковый номер) = x и другие флаги и параметры TCP.
  • На сервере есть приветственный сокет, предназначенный для обработки запросов на соединение.После получения запроса на установление соединения, установленный код SYN и ACK (флаг подтверждения) равны 1, ack (номер подтверждения) = x + 1, последовательность случайных чисел = y и возврат .
  • Клиент проверяет, равен ли ack x + 1. Если он равен, он устанавливает ACK в 1, SYN в 0 и ack в y + 1 для отправки на сервер.
  • После того, как приветственный сокет проверит, что ack равен y + 1, а ACK равен 1, создается новый сокет, который идентифицируется исходным IP-адресом/портом источника, IP-адресом назначения/портом назначения, а затем данными, отправленными клиент направляется в этот новый сокет. В этот момент устанавливается TCP-соединение.

просто говоря:

// client: 
send({SYN: 1, seq: x, ...others})
                    |
                    ↓
//server: 
send({SYN: 1, ACK: 1, ack: x + 1, seq: y, ...others})
                    |
                    ↓
//client: 
ack === x + 1 ? send({ACK: 1, SYN: 0, ack: y + 1, ...others}) : 'hehe'
                    |
                    ↓
//server: 
ack === y + 1 && ACK === 1 ? new Socket() : ''

SSL/TLS

Если HTTPS включен для шифрования, перед использованием TLS необходимо согласовать зашифрованный канал.

Обработать

  • Клиент: после установления TCP-соединения некоторые спецификации и случайные числа отправляются в виде обычного текста.Random1, версия протокола TLS, список поддерживаемых наборов шифров, другие поддерживаемые или желательные параметры TLS.
  • сервер:
    1. Получите версию протокола TLS для будущего взаимодействия, выберите один из наборов шифров, предоставленных клиентом, и сгенерируйте случайное число.Random2отправлено клиенту;
    2. Прикрепите собственный сертификат и отправьте ответ клиенту;
    3. В то же время также может быть отправлен запрос с просьбой предоставить клиенту сертификат и другие параметры расширения TLS.
  • Клиент:
    1. То же самое, может отправить свой собственный сертификат на сервер.
    2. После того, как клиент получает сертификат сервера, он проверяет действительность сертификата от корневого ЦС (органа, выдавшего сертификат) через отношение цепочки сертификатов.После прохождения проверки он извлекает открытый ключ сервера из сертификата, генерирует случайный номер Random3 и шифрует его открытым ключом сервера.Random3(предмастер-ключ), отправленный на сервер;
    3. Скажите серверу начать шифрование прозрачного письма;
    4. Для клиента三个随机数а также约定的加密方法генерировать对话密钥. Создайте сводку о завершении из информации о предыдущем рукопожатии, используйте对话密钥Зашифровать, отправить, чтобы сообщить серверу, что я сделал рукопожатие.
    • За исключением одноразового номера, зашифрованного открытым ключом, и дайджеста, зашифрованного сеансовым ключом, все остальные данные отправляются в виде открытого текста.
  • сервер:
    • Расшифруйте случайное число, отправленное клиентом с помощью закрытого ключа, проверьте целостность сообщения, проверив MAC-адрес сообщения, и сгенерируйте его таким же образом.对话密钥.
    • Расшифруйте сообщение о завершении, отправленное клиентом, и проверьте对话密钥это правильно или нет.
    1. Скажите клиенту начать шифрование;
    2. Клиенту снова возвращается зашифрованное сообщение о завершении.
  • Клиент использует ранее сгенерированный对话密钥Расшифровать сообщение, ОК对话密钥是否正确, если правильно, канал устанавливается и данные приложения отправляются.

в:

  • 对话密钥также известен как协商密钥.
  • 对话密钥даСимметричный ключ, симметричное шифрование и скорость дешифрования очень высоки.
  • Открытый ключ сервера и закрытый ключ являются асимметричными ключами, а скорость асимметричного шифрования и дешифрования очень низкая.
  • Используйте асимметричное шифрование для создания надежныхСимметричный ключ, используя симметричный ключ для последующего шифрования данных.
  • Вышеупомянутые пакеты с порядковыми номерами могут быть отправлены за один раз или могут быть отправлены непрерывно поэтапно.
  • SSL и TLS можно рассматривать как одно целое.
  • Сервер также может использовать свой собственный сертификат вместо сертификата, выданного ЦС.

оптимизация

Мы хотим оптимизировать время рукопожатия TCP и SSL/TLS. Есть несколько факторов:

  • Задержка передачи данных туда и обратно: в основном зависит от географического положения, использование более близкого сервера для передачи данных сократит время передачи данных туда и обратно, мы можем развернуть серверы в разных регионах (например: CDN, который также будет использовать разрешение DNS, возможно, в DNS На этапе синтаксического анализа выполняется сопоставление имени домена доступа клиента с ближайшим сервером.Близкое расположение данных к клиенту может сократить время передачи данных по сети.
  • Цепочка сертификатов. На самом деле, оптимизация задержки передачи данных в оба конца предназначена не только для этапа рукопожатия TCP, но также выигрывает от последующей передачи данных на основе TCP, такой как рукопожатие SSL/TLS и последующие ответы на запросы. Тогда цепочка сертификатов является важным фактором, влияющим на рукопожатие SSL/TLS.Цепочка сертификатов — это информация в сертификате, отправляемая сервером клиенту.корневой сертификатСостав (сравнение аналогично отношениям между серверами разрешения доменных имен DNS).
    • причина:
      1. Медленный старт TCP: из-за медленного старта TCP (во избежание перегрузки TCP-соединение может сначала отправить меньше пакетов, затем дождаться подтверждения клиента, затем удвоить, после нескольких круговых обходов, пока не будет достигнуто пороговое значение) и отправка данных рукопожатия TLS/SSL Как правило, в фазе медленного запуска TCP-соединения слишком много данных сертификата превысит начальное значение TCP-соединения, что удвоит количество циклов передачи данных.
      2. Проверка цепочки сертификатов слишком длинная: когда клиентский браузер проверяет надежность сертификата, он рекурсивно проверяет каждый узел в цепочке на корневой сертификат, что также увеличивает время рукопожатия.
    • метод:
      1. Сократите количество промежуточных центров сертификации, выбрав только сертификаты сайта и один промежуточный центр сертификации.
      2. Не добавляйте информацию о корневом сертификате, во встроенном списке доверия браузера есть корневой сертификат.
  • Количество рукопожатий: первые две оптимизации предназначены для оптимизации времени рукопожатия, и количество рукопожатий также является важным фактором, влияющим на задержку. Мы поговорим об этом позже, когда будем говорить о запросах большого объема.
  • Начальное окно перегрузки: Правильно увеличьте начальный размер окна перегрузки, то есть увеличьте начальный размер пакета, который может отправить соединение TCP.

3. Получите ответ страницы

перенаправить ответ

Если сервер возвращает перенаправление перехода (перенаправление без кеша), то браузер повторно перейдет на новый URL-адрес.разрешение DNSа такжеустановить соединение. Поэтому следует избегать ненужных перенаправлений.

ответ ресурса страницы

После получения html-ответа браузер начинает парсить страницу и вступает в стадию подготовки к рендерингу. Оптимизация загрузки также обсуждается позже, когда мы говорим о большом объеме запросов.

4. Разберите отображаемую страницу

Сначала нам нужно разделить этот процесс на две части.загрузка ресурсов страницыа такжеоказывать.

загрузка ресурсов страницы

В процессе парсинга страницы браузер будет запрашивать внешние ресурсы, такие как js, css, img и т. д. на странице.

4.1 Установление соединения

Точно так же для загрузки этих ресурсов также требуется установление TCP-соединения, а для прямого использования также требуется разрешение DNS и рукопожатие.

оптимизация

Количество и частота запросов здесь гораздо выше, чем при первом запросе ресурсов страницы, поэтому здесь мы сосредоточимся на оптимизации следующей партии запросов.

Большинство версий протокола HTTP, используемых в настоящее время браузерами, — это 1.1 и 2, которые несколько отличаются, но нижний уровень использует TCP для передачи данных. Поскольку рукопожатие TCP занимает много времени, а SSL/TLS требует больше времени, нам необходимо уменьшить количество и время, необходимое для установления соединений, которые необходимо установить в процессе загрузки.

  • Мультиплексирование: Лучший способ для HTTP 1.1 — включить длинные соединения: HTTP 1.1 по умолчанию предоставляет функцию включения длинных соединений По сравнению с короткими соединениями (каждый раз при запросе ресурса устанавливается TCP-соединение, а затем отключается), клиентский сокет (обзор. Сервер может открывать несколько портов для параллельных запросов) Последующие запросы к одному и тому же сокету (доменное имя + порт) будут мультиплексироваться с TCP-соединением для передачи до тех пор, пока TCP-соединение не будет закрыто.
  • Ускорение: существует механизм восстановления сеанса для рукопожатия SSL/TLS.После прохождения проверки можно напрямую использовать предыдущий ключ сеанса, чтобы сократить круговой путь рукопожатия.

4.2 Перед загрузкой

Когда сервер возвращает ответ, существует несколько ситуаций, таких как: сервер сильно загружен, сервер не работает, на запрос невозможно ответить своевременно или быстро, сервер географически слишком далеко или задержка очень высока среди операторов.

оптимизация

здесь сустановить соединениеЧасть оптимизации на самом деле общедоступна, но простое обычное установление соединения потребляет меньше ресурсов, поэтому мы объясним это здесь более подробно.

  • Повышенная пропускная способность. Но в большинстве случаев пропускная способность сервера не является основным фактором, влияющим на задержку.
  • Интеллектуальное разрешение DNS: в соответствии с IP-адресом клиента доменное имя разрешается в IP-адрес ближайшего сервера или сервера, не относящегося к другим операторам, что решает проблему географического положения и задержки между операторами.
  • CDN: Используйте определенный метод анализа, чтобы найти наиболее подходящий сервер статических ресурсов среди узловых серверов повсюду в соответствии с географическим положением, ситуацией нагрузки и соответствием ресурсов узлового сервера.
  • Балансировка нагрузки: используйте балансировку нагрузки DNS, балансировку нагрузки IP, балансировку нагрузки обратного прокси-сервера и т. д., чтобы выбрать наиболее подходящий сервер для обработки запросов от группы серверов (одинаковые обязанности в кластере) или группы серверов (распределенные обязанности).
  • Эти технологии могут сочетаться друг с другом, например, CDN будет использовать интеллектуальное разрешение DNS и балансировку нагрузки.
  • Среди них, если используется метод перенаправления, разрешение DNS и рукопожатие будут выполняться снова, и часть оптимизации фактически выполняется в части разрешения DNS доменного имени.

4.3 Начать загрузку

Что ж, наконец-то сервер может счастливо возвращать данные.

HTTP 1.1

Обработать

  • Хотя HTTP 1.1 имеет длинное соединение, TCP-соединение можно использовать для запроса нескольких ресурсов, но загрузка этих ресурсов является последовательной.Например, используя этот TCP-канал для запроса 1.css, 2.css и 1.js, передается только первоеуспешно завершеноЗатем будет следующая передача.
  • Хотя браузеры обычно запрашивают установление нескольких TCP-соединений (несколько портов запрашивают ресурсы с одного порта сервера, и для установления нового TCP-соединения будет выполняться новое рукопожатие), параллельный запрос ресурсов страницы увеличивает общую скорость загрузки. , но для каждого есть ограничение на количество параллельных подключений для каждого доменного имени (для защиты от нагрузки на сервер и ограничения портом хоста), поэтому нам все же нужно провести некоторые оптимизации.

оптимизация

  • уменьшать
    • Уменьшите общее количество запросов, которые необходимо инициировать на странице, таких как слияние кода, которое мы обычно используем, изображения спрайтов (изображения спрайтов / небольшие значки слияния спрайтов), преобразование изображений в base64 и запись в другие файлы, избегая пустого img src атрибуты и др.
    • Вырежьте и разделите данные, сначала загрузите данные, расположенные выше сгиба, и т. д.
  • Добавлено: увеличить доменные имена раздачи ресурсов, развернуть их под разными доменными именами и «прорваться» через лимит параллельных подключений браузера (в сочетании с частью DNS не так-то просто быть слишком рассеянным, и слишком много подключений будет делить полосу пропускания, и разрешение на мобильном терминале будет медленнее).

HTTP 2

Поскольку HTTP 2 обеспечивает функции мультиплексирования, основанные на передаче кадров и потоков двоичных данных, данные передаются через TCP-соединение.Рассеянная, неупорядоченная, параллельная передачаСтаньте реальностью, что все наши ресурсы могут передаваться параллельно без блокировки по одному TCP-соединению.
Поэтому мы просим уменьшить количество выполненных оптимизаций слияния HTTP 1.1, увеличение ресурсов распределенного домена становится недействительной оптимизацией, вы можете проиграть. В то же время из-за того, что файлы не объединяются, файлы обновлений нам не нужно изменять, один модуль разработки обновляет все (файлы слияния) модуля.

4.4 Загрузка

В целом это очень простой процесс, клиент получает ответ, возвращаемый серверным транспортом.

оптимизация

Чем меньше размер передаваемых данных, тем быстрее передача и меньше задержка.

  • меньше

    • Gzip: включение Gzip может сжать тело ответа, что может уменьшить объем данных на 70%.
    • Уменьшите количество файлов cookie: удалите ненужные файлы cookie и установите соответствующий срок действия.
    • Отказаться от файлов cookie: для запросов статических файлов мы можем обойтись без файлов cookie, то есть, как упоминалось в HTTP 1.1, они распространяются под другими доменными именами, а для поддоменов устанавливается разумный домен (область действия файлов cookie).
    • Сжатие заголовков: HTTP2 также предоставляет функцию сжатия заголовков, то есть через некоторые словари, совместно используемые обеими сторонами, информация заголовка (строка состояния, заголовок запроса/ответа) «отображается» в более короткие данные.
    • Изображение: используйте соответствующий размер и формат изображения, чтобы сохранить размер.

  • Кэш: Самый маленький к самому маленькому корпусу, конечно, не принимает передачу данных и использует локальный кеш. Как правило, это контролируется полем заголовка ответа, возвращенным сервером в последний раз.

    • Сильный кеш: Сильный кеш не отправляет запросы на сервер.
      • Истекает: поле http1.0, идентифицируемое по времени сервера.
      • Кэш-контроль: max-age=seconds, использовать время относительно запроса, не более этого времени, и напрямую использовать кеш. Есть другие значения.
    • Согласовать кеш:
      • Last-Modified/If-Modified-Since: время последней модификации ресурса в секундах. Клиент браузера отправляет поле If-Modified-Since, а сервер отвечает полем Last-Modified.
      • ETag/If-None-Match: идентификатор ресурса, клиент отправляет поле If-None-Match, сервер отвечает на поле ETag и сравнивает их, чтобы решить, возвращать ли перенаправление кеша или что-то еще. идентификатор сравнивает только содержимое и не заботится о ресурсе.

  • Разумное разделение ресурсов страницы, таких как внешние js и css, можно кэшировать независимо от html.

4.5 Закрыть TCP

После загрузки ресурса необходимо закрыть TCP-соединение. В этом абзаце нечего оптимизировать.

Обработать:

  • Клиент TCP отправляет FIN = 1 (флаг окончания) и случайную последовательность чисел = a, чтобы закрыть передачу данных от клиента к серверу.
  • Сервер получает этот запрос на закрытие и возвращает ACK = 1, ack = a + 1, а данные перед сервером, возможно, еще не были переданы.
  • После завершения передачи данных сервер отправляет клиенту FIN = 1 и случайное число seq = b.
  • Клиент возвращает ACK = 1, ack = b + 1 и ждет некоторое время, чтобы убедиться, что сервер не вернет запрос на повторную передачу, который не получил сообщения подтверждения, а затем закрывает соединение.
  • После того, как сервер получит подтверждающее сообщение, проверка закроет соединение.

Суммировать

HTTP2 работает отлично. Используйте кеш с умом.

рендеринг парсинга страницы

Описанная выше загрузка ресурсов происходит в процессе парсинга страницы. Итак, каков процесс парсинга и рендеринга страниц в браузере?

Обработать

В двух словах:

  • Обработка HTML-разметки, построение DOM-дерева.
  • Обработка разметки CSS, построение дерева CSSOM.
  • Объедините дерево DOM и дерево CSSOM в дерево рендеринга (игнорируя DOM, который не нуждается в рендеринге).
  • Компоновка основана на дереве рендеринга, и вычисляется геометрическая информация о каждом узле.
  • Рисует отдельные узлы на экране.
  • Когда в середине встречаются различные ресурсы, ресурсы будут загружены.

вопрос

  • Скачать
    • Блокировка рендеринга при загрузке css (кроме атрибута media).
    • При встрече тега script построение DOM останавливается, а управление передается js до тех пор, пока скрипт (загрузка) не будет выполнен, в это время браузер загрузит другие ресурсы с оптимизацией, но не будет их парсить. Если есть операция над CSSOM в js, она также проследит за тем, чтобы CSSOM был скачан и собран.
    • Загрузка ресурса изображения не будет заблокирована.
  • Redraw reflow приводит к повторной генерации дерева рендеринга.
    • Reflow (перекомпоновка): макет будет пересчитан, что обычно вызвано изменениями в структуре, добавлениями, удалениями, позициями и размерами элементов, например, после успешной загрузки img элемент img на заполненной странице будет быть заменены, что приведет к изменению размера, а также будет прочитано значение атрибута js.fetching, такое как смещение чтения, прокрутка, cilent, getComputedStyle и другая информация.
    • Перекрашивание: простые изменения внешнего вида могут вызвать перерисовку, например изменение цвета и т. д.
    • Reflow должен перерисовать.

оптимизация

  • dom
    • Упростите структуру DOM, уменьшите стоимость построения дерева DOM и дерева рендеринга, а также уменьшите количество элементов страницы.Например, используйте данные таблицы списка для разбиения по страницам и не используйте сложные сторонние компоненты для простых таблиц.
  • js
    • Поместите тег сценария js в нижнюю часть тела страницы, чтобы уменьшить блокировку других процессов.
    • Отложенное выполнение: Используйте атрибут defer для скриптов внешней цепочки, которые не модифицируют страницу, чтобы скрипты загружались параллельно без блокировки, и они не выполнялись сразу после скачивания, а выполнялись после парсинга всех элементов.
    • Сократите и объедините ненужные операции, связанные с DOM, такие как использование DocumentFragment, изменение имени класса вместо различных стилей и т. д., чтобы уменьшить число срабатываний перерисовки и перестановки.
  • css
    • Поместите css в голову, загрузите его заранее и предотвратите мерцание страницы, рекомбинируя css после рендеринга html.
    • Уменьшите уровни CSS и сложность селектора CSS, улучшите скорость синтаксического анализа, хотя в браузерах есть оптимизации.
    • Используйте более эффективные стили CSS, такие как flex, вместо float.
    • Включите составные слои, такие как использование 3D-преобразований, непрозрачности и т. д., чтобы элемент и его дочерние элементы не вызывали внешних перестановок, а такжеесть яма.
    • Разумное использование стилей вне потока документа для уменьшения влияния внешнего переформатирования, например абсолютного.
  • количество файлов
    • Уменьшение количества и размера файлов, загружаемых в первый раз, с помощью ленивой загрузки изображений, загрузки js по запросу и т. д. также может сэкономить пользовательский трафик и даже использовать хранилище для кэширования файлов js и css.
    • Разделите ресурсы страницы, сначала загрузите данные в верхней части страницы и т. д.

5. Другие меры по оптимизации

Мы также можем принять некоторые меры по оптимизации, которые не имеют ничего общего с задержкой и рендерингом:

  • Используйте PWA, чтобы пользователи могли просматривать страницу без получения данных.
  • Хранилище для некоторых данных запроса ajax страницы.
  • Прогресс загрузки, скелетные изображения, изображения-заполнители и т. д. и т. д. заставляют пользователя чувствовать себя лучше.
  • Своевременно обновляйте и обновляйте серверы, а меры по оптимизации зависят от поддержки серверов.

Ссылаться на

Категории