Таймаут потока что это такое
Вопрос по SmartPSS
Werewolf1971
Member
Доброе время суток всем!
Не смог найти ответ на форуме, поэтому создал тему. Если подобное где-то уже обсуждалось прошу перенаправить
Исходные данные: имеется сеть из 3 свитчей и 4 регистраторов (50 камер) плюс ПК с установленной СмартПСС на 10-ке.
При этом при просмотре на сетке камер (на экране монитора) видно что вместо вторичного потока в ячейках сетки идет первичный поток. При раскрытии закрытии любой ячейки на выбор видео также идет первичным потоком. При переключении через ПКМ на вторичный поток происходит или потеря сигнала или меняется поток, но при этом он и в фулловом окне также остается вторичным.
Перезагрузка переустановка Смарта ничего не дала.
При этом во всей сети происходят периодически затыки и пропадания каналов.
В чем может быть проблема?
Техподдержка VIDIMOST
специалист
Werewolf1971
Member
Werewolf1971
Member
Как бы по СмартПСС куча вопросов имеется
Техподдержка VIDIMOST
специалист
чем Вас не устраивает отображение в миниатюрах в доп потоке? зачем Вам в миниатюрах основной?
укажите модели и версии ПО пожалуйста!
укажите версию Smart pss!
Werewolf1971
Member
чем Вас не устраивает отображение в миниатюрах в доп потоке? зачем Вам в миниатюрах основной?
укажите модели и версии ПО пожалуйста!
укажите версию Smart pss!
на 1 монитор можно вывести макс 64 канала.
максимум можно вывести 4 монитора из одного Smart pss.
Поясняю что меня не устраивает, если вы не поняли с первого раза. Пишу четко и ясно:
В миниатюрах у меня идет отображение ОСНОВНОГО потока. И почему так происходит я не могу понять. И Мне не нужен основной поток в миниатюрах, я об этом не писал.
А если вам нужны подробности, то их есть у меня. Держите
Хорошо, пытаюсь поменять тип потока на вторичный в любой из миниатюр (в 1й, в 15й в 40й) не важно и потом ее раскрыть на весь экран, то происходит следующее:
И сразу скажу: предлагали клиенту поставить более новую версию ПО, но он отказался из за отсутствия русского интефейса.
Теперь вопрос насчет 64 канала на 1 монитор. Поясните, я правильно понимаю: если у меня 4 монитора, то я в общей сумме могу на них вывести 64х4 канала? то изображения с 256 камер (если конечно мне хватит мощности сети)
Русские Блоги
25. Тайм-аут протокола TCP и повторная передача
Таймаут TCP и повторная передача должны быть одной из самых сложных частей TCP;
Windows и Linux реализуют эту часть по-разному, но алгоритм в основном тот же;
Тайм-аут повторной передачи является основой для TCP для обеспечения надежной передачи;
Когда TCP отправляет данные, данные и подтверждение могут быть потеряны;
Поэтому TCP решает эту проблему, устанавливая таймер при отправке. Если таймер переполнен и не получил подтверждение, он передает данные повторно;
Будь то Windows или Linux, ключом является стратегия тайм-аута и повторной передачи. Необходимо учитывать два аспекта:
В настоящее время в более высоких версиях ядра Linux, таких как 3.15, имеется по меньшей мере 9 таймеров: таймер повторной передачи тайм-аута, непрерывный таймер, таймер задержки ER, таймер PTO, таймер задержки ACK, Таймер SYNACK, таймер поддержки активности, таймер FIN_WAIT2, таймер TIME_WAIT.
Это слишком много, для начинающих, мы сосредоточимся на следующих 4:
Пример тайм-аута повторной передачи
После ожидания около 16 минут (рисунок 2) клиент вернул ошибку: нет маршрута к хосту.
Рисунок 2 Клиент возвращает ошибку после ожидания около 16 минут
Рисунок 3 После 9-й повторной передачи хост лично отправляет протокол ARP для запроса MAC-адреса другой стороны
Потому что в том же сегменте сети, хост Sun отправил 17×3=51 Для одного запроса ARP отправка ARP каждые три раза занимает около 50 секунд.
Пример в Главе 21 (Рисунок 21-1) в «Подробном объяснении» состоит в том, чтобы сдаться после 12 повторных передач (около 9 минут) и отправить сегмент RST другой стороне.
Время поездки туда и обратно (RTT)
Как установить время повторной передачи (RTO)?
Когда пакет данных проходит, и подтверждение возвращается, это время обычно приблизительно равно времени RTT. Если подтверждение не получено в течение времени RTT, вероятно, что другая сторона не получила данные, или возвращенное подтверждение потеряно.
Поэтому наиболее интуитивная идея заключается в том, что RTO должен быть немного больше, чем RTT; Например: R T O = R T T + Δ t
RTT измерение
Однако, как измеряется RTT в формуле?
В TCP разница во времени между передачей пакета данных и получением подтверждения другой стороны будет записана TCP, а затем сохранена в переменной RTTs Входить;
В локальной сети наша сеть обычно очень стабильна. Каждый раз, когда RTT пересчитывается, изменение в основном не слишком велико, но в глобальной сети сеть становится чрезвычайно сложной. На этот раз RTT составляет 100 мс, может быть Он становится 800 мс за раз. В настоящее время нецелесообразно использовать рассчитанный в реальном времени RTT. В RFC используется взвешенный RTT. Его формула выглядит следующим образом:
Интуитивно понятным примером является то, что оценки некоторых учащихся слишком низкие, что снижает общий уровень класса. Чтобы предотвратить это явление, вы можете что-то сделать при расчете среднего.
Например, в настоящее время RTTs=200ms Последний измерил RTT=800ms Затем обновил RTTs=200×0.875+800×0.125=275ms；
Δt Как определить
Спереди мы представили формулу: RTO=RTT+Δt
Теперь мы обновляем его: RTO=RTTs+Δt
RTTS Метод расчета, который мы ввели в предыдущем разделе, теперь он Δt Что это и как рассчитывается? Мы только знаем, что он должен быть маленьким. RFC 2988 предусматривает:
Следовательно, согласно приведенному выше определению, Δt=4×RTTD ；
И RTTD Рассчитывается следующим образом: RTTD=(1−β)×RTTD+β×|RTTs−RTT|
Фактически, RTTD Это среднее отклонение, которое эквивалентно расстоянию между образцом и его средним значением;
Это похоже на то, насколько ваша оценка отличается от средней оценки вашего класса.
Экспоненциальный откат
Предполагая, что данные теряются при отправке данных в определенное время, согласно предыдущей формуле, мы вычислили значение RTO;
Если после повторной передачи подтверждения другой стороны не ожидается, значение RTO будет удвоено;
Пока в повторно переданных данных нет подтверждения, RTO всегда будет удваиваться.
Тогда n-я ретрансляция RTOn Значение: R T O n = 2 n − 1 × R T O 1
Алгоритм Карна
Предполагая, что пакет отправлен, и после нескольких повторных передач получен подтверждение другой стороны, как рассчитать новый RTT? На самом деле мы не можем узнать, какое подтверждение является подтверждением повторной передачи данных, поэтому алгоритм Карна предусматривает: В настоящее время не обновляется RTTs Значение 。
В следующий раз, когда происходит повторная передача, используется значение RTO после отката.
Вернуться к рисунку 1
С другой стороны, если мы будем следовать предыдущему RTTs Расчетная формула, рассчитанная RTTs Оно должно быть очень маленьким, вероятно, всего несколько миллисекунд. Если RTO рассчитывается на основе этого, это должно быть несколько миллисекунд. Но почему тайм-аут повторной передачи RTO Достигнуто около 200 мс?
С другой стороны, почему TCP останавливается там после 8 повторных передач в Linux? Это зависит от того, как ядро реализует это. Я верю, что каждый узнает этот ответ после освоения основного принципа таймаута TCP.
Таймаут соединения что это
Достаточно часто многие пользователи ПК, которые так или иначе связаны с Интернетом, а также геймеры, подключающиеся к игровым порталам, наблюдают появление ошибок соединения с сервером. Сейчас мы рассмотрим вопрос о том, что значит тайм-аут операции. Более того, будет предложено несколько основных способов решения этой проблемы.
Тайм-аут операции – что это такое?
Итак, на экране монитора возникает ошибка, сообщающая пользователю о том, что соединение прервано, вернее, время ожидания подключения истекло.
В принципе, тайм-аут и можно трактовать как некий временной промежуток, в течение которого система ожидает ответа сервера на собственный отправленный запрос. В системах Windows это параметр установлен по умолчанию, а его значение прописано в сетке системного реестра настроек текущего компьютерного терминала в подразделе SYSTEM, где во вложенных директориях находится подпапка Parameters, где время указано в секундах. Как правило, изменять его не рекомендуется.
Причины возникновения ошибки
Причин, когда возникает тайм-аут операции, может быть довольно много. Выделим наиболее часто встречающиеся ситуации. Прежде всего, в качестве основного фактора выступает нестабильное подключение к Интернету, когда постоянно происходит прерывание связи, и система не может получить цельный ответ сервера, к которому в данный момент выполняется подключение.
В некоторых случаях тайм-аут операции может срабатывать при включенных антивирусных программах или при неправильных настройках брэндмауэра Windows. Как известно, брэндмауэр при настройках по умолчанию способен блокировать достаточно много веб-ресурсов, считая их опасными или содержащими потенциально нежелательные данные. Такое очень часто встречается при подключению к серверам многопользовательских онлайн-игр.
Кроме всего прочего, тайм-аут операции завершает время ожидания подключения при использовании или неправильной настройке прокси-сервера. В данном случае речь идет и о настройках прокси в системе, и об использовании анонимных прокси-серверов, когда пользователь по каким-либо причинам хочет остаться во Всемирной паутине неузнанным, а проще говоря, скрыть истинный IP-адрес своего компьютерного терминала. Рассмотрим несколько основных методов исправления ситуации без вмешательства в системный реестр для выставления более высокого значения периода ожидания.
Тайм-аут операции: что делать? Простейший способ исправления ситуации
Как считается, наиболее простым способом, позволяющим избавиться от ошибки 118, является обычное закрытие не отвечающей страницы и ее повторное открытие по истечении минут десяти. Иногда может потребоваться закрыть и перезапустить сам интернет-браузер (часто такие ситуации почему-то наблюдаются в Google Chrome и других браузерах на его основе).
Если такой вариант не помогает, а сообщение «Ошибка: Тайм-аут операции…» выдается снова, можно применить обычную перезагрузку компьютера или ноутбука (а лучше и всех маршрутизаторов типа роутеров или ADSL-модемов).
Достаточно эффективным может оказаться решение проблемы, связанное с внесением, допустим, игрового сайта в список разрешений (исключений) антивируса и брэндмауэра, тем более что в обоих случаях в настройках сделать это не так уж и сложно.
Изменение параметров прокси-сервера
Несколько сложнее обстоит дело с настройками прокси в системе. Рассмотрим в качестве примера стандартный Internet Explorer. В браузере нужно использовать раздел «Свойства обозревателя» и вкладку «Подключения».
Снизу имеется кнопка «Настройка сети», после нажатия на которую будет произведен вход в окно настройки параметров локальной сети. Здесь достаточно просто снять галочку (флажок) со строки «Использовать прокси-сервер» и сохранить изменения (иногда можно отключить прокси для локальных адресов).
Но вот если подключение производится при помощи прокси, для установки правильных настроек лучше обратиться к провайдеру.
Исправление системного файла Hosts
Теперь перейдем к более сложному методу исправления ошибок, когда может срабатывать тайм-аут операции.
Сначала в меню отображения файлов и папок (в стандартном «Проводнике» это меню «Сервис» со строкой «Параметры папок») на вкладке вида необходимо задать показ скрытых папок и файлов.
После вышеуказанной операции необходимо открыть меню «Выполнить» и ввести в строке команду «notepad %windir%system32driversetchosts» (естественно, без кавычек), поле чего в «Блокноте» будет открыт файл Hosts. Обратите внимание: снизу имеется строка «::1 localhost». По идее, она должна быть последней, так что все, что находится ниже нее, нужно удалить, после чего произвести сохранение файла с оригинальным названием и местоположением. Теперь остается только перезагрузить компьютерный терминал. Затем, как правило, ошибка исчезает.
Заключение
Вот, собственно, и все по поводу срабатывающего тайм-аута. Конечно, можно использовать еще и редактирование системного реестра с заданием большего значения периода ожидания ответа сервера, вот только гарантии, что все остальные ресурсы будут грузиться без проблем, никто дать не может. К тому же, как уже понятно, и сами страницы, если и будут грузиться, то намного дольше. А это ни одному юзеру не нужно.
Бесплатный звонок
8 800 770 01 70
Сервисы сети JustLan
Сеть Direct Connect
DC: Настройка и использование
DC: Вопросы и проблемы
Если у вас возникают проблемы с закачкой или поиском файлов (вроде, всё делаете как надо, а ничего не качается или поиск выдаёт пустой список), уясните себе, что хаб DC (сервер) тут совершенно не при чем. Передача файлов происходит напрямую от клиента к клиенту, поэтому помехи могут быть только на пути между клиентами.
Помните, что правильная настройка самого DC-клиента ещё не означает правильной настройки системы, сети и других приложений, которые могут влиять на DC++.
Вариантов проблем тут по сути всего три (первый — наиболее частый):
Правильные сетевые настройки DC-клиента
Если у вас не прямое подключение компьютера к сети, а через роутер (маршрутизатор), то настройки могут отличаться. А если у вас провод от провайдера втыкается прямо в комп, то проверьте, что у вас включен активный режим передачи файлов (Файл — Настройки — Настройки соединения):
Остальные настройки DC++ на сетевые соединения никак не влияют. Так что если у вас тут всё выбрано как на картинке, значит проблема наверняка не в настройка клиента (то есть, читайте дальше).
Межсетевые экраны, антивирусы и их влияние на работу DC++
Ниже перечислено то, что может отрицательно влиять на работу DC++.
Если вы не знаете, что это такое, ниже приведен перечень популярных программ такого типа:
Антивирусы: Касперский (Антивирус, АнтиХакер, Internet Security), Eset NOD32, Symantec (Norton AntiVirus, Internet Security), Trend PC-Cillin, Avira Avast, DrWeb, McAfee Antivirus, Panda.
Firewall-ы: Outpost, WinGate, UserGate, WinProxy, WinRoute, ZoneAlarm, Comodo.
Что же касается аппаратных firewall-ов, пока нам известен только nVidia firewall, встроенный в материнские платы на чипсетах nVidia N-Force. Как его отключить читайте руководство по материнской плате.
Как быть, если у вас есть перечисленные программы или им аналогичные? Для начала вы можете попробовать полностью их отключить или настроить так, чтобы они не блокировали сетевые соединения (либо совсем все, либо те, которые создаются приложением DC++. Даже если вы боитесь отключать защиту — вы можете сделать это временно и проверить, что причина того, что DC++ не работает, была именно в данной программе. Причем подойдите к вопросу творчески, поэкспериментируйте с настройками вашего фаерволла или антивируса и добейтесь того, чтобы он не блокировал DC.
К сожалению, опыт говорит о том, что такие антивирусы, как NOD32 и Norton (Symantec) Internet Security обладают следующим неприятным свойством: даже полное их отключение (а в некоторых случаях — деинсталляция) на самом деле полным не является и всё равно создаёт помехи в работе DC++. Способов борьбы с этим (кроме самых радикальных вроде переустановки чистой системы) нам пока неизвестно. Причины кроются в некорректной работе этих программ и/или их деинсталляторов, повлиять на которые у пользователя возможности нет.
Для подключения к хабу в DC++ обычно используется 411 TCP-порт (зависит от настроек самого хаба, но на большинстве хабов он именно такой). В активном режиме DC++ использует многие порты для соединений с юзерами; в режиме ручного перенаправления — только тот порт, который указан в настройках.
Если НИЧЕГО из перечисленного не помогает:
Остаются только радикальные меры: переустановить «чистую» винду без лишних программ защиты. Многим пользователям оно кстати совершенно не повредит. Поверьте, потратить даже три часа на полную переустановкиу системы — это быстрее, чем три дня искать причину неработоспособности чёрт знает в какой программе. При том не советуе пользоваться «самосборками» Windows — они тоже бывают весьма «кривые», и гарантировать бесперебойную работу DC на этих системах вам никто не будет (благо опять-таки, есть печальный опыт наступания пользователей на эти грабли).
Разумеется, те же самые 2 порта (2000 TCP и 2000 UDP) должны быть разрешены на вход/выход в настройках фаерволла.
Подробное описание многих файрволлов (немного старое, но не потерявшее актуальности) и их настройки есть в интернете вот здесь.
в настоящее время у меня более 100 соединений в спящем состоянии.
некоторое соединение должно оставаться в состоянии сна (и не закрываться), потому что это постоянное соединение, но некоторые другие (с другим именем пользователя) из какого-то php-скрипта, и я хочу, чтобы они очень быстро тайм-аут.
можно ли настроить wait_timeout для каждого пользователя? и если да, то как?
7 ответов
нет конфигурации тайм-аута для каждого пользователя, но вы можете установить wait_timeout динамически значение. То есть после установления соединения с данным пользователем можно выдать инструкцию для изменения значения тайм-аута на то, каким оно должно быть для сеанса этого пользователя.
попробуйте следующий эксперимент в клиенте командной строки mysql:
затем вы можно выйти из сеанса, повторно подключиться и снова по умолчанию wait_timeout – это 28800. Поэтому он ограничен рамками текущей сессии.
вы также можете открыть второе окно и начать отдельный сеанс клиента mysql, чтобы доказать, что изменение wait_timeout в одном сеансе не влияет на другие параллельные сеансы.
вы должны установить следующие переменные в вашем my.conf :
wait_timeout таймаут для автоматизированные соединения (на мой взгляд более, чем 30 на веб-сервере слишком много).
interactive_timeout – это время ожидания взаимодействия консоли для холостого хода сессии.
другая возможность: MySQL поддерживает две разные переменные таймаута, wait_timeout для неинтерактивных клиентов, и interactive_timeout для интерактивных клиентов.
разница между интерактивными и неинтерактивными клиентами, кажется, просто ли вы указали при подключении.
Я не знаю, поможет ли это вам, потому что вам нужно как-то сделать mysql_real_connect() передайте эту опцию в свой
Если вы используете Разъем / J, вы можете использовать sessionVariables в URL JDBC клиента так: jdbc:mysql://hostname:3306/schema?sessionVariables=wait_timeout=600
другие соединители для других языков, вероятно, позволят то же самое.
Я проверил mysql.user таблица, и не похоже, что для нее есть настройка:
в зависимости от того, используете ли вы MySQLi или PDO, ваши соединения PHP MySQL должны либо зависать, когда запрос делает, либо совместно использоваться в пуле для процесса Apache.
например, с PDO, чтобы отключить постоянные соединения (я думаю, что это значение по умолчанию), подключитесь к своей БД с помощью:
init_connect будет выполняться всякий раз, когда пользователь входит в систему, поэтому мы можем писать небольшие обоснование и значение в зависимости от пользователя. Обратите внимание, что init_connect не будет выполняться для суперпользователя.
mysql> SET GLOBAL init_connect=»SET @@wait_timeout = CASE WHEN CURRENT_USER() LIKE ‘[email protected]%’ THEN ’30’ ELSE @@wait_timeout END»;
Таймаут потока что это такое
Глава 21 Тайм-ауты и повторные передачи TCP
Мы уже видели два примера тайм-аута и повторной передачи: (1) в примере, посвященном недоступности порта ICMP в разделе «ICMP ошибка недоступности порта» главы 6, мы видели, что TFTP клиент, использующий UDP, применяет простую стратегию тайм-аута и повторной передачи: он устанавливает период тайм-аута в 5 секунд и осуществляет повторную передачу каждые 5 секунд. (2) В примере ARP для несуществующего хоста (глава 4, раздел «Примеры ARP») мы видели, что когда TCP старается установить соединение, он повторно передает свои SYN, используя увеличенные задержки между каждой повторной передачей.
Простой пример использования тайм-аутов и повторных передач
Во-первых, давайте рассмотрим стратегию повторных передач, которая используется TCP. Мы установим соединение, отправим какие-нибудь данные, чтобы убедиться в том, что соединение функционирует, отсоединим кабель, отправим еще данные и посмотрим, как поступит TCP:
bsdi % telnet svr4 discard
Trying 140.252.13.34.
Connected to svr4.
Escape character is ‘^]’.
hello, world эту строку мы посылаем обычным образом
and hi перед тем как отправить эту строку, отсоединяем кабель
Connection closed by foreign host. вывод, после того как TCP ждал 9 минут
На рисунке 21.1 показан вывод команды tcpdump. (Мы удалили всю информацию, связанную с типом сервиса, которую устанавливает bsdi.)
6 24.480158 (18.2207) bsdi.1029 > svr4.discard: P 15:23(8) ack 1 win 4096
7 25.493733 ( 1.0136) bsdi.1029 > svr4.discard: P 15:23(8) ack 1 win 4096
8 28.493795 ( 3.0001) bsdi.1029 > svr4.discard: P 15:23(8) ack 1 win 4096
9 34.493971 ( 6.0002) bsdi.1029 > svr4.discard: P 15:23(8) ack 1 win 4096
10 46.484427 (11.9905) bsdi.1029 > svr4.discard: P 15:23(8) ack 1 win 4096
11 70.485105 (24.0007) bsdi.1029 > svr4.discard: P 15:23(8) ack 1 win 4096
12 118.486408 (48.0013) bsdi.1029 > svr4.discard: P 15:23(8) ack 1 win 4096
13 182.488164 (64.0018) bsdi.1029 > svr4.discard: P 15:23(8) ack 1 win 4096
14 246.489921 (64.0018) bsdi.1029 > svr4.discard: P 15:23(8) ack 1 win 4096
15 310.491678 (64.0018) bsdi.1029 > svr4.discard: P 15:23(8) ack 1 win 4096
16 374.493431 (64.0018) bsdi.1029 > svr4.discard: P 15:23(8) ack 1 win 4096
17 438.495196 (64.0018) bsdi.1029 > svr4.discard: P 15:23(8) ack 1 win 4096
18 502.486941 (63.9917) bsdi.1029 > svr4.discard: P 15:23(8) ack 1 win 4096
19 566.488478 (64.0015) bsdi.1029 > svr4.discard: R 23:23(0) ack 1 win 4096
Рисунок 21.1 Простой пример тайм-аута и повторной передачи TCP.
В строке 6 показано, как передается «and hi». Строки 7-18 это 12 повторных передач сегмента, а в строке 19 TCP прекращает попытки передачи и посылает сброс.
Обратите внимание на временные промежутки между последовательными повторными передачами: они происходили в моменты времени 1, 3, 6, 12, 24, 48 и 64 секунды. Дальше в этой главе мы увидим, что первый тайм-аут устанавливается в 1,5 секунды после первой передачи. (Причина, по которой он возник через 1,0136 секунды после первой передачи, а не точно через 1,5 секунды, была объяснена на рисунке 18.7.) После этого величина тайм-аута удваивается для каждой передачи, причем верхний предел составляет 64 секунды.
Подобное увеличение называется экспотенциальным наращиванием (exponential backoff). Сравните это с примером TFTP, который приведен в разделе «ICMP ошибка недоступности порта» главы 6, где каждая повторная передача осуществляется через 5 секунд после предыдущей.
Разница во времени между первой передачей пакета (строка 6, момент времени 24,480) и сбросом (строка 19, момент времени 566,488) составляет примерно 9 минут. Современные TCP реализации довольно настойчивы в попытках отправить данные!
В большинстве реализаций полная величина тайм-аута ненастраиваемая. Solaris 2.2 позволяет администратору изменить эту величину (переменная tcp_ip_abort_interval в разделе «Solaris 2.2» приложения E), а по умолчанию она составляет только 2 минуты, а не 9 минут, как это принято в большинстве реализаций.
Определение времени возврата
Во-первых, TCP должен рассчитать RTT между отправкой байта с конкретным номером последовательности и получением подтверждения на этот номер последовательности. Из предыдущей главы мы знаем, что обычно не существует полного соответствия между сегментами данных и подтверждениями (ACK). На рисунке 20.1 это означало, что один RTT, который может быть вычислен отправителем, является временем между передачей сегмента 4 (байты данных 1-1024) и получением сегмента 7 (ACK байт 1-2048), даже если этот ACK подтверждает дополнительно 1024 байта. Мы используем величину M, чтобы обозначить рассчитанный RTT.
Для определения RTT существует расширение к исходной спецификации TCP, которое называется хэшированная оценочная функция RTT (обозначается R)
Для подобной хэшированной оценочной функции, которая изменяется с изменением RTT, RFC 793 рекомендует, чтобы тайм-аут повторной передачи ( RTO) устанавливался следующим образом
где b это коэффициент изменения задержки с рекомендуемым значением равным 2.
[ Jacobson 1988] подробно обсуждает проблемы, связанные с подобным подходом, в основном заключающиеся в том, что он не может применяться при широком диапазоне изменения RTT, и является причиной нежелательных повторных передач. Как замечает Jacobson, нежелательные повторные передачи увеличивают загрузку сети.
В этом случае необходимо добавить возможность отслеживать расхождения в расчетах RTT в дополнение к хэшированной функции оценки RTT. Расчет RTO основанный на среднем и расхождении дает значительно лучшие результаты при широком диапазоне изменений времен возврата, чем просто расчет RTO как постоянного кратного среднего значения. Рисунки 5 и 6 в [Jacobson 1988] показывают сравнение значений RTO в соответствии с RFC 793 для некоторых реальных времен возврата, с расчетами RTO, которые мы показали ранее, которые принимают во внимание изменение времен возврата.
Как описано у Jacobson, среднее отклонение является хорошим приближением к стандартному отклонению, однако рассчитывается значительно легче. (Расчет стандартного отклонения требует вычисления квадратного корня.) Таким образом, следующие уравнения могут быть применены к каждому расчету RTT M.
где A это хэшированный RTT (оценочная функция среднего), а D это хэшированное среднее отклонение. Err это разница между только что рассчитанным значением и текущим значением оценочной функции RTT. Оба A и D используются для расчета следующего тайм-аута повторной передачи (RTO). Увеличение среднего (g) установлено в значение 1/8 (0,125). Увеличение отклонения (h) установлено в 0,25. Максимальное увеличение отклонения делает рост RTO быстрее при изменении RTT.
[Jacobson 1988] устанавливает 2D при расчете RTO, однако для следующих исследований [Jacobson 1990c] изменяет это значение на 4D, что соответствует реализации BSD Net/1.
В следующем разделе мы увидим, как устанавливаются эти оценочные функции, когда будем рассматривать примеры.
[Karn and Partridge 1987] указывает, что когда применяется тайм-аут и повторная передача, мы не можем обновить оценочные функции RTT, когда, в конце концов, прибывает подтверждение на повторно переданные данные. Это потому, что мы не знаем, которой передаче соответствует подтверждение (ACK). (Возможно, первая передача была задержана, но не была отброшена, или был задержан ACK на первую передачу.)
Так как данные были повторно переданы и к RTO было применено экспотенциальное наращивание, мы повторно используем экспотенциально увеличенный RTO для следующей передачи. Новый RTO не рассчитывается до тех пор, пока не будет получено подтверждение на сегмент, который не отправлялся повторно.
В этой главе мы рассмотрим примеры, которые проиллюстрируют детали разных реализаций TCP тайм-аутов и повторных передач, медленный старт и предотвращение переполнения.
С помощью программы sock отправлено 32768 байт данных с хоста slip на discard сервис хоста vangogh.cs.berkeley.edu:
Обратимся к рисунку, находящемуся на внутренней стороне обложки. Из рисунка видно, что slip подсоединен к Ethernet 140.252.1 двумя SLIP каналами, а затем через Internet к пункту назначения. Так как используется два SLIP канала (со скоростью 9600 бит в секунду), мы ожидаем появления определенных задержек.
Команда, приведенная выше, осуществит 32 записи по 1024 байта. Так как MTU между slip и bsdi составляет 296, то будет сгенерировано 128 сегментов, каждый из которых будет содержать 256 байт пользовательских данных. Полное время передачи займет примерно 45 секунд, и мы увидим один тайм-аут и три повторные передачи.
Из-за того, что вывод достаточно большой, мы не можем показать его целиком, однако рассмотрим его по частям, в процессе изучения главы. На рисунке 21.2 показана передача данных и подтверждений в течение первых 5 секунд. Мы немного модифицировали этот вывод от предыдущего вывода команды tcpdump. Мы только оценили моменты времени, когда пакет отправлялся или принимался хостом, на котором запущена программа tcpdump, на этом рисунке мы хотели показать, что пакет двигается по сети (так как это соединение в локальной сети не похоже на распределенный Ethernet), и показать, когда принимающий хост, возможно, генерирует подтверждения. (Мы удалили все объявления окна. slip всегда объявляет окно размером 4096, а vangogh всегда объявляет окно 8192.)
Рисунок 21.2 Обмен пакетами и расчет RTT.
Также обратите внимание на то, что на этом рисунке мы пронумеровали сегменты 1-13 и 15 в том порядке, в котором они были отправлены или приняты хостом slip. Это соответствует выводу tcpdump, который был получен для этого хоста.
Определение времени возврата
Три большие фигурные скобки, находящиеся с левой стороны временной диаграммы, указывают на то, какие сегменты были использованы при расчете RTT. Не для всех сегментов время было засечено.
Большинство реализаций TCP, происходящих от Berkeley, рассчитывают только одно значение RTT для соединения за один раз. Если в тот момент, когда отправляется сегмент данных, таймер для данного соединения уже используется, время для этого сегмента не засекается.
Установка времени осуществляется путем увеличения счетчика каждый раз, когда запускается 500-миллисекундный таймер TCP. Это означает, что для сегмента, подтверждение на который прибывают через 550 миллисекунд после того, как сегмент был отправлен, может быть принято RTT как равное одному тику (500 миллисекунд), так и RTT равное двум тикам (1000 миллисекунд).
В дополнение к этому счетчику тиков для каждого соединения, запоминается начальный номер последовательности данных в сегменте. Когда принимается подтверждение, содержащее этот номер последовательности, таймер выключается. Если данные не были повторно переданы, когда прибыл ACK, хэшированное RTT и хэшированное среднее отклонение обновляется на основе новых значений.
Таймер для соединения, показанного на рисунке 21.2, стартует, когда передается сегмент 1, и выключается, когда прибывает подтверждение на него (сегмент 2). Несмотря на то, что его RTT равен 1,061 секунды (из вывода команды tcpdump), исследование отладочной информации сокета показывает, что за этот период произошло 3 тика часов TCP, а это обозначает, что RTT равен 1500 миллисекунд.
Следующий сегмент, для которого засекли время, сегмент номер 3. Когда, через 2,4 миллисекунды, передается сегмент номер 4, он не может быть отслежен по времени, так как таймер для этого соединения уже используется. Когда прибывает сегмент 5, подтверждая данные, на которые было засечено время, его RTT рассчитывается равным 1 тику (500 миллисекунд), даже несмотря на то, что, как мы видели из вывода команды tcpdump, его RTT равен 0,808 секунды.
Таймер стартует снова, когда передается сегмент 6, и выключается, когда прибывает подтверждение на него, через 1,015 секунды (сегмент 10). Полученный RTT равен 2 тикам часов. Сегменты 7 и 9 не могут быть оценены по времени, так как таймер занят. Также, когда принимается сегмент 9 (ACK 769), ничего не обновляется, так как подтверждение не подтверждает байты, на которые засекли время.
На рисунке 21.3 показана взаимосвязь между реальными RTT, которые мы можем определить из вывода команды tcpdump, и счетчиком тиков часов.
Рисунок 21.3 Расчет RTT и тики часов.
В этом примере было передано 128 сегментов и получено 18 значений RTT. На рисунке 21.4 показаны измеренные RTT (взятые из вывода tcpdump) вместе с RTO, используемого в TCP для установки тайм-аутов (взято из отладочной информации сокета). Момент времени 0 (на рисунке 21.2) по оси OX соответствует отправке первого сегмента данных, а не отправке первого SYN.
Рисунок 21.4 Рассчитанные RTT и RTO TCP для этого примера.
Первые три точки, которые соответствующие измеренным RTT, соответствуют трем RTT, которые мы показали на рисунке 21.2. Пропуски в значениях RTT около моментов времени 10, 14 и 21 вызваны повторными передачами, которые здесь имели место (что будет показано позже в этой главе). Алгоритм Карна не позволяет обновить наши оценки до тех пор, пока еще один сегмент не будет передан и подтвержден. Также обратите внимание на то, что для этой реализации рассчитанные RTO TCP всегда кратны 500 миллисекундам.
Расчет оценочных функций RTT
Давайте посмотрим, как устанавливаются и обновляются оценочные функции RTT (хэшированный RTT и хэшированное среднее отклонение), и как рассчитывается тайм-аут для каждой передачи.
Переменные A и D устанавливаются в 0 и 3 секунды соответственно. Исходный тайм-аут для передачи рассчитывается с использованием формулы
RTO = A + 2D = 0 + 2 x 3 = 6 секунд
(Коэффициент 2D используется только для этого первоначального расчета. Затем при расчете RTO к A прибавляется 4D, как было показано ранее.) Это RTO для передачи первоначального SYN.
В случае если исходный SYN потерян, осуществляется тайм-аут и повторная передача. На рисунке 21.5 показаны первые четыре строки вывода команды tcpdump.
Рисунок 21.5 Тайм-аут и повторная передача исходного SYN.
Когда тайм-аут возникает позже, через 5,802 секунды, текущий RTO рассчитывается следующим образом
RTO = A + 4D = 0 + 4 x 3 = 12 секунд
Затем к RTO равному 12 применяется экспотенциальное наращивание. Так как это первый тайм-аут, используется множитель 2, при этом значение следующего тайм-аута будет равно 24 секундам. Следующий тайм-аут рассчитывается с использованием множителя 4, значения тайм-аута становится 48 секунд: 12 x 4. (Эти исходные RTO для первого SYN, 6 секунд и затем 24 секунды, как раз то, что мы видели на рисунке 4.5.)
Когда отправляется первый сегмент данных (сегмент 1 на рисунке 21.2), RTO не меняется, опять же в соответствии с алгоритмом Карна. Текущее значение, равное 24 секундам, повторно используется до тех пор, пока не будет осуществлено измерение RTT. Это означает, что RTO для момента времени равного 0 на рисунке 21.4 равно в действительности 24, однако мы не берем во внимание эту точку.
Когда прибывает подтверждение на этот первый сегмент данных (сегмент 2 на рисунке 21.2), получено 3 тика часов, и наши показатели устанавливаются следующим образом
A = M + 0,5 = 1,5 + 0,5 = 2
(Значение M равное 1,5 соответствует 3-м тикам часов.) Предыдущие установки A и D в 0 и 3 были сделаны для расчета первоначального RTO. Эти установки предназначены для первого расчета оценочных функций, с использованием первого измерения RTT M. RTO рассчитывается следующим образом
RTO = A + 4D = 2 + 4 x 1 = 6 секунд
Когда прибывает ACK на второй сегмент данных (сегмент 5 на рисунке 21.2), отсчитан 1 тик часов (0,5 секунды), и наши показатели обновляются следующим образом
RTO = A + 4D = 1,8125 + 4 x 1,125 = 6,3125
Существует несколько тонкостей в представлении Err, A и D, при расчетах с фиксированной точкой, которая и используется в действительности (однако мы показали для простоты с плавающей точкой). Эта разница дает RTO равное 6 секундам (а не 6,3125), как раз столько, сколько было показано на рисунке 21.4 для момента времени 1,871.
Мы описали алгоритм медленного старта в разделе «Медленный старт» главы 20, а также видели его в действии на рисунке 21.2.
Первоначально по соединению отправляется только один сегмент, и подтверждение на него должно быть получено перед тем, как будет отправлен другой сегмент. Когда сегмент 2 принят, отправляются два следующих сегмента.
Давайте теперь рассмотрим передачу сегментов данных. На рисунке 21.6 показана зависимость стартового номера последовательности сегмента от времени, когда сегмент был отправлен. Это позволит нам более наглядно представить процесс передачи данных. Обычно точки, соответствующие данным, должны двигаться вверх вправо, при этом наклон соответствует скорости передачи. Повторные передачи показаны отклонением графика вниз вправо.
В начале раздела «Пример RTT» этой главы мы сказали, что полное время передачи составляло примерно 45 секунд, однако на этом рисунке мы показали только 35 секунд. (Потому что, именно 35 секунд потребовалось для передачи только сегментов данных.) Первый сегмент данных не передавался в течении 6,3 секунды после отправки первого SYN, потому что первый SYN был потерян при передаче и передан повторно (рисунок 21.5). После того как последний сегмент данных и FIN были отправлены (момент времени 34,1 на рисунке 21.6), потребовалось еще примерно 4,0 секунды на то, чтобы принять последние 14 ACK от получателя перед тем, как от получателя был получен FIN.
Рисунок 21.6 Отправка 32768 байт данных от slip на vangogh.
На рисунке 21.6 мы сразу видим три повторные передачи в моменты времени 10, 14 и 21. Во всех трех случаях только один сегмент передается повторно, потому что только одна точка оказалась ниже предыдущих.
Давайте рассмотрим первый из этих «скачков вниз» (в момент времени 10). Вывод команды tcpdump мы рассмотрим вместе с рисунком 21.7.
Рисунок 21.7 Обмен пакетами в процессе повторной передачи в районе 10-секундной метки.
Мы удалили все объявления окна, за исключением сегмента 72, который мы обсудим ниже. slip всегда объявляет окно равное 4096, а vangogh объявляет окно равное 8192. Сегменты на этом рисунке пронумерованы как продолжение рисунка 21.2, где первый сегмент данных по соединению был с номером 1. Как и на рисунке 21.2, сегменты пронумерованы в соответствии с тем, как они отправлялись или принимались на хосте slip, где была запущена программа tcpdump. Мы также удалили несколько сегментов, которые не имели отношения к нашему обсуждению (44, 47 и 49, а также все ACK от vangogh).
Обратите внимание на то, что после повторной передачи (сегмент 63) отправитель продолжает обычную передачу данных (сегменты 67, 69 и 71). TCP не ожидает того, что удаленный конец подтвердит повторную передачу.
Давайте посмотрим, что происходит на принимающем конце. Когда обычные данные приходят последовательно (сегмент 43), принимающий TCP передает 256 байт данных пользовательскому процессу. Однако следующий принятый сегмент (сегмент 46) не в порядке; стартовый номер последовательности данных (6913) не является следующим ожидаемым номером последовательности (6657). TCP сохраняет 256 байт данных и отвечает посредством ACK с самый большим номером последовательности, который был принят успешно, плюс один (6657). Следующие семь сегментов, принятых vangogh (48, 50, 52, 54, 55, 57 и 59), также не в порядке. Данные сохраняются принимающим TCP, и генерируются дублированные ACK.
Если мы рассмотрим более подробно вывод команды tcpdump для моментов времени 14 и 21 на рисунке 21.6, то увидим, что они были вызваны получением трех дублированных ACK, а это указывает на то, что пакет был потерян. Во всех этих случаях только один пакет был передан повторно.
Мы продолжим рассмотрение этого примера в разделе «Пример переполнения (продолжение)» этой главы, после того как рассмотрим более подробно алгоритм предотвращения переполнения.
Алгоритм предотвращения переполнения
Медленный старт, который мы описали в разделе «Медленный старт» главы 20, это способ первоначально установить поток данных по соединению. Однако, в это же самое время мы достигнем предела у промежуточного маршрутизатора, при котором пакеты будут отбрасываться. Предотвращение переполнения это способ, позволяющий предотвратить потерю пакетов. Подробности можно найти в [ Jacobson 1988].
Предположение, на котором строится этот алгоритм, заключается в том, что из-за различных повреждений теряется очень малое число пакетов (значительно меньше чем 1%), поэтому потеря пакетов сигнализирует о том, что в каком-либо месте сети между источником и назначением появилось переполнение. Существуют два признака, по которым можно определить, что пакеты теряются: появление тайм-аутов и получение дублированных ACK. (Мы видели последнее в разделе «Пример переполнения» этой главы. Если же использовать тайм-аут как показатель возникновения переполнения, то нам потребуется хороший алгоритм расчета RTT, примерно такой, как описан в разделе «Определение времени возврата».)
Предотвращение переполнения и медленный старт это независимые друг от друга алгоритмы, более того, работающие с различными объектами. Однако, когда возникает переполнение, мы хотим замедлить скорость передачи пакетов по сети, а затем использовать медленный старт, чтобы начать все с начала. На практике эти алгоритмы используются вместе.
Предотвращение переполнения и медленный старт требуют, чтобы для каждого соединения были определены две переменные: окно переполнения, cwnd, и размер порога медленного старта, ssthresh. Вместе алгоритмы работают следующим образом:
Инициализация заданного соединения устанавливает cwnd в один сегмент, а ssthresh в 65535 байт. Подпрограмма вывода TCP определит, какое из значений меньше: cwnd или окно, объявленное получателем и никогда не пошлет больше минимального значения. Предотвращение переполнения это способ контролировать поток данных, со стороны отправителя, тогда как объявление окна это способ контролировать поток данных, со стороны получателя. Первый основан на оценке отправителем того, насколько переполнена сеть, тогда как последний связан с величиной доступного буферного пространства у получателя для данного соединения. Когда возникает переполнение (на что указывает тайм-аут или получение дублированных ACK), одна половина текущего размера окна (меньшее значение из величин cwnd и размера окна, объявленного получателем, но по меньшей мере два сегмента) сохраняется в ssthresh. Более того, если мы узнали о переполнении с помощью тайм-аута, cwnd устанавливается в один сегмент (то есть осуществляется медленный старт). Когда новые данные подтверждены удаленным концом, cwnd увеличивается, однако способ этого увеличения зависит от того, работает ли алгоритм медленного старта или предотвращения переполнения. Если cwnd меньше или равно ssthresh, используется медленный старт; иначе используется предотвращение переполнения. Медленный старт продолжается до тех пор, пока мы не достигнем половины пути до того момента где были, когда возникло переполнение (то есть, до того момента пока мы не запишем половину размера окна, которое доставило нам проблемы в шаге 2), после чего используется алгоритм предотвращения переполнения. Медленный старт требует, чтобы cwnd начиналась с одного сегмента и увеличивалась на один сегмент каждый раз при приеме ACK. Как указано в разделе «Медленный старт» главы 20, это открывает окно экспотенциально: посылается один сегмент, затем два, затем четыре и так далее. Предотвращение переполнения требует, чтобы cwnd увеличивалась на 1/cwnd плюс меньшая дробная часть размера сегмента (размер сегмента, поделенный на 8) каждый раз, когда прибывает ACK. (Это ошибка реализации, которая присутствовала во всех релизах 4.3BSD и даже в 4.4BSD. Но этой ошибки нет в будущих реализациях [Floyd 1994]. Обратите внимание на то, что в примерах ниже в главе используется этот термин, потому что примеры исполнялись на реализации с ошибкой [см. рисунок 21.9 и рисунок 21.11]). Это увеличение посредством сложения, по сравнению с экспотенциальным увеличением при медленном старте. Мы хотим увеличивать cwnd по крайней мере на один сегмент за каждый промежуток времени равный времени возврата (вне зависимости от того, сколько ACK было принято за этот RTT), тогда как медленный старт увеличивает cwnd на количество ACK принятых за время возврата. Прибавление меньшей дробной части размера сегмента позволяет быстрее открывать большие окна.
Релиз 4.3BSD Tahoe, описанный в [ Leffler et al. 1989], осуществляет медленный старт, только если удаленный конец находится в другой сети. Это было изменено в релизе 4.3BSD Reno таким образом, что медленный старт осуществляется всегда.
На рисунке 21.8 приведено описание медленного старта и предотвращения переполнения. Мы показали размер cwnd и ssthresh в блоках сегментов, тогда как в действительности их размер измеряется в байтах.
Рисунок 21.8 Медленный старт и предотвращение переполнения.
Как видно из этого рисунка, термин «медленный старт» не вполне корректен. Это, скорее, замедление передачи пакетов, которое вызвано переполнением, однако скорость увеличения количества пакетов, отправленных в сеть, увеличивается в течение медленного старта. Скорость увеличения не уменьшается до тех пор, пока не будет достигнуто значение ssthresh, когда начинает действовать предотвращение переполнения.
Быстрая повторная передача и алгоритм быстрого восстановления
В тексте не приводится достаточно жесткого разграничения между алгоритмом быстрой повторной передачи и быстрого восстановления. Это два абсолютно независимых алгоритма. Алгоритм быстрой повторной передачи вступает в действие, когда TCP определяет потерю сегмента и номер потерянного сегмента по наличию небольшого количества последователььных дублированных подтверждений (ACK). Потерянный сегмент передается повторно. Алгоритм быстрого востановления говорит, что после быстрой повторной передачи необходимо осуществить предотвращение переполнения, а не медленный старт. Алгоритм быстрой повторной передачи впервые появился в 4.3BSD Tahoe, однако за ним неправильно следовал медленный старт. Алгоритм быстрого восстановления впервые был применен в 4.3BSD Reno.
В 1990 году [ Jacobson 1990b] алгоритм предотвращения переполнения был модифицирован. Мы уже видели эти модификации в действии в примере переполнения (раздел «Пример переполнения» этой главы).
Перед тем как познакомиться с этими изменениями представьте, что TCP требует сгенерировать немедленное подтверждение (дублированный ACK), когда принят поврежденный сегмент. Этот дублированный ACK не должен быть задержан. Цель дублированного ACK заключается в том, чтобы сообщить удаленному концу о том, что сегмент был получен поврежденным, и сообщить, какой ожидается номер последовательности.
Так как мы не знаем, было ли дублирование ACK вызвано потерей сегмента или просто тем, что изменился порядок следования сегментов, мы ожидаем прихода небольшого количества дублированных ACK. Это означает, что если сегменты просто пришли в другом порядке, будет получено только один или два дублированных ACK перед тем, как перемешанные сегменты будут обработаны, после чего будет сгенерирован новый ACK. Если же последовательно пришло три или более дублированных ACK, это уже является признаком того, что сегмент был потерян (раздел «Пример переполнения»). Мы осуществляем повторную передачу отсутствующего сегмента, не ожидая истечения таймера повторной передачи. Также мы осуществляем предотвращение переполнения, но не медленный старт.
На рисунке 21.7 мы видели, что медленный старт не осуществлялся после того, как было принято три дублированных ACK. Вместо этого отправитель осуществил повторную передачу, за которой следует три сегмента новых данных (сегменты 67, 69 и 71), перед тем как были получены подтверждения на повторную передачу (сегмент 72).
Причина того, что в этом случае не был применен медленный старт, заключается в том, что получение дублированных ACK сообщило нечто большее, нежели просто о потере одного пакета. Так как получатель может только генерировать дублированные ACK, когда прибывает еще один сегмент, можно сказать, что этот сегмент вышел из сети и находится в буфере получателя. Таким образом, данные все еще двигаются между двумя концами, и мы не хотим внезапно уменьшить поток, воспользовавшись медленным cтартом.
Алгоритм функционирует следующим образом.
Передается отсутствующий сегмент.
Значение cwnd устанавливается в значение ssthresh плюс утроенное значение размера сегмента.
Мы увидим, что произойдет с переменными cwnd и ssthresh, в следующем разделе.
Пример переполнения (продолжение)
Просматривая соединение с использованием tcpdump и отладочной опции сокетов (которую мы описали в разделе «Пример RTT»), мы можем увидеть значения cwnd и ssthresh при передаче каждого сегмента. Если максимальный размер сегмента ( MSS) равен 256 байт, исходные значения cwnd и ssthresh будут равны 256 и 65535 соответственно. Каждый раз, когда принимается ACK, cwnd увеличивается на значение MSS и принимает значения 512, 768, 1024, 1280 и так далее. Предположим, что переполнения не происходит, поэтому окно переполнения достигнет значения окна, объявленного получателем, а это, в свою очередь, будет означать, что объявленное окно ограничивает поток данных.
Однако нам интересно посмотреть, что произойдет в случае возникновения переполнения. Рассмотрим тот же пример из раздела «Пример RTT». В этом примере переполнение появлялось четыре раза. Был тайм-аут при передаче исходного SYN, который предназначался для установления соединения (рисунок 21.5), после чего, в процессе передачи данных, было потеряно три пакета (рисунок 21.6).
На рисунке 21.9 показаны значения двух переменных cwnd и ssthresh, когда осуществлялась повторная передача исходного SYN, за которым следовало семь первых сегментов данных. (Мы показали обмен исходными сегментами данных и их ACK на рисунке 21.2.) Переданные байты данных показаны в формате вывода команды tcpdump: 1:257(256), что означает байты с 1 по 256.
Когда возникает тайм-аут при передаче SYN, ssthresh устанавливается в свое минимальное значение (512 байт, что равно, в этом примере, двум сегментам). cwnd устанавливается в один сегмент (256 байт), чтобы войти в фазу медленного старта.
Когда получены SYN и ACK, с этими переменными ничего не происходит, так как новые данные не были подтверждены.
Когда прибывает ACK 257, мы все еще находимся в режиме медленного старта, так как cwnd меньше либо равно ssthresh, поэтому cwnd увеличивается на 256. То же самое происходит, когда прибывает ACK 513.
Когда прибывает ACK 769, мы больше не находимся в режиме медленного старта, однако переходим в режим предотвращения переполнения. Новое значение cwnd рассчитывается следующим образом
cwnd ¬ cwnd + (разм.сегмента x разм.сегмента)/cwnd + разм.сегмента/8
Это больше на 1/cwnd, чем то, что мы показали ранее, принимая во внимание то, что cwnd рассчитывается в действительности в байтах, а не в сегментах. Для этого примера мы рассчитаем