ЛЕКЦИИ / Лекции1

ВОПРОС 34 ПРОТОКОЛ TCP: СОЕДИНЕНИЕ С2 продолжаем рассматривать протокол TCP которые находятся на транспортном уровне модели взаимодействия открытых систем. и в отличии от другого протокола транспортного уровня UDP, TCP обеспечивают гарантию доставки и гарантию сохранения порядка следования сообщений которые передаются по сети. для того чтобы обеспечить такие гарантии нельзя просто взять и начать передавать данные как это делается в UDP. в TCP перед отправкой данных необходимо установить соединение, а после того как все данные будут переданы соединение требуется разорвать. С3 рассмотрим как устанавливается соединение. отправитель посылает запрос на установку соединения - сообщение SYN от слова синхронизация. также в сегмент включается порядковый номер передаваемого байта. С4 получатель в ответ также передают сообщения SYN, куда включает подтверждение получения предыдущего сообщения ACK и порядковый номер байта который он ожидает - 7538. потому что на предыдущем этапе был получен байт с номером 7537. также отправитель включает в сегмент номер байта в потоке байт 36829. номера байт в первом сообщении и не могут быть всегда нулевыми. они выбираются по достаточно сложным алгоритмам, но для простоты можно представлять себе что эти номера выбираются случайным образом. С5 на третьем этапе пересылаются подтверждение получения предыдущего запроса на установку соединения ACK, номер следующего ожидаемого байта 36830, а также номер байта в сообщении 7538. после этого соединение считается установленным, и можно передавать данные. С6 рассмотрим как происходит разрыв соединения в TCP. соединение TCP дуплексное. это означает что после установки соединения передавать данные можно в две стороны. С7 есть две схемы разрыва соединения. возможен одновременный разрыв соединения. в этом случае обе стороны разрывают соединение в одно и то же время. либо односторонние. в этом случае одна сторона говорит о том что данные для передачи у нее закончились, но другая сторона может передавать данные еще достаточно долго. протокола TCP предусматривает два варианта разрыва соединения - корректное, с помощью одностороннего закрытия соединения и сообщения FIN. и разрыв из-за критической ситуации с помощью сообщения RST. С8 сначала рассмотрим как выполняется корректный разрыв соединения. сторона, которая хочет разорвать соединение, пересылают другой стороне сообщений FIN, С9 и в ответ получает сообщение ACK. однако соединение разорвано только с одной стороны. данные в правую сторону передавать нельзя, но в в левую сторону передавать можно. С10 когда правая сторона решила что данные для передачи у нее закончились - она также передает сообщение FIN, С11 в ответ получает сообщение ACK. подтверждение на этом этапе - соединение закрыто полностью в обе стороны. С12 для разрыва соединения в критической ситуации из-за ошибок в приложении или с оборудованием используется одно сообщение RST. в этом случае соединение закрывается в обе стороны, хотя сообщение RST предназначено для использования в критических ситуациях, некоторые протоколы используют его для быстрого закрытия соединения. С13 и так прежде чем передавать данные в TCP необходимо сначала установить соединение, а после завершения передачи соединение необходимо разорвать. для установки соединения в TCP используется схема трехкратного рукопожатия. сначала передается сообщение SYN, потом SYN+ACK, и на третьем шаге ACK. для разрыва соединения возможных две схемы. - корректное закрытие соединения требует отправки обеими сторонами сообщения FIN и получении подтверждения. разрыв соединения в критической ситуации может быть выполнен быстро отправкой одного сообщения RST. таким образом накладные расходы в TCP, особенно при передаче небольшого объема данных, значительно выше чем в UDP, но соединение и отправка подтверждений позволяют TCP обеспечивать гарантию доставки, и гарантию сохранения порядка следования сообщений. ¶

ВОПРОС 35 ПРОТОКОЛ TCP: ФОРМАТ ЗАГОЛОВКА С2 мы уже достаточно подробно рассмотрели логику работы TCP. теперь можем перейти к рассмотрению формата заголовка. TCP это самый сложный протокол который мы будем рассматривать в рамках курса. на слайде он представлен. - больше всего полей. назначение большинства полей вам уже должно быть понятную из предыдущих лекций. первые два поля - порт отправителя и порт получателя. порты - это адреса на транспортном уровне. они позволяют определить какому приложению предназначен сегмент. следующее поле - порядковый номер. С3 мы помним что TCP получает от вышестоящего уровня поток байт, который делится на отдельные части, называемые сегменты. TCP нумирует байты в потоке. и в поле порядковый номер содержится первый номер байта в сегменте. например байт 1000, байт 2460, или 3920. С4 если мы используем сеть ethernet, то размер сегмента как правило составляют 1460 байт, чтобы с заголовком TCP/IP можно было поместиться в кадр ethernet размером 1500 байт. следующее поле - номер подтверждения. подтверждение используется для обеспечения гарантии доставки сообщений. С5 отправитель передает сегмент с указанием номера последовательности первый байт 1000, последний байт 2459. получатель отправляет сегмент с подтверждением в котором он говорит какие данные получены. поле - номер подтверждения - используются для задания так называемого кумулятивного подтверждения, которое говорит о том, что полученны все предыдущие байты. особенности TCP в том, что в поле номер подтверждения указываются не номер последнего байта, который получен - в примере 2459, а номер следующего ожидаемого байта 2460. С6 затем идет поле длина заголовка - как и в случае с IP заголовок TCP состоит из двух частей. обязательной и необязательной. длина обязательной части заголовка 20 байт. длина необязательный может быть разной, в том числе и нулевой, поэтому мы должны знать общую длину заголовка TCP. затем идут три зарезервированных бита, которые сейчас не используется, и 9 полей флагов. флаги SN, CRW, ECE используется для управления перегрузкой. их назначение мы рассмотрим в отдельной лекции посвященной этой теме. флаг URG указывает на то что в сегменте содержатся срочные данные, которые необходимо быстро передать приложению. этот флаг используется совместно с полем "указатель на срочные данные" которые собственно содержат адрес этих данных. сейчас этот флаг и поле "указатель на срочные данные" не используются. Флаг ACK используются если в поле номер подтверждения записаны осмысленные данные, то есть для подтверждения принятой ранее информации. флаг Push указывает что полученные данные необходимо полностью сразу передать в приложение без промежуточной записей в буфер. также как и флаг URG этот флаг сейчас не используются. флаги RST и флаги FIN используется для разрыва соединения. а флаг SIN - синхронизация используются для установки соединения. следующее поле - "размер окна" - в этом поле получатель указывает сколько данных он может принять. поле используется для управления потоком. более подробно мы рассмотрим его в отдельной лекции. затем идет контрольная сумма, которая используется для проверки правильности доставки данных. если контрольная сумма расчитанная получателем не совпадают с контрольной суммой в заголовке TCP, то этот сегмент отбрасывается. поле "указатель на срочные данные" которые мы рассмотрели завершают обязательную часть заголовка TCP. С7 затем идет не обязательная часть заголовка, которая в TCP называются параметры. в отличие от IP, где опции используются редко, параметры в TCP используется часто. рассмотрим некоторые примеры параметров. параметры MSS - максимальный размер сегмента, говорит о том сегмент какого размера может принять получатель, если используется ethernet, то максимальный размер сегмента 1460 байт. максимальный размер сегмента задается отправителем и получателем при установке соединения. другой важный параметр - это масштаб окна. поле размер окна в заголовке TCP позволяет указать максимальный размер доступный для получения байт- 65535. но это маленький объем для современных высокоскоростных и территориально протяженных каналов. если использовать размер окна такого размера, то скорость передачи данных будет низкая. параметр "масштаб окна" позволяют увеличить размер окна до 1 гигабайта. другой полезный параметр - это выборочное подтверждение, которое мы уже рассматривали ранее. позволяет получить подтверждение диапазонов принятых байт, а не всех данных до определенного байта. выборочное подтверждение полезно, если потерян всего лишь один сегмент или небольшая порция в большом потоке данных. для диагностических целей можно использовать параметр "метки времени". после заголовка TCP, обязательных и необязательных полей, идут данные. данные в TCP также необязательны. вполне допускаются сегменты без данных. такие сегменты используются например при установке соединия. ¶

ВОПРОС 36 ПРОТОКОЛ TCP: УПРАВЛЕНИЕ ПОТОКОМ

С2 в TCP для повышения скорости работы в быстрых сетях используется скользящее окно. при этом отправитель передает все небольшое количество сегментов не дожидаясь подтверждения. эти сегменты хорошо занимают пропускную способность широкого канала. С3 но что произойдет если получает данные не высокопроизводительный сервер, а маленький телефон, смартфон, планшет или какое-то другое медленное устройство? в этом случае получатель примет несколько сегментов, а остальные будет вынужден отбросить. задача предотвращения отправки быстрым отправителем слишком большого количества сегментов, которые не могут быть получены медленным получателем - так называемого "затопления", в TCP называется - управление потоком. С4 может быть и другая причина "затопления", связанная с тем что на транспортном уровне мы работаем с приложениями. в отличие от сетевого и канального уровня, где коммутаторы или маршрутизаторы должны обрабатывать данные сразу же, как только они пришли, и делать это максимально быстро приложение не обязано читать данные сети как только они появились. приложение может быть занято какими-то другими важными делами, оно может читать данные сети по расписанию - например раз в минуту или раз в пять минут, или для этого могут быть какие-то другие причины. данные которые приходят из сети записываются в некоторый промежуточный буфер, откуда их со временем должно прочитать приложение. но что произойдет если приложения эти данные не читают? С5 в примере в буфер почти полностью занят, есть место всего лишь для двух сегментов, а отправитель передал в сети гораздо больше сегментов чем может поместиться в буфер. в результате два сегмента будут приняты, а остальные отброшены. нам нужен механизм, который позволяет получателю сказать сколько же данных он может принять, для того чтобы отправитель не передавал слишком много данных. С6 для этой цели используются поле размер окна в заголовке TCP. в этом поле отправитель указывают сколько байт данных он может принять. С7 рассмотрим как используются это поле на практике. предположим что размер буфера у получателя равен восьми сегментам. отправить их передает один сегмент, он записывается в буфер, получатель передает подтверждение получения этого сегмента. в подтверждении, кроме номера следующего ожидаемого байта, указывается также размер окна - 10220, что соответствует 7и сегментам. мы используем сеть ethernet в который размер кадра 1500 байт, если вычтем заголовок TCP - 20 байт и IP 20 байт, то размер данных сегмента получится 1460 байт. С8 затем отправитель передает сразу четыре сегмента. они записываются в буфер. получатель отправляет подтверждение, где указывает новый размер окна, который равен всего трем сегментам. предположим что приложение занято какими-то делами, и ничего из буфера не читает. отправитель передает три сегмента, они записываются в буфер, и в буфере место заканчивается. С9 получатель, передавая подтверждение, указывает, что размер окна равен нулю. этим он говорит отправителю чтобы тот остановился и пока ничего не передавал. С10 отправитель делает паузу и ждет следующего сообщения. С11 приложение прочитало часть данных из буфера. освободилось место для двух сегментов. получатель заново отправляет подтверждение последнего принятого байта и указывает новый размер окна равный двум сегментам. С12 отправитель передает эти два сегмента, которые снова записываются в буфер. С13 отправитель, если ждет слишком долго, может передать так называемый сегмент Zero Window Probe - просьба подтвердить что размер окна все еще равен нулю. он передается для того чтобы убедиться что получатель остается на связи и не произошло каких-то ошибок - например сегмент с новым размерам окна мог потеряться по сети, приложение могло прочитать данные, но по каким-то причинам транспортная подсистема это еще не обнаружила, либо у получателя произошла какая-то критическая ошибка и соединение уже разорванно. в ответ на сегмент Zero Window Probe получатель может отправить сообщение что размер окна по-прежнему равен нулю, это значит отправитель должен ждать, либо новый размер окна - значит отправитель может передавать данные. С14 итак мы рассмотрели тему управления потоком в TCP. "затопление" может быть из за того что отправитель намного мощнее чем получатель. либо из-за того что приложение на стороне получателя читает данные из буфера значительно медленнее, чем они туда поступают. получатель говорит отправителю о том сколько данных он может принять, то есть сколько есть свободного места в буфере с помощью поля "размер окна" в заголовке TCP. ¶

ВОПРОС 37 ПРОТОКОЛ TCP: УПРАВЛЕНИЕ ПЕРЕГРУЗКОЙ С2 мы рассматривали управление потоком в TCP - этот способ предотвращения отправки в сеть слишком большого количества сегментов, которые не могут быть приняты получателем, у которого просто недостаточно и вместо в буфере. получатель, при отправке каждого подтверждения, указывает также в сегменте размер окна - количество байт которые он может принять, отправлять больше данных в сеть не имеет смысла. С3 но может быть и другая проблема - в буфере получателя может быть достаточно свободного места, С4 но сеть через которые передаются данные перегружена! одновременно большое количество компьютеров решили передавать данные. маршрутизаторы не способны передать такое большое количество пакетов и единицу времени, и они вынуждены их отбрасывать пакеты. в этом случае происходит так называемая перегрузка - отправители передают в сеть большое количество данных. однако большая часть из этих данных отбрасываются маршрутизаторами и не доходит до получателей. таким образом большая часть каналов сети занята, но полезные данные от отправителя до получателя почти не доходят. С5 первый раз такая ситуация произошла в интернет в 1986 году. она называлась коллапс перегрузки, хотя теоретически она была предсказана раньше. чтобы решить эту проблему стали учитывать загрузку сети при формировании размера окна. то есть определять количество сегментов которые можно отправить в сеть не дожидаясь получения подтверждения. если раньше до коллапса перегрузки такое количество сегментов всегда была одинаково - 8 штук, то после коллапса перегрузки решили что это количество нужно определять динамически в зависимости от того загружена сеть или нет. и для того чтобы определить количество сегментов которые можно отправить в сеть используются так называемое окно перегрузки. C6 таким образом в TCP у нас есть два типа окна - окно управления потоком, которое мы рассматривали в прошлом вопросе - размер этого окна задается получателем в зависимости от того сколько места в буфере, и передается отправителю в сегментах с подтверждением. окно перегрузки существует на стороне отправителя. его размер рассчитывается отправителем в зависимости от того какая нагрузка на сеть, а не от того сколько данных может принять приложение. приложение может быть готово принять много данных, но сеть загружена, в этом случае отправлять так много данных не имеет смысла. С7 оба типа окон - окно управления потоком и окно перегрузки используются для решения более общей задачи - управления скорости передачи данных в TCP. если размер скользящего окна будет слишком маленьким, то в сеть мы будем отправлять маленькое количество сегментов, сеть будет не загружена полностью, и скорость передачи будет маленькой - ниже чем возможно. с другой стороны если мы будем отправлять в сеть большое количество сегментов, то сеть может оказаться перегруженной, маршрутизаторы начнут отбрасывать наши сегменты, их нужно будет отправлять заново, и скорость передачи данных опять окажется низкой. таким образом нам нужно определить оптимальный размер окна, для того чтобы мы могли передавать данные по сети избегая загрузки, и приложение могло принять эти данные, и записать их в свой буфер. С8 в TCP для определения размера окна перегрузки используется метод аддитивного увеличения, мультипликативного уменьшения. суть метода заключается в том что при получении каждого подтверждения мы прибавляем к размеру окна некоторое значение - как правило это размер одного сегмента TCP, а если перегрузка произошла, то у мы умножаем размер окна на некоторое значение - как правило это 1/2. то есть в TCP при перегрузке размер окна уменьшается в два раза. С9 вот график работы метода аддитивного увеличения, мультипликативного уменьшения. мы начинаем передавать данные, поступают подтверждения, размер окна увеличивается. происходит аддитивное увеличение. затем в сети произошла перегрузка, размер окна уменьшается в два раза, произошло мультипликативное уменьшение. затем данные снова передаются, размер окна при получении каждого подтверждения увеличивается на один сегмент аддитивным увеличением. и так происходит пока не произойдет следующее перегрузка. таким образом размер окна у нас напоминают зубья пилы. С10 как отправитель не узнает о том что в сети произошла перегрузка? это достаточно сложная задача, потому что сеть может быть составной. и перегрузка может происходить не на том сегменте сети который подключен к отправителю, а на каком-то сегменте между отправителем и получателем которые находятся достаточно далеко от того и другого. чаще всего на практике в качестве сигнала о перегрузке используется потеря сегмента. считается что сейчас каналы связи уже хорошего качества, и если произошла потеря сегмента, то не из-за ошибки канала, а из-за того что сеть перегружена. поэтому нужно уменьшить размер окна для того чтобы избежать дальнейшей перегрузки. есть также и другие типы сигналов - этого задержка сегмента, и сигнал от маршрутизатора. Их рассмотрим в следующих вопросах. С11 метод аддитивного увеличения мультипликативного уменьшения хорошо работал на медленных каналах связи, которые были во времена создания сети интернет. но на современных быстрых и надежных каналах связи этот метод работает плохо. с помощью аддитивного увеличения размер окна перегрузкой увеличивается очень медленно. для того чтобы решить эту проблему был предложен другой метод управления размером окна так называемый медленный старт. при медленном старте размер окна увеличивается на каждое подтверждение ни на один сегмент, а на 2. благодаря этому происходит экспоненциальное увеличение размера окна. сначала мы отправляем один сегмент, получили подтверждение. отправляем 2 сегмента получили 2 подтверждения. на каждое подтверждение отправляем по два сегмента всего 4, потом 8, потом 16, и так далее. то есть несмотря на название медленный старт размер окна увеличивается гораздо быстрее, чем при аддитивном увеличение мультипликативным уменьшении. недостаток метода заключается в том, что если произошла потеря сегмента, то размер окна уменьшается до нуля. таким образом медленный старт быстро разгоняется, но также быстро тормозится. С12 в TCP используется комбинация медленного старта и аддитивного увеличения мультипликативного уменьшения. сначала используется медленный старт для того чтобы быстро заполнить доступную пропускную способность канала. после того как размер окна достиг определенного значения - так называемый порог медленного старта, происходит переход на аддитивное увеличение мультипликативное уменьшение. и дальше уже используется этот метод. размер окна увеличивается медленно, но если пришел сигнал о перегрузке, размер окна уменьшается в два раза, а не снижается до нуля. порог медленного старта определяется следующим образом - сначала запускается медленный старт и работает до того пока не поступит сигнал о перегрузке. после этого размер окна при котором пришел сигнала перегрузки делится в два раза, и это значение выбираются для порога медленно старта. таким образом формируется достаточный запас размера окна для того чтобы не произошла перегрузка, который при аддитивном увеличении скорее всего не будет достигнут, если конечно загрузка сети останется на том же самом уровне. С13 итак мы рассмотрели управление перегрузкой в TCP. это предотвращение отправки в сеть слишком большого количества сегментов, которые приведут к перегрузке. для того чтобы справиться с этой проблемой используются окно перегрузки, которое определяет сколько сегментов можно отправить в сеть. если раньше размер окна перегрузки был фиксированным - 8 сегментов, то сейчас он определяется динамически, в зависимости от того насколько загружена сеть. В TCP для определения размера окна перегрузки используют комбинацию двух методов - аддитивное увеличение мультипликативное уменьшение и медленный старт. сначала работает медленный старт, затем происходит переход на адитивное увеличение мультипликативное уменьшение. основным сигналом о перегрузке является потеря сегментов в сети. но также существуют и другие сигналы - эта задержка сегментов и явный сигнал от маршрутизатора. ¶

ВОПРОС 38 ПРОТОКОЛ TCP: УПРАВЛЕНИЕ ПЕРЕГРУЗКОЙ ч.2 С2 продолжаем рассматривать управление перегрузкой в протоколе TCP. под перегрузкой в TCP понимается такое состояние сети при котором большое количество отправителей начинает передавать данные одновременно. маршрутизаторы не могут передать такое большое количество данных, и начинают отбрасывать пакеты. С3 как мы говорили - есть три вида сигналов по которым отправитель может узнать что в сети произошла перегрузка: это потеря сегмента задержка сегмента и явный сигнал от маршрутизатора. С4 до этого мы рассматривали только потерю сегмента. но если использовать потерю сегментов в качестве сигнала о перегрузке, то TCP фактически будет работать в режиме которые ведет к перегрузке. TCP постоянно увеличивает размер окна, пока перегрузка не произойдет. причем о перегрузке TCP узнает только после того как она произошла. поэтому предотвратить ее при такой схеме нельзя. другая проблема называется глобальной синхронизацией TCP, или TCP global synchronization. она заключается в том что когда на маршрутизаторе на котором произошла перегрузка заканчивается место в буфере, он отбрасывает сегменты всех отправителей. отправители обнаруживают потерю сегмента, понимают что произошла перегрузка, уменьшают размер окна. в TCPв отличие от ethernet или вай фай не выстроена схема рандомизирования задержки. поэтому все отправитель после уменьшения размера окна начинают передавать данные примерно в одно и то же время. в результате на маршрутизатор опять приходит большое количество пакетов, что в свою очередь ведет к перегрузке. для того чтобы решить эти проблемы используются другие сигналы перегрузке которые мы рассмотрим. С5 один из возможных вариантов - задержка сегмента. в этом случае измеряется так называемый round rtrip time - время движения сегмента от отправителя до получателя и обратно. отправитель передавая сегменты засекает round trip time, измеряет средние время, С6 и при существенном увеличении round trip time уменьшается размер окна перегрузки. С7 измерение времени задержки сегмента позволяет обнаружить перегрузку до того как она произошла. но задержка может быть вызвана не только перегрузкой, но и другими причинами. поэтому задержка сегмента не такой надежный сигнал как его потеря. другая проблема заключается в том, что когда мы используем такой сигнал о перегрузке на загруженных каналах связи, то это приводит к несправедливому распределению пропускной способности. наш компьютер начинают уменьшать размер окна перегрузки когда увеличивается время задержки сегмента. в то же время другие компьютеры, которые используют сигнал о перегрузке - потерю сегмента, продолжают увеличивать размер окна пока перегрузка не произойдет. решением является совместное использование двух сигналов - задержки и потери сегмента. такой подход используется например в протоколе Compound TCP реализованного компанией microsoft. С8 следующий вариант как отправитель может узнать о перегрузке - это явный сигнал от маршрутизатора. однако для этого маршрутизаторы должны поддерживать отправку сигналов. одним из возможных вариантов является технология Random Early Detection. при этом маршрутизатор с некоторой вероятностью начинает отбрасывать пакеты. еще до того как буфер полностью заполнен и началась перегрузка. в результате отправители узнают о возможной перегрузке и потери сегмента ещё до того как она произошла, и получают возможность заранее уменьшить окно перегрузки. но это не явный тип сигнала. технология Explicit Congestion Notification обеспечивает явную отправку сигнала от маршрутизатора к отправителю о том что в сети происходит перегрузка. C9 рассмотрим на схеме как она работает. отправитель передает сегмент в сеть который доходит до маршрутизатора. маршрутизатор находится в состоянии близком к перегрузке. буфер заполнен, но не полностью. для того чтобы предупредить отправителя о перегрузке в сети маршрутизатор устанавливать специальные флаги в заголовке IP, которые говорят о том что в сети произошла перегрузка. сегмент передается по сети дальше, и достигает получателя. C10 получатель в заголовке IP видит, что установлен флаг свидетельствующий о перегрузке. для того чтобы о перегрузке узнал не только получатель, но и отправитель - получатель устанавливает соответствующие флаги уже в заголовке TCP, когда передает подтверждение. C11 отправитель получает подтверждение доставки сообщения и в этом подтверждении он увидит что флаг сигнализирующий о перегрузке установлен. это будет сигналом о том что нужно уменьшить размер окна перегрузки. C12 рассмотрим какие поля в заголовке IP и TCP используется в технологии ECN - Explicit Congestion Notification. в заголовке IP используются два бита в поле тип сервиса. значение 00 говорит о том что перегрузки нет, а две единицы означают что перегрузка произошла. С13 в заголовке TCP для этих целей используются три флага. NS, CWR, ECE. C14 получатель который принял от маршрутизаторов заголовки IP сигнал о перегрузке используют флаг ECE (ECN-Echo) получатель устанавливает этот флаг в подтверждение получения сегмента, который он передает отправителю. отправитель в качестве подтверждения того что он получил сообщение о перегрузке, при передаче следующего сегмента устанавливает флаг CWR, который говорит о том что размер окна управление перегрузкой уменьшен. еще один флаг NS используется для защиты от случайного или злонамеренного изменения полей, который относится к технологии ECN (Explicit Congestion Notification). C15 итак мы закончили рассматривать управление перегрузкой в протоколе TCP. TCP использует три типа сигналов и перегрузке - это потеря сегментов, задержка сегментов, и явный сигнал от маршрутизатора. задержка сегментов позволяет быстрее узнать о перегрузке в сети, чем потеря сегментов, но надежность такого метода ниже, и он может привести к несправедливому распределению пропускной способности в загруженной сети. этот метод достаточно просто внедрить так как он требует изменений только на стороне отправителя сообщений. более совершенна технология использования явных сигналов от маршрутизатора. она позволяет быстро и надежно получить сигнал о том, что в сети произошла перегрузка. однако для этого необходимо взаимодействие сетевого и транспортного уровня, поэтому необходимо вносить изменения у отправителя, получателя, и во все промежуточные маршрутизаторы. ¶