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

Содержание

Как отличить дубликат от оригинала птс


фото, как выглядит оригинальный документ и в чем отличие от копии, а также возможно ли проверить по базе ГИБДД?

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

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

Однако каждый автолюбитель должен владеть информацией о том, как отличить дубликат ПТС от оригинала.

Дорогие читатели! Наши статьи рассказывают о типовых способах решения юридических вопросов, но каждый случай носит уникальный характер.
 
Если вы хотите узнать, как решить именно Вашу проблему — обращайтесь в форму онлайн-консультанта справа или звоните по телефону 8 (800) 350-29-87. Это быстро и бесплатно!

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

Паспорт транспортного средства (ПТС) — важный документ для автомобиля, который содержит в себе много полезной информации. К сожалению сегодня подделка ПТС нередкое явление, поэтому нужно знать основные отличия оригинала и дубликата.

Как отличить дубликат ПТС?

Итак, вам необходимо знать основные отличия:

  • в графе «особые отметки» на копии документа будет находиться штамп «дубликат»;
  • если вы покупаете подержанный автомобиль, то обычно вид его ПТС не может быть «новым» — царапины, потертости и другие признаки указывают, что документ является оригинальным;
  • наличие защиты — объемный текст, водяные знаки, голографическая наклейка и другие.

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

  • большой список предыдущих владельцев авто должно насторожить, так как это распространенный способ запутать следы;
  • отдаленный регион регистрации машины — один из признаков мошенничества;
  • определенно должны быть таможенные отметки для автомобилей иностранного производства;
  • старайтесь не приобретать авто с дубликатом документов, если оно самое новое.
Методы определения поддельных ПТС

Если у вас нет специально оборудования, то вы

можете использовать:

  • простой фонарик;
  • мощная лупа с увеличением от х10.

Когда у вас есть в руках ПТС, то посмотрите дубликат это или нет. Если он является дубликатом, то рекомендуется расспросить о причине дубляжа. Если вы доверяете доводам хозяина, то можно продолжать осмотр:

  1. Проведите по голограмме большим пальцем: основное тело документа и голограмма должна составлять ощущение единого целого, без лишних границ перехода.
  2. Бумага бланка ПТС на ощупь и визуально должна соответствовать всем похожим продуктам от Госзнака.
  3. Возьмите фонарик и наклоните ПТС под углом 25-35 градусов. Посветите на левый верхний угол, там вы должны заметить надпись «ПТС».
  4. Лупой наведите на голограмму: посередине изображен автомобиль, а на её лобовом стекле имеется надпись «Россия. Россия».
  5. Обратите внимание на качество бумаги. Как правило, подделку изготавливают из более плотной и гладкой бумаги, а оригинальный ПТС отличается шероховатостью.
  6. Посмотрите на левый нижний угол и год изготовления бланка: если дата будет меньше, чем год выдачи ПТС, то это главный признак подделки.

Полезные советы для владельцев и покупателей
  1. Смотрите на водяные знаки ПТС, настоящие будут легко размытые, а подделки идеально ровными и четкими.
  2. Учитывайте то, что бывает, в региональных ГИБДД небольших населенных пунктов в штате на некоторое время отсутствуют специалисты, и вы можете получить авто, который успешно прошел перерегистрацию органами с «успешной» экспертизой поддельного ПТС.
  3. Существуют фотоаппараты и смартфоны, у которых имеется встроенный ультрафиолет или инфракрасный фильтр. Они могут помочь вам в определении поддельных документов.

Возможно вас это заинтересует — Как продать подержанный автомобиль — основные советы и способы

Как определить ПТС дубликат — видео

Дубликат ПТС — как отличить, чего бояться и стоит ли покупать?

Что значит дубликат ПТС, как он выглядит, чего бояться и вообще стоит ли покупать машину, если ПТС – дубликат? Обо всем этом мы сегодня и поговорим.

  • Дубликат ПТС

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

Для начала давайте разберемся, что значит ПТС дубликат и почему он появляется у машины?

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

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

Как выглядит дубликат ПТС?

Для грамотного покупателя очень важно знать, как отличить дубликат ПТС

от оригинала. Пожалуй, самый очевидный признак – это здоровенный штемпель «ДУБЛИКАТ» где-нибудь на видном месте.

Он позволяет отличить дубликат, вообще не напрягаясь – его очень трудно не заметить. По правилам МВД, такой штамп должен ставиться при выдаче дублера ВСЕГДА! Но, как обычно, правила у нас работают с перебоями. Поэтому многие дубликаты остаются непомеченными, а нам, покупатлям, приходится искать вторичные признаки.

И второе отличие дубликата ПТС содержится в «Особых отметках». Это свободное поле в левой части каждой страницы паспорта. Сюда, отметку о выдаче дубликата оператор ГИБДД выводит практически всегда.

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

Но главное отличие дубликата ПТС – это организация, выдавшая документ. Дело в том, что оригинальные паспорта выдает таможня и автопроизводители. Для машин, собранных в России, ПТС выдает завод изготовитель, а для ввезенных из-за границы – таможня. А вот

дубликаты ПТС всегда выдает ГИБДД!

Итак, ребята, если напротив выдавшей организации стоит печать ГИБДД, значит это точно дубликат. А вы теперь знаете, как отличить ПТС оригинал от дубликата.

Дубликат ПТС — чего бояться?

Но что если вам попался дубликат ПТС – чего бояться при покупке авто? Главный минус машины с дубликатом – это то, что оригинал может попасть в руки третьих лиц. Поэтому, имея дело с дубликатом, всегда есть шанс потерять машину.

Как это работает? Например, это может оказаться залоговый авто. ПТС находится у залогодержателя, а предприимчивый владелец получает в ГИБДД дубликат и продает машину. Для покупателя эта ситуация – патовая. Если он не позаботился о нотариально заверенной выписке из реестра залогов, сохранить машину не получится.

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

Но главный косяк дубликата в том, что он скрывает всю предысторию автомобиля. Честно говоря, история машины у нас непрозрачна даже с оригинальным ПТС, но там хотя-бы видно:

1)Историю владельцев. Нет ли среди них юр.лиц.
2)Задерживался ли автомобиль у владельцев хотя бы на пару лет. Если меньше – вряд ли машину берегли.
3)Ставил ли первый владелец (дилер), машину на учет. Если ставил – значит на машине ездили, то есть она использовалась для тест-дрейва или как подменная.
4)Бывает наоборот, когда дотошный и НЕхитрый владелец израсходует много мест в ПТС, меняя СТС каждый раз при смене прописки. На деле же машина, пребывая в одних руках, обычно сохраняется намного лучше.

Грубо говоря, дубликат – это шляпа. Он практически стирает историю машины, поэтому его, кстати, намеренно получают, когда надо скрыть прошлое автомобиля.

Стоит ли покупать машину с дубликатом?

Итак, допустим вам попалась машина, у которой ПТС дубликат – стоит ли покупать такой авто? Здесь важно понимать, что дубликат – это всегда риск, но с годами этот риск снижается. Если дубликат и вызовет проблемы, то это произойдет в первые 2-3 года после его выдачи. А лет через 5-7 дубликат становится ничуть не опасней оригинала. Поэтому, друзья, в первую очередь смотрите на дату выдачи дублера.

Кроме того, в особых отметках дубликата, иногда пишут «выдан взамен утилизированного» или «выдан взамен утраченного».

Так вот «выдан взамен утраченного» — это и есть самый опасный вариант, которого лучше избегать. Но, как я уже говорил выше, особые отметки не стандартизированы. Иногда их вообще не заполняют, а чаще всего там указано просто «выдан взамен».

Так стоит ли покупать машину, если у нее дубликат ПТС? Осторожный покупатель такой авто не станет рассматривать в принципе – для него это не вариант. Если же рисковать вам по душе – это неплохой способ испытать свою удачу. В любом случае, покупая автомобиль с дубликатом, надо быть готовым к возможным потерям. Все-таки, риск – это неизбежная плата за более низкую цену, которой отличаются машины с дубликатом.

© Kak-Kupit-Auto.ru

Ссылки: zr.ru

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

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

Оригинальный ПТС

Как вычислить фальшивку

Если вы заметили странное поведение владельца, то вам стоит присмотреться к определённым моментам:

Если ПТС утерян

Иногда бывают случаи, когда вам могут показать восстановленный ПТС взамен утерянного, здесь вы должны также проявить максимум наблюдательности при проверке, но также знать один минус. Если вы потеряете и этот паспорт, то очень вероятно, что ваш автомобиль будут игнорировать при продаже.

Как проверить бланк ПТС

Для данной работы нужно специальное оборудование, но если его нет, то подойдет обычный карманный фонарик и лупа.

Оригинал ПТС в ултрафиолете

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

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


Основные способы, которые помогут понять, как отличить ПТС оригинал от дубликата

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

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

Однако каждый автолюбитель должен владеть информацией о том, как отличить дубликат ПТС от оригинала.

Как выглядит дубликат ПТС и какую информацию содержит?

Основная информация об оригиналах и дубликатах ПТС содержится в Приказе МВД Российской Федерации, Министерства промышленности и энергетики и минэкономразвития от 23.06.2015 года №496/192/134 «Об утверждении Положения о паспортах транспортных средств и паспортах шасси ТС».

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

Первое, что бросается в глаза – это наличие штампа «Дубликат» в поле «Особые отметки» (верхняя левая часть паспорта). Во многих отделениях ГИБДД его наносят для информирования о том, что данный документ не является первичным.

За годы своего использования, бланк ПТС несколько раз усовершенствовался, и на сегодняшний день имеет целый набор степеней защиты и специальных элементов, повышающих его защищенность. Бумага, из которой производится оригинал ПТС имеет водяные знаки, видимые на просвет.

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

Ниже расположен номер документа и 24 строки для внесения информации об автомобиле, регистрационных данных его составных частей (рама, кузов, шасси), мощности и экологическом классе двигателя, цвете кузова, а также разрешенной и максимальной массе транспортного средства.

В поле «Наименование организации, выдавшей паспорт» должны стоять печати Таможенных органов (если автомобиль транспортировался из-за границы и проходил все необходимые процедуры) или штамп завода-изготовителя.

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

Справка! Другие области бланка ПТС отведены для указания сведений о владельцах автомобиля, государственном регистрационном знаке, а также имеют место для подписи и печати (при необходимости).

Причины получения

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

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

  1. Утрата или кража оригинала.
  2. Замена ПТС в связи с отсутствием полей для внесения данных о новом владельце.
  3. Выдача дубликата на новом бланке взамен обветшалого.

Причина замены дубликата должны быть отражены в поле «Особые отметки» с указанием серии и номера предшествующего документа. Именно потеря документа является самым распространенным предлогом для получения дубликата ПТС с целью совершения преступных действий.

Паспорт транспортного средства – не тот документ, который необходимо постоянно иметь при себе и предъявлять, например, сотрудникам ГИБДД, поэтому и потерять его довольно сложно. Как показывает практика, покупка автомобиля с дубликатом ПТС является сделкой с повышенным риском.

Чем отличается от оригинала – максимально подробно

Официальная копия паспорта транспортного средства является таким же полноценным документом, как и оригинал. Причин получения дубликата множество – это и утрата или первоначального образца, и физический износ самого документа, и такие ситуации, в которых ПТС больше не имеет свободных областей для внесения информации о владельцах.

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

Внимание! На лицевой стороне оригинала всегда стоит печать завода изготовителя или штамп таможенных служб. На дубликате бланка в графе с информацией об организации, выдававшей паспорт, стоит печать ГИБДД или иных органов, имеющих такие полномочия.

Первое отличие, которое бросается в глаза в таком бланке – это наличие штампа «Дубликат» в поле «Особые отметки» (верхняя левая часть паспорта). Во многих отделениях ГИБДД его наносят для информирования о том, что данный документ не является первичным.

Как выглядит птс дубликат (фото):

Поле «Особые отметки» должно содержать информацию о причине выдачи дубликата. Таких причин несколько. Замена утилизированного ПТС – приемлемый вариант, так как для получения такого дубликата собственник должен предоставить оригинал. Если же в данной графе в качестве причины указана «Утрата», стоит внимательнее относится к такому бланку. Возможно владелец или его представитель скрывает информацию, которая может повлиять на исход сделки

Как снизить риск по сделкам с копией?

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

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

  • Покупка ТС с непогашенным кредитным договором (грозит изъятием у нового владельца в пользу кредитора по решению суда в соответствии с ФЗ 353 «О потребительском кредитовании»).
  • Приобретение одним из собственников совместно нажитого имущества. К примеру, во время бракоразводного процесса и разделения имущества один из супругов втайне от другого продает авто.

Если все-таки вы решили приобрести автомобиль с дубликатом паспорта, рекомендуется в первую очередь обратить внимание на то, есть ли в документе записи о предыдущих собственниках, кроме продавца. Если в ПТС указана информация только о нынешнем владельце, это повод задуматься.

Важно! Подозрительными дубликатами можно считать те, что получены не так давно, относительно дня продажи (до 3 месяцев). Свежая дата получения дубликата также может служить косвенным признаком недобросовестности дилера.

Полезное видео

Далее посмотрим интересное видео на тему данной статьи:

Итоги

Несмотря на то, что и дубликат, и оригинал являются равноценными документами, количество сделок с использованием копии паспорта ТС значительно меньше, чем с их первоначальным вариантом. Это говорит о том, что автолюбители избегают подобных автомобилей и с опаской смотрят на сделки с ними.

Следует отметить, что с 1 июля 2017 года на территории РФ согласно Решению Коллегии ЕЭК от 22.09.15 будут введены поправки в нормативные акты, связанные с использованием паспортов транспортных средств.

Также отметим, что проверить по базе и узнать оригинал документа можно.

Источник

Решено: повторяющаяся ошибка TCP SYN ID SYSLOG 419002

Привет,

Я поддерживаю устройство, в котором у нас есть 2 ASA, выступающих в качестве межсетевых экранов между их внутренней, DMZ и внешней сетью. Один ASA активен, а другой пассивен. У меня есть множество правил доступа для доступа устройств к серверам от внутреннего до DMZ, от DMZ до внешнего и т. Д. У меня проблема с одним веб-сервером. У веб-сервера есть ветвь DMZ и внешний сетевой адаптер.

Пользователи внутренней сети должны получить доступ к сетевому адаптеру DMZ, который у меня настроен и работает нормально.Существует также внешний веб-URL, который вводят внешние пользователи, чтобы получить доступ к веб-серверу извне. На ASA я добавил адрес dmz веб-сервера и внешний адрес как объекты.

В правиле доступа для внешней связи у меня проблема. У меня есть правило доступа к внешнему интерфейсу, которое должно разрешать ip из любого источника на этот веб-сервер, используя его внешний адрес.

Теперь, когда я пытаюсь проверить это, перейдя на URL внешнего адреса, он не подключается, и я получаю массу атак Duplicate TCP SYN, которые я просто не могу разрешить и не понимаю, откуда они берутся?

Я получаю сообщение об ошибке «Дублирование TCP SYN извне xx.xx.xx.xx / 21963 за пределы xx.xx.xx.xx / 80 с другим начальным порядковым номером «

Глядя на многочисленные журналы ошибок, исходный IP-адрес и исходный порт всегда точно такие же. Я понимаю, что обычно ошибка может означает подделку, но я не знаю, как это могло произойти. Также я понимаю, что это может быть петля маршрутизации, но опять же, я не знаю, где искать петлю маршрутизации.

Приветствуются любые советы по устранению неполадок. Обратите внимание, что я иметь идентичный веб-сервер только с разными IP-адресами, который, похоже, работает нормально, имеет одинаковые правила доступа на ASA.

.

RFC 2883 — Расширение опции выборочного подтверждения (SACK) для TCP

[Docs] [txt | pdf] [draft-floyd-sack] [Tracker] [Diff1] [Diff2] [Errata]

ПРЕДЛАГАЕМЫЙ СТАНДАРТ
Есть исправления

 Сетевая рабочая группа С. Флойд Запрос комментариев: 2883 ACIRI Категория: Стандарты Track J.Махдави Novell М. Матис Питтсбургский суперкомпьютерный центр М. Подольский Калифорнийский университет в Беркли Июль 2000 г. Расширение опции выборочного подтверждения (SACK) для TCP Статус этой памятки Этот документ определяет протокол отслеживания стандартов Интернета для Интернет-сообщество и просит обсуждения и предложения по улучшения.Пожалуйста, обратитесь к текущему выпуску "Интернет Официальные стандарты протокола »(STD 1) для состояния стандартизации и статус этого протокола. Распространение памятки не ограничено. Уведомление об авторских правах Авторское право (C) The Internet Society (2000). Все права защищены. Аннотация В этом примечании определяется расширение выборочного подтверждения. (SACK) Вариант [RFC2018] для TCP. RFC 2018 определил использование Опция SACK для подтверждения данных вне очереди, не охваченных Поле совокупного подтверждения TCP.Это примечание расширяет RFC 2018 указав использование опции SACK для подтверждения дублирования пакеты. Это примечание предполагает, что когда дублирующиеся пакеты получен, первый блок поля опции SACK может использоваться для сообщать порядковые номера пакета, вызвавшего подтверждение. Это расширение опции SACK позволяет TCP отправитель, чтобы определить порядок пакетов, полученных получателем, позволяя отправителю сделать вывод, когда он без необходимости повторно передал пакет.Отправитель TCP может использовать эту информацию для получения дополнительных сведений. надежная работа в среде переупорядоченных пакетов [BPS99], ACK потеря, репликация пакетов и / или тайм-ауты ранней повторной передачи. 1. Условные обозначения и сокращения Ключевые слова ДОЛЖНЫ, НЕ ДОЛЖНЫ, НЕОБХОДИМЫ, НЕ ДОЛЖНЫ, НЕ ДОЛЖНЫ, НЕ ДОЛЖЕН, РЕКОМЕНДУЕТСЯ, МОЖЕТ и НЕОБЯЗАТЕЛЬНО, когда они появляются в этом документ, следует интерпретировать, как описано в [B97]. Флойд и др. Стандарты Track [Страница 1] 
 RFC 2883 SACK Extension, июль 2000 г. 2.Введение Опция выборочного подтверждения (SACK), определенная в RFC 2018: используется получателем данных TCP для подтверждения несмежных блоков данные, не включенные в поле «Суммарное подтверждение». Тем не мение, RFC 2018 не указывает использование опции SACK при дублировании сегменты получены. В этом примечании указывается на использование SACK опция при подтверждении получения дублирующего пакета [F99]. Мы используем термин D-SACK (от duplicate-SACK) для обозначения блока SACK. который сообщает о повторяющемся сегменте.Этот документ не вносит никаких изменений в использование TCP кумулятивное поле подтверждения или по решению получателя TCP of * when * для отправки пакета подтверждения. Только этот документ касается содержимого опции SACK, когда подтверждение послал. Это расширение совместимо с текущими реализациями SACK. вариант в птс. То есть, если один из конечных узлов TCP не реализовать это расширение D-SACK и другой конечный узел TCP, мы считают, что это использование расширения D-SACK одним из конечных узлов не доставит проблем.Использование D-SACK не требует отдельного согласования между TCP. отправитель и получатель, которые уже согласовали возможность SACK. Отсутствие отдельного согласования для D-SACK означает, что TCP получатель может отправлять блоки D-SACK, когда отправитель TCP не понимать это расширение для SACK. В этом случае отправитель TCP будет просто отбросьте все блоки D-SACK и обработайте другие блоки SACK в поле опции SACK, как обычно. Флойд и др.Стандарты Track [Страница 2] 
 RFC 2883 SACK Extension, июль 2000 г. 3. Формат опций мешка, как определено в RFC 2018. Опция SACK, как определено в RFC 2018, выглядит следующим образом: + -------- + -------- + | Вид = 5 | Длина | + -------- + -------- + -------- + -------- + | Левый край 1-го блока | + -------- + -------- + -------- + -------- + | Правый край 1-го блока | + -------- + -------- + -------- + -------- + | | /.. . / | | + -------- + -------- + -------- + -------- + | Левый край n-го блока | + -------- + -------- + -------- + -------- + | Правый край n-го блока | + -------- + -------- + -------- + -------- + Параметр выборочного подтверждения (SACK) в заголовке TCP содержит несколько блоков SACK, где каждый блок определяет левый и правый край блока данных, полученных получателем TCP.В в частности, блок представляет собой непрерывное пространство последовательности данных получил и поставил в очередь у получателя, где "левый край" block - это первый порядковый номер блока, а «правый край» порядковый номер, следующий сразу за последним порядковым номером блока. RFC 2018 подразумевает, что первый блок SACK указывает сегмент, который вызвало подтверждение. Из RFC 2018, когда получатель данных выбирает отправку опции SACK, "первый блок SACK... ДОЛЖЕН указать непрерывный блок данных, содержащий сегмент, который запустил этот ACK, если только этот сегмент не продвинул номер подтверждения поле в заголовке ". Однако RFC 2018 не рассматривает использование опции SACK, когда подтверждение дублирующегося сегмента. Например, RFC 2018 указывает что "каждый блок представляет полученные байты данных, которые смежные и изолированные ". RFC 2018 дополнительно уточняет, что" если отправлено вообще, параметры SACK ДОЛЖНЫ быть включены во все ACK, которые не ACK наивысший порядковый номер в очереди получателя данных.«RFC 2018 не указывает использование опции SACK, когда дублирующийся сегмент получен, и поле совокупного подтверждения в ACK подтверждает все данные в очереди получателя данных. Флойд и др. Стандарты Track [Страница 3] 
 RFC 2883 SACK Extension, июль 2000 г. 4. Использование опции SACK для сообщения о повторяющемся сегменте. В этом разделе описывается использование блоков SACK, когда параметр SACK установлен. используется при сообщении о повторяющемся сегменте.Когда используется D-SACK, первым блоком опции SACK должен быть блок D-SACK, определяющий порядковые номера для повторяющегося сегмента, который запускает подтверждение. Если дублирующийся сегмент является частью большего блока несмежных данных в очереди данных получателя, то следующий блок SACK должен использоваться для указания этого большего блока. Дополнительные блоки SACK могут использоваться для указания дополнительных не- непрерывные блоки данных, как указано в RFC 2018. Рекомендации по сообщению о повторяющихся сегментах приведены ниже: (1) Блок D-SACK используется только для сообщения о повторяющихся смежных последовательность данных, полученных получателем в самом последнем пакете.(2) Сообщается о каждой повторяющейся непрерывной последовательности полученных данных. не более чем в одном блоке D-SACK. (Т.е. получатель отправляет два одинаковых D-SACK блокируется в последующих пакетах только в том случае, если получатель получает два повторяющиеся сегменты.) (3) Левый край блока D-SACK определяет первую последовательность номер повторяющейся непрерывной последовательности, а правый край блок D-SACK определяет порядковый номер сразу после последняя последовательность в повторяющейся непрерывной последовательности.(4) Если блок D-SACK сообщает о повторяющейся непрерывной последовательности из (возможно, больший) блок данных в очереди данных получателя выше совокупное подтверждение, затем второй блок SACK в этом Параметр SACK должен указывать этот (возможно, больший) блок данных. (5) Следуя блокам SACK, описанным выше, для сообщения о дубликатах сегментов, дополнительные блоки SACK могут использоваться для сообщения дополнительных блоки данных, как указано в RFC 2018. Обратите внимание: поскольку каждый повторяющийся сегмент сообщается только в одном ACK пакет, информация об этом повторяющемся сегменте будет потеряна, если этот Пакет ACK отброшен в сети.4.1 Сообщение о полных повторяющихся сегментах Мы проиллюстрируем эти рекомендации тремя примерами. В каждом примере мы предполагаем, что получатель данных сначала получил восемь сегментов 500 байт каждый и отправил подтверждение с совокупным поле подтверждения установлено на 4000 (при условии, что первый порядковый номер равно нулю). Блок D-SACK подчеркнут в каждом примере. Флойд и др. Стандарты Track [Страница 4] 
 RFC 2883 SACK Extension, июль 2000 г. 4.1.1. Пример 1. Сообщение о повторяющемся сегменте. Поскольку несколько пакетов ACK потеряны, отправитель данных повторно передает пакет 3000-3499, и получатель данных впоследствии получает повторяющийся сегмент с порядковыми номерами 3000-3499. Получатель отправляет подтверждение с полем кумулятивного подтверждения установлен на 4000, и первый блок D-SACK, определяющий порядковые номера 3000-3500. Передано Получено Отправлено ACK Сегментный сегмент (включая блоки SACK) 3000-3499 3000-3499 3500 (ACK сброшен) 3500-3999 3500-3999 4000 (ACK сброшен) 3000-3499 3000-3499 4000, SACK = 3000-3500 --------- 4.1.2. Пример 2. Сообщение о неупорядоченном сегменте и его дубликате сегмент. После потери пакета данных получатель получает сообщение не по порядку. сегмент данных, который запускает параметр SACK, как указано в RFC 2018. Из-за потери нескольких пакетов ACK отправитель повторно передает пакет данных. Получатель получает дубликат пакет и сообщает об этом в первом блоке D-SACK: Передано Получено Отправлено ACK Сегментный сегмент (включая блоки SACK) 3000-3499 3000-3499 3500 (ACK сброшен) 3500-3999 3500-3999 4000 (ACK сброшен) 4000-4499 (пакет данных отброшен) 4500-4999 4500-4999 4000, SACK = 4500-5000 (ACK сброшен) 3000-3499 3000-3499 4000, SACK = 3000-3500, 4500-5000 --------- Флойд и др.Стандарты Track [Страница 5] 
 RFC 2883 SACK Extension, июль 2000 г. 4.1.3. Пример 3. Сообщение о дубликате неупорядоченного сегмента. Из-за потерянного пакета данных приемник получает два вышедших из строя сегменты. Затем получатель получает дубликат сегмента для одного из эти вышедшие из строя сегменты: Передано Получено Отправлено ACK Сегментный сегмент (включая блоки SACK) 3500–3999 3500–3999 4000 4000-4499 (пакет данных отброшен) 4500-4999 4500-4999 4000, SACK = 4500-5000 5000-5499 5000-5499 4000, SACK = 4500-5500 (дублированный пакет) 5000-5499 4000, SACK = 5000-5500, 4500-5500 --------- 4.2. Как сообщить о частичных повторяющихся сегментах Возможно, отправитель передает пакет, содержащий один или несколько повторяющихся подсегментов - то есть только часть, но не все переданный пакет уже прибыл к получателю. Это может возникают, когда размер переданных сегментов отправителя увеличивается, что может произойти, когда PMTU увеличивается в середине TCP сеанс, например. Рекомендации в Разделе 4 выше применимы к отчет о частичных и полных повторяющихся сегментах.Эта секция приводит примеры этих рекомендаций при сообщении о частичном дублировании сегменты. Когда опция SACK используется для сообщения о частичном дублировании сегментов, первый блок D-SACK сообщает о первом повторяющемся суб- сегмент. Если подтверждаемый пакет данных содержит несколько частичные дубликаты подсегментов, затем только первый такой дубликат подсегмент сообщается в опции SACK. Мы проиллюстрируем это с помощью примеры ниже. 4.2.1. Пример 4: Отчет об одном повторяющемся подсегменте.Отправитель увеличивает размер пакета с 500 до 1000 байтов. Получатель впоследствии получает 1000-байтовый пакет, содержащий один 500-байтовый сегмент, который уже был получен, и тот, который не. Получатель сообщает только об уже полученном подсегменте, используя один блок D-SACK. Флойд и др. Стандарты Track [Страница 6] 
 RFC 2883 SACK Extension, июль 2000 г. Передано Получено Отправлено ACK Сегментный сегмент (включая блоки SACK) 500-999 500-999 1000 1000-1499 (с задержкой) 1500-1999 (пакет данных отброшен) 2000-2499 2000-2499 1000, SACK = 2000-2500 1000-2000 1000-1499 1500, SACK = 2000-2500 1000-2000 2500, SACK = 1000-1500 --------- 4.2.2. Пример 5: Два несмежных повторяющихся подсегмента, охватываемых совокупное признание. После того, как отправитель увеличивает размер своего пакета с 500 байт до 1500 байтов, получатель получает пакет, содержащий два несмежных дублировать подсегменты размером 500 байт, которые меньше совокупного поле подтверждения. Получатель сообщает о первом таком дубликате. сегмент в одном блоке D-SACK. Передано Получено Отправлено ACK Сегментный сегмент (включая блоки SACK) 500-999 500-999 1000 1000-1499 (с задержкой) 1500-1999 (пакет данных отброшен) 2000-2499 (задержано) 2500-2999 (пакет данных отброшен) 3000-3499 3000-3499 1000, SACK = 3000-3500 1000-2499 1000-1499 1500, SACK = 3000-3500 2000-2499 1500, SACK = 2000-2500, 3000-3500 1000-2499 2500, SACK = 1000-1500, 3000-3500 --------- 4.2.3. Пример 6: Два несмежных повторяющихся подсегмента не охвачены кумулятивным подтверждением. Этот пример аналогичен примеру 5, за исключением того, что после отправителя увеличивает размер пакета, получатель получает пакет, содержащий два несмежных повторяющихся подсегмента, которые находятся над кумулятивное подтверждение, а не ниже. Первый, D- Блок SACK сообщает о первом повторяющемся подсегменте, а второй, Блок SACK сообщает о большем блоке несмежных данных, который он принадлежит.Флойд и др. Стандарты Track [Страница 7] 
 RFC 2883 SACK Extension, июль 2000 г. Передано Получено Отправлено ACK Сегментный сегмент (включая блоки SACK) 500-999 500-999 1000 1000-1499 (пакет данных отброшен) 1500-1999 (с задержкой) 2000-2499 (пакет данных отброшен) 2500-2999 (с задержкой) 3000-3499 (пакет данных отброшен) 3500-3999 3500-3999 1000, SACK = 3500-4000 1000-1499 (пакет данных отброшен) 1500-2999 1500-1999 1000, SACK = 1500-2000, 3500-4000 2000-2499 1000, SACK = 2000-2500, 1500-2000, 3500–4000 1500-2999 1000, SACK = 1500-2000, 1500-3000, --------- 3500–4000 4.3. Взаимодействие между D-SACK и PAWS RFC 1323 [RFC1323] определяет алгоритм защиты от Обернутые порядковые номера (PAWS). PAWS дает метод для различение порядковых номеров для новых данных и последовательности числа из предыдущего цикла через пространство порядковых номеров. Дубликаты сегментов могут быть обнаружены PAWS как принадлежащие предыдущий цикл через пространство порядковых номеров. RFC 1323 указывает, что для таких пакетов получатель должен выполнять следующий: Отправьте подтверждение в ответ, как указано в RFC 793, стр. 69, и опустите сегмент.Поскольку PAWS по-прежнему требует отправки ACK, вредных взаимодействие между PAWS и использование D-SACK. Блок D-SACK может быть включенным в опцию SACK ACK, как описано в Разделе 4, независимо от использования PAWS получателем TCP, и независимо от определения PAWS действительности или недействительность сегмента данных. Отправители TCP, получающие блоки D-SACK, должны знать, что сегмент отмечен как повторяющийся сегмент, возможно, из предыдущего прокрутите пространство порядковых номеров.Это не зависит от использование PAWS получателем данных TCP. Мы не ожидаем, что это создаст серьезные проблемы для отправителей, использующих D-SACK Информация. Флойд и др. Стандарты Track [Страница 8] 
 RFC 2883 SACK Extension, июль 2000 г. 5. Обнаружение повторяющихся пакетов Это расширение опции SACK позволяет приемнику точно сообщить о приеме дублирующих данных.Потому что каждое получение о дублированном пакете сообщается только в одном пакете ACK, потеря единый ACK может помешать этой информации достичь отправителя. В Кроме того, отметим, что отправитель не обязательно может доверять получатель, чтобы отправить ему точную информацию [SCWA99]. Чтобы отправитель мог проверить, что первый блок (D) SACK подтверждение фактически подтверждает дублирование данных, отправитель должен сравнить пространство последовательности в первом блоке SACK с совокупный ACK, который хранится В ОДНОМ ПАКЕТЕ.Если SACK пространство последовательности меньше, чем этот совокупный ACK, это показатель что сегмент, идентифицированный блоком SACK, был получен больше чем один раз получателем. Реализация НЕ ДОЛЖНА сравнивать пространство последовательности в блоке SACK до переменной состояния TCP snd.una (который несет общий совокупный ACK), так как это может привести к неправильный вывод при переупорядочении пакетов ACK. Если пространство последовательности в первом блоке SACK больше, чем накопительный ACK, затем отправитель сравнивает пространство последовательности в первый блок SACK с пространством последовательности во втором SACK блок, если он есть.Это сравнение может определить, Блок SACK сообщает о повторяющихся данных, которые лежат выше совокупного ACK. Реализации TCP, следующие за RFC 2581 [RFC2581], могли видеть повторяющиеся пакеты в каждой из следующих четырех ситуаций. Этот документ не указывает, какое действие должна выполнять реализация TCP. беру в этих случаях. Расширение опции SACK просто включает отправителю для обнаружения каждого из этих случаев. Обратите внимание, что эти четыре условия не являются исчерпывающим списком возможных случаев дублирования пакеты, но являются репрезентативными для наиболее распространенных / вероятных случаев.В последующих документах будут описаны экспериментальные предложения для отправителя. ответы на обнаружение ненужных повторных передач из-за переупорядочение, потеря ACKS или таймауты на раннюю повторную передачу. Флойд и др. Стандарты Track [Страница 9] 
 RFC 2883 SACK Extension, июль 2000 г. 5.1. Репликация по сети Если пакет реплицируется в сети, это расширение SACK вариант может идентифицировать это.Например: Передано Получено Отправлено ACK Сегментный сегмент (включая блоки SACK) 500-999 500-999 1000 1000-1499 1000-1499 1500 (воспроизведено) 1000-1499 1500, SACK = 1000-1500 --------- В этом случае второй пакет был реплицирован в сети. An ACK, содержащий блок D-SACK, который ниже, чем его поле ACK, и не идентичен ранее повторно переданному сегменту является ориентировочным репликации по сети.БЕЗ D-SACK: Если D-SACK не использовался, а последний ACK был совмещен с данными пакет, отправитель не узнает, что пакет был реплицирован в сети. Если D-SACK не использовался и ни один из двух последних ACK были скопированы с пакетом данных, после чего отправитель мог разумно сделать вывод, что либо некоторый пакет данных *, либо * окончательный ACK пакет был реплицирован в сети. Получение D-SACK пакет дает отправителю информацию о том, что этот пакет данных был тиражируется в сети (при условии, что получатель не врет).ВОПРОСЫ ИССЛЕДОВАНИЯ: Текущая опция SACK уже позволяет отправителю идентифицировать дублирующиеся ACK, которые не подтверждают новые данные, но D-SACK вариант дает отправителю более веские основания для вывода, что duplicate ACK не подтверждает новые данные. Знание, что дублирующийся ACK не подтверждает, что новые данные позволяют отправителю воздерживаться от использования этих дублированных ACK для вывода о потере пакета (например, Fast Retransmit) или для отправки дополнительных данных (например, Fast Recovery). 5.2. Ложная ретрансляция из-за переупорядочения Если пакеты переупорядочиваются в сети так, что прибывает сегмент более 3 пакетов вышли из строя, алгоритм TCP Fast Retransmit повторно передаст пакет вне очереди.Пример этого показан ниже: Флойд и др. Стандарты Track [Страница 10] 
 RFC 2883 SACK Extension, июль 2000 г. Передано Получено Отправлено ACK Сегментный сегмент (включая блоки SACK) 500-999 500-999 1000 1000-1499 (с задержкой) 1500-1999 1500-1999 1000, SACK = 1500-2000 2000-2499 2000-2499 1000, мешок = 1500-2500 2500-2999 2500-2999 1000, SACK = 1500-3000 1000-1499 1000-1499 3000 1000-1499 3000, SACK = 1000-1500 --------- В этом случае ACK, содержащий блок SACK, меньший, чем его Поле ACK и идентично ранее повторно переданному сегменту свидетельствует о значительном переупорядочивании с последующим ложным (ненужная) ретрансляция.БЕЗ D-SACK: При использовании D-SACK, показанного выше, отправитель знает, что либо первая передача сегмента 1000-1499 была задержана в сеть, или первая передача сегмента 1000-1499 была прервана и вторая передача сегмента 1000-1499 была продублирована. Учитывая, что никакие другие сегменты в сети не дублировались, второй вариант можно считать маловероятным. Без использования D-SACK отправитель будет знать только то, что либо первая передача сегмента 1000-1499 была задержана в сети, или что либо один из сегментов данных, либо последний ACK был продублирован в сети.Таким образом, использование D-SACK позволяет отправителю чтобы более надежно заключить, что первая передача сегмента 1000-1499 не было сброшено. [AP99], [L99] и [LK00] отмечают, что отправитель мог однозначно обнаруживать ненужную повторную передачу с использованием метки времени вариант. [LK00] предлагает алгоритм на основе меток времени, который минимизирует штраф за ненужную ретрансляцию. [AP99] предлагает эвристика для обнаружения ненужной повторной передачи в среде без отметок времени и SACK.[L99] также предлагает двухбитный поле как альтернатива опции отметки времени для однозначно маркировка первых трех повторных передач пакета. Похожая идея был предложен в [ISO8073]. ВОПРОСЫ ИССЛЕДОВАНИЯ: Использование D-SACK позволяет отправителю обнаруживать некоторые случаи (например, когда пакетов ACK не было потеряно), когда быстрая повторная передача была вызвана переупорядочивание пакетов вместо потери пакетов. Это позволяет отправителю TCP Флойд и др. Стандарты Track [Страница 11] 
 RFC 2883 SACK Extension, июль 2000 г. настроить порог дублирования подтверждений, чтобы предотвратить такие ненужные быстрые ретрансляции в будущем.Вместе с тем, когда отправитель определяет после факта, что он сделал ненужное уменьшение окна, отправитель имеет возможность «отменить» это сокращение окна перегрузки путем сброса ssthresh на значение старого окна перегрузки и медленный запуск до окно перегрузки достигло этой точки. Любое предложение «отменить» уменьшение окна перегрузки будет необходимо учитывать возможность того, что получатель TCP может лгать в своих отчетах о полученных пакетах [SCWA99].5.3. Тайм-аут повторной передачи из-за потери ACK Если все окно ACK потеряно, произойдет тайм-аут. An пример этого приведен ниже: Передано Получено Отправлено ACK Сегментный сегмент (включая блоки SACK) 500-999 500-999 1000 (ACK сброшен) 1000-1499 1000-1499 1500 (ACK сброшен) 1500-1999 1500-1999 2000 (ACK сброшен) 2000-2499 2000-2499 2500 (ACK сброшен) (тайм-аут) 500-999 500-999 2500, SACK = 500-1000 -------- В этом случае все ACK отбрасываются, что приводит к тайм-ауту.Это состояние можно определить, потому что первый полученный ACK после тайм-аута переносится блок D-SACK, указывающий на дублирование данные были получены. БЕЗ D-SACK: Без использования D-SACK отправитель в этом случае не сможет решает, что ни один пакет данных не был отброшен. ВОПРОСЫ ИССЛЕДОВАНИЯ: Для TCP, который реализует некоторую форму контроля перегрузки ACK [BPK97], эта способность различать отброшенные пакеты данных и отброшенные пакеты ACK были бы особенно полезны.В этом случае соединение может реализовать контроль перегрузки для возврата (ACK) путь независимо от контроля перегрузки в прямом направлении (данные) путь. Флойд и др. Стандарты Track [Страница 12] 
 RFC 2883 SACK Extension, июль 2000 г. 5.4. Тайм-аут ранней повторной передачи Если RTO отправителя слишком короткое, время ожидания ранней повторной передачи может возникают, когда в сети фактически не было отброшено ни одного пакета.An пример этого приведен ниже: Передано Получено Отправлено ACK Сегментный сегмент (включая блоки SACK) 500-999 (с задержкой) 1000-1499 (с задержкой) 1500-1999 (с задержкой) 2000-2499 (задержано) (тайм-аут) 500-999 (с задержкой) 500–999 1000 1000-1499 (с задержкой) 1000-1499 1500 ... 1500–1999 2000 2000-2499 2500 500-999 2500, SACK = 500-1000 -------- 1000-1499 2500, SACK = 1000-1500 --------- ... В этом случае первый пакет повторно передается после тайм-аут. Впоследствии исходное окно пакетов поступает на получатель, в результате чего для этих сегментов будут получены ACK.После этого поступают повторные передачи этих сегментов, в результате чего ACK переносят Блоки SACK, которые идентифицируют повторяющиеся сегменты. Это можно определить как тайм-аут ранней повторной передачи, потому что ACK для байта 1000 получен после тайм-аута без SACK информация, за которой следует ACK, который несет информацию SACK (500- 999), указывая, что ретранслируемый сегмент уже был получил. БЕЗ D-SACK: Если D-SACK не использовался и один из дублирующих ACK был совмещен в пакете данных отправитель не знает, сколько дубликатов пакеты были получены.Если D-SACK не использовался и ни один из дублирующиеся ACK были скопированы в пакет данных, затем отправитель отправил бы N повторяющихся пакетов для некоторого N и получил бы N дубликаты ACK. В этом случае отправитель мог разумно предположить, что Флойд и др. Стандарты Track [Страница 13] 
 RFC 2883 SACK Extension, июль 2000 г. некоторые данные или пакет ACK были реплицированы в сети, или истек тайм-аут ранней повторной передачи (или что получатель лежа).ВОПРОСЫ ИССЛЕДОВАНИЯ: После того, как отправитель определит, что ненужный (т.е. ранний) истекло время ожидания повторной передачи, отправитель может настроить параметры для установки RTO, чтобы избежать ненужных тайм-аутов повторной передачи. Вместе с тем, когда отправитель определяет постфактум, что он произвел ненужное уменьшение окна, отправитель имеет возможность "отмены" этого уменьшения окна перегрузки. 6. Соображения безопасности Этот документ не усиливает и не ослабляет текущую безопасность TCP. свойства.7. Благодарности Мы хотели бы поблагодарить Марка Хэндли, Райнера Людвига и Венката. Падманабхану за беседы по этим вопросам и поблагодарить Марка Аллману за полезные отзывы об этом документе. 8. Ссылки [AP99] Марк Аллман и Верн Паксон, об оценке сквозных операций Свойства сетевого пути, SIGCOMM 99, август 1999 г. URL "http://www.acm.org/sigcomm/sigcomm99/papers/session7- 3.html ". [BPS99] J.C.R. Беннет, С. Партридж и Н. Шектман, Packet Изменение порядка не является патологическим поведением сети, IEEE / ACM Транзакции в сети, Vol.7, No. 6, декабрь 1999 г., С. 789-798. [BPK97] Хари Балакришнан, Венката Падманабхан и Рэнди Х. Кац, Влияние асимметрии на производительность TCP, третий ACM / IEEE Конференция Mobicom, Будапешт, Венгрия, сентябрь 1997 г. URL "http://www.cs.berkeley.edu/~padmanab/ index.html # Publications ". [F99] Флойд, С., Re: TCP и доставка вне очереди, идентификатор сообщения [email protected]> на сквозной Список рассылки по интересам, февраль 1999 г.URL "http://www.aciri.org/floyd/notes/TCP_Feb99.email". Флойд и др. Стандарты Track [Страница 14] 
 RFC 2883 SACK Extension, июль 2000 г. [ISO8073] ISO / IEC, Системы обработки информации - Открытые системы Межсоединение - транспортный протокол, ориентированный на соединение Спецификация, Международный стандарт ISO / IEC 8073, декабрь 1988 г. [L99] Райнер Людвиг, Пример использования беспроводных каналов с адаптацией потока, Технический отчет UCB // CSD-99-1053, май 1999 г.URL "http://iceberg.cs.berkeley.edu/papers/Ludwig- FlowAdaptive / ". [LK00] Райнер Людвиг и Рэнди Х. Кац, Алгоритм Эйфеля: Обеспечение устойчивости TCP к ложным повторным передачам, SIGCOMM Обзор компьютерных коммуникаций, т. 30, № 1, январь 2000 г. URL "http://www.acm.org/sigcomm/ccr/archive/ccr-toc/ccr- toc-2000.html ". [RFC1323] Якобсон, В., Брейден, Р. и Д. Борман, "Расширения TCP для Высокая производительность », RFC 1323, май 1992 г.[RFC2018] Mathis, M., Mahdavi, J., Floyd, S. и A. Romanow, "TCP Варианты выборочного подтверждения ", RFC 2018, апрель 1996 г. [RFC2581] Оллман, М., Паксон, В. и У. Стивенс, "Перегрузка TCP. Control », RFC 2581, апрель 1999 г. [SCWA99] Стефан Сэвидж, Нил Кардуэлл, Дэвид Ветералл, Том Андерсон, Контроль перегрузки TCP с неправильным поведением Ресивер, ACM Computer Communications Review, стр. 71-78, V. 29, № 5, октябрь 1999 г. URL "http: // www.acm.org/sigcomm/ccr/archive/ccr-toc/ccr-toc- 99.html ". Флойд и др. Стандарты Track [Страница 15] 
 RFC 2883 SACK Extension, июль 2000 г. Адреса авторов Салли Флойд Центр интернет-исследований AT&T при ICSI (ACIRI) Телефон: +1 510-666-6989 Электронная почта: [email protected] URL: http://www.aciri.org/floyd/ Джамшид Махдави Novell Телефон: 1-408-967-3806 Электронная почта: mahdavi @ novell.com Мэтт Мэтис Питтсбургский суперкомпьютерный центр Телефон: 412 268-3319 Электронная почта: [email protected] URL: http://www.psc.edu/~mathis/ Матвей Подольский UC Berkeley Департамент электротехники и информатики Телефон: 510-649-8914 Электронная почта: [email protected] URL: http://www.eecs.berkeley.edu/~podolsky Флойд и др. Стандарты Track [Страница 16] 
 RFC 2883 SACK Extension, июль 2000 г. Полное заявление об авторских правах Авторское право (C) The Internet Society (2000).Все права защищены. Этот документ и его переводы могут быть скопированы и предоставлены другие и производные работы, которые комментируют или иным образом объясняют это или помочь в его реализации могут быть подготовлены, скопированы, опубликованы и распространяется, полностью или частично, без ограничения каких-либо любезно, при условии, что указанное выше уведомление об авторских правах и этот абзац включены во все такие копии и производные работы. Однако это сам документ не может быть изменен каким-либо образом, например, путем удаления уведомление об авторских правах или ссылки на Internet Society или другие Интернет-организации, за исключением случаев, когда это необходимо для разработки Интернет-стандартов, в этом случае процедуры для авторские права, определенные в процессе разработки стандартов Интернета, должны быть следовали, или по мере необходимости перевести его на другие языки, кроме Английский.Ограниченные разрешения, предоставленные выше, являются бессрочными и не будут аннулировано Интернет-сообществом, его правопреемниками или правопреемниками. Этот документ и содержащаяся в нем информация размещены на Основа "КАК ЕСТЬ" и ИНТЕРНЕТ-ОБЩЕСТВО И ИНТЕРНЕТ-ИНЖИНИРИНГ TASK FORCE ОТКАЗЫВАЕТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ НО НЕ ОГРАНИЧИВАЕТСЯ НИКАКОЙ ГАРАНТИЕЙ, ЧТО ИСПОЛЬЗОВАНИЕ ИНФОРМАЦИИ ЗДЕСЬ НЕ НАРУШАЕТ НИКАКИХ ПРАВ ИЛИ ПОДРАЗУМЕВАЕМЫХ ГАРАНТИЙ КОММЕРЧЕСКАЯ ЦЕННОСТЬ ИЛИ ПРИГОДНОСТЬ ДЛЯ ОПРЕДЕЛЕННОЙ ЦЕЛИ.Подтверждение Финансирование функции редактора RFC в настоящее время обеспечивается Интернет-общество. Флойд и др. Стандарты Track [стр. 17]

Разметка HTML, созданная rfcmarkup 1.129d, доступная по адресу https://tools.ietf.org/tools/rfcmarkup/ .

java — различение повторяющихся строк в таблице sqlite

Переполнение стека
  1. Около
  2. Продукты
  3. Для команд
  1. Переполнение стека Общественные вопросы и ответы
  2. Переполнение стека для команд Где разработчики и технологи делятся частными знаниями с коллегами
  3. Вакансии Программирование и связанные с ним технические возможности карьерного роста
.

Как удалить дубликаты из таблицы в SQL Server — Статьи TechNet — США (английский)

Дубликаты данных в файле Excel, который вы получаете, — это повседневная проблема. Это нормально, если у нас есть 10 записей данных в файле, который мы получаем, и только 2 из них являются дубликатами. Это будет небольшая ручная работа, чтобы удалить эти две повторяющиеся записи в файле, а затем ETL (извлечение, преобразование и загрузка) данных в базу данных SQL Server с помощью SSIS. Щелкните здесь, чтобы просмотреть пошаговые инструкции, если вы не знаете, как обрабатывать данные ETL с помощью SSIS.Чтобы лучше понять и поработать над этой задачей, давайте создадим таблицу с именем Persons и несколько примеров данных в ней с дубликатами.
 
  СОЗДАТЬ   ТАБЛИЦА   Лица ( 
 
    Имя   варчар   (50)   НЕ   NULL  ,  
 
  0004               NOT   NULL  ,  
 
    [State]   char   (2)   NOT   NULL  
 
 )  
4  IN    IN (  Имя  , Город, [Штат])   ЗНАЧЕНИЯ   (  'John'  ,   'Dallas'  ,   'TX'  )  0 IN   INTO   человек (  Имя  , город, [штат])   ЗНАЧЕНИЯ   (  'Марка'  ,   ' Сиэтл ' ,  ' WA ' )   
  INSERT   INTO   Лица (  Имя  , город, [штат])   ЗНАЧЕНИЕ     (  ) ,   'Phoenix'  ,   'AZ'  )  
 
  INSERT   INTO   Лица (  Имя  , Город, [Область])    VALUES Laila ' ,  ' San Jose ' ,  ' CA ' )  
 
  INSERT   INTO   Лица (  Имя  , Город,  VAL0005ES )  (  'Samantha'  ,   'Tulsa'  ,   'OK'  )  
 
  INSERT   INTO   человек (  Название штата)    ЗНАЧЕНИЯ   (  'Bella'  ,   'San Antonio' ​​ ,   'TX'  )  
 
  INSERT   INTO   [  Лица ( ) State])   ЗНАЧЕНИЯ   (  'John'  ,   'Dallas'  ,   'TX'  )  
 Имя 
  INSERT    INTO    , Город, [штат])   ЗНАЧЕНИЯ   (  'John'  ,   'Dallas'  ,   'TX'  )  
 
  INSERT   INTO   INTO  Имя  , Город, [Штат])   ЗНАЧЕНИЯ   (  'Марка'  ,   'Сиэтл'  ,   'WA'  )  
 
  INTO 0004 INTO  Лица (  Имя  , Город, [Штат])   ЗНАЧЕНИЯ   (  'Nick'  ,   'Tempe'  ,   'FL'  
)  0 IN  0 IN  INTO   Лица (  Имя  , Город, [Штат])   ЗНАЧЕНИЯ   (  'John'  ,   'Dallas'  ,   'TX4'   'TX4'  
 
  SELECT   *   ИЗ   человек

Если вы посмотрите на данные, в них много дубликатов.Имена Джона и Марка многократно повторялись в данных. Теперь давайте напишем запрос, который использует функцию ROW NUMBER и присваивает всем повторяющимся значениям ранг 2, 3 и так далее. Щелкните здесь , чтобы узнать больше о функциях ранжирования.
 
  SELECT   Имя  
 
   , Город  
 
   , [Штат]  
 
   , НОМЕР РЯДА () НАВЕРХ (РАЗДЕЛ   BY Государство]   ЗАКАЗ   BY   [  Название  ])   AS   Rnum  
 
  ОТ   Лица
Помните, что предложение ORDER BY обязательно в функции ранжирования.Результат, установленный после использования функции ранжирования, будет выглядеть, как показано ниже, со всеми рангами, определенными как 1 для уникальных значений, и всеми дубликатами со значениями больше 1.

Теперь давайте напишем запрос, который удалит все повторяющиеся данные за один раз. Для этой цели мы будем использовать CTE (общее табличное выражение). В следующих статьях мы прочитаем, что такое CTE и почему он используется. На более легкой ноте CTE можно представить как эквивалент временные наборы результатов, которые могут использоваться только в базовых инструкциях SELECT, INSERT, UPDATE, DELETE или CREATE VIEW.

 
 ;   С   CTE   AS  
 
  ( 
 
  SELECT   Имя  
 
   , город  
 
   0004 9000_NO 
  0004 
 9000_N    
 9000_N (штат) НАВЕРХ (ПОДРАЗДЕЛЕНИЕ 
  BY   Имя  , Город, [Штат]   ЗАКАЗ   BY   [  Имя  ])   AS   Rnum  
    
 )  
 
  УДАЛИТЬ   ИЗ   CTE   ГДЕ   Rnum  1
В коде, говоря WHERE Rnum 1 , мы просим SQL Server сохранять все записи с рангом 1, которые не являются дубликатами, и удалять любые другие записи.После выполнения этого запроса в SQL Server Management Studio вы не получите дубликаты в вашей таблице. Чтобы убедиться в этом, просто запустите простой запрос к своей таблице.


.

python удаляет дубликаты из 2 списков

Переполнение стека
  1. Около
  2. Продукты
  3. Для команд
  1. Переполнение стека Общественные вопросы и ответы
  2. Переполнение стека для команд Где разработчики и технологи делятся частными знаниями с коллегами
  3. Вакансии Программирование и связанные с ним технические возможности карьерного роста
  4. Талант Нанимайте технических специалистов и создавайте свой бренд работодателя
  5. Реклама Обратитесь к разработчикам и технологам со всего мира
  6. О компании

Загрузка…

.

Найдите и удалите дубликаты — Excel

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

  1. Выберите ячейки, которые нужно проверить на наличие дубликатов.

    Примечание. Excel не может выделять дубликаты в области значений отчета сводной таблицы.

  2. Щелкните Домой > Условное форматирование > Правила выделения ячеек > Повторяющиеся значения .

  3. В поле рядом с значениями с выберите форматирование, которое вы хотите применить к повторяющимся значениям, а затем нажмите ОК .

Удалить повторяющиеся значения

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

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

  2. Щелкните Data > Remove Duplicates , а затем в разделе Columns установите или снимите отметку со столбцами, в которых вы хотите удалить дубликаты.

    Например, на этом листе столбец за январь содержит информацию о ценах, которую я хочу сохранить.

    Итак, я снял отметку января в поле Удалить дубликаты .

  3. Щелкните ОК .

.

Дубликат ПТС — что это? Стоит ли бояться покупки?

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

В отделении автоинспекции предоставляют замену ПТС с обновленным списком зарегистрированных владельцев. Здесь не прописываются все собственники автомобиля, только последний, который получил дубликат паспорта ТС на руки. Поэтому узнать количество реальных владельцев не получится. Возникает логичный вопрос: не пытается ли продавец скрыть таким образом историю автомобиля?

Именно этого и боятся покупатели, когда видят дубликат ПТС. На самом деле нужно подробно разобраться в ситуации. И в первую очередь необходимо найти причину для выдачи дубликата ПТС.

Для этого нужно смотреть на поле сбоку, которое называется «Особые отметки». Не зря оно так названо. Стоит особое внимание уделять записям в этой столбике. Здесь же вы сможете узнать причину, по которой был выдан дубликат. Основание для записи указывает инспектор ГИБДД.

Давайте рассмотрим все причины для получения дубликата ПТС.

Выдача дубликата ПТС по утилизации

В оригинале ПТС содержится всего 6 пустых полей для записи нового собственника автомобиля. Первые 2 обычно могут быть заполнены заводом изготовителем, либо автодилером, который приобретает автомобиль. Остальные поля заполняются данными частных собственников.

Если все строчки будут заполнены, то владелец имеет право получить дубликат ПТС. В этом случае в строке «Особые отметки» будут поставлены печать и запись об утилизации оригинала.

Выдали дубликат ПТС из-за кражи

Бывает такое, что документы выкрадывают из машины, из рук, из дома и т.д. Даже если до этого оригинал ПТС хранился строго в сейфе, то рано или поздно он может попасть в руки к злоумышленникам. В этом случае собственник подает заявление о потере документа.

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

Однако для покупателя важно, чтобы злоумышленники не использовали оригинал ПТС для создания «двойника» авто. Узнать об этом новому собственнику получится, когда придет повестка в прокуратуру и начнется выяснение обстоятельств. Дубликат ПТС в этом случае может принести лишние хлопоты.

 

 Выдача дубликата ПТС по потере оригинала

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

Паспорт транспортного средства – это важнейший документ, в котором собраны все сведения об автомобиле: его цвет, мощность, идентификационный номер и прочее, а также информация о производителе и всех предыдущих владельцах. Документ имеет несколько ступеней защиты в виде водяных знаков, голограмм и объемных изображений. Если этот документ утерян, то можно оформить дубликат. Этой возможностью нередко пользуются мошенники. Покупателям подержанных автомобилей необходимо знать, как отличить дубликат ПТС от оригинала.

Читайте также: Как и какими способами оплачивать платную парковку

Причины выдачи дубликата

Получить дубликат можно всего в трех случаях:

  1. Документ серьезно поврежден или вовсе утерян.
  2. Собственник сменил паспортные данные либо имеет новую прописку.
  3. В паспорте закончились свободные графы для внесения сведений о новых владельцах.

Нередко аферисты подают заявление в МРЭО, что ПТС потерян, а на самом деле документ хранится в банке, поскольку автомобиль является залогом либо вообще кредит за транспорт не погашен. Купив такое авто, новый владелец, вероятнее всего, лишится приобретения согласно судебному решению. Чтобы избежать подобной участи, необходимо знать, чем отличается оригинальный ПТС от дубликата и как его распознать. Неоригинальный паспорт особенно будет отличаться от первичного надписью «Дубликат» в верхней части.

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

Как отличить оригинал ПТС от копии

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

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

  1. На копии выданной МРЭО будет отметка со штампом «Дубликат».
  2. В качестве защиты от подделки – как на оригинальном документе, так и на дубликате – присутствуют особые элементы, в обоих случаях они одинаковые. Обязательно должны присутствовать защитные знаки в виде объемного текста, голограммы и водяного знака. В документе, изготовленном кустарным методом, символы будут безупречными, в оригинале же есть некоторые неровности, что и указывает на подлинность.
  3. Также при покупке подержанного автомобиля должен насторожить безупречный вид паспорта транспортного средства, поскольку за время пользования им на документе обычно возникают различные потертости и незначительные повреждения.

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

  1. Слишком большой перечень предыдущих владельцев. Таким образом злоумышленники пытаются запутать следы того, что автомобиль угнан или же на нем перебиты регистрационные номера.
  2. Если в паспорте транспортного средства внесен регион, значительно отдаленный от места продажи.
  3. Если покупается иномарка, то в ПТС обязательно должна быть специальная таможенная отметка, в противном случае могут возникнуть проблемы.
  4. Лучше отказаться от сделки, если автомобиль довольно новый, но вместо оригинала покупателю представляют дубликат ПТС.
  5. Не покупать автомобиль с дубликатом через посредников либо автосалоны с сомнительной репутацией, поскольку такая машина может оказаться кредитной.
  6. Также подозрение должно возникнуть, если явно хорошее транспортное средство в отличном состоянии продается по значительно заниженной стоимости.

Признаки подделки ПТС

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

  • голограмма в оригинальном документе ярче, а звездочки – более мелкие; подделка, в свою очередь, будет тусклой и не станет отражаться под всеми углами;
  • водяные знаки в настоящем паспорте немного размытые, а в подделке они имеют безупречную форму;
  • редко на каком фальшивом документе рельефное изображение будет ощущаться при касании;
  • бумага на оригинале на ощупь напоминает денежную бумагу, поддельная окажется более гладкой.

Чтобы не попасться на ловушку мошенников, необходимо максимально внимательно отнестись к проверке документов. При возникновении малейшего сомнения лучше не заключать сделку, ведь покупая автомобиль в «подарок», можно получить кредит прежнего собственника или вообще остаться ни с чем в случае изъятия машины согласно судебному решению.

Внимание! В рамках нашего портала вы можете бесплатно получить консультацию профессионального юриста. Все, что вам нужно сделать, это оставить свой вопрос в форме ниже. Обращайтесь!

rfc2883 

 Сетевая рабочая группа С. Флойд
Запрос комментариев: 2883 ACIRI
Категория: Стандарты трассы Дж. Махдави
                                                                  Novell
                                                               М. Матис
                                        Питтсбургский суперкомпьютерный центр
                                                             М.Подольский
                                                             Калифорнийский университет в Беркли
                                                               Июль 2000 г.


  Расширение опции выборочного подтверждения (SACK) для TCP

Статус этого меморандума

   Этот документ определяет протокол отслеживания стандартов Интернета для
   Интернет-сообщество и просит обсуждения и предложения по
   улучшения. Пожалуйста, обратитесь к текущему выпуску "Интернет
   Официальные стандарты протокола »(STD 1) для состояния стандартизации
   и статус этого протокола.Распространение этой памятки не ограничено.

Уведомление об авторских правах

   Авторское право (C) The Internet Society (2000). Все права защищены.

Абстрактный

   В этом примечании определяется расширение выборочного подтверждения.
   (SACK) Вариант [RFC2018] для TCP. RFC 2018 определил использование
   Опция SACK для подтверждения данных вне очереди, не охваченных
   Поле совокупного подтверждения TCP. Это примечание расширяет RFC 2018
   указав использование опции SACK для подтверждения дублирования
   пакеты.Это примечание предполагает, что когда дублирующиеся пакеты
   получен, первый блок поля опции SACK может использоваться для
   сообщить порядковые номера пакета, вызвавшего
   подтверждение. Это расширение опции SACK позволяет TCP
   отправитель, чтобы вывести порядок пакетов, полученных получателем,
   позволяя отправителю сделать вывод, когда он без необходимости повторно передал
   пакет. Отправитель TCP может затем использовать эту информацию для получения дополнительных сведений.
   надежная работа в среде переупорядоченных пакетов [BPS99], ACK
   потеря, репликация пакетов и / или тайм-ауты ранней повторной передачи.1. Условные обозначения и сокращения

   Ключевые слова ДОЛЖНЫ, НЕ ДОЛЖНЫ, НЕОБХОДИМЫ, НЕ ДОЛЖНЫ, НЕ ДОЛЖНЫ,
   НЕ ДОЛЖЕН, РЕКОМЕНДУЕТСЯ, МОЖЕТ и НЕОБЯЗАТЕЛЬНО, когда они появляются в этом
   документ, следует интерпретировать, как описано в [B97].




Флойд и др. Стандарты Track [Страница 1] 
RFC 2883 SACK Extension, июль 2000 г.


2. Введение

   Опция выборочного подтверждения (SACK), определенная в RFC 2018:
   используется получателем данных TCP для подтверждения несмежных блоков
   данные, не включенные в поле «Кумулятивное подтверждение».Тем не мение,
   RFC 2018 не определяет использование опции SACK при дублировании
   сегменты получены. Это примечание определяет использование SACK
   опция при подтверждении получения дублированного пакета [F99].
   Мы используем термин D-SACK (от duplicate-SACK) для обозначения блока SACK.
   который сообщает о повторяющемся сегменте.

   Этот документ не вносит никаких изменений в использование TCP
   кумулятивное поле подтверждения или по решению получателя TCP
   of * when * для отправки пакета подтверждения.Только этот документ
   касается содержимого опции SACK, когда подтверждение
   послал.

   Это расширение совместимо с текущими реализациями SACK.
   вариант в птс. То есть, если один из конечных узлов TCP не
   реализовать это расширение D-SACK и другой конечный узел TCP, мы
   считают, что это использование расширения D-SACK одним из конечных узлов
   не доставит проблем.

   Использование D-SACK не требует отдельного согласования между TCP.
   отправитель и получатель, которые уже согласовали возможность SACK.Отсутствие отдельного согласования для D-SACK означает, что TCP
   получатель может отправлять блоки D-SACK, когда отправитель TCP не
   понимать это расширение для SACK. В этом случае отправитель TCP будет
   просто отбросьте любые блоки D-SACK и обработайте другие блоки SACK
   в поле опции SACK, как обычно.





















Флойд и др. Стандарты Track [Страница 2] 
RFC 2883 SACK Extension, июль 2000 г.


3.Формат опций мешка, как определено в RFC 2018

   Опция SACK, как определено в RFC 2018, выглядит следующим образом:

                            + -------- + -------- +
                            | Вид = 5 | Длина |
          + -------- + -------- + -------- + -------- +
          | Левый край 1-го блока |
          + -------- + -------- + -------- + -------- +
          | Правый край 1-го блока |
          + -------- + -------- + -------- + -------- +
          | |
          /.. . /
          | |
          + -------- + -------- + -------- + -------- +
          | Левый край n-го блока |
          + -------- + -------- + -------- + -------- +
          | Правый край n-го блока |
          + -------- + -------- + -------- + -------- +

   Параметр выборочного подтверждения (SACK) в заголовке TCP
   содержит несколько блоков SACK, где каждый блок определяет левый
   и правый край блока данных, полученных на приемнике TCP.В
   в частности, блок представляет собой непрерывное пространство последовательности данных
   получил и поставил в очередь у получателя, где "левый край"
   block - это первый порядковый номер блока, а «правый край»
   порядковый номер, следующий сразу за последним порядковым номером
   блока.

   RFC 2018 подразумевает, что первый блок SACK определяет сегмент, который
   вызвало подтверждение. Из RFC 2018, когда получатель данных
   выбирает отправку опции SACK, "первый блок SACK... ДОЛЖЕН указать
   непрерывный блок данных, содержащий сегмент, который запустил
   этот ACK, если этот сегмент не продвинул номер подтверждения
   поле в заголовке ".

   Однако RFC 2018 не рассматривает использование опции SACK, когда
   подтверждение дублирующегося сегмента. Например, RFC 2018 указывает
   что "каждый блок представляет полученные байты данных, которые
   смежные и изолированные ". RFC 2018 дополнительно уточняет, что" если отправлено
   вообще, параметры SACK ДОЛЖНЫ быть включены во все ACK, которые не ACK
   наивысший порядковый номер в очереди получателя данных.«RFC 2018
   не указывает использование опции SACK, когда дублирующийся сегмент
   получено, и поле совокупного подтверждения в ACK
   подтверждает все данные в очереди получателя данных.






Флойд и др. Стандарты Track [Страница 3] 
RFC 2883 SACK Extension, июль 2000 г.


4. Использование опции SACK для сообщения о повторяющемся сегменте.

   В этом разделе описывается использование блоков SACK, когда параметр SACK установлен.
   используется при сообщении о повторяющемся сегменте.Когда используется D-SACK,
   первым блоком опции SACK должен быть блок D-SACK, определяющий
   порядковые номера для повторяющегося сегмента, который запускает
   подтверждение. Если повторяющийся сегмент является частью большего блока
   несмежных данных в очереди данных получателя, то
   следующий блок SACK должен использоваться для указания этого большего блока.
   Дополнительные блоки SACK могут использоваться для указания дополнительных не-
   непрерывные блоки данных, как указано в RFC 2018.

   Рекомендации по сообщению о повторяющихся сегментах кратко изложены ниже:

   (1) Блок D-SACK используется только для сообщения о повторяющихся смежных
   последовательность данных, полученных получателем в самом последнем пакете.(2) Сообщается о каждой повторяющейся непрерывной последовательности полученных данных.
   не более чем в одном блоке D-SACK. (Т.е. получатель отправляет два одинаковых
   D-SACK блокируется в последующих пакетах только в том случае, если получатель получает два
   повторяющиеся сегменты.)

   (3) Левый край блока D-SACK определяет первую последовательность
   номер повторяющейся непрерывной последовательности, а правый край
   блок D-SACK определяет порядковый номер сразу после
   последняя последовательность в повторяющейся непрерывной последовательности.(4) Если блок D-SACK сообщает о повторяющейся непрерывной последовательности из
   (возможно, больший) блок данных в очереди данных получателя выше
   совокупное подтверждение, затем второй блок SACK в этом
   Параметр SACK должен указывать этот (возможно, больший) блок данных.

   (5) Следуя блокам SACK, описанным выше, для сообщения о дубликатах
   сегментов, дополнительные блоки SACK могут использоваться для отчетов о дополнительных
   блоки данных, как указано в RFC 2018.

   Обратите внимание: поскольку каждый повторяющийся сегмент сообщается только в одном ACK
   пакет, информация об этом повторяющемся сегменте будет потеряна, если этот
   Пакет ACK отброшен в сети.4.1 Сообщение о полных повторяющихся сегментах

   Мы проиллюстрируем эти рекомендации тремя примерами. В каждом примере
   мы предполагаем, что получатель данных сначала получил восемь сегментов
   500 байт каждый и отправил подтверждение с совокупным
   поле подтверждения установлено на 4000 (при условии, что первый порядковый номер
   равен нулю). Блок D-SACK подчеркнут в каждом примере.




Флойд и др. Стандарты Track [Страница 4] 
RFC 2883 SACK Extension, июль 2000 г.


4.1.1. Пример 1. Сообщение о повторяющемся сегменте.

   Поскольку несколько пакетов ACK потеряны, отправитель данных повторно передает
   пакет 3000-3499, и получатель данных впоследствии получает
   повторяющийся сегмент с порядковыми номерами 3000-3499. Получатель
   отправляет подтверждение с полем совокупного подтверждения
   установлен на 4000, и первый блок D-SACK, определяющий порядковые номера
   3000-3500.

        Передано Получено ACK Отправлено
        Сегментный сегмент (включая блоки SACK)

        3000-3499 3000-3499 3500 (ACK сброшен)
        3500-3999 3500-3999 4000 (ACK сброшен)
        3000-3499 3000-3499 4000, SACK = 3000-3500
                                              ---------
4.1.2. Пример 2. Сообщение о неупорядоченном сегменте и его дубликате.
        сегмент.

   После потери пакета данных получатель получает сообщение не по порядку.
   сегмент данных, который запускает опцию SACK, как указано в RFC
   2018. Из-за потери нескольких пакетов ACK отправитель
   повторно передает пакет данных. Получатель получает дубликат
   пакет, и сообщает об этом в первом блоке D-SACK:

        Передано Получено ACK Отправлено
        Сегментный сегмент (включая блоки SACK)

        3000-3499 3000-3499 3500 (ACK сброшен)
        3500-3999 3500-3999 4000 (ACK сброшен)
        4000-4499 (пакет данных отброшен)
        4500-4999 4500-4999 4000, SACK = 4500-5000 (ACK сброшен)
        3000-3499 3000-3499 4000, SACK = 3000-3500, 4500-5000
                                                 ---------

















Флойд и др.Стандарты Track [Страница 5] 
RFC 2883 SACK Extension, июль 2000 г.


4.1.3. Пример 3: Сообщение о дубликате неупорядоченного сегмента.

   Из-за потерянного пакета данных приемник получает два вышедших из строя
   сегменты. Затем получатель получает дубликат сегмента для одного из
   эти вышедшие из строя сегменты:

        Передано Получено ACK Отправлено
        Сегментный сегмент (включая блоки SACK)

        3500–3999 3500–3999 4000
        4000-4499 (пакет данных отброшен)
        4500-4999 4500-4999 4000, SACK = 4500-5000
        5000-5499 5000-5499 4000, SACK = 4500-5500
                       (дублированный пакет)
                       5000-5499 4000, SACK = 5000-5500, 4500-5500
                                              ---------
4.2. Сообщение о частичных повторяющихся сегментах

   Возможно, отправитель передает пакет, содержащий один
   или несколько повторяющихся подсегментов - то есть только часть, но не все
   переданный пакет уже прибыл к получателю. Это может
   возникают, когда размер передаваемых сегментов отправителя увеличивается,
   что может произойти, когда PMTU увеличивается в середине TCP
   сеанс, например. Рекомендации в Разделе 4 выше применимы к
   отчет о частичных и полных повторяющихся сегментах.Эта секция
   приводит примеры этих рекомендаций при сообщении о частичном дублировании
   сегменты.

   Когда опция SACK используется для сообщения о частичном дублировании
   сегментов, первый блок D-SACK сообщает о первом повторяющемся под-
   сегмент. Если подтверждаемый пакет данных содержит несколько
   частичные дубликаты подсегментов, затем только первый такой дубликат
   подсегмент сообщается в опции SACK. Мы проиллюстрируем это с помощью
   примеры ниже.

4.2.1. Пример 4: Отчет об одном повторяющемся подсегменте.Отправитель увеличивает размер пакета с 500 до 1000 байтов.
   Получатель впоследствии получает 1000-байтовый пакет, содержащий один
   500-байтный подсегмент, который уже был получен, и тот, который
   нет. Получатель сообщает только об уже полученном подсегменте, используя
   один блок D-SACK.









Флойд и др. Стандарты Track [Страница 6] 
RFC 2883 SACK Extension, июль 2000 г.


        Передано Получено ACK Отправлено
        Сегментный сегмент (включая блоки SACK)

        500-999 500-999 1000
        1000-1499 (с задержкой)
        1500-1999 (пакет данных отброшен)
        2000-2499 2000-2499 1000, SACK = 2000-2500
        1000-2000 1000-1499 1500, SACK = 2000-2500
                       1000-2000 2500, SACK = 1000-1500
                                              ---------

4.2.2. Пример 5: Два несмежных повторяющихся подсегмента, охватываемых
        совокупное признание.

   После того, как отправитель увеличивает размер своего пакета с 500 до 1500 байтов
   байтов, получатель получает пакет, содержащий два несмежных
   дублировать подсегменты размером 500 байт, которые меньше совокупного
   поле подтверждения. Получатель сообщает о первом таком дубликате.
   сегмент в одном блоке D-SACK.

         Передано Получено ACK Отправлено
         Сегментный сегмент (включая блоки SACK)

         500-999 500-999 1000
         1000-1499 (с задержкой)
         1500-1999 (пакет данных отброшен)
         2000-2499 (задержано)
         2500-2999 (пакет данных отброшен)
         3000-3499 3000-3499 1000, SACK = 3000-3500
         1000-2499 1000-1499 1500, SACK = 3000-3500
                        2000-2499 1500, SACK = 2000-2500, 3000-3500
                        1000-2499 2500, SACK = 1000-1500, 3000-3500
                                               ---------

4.2.3. Пример 6: Два несмежных повторяющихся подсегмента не охвачены
        совокупным признанием.

   Этот пример аналогичен примеру 5, за исключением того, что после отправителя
   увеличивает размер пакета, получатель получает пакет, содержащий
   два несмежных повторяющихся подсегмента, которые находятся над
   поле совокупного подтверждения, а не ниже. Первый, D-
   Блок SACK сообщает о первом повторяющемся подотрезке, а второй,
   Блок SACK сообщает о большем блоке несмежных данных, который он
   принадлежит.Флойд и др. Стандарты Track [Страница 7] 
RFC 2883 SACK Extension, июль 2000 г.


         Передано Получено ACK Отправлено
         Сегментный сегмент (включая блоки SACK)

         500-999 500-999 1000
         1000-1499 (пакет данных отброшен)
         1500-1999 (с задержкой)
         2000-2499 (пакет данных отброшен)
         2500-2999 (с задержкой)
         3000-3499 (пакет данных отброшен)
         3500-3999 3500-3999 1000, SACK = 3500-4000
         1000-1499 (пакет данных отброшен)
         1500-2999 1500-1999 1000, SACK = 1500-2000, 3500-4000
                        2000-2499 1000, SACK = 2000-2500, 1500-2000,
                                            3500–4000
                        1500-2999 1000, SACK = 1500-2000, 1500-3000,
                                               ---------
                                            3500–4000

4.3. Взаимодействие между D-SACK и PAWS

   RFC 1323 [RFC1323] определяет алгоритм защиты от
   Обернутые порядковые номера (PAWS). PAWS дает метод для
   различение порядковых номеров для новых данных и последовательности
   числа из предыдущего цикла через пространство порядковых номеров.
   Дублирующиеся сегменты могут быть обнаружены PAWS как принадлежащие
   предыдущий цикл через пространство порядковых номеров.

   RFC 1323 указывает, что для таких пакетов получатель должен выполнять
   следующий:

      Отправьте подтверждение в ответ, как указано в RFC 793, стр. 69,
      и отбросьте сегмент.Поскольку PAWS по-прежнему требует отправки ACK, вредных
   взаимодействие между PAWS и использование D-SACK. Блок D-SACK может
   быть включенным в опцию SACK ACK, как описано в Разделе 4,
   независимо от использования PAWS получателем TCP, и
   независимо от определения PAWS действительности или
   недействительность сегмента данных.

   Отправители TCP, получающие блоки D-SACK, должны знать, что сегмент
   сообщается как повторяющийся сегмент, возможно, из предыдущего
   прокрутите пространство порядковых номеров.Это не зависит от
   использование PAWS получателем данных TCP. Мы не ожидаем, что это
   создаст серьезные проблемы для отправителей, использующих D-SACK
   Информация.





Флойд и др. Стандарты Track [Страница 8] 
RFC 2883 SACK Extension, июль 2000 г.


5. Обнаружение повторяющихся пакетов

   Это расширение опции SACK позволяет приемнику точно
   сообщить о приеме дублирующих данных.Потому что каждое получение
   о дублированном пакете сообщается только в одном пакете ACK, потеря
   одиночный ACK может помешать этой информации достичь отправителя. В
   Кроме того, отметим, что отправитель не обязательно может доверять
   получатель, чтобы отправить ему точную информацию [SCWA99].

   Чтобы отправитель мог проверить, что первый блок (D) SACK
   подтверждение фактически подтверждает дублирование данных, отправитель
   должен сравнить пространство последовательности в первом блоке SACK с
   совокупный ACK, который хранится В ОДНОМ ПАКЕТЕ.Если SACK
   пространство последовательности меньше, чем этот совокупный ACK, это показатель
   что сегмент, идентифицированный блоком SACK, был получен больше
   чем один раз получателем. Реализация НЕ ДОЛЖНА сравнивать
   пространство последовательности в блоке SACK до переменной состояния TCP snd.una
   (который несет общий совокупный ACK), так как это может привести к
   неправильный вывод, если пакеты ACK переупорядочены.

   Если пространство последовательности в первом блоке SACK больше, чем
   совокупный ACK, затем отправитель сравнивает пространство последовательности в
   первый блок SACK с пространством последовательности во втором SACK
   блок, если он есть.Это сравнение может определить,
   Блок SACK сообщает о повторяющихся данных, которые лежат выше совокупного
   ACK.

   Реализации TCP, следующие за RFC 2581 [RFC2581], могли видеть
   повторяющиеся пакеты в каждой из следующих четырех ситуаций. Этот
   документ не указывает, какое действие должна выполнять реализация TCP.
   беру в этих случаях. Расширение опции SACK просто включает
   отправителю для обнаружения каждого из этих случаев. Обратите внимание, что эти четыре
   условия не являются исчерпывающим списком возможных случаев дублирования
   пакеты, но являются типичными для наиболее распространенных / вероятных случаев.В последующих документах будут описаны экспериментальные предложения для отправителя.
   ответы на обнаружение ненужных ретрансляций из-за
   переупорядочение, потеря ACKS или таймауты на раннюю повторную передачу.














Флойд и др. Стандарты Track [Страница 9] 
RFC 2883 SACK Extension, июль 2000 г.


5.1. Репликация по сети

   Если пакет реплицируется в сети, это расширение SACK
   вариант может идентифицировать это.Например:

             Передано Получено ACK Отправлено
             Сегментный сегмент (включая блоки SACK)

             500-999 500-999 1000
             1000-1499 1000-1499 1500
                            (воспроизведено)
                            1000-1499 1500, SACK = 1000-1500
                                                   ---------

   В этом случае второй пакет был реплицирован в сети. An
   ACK, содержащий блок D-SACK, который ниже, чем его поле ACK, и
   не идентичен ранее ретранслированному сегменту является ориентировочным
   репликации по сети.БЕЗ D-SACK:

   Если D-SACK не использовался и последний ACK был совмещен с данными
   пакет, отправитель не узнает, что пакет был реплицирован
   в сети. Если D-SACK не использовался и ни один из двух последних
   ACK были скопированы с пакетом данных, после чего отправитель мог
   разумно сделать вывод, что либо какой-то пакет данных *, либо * окончательный ACK
   пакет был реплицирован в сети. Получение D-SACK
   пакет дает отправителю положительную информацию о том, что этот пакет данных был
   тиражируется в сети (при условии, что получатель не врет).ВОПРОСЫ ИССЛЕДОВАНИЯ:

   Текущая опция SACK уже позволяет отправителю идентифицировать
   дублированные ACK, которые не подтверждают новые данные, но D-SACK
   вариант дает отправителю более веские основания для вывода о том, что
   duplicate ACK не подтверждает новые данные. Знание того, что
   дублирующийся ACK не подтверждает, что новые данные позволяют отправителю
   воздерживаться от использования этих дублированных ACK для вывода о потере пакета (например,
   Fast Retransmit) или для отправки дополнительных данных (например, Fast Recovery).

5.2. Ложная ретрансляция из-за переупорядочения

   Если пакеты переупорядочены в сети так, что прибывает сегмент
   более 3 пакетов вышли из строя, алгоритм TCP Fast Retransmit
   повторно передаст неупорядоченный пакет.Пример этого показан
   ниже:





Флойд и др. Стандарты Track [Страница 10] 
RFC 2883 SACK Extension, июль 2000 г.


             Передано Получено ACK Отправлено
             Сегментный сегмент (включая блоки SACK)

             500-999 500-999 1000
             1000-1499 (с задержкой)
             1500-1999 1500-1999 1000, SACK = 1500-2000
             2000-2499 2000-2499 1000, мешок = 1500-2500
             2500-2999 2500-2999 1000, SACK = 1500-3000
             1000-1499 1000-1499 3000
                            1000-1499 3000, SACK = 1000-1500
                                                   ---------

   В этом случае ACK, содержащий блок SACK, меньший, чем его
   Поле ACK и идентично ранее повторно переданному сегменту
   свидетельствует о значительном переупорядочивании с последующим ложным
   (ненужная) ретрансляция.БЕЗ D-SACK:

   При использовании D-SACK, показанного выше, отправитель знает, что
   либо первая передача сегмента 1000-1499 была задержана в
   сеть, или первая передача сегмента 1000-1499 была прервана
   и вторая передача сегмента 1000-1499 была продублирована.
   Учитывая, что никакие другие сегменты в сети не дублировались,
   второй вариант можно считать маловероятным.

   Без использования D-SACK отправитель будет знать только то, что либо
   первая передача сегмента 1000-1499 была задержана в сети,
   или что либо один из сегментов данных, либо последний ACK был
   дублируется в сети.Таким образом, использование D-SACK позволяет отправителю
   чтобы более надежно заключить, что первая передача сегмента
   1000-1499 не было сброшено.

   [AP99], [L99] и [LK00] отмечают, что отправитель мог однозначно
   обнаружение ненужной повторной передачи с использованием метки времени
   вариант. [LK00] предлагает алгоритм на основе меток времени, который минимизирует
   штраф за ненужную ретрансляцию. [AP99] предлагает
   эвристика для обнаружения ненужной повторной передачи в среде
   без меток времени и SACK.[L99] также предлагает двухбитный
   поле как альтернатива опции отметки времени для однозначно
   маркировка первых трех повторных передач пакета. Похожая идея
   был предложен в [ISO8073].

   ВОПРОСЫ ИССЛЕДОВАНИЯ:

   Использование D-SACK позволяет отправителю обнаруживать некоторые случаи (например, когда
   пакеты ACK не были потеряны), когда быстрая повторная передача была вызвана
   переупорядочивание пакетов вместо потери пакетов. Это позволяет отправителю TCP



Флойд и др. Стандарты Track [Страница 11] 
RFC 2883 SACK Extension, июль 2000 г.


   настроить порог дублирования подтверждений, чтобы предотвратить такие
   ненужные быстрые ретрансляции в будущем.Вместе с этим, когда
   отправитель после факта определяет, что он сделал
   ненужное уменьшение окна, отправитель имеет возможность «отменить»
   это уменьшение окна перегрузки путем сброса ssthresh на
   значение старого окна перегрузки и медленный запуск до
   окно перегрузки достигло этой точки.

   Любое предложение по «отмене» уменьшения окна перегрузки будет
   необходимо учитывать возможность того, что получатель TCP может лгать
   в своих отчетах о полученных пакетах [SCWA99].5.3. Тайм-аут повторной передачи из-за потери ACK

   Если все окно ACK потеряно, произойдет тайм-аут. An
   пример этого приведен ниже:

             Передано Получено ACK Отправлено
             Сегментный сегмент (включая блоки SACK)

             500-999 500-999 1000 (ACK сброшен)
             1000-1499 1000-1499 1500 (ACK сброшен)
             1500-1999 1500-1999 2000 (ACK сброшен)
             2000-2499 2000-2499 2500 (ACK сброшен)
             (тайм-аут)
             500-999 500-999 2500, SACK = 500-1000
                                                   --------

   В этом случае все ACK отбрасываются, что приводит к тайм-ауту.Это состояние можно определить, потому что первый полученный ACK
   после тайм-аута переносится блок D-SACK, указывающий на дублирование
   данные были получены.

   БЕЗ D-SACK:

   Без использования D-SACK отправитель в этом случае не сможет
   решает, что ни один пакет данных не был отброшен.

   ВОПРОСЫ ИССЛЕДОВАНИЯ:

   Для TCP, который реализует некоторую форму управления перегрузкой ACK
   [BPK97], эта способность различать отброшенные пакеты данных и
   отброшенные пакеты ACK были бы особенно полезны.В этом случае
   соединение может реализовать контроль перегрузки для возврата (ACK)
   путь независимо от контроля перегрузки в прямом направлении (данные)
   дорожка.





Флойд и др. Стандарты Track [Страница 12] 
RFC 2883 SACK Extension, июль 2000 г.


5.4. Тайм-аут ранней ретрансляции

   Если RTO отправителя слишком короткое, может произойти тайм-аут ранней повторной передачи.
   возникают, когда в сети фактически не было отброшено ни одного пакета.An
   пример этого приведен ниже:

             Передано Получено ACK Отправлено
             Сегментный сегмент (включая блоки SACK)

             500-999 (с задержкой)
             1000-1499 (с задержкой)
             1500-1999 (с задержкой)
             2000-2499 (задержано)
             (тайм-аут)
             500-999 (с задержкой)
                            500–999 1000
             1000-1499 (с задержкой)
                            1000-1499 1500
             ...
                            1500–1999 2000
                            2000-2499 2500
                            500-999 2500, SACK = 500-1000
                                                   --------
                            1000-1499 2500, SACK = 1000-1500
                                                   ---------
                            ...

   В этом случае первый пакет повторно передается после
   тайм-аут. Впоследствии исходное окно пакетов поступает на
   получатель, в результате чего для этих сегментов будут получены ACK.После этого
   поступают повторные передачи этих сегментов, в результате чего ACK переносят
   Блоки SACK, которые идентифицируют повторяющиеся сегменты.

   Это можно определить как тайм-аут ранней повторной передачи, потому что
   ACK для байта 1000 получен после тайм-аута без SACK
   информация, за которой следует ACK, который несет информацию SACK (500-
   999), указывая, что ретранслируемый сегмент уже был
   полученный.

   БЕЗ D-SACK:

   Если D-SACK не использовался и один из дублирующих ACK был совмещен
   в пакете данных отправитель не знает, сколько дубликатов
   пакеты были получены.Если D-SACK не использовался и ни один из
   дублирующиеся ACK были скопированы с пакетом данных, затем отправитель
   отправил бы N повторяющихся пакетов для некоторого N и получил бы N
   дубликаты ACK. В этом случае отправитель мог разумно предположить, что




Флойд и др. Стандарты Track [Страница 13] 
RFC 2883 SACK Extension, июль 2000 г.


   некоторые данные или пакет ACK были реплицированы в сети, или что
   истек тайм-аут ранней повторной передачи (или что получатель
   врущий).ВОПРОСЫ ИССЛЕДОВАНИЯ:

   После того, как отправитель определит, что ненужный (т. Е. Преждевременный)
   истекло время ожидания повторной передачи, отправитель может настроить параметры
   для установки RTO, чтобы избежать ненужных тайм-аутов повторной передачи.
   Вместе с тем, когда отправитель определяет постфактум, что
   он произвел ненужное сокращение окна, отправитель имеет
   возможность «отмены» этого уменьшения окна перегрузки.

6. Соображения безопасности

   Этот документ не усиливает и не ослабляет текущую безопасность TCP.
   характеристики.7. Благодарности

   Мы хотели бы поблагодарить Марка Хэндли, Райнера Людвига и Венката.
   Падманабхану за беседы по этим вопросам и поблагодарить Марка
   Аллману за полезные отзывы об этом документе.

8. Ссылки

   [AP99] Марк Аллман и Верн Паксон, об оценке сквозных операций
             Свойства сетевого пути, SIGCOMM 99, август 1999 г. URL
             "http://www.acm.org/sigcomm/sigcomm99/papers/session7-
             3.html ".

   [BPS99] J.C.R. Беннет, К. Партридж и Н. Шектман, Packet
             Изменение порядка не является патологическим поведением сети, IEEE / ACM
             Транзакции в сети, Vol.7, No. 6, декабрь 1999 г.,
             С. 789-798.

   [BPK97] Хари Балакришнан, Венката Падманабхан и Рэнди Х. Кац,
             Влияние асимметрии на производительность TCP, третий ACM / IEEE
             Конференция Mobicom, Будапешт, Венгрия, сентябрь 1997 г. URL
             "http://www.cs.berkeley.edu/~padmanab/
             index.html # Публикации ".

   [F99] Флойд, С., Re: TCP и доставка вне очереди, идентификатор сообщения
             <199
[email protected]> на сквозной
             Список рассылки по интересам, февраль 1999 г.URL
             "http://www.aciri.org/floyd/notes/TCP_Feb99.email".





Флойд и др. Стандарты Track [Страница 14] 
RFC 2883 SACK Extension, июль 2000 г.


   [ISO8073] ISO / IEC, Системы обработки информации - Открытые системы
             Межсоединение - транспортный протокол, ориентированный на соединение
             Спецификация, международный стандарт ISO / IEC 8073, декабрь
             1988 г.

   [L99] Райнер Людвиг, Пример использования беспроводных каналов с адаптивным потоком,
             Технический отчет UCB // CSD-99-1053, май 1999 г.URL
             "http://iceberg.cs.berkeley.edu/papers/Ludwig-
             FlowAdaptive / ".

   [LK00] Райнер Людвиг и Рэнди Х. Кац, Алгоритм Эйфеля:
             Обеспечение устойчивости TCP к ложным повторным передачам, SIGCOMM
             Обзор компьютерных коммуникаций, т. 30, № 1, январь 2000 г.
             URL "http://www.acm.org/sigcomm/ccr/archive/ccr-toc/ccr-
             toc-2000.html ".

   [RFC1323] Якобсон, В., Брейден, Р. и Д. Борман, "Расширения TCP для
             Высокая производительность », RFC 1323, май 1992 г.[RFC2018] Mathis, M., Mahdavi, J., Floyd, S. и A. Romanow, "TCP
             Варианты выборочного подтверждения ", RFC 2018, апрель 1996 г.

   [RFC2581] Оллман, М., Паксон, В. и У. Стивенс, "Перегрузка TCP.
             Control », RFC 2581, апрель 1999 г.

   [SCWA99] Стефан Сэвидж, Нил Кардуэлл, Дэвид Ветеролл, Том
             Андерсон, Контроль перегрузки TCP с неправильным поведением
             Ресивер, ACM Computer Communications Review, стр. 71-78, V.
             29, № 5, октябрь 1999 г. URL
             "http: // www.acm.org/sigcomm/ccr/archive/ccr-toc/ccr-toc-
             99.html ".




















Флойд и др. Стандарты Track [Страница 15] 
RFC 2883 SACK Extension, июль 2000 г.


Адреса авторов

   Салли Флойд
   Центр интернет-исследований AT&T при ICSI (ACIRI)

   Телефон: +1 510-666-6989
   Электронная почта: [email protected]
   URL: http://www.aciri.org/floyd/


   Джамшид Махдави
   Novell

   Телефон: 1-408-967-3806
   Электронная почта: mahdavi @ novell.ком


   Мэтт Мэтис
   Питтсбургский суперкомпьютерный центр

   Телефон: 412 268-3319
   Электронная почта: [email protected]
   URL: http://www.psc.edu/~mathis/


   Матвей Подольский
   UC Berkeley Департамент электротехники и информатики

   Телефон: 510-649-8914
   Электронная почта: [email protected]
   URL: http://www.eecs.berkeley.edu/~podolsky




















Флойд и др. Стандарты Track [Страница 16] 
RFC 2883 SACK Extension, июль 2000 г.


Полное заявление об авторских правах

   Авторское право (C) The Internet Society (2000).Все права защищены.

   Этот документ и его переводы могут быть скопированы и предоставлены
   другие и производные работы, которые комментируют или иным образом объясняют это
   или помочь в его реализации могут быть подготовлены, скопированы, опубликованы
   и распространяется, полностью или частично, без ограничения каких-либо
   добрый, при условии, что указанное выше уведомление об авторских правах и этот абзац являются
   включены во все такие копии и производные работы. Однако это
   сам документ не может быть изменен каким-либо образом, например, путем удаления
   уведомление об авторских правах или ссылки на Internet Society или другие
   Интернет-организации, за исключением случаев, когда это необходимо для
   разработки Интернет-стандартов, в этом случае процедуры для
   авторские права, определенные в процессе разработки стандартов Интернета, должны быть
   следовать, или, если требуется, перевести его на другие языки, кроме
   Английский.Ограниченные разрешения, предоставленные выше, являются бессрочными и не будут
   аннулировано Интернет-сообществом, его правопреемниками или правопреемниками.

   Этот документ и содержащаяся в нем информация размещены на
   Основа "КАК ЕСТЬ" и ИНТЕРНЕТ-ОБЩЕСТВО И ИНТЕРНЕТ-ИНЖИНИРИНГ
   TASK FORCE ОТКАЗЫВАЕТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ
   НО НЕ ОГРАНИЧИВАЕТСЯ НИКАКОЙ ГАРАНТИЕЙ, ЧТО ИСПОЛЬЗОВАНИЕ ИНФОРМАЦИИ
   ЗДЕСЬ НЕ НАРУШАЕТ НИКАКИХ ПРАВ ИЛИ ПОДРАЗУМЕВАЕМЫХ ГАРАНТИЙ
   КОММЕРЧЕСКАЯ ЦЕННОСТЬ ИЛИ ПРИГОДНОСТЬ ДЛЯ ОПРЕДЕЛЕННОЙ ЦЕЛИ.Подтверждение

   Финансирование функции редактора RFC в настоящее время обеспечивается
   Интернет-сообщество.



















Флойд и др. Стандарты Track [стр. 17]

tcp — Что произойдет, если сервер получит дублированный SYN для существующего соединения?

Это происходит постоянно, чтобы хост установил несколько подключений к другому хосту (помните, что TCP не имеет клиентов или серверов; клиент / сервер — это концепция уровня приложения, которая здесь не по теме).Как RFC 793, Протокол управления передачей объясняет:

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

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

Все, что делает ваш пример, это пытается создать второе соединение.

Редактировать на основе ваших комментариев и ответа:

Последовательность событий в вашем вопросе не может быть в одном и том же соединении, потому что у вас другой начальный порядковый номер. Как объясняется в приведенной выше цитате RFC в моем ответе, порядковый номер является важной частью соединения, и вы меняете начальный порядковый номер, поэтому он не может быть частью того же соединения. Единственное возможное объяснение состоит в том, что это новое соединение, которое является обычным, или у хоста плохая реализация TCP, или на хосте есть какое-то программирование, которое намеренно пытается испортить TCP, ни одно из них не относится к теме или части теория протокола TCP.

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

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

Теория протокола TCP здесь находится в теме, но вопрос, задающий экстра-теоретический вопрос, не по теме. Что делает конкретная реализация хоста с ошибками (правильная реализация TCP не имеет другого начального порядкового номера для одного и того же соединения) или целенаправленная попытка нарушить TCP, является чем-то для другого сайта SE (либо сайта, специфичного для ОС хоста или Информационная безопасность).

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

Абстрактные

Важно понимать TCP, если вы хотите понять исторические, текущая и будущая архитектура Интернет-протоколов.Самый приложения в Интернете используют TCP, полагаясь на его механизмы, обеспечивающие безопасную доставку данных через ненадежный IP слой ниже. В этой статье мы исследуем фундаментальные концепции, лежащие в основе TCP и как он используется для передачи данных между двумя конечными точками.

1. Введение

Стандарт протокола управления передачей (TCP) определен в Документ стандартов RFC № 793 [10], подготовленный Инженерная группа Интернета (IETF).Исходная спецификация написанная в 1981 году, была основана на более ранних исследованиях и экспериментах в оригинальный ARPANET. На дизайн TCP сильно повлияло то, что стали известны как «непрерывный аргумент» [3].

Применительно к Интернету сквозной аргумент гласит, что использование чрезмерного интеллекта на физическом и канальном уровнях для обработки контроль ошибок, шифрование или управление потоком, которые вы излишне усложняете система.Это потому, что эти функции обычно необходимо выполнять в любом случае на конечных точках, так зачем дублировать усилия по пути? В Таким образом, результатом сквозной сети является обеспечение минимального функциональность на поэтапной основе и максимальный контроль между системы сквозной связи.

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

Термин «контроль перегрузки» употребляется неправильно. Предотвращение перегрузки было бы более подходящим термином, поскольку TCP не может контролировать перегрузку как таковую. В конечном итоге промежуточные устройства, такие как IP-маршрутизаторы, смогут только контролировать заторы.

Контроль перегрузки в настоящее время является большой областью исследований и проблем в сетевое сообщество. Сопутствующее исследование по контролю перегрузки исследует текущее состояние деятельности в этой области [9].

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

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

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

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

1.1.1 Доставка байтового потока

TCP-интерфейсы между вышележащим прикладным уровнем и сетевым уровнем ниже. Когда приложение отправляет данные в TCP, оно делает это в 8-битном байте. потоки.Затем отправляющий TCP должен сегментировать или разграничивать байтовый поток для передачи данных управляемыми частями на приемник 1 . Именно отсутствие «границ записи» дало ему название «служба доставки байтового потока».

1.1.2 Ориентация на соединение

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

1.1.3 Надежность

Ряд механизмов помогает гарантировать надежность TCP. Каждый из них кратко описывается ниже.

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

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

Повторные передачи . Чтобы гарантировать доставку данных, TCP должен реализовать схемы повторной передачи данных, которые могут быть потеряны или повреждены. Использование получателем положительных подтверждений отправителю подтверждает успешный прием данных. Отсутствие положительного подтверждения, в сочетании с периодом тайм-аута (см. таймеры ниже), вызовы для ретрансляции.

Последовательность .В сетях с коммутацией пакетов пакеты могут быть доставленным из строя. Задача TCP — правильно упорядочивать сегменты. он получает, поэтому он может доставить данные байтового потока в приложение в порядок.

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

1.2 Формат заголовка TCP

Помните, что комбинация заголовка TCP и TCP в одном пакете называется сегментом TCP. На рисунке 1 показан формат всех действительных TCP сегменты. Размер заголовка без опций — 20 байт. Мы будем кратко определите каждое поле заголовка TCP ниже.

Рисунок 1 — Формат заголовка TCP
1.2.1 Порт источника

16-битное число, идентифицирующее приложение, созданное сегментом TCP. изнутри хоста-отправителя.Номера портов разделены на три диапазоны, известные порты (от 0 до 1023), зарегистрированные порты (1024 через 49151) и частные порты (с 49152 до 65535). Назначение портов используются TCP как интерфейс к прикладному уровню. Например, сервер TELNET всегда назначается на хорошо известный порт 23 по умолчанию на хостах TCP. Полная пара IP-адресов (источник и пункт назначения) плюс полная пара портов TCP (источник и пункт назначения) определить единственное глобально уникальное TCP-соединение.См. [5] для дальнейшие подробности.

1.2.2 Порт назначения

16-битное число, идентифицирующее приложение, предназначенное для сегмента TCP. для на принимающем хосте. Порты назначения используют один и тот же номер порта назначения такие же, как и для исходных портов [5].

1.2.3 Порядковый номер

32-битное число, определяющее текущую позицию первого байта данных. в сегменте всего байтового потока для TCP-соединения.После достижения 2 32 -1 это число будет сброшено до 0.

1.2.4 Номер подтверждения

32-битное число, идентифицирующее следующий байт данных, от которого ожидает отправитель. получатель. Следовательно, число будет на единицу больше самого большого. недавно полученный байт данных. Это поле используется только тогда, когда ACK бит управления включен (см. ниже).

1.2.5 Длина заголовка

4-битное поле, указывающее общую длину заголовка TCP в 32-битных словах. (или кратно 4 байтам, если хотите).Без опций TCP заголовок всегда имеет длину 20 байт. Самый большой заголовок TCP может быть 60 байт. Это поле является обязательным, поскольку размер параметров поля не могут быть определены заранее. Обратите внимание, что это поле называется «смещение данных» в официальном стандарте TCP, но длина заголовка больше обычно используется.

1.2.6 Зарезервировано

6-битное поле, которое в настоящее время не используется и зарезервировано для использования в будущем.

1.2.7 Управляющие биты

Срочный указатель (URG) . Если это битовое поле установлено, принимающий TCP должен интерпретировать поле указателя срочности (см. ниже).

Подтверждение (ACK) . Если это битовое поле установлено, подтверждение поле, описанное ранее, является действительным.

Функция нажатия (PSH) . Если это битовое поле установлено, получатель должен как можно скорее доставьте этот сегмент в приложение-получатель.Примером его использования может быть отправка запроса Control-BREAK на приложение, которое может опережать данные в очереди.

Сбросить соединение (RST) . Если этот бит присутствует, он сигнализирует получатель, что отправитель прерывает соединение и все данные в очереди и выделенные буферы для соединения могут быть свободно освобождены.

Синхронизация (SYN) . Если это битовое поле присутствует, это означает, что отправитель пытается «синхронизировать» порядковые номера.Этот бит используется во время начальные этапы установления соединения между отправителем и получатель.

Нет данных от отправителя (FIN) . Если установлено, это битовое поле сообщает получатель, что отправитель достиг конца своего байтового потока для текущее TCP-соединение.

1.2.8 Окно

16-битное целое число, используемое TCP для управления потоком в форме данных. размер окна передачи.Этот номер сообщает отправителю, сколько данных получатель готов принять. Максимальное значение для этого поля будет ограничить размер окна до 65 535 байтов, однако опция «масштаб окна» можно использовать для использования еще больших окон.

1.2.9 Контрольная сумма

Отправитель TCP вычисляет значение на основе содержимого заголовка TCP. и поля данных. Это 16-битное значение будет сравниваться со значением приемник генерирует с использованием тех же вычислений.Если значения совпадают, Ресивер может быть очень уверен, что сегмент прибыл в целости и сохранности.

1.2.10 Срочный указатель

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

1.2.11 Опции

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

1.2.12 Прокладка

Поскольку параметры могут различаться по размеру, может потребоваться «дополнить» TCP заголовок с нулями, чтобы сегмент заканчивался на границе 32-битного слова как определяется стандартом [10].

1.2.13 Данные

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

2. Установление и прекращение соединения

TCP предоставляет услуги с установлением соединения через коммутацию пакетов. сети. Ориентированный на соединение подразумевает наличие виртуального соединения. между двумя конечными точками. 3 В любом виртуальном соединении есть три фазы. Это установление соединения, передача данных и соединение. завершающие фазы.

2.1 Трехстороннее рукопожатие

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

Рисунок 2 — Установление TCP-соединения

Из рисунка 2 видно, что существует три сегмента TCP. обменен между двумя хостами, хостом A и хостом B. Чтение диаграммы изображает события во времени.

Для начала хост A инициирует соединение, отправив сегмент TCP с набор управляющих битов SYN и начальный порядковый номер (ISN), который мы представляют как переменную x в поле порядкового номера.

В какой-то момент времени хост B получает этот сегмент SYN, обрабатывает его и отвечает собственным сегментом TCP. Ответ от хоста B содержит набор управляющих битов SYN и его собственный ISN, представленный как переменная y. Хост B также устанавливает бит управления ACK, чтобы указать следующий ожидаемый байт от хоста A должен содержать данные, начинающиеся с последовательности число x + 1.

Когда хост A получает ISN и ACK хоста B, он завершает соединение. этап установления путем отправки окончательного сегмента подтверждения хосту Б.В этом случае хост A устанавливает бит управления ACK и указывает следующий ожидаемый байт от хоста B, поместив номер подтверждения y + 1 в поле подтверждения.

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

2.2 Передача данных

После обмена ISN взаимодействующие приложения могут передавать данные между собой.Большая часть дискуссий вокруг данных передача требует, чтобы мы посмотрели на управление потоком и контроль перегрузки методы, которые мы обсудим позже в этом документе и ссылаемся на другие тексты [9]. Здесь вкратце изложим несколько ключевых идей, оставляя технические детали в сторону.

Простая реализация TCP помещает сегменты в сеть для получатель, пока есть данные для отправки и пока отправитель не превышать окно, объявленное получателем.Как получатель принимает и обрабатывает сегменты TCP, отправляет положительный результат подтверждения, указывающие, где он находится в байтовом потоке. Эти подтверждения также содержат «окно», которое определяет, сколько байты, которые получатель в настоящее время готов принять. Если данные дублируются или потеряна, в потоке байтов может существовать «дыра». Получатель продолжит чтобы подтвердить самое текущее непрерывное место в потоке байтов, это принял.

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

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

Таймеры используются для предотвращения тупиковых ситуаций и отсутствия ответов на запросы. Задерживается передачи используются для более эффективного использования пропускной способности сети отправляя большие «порции» данных сразу, а не меньшими отдельные части. 5

2.3 Окончание соединения

Чтобы соединение было разорвано, необходимо четыре сегмента. полностью закрыть соединение. Четыре сегмента необходимы из-за тот факт, что TCP является полнодуплексным протоколом, а это означает, что каждый конец должен закрыться вниз независимо. 6 Фаза завершения подключения показана на рисунке. 3 ниже.

Рисунок 3 — Завершение TCP-соединения

Обратите внимание, что вместо управляющих битовых полей SYN соединение фаза завершения использует битовые поля управления FIN, чтобы сигнализировать о завершении связь.

Чтобы разорвать соединение в нашем примере, приложение, работающее на Хост A сигнализирует TCP закрыть соединение. Это генерирует первый FIN сегмент от хоста A к хосту B. Когда хост B получает начальный FIN сегмент, он немедленно подтверждает сегмент и уведомляет его приложение-адресат запроса на расторжение. Как только приложение на хосте B также решает закрыть соединение, а затем отправляет свое собственный сегмент FIN, который хост A обработает и ответит подтверждение.

3. Скользящее окно и управление потоком

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

В [8] мы отмечаем, что управление потоком — это не то же самое, что управление перегрузкой.Контроль перегрузки в первую очередь связан с устойчивой перегрузкой сетевые промежуточные устройства, такие как IP-маршрутизаторы.

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

На рисунке 4 ниже показана концепция скользящего окна.

Рисунок 4 — Раздвижное окно

В этом простом примере есть 4-байтовое скользящее окно. Переезд из слева направо окно «скользит» по мере отправки байтов в потоке и признал. 7 Размер окна и скорость увеличения или уменьшение размера окна — область больших исследований. Мы снова ссылаемся на другие документы для более подробной информации [9].

4.Контроль перегрузки

Контроль перегрузки TCP и проблемы управления интернет-трафиком в целом это активная область исследований и экспериментов. Этот последний раздел очень краткое изложение стандартных алгоритмов управления перегрузкой широко используется сегодня в реализациях TCP. Эти алгоритмы определены в [6] и [7]. Их использование с TCP стандартизировано в [1].

4.1 Медленный старт

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

При первом запуске TCP-соединения инициализируется алгоритм медленного запуска. окно перегрузки до одного сегмента, который является максимальным размером сегмента (MSS) инициализируется получателем во время установления соединения фаза.Когда получатель возвращает подтверждения, окно перегрузки увеличивается на один сегмент для каждого подтверждения вернулся. Таким образом, отправитель может передать минимум перегрузки. окно и объявленное окно получателя, которое просто называется окно передачи.

Медленный старт на самом деле не очень медленный, когда сеть не перегружена и время отклика сети хорошее. Например, первая удачная передача и подтверждение сегмента TCP увеличивает окно на два сегмента.После успешной передачи этих двух сегментов и подтверждение завершается, окно увеличивается до четырех сегментов. Затем восемь сегментов, затем шестнадцать сегментов и так далее, удваиваясь от там до максимального размера окна, объявленного получателем, или пока, наконец, не произойдет затор.

4.2 Предотвращение перегрузки

Во время начальной фазы передачи данных TCP-соединения медленное Используется стартовый алгоритм.Однако во время медленного старта может быть точка. что сеть вынуждена отбросить один или несколько пакетов из-за перегрузки или скопление. В этом случае для замедления работы используется предотвращение перегрузки. скорость передачи. Однако медленный старт используется вместе с Предотвращение перегрузки как средство возобновления передачи данных чтобы он не замедлялся и не оставался медленным.

В алгоритме предотвращения перегрузки таймер повторной передачи истекает или прием дублированных ACK может неявно сигнализировать отправителю, что возникает ситуация перегрузки сети.Отправитель сразу устанавливает его окно передачи до половины текущего размера окна ( минимум окна перегрузки и объявленного окна получателя размер), но не менее двух сегментов. Если перегрузка обозначена значком таймаут, окно перегрузки сбрасывается до одного сегмента, который автоматически переводит отправителя в режим медленного запуска. Если бы затор был обозначается повторяющимися ACK, Fast Retransmit и Fast Recovery вызываются алгоритмы (см. ниже).

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

4.3 Fast Retransmit

При получении дублирующего ACK отправитель не знает, получен ли он. потому что сегмент TCP был потерян или просто сегмент был задержан и получен из строя у получателя. Если получатель может повторно заказать сегментов, не должно пройти много времени, прежде чем получатель отправит последний ожидаемое подтверждение. Обычно не более одного-двух дубликатов ACK следует получать, когда существуют простые неисправные состояния.Если однако отправитель получает более двух дублирующих ACK, это явный признак того, что по крайней мере один сегмент был потерян. ПТС отправитель будет считать, что прошло достаточно времени, чтобы все сегменты были должным образом переупорядочен тем, что получатель успел отправьте три повторяющихся ACK.

При получении трех или более одинаковых ACK отправитель даже не дождитесь истечения таймера повторной передачи перед повторной передачей сегмент (на что указывает позиция дублирующего ACK в байте транслировать).Этот процесс называется алгоритмом быстрой ретрансляции и был впервые определено в [7]. Сразу после быстрой ретрансляции идет быстрая повторная передача. Алгоритм восстановления.

4.4 Быстрое восстановление

Поскольку алгоритм Fast Retransmit используется, когда дублирующиеся ACK будучи полученным, отправитель TCP неявно знает, что есть данные все еще течет в ресивер. Почему? Причина в том, что повторяющиеся ACK может быть сгенерирован только при получении сегмента.Это сильный указывает на то, что серьезной перегрузки сети может не быть и что Потерянный отрезок был редким событием. Поэтому вместо сокращения потока данных внезапно, полностью перейдя в режим медленного старта, отправитель только вводит Режим предотвращения перегрузки.

Вместо того, чтобы начинать с окна из одного сегмента, как в режиме медленного старта, отправитель возобновляет передачу с большим окном, увеличиваясь, как если бы в Режим предотвращения перегрузки.Это позволяет увеличить пропускную способность при состояние лишь умеренной заложенности [23].

5. Выводы

TCP — довольно сложный протокол, который обрабатывает основную часть функциональности. в сети с коммутацией пакетов, такой как Интернет. Поддерживая надежная доставка данных в сети с коммутацией пакетов — нетривиальная задача задача. Этот документ лишь поверхностно описывает внутреннее устройство TCP, но надеюсь, предоставил читателю оценку и отправную точку для дальнейшего интереса к ПТС.Даже спустя почти 20 лет стандартизация, объем работы, который идет на поддержку и разработка надежных сетей с коммутацией пакетов не замедлилась. Это область большой деятельности, и есть много проблем, которые нужно решить. Как Интернет продолжает расти, наша зависимость от TCP будет все больше возрастать. важный. Поэтому сетевым инженерам, проектировщикам обязательно и исследователи должны как можно лучше разбираться в технологиях.

  1. Слово «сегмент» — это термин, используемый для описания размера блока данных TCP, передаваемого получателю.TCP определяет надлежащее использование этого размера сегмента, а не оставляет его на более высоком уровне. протоколы и приложения.
  2. Дублирующиеся пакеты обычно возникают из-за повторных передач, когда первый пакет мог быть задержка, а вторая отправлена ​​из-за отсутствия подтверждения. Тогда получатель может получить два одинаковых пакета.
  3. В отличие от протокола без установления соединения, такого как протокол пользовательских дейтаграмм (UDP).
  4. Есть дополнительные сведения о фазах установления соединения, передачи данных и завершения. которые выходят за рамки этого документа. Для любознательных читателей рекомендую обратиться к более полная ссылка, такая как [4], [11] и, конечно же, официальный стандарт RFC 793 [10].
  5. Ранее было обнаружено, что некоторые реализации TCP плохо работают из-за этого сценария. Это явление получило название синдрома глупого окна и описано в [2].
  6. Хотя это возможно, TCP не очень часто работает в «полузакрытом состоянии». См. [11] для получения дополнительной информации.
  7. В этом примере мы предполагаем, что байты подтверждаются немедленно, так что окно может перемещаться вперед. На практике окно отправителя сжимается и динамически увеличивается по мере поступления подтверждений. во время.
Сокращения
IP IP Интернет-протокол TCP Протокол управления передачей TCP / IP
ACK Подтверждение
бит двоичная цифра
IETF
ISN Начальный порядковый номер
RFC Запрос комментариев
Протокол управления передачей / Интернет-протокол
UDP Протокол дейтаграмм пользователя
Ссылки
[1] Роберт Брейден.Требования к хостам Интернета — уровни связи, октябрь 1989 г., RFC 1122.
[2] Дэвид Д. Кларк. Подтверждение окон и стратегия в TCP, июль 1982 г., RFC 813.
[3] Дэвид Д. Кларк. Философия разработки интернет-протоколов DARPA. В материалах SIGCOMM ’88, Computer Communications Review Vol. 18, No. 4, August 1988, pp. 106-114).
[4] Дуглас Э. Комер. Межсетевое взаимодействие с TCP / IP, Том I: Принципы, протоколы и архитектура.Прентис Холл, ISBN: 0-13-216987-8. 24 марта 1995 г.
[5] Управление по присвоению номеров Интернета. Назначение номера порта, февраль 2000 г.
[6] Ван Якобсон. Предотвращение перегрузки и контроль. Обзор компьютерных коммуникаций, том 18, номер 4, стр. 314-329, август 1988 г.
[7] Ван Якобсон. Модифицированный алгоритм предотвращения перегрузки TCP. Список рассылки end-2-end-Interest, 30 апреля 1990 г.
[8] S. Keshav. Инженерный подход к компьютерным сетям: сети банкоматов, Интернет и телефонная сеть. Эддисон Уэсли, ISBN: 0-201-63442-2. Июль 1997 г.
[9] Джон Кристофф. Контроль перегрузки TCP, март 2000 г.
[10] Джон Постел. Протокол управления передачей, сентябрь 1981 г., RFC 793.
[11] W. Ричард Стивенс. Иллюстрированный TCP / IP, Том 1: Протоколы.Эддисон Уэсли, ISBN: 0-201-63346-9. Январь 1994.

Домашняя страница Гото Джона Кристоффа


Последнее изменение: 24 апреля 2000 г.

Лекция

Лекция
  • протокол управления передачей
  • заголовок
  • порядковые номера и номера подтверждения
  • Таймер TCP
  • флаги заголовка
  • установление и отключение соединения
  • окно управления потоком
    Контрольная сумма
  • используется для обеспечения целостности пакета
    • Таймер
  • используется, чтобы решить, когда повторно передать пакет
    • Порядковый номер
  • используется для определения правильного переупорядочения пакетов, дублирование и потеря
  • подтверждение — это пакет, используемый для информирования отправителя пакета чек
  • отрицательное подтверждение — это пакет, используемый для информирования отправителя что ожидаемый пакет не был получен
    • Окно
  • — это количество незавершенных неподтвержденных данных отправитель может иметь.Как только все окно отправлено, отправитель должен остановиться
  • управление потоком — это замедление отправителя для достижения определенного цели, например, избегать отправки большего количества данных, чем у получателя есть буферное пространство
  • Подобно UDP, TCP обеспечивает демультиплексирование и целостность данных (контрольную сумму)
  • Кроме того, TCP предоставляет ряд услуг:
    • надежная последовательная передача данных
    • обмен данными с установлением соединения
    • модель «поток октетов»
    • замедление отправителя до:
      • предотвращение перегрузки сети (контроль перегрузки)
      • предотвратить переполнение буфера приемника (управление потоком)
    • срочные указатели, чтобы позволить получателю пропустить менее важные данные
  • сегмент TCP состоит из заголовка TCP, за которым следует ноль или более байты данных TCP
  • основы TCP определены в RFC 793:
     0 1 2 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Исходный порт | Порт назначения |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Порядковый номер |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Номер подтверждения |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Данные | | C | E | U | A | P | R | S | F | |
| Смещение | Резко | W | C | R | C | S | S | Y | I | Окно |
| | | R | E | G | K | H | T | N | N | |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Контрольная сумма | Срочный указатель |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Опции | Прокладка |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| данные |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
    (показанный здесь заголовок также отражает RFC 3168)
  • заголовок обычно имеет длину 20 байт, но может быть длиннее, если варианты присутствуют
  • поле длины заголовка («Data Offset») — это 32-битное число слова в заголовке, поэтому принимает значение 5 для 20-байтовых заголовков
  • порт источника, порт назначения и контрольная сумма такие же, как для UDP
  • , поскольку IP сообщает о длине пакета, поле длины заголовка не предоставляется в заголовке TCP
  • порядковый номер TCP имеет длину 32 бита
  • старший байт числа отправляется первым
  • Порядковые номера TCP подсчитывают байты, а не пакеты
  • порядковый номер в заголовке — это порядковый номер первый байт данных
  • , если данных нет, порядковый номер все равно будет установлен на порядковый номер следующего байта, который может быть отправлен
  • , поскольку TCP-соединение является двунаправленным, другое начальное порядковый номер (ISN) используется в каждом направлении: каждый партнер выбирает ISN, который будет использоваться при отправке данных
  • поле TCP ack сообщает порядковый номер следующего байт, который ожидается
  • этот байт, возможно, уже был отправлен
  • один пакет может нести данные и подтверждение, и мы называем это пакетом данных, или
  • один пакет может содержать подтверждение, но не содержать данных: это это пакет подтверждения
  • поле подтверждения должно быть установлено правильно каждый раз, когда бит подтверждения установлен в заголовке, который предназначен для всех пакетов, кроме самого первого пакет отправлен по соединению
  • предположим, что хост L отправляет пакет хосту R с порядковым номером 983 и 100 байт данных
  • хост R должен отправить обратно пакет с номером подтверждения 1083
  • этот пакет может быть подтверждением (нет данных), или подтверждение может быть совмещенный с сегментом данных
  • , чтобы расширить приведенный выше пример, предположим, что L отправляет два пакета с порядковые номера 983 и 1083, первый со 100 байтами данных, второй с одним байтом данных
  • хост R может отправить два подтверждения, 1083 и 1084, или может отправить один подтверждение с номером 1084
  • , потому что TCP acks — это кумулятивное , второго подтверждения достаточно
  • по этой причине TCP часто задерживает подтверждение одного сегмента, ожидание в течение короткого времени перед отправкой подтверждения: отложенное подтверждение
  • при использовании отложенных подтверждений TCP должен подтверждать не реже одного раза в два сегмента
  • предположим, что пакет или подтверждение потерян
  • потерянное подтверждение может не иметь большого значения, если более позднее подтверждение подтверждает получение тех же данных
  • , но при получении пакета не по порядку, получатель должен сохранить подтверждение последнего полученного пакета по порядку
  • приемник обычно буферизует полученные данные не по порядку
  • в любом случае отправитель TCP должен держать таймер
  • по истечении таймера первый неподтвержденный сегмент TCP ретранслируется
  • данные, изначально отправленные в виде нескольких сегментов, меньших, чем Максимальный размер сегмента (MSS) может быть объединен и повторно передан как один сегмент
  • если пакеты передаются очень редко, настройки таймера не имеют решающего значения
  • с использованием длительного (медленного) таймера, пакеты только повторно передаются при необходимости уменьшая количество отправляемых дополнительных данных
  • с использованием таймера быстрого периода, пакеты повторно передаются так же быстро по возможности, сокращая время до того, как получатель получит все свои данные
    • Таймеры
  • могут настраиваться адаптивно в зависимости от наблюдаемого RTT соединение, то есть время от отправки пакета (которое никогда не повторно передано), чтобы получить подтверждение для этого пакета
  • TCP измеряет время от отправки пакета x до получения соответствующий Ack: RTT x
  • при каждом измерении TCP обновляет текущее среднее значение: соответствующий Ack: RTT среднее = (1-альфа) RTT среднее + альфа RTT x
  • обычно альфа = 1/8, что легко вычислить с помощью двоичной арифметики
  • среднее (оценочное) RTT отслеживает несколько последних RTT x , с большим вниманием к последним
  • для каждого измерения TCP также обновляет текущее среднее значение разница между предполагаемым RTT и измерением: Diff пр. = (1-бета) Diff пр. — beta | RTT x — RTT пр. |
  • обычно, бета = 1/4
  • таймер настроен на истечение времени RTT пр. + 4 Diff пр.
  • это значение обеспечивает повторную передачу как можно скорее по предсказуемой сетей, и дает хороший запас для сильно изменчивых сетей
  • таймер TCP должен работать всякий раз, когда есть невыполненные неподтвержденные сегменты
  • каждый раз, когда пакет теряется, таймер удваивается: двоичная экспонента отвали
  • RTT пр. и Diff пр. тогда используется снова, когда данные передаются без ошибок
  • пакетов, которые передаются повторно, не используются для вычисления RTT x
  • TCP интерпретирует несколько повторяющихся подтверждений как признак того, что получатель имеет неупорядоченные данные и сразу (не дожидаясь таймера) повторно передает следующий пакет после последнего тот, который получил признание: fast retransmit
  • 8 флагов заголовка TCP и их значения:
    1. CWR, окно перегрузки уменьшено
    2. ECE, явное уведомление о перегрузке
    3. URG, сегмент содержит срочные данные, а отметки указателя срочности его месторасположение
    4. ACK, поле подтверждения действительно
    5. PSH, данные должны быть доставлены (PuSHed) в приложение быстро
    6. RST, ЗАМЕНИТЬ соединение
    7. SYN, это первый пакет в новом соединении
    8. FIN, это последний пакет в существующем соединении, обещаю никогда больше не отправлять данные по этому соединению
  • каждый пакет, но первый имеет установленный бит ACK
  • первый пакет в каждом направлении имеет установленный бит SYN
  • новые данные не могут быть отправлены после отправки пакета FIN, хотя данные все еще могут быть полученным, подтвержденным или повторно переданным
  • для запуска соединения клиент отправляет на сервер SYN-пакет
  • сервер ищет номер порта назначения, и если сервер прослушивает этот порт, возвращает пакет с SYN и Набор бит ACK (SYN + ACK)
  • этот пакет SYN + ACK имеет ISN сервера, а также несет полученный порядковый номер + 1
  • , что означает, что бит SYN считается в пространстве порядковых номеров, как если бы это был байт данных
  • клиент отвечает на SYN + ACK пакетом ACK, также увеличение собственного порядкового номера и номера подтверждения
  • пакет ACK может нести данные, но часто нет
  • всего, этот обмен тремя пакетами для настройки соединение известно как трехстороннее рукопожатие
  • в конце трехстороннего рукопожатия каждая сторона имеет:
  • знание того, что одноранговый узел заинтересован в установке соединения (при условии, что трехстороннее рукопожатие прошло успешно)
  • порядковый номер, ожидаемый для первого байта данных, который сверстник отправит
  • размер окна, сообщающий о максимальном количестве данных, которые могут быть отправлены
  • возможно несколько вариантов, о которых нам сообщил партнер как они собираются использовать TCP или как они хотели бы, чтобы мы использовали TCP
  • например, масштабирование окна может сказать нам умножить окно значение в определенной степени двойки
  • , если одноранговый узел не имеет приложения, прослушивающего данный порт, вместо SYN + ACK он отправляет сегмент с битом RST, сбросить соединение
  • как только TCP-хост знает, что больше никогда не будет отправлять данные по соединению, возможно, потому что приложение закрыло соединение, он может установить пакет с установленным битом FIN
  • принимающее приложение подтверждает FIN, снова увеличивая номер подтверждения, как если бы бит FIN был байтом данных
  • соединение теперь полузакрыто: только одна сторона может отправлять данные
  • оставшаяся сторона может отправить FIN, когда будет готова полностью закрыть соединение
  • этот FIN также подтвержден
  • хост L отправляет R пакет SYN с порядковым номером 99, номером подтверждения 0, порт источника 1000, порт назначения 2000
  • хост R отправляет L пакет SYN + ACK с порядковым номером 555, номер подтверждения 100, порт источника 2000, порт назначения 1000
  • номеров портов и бит ACK не будут отображаться в оставшейся части в этом примере, поскольку для каждого пакета установлен бит ACK, а порт числа всегда 1000-> 2000 для пакетов от L до R и 2000-> 1000 для пакетов от R до L
  • L отправляет R пакет с порядковым номером 100, номером подтверждения 556
  • L отправляет R пакет с порядковым номером 100, номером подтверждения 556, и один байт данных
  • R отправляет L пакет с порядковым номером 556, номером подтверждения 101, и два байта данных
  • L отправляет R пакет с порядковым номером 101, номером подтверждения 558
  • R отправляет L пакет FIN с порядковым номером 558, номером подтверждения 101,
  • L отправляет R пакет с порядковым номером 101, номером подтверждения 559
  • L отправляет R пакет FIN с порядковым номером 101, номером подтверждения 559
  • R отправляет L пакет с порядковым номером 559, номером подтверждения 102,
                              + --------- + --------- \ активно ОТКРЫТЬ
                              | ЗАКРЫТО | \ -----------
                              + --------- + | |
 | SYN | rcv SYN | SYN |
 | RCVD || ЗАКРЫТЬ |
 | ПОДОЖДИТЕ-1 | ------------------ | ПОДОЖДИТЕ |
 + --------- + rcv FIN \ + --------- +
   | rcv ACK of FIN ------- | ЗАКРЫТЬ |
   | -------------- snd ACK | ------- |
   V x V snd FIN V
 + --------- + + --------- + + --------- +
 | FINWAIT-2 | | ЗАКРЫТИЕ | | LAST-ACK |
 + --------- + + --------- + + --------- +
   | РКВ АСК ФИН | РКВ АСК ФИН |
   | rcv FIN -------------- | Тайм-аут = 2MSL -------------- |
   | ------- х В ------------ х В
    \ snd ACK + --------- + удалить TCB + --------- +
     ------------------------> | ВРЕМЯ ОЖИДАНИЯ | ------------------> | ЗАКРЫТО |
                              + --------- + + --------- +

                      Диаграмма состояния TCP-соединения
  • Состояние подключения должно быть записано на каждом одноранговом узле (два сверстники могут быть в разных состояниях)
  • другие переменные, включая окно, ожидаемый порядковый номер, последний подтвержденный порядковый номер и т. д. также должен быть записан на каждый пэр
  • каждый одноранговый узел поддерживает запись (в C, структуру) для отслеживания переменных для каждого соединения: блок управления передачей или TCB
  • TCB создается с сокетом и удаляется, когда сокет закрыто
  • при атаке SYN-flooding злоумышленник отправляет множество SYN-пакетов, попытка заполнить все TCP на цели информацией, которая никогда не использоваться
  • защита SYN-cookie не выделяет TCP до третьего пакет получен: вместо этого кодируется порядковый номер таким образом, что сложно угадать, информация в SYN
  • злоумышленник теперь должен либо отправлять SYN-пакеты с правильным (без подделки) IP-адресов, или никогда не увидят SYN + ACK и, следовательно, будут невозможно отправить правильный ACK, который действительно зарезервирует TCB
  • как последовательность и номера подтверждения, окно TCP считает байты
  • если действует масштабирование окна, окно подсчитывается в единицах 2, 4, 8, 16 или, как правило, 2 n байтов
  • в окне указано, сколько неподтвержденных байтов может иметь отправитель
  • получатель отправляет отправителю окно, чтобы отразить сумму свободное буферное пространство
  • это известно как управление потоком: поскольку отправитель может отправлять не более данные в одно окно за каждый RTT, получатель может замедлить отправителя, отправив небольшое окно
  • отправитель TCP должен буферизовать данные для отправки, пока окно не позволит это действительно будет отправлено
  • если приложение отправляет больше данных, чем может буферизовать TCP, приложение должен быть приостановлен, или операция отправки должна вернуть ошибку
  • отправитель TCP должен также буферизовать отправленные данные до тех пор, пока получатель подтверждает это
  • получатель TCP должен буферизовать данные, полученные, но еще не использованные приложение
  • получатель TCP также должен буферизовать полученные данные не по порядку, но все еще в окне
  • получатель TCP должен отправить отправителю окно, которое не больше, чем объем данных, который он может буферизовать для этого соединения
  • после того, как отправитель заполнил буфер получателя, получатель должен подтвердить все данные, но отправить нулевое окно
  • как только приложение потребляет данные, получатель должен отправить новый пакет подтверждения, чтобы «открыть» окно
  • однако подтверждение может быть потеряно
  • по этой причине отправитель с данными для отправки должен периодически отправлять первый байт данных для получателя, даже если окно равно нулю
  • приемник не должен принимать этот байт данных — если он действительно нет места, вместо этого он может повторно подтвердить предыдущий байт
  • в любом случае подтверждение будет нести текущее окно

Масштабирование размера окна TCP

TCP (протокол управления передачей) — это протокол, ориентированный на соединение, что означает, что мы отслеживаем, сколько данных было передано.Отправитель передает некоторые данные, а получатель должен их подтвердить. Если мы не получим подтверждение вовремя, отправитель повторно передаст данные.

TCP использует «оконное управление», что означает, что отправитель отправит один или несколько сегментов данных, а получатель подтвердит один или все сегменты. Когда мы запускаем TCP-соединение, хосты будут использовать буфер приема, в котором мы временно храним данные, прежде чем приложение сможет их обработать.

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

Обычно TCP-соединение запускается с небольшим размером окна, и каждый раз при успешном подтверждении размер окна увеличивается. Вот пример:

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

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

Хост теперь отправляет четыре сегмента, и хост с правой стороны отвечает одним подтверждением.

В приведенном выше примере размер окна продолжает увеличиваться, пока получатель отправляет подтверждения для всех наших сегментов или когда размер окна достигает определенного максимального предела. Если получатель не отправляет подтверждение в течение определенного периода времени (называемого временем приема-передачи), размер окна будет уменьшен.

Когда интерфейс перегружен, возможно, что IP-пакеты будут отброшены. Чтобы справиться с этим, TCP имеет ряд алгоритмов, которые имеют дело с контролем перегрузки. Один из них называется slow start .

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

При медленном запуске TCP размер окна сначала увеличивается экспоненциально (размер окна удваивается), но после отбрасывания пакета размер окна уменьшается до одного сегмента.Затем он будет снова экспоненциально расти, пока размер окна не станет половиной того, что было в момент возникновения перегрузки. В этот момент размер окна будет расти линейно, а не экспоненциально.

Когда интерфейс становится перегруженным, возможно, что все ваши TCP-соединения будут испытывать медленный запуск TCP. Пакеты будут отброшены, и тогда все TCP-соединения будут иметь небольшой размер окна. Это называется глобальной синхронизацией TCP . Вот как это выглядит:

Оранжевая, синяя и зеленая линии обозначают три разных TCP-соединения.Эти TCP-соединения запускаются в разное время, и через некоторое время интерфейс становится перегруженным, и пакеты всех TCP-соединений отбрасываются. Что происходит, так это то, что размер окна всех этих TCP-соединений уменьшится до одного, и как только перегрузка интерфейса исчезнет, ​​все их размеры окон снова увеличатся.

Затем интерфейс снова становится перегруженным, размер окна уменьшается до единицы, и история повторяется. В результате мы не используем всю доступную пропускную способность, которую может предложить наш интерфейс.Если вы посмотрите на пунктирную линию, то увидите, что у нас средняя загрузка интерфейса не очень высока.

Чтобы предотвратить глобальную синхронизацию, мы можем использовать КРАСНЫЙ (случайное раннее обнаружение). это функция, которая отбрасывает «случайные» пакеты из потоков TCP на основе количества пакетов в очереди и маркировки пакетов TOS (Тип обслуживания). Когда пакеты отбрасываются до заполнения очереди, мы можем избежать глобальной синхронизации.

Конечный результат будет выглядеть примерно так:

Когда мы используем КРАСНЫЙ, наша средняя загрузка интерфейса улучшается.

Теперь у вас есть представление о размере окна TCP, давайте посмотрим на реальный пример того, как используется размер окна. Для этого мы можем использовать wirehark.

Wireshark захватывает

Для проверки размера окна TCP я буду использовать два устройства:

Устройство слева — это современный компьютер с гигабитным интерфейсом. С правой стороны у нас есть небольшой Raspberry Pi с интерфейсом FastEthernet. Raspberry Pi — отличное маленькое устройство, но его интерфейс cpu / memory / ethernet ограничен.Чтобы получить интересный результат, я скопирую большой файл через SSH со своего компьютера на raspberry pi, который будет легко перегружен.

Вот что произошло, посмотрите на это изображение:

На графике выше вы можете увидеть размер окна, который использовался во время этого соединения. Передача файла началась примерно через 6 секунд, и вы можете видеть, что размер окна быстро увеличивался. Он немного поднимался и опускался, но примерно через 30 секунд полностью рухнул. Через несколько секунд он снова увеличился, и я смог завершить передачу файла.Давайте подробнее рассмотрим эту передачу файлов, которая начинается с трехстороннего рукопожатия:

Мой быстрый компьютер использует 10.56.100.1, а raspberry pi — 10.56.100.164. Выше вы можете видеть, что в сообщении SYN, ACK, что raspberry pi хочет использовать размер окна 29200. Мой компьютер хочет использовать размер окна 8388480 (win = 65535 * ws = 128), что сейчас не имеет значения, поскольку мы отправка данных на Raspberry Pi.

После нескольких пакетов размер окна Raspberry Pi выглядит так:

Выше видно, что размер окна увеличился до 132480.Первоначально размер окна был 16-битным, поэтому наибольший размер окна был бы 65535. В настоящее время мы используем коэффициент масштабирования, чтобы мы могли использовать окна большего размера.

Примерно на отметке 10 секунд размер окна уменьшился. Вот что произошло:

Raspberry Pi, похоже, не справляется с работой, и его буфер приема, вероятно, заполнен. Он сообщает компьютеру использовать размер окна 26752 с этого момента. Компьютер отправляет 18 сегментов по 1460 байтов и один сегмент по 472 байта (всего 26752 байта).Последний пакет показывает нам сообщение «TCP Window Full». Это то, что нам сообщает wirehark, наш компьютер полностью заполнил приемный буфер raspberry pi.

Как только Raspberry Pi немного догонит и около 30 секунд, происходит что-то плохое. Взгляните на снимок wirehark ниже:

Выше вы можете видеть, что Raspberry Pi отправляет ACK на компьютер с размером окна 0 . Это означает, что размер окна будет оставаться равным 0 в течение определенного периода времени, raspberry pi не сможет получить больше данных в этот момент, и передача TCP будет приостановлена ​​на некоторое время, пока обрабатывается буфер приема.

Вот настоящий пакет:

Выше вы можете видеть, что размер окна теперь равен 0. После обработки буфера приема raspberry pi отправит ACK с новым размером окна:

Размер окна теперь составляет всего 25600 байт, но он снова будет увеличиваться. Остальная часть передачи прошла без каких-либо сбоев, и передача файла завершилась.

Заключение

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

UDP, в отличие от TCP, является протоколом без установления соединения и будет просто продолжать отправлять трафик. Размер окна отсутствует, по этой причине вы можете захотеть ограничить свой UDP-трафик или вы можете увидеть истощение вашего TCP-трафика при перегрузке.

Надеюсь, вам понравился этот урок. Если у вас есть еще вопросы, не стесняйтесь оставлять комментарии на нашем форуме.

Настройка производительности

TCP / IP для виртуальных машин Azure

  • 23 минуты на чтение

В этой статье

В этой статье обсуждаются распространенные методы настройки производительности TCP / IP и некоторые моменты, которые следует учитывать при их использовании для виртуальных машин, работающих в Azure. В нем будет представлен базовый обзор методов и выяснено, как их можно настроить.

Общие методы настройки TCP / IP

MTU, фрагментация и разгрузка большой отправки

MTU

Максимальная единица передачи (MTU) — это кадр (пакет) наибольшего размера, указанный в байтах, который может быть отправлен по сетевому интерфейсу. MTU — это настраиваемый параметр. MTU по умолчанию, используемый на виртуальных машинах Azure, и значение по умолчанию для большинства сетевых устройств во всем мире — 1500 байт.

Фрагментация

Фрагментация происходит при отправке пакета, превышающего MTU сетевого интерфейса.Стек TCP / IP разбивает пакет на более мелкие части (фрагменты), которые соответствуют MTU интерфейса. Фрагментация происходит на уровне IP и не зависит от основного протокола (например, TCP). Когда по сетевому интерфейсу отправляется 2000-байтовый пакет с MTU 1500, пакет будет разбит на один 1500-байтовый пакет и один 500-байтовый пакет.

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

Бит Не фрагментировать в IP-пакете

Бит Не фрагментировать (DF) — это флаг в заголовке протокола IP. Бит DF указывает, что сетевые устройства на пути между отправителем и получателем не должны фрагментировать пакет. Этот бит может быть установлен по многим причинам. (См. Один пример в разделе «Обнаружение MTU пути» этой статьи.) Когда сетевое устройство получает пакет с установленным битом «Не фрагментировать», и этот пакет превышает MTU интерфейса устройства, стандартное поведение устройства — сбросить пакет.Устройство отправляет ICMP-сообщение о необходимости фрагментации обратно исходному источнику пакета.

Влияние фрагментации на производительность

Фрагментация может отрицательно сказаться на производительности. Одной из основных причин влияния на производительность является влияние фрагментации и повторной сборки пакетов на ЦП / память. Когда сетевому устройству необходимо фрагментировать пакет, ему необходимо выделить ресурсы ЦП / памяти для выполнения фрагментации.

То же самое происходит при повторной сборке пакета.Сетевое устройство должно хранить все фрагменты до тех пор, пока они не будут получены, чтобы оно могло собрать их в исходный пакет. Этот процесс фрагментации и повторной сборки также может вызвать задержку.

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

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

Фрагментацию можно рассматривать как отрицательную операцию, но поддержка фрагментации необходима, когда вы подключаете различные сети через Интернет.

Преимущества и последствия модификации MTU

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

Вот пример. Размер заголовка Ethernet составляет 14 байтов плюс 4-байтовая последовательность проверки кадра для обеспечения согласованности кадра. Если отправляется один пакет размером 2000 байт, в сеть добавляется 18 байтов служебных данных Ethernet. Если пакет разделен на 1500-байтовый пакет и 500-байтовый пакет, каждый пакет будет иметь 18 байтов заголовка Ethernet, всего 36 байтов.

Имейте в виду, что увеличение MTU не обязательно приведет к созданию более эффективной сети. Если приложение отправляет только 500-байтовые пакеты, накладные расходы заголовка будут существовать независимо от того, составляет ли MTU 1500 или 9000 байтов. Сеть станет более эффективной только в том случае, если в ней будут использоваться пакеты большего размера, на которые влияет MTU.

Azure и виртуальная машина MTU

MTU по умолчанию для виртуальных машин Azure составляет 1500 байт. Стек виртуальной сети Azure попытается фрагментировать пакет размером 1400 байт.

Обратите внимание, что стек виртуальной сети не является неэффективным по своей сути, поскольку он фрагментирует пакеты размером 1400 байт, даже если MTU виртуальных машин составляет 1500. Большой процент сетевых пакетов намного меньше 1400 или 1500 байтов.

Лазурь и фрагментация
Стек

Virtual Network настроен на отбрасывание «фрагментов вне порядка», то есть фрагментированных пакетов, которые не поступают в их первоначальном фрагментированном порядке. Эти пакеты отбрасываются в основном из-за объявленной в ноябре 2018 года уязвимости сетевой безопасности под названием FragmentSmack.

FragmentSmack — это дефект в способе обработки ядром Linux повторной сборки фрагментированных пакетов IPv4 и IPv6. Удаленный злоумышленник может использовать эту уязвимость для запуска дорогостоящих операций повторной сборки фрагментов, что может привести к увеличению загрузки ЦП и отказу в обслуживании в целевой системе.

Настройте MTU

Вы можете настроить MTU виртуальной машины Azure, как и в любой другой операционной системе. Но при настройке MTU следует учитывать описанную выше фрагментацию в Azure.

Мы не поощряем клиентов увеличивать MTU виртуальных машин. Это обсуждение предназначено для объяснения деталей того, как Azure реализует MTU и выполняет фрагментацию.

Важно

Известно, что увеличение MTU не улучшает производительность и может отрицательно сказаться на производительности приложения.

Большая отправка, выгрузка

Разгрузка большой отправки (LSO) может улучшить производительность сети за счет разгрузки сегментации пакетов на адаптер Ethernet. Когда LSO включен, стек TCP / IP создает большой пакет TCP и отправляет его адаптеру Ethernet для сегментации перед пересылкой.Преимущество LSO заключается в том, что он может освободить ЦП от сегментирования пакетов по размерам, соответствующим MTU, и передать эту обработку интерфейсу Ethernet, где она выполняется аппаратно. Дополнительные сведения о преимуществах LSO см. В разделе Поддержка разгрузки большой отправки.

Если LSO включен, клиенты Azure могут видеть кадры большого размера при захвате пакетов. Эти большие размеры кадра могут привести некоторых клиентов к мысли, что происходит фрагментация или что используется большой MTU, когда это не так.С помощью LSO адаптер Ethernet может объявлять больший максимальный размер сегмента (MSS) стеку TCP / IP, чтобы создать больший пакет TCP. Затем весь этот несегментированный кадр пересылается на адаптер Ethernet и будет виден при захвате пакета, выполняемом на виртуальной машине. Но пакет будет разбит на множество более мелких кадров адаптером Ethernet в соответствии с MTU адаптера Ethernet.

Масштабирование окна TCP MSS и PMTUD

Максимальный размер сегмента TCP

Максимальный размер сегмента TCP (MSS) — это параметр, ограничивающий размер сегментов TCP, что позволяет избежать фрагментации пакетов TCP.Операционные системы обычно используют эту формулу для установки MSS:

MSS = MTU - (размер заголовка IP + размер заголовка TCP)

Заголовок IP и заголовок TCP составляют по 20 байтов, или всего 40 байтов. Таким образом, интерфейс с MTU 1500 будет иметь MSS 1460. Но MSS можно настроить.

Этот параметр согласован в трехстороннем подтверждении связи TCP, когда сеанс TCP устанавливается между источником и получателем. Обе стороны отправляют значение MSS, и меньшее из двух используется для TCP-соединения.

Имейте в виду, что MTU источника и назначения — не единственные факторы, определяющие значение MSS. Промежуточные сетевые устройства, такие как VPN-шлюзы, включая Azure VPN Gateway, могут настраивать MTU независимо от источника и назначения, чтобы обеспечить оптимальную производительность сети.

Обнаружение MTU пути

MSS согласовывается, но он может не указывать фактический MSS, который может использоваться. Это связано с тем, что другие сетевые устройства на пути между источником и местом назначения могут иметь меньшее значение MTU, чем источник и место назначения.В этом случае устройство, у которого MTU меньше, чем размер пакета, отбросит пакет. Устройство отправит обратно сообщение ICMP Fragmentation Needed (Тип 3, Код 4), которое содержит его MTU. Это сообщение ICMP позволяет хосту-источнику соответствующим образом уменьшить свой MTU пути. Этот процесс называется Path MTU Discovery (PMTUD).

Процесс PMTUD неэффективен и влияет на производительность сети. Когда отправляются пакеты, которые превышают MTU сетевого пути, пакеты необходимо повторно передать с более низким MSS.Если отправитель не получает сообщение ICMP Fragmentation Needed, возможно, из-за сетевого брандмауэра на пути (обычно называемого PMTUD blackhole ), отправитель не знает, что ему нужно снизить MSS, и будет постоянно повторять передачу. пакет. Вот почему мы не рекомендуем увеличивать MTU виртуальной машины Azure.

VPN и MTU

Если вы используете виртуальные машины, которые выполняют инкапсуляцию (например, IPsec VPN), есть некоторые дополнительные соображения относительно размера пакета и MTU.VPN добавляют к пакетам больше заголовков, что увеличивает размер пакета и требует меньшего MSS.

Для Azure мы рекомендуем установить ограничение TCP MSS на 1350 байт и MTU интерфейса туннеля на 1400. Для получения дополнительной информации см. Страницу VPN-устройства и параметры IPSec / IKE.

Задержка, время приема-передачи и масштабирование окна TCP

Задержка и время приема-передачи

Задержка в сети определяется скоростью света в оптоволоконной сети. Пропускная способность сети TCP также эффективно регулируется временем приема-передачи (RTT) между двумя сетевыми устройствами.

Маршрут Расстояние В одну сторону RTT
Нью-Йорк — Сан-Франциско 4148 км 21 мс 42 мс
Нью-Йорк — Лондон 5,585 км 28 мс 56 мс
Нью-Йорк — Сидней 15,993 км 80 мс 160 мс

В этой таблице показано расстояние по прямой между двумя точками.В сетях расстояние обычно больше, чем расстояние по прямой. Вот простая формула для расчета минимального RTT в зависимости от скорости света:

минимум RTT = 2 * (Расстояние в километрах / Скорость распространения)

Вы можете использовать 200 для скорости распространения. Это расстояние в километрах, которое свет проходит за 1 миллисекунду.

Давайте в качестве примера возьмем Нью-Йорк и Сан-Франциско. Расстояние по прямой — 4 148 км. Подставляя это значение в уравнение, мы получаем следующее:

Минимальное RTT = 2 * (4,148/200)

Вывод уравнения в миллисекундах.

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

Влияние задержки и времени приема-передачи на TCP

Время приема-передачи напрямую влияет на максимальную пропускную способность TCP. В протоколе TCP размер окна — это максимальный объем трафика, который может быть отправлен по TCP-соединению до того, как отправителю потребуется получить подтверждение от получателя.Если TCP MSS установлен на 1460, а размер окна TCP установлен на 65 535, отправитель может отправить 45 пакетов, прежде чем он должен будет получить подтверждение от получателя. Если отправитель не получает подтверждения, он повторно передает данные. Вот формула:

Размер окна TCP / TCP MSS = количество отправленных пакетов

В этом примере 65 535/1460 округлено до 45.

Это состояние «ожидания подтверждения», механизм, обеспечивающий надежную доставку данных, заставляет RTT влиять на пропускную способность TCP.Чем дольше отправитель ждет подтверждения, тем дольше ему нужно ждать перед отправкой дополнительных данных.

Вот формула для расчета максимальной пропускной способности одного TCP-соединения:

Размер окна / (задержка RTT в миллисекундах / 1000) = максимальное количество байтов в секунду

В этой таблице показана максимальная пропускная способность одного TCP-соединения в мегабайтах / в секунду. (Для удобства чтения в качестве единицы измерения используются мегабайты.)

Размер окна TCP (байты) Задержка RTT (мс) Максимальная пропускная способность, мегабайт / с Максимальная пропускная способность, мегабит / с
65 535 1 65.54 524,29
65 535 30 2,18 17,48
65 535 60 1,09 8,74
65 535 90,73 5,83
65 535 120,55 4,37

Если пакеты потеряны, максимальная пропускная способность TCP-соединения будет уменьшена, пока отправитель повторно передает данные, которые он уже отправил.

Масштабирование окна TCP

Масштабирование окна TCP — это метод, который динамически увеличивает размер окна TCP, чтобы можно было отправить больше данных до того, как потребуется подтверждение. В предыдущем примере было отправлено 45 пакетов до того, как потребуется подтверждение. Если вы увеличите количество пакетов, которые могут быть отправлены до того, как потребуется подтверждение, вы уменьшите количество раз, когда отправитель ожидает подтверждения, что увеличивает максимальную пропускную способность TCP.

Эта таблица иллюстрирует эти отношения:

Размер окна TCP (байты) Задержка RTT (мс) Максимальная пропускная способность, мегабайт / с Максимальная пропускная способность, мегабит / с
65 535 30 2.18 17,48
131 070 30 4,37 34,95
262,140 30 8,74 69,91
524 280 30 17,48 139,81

Но значение заголовка TCP для размера окна TCP составляет всего 2 байта, что означает, что максимальное значение для окна приема составляет 65 535. Чтобы увеличить максимальный размер окна, был введен масштабный коэффициент окна TCP.3) = 262 140 байт

Коэффициент масштабирования 14 приводит к размеру окна TCP 14 (максимально допустимое смещение). Размер окна TCP составит 1 073 725 440 байт (8,5 гигабит).

Поддержка масштабирования окна TCP

Windows может устанавливать разные коэффициенты масштабирования для разных типов подключения. (Классы подключений включают центр обработки данных, Интернет и т. Д.) Используйте команду Get-NetTCPConnection PowerShell, чтобы просмотреть тип подключения для масштабирования окна:

  Get-NetTCPConnection

Для просмотра значений каждого класса можно использовать команду Get-NetTCPSetting PowerShell:

  Get-NetTCPSetting

Вы можете установить начальный размер окна TCP и коэффициент масштабирования TCP в Windows с помощью команды Set-NetTCPSetting PowerShell. 14)

Эти параметры с наибольшей вероятностью повлияют на производительность TCP, но имейте в виду, что многие другие факторы в Интернете, не зависящие от Azure, также могут влиять на производительность TCP.

Увеличить размер MTU

Поскольку больший MTU означает больший MSS, вы можете задаться вопросом, может ли увеличение MTU повысить производительность TCP. Возможно нет. У размера пакета есть плюсы и минусы, помимо TCP-трафика. Как обсуждалось ранее, наиболее важными факторами, влияющими на производительность TCP, являются размер окна TCP, потеря пакетов и RTT.

Важно

Мы не рекомендуем клиентам Azure изменять значение MTU по умолчанию на виртуальных машинах.

Ускоренная работа в сети и масштабирование на стороне приема

Ускоренная работа в сети

Исторически сложилось так, что сетевые функции виртуальной машины требовали большой нагрузки на ЦП как на гостевой виртуальной машине, так и на гипервизоре / хосте.Каждый пакет, проходящий через хост, обрабатывается программно центральным процессором, включая всю инкапсуляцию и декапсуляцию виртуальной сети. Таким образом, чем больше трафика проходит через хост, тем выше нагрузка на ЦП. И если центральный процессор занят другими операциями, это также повлияет на пропускную способность сети и задержку. Azure решает эту проблему с помощью ускоренной работы в сети.

Accelerated Network обеспечивает стабильную сверхмалую задержку в сети благодаря внутреннему программируемому оборудованию Azure и таким технологиям, как SR-IOV.Ускоренная работа в сети перемещает большую часть программно-определяемого сетевого стека Azure с процессоров на SmartNIC на базе FPGA. Это изменение позволяет приложениям конечных пользователей восстанавливать вычислительные циклы, что снижает нагрузку на виртуальную машину, снижает дрожание и несогласованность в задержках. Другими словами, производительность может быть более детерминированной.

Accelerated Network повышает производительность, позволяя гостевой виртуальной машине обходить хост и устанавливать канал данных напрямую с помощью SmartNIC хоста. Вот некоторые преимущества ускоренной работы в сети:

  • Более низкая задержка / большее количество пакетов в секунду (pps) : удаление виртуального коммутатора из канала данных устраняет время, которое пакеты тратятся на хосте для обработки политики, и увеличивает количество пакетов, которые могут быть обработаны в виртуальной машине.

  • Уменьшение джиттера : Обработка виртуального коммутатора зависит от объема политики, которую необходимо применить, и рабочей нагрузки процессора, выполняющего обработку. Передача применения политик на оборудование устраняет эту изменчивость, доставляя пакеты непосредственно на виртуальную машину, устраняя связь между хостами и все программные прерывания и переключение контекста.

  • Снижение загрузки ЦП : Обход виртуального коммутатора на хосте приводит к меньшей загрузке ЦП для обработки сетевого трафика.

Чтобы использовать ускоренную работу в сети, необходимо явно включить ее на каждой применимой виртуальной машине. См. Инструкции в разделе Создание виртуальной машины Linux с ускоренной сетью.

Масштабирование на стороне приема

Масштабирование на стороне приема (RSS) — это технология сетевого драйвера, которая более эффективно распределяет прием сетевого трафика за счет распределения обработки приема между несколькими ЦП в многопроцессорной системе. Проще говоря, RSS позволяет системе обрабатывать больше полученного трафика, потому что он использует все доступные процессоры вместо одного.Для более технического обсуждения RSS см. Введение для получения бокового масштабирования.

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

TCP TIME_WAIT и TIME_WAIT убийство

TCP TIME_WAIT — еще один распространенный параметр, влияющий на производительность сети и приложений.На загруженных виртуальных машинах, которые открывают и закрывают множество сокетов в качестве клиентов или серверов (IP-адрес источника: порт источника + IP-адрес назначения: порт назначения), во время нормальной работы TCP данный сокет может оказаться в состоянии TIME_WAIT для много времени. Состояние TIME_WAIT предназначено для того, чтобы разрешить доставку любых дополнительных данных в сокет перед его закрытием. Таким образом, стеки TCP / IP обычно предотвращают повторное использование сокета, молча отбрасывая TCP SYN-пакет клиента.

Время, в течение которого сокет находится в TIME_WAIT, можно настроить.Он может составлять от 30 секунд до 240 секунд. Сокеты — это ограниченный ресурс, и количество сокетов, которые можно использовать в любой момент времени, можно настроить. (Количество доступных сокетов обычно составляет около 30 000.) Если доступные сокеты потребляются, или если клиенты и серверы имеют несовпадающие настройки TIME_WAIT, и виртуальная машина пытается повторно использовать сокет в состоянии TIME_WAIT, новые соединения не будут выполнены как пакеты TCP SYN молча сбрасываются.

Значение диапазона портов для исходящих сокетов обычно настраивается в стеке TCP / IP операционной системы.То же самое верно для настроек TCP TIME_WAIT и повторного использования сокетов. Изменение этих чисел потенциально может улучшить масштабируемость. Но, в зависимости от ситуации, эти изменения могут вызвать проблемы совместимости. Будьте осторожны, если измените эти значения.

Вы можете использовать убийство TIME_WAIT, чтобы устранить это ограничение масштабирования. Убийство TIME_WAIT позволяет повторно использовать сокет в определенных ситуациях, например, когда порядковый номер в IP-пакете нового соединения превышает порядковый номер последнего пакета из предыдущего соединения.В этом случае операционная система позволит установить новое соединение (примет новый SYN / ACK) и принудительно закрыть предыдущее соединение, которое находилось в состоянии TIME_WAIT. Эта возможность поддерживается на виртуальных машинах Windows в Azure. Чтобы узнать о поддержке других виртуальных машин, обратитесь к поставщику ОС.

Чтобы узнать о настройке параметров TCP TIME_WAIT и диапазона портов источника, см. Параметры, которые можно изменить для повышения производительности сети.

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

Максимальная исходящая пропускная способность ВМ

Azure предоставляет виртуальные машины разных размеров и типов, каждая из которых обладает различным набором возможностей производительности.Одна из этих возможностей — пропускная способность сети (или полоса пропускания), которая измеряется в мегабитах в секунду (Мбит / с). Поскольку виртуальные машины размещаются на общем оборудовании, емкость сети должна быть справедливо распределена между виртуальными машинами, использующими одно и то же оборудование. Большим виртуальным машинам выделяется больше пропускной способности, чем виртуальным машинам меньшего размера.

Пропускная способность сети, выделенная каждой виртуальной машине, измеряется по исходящему (исходящему) трафику с виртуальной машины. Весь сетевой трафик, покидающий виртуальную машину, засчитывается в выделенный лимит, независимо от места назначения.Например, если для виртуальной машины установлено ограничение в 1000 Мбит / с, это ограничение применяется независимо от того, предназначен ли исходящий трафик для другой виртуальной машины в той же виртуальной сети или за пределами Azure.

Входящие данные напрямую не измеряются и не ограничиваются. Но есть и другие факторы, такие как ограничения ЦП и хранилища, которые могут повлиять на способность виртуальной машины обрабатывать входящие данные.

Ускоренная работа в сети разработана для повышения производительности сети, включая задержку, пропускную способность и использование ЦП.Ускоренная работа в сети может повысить пропускную способность виртуальной машины, но это возможно только в пределах выделенной ей пропускной способности.

Виртуальные машины Azure имеют по крайней мере один подключенный к ним сетевой интерфейс. Их может быть несколько. Пропускная способность, выделенная виртуальной машине, представляет собой сумму всего исходящего трафика по всем сетевым интерфейсам, подключенным к машине. Другими словами, полоса пропускания распределяется для каждой виртуальной машины независимо от того, сколько сетевых интерфейсов подключено к машине.

Ожидаемая исходящая пропускная способность и количество сетевых интерфейсов, поддерживаемых виртуальными машинами каждого размера, подробно описаны в разделе «Размеры для виртуальных машин Windows в Azure». Чтобы увидеть максимальную пропускную способность, выберите тип, например Общего назначения , а затем найдите раздел о серии размеров на странице результатов (например, «Серия Dv2»). Для каждой серии есть таблица с сетевыми характеристиками в последнем столбце, озаглавленном «Макс. Количество сетевых адаптеров / ожидаемая пропускная способность сети (Мбит / с)».

Предел пропускной способности применяется к виртуальной машине.Эти факторы не влияют на пропускную способность:

  • Количество сетевых интерфейсов : ограничение пропускной способности применяется к сумме всего исходящего трафика с виртуальной машины.

  • Ускоренная работа в сети : Хотя эта функция может быть полезна для достижения опубликованного лимита, она не меняет лимит.

  • Назначение трафика : все пункты назначения учитываются в лимите исходящего трафика.

  • Протокол : весь исходящий трафик по всем протоколам учитывается при подсчете лимита.

Дополнительные сведения см. В разделе Пропускная способность сети виртуальной машины.

Соображения относительно производительности Интернета

Как обсуждалось в этой статье, факторы в Интернете и вне контроля Azure могут влиять на производительность сети. Вот некоторые из этих факторов:

  • Задержка : на время прохождения туда и обратно между двумя пунктами назначения могут влиять проблемы в промежуточных сетях, трафик, который не проходит по «кратчайшему» пути, и неоптимальные пути пиринга.

  • Потеря пакетов : потеря пакетов может быть вызвана перегрузкой сети, проблемами физического пути и неэффективными сетевыми устройствами.

  • Размер MTU / фрагментация : фрагментация по пути может привести к задержкам в прибытии данных или к пакетам, прибывающим не по порядку, что может повлиять на доставку пакетов.

Traceroute — хороший инструмент для измерения характеристик производительности сети (например, потери пакетов и задержки) на каждом сетевом пути между исходным устройством и целевым устройством.

Рекомендации по проектированию сети

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

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

Регионы Azure, виртуальные сети и задержка

Регионы Azure состоят из нескольких центров обработки данных, существующих в пределах одной географической области. Эти центры обработки данных могут физически не находиться рядом друг с другом. В некоторых случаях их разделяет целых 10 километров. Виртуальная сеть представляет собой логическое наложение поверх физической сети центра обработки данных Azure. Виртуальная сеть не подразумевает какой-либо конкретной топологии сети в центре обработки данных.

Например, две виртуальные машины, которые находятся в одной виртуальной сети и подсети, могут находиться в разных стойках, рядах или даже центрах обработки данных.Они могут быть разделены футами оптоволоконного кабеля или километрами оптоволоконного кабеля. Этот вариант может вызвать переменную задержку (разница в несколько миллисекунд) между разными виртуальными машинами.

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

Истощение порта источника NAT

Развертывание в Azure может обмениваться данными с конечными точками за пределами Azure в общедоступном Интернете и / или в общедоступном IP-пространстве. Когда экземпляр инициирует исходящее соединение, Azure динамически сопоставляет частный IP-адрес с общедоступным IP-адресом. После того, как Azure создаст это сопоставление, обратный трафик для исходящего исходящего потока также может достигать частного IP-адреса, с которого исходил поток.

Для каждого исходящего подключения балансировщику нагрузки Azure необходимо поддерживать это сопоставление в течение некоторого периода времени.Благодаря многопользовательской природе Azure поддержание этого сопоставления для каждого исходящего потока для каждой виртуальной машины может потребовать значительных ресурсов. Таким образом, существуют ограничения, которые установлены и основаны на конфигурации виртуальной сети Azure. Или, точнее говоря, виртуальная машина Azure может устанавливать только определенное количество исходящих подключений в определенный момент времени. Когда эти ограничения будут достигнуты, виртуальная машина не сможет устанавливать больше исходящих подключений.

Но это поведение можно настроить. Дополнительные сведения об исчерпании портов SNAT и SNAT см. В этой статье.

Измерение производительности сети в Azure

Ряд максимумов производительности в этой статье связаны с задержкой в ​​сети / временем приема-передачи (RTT) между двумя виртуальными машинами. В этом разделе представлены некоторые предложения по тестированию задержки / RTT и по тестированию производительности TCP и производительности сети виртуальных машин. Вы можете настроить и протестировать производительность TCP / IP и сетевых значений, обсужденных ранее, используя методы, описанные в этом разделе. Вы можете включить значения задержки, MTU, MSS и размера окна в расчеты, представленные ранее, и сравнить теоретические максимумы с фактическими значениями, которые вы наблюдаете во время тестирования.

Измерение времени приема-передачи и потери пакетов

Производительность

TCP во многом зависит от RTT и потери пакетов. Утилита PING, доступная в Windows и Linux, предоставляет самый простой способ измерить RTT и потерю пакетов. Вывод PING покажет минимальную / максимальную / среднюю задержку между источником и получателем. Он также покажет потерю пакетов. По умолчанию PING использует протокол ICMP. Вы можете использовать PsPing для тестирования TCP RTT. Для получения дополнительной информации см. PsPing.

Измерьте фактическую пропускную способность TCP-соединения

NTttcp — это инструмент для тестирования производительности TCP на виртуальной машине Linux или Windows.Вы можете изменить различные настройки TCP, а затем протестировать преимущества с помощью NTttcp. Для получения дополнительной информации см. Эти ресурсы:

Измерьте фактическую пропускную способность виртуальной машины

Вы можете протестировать производительность различных типов виртуальных машин, ускоренных сетей и т. Д. С помощью инструмента iPerf. iPerf также доступен для Linux и Windows. iPerf может использовать TCP или UDP для проверки общей пропускной способности сети. На тесты пропускной способности iPerf TCP влияют факторы, обсуждаемые в этой статье (например, задержка и RTT).Таким образом, UDP может дать лучшие результаты, если вы просто хотите проверить максимальную пропускную способность.

Дополнительные сведения см. В статьях:

Обнаружение неэффективного поведения TCP

При захвате пакетов клиенты Azure могут видеть TCP-пакеты с TCP-флагами (SACK, DUP ACK, RETRANSMIT и FAST RETRANSMIT), которые могут указывать на проблемы с производительностью сети. Эти пакеты конкретно указывают на неэффективность сети, которая возникает в результате потери пакетов. Но потеря пакетов не обязательно вызвана проблемами производительности Azure.Проблемы с производительностью могут быть результатом проблем приложений, проблем с операционной системой или других проблем, которые могут не иметь прямого отношения к платформе Azure.

Также имейте в виду, что некоторая повторная передача и дублирование ACK являются нормальным явлением в сети. Протоколы TCP были созданы, чтобы быть надежными. Свидетельство наличия этих TCP-пакетов при захвате пакетов не обязательно указывает на системную проблему в сети, если только они не чрезмерны.

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

Следующие шаги

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

TCP Selective Acknowledgments (SACK) — PacketLife.net

На прошлой неделе мы исследовали, как TCP использует порядковые номера и номера подтверждения для отслеживания данных при двунаправленной передаче между двумя конечными хостами.Однако мы наблюдали только идеальный TCP-поток, когда все пакеты доставляются на любой конец успешно и по порядку. Что произойдет, если кто-то пропадет?

На схеме ниже показано TCP-соединение между клиентом и сервером, разделенное сетью. Время идет вертикально сверху вниз по мере отправки пакетов.

Клиент отправляет серверу некоторый запрос, и сервер формулирует ответ, разбитый на четыре сегмента (пакетов) TCP. Сервер передает все четыре пакета в ответ на запрос.Однако второй ответный пакет теряется где-то в сети и никогда не достигает хоста. Давайте разберемся, что происходит.

Шаг 1

Сегмент ответа № 2 потерян.

Шаг 2

Клиент получает сегмент №3. Изучив порядковый номер сегмента, клиент понимает, что этот сегмент неисправен; отсутствуют данные между последним полученным сегментом и этим. Клиент передает дублированное подтверждение для пакета №1, чтобы предупредить сервер о том, что он не получил никаких (надежных) данных за пределами пакета №1.

Шаг 3

Поскольку сервер еще не знает, что что-то не так (потому что он еще не получил дублированное подтверждение от клиента), он продолжает отправку сегмента №4. Клиент понимает, что данные все еще отсутствуют, и повторяет свое поведение на третьем шаге, отправляя еще одно дублирующее подтверждение для пакета №1.

Шаг 4

Сервер получает первое дублированное подтверждение от клиента для пакета №1. Поскольку клиент подтвердил получение только первого из четырех сегментов, сервер должен повторно передать все три оставшихся сегмента в ответе.

Второе дублированное подтверждение, полученное от клиента, игнорируется.

Шаг 5

Клиент успешно получает и подтверждает три оставшихся сегмента.

Ввести выборочные подтверждения

Вы, наверное, заметили, что эта конструкция неэффективна: хотя был потерян только пакет №2, серверу также требовалось повторно передать пакеты №3 и №4, потому что у клиента не было возможности подтвердить, что он получил эти пакеты.

Первоначально эта проблема была решена в RFC 1072, а в последнее время в RFC 2018 путем введения опции TCP с селективным подтверждением (SACK).SACK работают, добавляя к дублированному пакету подтверждения параметр TCP, содержащий диапазон полученных несмежных данных. Другими словами, он позволяет клиенту сказать: «У меня в порядке только до пакета №1, но я также получил пакеты №3 и №4». Это позволяет серверу повторно передать только пакет (ы), которые не были получены клиентом.

Поддержка SACK согласовывается в начале TCP-соединения; если оба хоста поддерживают это, его можно использовать. Давайте посмотрим, как работает наш предыдущий пример с включенным SACK:

Шаг 1

Сегмент ответа № 2 потерян.

Шаг 2

Клиент понимает, что отсутствует сегмент между сегментами №1 и №3. Он отправляет дублированное подтверждение для сегмента №1 и присоединяет параметр SACK, указывающий, что он получил сегмент №3.

Шаг 3

Клиент получает сегмент №4 и отправляет другое дублированное подтверждение для сегмента №1, но на этот раз расширяет параметр SACK, чтобы показать, что он получил сегменты с №3 по №4.

Шаг 4

Сервер получает дублированный ACK клиента для сегмента №1 и SACK для сегмента №3 (оба в одном пакете TCP).Исходя из этого, сервер делает вывод, что у клиента отсутствует сегмент №2, поэтому сегмент №2 передается повторно. Следующий SACK, полученный сервером, указывает на то, что клиент также успешно получил сегмент №4, поэтому больше сегменты не нужно передавать.

Шаг 5

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

Достаточно теории, вот захват

Этот захват пакета содержит демонстрацию SACK в действии.Мы знаем, что оба конечных хоста поддерживают выборочные подтверждения по наличию опции SACK разрешено в двух пакетах SYN, # 1 и # 2.

Ближе к концу захвата мы видим, что пакет № 30 был получен не по порядку, и клиент отправил дублирующее подтверждение в пакете № 31. Этот пакет включает опцию SACK, указывающую, что сегмент в пакете № 30 был получен.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *