Протокол 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:

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

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

q Механизмы масштабирования окон (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;

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

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

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

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

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

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

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

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

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

Microsoft Windows NT 5.0

Документ RFC	Название
	User Datagram Protocol (UDP)
	Trivial File Transfer Protocol (TFTP)
	Internet Protocol (IP)
	Internet Control Message Protocol (ICMP)
	Transmission Control Protocol (TCP)
	Fault Isolation and Recovery
	Address Resolution Protocol (ARP)
	Telnet Protocol (TELNET)
	Echo Protocol (ECHO)
	Discard Protocol (DISCARD)
	Character Generator Protocol (CHARGEN)
	Quote of the Day Protocol (QUOTE)
	Daytime Protocol (DAYTIME)
	IP over Ethernet
919,922	IP Broadcast Datagrams (broadcasting with subnets)
	Internet Standard Subnetting Procedure
	File Transfer Protocol (FTP)
1001,1002	NetBIOS Service Protocols
	Requirements for Internet Gateways
1034,1035	Domain Name System (DNS)
	IP over Token Ring
	Transmission of IP over Serial Lines (IP-SLIP)
	Internet Group Management Protocol (IGMP)
1122,1123	Host Requirements (communications and applications)
	Point-to-Point Protocol (PPP)
	Compressing TCP/IP Headers for Low-Speed Serial Links
	Simple Network Management Protocol (SNMP)
	Line Printer Daemon Protocol
	IP over FDDI
	Path MTU Discovery
	IP over ARCNET
	IEEE 802.5 Token Ring MIB (MIB-II)
	ICMP Router Discovery Messages
	TCP Extensions for High Performance
	PPP Internet Protocol Control Protocol (IPCP)
	PPP Authentication Protocols
	An Architecture for IP Address Allocation with CIDR
	Classless Inter-Domain Routing (CIDR): An Address Assignmentand Aggregation Strategy
	DHCP Options and BOOTP Vendor Extensions
	Interoperation Between DHCP and BOOTP
	Dynamic Host Configuration Protocol (DHCP)
	Clarifications and Extensions for the Bootstrap Protocol
	Requirements for Point-to-Point Protocol (PPP)
	Point-to-Point Protocol (PPP).
	PPP in High-level Data Link Control (HDLC) Framing
	PPP Internetwork Packet Exchange Control Protocol (IPXCP)
	Security Architecture for the Internet Protocol
	IP Authentication Header (AH)
	IP Encapsulating Security Payload (ESP)
	IP Authentication using Keyed MD5
	ESP DES-CBC Transform
	The ESP Triple DES-CBC Transform
	IP Authentication using Keyed SHA
	HMAC: Keyed Hashing for Message Authentication
	HMAC-MD5 IP Authentication with Replay Prevention
	Dynamic Updates in the Domain Name System (DNS UPDATE)
	Resource Reservation Protocol (RSVP) — Version 1 Functional Specification
	Internet Group Management Protocol, Version 2

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