ѕодпишитесь на наш Telegram-канал Ѕудьте в курсе последних новостей 👇 😉 ѕодписатьс€
ѕоддержим в трудное врем€ —пециальное предложение на техническую поддержку вашей »“ - инфраструктуры силами наших экспертов ѕодобрать тариф
ѕоставка оборудовани€ √аранти€ и помощь с настройкой. —кидка дл€ наших читателей по промокоду WIKIMERIONET  упить
»нтерфейс статистики Merion Mertics показывает ключевые диаграммы и графики по звонкам, а также историю звонков в формате, который легко поймет менеджер ѕопробовать бесплатно
¬недрение
офисной телефонии
Ўаг на пути к созданию доступных унифицированных коммуникаций в вашей компании ¬недрить
»нтеграци€ с CRM ѕомогаем навести пор€док с данными
и хранить их в единой экосистеме
ѕодключить
»“ Ѕезопасность ”мна€ информационна€ безопасность дл€ вашего бизнеса «аказать

TCP: ѕротокол управлени€ передачей

ѕроблемы и решени€ компьютерных сетей - „асть 12

ћерион Ќетворкс

12 минут чтени€

ќсновна€ цель TCP состоит в том, чтобы обеспечить транспортировать данные поверх IP.  ак протокол более высокого уровн€, он полагаетс€ на возможности адресации и мультиплексировани€ IPv6 дл€ передачи информации на правильный хост назначени€. ѕо этой причине TCP не требует схемы адресации.


”правление потоком

TCP использует метод скольз€щего окна дл€ управлени€ потоком информации по каждому соединению между двум€ хостами. –исунок 1 демонстрирует это. Ќа рисунке 1 предположим, что начальный размер окна установлен равным 20. «атем последовательность событий:

  • ¬ момент времени t1 отправитель передает 10 пакетов или октетов данных (в случае TCP это 10 октетов данных).
  • ¬ момент времени t2 получатель подтверждает эти 10 октетов, и дл€ окна установлено значение 30. Ёто означает, что отправителю теперь разрешено отправл€ть еще до 30 октетов данных перед ожиданием следующего подтверждени€; другими словами, отправитель может отправить до 40 октетов, прежде чем он должен будет дождатьс€ подтверждени€ дл€ отправки дополнительных данных.
–ис. 1 —кольз€щее окно
  • ¬ момент времени t3 отправитель отправл€ет еще 5 октетов данных, номера 11Ц15.
  • ¬ момент времени t4 приемник подтверждает получение октетов через 15, и окно устанавливаетс€ на 40 октетов.
  • ¬ момент времени t5 отправитель отправл€ет около 20 октетов данных, пронумерованных 16Ц35.
  • ¬ момент времени t6 получатель подтверждает 35, и окно устанавливаетс€ на 50.

—ледует отметить несколько важных моментов, касающихс€ этой техники:

  •  огда получатель подтверждает получение определенного фрагмента данных, он не€вно также подтверждает получение всего, что было до этого фрагмента данных.
  • ≈сли приемник не отправл€ет подтверждениеЧк примеру , передатчик отправл€ет 16-35 в момент времени t5, а приемник не отправл€ет подтверждениеЧотправитель будет ждать некоторое врем€ и считать, что данные никогда не поступали, поэтому он будет повторно отправл€ть данные.
  • ≈сли получатель подтверждает некоторые данные, переданные отправителем, но не все, отправитель предполагает, что некоторые данные отсутствуют, и ретранслирует с точки, которую подтвердил получатель. Ќапример, если отправитель передал 16-35 в момент времени t6, а получатель подтвердил 30, отправитель должен повторно передать 30 и переслать.
  • ќкно устанавливаетс€ как дл€ отправител€, так и дл€ получател€

¬место использовани€ номеров октетов TCP присваивает каждой передаче пор€дковый номер; когда приемник подтверждает определенный пор€дковый номер, передатчик предполагает, что приемник фактически получил все октеты информации вплоть пор€дкового номера передачи. ƒл€ TCP, таким образом, пор€дковый номер действует как своего рода Устенографи€Ф дл€ набора октетов. –исунок 2 демонстрирует это.

Ќа рисунке 2:

  • ¬ момент времени t1 отправитель объедин€ет октеты 1Ц10 и передает их, помеча€ их как пор€дковый номер 1.
  • ¬ момент времени t2 получатель подтверждает пор€дковый номер 1, не€вно подтвержда€ получение октетов 1Ц10.
  • ¬ момент времени t3 отправитель св€зывает октеты 11Ц15 вместе и передает их, помеча€ их как пор€дковый номер 2.
  • ¬ момент времени t4 получатель подтверждает пор€дковый номер 2, не€вно подтвержда€ октеты, отправленные через 15.
–ис. 2 ”правление окнами с серийными номерами
  • ¬ момент времени t5 предположим, что 10 октетов помест€тс€ в один пакет; в этом случае отправитель отправит два пакета, один из которых содержит 16Ц25 с пор€дковым номером 3, а другой - октеты 26Ц35 с пор€дковым номером 4.
  • ¬ момент времени t6 приемник подтверждает пор€дковый номер 4, не€вно подтвержда€ все ранее переданные данные.

„то произойдет, если один пакет информации будет пропущен?

„то делать, если первый пакет из потока в 100 пакетов не получен? »спользу€ систему, описанную на рисунке 2, получатель просто не подтвердит этот первый пакет информации, вынужда€ отправител€ повторно передать данные через некоторое врем€. ќднако это неэффективно; каждый потер€нный пакет информации требует полной повторной отправки из этого пакета. –еализации TCP используют два разных способа, чтобы получатель мог запросить один пакет.

ѕервый способ - тройное признание. ≈сли получатель трижды подтверждает пакет, который предшествует последнему подтвержденному серийному номеру, отправитель предполагает, что получатель запрашивает повторную передачу пакета. “ри повторных подтверждени€ используютс€ дл€ предотвращени€ неправильной доставки пакетов или отброшенных пакетов, вызывающих ложный запрос на повторную передачу.

¬торой способ заключаетс€ в реализации выборочных подтверждений (SACK).15 SACK добавл€ет новое поле к подтверждению TCP, которое позвол€ет получателю подтвердить получение определенного набора серийных номеров, а не предполагать, что подтверждение одного серийного номера также подтверждает каждый более низкий серийный номер.


 ак долго передатчик ждет перед повторной передачи?

ѕервый способ, которым отправитель может обнаружить потер€нный пакет - это врем€ ожидани€ повторной передачи (RTO), которое рассчитываетс€ как функци€ времени приема-передачи (RTT или rtt). Rtt Ч это временной интервал между передачей пакета отправителем и получением подтверждени€ от получател€. RTT измер€ет задержку в сети от передатчика до приемника, врем€ обработки в приемнике и задержку в сети от приемника до передатчика. ќбратите внимание, что rtt может варьироватьс€ в зависимости от пути, по которому каждый пакет проходит через сеть, локальных условий в момент коммутации пакета и т. д.

RTO обычно рассчитываетс€ как средневзвешенное значение, при котором более старые временные интервалы оказывают меньшее вли€ние, чем более поздние измеренные значени€.

јльтернативным механизмом, используемым в большинстве реализаций TCP, €вл€етс€ быстра€ ретрансл€ци€. ѕри быстрой повторной передаче получатель добавл€ет единицу к ожидаемому пор€дковому номеру в любом подтверждении. Ќапример, если отправитель передает последовательность 10, получатель подтверждает последовательность 11, даже если он еще не получил последовательность 11. ¬ этом случае пор€дковый номер в подтверждении подтверждает получение данных и указывает, какой пор€дковый номер он ожидает от отправител€ дл€ передачи в следующий раз.

≈сли передатчик получает подтверждение с пор€дковым номером, который на единицу больше последнего подтвержденного пор€дкового номера три раза подр€д, он будет считать, что следующие пакеты были отброшены.

“аким образом, существует два типа потери пакетов в TCP, когда реализован быстрый запуск. ѕервый-это стандартный тайм-аут, который возникает, когда отправитель передает пакет и не получает подтверждени€ до истечени€ срока действи€ RTO. Ёто называетс€ отказом RTO. ¬торой называетс€ быстрым сбоем ретрансл€ции. Ёти два услови€ часто обрабатываютс€ по-разному.


 ак выбираетс€ размер окна?

ѕри выборе размера окна необходимо учитывать р€д различных факторов, но доминирующим фактором часто €вл€етс€ получение максимально возможной производительности при одновременном предотвращении перегрузки канала. ‘актически, контроль перегрузки TCP, веро€тно, €вл€етс€ основной формой контрол€ перегрузки, фактически примен€емой в глобальном »нтернете. „тобы пон€ть контроль перегрузки TCP, лучше всего начать с некоторых определений:

  • ќкно приема (RWND): объем данных, которые приемник готов прин€ть; это окно обычно устанавливаетс€ на основе размера буфера приемника или какого-либо другого ресурса, доступного в приемнике. Ёто размер окна, объ€вленный в заголовке TCP.
  • ќкно перегрузки (CWND): объем данных, которые передатчик готов отправить до получени€ подтверждени€. Ёто окно не объ€вл€етс€ в заголовке TCP; получатель не знает размер CWND.
  • ѕорог медленного запуска (SST): CWND, при котором отправитель считает соединение с максимальной скоростью передачи пакетов без возникновени€ перегрузки в сети. SST изначально устанавливаетс€ реализацией и измен€етс€ в случае потери пакета в зависимости от используемого механизма предотвращени€ перегрузки.

Ѕольшинство реализаций TCP начинают сеансы с алгоритма медленного старта. 16 Ќа этом этапе CWND начинаетс€ с 1, 2 или 10. ƒл€ каждого сегмента, дл€ которого получено подтверждение, размер CWND увеличиваетс€ на 1. ”читыва€, что такие подтверждени€ должны занимать ненамного больше времени, чем один rtt, медленный запуск должен привести к удвоению окна каждого rtt. ќкно будет продолжать увеличиватьс€ с этой скоростью до тех пор, пока либо пакет не будет потер€н (приемник не сможет подтвердить пакет), CWND не достигнет RWND, либо CWND не достигнет SST.  ак только любое из этих трех условий происходит, отправитель переходит в режим предотвращени€ перегрузки.

ѕримечание.  аким образом увеличение CWND на 1 дл€ каждого полученного ACL удваивает окно дл€ каждого rtt? »де€ состоит в следующем: когда размер окна равен 1, вы должны получать один сегмент на каждый RTT.  огда вы увеличиваете размер окна до 2, вы должны получать 2 сегмента в каждом rtt; на 4, вы должны получить 4 и т. д. ѕоскольку получатель подтверждает каждый сегмент отдельно и увеличивает окно на 1 каждый раз, когда он подтверждает сегмент, он должен подтвердить 1 сегмент в первом rtt и установить окно на 2; 2 сегмента во втором rtt, добавл€€ 2 к окну, чтобы установить окно на 4; 4 сегмента в третьем RTT, добавив 4 к окну, чтобы установить размер окна равным 8 и т. д.

¬ режиме предотвращени€ перегрузки CWND увеличиваетс€ один раз за каждый rtt, что означает, что размер окна перестает расти экспоненциально, а вместо этого увеличиваетс€ линейно. CWND будет продолжать расти либо до тех пор, пока получатель не подтвердит получение пакета (TCP предполагает, что это означает, что пакет был потер€н или отброшен), либо пока CWND не достигнет RWND. —уществует два широко распространенных способа, которыми реализаци€ TCP может реагировать на потерю пакета, называемых Tahoe и Reno.

ѕримечание. Ќа самом деле существует множество различных вариаций Tahoe и Reno; здесь рассматриваютс€ только самые базовые реализации. “акже существует множество различных методов реагировани€ на потерю пакета, когда соединение находитс€ в режиме предотвращени€ перегрузки.

≈сли реализаци€ использует Tahoe, и потер€ пакета обнаружена посредством быстрой повторной передачи, она установит SST на половину текущего CWND, установит CWND на исходное значение и снова начнет медленный запуск. Ёто означает, что отправитель снова будет передавать 1, 2 или 10 пор€дковых номеров, увеличива€ CWND дл€ каждого подтвержденного пор€дкового номера.  ак и в начале процесса медленного запуска, это приводит к удвоению CWND каждого rtt.  ак только CWND достигнет SST, TCP вернетс€ в режим предотвращени€ перегрузки.

≈сли реализаци€ использует Reno, и потер€ пакета обнаружена посредством быстрой повторной передачи, она установит SST и CWND на половину текущего CWND и продолжит работу в режиме предотвращени€ перегрузки.

¬ любой реализации, если обнаруживаетс€ потер€ пакета из-за того, что получатель не отправл€ет подтверждение в пределах RTO, CWND устанавливаетс€ на 1, и медленный запуск используетс€ дл€ увеличени€ скорости соединени€.


 онтроль ошибок

TCP предоставл€ет две формы обнаружени€ ошибок и управлени€ ими:

  • —ам протокол, нар€ду с механизмом управлени€ окнами, обеспечивает доставку данных в приложение по пор€дку и без какой-либо недостающей информации.
  •  онтрольна€ сумма дополнени€ единицы, включенна€ в заголовок TCP, считаетс€ более слабой, чем Cyclic Redundancy Check (CRC) и многие другие формы обнаружени€ ошибок. Ёта проверка ошибок служит дополнением, а не заменой, коррекции ошибок, обеспечиваемой протоколами ниже и выше в стеке.

≈сли получатель обнаруживает ошибку контрольной суммы, он может использовать любой из описанных здесь механизмов, чтобы запросить отправител€ повторно передать данныеЧпросто не подтвержда€ получение данных, запрашива€ повторную передачу через SACK, активно не подтвержда€ получение данных через быструю повторную передачу или отправл€€ тройное подтверждение дл€ конкретного сегмента, содержащего поврежденные данные.


Ќомера портов TCP

TCP не управл€ет каким-либо типом мультиплексировани€ напр€мую; однако он предоставл€ет номера портов, которые приложени€ и протоколы выше TCP в стеке протоколов могут использовать дл€ мультиплексировани€. ’от€ эти номера портов передаютс€ в TCP, они обычно непрозрачны дл€ TCP; TCP не придает никакого значени€ этим номерам портов, кроме использовани€ их дл€ отправки информации правильному приложению на принимающем узле.

Ќомера TCP-портов дел€тс€ на два широких класса: хорошо известные и эфемерные. ’орошо известные порты определ€ютс€ как часть спецификации протокола верхнего уровн€; эти порты €вл€ютс€ портами Ђпо умолчаниюї дл€ этих приложений. Ќапример, службу, поддерживающую Simple Mail Transfer Protocol (SMTP), обычно можно найти, подключившись к узлу с использованием TCP на порт номер 25. —лужбу, поддерживающую Hypertext Transport Protocol (HTTP), обычно можно найти, подключившись к узлу с использованием TCP на порт 80. Ёти службы не об€зательно должны использовать эти номера портов; большинство серверов можно настроить на использование какого-либо номера порта, отличного от указанного в спецификации протокола. Ќапример, веб-серверы, не предназначенные дл€ общего (или общедоступного) использовани€, могут использовать какой-либо другой TCP-порт, например 8080.

Ёфемерные порты значимы только дл€ локального хоста и обычно назначаютс€ из пула доступных номеров портов на локальном хосте. Ёфемерные порты чаще всего используютс€ в качестве исходных портов дл€ TCP-соединений; например, хост, подключающийс€ к службе через порт 80 на сервере, будет использовать эфемерный порт в качестве исходного TCP-порта. ƒо тех пор, пока любой конкретный хост использует данный эфемерный номер порта только один раз дл€ любого TCP-соединени€, каждый сеанс TCP в любой сети может быть однозначно идентифицирован через исходный адрес, исходный порт, адрес назначени€, порт назначени€ и номер протокола, работающего поверх TCP.


Ќастройка сеанса TCP

TCP использует трехстороннее рукопожатие дл€ установки сеанса:

  1.  лиент отправл€ет синхронизацию (SYN) на сервер. Ётот пакет €вл€етс€ обычным TCP-пакетом, но с битом SYN, установленным в заголовке TCP, и указывает, что отправитель запрашивает сеанс дл€ настройки с получателем. Ётот пакет обычно отправл€етс€ на хорошо известный номер порта или на какой-то заранее установленный номер порта, который, как известно клиенту, будет прослушиватьс€ сервером по определенному IP-адресу. Ётот пакет включает в себ€ начальный пор€дковый номер клиента.
  2. —ервер отправл€ет подтверждение дл€ SYN, SYN-ACK. Ётот пакет подтверждает пор€дковый номер, предоставленный клиентом, плюс один, и включает начальный пор€дковый номер сервера в качестве пор€дкового номера дл€ этого пакета.
  3.  лиент отправл€ет подтверждение (ACK), включающее начальный пор€дковый номер сервера плюс один.

Ётот процесс используетс€ дл€ обеспечени€ двусторонней св€зи между клиентом и сервером перед началом передачи данных. ѕервоначальный пор€дковый номер, выбранный отправителем и получателем, в большинстве реализаций рандомизирован, чтобы не дать стороннему злоумышленнику угадать, какой пор€дковый номер будет использоватьс€, и захватить сеанс TCP на начальных этапах его формировани€.