Что лучше? Много маленьких пакетов TCP или один длинный? [закрыто]

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

В настоящее время я отправляю данные о местоположении следующим образом:

sendToClient((("UID:" + cl.uid +";x:" + cl.x)));
sendToClient((("UID:" + cl.uid +";y:" + cl.y)));
sendToClient((("UID:" + cl.uid +";z:" + cl.z)));

Очевидно, что он отправляет соответствующие значения X, Y и Z.

Будет ли эффективнее отправлять такие данные?

sendToClient((("UID:" + cl.uid +"|" + cl.x + "|" + cl.y + "|" + cl.z)));

Сегмент TCP имеет много накладных расходов. Когда вы отправляете 10-байтовое сообщение с одним TCP-пакетом, вы фактически отправляете:

• 16 байтов заголовка IPv4 (увеличится до 40 байтов, когда IPv6 станет обычным)
• 16 байтов заголовка TCP
• 10 байт полезной нагрузки
• дополнительные издержки для используемых протоколов передачи данных и физического уровня

В результате получается 42 байта трафика для транспортировки 10 байтов данных. Таким образом, вы используете только менее 25% доступной пропускной способности. И это еще не учитывает накладные расходы, которые потребляют низкоуровневые протоколы, такие как Ethernet или PPPoE (но их трудно оценить, потому что существует так много альтернатив).

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

По этой причине вы должны попытаться отправить все имеющиеся у вас данные сразу в одном сегменте TCP.

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

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

Один большой (в пределах разумного) лучше.

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

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

Все предыдущие ответы неверны. На практике не имеет значения, что вы делаете один длинный send()звонок или несколько маленькихsend() вызовов.

Как утверждает Филлип, сегмент TCP имеет некоторые накладные расходы, но, как программист приложения, вы не контролируете, как создаются сегменты. Проще говоря:

Один send()вызов не обязательно переводится в один сегмент TCP.

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

Это имеет несколько последствий, но наиболее важным является то, что:

Один send()вызов или один сегмент TCP не обязательно переводится в один успешный recv()вызов на другом конце

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

Если вы хотите отправлять и получать «пакеты» по протоколу TCP, вам необходимо внедрить маркеры запуска пакетов, маркеры длины и так далее. Как насчет использования протокола, ориентированного на сообщения, такого как UDP? UDP гарантирует, что один send()вызов преобразуется в одну отправленную дейтаграмму и в один recv()вызов!

Когда все, что у вас есть, это TCP, все выглядит как поток

Многие небольшие пакеты в порядке. На самом деле, если вы беспокоитесь о накладных расходах TCP, просто вставьтеbufferstream до 1500 символов (или каковы бы ни были ваши MTU TCP, лучше всего запрашивать его динамически), и решите проблему в одном месте. Это сэкономит вам ~ 40 байт за каждый дополнительный пакет, который вы в противном случае создали бы.

Тем не менее, все-таки лучше отправлять меньше данных, и в этом вам помогают создание более крупных объектов. Конечно, отправлять меньше, "UID:10|1|2|3чем отправлять UID:10;x:1UID:10;y:2UID:10;z:3. На самом деле, на этом этапе вам также не следует изобретать велосипед, используйте библиотеку типа protobuf, которая может уменьшить такие данные до 10-байтовой строки или меньше.

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

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

Итог: отправляйте как можно меньше данных, отправляйте большие пакеты и не пишите свои собственные низкоуровневые методы для этого, но полагайтесь на хорошо известные библиотеки и методы, такие как bufferstreamи protobuf, для обработки тяжелой работы.

Хотя я и новичок в сетевом программировании, я хотел бы поделиться своим ограниченным опытом, добавив несколько моментов:

• TCP подразумевает накладные расходы - вы должны измерить соответствующую статистику
• UDP является де-факто решением для сетевых игровых сценариев, но все реализации, основанные на нем, имеют дополнительный алгоритм на стороне ЦП для учета потери пакетов или отправки из строя

Что касается измерений, метрики, которые следует учитывать, являются:

• средняя и мгновенная пропускная способность
• средняя , максимальная и минимальная сквозная задержка. Для таких показателей существующие инструменты могут обеспечить быстрое решение. Например: iperf ( https://iperf.fr/ ), D-ITG ( http://traffic.comics.unina.it/software/ITG/ ). Датированный, но все еще полезный документ по настройке TCP можно найти по адресу http://dst.lbl.gov/publications/usenix-login.pdf .

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

• надежный UDP http://sourceforge.net/projects/rudp/
• ENET http://enet.bespin.org/ (который мог бы даже заменить обработку сообщений TCP, если было обнаружено, что она работает лучше)
• UDT (протокол передачи данных на основе UDP http://udt.sourceforge.net/ ), который, кажется, стал нормой в вычислительных сценариях HP

Вывод: поскольку реализация UDP может превзойти (в 3 раза) TCP-реализацию, имеет смысл рассмотреть ее, как только вы определили свой сценарий как UDP-дружественный. Имейте в виду! Реализация полного стека TCP поверх UDP всегда плохая идея.