прикладной уровень

Зачем вводить прикладной уровень

Определяет спецификацию содержимого для передачи между процессами.

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

HTTP-протокол

https

http длинные и короткие ссылки

Для стандарта HTTP HTTP 1.0 по умолчанию используется короткое соединение.Что такое короткое соединение? То есть сервер закроет соединение после отправки последнего байта данных, то есть переработает структуру tcp_sock, так что если клиент отправит данные на сервер, они будут отброшены напрямую. Даже если в это время у клиента еще есть такая структура, мы говорим, что соединение было закрыто или разъединено. Знает ли клиент, когда соединение с сервером закрыто? Я не знаю, обе стороны могут закрыть соединение в любое время, не уведомляя друг друга. Возможно, вы уже знаете недостатки короткого соединения: если вы хотите отправить несколько запросов на сервер подряд, вам нужно установить новое соединение для каждого запроса.

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

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

взаимосвязь протоколов http и tcp

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

HTTP — это протокол прикладного уровня, который определяет спецификацию содержимого данных, передаваемых между процессами (соглашение о спецификации содержимого прикладного уровня);

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

Зачем внедрять транспортный уровень

Мы знаем, что транспортный уровень находится поверх сетевого уровня, который обеспечивает логические каналы между хостами. Тогда, поскольку пакет был отправлен с одного хоста на другой, зачем нам нужен транспортный уровень? Это связано с тем, что транспортный уровень обеспечивает сквозные соединения между процессами приложений. Мы знаем, что компьютер может одновременно иметь несколько процессов, использующих сетевое подключение, поэтому после того, как сетевой пакет достигнет хоста, как отличить, какому процессу он принадлежит? Для этого требуется роль транспортного уровня. (Сетевой уровень отвечает только за передачу данных на уровне IP и не отвечает за надежность.) Таким образом, есть два основных момента для введения транспортного уровня:

Протокол передачи данных на уровне процесса.
Гарантия надежности передачи.

Ссылаться на:blog.CSDN.net/Хань Чжэнь7541…

TCP-протокол

Что такое TCP-ссылка?

Давайте начнем с вывода: соединение на самом деле является структурой данных ядра операционной системы, называемой блоком управления TCP (TCB), которая является структурой tcp_sock для linux. Информация, используемая для обеспечения надежности и механизмов управления потоком, включая сокет, порядковый номер и размер окна, называется соединением.

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

Зачем нужен ТКБ?

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

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

Пакет данных должен сначала быть проверен сетевой картой, чтобы убедиться, что он правильный или нет.
Уровень канала передачи данных переходит к различным типам верхнего уровня (уровню IP или другому) в соответствии с типом заголовка и удаляет заголовок уровня канала данных.
Уровень IP также должен сначала проверить, а затем выбрать другой тип (TCP или UDP) в соответствии с заголовком IP, затем удалить заголовок уровня IP и отправить оставшиеся данные соответствующему обработчику (tcp или udp).
На уровне tcp обработчик выбирает сокет по номеру порта в заголовке tcp и копирует в него свои полезные данные.

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

Почему сказано, что четверка является уникальным идентификатором соединения?

Мы, наверное, много раз слышали поговорку о том, что соединение tcp однозначно идентифицируется четырехъядерным соединением. Четверка соединений относится к .

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

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

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

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

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

Очереди полуобъединения и SYN-атаки

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

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

Атака SYN означает, что клиент подделывает большое количество несуществующих IP-адресов за короткий промежуток времени и постоянно отправляет SYN-пакеты на сервер., Сервер отвечает на пакет подтверждения и ждет подтверждения от Клиента. Поскольку исходный адрес не существует, Серверу необходимо непрерывно повторять передачу до истечения времени ожидания. Эти поддельные SYN-пакеты будут занимать очередь полусоединения в течение длительного времени. , что приводит к тому, что обычные запросы SYN из-за переполнения очереди отбрасываются, вызывая перегрузку сети или даже паралич системы.

Зачем TCP нужно три рукопожатия и четыре волны?

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

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

Как показано на рисунке выше, два TCP A/B на обеих сторонах связи отправляют управляющие сообщения SYN и ACK другой стороне соответственно и ждут, пока обе стороны получат желаемый порядковый номер инициализации, прежде чем они смогут начать связь. к дизайну заголовка сообщения TCP, мы можем объединить две связи в середине в одну, и TCP B может отправлять управляющие сообщения ACK и SYN на TCP A одновременно, что также помогает нам сократить четыре связи до трех.

Клиент: Мой серийный номер начинается со 100.
Сервер: Понятно. Мои серийные номера начинаются с 300.
Клиент: Понятно.

Потому что, когда сервер получает сообщение с запросом на соединение SYN от клиента, он может напрямую отправить сообщение SYN+ACK. вСообщение ACK используется для ответа, а сообщение SYN используется для синхронизации..А вот при закрытии соединения, когда сервер получает сообщение FIN, скорее всего не сразу закроет SOCKET**, ** Таким образом, вы можете сначала ответить только на сообщение ACK, сообщив клиенту: «Я получил отправленное вами сообщение FIN». Я могу отправить сообщение FIN только до тех пор, пока все сообщения на моем сервере не будут отправлены, поэтому я не могу отправить его вместе. Поэтому требуется четыре взмаха рук:

Клиент: выключен.
Сервер: Понятно.
Сервер: выключен.
Клиент: Понятно.

Ссылаться на:

Что такое D Raven ES

nuggets.capable/post/684490…

Как TCP гарантирует надежную передачу?

Хватит ждать протокола ARQ

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

Случаи потери ответа**** и позднего ответа

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

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

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

Примечания об остановке ожидания протоколов

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

Протокол непрерывного ARQ

Прекратить ожидание ARQ (автоматический запрос на повторение) Отправитель может отправлять только один пакет за раз и должен ждать, пока не придет ответ. В то время как отправитель протокола непрерывного ARQ имеетокно отправки,Отправитель может продолжать отправлять пакеты в окне, не получая подтверждения.

Накопленное подтверждение

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

управление потоком

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

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

Тупик, вызванный управлением потоком? Как избежать взаимоблокировки?

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

**Чтобы избежать взаимоблокировок, вызванных управлением потоком, TCP использует постоянные таймеры. **Запускайте этот таймер каждый раз, когда отправитель получает ответ с нулевым окном. Когда время истекло, он будет активно отправлять сообщение, чтобы спросить размер окна получателя. Если получатель все равно возвращает нулевое окно, сбросить таймер и продолжить ожидание, если окно не 0, значит, ответное сообщение потеряно, а затем сбросить окно отправки и начать отправку, избежав таким образом возникновения взаимоблокировки.

контроль перегрузки

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

Отправитель поддерживаетОкно перегрузкиcwnd**(congestion window)** переменная состояния. Размер окна перегрузки зависит от того, насколько перегружена сеть, и изменяется динамически. Отправитель делает свое окно отправки равным окну перегрузки.Кроме того, учитывая способность получателя к приему, окно отправки может быть меньше окна перегрузки.

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

Чтобы предотвратить перегрузку сети, вызванную чрезмерным ростом cwnd, необходимо установитьПорог медленного запуска ****ssthreshПеременные состояния. Использование ssthresh выглядит следующим образом:

когдаcwnd<ssthresh, используйте алгоритм медленного старта.

когдаcwnd>ssthresh, вместо этого используйте алгоритм предотвращения перегрузки.

когдаcwnd=ssthresh, медленный старт является произвольным с алгоритмом предотвращения перегрузки.

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

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

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

Быстрая повторная передача также используется в сочетании сбыстрое восстановлениеАлгоритм имеет следующие два пункта:

① Когда отправитель получает три повторных подтверждения подряд, выполняется алгоритм «сокращения умножения», который вдвое уменьшает порог ssthresh. Но тогда алгоритм медленного старта не выполняется.

② Учитывая, что если сеть перегружена, она не получит несколько дубликатов подтверждений, поэтому отправитель теперь считает, что сеть не может быть перегружена. Таким образом, вместо того, чтобы выполнять алгоритм медленного запуска в это время, установите для cwnd размер ssthresh, а затем выполните алгоритм предотвращения перегрузки. Как показано ниже:

Примечание о непрерывном ARQ:

Байты, полученные получателем, будут сохранены в окне приема, и получатель кумулятивно подтвердит правильность приема упорядоченных байтов.После отправки ответа с подтверждением окно приема может переместиться вперед на указанные байты.
В то же время размер окна отправки не обязательно должен быть таким же большим, как окно приема. Хотя размер окна отправки устанавливается в соответствии с размером окна приема, есть время для передачи ответа в сети.Возможно, что размер окна приема в момент времени t1 равен m, но когда отправителю приходит подтверждающий ответ, изменился размер принимающего окна.
Кроме того, на размер окна отправки также влияет перегрузка сети. Когда сеть перегружена, окно отправки будет уменьшено.
Стандарт TCP не указывает, что делать с байтами, поступающими не по порядку. Однако протокол TCP обычно буферизует эти байты и ожидает поступления недостающих байтов, прежде чем передать их на прикладной уровень для обработки. Это экономит полосу пропускания по сравнению с простым отбрасыванием байтов не по порядку.
Стандарт TCP предусматривает, что получатель должен иметь функцию кумулятивного подтверждения. Получатель может одновременно подтверждать несколько сегментов TCP, но он не может задерживаться слишком долго, как правило, в пределах 0,5 с.

blog.CSDN.net/День мертвых_21112…

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

TCP (протокол управления передачей)

UDP (протокол пользовательских дейтаграмм)

Когда IP-пакет передает данные в пункт назначения посредством маршрутизации, запрашиваются и получаются различные приложения в соответствии с информацией об исходном порте и порте назначения в заголовке пакета TCP или UDP. Другими словами, как TCP, так и UDP содержат необходимую информацию о порте источника и порте назначения для сетевых служб, чтобы установить и реализовать службы сетевой передачи. В это время возникает ваш вопрос: раз все они используются для передачи, то зачем вам нужно заниматься двумя разными протоколами? Это должно начинаться с потребностей различных служб в сети.

В сети,Некоторые службы, такие как HTTP, FTP и т. д., требуют более высокой надежности данных., при использовании этих сервисов необходимо обеспечить безошибочную доставку пакетов данных **, а другим сервисам, таким как DNS, средства мгновенного чата и т. д., не требуется такая высокая надежность, высокая эффективность и реально- время они обеспокоены. ** В соответствии с различными потребностями этих двух служб были созданы протокол TCP с установлением соединения и протокол UDP без установления соединения.

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

надежность
На основе соединения и без соединения;
TCP гарантирует доступность и порядок данных, UDP может терять пакеты и выходить из строя;
занятость ресурса
Требования к системным ресурсам (больше TCP, меньше UDP); 8 байт для заголовка UDP, 20 байт для заголовка TCP**. **
скорость
Пропускная способность протокола UDP не регулируется управлением потоком и контролем перегрузки, а ограничивается только скоростью, с которой прикладное программное обеспечение генерирует данные, пропускной способностью передачи и производительностью исходного и конечного хостов. Следовательно, пропускная способность протокола UDP выше.
Простой
Структура программы UDP относительно проста;
Режим потока (байт) и режим дейтаграммы (http-сообщение);

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

Зачем вводить сетевой уровень

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

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

канальный уровень

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

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

физический слой

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

Интервью с Али Архитектором: Коммуникация в компьютерной сети