Цены снижены! Бесплатная доставка контурной маркировки по всей России

Птс на: Что такое ПТС — зачем и кто выдает, как выглядит дубликат

Содержание

Электронный ПТС

01.06.2021

1 ноября 2019 года страны Евразийского экономического союза (Россия, Белоруссия, Казахстан, Киргизия и Армения) начали переход на электронные паспорта транспортных средств. В тестовом режиме проект был запущен в июле 2019 года для ограниченного числа производителей транспортных средств. Предполагалось, что бумажные документы перестанут выдавать уже в ноябре, однако из-за технических сложностей, полный переход на ЭПТС отложили на 1 ноября 2020 года. С этой даты в России запретили производителям и импортерам выдавать бумажные ПТС, теперь на все новые машины только электронный ПТС.

Что такое ЭПТС?

Так выглядел бумажный ПТС на прицеп МЗСА для водной техники:

Теперь вместо бумажного ПТС для регистрации в ГИБДД требуется выписка из электронного ПТС (ЭПТС):

Обычно это распечатка А4 на 3 страницах, но можно попросить продавца прислать pdf-файл. Сама информация о транспортном средстве и владельце храниться в базе данных на elpts.ru, а выписка содержит самую основную информацию, например, не содержит информацию о владельце. Если вы владелец, и зарегистрированы на elpts.ru, то сможете распечатать выписку из ЭПТС, но там не будет указано, что вы владелец.

Что поменялось от введения ЭПТС?

Что обещали, когда вводили обязательные электронные паспорта транспортного средства:

  • «Стоит отметить, что в нем содержится гораздо больше информации, чем в бумажном ПТС. Например, расположение и структура VIN номера, номера двигателя, адрес завода-изготовителя, сборочного завода и представителя изготовителя.»
  • «Кроме того, в нем содержится огромный массив данных о самом транспортном средстве: тип кузова, габаритные размеры, количество дверей, тип и расположение двигателя, количество и объем цилиндров, тип коробки передач, размерность, нагрузка и скоростной индекс резины — всего около полутора сотен пунктов. В том числе, указывается максимальная масса прицепа без тормозной системы и прицепа оборудованного тормозами, а также технически допустимая максимальная нагрузка на опорно-сцепное устройство.»
  • «В ЭПТС будут внесены и все конструктивные изменения транспортного средства.»
  • «В электронном паспорте, информация о транспортном средстве разбита по тематическим разделам. К примеру, раздел „Общие характеристики транспортного средства“, содержит 42 пункта.»
  • «В перспективе, предполагается добавлять в ЭПТС данные о техническом обслуживании, пройденном техосмотре, с указанием пробега, а также сведения о ДТП. Благодаря этому, рынок подержанных автомобилей и прицепов станет гораздо более цивилизованным, покупатель сможет получить честную информацию о машине, которую планирует приобрести. Фактически, это своеобразный аналог американской системы CARFAX — любой желающий за небольшую плату получит историю автомобиля.»
Тиражировались примерно такие картинки:

Ничего этого в ЭПТС пока нет.

Что на наш взгляд получилось в реальности по состоянию на 1 июня 2021 года:

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

Надо ли менять ПТС на ЭПТС?

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


Комментарии

Пока нет комментариев

Написать комментарий

Что такое птс на питбайк?

PITBIKER / 6 ноября 2019 0 комментариев ПТС на питбайк

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

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

Различные нормативно-правовые акты приравнивают питбайк к разным категориям транспорта. Но нас интересуют только два из них: ПДД, которые устанавливают правила управления им, и КоАП, предусматривающий разного рода санкции за нарушения, в том числе штрафы, лишение автомобильных прав и штрафстоянку.

  • По ПДД питбайк – это транспортное средство, которое может быть мотоциклом при объёме двигателя более 50 см3 либо мопедом при рабочем объёме менее 50 кубов. Соответственно, ПДД не явно, но предусматривают, что для управления питбайком в 2019 году нужны права категории A или M, либо подкатегории A1.
  • Но, согласно КоАП, питбайк – это не транспортное средство. И отсюда следуют определённые выводы, в том числе отсутствие штрафа, штрафстоянки и ненужность прав для питбайка. Давайте этот момент разберём подробнее!

Примечание в статье 12.1, которое применяется ко всей 12 главе Административного кодекса, отвечающего за штрафы в области дорожного движения, гласит, что транспортное средство для

Поделиcь с друзьями:

В России в обязательном порядке начали выдавать электронные ПТС

https://ria.ru/20191101/1560462759.html

В России в обязательном порядке начали выдавать электронные ПТС

В России в обязательном порядке начали выдавать электронные ПТС — РИА Новости, 03.03.2020

В России в обязательном порядке начали выдавать электронные ПТС

Электронные паспорта транспортного средства (ЭПТС) взамен бумажных начали выдавать ко всем выпускаемым в России автомобилям. Соответствующие поправки в… РИА Новости, 03.03.2020

2019-11-01T00:15

2019-11-01T00:15

2020-03-03T17:09

евразийская экономическая комиссия

гибдд мвд рф

авто

россия

/html/head/meta[@name=’og:title’]/@content

/html/head/meta[@name=’og:description’]/@content

https://cdn23.img.ria.ru/images/156014/77/1560147763_0:198:2938:1851_1920x0_80_0_0_4a40a6bcbfad3a9757cf9f6a2197e55e.jpg

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

https://ria.ru/20191023/1560125542.html

россия

РИА Новости

[email protected]

7 495 645-6601

ФГУП МИА «Россия сегодня»

https://xn--c1acbl2abdlkab1og.xn--p1ai/awards/

2019

РИА Новости

[email protected]

7 495 645-6601

ФГУП МИА «Россия сегодня»

https://xn--c1acbl2abdlkab1og.xn--p1ai/awards/

Новости

ru-RU

https://ria.ru/docs/about/copyright.html

https://xn--c1acbl2abdlkab1og.xn--p1ai/

РИА Новости

[email protected]

7 495 645-6601

ФГУП МИА «Россия сегодня»

https://xn--c1acbl2abdlkab1og.xn--p1ai/awards/

https://cdn25.img.ria.ru/images/156014/77/1560147763_104:0:2835:2048_1920x0_80_0_0_fbfe4e7e978888ac3840f72673fe3b60.jpg

РИА Новости

[email protected]

7 495 645-6601

ФГУП МИА «Россия сегодня»

https://xn--c1acbl2abdlkab1og.xn--p1ai/awards/

РИА Новости

[email protected]

7 495 645-6601

ФГУП МИА «Россия сегодня»

https://xn--c1acbl2abdlkab1og.xn--p1ai/awards/

евразийская экономическая комиссия, гибдд мвд рф, авто, россия

МОСКВА, 1 ноя — РИА Новости. Электронные паспорта транспортного средства (ЭПТС) взамен бумажных начали выдавать ко всем выпускаемым в России автомобилям. Соответствующие поправки в законодательство вступили в силу в пятницу, 1 ноября.

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

Вместе с Россией на ЭПТС должны были также перейти страны Евразийского союза, однако в октябре Коллегия Евразийской экономической комиссии (ЕЭК) продлила срок выдачи бумажных паспортов транспортного средства (ПТС) на год, до 1 ноября 2020 года.

Первые легковые машины с ЭПТС в тестовом порядке были проданы в России весной. Тогда была отработана смена собственника по цепочке организация-изготовитель — дистрибьютор — официальный дилер — конечный покупатель (юридическое лицо) с отражением в ЭПТС на каждом этапе и дальнейшей регистрацией автомобиля в ГИБДД.

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

23 октября 2019, 17:00

Введение электронных ПТС не приведет к росту мошенничества, заверил Акимов

С 1 ноября 2020 года Паспорта транспортных средств будут оформляться в электронном виде — Внешнеэкономические новости от 01.10.2020

Паспорта транспортных средств на импортируемые в ЕАЭС транспортные средства (далее — ПТС) с 01 ноября 2020 г. будут оформляться в электронном виде.

Действие электронных ПТС согласно Решению Совета ЕЭК от 22 сентября 2015 г. № 122 распространяется на территорию всех государств-членов ЕАЭС. Наличие электронного ПТС является достаточным условием для регистрации и допуска транспортных средств к участию в дорожном движении.

Администратором системы электронных паспортов определено АО «Электронный паспорт». ФТС России и АО «Электронный паспорт» заключили соглашение об информационном взаимодействии, в рамках которого была успешно апробирована технология передачи сведений о выпуске транспортных средств в свободное обращение, а также об уплате утилизационного сбора.

Сведения об организациях, включенных в Единый реестр с предоставленными Минпромторгом России полномочиями на оформление электронных ПТС (электронных паспортов шасси транспортных средств), размещены на сайте Минпромторга России.

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

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

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

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

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

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

На транспортные средства (шасси, машины), на которые оформлены электронные ПТС, оформление ПТС на бумажном носителе не допускается.

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

Таможенники объяснили, надо ли менять бумажный ПТС на электронный

С 1 ноября 2020 года Владивостокская таможня прекратит выдачу паспортов транспортного средства. Вместо бумажных паспортов будут выдавать электронные — собственникам, у которых ПТС на руках, заменять его на электронный не обязательно. Об этом сообщает пресс-служба таможни.

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

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

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

По словам начальника таможенного поста Морской порт Владивосток Олега Усова, первые электронные ПТС на новые автомобили в России стали выдавать ещё в 2019 году в тестовом режиме. С 1 ноября прошлого года по состоянию на конец октября текущего года на таможенном посту Морской порт Владивосток оформили 69 740 автомобилей, 15 из которых — с электронными ПТС.

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

Что делать если потеряли ПТС на прицеп?

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

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

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

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

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

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

Возврат к списку

Как сделать ПТС на машину без документов: 3 варианта

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

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

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

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

Когда это может быть нужно

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

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

  • Все документы украдены: из дома, дачи, борсетки, из машины, вместе с машиной (которая потом найдена) и т. п., или же просто утрачены (пожар, питомцы и т. п. бытовые причины) – это самый простой случай, когда документация не «делается», а восстанавливается;
  • Машина куплена без передачи документов (бывает и такое), которая так и не состоялась т. к. хозяин пребывает неизвестно где – более сложная ситуация, но тоже решаема;
  • Машина не имеет документов и ее хозяева неизвестны – вариант печальный, но тоже не без надежды на благополучный исход;
  • Машины-конструкторы и криминальные авто – тут смотря по обстоятельствам, но у криминала в любом случае шансов совсем мало.

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

Варианты получения ПТС

Сразу отмечу, что успешное получение ПТС, как главного документа на автотранспорт, также означает и успешное решение вопроса со всей остальной документацией. Например, СТС (свидетельство о регистрации ТС) вам выдадут в комплекте с новыми номерами и паспортом на машину.

Вот почему главная цель для машины без документов – добиться положительного решения МРЭО (а именно там занимаются подобными случаями) по выдаче паспорта.

Автомобиль принадлежит вам и все документы утрачены вами

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

Чаще всего водитель лишается одновременно гражданского паспорта, СТС, страховки и водительского удостоверения (ВУ), т. к. эти документы входят в дорожный пакет.

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

И еще реже бывают случаи, когда у водителя отсутствует еще и ДКП (договор купли-продажи). Но имеют место и такие совпадения, когда, к примеру, ДКП потерялся давно, а уже потом пропали и остальные документы. И все равно, т. к. авто ваше, редко у кого не будет каких-либо копий, сканов, дополнительной документации (чеки СТО, сервисные книжки) и т. п.

В любом случае вот что вы можете восстановить с нуля сразу:

  • Гражданский паспорт в паспортном столе;
  • Страховой полис в вашей страховой компании;
  • Диагностическую карту на вашем СТО;
  • ДКП в МРЭО, куда он сдавался или у бывшего хозяина.

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

Автомобиль вам юридически не принадлежит и хозяин известен

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

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

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

Более сложный случай

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

Все хлопоты тут делятся на два дела:

  • Установление собственности на ТС;
  • Восстановление доступа ТС к передвижению по дорогам.
Установление права собственности

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

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

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

Внимание! Все документы должны составляться очень подробно и аккуратно т. к. именно это существенно влияет на вынесение положительного решения в МРЭО.

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

  • Договор купли-продажи;
  • Акт приема-передачи ТС;
  • Финансовая расписка в получении средств за автомобиль;
  • Объяснительная о владении и утрате основной документации от прежнего собственника;
  • Объяснительная об обстоятельствах приобретения вами данного ТС;
  • Какие-либо другие дополнительные документы: связанные с авто старые чеки, талоны, книжки, а также ксерокопия гражданского паспорта и ВУ.
Восстановление доступа ТС к передвижению по дорогам

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

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

Дежурному инспектору нужно будет объяснить суть дела, он просмотрит документы и выдаст вам бланк заявления на восстановление ПТС, а также реквизиты для оплаты пошлин.

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

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

Автомобиль без документов и неизвестно кому он принадлежал

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

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

Если авто без документов осталось в наследство, то нужно нотариально оформить его как наследуемую вещь. После этого любой наследник будет иметь право продать вам машину по стандартному ДКП.

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

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

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

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

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

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

Получив такое заключение, вы вправе подавать заявление в МРЭО на выдачу ПТС, СТС и госномеров по уже описанному мной сценарию.

Проблемные автомобили, продающиеся без ПТС

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

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

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

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

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

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

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

Следует иметь в виду, что правила ввоза, схемы разборки/сборки и легализация авто из Японии 2016 года пока что не изменились, но власти вполне могут в будущем как-то подкорректировать законодательство в отношении «автораспилов».

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

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

Что делать если машина в аресте

Статья дополнена благодаря вопросу Вячеслава от 06.02.2017 .

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

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

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

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

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

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

Полезные советы

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

Заключение

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

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

Парень одев на головку камеру полез на башенный кран снимать Дубай с высоты. Тут и экстрим и Дубай):

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

Всего вам доброго, и до следующей встречи!

TCP Антисептическая жидкость — Обзор характеристик продукта (SmPC)

Эта информация предназначена для медицинских работников

Активные ингредиенты: Жидкий антисептик TCP представляет собой водный раствор фенола 0,175% мас. / Об. И галогенированных фенолов 0,68% мас. / Об. Водный жидкий антисептик. Симптоматическое облегчение боли в горле, в том числе связанной с простудой и гриппом. Обычные язвы во рту, порезы, ссадины, укусы, укусы, фурункулы, пятна и прыщи.

Взрослые, дети и пожилые люди.

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

Полоскать горло два раза в день TCP, разбавленным 5 частями воды. Не глотай.

Обычные язвы во рту.

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

Порезы, ссадины, укусы и укусы.

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

Фурункулы, пятна и прыщи.

Наносите неразбавленным каждые 4 часа. Не накрывать. Повышенная чувствительность к любому из активных ингредиентов. Обратитесь за медицинской помощью, если симптомы сохраняются более нескольких дней. Хранить в недоступном для детей месте. Нет опыта использования продукта во время беременности и кормления грудью, но продукт широко применяется в течение многих лет без каких-либо побочных эффектов. Следует избегать использования при аллергических кожных заболеваниях.Маловероятно, что серьезные побочные эффекты возникнут в результате передозировки этого продукта. Случайное проглатывание: при случайном проглатывании чистого количества TCP (более 30 мл) немедленно выпейте от 0,5 до 1 литра воды. Если дискомфорт не проходит, обратитесь к врачу. Галогенированные фенолы действуют на все патогенные микроорганизмы одинаково и примерно в одинаковой степени, т. Е. Они неспецифичны, их активность существенно не снижается из-за наличия относительно большого количества неживого органического вещества, что означает их относительно простое химическое строение. что их использование не способствует появлению штаммов микроорганизмов, приспособленных к сопротивлению их действию.Жидкий антисептик TCP предназначен только для местного применения. Значительное всасывание из этой лекарственной формы для местного применения считается маловероятным. Вспомогательные вещества: глицерин, концентрированная фосфорная кислота, хинолиновый желтый (E104) и очищенная вода. Жидкий антисептик TCP хранится во флаконах из желтого бесцветного стекла емкостью 50 мл, 100 мл и 200 мл с белыми беспатными полипропиленовыми крышками с защитой от вскрытия или во флаконах из янтарного бесцветного стекла объемом 500 мл с белыми полипропиленовыми крышками без ваты. Omega Pharma Ltd.1 st Floor32 Vauxhall Bridge Road LONDON, SW1V 2SA, Великобритания

TCP в питьевой воде Калифорнии

В 2015 году Clean Water Action запустила новую кампанию по регулированию 1,2,3 TCP в питьевой воде в Калифорнии.В частности, мы призвали к стандарту питьевой воды, также называемому максимальным уровнем загрязнения или MCL 0,005 частей на миллиард, который был самым низким уровнем, при котором химическое вещество могло быть обнаружено. Мы также призвали Dow Chemical и Shell взять на себя ответственность за расходы на очистку воды, поскольку они вызвали загрязнение в системе водоснабжения штата (см. Ниже). В декабре 2017 года мы одержали крупную победу, когда стандарт стал законом. Кроме того, десятки систем водоснабжения успешно подали в суд на две мега-компании, чтобы возместить затраты на очистку, в то время как попытки корпораций оспорить стандарт в суде потерпели неудачу.

1,2,3-TCP: трагедия, которой можно было избежать

В 1940-х годах сельскохозяйственные подразделения Dow Chemical и Shell начали продавать два почвенных фумиганта под торговыми марками D-D и Telone, чтобы помочь фермерам справиться с нематодами, повреждающими урожай. Поскольку пестициды предназначены для уничтожения живых организмов, они по своей природе токсичны. Однако одно химическое вещество в составе D-D и Telone было особенно токсичным для человека и стойким в окружающей среде — 1,2,3-TCP или трихлорпропан (TCP).

По иронии судьбы, TCP не был ингредиентом, убившим нематод. Вместо этого при производстве фумигантов произошло загрязнение. Хотя до того, как продукты поступили на рынок, его можно было легко удалить, но Dow and Shell предпочли оставить его и просто — и обманчиво — зарегистрировали его как активный ингредиент. Другими словами, они ложно утверждали, что загрязнение было необходимо для эффективности их продуктов. И это несмотря на то, что у компаний уже были научные доказательства опасности этого химического вещества для человека.

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

Что такое 1,2,3 –TCP?

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

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

Воздействие на здоровье

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

В 2009 году Управление по оценке рисков для здоровья окружающей среды приняло цель общественного здравоохранения в отношении TCP в отношении питьевой воды на уровне 0,0007 частей на миллиард (частей на миллиард) — одна из самых строгих, когда-либо установленных в штате, — из-за исследований, показывающих, что чрезвычайно токсичен при низких уровнях. Цель общественного здравоохранения — это уровень воды, при котором не ожидается значительного воздействия на здоровье населения. Это не обязательный стандарт.

Насколько велика проблема?

В течение 2013 г. обнаружение 1,2,3-TCP в двух или более пробах было зарегистрировано в 372 активных и резервных источниках, принадлежащих 92 системам водоснабжения в 17 округах.Теперь, когда стандарт действует, общественные системы водоснабжения с уровнем содержания химического вещества, превышающим 5 частей на миллиард, должны обрабатывать воду. К сожалению, это не защищает людей в пострадавших районах, которые полагаются на частные колодцы, которые могут быть загрязнены, хотя Генеральная прокуратура штата изучает возможные юридические пути, чтобы гарантировать, что Dow и Shell предоставят некоторую финансовую помощь таким общинам.

Эта карта была составлена ​​KQED на основе информации Государственного управления водных ресурсов. На нем показаны водные системы, в которых были обнаружены значительные уровни 123-TCP.Изображение предоставлено KQED, репортер которой Саша Хоха обнаружила, что ее собственный водопровод загрязнен, как часть материала по этому вопросу.

Как изменить максимальное время ожидания повторной передачи TCP / IP

Сводка

TCP запускает таймер повторной передачи, когда каждый исходящий сегмент передается IP. Если подтверждение не было получено для данных в данном сегменте до истечения таймера, сегмент передается повторно до значения TcpMaxDataRetransmissions.Значение по умолчанию для этого параметра — 5 .

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

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

Для получения дополнительных сведений о последнем пакете обновления для Windows 2000 щелкните следующий номер статьи в базе знаний Microsoft:

260910 Как получить последний пакет обновления для Windows 2000

Дополнительная информация

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

322756 Как создать резервную копию и восстановить реестр в Windows
Параметр реестра TcpMaxDataRetransmissions контролирует количество повторных передач TCP отдельного сегмента данных, прежде чем он прервет соединение.Это значение не настроено по умолчанию, но его можно ввести, чтобы изменить количество повторных попыток по умолчанию.

Измените следующий подраздел в Windows 7, Windows 2008 R2, Windows 2008, Windows 2000, Windows Vista, Windows 2003 и Windows XP:

HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Services \ Tcpip \ Parameters

             
Имя значения: TcpMaxDataRetransmissions
Тип данных: REG_DWORD - Число
Допустимый диапазон: 0 - 0xFFFFFFFF
По умолчанию: 5

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

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

Измените следующий подраздел в Windows 2003, Windows XP и Windows 2000:

HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Services \ Tcpip \ Parameters \ Interfaces \ ID для адаптера

             
Имя значения: TCPInitialRtt
Тип данных: REG_DWORD
Допустимый диапазон: 300-65535 (миллисекунды в десятичном формате)
По умолчанию: 0xBB8 (3000 миллисекунд в шестнадцатеричном формате)

Описание: этот параметр управляет таймаутом начальной повторной передачи, который используется TCP при каждом новом соединении.Он применяется к запросу на соединение (SYN) и к первым сегментам данных, которые отправляются при каждом соединении. Например, значение «5000 decimal» устанавливает начальное время повторной передачи равным пяти секундам.

ПРИМЕЧАНИЕ. Увеличивать значение можно только для начального тайм-аута. Уменьшение значения не поддерживается.

Измените следующий ключ в Windows NT 4.0:

HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Services \ Tcpip \ Parameters

 Имя значения: InitialRttData Тип: REG_DWORD Допустимый диапазон: 0-65535 (десятичный) По умолчанию: 0xBB8 (3000 десятичный) 

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

Например, значение «5000 decimal» устанавливает начальное время повторной передачи равным пяти секундам.

Начальным RTO в Windows Server 2008 R2 и Windows 7 можно управлять с помощью команды NetSH в initialRTO.

Для получения предварительных требований и получения дополнительной информации щелкните следующий номер статьи, чтобы просмотреть статью в базе знаний Microsoft:

2472264 Невозможно настроить некоторые конфигурации TCP с помощью команды netsh в Windows Server 2008 R2

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

232512 TCP / IP может преждевременно повторно передавать пакеты

223450 TCP Настройка таймера начальной повторной передачи добавлена ​​в Windows NT

Для получения дополнительной информации поищите в Интернете «RFC 793 (раздел 3.7) Спецификация протокола TCP. «

Механизм более быстрого восстановления TCP в сетях центров обработки данных

[Представлено 15 февраля 2021 г.]

Скачать PDF
Аннотация: Облачные интерактивные приложения, управляемые данными, генерируют рой небольших TCP-потоков. которые конкурируют за небольшое буферное пространство в коммутаторах центра обработки данных. Такой приложения требуют короткого времени завершения потока (FCT) для выполнения своей работы эффективно.Однако TCP не обращает внимания на составную природу приложения. данных и искусственно завышает FCT таких потоков на несколько порядков величина. Это связано с ориентированным на Интернет дизайном TCP, который устраняет время ожидания повторной передачи (RTO) должно составлять не менее сотен миллисекунд. К лучшему понять эту проблему, в этой статье мы используем эмпирические измерения в небольшой стенд для изучения на микроскопическом уровне воздействия различных типов потери пакетов на производительности TCP. В частности, мы выделяем потери пакетов которые влияют на хвостовую часть малых потоков, а также на скачкообразные потери, которые охватывают значительная часть небольшого окна перегрузки TCP-потоков в дата-центры, чтобы показать существенное влияние на FCT.Исходя из этого, мы предлагать так называемые, своевременно ретранслируемые ACK (или T-RACK), простая потеря механизм восстановления, чтобы скрыть недостатки длительного RTO даже в наличие больших потерь пакетов. Интересно, что T-RACKS достигает этого. прозрачно для самого TCP, поскольку он не требует изменения TCP в виртуальная машина (ВМ) арендатора. T-RACK могут быть реализованы как программная прокладка слой в гипервизоре между виртуальными машинами и сетевой картой сервера или на оборудовании в качестве сетевая функция в SmartNIC.Результаты моделирования и реальных испытаний что T-RACK обеспечивает заметное улучшение производительности.

История отправки

От: Ахмед М. Абдельмонием [просмотреть электронную почту]
[v1] Пн, 15 февраля 2021 г., 11:36:33 UTC (1204 КБ)

UDP против TCP для VoIP

В VoIP образцы звука помещаются в пакеты данных для передачи по IP-сети. Обычно один пакет содержит от 10 до 30 миллисекунд звука.TCP и UDP — два из наиболее часто используемых протоколов подключения, используемых для передачи данных через Интернет.

Данные передаются по Интернету пакетами. Думайте о них как о письмах: как и о письмах, на пакетах есть конверт с адресом отправителя / отправителя. TCP и UDP — это всего лишь два типа конвертов. Оба они несут данные и оба используют IP-адреса, но внешний конверт отличается. Подумайте о USPS и FedEx. Адрес на конверте — это IP-адрес, откуда пришел пакет (адрес источника) и куда он направляется (адрес назначения).TCP настолько распространен в Интернете, что обычно сочетается с IP и записывается как TCP / IP.

TCP: точность имеет значение

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

Поскольку TCP ориентирован на соединение, он также гарантирует доставку пакетов данных в том же порядке, в котором они были отправлены. Процесс выглядит примерно так:

  1. Конечная точка A отправляет пакет 1 конечной точке B.

  2. Конечная точка B принимает пакет 1 без ошибок и отправляет пакет подтверждения обратно в конечную точку A.

  3. Конечная точка A получает пакет подтверждения и переходит к отправке пакета 2 конечной точке B.

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

UDP: скорость имеет значение

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

UDP — это протокол, оптимизированный для своевременной доставки пакетов данных к месту назначения; он предназначен для сервисов реального времени, таких как VoIP, где важно поддерживать поток данных.

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

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

Почему UDP и TCP имеют значение для VoIP

Протоколы

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

Регистрации устройств

В настоящий момент у Junction Networks есть тысячи устройств, пытающихся подключиться к Junction Networks. Эти устройства включают в себя все, от отдельных SIP-телефонов до SIP-устройств и других УАТС. Большинство попыток подключения — это простая регистрация SIP. Регистрация SIP — это когда устройство SIP сообщает серверу, в данном случае Junction Networks, что оно доступно для звонков и каков его IP-адрес.Это общение происходит в любом месте от каждой минуты до каждого часа для каждого устройства. Это много пакетов.

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

VoIP-трафик лучше всего оставить как UDP-трафик как по причинам нагрузки на сервер, так и по причинам качества вызовов.

Качество звонка

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

Обзор балансировки нагрузки TCP-прокси | Google Cloud

TCP Proxy Load Balancing — это балансировщик нагрузки обратного прокси, который распределяет TCP трафик, поступающий из Интернета на экземпляры виртуальных машин (ВМ) в вашем Сеть Google Cloud VPC.Когда используешь Балансировка нагрузки TCP-прокси, трафик, поступающий через TCP-соединение, прекращается на уровень балансировки нагрузки, а затем перенаправляется на ближайший доступный бэкэнд используя TCP или SSL.

TCP Proxy Load Balancing позволяет использовать один IP-адрес для все пользователи по всему миру. Балансировщик нагрузки TCP-прокси автоматически маршрутизирует трафик к бэкэндам, ближайшим к пользователю.

На уровне Premium можно настроить балансировку нагрузки TCP Proxy как глобальную сервис балансировки нагрузки.На уровне Standard балансировщик нагрузки TCP-прокси обрабатывает нагрузку. балансировка на региональном уровне. В разделе Поведение балансировщика нагрузки в Уровни сетевых услуг.

В этом примере соединения для трафика от пользователей в Сеуле и Бостоне завершается на уровне балансировки нагрузки. Эти связи с маркировкой 1a и 2a . Устанавливаются отдельные соединения от нагрузки. балансировщик выбранных бэкэнд-инстансов. Эти соединения имеют маркировку 1b . и 2b .

Балансировка нагрузки в облаке с завершением TCP (щелкните, чтобы увеличить)

Балансировка нагрузки прокси TCP предназначена для трафика TCP на определенных хорошо известных порты, такие как порт 25 для SMTP. Для большего информацию см. Порт технические характеристики. Для клиентского трафика, зашифрованного на тех же портах, используйте Балансировка нагрузки SSL-прокси.

Для получения информации о том, чем балансировщики нагрузки Google Cloud отличаются от каждого прочее, см. следующие документы:

Преимущества

Некоторые преимущества балансировщика нагрузки TCP-прокси включают:

  • Завершение IPv6. TCP Proxy Load Balancing поддерживает как IPv4, так и IPv6 адреса для клиентского трафика. Клиентские запросы IPv6 завершаются на уровне балансировки нагрузки, а затем проксируются через IPv4 на ваш бэкэнды.
  • Интеллектуальная маршрутизация. Балансировщик нагрузки может направлять запросы на серверную часть. места, где есть вместимость. Напротив, балансировщик нагрузки L3 / L4 должен маршрут к региональным серверам без учета пропускной способности. Использование умнее маршрутизация позволяет инициализировать N + 1 или N + 2 вместо x * N.
  • Установка исправлений безопасности. Если уязвимости возникают в стеке TCP, Cloud Load Balancing автоматически применяет исправления к балансировщику нагрузки чтобы ваши серверы были в безопасности.
  • Поддержка следующих хорошо известных портов TCP. 25, 43, 110, 143, 195, 443, 465, 587, 700, 993, 995, 1883, 3389, 5222, 5432, 5671, 5672, 5900, 5901, 6379, 8085, 8099, 9092, 9200 и 9300.
Примечание. TCP Proxy Load Balancing не поддерживает TCP-порты 80 или 8080.Для HTTP-трафика используйте внешнюю балансировку нагрузки HTTP (S).

Архитектура

Ниже приведены компоненты балансировщиков нагрузки TCP-прокси.

Правила переадресации и IP-адреса

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

Каждое правило переадресации предоставляет один IP-адрес, который можно использовать в DNS. записи для вашего приложения. Балансировка нагрузки на основе DNS не требуется.Вы можете либо зарезервируйте статический IP-адрес, который вы можете использовать, либо разрешите Cloud Load Balancing назначит вам один вариант. Мы рекомендуем вам зарезервировать статический IP-адрес; в противном случае вы должны обновить свою запись DNS новым назначается эфемерный IP-адрес всякий раз, когда вы удаляете правило переадресации и создаете новый.

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

Целевые прокси

TCP Proxy Load Balancing завершает TCP-соединения от клиента и создает новые подключения к бэкэндам. По умолчанию исходный IP-адрес клиента и информация о порте не сохраняется. Вы можете сохранить эту информацию, используя ПРОКСИ протокол. Целевые прокси маршрутизируют входящие запросы напрямую к серверным службам.

Серверные службы

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

У каждого подсистемы балансировки нагрузки прокси-сервера

TCP есть один ресурс внутренней службы. Изменения в бэкэнд-сервис не происходит мгновенно. Внесение изменений может занять несколько минут. для распространения на Google Front Ends (GFE).

Каждая серверная служба указывает проверки здоровья для выполнения доступные бэкенды.

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

Протокол для связи с бэкэндами

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

Правила межсетевого экрана

Внутренние экземпляры должны разрешать подключения из следующих источников:

  • Балансировщик нагрузки Google Front End (GFE) для всех запросов, отправленных на ваш бэкэнды
  • Зонды для проверки работоспособности

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

  • На порт назначения для каждой проверки работоспособности серверной службы.

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

  • Для GCE_VM_IP_PORT NEG backends: к номерам портов конечные точки.

Правила межсетевого экрана реализуются на уровне экземпляра ВМ, а не на Прокси GFE. Вы не можете использовать правила брандмауэра Google Cloud для предотвращения трафик от балансировщика нагрузки.Вы можете использовать Google Cloud Armor для этого.

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

Для подсистем балансировки нагрузки прокси-сервера SSL и подсистемы балансировки нагрузки прокси-сервера TCP требуются следующие диапазоны источников. следует:

  • 130.211.0.0/22 ​​
  • 35.191.0.0/16

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

Исходные IP-адреса

Исходный IP-адрес для пакетов с точки зрения серверной части — , а не . Внешний IP-адрес Google Cloud балансировщика нагрузки. В других словами, есть два TCP-соединения:

  • Подключение 1, от исходного клиента к балансировщику нагрузки (GFE):

    • Исходный IP-адрес: исходный клиент (или внешний IP-адрес, если клиент находится за NAT или прокси-сервером прямого доступа).
    • IP-адрес назначения: IP-адрес вашего балансировщика нагрузки.
  • Подключение 2, от балансировщика нагрузки (GFE) к внутренней виртуальной машине или конечной точке:

    • IP-адрес источника: IP-адрес в одном из диапазонов, указанных в Правила межсетевого экрана.

    • IP-адрес назначения: внутренний IP-адрес внутренней виртуальной машины или контейнер в сети виртуального частного облака (VPC).

Открытые порты

Балансировщики нагрузки прокси TCP — это подсистемы балансировки нагрузки обратного прокси.Загрузка балансировщик завершает входящие соединения, а затем открывает новые соединения из балансировщик нагрузки на серверные ВМ. Эти балансировщики нагрузки реализованы с использованием Прокси-серверы Google Front End (GFE) по всему миру.

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

Запуск сканирования порта на IP-адресе балансировщика нагрузки на основе GFE бесполезен с точки зрения аудита по следующим причинам:

  • Сканирование порта (например, с помощью Nmap ) обычно не ожидает пакета ответа или пакет TCP RST при выполнении зондирования TCP SYN.GFE отправят SYN-ACK пакеты в ответ на SYN-зонды для различных портов, если ваш балансировщик нагрузки использует IP-адрес уровня Premium. Однако GFE отправляют пакеты только на ваш бэкэнды в ответ на пакеты, отправленные на IP-адрес вашего балансировщика нагрузки и порт назначения, настроенный в его правиле переадресации. Пакеты отправлены на разные IP-адреса балансировщика нагрузки или IP-адрес вашего балансировщика нагрузки на порт, не настроенный в вашем правиле переадресации, не приводит к пакетам отправляется на серверную часть вашего балансировщика нагрузки.Даже без какой-либо специальной настройки инфраструктура Google и GFE обеспечивают Глубокая защита от DDoS-атак и SYN-флуда.

  • На пакеты, отправленные на IP-адрес вашего балансировщика нагрузки, может ответить любой GFE в парке Google; однако сканирование IP-адреса балансировщика нагрузки и комбинация портов назначения опрашивает только один GFE на TCP-соединение. IP-адрес вашего балансировщика нагрузки не назначен отдельное устройство или система. Таким образом, сканирование IP-адреса нагрузки на основе GFE балансировщик не сканирует все GFE в парке Google.

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

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

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

Распределение трафика

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

Как распределяются соединения

TCP Proxy Load Balancing можно настроить как глобальную службу балансировки нагрузки. с премиум-уровнем и как региональный обслуживание на уровне Standard.

Для премиум-уровня:

  • У вас может быть только одна серверная служба, а серверная служба может имеют серверные части в нескольких регионах. Для глобальной балансировки нагрузки вы развертываете свой бэкэнды в нескольких регионах, а балансировщик нагрузки автоматически направляет трафик в ближайший к пользователю регион.Если регион загружен, балансировщик нагрузки автоматически направляет новые подключения в другой регион с доступная мощность. Существующие пользовательские подключения остаются в текущем регионе.
  • Google объявляет IP-адрес вашего балансировщика нагрузки со всех точек присутствие по всему миру. Каждый IP-адрес балансировщика нагрузки является глобальным произвольным.
  • Если вы настраиваете серверную службу с серверной частью в нескольких регионах, Google Внешние интерфейсы (GFE) пытаются направить запросы к работоспособному внутреннему экземпляру группы или NEG в регионе, ближайшем к пользователю.Подробная информация о процессе задокументировано на этой странице.

Для стандартного уровня:

  • Google рекламирует IP-адрес вашего балансировщика нагрузки из точек присутствия связанный с регионом правила переадресации. Балансировщик нагрузки использует региональный внешний IP-адрес.

  • Вы можете настроить серверные ВМ в том же регионе, что и правило переадресации. Процесс, описанный здесь, по-прежнему применяется, но GFE направляют запросы только на здоровые серверные ВМ в этом одном регионе.

Процесс распределения запроса:

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

Балансировщик нагрузки использует следующий процесс:

  1. Внешний IP-адрес правила переадресации объявляется граничными маршрутизаторами на границы сети Google.В каждом объявлении указывается следующий переход к Система балансировки нагрузки уровня 3/4 (Maglev) максимально приближена к пользователю.
  2. Системы
  3. Maglev проверяют исходный IP-адрес входящего пакета. Они направить входящий запрос в системы Maglev, которые гео-IP Google системы определяют как можно ближе к пользователю.
  4. Системы Maglev направляют трафик во внешний интерфейс Google (GFE) первого уровня. GFE первого уровня завершает TLS, если требуется, а затем направляет трафик на GFE второго уровня в соответствии с этим процессом:
    1. Если серверная служба использует группу экземпляров или GCE_VM_IP_PORT Серверные модули NEG, GFE первого уровня предпочитают GFE второго уровня, которые расположен в или рядом с регионом, который содержит группу экземпляров или NEG.
    2. Для серверных сегментов и серверных служб с гибридными NEG, без сервера NEG и интернет-NEG, GFE первого уровня выбирают GFE второго уровня в подмножество регионов, так что время приема-передачи между двумя GFE равно сведены к минимуму.

      Предпочтение GFE второго уровня не является гарантией и может динамически изменяться в зависимости от состояния и обслуживания сети Google.

      GFE второго уровня осведомлены о статусе проверки работоспособности и фактическом сервере использование емкости.

  5. GFE второго уровня направляет запросы к серверным модулям в зонах в пределах своего область.
  6. Для уровня Premium иногда GFE второго уровня отправляют запросы на серверные ВМ. в зонах разных регионов. Такое поведение называется перетекание .
  7. Перелив регулируется двумя принципами:

  • Перелива возможна, когда все серверные ВМ известны второму уровню GFE работают на пределе своих возможностей или работают нездорово.
  • GFE второго уровня содержит информацию для здорового, доступного бэкенды в зонах другого региона.

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

Поведение Spillover не исчерпывает все возможные Google Cloud зоны. Если вам нужно направить трафик от бэкендов в определенном зоны или всего региона, необходимо установить емкость масштабатора до нуля.Настройка серверных ВМ на отказ проверки работоспособности не гарантирует, что GFE второго уровня распространяется на серверные модули в зонах другого региона.

  • При распределении запросов на бэкенды GFE работают в зональном уровень.

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

  • Режим балансировки

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

    Для балансировки нагрузки прокси TCP режим балансировки может быть ПОДКЛЮЧЕНИЕ или ИСПОЛЬЗОВАНИЕ .

    Если режим балансировки нагрузки — ПОДКЛЮЧЕНИЕ , нагрузка распределяется в зависимости от того, как бэкэнд может обрабатывать множество одновременных подключений. Вы также должны указать ровно один из следующих параметров: maxConnections (кроме региональные группы управляемых экземпляров), maxConnectionsPerInstance или maxConnectionsPerEndpoint .

    Если режим балансировки нагрузки ИСПОЛЬЗОВАНИЕ , нагрузка распределяется на основе использования экземпляров в группе экземпляров.

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

    Сходство сеанса

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

    TCP Proxy Load Balancing предлагает привязка IP-адреса клиента, который перенаправляет все запросы с одного и того же IP-адреса клиента на один и тот же сервер.

    Отказоустойчивый

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

    Балансировка нагрузки для приложений GKE

    Если вы создаете приложения на Google Kubernetes Engine, вы можете использовать автономный NEG для балансировки нагрузки трафика непосредственно в контейнеры.С автономными NEG вы несут ответственность за создание Сервисный объект, который создает NEG, а затем связать NEG с серверной службой, чтобы балансировщик нагрузки может подключаться к стручкам.

    Связанная документация GKE:

    Ограничения

    • Балансировщики нагрузки прокси TCP не поддерживают пиринг сети VPC.

    Что дальше

    TCP в многоскачковых беспроводных одноранговых сетях: проблемы и решение | Журнал EURASIP по беспроводным коммуникациям и сетям

    В этом разделе мы представляем некоторые из основных подходов, которые были предложены в литературе для повышения производительности TCP в многозвенных беспроводных сетях.Мы перегруппировали эти подходы в четыре набора в соответствии со стратегией, используемой для повышения производительности TCP. Однако некоторые подходы могут быть сопоставлены с несколькими типами стратегий, но классифицируются только по их основной стратегии. Подходы, принадлежащие к одному набору, подразделяются на два типа: межуровневые подходы и многоуровневые подходы. Межуровневые предложения основаны на взаимодействии между двумя уровнями архитектуры взаимодействия открытых систем (OSI). В частности, межуровневое взаимодействие, рассматриваемое в этой статье, происходит между уровнем TCP и сетевым уровнем или уровнем канала данных.Эти подходы были мотивированы тем фактом, что «предоставление информации нижнего уровня верхнему уровню должно помочь верхнему уровню работать лучше». Многоуровневые подходы основаны на адаптации уровней OSI независимо от других уровней. Таким образом, в зависимости от того, какой уровень задействован, многоуровневые предложения можно разделить на три типа: уровень TCP, сетевой уровень и подходы канального уровня. Для каждого подхода, представленного здесь, представлены типичные схемы и описаны их механизмы, а также обсуждены их сильные и слабые стороны в улучшении производительности TCP в многозвенных беспроводных сетях.Кроме того, для каждой категории приводится сравнение основных характеристик различных усовершенствований TCP.

    3.1 Определение сбоев маршрутизации

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

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

    3.1.1 Уровни TCP
    Фиксированное RTO

    Dyer et al.представил фиксированный RTO [26], который представляет собой простой эвристический метод, который не полагается на обратную связь от нижележащих слоев. Фиксированное RTO предназначено для различения потери маршрута и перегрузки сети и, таким образом, пытается улучшить производительность TCP. В случае тайм-аута обычный TCP повторно передает неподтвержденный пакет и удваивает интервал RTO. Для каждой повторной передачи пакета RTO удваивается до тех пор, пока не будет получен ACK для повторно переданного пакета. Этот экспоненциальный рост RTO позволяет TCP изящно справляться с перегрузкой сети.Однако в многозвенных беспроводных сетях потери могут происходить часто и временно из-за потерь маршрута, а перегрузка сети возникает редко. Основываясь на этом и используя преимущества алгоритмов маршрутизации, предназначенных для быстрого восстановления нарушенных маршрутов, авторы показывают, что интуитивно понятно, что TCP повторно передает неподтвержденный пакет через определенные промежутки времени вместо того, чтобы ждать все более длительные периоды времени между ними. ретрансляции. Следовательно, фиксированный RTO сохраняет RTO фиксированным после первой повторной передачи.Когда тайм-ауты происходят последовательно, то есть отсутствующий ACK не получен до истечения второго RTO, это считается доказательством потери маршрута. Неподтвержденный пакет повторно передается снова, но RTO не удваивается во второй раз. RTO остается фиксированным до тех пор, пока маршрут не будет восстановлен и повторно переданный пакет не будет подтвержден.

    Для оценки производительности TCP с фиксированным RTO, тремя протоколами маршрутизации, двумя по запросу (Ad-Hoc on Demand Distance Vector (AODV) и Dynamic Source Routing (DSR)) и одним протоколом адаптивной проактивной маршрутизации (Adaptive Distance Vector (Adaptive Distance Vector (Adaptive Distance Vector) ADV)).Результаты показывают, что проактивный алгоритм ADV хорошо работает в различных условиях и что метод фиксированного RTO значительно улучшает производительность TCP по сравнению с двумя алгоритмами по запросу. Тем не менее предположение о том, что два последовательных тайм-аута являются исключительными результатами сбоев маршрута, требует дополнительного анализа, особенно при наличии перегрузки.

    TCP DOOR

    TCP обнаружение нарушения порядка и ответа (DOOR) [27] — это сквозной подход, который не требует какой-либо обратной связи от сети или от нижних уровней.Этот подход был разработан Ван и Чжан для повышения производительности TCP за счет обнаружения и реагирования на неупорядоченные события доставки пакетов, которые являются результатом частых изменений маршрута. В TCP-DOOR события нарушения порядка (OOO) интерпретируются как указание на сбой маршрута. Таким образом, отправитель может отличить изменение маршрута от перегрузки сети. Обнаружение ООО событий может быть выполнено либо отправителем, либо получателем. Хотя получатель может уведомить отправителя об обнаруженных неупорядоченных пакетах данных, сам отправитель может заметить ACK, поступающие не по порядку.Как только отправитель TCP распознает событие OOO, предлагаются два ответных действия. В первом действии отправитель может временно отключить механизм управления перегрузкой TCP, сохранив постоянные переменные состояния. В другом действии, если механизм управления перегрузкой был задействован в течение прошедшего периода времени, отправитель TCP должен немедленно восстановиться до состояния, предшествовавшего вызову управления перегрузкой.

    В TCP-DOOR авторы рекомендуют свой подход в первую очередь для среды, имеющей как специальные, так и фиксированные инфраструктурные сети, где адаптация подхода, основанного на обратной связи, особенно трудна.В целом TCP DOOR демонстрирует значительные улучшения по сравнению со стандартным TCP. Тем не менее, требуется дополнительный анализ, чтобы ответить на вопрос, что, если ООО не вызвано изменениями маршрута. Фактически, изменение маршрута — не единственная причина доставки пакетов вне очереди. Например, в протоколе многопутевой маршрутизации, таком как алгоритм временной маршрутизации (TORA) [28], может возникнуть ООО, если пакеты с разных путей неупорядочены.

    3.1.2 Подходы к сетевому уровню
    Маршрутизация резервного пути

    В этом подходе Lim et al.[29] исследовали производительность TCP по протоколу многопутевой маршрутизации. Показано, что многопутевая маршрутизация может улучшить доступность путей для TCP-соединений. Авторы обнаружили, что исходная многопутевая маршрутизация может ухудшить производительность TCP из-за частой доставки пакетов с нарушением порядка и неточности измерения среднего RTT. Поэтому они представляют новый вариант стратегии многопутевой маршрутизации, называемый маршрутизацией резервного пути. В стратегии маршрутизации резервного пути в любой момент времени используется только один путь.Однако стратегия маршрутизации резервного пути поддерживает несколько путей от источника к месту назначения. Другие альтернативные пути используются в качестве резервных, если текущий путь нарушен. Два метода рассматривались как критерии выбора путей. В первом методе путь с кратчайшим переходом выбирается в качестве основного пути, а путь с кратчайшей задержкой является альтернативным. Для второго метода путь с кратчайшей задержкой является основным, а максимально непересекающийся путь выбирается в качестве альтернативы.Альтернативный максимально непересекающийся путь — это путь, который имеет наименьшее количество перекрывающихся промежуточных узлов с основным путем.

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

    Маршрутизация с использованием нескольких интерфейсов

    В [31] Юн и Вайдья предложили схему сетевого уровня, которая использует несколько разнородных беспроводных интерфейсов в многозвенных беспроводных сетях. Идея состоит в том, чтобы использовать два гетерогенных беспроводных интерфейса в каждом узле: первичный интерфейс 802.11a и вторичный интерфейс 802.11b (или 802.11). Первичный путь через интерфейс 802.11a поддерживается протоколом реактивной маршрутизации, таким как DSR, а вторичный путь через 802.11b поддерживается протоколом упреждающей маршрутизации, таким как маршрутизация с использованием вектора расстояния от места назначения (DSDV). В нормальных условиях пакеты данных TCP будут использовать первичный путь, который имеет более высокую скорость, а пакеты управления (ACK) будут использовать вторичный путь. В случае сбоев канала TCP будет использовать вторичный путь для восстановления своих пакетов и сохранения размера окна. Он продолжает обмениваться данными с использованием низкоскоростного интерфейса до тех пор, пока не будет восстановлен высокоскоростной путь. 802.11b (или 802.11) используется на вторичном пути, поскольку они обладают другими свойствами, чем интерфейс 802.11a (т. Е. Более медленная скорость, но больший диапазон передачи).

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

    3.1.3 Межуровневые подходы TCP и сети
    Метод явного уведомления об отказе канала (ELFN)

    ELFN [32] — это простой подход, разработанный Холландом и Вайдья. Этот подход основан на реальном взаимодействии между TCP и протоколами маршрутизации.Это взаимодействие направлено на предоставление информации о сбоях канала отправителю TCP, чтобы TCP мог отличить потери пакетов, вызванные сбоями канала, от потерь, вызванных перегрузкой. Когда происходит сбой связи, сообщение ELFN, которое совмещается с сообщением об ошибке маршрута, будет отправлено протоколом маршрутизации отправителю TCP. Сообщение ELFN похоже на сообщение протокола управляющих сообщений Интернета (ICMP) «хост недоступен», которое содержит адреса и порты отправителя-получателя, а также порядковый номер пакета TCP.Отправитель, получив сообщение ELFN, отключает свои таймеры повторной передачи и переходит в режим ожидания. В течение периода ожидания отправитель TCP использует периодическое зондирующее сообщение, чтобы определить, восстановлен ли маршрут. Если получено подтверждение пробного пакета (подразумевающее, что маршрут восстановлен), отправитель TCP возобновляет работу таймеров повторной передачи и выходит из режима ожидания, чтобы продолжить нормальные операции. Таким образом, TCP может избежать фазы медленного старта и продолжить работу с высокой скоростью.

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

    3.1.4 Сравнение

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

    В решениях сетевого уровня маршрутизация резервного пути и маршрутизация с использованием нескольких интерфейсов поддерживают два маршрута: один основной путь для нормальной передачи данных и другой резервный путь для восстановления данных в случае сбоев маршрута.В резервной маршрутизации это делается с помощью протокола многопутевой маршрутизации. Между тем, Routing Exploiting Multiple Interfaces использует разные протоколы маршрутизации, работающие через разные радиоинтерфейсы. Сравнивая эти два подхода, можно сказать, что маршрутизация с использованием нескольких интерфейсов работает лучше, чем маршрутизация резервного пути, но за счет занятости, когда каждый узел должен быть оснащен двумя радиоинтерфейсами. Предложение TCP и межуровневого сетевого взаимодействия, ELFN, основано на явном уведомлении от сетевого уровня для обнаружения сбоя маршрута.Для обнаружения повторных подключений ELFN использует механизм зондирования, и реализовать этот механизм непросто. Какое оптимальное значение интервала зондирования? И каков смысл этого механизма в случае высокой нагрузки? В частности, видно, что в случае высокой нагрузки ELFN работает хуже, чем стандартный TCP. Таблица 1 иллюстрирует сводку основных характеристик обсуждаемых усовершенствований TCP.

    Таблица 1 Сравнение основных характеристик различных расширений TCP

    3.2 Оценка полосы пропускания и состояния канала

    Как обсуждалось в разделе 2, традиционный механизм TCP управления перегрузкой на основе потерь не может точно настроить скорость передачи, когда он используется в многозвенных беспроводных сетях. Потеря пакетов не всегда является признаком перегрузки; это могло произойти из-за мобильности или из-за ошибок беспроводной связи. Хорошо известно, что один из критических источников низкой производительности TCP в многоинтервальных беспроводных сетях лежит на «озере», координате между уровнями TCP и MAC. Если существует большая разница между скоростями передачи MAC и TCP, это может вызвать перегрузку сети и повторные передачи.С этой целью недавно было предложено несколько схем TCP для решения проблемы за счет лучшей оценки доступной полосы пропускания и статуса канала. Типичные схемы, использующие управление скоростью для повышения производительности TCP, включают TCP-Vegas [33], TCP-Westwood [34], TCP-CL [35], управление скоростью передачи на основе эффективности канала [36] и TCPCC [ 37].

    3.2.1 Подходы на уровне TCP
    TCP-Vegas

    TCP-Vegas [33] — один из вариантов TCP, в котором используется механизм управления перегрузкой на основе скорости.Он был разработан в Университете Аризоны Бракмо и Петерсоном. Основная идея состоит в том, чтобы тщательно настроить скорость отправки, сравнив ее с расчетной скоростью. Он подчеркивает задержку пакета, а не потерю пакета, как признак, помогающий определить скорость отправки пакетов. Кроме того, он также изменяет алгоритмы обнаружения и предотвращения перегрузки для повышения общей пропускной способности TCP. Несмотря на то, что TCP-Vegas не был специально разработан для беспроводной связи, производительность TCP может быть улучшена, поскольку присущий ему алгоритм управления перегрузкой на основе скорости может проактивно избегать возможных перегрузок и потерь пакетов, гарантируя, что количество ожидающих сегментов в сети невелико. .

    Наиболее существенное различие между TCP-Vegas и традиционными вариантами TCP заключается в использовании метода на основе скорости для управления размером окна перегрузки. В отличие от других разновидностей, таких как Reno, NewReno и т. Д., Которые обнаруживают перегрузку только после того, как она действительно произошла через отбрасывание пакетов, TCP Vegas обнаруживает перегрузку на начальной стадии на основе увеличения значений RTT пакетов в соединении. Для каждого RTT TCP-Vegas сравнивает ожидаемую пропускную способность с фактической измеренной пропускной способностью.Ожидаемая пропускная способность рассчитывается делением текущего размера окна на минимальный наблюдаемый RTT. Однако фактическая пропускная способность измеряется как количество байтов, переданных между моментом передачи выделенного сегмента и его подтверждением, деленное на время, необходимое для получения подтверждения. Если разница между двумя значениями меньше α , TCP-Vegas линейно увеличивает cwnd для следующего RTT, предполагая, что пропускная способность меньше доступной полосы пропускания; и если разница превышает β , TCP-Vegas линейно уменьшает окно перегрузки для следующего RTT, чтобы избежать выхода за пределы полосы пропускания.Если разница между α и β , TCP-Vegas сохраняет cwnd без изменений. Помимо модификации управления перегрузкой на основе скорости, TCP-Vegas модифицировал механизм медленного старта, позволив cwnd экспоненциально расти только один раз в каждом втором RTT. Это позволяет TCP-Vegas сравнивать ожидаемую и фактическую пропускную способность. Если разница превышает пороговое значение γ , TCP-Vegas переходит из режима медленного старта в режим линейного увеличения / линейного уменьшения, как описано выше.

    Однако TCP-Vegas также унаследовал некоторые недостатки обычного TCP. Он не может справиться с последствиями сбоя маршрута и ошибок беспроводного канала. Более того, как сообщается в [38], TCP-Vegas страдает рядом других проблем. Во-первых, поскольку TCP-Vegas использует baseRTT для расчета ожидаемой пропускной способности в беспроводной сети, baseRTT может не отражать фактическое минимальное измеренное время приема-передачи соединения из-за изменения маршрута в многопролетных беспроводных сетях. Следовательно, есть неточности в расчетной ожидаемой пропускной способности после события изменения маршрута.Другая проблема — это несправедливость TCP-Vegas, когда он взаимодействует с другими версиями, такими как Reno. В этом случае производительность Vegas ухудшается, потому что Vegas снижает скорость отправки до Reno, поскольку он рано обнаруживает перегрузку и, следовательно, предоставляет большую пропускную способность для сосуществующих потоков TCP Reno. Следовательно, справедливость, обеспечиваемая механизмом линейного увеличения / уменьшения для контроля перегрузки в Вегасе, является важным вопросом для исследования.

    TCP-Westwood — еще один вариант TCP, основанный на оценке пропускной способности, который был представлен Casetti et al.[34]. TCP-Westwood — это модификация на стороне отправителя, которая улучшает производительность TCP Reno как в проводных, так и в беспроводных сетях. Ключевая идея — непрерывно оценивать полосу пропускания, используемую соединением, путем измерения скорости возвращаемых ACK. Когда происходит потеря, либо при получении трех дублированных ACK, либо после тайм-аута, TCP-Westwood использует предполагаемую полосу пропускания, чтобы намного быстрее зафиксировать состояние перегрузки, а затем вычисляет окно перегрузки и порог медленного запуска. Авторы называют этот механизм более быстрым восстановлением.Более того, при длительном отсутствии ACK расчетная полоса пропускания будет экспоненциально уменьшаться. Смысл этой стратегии прост: в случае потери пакета, в отличие от обычного TCP, который слепо уменьшает cwnd и ssthresh , TCP Westwood пытается вычислить правильные значения cwnd и ssthresh , которые являются в соответствии с эффективной пропускной способностью, используемой во время перегрузки. Фактически, традиционные схемы TCP не эффективны в беспроводных каналах связи, где спорадические потери из-за проблем с радиоканалом часто неверно интерпретируются как признак перегрузки и, таким образом, приводят к ненужному сокращению окна.Тем не менее, TCP-Westwood особенно устойчив к беспроводной связи, потому что он пытается поддерживать скорость передачи на уровне непосредственно перед возникновением потери пакета, чтобы избежать ненужного уменьшения окна.

    Экспериментальные исследования TCP-Westwood показывают улучшение пропускной способности и справедливости. Кроме того, совместимость с TCP Reno наблюдалась в серии экспериментов, показывающих, что соединения TCP Reno не испытывают недостатка в соединениях TCP-Westwood. Более того, TCP-Westwood полностью соответствует принципу построения сквозного TCP, и это улучшение особенно заметно в беспроводных сетях с потерями в каналах связи.Однако, в отличие от обычного TCP, который не может отличить случайные ошибки от потери из-за перегрузки, производительность TCP-Westwood также нечувствительна к случайным ошибкам. Когда возникает случайная ошибка, вызванная ошибкой маршрута или ошибкой канала, расчетная полоса пропускания быстро уменьшается, как описано ранее, и это приводит к снижению производительности после восстановления пути. Подобно TCP-Vegas, TCP-Westwood использует наблюдаемое наименьшее время приема-передачи (RTTmin) при оценке пропускной способности. Это может привести к проблемам, поскольку любое изменение маршрута сделает недействительным RTTmin и, таким образом, приведет к неверным оценкам пропускной способности.Таким образом, стремление исследователей состоит в том, чтобы сделать TCP способным реагировать на различные типы ошибок.

    3.2.2 Межуровневые подходы
    TCP-CL

    Ченг и Лин предложили TCP-CL [35], который представляет собой совместный подход, основанный на межуровневой структуре для повышения сквозной производительности TCP. в беспроводных сетях. Авторы показывают, что путем внесения незначительных изменений в устаревшие протоколы MAC и TCP IEEE 802.11, TCP-CL обеспечивает значительное улучшение производительности TCP в многозвенных беспроводных средах.Стандартный уровень MAC IEEE 802.11 обеспечивает надежную работу по каналу связи путем определения параметра ограничения повторных попыток (RETL). Используя этот параметр всякий раз, когда узлу не удается передать кадр, он повторно передает этот кадр, а затем увеличивает значение RETL на единицу. Если значение RETL превышает заданный порог (т. Е. 7 для базовых механизмов доступа и 4 для виртуальных механизмов определения несущей), кадр будет отброшен, о сбое канала будет сообщено на канальный уровень, а для RETL будет установлено значение нуль.RETL также сбрасывается в ноль после успешной передачи кадра. Тем не менее, если канал имеет высокую степень конкуренции, уровень MAC может ошибочно сделать вывод о сбое канала. Следовательно, такое неправильное толкование отказов канала может серьезно повлиять на производительность TCP.

    Таким образом, чтобы уменьшить влияние конкуренции на канальном уровне на производительность TCP, этот подход расширяет схему IEEE 802.11 DCF, вводя новую переменную, обозначенную как предел повторной передачи (RETF), для записи количества попыток повторной передачи в в случае сбоев непрерывной передачи.Если значение RETF не превышает пороговое значение повторной передачи, а также получение TCP ACK в том же потоке, он пересылает совмещенные TCP-сообщения с отрицательным подтверждением (NAK) с использованием обратного TCP ACK по сквозному пути и увеличивает значение RETF. Если значение RETF превышает порог повторной передачи, он отбрасывает переданный пакет, а затем сбрасывает конкуренцию и RETL, соответственно. Опция NAK запускается только тогда, когда кадр канального уровня отбрасывается в результате ошибок передачи, и ограничивается пороговым значением повторной передачи.Если фрейм данных TCP отбрасывается после нескольких попыток повторной передачи (ограничен порогом повтора), протокол уровня MAC запускает параметр TCP NAK в заголовке TCP, связанный с порядковым номером отброшенного пакета, а затем совмещает этот параметр, используя обратный TCP ACK, чтобы уведомить отправителя TCP о повторной передаче отсутствующего пакета. Обратите внимание, что уведомление NAK отправляется в совмещенном режиме с возвращенным сегментом TCP ACK, чтобы избежать увеличения конкуренции на канальном уровне. Эта межуровневая поддержка протокола канального уровня гарантирует, что протокол TCP транспортного уровня знает об ошибке передачи на канальном уровне и может затем реагировать на эту ошибку в соответствии с информацией о повреждении беспроводной сети, передаваемой принятым NAK.Таким образом, TCP может различать потери из-за повреждения и перегрузки, что позволяет ему реагировать соответствующим образом в каждом случае.

    В рамках этого подхода было предложено межуровневое решение, обозначенное как TCP-CL, для повышения производительности TCP в многозвенных беспроводных сетях. В целом, результаты показывают, что предложенная схема имеет ряд ключевых преимуществ по сравнению с обычным TCP, включая более эффективную обработку частых потерь передачи, более быструю реакцию на потери из-за повреждения, а также способность различать ошибки перегрузки и ошибки передачи и примите соответствующие меры по исправлению положения.Важно отметить, что предлагаемый механизм не требует, чтобы какой-либо узел кэшировал какие-либо неподтвержденные пакеты для каждого TCP-соединения, проходящего через него. Производительность TCP-CL сравнивается с производительностью стандартных схем TCP-Reno и TCP-Westwood с точки зрения пропускной способности. Результаты моделирования показывают, что TCP-CL обеспечивает значительное улучшение производительности TCP-передачи по многосегментным беспроводным сетям. Однако эта схема сохраняет единственный путь к каждому месту назначения без эффективного использования доступных путей.Более того, для изучения влияния мобильности на эту схему требуется дополнительный анализ.

    Управление скоростью передачи на основе эффективности канала — это межуровневый подход, проведенный Zhang et al. [36]. В этом подходе авторы показывают, что в многозвенных беспроводных сетях, если скорость передачи TCP не совпадает со скоростью передачи протокола управления доступом к среде (MAC), это вызывает перегрузку сети и снижение производительности сети. Поэтому они предлагают новый подход к управлению скоростью передачи TCP путем использования информации MAC через межуровневый уровень.Основной вклад этого подхода заключается в том, чтобы передать реальную эффективность канала протокола MAC в TCP, чтобы адаптивно управлять скоростью передачи. Это поможет уменьшить большую разницу между скоростью передачи TCP и MAC и, как следствие, уменьшить перегрузку сети и повторную передачу. С этой целью были введены две важные меры: эффективность реального канала MAC и эффективность виртуального канала TCP. В качестве критерия реальной эффективности MAC-канала TCP регулирует скорость передачи, которая неявно контролируется окном перегрузки и потоком TCP ACK, чтобы поддерживать эффективность виртуального TCP-канала, близкую к реальной эффективности MAC-канала.

    Этот подход предлагает новый механизм обратной связи с TCP об эффективности реального канала протокола MAC, чтобы снизить нагрузку на протокол MAC до того, как произойдет событие перегрузки, и повысить производительность сети. Результаты моделирования показывают, что предложенный механизм превосходит 802.11 DCF с точки зрения пропускной способности и задержки. Однако этот подход не учитывает влияние сбоев маршрута и высокого BER на промежуточных узлах. Более того, мобильность оказывает большое влияние на эффективность канала, и неясно, как этот подход будет работать в мобильных сетях, поэтому требуется дополнительный анализ.

    TCPCC — это межуровневый подход, проведенный Zhang et al. [37]. В этом исследовании авторы показывают, что чрезмерное внедрение обычного механизма окна TCP приводит к серьезным конфликтам, а среднее количество конфликтов вызывает перегрузку сети. Они также показывают, что для характеристики состояния сети следует использовать два важных показателя: использование канала (CU) и коэффициент конкуренции (CR). Затем, на основе этих двух показателей, они предлагают новый механизм управления скоростью передачи TCP, основанный на использовании канала и коэффициенте конкуренции (TCPCC).В этом механизме каждый узел собирает информацию о статусе занятости сети и соответственно определяет CU и CR. Значения CU и CR, возвращаемые через ACK, в конечном итоге определяются узлом узкого места в потоке. Отправитель TCP контролирует свою скорость передачи на основе информации обратной связи.

    Результаты моделирования в [37] показывают, что механизм TCPCC значительно превосходит традиционный механизм TCP и механизм контроля конфликтов TCP с точки зрения пропускной способности и сквозной задержки.Тем не менее, подобно управлению скоростью передачи на основе эффективности канала, TCPCC не имеет механизма для обработки сбоев маршрута. Более того, TCPCC требует использования явной информации обратной связи от промежуточных узлов. Развернуть TCPCC сложнее, поскольку он зависит от взаимодействия всех узлов.

    3.2.3 Сравнение

    Были обсуждены пять подходов. Эти подходы решают проблему неспособности TCP управлять трафиком в зависимости от состояния сети, что является одной из основных причин ухудшения производительности в многозвенных беспроводных сетях.Для решения этой проблемы представлены два доступных метода. Первый — позволить TCP оценить состояние сети без нарушения многоуровневого принципа. В частности, TCP должен выполнять некоторые статистические операции для оценки состояния и соответствующей реакции, такие как TCP-Vegas [33] и TCP-Westwood [34]. Другой способ — получить обратную связь о статусе сети через межуровневую информацию. Таким образом TCP может считывать эту информацию и настраиваться. Подходы, в которых используется этот метод: TCP-LC [35], управление скоростью передачи на основе эффективности канала [36] и TCPCC [37].Эти подходы, использующие явную обратную связь из сетей, обеспечивают значительное улучшение производительности TCP. Однако, если рассматривать концепцию протоколов и приложений изолированно, TCP-Westwood кажется предпочтительным выбором. Это связано с тем, что TCP-Westwood использует идею оценки пропускной способности и может эффективно уменьшить влияние потерь, не вызванных перегрузкой. Таблица 2 иллюстрирует сводку основных характеристик обсуждаемых усовершенствований TCP.

    Таблица 2 Сравнение основных характеристик различных улучшений TCP

    3.3 Уменьшение накладных расходов трафика ACK

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

    В устаревшем протоколе TCP после успешного приема каждого пакета данных, переданного от отправителя к получателю, будет сгенерирован ответ ACK от получателя к отправителю (рисунок 4a). Если пакет данных не был подтвержден в течение некоторого времени, он считается потерянным и повторно передается отправителем. Фактически, ACK считаются управляющим трафиком, используемым TCP для обеспечения надежного восстановления данных.Однако небольшие TCP ACK потребляют беспроводных ресурсов столько же, сколько длинные пакеты данных TCP. Более того, взаимные помехи и коллизии между данными и пакетами ACK, которые вызваны совместным использованием одного и того же маршрута, увеличиваются с увеличением количества сгенерированных ACK [39]. Следовательно, желательно уменьшить количество управляющего трафика (ACK), чтобы сделать ресурсы доступными для фактических пакетов данных и уменьшить помехи и конфликты между данными и пакетами ACK. Это достигается за счет объединения нескольких ACK в один ACK, что возможно благодаря опции кумулятивного ACK, используемой в TCP.

    Рисунок 4

    (a) Стандартный TCP, (b) стандартный TCP с опцией отложенного ACK и (c) TCP с задержкой более двух ACK .

    Первая оптимизация такого рода была введена через стандартный TCP с опцией отложенного ACK в (RFC 1122 [14], RFC 2581 [40]). При использовании стандартной опции ACK с задержкой TCP может генерировать один ACK после получения двух упорядоченных пакетов данных (рисунок 4b). В ходе обширного моделирования [41, 42] сообщалось, что варианты TCP, такие как Reno, New Reno, SACK и Vegas, работают лучше за счет использования отложенных ACK в случае пропускной способности, полосы пропускания и энергопотребления.Однако в сетях 802.11 проблема интерференции между ACK и пакетами данных может все еще сохраняться, и преимущества стандартного TCP с отложенным ACK могут быть дополнительно улучшены. (Рисунок 4c) показывает случай задержки ACK для более чем двух пакетов. Фактически, уменьшение количества ACK может улучшить производительность TCP, однако большие совокупные ACK вызовут потерю пакетов из-за тайм-аута повторной передачи на стороне отправителя TCP. Для решения этой проблемы было предложено множество улучшений и оптимизаций для уменьшения накладных расходов на трафик, вызванных генерацией большего количества ACK, чем необходимо.

    3.3.1 Подходы на уровне TCP
    ACK с динамической задержкой (TCP-DDA)

    TCP-DDA [39] — это простая модификация приемника, представленная Альтманом и Хименесом. В рамках этого подхода авторы исследовали влияние создания отложенных ACK для более чем двух полученных пакетов на производительность TCP в многосетевых беспроводных сетях. Они предложили схему ограниченного динамического отложенного ACK, в которой получатель начинает задерживать один ACK (отправляя один ACK для двух в порядке получения пакетов) и продолжает увеличиваться до четырех в зависимости от порядкового номера подтвержденного пакета.Например, когда задержанный ACK установлен на четыре, получатель может отправить один ACK для пакета ( Pi ), подразумевая, что пакеты ( Pi-1 ), ( Pi-2 ) и ( Pi-3 ) также были успешно получены, без отправки отдельных ACK для каждого. Получатель продолжает задерживать четыре ACK, за исключением того, что при запуске сеанса он снова уменьшает задержанное ACK до одного.

    Хотя опция отложенного ACK снижает частоту выборок RTT, измеряемых отправителем TCP, это уменьшение обратной связи оказывает значительное влияние на истечение срока RTO.В результате TCP может повторно передать все пакеты, задержанные их ACK, даже если пакеты получены. Следовательно, TCP должен точно выбрать оптимальное значение окна задержки ACK. Хотя TCP-DDA показал хорошую производительность в статических одноранговых сетях по сравнению со стандартным TCP, он может оказаться неэффективным в сценариях с высоким трафиком и значительной потерей пакетов. Более того, TCP-DDA был получен только для одного потока в статических сетях, множественные потоки и мобильность являются хорошими проблемами для дальнейшего улучшения.

    Динамический адаптивный ACK (TCP-DAA)

    TCP-DAA [41] — это модификация отправителя / получателя, представленная Оливейрой и Брауном. В TCP-DAA получатель уменьшает количество ACK, используя кумулятивное свойство TCP. TCP-DAA диктует изменения как отправителю, так и получателю. В этом подходе приемник может объединить до четырех пакетов ACK, когда беспроводной канал находится в хорошем состоянии, и меньше для каналов с потерями. Ограничение в четыре пакета накладывается пределом окна перегрузки отправителя, который также фиксируется на уровне четырех пакетов.Авторы сообщают, что нижний предел cwnd отправителя подходит для минимизации коллизий и более чем достаточен для сценариев, имеющих до 10 переходов. Задержка ответов ACK выполняется динамически на основе события потери пакета. Когда нет потери пакетов, TCP-DAA задерживает ACK до тех пор, пока не получит больше пакетов данных, до четырех, но сокращает это число до двух в случае доставки пакетов вне очереди. Эти концепции приводят к тому, что этот подход превосходит обычный TCP, когда канал может обеспечить более высокую пропускную способность.

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

    Отложенное совокупное подтверждение (TCP-DCA)

    TCP-DCA — это схема на основе приемника TCP, представленная Ченом и др. [43]. В этой схеме авторы показывают, что TCP не всегда увеличивает пропускную способность, задерживая неограниченное количество ACK. Кроме того, на приемнике существует оптимальный размер окна задержки, обеспечивающий наилучшую пропускную способность TCP. В TCP-DCA длина пути является важным фактором, который следует учитывать при выборе подходящих размеров окна задержки.Поэтому TCP-DCA выбрал другой размер окна задержки для адаптации генерации TCP ACK в зависимости от количества переходов. Когда количество переходов между отправителем и получателем меньше или равно трем, окно задержки устанавливается равным размеру cwnd . Для длины пути от четырех до девяти переходов окно задержки устанавливается на фиксированное значение с пятью пакетами. В случае длинных путей, более десяти переходов, получатель установит окно задержки на три пакета. TCP-DCA показал хорошую производительность в многозвенных беспроводных сетях.В заключение, задерживая ACK для большого количества пакетов данных, большое окно задержки всегда полезно в связи с короткими путями, но может быть неуместным для сетей с длинными путями. Чем длиннее сквозной путь, тем дольше отправитель TCP обнаруживает потерянные пакеты, вызванные задержкой большего количества ACK. Кроме того, при прохождении более длинного пути пакет с большей вероятностью будет испытывать помехи.

    TCP-DCA — это сквозная семантическая схема TCP, которая показывает хорошую производительность в статических, мобильных и гибридных одноранговых сетях.TCP-DCA был предложен для уменьшения количества ACK адаптивно в зависимости от длины пути. Однако знание количества переходов между отправителем и получателем не является свойством TCP и может потребовать взаимодействия с нижележащими уровнями. Более того, оценить количество переходов по TCP непросто, особенно в мобильных сетях, где длина пути изменяется динамически. Кроме того, TCP-DCA использует большое окно фиксированной задержки на протяжении всей передачи между отправителем и получателем, и это может повлиять на производительность каналов с высокой частотой битовых ошибок.

    TCP с адаптивным окном задержки (TCP-ADW)

    TCP-ADW — это модификация TCP на основе приемника, представленная Аль-Джубари и Османом [44]. Авторы показывают, что использование фиксированного окна задержки недопустимо в этой изменяющейся среде, и оптимальный размер окна задержки на приемнике, который обеспечивает лучшую пропускную способность TCP, может быть достигнут динамически. TCP-ADW динамически регулирует окно задержки на основе нескольких условий, таких как скорость передачи, фаза медленного старта, длина пути и событие потери пакета.Чтобы соответствующим образом уменьшить количество пакетов ACK, TCP-ADW создает ACK, достигая оптимального окна динамической задержки. Таким образом, приемник сможет адаптироваться к различным значениям задержек, налагаемых условиями беспроводного канала. Кроме того, он задерживает ровно столько, чтобы избежать тайм-аута передачи у отправителя. В этом подходе, если таймер повторной передачи отправителя не истечет, получатель всегда увеличивает окно задержки на основе увеличения скорости передачи, за исключением запуска сеанса.Во время запуска приемник устанавливает окно задержки равным единице и увеличивает его в зависимости от скорости передачи. Когда происходит потеря пакета, приемник уменьшает свое окно задержки до определенного значения в зависимости от количества скачков (длины пути). В случае короткого пути приемник уменьшает окно задержки вдвое. Однако для длинного пути приемник уменьшит окно задержки до двух. Это связано с тем, что отправителю TCP потребуется много времени, чтобы обнаружить потерянные пакеты, полученные из-за задержки большего количества ACK. Неупорядоченные пакеты немедленно заставляют генерацию ACK своевременно информировать отправителя о потере / восстановлении пакета, как это введено в рекомендации RFC 2581 [40].Приемник использует фиксированный интервал 200 мс для тайм-аута.

    TCP-ADW — это сквозное решение TCP, которое демонстрирует значительную производительность по сравнению с TCP-DCA и многое другое по сравнению с обычным TCP в статических одноранговых сетях. Однако требуется оценка TCP-ADW в мобильных одноранговых сетях и изучение его производительности в каналах с высоким BER.

    3.3.2 Межуровневые подходы
    Мониторинг отложенного подтверждения (TCP-MDA)

    MDA — это межуровневая модификация, представленная Armaghani et al.[45]. TCP-MDA предложил стратегию динамического взаимодействия между уровнями TCP и MAC, которая уменьшает количество ACK за счет мониторинга состояния канала. Чтобы правильно установить количество задержанных ACK в TCP, TCP-MDA использует механизм для сбора вероятности коллизии на пути от отправителя к получателю на уровне MAC. Основываясь на оцененной вероятности коллизии, TCP подстраивается под состояние канала, задерживая меньше ACK в условиях высокого трафика и больше ACK в условиях низкого трафика. Если канал находится в хорошем состоянии, когда оценочная вероятность столкновения меньше заранее определенного порога, приемник TCP может объединить до четырех ACK.Однако, когда наблюдается высокая коллизия на уровне MAC, получатель TCP генерирует больше ACK, чтобы избежать ненужной повторной передачи, вызванной тайм-аутом на стороне отправителя. Ограничение в четыре ACK устанавливается отправителем cwnd , которое определяется как максимальное количество пакетов данных, которое отправитель TCP может ввести в сеть в любое время, не дожидаясь ACK от получателя. Этот нижний предел в четыре пакета для cwnd подходит для минимизации конфликта каналов в сценариях ближнего действия [46].

    Результаты моделирования показывают улучшение пропускной способности по сравнению с TCP-DAA и многое другое по сравнению с обычным TCP в различных сценариях. TCP-MDA показывает, что оптимальное количество отложенных ACK основано на длине пути TCP-соединения, и большое окно задержки может только улучшить TCP. Кроме того, результаты показывают, что существует оптимальное количество отложенных ACK, обеспечивающее наилучшую пропускную способность в различных диапазонах. Таким образом, TCP-MDA показывает, что большое оптимальное число может улучшить пропускную способность TCP только в коротких сценариях с менее чем пятью переходами.Однако ограничение окна перегрузки более длинного пути обеспечивает больший выигрыш в пропускной способности. Однако, поскольку TCP-MDA был разработан для хорошей работы в статических сетях, требуется оценка TCP-MDA в мобильных сетях. Кроме того, TCP-MDA требует, чтобы промежуточные узлы уведомляли TCP о состоянии канала, что усложняет его развертывание и реализацию. Более того, ограничение cwnd до четырех может повлиять на производительность TCP в случае высокой скорости трансмутации и низкого BER.

    3.3.3 Сравнение

    Было представлено пять подходов. Эти подходы решают проблему уменьшения накладных расходов, вызванных трафиком ACK в беспроводном канале, что является одной из ключевых проблем снижения производительности TCP в беспроводных сетях с множеством переходов. Некоторые подходы основаны на модификации сквозного уровня TCP, например DDA, DAA, DCA, ADW и другие, основанные на кросс-уровнях, например MDA. DDA и DAA динамически сокращают количество ACK, но ограничиваются четырьмя пакетами. DDA увеличивает окно задержки на основе увеличения порядкового номера пакетов.Однако DAA увеличивает окно задержки на основе доставки пакетов в порядке и уменьшает окно задержки на основе событий потери (доставка пакетов вне очереди). Для подхода DCA окно задержки настраивается адаптивно в зависимости от количества скачков. DCA показывает хорошую производительность по сравнению с DAA, который, в свою очередь, превосходит DDA. В ADW окно задержки не ограничено и устанавливается адаптивно и динамически на основе трех бессильных факторов, количества скачков, скорости передачи и события потери. Результаты ADW показывают, что ADW имеет значительную производительность по сравнению с DCA и намного больше по сравнению со стандартным TCP в статических одноранговых сетях.При межуровневом подходе используйте обратную связь от уровня MAC для установки окна задержки. MDA использует ограниченное окно задержки до четырех пакетов для генерации ACK. Результаты моделирования MDA показывают, что MDA также превосходит DAA и обычный TCP. Таблица 3 иллюстрирует сводку основных характеристик обсуждаемых усовершенствований TCP.

    Таблица 3 Сравнение основных характеристик различных расширений TCP

    3.4 Ограничение агрессивности TCP

    Хорошо известно, что одной из основных функций TCP является механизм окна TCP, который контролирует объем трафика, отправляемого в сеть.Однако одна из важнейших причин низкой производительности TCP в многозвенных беспроводных сетях заключается в агрессивной политике увеличения окна самого TCP. Таким образом, недавно было предложено несколько усовершенствований TCP для решения проблемы агрессивности TCP. В разделе 2.4 мы обсудили неблагоприятное влияние проблем конкуренции между потоками и внутри потоков на производительность TCP. Причина этого утверждения заключается в том, что обычный TCP не управляет своим окном перегрузки на соответствующем уровне.Типичные схемы, которые уменьшают конкуренцию за счет ограничения агрессивности TCP, включают «TCP-Vegas-W» [47], «Ограничение окна перегрузки» [24], «Частичное увеличение окна (FeW)» [48], «Адаптивный размер пакета поверх FeW (APS-FeW) [49] и «Link RED and Adaptive Pacing» [46].

    3.4.1 Подходы на уровне TCP
    Частичное приращение окна (FeW)

    FeW — это межуровневый подход, предложенный Nahm et al. [48] ​​В этом исследовании авторы исследуют влияние перегрузки и конфликтов MAC-адресов на взаимодействие между TCP и протоколами специальной маршрутизации по запросу в 802.11 специальных сетей. Они заметили, что TCP обычно работает с высокой скоростью и вызывает чрезмерную реакцию протокола маршрутизации. Следовательно, ограничение этой агрессивности окна перегрузки TCP может значительно улучшить качество сквозного соединения. С этой целью авторы предлагают схему дробного приращения окна (FeW), в которой TCP использует дробное обновление окна вместо использования экспоненциального обновления окна, связанного с обычным TCP. При каждом приеме ACK отправитель TCP обновляет cwnd по уравнению 1.Таким образом, FeW заставит TCP работать с очень маленькой дробной скоростью (0 ≤ 1) при каждом RTT:

    cwndnew = cwndcurrent + αcwndcurrent

    (1)

    Результаты моделирования в [48] демонстрируют, что FeW значительно улучшает производительность TCP, что подтверждает предположение FeW о том, что его механизм прогнозирования окна остается таким же точным, как и в устаревшем TCP. Беспроводное соединение может выиграть как от быстрой реакции устаревшего TCP, так и от снижения нагрузки FeW.Однако еще не ясно, в какой степени короткие соединения с относительно небольшими объемами данных могут пострадать от более медленного роста окна перегрузки и, как следствие, более медленной сходимости. Более того, механизм обновления окна FeW не может в полной мере использовать его точное прогнозируемое окно для передачи, потому что на практике это приводит к схеме с нецелым приращением размера окна на RTT. Хотя FeW настраивает свое окно перегрузки по той же схеме, что и унаследованный TCP, дробная часть его окна не влияет на передачу, и определенная часть прогнозируемой пропускной способности сети тратится впустую.Решение этой проблемы дано в [49].

    APS-FeW

    Wang et al. предложили новый адаптивный размер пакета (APS) [49], усовершенствованный для FeW [48]. И FeW, и APS-FeWare основаны на наблюдении, что TCP вызывает чрезмерное действие протокола маршрутизации и снижает производительность соединения. Как показано в [48], схема FeW улучшает производительность соединения, ограничивая агрессивность TCP. Авторы в [49] показывают, что в некоторой степени FeW слишком строг в том, что он исключает возможность доставки большего количества байтов в том же окне перегрузки.Основываясь на своем исследовании механизма обновления окна FeW, они обнаружили, что FeW не может в полной мере использовать свое точно предсказанное окно для передачи. Хотя FeW настраивает свое окно перегрузки по той же схеме, что и унаследованный TCP, дробная часть его окна может тратить впустую пропускную способность сети. Чтобы решить эту проблему, [49] предлагает схему адаптивного размера пакета (APS) для работы поверх FeW для TCP. Поскольку размер пакета на начальном этапе является целым числом, APS работает точно так же, как TCP.Когда окно перегрузки превышает пороговое значение, cwnd становится дробным числом. В отличие от FeW, который имеет фиксированный размер пакета, APS поверх FeW (APS-FeW) может адаптировать размер пакета к текущему прогнозируемому окну и полностью использовать окно для передачи. Он определяет начальный размер пакета ( initPacketsize ) как фиксированный размер пакета при сбросе TCP и использует ( cwnd ) для вычисления текущего размера пакета, как в следующем уравнении 2:

    Packetsize = cwnd × initPacketsizecwnd

    (2)

    Процедура APS-FeW следующая.(1) Когда источник TCP получает ACK, он обновляет свое окно перегрузки и текущий размер пакета, как показано в уравнении 2. Затем он продолжает использовать этот размер пакета для передачи следующих пакетов до тех пор, пока не придет следующий ACK. (2) Когда таймер повторной передачи истек, TCP переходит в режим медленного запуска, окно перегрузки сбрасывается до 1. Источнику TCP необходимо повторно упаковать данные в своем буфере с исходным размером пакета и повторно передать их. (3) Когда TCP входит в режим быстрого запуска из-за трех дублированных ACK, источнику TCP не нужно перепаковывать потерянный пакет, он просто повторно передает пакет в своем буфере.

    Предлагаемая схема использует преимущества как устаревшего TCP, так и FeW для повышения производительности TCP по сравнению с многоинтервальными сетями 802.11. Благодаря обширным результатам моделирования, представленным в [49], этот подход показывает, что APS по сравнению с FeW превосходит FeW. С APS-FeW беспроводное соединение может выиграть как от быстрой реакции устаревшего TCP, так и от снижения нагрузки FeW.

    TCP-Vegas-W

    В [47], Ding et al. предложил Vegas-W, который представляет собой модифицированный протокол TCP на основе TCP-Vegas [33] для многоузловых одноранговых сетей.Этот подход основан на наблюдении, что TCP Vegas не может поддерживать оптимальное окно с максимальной средней пропускной способностью, когда емкость сети меньше, чем сбросить порог медленного запуска Vegas. Согласно исследованию авторов, эта проблема возникает из-за большого минимального окна перегрузки в Вегасе, большого сброса порога медленного запуска и политики агрессивного увеличения окна. Все они вызывают перегрузку сети, что приводит к потерям пакетов на уровне MAC, чрезмерной реакции на уровне маршрутизации и, как следствие, снижается совокупная пропускная способность всего трафика.Чтобы решить эту проблему, авторы предлагают Vegas-W, в котором окно перегрузки расширено на долю таймера управления скоростью в процессе отправки TCP. В TCP-Vegas-W механизмы зондирования устаревшего TCP-Vegas на фазах медленного запуска и предотвращения перегрузки были изменены, чтобы увеличить окно перегрузки после получения более одного ACK. Кроме того, порог медленного старта модифицируется для обновления путем отслеживания стабильного окна.

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

    3.4.2 Подходы канального уровня
    Link RED и адаптивная стимуляция

    LINK RED и AP [46] — это методы, предложенные Fu et al.которые позволяют TCP упреждающе реагировать на перегрузку канала, адаптивно задерживая передачу определенных пакетов, чтобы уменьшить конкуренцию. Авторы в этой статье показывают, что небольшое окно перегрузки TCP может иметь положительное влияние на производительность TCP в мобильной сети ad hoc. Этот подход показал, что максимум 1/4 пространственного повторного использования улучшает производительность TCP для одностороннего потока в определенных сценариях. Это исследование подразумевает, что ограничение максимальной скорости отправки источника TCP может облегчить проблему перерегулирования окна перегрузки, что, в свою очередь, может уменьшить конкуренцию на уровне MAC.В следующем разделе мы кратко объясним два предложенных метода, используемых в этом подходе. случайное раннее обнаружение канала (Link RED) [46] — это алгоритм управления активной очередью канального уровня, который использует метку явного уведомления о перегрузке (ECN) для стабилизации окна TCP. Link RED призван уменьшить конкуренцию на беспроводном канале. Это достигается за счет поддержания среднего числа повторных попыток для недавних передач пакетов. Если среднее значение попытки повтора превышает заданное пороговое значение, Link RED будет отмечать исходящие пакеты с вероятностью, зависящей от значения, вычисленного в соответствии с алгоритмом RED [50].Авторы предложили увеличить время отката на уровне MAC, тогда TCP снизит скорость отправки и тем самым в некоторой степени предотвратит потерю пакетов.

    Adaptive Pacing (AP)

    [46] направлен на улучшение повторного использования пространственного канала, и это достигается за счет более сбалансированного распределения трафика между промежуточными узлами. В текущем протоколе IEEE 802.11 узел ограничен от конкуренции за канал случайным периодом отсрочки передачи плюс время передачи одного пакета, которое объявляется кадром RTS или CTS.Однако связанные с конкуренцией отбрасывания, вызванные проблемой открытых приемников, сохраняются из-за отсутствия координации между узлами, которые находятся на расстоянии двух переходов друг от друга. Чтобы решить эту проблему, AP позволяет некоторым узлам ждать, в дополнение к обычному периоду задержки, в течение дополнительного времени, равного времени передачи пакета, когда это необходимо. AP используется совместно с Link RED следующим образом. Когда узел обнаруживает, что его среднее количество повторных попыток передачи меньше порогового значения, он вычисляет время задержки, как обычно.Когда среднее количество повторных попыток превысит этот порог, Link RED начнет маркировать пакеты, а AP затем увеличит время задержки ожидающей передачи на интервал, равный времени передачи предыдущего пакета. Link RED обеспечивает ранний признак перегрузки сети, что помогает TCP улучшить справедливость взаимодействия между несколькими сеансами TCP. Когда Link RED используется вместе с AP, они улучшают пространственное повторное использование за счет уменьшения конкуренции и, таким образом, улучшают производительность TCP.Однако в этом подходе дополнительное время отката зависит от размера пакета, поэтому необходимо проверить наличие пакетов данных другого размера в сети. Более того, Link RED требует, чтобы уровень MAC поддерживал среднее значение попытки повторной передачи. Это также требует, чтобы алгоритм, подобный RED, был реализован на уровне MAC, и это усложняет реализацию и развертывание схемы.

    3.4.3 Межуровневые подходы
    Предел окна перегрузки (CWL)

    Chen et al.разработан CWL [24], чтобы уменьшить конкуренцию на уровне MAC, чтобы улучшить производительность TCP. Основная цель этого подхода — динамически регулировать максимальный размер окна перегрузки в зависимости от текущей длины пути. Следовательно, скорость отправки не будет превышать максимальное пространственное повторное использование канала. Благодаря этому уменьшаются проблемы конкуренции как внутри потока, так и между потоками. Авторы в [24] обращают проблему настройки правильного CWL в определение произведения полосы пропускания-задержки (BDP) пути.Основываясь на этой методологии, они сначала показывают и доказывают, что, независимо от какого-либо конкретного протокола уровня MAC, верхняя граница BDP тракта не может превышать его счетчик переходов туда и обратно (RTHC). Следовательно, CWL должен использоваться с протоколами маршрутизации, которые знают длину пути. Принимая во внимание помехи при передаче протокола уровня MAC IEEE 802.11, этот подход позволяет получить более жесткую верхнюю границу BDP, которая составляет примерно 1/5 от RTHC в определенной топологии. На основе этой более жесткой границы показано, что пропускную способность TCP можно улучшить, задав его CWL динамически в соответствии с текущим RTHC пути.Это приближение 1/5 может быть легко объяснено также с учетом увеличения конкуренции (и, таким образом, уменьшения пространственного повторного использования), вносимого обратными пакетами ACK на том же пути. Для MAC IEEE 802.11 этот подход дает еще более жесткую границу RTHC 5. Протокол маршрутизации DSR используется как протокол маршрутизации с учетом пути для получения информации о длине пути в исходном узле. Это позволяет динамически настраивать CWL в зависимости от длины пути соединения. CWL — это ограничение окна динамической перегрузки, основанное на характеристиках широковещательной передачи беспроводной среды.В этом подходе, основанном на приближении более жестких границ, 1/5 от RTHC, предел окна устанавливается только для одного потока. Однако для нескольких конкурирующих потоков неясно, будет ли это всегда. Фактор может зависеть от плотности и количества конкурирующих соединений. Кроме того, не проводилось всестороннего исследования использования мобильной сети, в которой длина пути динамически изменяется. Более того, в беспроводной многозвенной связи конкуренция за полосу пропускания между сегментами DATA и ACK еще более выражена из-за широковещательной природы совместно используемой беспроводной среды и ограниченной доступной полосы пропускания, однако никаких всесторонних исследований не проводилось.Чтобы продемонстрировать прирост производительности их схемы, были проведены различные симуляции для сравнения ее с TCP Reno с неограниченным окном перегрузки. Тем не менее, следует отметить, что они также изменили максимальный тайм-аут повторной передачи TCP в своих симуляциях, чтобы позволить TCP зондировать маршрут быстро, установив его на 2 секунды в отличие от 240 секунд, указанных в RFC 1122 [14]. Это может повлиять на результаты моделирования.

    3.4.4 Сравнение

    Было представлено пять подходов.Эти подходы решают проблему перегрузки TCP, которая является одним из ключевых факторов проблемы конкуренции в многозвенных беспроводных сетях. Эти подходы подразделяются на три набора на основе уровня модификации: подходы уровня TCP, подходы сетевого уровня и межуровневые подходы. Недавние исследования утверждают, что перегрузка сети является основным фактором, способствующим конфликтам и потерям пакетов в многозвенных беспроводных сетях [48, 49]. Благодаря точно настроенному оконному механизму TCP, сетевая нагрузка может поддерживаться на разумном уровне, и, следовательно, производительность TCP повышается.Однако в других исследованиях предлагалось решить эту проблему с самого начала на канальном уровне [46]. В то время как другие связывают эту проблему с отсутствием координации между TCP и другими уровнями и предполагают, что межуровневое распределение является лучшим решением. В FeW [48] средняя цель — заставить TCP работать с очень малой дробной скоростью. Оценка схемы FeW показывает, что FeW превосходит Link RED [46]. Однако дробная часть его окна может тратить впустую емкость сети. ASP-FEW [49] предложил решить эту проблему, динамически изменяя размер пакета в зависимости от размера окна перегрузки.APS-FeW показывает хорошую производительность по сравнению с FeW с точки зрения пропускной способности. Vegas-W [47] также показывает улучшенную производительность TCP по сравнению с FeW. Этот подход был предложен для преодоления проблем большого минимального окна перегрузки, большого сброса порога медленного старта и агрессивной политики увеличения окна TCP-Vegas в многозвенных беспроводных сетях. В предложениях канального уровня Link RED и Adaptive Pacing предлагали уменьшить проблему конкуренции от ее источника на канальном уровне. Основная идея, лежащая в основе этого подхода, состоит в том, чтобы управлять размером окна TCP путем настройки вероятности отбрасывания канального уровня в соответствии с предполагаемым конфликтом каналов.CWL [24] — это простой межуровневый подход, который направлен на уменьшение конкуренции на беспроводном канале путем ограничения окна перегрузки TCP на основе определения количества переходов пути туда и обратно.

    alexxlab / 20.01.1975 / Разное

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

    Почта не будет опубликована / Обязательны для заполнения *