Компьютерная сеть слишком сложна? Достаточно знать это

Два «брата» — компьютерная сеть и компьютерная операционная система — все позиции разработки, которые должны быть «под присягой», независимо от того, занимаетесь ли вы Java, C++ или тестируете. Для back-end разработки детской обуви компьютерная сеть имеет не меньшее значение, чем языковая основа, ведь разработка обычно связана с сетью, например: захват пакета и так далее. Поэтому к подготовке к этому пункту знаний следует все же отнестись с трепетом, и не пропускать ни одной проблемы, ускользнувшей из сети. Ниже мой процесс обучения:

1. Чтение книг: Для базовых компьютерных модулей я рекомендую найти классическую книгу, чтобы усердно учиться.Нельзя просто пойти на собеседование, просто прочитав священные писания. Всего я прочитал две книги: «Компьютерная операционная система» и «Протокол HTTP» Тан Сяоданя. "Компьютерная операционная система" - это учебник, поэтому знания относительно базовые, а охват относительно широкий, и тем не менее его необходимо прочитать неспециалистам. В книге «Иллюстрированный HTTP» используется множество иллюстраций, объясняющих некоторые моменты в простой для понимания форме, и она выглядит очень быстро, поэтому ее рекомендуется читать.

2. Делайте заметки: Есть еще много знаний о компьютерных сетях.Когда вам нужно прочитать книгу, делайте заметки, чтобы облегчить обзор. И когда вы делаете заметки, вы можете зайти в Baidu по этой точке знаний, чтобы увидеть, есть ли какие-то моменты, которые вы пропустили, а затем добавить их. Позвольте мне поговорить об этом здесь, почему я продолжаю подчеркивать необходимость делать заметки? Преимущество 1: Делать заметки — это первый раз, когда вы просматриваете точки знаний в книге и углубляете свою память; Преимущество 2: И если вы публикуете в сообществе по связям с общественностью, вы должны обеспечить максимальную точность, вам нужно посмотреть на это еще раз Знание баллы, проверьте, нет ли у вас недоразумений и упущений и т. д., чтобы завершить глубокое копание баллов знаний; Преимущество 3: Когда дело доходит до обзора интервью, вы вряд ли будете читать книгу снова, тогда появятся примечания Очень важно, чтобы заметки, сделанные вами, можно было просмотреть очень быстро, и лучше всего иметь какое-то понимание в заметках, которое отличается от написания Священных Писаний лицом к лицу.

3. Посмотрите на личные писания: часто проверяйте Ню Кэ, чтобы узнать, что интервьюеры спрашивают о компьютерных сетях? Вы можете ответить на многие вопросы, но если вы не понимаете, как спрашивает интервьюер, вы не сможете на них ответить; подготовили ли вы сами вопросы, которые задавали? Кроме того, компьютерная сеть и компьютерная операционная система будут подчеркнуты из-за разных компаний и должностей.Если вы посмотрите интервью, вы обнаружите, что есть еще некоторые правила, но это не абсолютно.В конце концов, вы должны увидеть Ваше интервью.Предпочтение офицера.

1. Расскажите о своем понимании архитектуры пятиуровневого сетевого протокола?

При изучении компьютерных сетей мы обычно применяем компромиссный метод, то есть нейтрализуем преимущества OSI и TCP/IP и принимаем архитектуру только с пятиуровневыми протоколами, которая одновременно кратка и понятна.

1. Прикладной уровень

Задача прикладного уровня (application-layer) состоит в том, чтобы выполнить конкретное сетевое приложение посредством взаимодействия между прикладными процессами. Протокол прикладного уровня определяет правила связи и взаимодействия между прикладными процессами (процессами: программами, работающими на хосте). Для разных сетевых приложений требуются разные протоколы прикладного уровня. В Интернете существует множество протоколов прикладного уровня, таких как система доменных имен DNS, протокол HTTP, поддерживающий приложения World Wide Web, протокол SMTP, поддерживающий электронную почту, и так далее. Мы называем блок данных, с которым взаимодействует прикладной уровень, сообщением.

2. Транспортный уровень

Основная задача транспортного уровня — предоставить общий сервис передачи данных для связи между двумя хост-процессами. Прикладной процесс использует эту службу для передачи пакетов прикладного уровня. «Универсальный» означает, что он не нацелен на конкретное сетевое приложение, но несколько приложений могут использовать одну и ту же службу транспортного уровня.

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

3. Сетевой уровень

Два компьютера, взаимодействующие в компьютерной сети, могут проходить через множество каналов передачи данных, а также могут проходить через множество коммуникационных подсетей. Задача сетевого уровня — выбрать соответствующие узлы маршрутизации и коммутации между сетями, чтобы обеспечить своевременную доставку данных. При отправке данных сетевой уровень инкапсулирует сегменты или пользовательские дейтаграммы, сгенерированные транспортным уровнем, в пакеты и пакеты для передачи. В архитектуре TCP/IP, поскольку сетевой уровень использует протокол IP, пакеты также называются дейтаграммами IP или просто дейтаграммами.

4. Канальный уровень

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

При приеме данных управляющая информация позволяет приемнику узнать, с какого бита кадр начинается и где он заканчивается. Таким образом, после получения кадра канальный уровень может извлечь из него часть данных и передать ее сетевому уровню. Управляющая информация также позволяет приемнику обнаруживать ошибки в принятом кадре. Если обнаружена ошибка, канальный уровень просто отбрасывает ошибочный кадр, чтобы не тратить ресурсы сети впустую, продолжая передачу по сети. Если необходимо исправить ошибки при передаче данных на канальном уровне (то есть канальный уровень должен не только обнаруживать, но и исправлять ошибки), то для исправления ошибок используется надежный протокол передачи. Такой подход усложняет протокол на канальном уровне.

5. Физический уровень

Единицей данных, передаваемых на физическом уровне, является бит. Роль физического уровня заключается в реализации прозрачной передачи битовых потоков между соседними компьютерными узлами и максимально возможном устранении различий между конкретными средами передачи и физическими устройствами. Уровень канала передачи данных выше него не должен учитывать, что является конкретной средой передачи сети. «Прозрачная передача потока битов» означает, что поток битов, передаваемый реальной схемой, не изменился, и цепь кажется невидимой для передаваемого потока битов.

2. Какие сетевые протоколы соответствуют каждому уровню?

В системе пятиуровневой компьютерной сети задействовано множество протоколов. Наиболее часто используемые из них перечислены ниже:

3. Как работает протокол ARP?

Протокол ARP на сетевом уровне завершает сопоставление IP-адресов и физических адресов. Во-первых, каждый хост создает список ARP в своем собственном буфере ARP для представления соответствия между IP-адресами и MAC-адресами. Когда узлу-источнику необходимо отправить пакет данных узлу-получателю, он сначала проверит, есть ли MAC-адрес, соответствующий IP-адресу, в его списке ARP: если да, он отправит пакет данных напрямую на этот MAC-адрес; если нет, он отправит широковещательный пакет запроса ARP в сегмент локальной сети, чтобы запросить MAC-адрес, соответствующий хосту назначения.

Этот пакет запроса ARP включает IP-адрес исходного хоста, аппаратный адрес и IP-адрес целевого хоста. После того, как все узлы в сети получат этот запрос ARP, они проверят, совпадает ли IP-адрес назначения в пакете данных с их собственным IP-адресом. Если это не то же самое, игнорируйте пакет данных; если это то же самое, хост сначала добавляет MAC-адрес и IP-адрес отправителя в свой собственный список ARP, если информация об IP уже существует в таблице ARP, он перезапишет ее. , а затем отправить Хост отправляет ответный пакет ARP, чтобы сообщить другой стороне, что это MAC-адрес, который ей нужно найти; после того, как хост-источник получает ответный пакет ARP, он добавляет IP-адрес и MAC-адрес хоста назначения свой собственный список ARP и используйте эту информацию, чтобы начать передачу данных. Если хост-источник никогда не получал ответный пакет ARP, это означает, что запрос ARP завершился неудачно.

4. Расскажите о своем понимании классификации IP-адресов?

IP-адрес относится к адресу Интернет-протокола, который представляет собой унифицированный формат адреса, предоставляемый протоколом IP.Он назначает логический адрес каждой сети и каждому хосту в Интернете, чтобы скрыть разницу в физических адресах. Схема адресации IP-адресов делит пространство IP-адресов на пять классов: A, B, C, D и E. Среди них A, B и C являются базовыми классами, а классы D и E используются как многоадресные и зарезервированные, и являются специальными адресами.

Каждый IP-адрес включает в себя два идентификационных кода (ID), идентификатор сети и идентификатор хоста. Все узлы в одной физической сети используют один и тот же идентификатор сети, а узел в сети (включая рабочие станции, серверы и маршрутизаторы в сети) имеет соответствующий ему идентификатор узла. Характеристики адресов класса A~E следующие:

Адрес класса A: начните с 0, диапазон первого байта: 0~127;

Адреса класса B: начало 10, диапазон первого байта: от 128 до 191;

Адрес класса C: начните со 110, диапазон первых байтов: 192~223;

Адрес класса D: начинается с 1110, а первый байт находится в диапазоне от 224 до 239;

Адреса класса E: начинаются с 1111, зарезервированные адреса

5. Каковы основные возможности TCP?

1. TCP ориентирован на соединение. (Так же, как и при звонке, вам нужно набрать номер, чтобы установить соединение, прежде чем звонить, и повесить трубку, чтобы разорвать соединение после завершения звонка);

2. Каждое TCP-соединение может иметь только две конечные точки, и каждое TCP-соединение может быть только двухточечным (один-к-одному);

3. TCP обеспечивает надежную доставку услуг. Данные, передаваемые по TCP-соединению, безошибочны, не теряются, не дублируются и поступают последовательно;

4. TCP обеспечивает полнодуплексную связь. TCP позволяет приложениям на обеих сторонах связи отправлять данные в любое время. Оба конца соединения TCP оснащены буфером отправки и буфером приема, которые используются для временного хранения данных, передаваемых между двумя сторонами;

5. Ориентирован на байтовый поток. «Поток» в TCP относится к последовательности байтов, поступающих в процесс или исходящих из него. Значение «ориентированного на поток байтов» заключается в том, что, хотя взаимодействие между приложением и TCP представляет собой один блок данных за раз (разных размеров), TCP рассматривает только данные, переданные приложением, как серию неструктурированных потоков байтов. .

6. Каковы основные особенности UDP?

1. UDP не требует установления соединения;

2. UDP использует доставку с наилучшими усилиями, то есть надежная доставка не гарантируется, поэтому хосту не нужно поддерживать сложное состояние канала (параметров много);

3. UDP ориентирован на сообщения;

4. UDP не контролирует перегрузку, поэтому перегрузка сети не снизит скорость отправки хоста-источника (полезно для приложений реального времени, таких как прямая трансляция, видеоконференция в реальном времени и т. д.);

5. UDP поддерживает интерактивную связь «один к одному», «один ко многим», «многие к одному» и «многие ко многим»;

6. Накладные расходы заголовка UDP небольшие, всего 8 байт, что короче 20-байтового заголовка TCP.

7. В чем разница между TCP и UDP?

TCP предоставляет услуги, ориентированные на соединение. Соединение должно быть установлено перед передачей данных, а соединение должно быть разорвано после завершения передачи данных. TCP не предоставляет услуги широковещательной или многоадресной рассылки. Поскольку TCP должен предоставлять надежные, ориентированные на соединение транспортные услуги (надежность TCP отражается в том факте, что TCP имеет три рукопожатия для установления соединения перед передачей данных, а также механизмы подтверждения, окна, повторной передачи и управления перегрузкой во время передачи данных). После передачи данных соединение будет разорвано для экономии системных ресурсов), что неизбежно добавляет много накладных расходов, таких как подтверждение, управление потоком, таймеры и управление соединением. Это не только делает заголовок блока данных протокола намного больше, но и отнимает много ресурсов процессора.

UDP не нужно устанавливать соединение перед передачей данных, а удаленному хосту не нужно давать никаких подтверждений после получения UDP-пакета. Хотя UDP не обеспечивает надежной доставки, в некоторых случаях UDP действительно является наиболее эффективным способом работы (обычно используется для обмена мгновенными сообщениями), например: голос QQ, видео QQ, прямая трансляция и т. д.

8. Какие общие протоколы прикладного уровня соответствуют TCP и UDP?

1. Протокол прикладного уровня, соответствующий TCP

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

Telnet: это порт, используемый для удаленного входа в систему. Пользователи могут удаленно подключаться к компьютеру под своим собственным именем. Через этот порт может предоставляться служба связи на основе режима DOS. Если предыдущая BBS является чисто символьным интерфейсом, сервер, поддерживающий BBS, откроет порт 23 для предоставления услуг внешнему миру.

SMTP: определяет простой протокол передачи почты, который используется многими почтовыми серверами для отправки почты. Например, этот порт почтовой службы используется в распространенных бесплатных почтовых службах, поэтому вы часто видите такую настройку порта SMTP в настройках электронной почты — и сервер открывает порт 25.

POP3: соответствует SMTP, а POP3 используется для получения почты. Обычно протокол POP3 использует порт 110. То есть, если у вас есть соответствующая программа, использующая протокол POP3 (например, Fo-xmail или Outlook), вы можете войти в интерфейс почтового ящика, не используя веб-режим, и вы можете напрямую использовать почтовую программу. для получения почты (если это почтовый ящик 163, нет необходимости сначала Заходить на сайт NetEase, а потом заходить в свой почтовый ящик для получения писем).

HTTP: транспортный протокол для передачи гипертекста с веб-сервера в локальный браузер.

2. Протокол прикладного уровня, соответствующий UDP

DNS: используется службами разрешения доменных имен для преобразования адресов доменных имен в IP-адреса. DNS использует порт 53.

SNMP: простой протокол управления сетью, использующий порт 161, используется для управления сетевыми устройствами. Поскольку существует так много сетевых устройств, услуги без установления соединения имеют свои преимущества.

TFTP (Простой протокол передачи файлов): Упрощенный протокол передачи файлов, который использует службы UDP на общеизвестном порту 69.

9. Подробно опишите процесс трехэтапного рукопожатия TCP?

1. Трехстороннее рукопожатие

Процесс установления соединения в TCP называется рукопожатием, и рукопожатие требует обмена тремя сегментами TCP между клиентом и сервером.

Изначально и клиент, и сервер находятся в состоянии ЗАКРЫТ. В этом примере A (Клиент) активно открывает соединение, а B (Сервер) пассивно открывает соединение.

Вначале серверный процесс TCP B сначала создает блок управления передачей TCB, готовый принять запрос на соединение от клиентского процесса. Затем серверный процесс находится в состоянии LISTEN (прослушивание), ожидая запроса на подключение от клиента. Если да, то ответьте немедленно.

Первое рукопожатие: клиентский процесс TCP A также первым создает TCB блока управления передачей. Затем, при намерении установить TCP-соединение, сегмент запроса на соединение отправляется в B. В это время бит синхронизации в заголовке равен SYN=1, и в то же время выбирается начальный порядковый номер seq=x. TCP предусматривает, что сегмент SYN (то есть сегмент с SYN = 1) не может передавать данные, но использует порядковый номер. В этот момент клиентский процесс TCP переходит в состояние SYN-SENT.

Второе рукопожатие: после того, как B получит сообщение с запросом на соединение, если он согласен установить соединение, он отправляет подтверждение A. В сегменте подтверждения и бит SYN, и бит ACK должны быть установлены в 1, номер подтверждения равен ack = x + 1, а начальный порядковый номер seq = y также выбирается для себя. Обратите внимание, что этот сегмент также не может передавать данные, но также использует порядковый номер. В это время серверный процесс TCP переходит в состояние SYN-RCVD (синхронный прием).

Третье рукопожатие: после того, как клиентский процесс TCP получает подтверждение от B, он также передает подтверждение B. ACK сегмента подтверждения устанавливается равным 1, номер подтверждения ack = y + 1, а его собственный порядковый номер seq = x + 1. В это время сегмент ACK может нести данные. Однако, если данные не переносятся, порядковый номер не используется.В этом случае порядковый номер следующего сегмента данных по-прежнему равен seq = x + 1. В этот момент TCP-соединение установлено, и A переходит в состояние ESTABLISHED (соединение установлено).

10. Почему нельзя дважды пожать друг другу руки?

Чтобы предотвратить повторную отправку сегмента запроса на соединение, срок действия которого истек, в B, что приведет к ошибке. Например, в следующей ситуации: первый сегмент запроса на соединение, отправленный А, не был потерян, а оставался в узле сети в течение длительного времени, так что он был задержан до определенного периода времени после того, как соединение было разорвано до достижения В. . Первоначально это был давно несуществующий сегмент. Однако после того, как B получает недопустимый сегмент запроса на соединение, он ошибочно полагает, что A отправил новый запрос на соединение. Таким образом, он отправляет сегмент подтверждения А и соглашается установить соединение.

В приведенной выше ситуации, если третье рукопожатие не выполнено, после того, как B отправил подтверждение, он считает, что новое транспортное соединение установлено и ожидает отправки данных от A. Многие ресурсы B просто потрачены впустую.

Если используется трехстороннее рукопожатие, поскольку A фактически не отправляет запрос на установление соединения, он будет игнорировать подтверждение B и не будет отправлять данные B. Поскольку B не получает подтверждения, он знает, что A не просил установить соединение.

11. Почему нет необходимости в четырехстороннем рукопожатии?

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

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

12. После того, как сервер получил SYN от клиента, почему он возвращает SYN?

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

SYN — это сигнал квитирования, используемый TCP/IP при установлении соединения. Когда между клиентом и сервером устанавливается нормальное сетевое соединение TCP, клиент сначала отправляет сообщение SYN, сервер использует ответ SYN-ACK, чтобы указать, что он получил сообщение, и, наконец, клиент отправляет ACK (Подтверждение [ Перевод на китайский язык: символ подтверждения, При передаче данных - символ управления передачей, отправляемый принимающей станцией на передающую станцию. Он указывает, что полученные данные были получены без ошибок]) ответ на сообщение. Таким образом, между клиентом и сервером может быть установлено надежное TCP-соединение, и данные могут передаваться между клиентом и сервером.

13. Зачем отправлять ACK после передачи SYN?

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

14. Опишите подробно процесс четырехкратной завивки ПТС?

После завершения передачи данных обе стороны связи могут разорвать соединение. Теперь и A, и B находятся в состоянии ESTABLISHED.

Первая волна: процесс приложения A сначала отправляет сегмент освобождения соединения в свой TCP, снова прекращает отправку данных и активно закрывает TCP-соединение. A устанавливает бит управления завершением FIN в заголовке сегмента разрыва соединения в 1, а его порядковый номер seq = u (равный порядковому номеру последнего байта ранее переданных данных плюс 1), затем A входит в FIN-WAIT -1 (Завершить состояние ожидания 1) и дождаться подтверждения от B. Обратите внимание: TCP предусматривает, что даже если сегмент FIN не несет данных, он использует порядковый номер.

Вторая волна: B отправляет подтверждение сразу после получения сегмента разрыва соединения, номер подтверждения ack = u + 1, а собственный порядковый номер сегмента v (равный последнему слову данных, которое было передано до B). порядковый номер секции увеличивается на 1), а затем B переходит в состояние CLOSE-WAIT (ожидание закрытия). В это время серверный процесс TCP должен уведомить высокоуровневый процесс приложения, чтобы соединение от A к B было разорвано. В это время TCP-соединение находится в полузакрытом состоянии, то есть у A нет данных для отправки. , но если B отправляет данные, A все равно хочет их получить. То есть соединение от B к A не закрыто, и это состояние может продолжаться в течение определенного периода времени. Получив подтверждение от B, A переходит в состояние FIN-WAIT-2 (ожидание завершения 2) и ожидает сегмента освобождения соединения, отправленного B.

Третья волна: если у B нет данных для отправки A, его прикладной процесс уведомит TCP о разрыве соединения. В это время сегмент освобождения соединения, отправленный B, должен иметь FIN = 1. Предположим, что порядковый номер B равен w (в полузакрытом состоянии B мог отправить еще какие-то данные). B также должен повторить последний отправленный номер подтверждения ack = u + 1. В это время B входит в состояние LAST-ACK (последнее подтверждение) и ожидает подтверждения от A.

Четвертая волна: после того, как A получит сообщение об освобождении соединения от B, он должен подтвердить его. Установите ACK на 1 в сегменте подтверждения, номер подтверждения ack = w + 1 и собственный порядковый номер seq = u + 1 (ранее отправленный сегмент FIN использует порядковый номер). Затем войдите в состояние TIME-WAIT (время ожидания). Обратите внимание, что TCP-соединение еще не разорвано. A должен дождаться времени, установленного таймером 2MSL (MSL: максимальное время жизни сегмента), прежде чем A сможет войти в состояние CLOSED, а затем отменить блок управления передачей и разорвать это TCP-соединение. Конечно, если B получает подтверждение от A, он переходит в состояние CLOSED, а затем отменяет блок управления передачей. Таким образом, при разрыве соединения B завершает TCP-соединение раньше, чем A.

15. Почему состояние TIME-WAIT должно ждать 2MSL?

1. Чтобы гарантировать, что последний сегмент ACK, отправленный A, может быть достигнут B. Этот сегмент ACK может быть потерян, тем самым препятствуя тому, чтобы B в состоянии LAST-ACK получил подтверждение отправленного сегмента FIN + ACK. B будет повторно передавать сегмент FIN+ACK с течением времени, а A может получить повторно переданный сегмент FIN+ACK в течение времени 2MSL (время ожидания + передача 1MSL). Затем A повторно передает подтверждение, перезапуская таймер 2MSL. Наконец, и A, и B нормально переходят в состояние CLOSED. Если A не ждет в течение определенного периода времени в состоянии TIME-WAIT, а разрывает соединение сразу после отправки сегмента ACK, то он не может получить сегмент FIN + ACK, повторно переданный B, поэтому он не будет отправлять другое подтверждение. , так что B не может войти в состояние CLOSED в соответствии с обычными шагами.

2. Предотвратите появление в этом соединении недопустимых сегментов запроса на соединение. После того, как А отправил последний сегмент ACK и после 2MSL, все сегменты, сгенерированные за время соединения, могут исчезнуть из сети. Таким образом, этот старый сегмент запроса на соединение не появится в следующем соединении.

16. Почему второй и третий раз нельзя объединить, и какое время ожидания между вторым и третьим разом?

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

17. Какова функция таймера проверки активности?

В дополнение к таймеру ожидания, TCP также имеет таймер проверки активности. Представьте себе сценарий, в котором клиент активно установил TCP-соединение с сервером. Но затем хост клиента внезапно выходит из строя. Очевидно, что сервер больше не сможет получать данные, отправленные клиентом в будущем. Поэтому должны быть меры, чтобы сервер не ждал напрасно. Это требует использования таймера поддержания активности.

Каждый раз, когда сервер получает данные от клиента, он сбрасывает таймер проверки активности, который обычно устанавливается на два часа. Если данные клиента не поступают в течение двух часов, сервер отправляет тестовый сегмент, а затем отправляет его каждые 75 секунд. Если после отправки 10 тестовых сегментов подряд нет ответа от клиента, сервер считает, что клиент неисправен, и затем закрывает соединение.

18. Как протокол TCP обеспечивает надежную передачу?

1. Проверка пакета данных: цель состоит в том, чтобы обнаружить любые изменения в данных во время передачи.Если есть ошибка в проверке пакета, сегмент пакета будет отброшен, и ответ не будет дан.В это время TCP будет повторно передавать данные после истечения времени ожидания отправителя данных. ;

2. Переупорядочивание неупорядоченных пакетов. Поскольку сегменты TCP передаются как дейтаграммы IP, а дейтаграммы IP могут приходить не по порядку, сегменты TCP также могут приходить не по порядку. TCP переупорядочивает неупорядоченные данные перед передачей их на прикладной уровень;

3. Отбросить дубликаты данных. Для дубликатов данных дубликаты данных можно удалить;

4. Механизм подтверждения. Когда TCP получает данные с другого конца соединения TCP, он отправляет подтверждение. Это подтверждение не отправляется немедленно, обычно оно задерживается на долю секунды;

5. Тайм-аут повторной передачи: когда TCP отправляет сегмент, он запускает таймер и ожидает, пока пункт назначения подтвердит получение сегмента. Если подтверждение не может быть получено вовремя, сегмент будет отправлен повторно;

6. Управление потоком. Каждая сторона TCP-соединения имеет буферное пространство фиксированного размера. Принимающая сторона TCP позволяет другой стороне отправлять столько данных, сколько может вместить буфер получателя.Это предотвращает переполнение буферов более медленных узлов более быстрыми узлами.Это управление потоком. Протокол управления потоком, используемый TCP, представляет собой протокол скользящего окна переменного размера.

19. Расскажите о своем понимании соглашения об остановке ожидания?

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

20. Расскажите о своем понимании протокола ARQ?

Протокол автоматического повторного запроса ARQ

Тайм-аут повторной передачи в протоколе с остановкой ожидания означает, что до тех пор, пока подтверждение не будет получено в течение определенного периода времени, ранее отправленный пакет будет передан повторно (считается, что только что отправленный пакет потерян). Следовательно, каждый раз при отправке пакета необходимо устанавливать таймер тайм-аута, а время его повторной передачи должно быть больше, чем среднее время приема-передачи данных при передаче пакета. Этот режим автоматического повторения часто называют автоматическим ARQ запроса на повторение.

Непрерывный протокол ARQ

Непрерывный протокол ARQ улучшает использование канала. Отправитель поддерживает окно отправки, и все пакеты в пределах окна отправки могут отправляться непрерывно, не дожидаясь подтверждения от другой стороны. Получатель обычно принимает кумулятивное подтверждение и отправляет подтверждение последнему пакету, прибывшему по порядку, указывая, что все пакеты до этого пакета были получены правильно.

21. Расскажите о своем понимании раздвижных окон?

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

В TCP для управления передачей используется скользящее окно Размер скользящего окна означает, какой объем буфера есть у приемника для приема данных. Отправитель может использовать размер скользящего окна, чтобы определить, сколько байтов данных следует отправить. Когда скользящее окно равно 0, отправитель, как правило, больше не может отправлять дейтаграммы, за исключением двух случаев, один из которых предназначен для отправки срочных данных, например, позволяющих пользователю завершить запущенный процесс на удаленной машине. Другая ситуация заключается в том, что отправитель может послать 1-байтовую дейтаграмму, чтобы проинформировать получателя о том, что нужно повторно указать следующий байт, который он хочет получить, и размер скользящего окна отправителя.

22. Расскажите о своем понимании управления потоком?

TCP использует скользящие окна для управления потоком. Управление потоком предназначено для управления скоростью отправки отправителя и обеспечения того, чтобы у получателя было время для приема. Поле окна в сообщении подтверждения, отправленном получателем, может использоваться для управления размером окна отправителя, тем самым влияя на скорость отправки отправителем. Если в поле окна установлено значение 0, отправитель не может отправлять данные.

23. Расскажите о своем понимании управления перегрузкой TCP? Какие алгоритмы используются?

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

Контроль перегрузки предназначен для предотвращения ввода слишком большого количества данных в сеть, чтобы маршрутизаторы или каналы в сети не были перегружены. Управление перегрузкой исходит из того, что сеть может выдержать существующую сетевую нагрузку. Управление перегрузкой — это глобальный процесс, в котором участвуют все хосты, все маршрутизаторы и все факторы, связанные с ухудшением производительности передачи по сети. Напротив, управление потоком часто представляет собой управление трафиком «точка-точка» и представляет собой сквозную проблему. Все, что делает управление потоком, — это регулирует скорость, с которой отправитель отправляет данные, чтобы у получателя было время их получить.

Для управления перегрузкой отправитель TCP поддерживает переменную состояния окна перегрузки (cwnd). Размер окна контроля перегрузки зависит от степени загруженности сети и изменяется динамически. Отправитель позволяет своему окну отправки быть меньшим из окна перегрузки и окна приема получателя.

TCP использует четыре алгоритма для управления перегрузкой, а именно: медленный старт, предотвращение перегрузки, быстрая повторная передача и быстрое восстановление. На сетевом уровне маршрутизаторы также могут применять соответствующие стратегии отбрасывания пакетов (такие как активное управление очередями AQM), чтобы уменьшить перегрузку сети.

Медленный старт:

Идея алгоритма медленного старта заключается в том, что когда хост начинает отправлять данные, если большое количество байтов данных сразу же вводится в сеть, это может вызвать перегрузку сети, потому что соответствие сети еще неизвестно. Опыт показал, что лучший метод — сначала зондировать, то есть постепенно увеличивать окно отправки от малого до большого, то есть постепенно увеличивать значение окна перегрузки от малого до большого. Начальное значение cwnd равно 1, и cwnd удваивается после каждого раунда распространения.

Предотвращение перегрузки:

Идея алгоритма предотвращения перегрузки состоит в том, чтобы медленно увеличивать cwnd окна перегрузки, то есть увеличивать cwnd отправителя на 1 каждый раз, когда истекает время приема-передачи RTT.

Быстрая ретрансляция и быстрое восстановление:

В TCP/IP быстрая повторная передача и восстановление (FRR) — это алгоритм управления перегрузкой, который позволяет быстро восстанавливать потерянные пакеты.

Без FRR, если пакет потерян, TCP будет использовать таймер, требующий приостановки передачи. Во время этой паузы новые или дублированные пакеты не отправляются. При использовании FRR, если получатель получает сегмент вне очереди, он немедленно отправляет дубликат подтверждения отправителю. Если передатчик получает три повторяющихся подтверждения, он предполагает, что сегменты данных, указанные в подтверждении, отсутствуют, и немедленно повторно передает эти недостающие сегменты данных.

С FRR нет задержки из-за пауз, необходимых при повторных передачах. Быстрая повторная передача и быстрое восстановление (FRR) работают наиболее эффективно при потере отдельных пакетов. Это не очень хорошо работает, когда за короткий промежуток времени теряется несколько пакетов данных.

24. Что такое липкий мешок?

При изучении Java NIO вы можете обнаружить, что если клиент постоянно отправляет пакеты данных на сервер, данные, полученные сервером, будут казаться слипшимися.

1. TCP основан на потоках байтов.Хотя взаимодействие данных между прикладным уровнем и транспортным уровнем TCP представляет собой блоки данных разного размера, TCP рассматривает эти блоки данных только как серию неструктурированных потоков байтов без границ;

2. Из структуры кадра TCP также видно, что в заголовке TCP нет поля, указывающего длину данных.

Исходя из двух вышеуказанных моментов, при использовании TCP для передачи данных есть вероятность залипания или распаковки. Пакет данных содержит информацию о двух пакетах данных, отправленных отправителем, и это явление называется липкими пакетами.

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

25. Как генерируется липкий TCP-пакет?

Отправитель генерирует липкие пакеты

Клиент и сервер, которые используют протокол TCP для передачи данных, часто поддерживают длительное состояние соединения (отсутствует фиксированный пакет для отправки данных один раз за соединение), и обе стороны всегда могут передавать данные, не разрывая соединения. Но когда отправляемые пакеты данных слишком малы, протокол TCP по умолчанию включает алгоритм Nagle, объединяет и отправляет эти меньшие пакеты данных (отправка буферных данных — это процесс сжатия кучи); этот процесс объединения заключается в отправке буферов. выполняется в области, то есть когда данные отправляются, они уже находятся в состоянии липких пакетов.

Получатель генерирует липкие пакеты

Когда получатель использует протокол TCP для получения данных, процесс выглядит следующим образом: данные отправляются получателю и передаются из нижней части сетевой модели на транспортный уровень.Обработка протокола TCP транспортного уровня заключается в следующем. поместите его в приемный буфер, а затем прикладной уровень будет активно получать его (язык C использует такие функции, как recv, read и т. д.); в это время будет проблема, то есть функция чтения данных, которую мы вызов в программе не может вовремя вынуть данные в буфер, а следующие данные приходят снова и какая-то часть Конец буфера помещается в него липким пакетом, когда мы читаем данные. (скорость размещения данных> скорость получения данных прикладного уровня)

26. Как решить распаковку и приклеивание?

Как правило, существует два общих решения механизма субподряда:

1. Управление специальными персонажами;

2. Добавьте длину пакета данных в заголовок пакета.

Если используете netty, то есть специальные энкодеры и декодеры для решения проблемы распаковки и втыкания.

Советы: UDP не имеет проблем с липкими пакетами, но есть потеря пакетов и беспорядок. Неполных пакетов не будет, будут получены только правильные пакеты. Протокол блока передаваемых данных представляет собой UDP-пакет или пользовательскую дейтаграмму, которые не объединяются и не разделяются при отправке.

27. Знаете ли вы что-нибудь о кодах состояния HTTP?

1ХХ информация

1. 100 Продолжить: Указывает, что пока все нормально, и клиент может продолжать отправлять запрос или игнорировать ответ.

2ХХ успехов

1. 200 OK

2. 204 Нет содержимого: запрос был успешно обработан, но возвращенное ответное сообщение не содержит основной части объекта. Обычно он используется, когда вам нужно только отправить информацию от клиента к серверу и не нужно возвращать данные.

3. 206 Partial Content: указывает, что клиент сделал запрос диапазона, а ответное сообщение содержит содержимое объекта диапазона, указанного Content-Range.

3XX редирект

1. 301 Moved Permanently: постоянное перенаправление;

2. 302 Найдено: временное перенаправление;

3. 303 См. Другое: выполняет ту же функцию, что и 302, но 303 явно требует, чтобы клиент использовал метод GET для получения ресурсов.

4. 304 Not Modified: Если заголовок сообщения запроса содержит некоторые условия, такие как: If-Match, If-Modified-Since, If-None-Match, If-Range, If-Unmodified-Since, если условия не выполняются , серверу будет возвращен код состояния A 304.

5. 307 Временные перенаправления: временное перенаправление, аналогичное 302, но 307 требует, чтобы браузер изменил метод повторного перенаправленного запроса на метод получения.

4XX Ошибка клиента

1. 400 Bad Request: в сообщении запроса есть синтаксическая ошибка.

2. 401 Unauthorized: этот код состояния указывает, что для отправленного запроса требуется информация аутентификации (BASIC-аутентификация, DIGEST-аутентификация). Если запрос был сделан ранее, аутентификация пользователя не удалась.

3. 403 Forbidden: Запрос отклонен.

4. 404 Not Found

5ХХ ошибка сервера

1. 500 Internal Server Error: Произошла ошибка при выполнении запроса сервером;

2. 503 Служба недоступна: сервер временно перегружен или находится в состоянии простоя из-за технического обслуживания и не может сейчас обрабатывать запросы.

28. Что представляют собой коды состояния HTTP 301 и 302? Какая разница?

301 и 302 — это кодировка статуса HTTP, и оба означают, что URL-адрес был передан.

разница:

301 перенаправление: 301 означает постоянное перемещение

302 перенаправление: 302 означает временно перемещенный

29. В чем разница между прямой и переадресацией?

Forward and Redirect перенаправляет запрос от имени двумя способами: прямая и непрямая переадресация на пересылку.

Прямой режим экспедирования (вперед): клиент и браузер выдают только запрос, сервлет, HTML, JSP или другие информационные ресурсы, по второму ответу информационного ресурса, в запросе на объект запроса сохраненные объекты для каждой информационные ресурсы совместно используются.

Косвенная переадресация (перенаправление): на самом деле это два HTTP-запроса.Когда сервер отвечает на первый запрос, браузер просит браузер отправить запрос на другой URL-адрес, чтобы достичь цели переадресации.

Возьмем простой пример:

Прямая переадресация эквивалентна: «A просит B одолжить деньги, B говорит «нет», B просит C одолжить деньги, и если ему не удастся занять деньги, он передаст сообщение A»;

Косвенная переадресация эквивалентна: «A просит B одолжить деньги, B говорит «нет», пусть A попросит C одолжить».

30. Что такое методы HTTP?

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

1. GET: для получения ресурсов большинство современных сетей используют GET;

2. HEAD: получить заголовок сообщения, который аналогичен методу GET, но не возвращает основную часть сообщения;

3. POST: передача тела объекта

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

5. ИСПРАВЛЕНИЕ: Частично изменить ресурс. PUT также можно использовать для изменения ресурса, но он может только полностью заменить исходный ресурс, а PATCH допускает частичную модификацию.

6. ВАРИАНТЫ: Запросить методы, поддерживаемые указанным URL-адресом;

7. CONNECT: требует установки туннеля при обмене данными с прокси-сервером. Используйте протоколы SSL (Secure Sockets Layer, Secure Sockets Layer) и TLS (Transport Layer Security, Transport Layer Security) для шифрования содержимого связи и его передачи через сетевой туннель.

8. TRACE: Проследите путь. Сервер возвращает путь связи клиенту. При отправке запроса заполните значение в поле заголовка Max-Forwards, оно будет уменьшаться на 1 при каждом прохождении через сервер, а передача прекратится при значении 0. TRACE обычно не используется и уязвим для XST-атак (Cross-Site Tracing).

31. Скажите, в чем разница между GET и POST?

GET и POST по сути являются HTTP-запросами, но их функции определены и адаптированы, и они адаптированы к соответствующим сценариям.

Существенная разница: GET — это просто HTTP-запрос, а POST сначала отправляет заголовок запроса, а затем тело запроса, что на самом деле представляет собой два запроса.

1. Функционально GET обычно используется для получения ресурсов с сервера, а POST обычно используется для обновления ресурсов на сервере;

2. С точки зрения службы REST, GET является идемпотентным, то есть читая один и тот же ресурс, всегда получают одни и те же данные, тогда как POST не является идемпотентным, так как каждый запрос не изменяет ресурс одинаково, далее В общем, GET не изменит ресурсы на сервере, а POST изменит ресурсы сервера;

3. С точки зрения формы параметра запроса, данные GET-запроса будут привязаны к URL-адресу, то есть данные запроса будут помещены в заголовок запроса HTTP-сообщения, URL-адрес и данные передачи разделяются знаком ?, а параметры соединяются знаком &. В частности, если данные представляют собой английские буквы/цифры, они отправляются как есть; в противном случае они кодируются как строка MIME application/x-www-form-urlencoded (преобразуется в +, если это пробел, или +, если это является китайским/другим символом. Зашифруйте строку напрямую с помощью BASE64 и получите, например: %E4%BD%A0%E5%A5%BD, где XX в %XX – это ASCII символа в шестнадцатеричном формате); и запрос POST отправит Данные помещаются в тело запроса сообщения HTTP-запроса;

4. С точки зрения безопасности, безопасность POST выше, чем у GET, потому что данные, отправленные запросом GET, будут отображаться в URL-адресе в виде открытого текста, а параметры запроса POST заключены в тело запроса, что относительно безопаснее. ;

5. С точки зрения размера запроса длина запроса GET ограничена ограничением браузера или сервера на длину URL-адреса, а количество данных, разрешенных для отправки, относительно невелико, в то время как POST-запрос не имеет ограничений по размеру.

32. Процесс ввода URL-адреса в браузере для отображения домашней страницы?

1. Разрешение DNS: браузер запрашивает DNS для получения IP-адреса, соответствующего доменному имени: конкретный процесс включает в себя поиск браузером собственного кеша DNS, поиск в кеше DNS операционной системы, чтение локального файла хоста и запрос локального DNS. сервер. Для запроса к локальному DNS-серверу, если запрашиваемое доменное имя включено в ресурсы зоны локальной конфигурации, результат разрешения возвращается клиенту для завершения разрешения доменного имени (это разрешение является полномочным); если доменное имя для запроса находится не в разрешении зоны локального DNS-сервера, но сервер кэшировал это отношение сопоставления URL-адресов, затем вызовите сопоставление этого IP-адреса для завершения разрешения доменного имени (это разрешение не является полномочным). Если локальный сервер доменных имен не кэширует связь сопоставления URL-адресов, он инициирует рекурсивный или итеративный запрос в соответствии со своими настройками;

2. TCP-соединение: после того, как браузер получает IP-адрес, соответствующий доменному имени, браузер запрашивает сервер для установления связи и инициирует трехстороннее рукопожатие;

3. Отправить HTTP-запрос: после установления TCP-соединения браузер отправляет HTTP-запрос на сервер;

4. Сервер обрабатывает запрос и возвращает HTTP-сообщение: сервер получает запрос, сопоставляет его с конкретным обработчиком запросов для обработки в соответствии с параметрами пути и возвращает результат обработки и соответствующее представление в браузер;

5. Браузер анализирует и отображает страницу: браузер анализирует и отображает представление.Если он встречает ссылки на статические ресурсы, такие как файлы js, css и изображения, он повторяет вышеуказанные шаги и запрашивает эти ресурсы с сервера; данные отображают страницу и, наконец, представляют полную страницу пользователю.

6. Соединение завершается.

33. Что такое процесс разрешения DNS?

1. Запрос хоста к локальному серверу доменных имен обычно представляет собой рекурсивный запрос. Так называемый рекурсивный запрос: если локальный сервер доменных имен, запрашиваемый хостом, не знает IP-адрес запрошенного доменного имени, то локальный сервер доменных имен будет продолжать отправлять сообщение запроса на корневой сервер доменных имен. в качестве DNS-клиента (то есть продолжать запрашивать хост. ), вместо того, чтобы позволить хосту самому выполнить следующий запрос. Поэтому результатом запроса, возвращаемым рекурсивным запросом, является либо запрашиваемый IP-адрес, либо сообщение об ошибке, указывающее, что требуемый IP-адрес не может быть запрошен.

2. Итеративный запрос запроса локального сервера имен к корневому серверу имен. Особенности итеративного запроса: когда корневой сервер имен доменов получает сообщение с запросом итеративного запроса, отправленное локальным сервером доменных имен, он либо сообщает запрашиваемый IP-адрес, либо сообщает локальному серверу: «Какой сервер доменных имен вы должны запросить следующим ?" Затем позвольте локальному серверу выполнять последующие запросы. Корневой сервер имен доменов обычно сообщает локальному серверу имен доменов известный ему IP-адрес сервера имен доменов верхнего уровня, чтобы локальный сервер имен доменов мог запрашивать сервер имен доменов верхнего уровня. После получения запроса от локального сервера доменных имен сервер доменных имен верхнего уровня либо дает запрашиваемый IP-адрес, либо сообщает локальному серверу, какой полномочный сервер доменных имен следует запрашивать следующим. Наконец, локальный сервер доменных имен получает IP-адрес для разрешения или сообщает об ошибке, а затем возвращает результат хосту, инициировавшему запрос.

34. Расскажите о своем понимании кэширования доменных имен?

Чтобы повысить эффективность DNS-запросов, снизить нагрузку на сервер и уменьшить количество пакетов DNS-запросов в Интернете, на сервере доменных имен широко используется кэш для хранения недавно запрошенных доменных имен и записей, откуда получена информация о сопоставлении доменных имен.

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

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

35. Расскажите о своем понимании длинного и короткого соединения HTTP? К каким сценариям он применим?

Короткие соединения используются по умолчанию в HTTP/1.0. То есть каждый раз, когда клиент и сервер выполняют HTTP-операцию, устанавливается соединение, которое разрывается при завершении задачи. Когда веб-страница определенного HTML или другого типа, к которой обращается клиентский браузер, содержит другие веб-ресурсы (такие как: файлы JavaScript, файлы изображений, файлы CSS и т. д.), каждый раз, когда встречается такой веб-ресурс, браузер перезагружает Установите сеанс HTTP.

Начиная с HTTP/1.1, постоянные соединения используются по умолчанию для поддержания характеристик соединения. Эта строка кода будет добавлена в заголовок ответа с использованием протокола HTTP с длинным подключением.

Connection:keep-alive

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

Keep-Alive не удерживает соединение вечно, у него есть время удержания, которое можно установить в различном серверном ПО (например, в Apache). Реализация постоянного соединения требует, чтобы и клиент, и сервер поддерживали постоянные соединения.

36. Расскажите об основных изменениях HTTP 1.0, 1.1 и 1.2?

Основные изменения в HTTP 1.1:

1. HTTP 1.0 разрабатывался годами, и в версии 1.1 были предложены улучшения. Во-первых, предложить длинное соединение, HTTP может непрерывно отправлять запросы в TCP-соединении.

2. Затем HTTP1.1 поддерживает отправку только заголовка без отправки тела. Причина в том, что по заголовку определяется, успешен он или нет, а затем данные отправляются для экономии пропускной способности, собственно, почтовый запрос делает это по умолчанию.

3. Поле хоста HTTP1.1. Поскольку виртуальный хост может поддерживать несколько доменных имен, хост обычно получается после разрешения доменного имени.

Основные изменения HTTP2.0:

1. HTTP2.0 поддерживает мультиплексирование, и то же самое соединение может обрабатывать несколько запросов одновременно. Метод состоит в том, чтобы разделить пакет данных HTTP в несколько кадров, отправлять их одновременно и упорядоченным и реорганизовать их на другом конце в соответствии с порядковым номером, Без потребности в http-запросах прибывают последовательно;

2. HTTP2.0 поддерживает server push, то есть после поступления HTTP-запроса сервер отправляет клиенту дополнительный контент в дополнение к возвращаемым данным;

3. HTTP2.0 сжимает заголовок запроса, а основной единицей является двоичный поток кадров, который занимает меньше места;

4. HTTP2.0 подходит для сценариев HTTPS, поскольку добавляет уровень SSL между HTTP и TCP.

37. Каков рабочий процесс HTTPS?

1. Клиент отправляет поддерживаемые им правила шифрования на сервер, и представитель сообщает серверу о подключении;

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

3. После того, как клиент получает сертификат с веб-сайта, он делает следующее:

3.1 Проверить действительность сертификата;
3.2 Если сертификат проверен, браузер сгенерирует строку случайных чисел и зашифрует ее с помощью открытого ключа в сертификате;
3.3 Рассчитайте сообщение рукопожатия с помощью согласованного алгоритма хеширования, зашифруйте его сгенерированным ключом и вместе отправьте на сервер.

4. Сервер получает информацию, отправленную клиентом, и делает следующее:

4.1 Используйте закрытый ключ для анализа пароля, используйте пароль для анализа сообщения рукопожатия и проверьте, соответствует ли хеш-значение значению, отправленному браузером;
4.2 Шифровать сообщения с помощью ключей;

5. Если значения хэшей алгоритма совпадают, рукопожатие прошло успешно.

38. В чем разница между HTTP и HTTPS?

1. Накладные расходы: протокол HTTPS должен подать заявку на сертификат от центра сертификации.Как правило, бесплатных сертификатов очень мало, и они должны быть платными;

2. Потребление ресурсов: HTTP — это протокол передачи гипертекста, информация передается в виде открытого текста, а HTTPS — безопасный протокол передачи с шифрованием ssl, который потребляет больше ресурсов ЦП и памяти;

3. Разные порты: HTTP и HTTPS используют совершенно разные способы подключения, и используемые порты тоже разные: первый 80, второй 443;

4. Безопасность: HTTP-соединение очень простое и без сохранения состояния; HTTPS-протокол — это сетевой протокол, построенный на основе протокола TSL+HTTP, который может выполнять зашифрованную передачу и аутентификацию личности, что является более безопасным, чем протокол HTTP.

39. Каковы преимущества и недостатки HTTPS?

преимущество:

1. Используйте протокол HTTPS для аутентификации пользователей и серверов, чтобы гарантировать, что данные отправляются на правильный клиент и сервер;

2. Протокол HTTPS — это сетевой протокол, построенный на основе протокола SSL + HTTP, который может выполнять зашифрованную передачу и аутентификацию личности.Он более безопасен, чем протокол HTTP, что может предотвратить кражу и изменение данных в процессе передачи и обеспечить целостность данных;

3. HTTPS является наиболее безопасным решением в текущей архитектуре, хотя он и не является абсолютно безопасным, но значительно увеличивает стоимость атак типа «человек посередине».

недостаток:

1. Фаза рукопожатия протокола HTTPS требует много времени, что продлит время загрузки страницы почти на 50% и увеличит энергопотребление на 10-20%;

2. Кэширование HTTPS-соединений не так эффективно, как HTTP, что приведет к увеличению накладных расходов на передачу данных и энергопотребления, в результате чего пострадают даже существующие меры безопасности;

3. SSL-сертификаты требуют денег, чем мощнее сертификат, тем выше стоимость, для личных сайтов и небольших сайтов он не нужен.

4. SSL-сертификаты обычно должны быть привязаны к IP-адресу, а несколько доменных имен не могут быть привязаны к одному и тому же IP-адресу.Ресурсы IPv4 не могут поддерживать такое потребление;

5. Область шифрования протокола HTTPS также относительно ограничена и мало влияет на хакерские атаки, атаки типа «отказ в обслуживании» и захват сервера. Что наиболее важно, система кредитной цепочки SSL-сертификатов небезопасна, особенно в случае, если некоторые страны могут контролировать корневой сертификат ЦС, атаки «человек посередине» также возможны.

40. Что такое цифровая подпись?

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

41. Что такое цифровой сертификат?

При симметричном шифровании обе стороны используют открытый ключ для расшифровки. Хотя цифровая подпись может гарантировать, что данные не будут заменены, данные шифруются открытым ключом.Если открытый ключ также заменен, данные все равно могут быть подделаны, поскольку пользователь не знает, что открытый ключ, предоставленный другим партия на самом деле фейк. Следовательно, чтобы убедиться, что открытый ключ отправителя является истинным, центр сертификации ЦС будет нести ответственность за выдачу сертификата, а открытый ключ внутри гарантированно будет истинным.Когда пользователь запрашивает сервер, сервер выдает сертификат пользователю, и этот сертификат получен через встроенный сертификат системы.

42. Что такое симметричное шифрование и асимметричное шифрование?

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

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

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