Почему UDP + программное обеспечение надежная система заказа быстрее, чем TCP?

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

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

TCP - UDP Comparative Analysis

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

Ответ, на мой взгляд, состоит из двух слов: «Контроль перегрузки».

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

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

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

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

Эта небольшая статья устарела, но, когда дело касается игр, все еще остается верной. Он объясняет два протокола и хаос, который эти люди устроили, пытаясь разработать многопользовательскую интернет-игру. "X-Wing vs Tie Fighter"

Извлеченные уроки (Интернет - отстой)

Однако есть одно предостережение: я запускаю / разрабатываю многопользовательскую игру, и я использовал обе. UDP был намного лучше для моего приложения, но многие люди не могли играть с UDP. Маршрутизаторы и тому подобное заблокировали соединения. Поэтому я перешел на "надежный" ПТС. Что ж ... Надежно? Я так не думаю. Вы отправляете пакет, без ошибок, вы отправляете другой, и он вылетает (исключение) в середине пакета. Какие пакеты это сделали? Таким образом, вы в конечном итоге пишете надежный протокол ПОВЕРХ tcp, имитировать UDP - но постоянно устанавливать новое соединение при сбое. Возьмите о неэффективности.

UDP + Остановить и подождать ARW = хорошо

UDP + Протокол скользящего окна = лучше

TCP + Протокол скользящего окна с повторным подключением? = Бесполезное массовое ПО. (IMHO)

Другой побочный эффект - многопоточные приложения. TCP хорошо подходит для чатов, поскольку каждая комната может быть собственным потоком. Комната может вместить 60-100 человек, и она работает нормально, поскольку поток Комнаты содержит сокеты для каждого участника.

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

Фактически, вы должны сделать то же самое с TCP, но только при подключении.

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

Мы перешли с надежного на ненадежный в «Лиге легенд» около года назад из-за нескольких преимуществ, которые с тех пор подтвердились:

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

2) Заказ иногда не нужен. Если я отправляю разные сообщения в разные системы, возможно, нет необходимости приводить эти сообщения в порядок. Я не заставляю клиента ждать сообщений по порядку.

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

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

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

6) Пакет заголовка меньшего размера ... особо нечего говорить об этом.