Проблемы, связанные с TCP/IP
Некоторые методы программирования выполняются с проблемами производительности, связанными с реализацией TCP/IP. Такие проблемы с производительностью не предполагают, что TCP/IP неэффективны или узкие места производительности; Скорее, эти проблемы возникают, когда операции TCP/IP не понимаются.
Следующие проблемы определяют распространенные сценарии, в которых сочетание операций TCP/IP и вариантов разработки сетевых приложений приводит к снижению производительности.
Приложения с большим количеством подключений.
Некоторые приложения создает экземпляр нового TCP-подключения для каждой транзакции. Создание TCP-подключения занимает время, вносит дополнительные RTT и подвергается медленному запуску. Кроме того, закрытые подключения подвергаются времени ожидания, который потребляет системные ресурсы.
Приложения с большим количеством подключений часто используются в значительной степени, так как они легко создаются; тестирование и обработка ошибок очень простая. Обнаружение сбоев в постоянном подключении может занять значительные усилия и код, поэтому иногда не выполняется.
Исправите эту ситуацию, повторно выполнив TCP-подключение. Это может привести к сериализации через TCP-подключение, если транзакции не мультиплексируются по нескольким подключениям. Если этот подход применяется, количество подключений должно быть ограничено двумя, а обрамления на уровне приложений и расширенной обработки ошибок требуется.
Буферы отправки с нулевой длиной и блокирующие отправки.
Отключение буферизации с помощью функции setockopt для задания буфера отправки (SO_SNDBUF) равно нулю, аналогично отключению кэширования дисков. При настройке буфера отправки на нулевое значение и выдаче блокирующих отправки приложение имеет пятьдесят процентов шансов получить отложенное подтверждение в 200 миллисекундах.
Не отключайте буферизацию отправки, если вы не рассмотрели влияние во всех сетевых средах. Одно исключение: потоковая передача данных с использованием перекрывающихся операций ввода-вывода должна задать буфер отправки равным нулю.
Модель программирования отправкиSend-Receive.
Структурирование приложения для выполнения отправки-отправки увеличивает вероятность возникновения алгоритма Nagle, что приводит к задержке RTT+200 мс. Алгоритм Nagle может быть обнаружен, если последняя отправка меньше максимального размера сегмента TCP (MSS, максимальные данные в одной диаграмме данных). MSS может быть очень большим значением (64 КБ в IPv4 и даже большим в IPv6), поэтому не подсчитывайте на обычно небольшой MSS. Лучше всего объединить два отправки в одну отправку с помощью функции WSASend или memcpy.
Большое количество одновременных подключений.
Одновременные подключения не должны превышать два, за исключением приложений специального назначения. Превышение двух одновременных подключений приводит к потере ресурсов. Хорошее правило заключается в том, чтобы иметь до четырех коротких постоянных подключений или двух постоянных подключений на место назначения.
Связанные разделы