Протоколы Internet


Протокол TCP - часть 4


В состоянии established пакет будет принят сервером, если его ISN лежит в пределах s_ack, s_ack+s_wind (s_wind – ширина окна для сервера; см. рис. 4.4.3.5). Аналогичный диапазон isn для клиента выглядит как: c_ack, c_ack+c_wind (c_wind – ширина окна для клиента). c_wind и s_wind могут быть не равны. Пакеты, для которых эти условия не выполняются, будут отброшены.

Рассмотрим пример установления соединения для случая FTP-запроса (См. также http://www.cis.ohio-state.edu/~dolske/gradwork/cis694q). Пусть клиент С запускает процесс установления FTP-соединения с сервером s. Обычный порядок установления соединения показан ниже (см. рис. 4.4.3.3):

c -> s:syn(isnc)

s -> c:syn(isns), ack(isnc)

c -> s: ack(isns) (Связь установлена)

c -> s: данные

и/или

s -> c: данные

isn – идентификатор пакета, посылаемого клиентом (С) или сервером (S). Клиент, послав syn серверу S, переходит в состояние syn_sent. При этом запускается таймер установления соединения. Как при установлении соединения так и при его разрыве приходится сталкиваться с проблемой двух армий. Представим себе, что имеется две армии А и Б, причем Б больше по численности чем А. Армия Б разделена на две части, размещенные по разные стороны от армии А. Если две части армии Б одновременно нападут на армию А, победа гарантирована. В то же время нападение на А одной из частей армии Б обрекает ее на поражение. Но как обеспечить одновременность? Здесь предполагается, что радио еще не изобретено и передача сообщений осуществляется вестовыми, которые в нашем случае могут быть перехвачены врагом. Как убедиться, что вестовой дошел? Первое, что приходит в голову, это послать другого вестового с подтверждением. Но он также с некоторой вероятностью может быть перехвачен. А отправитель не будет знать, дошел ли он. Ведь если сообщение перехвачено, отправитель первичного запроса не выдаст команды на начало, так как не уверен, дошло ли его первое сообщение. Возникает вопрос, существует ли алгоритм, который бы гарантировал надежность синхронизации решений путем обмена сообщениями при ненадежной доставке? Повысит ли достоверность увеличение числа обменов между партнерами? Ответом на этот вопрос будет - нет не существует. В этом читатель, порассуждав логически, может убедиться самостоятельно. Не трудно видеть, что схожие проблемы возникают в любом протоколе, работающем через установление соединения. Чаще всего эта проблема решается путем таймаутов и повторных попыток (это, слава богу, не война и все обходится без людских жертв).




Начало  Назад  Вперед