Самые полные тестовые вопросы - статьи о компьютерных сетях (обязательны для каждого разработчика)

Самый полный в истории, не приемлю опровержения! ! ! ! ! ! ! PDF-версия также приведена в конце статьи.

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

Когда интервьюер спросит вас, зачем нужно три рукопожатия, роль трех рукопожатий и расскажите о трех трехсторонних рукопожатиях, думаю, многие ответят так:

Во-первых, многие сначала расскажут о процессе рукопожатия:

1. Первое рукопожатие: клиент отправляет серверу сообщение SYN.

2. Второе рукопожатие: после того, как сервер получит сообщение SYN, он ответит сообщением SYN+ACK.

3. Третье рукопожатие: после того, как клиент получит сообщение SYN+ACK, он ответит сообщением ACK.

4. После получения сервером сообщения ACK устанавливается трехстороннее рукопожатие.

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

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

Второе рукопожатие: сервер отправляет пакет, а клиент его получает. Таким образом, клиент может прийти к выводу, что возможности приема и отправки сервера и возможности приема и отправки клиента являются нормальными. Однако в настоящее время сервер не может подтвердить, нормальная ли приемная способность клиента.

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

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

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

В начале клиент находится в закрытом состоянии, а сервер в состоянии прослушивания. потом

1. Первое рукопожатие: клиент отправляет SYN-сообщение на сервер и указывает порядковый номер инициализации клиентаISN(c). В этот момент клиент находится вSYN_Sendусловие.

2. Второе рукопожатие: после того, как сервер получит сообщение SYN от клиента, он ответит своим собственным сообщением SYN, а также укажет свой собственный порядковый номер ISN инициализации, а также будет использовать ISN + 1 клиента в качестве Значение ACK указывает на то, что он получил SYN от клиента, и сервер находится в состоянииSYN_REVDстатус.

3. Третье рукопожатие: после того, как клиент получит сообщение SYN, он отправит сообщение ACK.Конечно, он также использует ISN + 1 сервера в качестве значения ACK, указывая, что сообщение SYN от сервера было получено , клиент находится вestablisedусловие.

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

Роль трехстороннего рукопожатия

Функций тройного рукопожатия также много, запомните еще несколько, чтобы не потерять. Например:

1. Подтвердите, являются ли возможности приема и отправки обеих сторон нормальными.

2. Укажите собственный порядковый номер инициализации для подготовки к последующей надежной передаче.

1. Фиксирован ли (ISN)?

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

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

2. Что такое очередь полусоединений

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

Вот еще немного оВремя повторной передачи SYN-ACKПроблема: после того, как сервер отправляет пакет SYN-ACK, если он не получает пакет подтверждения клиента, сервер повторно передает его в первый раз, ждет некоторое время и не получает пакет подтверждения клиента и выполняет вторая повторная передача Если количество повторных передач превышает установленное системой максимальное количество повторных передач, система удаляет информацию о соединении из очереди полусоединений. Обратите внимание, что время ожидания для каждой повторной передачи не обязательно одинаково и обычно увеличивается экспоненциально, например, время интервала составляет 1 с, 2 с, 4 с, 8 с,

3. Можно ли передавать данные во время трехэтапного рукопожатия?

Многие могут подумать, что трехстороннее рукопожатие не может передавать данные, но на самом деле во время третьего рукопожатия данные могут передаваться. То есть первое и второе рукопожатия не могут передавать данные, а третье рукопожатие может передавать данные.

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

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

2. Скажи что-нибудь и помаши рукой четыре раза

То же самое касается четырехкратного махания руками: никогда не отправляйте сообщение FIN с другой стороны, сообщение ACK с нашей стороны, сообщение FIN с нашей стороны и сообщение ACK с нашей стороны. Затем конец, лучше немного подробнее, например, он почти такой же, как следующий.условиеПомните, меня несколько раз спрашивали в моем последнем интервью, ха-ха. Я ответил неправильно и думал, что был прав, но в то время я объяснил это прямо, ха-ха.

В начале обе стороны находятся в установленном состоянии.Если клиент первым инициирует запрос на отключение, то:

1. Первая волна: клиент отправляет сообщение FIN, в сообщении указывается серийный номер. В этот момент клиент находится вCLOSED_WAIT1условие.

2. Второе рукопожатие: после того, как сервер получит FIN, он отправит сообщение ACK и использует значение серийного номера клиента + 1 в качестве значения серийного номера сообщения ACK, указывая, что он получил сообщение клиента. сервер времени включенCLOSE_WAIT2условие.

3. Третья волна: Если сервер тоже хочет отключиться, как и первая волна клиента, отправьте сообщение FIN и укажите серийный номер. В это время сервер находится вLAST_ACKстатус.

4. Четвертая волна: после того, как клиент получает FIN, он также отправляет сообщение ACK в качестве ответа и использует значение серийного номера сервера + 1 в качестве значения серийного номера своего собственного сообщения ACK. вTIME_WAITусловие. Потребуется некоторое время, чтобы убедиться, что сервер не перейдет в состояние CLOSED, пока не получит собственное сообщение ACK.

5. После того, как сервер получает сообщение ACK, он закрывает соединение и находится в состоянии CLOSED.

Главное, что здесь особенно необходимо, этоTIME_WAITВ таком состоянии это высокочастотный тестовый сайт для интервью, чтобы понять, почему клиент не закрывается сразу после отправки ACK, а ждет какое-то время, чтобы закрыться. Причина этого заключается в том, чтобы убедиться, что сервер получил наше сообщение ACK. Если нет, сервер повторно отправит сообщение FIN клиенту. После того, как клиент снова получит сообщение FIN, он узнает, что предыдущее сообщение ACK потеряно, а затем снова отправляется сообщение ACK.

Что касается длительности TIME_WAIT, то это как минимум время прохождения одного сообщения туда и обратно. Как правило, устанавливается таймер.Если сообщение FIN не получено снова по истечении этого времени, это означает, что другой стороне удалось получить сообщение ACK, и он находится в состоянии CLOSED.

Здесь я даю значение каждого состояния, вы можете посмотреть, если вам интересно.

LISTEN - прослушивать запросы на подключение от удаленных портов TCP;

SYN-SENT — дождаться соответствующего запроса на соединение после отправки запроса на соединение;

SYN-RECEIVED - дождаться подтверждения запроса на соединение после получения и отправки запроса на соединение;

ESTABLISHED - представляет собой открытое соединение, данные могут быть отправлены пользователю;

FIN-WAIT-1 — дождаться запроса на прерывание соединения от удаленного TCP или подтверждения предыдущего запроса на прерывание соединения;

FIN-WAIT-2 - дождаться запроса на прерывание соединения от удаленного TCP;

CLOSE-WAIT - дождаться запроса на разрыв соединения от локального пользователя;

ЗАКРЫТИЕ — ожидание подтверждения разрыва соединения удаленным TCP;

LAST-ACK — дождаться подтверждения запроса на прерывание соединения, первоначально отправленного на удаленный TCP;

TIME-WAIT — выжидает достаточное время, чтобы удаленный TCP получил подтверждение запроса на прерывание соединения;

ЗАКРЫТО - состояние соединения отсутствует;

3. Расскажите о разнице между POST и GET

сцены, которые будут использоваться

GET используется для получения ресурса, а POST используется для передачи тела объекта.

параметр

Как запросы GET, так и запросы POST могут использовать дополнительные параметры, но параметры GET отображаются в URL-адресе в виде строк запроса, а параметры POST хранятся в теле объекта. Тот факт, что параметры POST хранятся в теле объекта, не может считаться более безопасным, потому что его все еще можно просмотреть с помощью некоторых инструментов захвата пакетов (Fiddler).

Поскольку URL-адрес поддерживает только код ASCII, если в параметре GET есть китайские символы, его необходимо сначала закодировать. Например中文превратится в%E4%B8%AD%E6%96%87, а пробелы преобразуются в%20. Параметры POST поддерживают стандартные наборы символов.

GET /test/demo_form.asp?name1=value1&name2=value2 HTTP/1.1Copy to clipboardErrorCopied
POST /test/demo_form.asp HTTP/1.1
Host: w3schools.com
name1=value1&name2=value2Copy to clipboardErrorCopied

безопасность

Безопасный метод HTTP не изменяет состояние сервера, что означает, что он доступен только для чтения.

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

Помимо GET безопасными методами являются: HEAD, OPTIONS.

Помимо POST, к небезопасным методам относятся PUT и DELETE.

идемпотентность

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

Все безопасные методы также идемпотентны.

При правильной реализации такие методы, как GET, HEAD, PUT и DELETE, являются идемпотентными, а метод POST — нет.

GET /pageX HTTP/1.1 является идемпотентным, и если он вызывается несколько раз подряд, результат, получаемый клиентом, будет одинаковым:

GET /pageX HTTP/1.1
GET /pageX HTTP/1.1
GET /pageX HTTP/1.1
GET /pageX HTTP/1.1Copy to clipboardErrorCopied

POST /add_row HTTP/1.1 не является идемпотентным, если он вызывается несколько раз, он добавит несколько строк записей:

POST /add_row HTTP/1.1   -> Adds a 1nd row
POST /add_row HTTP/1.1   -> Adds a 2nd row
POST /add_row HTTP/1.1   -> Adds a 3rd rowCopy to clipboardErrorCopied

DELETE /idX/delete HTTP/1.1 является идемпотентным, даже если разные запросы получают разные коды состояния:

DELETE /idX/delete HTTP/1.1   -> Returns 200 if idX exists
DELETE /idX/delete HTTP/1.1   -> Returns 404 as it just got deleted
DELETE /idX/delete HTTP/1.1   -> Returns 404Copy to clipboardErrorCopied

кэшируемый

Если вы хотите кэшировать ответ, необходимо выполнить следующие условия:

Сам HTTP-метод сообщения запроса кэшируется, включая GET и HEAD, но PUT и DELETE не кэшируются, а POST в большинстве случаев не кэшируется.
Коды состояния пакета ответа можно кэшировать, в том числе: 200, 203, 204, 206, 300, 301, 404, 405, 410, 414 и 501.
В поле заголовка Cache-Control ответного сообщения не указано, что кэширование не требуется.

XMLHttpRequest

Чтобы проиллюстрировать еще одно различие между POST и GET, необходимо сначала понять XMLHttpRequest:

XMLHttpRequest — это API, который предоставляет клиентам возможность передавать данные между клиентом и сервером. Он обеспечивает простой способ получения данных по URL-адресу без обновления всей страницы. Это позволяет веб-странице обновлять только часть страницы, не беспокоя пользователя. XMLHttpRequest активно используется в AJAX.

При использовании метода POST XMLHttpRequest браузер сначала отправит заголовок, а затем данные. Но не все браузеры так делают, например Firefox нет.
И заголовок метода GET, и данные будут отправлены вместе.

Кроме того, они были организованы в PDF-файлы и отправлены вам:500 вопросов для интервью, которые вы должны знать (с ответами)

4. Интервьюер: Расскажите о разнице между TCP и UDP.

Основные возможности протокола TCP

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

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

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

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

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

Принцип надежности TCP

Надежная передача имеет следующие две характеристики:

А. Канал передачи безошибочен, чтобы гарантировать правильность данных передачи;

б) как бы быстро отправитель ни отправлял данные, получатель всегда успевает обработать полученные данные;

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

(2) Во-вторых, TCP использует непрерывный протокол ARQ (go-back-N; автоматическая повторная передача с течением времени) для обеспечения правильности передачи данных и использует протокол скользящего окна для обеспечения своевременной обработки получателем полученных данных. данные для управления потоком.

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

Возможности протокола UDP

(1) UDP — это протокол транспортного уровня без установления соединения;

(2) UDP прилагает все усилия для доставки и не гарантирует надежную доставку;

(3) UDP ориентирован на сообщения, и сообщение, доставляемое прикладным уровнем, не объединяется и не разделяется, а граница исходного сообщения сохраняется;

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

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

(6) Заголовок UDP невелик, всего 8 байт.

Разница между TCP и UDP

(1) TCP — это надежная передача, а UDP — ненадежная передача;

(2) TCP с установлением соединения, UDP без установления соединения;

(3) TCP передает данные по порядку, UDP не гарантирует порядок данных;

(4) TCP не сохраняет границы данных, а UDP сохраняет границы данных;

(5) скорость передачи TCP ниже, чем UDP;

(6) TCP имеет управление потоком и контроль перегрузки, а UDP — нет;

(7) TCP — это тяжеловесный протокол, а UDP — это облегченный протокол;

(8) заголовок TCP на 20 байт длиннее, а заголовок UDP на 8 байт короче;

Общие протоколы на основе TCP и UDP

Протоколы HTTP, HTTPS, FTP, TELNET, SMTP (Simple Mail Transfer Protocol) основаны на надежном протоколе TCP. TFTP, DNS, DHCP, TFTP, SNMP (простой протокол управления сетью), RIP на основе ненадежного протокола UDP

Есть много общих сценариев для TCP и UDP, например, когда я проходил собеседование, меня спросили: TCP и UDP используются в процессе входа в QQ, а как насчет вызовов QQ?

5. Вопросы для интервью: расскажите о разнице между HTTP 1.0, 1.1 и 2.0.

HTTP/1.0

В мае 1996 г. была выпущена версия HTTP/1.0.Чтобы повысить эффективность системы,HTTP/1.0 предусматривает, что браузер и сервер поддерживают только кратковременное соединение.Каждый запрос браузера должен установить TCP-соединение с сервером, и сервер немедленно отключает TCP-соединение после завершения обработки запроса., сервер не отслеживает каждого клиента и не регистрирует прошлые запросы.

Этот метод похож на то, когда мы разговариваем по телефону, мы можем сказать только одно, после того, как мы закончили говорить, мы должны повесить трубку, а когда мы хотим сказать что-то еще, мы должны позвонить снова.

В HTTP/1.0 браузер и сервер поддерживают только кратковременное соединение, и это соединение нельзя использовать повторно. Другими словами, на одно TCP-соединение может быть отправлен только один запрос. После отправки данных соединение закрывается.Если вы хотите запросить другие ресурсы, необходимо создать новое соединение.

Мы знаем, что для установления TCP-соединения требуется трехстороннее рукопожатие, что занимает много времени. Поэтому производительность версии HTTP/1.0 относительно низкая.

HTTP1.0 может принудительно открывать длинные ссылки, например приниматьConnection: keep-aliveОднако это поле не является стандартным полем и может вести себя непоследовательно в разных реализациях, поэтому оно не является фундаментальным решением.

HTTP/1.1

Чтобы устранить недостатки HTTP/1.0, HTTP/1.1 родился в 1999 году. По сравнению с HTTP/1.0 основным улучшением является введение постоянных соединений. Так называемое постоянное соединениеTCP-соединения не закрываются по умолчанию и могут быть мультиплексированы несколькими запросами..

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

Когда клиент и сервер обнаруживают, что другая сторона не была активна в течение определенного периода времени, они могут активно закрыть соединение. Или клиент активно говорит серверу закрыть соединение во время последнего запроса.

Версия HTTP/1.1 также представила конвейерный механизм (pipelining), то есть в одном и том же TCP-соединении клиент может отправлять несколько запросов одновременно. Это еще больше повышает эффективность протокола HTTP.

Благодаря постоянным соединениям и каналам эффективность HTTP значительно повышается. Однако сервер по-прежнему выполняется последовательно, и еще есть возможности для повышения эффективности.

HTTP/2

HTTP/2 — это первое обновление протокола HTTP после выпуска HTTP 1.1 в 1999 году, в основном основанное на протоколе SPDY.

HTTP/2 Чтобы решить проблему эффективности, которая все еще существует в HTTP/1.1, HTTP/2 принимаетмультиплексирование. То есть в соединении и клиент, и браузер могут отправлять несколько запросов или ответов одновременно, и в порядке нет однозначного соответствия. Для этого есть обязательное условие, то есть реализован HTTP/2.Бинарное кадрирование, то есть HTTP/2 разделит всю передаваемую информацию на более мелкие сообщения и кадры и закодирует их в двоичном формате.

То есть начальник может отдать несколько приказов одновременно, а сотрудник может также получить запрос А и запрос Б, поэтому он сначала отвечает на запрос А, но получается, что процесс обработки очень длительный. -потребление, поэтому он отправляет обработанную часть запроса A, затем отвечает на запросы B, а после завершения отправляет оставшуюся часть запроса A. Ответ, состоящий из двух частей, на запрос А объединяется и отправляется начальнику.

И этот слой, отвечающий за разбиение, сборку запросов и бинарных фреймов, называетсяДвоичный слой кадрирования.

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

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

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

В настоящее время основными протоколами HTTP по-прежнему являются HTTP/1.1 и HTTP/2. Уровень использования HTTP/2 на основных веб-сайтах также увеличивается с каждым годом.

6. Что такое SQL-инъекция? Например?

SQL-инъекция заключается в том, чтобы заставить сервер выполнять вредоносные SQL-команды, вставляя SQL-команды в строку запроса отправки веб-формы или вводя доменное имя или запрос страницы.

1) Общая идея атаки SQL инъекции

(1) Найдите место SQL-инъекции (2) Определите тип сервера и тип фоновой базы данных. (3) Атаки путем внедрения SQL-кода против необоснованных характеристик сервера и базы данных.

2) Примеры атак SQL-инъекциями

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

用户名： ‘or 1 = 1 --
密 码：

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

Давайте проанализируем это: Теоретически в программе фоновой аутентификации будут следующие операторы SQL:

String sql = “select * from user_table where username=’ “+userName+” ’ and password=’ “+password+” ‘”;

Следовательно, когда вводятся указанные выше имя пользователя и пароль, указанный выше оператор SQL становится следующим:

SELECT * FROM user_table WHERE username=’’or 1 = 1 –- and password=’’

Анализируя приведенный выше оператор SQL, мы знаем, что оператор username=' или 1=1 будет успешным; затем добавьте два -, что означает комментарий, он прокомментирует следующие операторы, чтобы они не работали. Таким образом, приведенное выше утверждение всегда может быть выполнено правильно, и пользователь может легко обмануть систему и получить юридическую личность.

3) Методы преодоления

(1) Привязка параметров

Используя предварительно скомпилированные средства, привязка параметров — лучший способ предотвратить SQL-инъекцию. В настоящее время во многих ORM-фреймворках и JDBC реализованы функции предварительной компиляции SQL и привязки параметров.Вредоносный SQL злоумышленника будет выполняться как параметры SQL, а не команды SQL. В файле сопоставления mybatis мы обычно используем # и $, чтобы получить значение параметра для переданных параметров. Когда используется #, переменная является заполнителем, который обычно является заполнителем, когда мы используем PrepareStatement javajdbc, все из которых могут предотвратить внедрение SQL; при использовании $ переменная добавляется непосредственно к SQL, и обычно есть проблема с SQL-инъекцией.

(2) Используйте регулярные выражения для фильтрации входящих параметров.

7. Расскажите, например, об атаках XSS?

XSS — это уязвимость компьютерной безопасности, которая часто появляется в веб-приложениях, и вместе с внедрением SQL она стала наиболее распространенным методом атак в Интернете.

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

1) Вред XSS-атаки

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

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

Кража важной и коммерчески ценной информации у компании

незаконная передача

Электронная почта принудительно

Висячая лошадь на сайте

Контролируйте компьютер жертвы, чтобы запускать атаки на другие веб-сайты

2) Анализ причин

Основная причина: слишком большое доверие к данным, представленным клиентом!

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

Дальнейший анализ деталей: данные, отправленные клиентом, изначально требуются приложению, но злоумышленники используют доверие веб-сайта к данным, отправленным клиентом, чтобы вставить в данные некоторые символы и код javascript, после чего эти данные станут часть кода приложения, то злоумышленник может начать атаку недобросовестно, поэтому мы никогда не должны доверять данным, предоставленным любым клиентом! ! !

3) Классификация XSS-атак

(1) Отражающая XSS-атака (непостоянная XSS-атака).

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

http://www.test.com/message.php?send=Hello,World！

Получатель получит сообщение и отобразит Hello, World, однако сообщение не будет отправлено нормально:

http://www.test.com/message.php?send=<script>alert(‘foolish!’)</script>！

Когда получатель получит сообщение, появится всплывающее окно с предупреждением!

(2) Постоянная XSS-атака (сценарий доски объявлений)

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

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

Например, поля формы в форме доски объявлений:

<input type="text" name="content" value="这里是用户填写的数据">

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

<script>alert(‘foolish!’)；</script> <!--或者html其他标签（破坏样式。。。）、一段攻击型代码-->

Отправьте и сохраните данные в базе данных; когда другие пользователи извлекут данные и отобразят их, эти оскорбительные коды будут выполнены.

4) Политика устранения уязвимостей

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

Отметьте важные файлы cookie только как http, чтобы оператор document.cookie в Javascript не мог получить файл cookie (если в файле cookie установлен атрибут HttpOnly, информация о файлах cookie не может быть прочитана через сценарий js, что может эффективно предотвратить атаки XSS);

Данные формы определяют тип значения, например: age должен быть только int, name должен быть только буквенно-цифровой комбинацией. . . .

Html Encode обработка данных

Отфильтруйте или удалите специальные HTML-теги, например:

<script>, <iframe> , < for <, > for>, &quot for

Теги, фильтрующие события JavaScript, такие как «οnclick=", «onfocus» и т. д.

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

8. Что делать, если я не хочу разрывать соединение в процессе взаимодействия, как его сохранить?

Укажите keep-alive в поле Connection тела ответа в HTTP.

connetion:keep-alive;

9. Значение кодирования URL в GET-запросах

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

На примере «имя1=значение1&имя2=значение2» поговорим о процессе парсинга данных от клиента к серверу. Во-первых, приведенная выше строка представлена в ASCII на компьютере как:

   6E616D6531 3D 76616C756531 26 6E616D6532 3D 76616C756532
   6E616D6531：name1 
   3D：= 
   76616C756531：value1 
   26：&
   6E616D6532：name2 
   3D：= 
   76616C756532：value2

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

Теперь рассмотрим такой вопрос, а что если наше значение параметра содержит спецсимволы типа = или &? Например, «имя1=значение1», где значением значения1 является строка «va&lu=e1», тогда в процессе передачи оно фактически станет «name1=va&lu=e1». Таким образом, наше первоначальное намерение состояло в том, чтобы иметь только одну пару ключ-значение, но сервер разрешит ее в две пары ключ-значение, что создает двусмысленность.

Итак, как решить двусмысленность, вызванную вышеуказанными проблемами? Решение состоит в URL-кодировании параметров: например, мы URL-кодируем приведенные выше неоднозначные символы: «name1=va%26lu%3D», чтобы сервер поместил слово сразу после «%». Разделы обрабатываются как обычные байт, то есть они не рассматриваются как разделители для параметров или пар ключ-значение

10. Каковы общие коды состояния HTTP и сценарии использования?

Классификация кодов состояния

1xx: указывает, что в настоящее время протокол находится в промежуточном состоянии, и требуются последующие запросы.

2xx: указывает, что запрос был успешным

3xx: указывает статус перенаправления и требует повторного запроса.

4xx: указывает, что сообщение запроса неверно.

5xx: ошибка на стороне сервера

Общие коды состояния

101 Переключить протокол запроса, переключиться с HTTP на WebSocket

200 Запрос был успешным с телом ответа

301 Постоянное перенаправление: будет кэшироваться

302 Временное перенаправление: не будет кэшироваться

304 Обсудить попадание в кеш

403 Сервер запрещен

404 Ресурс не найден

400 Ошибка запроса

500 ошибка на стороне сервера

503 Сервер занят

11. Как HTTP реализует длинное соединение? Когда истечет время?

Установив Connection: keep-alive в заголовке (заголовок запроса и ответа), протокол HTTP1.0 поддерживает его, но по умолчанию он закрыт.Начиная с протокола HTTP1.1, соединение по умолчанию является длинным соединением.

1. HTTP обычно имеет процесс демона httpd, который может установить тайм-аут для поддержания активности.Когда tcp-ссылка простаивает более этого времени, она будет закрыта.Вы также можете установить время тайм-аута в заголовке HTTP.

2. Keep-alive TCP содержит три параметра, которые можно установить в net.ipv4 ядра системы: когда TCP-ссылка простаивает и tcp_keepalive_time простаивает, будет происходить пакет обнаружения. отправлено, ссылка будет удалена.

(1) tcp_keepalive_intvl = 15 (2) tcp_keepalive_probes = 5 (3) tcp_keepalive_time = 1800

На самом деле в HTTP нет длинных и коротких ссылок, они есть только в TCP. Длинное соединение TCP может повторно использовать ссылку TCP для инициирования нескольких HTTP-запросов, что может снизить потребление ресурсов. Например, если вы запрашиваете HTML один раз, вы также можете необходимо запросить последующие JS/CSS/изображения и т. д.

12. В чем разница между кодами состояния HTTP 301 и 302?

1. Концепция перенаправления 301

301 Redirect (301 Move Permanently) относится к постоянному переносу страницы, что означает, что ресурс или страница постоянно переносятся в другое место. 301 — это код состояния в протоколе HTTP. Когда пользователь или поисковая система отправляет запрос на просмотр на сервер, поток данных HTTP, возвращаемый сервером, включает в себя код состояния 301 в заголовке, указывающий, что ресурс навсегда изменил свой место нахождения.

Перенаправление 301 — очень важная технология «автоматического перенаправления», а перенаправление URL-адресов — наиболее подходящий метод.

2. В каких случаях нужно делать 301 редирект?

В процессе разработки веб-страницы часто приходится сталкиваться с тем, что структура каталога сайта корректируется, и страница переносится на новый адрес, смена расширения веб-страницы влечет за собой изменение адреса веб-страницы. Адрес указан неверно, и после посещения появится страница 404, что напрямую ведет к потере трафика сайта. Или нам нужно несколько доменных имен, чтобы перейти на одно и то же доменное имя, например, доменное имя основного сайта этого сайтаwww.conimi.comи доменное имяwww.nico.cc, из-за перенаправления 301, установленного для доменного имени, при входе на www.nico.cc, автоматически перейти кwww.conimi.com.

3. Каковы преимущества переадресации 301?

Полезно определить предпочтительный домен веб-сайта, а переадресация 301 для нескольких путей одной и той же страницы ресурса полезна для концентрации весов URL. Напримерwww.conimi.com иconimi.com — это два разных доменных имени, но содержание, на которое они указывают, абсолютно одинаковое, поисковые системы будут индексировать два доменных имени по-разному, что приведет к разбросу веса и рейтинга веб-сайта; выполните перенаправление 301 на conimi.com и перейти на www.com После conimi.com вес и рейтинг будут сконцентрированы на www.conimi.com, тем самым улучшив естественный рейтинг.

4. Что, черт возьми, такое перенаправление 302?

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

5. Разница между 301 и 302

301 редирект — это постоянная передача страницы, когда поисковая система сканирует новый контент, она также заменяет старый URL-адрес перенаправленным URL-адресом;

Перенаправление 302 — это временная передача страницы. Поисковые системы будут сканировать новый контент и сохранять старый URL-адрес, а новый URL-адрес будет считаться временным.

13. Каковы классификации IP-адресов?

Адрес класса A (1~126): номер сети занимает первые 8 бит, начиная с 0, а номер хоста занимает последние 24 бита.

Адрес класса B (128~191): номер сети занимает первые 16 цифр, начиная с 10, а номер хоста занимает последние 16 цифр.

Адрес класса C (192~223): номер сети занимает первые 24 цифры, начиная со 110, а номер хоста занимает последние 8 цифр.

Адреса класса D (224~239): начиная с 1110, зарезервированы для многоадресных адресов.

Адрес класса E (240~255): начните с 1111, биты зарезервированы для будущего использования.

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

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

15. Как работает протокол 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 не выполнен.

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

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

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

UDP не требует установления соединения;
UDP использует доставку с наилучшими усилиями, т.е. надежная доставка не гарантируется, поэтому хосту не нужно поддерживать сложное состояние канала (в нем много параметров);
UDP ориентирован на сообщения;
UDP не контролирует перегрузку, поэтому перегрузка сети не снизит скорость отправки хоста-источника (полезно для приложений реального времени, таких как прямые трансляции, видеоконференции в реальном времени и т. д.);
UDP поддерживает интерактивную связь «один к одному», «один ко многим», «многие к одному» и «многие ко многим»;
Заголовок UDP имеет небольшие служебные данные, всего 8 байтов, что короче 20-байтового заголовка TCP.

18. Какие общие протоколы прикладного уровня соответствуют 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.

19. Почему состояние 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 все сегменты, сгенерированные за время соединения, могут исчезнуть из сети. Таким образом, этот старый сегмент запроса на соединение не появится в следующем соединении.

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

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

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

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

Проверка пакета: Цель состоит в том, чтобы обнаружить любые изменения в данных во время передачи. Если при проверке пакета возникает ошибка, пакет будет отброшен, и ответ не будет дан. В это время TCP повторно передаст данные после время ожидания терминала данных истекло;
Переупорядочивание неупорядоченных пакетов: поскольку сегменты TCP передаются как дейтаграммы IP, а дейтаграммы IP могут поступать не по порядку, сегменты TCP также могут приходить не по порядку. TCP переупорядочивает неупорядоченные данные перед передачей их на прикладной уровень;
Отбросить дубликаты данных: для повторяющихся данных можно удалить повторяющиеся данные;
Механизм подтверждения: когда TCP получает данные с другого конца соединения TCP, он отправляет подтверждение. Это подтверждение не отправляется немедленно, обычно оно задерживается на долю секунды;
Тайм-аут повторной передачи: когда TCP отправляет сегмент, он запускает таймер и ожидает, пока пункт назначения подтвердит получение сегмента. Если подтверждение не может быть получено вовремя, сегмент будет отправлен повторно;
Управление потоком: каждая сторона TCP-соединения имеет буферное пространство фиксированного размера. Принимающая сторона TCP позволяет другой стороне отправлять столько данных, сколько может вместить буфер получателя.Это предотвращает переполнение буферов более медленных узлов более быстрыми узлами.Это управление потоком. Протокол управления потоком, используемый TCP, представляет собой протокол скользящего окна переменного размера.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

специальное управление персонажем;
Добавьте длину пакета в заголовок пакета.

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

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

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

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

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

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

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

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

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

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

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

GET: получить ресурсы, большинство современных сетей используют GET;
HEAD: получает заголовок сообщения, аналогично методу GET, но не возвращает тело объекта сообщения;
POST: передать тело объекта
PUT: Загрузить файл.Поскольку у него нет механизма проверки, любой может загрузить файл, поэтому возникают проблемы с безопасностью, и этот метод обычно не используется.
ИСПРАВЛЕНИЕ: Частично изменить ресурс. PUT также можно использовать для изменения ресурса, но он может только полностью заменить исходный ресурс, а PATCH допускает частичную модификацию.
ВАРИАНТЫ: Запросить методы, поддерживаемые указанным URL-адресом;
CONNECT: требует установки туннеля при обмене данными с прокси-сервером. Используйте протоколы SSL (Secure Sockets Layer, Secure Sockets Layer) и TLS (Transport Layer Security, Transport Layer Security) для шифрования содержимого связи и его передачи через сетевой туннель.
TRACE: Проследите путь. Сервер возвращает путь связи клиенту. При отправке запроса заполните значение в поле заголовка Max-Forwards, которое будет уменьшаться на 1 каждый раз, когда оно проходит через сервер, и прекратите передачу, когда значение будет равно 0. TRACE обычно не используется и уязвим для XST-атак (Cross-Site Tracing).

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

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

33. Процесс разрешения DNS?

Запрос хоста к локальному серверу доменных имен обычно представляет собой рекурсивный запрос. Так называемый рекурсивный запрос: если локальный сервер доменных имен, запрашиваемый хостом, не знает IP-адрес запрошенного доменного имени, то локальный сервер доменных имен будет продолжать отправлять сообщение запроса на корневой сервер доменных имен. в качестве DNS-клиента (то есть продолжать запрашивать хост. ), вместо того, чтобы позволить хосту самому выполнить следующий запрос. Поэтому результатом запроса, возвращаемым рекурсивным запросом, является либо запрашиваемый IP-адрес, либо сообщение об ошибке, указывающее, что требуемый IP-адрес не может быть запрошен.
Итеративный запрос локального сервера имен к корневому серверу имен. Особенности итеративного запроса: когда корневой сервер имен доменов получает сообщение с запросом итеративного запроса, отправленное локальным сервером доменных имен, он либо сообщает запрашиваемый 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. Каков рабочий процесс HTTPS?

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

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

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

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

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

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

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

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

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

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

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

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

недостаток:

Фаза рукопожатия протокола HTTPS требует много времени, что увеличивает время загрузки страницы почти на 50% и увеличивает энергопотребление на 10–20%;
Кэширование HTTPS-соединений не так эффективно, как HTTP, что приведет к увеличению накладных расходов на данные и энергопотреблению, и в результате будут затронуты даже существующие меры безопасности;
Сертификаты SSL стоят денег.Чем мощнее сертификат, тем выше стоимость.Личные веб-сайты и небольшие веб-сайты обычно не используют его;
SSL-сертификаты обычно должны быть привязаны к IP-адресу, а несколько доменных имен не могут быть привязаны к одному и тому же IP-адресу.Ресурсы IPv4 не могут поддерживать такое потребление;
Область шифрования протокола HTTPS также относительно ограничена, и он не играет большой роли в хакерских атаках, атаках типа «отказ в обслуживании», захвате серверов и т. д. Что наиболее важно, система кредитной цепочки SSL-сертификатов небезопасна, особенно в случае, если некоторые страны могут контролировать корневой сертификат ЦС, атаки «человек посередине» также возможны.

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

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

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

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

41. В чем разница между файлами cookie и сеансом?

1. Поскольку протокол HTTP является протоколом без сохранения состояния, когда серверу необходимо записать статус пользователя, ему необходимо использовать механизм для идентификации конкретного пользователя.Этот механизм — сеанс.Типичный сценарий — корзина покупок.

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

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

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

Кто-то спросил, а что если в браузере клиента отключены куки? В этом случае для отслеживания сеанса используется метод, называемый перезаписью URL-адресов, то есть для каждого HTTP-взаимодействия к URL-адресу добавляется такой параметр, как sid=xxxxx, и сервер соответствующим образом идентифицирует пользователя.

3. Файлы cookie действительно можно использовать в некоторых удобных для пользователя сценариях.Предположим, вы вошли на веб-сайт один раз и не хотите снова входить в свою учетную запись при следующем входе.Что вам следует делать? Эта информация может быть записана в куки, при посещении сайта скрипт страницы сайта может прочитать эту информацию и автоматически подставить вам имя пользователя, что удобно пользователю. Это также происхождение имени файла cookie, немного сладкого для пользователя.

Итак, резюмируя:

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

Cookie — это механизм сохранения клиентом информации о пользователе, который используется для записи некоторой информации о пользователе, а также способ реализации сеанса.

Кроме того, вот другие вопросы интервью

Руководство по чтению вопросов для собеседования по основам Java

Руководство по чтению вопросов для собеседования по Java Exception

Руководство по чтению вопросов для собеседования по коллекциям Java

Руководство по чтению вопросов для собеседования по Java Concurrency

Руководство по чтению вопросов интервью JVM

Руководство по чтению вопросов для собеседования по SSM Framework

Руководство по чтению вопросов на собеседовании по операционной системе (обязательно к просмотру)

Руководство по чтению вопросов для собеседования по компьютерным сетям (обязательно к просмотру)

Java Interview Questions Руководство по чтению вопросов для интервью (Обязательно к просмотру)

Руководство по чтению вопросов для собеседования с MySQL (обязательно к просмотру)

Руководство по чтению вопросов интервью Redis (обязательно к просмотру)

Руководство по чтению вопросов об очереди сообщений и интервью с Zookeeper (обязательно к просмотру)

Это нелегко организовать, если вы найдете это полезным, не забудьте поставить лайк @shuaidi.