Примечание: число (xx) перед каждым вопросом представляет частоту вопроса.Эта основа компьютерной сети основана на вопросах и соответствующих ответах, справочных ссылках и т. д., которые были отсортированы на обложке более 30 статей. . Содержание статьи организовано лицом, получившим Оферту.
(3) Вопрос: HTTP-кеш
Кэш HTTP далее делится на сильный кеш и кеш согласования:
- Сначала проверьте, доступен ли сильный кеш через Cache-Control, если надежный кеш доступен, затем прочитайте кеш напрямую.
- Если нет, то войдите в фазу кеша согласования, инициируйте HTTP-запрос, и сервер проверит, обновлен ли ресурс, если заголовок запроса содержит поля условного запроса If-Modified-Since и If-None-Match:
- Если ресурс обновлен, верните ресурс и код состояния 200.
- Если ресурс не обновляется, скажите браузеру использовать кеш для прямого извлечения ресурса.
(5) Вопрос. Каковы распространенные коды состояния HTTP и сценарии использования?
- 1xx: указывает, что в настоящее время протокол находится в промежуточном состоянии, и требуются последующие запросы.
- 2xx: указывает, что запрос был успешным
- 3xx: указывает статус перенаправления и требует повторного запроса.
- 4xx: указывает, что сообщение запроса неверно.
- 5xx: ошибка на стороне сервера
Общие коды состояния:
- 101 Переключить протокол запроса, переключиться с HTTP на WebSocket
- 200 Запрос был успешным с телом ответа
- 301 Постоянное перенаправление: будет кэшироваться
- 302 Временное перенаправление: не будет кэшироваться
- 304 Обсудить попадание в кеш
- 403 Сервер запрещен
- 404 Ресурс не найден
- 400 Ошибка запроса
- 500 ошибка на стороне сервера
- 503 Сервер занят
Вы знаете, что такое код состояния 302? С какими сценариями 302 вы сталкивались при просмотре веб-страниц?
А 302 означает временное перенаправление.Этот ресурс недоступен только временно, но к нему можно будет продолжать обращаться через некоторое время.Как правило, когда для доступа к ресурсу определенного веб-сайта требуется разрешение, пользователю потребуется войти в систему и перейти к страницу входа.После входа в систему вы можете продолжить доступ.
Подобно 301, он перейдет на новый веб-сайт, но ресурс адреса, который представляет 301, был удален навсегда, и этот адрес не должен использоваться в будущем.Когда поисковая система сканирует, она также заменит старый на новый адрес. Возвращенный адрес можно получить в заголовке местоположения возвращенного ответа. Сцена 301 выглядит следующим образом:
(2) В: Каковы общие методы запросов, различия и способы использования HTTP?
http/1.1 определяет следующие методы запроса:
- GET: общие данные для получения
- HEAD: Получить метаинформацию о ресурсе
- POST: отправить данные
- ПОСТАВИТЬ: изменить данные
- УДАЛИТЬ: удалить данные
- CONNECT: установить туннель подключения для прокси-сервера
- ПАРАМЕТРЫ: перечисляет методы запроса, которые могут быть выполнены на ресурсе, часто используемые для междоменных запросов.
- TRACE: трассировка пути передачи запроса-ответа
() Q: Каково ваше понимание компьютерных сетей?
Прикладной уровень, уровень представления, сеансовый уровень, транспортный уровень, сетевой уровень, канальный уровень, физический уровень
(3) В: Что такое HTTPS? конкретный процесс
HTTPS устанавливает уровень безопасности между HTTP и TCP. Когда HTTP взаимодействует с TCP, он должен сначала пройти уровень безопасности, зашифровать пакет данных, а затем передать зашифрованный пакет данных в TCP. быть переданы в HTTP выше.
Браузер передает client_random и список методов шифрования.После того, как сервер его получает, он передает браузеру server_random, список методов шифрования и цифровой сертификат (включая открытый ключ), после чего браузер проверяет цифровой сертификат на законных основаниях .Если проверка проходит, то Генерируем pre_random, затем шифруем его открытым ключом и передаем на сервер.Сервер использует client_random, server_random и pre_random, и использует открытый ключ для шифрования для генерации секрета, а затем последующие передача использует секрет в качестве секретного ключа для шифрования и дешифрования данных.
(4) Q: три рукопожатия и четыре волны
Почему трехсторонний рукопожатия: для подтверждения отправки и получения возможностей другой стороны.
трехстороннее рукопожатие
Основной процесс трехстороннего рукопожатия:
- В начале обе стороны находятся в состоянии CLOSED, а затем сервер начинает слушать порт и переходит в состояние LISTEN.
- Затем клиент активно инициирует соединение, отправляет SYN, а затем сам становится SYN-SENT, seq = x
- После того, как сервер его получает, он возвращает SYN seq = y и ACK ack = x + 1 (для SYN, отправленного клиентом), и становится самим SYN-REVD
- После этого клиент снова отправляет серверу ACK seq = x + 1, ack = y + 1, и он переходит в состояние EASTABLISHED, сервер получает ACK и также переходит в состояние ESTABLISHED.
SYN требует подтверждения от партнера, поэтому сериализация ACK должна быть увеличена на 1. Все, что требует подтверждения от партнера, использует сериализацию пакетов TCP.
Почему не дважды?
Возможность приема клиента не может быть подтверждена.
Если клиент сначала отправляет SYN-пакет, но остается в сети, TCP считает, что пакет потерян, а затем повторно передает его, и соединение устанавливается двумя рукопожатиями.
Подождите, пока клиент не закроет соединение. Однако, если после этого пакет достигает сервера, сервер получает его, отправляет соответствующую таблицу данных и устанавливает связь, но клиент в это время закрыл соединение, что приводит к пустой трате ресурсов ссылки.
Почему не в четыре раза?
Больше четырех раз — нормально, но и трех достаточно.
помахал четыре раза
- Он находится в состоянии ESTABLISH в начале, а затем клиент отправляет сообщение FIN с seq=p, и состояние меняется на FIN-WAIT-1
- После того, как сервер его получает, он отправляет подтверждение ACK, ack = p + 1, а затем переходит в состояние CLOSE-WAIT.
- После того, как клиент его получает, он переходит в состояние FIN-WAIT-2.
- Через некоторое время дождаться обработки данных, снова отправить FIN и ACK, seq=q, ack=p+1, и войти в стадию LAST-ACK
- После того, как клиент получает FIN, клиент после его получения входит в TIME_WAIT (ожидание 2MSL), а затем отправляет ACK на сервер ack = 1 + 1
- Сервер переходит в состояние ЗАКРЫТ после его получения
В это время клиенту еще нужно дождаться двух MSL, если он не получает от сервера запрос на повторную передачу, значит, ACK пришел успешно, волна завершена, и клиент переходит в состояние CLOSED, в противном случае ACK передается повторно.
Почему нужно ждать 2MSL (максимальное время жизни сегмента):
Потому что, если вы не ждете, если у сервера все еще есть много пакетов данных для отправки клиенту, а порт клиента занят новым приложением, тогда будут получены бесполезные пакеты данных, что приведет к путанице пакетов, поэтому Безопаснее всего сказать Метод заключается в том, чтобы дождаться, пока пакеты данных, отправленные сервером, не будут мертвы, а затем запустить новое приложение.
- 1 MSL гарантирует, что последнее сообщение ACK стороны, которая активно закрывает руки после четырех волн, может, наконец, достичь партнера.
- 1 MSL гарантирует, что сообщение FIN для повторной передачи может быть получено, если одноранговый узел не получил ACK
Почему четыре раза вместо трех?
** Если это три раза, то ACK и FIN сервера объединяются в одну волну, тогда из-за большой задержки TCP FIN может не дойти до сервера, а затем пусть клиент продолжит повторную отправку FIN
использованная литература
В: Что делать, если я не хочу разрывать соединение в процессе взаимодействия, как его сохранить?
Укажите keep-alive в поле Connection тела ответа в HTTP.
Знаете ли вы что-нибудь о скользящих окнах TCP?
В канале TCP для отправителя и получателя TCP должен поместить отправленные данные вотправить буфер, поместите полученные данные вприемный буфер. Однако часто возникает ситуация, когда отправитель отправляет слишком много, а получатель не может это переварить, поэтому необходимо управление потоком, то есть размер приемного буфера используется для управления отправкой отправителя. Если приемный буфер другой стороны заполнен, она не может продолжать передачу. Этот процесс управления потоком требует поддержания окна отправки у отправителя и окна приема у получателя.
Существует два типа скользящих окон TCP:окно отправкииокно получения.
использованная литература
Принципиально разные
Ajax, асинхронный JavaScript и XML, представляет собой технологию веб-разработки для приложений, создающих интерактивные веб-страницы.
websocket — это новый протокол HTML5, который реализует связь между браузером и сервером в режиме реального времени.
Жизненный цикл отличается:
- websocket - это длинное соединение, сессия всегда поддерживается
- Ajax отключится после отправки и получения
Область применения:
- websocket используется для интерактивных данных в режиме реального времени между интерфейсом и сервером.
- ajax не в реальном времени
спонсор:
- Клиент AJAX инициирован
- Сервер WebSocket и клиент подталкивают друг друга
Знаете о веб-сокетах?
Длинный опрос и короткий опрос, WebSocket — это длинный опрос.
Например, в сценарии электронной коммерции ассортимент товаров может измениться, поэтому это необходимо вовремя отразить пользователю, чтобы клиентская сторона продолжала отправлять запросы, а затем серверная сторона продолжала проверять изменения. это короткий опрос.
Производительность длительного опроса заключается в том, что если нет изменений, он не вернется, а дождется изменения или тайм-аута (обычно более десяти секунд) перед возвратом.Если возврата нет, клиенту не нужно отправлять запросы на все время, поэтому давление с обеих сторон уменьшается.
Ссылка на ссылку
Как HTTP реализует длинные соединения? Когда истечет время?
Установив Connection: keep-alive в заголовке (заголовок запроса и ответа), протокол HTTP1.0 поддерживает его, но по умолчанию он закрыт.Начиная с протокола HTTP1.1, соединение по умолчанию является длинным соединением.
- HTTP обычно имеет демона httpd, который может установить время ожидания для поддержания активности, которое будет закрыто, когда tcp-ссылка простаивает дольше, чем это время, и время ожидания также может быть установлено в заголовке HTTP.
- Keep-alive TCP содержит три параметра, которые можно установить в net.ipv4 ядра системы: когда TCP-ссылка простаивает и tcp_keepalive_time простаивает, происходит пакет обнаружения.Если ACK от другой стороны не получен , затем каждый tcp_keepalive_intvl Опять же, пока не будут отправлены tcp_keepalive_probes, ссылка будет сброшена.
- tcp_keepalive_intvl = 15
- tcp_keepalive_probes = 5
- tcp_keepalive_time = 1800
На самом деле в HTTP нет длинных или коротких ссылок, они есть только в TCP. Длинное соединение TCP может повторно использовать ссылку TCP для инициирования нескольких HTTP-запросов, что может снизить потребление ресурсов. Например, если вы запрашиваете HTML один раз, вы также можете необходимо запросить последующие JS/CSS/изображения и т. д.
Ссылка на ссылку
Вопрос: Разница между Fetch API и традиционным запросом
- Fetch соответствует принципу разделения задач, использует Promise, более богатый API и поддерживает Async/Await.
- Проще и семантичнее
- Вы можете использовать isomorphic-fetch , isomorphic удобен
Справочные ресурсы
(2) В: Какие типы файлов обычно можно отправлять POST?Обработка данных?
- Текст, картинки, видео, аудио и т.д.
- текст/изображение/аудио/или приложение/json и т. д.
В: Как TCP обеспечивает эффективную передачу и принцип управления перегрузкой.
- tcp — это надежный протокол связи транспортного уровня, ориентированный на установление соединения.
Надежность отражается в: состоянии, управляемости
- С сохранением состояния означает, что TCP будет подтверждать, какие пакеты были отправлены, какие пакеты были получены получателем, а какие не были получены, гарантируя, что пакеты поступят в порядке и не будут допущены ошибки.
- Управляемый означает, что в случае потери пакетов или плохого состояния сети он перейдет к своему собственному поведению, снизит скорость передачи или повторит передачу.
Следовательно, вышеуказанное может обеспечить эффективную передачу пакетов данных.
Принцип управления перегрузкой
Причина в том, что вся сетевая среда может быть особенно плохой и легко потерять пакеты, поэтому отправителю следует обратить на это внимание.
Используются три основных метода:
- Медленный начальный порог + предотвращение заторов
- быстрая ретрансляция
- Быстрый ответ
Порог медленного старта + предотвращение перегрузки
Для управления перегрузкой TCP в основном поддерживает два основных состояния:
- Окно перегрузки (cwnd)
- Порог медленного запуска (ssthresh)
Окно перегрузки используется отправителем для управления размером окна отправки.
Затем используется консервативный алгоритм медленного старта для медленной адаптации к сети.В начале передачи отправитель и получатель сначала устанавливают соединение через трехстороннее рукопожатие, определяют размер своих соответствующих окон приема, а затем инициализируют окна перегрузки обеих сторон Затем после каждого раунда RTT (задержка передачи и приема) размер окна перегрузки удваивается, пока не будет достигнут порог медленного запуска.
Затем начните предотвращение перегрузки.Конкретный метод предотвращения перегрузки состоит в том, чтобы удвоить окно перегрузки в каждом раунде RTT раньше, а теперь добавить одно в каждом раунде.
быстрая ретрансляция
В процессе передачи TCP, если происходит потеря пакета, принимающая сторона будет повторять ACK перед отправкой.Например, если 5-й пакет потерян, 6 и 7 достигнуты, а затем принимающая сторона отправит четвертый пакет для 5, 6 и 7. ACK, в это время отправитель получает 3 повторных ACK и понимает, что пакет потерян, он будет немедленно повторно передан, не дожидаясь RTO (тайм-аут повторной передачи)
Выборочная повторная передача: атрибут SACK необязательно добавляется к заголовку сообщения, левый край и правый край используются для обозначения прибытия этих пакетов, а затем пакеты, которые не прибыли, передаются повторно.
быстрое восстановление
Если отправитель получает 3 дубликата ACK, обнаруживает потерю пакетов и чувствует, что текущее состояние сети перешло в состояние перегрузки, он перейдет к фазе быстрого восстановления:
- уменьшит порог перегрузки до половины окна перегрузки
- Тогда размер окна перегрузки становится порогом перегрузки.
- Затем окно перегрузки линейно увеличивается, чтобы адаптироваться к условиям сети.
В: Что делает ОПЦИЯ? Приведите пример использования OPTION?
Цель состоит в том, чтобы отправить своего рода тестовый запрос, чтобы определить, какие ограничения должен иметь запрос к определенному месту назначения, а затем отправить реальный запрос в соответствии с ограничениями.
Например, предварительная проверка междоменных ресурсов сначала отправляется с использованием метода HTTP OPTIONS. Используется для обработки запросов из разных источников.
В: Вы знаете http? Какой слой соглашения? (прикладной уровень)
- Гибкий и масштабируемый, кроме положения пробелов между словами, кроме поля новой строки, других ограничений нет, любой ресурс может передавать только текст, также можно передавать картинки, видео и т.д.
- Надежная передача, основанная на TCP/IP, поэтому наследует эту функцию
- запрос-ответ, туда и обратно
- Без сохранения состояния, каждый HTTP-запрос является независимым, несвязанным и не требует сохранения контекстной информации по умолчанию.
недостаток:
- Передача открытого текста небезопасна
- Мультиплексирование TCP-канала вызовет непосредственную перегрузку
- Без сохранения состояния В случае длительного соединения необходимо сохранить большой объем контекста, чтобы избежать передачи большого количества повторяющейся информации.
В. Семиуровневая модель OSI и четырехуровневая модель TCP/IP
- прикладной уровень
- уровень представления
- сеансовый уровень
- транспортный уровень
- Сетевой уровень
- канальный уровень
- физический слой
Четырехслойная концепция TCP / IP:
- Прикладной уровень: прикладной уровень, уровень представления, сеансовый уровень: HTTP
- Транспортный уровень: Транспортный уровень: TCP/UDP
- Сетевой уровень: Сетевой уровень: IP
- Канальный уровень: канальный уровень, физический уровень
(3) В: Как протокол TCP может быть надежным и почему UDP ненадежен?
- TCP — это ориентированный на установление соединения, надежный протокол связи транспортного уровня.
- UDP — это коммуникационный протокол транспортного уровня без установления соединения, который наследует функции IP и основан на дейтаграммах.
Почему TCP надежен? Надежность TCP отражается на состоянии и контроле
- Он будет точно записывать, какие данные отправлены, какие данные получены другой стороной, а какие нет, и гарантирует, что пакеты данных прибывают в порядке, и ошибки не допускаются.
- Поняв, что пакет потерян или сетевая среда не в порядке, TCP изменит свое поведение в соответствии с конкретной ситуацией, контролируя собственную скорость отправки или повторную передачу, что поддается контролю.
И наоборот, UDP не имеет состояния и не контролируется.
Улучшение HTTP 2
Улучшенная производительность:
- сжатие заголовка
- мультиплексирование
- Server Push
использованная литература
❤️ Спасибо за поддержку
Если вам это нравится, не забудьте поделиться, поставить лайк и посмотреть Sanlian~.