Механизм построения соединения выглядит следующим образом.
- Приложение инициатор соединения обращается к своей ОС с запросом активного открытия соединения (active open).
- ОС должна выделить процессу инииатору протокольный порт
- после чего его партнеру высылается сообщение, которое устанавливает счетчики переданных данных в исходное состояние (происходит синхронизация потоков).
- К этому времени процесс партнер должен выполнить функцию пассивного открытия (passive open) соединения, указывая тем самым своей ОС, что приложение ожидает входящий трафик, и тоже получить номер протокольного порта.
Строгое описание процесса с помощью конечных автоматов я приведу позже.
Протокол TCP обеспечивает надежную доставку данных в том смысле, что он организует прямое подтверждение корректного приема информации получателем. Процесс подтверждения называется квитирование (выдача квитанции). Он достаточно любопытен.
Отправитель шлет получателю некоторую порцию данных. В процессе доставки даные могут быть утеряны или искажены, поэтому получатель, если он конечно вообще хоть что-то получил, должен произвести проверку их корректности и целостности. Делается это путем расчета контрольной суммы. Мы не будем разбирать подробно, только отметим, что при расчете контрольной суммы по своему сообщению (а оно у TCP называется сегментом, segment) протокол TCP использует механизм подстановки псевдозаголовка, полностью аналогичный соответствующей операции в протоколе UDP. Формат псевдозаголовка совпадает с уже рассмотренным нами форматом псевдозаголовка UDP, лишь с тем отличием, что поле Protocol содержит код протокола TCP (число 6). Если контрольная сумма сошлась, то есть данные получены без искажений, то агент протокола TCP хоста получателя шлет квитанцию – подтверждение приема; если контрольная сумма не сходится, то никакой квитанции не выдается.
Отправитель должен учитывать, что возможна потеря высланного им пакета, искажение данных или, наконец, потеря высланной получателем квитанции. Во всех трех случаях отправитель не получит никаких известий от получателя о состоянии процесса передачи информации. Ожидание может затянуться…. Для выхода из состояния бесконечного ожидания отправитель устанавливает таймер, «засекая» время отправления пакета. Период ожидания называют тайм-аутом (timeout) По истечении этого времени отправитель считает, что пакет утерян или искажен, и повторяет передачу.
Такая техника называется положительным квитированием с повтором передачи (positive acknowledgement with retransmission). Описанный механизм может быть проиллюстрирован на рисунке. Считаем что вертикальные линии ограничивают действие протокола. Между ними находятся протоколы нижележащих уровней и среда пердачи данных. Время течет сверху вниз, поэтому стрелки наклонены., то есть произведен учет конечного времени распространения информации.
Передача пакета 1
Получение пакета 1
Передача квитанции на пакет 1
Прием квитанции на пакет 1
Передача пакета 2
Прием пакета 2
Передача квитанции на пакет 2
Прием квитанции на пакет 2
Оптимизация длительности timeout
В громадной сети Internet нельзя заранее принять некоторое среднее время тайм-аута. Установишь большое – ограничишь пропускную способность, так как отправитель слишком долго будет эдать подтверждения. Установишь маленькое – появится множество лишних повторных посылок.
Поэтому в TCP принята достаточно сложная логика оптимизации длительности интервала ожидания. Техничесике решения на эту тему достаточно долго дискутировались в литературе и принимались не просто. Там заложены достаточно сложные математические аппараты, и тот, кто заинтересуется этим, может поковыряться самостоятельно. Мы ограничимся только общим описанием.
Всякий раз, отправляя пакет, TCP измеряет время до прихода квитанции. Это так называемое время двойного прохода (round trip time, RTT). Результаты измерений уредняются с убывающим для более ранних измерений весом.
Длительность тайм-аута устанавливается пропорционально усредненному
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.