Политики отправки и приема сегментов

При отсутствии данных, помеченных флагом PSH, протокол TCP на стороне отправителя может сам решать, когда следует осуществить передачу. Когда дан­ные передаются модулю протокола TCP пользовательским приложением, они записываются в передающий буфер. Протокол TCP может создавать сегмент для каждой группы данных, предоставленных приложением, или он может ожидать накопления определенного количества данных и только после этого формиро­вать и отправлять сегмент. То, какая политика отправки лучше, всецело зависит от требований к производительности. Если передачи сегментов происходят редко, но при этом передаются большие объемы данных, то сегменты можно формировать сразу при поступлении данных — накладные расходы здесь будут невелики. С другой стороны, даже если объем передаваемых данных невелик, иногда имеет смысл слать их сразу же при поступлении — при этом накладные расходы велики, но такая система обеспечивает быструю реакцию на изменения состояния сети.

При отсутствии данных, помеченных флагом PSH, протокол TCP на стороне получателя также может самостоятельно решать, когда следует доставить дан­ные пользовательскому приложению. Так, он может доставлять данные при получении каждого сегмента по порядку или заносить данные из нескольких сегментов в буфер приема. Как и в случае с отправкой, выбор политики достав­ки зависит от требований к производительности. Если данные приходят редко и имеют большой объем, то приложение получит их сразу. С другой стороны, если данные поступают часто и маленькими порциями, то немедленная их передача приложению приведет к неэффективному расходованию ресурсов приложения и протокола TCP.

Если сегменты поступают в порядке их отсылки по установленному соедине­нию, протокол TCP помещает их данные в буфер получения для доставки поль­зовательскому приложению. Но вполне возможна ситуация, при которой определенный сегмент поступит не в порядке отправления. В этом случае про­токол TCP на принимающей стороне может либо принимать только те сегменты, которые поступают в порядке отправления (другие сегменты просто отбрасыва­ются), либо принимать все сегменты, номера которых зафиксированы в окне приема (вне зависимости от порядка их поступления).

Первый вариант действий упрощает реализацию протокола, но при этом воз­никает дополнительная нагрузка на сеть, так как отправитель будет ожидать некоторое время, а затем повторно передаст отброшенные сегменты, которые хотя и были успешно получены, но затем были отброшены из-за некорректного порядка поступления. Более того, если один сегмент был потерян при передаче, то необходимо посылать повторно все последующие сегменты.

При втором варианте может быть снижено количество повторных передач, но при этом требуется более сложный алгоритм приема и более сложная схема сохра­нения данных для буферизации и отслеживания порядка поступления данных.

Протокол TCP поддерживает очередь сегментов, которые были посланы, но еще не были подтверждены. Спецификация протокола говорит, что он будет повторно передавать сегмент, если на него не было получено подтверждение в определенный период времени. Реализация протокола TCP может поддерживать три режима повторной передачи:

q Только первый. Поддерживается один таймер повторной передачи для всей очереди. Если получено подтверждение, из очереди повторной пере­дачи удаляется первый сегмент и таймер сбрасывается. Если таймер сра­батывает (подтверждение не получено за указанное время), сегмент из начала очереди передается повторно, а таймер сбрасывается.

q Пакетный. Поддерживается один таймер повторной передачи для всей очереди. Если получено подтверждение, из очереди повторной передачи удаляются все сегменты и таймер сбрасывается. Если таймер срабатывает (подтверждение не получено за указанное время), все сегменты из очереди передаются повторно, а таймер сбрасывается.

q Индивидуальный. Для каждого сегмента в очереди поддерживается отдельный таймер. Если на определенный сегмент получено подтвержде­ние, из очереди повторной передачи удаляется соответствующий сегмент и обнуляется его таймер. Если какой-либо из таймеров срабатывает, то соответствующий сегмент передается повторно, а его таймер сбрасыва­ется.

Режим «Только первый» повышает эффективность передачи трафика, так как только потерянные сегменты (или сегменты, чьи подтверждения были поте­ряны) передаются повторно. Но из-за того, что таймер для второго сегмента в очереди не устанавливается до тех пор, пока не подтвержден первый сегмент, могут возникать некоторые задержки. Индивидуальный режим решает эти про­блемы, но его реализация более сложна. Пакетный режим также снижает веро­ятность длительных задержек, но может привести к ненужным повторным передачам.

Реальная эффективность той или иной политики повторной передачи зави­сит от политики приема сегментов на стороне получателя. Если получатель ис­пользует политику приема, в соответствии с которой принимаются только сегменты, следующие в порядке отправления, то он будет отбрасывать сегменты, полученные после потерянного сегмента. Такая схема работы хорошо подходит к пакетной политике повторной передачи. Если получатель принимает все сег­менты несмотря на порядок их прибытия, то оптимальными являются режимы «Только первый» или «Индивидуальный».

При поступлении сегмента протокол TCP на принимающей стороне имеет два варианта действий для отправки подтверждения:

q Немедленно. Как только данные с определенным номером в последова­тельности приняты, немедленно передается пустой (без данных) сегмент, содержащий соответствующий номер подтверждения.

q С накоплением. Когда данные, посланные отправителем, успешно при­няты, протокол отмечает необходимость их подтверждения. Флаг АСК может быть выставлен в сегменте с данными, который получатель отпра­вит в ответ отправителю. Для избежания длительных задержек устанавли­вается таймер окна. Если таймер истекает до момента отсылки очередного сегмента с подтверждением, то посылается пустой сегмент, содержащий соответствующий номер подтверждения.

Первый вариант прост в реализации, позволяет протоколу TCP на отправ­ляющей стороне полностью «контролировать ситуацию» и уменьшает число повторных передач. Однако такой подход приводит к тому, что по сети часто передаются подтверждения (пустые сегменты, используемые только для под­тверждения). Следовательно, возрастает загрузка сети. Рассмотрим, например, ситуацию, при которой протокол TCP на принимающей стороне получает сег­мент и немедленно посылает на него подтверждение. А приложение на прини­мающей стороне вдруг расширяет окно приема, вызывая тем самым посылку еще одного пустого сегмента для предоставления дополнительного кредита отправляющей стороне. Очевидно, что накладные расходы здесь достаточно ве­лики. Поэтому обычно используется вариант работы с накоплением. Следует отметить, что политика с накоплением приводит к увеличению нагрузки на при­нимающую сторону и усложняет задачу отправителя по оценке времени обраще­ния.

Дата добавления: 2015-07-13