7. Протокол tcp

Для достижения высокой производительности конечных систем и сети в целом очень важно правильно выбрать транспортный протокол. Транспортный прото­кол обеспечивает интерфейс между приложениями и сетевым оборудованием. Он выполняет несколько функций, в том числе, позволяет приложениям запра­шивать желаемое качество обслуживания. Сетевые приложения фирмы Micro­soft требуют, чтобы сетевые драйверы обеспечивали как режим передачи данных с гарантией доставки, так и негарантированную доставку. При передаче с гаран­тией доставки потеря данных исключается, так как постоянно проводится под­тверждение успешности приема. Если подтверждение не получено, производится повторная посылка данных. Ориентированные на предварительное установление соединения транспортные протоколы, такие как TCP (Transmission Control Pro­tocol), делят общий поток данных приложения на раздельные логические потоки и могут дифференцированно распределять ресурсы между ними, что позволяет эффективно использовать общую пропускную способность.

Протокол управления передачей данных TCP описан в документе RFC 793. Протокол TCP — это основной транспортный протокол стека протоколов TCP/IP. Он обеспечивает надежную передачу данных, базируясь на услугах протокола IP. На протокол TCP, в частности, возложена задача управления потоками и перегрузками, что подразумевает согласование скорости передачи данных с техническими возможностями рабочей станции-получателя и проме­жуточных устройств.

Поступающие к получателю данные буферизуются средствами протокола TCP. Перед отправкой данные также буферизуются.

Для достижения необходимой для данного логического соединения пропуск­ной способности важно правильно выбрать реализацию протокола TCP и опти­мально настроить его параметры, влияющие на производительность. В конечном счете пропускная способность логических соединений определяет, насколько быстро приложения обмениваются данными по сети. Такие протоколы прикладного уровня, как HTTP и FTP, передают протоколу TCP свои данные для тран­спортировки. Поэтому скоростные характеристики TCP оказывают непосредст­венное влияние на производительность приложений.

Кроме того, на уровень перегрузок, возникающих в сети, очень влияют пра­вила транспортного протокола для передачи и повторной передачи данных. Про­токол TCP активно используется и поддерживается большинством приложений, которые опираются на стек протоколов TCP/IP. Протокол TCP входит в состав транспортных протоколов, поддерживаемых операционной системой Microsoft Windows NT 5.0 (Windows 2000). На рис. 7.1 схематично показана сетевая мо­дель этой операционной системы и место протокола TCP в ней.

Поддержка TCP позволяет пользователям Microsoft Windows NT совместно работать через сеть с использованием всех доступных сервисов. В операцион­ной системе Microsoft Windows NT 5.0 поддержка TCP значительно расширена. Реализация стека протоколов TCP/IP для операционных систем Microsoft Win­dows NT 4.0/5.0 пользуется параметрами, которые хранятся в системном реест­ре. Эти параметры можно корректировать вручную, но, вообще говоря, данные реализации протоколов являются самонастраивающимися.

Коротко рассмотрим основные расширения протокола TCP в операционной системе Microsoft Windows NT 5.0:

• Выборочное подтверждение (TCP Selective Acknowledgment, SACK — RFC 2018). Это расширение сравнительно недавно утвердил консорциум IETF. Оно позволяет подтверждать прием данных не в порядке их поступ­ления, как это было раньше, а выборочно. Этот подход имеет два главных преимущества. Во-первых, повышается эффективность повторных передач дейтаграмм протокола TCP благодаря сокращению времени повторной пе­редачи. Протокол TCP использует алгоритм повторной передачи, который учитывает, в каком порядке поступают подтверждения. Такой подход вполне приемлем, однако в этом случае на восстановление каждого по­терянного сегмента уходит примерно один цикл обращения. Механизм SACK позволяет осуществлять повторную передачу сразу нескольких по­терянных сегментов в одном цикле. Во-вторых, благодаря выборочным подтверждениям, протокол TCP, как показали проведенные исследования, точнее оценивает доступную ширину полосы пропускания в условиях не­скольких последовательных потерь пакетов и способен обойтись без вы­полнения алгоритма «Медленного старта»;

• Подтверждение с задержкой (Delayed Acknowledgments — RFC 1122). В соответствии с этим алгоритмом подтверждения высылаются, если не было выслано подтверждение на предыдущий принятый сегмент, или если после получения сегмента в течение 200 мс не поступил следую­щий;

• Механизмы масштабирования окон (TCP Receive Window Size Calcula­tion and Window Scaling — RFC 1323). Протокол не использует жестко заданный размер окна. Он может увеличивать его размер на величину мак­симального размера сегмента (Maximum Segment Size, MSS), величина ко­торого определяется при установлении соединения. Размер окна приема по умолчанию равен 8 Кбайт. Этот размер выставляется в настройках ре­естра для протокола TCP, а именно, в параметре TcpWindowSize. Макси­мальный размер окна — 64 Кбайт. Для сетей Ethernet размер окна обычно равен 8760 байт для версии Microsoft Windows NT 4.0 и 17 520 байт (16 Кбайт, размещенные в двенадцати сегментах по 1460 байт) для версии Microsoft Windows NT 5.0;

• Временные штампы (TCP Timestamps - RFC 1323);

• Обнаружение PMTU (PMTU (Path Maximum Transmission Unit) Disco­very — RFC 1191). Обычно величина MSS равна величине MTU за вы­четом 40 байт на заголовки IP и TCP. Сегмент в распределенную сеть отправляется с запретом фрагментации. На отдельных участках сети может быть принят другой MTU. Маршрутизатор, который настроен на этот размер, отсылает сообщение протокола ICMP о недоступности пунк­та назначения с указанием действующего размера MTU. На основании этого сообщения отправитель изменит значение MTU так, чтобы сегменты смогли достичь получателя. Максимальный размер MTU составляет 68 байт. Предусмотрена возможность работы с маршрутизаторами, кото­рые не совместимы с алгоритмом определения MTU. Для работы с ними в реестре предусмотрены два параметра. PMTU можно определить и вруч­ную — командой ping с ключом запрета фрагментации;

• Обнаружение неработающего шлюза — маршрутизатора по умолча­нию — (Dead Gateway Detection). Метод описан в документе RFC 816. Проводятся необходимые действия для поиска работающего маршрутизаторатора взамен отключенного с соответствующей корректировкой таблицы маршрутизации;

• Политика повторной передачи (TCP Retransmission Behavior). Число попыток повторной передачи определяется параметром реестра ТсрМах-DataRetransmission. По умолчанию этот параметр равен 5. Добавление единицы к этому параметру удваивает значение таймера повторной пере­дачи, которое в начальный период работы соединения равно 3 с;

• Алгоритмы медленного старта и предотвращения перегрузки (Slow Start Algorithm and Congestion Avoidance — RFC 1122);

• Предотвращение синдрома «глупого» окна (Silly Window Syndrome, SWS — RFC 1122). Получатель всегда старается увеличить окно приема, если имеет свободное буферное пространство. Отправитель также старает­ся увеличить окно передачи при малейшей возможности. В такой ситуа­ции говорить о стабильном потоке сегментов не приходится. Для того чтобы уберечь отправителя и получателя от соблазна «втиснуть в канал лишний сегмент», используется алгоритм предотвращения SWS. Большой объем данных не отправляется до тех пор, пока получатель не объявит размер окна, достаточный для посылки полного сегмента. Кроме того, может производиться настройка, не позволяющая увеличивать окно при­ема меньше, чем на сегмент;

• Алгоритм Nagle (Nagle Algorithm, RFC 896). Алгоритм предназначен для уменьшения количества небольших сегментов в сети. Предпочтение при передаче отдается полноразмерным сегментам.

В данном разделе подробно рассматриваются лишь некоторые из этих расши­рений. Для того чтобы понять основные механизмы работы всех существующих расширений, остановимся на базовых принципах протокола. За подробностями заинтересованный читатель может обратиться к документам RFC, приведенным в табл. 7.1. Следует отметить, что глубокое понимание существующих механиз­мов протокола TCP и того, как они влияют на производительность сети, необ­ходимо для разработки, внедрения, эксплуатации или сопровождения сетей. Это обусловлено тем, что TCP лежит в основе всех современных сетевых операци­онных систем — и в первую очередь, Windows NT. Так, если внедряется крупная, распределенная сеть на базе этой операционной системы, то проектировщику стоит обратить самое пристальное внимание на планирование загрузки сетевых каналов.

Таблица 7.1. Стандарты RFC, поддерживаемые операционной системой

Microsoft Windows NT 5.0

Документ RFC	Название
768	User Datagram Protocol (UDP)
783	Trivial File Transfer Protocol (TFTP)
791	Internet Protocol (IP)
792	Internet Control Message Protocol (ICMP)
793	Transmission Control Protocol (TCP)
816	Fault Isolation and Recovery
826	Address Resolution Protocol (ARP)
854	Telnet Protocol (TELNET)
862	Echo Protocol (ECHO)
863	Discard Protocol (DISCARD)
864	Character Generator Protocol (CHARGEN)
865	Quote of the Day Protocol (QUOTE)
867	Daytime Protocol (DAYTIME)
894	IP over Ethernet
919,922	IP Broadcast Datagrams (broadcasting with subnets)
950	Internet Standard Subnetting Procedure
959	File Transfer Protocol (FTP)
1001,1002	NetBIOS Service Protocols
1009	Requirements for Internet Gateways
1034,1035	Domain Name System (DNS)
1042	IP over Token Ring
1055	Transmission of IP over Serial Lines (IP-SLIP)
1112	Internet Group Management Protocol (IGMP)
1122,1123	Host Requirements (communications and applications)
1134	Point-to-Point Protocol (PPP)
1144	Compressing TCP/IP Headers for Low-Speed Serial Links
1157	Simple Network Management Protocol (SNMP)
1179	Line Printer Daemon Protocol
1188	IP over FDDI
1191	Path MTU Discovery
1201	IP over ARCNET
1231	IEEE 802.5 Token Ring MIB (MIB-II)
1256	ICMP Router Discovery Messages
1323	TCP Extensions for High Performance
1332	PPP Internet Protocol Control Protocol (IPCP)
1334	PPP Authentication Protocols
1518	An Architecture for IP Address Allocation with CIDR
1519		Classless Inter-Domain Routing (CIDR): An Address Assignmentand Aggregation Strategy
1533		DHCP Options and BOOTP Vendor Extensions
1534		Interoperation Between DHCP and BOOTP
1541		Dynamic Host Configuration Protocol (DHCP)
1542		Clarifications and Extensions for the Bootstrap Protocol
1547		Requirements for Point-to-Point Protocol (PPP)
1548		Point-to-Point Protocol (PPP) .
1549		PPP in High-level Data Link Control (HDLC) Framing
1552		PPP Internetwork Packet Exchange Control Protocol (IPXCP)
1825		Security Architecture for the Internet Protocol
1826		IP Authentication Header (AH)
1827		IP Encapsulating Security Payload (ESP)
1828		IP Authentication using Keyed MD5
1829		ESP DES-CBC Transform
1851		The ESP Triple DES-CBC Transform
1852		IP Authentication using Keyed SHA
2014		HMAC: Keyed Hashing for Message Authentication
2085		HMAC-MD5 IP Authentication with Replay Prevention
2136		Dynamic Updates in the Domain Name System (DNS UPDATE)
2205		Resource Reservation Protocol (RSVP) — Version 1 Functional Specification
2236		Internet Group Management Protocol, Version 2