TCP/IP вы, возможно, не изучали

задняя часть алгоритм Linux TCP/IP
TCP/IP вы, возможно, не изучали

Обзор

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

Примечание:Эта статья была впервые опубликована на моем официальном аккаунтеCodeSheep,МожетНажмитеилисканированиеследующеебудь остороженЗаходи подписывайся ↓ ↓ ↓

CodeSheep · 程序羊

Сомнение 1 — о перегрузке

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

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

  • 1.Максимальная настройка окна приема в ОС не менялась уже много лет.Например,когда в винде не включена "Опция окна TCP" максимальный размер окна приема всего 64Кб. Однако с развитием сети точка перегрузки во многих средах намного превышает 64 КБ, то есть окно отправки никогда не коснется точки перегрузки.

  • 2. Многие сценарии приложений представляют собой интерактивный обмен небольшими данными, например, чат и т. д., нет возможности перегрузки

  • 3. Некоторые приложения используют синхронный режим при передаче данных, для чего может потребоваться очень маленькое окно (например, операция записи NFS с использованием синхронного режима, каждый раз, когда отправляется запрос на запись, он останавливается и ждет ответа, а запрос на запись может всего 4кб)

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

Сомнение 2 - О повторной передаче по тайм-ауту

Сомнение второе:Споры о настройках ssthresh после повторной передачи по тайм-ауту

  • 1. Ричард Стивенс установил значение критического окна как половину окна отправки, когда перегрузка произошла в последний раз в «Подробное объяснение TCP/IP».

  • 2. RFC5681 считает, что он должен составлять 1/2 объема неподтвержденных данных (также известного как FlightSize) при возникновении перегрузки и не менее 2MSS.

  • 3. Алгоритм Westwood/Westwood+ считает, что: сначала подсчитайте, сколько пакетов было отправлено получателю (это можно рассчитать на основе ACK, полученного получателем), чтобы точно оценить пропускную способность при возникновении перегрузки, и, наконец, подтвердить согласно полосе пропускания новое окно перегрузки

  • 4. Алгоритм Vegas думает так: ввести новую концепцию и отказаться от прежней практики настройки окна перегрузки после потери пакетов. Он регулирует скорость отправки пакетов, отслеживая состояние сети, чтобы добиться «настоящего предотвращения перегрузки». Когда сеть в порядке, RTT относительно стабилен, и окно перегрузки в это время может быть увеличено; когда сеть занята, RTT увеличивается, а окно перегрузки в это время может быть уменьшено.

  • 5. Алгоритм Compound считает, что: одновременно поддерживаются два окна перегрузки, одно похоже на Vegas, а другое похоже на RFC5681.Что действительно работает, так это сумма двух (по умолчанию оно закрыто в Win7)

  • 6. Алгоритм BIC/алгоритм CUBIC Они используются в linux 2.6.18 и linux 2.6.19 соответственно и еще не изучены.

Несколько кратких сводок о TCP/IP:

  • (1) При отсутствии перегрузки чем больше окно отправки, тем выше производительность. ∴ В случае неограниченной пропускной способности окно принятия должно быть максимально увеличено, например, включена опция масштабирования.

  • (2) Если перегрузка происходит часто, ограничение окна отправки может улучшить производительность. ∵ Даже повторная передача 1/10 000 оказывает большое влияние на производительность. Во многих ОС окно отправки можно уменьшить, ограничив окно получения.

  • (3) Повторная передача по тайм-ауту оказывает наибольшее влияние на производительность.В течение времени ∵RTO данные не передаются, а Cwnd будет установлено на 1MSS, чего следует избегать, насколько это возможно.

  • (4) Быстрая повторная передача меньше влияет на производительность, ∵ нет времени ожидания, а уменьшение Cwnd невелико.

  • (5) SACK и NewReno полезны для повышения эффективности повторной передачи и повышения производительности передачи.

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

постскриптум

Дополнительные статьи автора о SpringBt находятся здесь:

Если вам интересно, вы также можете уделить время прочтению некоторых статей автора о контейнеризации и микросервисах:

CodeSheep · 程序羊

Категории