L10-Сети (tcp v2)
.pdf
«Медленный старт»
Подобная стратегия может показаться вполне приемлемой, но, к сожалению, только на первый взгляд
Поскольку перегрузить сеть легко, а восстановить ее нормальное функционирование сложно
После возникновения перегрузки для восстановления рабочих параметров сети могут потребоваться достаточно длительное время и значительные усилия администратора и участников сетевого обмена
Следовательно, при экспоненциальном росте размера окна перегрузки
CWND (после восстановления единичного значения) его величина способна довольно быстро снова достичь максимума, хотя к этому времени нормальные параметры сети еще не будут восстановлены
Поэтому повторный «Медленный старт» не облегчит, а, наоборот, усложнит процесс восстановления
© Masich G.F. 18.11.2013 |
ТСР |
82 |
«Медленный старт»
Для разрешения указанной проблемы был предложен алгоритм «Медленный старт» с линейным ростом размера окна перегрузки
CWND.
1.Значение переменной SSTHREST (порог «Медленного старта») устанавливается равным половине текущего размера окна перегрузки:
SSTHREST = CWND/2
2.CWND = 1 и выполняется процедура «Медленного старта» до тех пор, пока
CWND < SSTHREST (шаг 1)
В этой фазе размер окна CWND будет увеличиваться на единицу после
получения подтверждения о приеме каждого посланного сегмента
(экспоненциальная фаза)
3. Если CWND > SSTHREST, то его следует увеличивать на единицу каждый раз по истечении времени обращения сегмента RTT.
© Masich G.F. 18.11.2013 |
ТСР |
83 |
«Медленный старт»
Модифицированный вариант процедуры «Медленный старт» показан на рис. 11. При
этом на рис. 11,а отображена динамика роста размера окна перегрузки, аналогичная
представленной на рис. 10, только в данном случае последний сегмент потерян. Рис. 11,б иллюстрирует реакцию протокола на потерю сегмента. Значение переменной SSTHREST устанавливается равным восьми. До тех пор, пока размер окна перегрузки не достигнет этой величины, оно растет по экспоненте, а после прохождения указанного рубежа увеличивается линейно.
На рис. 12 окно CWND шириной восемь сегментов задает граничное значение. И если
для достижения тайм-аута здесь понадобилось четыре времени обращения RTT, то для повторного вхождения в этот режим потребуется уже одиннадцатикратное время RTT.
© Masich G.F. 18.11.2013 |
ТСР |
84 |
Рис.11 «Медленный старт» с линейным ростом окна перегрузки: а — заканчивающийся потерей сегмента; б — с предотвращением перегрузки
© Masich G.F. 18.11.2013 |
ТСР |
85 |
Рис.12 Временная диаграмма для алгоритмов «Медленный старт» и предотвращения перегрузок
© Masich G.F. 18.11.2013 |
ТСР |
86 |
Таймеры TCP
© Masich G.F. 18.11.2013 |
ТСР |
87 |
Таймеры TCP
Для взаимного согласования операций в рамках TCPпротокола используется четыре таймера:
1.Таймер повторных передач (retransmission; RTO)
Контролирует время прихода подтверждений (ACK)
Запускается в момент посылки сегмента
При получении отклика ACK до истечения времени таймера, он
сбрасывается
Если же время таймера истекает до прихода ACK, сегмент посылается адресату повторно, а таймер перезапускается.
© Masich G.F. 18.11.2013 |
ТСР |
88 |
Таймеры TCP
2.Таймер запросов (persist timer)
Контролирует размер окна при window=0
Получатель при изменении ситуации посылает сегмент с ненулевым значением ширины окна, что позволит отправителю возобновить свою работу.
Но если этот сегмент будет потерян, возникнет тупик, тогда каждая
из сторон ждет сигнала от партнера
Именно в этой ситуации и используется таймер запросов. По истечении времени этого таймера отправитель пошлет сегмент адресату.
Отклик на этот сегмент будет содержать новое значение ширины окна.
Таймер запускается каждый раз, когда получен сегмент с window=0
© Masich G.F. 18.11.2013 |
ТСР |
89 |
Таймеры TCP
3.Таймер контроля работоспособности (keepalive)
Регистрирует факты выхода из строя или перезагрузки ЭВМпартнеров.
Время по умолчанию равно 2 часам.
Keepalive-таймер не является частью TCP-спецификации.
Полезен для выявления состояний сервера half-open при условии, что клиент отключился (например, пользователь выключил свою
персональную ЭВМ, не выполнив LOGOUT).
По истечении времени таймера клиенту посылается сегмент проверки состояния. Если в течение 75 секунд будет получен отклик, сервер повторяет запрос 10 раз с периодом 75 сек, после чего соединение разрывается. При получении любого сегмента от клиента таймер
сбрасывается и запускается вновь.
© Masich G.F. 18.11.2013 |
ТСР |
90 |
Таймеры TCP
4.2MSL-таймер (Maximum Segment Lifetime)
Контролирует время пребывания канала в состоянии TIME_WAIT.
Выдержка таймера по умолчанию равно 2 мин (FIN_WAIT- таймер) и RFC-793.
Таймер запускается при выполнении процедуры active close в
момент посылки последнего ACK
© Masich G.F. 18.11.2013 |
ТСР |
91 |