Интервью | Вы должны знать о http (с внутренним толчком в конце)

HTTP-кэш делится на сильный кеш и кеш согласования. Сильный кеш — это кеш браузера, а ресурсы берутся напрямую из браузера. Согласованное кэширование означает, что ресурсы будут получены от cdn.

Для сильного кэширования есть два флага оценки: флаг Expires использовался до http1.0 для указания времени истечения срока действия, но возникла проблема асинхронности времени между клиентом и сервером, поэтому Cache-Control был добавлен после http1.1. Это указывает время с момента отправки запроса, что является относительно точным относительным временем.

Сильный кеш — это кеш браузера, который делится на две категории: из кеша памяти и из кеша диска, а возвращаемый код состояния равен 200. Разница между ними заключается в том, что из кеша памяти берется из памяти. из дискового кэша берется с жесткого диска. Если текущая страница обновлена, а памяти достаточно, вернитесь из кеша памяти. Но если он возвращается на предыдущую страницу или текущего объема памяти недостаточно, он возвращается из кеша диска.

Флаги оценки кэша согласования: Last-Modified и ETag. ETag — это хэш, генерируемый файлом каждый раз, единственный с высокой точностью, но громоздкий и потребляющий производительность. Last-Modified — это время создания файла в секундах, что относительно неточно. Поскольку файл может быть сгенерирован несколько раз за 1 с. Приоритетным критерием для суждения является ETag. Второй — Last-Modified.

Процесс оценки HTTP-кэша: сначала оцените значение Cache-Control, которое здесь не подробно описано.Например, если max-age=300, сильный кеш будет активирован в течение пяти минут. Если прошло 5 минут, он перейдет в стадию буфера согласования. Исходящий http-запрос будет иметь два флаговых бита: If-Modified-Since (из Last-Modified в возвращаемом заголовке первого запроса) и If-None-Match (из ETag в возвращаемом заголовке первого запроса)) . Я упомянул разницу между двумя битами флага выше.По биту флага судят, обновлен ли файл.Если он обновлен, возвращается код состояния 200 и ресурс. Если обновления нет, просто верните код состояния 304.

Процесс рукопожатия TCP: клиент отправляет пакет ACK на сервер. После того, как сервер получает пакет ACK, он отправляет клиенту пакет ACK+SYN. После того, как клиент получает пакет ACK+SYN, он возвращает пакет SYN серверу.

Трехстороннее рукопожатие — это минимальное безопасное количество раз, позволяющее определить способность клиента отправлять и получать сообщения.

Четырехволновой процесс:

1. Клиент отправляет fin-пакеты, как и сервер, и тогда клиент не может отправлять данные, а может только читать данные.

2. После того, как сервер получает пакет fin, подобно тому, как клиент отправляет пакет ACK, сервер может только отправлять данные, но не может получать данные.

3. Когда данные будут отправлены, сервер отправит пакет fin клиенту. В этот момент сервер не может читать или получать данные.

4. Когда клиент получит пакет fin, он отправит пакет подтверждения на сервер, подождет достаточное время, а затем перейдет в закрытое состояние. Когда сервер получает пакет подтверждения, он также переходит в закрытое состояние.

Почему процесс завивки занимает 4 раза?

Поскольку TCP является дуплексным каналом, и сервер, и клиент могут отправлять и получать данные. Обе стороны бегут одновременно.

Процесс рукопожатия https делится на два этапа: проверка сертификата и передача данных

1. Клиент обращается к веб-серверу, и сервер возвращает цифровую подпись (открытый ключ, информация о сертификате, информация о сервере, хеш-значение).

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

3. После того, как данные возвращены на сервер, сервер использует соответствующий закрытый ключ для расшифровки, чтобы получить случайное число.

4. После этого сервер и клиент взаимодействуют посредством симметричного шифрования случайных чисел.

После получения цифровой подписи, предоставленной сервером, клиент расшифрует вещь с цифровой подписью в соответствии с закрытым ключом, выданным учреждением. В расшифрованном виде он будет содержать информацию о сервере и информацию о сертификате.

Информация сертификата должна быть проверена в следующих аспектах:

1. Доверяет ли клиент стороннему органу (ЦС), выдавшему сертификат.

2. Сравните, действителен ли сертификат проверки системного времени.

3. Проверьте, отозван ли сертификат с помощью CRL или OCSP.

4. Проверяя, есть ли у другой стороны закрытый ключ сертификата, определите, соответствует ли доменное имя веб-сайта сертификата доменному имени, выданному сертификатом.

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

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

Применение асимметричного шифрования и симметричного шифрования в HTTPS: Из-за производительности HTTPS использует асимметричное шифрование только при первом установлении, а затем процесс представляет собой симметричное шифрование случайного числа.

Атака «человек посередине» означает, что открытый ключ также может быть перехвачен во время передачи без сертификата ЦС.

После того, как посредник перехватывает открытый ключ, он заменяет открытый ключ своим собственным открытым ключом.

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

В процессе возврата посредник снова перехватывает данные и расшифровывает их с помощью закрытого ключа.

После завершения расшифровки данные шифруются истинным открытым ключом и возвращаются на сервер.

Все данные эквивалентны передаче в виде открытого текста.

Основное отличие заключается в следующих 4 пунктах:

1. Двоичная передача: данные http2.0 передаются в двоичной форме, наименьшей единицей является кадр, а несколько кадров передаются в виде потока данных. А следующий http1.1 передается в текстовом формате. Очевидно, что бинарный метод передачи более эффективен.

2. Сжатие заголовков: в http1.1 каждый запрос будет содержать большое количество повторяющейся информации заголовка. Но в http2.0 вам нужно только отправить измененную информацию заголовка.

3. Проталкивание сервером: сервер может активно проталкивать другие ресурсы при отправке html, и нет необходимости ждать, пока браузер запросит соответствующее местоположение.

4. Мультиплексирование, подробности см. в следующем вопросе.

Каждый запрос HTTP/1 устанавливает tcp-ссылку, которую мы называем трехсторонним рукопожатием и четырьмя волнами. Этот процесс занимает очень много времени, хотя можно включить поддержку активности, чтобы избежать проблемы множественных подключений. Но есть еще две проблемы:

1. Последовательная передача файлов. Процесс передачи файлов заключается в том, что когда файл передается, b файл может только ждать. В процессе передачи файла он должен пройти три процесса: подключение к службе, обработка файла сервером и отключение службы. Предположим, что каждый процесс занимает 1 с, тогда файл a занимает 3 с, а передача файла b завершается за 6 с.

2. Слишком много подключений. Когда клиент инициирует несколько запросов, браузер устанавливает ограничение на количество одновременных запросов.Максимальное количество одновременных запросов в Chrome равно 6. Затем седьмой запрос должен дождаться завершения предыдущего запроса, прежде чем получить соответствующий запрос. результат.

После http2 он был изменен на двоичную передачу, и появилось больше концепций кадров и потоков.

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

Пакеты HTTP делятся на пакеты запроса и соответствующие пакеты. Они разделены на 4 части:

1. Строка запроса/строка ответа. Строка запроса состоит из метода, URL-адреса и версии http. Например: ПОЛУЧИТЬ /index.html HTTP/1.1. Строка ответа состоит из версии http и кода состояния, например: HTTP/1.1 200ok

2. Заголовок запроса/заголовок ответа: заголовок состоит из нескольких полей ключ:значение.

3. Пустая строка: функция в основном используется для разделения головы и объекта.

4. Тело запроса/тело ответа: Тело запроса в основном содержит некоторые параметры во время публикации. Тело ответа в основном содержит некоторые данные, возвращаемые сервером.

1XX: Предварительный ответ

2ХХ: успех

• 200 OK: указывает, что запрос был обработан сервером и возвращен корректно.
• 206 Частичный контент, запросите диапазон.

3XX: перенаправление

• 301 перемещен навсегда, постоянное перенаправление, указывающее, что ресурсу был присвоен новый URL-адрес
• 302 найдено, временное перенаправление, указывающее на то, что ресурсу временно присвоен новый URL
• 304 не изменено, указывающее на то, что сервер разрешает доступ к ресурсу, но запрос не соответствует условиям из-за возникновения

4XX: ошибка клиента

• 400 неверный запрос, в сообщении запроса есть синтаксическая ошибка
• 403 запрещено, что указывает на то, что доступ к запрошенному ресурсу был запрещен сервером
• 404 not found, указывающий на то, что запрошенный ресурс не найден на сервере

5XX: ошибка сервера

• 500 внутренняя ошибка сервера, указывающая на то, что при обработке запроса произошла ошибка на стороне сервера

• Cache-Control управляет кешем
• Управление соединением соединения, по одному заголовку
• Transfor-Encoding Формат кодирования передачи тела сообщения.

Поля запроса:

• Примите типы мультимедиа, которые может обрабатывать клиент или прокси.
• If-None-Match сравнивает теги сущностей (ETage)
• If-Modified-Since сравнить время обновления ресурса (Last-Modified)
• Запрос диапазона байтов для объекта Range
• Информация для веб-аутентификации авторизации
• Хост Сервер, на котором находится запрошенный ресурс.
• Информация о клиентской программе User-Agent

Поля ответа:

• URI местоположения для перенаправления клиента на
• ETag Строка, которая может представлять уникальный ресурс ресурса.
• Информация о сервере сервера