rst ack что это
Русские Блоги
Формат сообщения TCP и флаги TCP
(2) Формат сообщения TCP (rfc793)
Описание каждого поля:
TCP использует полнодуплексный режим, и передача данных выполняется после того, как соединение установлено и до того, как соединение будет разорвано.Передача данных является односторонней, от отправителя к получателю. TCP может гарантировать, что данные будут приняты принимающей стороной через порядковый номер. TCP устанавливает соединение посредством трехстороннего рукопожатия.
Во время TCP-соединения бит флагов используется для индикации состояния соединения во время передачи. Таким образом, этот флаг можно использовать для обнаружения проблемы или управления отправкой указанного соединения. Процесс трехстороннего подтверждения TCP выглядит следующим образом:
Для старой версии определения заголовка TCP, флаги имеют 6 бит, а новая версия заголовка TCP расширяет флаги на 3 бита. Каждый флаг TCP соответствует 1 биту. Таким образом, старая версия флагов заголовка TCP имеет 6 значений, а новая версия расширила 3 значения. От низкого к высокому: FIN, SYN, RST, PSH, ACK, URG, ECE, CWR, NS.
Старое поле TCP Flags:
Новая версия поля TCP Flags:
Описание значения флагов:
FIN: сокращение от «готово». Указывает отправителя и отправленные данные. Обычно используется в последнем пакете после того, как отправитель отправил данные.
SYN: сокращение от «Синхронизация». Представляет первый шаг трехстороннего рукопожатия для установления соединения.Значение флага устанавливается на SYN в первом пакете, отправленном отправителем, когда соединение установлено.
RST: сокращение от «сброс». Флаг сброса подключения используется для сброса неправильного подключения из-за сбоя хоста или по другим причинам. Или, когда отправляющий пакет отправляется неожиданному узлу назначения, принимающая сторона отправляет пакет сброса для сброса флага соединения.
PSH: сокращение от «push». Уведомить принимающую сторону о необходимости обработки полученного сообщения вместо буферизации сообщения в буфере.
ACK: сокращение от «Подтверждение». Указывает, что пакет был успешно получен.
URG: сокращение от «срочно». Уведомить принимающую сторону о необходимости обработки полученных срочных пакетов перед обработкой других пакетов. Подробнее см. RFC6093.
ECE: сокращение от «ECN-Echo». ECN означает явное уведомление о перегрузке. Указывает, что одноранговый узел TCP имеет возможность ECN. Подробнее см. RFC3168.
CWR: сокращение от «Уменьшенное окно перегрузки». Отправитель будет использовать флаг CWR при получении пакета с флагом ECE. Подробнее см. RFC3168.
NS: сокращение от «nonce sum». Этот тег используется для защиты от вредоносных скрытых сообщений, отправляемых отправителем. Подробнее см. RFC 3540.
(4) Используйте tcpdump для захвата сообщения значения флага ответа
Потому что флаги TCP расположены в 14-м байте заголовка TCP. Все это можно просканировать с помощью следующей команды:
Почему я вижу пакет RST, ACK вместо пакета RST?
В Wireshark я часто вижу, что потоки TCP заканчиваются пакетом RST, ACK вместо пакета RST. Кто-нибудь знает, почему это?
Пример того, что я вижу:
Wireshark не собирает пакет RST до пакета RST, ACK.
2 ответа
A RST /ACK не является подтверждением RST, так же как SYN /ACK не является точно подтверждением SYN. Установление TCP фактически является четырехсторонним процессом: инициирующий узел отправляет SYN принимающему хосту, который отправляет ACK для этого SYN. Принимающий хост отправляет SYN на инициирующий узел, который отправляет ACK обратно. Это устанавливает связь с состоянием.
Чтобы сделать это более эффективным, принимающий хост может ACK SYN и отправить свой собственный SYN в тот же пакет, создав трехсторонний процесс, который мы привыкли видеть.
В случае RST /ACK устройство подтверждает, какие данные были отправлены в предыдущем пакете (-ях) в последовательности с ACK, а затем уведомляет отправителя, что соединение закрыто с RST. Устройство просто объединяет два пакета в один, как SYN /ACK. RST /ACK обычно не является нормальным ответом при закрытии сеанса TCP, но это также не обязательно указывает на проблему.
После установления соединения все пакеты должны иметь ACK и соответствовать порядковому номеру полученных пакетов для надежного транспорта /безопасности. RST без ACK не будет приниматься. Когда одна сторона отправляет RST, сокет немедленно закрывается, и принимающая сторона также закрывает сокет сразу после получения действительного RST. Он не должен быть и не может быть подтвержден.
после рукопожатия TCP
B закрывает сокет после того, как он отправляет последний пакет, и A закрывает сокет после его получения.
(не рассматривая здесь TCP-окно, или может быть больше пакетов с одного конца перед объявлением)
Флаг ACK, номер подтверждения и процедура подтверждения связаны, но не одно и то же.
Номер подтверждения: 32 бит
Во всех состояниях, кроме SYN-SENT, все сегменты сброса (RST) проверяются путем проверки их SEQ-полей. Сброс действителен, если его порядковый номер находится в окне. В состоянии SYN-SENT (RST, полученное в ответ к исходному SYN), RST является приемлемым, если поле ACK подтверждает SYN.
Приемник RST сначала проверяет его, затем изменяет состояние. Если приемник находился в состоянии LISTEN, он игнорирует его. Если приемник был в состоянии SYN-RECEIVED и ранее находилось в состоянии LISTEN, то приемник возвращается в состояние LISTEN, иначе приемник прерывает соединение и переходит в состояние ЗАКРЫТО. Если приемник был в любом другом состоянии, он прерывает соединение и советует пользователю и переходит в состояние ЗАКРЫТО.
Внутренние механизмы ТСР, влияющие на скорость загрузки: часть 1
Ускорение каких-либо процессов невозможно без детального представления их внутреннего устройства. Ускорение интернета невозможно без понимания (и соответствующей настройки) основополагающих протоколов — IP и TCP. Давайте разбираться с особенностями протоколов, влияющих на скорость интернета.
IP (Internet Protocol) обеспечивает маршрутизацию между хостами и адресацию. TCP (Transmission Control Protocol) обеспечивает абстракцию, в которой сеть надежно работает по ненадежному по своей сути каналу.
Протоколы TCP/IP были предложены Винтом Серфом и Бобом Каном в статье «Протокол связи для сети на основе пакетов», опубликованной в 1974 году. Исходное предложение, зарегистрированное как RFC 675, было несколько раз отредактировано и в 1981 году 4-я версия спецификации TCP/IP была опубликована как два разных RFC:
TCP обеспечивает нужную абстракцию сетевых соединений, чтобы приложениям не пришлось решать различные связанные с этим задачи, такие как: повторная передача потерянных данных, доставка данных в определенном порядке, целостность данных и тому подобное. Когда вы работаете с потоком TCP, вы знаете, что отправленные байты будут идентичны полученным, и что они придут в одинаковом порядке. Можно сказать, что TCP больше «заточен» на корректность доставки данных, а не на скорость. Этот факт создает ряд проблем, когда дело доходит до оптимизации производительности сайтов.
Стандарт НТТР не требует использования именно TCP как транспортного протокола. Если мы захотим, мы можем передавать НТТР через датаграммный сокет (UDP – User Datagram Protocol) или через любой другой. Но на практике весь НТТР трафик передается через TCP, благодаря удобству последнего.
Поэтому необходимо понимать некоторые внутренние механизмы TCP, чтобы оптимизировать сайты. Скорее всего, вы не будете работать с сокетами TCP напрямую в своем приложении, но некоторые ваши решения в части проектирования приложения будут диктовать производительность TCP, через который будет работать ваше приложение.
Тройное рукопожатие
Все TCP-соединения начинаются с тройного рукопожатия (рис. 1). До того как клиент и сервер могут обменяться любыми данными приложения, они должны «договориться» о начальном числе последовательности пакетов, а также о ряде других переменных, связанных с этим соединением. Числа последовательностей выбираются случайно на обоих сторонах ради безопасности.
Клиент выбирает случайное число Х и отправляет SYN-пакет, который может также содержать дополнительные флаги TCP и значения опций.
SYN ACK
Сервер выбирает свое собственное случайное число Y, прибавляет 1 к значению Х, добавляет свои флаги и опции и отправляет ответ.
Клиент прибавляет 1 к значениям Х и Y и завершает хэндшейк, отправляя АСК-пакет.
Рис. 1. Тройное рукопожатие.
После того как хэндшейк совершен, может быть начат обмен данными. Клиент может отправить пакет данных сразу после АСК-пакета, сервер должен дождаться АСК-пакета, чтобы начать отправлять данные. Этот процесс происходит при каждом TCP-соединении и представляет серьезную сложность плане производительности сайтов. Ведь каждое новое соединение означает некоторую сетевую задержку.
Например, если клиент в Нью-Йорке, сервер – в Лондоне, и мы создаем новое TCP-соединение, это займет 56 миллисекунд. 28 миллисекунд, чтобы пакет прошел в одном направлении и столько же, чтобы вернуться в Нью-Йорк. Ширина канала не играет здесь никакой роли. Создание TCP-соединений оказывается «дорогим удовольствием», поэтому повторное использование соединений является важной возможностью оптимизации любых приложений, работающих по TCP.
TCP Fast Open (TFO)
Загрузка страницы может означать скачивание сотен ее составляющих с разных хостов. Это может потребовать создания браузером десятков новых TCP-соединений, каждое из которых будет давать задержку из-за хэндшейка. Стоит ли говорить, что это может ухудшить скорость загрузки такой страницы, особенно для мобильных пользователей.
TCP Fast Open (TFO) – это механизм, который позволяет снизить задержку за счет того, что позволяет отправку данных внутри SYN-пакета. Однако и у него есть свои ограничения: в частности, на максимальный размер данных внутри SYN-пакета. Кроме того, только некоторые типы HTTP-запросов могут использовать TFO, и это работает только для повторных соединений, поскольку использует cookie-файл.
Использование TFO требует явной поддержки этого механизма на клиенте, сервере и в приложении. Это работает на сервере с ядром Linux версии 3.7 и выше и с совместимым клиентом (Linux, iOS9 и выше, OSX 10.11 и выше), а также потребуется включить соответствующие флаги сокетов внутри приложения.
Специалисты компании Google определили, что TFO может снизить сетевую задержку при HTTP-запросах на 15%, ускорить загрузку страниц на 10% в среднем и в отдельных случаях – до 40%.
Контроль за перегрузкой
В начале 1984 года Джон Нейгл описал состояние сети, названное им как «коллапс перегрузки», которое может сформироваться в любой сети, где ширина каналов между узлами неодинакова.
Когда круговая задержка (время прохождения пакетов «туда-обратно») превосходит максимальный интервал повторной передачи, хосты начинают отправлять копии одних и тех же датаграмм в сеть. Это приведет к тому, что буферы будут забиты и пакеты будут теряться. В итоге хосты будут слать пакеты по нескольку раз, и спустя несколько попыток пакеты будут достигать цели. Это называется «коллапсом перегрузки».
Нейгл показал, что коллапс перегрузки не представлял в то время проблемы для ARPANETN, поскольку у узлов была одинаковая ширина каналов, а у бэкбона (высокоскоростной магистрали) была избыточная пропускная способность. Однако это уже давно не так в современном интернете. Еще в 1986 году, когда число узлов в сети превысило 5000, произошла серия коллапсов перегрузки. В некоторых случаях это привело к тому, что скорость работы сети падала в 1000 раз, что означало фактическую неработоспособность.
Чтобы справиться с этой проблемой, в TCP были применены несколько механизмов: контроль потока, контроль перегрузки, предотвращение перегрузки. Они определяли скорость, с которой данные могут передаваться в обоих направлениях.
Контроль потока
Контроль потока предотвращает отправку слишком большого количества данных получателю, которые он не сможет обработать. Чтобы этого не происходило, каждая сторона TCP-соединения сообщает размер доступного места в буфере для поступающих данных. Этот параметр — «окно приема» (receive window – rwnd).
Когда устанавливается соединение, обе стороны задают свои значения rwn на основании своих системных значений по умолчанию. Открытие типичной страницы в интернете будет означать отправку большого количества данных от сервера клиенту, таким образом, окно приема клиента будет главным ограничителем. Однако, если клиент отправляет много данных на сервер, например, загружая туда видео, тогда ограничивающим фактором будет окно приема сервера.
Если по каким-то причинам одна сторона не может справиться с поступающим потоком данных, она должна сообщить уменьшенное значение своего окна приема. Если окно приема достигает значения 0, это служит сигналом отправителю, что не нужно более отправлять данные, пока буфер получателя не будет очищен на уровне приложения. Эта последовательность повторяется постоянно в каждом TCP-соединении: каждый АСК-пакет несет в себе свежее значение rwnd для обеих сторон, позволяя им динамически корректировать скорость потока данных в соответствии с возможностями получателя и отправителя.
Рис. 2. Передача значения окна приема.
Масштабирование окна (RFC 1323)
Исходная спецификация TCP ограничивала 16-ю битами размер передаваемого значения окна приема. Это серьезно ограничило его сверху, поскольку окно приема не могло быть более 2^16 или 65 535 байт. Оказалось, что это зачастую недостаточно для оптимальной производительности, особенно в сетях с большим «произведением ширины канала на задержку» (BDP – bandwidth-delay product).
Чтобы справиться с этой проблемой в RFC 1323 была введена опция масштабирования TCP-окна, которая позволяла увеличить размер окна приема с 65 535 байт до 1 гигабайта. Параметр масштабирования окна передается при тройном рукопожатии и представляет количество бит для сдвига влево 16-битного размера окна приема в следующих АСК-пакетах.
Сегодня масштабирование окна приема включено по умолчанию на всех основных платформах. Однако промежуточные узлы, роутеры и сетевые экраны могут переписать или даже удалить этот параметр. Если ваше соединение не может полностью использовать весь канал, нужно начать с проверки значений окон приема. На платформе Linux опцию масштабирования окна можно проверить и установить так:
В следующей части мы разберемся, что такое TCP Slow Start, как оптимизировать скорость передачи данных и увеличить начальное окно, а также соберем все рекомендации по оптимизации TCP/IP стека воедино.
Русские Блоги
Wireshark analysis art [описание чтения]
Wireshark analysis art [описание чтения]
1. Фактическая работа Wireshark
Анализ работы интерфейса
Один из трех приемов: просмотр статистики и атрибутивной информации
Одна из трех осей анализа производительности:
Определите, высокий или низкий расход, и не перегружен ли он
Второй из трех способов: просмотр и анализ экспертной информации.
Анализ производительности по трем осям:
Проверьте, есть ли такая информация, как примечания, предупреждения, ошибки, проверьте наличие связанных предупреждений и ошибок, оцените качество сети, нарушение повторной передачи и т. Д.
Три хитрости: просмотрите время ответа службы
Третий из трех приемов анализа производительности:
Проверьте время отклика службы для каждой операции, чтобы определить, не перегружена ли она.
Используйте относительные значения для seq вместо истинных значений
Правка-> Настройки-> Протоколы-> TCP, отметьте относительные порядковые номера.
Это относительное значение до включения.
Просмотр TCP StreamGraph
Проверьте ситуацию передачи данных, например, является ли передача ровной, есть ли TCP Zero Windows и т. Д.
Значение поля и подсказка
1，[Packer size limited during caputre]
2，[TCP ACKed unseen segment]
3，[TCP Previous segment not captured]
При передаче данных TCP, в дополнение к трехэтапному и четырехстороннему рукопожатию, сегмент данных, отправленный одним и тем же компьютером, должен быть непрерывным, то есть Seq следующего пакета равен Seq + Len предыдущего пакета. Это правильная ситуация; если Если будет обнаружено, что Seq последнего пакета больше, чем Seq + Len предыдущего пакета, это означает, что часть данных потеряна в середине. Если потерянные данные не найдены во всем сетевом пакете, Wireshark предложит [TCP Previous segment not captured] ，
В этой ситуации есть две возможности:
4，[TCP Out-of-Order]
При передаче данных TCP, в дополнение к трехэтапному и четырехэтапному рукопожатию, сегмент данных, отправленный одной и той же машиной, должен быть непрерывным, то есть Seq следующего пакета равняется Seq + Len предыдущего пакета, что должно быть правильным случаем; или Говорят, что Seq последнего пакета должен быть больше или равен Seq + Len предыдущего пакета. Если Wireshark обнаруживает, что Seq последнего пакета меньше, чем Seq + Len предыдущего пакета, то он считается неисправным, и он запрашивает [TCP Out-of-Order] 。
5，[TCP Dup ACK]
6，[TCP Fast Retransmission]
Когда отправитель получает 3 или более подряд [TCP Dup ACK] В то время я понял, что ранее отправленный пакет может быть потерян, поэтому он начнет быстро повторно передавать в соответствии с RFC. [TCP Dup ACK] Это получатель отвечает отправителю, поэтому отправитель может его воспринять и начать быструю повторную передачу, когда он получает более трех сообщений подряд.
Алгоритм быстрой повторной передачи предусматривает, что, пока отправитель получает 3 повторяющихся подтверждения подряд, он должен немедленно повторно передать сегмент сообщения, который другой стороной не получил, не дожидаясь истечения установленного времени счетчика повторной передачи.
7，[TCP Retransmission]
Если пакет действительно потерян, и никакие последующие пакеты не могут вызвать [Dup Ack] на получателе, тогда быстрая повторная передача не будет включена.В этом случае отправитель может только дождаться тайм-аута перед отправкой повторной передачи. Пакет будет отмечен wirehark и подсказкой [TCP Retransmission]
Тайм-аут TCP и повторная передача должны быть одними из самых сложных частей TCP. Тайм-аут повторной передачи является основой TCP для обеспечения надежной передачи. Когда TCP отправляет данные, данные и подтверждение могут быть потеряны, поэтому TCP решает эту проблему, устанавливая таймер при отправке. Если таймер переполняется и не получил подтверждения, он повторно передает данные. Ключевым моментом является стратегия тайм-аута и повторной передачи. Необходимо учитывать два аспекта:
В более поздних версиях ядра Linux, таких как 3.15, есть как минимум 9 таймеров: таймер повторной передачи тайм-аута, непрерывный таймер, таймер задержки ER, таймер PTO, таймер задержки ACK, таймер SYNACK, Таймер поддержания активности, таймер FIN_WAIT2, таймер TIME_WAIT.
8，[TCP zerowindow]
Как правило, размер окна следует постепенно уменьшать до заполнения буфера.
9，[TCP window Full]
[TCP window Full] и указанное выше [TCP zerowindow] легко перепутать. Первое означает, что отправитель этого пакета не имеет возможности отправлять какие-либо данные в данный момент; второй означает, что отправитель этого пакета больше не может получать данные; оба будут Приостановить передачу данных
10，[TCP segment of reassembled PDU]
Доступно только в меню Edit-> Preferences-> Protocols-> TCP Allow sub dissector to reassemble TCP streams После этого можно получить это приглашение. Это представление может виртуально собирать TCP-пакеты, принадлежащие одному PDU прикладного уровня.
11，[Continuation to #]
Закрывается только в меню Edit-> Preferences-> Protocols-> TCP Allow sub dissector to reassemble TCP streams После этого можно получить это приглашение.
12，[Time-to-live-exceeded(Fragment reasembly time execeeded)]
(Превышено время повторной сборки фрагмента) указывает на то, что отправитель этого пакета уже получил некоторые фрагменты раньше, но по некоторым причинам сборка задерживалась.
Например, если некоторые фрагменты потеряны во время передачи, получатель не может их собрать, а затем отправитель уведомляется этим методом ICMP.
Во-вторых, Wireshark анализирует протокол TCP.
Основы протокола захвата пакетов TCP
Поле управления TCP
На уровне TCP есть поле FLAGS со следующими идентификаторами: SYN, FIN, ACK, PSH, RST, URG.
Форма поля управления, отображаемого при захвате пакета, следующая:
[SYN]: установить соединение, запустить пакет [FIN]: закрыть соединение, завершить пакет [PSH]: передача данных DATA [ACK]: ответ ACK [RST]: RESET, сброс соединения
Два других часто используемых поля:
[Len]: длина пакета [Seq]: порядковый номер пакета.
ACK может использоваться одновременно с SYN, FIN и т. Д. Например, SYN и ACK могут быть 1 одновременно, это означает, что ответ после установления соединения, если это только один SYN, это означает, что установлено только соединение
Когда появляется пакет FIN или RST, мы думаем, что клиент отключен от сервера. Когда появляются пакеты SYN и SYN + ACK, мы думаем, что клиент установил соединение с сервером.
Направление захвата пакета (клиент или сервер)
TCP Ack
Например, ACK пакета 97 = 65701 и Seq + Len = 64273 + 1428 = 65701 пакета 96, тогда это означает, что ACK 97 является ответом на 96, то есть другие ACK до 96 не отображаются. Фактически, пакеты прошли ACK пакета 97, поэтому отправитель также знает, что все пакеты, отправленные до 96, были получены и подтверждены другой стороной.
MSL、TTL、RTT
RTT (время приема-передачи), что означает время, необходимое для передачи данных от клиента к серверу и обратно. TCP содержит алгоритм для динамической оценки RTT.
Разрешение MAC-адреса
Протокол = ARP Источник и место назначения имеют формат MAC-адреса, например 00: 60: 48: ff: 12: 31.
При анализе захвата пакетов, если сеть заблокирована, ACK не может быть получен и т. Д., Необходимо дополнительно проверить правильность MAC-адреса каждого пакета.Напротив, есть некоторые проблемы, вызванные несколькими MAC-адресами.
Протокол установления связи TCP и волновой протокол
Пакет трехстороннего подтверждения TCP и ответного суждения
Соглашение о трехстороннем рукопожатии
Захват пакетных данных, как определить, является ли пакет пакетом возврата предыдущего пакета? Согласно протоколу TCP, если значение Ack следующего пакета равно Seq + Len предыдущего пакета, это означает, что пакет возвращается.
Во время трехстороннего рукопожатия все MSS будут объявлены друг другу.
ПТС четыре раза махнул и трижды
Четырехволновой протокол TCP
Обычно таких волн будет четыре, но если есть задержка с подтверждением, тогда четыре волны станут тремя волнами, сохраняя вторую сумку из четырех волн.
Алгоритм контроля перегрузки TCP
Количество байтов в пути
Перегрузка сети
Окно отправки
Алгоритм TCP Nagle и отложенный ACK
Это необходимо для уменьшения количества небольших пакетов в глобальной сети, тем самым уменьшая вероятность перегрузки сети;
Преимущество этого алгоритма в том, что он адаптивен. Чем быстрее приходит подтверждение, тем быстрее будут отправлены данные. В низкоскоростной глобальной сети, которая хочет уменьшить количество небольших пакетов, будет отправлено меньше пакетов;
Если tcp отправляет подтверждение подтверждения для каждого пакета данных, то отправка подтверждения для одного пакета данных обходится дороже, поэтому TCP будет задерживаться на определенный период времени. Если в течение этого периода на противоположный конец будут отправлены данные, они будут отправлены с совмещением. ack, если будет обнаружено, что подтверждение не было отправлено при срабатывании таймера отложенного подтверждения, оно будет отправлено отдельно немедленно;
Преимущества отложенного ACK:
(1) Избегайте синдрома запутанного окна; (2) При отправке данных отправляйте подтверждение с совмещением вместо отправки подтверждения отдельно; (3) Если Если в течение времени задержки поступает несколько сегментов данных, стеку протоколов разрешается отправить подтверждение для подтверждения нескольких сегментов сообщения;
Используйте параметр сокета TCP TCP_NODELAY, чтобы отключить параметр сокета;
Рассмотрите возможность отключения алгоритма Нэгла в следующих случаях:
(1) Противоположный конец не отправляет данные на локальный конец, и операция более чувствительна к задержке; этот вид операции не может переносить подтверждение; (2) Операция записи-записи-чтения, как указано выше; В этом случае вместо отключения алгоритма Нэгла предпочтительнее использовать другие методы:
Разница и сравнение TCP и UDP
Главное отличие
Разница между TCP и UDP в том, что TCP надежен, а UDP ненадежен, но какова реальная производительность? Что ненадежно? В чем разница между ACK конкретного протокола?
Независимо от того, TCP это или UDP, он может быть фрагментированным, что определяется MSS Ethernet; разница заключается в обработке фрагментированной передачи:
UDP больше подходит для голоса, чем TCP
Сценарий голосового вызова заключается в том, что задержка не может быть принята, но качество звука немного хуже. В этом случае во время передачи UDP, если некоторые пакеты потеряны, прикладной уровень может игнорировать и продолжать передавать другие пакеты. Потеря некоторых пакетов повлияет только на качество звука, но обеспечит плавность. Что касается TCP, каждый пакет будет передан повторно, и пока пакет будет потерян, он будет повторно передаваться. Это вызовет определенную задержку. Если есть задержка в голосе, это нежелательно.
Следовательно, TCP и UDP имеют свои подходящие сценарии. Для голоса и видео больше подходит UDP.Как голосовая сеть и linphone, UDP используется для обработки аудио и видео. TCP должен использоваться при взаимодействии базового и основного протоколов.
Эффективность TCP и UDP
Пример: по дороге взад и вперед едет только одна машина. Процесс возврата эквивалентен пустому пробегу (обратный путь эквивалентен ACK TCP), поэтому эффективность TCP, конечно, низкая. Однако, если вы попытаетесь увеличить количество транспортных средств при отсутствии заторов, транспортные средства на дороге будут просто заполнены, поэтому общая эффективность передачи улучшится, а ACK обратного рейса не будет затронут.
Фрагментация пакетов, MTU, MSS
Фрагментация и повторная сборка пакетов
Но следует отметить, что в некоторых сетях в настоящее время есть такие устройства, как Jumbo Frame (jumbo frame) или PPPOE, поэтому их MTU не составляет 1500 байтов. В настоящее время у отправителя нет хорошего механизма для определения оптимального размера фрагмента, и он должен стараться поддерживать согласованность MTU устройств в сети. Если MTU устройств в сети несовместимо, как протокол TCP адаптируется к MTU? Мы знаем, что когда TCP устанавливает соединение, сначала должно быть выполнено трехстороннее рукопожатие. TCP взаимно объявит свой собственный MSS в первых двух пакетах подтверждения. Если клиентская сторона объявляет свой собственный MSS = 8960 (jumbo-фрейм), а серверная сторона объявляет свой собственный MSS = 1460, то клиент знает MSS сервера после трехстороннего рукопожатия, поэтому, когда клиент хочет отправить пакет, превышающий MSS сервера Будет предпринята инициатива по уменьшению собственного MSS до размера MSS на стороне сервера, чтобы адаптироваться к MTU получателя. Видно, что уровень протокола TCP проделал большую оптимизацию и обработку.
Настоящая битва MTU
Если MTU клиента = 9000, а MTU сервера = 1500, тогда, когда клиент запрашивает сервер, пакет клиента будет либо потерян, либо фрагментирован при прохождении через маршрутизатор. Если этот пакет jumbo-кадра несет на сетевом уровне флаг DF (Don’t Fragment), он будет отброшен (его установка означает, что фрагментация не разрешена), если он не установлен, будет выполнена передача фрагмента. Следует отметить, что в этом случае, если пакет потерян, а повторная передача все еще отбрасывается, он становится черной дырой.
В тесте вы можете смоделировать эту ситуацию с помощью команды ping:
Особый контроль потока и пропускная способность
Существует своего рода «кадр паузы», который может удовлетворить это требование: когда буфер коммутатора собирается заполниться, на сервер отправляется кадр паузы, и сервер некоторое время ждет, чтобы отправить его снова, чтобы избежать переполнения и потери пакетов. Повторная передача после потери пакета. Время ожидания на стороне сервера определяется параметром pause_time в кадре паузы, так что серверная сторона начнет отправку после ожидания pause_time. Конечно, коммутатор также может отправить на сервер кадр паузы с pause_time = 0, чтобы сообщить серверу, что я его обработал и могу отправить немедленно.
Обратите внимание, что управление потоком здесь отличается от управления потоком TCP.
В-третьих, используйте методологию анализа Wireshark.
Чтобы устранить проблему с помощью wirehark, вам необходимо проанализировать сетевой пакет, найти некоторые подсказки в сетевом пакете, а затем сделать вывод на основе сетевого протокола, затем отменить один за другим и, наконец, найти проблему.
Необходимо уметь понимать основной протокол TCP и смысл каждого поля.
Используйте некоторые инструменты статистики и анализа Wireshark, фильтры и т. Д.
Существует большая разница между отправкой и получением захвата пакетов
Используйте «три оси» рабочего процесса и шагов для анализа проблемы.