Является ли UDP еще лучше, чем TCP для игр с тяжелыми данными в реальном времени?

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

Большинство статей являются сервальными годами, и поскольку ~ 80% всех данных, передаваемых в Интернете, является TCP, для TCP требуется много оптимизировать.

Это заставляет меня задуматься: UDP по-прежнему превосходит скорость и латентность? Может ли недавняя оптимизация TCP сделать TCP лучше, чем UDP?

67 голосов | спросил KaareZ 18 AMpMon, 18 Apr 2016 11:28:10 +030028Monday 2016, 11:28:10

10 ответов


113

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

TCP создает абстракцию, в которую поступают все сетевые пакеты, и они поступают в том порядке, в котором они были отправлены. Чтобы реализовать такую ​​абстракцию на канале с потерями, он должен реализовать повторные передачи и тайм-ауты, которые потребляют время. Если вы отправляете 2 обновления по TCP и пакет первого обновления теряется, вы не увидите второго обновления, пока:

  1. Обнаружена потеря первого обновления.
  2. Запрошена повторная передача первого обновления.
  3. повторная передача прибыла и обработана.

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

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

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

EDIT - добавление дополнительной информации для включения /адреса некоторых комментариев:

Обычно скорость потери пакетов в сети Ethernet очень низка, но она становится намного выше, когда задействован WiFi, или если у пользователя есть загрузка /загрузка. Предположим, что мы имеем абсолютно равномерную потерю пакетов 0,01% (в одну сторону, а не в оба конца). На шутере от первого лица клиенты должны отправлять обновления всякий раз, когда что-то происходит, например, когда курсор мыши поворачивает плеер, что происходит примерно 20 раз в секунду. Они также могли отправлять обновления на кадр или фиксированный интервал, который должен составлять 60-120 обновлений в секунду. Поскольку эти обновления отправляются в разное время, они будут /должны отправляться в одном пакете за обновление. В игре с 16 игроками все 16 игроков отправляют эти 20-120 пакетов в секунду на сервер, в результате чего в общей сложности 320-1920 пакетов в секунду. С нашей скоростью потери пакетов 0,01% мы ожидаем, что потеряем пакет каждые 5,2-31,25 секунды. В этом примере мы просто игнорируем пакеты, отправленные с сервера игрокам.

В каждом пакете, который мы получаем после потерянного пакета, мы отправим DupAck и после третьего DupAck отправитель будет повторно передавать потерянный пакет . Таким образом, время, необходимое TCP для инициирования повторной передачи, - это 3 пакета, плюс время, необходимое для того, чтобы последний DupAck пришел к отправителю. Затем нам нужно дождаться возвращения повторной передачи, так что в общем случае мы ожидаем 3 пакета + 1 латентность в оба конца. Задержка округления составляет, как правило, 0-1 мс в локальной сети и 50-200 мс в Интернете. 3 пакета, как правило, поступают в 25 мс, если мы отправляем 120 пакетов в секунду и в 150 мс, если мы отправляем 20 пакетов в секунду.

В отличие от UDP мы восстанавливаем потерянный пакет, как только получаем следующий пакет, поэтому мы теряем 8,3 мс, если мы отправляем 120 пакетов в секунду и 50 мс, если мы отправляем 20 пакетов в секунду.

С TCP вещи становятся беспорядочными, если нам также нужно рассмотреть Nagle (если разработчик забывает отключить отправку коалесценции или не может отключить задержку ACK ), избежание переполнения сети или если потеря пакетов плохая, что мы должны учитывают потери нескольких пакетов (включая потерянные Ack и DupAck). С UDP мы можем легко писать более быстрый код, потому что мы просто не заботимся о том, чтобы быть хорошим сетевым гражданином, как TCP.

ответил Peter 18 PMpMon, 18 Apr 2016 12:20:33 +030020Monday 2016, 12:20:33
17

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

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

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

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

НО , посмотрите дальше. Единственное преимущество, которое дает UDP, - это его скорость, и это правильно, что мы действительно хотим. Пакет UDP обрабатывается, суммируется и отправляется без каких-либо конкретных элементов управления, потому что это работает протокол UDP. Пакет TCP должен быть обработан, помечен, скомпонован, и когда он прибывает ACK отправляется обратно, чтобы сообщить отправителю «пакет x здесь, продолжайте» , и когда этот сигнал не отправляется, значит, этот пакет x должен быть отправлен снова.

  

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

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

TCP вызывает дрожание при достаточно высокой задержке, UDP не выполняет:

 <video style = "min-width: 100% height: auto" autoplay = "" preload = "auto" loop = "true "> <источник src =" https://gafferongames.com/videos/deterministic_lockstep_tcp_250ms_5pc.mp4 "type =" video /mp4 "> <источник src =" http://173.255.195.190/cubes_deterministic_lockstep_tcp_250ms_5pc.webm " type = "video /webm"> Ваш браузер не поддерживает тег видео. </video>
  

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

Хорошо, да, это так и будет для long . Вы можете узнать больше о TCP vs UDP здесь .

ответил liggiorgio 18 PMpMon, 18 Apr 2016 20:19:48 +030019Monday 2016, 20:19:48
9

Протокол TCP <- Transmission Контроль . Это сделано для управления .

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

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

Дополнительно

  • Алгоритм Нэгле может удерживать данные отправителей, пока не появится больше для отправки (для более эффективного использования фреймов данных). Временные критические данные задерживаются.
  • Я считаю, что обычные домашние маршрутизаторы с wlan могут делать умные вещи (замедлять), чтобы сгладить пропускную способность TCP между несколькими клиентами (интерфейс wlan является узким местом, даже если игра не использует его). Относится к широковещательной /многоадресной передаче, т.е. «другие» данные могут снизить пропускную способность TCP.
  • TCP ACKnowledges все, что не обязательно для игровой среды. В ACKing нет никакого отдельного обновления физики. Достаточно для подтверждения, например, один раз в секунду или аналогично. Если клиент (или сервер) молчат в течение более длительного времени, тогда пришло время отреагировать.

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

UDP ничего не делает. Он стреляет в ваш , только тот не может ожидать, что он будет ударяться каждый раз - в этом случае цель должна объявить, что «вы не стреляли в течение длительного времени, почему?». Можно все же создать собственные пользовательские пакеты ACK, поместить несколько записей в один пакет и т. Д. Также важно контролировать NAT-обход. UDP, безусловно, подходит для игр с низкой задержкой.

ответил Stormwind 18 PMpMon, 18 Apr 2016 19:39:12 +030039Monday 2016, 19:39:12
3

Вы можете сравнить первую диаграмму RFC 768 (UDP) с первой диаграммой < a href = "https://tools.ietf.org/html/rfc793#page-15" rel = "nofollow"> RFCP 793 (TCP) страница 15 .

Оба показывают 16 бит для «порта источника», за которым следуют 16 бит для «порта памяти». Оба показывают 16 бит для «чека». Согласно RFC 768, процедура UDP chechecksum такая же, как и в TCP.â €

В то время как длина UDP завершает детали диаграммы UDP, длина TCP является частью «96-битного псевдо-заголовка», описанной на страницах 15 и 16.

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

Другая причина заключается в том, что «трехстороннее рукопожатие» TCP означает, что отправитель должен ждать ответа. Это требование вводит дополнительные накладные расходы, которые UDP не обрабатывает. Причина в том, что большинство ваших интернет-сообщений начинается с некоторых сообщений UDP. В базовом DNS используется UDP, потому что запрос и ответ могут быть выполнены за меньшее количество шагов, чем процесс TCP-tright handshake. Функция TCP для отслеживания потерянных пакетов довольно неинтересна, поскольку компьютер может просто сделать новый запрос, а не пытаться дать удаленной системе знать, что есть невыполненный предыдущий запрос.

ответил TOOGAM 21 AMpThu, 21 Apr 2016 03:39:58 +030039Thursday 2016, 03:39:58
2

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

  1. Откроется сеанс TCP, и когда бомбу отправится, отправьте сообщение TCP всем игрокам (если возможно, см. ниже)
  2. Сохраняйте прослушивание порта UDP, и когда бомбу отправляется, отправьте сообщение UDP всем игрокам независимо от состояния их подключения.

Предполагая, что до этого не было необходимости обновления, время, когда это сингулярное обновление прибывает в 1 против 2, не будет сильно отличаться. Это одна поездка от сервера к клиенту. Но, скажем, вместо того, чтобы просто бомба уходит, вы пытаетесь постоянно передавать активность кого-то, проходящего через лабиринт; плетение, уклонение, стрельба и т. д. В случае UDP каждое действие будет отправлено в дейтаграмме, как только это произойдет. В случае TCP каждое действие будет отправлено в пакете, только если серверу разрешено отправлять. Что говорит, что это разрешено отправлять? Наличие комнаты в окне TCP (при условии, что delayed ack активен), чтобы сообщение могло быть помещено в провод. Если нет, ему необходимо дождаться, когда ack прибудет от клиента перед отправкой.

Как долго это слишком долго? Когда многопользовательская разработка шутера от первого лица поразила его в конце 90-х и начале 2000-х годов, низкочастотные соединения не были обычным явлением. Модем для коммутируемого доступа будет иметь типичную одностороннюю задержку в 180 мс. Ожидание вокруг ack перед отправкой другого обновления, эффективно удвоение этого времени до 360 мс, было болезненным; даже начинающие пользователи могут определенно почувствовать разницу. Когда подключались широкополосные подключения, они значительно сократили задержку, но она по-прежнему сохраняется, когда пропускная способность не хватает (нередко в некоторых областях). Таким образом, предпочтение минимально возможной задержки сохранялось.

Современные домашние соединения и межсоединения изменили это, до такой степени, что региональная латентность, даже в перегруженные часы, находится в диапазоне 15 мс или ниже. Выбор TCP вместо UDP будет невидимым в большинстве случаев, поскольку латентность «достаточно низкая». Тем не менее, по-прежнему сохраняется тенденция UDP к приоритету по TCP, учитывая его историю как протокол с низкой задержкой. Итак, на данный момент (и, вероятно, некоторое время в будущем) UDP будет предпочтительнее для обмена в режиме реального времени.

ответил Jeff Meden 18 PMpMon, 18 Apr 2016 20:26:10 +030026Monday 2016, 20:26:10
2
  

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

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

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

При наличии потери пакетов два отличаются в задержке, но только в этом состоянии. В противном случае TCP имеет столь же низкую задержку, что и UDP (дайте или возьмите, возможно, несколько десятков наносекунд, потому что сетевой стек имеет немного больше логики, но это довольно небрежно). Существует небольшая разница в размере заголовка, поэтому с технической точки зрения больше байтов должно проходить через провод по последовательным линиям, но это тоже несущественно. Это действительно важно для массовых переводов, а затем разница в 0,5%. Большинство пользователей с домашним DSL-доступом в Интернет маршрутизируют весь свой трафик через ATM, который добавляет свыше 10% -ных служебных данных протокола (5 байтов управления для 48 байтов полезной нагрузки, плюс частичные кадры), и никто даже не замечает.

Некоторые люди строят надежность поверх UDP. Если требуется какой-то уровень надежности, но не требуется строгое освобождение в порядке, может дать небольшое преимущество. Тем не менее, это все еще спорно, делает ли подход много смысла, и вы платите здоровенную цену за этого небольшое преимущество.
Если у вас есть клиенты, подключающиеся к WiFis или другим «странным» местам, вы заметите, что часто общая поддержка TCP намного, намного лучше, чем для UDP.

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

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

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

Обратите внимание, что потеря пакетов является нормальным условием. Хотя IP, как правило, «вполне надежный», иногда могут выпадать пакеты, и произойдет . Хотя потерянные пакеты обычно находятся на редкой стороне (здесь здесь меньше 1%), это не что-то необычное или теоретическое, или указание на то, что что-то нарушено. Это совершенно нормально.
Например, каждый массовый перенос TCP обязательно включает потерянные пакеты (как работает контроль перегрузки).

ответил Damon 19 PMpTue, 19 Apr 2016 16:01:41 +030001Tuesday 2016, 16:01:41
2

В MPG с высокой пропускной способностью вам все равно, если вы пропустили пакет, дающий вам местоположение и здоровье монстра # 425, потому что вы получите другое обновление за небольшую часть секунды. Это и пример, где UDP делает TCP глупым, заставляя вас ждать мгновенно устаревших данных.

В той же игре вы хотите, чтобы патчи отображались точно так, как они были разработаны. В TCP уже есть встроенные функции «сказать мне, если это не удается», что облегчает автоматические повторы и проверенные сбои. Вы можете сделать это в UDP, но зачем воссоздать технологию?

Вот простое описание того, что происходит.

UDP - Изолировать фрагмент O'data.
   Сделать пакет.
   Инкапсулировать в IP.
   Отгрузите его.

TCP - изолировать поток O'data.
   Сделайте пакет с фронта потока.
   Инкапсулировать в IP.
   Подождите места в окне TCP.
   Отгрузите его.
   Продолжайте пересылку до получения квитанции или тайм-аута.
   Оставайтесь в окне TCP до получения квитанции или таймаута.

Отгрузка только означает, что она прошла через локальную сетевую карту, не более.

Получение приема TCP и гарантирует прием данных и освобождает пространство в окне для следующего пакета.

Повторная отправка (слегка) увеличивает вероятность возможного получения.

TCP-пакеты повторно собираются с другой стороны в виде упорядоченного потока данных. UPD-пакеты принимаются как отдельный пакет. Протокол не сохраняет порядок.

TCP хорош для толкания требуемых данных и больших упорядоченных объемов данных. TCP предоставляет уведомление о постоянном сбое. TCP самозажимается через забитые трубы (ref: window). TCP имеет рукопожатие, чтобы замедлить инициализацию. TCP требует «соединения» перед передачей.

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

Я разработал и написал коммерчески используемую UDP-программу многоадресной передачи файлов. Я работал над IP-стеками. Это всего лишь основы, без minutia. Объяснение «сокетов, MTU и других забавных игрушек» было немного выше того, что было бы полезно для этого вопроса.

P.s. (Я не могу добавлять комментарии к комментариям)   UDP также хорош для данных, которые желательны, но не требуются. Прямая коррекция ошибок - пример этого, много ненужных, но желательных пакетов.

ответил dusc2don 18 PMpMon, 18 Apr 2016 23:46:09 +030046Monday 2016, 23:46:09
1
  

Все TCP-оптимизированные маршрутизаторы сделали TCP лучше, чем UDP?

Еще один вопрос: «тяжелые данные» означают, что вы часто загружаете сцены?

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

ответил Vadim Suraev 18 PMpMon, 18 Apr 2016 19:27:58 +030027Monday 2016, 19:27:58
1

Ни UDP, ни TCP (или любой другой вариант) не имеют права superior , даже не с точки зрения скорости /задержки. Ваш выбор должен быть сделан в зависимости от требований вашего приложения. Для этого вам следует сравнить функции, предлагаемые каждым протоколом, понимая, что больше функций подразумевает дополнительные накладные расходы. Поэтому, если целью является минимизация задержки или максимизация скорости, тогда вы должны выбрать протокол с максимально возможными функциями, но при этом сохраняя основные функции, необходимые для удовлетворения ваших требований.

Сравнение протоколов

В общем, UDP (User Datagram Protocol) предлагает наименьшее количество функций. Это упрощает то, что вы отправляете данные без какого-либо получения /подтверждения.

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


Пример: Конференц-связь Skype

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

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


Варианты реализации

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

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

ответил Nick Miller 21 PMpThu, 21 Apr 2016 21:02:37 +030002Thursday 2016, 21:02:37
1

Я заметил много комментариев, когда люди считают, что пакеты TCP больше, чем UDP-пакеты. Не доверяйте мне, прочтите документацию. Протокол следующий: несколько байтов для заголовка Ethernet (2 байта типа сообщения, 48 бит MAC, 6 байт) (для Wifi заголовок может отличаться) 20 байтов для IP-адресов 20 байт для TCP или UDP x байтов для данных x от 0 до 1500 (см. MTU) Наконец, контрольная сумма, чтобы убедиться, что в этом Ethernet-пакете не произошло никакого повреждения.

TCP позволяет отправлять более крупный пакет «stream» размером около 64K. Этот «большой» блок фактически прерывается во многих небольших пакетах Ethernet.

ответил Joust6809 21 PMpThu, 21 Apr 2016 22:42:26 +030042Thursday 2016, 22:42:26

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132