Таймаут потока что это такое
Тайм-аут операции: причины возникновения ошибки и методы ее исправления
Достаточно часто многие пользователи ПК, которые так или иначе связаны с Интернетом, а также геймеры, подключающиеся к игровым порталам, наблюдают появление ошибок соединения с сервером. Сейчас мы рассмотрим вопрос о том, что значит тайм-аут операции. Более того, будет предложено несколько основных способов решения этой проблемы.
Итак, на экране монитора возникает ошибка, сообщающая пользователю о том, что соединение прервано, вернее, время ожидания подключения истекло.
В принципе, тайм-аут и можно трактовать как некий временной промежуток, в течение которого система ожидает ответа сервера на собственный отправленный запрос. В системах Windows это параметр установлен по умолчанию, а его значение прописано в сетке системного реестра настроек текущего компьютерного терминала в подразделе SYSTEM, где во вложенных директориях находится подпапка Parameters, где время указано в секундах. Как правило, изменять его не рекомендуется.
Причины возникновения ошибки
Причин, когда возникает тайм-аут операции, может быть довольно много. Выделим наиболее часто встречающиеся ситуации. Прежде всего, в качестве основного фактора выступает нестабильное подключение к Интернету, когда постоянно происходит прерывание связи, и система не может получить цельный ответ сервера, к которому в данный момент выполняется подключение.
В некоторых случаях тайм-аут операции может срабатывать при включенных антивирусных программах или при неправильных настройках брэндмауэра Windows. Как известно, брэндмауэр при настройках по умолчанию способен блокировать достаточно много веб-ресурсов, считая их опасными или содержащими потенциально нежелательные данные. Такое очень часто встречается при подключению к серверам многопользовательских онлайн-игр.
Кроме всего прочего, тайм-аут операции завершает время ожидания подключения при использовании или неправильной настройке прокси-сервера. В данном случае речь идет и о настройках прокси в системе, и об использовании анонимных прокси-серверов, когда пользователь по каким-либо причинам хочет остаться во Всемирной паутине неузнанным, а проще говоря, скрыть истинный IP-адрес своего компьютерного терминала. Рассмотрим несколько основных методов исправления ситуации без вмешательства в системный реестр для выставления более высокого значения периода ожидания.
Тайм-аут операции: что делать? Простейший способ исправления ситуации
Как считается, наиболее простым способом, позволяющим избавиться от ошибки 118, является обычное закрытие не отвечающей страницы и ее повторное открытие по истечении минут десяти. Иногда может потребоваться закрыть и перезапустить сам интернет-браузер (часто такие ситуации почему-то наблюдаются в Google Chrome и других браузерах на его основе).
Если такой вариант не помогает, а сообщение «Ошибка: Тайм-аут операции…» выдается снова, можно применить обычную перезагрузку компьютера или ноутбука (а лучше и всех маршрутизаторов типа роутеров или ADSL-модемов).
Достаточно эффективным может оказаться решение проблемы, связанное с внесением, допустим, игрового сайта в список разрешений (исключений) антивируса и брэндмауэра, тем более что в обоих случаях в настройках сделать это не так уж и сложно.
Изменение параметров прокси-сервера
Несколько сложнее обстоит дело с настройками прокси в системе. Рассмотрим в качестве примера стандартный Internet Explorer. В браузере нужно использовать раздел «Свойства обозревателя» и вкладку «Подключения».
Снизу имеется кнопка «Настройка сети», после нажатия на которую будет произведен вход в окно настройки параметров локальной сети. Здесь достаточно просто снять галочку (флажок) со строки «Использовать прокси-сервер» и сохранить изменения (иногда можно отключить прокси для локальных адресов).
Но вот если подключение производится при помощи прокси, для установки правильных настроек лучше обратиться к провайдеру.
Исправление системного файла Hosts
Теперь перейдем к более сложному методу исправления ошибок, когда может срабатывать тайм-аут операции.
Сначала в меню отображения файлов и папок (в стандартном «Проводнике» это меню «Сервис» со строкой «Параметры папок») на вкладке вида необходимо задать показ скрытых папок и файлов.
После вышеуказанной операции необходимо открыть меню «Выполнить» и ввести в строке команду «notepad %windir%\system32\drivers\etc\hosts» (естественно, без кавычек), поле чего в «Блокноте» будет открыт файл Hosts. Обратите внимание: снизу имеется строка «::1 localhost». По идее, она должна быть последней, так что все, что находится ниже нее, нужно удалить, после чего произвести сохранение файла с оригинальным названием и местоположением. Теперь остается только перезагрузить компьютерный терминал. Затем, как правило, ошибка исчезает.
Заключение
Вот, собственно, и все по поводу срабатывающего тайм-аута. Конечно, можно использовать еще и редактирование системного реестра с заданием большего значения периода ожидания ответа сервера, вот только гарантии, что все остальные ресурсы будут грузиться без проблем, никто дать не может. К тому же, как уже понятно, и сами страницы, если и будут грузиться, то намного дольше. А это ни одному юзеру не нужно.
Таймаут потока что это такое
Мы уже видели два примера тайм-аута и повторной передачи: (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 рассчитывается в действительности в байтах, а не в сегментах. Для этого примера мы рассчитаем