Птс оригинал и дубликат отличие: Как отличить дубликат ПТС от оригинала: как его проверить и распознать — dvd-auto.ru — Штатные головные устройства c GPS навигацией

Содержание

Как отличить оригинальный ПТС от дубликата?

29.08.2017 1848 Теги: #ПТС#оригинальныйптс

Оригинальные ПТС в России выдаются в двух местах – это таможня, если машина приехала к нам из другой страны, или завод-изготовитель, если машина собрана в России. А дубликатные (замененные) ПТС выдают в ГИБДД.
Как раз это и является основным фактором определения оригинальности или
неоригинальности ПТС.
Итак, оригинальный ПТС.
Первый вариант. Смотрим 23-й пункт – например, «Центральная акцизная
таможня». Это то место, где выдали этот документ.
Второй вариант. 23-й пункт, например, ООО «ПСМА-РУС». Это автомобиль,
собранный в России, соответственно, на заводе ему и выдали ПТС.
Таможня может быть необязательно центральной московской. Она может быть из другого города. Например, автомобили, которые приходят из Японии – праворульные – им ПТС выдают во Владивостоке, Находке либо каких-то других городах.

Птс оригинал и дубликат отличие: Как отличить дубликат ПТС от оригинала: как его проверить и распознать

Теперь рассмотрим неоригинальный ПТС. Смотрим тот же 23-й пункт в документе и видим, что ПТС выдан ГИБДД. Подразделения ГИБДД могут быть разные. Но, прочитав название организации, вы точно поймете, что ПТС неоригинальный. Также иногда ставят печать или просто пишут от руки «Дубликат». Но иногда и нет. Поэтому всегда смотрите 23-й пункт.
Причины, по которым ПТС меняется, могут быть разными. Например, машина собрана в России и в ПТС таких автомобилей сразу три места теряются.
Первое место – это сам производитель, потом у нас идет головной дилер, который машины распределяет по регионам, и всегда есть дилер, который машину эту продает.
Уже три места потеряно, а потом появляется владелец, который машину покупает. Иногда еще бывает, что региональный дилер перекидывает машину другому дилеру. Этот дилер тоже вписывается, то есть еще одно место теряется. Дальше человек, который машину эту купил, год-два- три поездил, решил машину сдать в трейд-ин. Дилер также вписывается в ПТС – и все, места нет.

Таким образом, в последнее время появляется очень много машин
с замененными ПТС.
Также ПТС может закончиться просто потому, что у машины было слишком много хозяев. Это самый простой вариант.
Еще один вариант. К примеру, у автомобиля может быть два владельца всего лишь, но ПТС тоже уже заменен. Это может произойти потому, что предыдущие владельцы меняли место жительства и госномера. Либо девушка замуж вышла. Меняет фамилию и в таком случае обязательно появляется новая запись в ПТС. Таким вот образом ПТС заполняется и его приходится менять.
Также ПТС, возможно, был украден либо утерян, либо случайно уничтожен. В таком случае владелец автомобиля идет в ГИБДД и получает новый паспорт для своего автомобиля.
Вообще, если вы собираетесь покупать машину, и у нее замененный ПТС, в этом нет ничего страшного. Просто надо проверять заранее, чтобы у машины не было десяти владельцев за короткий срок, не было юридических проблем. А если вы переживаете, что в будущем, когда вы будете машину продавать, ваш клиент будет отказываться от хорошего автомобиля из-за бумажки, то хочу вас обрадовать.

Умные люди смотрят в первую очередь на другие вещи, поэтому – не переживайте. Тем более, ездить на машине, а не на бумаге!
И еще такой момент. Ходят слухи, что в 2017 году ПТС отменят. Я думаю, что эти слухи образовались не на ровном месте – действительно так и будет, потому что во всем цивилизованном мире от них уже отказались, и вся информация теперь хранится в соответствующих базах в электронном виде.
Итог следующий: смотрим 23-й пункт на лицевой странице ПТС и определяем

оригинальность или неоригинальность документа.

что значит, стоит ли покупать машину с ним

Что вас больше всего тревожит при покупке подержанной машины с рук: техническое состояние, хорошая история или чистота документов? Сделать диагностику понравившегося б/у автомобиля сейчас несложно, историю можно проверить онлайн даже на сайте с объявлениями, а вот документы остаются популярным у мошенников способов обмануть потенциального покупателя.

И один из главных поводов насторожиться – это невинный на первый взгляд дубликат ПТC
Что такое ПТС, кто его выдает и зачем он нужен
Паспорт транспортного средства – это основной документ автомобиля (как, собственно, и у человека). Правда, он практически всегда спокойно лежит в дальнем ящике комода с документами. ПТС нужен по сути всего два раза в жизни автомобиля: когда вы приобретаете машину и когда продаете ее.
Но без него в этих ситуациях не обойтись.
ПТС содержит в себе всю ключевую информацию о машине, точнее почти всю. В эту бумагу вписаны марка и модель машины, дата ее изготовление, таможенные отметки, идентификационные номера, характеристики, а также собственники.
Если автомобиль был выпущен на иностранном заводе, а затем импортирован в Россию, то ПТС выдается таможенными органами

Если транспортное средство произвели в России, то первым будет указан отечественный завод-изготовитель

Следующим владельцем, скорее всего, станет представительство-импортер, либо автосалон, либо частник, который ввез машину из другого государства для собственных нужд. Все сделки, в результате которых автомобиль меняет собственника, прописываются в ПТС в специальных графах.
Также ПТС может содержат ограничения по таможенному оформлению.
Продавец подержанной машины может иметь на руках дубликат ПТС вместо оригинала. Почему?
Если ПТС — дубликат, что это значит?
Дубликат — это выданный заново документ. Законных и честных причин, по которым может появиться дубликат ПТС вместо оригинального документа, всего четыре:
Взамен испорченного (облили водой, порвали, дети разрисовали)

Взамен заполненного

Взамен потерянного

Взамен украденного

С испорченным документом все просто: собственник ТС или доверенное лицо обращаются в отделение ГИБДД, печально демонстрируют поврежденную бумагу и оформляют заявление с просьбой выдать новый ПТС, то есть его дубликат.
Аналогично приходится действовать с паспортом, в котором закончилось свободное место

. Обычно это происходит, когда у машины было много собственников или у ее хозяина менялись жизненные обстоятельства: смена фамилии, прописки, украденные или потерянные государственные регистрационные знаки и пр.
Негодный документ сдается в ГИБДД — утилизируется, на руки выдается дубликат
С потерянным паспортом процедура не отличается — за исключением того, что юристы рекомендуют сразу же сообщить в ГИБДД об утере и «аннулировании» документа. Это как с блокировкой потерянной банковской карты — с целью исключить возможные мошеннические манипуляции с пропавшим документом.
В случае с кражей (только одного ПТС или пакета документов, в котором был и ПТС) по букве закона надо сначала написать заявление в полицию, дождаться, пока сотрудники найдут (или, скорее всего, не найдут) преступников, а только затем получить дубликат документа.
Большинство автовладельцев предпочитают не ждать положенного месяца на прекращение уголовного дела и заявить о потере ПТС, чтобы быстро оформить дубликат.
Как понять, что вам предъявляют дубликат ПТС
Оригинал ПТС и его дубликат – в чем между ними разница? Чаще всего вычислить дубликат паспортного средства несложно – на нем ставят штамп «Дубликат».
Если этого по какой-то причине не сделали, то все равно догадаться нетрудно: органом, выдавшим ПТС, будет указано отделение ГИБДД. Как вы помните, в оригинале должны быть прописаны таможенные органы или завод-изготовитель. В ГИБДД же обращаются только для замены ПТС.
Наконец, самое очевидное свидетельство дубликата ПТС – это дата его выдачи. Если она намного более свежая, чем дата выпуска автомобиля, то перед вами дубликат паспорта.

Если ПТС — дубликат, стоит ли покупать машину?
Чего бояться при покупке с дубликатом ПТС? Конечно, нет ничего страшного, если нерадивому автовладельцу пришлось заменить главный документ машины из-за утери или порчи. Все выглядит чисто, вот и штамп из ГИБДД на бумаге…

Но если есть возможность, лучше поискать другую машину!

И вот почему. Вы никак не сможете проверить, почему человек в действительности предлагает вам машину с дубликатом ПТС. А мошеннических или просто невыгодных для покупателя подержанного автомобиля схем с неоригинальными документами может быть немало:
машина часто меняла владельцев

автомобиль куплен в кредит, который еще не погасили

машина находится в залоге в ломбарде

оригинал документа был украден, его успели применить в незаконных сделках

Вот чем опасен дубликат ПТС при покупке автомобиля на вторичном рынке.
Множество владельцев
Это самая невинная причина, по которой могут выдать новый ПТС. И машину это, как вы понимаете, не красит. Во-первых, это означает, что автомобиль эксплуатировало множество разных людей. Во-вторых, что машину по каким-то причинам часто перепродавали. В-третьих, в паспорте, выданном взамен переполненного, не будут указаны все эти владельцы, и вы не узнаете, кем они были – возможно, в оригинальном ПТС были перечислены таксопарки и логистические компании. Скорее всего, именно это хотел скрыть продавец, спешно получивший дубликат перед продажей машины.
Кредитный автомобиль
При приобретении машины в кредит банк, выдающий часть суммы на его покупку, берет в залог основной документ машины – паспорт транспортного средства. Он хранится там до полной выплаты кредита, что не позволяет собственнику продать машину. Человек, который решил прекратить выплачивать кредит (или планировал нечестную сделку изначально), заявляет в ГИБДД об утере – и получает дубликат! Инспекторы до сих пор не имеют полноценного доступа к базам банка и зачастую не могут проверить, не находится ли машина в залоге.
Что будет дальше, предположить несложно. Продавец исчезает вместе с деньгами, а покупатель остается один на один с банком, который имеет полное право конфисковать кредитомобиль.
Оригинал ПТС находится в ломбарде
Но «пробить» машину на предмет залога в банке еще можно через нотариальные конторы или некоторые базы данных. А вот если автомобиль заложен в ломбард, то проверить это практически невозможно, и дубликат ПТС продавец может предлагать как раз потому, что сам документ находится в ломбарде.
Стоит ли брать машину с дубликатом ПТС
Если это не «та самая машина всей моей мечты», то проще отказаться от покупки и поискать на вторичке другой вариант. Не забывайте, что даже при условии полной чистоты машины вам в дальнейшем придется иметь дело именно с дубликатом ПТС, в частности — продавать машину со сложностями и возможным демпингом.
риски, что значит, стоит ли покупать
Любая вещь может потеряться, если ее обладатель невнимателен. Особенно обидно, когда утрачены документы на автомобиль – паспорт транспортного средства, СТС и другие. Ездить на машине без них нельзя, поэтому придется получать дубликаты. Кроме затрат времени и денег, это сулит и сложности при продаже авто на вторичном рынке. Увидев неоригинальные документы, покупатель может заподозрить мошенничество. Разберемся, что делать, если ПТС понравившегося автомобиля — дубликат.

Почему дубликат
Ответ на вопрос, что такое дубликат ПТС при покупке автомобиля, содержится в приказе № 496/134/192 от 23 июня 2005 года, изданном МВД, Минэкономразвития и Министерством промышленности (с 1 ноября 2020 года заменяется на аналогичный приказ № 135/857/409 от 18 марта 2019 года).
Законные причины для замены ПТС:
потеря оригинального паспорта;
неоднократная смена владельцев, отчего в документе закончилось место.
Если старый ПТС использовать нельзя, владелец машины должен оформить его дубликат. О том, как правильно это сделать, читайте здесь.
Но кроме официальных причин, замена ПТС на дубликат может быть сделана в целях обмана покупателя (подробнее об этом ниже).
Как понять
Узнать дубликат ПТС можно по его внешнему виду. И дубликат, и оригинал выпускаются на бланках строгой отчетности Гознака, имеющих ряд защитных элементов. В документе указываются данные о транспортном средстве, его технических характеристиках, владельцах и ряд других.
Основное отличие дубликата паспорта транспортного средства от оригинала – соответствующая надпись на бланке документа. В приложении 1 к упомянутому выше приказу №с496/134/192 установлено, что дубликат ПТС совпадает с обычной формой ПТС и отличается только надписью: «Дубликат. Выдан взамен ПТС (ПШТС)», с указанием реквизитов первоначального документа и причины выдачи дубликата (например «выдан взамен утраченного»). Надпись «Дубликат» ставится также на титульном листе в верхнем углу документа.
Другое отличие между оригинальным ПТС и его дубликатом – орган, выдавший документ. ПТС выдается впервые либо при ввозе, либо при изготовлении автомобиля на заводе в России. Поэтому на оригинальных экземплярах ПТС ставится печать таможенных органов (если машина ввезена в Россию), либо штамп завода-изготовителя. Если же в нижней части первого листа ПТС стоит печать органа ГИБДД – это дубликат (их выдают именно органы ГИБДД).
Мнение эксперта
Евгений Иванов, юрист
Из этого правила есть исключения – если ПТС был утерян до первой регистрации в ГИБДД, его дубликат выдают либо таможенный орган, либо завод-изготовитель, и тогда печать одного из них появится на дубликате. Но такие случаи редки, и, как правило, не связаны с мошенничеством или желанием владельца автомобиля скрыть полученный автокредит.
Подробнее о том, как выглядит дубликат ПТС и при каких условиях он выдается, вы можете прочитать здесь.
Если дубликат выдан органом ГИБДД в законном порядке, он является законным документом.   Реже встречаются случаи предъявления поддельных паспортов ТС. Неподготовленный человек сможет отличить фальшивку только в том случае, если она неаккуратно оформлена.
Чем плох
Считается, что покупка машины по дубликату ПТС может повлечь некоторые риски. Разберемся подробнее, чем опасен или плох дубликат ПТС для нового собственника машины.
Считается, что в дубликате могут отсутствовать важные сведения, которые были включены в оригинальный ПТС.
Основные риски при покупке авто с дубликатом ПТС состоят в том, что машина может находиться в залоге. Это происходит, если:
продавец взял на ее покупку автокредит, или
предоставил ее в залог в обеспечение какого-либо другого кредита, взятого в банке или займа, полученного от гражданина или организации.
В таких случаях заключается договор залога и банк или другой залогодержатель временно забирает ПТС. Продавать кредитную машину без согласия банка нельзя. Но, если кредит нечем оплачивать, такая мысль может возникнуть у владельца авто. Такая продажа будет незаконна. Помимо того, что продавец нарушит свой договор залога с банком, его действия по отношению к будущему покупателю можно квалифицировать, как мошенничество.
Обычно продажа по дубликату паспорта транспортного средства проводится по низкой цене. Но желание сэкономить на покупке автомобиля с пробегом зачастую приводит к серьезным проблемам.   Недобросовестный продавец может получить дубликат и выставить автомобиль на продажу. Это опасно тем, что залог с автомобиля не снимается после смены владельца. Если продавец не выплатит свой долг банку, автомобиль могут изъять в счет погашения долга.
Помимо кредита, дубликат ПТС может скрывать за собой спор о наследстве. Если оригинал ПТС находится у одного из наследников, второй может попытаться оформить на себя документы, получить дубликат и продать машину по нему. Аналогичная ситуация может возникнуть в бракоразводном процессе и в других случаях раздела имущества.
Дубликат ПТС может быть оформлен на угнанную или полностью восстановленную после ДТП машину. Последнее возможно, если сохранился VIN – под него восстанавливается автомобиль, который по сути представляет собой конструктор из запчастей кустарной сборки. Помимо проблем с документами, у такой машины может вскрыться множество технических недостатков, сводящих ее ценность к нулю.   Но эти случаи сложно выявить без проверки экспертом не только документов, но и технического состояния автомобиля.
Чтобы не остаться без денег и без машины, покупатель должен тщательно проверить все документы перед покупкой. Если ПТС – дубликат, необходимо дополнительно обезопасить себя.
Стоит ли покупать
В целом оригинал ПТС безопаснее для сделки купли-продажи. Но и если ПТС у машины – дубликат, это не повод сразу отказываться от покупки.
Основной метод проверки машины на залог – запрос через единый реестр уведомлений о залогах движимого имущества, который ведет Федеральная нотариальная палата РФ. Он доступен в электронном виде на сайте:
https://www.reestr-zalogov. ru/
Мнение эксперта
Евгений Иванов, юрист
Информацию в этот реестр вносят на добровольных началах. Банки, как правило, не пренебрегают этой возможностью обеспечить сохранность заложенного автомобиля. А вот частное лицо или организация, давшие в долг под залог автомобиля, могут и не подать уведомление.
Поэтому отсутствие в реестре сведений о залоге конкретной машины не означает, что она не заложена. Тем не менее, выписку из реестра должен получить каждый покупатель автомобиля на вторичном рынке. Это позволит подтвердить, что он ответственно отнесся к проверке приобретаемого имущества. Если впоследствии окажется, что автомобиль был в залоге, проведенные перед покупкой проверки позволят покупателю доказать свою добросовестность и дают шансы на сохранение имущества (хотя и не всегда).
Кроме проверки через реестр, нужно получить максимум информации о продавце и обстоятельствах, при которых он приобрел автомобиль с дубликатом ПТС. К примеру. можно вместе с продавцом обратиться в автосалон, где ранее совершалась покупка. Его сотрудники смогут сообщить, оформлял ли продавец автокредит.
Этот способ проверки годится только в случае, если:
автомобиль куплен в автосалоне, который все еще существует;
продавец готов сотрудничать, так как постороннему человеку информацию об оформленном кредите не сообщат. Кроме того, нельзя исключить вероятность сговора между продавцом и сотрудником автосалона, или простую невнимательность, ошибку в базе данных и т.п. Для покупки старых машин, сменивших несколько хозяев, этот метод проверки тоже не годится.
Более безопасный способ — купить автомобиль с дубликатом ПТС через отдел trade-in автосалона. Они проводят собственную юридическую проверку истории автомобиля и его документов, что дает некоторую уверенность в чистоте сделки. Разумеется, и здесь нельзя полностью исключить вероятность обмана, ошибки или небрежности сотрудников автосалона, и т.п.
Не всегда покупка авто с дубликатом ПТС – это плохо. Покупать машину по дубликату можно, если замена документа произошла по уважительной причине — если закончилось место в оригинальном паспорте и владелец готов предъявить его копию. Но и здесь возможны нюансы:
Когда владельцев немного, а строчки оказались заполнены из-за смены их данных (например, фамилий), обычно проблем не возникает.
Если же машину часто перепродавали, это может указывать на проблемы с ее техническим состоянием.
В случаях, когда в особых отметках есть информация о замене ПТС в связи с утерей, нельзя исключить риск того, что автомобиль находится в залоге.
Если же продажа автомобиля с дубликатом ПТС происходит по генеральной доверенности, риски многократно возрастают. Законный владелец, взявший кредит, может и не знать о действиях фактического продавца — или это не удастся доказать. В такой ситуации недобросовестность выдавшего доверенность владельца не очевидна. Если автомобиль окажется в залоге, что-то взыскать с зарегистрированного владельца, взявшего кредит, скорее всего, не удастся и придется самостоятельно выкупать автомобиль у банка. Поэтому покупать автомобиль с дубликатом ПТС по доверенности не стоит.
При покупке нужно обратить внимание на поведение продавца. Если он нервничает, торопит, отказывается давать все документы по запросу, а запрошенная цена очень низкая — это поводы насторожиться.
Нужно внимательно перепроверить все данные в дубликате ПТС – нет ли расхождений в цвете, технических характеристиках автомобиля, данных владельца и т.п., основания предыдущих передач между владельцами (нет ли там записи о залоге).
Помимо ПТС, необходимо проверить и записать все данные продавца (ФИО, паспорт, регистрация и т.п.), а также все другие документы и сервисную книжку автомобиля, в которой может быть отражены данные о его предыдущих владельцах. Не будет лишним и проверить автомобиль по VIN коду на сайте ГИБДД.
https://гибдд.рф/check/auto
Если возникла проблема
В случаях, когда несмотря на проведенные проверки, был куплен кредитный автомобиль, необходимо принять меры для урегулирования ситуации:
заявить в полицию
Заявление в полицию о факте мошенничества позволит отыскать преступника, перепродавшего кредитный автомобиль. Здесь пригодится вся информация, собранная о продавце при подготовке сделки. Необходимо подать именно заявление о совершенном преступлении, поскольку продавший кредитный автомобиль человек заведомо знал об обмане. Такие действия выходят за пределы обычных гражданско-правовых споров и уголовно наказуемы.
урегулировать отношения с банком
Чтобы сохранить за собой автомобиль, скорее всего, покупателю придется заплатить банку, который ранее выдал кредит на его приобретение. Фактически машину придется купить второй раз. Если денег на это нет, банк может пойти навстречу и предоставить кредит на льготных условиях или с отсрочкой выплаты основного долга, когда на протяжении нескольких месяцев выплачиваются только проценты («кредитные каникулы»). За это время мошенника могут найти и взыскать средства с него. Но обязанности идти навстречу неудачливому покупателю у банка нет, в каждом случае придется договариваться.
Проблема дубликатов будет решена раз и навсегда после перехода на единую систему электронных ПТС. Вместо бумажных документов будет создана единая база данных, в которую будут вноситься записи, в том числе, о залогах транспортных средств. Для подтверждения информации из нее можно будет получать выписки неограниченное количество раз.   Не потребуется восстанавливать оригиналы утерянных документов (можно будет просто получить новую выписку). Количество строк в базе данных также не ограничено, поэтому электронный ПТС не закончится. Дубликаты электронных паспортов транспортных средств выдаваться не будут.
Однако принудительного перехода на электронные ПТС для уже выпущенных на рынок автомобилей не планируется. Поэтому еще долгое время покупатели будут вынуждены решать, можно ли покупать машину на вторичном рынке, если ее ПТС присутствует только в виде дубликата. Чтобы не столкнуться с мошенничеством, нужно тщательно проверить все документы перед покупкой.

Что значит 25 ПТС — ответ на вопрос
У автолюбителей в наше время нередко возникает подобный вопрос. Дело в том, что это обозначение может фигурировать в документах. В официальных источниках можно найти довольно скудные сведения на данную тему. Как правило, говориться, что это код определенного региона. На самом деле, так оно и есть. В данном случае, код 25 ПТС (паспорт транспортного средства) обозначает приморский край. Такую отметку присваивают каждому автомобилю, который попал в Россию через таможню данного региона.
На каких машинах встречается?
Это обозначение зачастую можно увидеть в документах, имеющих отношение к японской или корейской машине. При этом авто японского происхождения, чаще всего, имеют правый руль. Ещё 25 ПТС встречается на европейских или американских машинах, но гораздо реже. Если на глаза попалась машина из Америки или Европы с подобной пометкой, то можно сделать вывод, что их привезли на Дальний Восток по морю или железной дороге и растаможили там. Транспортные средства такого типа можно встретить, преимущественно, в восточных регионах государства Российского.
Положительные стороны
Как уже упоминалось выше, по этой пометке в документах на автомобиль можно определить как образом он оказался в России. Многие автолюбители воспринимают этот набор букв и цифр как дополнительный знак качества, ведь это значит, что транспортное средство было напрямую доставлено, например, из Японии. Ведь ни для кого не секрет, что жители страны Восходящего Солнца делают для себя машины гораздо качественней, чем когда хотят их продать, например, в Америку.
Однако, если в документах есть отметка другого региона, то для знающих людей это своего рода условный знак, который говорит о том, что, возможно, качество автомобиля не очень хорошее. Но дело в том, что в этих делах есть небольшая хитрость. Большим плюсом является наличие в документах печати таможни или дополнительного владельца. Совсем другое дело, когда отметка 25 ПТС находится в дубликате. Причина, по которой образовалось данное явление может быть различной. В этой ситуации, покупка такого транспортного средства будет примерно равноценна приобретению кота в мешке.
По какой причине появляется дубликат?
Такое явление не является нарушением закона и ничего криминального в этом нет. Появиться подобное, может, если в оригинале закончилось место под подписи. В такой ситуации, появление дубликата вполне закономерное явление. Но в связи с этим могут возникнуть некоторые вопросы. Дело в том, что большое число владельцев автомобиля — это не всегда хорошо, а иногда очень плохо. Когда машина проходит через большое количество людей, то потихоньку вырабатывает свой ресурс и надежней не становится. Вдобавок, когда смена хозяев происходит за сравнительно небольшой промежуток времени, могут возникнуть вопросы относительно чистоты транспортного средства в криминальном плане.
На эти мелочи стоит обратить внимание если дубликат находится у владельца, который не владел машиной даже год. Однако, следует помнить, что дубликат ещё может выдаваться при потере. Подобные ситуации тоже не являются большой редкостью. Ещё такое явление можно наблюдать у машины, находящейся в кредите. Дело в том, что при его оформлении представители банка обязаны изъять у автовладельца оригинал документов и сохранить до выплаты кредита в полном объёме.
В наше время находятся умельцы, которые умудряются продать даже тот автомобиль, на котором лежит ограничение подобного типа. Такие умники просто пишут в ГИБДД заявление о том, что оригинал технического паспорта был утерян. После этого сотрудники правоохранительных органов выдают таким гражданам дубликат, с которым они спокойно могут продать налево свой автомобиль. При этом с банком, который, несомненно, захочет забрать залог за невыплаченный кредит будет разбираться уже новый хозяин машины, который ничего не подозревает.
Чтобы не стать жертвой таких обстоятельств, перед покупкой новой машины лучшим решением будет тщательно проверить его историю, так как вряд ли старый владелец признается в наличие каких — нибудь подводных камней. Такая осторожность позволит избежать досадных обстоятельств в будущем, а также обезопасит нового хозяина машины. Знающие люди советуют отказываться от покупки машины с рук при наличии малейших сомнений.
Истории автовладельцев
Василий 45 лет.
«Однажды захотел я купить Хендай Туксон с рук. Нашёлся мужик, который готов был мне его продать почти в два раза дешевле, чем в салоне такая тачка стоит. Всё было в порядке пока я не увидел дубликат технического паспорта и не решил проверить тачку через знакомого в ГАИ. Оказалось, что машина в угоне.»
Александр 39 лет.
«Пару лет назад брал я Тоёту Короллу. Цена была сильно завышена и я уже собрался отказываться пока старый владелец не показал мне тех. паспорт с отметкой 25 ПТС. Я тогда не знал, что это, а когда он сказал мне, что это вроде как показатель качества я вовсе не поверил. Только после того, как друзья объяснили мне, что через Приморский регион плохие тачки редко приходят я бросился звонить тому мужику и соглашаться на указанную сумму. В итоге езжу 8 год и не жалуюсь.»
Евгений 37 лет.
«Как — то раз покупал я Киа Спортридж за небольшую цену. С самого начала меня это сильно насторожило. Но при дальнейшем рассмотрении всё казалось просто идеальным. Даже в дубликате документов красовалась отметка 25 ПТС. Когда я уже почти согласился до меня дошли сведения, что данная машина находится под залогом кредита в банке. От покупки сразу отказался.»
Заключение
Если вспомнить всё то, что говорилось выше, то можно сделать вывод, что значит 25 ПТС. Подобный код может предоставить определенные сведения о машине. Его силу может подкрепить печать таможни, которая находится в Приморском крае. По этой отметке можно сделать вывод, что автомобиль не был собран в России или где — то ещё. Он скорей всего свежий и прибыл прямо с завода, или имеет срок службы не более одного года. Насторожиться стоит если вместо оригинала документов при продаже показывают их дубликат. В этой ситуации, проверка прошлого транспортного средства будет закономерной мерой предосторожности.
Что значит 25 ПТС? Видео
Рекомендую прочитать:
Cтоит ли покупать машину у которой дубликат ПТС?
Портится или теряется все, так часто бывает. Теряют буквально все: паспорт, техническую документацию и многое другое. Если, предположим, водитель потерял ПТС, то ему категорически нельзя управлять транспортным средством. Он должен в этом случае написать заявление в ГИБДД и попросить выдать ему дубликат этого документа.
Покупатель же автотранспорта с пробегом насторожится при виде дубликата паспорта ТС, ибо с оригиналом иметь дело намного безопаснее, нежели с «копией».
Сложно распознать случай, если с «клоном» ПТС продается авто находящееся в залоге или взятый в автокредит. Это, кстати, самые распространенные мошеннические схемы в нашей стране. Ниже можно узнать, в чем же опасность «копии» ПТС и каким образом избежать рисков.
Что же это — копия ПТС?
Копия одержит графу «Особые отметки», в которой отмечено: «Дубликат. Так же указано, что он является заменой потерянного старого ПТС» с обязательным указанием реквизитов подлинника.
Отличается ли еще чем-то копия ПТС от оригинала?
В нем так же, как и в оригинале 24 графы, в которых указаны: марка транспортного средства, VIN-номер, вид кузова, сведения о силовом агрегате, год выпуска автомобиля, массу, инициалы владельца и иные данные о нем.
Мошенники при продаже автомобиля передают обманутым покупателям поддельные ПТС, которые не так-то просто отличить от оригинальных. Профессионал, может быть и может найти отличия, но простому обывателю это, скорее всего, не «грозит». В любой копии всегда указывается, что документ является заменой утерянного.
На ПТС также имеются водяные знаки. Так как «клоны» изготавливаются кустарно, то, стало быть, и сделаны они неаккуратно.
Копия ПТС выдается при смене хозяина авто, в случае потери/краже оригинальна, смене места жительства владельца автомобиля ТС и при отсутствии для внесения данных свободного места в старом.

Надо ли бояться дубликата ПТС, а если да — то чего опасаться?
В нашей стране мошенники успешно проворачивают разные сомнительные схемы. Чаще они, конечно аферы проворачивают с недвижимостью, нежели с машинами. Но все же, чем же грозит приобретение автомобиля с «клоном» документов?
Прежде чем притупить к реализации своего зловещего плана, владелец-аферист пишет в ГИБДД заявление об утере ПТС и получает копию документа на основании собственника. Затем он выставляет автомобиль на продажу.
Покупатель даже не в курсе, что вскоре его начнет «доставать» банк и ему придется выплачивать кредит старого владельца.
В данном случае никакие документы о купле-продаже здесь банковских служащих не убедят. Даже в суде свою непричастность доказать не получится.
Так что, дабы не оказаться в столь щепетильной ситуации, надо в банке собрать все необходимые сведения о состоянии документов.
Обладатель автомобиля имеющий дубликат ПТС на руках практически не имеет шансов на продажу автомашины. Поэтому они сбавляют стоимость машины до минимума, даже если у паспорта на автомобиль есть копия оригинала, и ПТС заменился только из-за того, что в нем не осталось свободных строчек.
Конечно, у копий ПТС существует и юридическая сила, но они все таки делают мутной историю машины. Если такое авто очень сильно приглянулось, то все имеющиеся документы на него следует изучать очень внимательно.
Надо ли совершать покупку такого транспортного средства?
Имеются случаи, когда сделка по приобретении машины будет совершенно законной, если:
— ТС имело много владельцев. Просто в ПТС однажды при регистрации не хватило «злополучной» строчки. У самого же продавца имеется копия старого ПТС, в которой указана вся история автомашины;
— из-за невнимательности утрачивается или повреждается оригинал.
Самая широко используемая в нашей стране сделка – приобретение машины в кредит. Покупая авто через банк, владелец передает ПТС кредитному учреждению. Часто случается, что впоследствии клиенту банка нечем оплачивать автокредит.
Автовладелец пишет заявление в ГИБДД, получает копию ПТС и выставляет недавнюю покупку на продажу. Такого можно избежать, если посетить автосалон, в котором старый владелец покупал автомобиль. Можно к тому и выяснить, был на автомашину оформлен автокредит или нет.
Дыбы не платить чужой кредит, сделку купли/продажи осуществляют через официального авто дилера в отделе trade-in. Ни в коем случае не следует связываться с перекупщиками, поскольку они взвинчивают цену, но если выхода нет, подыскивают кого-то понадежней.
При приобретении автотранспорта у человека, показавшего генералку от владельца, не редки случаи, когда кредитное учреждение забирает авто в счет уплаты задолженности. Порой автосалонам приходится страдать по причине своей оплошности, ибо они не внимательно работают документами на машину, и потом им просто некому выставить претензии.
В отделе трейд-ин так же не особо настораживаются при виде копии старого ПТС. Получается обезопаситься, совершив сделку через авторизированного дилера.
Плюсы и минусы
Если покупается транспортное средство с копией ПТС плюс лишь один – доступная стоимость авто, а вот что касается минусов, то их предостаточно. Не каждый может себе позволить купить новый автомобиль.
Среднестатистический россиянин приобретает машину с пробегом желая сэкономить. Он даже не может предположить, что он будет вынужден впоследствии либо крупно вложиться в ремонт, или нарваться на мошенников.
Как же минимизировать риски?
Дабы не попасться в «сети» мошенников, не следует покупать автомашину с дубликатом ПТС. Не всегда, конечно дубликат паспорта машины может – свидетельствовать о мошенничестве. Часто такой документ выдается совершенно законно. Жаль, конечно, что такое доходит не до всех. Сложнее всего приходится людям продающим автомашину с дубликатом документа. Здесь даже низкая стоимость автомобиля не всегда спасет. Выходов в данном случае только два: надеяться на то, что найдётся кто не побоится такую машину купить или самому до скончания дней ездить на ней.
03.07.2017
Понятие что такое дубликат документа
Потеря документа или его повреждение являются основаниями для выдачи дубликата документа. А что такое дубликат документа? Это есть выдача нового экземпляра юридического акта.

Термин «дубликат» следует отличать от сопряженных с ним понятий: «оригинал» и «копия» документа.

Общее и отличное у оригинала, дубликата и копии документа

Общим у оригинала, копии и дубликата является их содержание, которое определяется по тексту подлинника, а затем повторяется в дубликате или копии.

Подлинник или оригинал документа, как определяется в соответствии с национальным стандартом ГОСТ Р 7.0.8-2013, – это единственный или первый экземпляр документа.

Дубликатом является повторный экземпляр оригинала. Он имеет абсолютно такую же юридическую силу, как и оригинал, но отличается в некоторых реквизитах. Дубликат выдается взамен подлинника, поэтому одновременно может существовать только один дубликат.

Копия – новый экземпляр, точно воспроизводящий всю информацию подлинника. Копия может существовать как в письменной, документарной форме, так и как электронная копия.

Кроме того, копия может быть простой или заверенной. Копия имеет юридическую силу подлинника только в отдельных случаях, например, когда нотариально заверена копия договора.

Количество копий зависит от воли обладателя документа, поскольку законодатель никаких ограничений на этот счет не устанавливает.

Помимо копий лицу могут выдаваться выписки из документа.

Содержание дубликата документа

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

Порядок выдачи дубликата и его точные реквизиты зависят от органа, осуществляющего замену и от конкретной ситуации.

Однако обычно соблюдаются следующие правила:

дубликат оформляется в той же форме, что и оригинал. Если подлинник был выполнен на бланке, дубликат заполняется на таком же формуляре. Этим дубликат отличается от копии, которая может быть выполнена на обычном листе бумаги;
на дубликате проставляется штамп или делается надпись «Дубликат», на подлиннике, если он не утрачен, одновременно делается ссылка на выданный дубликат. Такое действие лишает оригинал юридической силы и дальнейшее его использование неправомерно;
прописывается порядковый номер дубликата;
на дубликате снова проставляются необходимые подписи и печати.
что значит и чего бояться, если покупать авто?

ПТС, а также его дубликат, он же автомобильный паспорт, считается одним из самых важных автомобильных документов. Именно в нём указывается вся необходимая информация об идентификационном номере авто, технических характеристиках, данные о производителе и так далее.
Он, в отличие от водительского удостоверения, не играет роли в установлении личности автовладельца, поэтому возить его с собой необязательно: чтобы сотрудник ГИБДД проверил документы, понадобятся лишь права.
Однако паспорт транспортного средства играет важную роль при осуществлении сделок с автомобилем, например, при продаже или купле, а также он нужен при изменении характеристик машины. Однако иногда при сделке можно наткнуться на дублирующее удостворенеие: ПТС дубликат что значит и как получить дубликат ПТС – вот тема этой статьи.
Содержание статьи
Основные характеристики дубликата
Утверждают форму ПТС при помощи нормативно-правовых актов. Она повсюду едина, поскольку вид информации для каждого ТС одинаков. Кроме того, абсолютно все бланки для него выпускаются одинаковыми, причём каждый имеет степень защиты.
Выдают такой тип всего 3 организации:
Таможенная служба – при ввозе автотранспорта из-за рубежа во время процедуры оформления;
ГИБДД – если необходимо восстановить документ после утраты или заменить его;
Производитель – во время покупки нового авто у официальных дилеров или непосредственно изготовителя.
Если первоначальный бланк был заменён, то выданный заново ПТС именуется дубликатом. Выдаваться он может по нескольким причинам:
Оригинал содержал слишком много информации о предыдущих владельцах авто, их невозможно было поместить в поле, поэтому был выдан дублирующий бланк, по аналогии с другими записями об изменении параметров. В такой ситуации копию первоочередной бумаги настоятельно рекомендуется сохранять, поскольку оригинальную изымают, для того, чтобы не возникло проблем во время сделки;
Выдаётся новый ПТС при утере первичного, его краже или повреждении. Такое происходит и при изменении данных автовладельца, к примеру, его фамилии или места регистрации, в редких случаях – отчества или имени. В таких случаях, или если его потеряли, тоже не нужно бояться приобретать авто: достаточно лишь показать копию оригинала и дублирующий бланк продавцу. При этом покупателю следует внимательно сверить бумаги, убедиться в их подлинности и сравнить информацию с реальными характеристиками транспортного средства;
Во всех других ситуациях, как то залог оригинального паспорта у банка, поскольку на авто оформлен ещё не выплаченный кредит, заново выданный лишь принесёт ненужные приобретателю трудности.
Законно получить бумагу можно в день обращения владельца в полицию. При этом нередки случаи, когда требуется дополнительное время на проверку:
например, нужно выяснить, из-за чего изменялись данные и была ли процедура законна, а также почему и в каких обстоятельствах утерян оригинальный документ.
Иногда проверка такого характера может занять от 2 недель до месяца, при этом владелец обязан будет заплатить пошлину.
Как получить?
Чтобы подать заявление для нового паспорта, понадобится несколько бумаг:
Паспорт;
Документ, подтверждающий покупку ТС;
Свидетельство, подтверждающее право собственности на авто;
Полис страхования ОСАГО;
Чек, удостоверяющий оплату госпошлины;
Объяснительная (если оригинальный бланк утерян).
Отличия
Как отличить оригинал от дубликата? Очень просто – достаточно взглянуть на бланк:
единственным отличием станет печать «дубликат», а также запись о том, что новая бумага выдана взамен определённого паспорта.
Именно эти признаки помогут определить факт дублирующего ПТС во время сделки.
Чем опасна купля без оригинального паспорта?
Итак, совершая сделку, когда присутствует дубликат ПТС чего бояться и как снизить риск? Страх покупателя при осуществлении купли-продажи без оригинала вполне понятен. Если продавец на сделке предъявляет дублирующий паспорт, нужно в том числе учесть, что он вполне может быть нечестным. Некоторые мошенники могут получить законный дубликат, используя в своих коварных целях.
Получают бумагу преступники могут абсолютно легально: например, предмет сделки был угнан, а её затем восстановили, вписав имя мошенника. Или такой момент: машина приобреталась в рассрочку, но при этом кредит ещё не был выплачен, поэтому оригинал всё ещё в залоге у кредитора. Эта ситуация не помешает автовладельцу взять и оформить дублирующий документ – в этом случае после продажи нечестный владелец остаётся в выигрыше, поскольку успел совершить лишь 1 кредитный платёж. Также не исключён вариант полностью поддельного бланка, причём не только оригинального, но и дублирующего.
Как избежать мошенничества?
Стоит ли покупать такого рода автосредство, которое за место ПТС имеет его дубликат? Чтобы обезопасить себя от мошеннических схем, лучше всего попросту не заключать подозрительной купли-продажи. Однако некоторые покупатели всё же хотят рискнуть ввиду особой выгоды попавшегося предложения.
В такой ситуации разумно следовать методам безопасности:
Рекомендуется связаться с салоном, где продавец, соответственно информации в ПТС, приобретал автотранспорт;
Покупать автосредство необходимо только у владельца, поскольку во время сделки по генеральной доверенности риск мошенничества очень высок, даже если присутствует печать нотариуса;
Нужно выяснить, где территориально регистрировался автомобиль во время покупки: если достаточно далеко, это тоже должно стать основанием насторожиться, ведь авто могли угнать, чтобы быстро сбыть в другом регионе;
Также следует исследовать удостоверение транспортного средства и узнать, была ли сделана запись о снятии с учёта. Если транспорт подлежит утилизации, такой никогда не получится зарегистрировать;
Далее необходимо изучить запись о том, когда именно выдавался дублирующий документ. Если с момента переоформления и получения прошло не так много времени, особенно если это произошло несколько дней назад, от покупки следует отказаться. Лучше всего, если он выдавался 2 и более года назад, и за это время у авто владелец не менялся.
Кроме этого, рекомендовано узнать о количестве всех владельцев ТС за весь период – подозрение должны вызвать часто меняющиеся записи. А ещё нужно взглянуть на ВИН-щиток на кузове и в салоне, и сравнить с номером в бумаге.
Ну а самым важным подтверждающим документом должна служить копия оригинальной бумаги: если продавец не показывает её под каким-либо предлогом, например, говорит, что она потерянная, брать такое ТС не рекомендуется.
Внимание!
В связи с частыми изменениями законодательства РФ, информация на сайте не всегда успевает обновляться, поэтому для Вас круглосуточно работают бесплатные эксперты-юристы!
Горячие линии:
Москва: +7 (499) 653-60-72, доб. 206
Санкт-Петербург: +7 (812) 426-14-07, доб. 997
Регионы РФ: +7 (800) 500-27-29, доб. 669.
Заявки принимаются круглосуточно и каждый день. Либо воспользуйтесь онлайн формой.

arduino — HTTP против TCP / IP, отправка данных на веб-сервер
Вкратце: TCP — это протокол транспортного уровня, а HTTP — это протокол прикладного уровня, работающий поверх TCP.
Подробно: Чтобы понять разницу (и многие другие сетевые темы), вам необходимо понять идею многоуровневой сетевой модели. По сути, существуют разные протоколы, которые позволяют компьютеру общаться на разных расстояниях и на разных уровнях абстракции.
В самом низу сетевого стека находится физический уровень.Здесь электрические сигналы, световые импульсы или радиоволны действительно передают информацию с места на место. На физическом уровне на самом деле нет протоколов, но вместо этого есть стандарты для напряжений, частот и других физических свойств. Таким образом вы можете передавать информацию напрямую, но вам потребуется много энергии или выделенная линия, а без более высоких уровней вы не сможете разделить полосу пропускания.
Следующий уровень — это канальный уровень. Этот уровень охватывает связь с устройствами, которые совместно используют физическую среду связи.Здесь такие протоколы, как Ethernet, 802.11a / b / g / n и Token Ring, определяют, как обрабатывать несколько одновременных доступов к физической среде и как направлять трафик на одно устройство вместо другого. В обычной домашней сети именно так ваш компьютер общается с домашним «маршрутизатором».
Третий уровень — это сетевой уровень. В большинстве случаев это Интернет-протокол (IP). Именно здесь происходит волшебство Интернета, и вы можете разговаривать с компьютером на другом конце света, не зная, где он находится.Маршрутизаторы обрабатывают направление вашего трафика из вашей локальной сети в сеть, в которой находится другой компьютер, где его собственный канальный уровень обрабатывает доставку пакетов на нужный компьютер.
Теперь мы кое-чего добились. Мы можем разговаривать с компьютером где-нибудь по всему миру, но на нем работает множество разных программ. Как он должен знать, кому доставить ваше сообщение? Об этом позаботится транспортный уровень, обычно с помощью номеров портов. Двумя наиболее популярными протоколами транспортного уровня являются TCP и UDP.TCP делает много интересных вещей, чтобы сгладить грубые пятна связи с коммутацией пакетов на сетевом уровне, например переупорядочивание пакетов, повторная передача потерянных пакетов и т. Д. UDP более ненадежен, но имеет меньше накладных расходов.
Итак, мы подключили ваш браузер к программному обеспечению веб-сервера на другом конце, но как сервер узнает, какую страницу вы хотите? Как вы можете задать вопрос или ответ? Это то, что обрабатывают протоколы прикладного уровня. Для веб-трафика это протокол передачи гипертекста (HTTP).Существуют тысячи протоколов прикладного уровня: SMTP, IMAP и POP3 для электронной почты; XMPP, IRC, ICQ для чата; Telnet, SSH, RDP для удаленного администрирования; пр.
Это пять уровней сетевой модели TCP / IP, но на самом деле они только концептуальные. Модель OSI имеет 7 уровней. В действительности, некоторые протоколы переключаются между различными уровнями или могут работать на нескольких уровнях одновременно. Например, TLS / SSL обеспечивает шифрование и информацию о сеансе между сетевым и транспортным уровнями.Выше уровня приложения интерфейсы прикладного программирования (API) управляют взаимодействием с веб-приложениями, такими как Quora, Twitter и Facebook.
Стек Интернет-протокола
Стек Интернет-протокола
Хенрик Фрыстык, июль 1994 г.,
Как упоминалось в Интернет-разделе, Интернет — это абстракция от базовых сетевых технологий. и разрешение физических адресов. В этом разделе представлены основные компоненты стека Интернет-протокола и связывает стек с Модель стека эталонных протоколов ISO OSI.Модель Интернета Стек протоколов показан на рисунке ниже.
В этом документе описаны различные части, представленные на этой диаграмме. Описываются протоколы верхнего уровня, например FTP, Telnet, TFTP и т. Д. в протоколе уровня представления раздел. Следующие темы останутся разделами в этом документ:
Интернет-протокол (IP)
Протокол дейтаграмм пользователя (UDP)
Протокол управления передачей (TCP)
Протокол управления транзакционной передачей (T / TCP)
TCP / IP и OSI / RM
Интернет-протокол (IP)
Как видно на рисунке выше, стек Интернет-протокола обеспечивает ориентированная на соединение надежная ветвь (TCP) и без установления соединения ненадежная ветвь (UDP) строится поверх Интернет-протокола.
Интернет-протокол уровень в стеке протоколов TCP / IP — это первый уровень, который вводит абстракция виртуальной сети, которая является основным принципом Интернет-модель. Все детали физической реализации (в идеале даже хотя это не совсем так) скрыты ниже уровня IP. IP Layer обеспечивает ненадежную систему доставки без установления соединения. В Причина, по которой ненадежна, проистекает из того факта, что протокол не предоставляет никаких функций для восстановления ошибок для дейтаграмм которые либо дублируются, либо теряются, либо поступают на удаленный хост в другой заказ, чем они отправляют.Если таких ошибок нет в На физическом уровне протокол IP гарантирует, что передача завершено успешно.
Основной единицей обмена данными на уровне IP является Интернет. Датаграмма. Формат дейтаграммы IP и краткое описание наиболее важные поля включены ниже:
LEN
Количество 32-битных сегментов в IP-заголовке. Без всяких OPTIONS, это значение 5
ВИД УСЛУГ
Каждой дейтаграмме IP может быть присвоено значение приоритета от 0 до 7. показывая важность дейтаграммы.Это позволяет внеполосные данные должны маршрутизироваться быстрее, чем обычные данные. Этот очень важно как контрольное сообщение в Интернете Сообщения протокола (ICMP) передаются как часть данных IP. дейтаграмма. Даже если сообщение ICMP инкапсулировано в IP датаграмма, протокол ICMP обычно считается неотъемлемой частью уровня IP, а не уровня UDP или TCP. Кроме того, ТИП Поле SERVICE позволяет классифицировать дейтаграмму, чтобы укажите желаемая услуга, требующая короткого времени задержки, высокая надежность или высокая производительность.Однако для того, чтобы это было эффект, шлюзы должны знать более одного маршрута к удаленному хосту и как описано во введении, это не тот случай.
ИДЕНТ., ФЛАГИ и СМЕЩЕНИЕ ФРАГМЕНТА
Эти поля используются для описания фрагментации дейтаграммы. Фактическая длина дейтаграммы IP в принципе не зависит от длина физических кадров, передаваемых по сети, называется максимальным блоком передачи данных (MTU) сети .Если дейтаграмма длиннее, чем MTU, тогда она делится на набор фрагменты, имеющие почти тот же заголовок, что и исходная дейтаграмма, но только объем данных, который помещается в физический фрейм. ИДЕНТ флаг используется для идентификации сегментов, принадлежащих одной дейтаграмме, и СМЕЩЕНИЕ ФРАГМЕНТА — относительное положение фрагмента внутри исходная дейтаграмма. После фрагментации дейтаграмма остается как это до тех пор, пока он не получит конечный пункт назначения. Если один или несколько сегментов потеряны или ошибочны, вся дейтаграмма отбрасывается.
Однако основная сетевая технология не полностью скрыта. ниже уровня IP, несмотря на функцию фрагментации. В Причина в том, что MTU может варьироваться от 128 и менее до нескольких тысяч байтов в зависимости от физической сети (Ethernet имеет MTU 1500 байтов). Следовательно, это вопрос эффективности при выборе правильного размер дейтаграммы, чтобы минимизировать фрагментацию. Рекомендуется что шлюзы способны обрабатывать дейтаграммы размером не менее 576 байт без использования фрагментации.
ВРЕМЯ
Это оставшееся время жизни (TTL) для дейтаграммы когда он путешествует по Интернету. Протокол маршрутной информации (RIP) указывает, что разрешено не более 15 переходов.
IP-АДРЕС ИСТОЧНИКА и IP-АДРЕС НАЗНАЧЕНИЯ
И адрес отправителя, и адрес назначения указаны в заголовок дейтаграммы, чтобы получатель мог отправить ответ обратно передающий хост. Однако обратите внимание, что только адрес хоста указано — не номер порта.Это потому, что IP-протокол Протокол IMP-to-IMP — это , а не , сквозной протокол. А требуется дополнительный слой, чтобы на самом деле указать, какие два процесса на передающий хост и конечный пункт назначения, который должен получить дейтаграммы.
Обратите внимание, что IP-датаграмма оставляет место только для исходного источника. IP-адрес и исходный IP-адрес назначения. Как упоминалось в раздел Шлюзы и маршрутизация адрес следующего перехода указывается путем инкапсуляции.В Internet Layer передает IP-адреса следующего перехода адрес к сетевому уровню . Этот IP-адрес привязан к физический адрес, и с этим адресом формируется новый фрейм. Прочее исходного кадра затем инкапсулируется в новый кадр, прежде чем он будет отправить по каналу связи.
Протокол пользовательских дейтаграмм (UDP)
Протокол дейтаграмм пользователя (UDP) — это очень тонкий протокол, построенный на основе Интернет-протокола. Базовая единица данных — Пользователь. дейтаграмма и протокол UDP обеспечивают такие же ненадежные, сервис без установления соединения, передающий пользовательские дейтаграммы как протокол IP передает свои дейтаграммы.Основное отличие состоит в том, что UDP протокол сквозной протокол . То есть он содержит достаточно информации для передачи дейтаграммы пользователя от одного процесса на передающий хост другому процессу на принимающем хосте. Формат дейтаграммы пользователя показано ниже:
Поле LENGTH — это длина дейтаграммы пользователя, включая заголовок, то есть минимальное значение LENGTH составляет 8 байтов. Источник ПОРТ и ПОРТ НАЗНАЧЕНИЯ — это связь между IP-адресом и процесс, запущенный на хосте.Сетевой порт обычно обозначается целое число. Однако дейтаграмма пользователя не содержит IP-адреса. Итак, как протокол UDP знает, когда конечный пункт назначения достиг?
При вычислении заголовка CHECKSUM протокол UDP добавляет 12-байтовый псевдозаголовок, состоящий из ИСТОЧНИКА IP-АДРЕСА, IP-АДРЕС НАЗНАЧЕНИЯ и некоторые дополнительные поля. Когда хозяин получает дейтаграмму UDP, принимает заголовок UDP и создает новый псевдо-заголовок с использованием собственного IP-адреса в качестве IP-АДРЕСА НАЗНАЧЕНИЯ и IP-АДРЕС ИСТОЧНИКА, извлеченный из дейтаграммы IP.Затем это вычисляет контрольную сумму, и если она равна контрольной сумме UDP, то дейтаграмма получила конечный пункт назначения.
Как указано в стеке Интернет-протокола Рисунок Протокол UDP часто используется в качестве основного протокола в протоколы клиент-серверных приложений, такие как TFTP, DNS и т. д., где накладные расходы на обеспечение надежной передачи с установлением соединения значительный. Эта проблема будет рассмотрена далее в следующих двух разделы.
Протокол управления передачей (TCP)
Управление передачей Протокол обеспечивает полнодуплексный, надежный, ориентированный на соединение сервис на прикладном уровне, как показано на рисунке стека Интернет-протокола.Эта секция описал основной принцип протокола TCP и то, как он обеспечивает надежный сервис для протоколов прикладного уровня.
Протокол TCP — это потоковый протокол. Он предназначен для предоставить программному обеспечению прикладного уровня услугу для передачи большой объем данных надежным способом. Устанавливает полный дуплекс виртуальный канал между двумя передающими узлами, чтобы оба узла одновременно может размещать данные в Интернете без указания узел назначения после установления соединения.В протоколе управления транзакционной передачей (T / TCP) раздел клиент-серверное расширение протокола TCP представлена как альтернатива потоковой архитектуре.
Формат сегмента TCP
Сегмент — это основная единица данных в протоколе TCP. Так много следующие разделы основаны на этой единице данных, формат представлены здесь:
ПОРТ ИСТОЧНИКА, ПОРТ НАЗНАЧЕНИЯ
Протокол TCP использует тот же трюк с использованием псевдозаголовка. вместо передачи IP-адреса источника и пункта назначения IP-адрес уже включен в IP-дейтаграмму.Поэтому только номера портов необходимы для однозначного определения взаимодействующего хосты.
КОД
Это поле используется, чтобы указать содержимое сегмента и если необходимо предпринять определенные действия, например, если отправитель достиг EOF в потоке.
ОПЦИИ
Протокол TCP использует поле OPTIONS для обмена информацией например, максимальный размер сегмента принят между уровнями TCP на два хозяина. В настоящее время определены следующие флаги:
URG Поле указателя срочности действительно
ACK Поле подтверждения действительно
PSH Этот сегмент запрашивает push
RST Сбросить соединение
SYN Синхронизировать порядковые номера
FIN Отправитель достиг конца своего байтового потока
СМЕЩЕНИЕ
Это целое число указывает смещение пользовательских данных в пределах сегмент.Это поле требуется только потому, что количество битов, используемых в Поле OPTIONS может отличаться
СРОЧНЫЙ УКАЗАТЕЛЬ
Это поле может быть инициализировано, чтобы указывать на место в пользовательском данные, в которых размещена срочная информация, такая как коды выхода и т. д. Тогда принимающий хост может обработать эту часть немедленно, когда он получает сегмент.
Надежная трансмиссия
На уровне IP-протокола пакеты могут быть отброшены из-за сети. перегрузка, отказ шумового шлюза и т. д.Чтобы обеспечить надежную службы TCP должен восстанавливать данные, которые были повреждены, потеряны, дублированы или доставлены из строя через Интернет система. Это достигается путем присвоения НОМЕРА ПОСЛЕДОВАТЕЛЬНОСТИ каждому байту. передано и требует положительного подтверждения (ACK) от принимающего хоста. Если ACK не получен в течение таймаута интервал, данные передаются повторно. В приемнике последовательность числа используются для правильного порядка сегментов, которые могут быть получены порядка и устранения дубликатов.Ущерб обрабатывается добавлением контрольную сумму для каждого переданного сегмента, проверяя ее на приемнике, и отбрасывание поврежденных сегментов. Принцип показан в рисунок ниже:
Хост A передает пакет данных на хост B , но пакет теряется до того, как достигнет места назначения. Тем не мение, HostA установил таймер, когда ожидать ACK от Host B , поэтому, когда этот таймер заканчивается, пакет передается повторно. В сложная часть метода — найти значение периода тайм-аута поскольку сегмент TCP может перемещаться по разным скоростным сетям с разные нагрузки.Это означает, что Время приема-передачи (RTT) может варьироваться от сегмента к сегменту. Простой способ расчета RTT заключается в использовании рекурсивного среднего значения с экспоненциальным окном для уменьшить важность старых ценностей.
Как упоминалось во введении к TCP раздел, протокол является потоковым протоколом. Оно использует неструктурированные потоки без метода индексации пользовательских данных, например в качестве записи и т. д. Кроме того, длина сегмента TCP может варьироваться в зависимости от случай для IP-дейтаграммы и пользовательской дейтаграммы UDP.Следовательно подтверждение не может быть основано на номере сегмента, но должно быть на основе успешно переданных байтов.
Однако принцип PAR очень неэффективен, поскольку передающий хост должен дождаться подтверждения, прежде чем он сможет отправить следующий сегмент. Это означает, что минимальное время между двумя сегментами составляет 1 RTT. плюс время, необходимое для обслуживания сегментов с обоих концов. ПТС Протокол решает эту проблему, используя скользящие окна на обоих концах.
Этот метод позволяет передающему узлу отправлять столько байтов, сколько может. быть сохранены в окне отправки, а затем ждать подтверждения, как удаленный хост получает сегменты и отправляет данные в другой направление.Отправленное подтверждение является кумулятивным, так что оно в все время показывает следующий байт , который ожидает принимающий хост чтобы увидеть. Пример с большим размером окна и выборочной ретрансляция показана на рисунке:
Байт номер 1 потерян, поэтому Host B никогда не отправляет положительный результат. подтверждение. Когда Хост A истекает в байте 1, он повторно передает Это. Однако, поскольку остальные байты от 2 до 5 передаются успешно следующее подтверждение может сразу перейти к 6, следующий ожидаемый байт.Байт 2 также повторно передается как Host не знает точно, сколько байтов ошибочно. Хост B просто отбрасывает байт 2, поскольку он уже загружен.
Технику окна можно также использовать для контроля перегрузки. механизм. Как указано в сегменте TCP Форматирование Рисунок каждый сегмент имеет поле ОКНО, которое указывает, как много данных, которые хост готов получить. Если хост сильно загружен, это может уменьшить параметр WINDOW и, следовательно, скорость передачи капли.
Однако, поскольку протокол TCP является сквозным протоколом, он не может видеть если в промежуточном интерфейсе возникла проблема перегрузки Процессор сообщений (IMP) (часто называемый пакетной коммутацией) узел ) и, следовательно, у него нет средств управлять им, регулируя размер окна. TCP решает эту проблему с помощью контрольного сообщения Интернета. Сообщения о блокировке источника протокола (ICMP).
Установление соединения
Когда нужно открыть TCP-соединение, используется трехстороннее рукопожатие (3WHS). чтобы установить виртуальный канал, существующий до соединение закрывается в конце передачи данных.3WHS — это описывается ниже, поскольку это важная часть TCP протокол, но также показывает некоторые недостатки в протоколе. В Принцип работы 3WHS показан на рисунке ниже:
Блоки посередине символизируют соответствующую часть TCP. сегмент, то есть НОМЕР ПОСЛЕДОВАТЕЛЬНОСТИ, НОМЕР ПОДТВЕРЖДЕНИЯ и код. Активный Host A отправляет сегмент, указывающий, что он НОМЕР ПОСЛЕДОВАТЕЛЬНОСТИ начинается с x. Хост B отвечает ACK и указывает, что он начинается с НОМЕРА ПОСЛЕДОВАТЕЛЬНОСТИ y.На третьем сегмент: оба хоста согласны с порядковыми номерами и что они готов к передаче данных.
На рисунке только Host A делает активное открытие. Собственно два хосты могут открывать одновременно, и в этом случае оба хоста выполняют SYN-RECEIVED, а затем синхронизировать соответственно. Основная причина для 3WHS заключается в том, чтобы предотвратить запуск старых дублирующих подключений вызывая замешательство.
Обратите внимание, что НОМЕР ПОСЛЕДОВАТЕЛЬНОСТИ сегментов 3 и 4 одинаков, потому что ACK не занимает пространство порядковых номеров (если это так, протокол приведет к ACKing ACK!).
Однако установление TCP-соединения довольно долгое время. во многих приложениях, особенно в клиент-серверных приложениях например, во всемирной паутине. В следующем разделе представлена альтернатива, имеющая представлено более легкое установление соединения.
Протокол управления транзакционной передачей (T / TCP)
Протокол TCP — это высокосимметричный протокол, в котором оба хоста могут передавать и получать данные одновременно. Тем не менее, не все приложения симметричны по своей природе.Типичный пример — это протокол клиент-сервер, такой как Домен Служба имен. Транзакционная передача Протокол управления (T / TCP), который является очень новым протоколом (июль 1994 г. ) предлагает альтернативу TCP, когда требуется высокая производительность в клиент-серверные приложения. Некоторые из требований высокого Протоколы, ориентированные на выполнение транзакций, перечислены ниже:
Взаимодействие между клиентом и сервером основано на запрос, за которым следует ответ, то есть подход без сохранения состояния.
Протокол должен гарантировать, что транзакция выполняется в один раз, и любые повторяющиеся пакеты, полученные сервером, должны быть отброшенным.
Нет явной процедуры открытия или закрытия соединения. Это напротив TCP и 3WHS, как описано выше.
Минимальная задержка транзакции для клиента должна быть Раунд Время отключения (RTT) + Время обработки сервера (SPT) . То есть в основном такое же требование, как отсутствие явной процедуры открытия или закрытия.
Протокол должен поддерживать надежный минимум сделка ровно 1 сегмента в обе стороны.
В этом разделе описывается, как протокол TTCP решает эти проблемы. требований, а также которые могут повлиять на всемирную Веб-модель в отношении производительности.
Неявное установление соединения
Протокол T / TCP обозначен именем, основанным на TCP. протокол и T / TCP обратно совместим с TCP. Однако один из особенности протокола T / TCP в том, что он может обходить 3WHS описано в предыдущем разделе, но в случае неисправность может быть устранена с помощью процедуры 3WHS.
3HWS был введен для предотвращения старых дубликатов инициирование соединения от причинения путаницы. Однако T / TCP предоставляет альтернативой этому путем введения трех новых параметров в Поле OPTION в сегменте TCP:
СЧЕТЧИК СОЕДИНЕНИЙ (CC)
Это 32-битный номер воплощения, где отдельное значение назначается всем сегментам, отправляемым от Host A до Host B и другое отличное число наоборот. Ядро на обоих хостах держит кэш всех номеров CC, которые в настоящее время используются подключениями к удаленному хосты.При каждом новом подключении номер CC клиента монотонно увеличивается на 1, чтобы сегмент, принадлежащий новому соединению, мог быть отделенным от старых дубликатов от предыдущих подключений.
СЧЕТЧИК СОЕДИНЕНИЙ НОВЫЙ (CC.NEW)
В некоторых ситуациях принцип монотонно возрастающего значение CC может быть нарушено либо из-за сбоя хоста, либо из-за достигается максимальное число, то есть 4G, и счетчик возвращается к 0. Это возможно на практике, поскольку один и тот же номер CC является глобальным для все соединения.В этой ситуации отправляется CC.NEW, а удаленный хост сбрасывает свой кеш и возвращается к обычному TCP-соединению 3WHS учреждение. Этот сигнал всегда будет посылаться из клиент и с по сервер.
ПОДКЛЮЧЕНИЕ СЧЕТЧИКА ECHO (CC.ECHO)
В ответе сервера поле CC.ECHO содержит значение CC отправить клиентом, чтобы клиент мог проверить ответ как принадлежность к конкретной сделке.
Байпас 3WHS показан на следующем рисунке:
В этом примере два сегмента отправляются в обоих направлениях.Связь устанавливается, когда первый сегмент достигает сервера. Клиент остается в Состояние ВРЕМЯ-ОЖИДАНИЕ, которое объясняется в следующем разделе.
Connection Shotdown
Каждое TCP или UDP-соединение между двумя хостами однозначно идентифицируется следующей пятеркой:
Протокол (UDP, TCP)
IP-адрес хоста A
Номер порта хоста A
IP-адрес хоста B
Номер порта хоста B
Всякий раз, когда TCP-соединение было закрыто, ассоциация описывала кортеж из 5 переходит в состояние ожидания, чтобы убедиться, что оба хоста получил окончательное подтверждение от процедуры закрытия.В время ожидания называется TIME-WAIT и по умолчанию 2 * MSL (120 секунд), где MSL — это максимальное время жизни сегмента. То есть, два хоста не могут выполнить новую транзакцию с использованием одного и того же 5-кортежа по крайней мере, через 120 секунд после предыдущего подключения прекращено. Один из способов обойти эту проблему — выбрать другой 5-кортеж, но как упоминалось в Расширении TCP для Транзакции — концепции, которые не масштабируются из-за чрезмерного объем пространства ядра, занятого завершенными TCP-соединениями, зависает вокруг.
Однако номера CC T / RCP дают уникальную идентификацию каждого транзакция, поэтому протокол T / TCP может обрезать WAIT-STATE путем сравнения номеров CC. Этот принцип можно посмотреть при расширении конечного автомата одной транзакции, чтобы также включить информация о предыдущих и будущих транзакциях с использованием одного и того же 5-кортежа.
TTCP и Интернет
Как будет показано при описании всемирной паутины этой диссертации, принцип Всемирной паутины — это транзакционный обмен данными объект.Это причина, по которой протокол T / TCP очень интересен. в этой перспективе.
TCP / IP и OSI / RM
Международная организация по стандартизации (ISO) разработала второй доминирующая схема многоуровневого протокола, называемая открытой системой ISO Эталонная модель межсоединений (OSI / RM) . В этом разделе представлены эталонная модель OSI и сравнивает ее со стеком протоколов TCP / IP как показано на рисунке.
Физический уровень
Определяет физическое соединение между хост-компьютерами и IMP и как биты передаются по каналу связи.
Канальный уровень данных
Этот уровень определяет, как данные передаются между IMP с использованием рамки . Его основная задача — сменить сервис из физический уровень в пакетно-ориентированную безошибочную передачу.
Сетевой уровень
Кадры уровня канала данных организованы в Пакеты и направляются по сети. Связи все еще между IMP.
Транспортный уровень
Первый уровень, обеспечивающий сквозную транспортную службу.Это гарантирует, что переданные данные правильно поступят на другой конец.
Сессионный уровень
Этот уровень определяет, как два хоста могут устанавливать сеансы, где данные могут передаваться в обоих направлениях по виртуальному соединению между двумя хозяевами.
Уровень презентации
Уровень представления представляет набор синтаксиса и семантики информация, передаваемая через нижние уровни протокола.
Уровень приложения
Этот уровень определяет виртуальную сеть, независимую от платформы. терминал, чтобы прикладные программы могли обмениваться данными независимо от используемое внутреннее представление данных.
Хотя OSI / RM и TCP / IP можно так сравнить, существует несколько существенных различий между OSI / RM и TCP / IP. стек протоколов, но наиболее важным является то, что OSI / RM — это стандартизированная модель , показывающая, как функциональность протокола стек можно организовать. В нем не указаны точные услуги и протоколы, которые будут использоваться на каждом уровне, тогда как TCP / IP является результатом экспериментальное исследование. Несмотря на это, модель OSI / RM была основа реализации нескольких стеков протоколов, таких как X.25, обсуждали в критике X.25
Другое отличие состоит в том, где находится интеллект. наслоение. OSR / RM представляет надежный сервис на уровне канала передачи данных тогда как TCP / IP имеет интеллект только на транспортном уровне. Обе решения имеют преимущества и недостатки. Когда достоверные данные услуга передачи размещается на нижних уровнях, клиенты используют сеть для связи может быть очень простой, поскольку у них нет для обработки сложных ошибочных ситуаций. Недостаток в том, что производительность снижается из-за чрезмерного количества управляющей информации передается и обрабатывается на каждом хосте.

Хенрик Фристик, [email protected], июль 1994 г.,
Сетевая рабочая группа М. Аллман Запрос комментариев: 5681 В. Паксон Устарело: 2581 ICSI Категория: Стандарты Track E. Blanton Университет Пердью Сентябрь 2009 г. Контроль перегрузки TCP Абстрактный Этот документ определяет четыре взаимосвязанных контроля перегрузки TCP. алгоритмы: медленный старт, предотвращение перегрузки, быстрая повторная передача и Быстрое выздоровление.Кроме того, в документе указывается, как TCP должен начать передачу после относительно длительного периода простоя, а также обсуждение различных методов генерации подтверждений. Этот документ устарел RFC 2581. Статус этой памятки Этот документ определяет протокол отслеживания стандартов Интернета для Интернет-сообщество и просит обсуждения и предложения по улучшения. См. Текущую редакцию «Интернет» Официальные стандарты протокола »(STD 1) для состояния стандартизации и статус этого протокола.Распространение памятки не ограничено. Уведомление об авторских правах Авторские права (c) 2009 IETF Trust и лица, указанные как авторы документа. Все права защищены. Этот документ регулируется BCP 78 и Правовой нормой IETF Trust. Положения, относящиеся к документам IETF, действующие на дату публикация этого документа (http://trustee.ietf.org/license-info). Пожалуйста, внимательно ознакомьтесь с этими документами, поскольку они описывают ваши права. и ограничения в отношении этого документа. Этот документ может содержать материалы из документов IETF или IETF. Материалы опубликованы или станут общедоступными до ноября 10, 2008.Лица, контролирующие авторские права на некоторые из этих материал, возможно, не давал IETF Trust право разрешать модификации такого материала вне процесса стандартизации IETF. Без получения соответствующей лицензии от лица (лиц), контролирующего авторские права на такие материалы, этот документ не может быть изменен вне Процесса стандартизации IETF, и производные от него разработки могут Allman, et al. Стандарты Track [Страница 1] RFC 5681 TCP Congestion Control, сентябрь 2009 г. не создаваться вне процесса стандартов IETF, кроме как для форматирования его для публикации как RFC или для перевода на другие языки чем английский.Оглавление 1. Введение ……………………………………….. ….. 2 2. Определения ……………………………………….. …… 3 3. Алгоритмы контроля перегрузки …………………………….. 4 3.1. Медленный запуск и предотвращение перегрузки …………………… 4 3.2. Быстрая повторная передача / быстрое восстановление ………………………… 8 4. Дополнительные соображения ……………………………….. 10 4.1. Перезапуск неактивных подключений …………………………. 10 4.2. Генерация благодарностей ………………………….. 11 4.3. Механизмы возмещения убытков ……………………………. 12 5. Соображения безопасности …………. ……………………… 13 6. Изменения между RFC 2001 и RFC 2581 …………………….. 13 7. Изменения относительно RFC 2581 …………………………….. 14 8. Благодарности ……………………………………….. .15 9. Ссылки …………………………………………….. 15 9.1. Нормативные ссылки ……………………………….. 15 9.2. Информационные ссылки ……………………………… 16 1. Введение Этот документ определяет четыре TCP [RFC793] контроля перегрузки алгоритмы: медленный старт, предотвращение перегрузки, быстрая повторная передача и Быстрое выздоровление. Эти алгоритмы были разработаны в [Jac88] и [Jac90]. Их использование с TCP стандартизировано в [RFC1122]. Дополнительный ранний работать в аддитивном увеличении, мультипликативном уменьшении контроля перегрузки приведен в [CJ89].Обратите внимание, что [Ste94] предоставляет примеры этих алгоритмов в действии и [WS95] предоставляет объяснение исходного кода для BSD. реализация этих алгоритмов. В дополнение к указанию этих алгоритмов управления перегрузкой, это документ определяет, что TCP-соединения должны делать после относительно длительный период простоя, а также уточнение и уточнение некоторых проблемы, связанные с генерацией TCP ACK. Этот документ устарел [RFC2581], который, в свою очередь, устарел [RFC2001].Этот документ организован следующим образом. В разделе 2 представлены различные определения, которые будут использоваться в документе. Раздел 3 предоставляет спецификацию алгоритмов управления перегрузкой. В разделе 4 описаны проблемы, связанные с контролем перегрузки. алгоритмы и, наконец, в разделе 5 изложены соображения безопасности. Allman, et al. Стандарты Track [Страница 2] RFC 5681 TCP Congestion Control, сентябрь 2009 г. Ключевые слова «ДОЛЖНЫ», «НЕ ДОЛЖНЫ», «ОБЯЗАТЕЛЬНО», «ДОЛЖНЫ», «НЕ ДОЛЖНЫ», «ДОЛЖЕН», «НЕ ДОЛЖЕН», «РЕКОМЕНДУЕТСЯ», «МОЖЕТ» и «ДОПОЛНИТЕЛЬНО» в этом документ следует интерпретировать, как описано в [RFC2119]. 2. Определения В этом разделе дается определение нескольких терминов, которые будут используется в оставшейся части этого документа. СЕГМЕНТ: Сегмент — это ЛЮБЫЕ данные TCP / IP или пакет подтверждения (или обе). МАКСИМАЛЬНЫЙ РАЗМЕР СЕГМЕНТА (SMSS): SMSS — это размер самый большой сегмент, который отправитель может передать. Это значение может быть исходя из максимальной единицы передачи сети, путь Алгоритм обнаружения MTU [RFC1191, RFC4821], RMSS (см. Следующий элемент), или другие факторы.Размер не включает заголовки TCP / IP. и варианты. МАКСИМАЛЬНЫЙ РАЗМЕР СЕГМЕНТА ПРИЕМНИКА (RMSS): RMSS — это размер самый большой сегмент, который приемник готов принять. Это значение, указанное в опции MSS, отправленное получателем во время подключение запускается. Или, если опция MSS не используется, это 536 байтов [RFC1122]. Размер не включает заголовки TCP / IP и опции. ПОЛНЫЙ СЕГМЕНТ: сегмент, содержащий максимальное количество разрешенные байты данных (т. е.е., сегмент, содержащий байты SMSS данные). ОКНО ПРИЕМНИКА (rwnd): последнее объявленное окно приемника. ОКНО ЗАГРЯЗНЕНИЯ (cwnd): переменная состояния TCP, ограничивающая количество данных, которые TCP может отправить. В любой момент времени TCP НЕ ДОЛЖЕН отправлять данные с порядковым номером выше суммы наивысшего подтвержденный порядковый номер и минимум cwnd и rwnd. НАЧАЛЬНОЕ ОКНО (IW): начальное окно — это размер окна отправителя. окно насыщения после завершения трехстороннего рукопожатия.Окно потерь (LW): окно потерь — это размер перегрузки. окно после того, как отправитель TCP обнаружит потерю с помощью повторной передачи таймер. ОКНО ПЕРЕЗАГРУЗКИ (RW): окно перезапуска соответствует размеру перегрузки. окно после того, как TCP перезапустит передачу после периода ожидания (если используется алгоритм медленного старта; см. раздел 4.1 для получения дополнительной информации обсуждение). Allman, et al. Стандарты Track [Страница 3] RFC 5681 TCP Congestion Control, сентябрь 2009 г. РАЗМЕР ПОЛЕТА: количество данных, которые были отправлены, но еще не отправлены. совокупно признано.ДВОЙНОЕ ПОДТВЕРЖДЕНИЕ: подтверждение считается «дублировать» в следующих алгоритмах, когда (а) получатель ACK имеет ожидающие данные, (b) входящее подтверждение не несет данных, (c) биты SYN и FIN отключены, (d) номер подтверждения равен наибольшему подтверждению получено по данному соединению (TCP.UNA из [RFC793]) и (e) объявленное окно во входящем подтверждении равно объявленное окно в последнем входящем подтверждении.В качестве альтернативы TCP, который использует выборочные подтверждения (SACK) [RFC2018, RFC2883] может использовать информацию SACK для определить, является ли входящий ACK «дубликатом» (например, если ACK содержит ранее неизвестную информацию SACK). 3. Алгоритмы контроля перегрузки В этом разделе определены четыре алгоритма управления перегрузкой: медленный. запуск, предотвращение перегрузки, быстрая повторная передача и быстрое восстановление, разработан в [Jac88] и [Jac90]. В некоторых ситуациях это может быть для TCP-отправителя выгодно быть более консервативным, чем алгоритмы позволяют; однако TCP НЕ ДОЛЖЕН быть более агрессивным, чем следующие алгоритмы разрешают (то есть НЕ ДОЛЖНЫ отправлять данные, когда значение cwnd, вычисленное по следующим алгоритмам, не позволило бы данные для отправки).Также обратите внимание, что алгоритмы, указанные в этом документе, работают в условия использования потерь как сигнала перегрузки. Явная перегрузка Уведомление (ECN) также может использоваться, как указано в [RFC3168]. 3.1. Медленный старт и предотвращение перегрузки Алгоритмы медленного старта и предотвращения перегрузки ДОЛЖНЫ использоваться Отправитель TCP для контроля количества вводимых незавершенных данных в сеть. Для реализации этих алгоритмов две переменные: добавлен в состояние TCP для каждого соединения.Окно перегрузки (cwnd) ограничение на объем данных, которое отправитель может передать на стороне отправителя. в сеть до получения подтверждения (ACK), а объявленное окно получателя (rwnd) — это ограничение на стороне получателя на количество невыполненных данных. Минимум cwnd и rwnd управляет передача данных. Другая переменная состояния, порог медленного старта (ssthresh), используется чтобы определить, какой алгоритм используется: медленный старт или алгоритм предотвращения перегрузки используется для управления передачей данных, как обсуждается ниже.Allman, et al. Стандарты Track [Страница 4] RFC 5681 TCP Congestion Control, сентябрь 2009 г. Начало передачи в сеть с неизвестными условиями требует, чтобы TCP медленно зондировал сеть, чтобы определить доступные емкости, чтобы избежать перегрузки сети неуместно большой пакет данных. Алгоритм медленного старта: используется для этой цели в начале передачи или после восстановление потери, обнаруженной таймером повторной передачи.Медленный старт дополнительно служит для запуска «часов ACK», используемых отправителем TCP для выпуска данных в сеть при медленном запуске, перегрузке алгоритмы предотвращения и восстановления потерь. IW, начальное значение cwnd, ДОЛЖНО быть установлено с использованием следующих рекомендации в качестве верхней границы. Если SMSS> 2190 байт: IW = 2 * байта SMSS и НЕ ДОЛЖЕН быть более 2 сегментов Если (SMSS> 1095 байт) и (SMSS RFC 5681 TCP Congestion Control, сентябрь 2009 г. Алгоритм медленного старта используется, когда cwnd ssthresh.Когда cwnd и ssthresh равны, отправитель может использовать либо медленный старт, либо предотвращение перегрузки. Во время медленного запуска TCP увеличивает cwnd максимум на байты SMSS для каждый полученный ACK, который в совокупности подтверждает новые данные. Медленный start заканчивается, когда cwnd превышает ssthresh (или, необязательно, когда он достигает его, как отмечалось выше) или когда наблюдается затор. Пока Традиционно реализации TCP увеличили cwnd точно на Байты SMSS после получения ACK, покрывающего новые данные, РЕКОМЕНДУЕМ что реализации TCP увеличивают cwnd на: cwnd + = min (N, SMSS) (2) где N — количество ранее не подтвержденных байтов с подтверждением во входящем ACK.Эта настройка является частью соответствующего байта Подсчет [RFC3465] и защита от неправильного поведения получатели, которые могут попытаться побудить отправителя искусственно раздуть cwnd с использованием механизма, известного как «ACK Division» [SCWA99]. ACK Подразделение состоит из получателя, отправляющего несколько ACK для одного Сегмент данных TCP, каждый из которых подтверждает только часть своих данных. А TCP, увеличивающий cwnd на SMSS для каждого такого ACK, будет ненадлежащим образом завышать объем данных, вводимых в сеть.Во время предотвращения перегрузки cwnd увеличивается примерно на 1 полный размер сегмента за время приема-передачи (RTT). Предотвращение перегрузки продолжается, пока не будет обнаружена перегрузка. Основные рекомендации по приращение cwnd во время предотвращения перегрузки: * МОЖЕТ увеличивать cwnd на байты SMSS * СЛЕДУЕТ увеличивать cwnd по уравнению (2) один раз за RTT * НЕ ДОЛЖНЫ увеличивать cwnd более чем на байты SMSS Отметим, что [RFC3465] допускает увеличение cwnd больше, чем SMSS байтов для входящих подтверждений во время медленного старта на экспериментальная база; однако такое поведение не допускается как часть стандарт.РЕКОМЕНДУЕМЫЙ способ увеличения cwnd во избежание перегрузки: для подсчета количества байтов, подтвержденных ACK для новые данные. (Недостатком этой реализации является то, что она требует поддержание дополнительной переменной состояния.) Когда количество байтов Подтвержденный достигает cwnd, затем cwnd может быть увеличен до SMSS байтов. Обратите внимание, что во время предотвращения перегрузки cwnd НЕ ДОЛЖЕН быть Allman, et al. Standards Track [Страница 6] RFC 5681 TCP Congestion Control, сентябрь 2009 г. увеличился более чем на SMSS байт за RTT.Этот метод позволяет TCP для увеличения cwnd на один сегмент за RTT в условиях задержки ACKs и обеспечивает устойчивость к атакам ACK Division. Еще одна распространенная формула, которую TCP МОЖЕТ использовать для обновления cwnd во время Предотвращение заторов приведено в уравнении (3): cwnd + = SMSS * SMSS / cwnd (3) Эта настройка выполняется для каждого входящего ACK, подтверждающего новые данные. Уравнение (3) дает приемлемое приближение к лежащий в основе принцип увеличения cwnd на 1 полноразмерный сегмент на RTT.(Обратите внимание, что для подключения, в котором приемник подтверждение каждого второго пакета, (3) менее агрессивно, чем разрешено — примерно увеличивается cwnd каждую секунду RTT. ) Замечание по реализации: поскольку в TCP обычно используется целочисленная арифметика реализации, формула, приведенная в уравнении (3), может не увеличивайте cwnd, когда окно перегрузки больше, чем SMSS * SMSS. Если приведенная выше формула дает 0, результат СЛЕДУЕТ округлить до 1 байт. Примечание по реализации: в более старых реализациях есть дополнительная аддитивная константа в правой части уравнения (3).Это неверен и может фактически привести к снижению производительности [RFC2525]. Примечание по реализации: некоторые реализации поддерживают cwnd в единицах байты, а остальные — в единицах полноразмерных сегментов. Последний будет находят уравнение (3) трудным для использования и могут предпочесть использовать Подход к подсчету обсуждался в предыдущем абзаце. Когда отправитель TCP обнаруживает потерю сегмента с помощью таймера повторной передачи и данный сегмент еще не переиздавался таймер повторной передачи, значение ssthresh ДОЛЖНО быть установлено на no more чем значение, указанное в уравнении (4): ssthresh = max (Размер полета / 2, 2 * SMSS) (4) где, как обсуждалось выше, FlightSize — это сумма невыплаченных данные в сети. С другой стороны, когда отправитель TCP обнаруживает потерю сегмента, используя таймер ретрансляции и данный сегмент уже был ретранслируется таймером повторной передачи хотя бы один раз, значение ssthresh остается постоянным. Allman, et al. Стандарты Track [Страница 7] RFC 5681 TCP Congestion Control, сентябрь 2009 г. Примечание по реализации: простая ошибка — просто использовать cwnd, а не FlightSize, который в некоторых реализациях может кстати увеличиваются далеко за пределы rwnd.Кроме того, по истечении времени ожидания (как указано в [RFC2988]) cwnd ДОЛЖЕН быть не больше окна потерь LW, что равно 1 полноразмерному сегмент (независимо от значения IW). Поэтому после повторная передача отброшенного сегмента, отправитель TCP использует медленный старт алгоритм увеличения окна с 1 полноразмерного сегмента до нового значение ssthresh, после чего для предотвращения перегрузки снова требуется над. Как показано в [FF96] и [RFC3782], восстановление потерь на основе медленного старта после тайм-аута может вызвать ложные повторные передачи, которые запускают повторяющиеся благодарности.Реакция на прибытие этих дублирование ACK в реализациях TCP сильно различается. Этот документ не указывает, как обращаться с такими признаниями, но отмечает это как область, которой можно уделить дополнительное внимание, экспериментирование и уточнение. 3.2. Быстрая ретрансляция / быстрое восстановление Получатель TCP ДОЛЖЕН немедленно отправить дубликат ACK при исходящем прибывает сегмент порядка. Целью этого ACK является информирование отправитель, что сегмент был получен с нарушением порядка, и какая последовательность число ожидается.С точки зрения отправителя дублирующиеся ACK может быть вызвано рядом сетевых проблем. Во-первых, они могут быть вызвано выпавшими сегментами. В этом случае все сегменты после сброшенный сегмент вызовет дублирование ACK, пока не будет отремонтирован. Во-вторых, повторяющиеся ACK могут быть вызваны переупорядочением сегменты данных по сети (не редкое событие в некоторой сети пути [Pax97]). Наконец, повторяющиеся ACK могут быть вызваны репликацией. ACK или сегментов данных по сети.Кроме того, приемник TCP СЛЕДУЕТ немедленно отправлять ACK, когда входящий сегмент заполняет все или часть промежутка в пространстве последовательности. Это даст больше своевременная информация для отправителя, возмещающего убытки через таймаут повторной передачи, быстрая повторная передача или расширенная потеря алгоритм восстановления, описанный в разделе 4.3. Отправителю TCP СЛЕДУЕТ использовать алгоритм «быстрой повторной передачи» для обнаружения и потеря ремонта на основе входящих дублирующих ACK. Быстро Алгоритм повторной передачи использует поступление 3 повторяющихся ACK (как определено в разделе 2, без каких-либо промежуточных ACK, которые перемещают SND.UNA) в качестве индикация потери сегмента. После получения 3 дубликатов ACK, TCP выполняет повторную передачу того, что кажется отсутствующим. сегмент, не дожидаясь истечения таймера повторной передачи. Allman, et al. Standards Track [Страница 8] RFC 5681 TCP Congestion Control, сентябрь 2009 г. После того, как алгоритм быстрой повторной передачи отправляет то, что кажется отсутствующий сегмент, алгоритм «быстрого восстановления» управляет передача новых данных до тех пор, пока не будет получен не дублирующийся ACK.В Причина невыполнения медленного старта заключается в том, что получение повторяющиеся ACK не только указывают на то, что сегмент был потерян, но и также, что сегменты, скорее всего, покидают сеть (хотя массивное дублирование сегмента в сети может сделать это недействительным вывод). Другими словами, поскольку получатель может только генерировать дублировать ACK, когда сегмент прибыл, этот сегмент покинул сети и находится в буфере получателя, поэтому мы знаем, что это больше не потребление сетевых ресурсов.Кроме того, поскольку ACK «часы» [Jac88] сохраняется, отправитель TCP может продолжать передавать новые сегменты (хотя передача должна продолжаться с использованием сокращенного cwnd, поскольку потеря является признаком перегрузки). Реализованы алгоритмы быстрой ретрансляции и быстрого восстановления. вместе следующим образом. 1. На первом и втором дублирующих ACK, полученных отправителем, TCP ДОЛЖЕН отправить сегмент ранее не отправленных данных согласно [RFC3042] при условии, что объявленное окно получателя позволяет, общая FlightSize останется меньше или равным cwnd плюс 2 * SMSS, и что новые данные доступны для передачи.Далее Отправитель TCP НЕ ДОЛЖЕН изменять cwnd для отражения этих двух сегментов. [RFC3042]. Обратите внимание, что отправитель, использующий SACK [RFC2018], НЕ ДОЛЖЕН отправлять новые данные, если входящее дублирующее подтверждение не содержит новая информация SACK. 2. Когда получен третий дублирующий ACK, TCP ДОЛЖЕН установить ssthresh. до не более значения, указанного в уравнении (4). Когда [RFC3042] используется, дополнительные данные, отправленные в режиме ограниченной передачи, НЕ ДОЛЖНЫ быть включены в этот расчет.3. Потерянный сегмент, начинающийся с SND.UNA, ДОЛЖЕН быть передан повторно и cwnd установлен на ssthresh плюс 3 * SMSS. Это искусственно «раздувает» окно перегрузки по количеству сегментов (три), в которых вышел из сети и буферизован получателем. 4. За каждый полученный дополнительный дубликат ACK (после третьего), cwnd ДОЛЖЕН быть увеличен с помощью SMSS. Это искусственно раздувает окно перегрузки, чтобы отразить дополнительный сегмент, который покинул сеть.Примечание. [SCWA99] обсуждает атаку на приемник, при которой многие поддельные дубликаты ACK отправляются отправителю данных, чтобы искусственно раздуть cwnd и вызвать превышение допустимого Allman, et al. Стандарты Track [Страница 9] RFC 5681 TCP Congestion Control, сентябрь 2009 г. скорость отправки, которая будет использоваться. Таким образом, TCP МОЖЕТ ограничить количество раз cwnd искусственно завышается во время восстановления потерь до количество незавершенных сегментов (или их приблизительное значение).Примечание. Когда расширенный механизм восстановления потерь (например, в разделе 4.3) не используется, это увеличение FlightSize может заставляют уравнение (4) слегка увеличивать cwnd и ssthresh, поскольку некоторые сегментов между SND.UNA и SND.NXT предполагается иметь покинули сеть, но по-прежнему отражаются в FlightSize. 5. Когда доступны ранее неотправленные данные и новое значение cwnd и объявленное окно получателя разрешают, TCP ДОЛЖЕН отправить 1 * SMSS байтов ранее не отправленных данных.6. Когда приходит следующий ACK, который подтверждает ранее неподтвержденные данные, TCP ДОЛЖЕН установить cwnd на ssthresh (значение установлен на шаге 2). Это называется «сдуванием» окна. Этот ACK должен быть подтверждением, вызванным повторная передача с шага 3, один RTT после повторной передачи (хотя он может появиться раньше при наличии значительного заказная доставка сегментов данных получателю). Кроме того, этот ACK должен подтверждать все промежуточные сегменты, отправленные между потерянным сегментом и получением третий дублирующий ACK, если ни один из них не был потерян.Примечание. Известно, что этот алгоритм обычно не обеспечивает эффективного восстановления. от множественных потерь в одной серии пакетов [FF96]. Раздел 4.3 ниже касается таких случаев. 4. Дополнительные соображения 4.1. Перезапуск неактивных подключений Известная проблема с описанными алгоритмами контроля перегрузки TCP выше заключается в том, что они допускают потенциально несоответствующий всплеск трафика для передачи после того, как TCP простаивает в течение относительно длительного времени период времени. После периода простоя TCP не может использовать часы ACK для стробирования новых сегментов в сети, поскольку все ACK истощены из сети.Следовательно, как указано выше, TCP потенциально может послать пакет линейной скорости размера cwnd в сеть после простоя период. Кроме того, изменение сетевых условий могло привести к Представление TCP о доступной сквозной пропускной способности сети между двумя конечные точки, по оценке cwnd, неточны во время длительный простой. Allman, et al. Standards Track [Страница 10] RFC 5681 TCP Congestion Control, сентябрь 2009 г. [Jac88] рекомендует TCP использовать медленный старт для возобновления передачи. после относительно длительного простоя.Медленный старт служит для перезапуска часы ACK, как и в начале передачи. Этот Механизм получил широкое распространение следующим образом. Когда TCP не получил сегмент более одного тайм-аута повторной передачи, cwnd уменьшается до значения окна перезапуска (RW) перед передача начинается. Для целей этого стандарта мы определяем RW = min (IW, cwnd). Используя время последнего получения сегмента, чтобы определить, не уменьшать cwnd может не сдуть cwnd в общем случае постоянные HTTP-соединения [HTH98].В этом случае веб-сервер получает запрос перед передачей данных веб-клиенту. В прием запроса приводит к сбою теста на неактивное соединение, и позволяет TCP начать передачу с возможно неуместно большой cwnd. Следовательно, TCP ДОЛЖЕН установить cwnd не более чем RW перед началом передача, если TCP не отправлял данные в интервале, превышающем таймаут повторной передачи. 4.2. Создание благодарностей Алгоритм отложенного ACK, указанный в [RFC1122], ДОЛЖЕН использоваться Приемник TCP.При использовании отложенных ACK получатель TCP НЕ ДОЛЖЕН чрезмерно задерживать подтверждения. В частности, ACK ДОЛЖЕН быть генерируется как минимум для каждого второго полноразмерного сегмента и ДОЛЖЕН быть генерируется в течение 500 мс после поступления первого неподтвержденного пакет. Требование, чтобы ACK «ДОЛЖЕН» создаваться как минимум для каждого второй полноразмерный сегмент указан в [RFC1122] в одном месте как ОБЯЗАТЕЛЬНО, а другое ОБЯЗАТЕЛЬНО. Здесь мы однозначно заявляем, что это ДОЛЖЕН. Мы также подчеркиваем, что это ДОЛЖНО, а это означает, что разработчик действительно должен отклоняться от этого требования только после тщательное рассмотрение последствий.См. Обсуждение «Нарушение растягивания ACK» в [RFC2525] и ссылки в нем для обсуждение возможных проблем с производительностью при генерации ACK реже, чем каждый второй полноразмерный сегмент. В некоторых случаях отправитель и получатель могут не договориться о том, что представляет собой полноразмерный сегмент. Считается, что реализация соблюдать это требование, если он отправляет хотя бы одно подтверждение каждый раз, когда он получает 2 * RMSS байта новых данных от отправителя, где RMSS — это максимальный размер сегмента, указанный получателем для отправитель (или значение по умолчанию 536 байт согласно [RFC1122], если приемник не указывает опцию MSS во время подключения Allman, et al.Стандарты Track [стр. 11] RFC 5681 TCP Congestion Control, сентябрь 2009 г. учреждение). Отправитель может быть вынужден использовать сегмент меньшего размера чем RMSS из-за максимального блока передачи (MTU), MTU пути алгоритм обнаружения или другие факторы. Например, рассмотрим случай, когда получатель объявляет RMSS размером X байтов, но отправитель заканчивается использование сегмента размером Y байтов (Y RFC 5681 TCP Congestion Control, сентябрь 2009 г. был успешно повторно передан, cwnd ДОЛЖЕН быть установлен не более чем ssthresh и предотвращение перегрузки ДОЛЖНЫ использоваться для дальнейшего увеличения cwnd.Потеря двух последовательных окон данных или потеря одного повторную передачу следует рассматривать как два признака перегрузки и, следовательно, в этом случае cwnd (и ssthresh) ДОЛЖНЫ быть уменьшены дважды. Мы РЕКОМЕНДУЕМ разработчикам TCP использовать какую-либо форму расширенных потерь восстановление, которое может справиться с множественными потерями в окне данных. В алгоритмы, подробно описанные в [RFC3782] и [RFC3517], соответствуют общим принципы, изложенные выше. Отметим, что пока это не единственные два алгоритма, которые соответствуют указанным выше общим принципам, эти два алгоритмы проверены сообществом и в настоящее время Стандарты Track.5. Соображения безопасности Этот документ требует, чтобы TCP уменьшил скорость отправки в наличие таймаутов ретрансляции и приход дубликата благодарности. Таким образом, злоумышленник может снизить производительность TCP-соединение, вызывая пакеты данных или их признания утерянными, или путем подделки чрезмерных дубликатов благодарности. В ответ на атаку подразделения ACK, описанную в [SCWA99], это документ РЕКОМЕНДУЕТ увеличить окно перегрузки на основе количество байтов, вновь подтвержденных в каждом поступающем ACK, а не определенной константой для каждого приходящего ACK (как описано в разделе 3.1). Интернет в значительной степени полагается на правильные реализация этих алгоритмов для сохранения сети стабильность и избежать развала заторов. Злоумышленник может вызвать TCP конечные точки, чтобы более агрессивно реагировать на перегрузку за счет подделка избыточных повторяющихся подтверждений или чрезмерного Благодарности за новые данные. Вероятно, такая атака могла загнать часть сети в коллапс из-за перегрузки. 6. Изменения между RFC 2001 и RFC 2581 [RFC2001] был сильно переписан редакционно, и это не возможно перечислить список изменений между [RFC2001] и [RFC2581].Целью [RFC2581] было не изменять ни один из рекомендации, данные в [RFC2001], но для дальнейшего прояснения случаев, когда не обсуждались подробно в [RFC2001]. В частности, [RFC2581] предложил, что TCP-соединения должны делать после относительно длительного простоя период, а также уточнил и прояснил некоторые вопросы Allman, et al. Standards Track [Страница 13] RFC 5681 TCP Congestion Control, сентябрь 2009 г. относящиеся к генерации TCP ACK.Наконец, допустимая верхняя граница для начального окна перегрузки было увеличено с одного до двух сегменты. 7. Изменения относительно RFC 2581 Было добавлено конкретное определение для «дублированного подтверждения», на основе определения, используемого BSD TCP. В документе теперь отмечается, что что делать с дублирующимися ACK после сработал таймер повторной передачи — это будущая работа и явно не указано в этом документе. Первоначальные требования к окну были изменены, чтобы позволить увеличить начальное Windows в соответствии со стандартом [RFC3390].Кроме того, шаги по принимать, когда обнаруживается, что начальное окно слишком велико из-за пути Обнаружение MTU [RFC1191] подробно описано. Рекомендуемое начальное значение для ssthresh было изменено на что он ДОЛЖЕН быть произвольно высоким там, где он был ранее МОЖЕТ. Это служит дополнительным руководством для разработчиков по данному вопросу. При медленном запуске использование соответствующего подсчета байтов [RFC3465] с L = 1 * SMSS явно рекомендуется. Метод увеличения cwnd, указанный в [RFC2581], по-прежнему явно разрешен.Подсчет байтов во время заторов также рекомендуется избегать, в то время как метод из [RFC2581] и другие безопасные методы все еще разрешены. Уточнена обработка ssthresh при тайм-ауте повторной передачи. В частности, ssthresh должен быть установлен на половину FlightSize на сначала повторная передача данного сегмента, а затем постоянная последующие повторные передачи того же сегмента. Описание быстрой повторной передачи и быстрого восстановления было уточнены, и теперь использование ограниченной передачи [RFC3042] рекомендуемые.TCP теперь МОЖЕТ ограничить количество дублирующихся ACK, которые искусственно раздуть cwnd при восстановлении потерь до количества сегментов выдающийся, чтобы избежать повторной атаки спуфинга ACK, описанной в [SCWA99]. Окно перезапуска было изменено с IW на min (IW, cwnd). Этот поведение было описано как «экспериментальное» в [RFC2581]. Теперь разработчикам TCP рекомендуется реализовать расширенный алгоритм восстановления потерь, соответствующий принципам, изложенным в данном документ.Allman, et al. Стандарты Track [стр. 14] RFC 5681 TCP Congestion Control, сентябрь 2009 г. Вопросы безопасности были обновлены, чтобы обсудить разделение ACK. и рекомендую подсчет байтов в качестве противодействия этой атаке. 8. Благодарности Описываемые нами основные алгоритмы были разработаны Ван Якобсоном. [Jac88, Jac90]. Кроме того, ограниченная передача [RFC3042] была разработан совместно с Хари Балакришнаном и Салли Флойд.В начальный размер окна перегрузки, указанный в этом документе, является результатом работы с Салли Флойд и Крейгом Партриджем [RFC2414, RFC3390]. В. Ричард («Богатый») Стивенс написал первую версию этого документа. [RFC2001] и является соавтором второй версии [RFC2581]. Это настоящее версия очень выигрывает от его ясности и вдумчивости описание, и мы благодарны Рича за вклад в разъяснение контроля перегрузки TCP, а также в более широком смысле помогая нам разобраться во многих вопросах, касающихся сетей.Мы хотим подчеркнуть, что недостатки и ошибки этого за документ несут полную ответственность текущие авторы. Часть текста из этого документа взята из «TCP / IP Иллюстрированный, Том 1: Протоколы »У. Ричарда Стивенса (Addison-Wesley, 1994) и «TCP / IP Illustrated, том 2: The Реализация »Гэри Р. Райта и У. Ричарда Стивенса (Аддисон- Уэсли, 1995). Этот материал используется с разрешения Эддисон-Уэсли. Анил Агарвал, Стив Арден, Нил Кардуэлл, Норитоши Демизу, Горри Фэрхерст, Кевин Фолл, Джон Хеффнер, Альфред Хенес, Салли Флойд, Райнер Людвиг, Мэтт Матис, Крейг Партридж и Джо Тач внес ряд полезных предложений.9. Ссылки 9.1. Нормативные ссылки [RFC793] Постел, Дж., «Протокол управления передачей», STD 7, RFC 793, сентябрь 1981 г. [RFC1122] Braden, R., Ed., «Требования к хостам Интернета — Уровни связи «, STD 3, RFC 1122, октябрь 1989 г. [RFC1191] Могул, Дж. И С. Диринг, «Обнаружение MTU пути», RFC 1191, Ноябрь 1990 г. [RFC2119] Брэднер, С. «Ключевые слова для использования в RFC для обозначения Уровни требований », BCP 14, RFC 2119, март 1997 г.Allman, et al. Standards Track [Страница 15] RFC 5681 TCP Congestion Control, сентябрь 2009 г. 9.2. Информативные ссылки [CJ89] Чиу Д. и Р. Джайн, «Анализ увеличения / уменьшения Алгоритмы предотвращения перегрузки в компьютерных сетях », Журнал компьютерных сетей и систем ISDN, вып. 17, нет. 1, стр. 1-14, июнь 1989 г. [FF96] Фолл, К. и С. Флойд, «Сравнения на основе моделирования Тахо, Рино и SACK TCP », Обзор компьютерных коммуникаций, Июль 1996 г., ftp: // ftp.ee.lbl.gov/papers/sacks.ps.Z. [Hoe96] Хоу, Дж., «Улучшение поведения при запуске в условиях перегрузки» Схема управления для TCP », В ACM SIGCOMM, август 1996 г. [HTH98] Хьюз, А., Тач, Дж., И Дж. Хайдеманн, «Проблемы TCP Медленный перезапуск после простоя «, Работа в процессе, март 1998 г. [Jac88] Якобсон, В., «Предотвращение перегрузки и контроль», Компьютер. Коммуникационный обзор, т. 18, нет. 4, стр. 314-329, авг. 1988. ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z. [Jac90] Якобсон, В., «Избегание модифицированной перегрузки TCP Алгоритм «, список рассылки end2end-Interest, 30 апреля 1990 г. ftp://ftp.isi.edu/end2end/end2end-interest-1990.mail. [MM96a] Матис, М. и Дж. Махдави, «Прямое подтверждение: Уточнение контроля перегрузки TCP », Труды SIGCOMM’96, август 1996 г., Стэнфорд, Калифорния. Доступна с http://www.psc.edu/networking/papers/papers.html [MM96b] Матис, М.и Дж. Махдави, «Снижение скорости TCP вдвое с ограничением Параметры », Технический отчет. Доступен с http://www.psc.edu/networking/papers/FACKnotes/current. [Pax97] Паксон В., «Динамика сквозных интернет-пакетов», Труды SIGCOMM ’97, Канны, Франция, сентябрь 1997 г. [RFC813] Кларк, Д., «Окно и стратегия подтверждения в TCP», RFC 813, июль 1982 г. [RFC2001] Стивенс, У., «Медленный запуск TCP, предотвращение перегрузки, быстрый Алгоритмы ретрансляции и быстрого восстановления », RFC 2001, Январь 1997 г.[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, «TCP Варианты выборочного подтверждения «, RFC 2018, октябрь 1996 г. Allman, et al. Стандарты Track [Страница 16] RFC 5681 TCP Congestion Control, сентябрь 2009 г. [RFC2414] Оллман, М., Флойд, С., и К. Партридж, «Увеличение TCP Начальное окно », RFC 2414, сентябрь 1998 г. [RFC2525] Паксон, В., Оллман, М., Доусон, С., Феннер, В., Гринер, Дж., Небеса, I., Lahey, K., Semke, J., and B. Volz, «Known TCP Проблемы реализации », RFC 2525, март 1999 г. [RFC2581] Оллман, М., Паксон, В., и У. Стивенс, «Перегрузка TCP. Control », RFC 2581, апрель 1999 г. [RFC2883] Флойд, С., Махдави, Дж., Матис, М., и М. Подольски, «An Расширение опции выборочного подтверждения (SACK) для TCP », RFC 2883, июль 2000 г. [RFC2988] Паксон В. и М. Оллман, «Вычисление повторной передачи TCP Таймер », RFC 2988, ноябрь 2000 г.[RFC3042] Оллман, М., Балакришнан, Х., и С. Флойд, «Улучшение Восстановление потерь TCP с использованием ограниченной передачи », RFC 3042, Январь 2001 г. [RFC3168] Рамакришнан, К., Флойд, С., и Д. Блэк, «Добавление Явное уведомление о перегрузке (ECN) для IP «, RFC 3168, Сентябрь 2001 г. [RFC3390] Оллман, М., Флойд, С., и К. Партридж, «Увеличение числа TCP Начальное окно », RFC 3390, октябрь 2002 г. [RFC3465] Оллман М., «Контроль перегрузки TCP с помощью соответствующего байта. Counting (ABC) », RFC 3465, февраль 2003 г.[RFC3517] Блэнтон, Э., Оллман, М., Фолл, К., и Л. Ван, «A Потеря, основанная на консервативном выборочном подтверждении (SACK) Алгоритм восстановления для TCP », RFC 3517, апрель 2003 г. [RFC3782] Флойд, С., Хендерсон, Т., и А. Гуртов, «The NewReno Модификация алгоритма быстрого восстановления TCP », RFC 3782, Апрель 2004 г. [RFC4821] Мэтис, М. и Дж. Хеффнер, «MTU пути уровня пакетирования Discovery », RFC 4821, март 2007 г. [SCWA99] Сэвидж, С., Кардуэлл, Н., Ветералл, Д., и Т. Андерсон, «Контроль перегрузки TCP с помощью неправильно работающего получателя», ACM Computer Communication Review, 29 (5), октябрь 1999 г. [Ste94] Стивенс, В., «TCP / IP Illustrated, Том 1: Протоколы», Аддисон-Уэсли, 1994. Allman, et al. Стандарты Track [стр. 17] RFC 5681 TCP Congestion Control, сентябрь 2009 г. [WS95] Райт, Г. и У. Стивенс, «Иллюстрированный протокол TCP / IP, том 2: Реализация », Addison-Wesley, 1995.Адреса авторов Марк Оллман Международный институт компьютерных наук (ICSI) 1947 Центральная улица Люкс 600 Беркли, Калифорния 94704-1198 Телефон: +1440235 1792 Электронная почта: [email protected] http://www.icir.org/mallman/ Верн Паксон Международный институт компьютерных наук (ICSI) 1947 Центральная улица Люкс 600 Беркли, Калифорния 94704-1198 Телефон: +1510 / 642-4274 x302 Электронная почта: [email protected] http://www.icir.org/vern/ Итан Блэнтон Университет Пердью Компьютерные науки 305 North University Street West Lafayette, IN 47907 Электронная почта: eblanton @ cs.Purdue.edu http://www.cs.purdue.edu/homes/eblanton/ Allman, et al. Стандарты Track [стр. 18]
[Глава 6] 6.3 Как выглядит пакет?
Чтобы понять фильтрацию пакетов, вы сначала должны понять пакеты и как они обрабатываются на каждом уровне Стек протоколов TCP / IP:
Пакеты построены таким образом, что уровни для каждого протокола используемые для конкретного соединения, обертываются вокруг пакетов, например слои кожи на луке.
На каждом уровне пакет состоит из двух частей: заголовка и тела. В заголовок содержит информацию о протоколе, относящуюся к этому уровню, а body содержит данные для этого слоя, который часто состоит из целого пакет со следующего уровня в стеке. Каждый слой обрабатывает информацию, которую он получает из слоя над ним в виде данных, и применяет его собственный заголовок к этим данным. На каждом уровне пакет содержит все информация, передаваемая с более высокого уровня; ничего не потеряно. Этот известен процесс сохранения данных при присоединении нового заголовка как инкапсуляция .
На прикладном уровне пакет состоит просто из данных, которые необходимо передано (например, часть файла передается во время FTP-сессия). Когда он переходит на транспортный уровень, Протокол управления передачей (TCP) или Пользователь Протокол дейтаграмм (UDP) сохраняет данные из предыдущий слой и прикрепляет к нему заголовок. На следующем слое IP считает весь пакет (состоящий теперь из заголовок TCP или UDP и data), чтобы быть данными, и теперь прикрепляет свой собственный IP заголовок.Наконец, на уровне доступа к сети Ethernet или другой сетевой протокол рассматривает весь IP-пакет передается ему как данные и прикрепляет свой собственный заголовок. На рис. 6.2 показано, как это работает.
На другой стороне соединения этот процесс обратный. Поскольку данные передаются с одного уровня на следующий более высокий уровень, каждый заголовок (каждая кожица лука) снимается соответствующим слоем. За Например, уровень Интернета удаляет заголовок IP перед передачей инкапсулированных данных на транспортный уровень (TCP или UDP).
Пытаясь понять фильтрацию пакетов, самое важное информация, с нашей точки зрения, находится в заголовках различных слои. В разделах ниже рассматриваются несколько примеров различных типов. пакетов и показать содержимое каждого из заголовков этого пакета фильтрующие маршрутизаторы будут изучены. Мы предполагаем определенное знание Основы TCP / IP и сконцентрируйтесь на обсуждении конкретных вопросов, связанных с пакетом фильтрация. Для подробного введения в TCP / IP, см. Приложение C.
В приведенном ниже обсуждении мы начнем с простого примера, демонстрирующего TCP / IP через Ethernet. Оттуда мы переходим к обсудите характеристики фильтрации пакетов IP, затем протоколы выше IP (например, TCP, UDP, ICMP и RPC), протоколы ниже IP (например, как Ethernet) и, наконец, протоколы, отличные от IP (например, AppleTalk или IPX).
6.3.1 TCP / IP / Ethernet Пример
Рассмотрим пример пакета TCP / IP (для например, тот, который является частью Telnet-соединения) на Ethernet.Здесь нас интересуют четыре слоя: Уровень Ethernet, уровень IP, Уровень TCP и уровень данных. В этой секции, мы рассмотрим их снизу вверх и посмотрим на содержимое заголовки, которые будут проверять маршрутизаторы с фильтрацией пакетов.
6.3.1.1 Уровень Ethernet
На уровне Ethernet пакет состоит из двух частей: Ethernet заголовок и тело Ethernet. В общем, ты не сможешь сделать фильтрация пакетов на основе информации в заголовке Ethernet.В основном, заголовок сообщает вам:
Что это за пакет — мы предположим в этом пример, что это IP-пакет, а не Пакет AppleTalk, пакет Novell, пакет DECNET, или какой-то другой пакет.
Ethernet-адрес машины, на которую был помещен пакет. этот конкретный сегмент сети Ethernet — оригинал исходный компьютер, если он присоединен к этому сегменту; в противном случае последний маршрутизатор на пути от исходной машины сюда.
Адрес Ethernet пункта назначения пакета на этом конкретный сегмент сети Ethernet — возможно, машина назначения, если она присоединена к этому сегменту; в противном случае следующий маршрутизатор на пути отсюда к целевой машине.
Поскольку мы рассматриваем IP-пакеты в этом Например, мы знаем, что тело Ethernet содержит IP-пакет.
6.3.1.2 Уровень IP
На уровне IP пакет IP состоит из двух частей: заголовка IP и Тело IP, как показано на рисунке 6.3. С точки зрения фильтрации пакетов, Заголовок IP содержит четыре интересных части информация:
IP-адрес источника — четыре байтами и обычно записываются как что-то вроде 172.16.244.34.
IP-адрес назначения адрес — как у источника IP адрес.
IP-протокол тип — идентифицирует тело IP как Пакет TCP, в отличие от UDP пакет, протокол управляющих сообщений Интернета (ICMP) пакет или какой-либо другой тип пакета.
Поле опций IP , которое почти всегда пусто, но именно здесь такие параметры, как Исходный IP-маршрут и IP-адрес параметры безопасности были бы указаны, если бы они использовались для данного пакет. (См. Обсуждение в разделе «IP варианты «ниже.)
IP может разделить пакет, который слишком велик для пересечь данную сеть в серию более мелких пакетов, называемых фрагментов . Фрагментация пакета не меняется его структура на уровне IP ( Заголовки IP дублируются в каждом фрагменте), но это может означать, что тело содержит только часть пакета в следующий слой.(См. Обсуждение в разделе «IP фрагментация »ниже.)
Рисунок 6.3: Заголовок и тело IP-адреса
Тело IP в этом примере содержит нефрагментированный TCP-пакет, хотя он мог бы хорошо содержать первый фрагмент фрагментированного TCP пакет.
6.3.1.3 Уровень TCP
На уровне TCP пакет снова содержит два части: заголовок TCP и Тело ПТС. (Рисунок 13.12 в Приложении C показывает формат заголовка и тела TCP.) С точки зрения фильтрации пакетов TCP заголовок содержит три интересных элемента информации:
Исходный порт TCP — a двухбайтовое число, указывающее, какой клиент или сервер обрабатывает пакет исходит с исходной машины
Порт назначения TCP — просто как порт источника TCP
Поле флагов TCP
Поле флагов TCP содержит один интересующий бит для фильтрации пакетов: бит ACK.Изучив Бит ACK, маршрутизатор с фильтрацией пакетов может определить является ли данный пакет первым пакетом, инициирующим TCP-соединение (если бит ACK не установлен) или является последующим пакетом (если ACK бит установлен). Бит ACK является частью Механизм TCP, который гарантирует доставку данные. Бит ACK устанавливается всякий раз, когда одна сторона соединение получило данные с другой стороны (оно подтверждает полученные данные). Следовательно, бит ACK установлен на все пакеты, идущие в любом направлении, кроме самого первого пакета от клиента к серверу.
Тело TCP содержит фактические «данные» передается — например, для Telnet нажатия клавиш или экран дисплеи, которые являются частью сеанса Telnet, или для FTP передаваемые данные или команды выдается как часть сеанса FTP.
6.3.2 IP
IP служит средним Интернет. Под ним может быть много разных слоев, например Ethernet, Token Ring, FDDI, PPP, или почтовый голубь. [2] IP может иметь много других протоколов поверх него, с TCP, UDP и ICMP на сегодняшний день наиболее распространены, по крайней мере, за пределами исследовательской среды.В этом в разделе мы обсуждаем особенности IP, относящийся к фильтрации пакетов.
6.3.2.1 Параметры IP
Как мы видели при обсуждении уровня IP выше, Заголовки IP включают поле опций, который обычно пуст. По своему дизайну IP поле опций предназначалось как место для специальной информации или инструкции по обработке, у которых не было отдельного поля в шапке. Однако разработчики TCP / IP сделали такие хорошая работа по обеспечению полей для всего необходимого, что поле опций почти всегда пусто.На практике, Опции IP используются очень редко, за исключением взлома попытки и (очень редко) для сетевой отладки.
Наиболее распространенным вариантом IP, которым может быть межсетевой экран сталкивается с источником IP вариант маршрута. Маршрутизация от источника позволяет источнику пакета указать маршрут, по которому пакет должен идти к месту назначения, вместо того, чтобы позволить каждому маршрутизатору по пути использовать свои таблицы маршрутизации чтобы решить, куда отправить пакет дальше. Исходная маршрутизация предполагается для отмены инструкций в таблицах маршрутизации.Теоретически опция маршрутизации от источника полезна для работы с маршрутизаторами с неисправными или неверные таблицы маршрутизации; если вы знаете маршрут, по которому следует брать, но таблицы маршрутизации сломаны, можно переопределить неверную информацию в таблицах маршрутизации, указав соответствующие Параметры маршрута от источника IP для всех ваших пакетов. В на практике маршрутизация от источника обычно используется только злоумышленниками, которые пытаются обойти меры безопасности, заставляя пакеты следовать неожиданным путям.
Многие системы фильтрации пакетов используют метод отбрасывания любого пакета с установленным IP-адресом, даже не пытаясь разобраться, что это за вариант или что он означает; в общем это кажется работать хорошо, не вызывая особых проблем.
6.3.2.2 IP-фрагментация
Еще одно соображение на уровне IP для фильтрации пакетов это фрагментация. Одна из особенностей IP — это возможность разделить большой пакет, который иначе не смог бы пройти через некоторые сетевая ссылка (из-за ограничений на размер пакета по этой ссылке) на более мелкие пакеты, называемые фрагментами , которые могут перейдите по этой ссылке. Затем фрагменты собираются полностью. пакет на машине назначения (не на машине на другом конце ограниченной ссылки; когда пакет фрагментирован, он остается фрагментированным пока не достигнет пункта назначения).
IP-фрагментация показана на рисунке 6.4.
Рисунок 6.4: Фрагментация данных
С точки зрения фильтрации пакетов проблема с фрагментацией заключается в том, что только первый фрагмент будет содержать информацию заголовка из протоколов более высокого уровня, таких как TCP, что пакет система фильтрации нуждается в том, чтобы решить, разрешать или нет полный пакет. Общий подход к фильтрации пакетов для работы с фрагментация заключается в том, чтобы пропускать любые фрагменты, не являющиеся первыми, и выполнять фильтрация пакетов только по первому фрагменту пакета.Это безопасно потому что, если фильтрация пакетов решает отбросить первый фрагмент, система назначения не сможет собрать остальную часть фрагментов в исходный пакет, независимо от того, сколько остальных полученных фрагментов. Если он не может восстановить оригинал пакет, частично собранный пакет не будет принят.
Целевой хост некоторое время будет удерживать фрагменты в памяти, ждет, чтобы увидеть, получит ли он недостающий кусок; это делает возможным для злоумышленников использовать фрагментированные пакеты при отказе в обслуживании атака.Когда целевой хост отказывается от повторной сборки пакета, он отправит время повторной сборки пакета ICMP просрочено «сообщение на исходный хост, которое сообщит злоумышленник, что хост существует, и почему соединение не было преуспевать. С таким отрицанием сервисные атаки, но вы можете отфильтровать ICMP Сообщения.
Исходящие фрагменты предположительно могут содержать данные, которые вы не хотите выпуск в мир. Например, исходящий NFS пакет почти наверняка был бы фрагментирован, и если бы файл был конфиденциально, эта информация будет раскрыта.Если это произойдет авария, вряд ли проблема; люди обычно не вешают смотреть на данные в случайных пакетах, проходящих на всякий случай в них есть что-то интересное. Вы можете ждать очень долго чтобы кто-то случайно отправил фрагмент с интересными данными в этом.
Если кто-то внутри намеренно использует фрагментацию для передачи данных, у вас есть враждебные пользователи внутри брандмауэра, и никакой брандмауэр не может справиться успешно с этой проблемой. (Они, наверное, не очень умны однако враждебные пользователи, потому что есть более простые способы получить данные.)
Единственная ситуация, при которой нужно побеспокоиться об исходящих фрагментах это тот, в котором вы разрешаете запрос, но блокируете исходящий Ответить. В этой ситуации непервая часть ответа получит out, и у злоумышленника есть основания их ожидать и искать. Ты может справиться с этим, отфильтровывая запросы и не полагаясь на фильтрацию ответов.
6.3.3 Вышеуказанные протоколы IP
IP служит базой для ряда различных протоколы; безусловно, наиболее распространенными являются TCP, UDP и ICMP.Это в Фактически, единственные IP-протоколы, которые вы вероятно увидеть за пределами исследовательской среды.
Мы обсуждаем удаленные вызовы процедур (RPC) также в этот раздел, хотя RPC, строго говоря, на основе TCP или UDP, а не по самому IP. Имеет смысл обсудить это здесь, однако, поскольку, как TCP и UDP, RPC предназначен для работы как протокол сеанса общего назначения, на котором протоколы приложений можно наслоить.
Кроме того, мы кратко обсудим IP over IP (т.е., IP-пакет инкапсулирован в другом IP-пакете), который используется в основном для туннелирования многоадресных IP-пакетов по IP-сетям без многоадресной передачи.
6.3.3.1 TCP
TCP — это протокол, наиболее часто используемый для служб в Интернете. Например, Telnet, FTP, SMTP, NNTP и HTTP все основаны на TCP Сервисы. TCP обеспечивает надежную двунаправленную соединение между двумя конечными точками. Открытие TCP соединение похоже на телефонный звонок: вы набираете номер, а после небольшой период настройки, устанавливается достаточно надежное соединение между вами и тем, кому вы звоните.
TCP надежен в том, что дает три гарантии прикладному уровню:
Пункт назначения получит данные приложения в том порядке, в котором они были послал.
Пункт назначения получит все данные приложения.
Пункт назначения не будет получать дубликаты любого из Данные приложений.
TCP уничтожит соединение, а не нарушит его этих гарантий. Например, если пакеты TCP с середины сеанса теряются при транспортировке к месту назначения, уровень TCP будет организовывать эти пакеты повторно передается перед передачей данных на уровень приложения.Это не будет передавать данные после отсутствующих данных, пока не получит отсутствующие данные. Если некоторые данные не могут быть восстановлены, несмотря на повторные попытки, уровень TCP убьет подключения и сообщить об этом на уровень приложения, а не в руки вверх данные до уровня приложения с пробелом в нем.
Эти гарантии связаны с определенными расходами во время настройки (обе стороны соединения должны обмениваться информацией о запуске перед они действительно могут начать перемещение данных) и текущую производительность (два стороны соединения должны отслеживать статус соединение, чтобы определить, какие данные нужно переслать другому сторону, чтобы заполнить пробелы в разговоре).
TCP является двунаправленным в том смысле, что когда соединение установлен, сервер может отвечать клиенту по тому же связь. Вам не нужно устанавливать одно соединение от клиента на сервер для запросов или команд, а другой с сервера обратно клиенту для ответов.
Если вы пытаетесь заблокировать TCP-соединение, это Достаточно просто заблокировать первый пакет соединения. Без этот первый пакет (и, что более важно, запуск соединения содержащуюся в нем информацию), дальнейшие пакеты в этом соединении не будут быть повторно собранным в поток данных получателем, а соединение никогда не будет сделано.Этот первый пакет узнаваем, потому что Бит ACK в его заголовке TCP не набор; каждый второй пакет в соединении, независимо от того, какой направление движения, будет установлен бит ACK.
Распознавание этих «начала соединения» Пакеты TCP позволяют применять политику, которая позволяет внутренним клиентам подключаться к внешним серверам, но предотвращает внешние клиенты от подключения к внутренним серверам. Вы делаете это разрешение TCP-пакетов при запуске соединения ( без установленного бита ACK) только исходящий, а не входящий.Пакеты начала соединения будут разрешены из внутренние клиенты на внешние серверы, но не будут допущены с внешние клиенты на внутренние серверы. Злоумышленники не могут подорвать это подход, просто включив бит ACK в их пакетов начала соединения, потому что отсутствие Бит ACK определяет эти пакеты как начало. пакетов подключения.
Реализации фильтрации пакетов различаются по тому, как они обрабатывают и позволяют обрабатывать бит ACK. Некоторая фильтрация пакетов реализации предоставляют прямой доступ к ACK бит — например, позволив вам включить «ack» в качестве ключевого слова в правило фильтрации пакетов.Некоторые другие реализации предоставляют косвенный доступ в бит ACK. Например, Cisco «установленное» ключевое слово работает, исследуя этот бит (установлено «истина», если бит ACK установлен, и «false», если бит ACK не установлено). Наконец, некоторые реализации не позволяют изучить Бит ACK вообще нет.
На рисунке 6.5 показано, что ACK установлен для пакетов, которые являются частью TCP-соединение.
Рисунок 6.5: Биты ACK в TCP-пакетах
6.3.3.2 UDP
Тело IP-пакета может содержать Пакет UDP вместо TCP пакет.UDP — альтернатива с низкими накладными расходами TCP.
UDP — это низкие накладные расходы в том смысле, что он не дает никаких гарантий надежности (доставка, заказ, и без дублирования), что TCP делает, и, следовательно, ему не нужен механизм для предоставления этих гарантий. Каждый Пакет UDP независимый; UDP пакеты не являются частью «виртуальной цепи», поскольку Пакеты TCP есть. Отправка UDP пакетов — все равно что бросать открытки по почте: если вы уроните 100 открытки по почте, даже если все они адресованы одному и тому же место, вы не можете быть абсолютно уверены, что все они получат там, и те, кто попадает туда, вероятно, не будут точно в том же порядке, в котором они были, когда вы их отправляли.
В отличие от открыток, UDP-пакеты могут приходить более одного раза (не разорвав в клочья, что обычно только так, чтобы одна и та же открытка была доставлена несколько раз). Несколько копии возможны, потому что пакет может быть продублирован базовая сеть. Например, в сети Ethernet пакет будет дублируется, если маршрутизатор подумал, что он мог быть жертвой коллизия Ethernet. Если роутер был неправильный, а оригинал пакет не был жертвой столкновения, как исходный, так и дубликат в конечном итоге прибудет в пункт назначения.(Смущенный приложение также может решить отправить одни и те же данные дважды, возможно потому что он не получил ожидаемого ответа на первый.)
Все это может случиться с TCP-пакетами, тоже, но они будут исправлены перед передачей данных в заявление. С UDP приложение отвечает за обработку пакетов, а не исправленных данных.
UDP-пакеты очень похожи на Пакеты TCP в составе. UDP заголовок содержит порт источника и назначения UDP числа, как и источник и назначение TCP номера портов.Однако заголовок UDP не содержат что-нибудь похожее на бит ACK. В Бит ACK является частью TCP механизм гарантии надежной доставки данных. Потому что UDP не дает таких гарантий, ему не нужен Бит ACK. Нет возможности для фильтрации пакетов маршрутизатор, чтобы определить, просто проверив заголовок входящего Пакет UDP, является ли этот пакет первым пакетом от внешнего клиента к внутреннему серверу или ответ от внешний сервер обратно к внутреннему клиенту.
Некоторые реализации фильтрации пакетов, например FireWall-1 от CheckPoint продукт, Янус; Маршрутизатор SecureConnect от Morning Star; и KarlBridge / KarlBrouter, имеют возможность «запоминание» исходящих пакетов UDP, которые они видели.Затем они могут разрешить только соответствующий ответ пакеты обратно через механизм фильтрации. Для того, чтобы быть считается ответом, входящий пакет должен быть от хоста и порт, на который был отправлен исходящий пакет, и должен быть направлен на хост и порт, отправивший исходящий пакет. Эта возможность часто называют динамической фильтрацией пакетов , поскольку маршрутизатор существенно изменяет правила фильтрации на fly, чтобы разместить эти возвращающиеся пакеты. Правила созданы, чтобы разрешить ответы ограничены по времени; они истекают через несколько секунд или минут.Динамическая фильтрация пакетов также может использоваться в любой ситуации. в котором правила фильтрации пакетов меняются без чьей-либо явной изменение конфигурации; разные продукты поддерживают разные возможности.
На рисунке 6.6 показана динамическая фильтрация пакетов в уровень UDP.
Рисунок 6.6: Динамическая фильтрация пакетов на уровне UDP
6.3.3.3 ICMP
ICMP используется для определения статуса IP и управляющие сообщения. Пакеты ICMP передаются в тело IP-пакетов, как и TCP и пакеты UDP есть.Примеры Сообщения ICMP включают:
Эхо-запрос — что хост отправляет при запуске пинг .
Эхо-ответ — то, что хост отвечает на «эхо-запрос» с.
Превышено время — что маршрутизатор возвращает, когда он определяет, что пакет кажется зацикленным; более интуитивное имя может быть превышено максимальное количество переходов .
Назначение недоступно — что возвращает маршрутизатор когда пункт назначения пакета не может быть достигнут по какой-либо причине (е.g., потому что сетевое соединение не работает).
Redirect — что маршрутизатор отправляет хосту в ответ к пакету, который хост должен был отправить другому маршрутизатору; роутер все равно обрабатывает исходный пакет (перенаправляя его на маршрутизатор, должен был пойти в первую очередь), а перенаправление сообщает хосту о более эффективном пути в следующий раз.
В отличие от TCP или UDP, ICMP не имеет портов источника или назначения, и нет другие протоколы накладываются поверх него.Вместо этого есть набор определенные коды типов сообщений ICMP; конкретный используемый код диктует интерпретацию остальной части Пакет ICMP.
Многие системы фильтрации пакетов позволяют фильтровать ICMP пакетов на основе поля типа сообщения ICMP, много поскольку они позволяют фильтровать TCP или Пакеты UDP на основе TCP или Поля источника UDP и порта назначения.
6.3.3.4 RPC
Есть несколько удаленных вызовов процедур протоколы, известные как RPC. Самый популярный иногда называют «Солнце. RPC «, потому что он был первоначально разработан в Sun Microsystems.Это протокол, который мы будем обсуждать, и это протокол, который чаще всего называют просто «ПКР». Вызов другой удаленной процедуры механизмы специфичны для конкретной UNIX реализации или семейства реализаций. (Например, OSF DCE имеет собственный протокол удаленного вызова процедур.) механизмы отличаются в деталях от RPC, но имеют тенденцию есть похожие проблемы.
Строго говоря, механизм RPC не построен поверх IP, а скорее поверх UDP и TCP. Однако, как и TCP и UDP, RPC используется как транспортный протокол общего назначения для различных приложений протоколы (такие как NFS и NIS / YP, как мы обсуждаем в главе 8), поэтому имеет смысл описать его здесь.NFS и NIS / YP уязвимы сервисы с точки зрения сетевой безопасности. Злоумышленник с доступ к вашему серверу NFS, вероятно, может читать любой файл в вашей системе. Злоумышленник, имеющий доступ к вашему Сервер NIS / YP, вероятно, может получить ваш пароль файл, на котором он может запустить атаку с взломом пароля против вашего система.
В протоколах TCP и UDP, номера портов — это двухбайтовые поля. Это означает, что есть только 65 536 возможных номеров портов для TCP и Сервисы UDP. Недостаточно портов, чтобы назначать уникальный хорошо известный номер порта каждой возможной службе и приложение, которому он может понадобиться.Среди прочего, RPC устраняет это ограничение. Каждый Сервису на основе RPC присваивается уникальный четырехбайтовый «Сервисный номер RPC». Это позволяет 4 294 967 296 различных услуг, каждая с уникальным номером. Это более чем достаточно, чтобы присвоить уникальный номер каждой возможной услуге и приложение, которое вам понадобится.
RPC построен поверх TCP и UDP, поэтому должен быть какой-то способ сопоставления Сервисные номера RPC Серверы на основе RPC, используемые на машине для определенные порты TCP или UDP эти серверы используют.Вот где Входит сервер portmapper .
Portmapper является единственным Сервер, связанный с RPC, который гарантированно работает на конкретный порт TCP или UDP номер (он находится в порту 111 на обоих). Когда Сервер на основе RPC, такой как NFS или запускается сервер NIS / YP, он выделяет случайный TCP и / или UDP (некоторые используют один, некоторые другие, некоторые оба) порт для себя. [3] Затем он связывается с сервером portmapper на та же машина, чтобы «прописать» свою уникальную Сервисный номер RPC и конкретный порт (ы) он используется в данный момент.
Клиентская программа на основе RPC, которая хочет связаться с конкретный сервер на основе RPC сначала на машине связывается с сервером portmapper на этом компьютере (который, помните, всегда работает и по TCP, и по UDP-порт 111). Клиент рассказывает portmapper уникальный RPC сервисный номер сервера, к которому он хочет получить доступ, и portmapper отвечает сообщением, в котором эффект, либо «Извините, но эта услуга недоступна эта машина в данный момент «или» Эта служба в настоящее время работает на TCP (или UDP) порте N на этой машине на данный момент.»При этом точка, клиент связывается с сервером по номеру порта, с которого он получил portmapper и продолжает разговор напрямую с сервером, без дальнейшего участия портмапер . (Рисунок 6.7 показывает этот процесс.)
Рисунок 6.7: RPC и portmapper
Очень сложно использовать фильтрацию пакетов для управления Службы на основе RPC, потому что вы не знаете, что порт, который служба будет использовать на конкретной машине — и шансы заключается в том, что используемый порт будет меняться каждый раз, когда машина перезагрузился.Блокировка доступа к Portmapper не достаточный. Злоумышленник может обойти этап разговора с portmapper , и просто попробуйте все Порты TCP и / или UDP (65 536 все возможные порты могут быть проверены на конкретной машине минут), ища ответ, ожидаемый от конкретного Сервер на основе RPC, такой как NFS или NIS / YP.
Некоторые новые продукты для фильтрации пакетов могут общаться с portmapper , чтобы определить, где какие службы и фильтровать на этом основании.Обратите внимание, что это необходимо проверить на на пакетной основе для служб на основе UDP. Пакет фильтр придется обращаться portmapper каждый раз, когда он получает пакет, потому что, если машина перезагрузилась, служба может взолнованный. Поскольку TCP ориентирован на соединение, порт номер нужно проверять только для каждого соединения. Используя это механизм, разрешающий службы на основе UDP, будет приводят к высоким накладным расходам и, вероятно, не подходят для работы с интенсивными данными такие приложения, как NFS.
ПРИМЕЧАНИЕ: Даже если этого недостаточно, вам все равно следует заблокировать доступ к portmapper , потому что некоторые версии portmapper могут использоваться как прокси для клиентов злоумышленника.
Итак, что вы делаете для защиты служб на основе RPC? А пара наблюдений: во-первых, оказывается, что большинство «опасные» сервисы на основе RPC (особенно NIS / YP и NFS) предлагаются только по UDP. Во-вторых, большинство услуг вы хотите получить доступ через фильтр пакетов, На основе TCP, не На основе UDP; заметными исключениями являются DNS, NTP, syslog и Archie. Эти двойные наблюдения приводят к общему подходу, который используют многие сайты при работе с RPC с использованием фильтрации пакетов: блок UDP вообще, кроме конкретного и плотно управляемые «глазки» для DNS, NTP, системный журнал и Арчи.(См. Обсуждение эти службы в главе 8.)
При таком подходе, если вы хотите разрешить любой TCP-протокол Служба RPC, вам необходимо разрешить их все. Серверы NFS на базе TCP, пока доступны, но пока не используются широко; если вы их используете, однако вам необходимо соответствующим образом изменить этот подход.
6.3.3.5 IP поверх IP
В некоторых случаях IP-пакеты инкапсулируются в других IP-пакетах для передачи, что дает так называемый «IP over IP. «Наиболее частое использование IP over IP предназначен для многоадресной передачи IP-пакеты (то есть пакеты с многоадресной адреса назначения) между сетями, которые поддерживают многоадресную рассылку через промежуточные сети, которые этого не делают.Чтобы пересечь эти промежуточные сети, специальный многоадресный маршрутизатор (или mrouter ) на каждая многоадресная сеть инкапсулирует многоадресную рассылку IP-пакеты, которые он хочет отправить в не многоадресную рассылку (то есть нормальные) IP-пакеты, адресованные другим mrouter s. Другой mrouter s, при получении этих инкапсулированных многоадресные пакеты, удалите внешний (не многоадресный) пакет, а затем обрабатывать внутренний (многоадресный) пакет.
Multicast IP становится все более популярным на Интернет, в первую очередь из-за конференц-связи и других услуг предлагается через MBONE.Обсуждаем MBONE и мультикаст службы в целом, более подробно в главе 2, Internet Services и Глава 8.
6.3.6 IP Version 6
Текущая версия IP (на момент написания этой книги) официально известен как IP Версия 4; на протяжении всей книги, когда мы говорим о IP без дополнительной квалификации, вот что мы говоря о. Однако есть новая версия IP в разработке, известный как IP версии 6 (IPv6 для короткая). Зачем нужна новая версия IP и как повлияет ли на вас IPv6?
Как мы уже упоминали в разделе «Что насчет будущего? Удерживает »в главе 4, Firewall Design , импульс к созданию IPv6 был одной простой проблемой: Интернет заканчиваются IP-адреса.В Интернете есть стали настолько популярными, что их просто не хватит Номера IP-сетей (особенно сети класса B числа, которые оказались тем, что нужно большинству сайтов) для обхода; по некоторым оценкам, если бы ничего не было сделано, Интернет бы закончились адреса в 1995 или 1996 годах. К счастью, проблема заключалась в признал, и что-то было сделано. На самом деле две вещи — во-первых, реализация комплекса временных мер и инструкций по наилучшее возможное использование оставшихся неназначенных адресов и, во-вторых, разработка и реализация новой версии IP, который будет постоянно заниматься проблема исчерпания адресов.
Если вы собираетесь создать новую версию IP в чтобы справиться с исчерпанием адресного пространства, вы можете также взять преимущество возможности иметь дело с целым множеством других проблемы или ограничения в IP, такие как шифрование, аутентификация, маршрутизация от источника и динамический конфигурация. По словам Стива Белловина из AT&T Bell Laboratories, широко известные межсетевые экраны специалист по Интернету и участник Процесс разработки IPv6: [4]
IPv6 основан на концепции вложенных заголовки.Так выполняются шифрование и аутентификация; то поле «следующий протокол» после IPv6 header определяет шифрование или заголовок аутентификации. В очереди, в их следующих полях протокола обычно указывается либо IPv6 или один из обычных транспортных протоколов, например как TCP или UDP.
Вложенный IP поверх IP может быть выполнен даже без шифрования или аутентификации; который можно использовать как форму маршрутизации от источника. Более эффективный способ — использовать исходную маршрутизацию. заголовок — который более полезен, чем соответствующий Вариант IPv4 и, вероятно, будет использоваться гораздо чаще, особенно для мобильного IP.
Некоторые последствия для брандмауэров уже очевидны. Пакет фильтр должен следовать по всей цепочке заголовков, понимания и обрабатывая каждый по очереди. (И да, это может заставить смотреть на порт номера дороже.) Достаточно осторожная позиция диктует, что пакет с неизвестным заголовком будет возвращен, будь то входящий или исходящий. Кроме того, простота и распространенность маршрутизации от источника означает, что криптографические аутентификация абсолютно необходима. С другой стороны, это Предполагалось, что такая аутентификация станет стандартной обязательной функцией.Зашифрованные пакеты непрозрачны и поэтому не могут быть исследованы; это правда сегодня, конечно, но сейчас используется не так много шифровальщиков. Это изменится. Также обратите внимание, что шифрование может выполняться от хоста к хосту, хост-шлюз или шлюз-шлюз, все еще усложняющий анализ более.
На фильтрацию на основе адресов также в некоторой степени повлияет новый механизмы автоконфигурации. Жизненно важно, чтобы любой хост, чей адрес указанные в фильтре получают каждый раз один и тот же адрес.Пока это цель стандартных механизмов, нужно быть осторожным проприетарные схемы, серверы коммутируемого доступа и т. д. Также, адрес высокого порядка биты могут меняться, чтобы приспособиться к комбинации на основе провайдера адресация и простое переключение между операторами связи.
Наконец, IPv6 включает «потоки». Потоки — это, по сути, виртуальные контуры на Уровень IP; они предназначены для использования в вещах например, видео, выбор схемы ATM с промежуточным переходом, и т.д. Но их также можно использовать для межсетевых экранов, если аутентификация: проблема с ответом UDP может исчезнуть если запрос имел идентификатор потока, на который ссылался ответ.Этот, кстати, это мое смутное представление; нет стандартов того, как это должно быть сделано. Обычный протокол настройки потока работать не будет; это слишком дорого. Но заголовок обхода брандмауэра может сделать эту работу.
Как видите, IPv6 может оказать серьезное влияние на брандмауэры, особенно в отношении фильтрации пакетов. Как эта книга пишется, но еще слишком рано говорить, что это за эффекты будут, и когда мы начнем их ощущать.
Имейте в виду, что IPv6 не будет развернут с ночевкой.IPv4 будет существовать долгое время, и многие сайты будут продолжать использовать его в обозримом будущем. В Разработчики IPv6 очень чувствительны к переходу проблем, и этой области уделяется много внимания, и сайты могут использовать различные стратегии миграции.
6.3.7 Протоколы не-IP
Другие протоколы того же уровня, что и IP, например, AppleTalk и IPX предоставляют аналогичные виды информация как IP, хотя заголовки и операции для этих протоколов и, следовательно, их фильтрация пакетов характеристики, различаются в корне.Большинство реализаций фильтрации пакетов поддерживать только фильтрацию IP и просто отбросить не-IP-пакеты. Некоторые пакеты предоставляют ограниченное поддержка фильтрации пакетов для не-IP протоколов, но эта поддержка обычно гораздо менее гибкая и способная, чем возможность IP-фильтрации маршрутизатора.
В настоящее время фильтрация пакетов как инструмент не так популярна и хорошо разработан для протоколов не-IP, предположительно потому, что эти протоколы редко используются для связи вне единого организация через Интернет.(Интернет по определению сеть IP сетей). Без IP протоколы представляют собой большую проблему для межсетевых экранов, которые являются внутренними для организации, и для этого приложения вы захотите выбрать одну пакетов, поддерживающих фильтрацию не по IP.
В Интернете обрабатываются не-IP протоколы инкапсулируя их в IP-протоколы. В большинстве случаях вы будете ограничены разрешением или отказом в инкапсулированном протоколы в целом; ты можешь принять все Соединения Appletalk-in-UDP или отклонить их на все.Несколько пакетов, поддерживающих протоколы, отличные от IP. может распознавать эти соединения при инкапсуляции и фильтровать по полям в них.
Что такое TCP и UDP? Простое объяснение
Быстрая и полная передача ваших данных зависит от используемых вами сетевых протоколов, UDP или TCP. Они оба выполняют одну и ту же работу, но по-разному. Один надежнее, а другой быстрее. Узнайте, какой из них вам нужен, ниже.
Определение TCP и UDP
TCP (протокол управления передачей) и UDP (протокол пользовательских дейтаграмм) — это сетевые протоколы, которые передают ваши данные через Интернет с вашего устройства на веб-сервер.Вы используете один из этих протоколов, когда общаетесь с друзьями в Skype, отправляете электронные письма, смотрите онлайн-видео или просто просматриваете веб-страницы.
И UDP, и TCP разделяют ваши данные на более мелкие блоки, называемые пакетами данных. К ним относятся IP-адреса отправителя и получателя, различные конфигурации, фактические данные, которые вы отправляете, и конечный элемент — данные, указывающие на конец пакета. Единственное различие между этими двумя протоколами — способ перемещения пакетов данных. Давайте углубимся в это более подробно.
Как работают TCP и UDP
TCP — это наиболее часто используемый протокол в Интернете, поскольку он считается более надежным. Вот что он делает для отправки ваших данных:
TCP присваивает каждому пакету данных уникальный идентификатор и порядковый номер. Это позволяет получателю определить, какой пакет был получен, а какой прибывает следующим.
Как только пакет данных получен, и если он находится в правильном порядке, получатель отправляет подтверждение отправителю.
Отправитель теперь может отправить другой пакет.
Если пакет потерян или отправлен в неправильном порядке, получатель молчит, указывая на то, что тот же пакет данных необходимо отправить повторно.
Поскольку данные отправляются последовательно, это помогает с перегрузкой данных и управлением потоком, а также упрощает обнаружение и исправление любых ошибок. Это также означает, что данные, отправленные по TCP, с большей вероятностью дойдут до места назначения полностью. Однако у него есть обратная сторона. Между двумя сторонами происходит много обмена данными, поэтому для установления соединения и обмена данными требуется больше времени.
UDP выполняет ту же работу без необходимости использования уникальных идентификаторов или порядковых номеров. Он отправляет данные в потоке и имеет только контрольную сумму, чтобы гарантировать, что данные прибыли неповрежденными. UDP почти не имеет исправления ошибок и не заботится о потерянных пакетах. Он более подвержен ошибкам, но отправляет данные намного быстрее, чем TCP.
Безопасен ли протокол UDP? Практически невозможно настроить брандмауэр, разрешающий только некоторые UDP-соединения и блокирующий остальные. Однако, хотя TCP намного проще защитить, UDP-соединения не остаются полностью незащищенными.Пользователи могут использовать прокси для определенных приложений или установить туннельное соединение между удаленным пользователем и внутренней сетью компании.
В чем основное различие между TCP и UDP?
У каждого протокола есть свои сильные и слабые стороны. Один из них намного быстрее, другой безопаснее и т. Д. Вот как они сравниваются бок о бок:
TCP UDP
Надежность Высокая Нижний
Скорость Нижний Высокая
Способ передачи Пакеты доставляются в последовательности Пакеты доставляются потоком
Обнаружение и исправление ошибок Есть №
Контроль перегрузки Есть №
Благодарность Есть Только контрольная сумма
Итак, что лучше — UDP или TCP? Как и во всех подобных случаях, все зависит от того, для чего вы их используете.Если вам нужна быстрая и постоянная передача данных для правильной работы приложения, вам придется использовать UDP. В остальном TCP является стабильным и надежным протоколом для передачи данных и не теряет их в процессе.
OpenVPN: TCP против UDP
Совместимы ли протоколы UDP и TCP со службами VPN? Да. Оба они работают с OpenVPN, протоколом VPN с открытым исходным кодом, который используется многими ведущими поставщиками VPN, включая NordVPN. OpenVPN работает на обоих сетевых протоколах, и оба они обеспечивают конфиденциальность и безопасность.Какой из них выбрать, зависит от того, для чего вы используете VPN. TCP более надежен, поэтому вы можете подумать, что TCP — лучший вариант, но бывают случаи, когда UDP может быть предпочтительнее.
UDP — отличный вариант, если вы играете, транслируете потоковое видео или пользуетесь услугами VoIP. Это может привести к потере одного или двух пакетов, но это не окажет большого влияния на ваше соединение в целом. Использование TCP для таких служб может вызвать задержку (особенно если вы подключены к серверам на другом конце света), что может полностью испортить вам работу.Поэтому OpenVPN через TCP рекомендуется для статического использования, такого как электронная почта, просмотр веб-страниц и передача файлов.

Какой протокол использует NordVPN?
NordVPN хочет обеспечить лучший опыт просмотра без ущерба для скорости, поэтому по умолчанию мы используем протокол UDP. Мы рекомендуем сначала попробовать протокол UDP и переключаться на TCP только в случае возникновения каких-либо проблем.
Чтобы изменить UDP на TCP на NordVPN (для пользователей Windows):
Перейти к настройкам , щелкнув значок шестеренки в правом верхнем углу;
Выберите Advanced в меню слева;
В разделе Протокол выберите TCP.
Чтобы изменить UDP на TCP на NordVPN (для пользователей MacOS):
Откройте панель настроек , нажав кнопку ползунка в верхнем левом углу или найдя NordVPN в строке меню и выбрав Настройки (горячая клавиша по умолчанию: Cmd +,).
Соединение: Предпочитать UDP вместо TCP. будет включен по умолчанию. Установите флажок, чтобы отключить его.
Если ваша скорость упала, вы также можете попробовать несколько уловок для увеличения скорости VPN.
Для получения дополнительных советов по кибербезопасности подпишитесь на нашу бесплатную ежемесячную рассылку новостей ниже!
Принцип надежной передачи данных
Принцип надежной передачи данных В этом разделе мы рассмотрим проблему надежной передачи данных в общий контекст. Это уместно, поскольку проблема реализации надежная передача данных происходит не только на транспортном уровне, но и на канальном уровне и на уровне приложений. Общая проблема поэтому имеет центральное значение для сетей.Действительно, если бы нужно было идентифицировать список « топ-10 » принципиально важных проблем во всем нетворкинге, это был бы лучший кандидат на возглавление этого списка. В следующем разделе мы исследует TCP и покажет, в частности, что TCP использует многие из принципы, которые мы собираемся описать.
Рисунок 3.4-1: Надежная передача данных: сервисная модель и реализация услуги.
Рис. 3.4-1 иллюстрирует структуру нашего исследования надежных данных. передача. Абстракция службы , предоставляемая объектам верхнего уровня это надежный канал, по которому могут передаваться данные.С надежный канал, биты передаваемых данных не повреждены (переключается с От 0 до 1 или наоборот) или потеряны, и все доставляются в том порядке, в котором они были отправлены. Именно такую модель обслуживания предлагает TCP. к Интернет-приложениям, которые его вызывают.
Ответственность за протокол надежной передачи данных на номер реализовать эту абстракцию службы . Эта задача затрудняется тем, что слой ниже надежные данные протокол передачи может быть ненадежным.Например, TCP — надежный протокол передачи данных, реализованный поверх ненадежного (IP) конечный сетевой уровень. В более общем смысле, слой под двумя конечные точки с надежной связью могут состоять из одного физического канала (например, как в случае протокола передачи данных на уровне канала) или глобальный межсетевое взаимодействие (например, как в случае протокола транспортного уровня). За в наших целях, однако, мы можем рассматривать этот нижний уровень просто как ненадежный двухточечный канал.
В этом разделе мы будем постепенно развивать отправителя и получателя. стороны надежного протокола передачи данных, учитывая все более сложные модели нижележащего канала.Рисунок 3.4-1 (b) иллюстрирует интерфейсы. для нашего протокола передачи данных. Отправляющая сторона протокола передачи данных будет вызван сверху вызовом rdt_send (). Это будет передал данные для доставки на верхний уровень на принимающей стороне. (Здесь rdt означает « r eliable d ata t ransfer » протокол и _send указывают, что отправляющая сторона rdt называется. Первым шагом в разработке любого протокола является выбор хорошее имя!) На принимающей стороне будет вызываться rdt_rcv () когда пакет приходит с принимающей стороны канала.Когда rdt протокол хочет доставить данные на верхний уровень, он сделает это вызов delivery_data () . Далее мы используем терминологию «пакет», а не «сегмент» для блока данных протокола. теория, развитая в этом разделе, применима к компьютерным сетям в целом, и не только на транспортном уровне Интернета, общий термин «пакет» возможно, здесь более уместно.
В этом разделе мы рассматриваем только случай однонаправленных данных передача, т.е.е., передача данных от отправляющей к принимающей стороне. Дело надежной двунаправленной (т. е. полнодуплексной) передачи данных концептуально не сложнее, но значительно утомительнее. Хотя мы рассматриваем только однонаправленная передача данных, важно отметить, что отправка и получающие стороны нашего протокола, тем не менее, должны будут передавать пакеты в в обоих направлениях , как показано на Рисунке 3.4-1. Мы скоро увидим что в дополнение к обмену пакетами, содержащими передаваемые данные, отправляющая и получающая стороны rdt также должны будут обмениваться пакеты управления вперед и назад.И отправляющая, и получающая стороны rdt отправлять пакеты на другую сторону с помощью вызова udt_send () ( или nreliable d ата т (перевод )).
3.4.1 Создание надежного протокола передачи данных
Надежная передача данных по абсолютно надежному каналу: rdt1.0 Сначала рассмотрим простейший случай, когда основной канал полностью надежный. Сам протокол, который мы назовем rdt1.0, тривиально. Определения конечного автомата (FSM) для rdt1.0 отправитель и приемник показаны на Рисунке 3.4-2. Отправитель и получатель Каждый автомат на рис. 3.4-2 имеет только одно состояние. Стрелки в Описание конечного автомата указывает на переход протокола из одного состояния другому. (Поскольку каждый автомат на рис. 3.4-2 имеет только одно состояние, переход обязательно из одного состояния обратно в себя; посмотрим посложнее диаграммы состояний вкратце.). Отображается событие, вызвавшее переход над горизонтальной линией, обозначающей переход, и предпринятые действия когда событие происходит, отображаются под горизонтальной линией.
Отправляющая сторона rdt просто принимает данные от верхнего уровня через событие rdt_send (data) помещает данные в пакет (через действие make_pkt (пакет, данные)) и отправляет пакет в канал. На практике событие rdt_send (data) будет результатом вызов процедуры (например, rdt_send ()) приложением верхнего уровня.
На принимающей стороне rdt получает пакет от нижележащего канал через событие rdt_rcv (пакет), удаляет данные из пакет (через экстракт действия (пакет, данные)) и передает данные до верхнего слоя.На практике событие rdt_rcv (пакет) будет результат вызова процедуры (например, в rdt_rcv ()) из нижнего протокол уровня.
В этом простом протоколе нет разницы между единицей данных и пакет. Кроме того, весь поток пакетов идет от отправителя к получателю — с совершенно надежный канал, нет необходимости в приемной стороне предоставить отправителю обратную связь, так как ничего не может пойти не так!

Рисунок 3.4-2: rdt1.0 — протокол для полностью надежный канал
Надежная передача данных по каналу с битовыми ошибками: rdt2.0 Более реалистичной моделью нижележащего канала является та, в которой биты в пакете могут быть повреждены. Такие битовые ошибки обычно возникают в физические компоненты сети, когда пакет передается, распространяется, или находится в буфере. Мы продолжим пока предполагать, что все переданные пакеты принимаются (хотя их биты могут быть повреждены) в порядке в котором они были отправлены.
Перед разработкой протокола для надежной связи по такой канал, сначала подумайте, как люди могут справиться с такой ситуацией.Учитывать как вы сами можете продиктовать длинное сообщение по телефону. В типичном сценария, получатель сообщения может сказать « ОК » после каждого предложения услышал, понял и записал. Если получатель сообщения слышит искаженное предложение, вас просят повторить искаженное предложение. Это протокол диктовки сообщений использует как положительных подтверждений (« ОК »), так и отрицательных подтверждений (« Пожалуйста, повторите это »). Эти управляющие сообщения позволяют получателю сообщить отправителю, что получено правильно, а что — получен по ошибке и поэтому требует повторения.В настройках компьютерной сети известны надежные протоколы передачи данных, основанные на такой ретрансляции. Протоколы ARQ (автоматический запрос на повторение).
По сути, требуются две дополнительные возможности протокола в Протоколы ARQ для обработки наличия битовых ошибок:
Обнаружение ошибки. Во-первых, необходим механизм, позволяющий приемнику чтобы обнаружить, когда произошли битовые ошибки. Напомним из разделов 3.3, что транспортный протокол UDP использует поле контрольной суммы Интернета точно для с этой целью.В главе 5 мы рассмотрим обнаружение и исправление ошибок. техники более подробно; Эти методы позволяют приемнику обнаруживать, и, возможно, исправить битовые ошибки пакета. На данный момент нам нужно только знать, что эти методы требуют, чтобы дополнительные биты (помимо битов исходных данных быть переданным) быть отправленным от отправителя к получателю; эти биты будут быть собраны в поле контрольной суммы пакета данных rdt2.0 пакет.
Приемник обратной связи. Поскольку отправитель и получатель обычно выполняют на разных конечных системах, возможно разделенных тысячами миль, единственный способ для отправителя узнать взгляд получателя на мир (в в этом случае, был ли пакет получен правильно) для получателя чтобы предоставить отправителю явную обратную связь.Положительный (ACK) и отрицательный ответы подтверждения (NAK) в сценарии диктовки сообщения являются пример такой обратной связи. Наш протокол rdt2.0 аналогичным образом отправит Пакеты ACK и NAK возвращаются от получателя к отправителю. В принципе, эти пакеты должны быть длиной всего один бит, например, нулевое значение может указывать NAK и значение 1 могут указывать на ACK.
На рисунке 3.4-3 показано представление конечным автоматом rdt2.0 , . протокол передачи данных, использующий обнаружение ошибок, положительные подтверждения (ACK) и отрицательные подтверждения (NAK).
Передающая сторона rdt2.0 имеет два состояния. В одном состоянии отправляющая сторона протокол ожидает передачи данных с верхнего уровня. В в другом состоянии протокол отправителя ожидает пакета ACK или NAK от ресивера. Если получен пакет ACK (обозначение rdt_rcv (rcvpkt) && isACK (rcvpkt) на рисунке 3.4-3 соответствует этому событию), отправитель знает, что был получен последний переданный пакет правильно и, таким образом, протокол возвращается в состояние ожидания данных из верхнего слоя.Если получен NAK, протокол повторно передает последний пакет и ожидает ответа ACK или NAK от получателя в ответ на повторно переданный пакет данных. Важно отметить, что когда получатель находится в состоянии ожидания ACK-или-NAK, он может не получить больше данных с верхнего уровня; это произойдет только после того, как отправитель получает ACK и выходит из этого состояния. Таким образом, отправитель не отправит новый фрагмент данных, пока не будет уверен, что получатель правильно получил текущий пакет.Из-за такого поведения такие протоколы, как rdt2.0 находятся известные как протоколы с остановкой и ожиданием .
FSM на стороне приемника для rdt2.0 все еще находится в единственном состоянии. По прибытии пакета получатель отвечает либо ACK, либо NAK, в зависимости от от того, поврежден ли полученный пакет. На рисунке 3.4-3 нотация rdt_rcv (rcvpkt) && corrected (rcvpkt) соответствует к событию, когда пакет получен и оказался ошибочным.

Рисунок 3.4-3: rdt2.0 — протокол для канал с битовыми ошибками
Протокол rdt2.0 может выглядеть так, как будто он работает, но, к сожалению, фатальный недостаток. В частности, мы не учли возможность того, что пакет ACK или NAK может быть поврежден! (Прежде чем продолжить, вам следует подумайте, как решить эту проблему.) К сожалению, наша небольшая недосмотр не так безобидно, как может показаться. Как минимум, нам нужно будет добавить контрольную сумму биты в пакеты ACK / NAK для обнаружения таких ошибок. Тем труднее вопрос в том, как протокол должен восстанавливаться после ошибок в пакетах ACK или NAK.Сложность здесь в том, что если ACK или NAK повреждены, отправитель нет возможности узнать, правильно ли получатель получил последний фрагмент переданных данных.
Рассмотрим три возможности обработки поврежденных ACK или NAK:
В первую очередь подумайте, что человек может сделать в сообщении. сценарий диктанта. Если говорящий не понял « ОК » или « Пожалуйста, повторить это » ответ получателя, говорящий, вероятно, спросит: « Что вы сказали? » (таким образом, вводя новый тип пакета отправитель-получатель к нашему протоколу).Затем говорящий повторял ответ. Но что, если « Что ты сказал » говорящего поврежден? Приемник, не имеющий представление о том, было ли искаженное предложение частью диктовки или просьбы чтобы повторить последний ответ, вероятно, тогда ответит: « Что вы сказать? » И тогда, конечно, этот ответ может быть искажен. Ясно, что мы направляясь по трудному пути.
Вторая альтернатива — добавить достаточно битов контрольной суммы, чтобы отправитель мог не только обнаруживать, но и исправлять битовые ошибки.Это решает немедленную проблема для канала, который может повреждать пакеты, но не терять их.
Третий подход заключается в том, что отправитель просто повторно отправляет текущий пакет данных. когда он получает искаженный пакет ACK или NAK. Однако это вводит дубликат пакеты в канал отправитель-получатель. Основная трудность с повторяющимися пакетами заключается в том, что получатель не знает, есть ли ACK или последний отправленный NAK был получен отправителем правильно. Таким образом, он может не знаю априори , содержит ли приходящий пакет новые данные или это ретрансляция!
Простое решение этой новой проблемы (принятое почти во всех существующих протоколы передачи данных, включая TCP) заключается в добавлении нового поля к данным пакет и попросите отправителя пронумеровать свои пакеты данных, поместив последовательность номер в это поле.Затем приемнику нужно только проверить эту последовательность число, чтобы определить, является ли полученный пакет повторной передачей. Для этого простого случая протокола остановки и ожидания 1-битный порядковый номер будет достаточно, так как это позволит получателю узнать, был ли отправитель повторно отправляет ранее переданный пакет (порядковый номер полученный пакет имеет тот же порядковый номер, что и последний полученный пакет) или новый пакет (порядковый номер меняется, т.е. перемещается « вперед » в арифметике по модулю 2).Поскольку в настоящее время мы предполагаем, что канал не теряет пакеты, пакеты ACK и NAK сами по себе не должны указывать порядковый номер пакета, который они принимают ACKing или NAK, поскольку отправитель знает, что полученный пакет ACK или NAK (искаженный или нет) был сгенерирован в ответ на последний переданный пакет данных.
Рисунок 3.4-4: Отправитель rdt2.1

Рисунок 3.4-5: приемник rdt2.1
На рисунках 3.4-4 и 3.4-5 показано описание конечного автомата для rdt2.1 , наша исправленная версия rdt2.0 . Отправитель rdt2.1 каждый конечный автомат и приемник теперь имеют в два раза больше состояний, чем раньше. Это потому что состояние протокола теперь должно отражать, отправленные (отправителем) или ожидаемые (получателем) должны иметь порядковый номер 0 или 1. Обратите внимание, что действия в тех состояниях, где отправленный или ожидаемый пакет с нулевым номером является зеркальным отображением тех когда отправляется или ожидается пакет с 1 номером; единственные различия связаны с обработкой порядкового номера.
Протокол rdt2.1 использует как положительные, так и отрицательные подтверждения от получатель отправителю. Отрицательное подтверждение отправляется всякий раз, когда получен поврежденный пакет или пакет, вышедший из строя. Мы можем достигают того же эффекта, что и NAK, если вместо отправки NAK мы отправить ACK для последнего правильно полученного пакета. Отправитель, получающий два ACK для одного и того же пакета (т.е. получает дублирующих ACK ) знает что получатель неправильно получил пакет, следующий за пакетом это подтверждается дважды.Многие реализации TCP используют квитанцию так называемых «тройных дубликатов ACK» (три пакета ACK, все ACK тот же пакет), чтобы инициировать повторную передачу отправителю. Наш без НАК надежный протокол передачи данных для канала с битовыми ошибками — rdt2.2, показано на Рисунках 3.4-6 и 3.4-7.

Рисунок 3.4-6: Отправитель rdt2.2

Рисунок 3.4-7: Приемник rdt2.2
Надежная передача данных по каналу с потерями с битовыми ошибками: rdt3.0 Предположим теперь, что помимо искажающих битов, основной канал может также потерять пакетов, что не редкость для современных компьютеров сети (включая Интернет).Две дополнительные проблемы теперь должны быть адресуется протоколом: как обнаружить потерю пакетов и что делать, когда это происходит. Использование контрольных сумм, порядковых номеров, пакетов ACK и ретрансляции — методы, уже разработанные в rdt 2.2 — позволит нам ответить на последнее беспокойство. Решение первой проблемы потребует добавления нового механизма протокола.
Есть много возможных подходов к борьбе с потерей пакетов (еще несколько из них рассматриваются в упражнениях в конце глава).Здесь мы возложим бремя обнаружения и восстановления потерянных пакеты на отправителя. Предположим, что отправитель передает пакет данных и либо этот пакет, либо ACK получателя этого пакета теряются. В любом случае ответ от получателя не поступает. Если отправитель готов ждать достаточно долго, чтобы было наверняка что пакет был потерян, он может просто повторно передать пакет данных. Вы должны убедиться, что этот протокол действительно работает.
Но как долго отправитель должен ждать, чтобы убедиться, что что-то было потерял? Очевидно, что он должен ждать, по крайней мере, столько же, сколько задержка в оба конца между отправитель и получатель (что может включать буферизацию на промежуточных маршрутизаторах или шлюзы) плюс любое количество времени, необходимое для обработки пакета на приемнике.Во многих сетях максимальная задержка в худшем случае очень велика. трудно даже оценить, а тем более знать наверняка. Более того, в идеале протокол должен восстанавливаться после потери пакетов как можно скорее; ожидающий в худшем случае задержка может означать долгое ожидание, пока не начнется восстановление после ошибки. Подход, принятый таким образом на практике, заключается в том, чтобы отправитель « разумно » выберите такое значение времени, чтобы потеря пакетов была вероятной, хотя и не гарантированной, должно было случиться. Если ACK не получен в течение этого времени, пакет передается повторно.Обратите внимание, что если пакет испытывает особенно большой задержка, отправитель может повторно передать пакет, даже если данные пакет и его ACK не были потеряны. Это вводит возможность дублирования пакеты данных в канале отправитель-получатель. К счастью, протокол rdt2.2 уже имеет достаточную функциональность (т.е. порядковые номера) для обработки случай дублирования пакетов.
С точки зрения отправителя ретрансляция — это панацея. Отправитель не знает, был ли потерян пакет данных, был потерян ACK или пакет или ACK просто слишком задержаны.Во всех случаях действие то же: ретранслировать. Чтобы реализовать механизм повременной ретрансляции, потребуется таймер обратного отсчета , который может прервать отправителя после заданное количество таймера истекло. Таким образом, отправитель должен иметь возможность на (i) запускает таймер каждый раз, когда пакет (либо первый пакет, или повторная передача), (ii) отвечает на прерывание таймера (предпринимая соответствующие действия) и (iii) остановите таймер.
Наличие сгенерированных отправителем повторяющихся пакетов и пакетов (данных, ACK) также усложняет обработку отправителем любого пакета ACK. он получает. Если ACK получен, как отправителю узнать, был ли он отправлено получателем в ответ на его (отправителя) последний переданный пакет, или это отложенный ACK, отправленный в ответ на более раннюю передачу другого пакета данных? Решение этой дилеммы — увеличить пакет ACK с полем подтверждения . Когда ресивер генерирует ACK, он копирует порядковый номер пакета данных, который Подтверждено в это поле подтверждения. Изучив содержание поля подтверждения отправитель может определить порядковый номер о получении положительного подтверждения пакета.

Рисунок 3. 4-8: FSM отправителя rdt 3.0
Рисунок 3.4-9: Работа rdt 3.0, переменный битовый протокол
На рис. 3.4-8 показан конечный автомат отправителя для rdt3.0 , протокол, который надежно передает данные по каналу, который может повредить или потеряете пакеты. На рис. 3.4-9 показано, как протокол работает с нет потерянных или задержанных пакетов, и как он обрабатывает потерянные пакеты данных. На рисунке 3.4-9, время движется вперед от верха диаграммы к низу схемы; обратите внимание, что время получения пакета обязательно позже чем время отправки пакета в результате передачи и распространения задержки. На рисунках 3.4-9 (b) — (d) скобки на стороне отправки указывают время, в которое установлен таймер, и более позднее время ожидания.Некоторые из более тонкие аспекты этого протокола исследуются в упражнениях в конце этой главы. Поскольку порядковые номера пакетов меняются от 0 до 1 протокол rdt3.0 иногда называют чередующимся битом протокол.
Мы собрали ключевые элементы протокола передачи данных. Контрольные суммы, порядковые номера, таймеры, а также положительное и отрицательное подтверждение каждый из пакетов играет важную и необходимую роль в работе протокол. Теперь у нас есть работающий надежный протокол передачи данных!
3.4.2 Конвейерные протоколы надежной передачи данных
Протокол rdt3.0 — функционально правильный протокол, но он вряд ли кто-то будет доволен его производительностью, особенно в современных высокоскоростных сетях. В основе производительности rdt3.0 Проблема в том, что это протокол остановки и ожидания.
Чтобы оценить влияние этой остановки и ожидания на производительность, рассмотрим идеализированный случай двух конечных хостов, один из которых расположен на западном побережье США, а другой находится на восточном побережье.Скорость света задержка распространения, T _prop , между этими двумя конечными системами составляет примерно 15 миллисекунд. Предположим, что они связаны канал с емкостью, С, 1 Гигабит (10 ** 9 бит) в секунду. При размере пакета SP 1 Кбайт на пакет, включая оба заголовка. полей и данных, время, необходимое для фактической передачи пакета в Ссылка 1 Гбит / с
T _trans = SP / C = (8 Кбит / пакет) / (10 ** 9 бит / сек) = 8 микросекунд
С нашим протоколом остановки и ожидания, если отправитель начинает отправку пакета при t = 0, затем при t = 8 микросекунд последний бит входит в канал на стороне отправителя.Затем пакет проходит 15 мс по пересеченной местности. путешествие, как показано на рисунке 3.4-10a, с последним битом пакета выходящий на приемник при t = 15.008 мсек. Предполагая для простоты что пакеты ACK того же размера, что и пакеты данных, и что получатель может начать отправку пакета ACK, как только последний бит пакета данных получен, последний бит пакета ACK возвращается получателю при t = 30,016 мсек. Таким образом, за 30,016 мс отправитель был только занят. (отправка или получение) для.016 мсек. Если мы определим использование отправителя (или канала) как долю времени, в течение которого отправитель фактически занят отправкой битов в канал, у нас довольно мрачная загрузка отправителя, У _{отправитель} , из
U _{отправитель} = (.008 / 30.016) = 0,00015
То есть отправитель был занят лишь 1,5 сотых процента от время. С другой стороны, отправитель мог отправить только 1 Кбайт в 30,016 миллисекунды, эффективная пропускная способность всего 33 КБ / сек — даже если подумать была доступна ссылка 1 Гигабит в секунду! Представьте себе несчастного сетевого администратора кто только что заплатил целое состояние за гигабитный канал связи, но сумел получить пропускная способность всего 33КБ! Это наглядный пример того, как сетевые протоколы может ограничивать возможности, предоставляемые базовым сетевым оборудованием.Кроме того, мы пренебрегли временем обработки протокола нижнего уровня на отправителе. и получателя, а также задержки обработки и постановки в очередь, которые могут происходят на любых промежуточных маршрутизаторах между отправителем и получателем. Включая эти эффекты будут служить только для дальнейшего увеличения задержки и дальнейшего подчеркнут низкую производительность.

Рисунок 3.4-10: Стоп-энд-ожидание в сравнении с конвейерными протоколами
Решение этой конкретной проблемы с производительностью простое: вместо того, чтобы действовать в режиме ожидания и остановки, отправителю разрешается отправлять несколько пакетов, не дожидаясь подтверждений, как показано на Рисунок 3.4-10 (б). Поскольку множество пакетов в пути от отправителя к получателю может быть визуализирован как заполнение трубопровода, этот метод известен как конвейерная обработка . Конвейерная обработка имеет несколько последствий для надежных протоколов передачи данных:
Диапазон порядковых номеров должен быть увеличен, так как каждый транзитный пакет (не считая повторных передач) должен иметь уникальный порядковый номер и может быть несколько транзитных неподтвержденных пакетов.
На стороне отправителя и получателя протоколов может потребоваться больше буферизации. чем один пакет.Как минимум, отправитель должен буферизовать пакеты, которые были переданы, но еще не подтверждены. Буферизация правильно полученных пакеты также могут потребоваться на приемнике, как обсуждается ниже.
Диапазон необходимых порядковых номеров и требования к буферизации будут зависят от того, как протокол передачи данных реагирует на потерю, поврежденные и слишком задержанные пакеты. Два основных подхода к конвейеру исправление ошибок может быть идентифицировано: Go-Back-N и выборочный повтор.
3.4.3 Go-Back-N (GBN)
Рисунок 3.4-11: Просмотр порядковых номеров отправителем в Go-Back-N
В протоколе Go-Back-N (GBN) отправителю разрешено передавать несколько пакетов (при наличии) без ожидания подтверждения, но ограничено иметь не более некоторого максимально допустимого числа, N , неподтвержденных пакетов в конвейере. На рис. 3.4-11 показан адрес отправителя. просмотр диапазона порядковых номеров в протоколе GBN.Если мы определим основание быть порядковым номером самого старого неподтвержденного пакета и nextseqnum — наименьший неиспользуемый порядковый номер (т. Е. порядковый номер следующего пакета для отправки), затем четыре интервала в можно определить диапазон порядковых номеров. Порядковые номера в интервал [0, base-1] соответствует пакетам, которые уже были передано и подтверждено. Интервал [base, nextseqnum-1] соответствует пакетам, которые были отправлены, но еще не подтверждены.Порядковые номера в интервале [nextseqnum, base + N-1] может использоваться для пакетов, которые могут быть отправлены немедленно, если данные поступят с верхнего уровня. Ну наконец то, порядковые номера больше или равные base + N не могут использоваться пока не будет подтвержден неподтвержденный пакет, находящийся в конвейере.
Как показано на Рисунке 3.4-11, диапазон допустимых порядковых номеров для переданных, но еще не подтвержденных пакетов можно рассматривать как « окно » размером N в диапазоне порядковых номеров.Как протокол работает, это окно скользит вперед по пространству порядковых номеров. По этой причине, N часто упоминается как размер окна и сам протокол GBN как протокол скользящего окна . Вы можете спросить, почему даже ограничить количество выдающихся неподтвержденных пакетов до значения из N в первую очередь. Почему бы не разрешить неограниченное количество таких пакетов? В разделе 3.5 мы увидим, что управление потоком это одна из причин ограничить отправителя.Мы рассмотрим другой Причина для этого в разделе 3.7, когда мы изучаем управление перегрузкой TCP.
На практике порядковый номер пакета передается фиксированной длины. поле в заголовке пакета. Если k — количество битов в пакете поле порядкового номера, диапазон порядковых номеров составляет, таким образом, [0,2 ^k -1] . С конечным диапазоном порядковых номеров вся арифметика, включающая последовательность числа затем должны быть выполнены с использованием арифметики по модулю 2 ^k .(То есть, пространство порядковых номеров можно представить как кольцо размера 2 ^к, где за порядковым номером 2 ^k -1 сразу следует порядковый номер 0.) Напомним, что rtd3.0 имел 1-битный порядковый номер. и диапазон порядковых номеров [0,1] . Некоторые проблемы в конце этой главы исследуйте последствия конечного диапазона последовательности числа. В разделе 3.5 мы увидим, что TCP имеет 32-битную последовательность числовое поле, где порядковые номера TCP подсчитывают байты в потоке байтов а не пакеты.

Рисунок 3.4-12. Расширенное описание FSM отправителя GBN.

Рисунок 3.4-13. Расширенное описание FSM приемника GBN.
На рисунках 3.4-12 и 3.4-13 дано расширенное описание отправителя. и стороны-получатели протокола GBN на основе ACK без NAK. Мы ссылаемся на это описание конечного автомата как расширенного-FSM , поскольку мы добавили переменные (аналогично переменным языка программирования) для base и nextseqnum, а также добавлены операции с этими переменными и условные действия, включающие эти переменные.Обратите внимание, что спецификация расширенного FSM теперь начинается чтобы выглядеть как спецификация языка программирования. [Бохман 84] предоставляет отличный обзор дополнительных расширений методов конечных автоматов а также другие методы определения протоколов на основе языков программирования.
Отправитель GBN должен реагировать на три типа событий:
Призыв свыше. Когда rdt_send () вызывается сверху, отправитель сначала проверяет, заполнено ли окно, т.е.е., есть ли N ожидающих неподтвержденных пакетов. Если окно не заполнен, пакет создается и отправляется, а переменные соответствующим образом обновлено. Если окно заполнено, отправитель просто возвращает данные обратно на верхний уровень — неявное указание на то, что окно заполнено. В верхнему слою, вероятно, придется повторить попытку позже. В реальной реализации отправитель, скорее всего, либо буферизовал (но не сразу отправил) эти данные, или имел бы механизм синхронизации (например,г., семафор или флаг), который позволит верхнему уровню вызывать только rdt_send () когда окно не заполнено.
Получение ACK. В нашем протоколе GBN подтверждение пакета с порядковым номером n будет считаться совокупным подтверждением , указывает, что все пакеты с порядковым номером до включительно n были правильно получены получателем. Мы вернемся к об этом чуть позже, когда мы рассмотрим приемную сторону GBN.
Событие тайм-аута. Название протокола, Go-Back-N, является производным от поведения отправителя при наличии потерянных или чрезмерно задержанных пакетов. Как и в протоколе остановки и ожидания, для восстановления снова будет использоваться таймер. от потерянных данных или пакетов подтверждения. Если истекает тайм-аут, отправитель повторно отправляет все пакетов, которые были отправлены ранее, но которые еще не было подтверждено. Наш отправитель на Рисунке 3.4-12 использует только единственный таймер, который можно рассматривать как таймер для самых старых переданных, но еще не подтвержденных пакет.Если ACK получен, но есть еще переданные, но еще не подтвержденные пакетов, таймер перезапускается. Если нет невыполненных непризнанных пакетов, таймер остановлен.
Действия получателя в GBN также просты. Если пакет с последовательностью номер n получен правильно и в порядке (т. е. данные последние доставленный на верхний уровень пришел из пакета с порядковым номером n-1 ), приемник отправляет ACK для пакета n и доставляет часть данных пакета на верхний уровень.Во всех остальных случаях получатель сбрасывает пакет и повторно отправляет ACK для последнего полученного пакета. Обратите внимание, что, поскольку пакеты доставляются на верхний уровень по одному, если получен пакет k и доставлено, то все пакеты с порядковым номером ниже k имеют также был доставлен. Таким образом, использование кумулятивных подтверждений является естественный выбор для GBN.
В нашем протоколе GBN приемник отбрасывает неупорядоченные пакеты. Пока может показаться глупым и расточительным отказываться от правильно полученного (но вышедшего из строя) пакет, для этого есть какое-то оправдание.Напомним, что приемник должен доставлять данные по порядку на верхний уровень. Предположим теперь, что пакет n ожидается, но приходит пакет n + 1 . Поскольку данные должны быть доставлены для того, чтобы получатель мог буферизовать (сохранить) пакет п + 1 а затем доставить этот пакет на верхний уровень после того, как он позже получил и доставил пакет n. Однако, если пакет n потеряно, и он и пакет п + 1 будет в конечном итоге будет повторно передан в результате правила повторной передачи GBN у отправителя.Таким образом, получатель может просто отбросить пакет n + 1. Преимущество такого подхода — простота буферизации приемника. — приемнику не нужно буферизовать любых неупорядоченных пакетов. Таким образом, пока отправитель должен поддерживать верхнюю и нижнюю границы своего окна и позиция nextseqnum в этом окне, единственная информация приемник должен поддерживать порядковый номер следующего по порядку пакет. Это значение хранится в переменной expectedseqnum, показано в автомате приемника на рисунке 3.4-13. Конечно, недостаток метания правильно полученный пакет заключается в том, что последующая повторная передача этого пакета может быть потеряно или искажено и, следовательно, еще больше повторных передач потребуется.

Рисунок 3.4-14: Go-Back-N в работе
На рис. 3.4-14 показана работа протокола GBN для случая размер окна четыре пакета. Из-за этого ограничения размера окна отправитель отправляет пакеты с 0 по 3, но затем должен ждать одного или нескольких этих пакетов необходимо подтвердить перед продолжением.Поскольку каждый последующий ACK (например, ACK0 и ACK1) получен, окно сдвигается вперед и отправитель может передать один новый пакет (pkt4 и pkt5 соответственно). На на стороне получателя пакет 2 потерян и, таким образом, найдены пакеты 3, 4 и 5 быть вышедшими из строя и отбрасываются.
Прежде чем завершить обсуждение GBN, стоит отметить, что реализация этого протокола в стеке протоколов, вероятно, будет иметь аналогичную структуру с расширенным автоматом на рис. 3.4-12. Реализация будет также вероятно будут в виде различных процедур, реализующих действия должны быть приняты в ответ на различные события, которые могут произойти.В таком событийном программирование, различные процедуры вызываются (вызываются) либо другие процедуры в стеке протоколов или в результате прерывания. В отправителе этими событиями будут (i) вызов с верхнего уровня. объект для вызова rdt_send (), (ii) прерывание по таймеру и (iii) вызов из нижнего уровня для вызова rdt_rcv (), когда пакет прибывает. Упражнения по программированию в конце этой главы дадут у вас есть шанс реализовать эти процедуры в смоделированном, но реалистичном, настройка сети.
Здесь отметим, что протокол GBN включает в себя почти все методы что мы укажем при изучении надежных компонентов передачи данных протокола TCP в разделе 3.5: использование порядковых номеров, кумулятивных подтверждений, контрольные суммы и операция тайм-аута / повторной передачи. Действительно, TCP часто называется протоколом стиля GBN. Однако есть некоторые различия. Многие реализации TCP будут буферизовать правильно полученные но неупорядоченные сегменты [Stevens 1994]. Предлагаемая модификация TCP, так называемое выборочное подтверждение. [RFC 2018], также позволит получателю TCP выборочно подтверждать единичный неупорядоченный пакет, а не кумулятивно подтвердить последний правильно полученный пакет.Понятие избирательного подтверждение лежит в основе второго широкого класса конвейерных Протоколы: так называемые протоколы избирательного повтора.
3.4.4 Выборочный повтор (SR)
Протокол GBN позволяет отправителю потенциально « заполнить конвейер » на рис. 3.4-10 с пакетами, что позволяет избежать проблем с использованием канала. мы отметили с протоколами остановки и ожидания. Однако есть сценарии в который сам GBN будет страдать от проблем с производительностью. Особенно, когда размер окна и произведение задержки полосы пропускания большие, много пакетов может быть в стадии разработки.Таким образом, одиночная ошибка пакета может вызвать повторную передачу GBN. большое количество пакетов, многие из которых могут оказаться ненужными. Поскольку вероятность ошибок канала увеличивается, конвейер может заполниться этими ненужные повторные передачи. Представьте себе в нашем сценарии диктовки сообщений, если каждый раз слово было искажено, окружающие 1000 слов (например, окно размер 1000 слов) пришлось повторить. Диктовка будет замедлена все повторяющиеся слова.
Как следует из названия, протоколы избирательного повтора (SR) избегают ненужных повторных передач, когда отправитель повторно передает только те пакеты, которые он подозревает, что был получен по ошибке (т.е., были утеряны или повреждены) на приемник. Эта индивидуальная повторная передача по мере необходимости потребует, чтобы приемник индивидуально подтверждает правильно принятые пакеты. Размер окна N снова будет использоваться для ограничения количества невыполненных, неподтвержденные пакеты в конвейере. Однако, в отличие от GBN, отправитель уже получил ACK для некоторых пакетов в окне. На рис. 3.4-15 показано, как отправитель SR видит пространство порядковых номеров. На рис. 3.4-16 показаны различные действия, предпринимаемые отправителем SR.
Приемник SR подтвердит правильно полученный пакет, если или не в порядке. Неупорядоченные пакеты буферизуются до тех пор, пока не исчезнут какие-либо пакеты (т.е. пакеты с меньшими порядковыми номерами) принимаются, при этом точка, партия пакетов может быть доставлена по порядку на верхний уровень. На рисунке figsrreceiver перечислены различные действия, предпринимаемые приемником SR. На рис. 3.4-18 показан пример работы SR при наличии потерянного пакеты. Обратите внимание, что на рис. 3.4-18 получатель изначально буферизует пакеты. 3 и 4, и доставляет их вместе с пакетом 2 на верхний уровень при пакет 2 наконец получен.

Рисунок 3.4-15: Представления отправителя и получателя SR пространства порядковых номеров

Данные получены сверху. При получении данных сверху Отправитель SR проверяет следующий доступный порядковый номер для пакета. Если порядковый номер находится в окне отправителя, данные пакетируются и отправлено; в противном случае он либо буферизируется, либо возвращается на верхний уровень для последующей передачи, как в GBN.
Тайм-аут. Таймеры снова используются для защиты от потери пакетов. Однако теперь у каждого пакета должен быть свой логический таймер, поскольку только один пакет будет передан по таймауту. Единый аппаратный таймер может использоваться для имитации работы нескольких логических таймеров.
Получено ACK. Если получен ACK, отправитель SR отмечает этот пакет. как полученный, при условии, что он находится в окне. Если пакет порядковый номер равен sendbase , база окна перешел к неподтвержденному пакету с наименьшим порядковым номером.Если окно перемещается и есть непереданные пакеты с порядковыми номерами которые теперь попадают в окно, эти пакеты передаются.
Рисунок 3.4-16: Действия отправителя выборочного повтора

Пакет с порядковым номером в [ rcvbase, rcvbase + N-1 ] правильно получила. В этом случае полученный пакет попадает в приемники окно и выборочный пакет ACK возвращается отправителю.Если пакет не был получен ранее, он помещается в буфер. Если этот пакет имеет последовательность число, равное основанию окна приема ( rcvbase в Рис. 3.4-15), затем этот пакет и все ранее буферизованные и последовательно пронумерованных (начиная с rcvbase) пакетов доставляются на верхний слой. Затем окно приема перемещается вперед на количество пакетов. доставляется на верхний уровень. В качестве примера рассмотрим Рисунок 3.4-18. Когда получен пакет с порядковым номером rcvbase = 2 , он и пакеты rcvbase + 1 и rcvbase + 2 могут быть доставлены в верхний слой.
Получен пакет с порядковым номером в [ rcvbase-N, rcvbase-1 ]. В этом случае должен быть сгенерирован ACK, даже если это пакет, который получатель ранее подтвердил.
В противном случае. Игнорировать пакет.
Рисунок 3.4-17: Действия приемника выборочного повтора
Важно отметить, что на шаге 2 на рис. 3.4-17 получатель повторно подтверждает (а не игнорирует) уже полученные пакеты с определенными порядковыми номерами ниже текущая основа окна.Вы должны убедить себя, что это повторное признание действительно необходимо. Учитывая пробелы порядковых номеров отправителя и получателя на рисунке 3.4-15 например, если нет ACK для пакета sendbase распространяясь от получателя к отправителю, отправитель в конечном итоге повторно передать пакет sendbase, даже если он понятен (нам, а не отправитель!), что получатель уже получил этот пакет. Если получатель не должен подтверждать этот пакет, окно отправителя никогда не сдвинется вперед! Этот пример иллюстрирует важный аспект протоколов SR (и многие другие протоколы): отправитель и получатель не всегда иметь одинаковое представление о том, что было получено правильно и что нет.Для протоколов SR это означает, что окна отправителя и получателя не всегда будет совпадать.
Рисунок 3.4-18: Операция SR

Рисунок 3.4-19: Дилемма приемника SR со слишком большими окнами: новое пакет или ретрансляция?
Отсутствует синхронизация окон отправителя и получателя. важные последствия, когда мы сталкиваемся с реальностью конечного диапазона порядковых номеров. Рассмотрим, что может случиться, например, с конечным диапазон из четырех порядковых номеров пакетов, 0,1,2,3 и размер окна три.Предположим, что пакеты с 0 по 2 передаются и принимаются правильно, и подтвержден получателем. На этом окно приемника закрыто. четвертый, пятый и шестой пакеты с порядковыми номерами 3, 0, и 1 соответственно. Теперь рассмотрим два сценария. В первом сценарии как показано на рисунке 3.4-19 (a), ACK для первых трех пакетов теряются. и отправитель повторно передает эти пакеты. Таким образом, получатель затем получает пакет с порядковым номером 0 — копия первого отправленного пакета.
Во втором сценарии, показанном на Рисунке 3.4-19 (b), ACK для первые три пакета доставлены правильно. Отправитель движется свое окно вперед и отправляет четвертый, пятый и шестой пакеты с порядковые номера 3, 0, 1 соответственно. Пакет с порядковым номером 3 потеряно, но приходит пакет с порядковым номером 0 — пакет, содержащий новые данных.
Теперь рассмотрим точку зрения получателя на рис. 3.4-19, на которой образная шторка между отправителем и получателем, так как получатель не может « видеть » действия отправителя.Все получатель наблюдает это последовательность сообщений, которые он получает из канала и отправляет в канал. Что касается двух сценариев на Рисунке 3.4-19 идентичны. Нет возможности отличить ретрансляцию первого пакета из исходной передачи пятого пакета. Ясно, что размер окна на единицу меньше размера последовательности числовое пространство не работает. Но насколько маленьким должен быть размер окна? Проблема в конце главы просит вас показать, что размер окна должен быть меньше или равно половине размера пространства порядковых номеров.
Завершим обсуждение надежных протоколов передачи данных следующим: учитывая еще одно допущение в нашей базовой модели канала. Напомним, что мы предположили, что пакеты нельзя переупорядочить в течение канал между отправителем и получателем. Это вообще разумный предположение, когда отправитель и получатель связаны одним физическим провод. Однако, когда соединяющий их « канал » является сетью, пакет может произойти переупорядочивание. Одним из проявлений упорядочивания пакетов является старый копии пакета с порядковым номером или номером подтверждения x может появиться, даже если ни окно отправителя, ни окно получателя содержит х. С переупорядочиванием пакетов можно думать о канале как по существу буферизация пакетов и спонтанная передача этих пакетов на любой пункт в будущем. Поскольку порядковые номера могут использоваться повторно, необходимо принять меры для защиты от таких повторяющихся пакетов. Подход используется на практике, чтобы гарантировать, что порядковый номер не будет повторно использован до тех пор, пока отправитель относительно « уверен », чем любые ранее отправленные пакеты с порядковый номер x больше не в сети.Это делается предполагая, что пакет не может « жить » в сети дольше, чем некоторое фиксированное максимальное количество времени. Максимальное время жизни пакета приблизительно в расширениях TCP для высокоскоростных сетей предполагается три минуты [RFC 1323]. Саншайн [Саншайн 1978] описывает метод использования порядковых номеров, позволяющий переупорядочивать проблем можно полностью избежать.
Список литературы
[Бохман 84] Г.В. Бохманн и К.А. Саншайн, «Формальные методы в разработке протокола связи», IEEE Transactions. on Communicaitons , Vol.COM-28, No. 4, (апрель 1980 г.), стр. 624-631.
[RFC 1323] V. Якобсон, С. Брейден, Д. Борман, «Расширения TCP для высокой производительности», RFC 1323, май 1992 г.
[RFC 2018] М. Матис, Дж. Махдави, С. Флойд, А. Романов, «Параметры выборочного подтверждения TCP», RFC 2018, октябрь 1996 г.
[Стивенс 1994] W.R. Стивенс, TCP / IP Иллюстрированный, Том 1: Протоколы. Аддисон-Уэсли, Рединг, Массачусетс, 1994.
[Саншайн 1978] С. Саншайн и Ю.К. Далал, «Управление соединениями в транспортных протоколах», Компьютер Networks , Амстердам, Нидерланды: Северная Голландия «, 1978.
Авторские права 1999 г. Кейт В. Росс и Джеймс Ф. Куроз, Все права защищены.
Счетчик ACN
Счетчик ACN Дата : Пт, 22 августа 2003 г.
Лекция № 11 (Оценка TCP RTT, быстрая повторная передача, быстрое восстановление)
Автор: Рупеш Р. Мехта
Базовый Терминология
Время приема-передачи (RTT) определяется как время между отправкой пакетов и это получено.
Окно перегрузки (CWND) — ограничение на объем данных на стороне отправителя. передача по сети до получения ACK.
Таймаут повторной передачи (RTO) — это время, установленное для ACK конкретный пакет, который должен быть получен, по истечении этого времени пакет объявляется как утерян и передается повторно.
Duplicate ACK (DUP ACK) — это ACK, отправленный TCP на другой конец, сообщающий что сегмент мог быть потерян, и сообщая ему значение следующего ожидаемый порядковый номер.
Порог медленного запуска (ssthresh) — параметр (или значение), используемый в управление передачей данных.

При оценке времени туда и обратно сглаженный RTT задается как следующее:
SRTT = альфа * SRTT + (1-альфа) * RTT_i
В этом расчете значение альфы выбрано равным 7/8, так как присвоение низкого значения дает акцент на недавнем RTT, поэтому внезапные всплески значения RTT могут повлиять на SRTT.Сохранение более высокого значения подчеркивает старое значение SRTT и, следовательно, внезапные всплески не повлияет на значение SRTT очень эффективно.
Первоначально значение RTO предлагается как: RTO = beta * SRTT. Но возникла проблема с выбором бета-версии, меньшая ценность бета дает около 50% неверной оценки того, что пакет был потерян а высокое значение беты заставляет долго ждать потерянных пакетов. так, RTO = SRTT + 4 * RTT_var
принимается за значение RTO.
RTO Backoff — это метод, который продолжает увеличивать значение RTO. экспоненциально всякий раз, когда есть ретрансляция, но ограничивается несколькими минут.
RTT выборка Неоднозначность — это проблема, возникающая из-за того, как отбираются образцы для расчет среднего: TCP не может различить два отдельные подтверждения для одного и того же порядкового номера. Поэтому мы есть следующая проблема:
Тайм-аут происходит до получения ACK, и PKT1 передается повторно.ACK для первого PKT1 приходит немного позже, и источник измеряет неправильное значение RTT.
инжир. RTT это считается разницей между последней ретрансляцией и ACK получен за исходный пакет.
Таким образом, используя исходную передачу для RTT измерения, вызывает завышенную оценку, в то время как недавняя повторная передача для измерения RTT вызывает заниженную оценку и при этом дает очень негативный эффект.(Поскольку меньшее RTT имеет тенденцию к уменьшению RTO что дополнительно приводит к оценке потери пакета, даже если пакет не потерян и, таким образом, вызывает повторную передачу.)
Игнорирование выборки RTT также приводит к проблеме непрерывных повторная передача (причина указана ниже), поскольку RTT изменяется из-за нескольких такие причины, как перегрузка в сети, изменение маршрута в зависимости от какая-то политика.
Правило 1: игнорировать измеренный RTT для повторно переданных пакетов.
Этот устраняет двусмысленность измерений RTT.
Правило 2: RTO следует удвоить после повторной передачи.
Это называется «Экспоненциальный откат».
Почему правило 2 необходимо?
Когда RTO меньше реального RTT ..
Если применяется только Правило 1, TCP будет использовать предыдущее RTO. навсегда. Таким образом, все пакеты будут переданы повторно.
Нет измерений RTT бывает.
Использование отметки времени для устранения неоднозначности также является хорошим решением. В качестве другой конец скопирует значение из подтверждаемого сегмента и положить его в ACK и отправить обратно отправителю, тогда легко рассчитать RTO.Но эта схема предполагает накладные расходы (т.е. не может сжимать заголовок).

БЫСТРЫЙ ПЕРЕДАЧА / БЫСТРОЕ ВОССТАНОВЛЕНИЕ:
Быстро Передача инфекции : Когда TCP обнаруживает потерю сегмента с помощью таймера повторной передачи, тогда ssthresh устанавливается на половина CWND. то есть (ssthresh = CWND / 2) и CWND установлен 1-полноразмерный сегмент.Теперь вместо того, чтобы ждать таймер повторной передачи, чтобы выйти, TCP обнаруживает потерю пакета, ища переупорядочивание пакетов и повторная передача потерянного пакета. Эта схема называется как «Быстрая ретрансляция». В этом алгоритме Получатель TCP немедленно отправляет дублированный ACK на неупорядоченный сегмент пребытие. Другой конец TCP выводит из небольшого числа (обычно 3) последовательных повторяющихся ACK, что сегмент был потерян, и выводит начальный порядковый номер отсутствующего сегмента. Отсутствующий сегмент передано повторно.
Быстро Восстановление : Этот алгоритм говорит, что после быстрой повторной передачи Алго. (т.е. после повторной передачи отсутствующего сегмента), Выполняется предотвращение перегрузки, но не медленный старт. Это улучшение, обеспечивающее более высокую пропускную способность при умеренной перегрузке, особенно для большого окна.Этот алгоритм управляет передачей новые данные, пока не поступит свежий (новый) ACK.

Алгоритм работает следующим образом:
Если получен номер DUP-ACK = 3
ssthresh = CWND / 2;
Повторно передать потерянный сегмент;
CWND = sshthresh + 3; / * 3 для 3 DUP-ACK * /
За каждый следующий DUP-ACK
Увеличьте CWND на 1.
/ * т.е. CWND = CWND + 1. Это увеличивает CWND для отражения сегмента, вышедшего из сети * /
Если разрешено CWND и Окно объявления получателя
Передать сегмент (если любой….)
Если не DUP-ACK / * т.е. Новый / Свежий ACK * /
CWND = sshthresh / * Сдутие окна * /
Избежание перегрузки вызова Алгоритм
Перегрузка Избежание (CA):
Предположим, CWND отправителя = W.
No related posts.

	TCP	UDP
Надежность	Высокая	Нижний
Скорость	Нижний	Высокая
Способ передачи	Пакеты доставляются в последовательности	Пакеты доставляются потоком
Обнаружение и исправление ошибок	Есть	№
Контроль перегрузки	Есть	№
Благодарность	Есть	Только контрольная сумма

Как отличить оригинальный ПТС от дубликата?

что значит, стоит ли покупать машину с ним

Что такое ПТС, кто его выдает и зачем он нужен

Если ПТС — дубликат, что это значит?

Как понять, что вам предъявляют дубликат ПТС

Если ПТС — дубликат, стоит ли покупать машину?

Но если есть возможность, лучше поискать другую машину!

Множество владельцев

Кредитный автомобиль

Оригинал ПТС находится в ломбарде

Стоит ли брать машину с дубликатом ПТС

риски, что значит, стоит ли покупать

Почему дубликат

Как понять

Чем плох

Стоит ли покупать

Если возникла проблема

Что значит 25 ПТС — ответ на вопрос

На каких машинах встречается?

Положительные стороны

По какой причине появляется дубликат?

Истории автовладельцев

Заключение

Что значит 25 ПТС? Видео

Рекомендую прочитать:

Cтоит ли покупать машину у которой дубликат ПТС?

Понятие что такое дубликат документа

что значит и чего бояться, если покупать авто?

Основные характеристики дубликата

Как получить?

Отличия

Чем опасна купля без оригинального паспорта?

Как избежать мошенничества?

arduino — HTTP против TCP / IP, отправка данных на веб-сервер

Стек Интернет-протокола

Интернет-протокол (IP)

Протокол пользовательских дейтаграмм (UDP)

Протокол управления передачей (TCP)

Формат сегмента TCP

Надежная трансмиссия

Установление соединения

Протокол управления транзакционной передачей (T / TCP)

Неявное установление соединения

Connection Shotdown

TTCP и Интернет

TCP / IP и OSI / RM

[Глава 6] 6.3 Как выглядит пакет?

6.3.1 TCP / IP / Ethernet Пример

6.3.1.1 Уровень Ethernet

6.3.1.2 Уровень IP

Рисунок 6.3: Заголовок и тело IP-адреса

6.3.1.3 Уровень TCP

6.3.2 IP

6.3.2.1 Параметры IP

6.3.2.2 IP-фрагментация

Рисунок 6.4: Фрагментация данных

6.3.3 Вышеуказанные протоколы IP

6.3.3.1 TCP

Рисунок 6.5: Биты ACK в TCP-пакетах

6.3.3.2 UDP

Рисунок 6.6: Динамическая фильтрация пакетов на уровне UDP

6.3.3.3 ICMP

6.3.3.4 RPC

Рисунок 6.7: RPC и portmapper

6.3.3.5 IP поверх IP

6.3.6 IP Version 6

6.3.7 Протоколы не-IP

Что такое TCP и UDP? Простое объяснение

Определение TCP и UDP

Как работают TCP и UDP

В чем основное различие между TCP и UDP?

OpenVPN: TCP против UDP

Какой протокол использует NordVPN?

Принцип надежной передачи данных

3.4.1 Создание надежного протокола передачи данных

3.4.2 Конвейерные протоколы надежной передачи данных

3.4.4 Выборочный повтор (SR)

Счетчик ACN

Ответить Отменить ответ