Госпошлина за дубликат птс: Размер госпошлины за регистрацию транспортных средств

Размер госпошлины за регистрацию транспортных средств

№	Объекты взимания сборов		Госпошлина
1	За регистрацию автотранспорта
	выдача гос. регистрационных знаков	2000	2850
	Выдача свидетельства о регистрации ТС	500
	Внесение изменений в ПТС	350
	За регистрацию автотранспортных средств с выдачей ПТС
	выдача гос. регистрационных знаков	2000	3300
	Выдача свидетельства о регистрации ТС	500
	Выдача ПТС	800
2	За регистрацию мототранспортных средств и прицепов
	выдача гос. регистрационных знаков	1500	2350
	Выдача свидетельства о регистрации ТС	500
	Внесение изменений в ПТС	350
	За регистрацию мототранспортных средств и прицепов, с выдачей ПТС
	выдача гос. регистрационных знаков	1500	2800
	Выдача свидетельства о регистрации ТС	500
	Выдача ПТС	800
3	Выдача документов взамен утраченных или пришедших в негодность
	Паспорт транспортного средства		1300
	Выдача свидетельства о регистрации ТС	500
	Выдача ПТС	800
	Свидетельство о регистрации ТС		850
	Внесение изменений в ПТС	350
	Выдача свидетельства о регистрации ТС	500
4	Выдача государственных регистрационных знаков взамен утраченных или пришедших в негодность
	Государственные регистрационные знаки на автомобиль		2850
	Выдача гос.рег.знаков	2000
	Выдача свидетельства о регистрации ТС	500
	Внесение изменений в ПТС	350
	Государственные регистрационные знаки на мотоцикл или прицеп		2350
	Выдача гос.рег.знака	1500
	Выдача свидетельства о регистрации ТС	500
	Внесение изменений в ПТС	350
5	За перерегистрацию в связи с изменением регистрационных данных
	Внесение изменений в ПТС	350	850
	Выдача свидетельства о регистрации ТС	500
	За перерегистрацию в связи с изменение регистрационных данных с выдачей ПТС
	Выдача свидетельства о регистрации ТС	500	1300
	выдача ПТС	800
	за перерегистрацию в связи с изменением регистрационных данных с выдачей регистрационных знаков и ПТС на автомобиль
	Выдача свидетельства о регистрации ТС	500	3300
	Выдача ПТС	800
	Выдача гос.рег. знаков	2000
	За перерегистрацию в связи с изменением регистрационных знаков на автомобиль
	Выдача свидетельства о регистрации ТС	500	2850
	Внесение изменений в ПТС	350
	Выдача гос.рег. знака	2000
	За перерегистрацию в связи с изменением регистрационных данных с выдачей регистрационных знаков и ПТС на мототранспортные средства и прицепы
	Выдача свидетельства о регистрации ТС	500	2800
	Выдача ПТС	800
	Выдача гос.рег. знака	1500
	За перерегистрацию в связи с изменением регистрационных данных с выдачей регистрационных знаков на мототранспортные средства и прицепы
	Выдача свидетельства о регистрации ТС	500	2350
	Внесение изменений в ПТС	350
	Выдача гос.рег. знака	1500
6	За временную регистрацию по месту пребывания
	Выдача свидетельства о регистрации ТС	500	850
	Временная регистрация	350
	Временная регистрация автомобиля с выдачей свидетельства о регистрации и  гос.рег.знаков		2850
	Выдача свидетельства о регистрации ТС	500
	Временная регистрация	350
	Выдача гос.рег. знаков	2000
	Временная регистрациямототранспортного средства и прицепа		2350
	Выдача свидетельства о регистрации ТС	500
	Временная регистрация	350
	Выдача гос.рег. знака	1500
7	Снятие с учета с выдачей знаков «Транзит» и ПТС на автомобили,мототранспортные средства и прицепы (в связи с убытием за пределы Российской Федерации):
	На металлической основе для автомобилей		2100
	Знаки «Транзит»	1600
	Выдача св-ва о регистрации ТС	500
	На металлической основе для мототранспортных средств и прицепов		1300
	Знаки «Транзит»	800
	Выдача  св-ва о регистрации ТС	500
8	Выдача свидетельства о соответствии конструкции ТС		800

Управление Государственной инспекции безопасности дорожного движения Главного управления Министерства внутренних дел России по Иркутской области

Регистрация транспортных средств

Напоминаем, что с 1 января 2017 года выпуск в обращение (выдача паспорта транспортного средства) ввозимых транспортных средств осуществляется таможенными органами только после оснащения транспортных средств устройствами вызова экстренных оперативных служб (далее — УВЭОС).

При необходимости минимизации временных затрат приобрести УВЭОС можно через официальный сайт АО «ГЛОНАСС». Для этого необходимо зарегистрироваться на сайте и внести предварительную оплату, после чего произойдет автоматическое попадание в электронную очередь заявителей, ожидающих получения устройств.

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

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

• Регистрация транспортных средств, не состоящих на регистрационном учете

  • Заявление установленного образца о регистрации автомототранспортного средства или прицепа  
  • Документ, удостоверяющий личность
  • Документ, удостоверяющий полномочия заявителя на предоставление интересов собственника транспортного средства (при наличии)
  • Для юридических лиц — выписка из Единого государственного реестра юридических лиц (предоставляется заявителем по собственной инициативе)
  • Паспорт транспортного средства
  • Документы, удостоверяющие право собственности на транспортное средство
  • Документ об оплате государственной пошлины за регистрационные действия, связанные с выдачей регистрационных знаков, свидетельства о регистрации транспортного средства, за внесение изменений в выданный ранее паспорт транспортного средства (предоставляется заявителем по собственной инициативе)
  • Государственные регистрационные знаки «Транзит» (если они выдавались)
  • Транспортное средство

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

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

• Регистрация автомототранспортных средств или прицепов к ним, на ограниченный срок

  • Заявление установленного образца о регистрации на ограниченный срок автомототранспортного средства или прицепа  
  • Документ, удостоверяющий личность
  • Документ, удостоверяющий полномочия заявителя на предоставление интересов собственника транспортного средства
  • Выписка из Единого государственного реестра юридических лиц – для юридических лиц (предоставляется заявителем по собственной инициативе)
  • Паспорт транспортного средства
  • Договор лизинга (сублизинга) и акт приема-передачи предмета лизинга
  • Документы, удостоверяющие право собственности лизингодателя на транспортное средство
  • Документы с отметками таможенных органов о выпуске временно ввезенных транспортных средств и регистрационные знаки, выданные на зарегистрированные в других государствах транспортные средства (при наличии)
  • Документ об оплате государственной пошлины за регистрационные действия, связанные с выдачей регистрационных знаков, свидетельства о регистрации транспортного средства, за внесение изменений в выданный ранее паспорт транспортного средства (предоставляется заявителем по собственной инициативе)
  • Государственные регистрационные знаки «Транзит» (если они выдавались)
  • Транспортное средство

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

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

• Изменение регистрационных данных транспортных средств в связи со сменой собственника, сведений о собственнике или транспортном средстве

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

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

  • Заявление установленного образца, о выдаче дубликатов регистрационных знаков автомототранспортных средств и (или) свидетельства о регистрации ТС и (или) паспорта транспортного средства  
  • Документ, удостоверяющий личность
  • Документ, удостоверяющий полномочия заявителя на предоставление интересов собственника транспортного средства (при наличии)
  • Свидетельство о регистрации транспортного средства (при наличии)
  • Паспорт транспортного средства (при наличии)
  • Документ об оплате государственной пошлины за регистрационные действия, связанные с выдачей свидетельства о регистрации транспортного средства, за внесение изменений в выданный ранее паспорт транспортного средства; при получении дубликатов регистрационных знаков — за выдачу государственных регистрационных знаков; в случае получения дубликата паспорта транспортного средства — за выдачу паспорта транспортного средства (предоставляется заявителем по собственной инициативе)
  • Транспортное средство для осмотра не предоставляется

• Изменение регистрационных данных транспортного средства связанное с внесением изменений в конструкцию транспортного средства

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

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

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

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

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

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

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

  • Заявление установленного образца, об изменении учетных данных  
  • Документ, удостоверяющий личность
  • Документ, удостоверяющий полномочия заявителя на предоставление интересов собственника транспортного средства (при наличии)
  • Для физических лиц – свидетельство о заключении (расторжении) брака, изменении фамилии, и (или) имени, и (или) отчества
  • Для юридических лиц — выписка из ЕГРЮЛ (предоставляется заявителем по собственной инициативе)
  • Свидетельство о регистрации транспортного средства
  • Паспорт транспортного средства
  • Документ об оплате государственной пошлины за регистрационные действия, связанные с выдачей свидетельства о регистрации транспортного средства, государственной пошлины за внесение изменений в выданный ранее паспорт транспортного средства (предоставляется заявителем по собственной инициативе)
  • Транспортное средство для осмотра не предоставляется

• Прекращение регистрации в связи с утратой транспортного средства

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

• Прекращение регистрации в связи с хищением транспортного средства

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

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

  • Заявление установленного образца, о причине прекращения регистрации транспортного средства  
  • Документ, удостоверяющий личность
  • Документ, удостоверяющий полномочия заявителя на предоставление интересов собственника транспортного средства (при наличии)
  • Копия документа подтверждающего факт перехода права собственности (купля-продажа и т.д.)

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

  • Заявление установленного образца, о причине прекращения регистрации транспортного средства  
  • Документ, удостоверяющий личность
  • Документ, удостоверяющий полномочия заявителя на предоставление интересов собственника транспортного средства (при наличии)
  • Транспортное средство для осмотра не предоставляется

• Прекращение регистрации транспортного средства в связи с утилизацией

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

• Прекращение регистрации транспортного средства в связи с вывозом за пределы Российской Федерации

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

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

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

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

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

Бланки заявлений

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

Часто задаваемые вопросы по теме

Раздел не найден.

Информация о реквизитах и размерах госпошлин

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

Адреса осуществления государственной функции:

В списке отображается информация только

Выбрать другой регион: 01. Республика Адыгея02. Республика Башкортостан03. Республика Бурятия04. Республика Алтай05. Республика Дагестан06. Республика Ингушетия07. Кабардино-Балкарская Республика08. Республика Калмыкия09. Карачаево-Черкесская Республика10. Республика Карелия11. Республика Коми12. Республика Марий Эл13. Республика Мордовия14. Республика Саха (Якутия)15. Республика Северная Осетия — Алания16. Республика Татарстан17. Республика Тыва18. Удмуртская Республика19. Республика Хакасия21. Чувашская Республика22. Алтайский край23. Краснодарский край24. Красноярский край25. Приморский край26. Ставропольский край27. Хабаровский край28. Амурская область29. Архангельская область30. Астраханская область31. Белгородская область32. Брянская область33. Владимирская область34. Волгоградская область35. Вологодская область36. Воронежская область37. Ивановская область38. Иркутская область39. Калининградская область40. Калужская область41. Камчатский край42. Кемеровская область43. Кировская область44. Костромская область45. Курганская область46. Курская область47. Ленинградская область48. Липецкая область49. Магаданская область50. Московская область51. Мурманская область52. Нижегородская область53. Новгородская область54. Новосибирская область55. Омская область56. Оренбургская область57. Орловская область58. Пензенская область59. Пермский край60. Псковская область61. Ростовская область62. Рязанская область63. Самарская область64. Саратовская область65. Сахалинская область66. Свердловская область67. Смоленская область68. Тамбовская область69. Тверская область70. Томская область71. Тульская область72. Тюменская область73. Ульяновская область74. Челябинская область75. Забайкальский край76. Ярославская область77. город Москва78. город Санкт-Петербург79. Еврейская автономная область82. Республика Крым83. Ненецкий автономный округ86. Ханты-Мансийский автономный округ — Югра87. Чукотский автономный округ89. Ямало-Ненецкий автономный округ92. город Севастополь95. Чеченская Республика00. Российская Федерация

Госпошлины — Иркутская область. Официальный портал

 Вниманию эксплуатантов аттракционов!

Обратите внимание! В соответствии с Постановлением Правительства РФ от 23.09.2020 №1538 «О внесении изменений в постановление Правительства Российской Федерации от 13 ноября 2013 г. №1013 технический осмотр квадроциклов с 07.10.2020 года необходимо проходить в органах гостехнадзора.

Из-за неблагоприятной эпидемиологической обстановки:

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

Получателям справок о наличии или отсутствии зарегистрированных самоходных машин заявление необходимо подать в сканированном виде на адрес электронной почты [email protected]. Выдача справки заявителю осуществляется по истечении 5 рабочих дней с даты подачи заявления лично при предъявлении паспорта или доверенному лицу при предъявлении доверенности и паспорта по адресу: г. Иркутск, ул. Мухиной, д. 2А, каб. 216 либо направляется посредством АО Почта России на адрес регистрации заявителя.

Получателям справок о наличии или отсутствии выданного удостоверения тракториста-машиниста (тракториста) заявление необходимо подать в сканированном виде на адрес электронной почты [email protected]. Выдача справки заявителю осуществляется по истечении 3 рабочих дней с даты подачи заявления лично при предъявлении паспорта по адресу: г. Иркутск, ул. Мухиной, д. 2А, каб. 216.

Бланк заявления

---

№	Наименование пошлины
1	За государственную регистрацию транспортных средств и совершение иных регистрационных действий, связанных:
1.1	с выдачей государственных регистрационных знаков на мототранспортные средства, прицепы, тракторы, самоходные дорожно-строительные и иные самоходные машины, в том числе взамен утраченных или пришедших в негодность	1500
1.2	с выдачей паспорта транспортного средства, в том числе взамен утраченного или пришедшего в негодность	800
1.3	с выдачей свидетельства о регистрации транспортного средства, в том числе взамен утраченного или пришедшего в негодность	500
2	За внесение изменений в выданный ранее паспорт транспортного средства	350
3	За выдачу государственных регистрационных знаков транспортных средств «Транзит», в том числе взамен утраченных или пришедших в негодность изготавливаемых из расходных материалов на бумажной основе	200
4	За выдачу свидетельства на высвободившийся номерной агрегат, в том числе взамен утраченного или пришедшего в негодность	350
5	За выдачу документа о прохождении технического осмотра тракторов, самоходных дорожно­строительных и иных самоходных машин и прицепов к ним	400
6	За выдачу национального водительского удостоверения, удостоверения тракториста-машиниста (тракториста), временного удостоверения на право управления самоходными машинами, в том числе взамен утраченного или пришедшего в негодность изготавливаемого из расходных материалов на бумажной основе	500
7	За выдачу учебным учреждениям свидетельств о соответствии требованиям оборудования и оснащенности образовательного процесса для рассмотрения вопроса соответствующими органами об аккредитации и о выдаче указанным учреждениям лицензий на право подготовки трактористов и машинистов самоходных машин	1600
8	За государственную регистрацию (возобновление государственной регистрации) аттракциона, включая выдачу свидетельства о государственной регистрации аттракциона и государственного регистрационного знака на аттракцион:
8.1	с высокой степенью потенциального биомеханического риска (RB-1)	13000
8.2	со средней степенью потенциального биомеханического риска (RB-2)	7000
8.3	с низкой степенью потенциального биомеханического риска (RB-3)	3500
9	За временную государственную регистрацию по месту пребывания ранее зарегистрированного аттракциона:
9.1	с высокой степенью потенциального биомеханического риска (RB-1)	2400
9.2	со средней степенью потенциального биомеханического риска (RB-2)	1800
9.3	с низкой степенью потенциального биомеханического риска (RB-3)	1300
10	За выдачу дубликата свидетельства о государственной регистрации аттракциона	600
11	За выдачу справки о совершенных регистрационных действиях в отношении аттракциона	600
12	За выдачу государственного регистрационного знака на аттракцион взамен утраченного или пришедшего в негодность	1500

Дата изменения: 09.12.2020 12:14

Реквизиты на оплату госпошлин

РАЗМЕР ГОСУДАРСТВЕННОЙ ПОШЛИНЫ И ИНЫХ ПЛАТЕЖЕЙ ПРИ ПОЛУЧЕНИИ УСЛУГ РОСРЕЕСТРА ЗАВИСИТ ОТ КОЛИЧЕСТВА УЧАСТНИКОВ И РЕГИСТРАЦИОННЫХ  ДЕЙСТВИЙ (Сумму госпошлины  уточнить у специалиста МФЦ).

Плата за предоставление сведений, содержащихся в Едином государственном реестре недвижимости, осуществляется по уникальному идентификационному номеру начисления (УИН). платежный документ с указанием номера УИН выдает специалист МФЦ при приеме запроса.

КОНСУЛЬТАЦИЮ ПО ГОСУДАРСТВЕННЫМ ПОШЛИНАМ И ИНЫМ ПЛАТЕЖАМ ПРИ ПРЕДОСТАВЛЕНИИ ГОСУДАРСТВЕННЫХ И МУНИЦИПАЛЬНЫХ УСЛУГ МОЖНО ПОЛУЧИТЬ ПО ТЕЛЕФОНУ 8-800-200-8212 ИЛИ В МФЦ.

Управление Федеральной службы государственной регистрации, кадастра и картографии по Республике Коми  Филиал федерального государственного бюджетного учреждения «Федеральная кадастровая палата Федеральной службы государственной регистрации, кадастра и картографии» по Республике Коми

1. Государственный кадастровый учет недвижимого имущества и (или) государственная регистрация прав на недвижимое имущество и сделок с ним

Государственная пошлина за государственную регистрацию прав на недвижимое имущество и сделок с ним

2. Предоставление сведений, содержащихся в Едином государственном реестре недвижимости

Плата за предоставление сведений из ЕГРН (услуги Кадастровой палаты)

Плата за предоставление сведений из ЕГРН (услуги Управления Росреестра)

Размер части платы за предоставление сведений из ЕГРН

Управление Федеральной налоговой службы по Республике Коми

1. Государственная регистрация юридических лиц, физических лиц в качестве индивидуальных предпринимателей и крестьянских (фермерских) хозяйств

Государственная пошлина за повторную выдачу свидетельства о постановке на учет в налоговом органе

2. Предоставление заинтересованным лицам сведений, содержащихся в реестре дисквалифицированных лиц

Плата за предоставление информации из реестра дисквалифицированных лиц (РДЛ)

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

Государственная пошлина за предоставление сведений, содержащихся в ЕГРЮЛ, ЕГРИП

Министерство внутренних дел по Республике Коми

1. Проведение экзаменов на право управления транспортными средствами и выдаче водительских удостоверений (в части выдачи российских национальных водительских  удостоверений при замене, утрате (хищении) и  международных водительских удостоверений)

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

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

Государственная пошлина за оформление паспорта гражданина РФ

Государственная пошлина за выдачу паспорта гражданина Российской Федерации взамен утраченного или пришедшего в негодность

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

Государственная пошлина за  внесение изменений в загранпаспорт гражданина РФ (старого образца на 5 лет)

Государственная пошлина за оформление загранпаспорта гражданина РФ до 14 лет (старого образца на 5 лет)

Государственная пошлина за оформление загранпаспорта гражданина РФ (старого образца на 5 лет)

Государственная пошлина за оформление биометрического загранпаспорта гражданина РФ

 

 

Госпошлина за регистрацию автомобилей в ГИБДД выросла в 1,5 раза | Новости Нижнего Тагила и Свердловской области

№ п/п	Наименование операции	Госпош
1	Регистрация нового автомобиля при наличии ПТС	2850
2	Регистрация нового автомобиля при выдаче ПТС в ГИБДД	3300
3	Перерегистрация автомобиля без замены госномеров при наличии ПТС	850
4	Перерегистрация автомобиля без замены госномеров при выдаче ПТС в ГИБДД	1300
5	Перерегистрация автомобиля с выдачей госномеров при наличии ПТС	2850
6	Перерегистрация автомобиля с выдачей госномеров и выдачей ПТС в ГИБДД	3300
7	Снятие с учета автомобиля, убывающего за пределы РФ, с выдачей регистрационных знаков Тип – 19 «Транзит» (металл)	1600
8	Снятие с учета автомобиля, убывающего за пределы РФ, с выдачей регистрационных знаков Тип – 19 «Транзит» (металл) и свидетельства о регистрации	2100
9	Дубликат ПТС (техпаспорта) с заменой госномеров	3300
10	Дубликат ПТС (техпаспорта) без замены госномеров	1300
11	Дубликат свидетельства о регистрации с заменой госномеров при наличии ПТС	2850
12	Дубликат свидетельства о регистрации с заменой госномеров с выдачей ПТС в ГИБДД	3300
13	Дубликат свидетельства о регистрации без замены госномеров при наличии ПТС	850
14	Дубликат свидетельства о регистрации без замены госномеров при выдаче ПТС в ГИБДД	1300
15	Дубликат свидетельства о регистрации, ПТС и госномеров	3300
16	Дубликат регистрационных знаков при наличии ПТС	2850
17	Выдача акта ТО	0
18	Выдача свидетельства о соответствии конструкции ТС	800
19	Выдача свидетельства на высвободившийся номерной агрегат (кузов, рама)	350
20	Регистрация временного ввоза автомобиля (прибывшего из-за рубежа)	2500
21	Выдача транзитных номеров для перегона на территории РФ	200
22	Выдача национального водительского удостоверения	2000
23	Выдача международного водительского удостоверения	1600

Госпошлины со скидкой — Новости — Главная — Официальный сайт Администрации Дружининского городского поселения

16 февраля 2017

Госпошлины со скидкой

Уважаемы граждане, РЭО ГИБДД МО МВД России «Нижнесергинский» информирует

   С 1 января 2017 года граждане обратившиеся через Единый портал государственных и муниципальных услуг смогут оплачивать государственные пошлины со скидкой 30% от первоначальной суммы.

   Размер взимаемой государственной пошлины за предоставление государственных услуг по регистрации транспортных средств, выдаче водительских удостоверений и совершение иных регистрационных действий

Государственная услуга по регистрации транспортных средств, выдаче водительских удостоверений и совершение иных регистрационных действий	Государственная пошлина	Государственная пошлина со скидкой 30% через Единый портал государственных услуг
Регистрация нового автомобиля при наличии ПТС	2850	1995
Регистрация нового автомобиля при выдаче ПТС	3300	2310
Регистрация нового прицепа при наличии ПТС	2350	1645
Регистрация нового мотоцикла при наличии ПТС	2800	1960
Перерегистрация автомобиля без замены г/номеров при наличии ПТС	850	595
Перерегистрация автомобиля без замены г/номеров с выдачей ПТС	1300	910
Перерегистрация автомобиля с выдачей г/номеров при наличии ПТС	2850	1995
Перерегистрация автомобиля с выдачей г/номеров и ПТС	3300	2310
Снятие с учета ТС с убытием за пределы РФ при наличии свидетельства и регистрации и выдачи транзита	200	140
Снятие с учета ТС с убытием за пределы РФ при выдачи свидетельства о регистрации и выдачи транзита	700	490
Выдача дубликата ПТС с заменой г/номеров	3300	2310
Выдача дубликата ПТС без замены г/номеров	1300	910
Выдача дубликата свидетельства о регистрации с заменой г/номеров при наличии ПТС	2850	1995
Выдача дубликата свидетельства о регистрации с заменой г/номеров с выдачей ПТС	3300	2310
Выдача дубликата свидетельства о регистрации без замены г/номеров при наличии ПТС	850	595
Выдача дубликата г/номеров при наличии ПТС	2850	1995
Выдача дубликата г/номеров с выдачей ПТС	3300	2310
Выдача дубликата г/номеров и свидетельства о регистрации при наличии ПТС	2850	1995
Выдача дубликата г/номеров и свидетельства о регистрации с выдачей ПТС	3300	2310
Регистрация временного ввоза автомобиля прибывшего из-за рубежа	2500	1750
Получение национального водительского удостоверения	2000	1400
Получение международного водительского удостоверения	1600	1120
Получение российского национального водительского удостоверения после обмена иностранного национального водительского удостоверения	2000	— — — — —

   Также вы можете оценить качество предоставленных государственных услуг на официальных сайтах https://66mvd.ru, https://www.vashkontrol.ru, в личном кабинете Единого портала государственных и муниципальных услуг, с помощью текстовых сообщений (смс-опросы), также с помощью анкет в подразделении РЭО ГИБДД.

Назад к списку

IPsec через TCP терпит неудачу при прохождении трафика через ASA

Cisco VPN-клиенты, которые подключаются к головному узлу VPN с помощью IPsec через TCP, могут подключиться к головному узлу нормально, но затем через некоторое время соединение не будет установлено. В этом документе описывается, как переключиться на IPsec через UDP или встроенную инкапсуляцию ESP IPsec для решения проблемы.

Требования

Чтобы столкнуться с этой конкретной проблемой, клиенты Cisco VPN должны быть настроены для подключения к головному устройству VPN с использованием IPsec через TCP.В большинстве случаев сетевые администраторы настраивают ASA для приема подключений клиента Cisco VPN через порт TCP 10000.

Используемые компоненты

Информация в этом документе основана на Cisco VPN Client.

Условные обозначения

Дополнительные сведения об условных обозначениях в документах см. В разделе «Условные обозначения технических советов Cisco».

Когда VPN-клиент настроен для IPsec over TCP (cTCP), программное обеспечение VPN-клиента не будет отвечать, если получен дублированный TCP ACK, запрашивающий у VPN-клиента повторную передачу данных.Дублирующий ACK может быть сгенерирован, если есть потеря пакета где-то между VPN-клиентом и головным узлом ASA. Периодическая потеря пакетов — довольно распространенная реальность в Интернете. Однако, поскольку конечные точки VPN не используют протокол TCP (напомним, что они используют cTCP), конечные точки продолжат передачу, и соединение будет продолжено.

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

Это не ошибка, а побочный эффект потери пакетов в сети и того факта, что cTCP не является настоящим TCP. CTCP пытается имитировать протокол TCP, заключая пакеты IPsec в заголовок TCP, но это объем протокола.

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

Решение

Чтобы решить эту проблему, выполните любое из следующих действий:

• Переключитесь с IPsec через TCP на IPsec через UDP или встроенную инкапсуляцию с протоколом ESP.

• Переключитесь на клиента AnyConnect для завершения VPN, который использует полностью реализованный стек протоколов TCP.

• Настройте ASA для применения обхода состояния tcp для этих конкретных потоков IPsec / TCP. Это по существу отключает все проверки безопасности для соединений, которые соответствуют политике обхода tcp-state, но позволит соединениям работать до тех пор, пока не будет реализовано другое разрешение из этого списка. Дополнительные сведения см. В разделе «Рекомендации и ограничения по обходу состояния TCP».

• Определите источник потери пакета и выполните корректирующие действия, чтобы предотвратить попадание пакетов IPsec / TCP в сеть.Обычно это невозможно или крайне сложно, поскольку причиной проблемы обычно является потеря пакетов в Интернете, и отбрасывание невозможно предотвратить.

Сетевая рабочая группа М. Аллман Запрос комментариев: 5681 В. Паксон Вышло из употребления: 2581 ICSI Категория: Стандарты Track E.Blanton Университет Пердью Сентябрь 2009 г. Контроль перегрузки TCP Абстрактный Этот документ определяет четыре взаимосвязанных контроля перегрузки TCP. алгоритмы: медленный старт, предотвращение перегрузки, быстрая повторная передача и Быстрое выздоровление. Кроме того, в документе указывается, как TCP должен начать передачу после относительно длительного периода простоя, а также обсуждение различных методов генерации подтверждений.Этот документ устарел RFC 2581. Статус этой памятки Этот документ определяет протокол отслеживания стандартов Интернета для Интернет-сообщество и просит обсуждения и предложения по улучшения. См. Текущую редакцию «Интернет Официальные стандарты протокола »(STD 1) для состояния стандартизации и статус этого протокола. Распространение этой памятки не ограничено. Уведомление об авторских правах Авторские права (c) 2009 IETF Trust и лица, указанные как авторы документа.Все права защищены. Этот документ подпадает под действие BCP 78 и Правового регулирования IETF Trust. Положения, относящиеся к документам IETF, действующие на дату публикация этого документа (http://trustee.ietf.org/license-info). Пожалуйста, внимательно ознакомьтесь с этими документами, поскольку они описывают ваши права. и ограничения в отношении этого документа. Этот документ может содержать материалы из документов IETF или IETF. Материалы опубликованы или станут общедоступными до ноября. 10, 2008. Лица, контролирующие авторские права на некоторые из этих материал, возможно, не предоставил IETF Trust право разрешать модификации такого материала вне процесса стандартизации IETF.Без получения соответствующей лицензии от лица (лиц), контролирующего авторские права на такие материалы, этот документ не может быть изменен вне Процесса стандартизации IETF, и производные от него разработки могут Allman и др. Standards Track [Страница 1] RFC 5681 TCP Congestion Control, сентябрь 2009 г. не создаваться вне процесса стандартизации IETF, кроме как для форматирования его для публикации как RFC или для перевода на другие языки чем английский.Оглавление 1. Введение ……………………………………….. ….. 2 2. Определения ……………………………………….. …… 3 3. Алгоритмы контроля перегрузки …………………………….. 4 3.1. Медленный запуск и предотвращение перегрузки …………………… 4 3.2. Fast Retransmit / Fast Recovery ………………………… 8 4. Дополнительные соображения ……………………………….. 10 4.1. Перезапуск неактивных подключений …………………………. 10 4.2. Формирование благодарностей ………………………….. 11 4.3. Механизмы возмещения убытков ……………………………. 12 5. Соображения безопасности …………………………………. 13 6. Изменения между RFC 2001 и RFC 2581 …………………….. 13 7. Изменения относительно RFC 2581 …………………………….. 14 8. Благодарности ……………………………………….. .15 9. Ссылки …………………………………………….. 15 9.1. Нормативные ссылки ……………………………….. 15 9.2. Информационные ссылки ……………………………… 16 1. Введение Этот документ определяет четыре TCP [RFC793] контроля перегрузки алгоритмы: медленный старт, предотвращение перегрузки, быстрая повторная передача и Быстрое выздоровление. Эти алгоритмы были разработаны в [Jac88] и [Jac90]. Их использование с TCP стандартизировано в [RFC1122]. Дополнительный ранний работать в аддитивном увеличении, мультипликативном уменьшении контроля перегрузки приведен в [CJ89].Обратите внимание, что [Ste94] предоставляет примеры этих алгоритмов в действии и [WS95] предоставляет объяснение исходного кода для BSD. реализация этих алгоритмов. В дополнение к указанию этих алгоритмов управления перегрузкой, это документ определяет, что TCP-соединения должны делать после относительно длительный период простоя, а также уточнение и уточнение некоторых проблемы, связанные с генерацией TCP ACK. Этот документ устарел [RFC2581], который, в свою очередь, устарел [RFC2001].Этот документ организован следующим образом. В разделе 2 представлены различные определения, которые будут использоваться в документе. Раздел 3 предоставляет спецификацию алгоритмов управления перегрузкой. В разделе 4 излагаются проблемы, связанные с контролем перегрузки. алгоритмы и, наконец, в разделе 5 изложены соображения безопасности. Allman и др. Стандарты Track [Страница 2] RFC 5681 TCP Congestion Control, сентябрь 2009 г. Ключевые слова «ДОЛЖНЫ», «НЕ ДОЛЖНЫ», «ОБЯЗАТЕЛЬНО», «ДОЛЖНЫ», «НЕ ДОЛЖНЫ», «ДОЛЖЕН», «НЕ ДОЛЖЕН», «РЕКОМЕНДУЕТСЯ», «МОЖЕТ» и «ДОПОЛНИТЕЛЬНО» в этом документ следует интерпретировать, как описано в [RFC2119].2. Определения В этом разделе дается определение нескольких терминов, которые будут используется в остальной части этого документа. СЕГМЕНТ: Сегмент — это ЛЮБЫЕ данные TCP / IP или пакет подтверждения (или обе). МАКСИМАЛЬНЫЙ РАЗМЕР СЕГМЕНТА ОТПРАВИТЕЛЯ (SMSS): SMSS — это размер самый большой сегмент, который отправитель может передать. Это значение может быть исходя из максимальной единицы передачи сети, путь Алгоритм обнаружения MTU [RFC1191, RFC4821], RMSS (см. Следующий пункт), или другие факторы.Размер не включает заголовки TCP / IP. и варианты. МАКСИМАЛЬНЫЙ РАЗМЕР СЕГМЕНТА ПРИЕМНИКА (RMSS): RMSS — это размер самый большой сегмент, который приемник готов принять. Это значение, указанное в опции MSS, отправленное получателем во время подключение запускается. Или, если опция MSS не используется, это 536 байтов [RFC1122]. Размер не включает заголовки TCP / IP и опции. ПОЛНЫЙ СЕГМЕНТ: сегмент, содержащий максимальное количество разрешенные байты данных (т.е., сегмент, содержащий байты SMSS данные). ОКНО ПРИЕМНИКА (rwnd): последнее объявленное окно приемника. ОКНО ЗАГРЯЗНЕНИЯ (cwnd): переменная состояния TCP, ограничивающая количество данных, которые TCP может отправить. В любой момент времени TCP НЕ ДОЛЖЕН отправлять данные с порядковым номером выше суммы наивысшего подтвержденный порядковый номер и минимум cwnd и rwnd. НАЧАЛЬНОЕ ОКНО (IW): начальное окно — это размер окна отправителя. окно насыщения после завершения трехстороннего рукопожатия.ОКНО ПОТЕРИ (LW): окно потерь — это размер перегрузки. окно после того, как отправитель TCP обнаружит потерю, используя его повторную передачу таймер. RESTART WINDOW (RW): Окно перезапуска соответствует размеру перегрузки. окно после того, как TCP перезапустит передачу после периода ожидания (если используется алгоритм медленного старта; см. раздел 4.1 для получения дополнительной информации обсуждение). Allman и др. Стандарты Track [Страница 3] RFC 5681 TCP Congestion Control, сентябрь 2009 г. РАЗМЕР ПОЛЕТА: количество данных, которые были отправлены, но еще не были отправлены. совокупно признано.ДВОЙНОЕ ПОДТВЕРЖДЕНИЕ: подтверждение считается «дублировать» в следующих алгоритмах, когда (а) получатель ACK имеет ожидающие данные, (b) входящее подтверждение не несет данных, (c) биты SYN и FIN отключены, (d) номер подтверждения равен наибольшему подтверждению получено по данному соединению (TCP.UNA из [RFC793]) и (e) объявленное окно во входящем подтверждении равно объявленное окно в последнем входящем подтверждении.В качестве альтернативы TCP, который использует выборочные подтверждения (SACK) [RFC2018, RFC2883] может использовать информацию SACK для определить, является ли входящий ACK «дубликатом» (например, если ACK содержит ранее неизвестную информацию SACK). 3. Алгоритмы контроля перегрузки В этом разделе определены четыре алгоритма управления перегрузкой: медленный. запуск, предотвращение перегрузки, быстрая повторная передача и быстрое восстановление, разработан в [Jac88] и [Jac90]. В некоторых ситуациях это может быть для TCP-отправителя выгодно быть более консервативным, чем алгоритмы позволяют; однако TCP НЕ ДОЛЖЕН быть более агрессивным, чем следующие алгоритмы разрешают (то есть НЕ ДОЛЖНЫ отправлять данные, когда значение cwnd, вычисленное следующими алгоритмами, не позволило бы данные для отправки).Также обратите внимание, что алгоритмы, указанные в этом документе, работают в условия использования потерь как сигнала перегрузки. Явная перегрузка Уведомление (ECN) также может использоваться, как указано в [RFC3168]. 3.1. Медленный старт и предотвращение перегрузки Алгоритмы медленного старта и предотвращения перегрузки ДОЛЖНЫ использоваться Отправитель TCP для контроля количества вводимых незавершенных данных в сеть. Для реализации этих алгоритмов используются две переменные: добавлен в состояние TCP для каждого соединения.Окно перегрузки (cwnd) ограничение на объем данных, которые отправитель может передать на стороне отправителя. в сеть до получения подтверждения (ACK), в то время как объявленное окно получателя (rwnd) — это ограничение на стороне получателя на количество невыполненных данных. Минимум cwnd и rwnd управляет передача данных. Используется другая переменная состояния, порог медленного старта (ssthresh). чтобы определить, какой алгоритм используется: медленный старт или алгоритм предотвращения перегрузки используется для управления передачей данных, как обсуждается ниже.Allman и др. Стандарты Track [Страница 4] RFC 5681 TCP Congestion Control, сентябрь 2009 г. Начало передачи в сеть с неизвестными условиями требует, чтобы TCP медленно зондировал сеть, чтобы определить доступные емкости, чтобы избежать перегрузки сети неуместно большой пакет данных. Алгоритм медленного старта: используется для этой цели в начале передачи или после восстановление потери, обнаруженной таймером повторной передачи.Медленный старт дополнительно служит для запуска «часов ACK», используемых отправителем TCP для выпуска данных в сеть при медленном запуске, перегрузке алгоритмы предотвращения и восстановления потерь. IW, начальное значение cwnd, ДОЛЖНО быть установлено с использованием следующих руководящие принципы в качестве верхней границы. Если SMSS> 2190 байт: IW = 2 * байта SMSS и НЕ ДОЛЖЕН быть более 2 сегментов Если (SMSS> 1095 байт) и (SMSS RFC 5681 TCP Congestion Control, сентябрь 2009 г. Алгоритм медленного старта используется, когда cwnd ssthresh.Когда cwnd и ssthresh равны, отправитель может использовать либо медленный старт, либо предотвращение перегрузки. Во время медленного запуска TCP увеличивает cwnd максимум на байты SMSS для каждый полученный ACK, который в совокупности подтверждает новые данные. Медленный start заканчивается, когда cwnd превышает ssthresh (или, необязательно, когда он достигает его, как отмечалось выше) или когда наблюдается скопление. Пока Традиционно реализации TCP увеличили cwnd точно на Байты SMSS после получения ACK, покрывающего новые данные, РЕКОМЕНДУЕМ что реализации TCP увеличивают cwnd на: cwnd + = min (N, SMSS) (2) где N — количество подтвержденных ранее неподтвержденных байтов во входящем ACK.Эта настройка является частью соответствующего байта. Подсчет [RFC3465] и защита от ненадлежащего поведения получатели, которые могут попытаться побудить отправителя искусственно раздуть cwnd с использованием механизма, известного как «ACK Division» [SCWA99]. ACK Подразделение состоит из получателя, отправляющего несколько ACK для одного Сегмент данных TCP, каждый из которых подтверждает только часть своих данных. А TCP, увеличивающий cwnd на SMSS для каждого такого ACK, будет ненадлежащим образом завышать объем данных, вводимых в сеть.Во время предотвращения перегрузки cwnd увеличивается примерно на 1 полный размер сегмента за время приема-передачи (RTT). Предотвращение перегрузки продолжается, пока не будет обнаружена перегрузка. Основные рекомендации по увеличение cwnd во время предотвращения перегрузки: * МОЖЕТ увеличивать cwnd на байты SMSS * СЛЕДУЕТ увеличивать cwnd по уравнению (2) один раз за RTT * НЕ ДОЛЖНЫ увеличивать cwnd более чем на байты SMSS Отметим, что [RFC3465] допускает увеличение cwnd более чем на SMSS. байтов для входящих подтверждений во время медленного старта на экспериментальная база; однако такое поведение не допускается как часть стандарт.РЕКОМЕНДУЕМЫЙ способ увеличения cwnd во избежание перегрузки: для подсчета количества байтов, подтвержденных ACK для новые данные. (Недостатком этой реализации является то, что она требует поддерживая дополнительную переменную состояния.) Когда количество байтов Подтвержденный достигает cwnd, затем cwnd может быть увеличен до SMSS байтов. Обратите внимание, что во время предотвращения перегрузки cwnd НЕ ДОЛЖЕН быть Allman и др. Стандарты Track [Страница 6] RFC 5681 TCP Congestion Control, сентябрь 2009 г. увеличилось более чем на SMSS байт за RTT.Этот метод позволяет TCP для увеличения cwnd на один сегмент за RTT в условиях задержки ACK и обеспечивает устойчивость к атакам ACK Division. Еще одна распространенная формула, которую TCP МОЖЕТ использовать для обновления cwnd во время Предотвращение заторов приведено в уравнении (3): cwnd + = SMSS * SMSS / cwnd (3) Эта настройка выполняется для каждого входящего ACK, подтверждающего новые данные. Уравнение (3) дает приемлемое приближение к лежащий в основе принцип увеличения cwnd на 1 полноразмерный сегмент на RTT.(Обратите внимание, что для подключения, в котором приемник подтверждение каждого второго пакета, (3) менее агрессивно, чем разрешено — примерно увеличивается cwnd каждую секунду RTT.) Примечание по реализации: поскольку в TCP обычно используется целочисленная арифметика реализаций, формула, приведенная в уравнении (3), может не увеличивайте cwnd, когда окно перегрузки больше, чем SMSS * SMSS. Если приведенная выше формула дает 0, результат ДОЛЖЕН быть округлен до 1. байт. Примечание по реализации: в более старых реализациях есть дополнительная аддитивная константа в правой части уравнения (3).Это неверно и может фактически привести к снижению производительности [RFC2525]. Примечание по реализации: некоторые реализации поддерживают cwnd в единицах байты, а остальные — в единицах полноразмерных сегментов. Последний будет находят уравнение (3) трудным для использования и могут предпочесть использовать счетный подход, рассмотренный в предыдущем абзаце. Когда отправитель TCP обнаруживает потерю сегмента с помощью таймера повторной передачи и данный сегмент еще не пересылался в таймер повторной передачи, значение ssthresh ДОЛЖНО быть установлено на no more чем значение, указанное в уравнении (4): ssthresh = max (Размер полета / 2, 2 * SMSS) (4) где, как обсуждалось выше, FlightSize — это сумма невыплаченных данные в сети.С другой стороны, когда отправитель TCP обнаруживает потерю сегмента, используя таймер повторной передачи и данный сегмент уже был ретранслируется таймером повторной передачи хотя бы один раз, значение ssthresh остается постоянным. Allman и др. Стандарты Track [Страница 7] RFC 5681 TCP Congestion Control, сентябрь 2009 г. Примечание по реализации: простая ошибка — просто использовать cwnd, а не FlightSize, который в некоторых реализациях может кстати увеличиваются далеко за пределы rwnd.Кроме того, по истечении времени ожидания (как указано в [RFC2988]) cwnd ДОЛЖЕН быть не более чем окно потерь LW, которое равно 1 полноразмерному сегмент (независимо от значения IW). Поэтому после повторная передача отброшенного сегмента, отправитель TCP использует медленный старт алгоритм увеличения окна с 1 полноразмерного сегмента до нового значение ssthresh, при котором для предотвращения перегрузки снова требуется над. Как показано в [FF96] и [RFC3782], восстановление потерь на основе медленного старта после тайм-аута может вызвать ложные повторные передачи, которые запускают повторяющиеся благодарности.Реакция на прибытие этих повторяющиеся ACK в реализациях TCP сильно различаются. Этот документ не указывает, как относиться к таким признаниям, но отмечает это как область, которой можно уделить дополнительное внимание, экспериментирование и уточнение. 3.2. Быстрая ретрансляция / быстрое восстановление Получатель TCP ДОЛЖЕН немедленно отправить дубликат ACK при исходящем прибывает сегмент порядка. Целью этого ACK является информирование отправитель, что сегмент был получен не по порядку и в какой последовательности число ожидается.С точки зрения отправителя дублирующиеся ACK может быть вызвано рядом сетевых проблем. Во-первых, они могут быть вызвано выпавшими сегментами. В этом случае все сегменты после отброшенный сегмент вызовет дублирование ACK до тех пор, пока потеря не будет отремонтирован. Во-вторых, дублирование ACK может быть вызвано изменением порядка сегменты данных по сети (не редкое событие в какой-то сети пути [Pax97]). Наконец, повторяющиеся ACK могут быть вызваны репликацией. ACK или сегментов данных по сети.Кроме того, приемник TCP СЛЕДУЕТ немедленно отправлять ACK, когда входящий сегмент заполняет все или часть промежутка в пространстве последовательности. Это даст больше своевременная информация для отправителя, возмещающего убытки через тайм-аут повторной передачи, быстрая повторная передача или расширенная потеря алгоритм восстановления, как описано в разделе 4.3. Отправителю TCP СЛЕДУЕТ использовать алгоритм «быстрой повторной передачи» для обнаружения и потеря ремонта на основе входящих дублирующих ACK. Быстро Алгоритм повторной передачи использует поступление 3 повторяющихся ACK (как определено в разделе 2, без каких-либо промежуточных ACK, которые перемещают SND.UNA) в качестве индикация потери сегмента. После получения 3-х дубликатов ACK, TCP выполняет повторную передачу того, что кажется отсутствующим. сегмент, не дожидаясь истечения таймера повторной передачи. Allman и др. Стандарты Track [Страница 8] RFC 5681 TCP Congestion Control, сентябрь 2009 г. После того, как алгоритм быстрой ретрансляции отправит то, что кажется отсутствующий сегмент, алгоритм «быстрого восстановления» управляет передача новых данных до тех пор, пока не будет получен неповторимый ACK.В Причина невыполнения медленного старта заключается в том, что получение повторяющиеся ACK не только указывают на то, что сегмент был потерян, но и также, что сегменты, скорее всего, покидают сеть (хотя массивное дублирование сегмента в сети может сделать это недействительным вывод). Другими словами, поскольку получатель может только генерировать дублировать ACK, когда сегмент прибыл, этот сегмент покинул сети и находится в буфере получателя, поэтому мы знаем, что это больше не потребляющие сетевые ресурсы.Кроме того, поскольку ACK «часы» [Jac88] сохраняется, отправитель TCP может продолжать передавать новые сегменты (хотя передача должна продолжаться с использованием сокращенного cwnd, поскольку потеря является признаком перегрузки). Реализованы алгоритмы быстрой ретрансляции и быстрого восстановления. вместе следующим образом. 1. На первом и втором дублированных ACK, полученных отправителем, TCP ДОЛЖЕН отправлять сегмент ранее не отправленных данных согласно [RFC3042] при условии, что объявленное окно получателя позволяет, общая FlightSize останется меньше или равным cwnd плюс 2 * SMSS, и что новые данные доступны для передачи.Далее Отправитель TCP НЕ ДОЛЖЕН изменять cwnd для отражения этих двух сегментов. [RFC3042]. Обратите внимание, что отправитель, использующий SACK [RFC2018], НЕ ДОЛЖЕН отправлять новые данные, если входящее дублирующее подтверждение не содержит новая информация о SACK. 2. Когда получен третий дублирующий ACK, TCP ДОЛЖЕН установить ssthresh. не более чем значение, указанное в уравнении (4). Когда [RFC3042] используется, дополнительные данные, отправленные в режиме ограниченной передачи, НЕ ДОЛЖНЫ быть включены в этот расчет.3. Потерянный сегмент, начинающийся с SND.UNA, ДОЛЖЕН быть передан повторно и cwnd установлен на ssthresh плюс 3 * SMSS. Это искусственно «раздувает» окно перегрузки по количеству сегментов (три), в которых вышел из сети и буферизован получателем. 4. За каждый полученный дополнительный дубликат ACK (после третьего), cwnd ДОЛЖЕН быть увеличен с помощью SMSS. Это искусственно раздувает окно перегрузки, чтобы отразить дополнительный сегмент, который покинул сеть.Примечание: [SCWA99] обсуждает атаку на приемник, при которой многие поддельные дубликаты ACK отправляются отправителю данных, чтобы искусственно раздуть cwnd и вызвать превышение допустимого Allman и др. Стандарты Track [Страница 9] RFC 5681 TCP Congestion Control, сентябрь 2009 г. скорость отправки, которая будет использоваться. Поэтому TCP МОЖЕТ ограничить количество раз cwnd искусственно завышается во время восстановления потерь до количество незавершенных сегментов (или их приблизительное значение).Примечание. Когда расширенный механизм восстановления потерь (например, в разделе 4.3) не используется, это увеличение FlightSize может заставляют уравнение (4) слегка увеличивать cwnd и ssthresh, поскольку некоторые сегментов между SND.UNA и SND.NXT предполагается иметь покинули сеть, но по-прежнему отражаются в FlightSize. 5. Если доступны ранее неотправленные данные и новое значение cwnd и объявленное окно получателя разрешают, TCP ДОЛЖЕН отправить 1 * SMSS байт ранее неотправленных данных.6. Когда приходит следующий ACK, подтверждающий ранее неподтвержденные данные, TCP ДОЛЖЕН установить cwnd на ssthresh (значение установлен на шаге 2). Это называется «сдуванием» окна. Этот ACK должен быть подтверждением, вызванным повторная передача с шага 3, один RTT после повторной передачи (хотя он может прибыть раньше при наличии значительных выбросов заказная доставка сегментов данных получателю). Кроме того, этот ACK должен подтверждать все промежуточные сегменты, отправленные между потерянным сегментом и получением третий дубликат ACK, если ни один из них не был потерян.Примечание. Известно, что этот алгоритм обычно не обеспечивает эффективного восстановления. от множественных потерь в одной серии пакетов [FF96]. Раздел 4.3 ниже касается таких случаев. 4. Дополнительные соображения 4.1. Перезапуск неактивных подключений Известная проблема с описанными алгоритмами контроля перегрузки TCP выше заключается в том, что они допускают потенциально несоответствующий всплеск трафика для передачи после того, как TCP простаивает в течение относительно длительного времени период времени. После периода простоя TCP не может использовать часы ACK для стробирования новых сегментов в сети, так как все ACK истощены из сети.Следовательно, как указано выше, TCP потенциально может послать пакет линейной скорости размера cwnd в сеть после простоя период. Кроме того, изменение условий сети могло привести к Представление TCP о доступной сквозной пропускной способности сети между двумя конечные точки, по оценке cwnd, неточные во время длительный простой. Allman и др. Стандарты Track [Страница 10] RFC 5681 TCP Congestion Control, сентябрь 2009 г. [Jac88] рекомендует TCP использовать медленный старт для возобновления передачи. после относительно длительного простоя.Медленный старт служит для перезапуска часы ACK, как и в начале передачи. Этот Механизм получил широкое распространение следующим образом. Когда TCP не получил сегмент более одного тайм-аута повторной передачи, cwnd уменьшается до значения окна перезапуска (RW) перед передача начинается. Для целей этого стандарта мы определяем RW = min (IW, cwnd). Используя время последнего получения сегмента, чтобы определить, не уменьшать cwnd может не сдуть cwnd в общем случае постоянные HTTP-соединения [HTH98].В этом случае веб-сервер получает запрос перед передачей данных веб-клиенту. В прием запроса приводит к сбою теста на неактивное соединение, и позволяет TCP начать передачу с возможно неуместно большой cwnd. Следовательно, TCP ДОЛЖЕН установить cwnd не более чем RW перед началом передача, если TCP не отправлял данные в интервале, превышающем таймаут повторной передачи. 4.2. Создание благодарностей Алгоритм отложенного ACK, указанный в [RFC1122], ДОЛЖЕН использоваться Приемник TCP.При использовании отложенных ACK получатель TCP НЕ ДОЛЖЕН чрезмерно задерживать подтверждения. В частности, ACK ДОЛЖЕН быть генерируется как минимум для каждого второго полноразмерного сегмента и ДОЛЖЕН быть генерируется в течение 500 мс после поступления первого неподтвержденного пакет. Требование, чтобы ACK «ДОЛЖЕН» создаваться хотя бы для каждого второй полноразмерный сегмент указан в [RFC1122] в одном месте как ОБЯЗАТЕЛЬНО, а другое — ОБЯЗАТЕЛЬНО. Здесь мы однозначно заявляем, что это ДОЛЖЕН. Мы также подчеркиваем, что это ДОЛЖНО, а это означает, что разработчик действительно должен отклоняться от этого требования только после того, как тщательное рассмотрение последствий.См. Обсуждение «Нарушение растягивания ACK» в [RFC2525] и ссылки в нем для обсуждение возможных проблем производительности при генерации ACK реже, чем каждый второй полноразмерный сегмент. В некоторых случаях отправитель и получатель могут не договориться о том, что представляет собой полноразмерный сегмент. Считается, что реализация соблюдать это требование, если он отправляет хотя бы одно подтверждение каждый раз, когда он получает 2 * RMSS байта новых данных от отправителя, где RMSS — максимальный размер сегмента, указанный получателем для отправитель (или значение по умолчанию 536 байт согласно [RFC1122], если приемник не указывает опцию MSS во время подключения Allman и др.Стандарты Track [стр. 11] RFC 5681 TCP Congestion Control, сентябрь 2009 г. учреждение). Отправитель может быть вынужден использовать сегмент меньшего размера чем RMSS из-за максимального блока передачи (MTU), MTU пути алгоритм обнаружения или другие факторы. Например, рассмотрим случай, когда получатель объявляет RMSS размером X байтов, но отправитель заканчивается использование сегмента размером Y байтов (Y RFC 5681 TCP Congestion Control, сентябрь 2009 г. был успешно повторно передан, cwnd ДОЛЖЕН быть установлен не более чем ssthresh и предотвращение перегрузки ДОЛЖНЫ использоваться для дальнейшего увеличения cwnd.Потеря двух последовательных окон данных или потеря одного повторную передачу следует рассматривать как два признака перегрузки и, следовательно, в этом случае cwnd (и ssthresh) ДОЛЖНЫ быть уменьшены дважды. Мы РЕКОМЕНДУЕМ разработчикам TCP использовать какую-либо форму расширенных потерь. восстановление, которое может справиться с множественными потерями в окне данных. В алгоритмы, подробно описанные в [RFC3782] и [RFC3517], соответствуют общим принципы, изложенные выше. Отметим, что пока это не единственные два алгоритма, которые соответствуют указанным выше общим принципам, эти два алгоритмы были проверены сообществом и в настоящее время Стандарты Track.5. Соображения безопасности Этот документ требует, чтобы TCP уменьшил скорость отправки в наличие таймаутов ретрансляции и приход дубликата благодарности. Таким образом, злоумышленник может снизить производительность TCP-соединение, вызывая пакеты данных или их признания утерянными, или путем подделки избыточных дубликатов благодарности. В ответ на атаку подразделения ACK, описанную в [SCWA99], это документ РЕКОМЕНДУЕТ увеличить окно перегрузки на основе количество байтов, вновь подтвержденных в каждом поступающем ACK, а не определенной константой для каждого приходящего ACK (как описано в разделе 3.1). Интернет в значительной степени полагается на правильные реализация этих алгоритмов для сохранения сети стабильность и избежать развала заторов. Злоумышленник может вызвать TCP конечные точки, чтобы более агрессивно реагировать на перегрузку за счет подделка чрезмерного количества повторяющихся подтверждений или чрезмерного Благодарности за новые данные. Вероятно, такая атака могла загнать часть сети в коллапс из-за перегрузки. 6. Изменения между RFC 2001 и RFC 2581 [RFC2001] был сильно переписан редакционной редакцией, и это не возможно перечислить список изменений между [RFC2001] и [RFC2581].Намерение [RFC2581] состояло в том, чтобы не изменять ни одну из рекомендации, данные в [RFC2001], но для дальнейшего прояснения случаев, когда не обсуждались подробно в [RFC2001]. В частности, [RFC2581] предложил, что TCP-соединения должны делать после относительно длительного простоя период, а также уточнил и прояснил некоторые вопросы Allman и др. Стандарты Track [стр. 13] RFC 5681 TCP Congestion Control, сентябрь 2009 г. относящиеся к генерации TCP ACK.Наконец, допустимая верхняя граница для начального окна перегрузки было увеличено с одного до двух сегменты. 7. Изменения относительно RFC 2581 Было добавлено конкретное определение для «дублированного подтверждения», на основе определения, используемого BSD TCP. В документе теперь отмечается, что что делать с повторяющимися ACK после сработал таймер повторной передачи — это будущая работа и явно не указано в этом документе. Первоначальные требования к окну были изменены, чтобы разрешить большее начальное Windows в соответствии со стандартом [RFC3390].Кроме того, шаги к принимать, когда обнаруживается, что начальное окно слишком велико из-за пути Обнаружение MTU [RFC1191] подробно описано. Рекомендуемое начальное значение ssthresh было изменено на что он ДОЛЖЕН быть произвольно высоким там, где он был ранее МОЖЕТ. Это служит дополнительным руководством для разработчиков по данному вопросу. При медленном запуске использование соответствующего подсчета байтов [RFC3465] с L = 1 * SMSS явно рекомендуется. Метод увеличения cwnd, указанный в [RFC2581], по-прежнему явно разрешен.Подсчет байтов во время заторов также рекомендуется избегать, в то время как метод из [RFC2581] и другие безопасные методы все еще разрешены. Уточнена обработка ssthresh при тайм-ауте повторной передачи. В частности, ssthresh должен быть установлен на половину FlightSize на первая повторная передача данного сегмента, а затем постоянная последующие повторные передачи того же сегмента. Описание быстрой повторной передачи и быстрого восстановления было уточнены, и использование ограниченной передачи [RFC3042] теперь рекомендуемые.TCP теперь МОЖЕТ ограничить количество дублирующихся ACK, которые искусственно раздуть cwnd при восстановлении потерь до количества сегментов выдающийся, чтобы избежать атаки с дублированием спуфинга ACK, описанной в [SCWA99]. Окно перезапуска изменено с IW на min (IW, cwnd). Этот поведение было описано как «экспериментальное» в [RFC2581]. В настоящее время рекомендуется, чтобы разработчики TCP реализовали расширенный алгоритм восстановления потерь, соответствующий принципам, изложенным в данном документ.Allman и др. Стандарты Track [Страница 14] RFC 5681 TCP Congestion Control, сентябрь 2009 г. Вопросы безопасности были обновлены, чтобы обсудить разделение ACK. и рекомендую подсчет байтов в качестве противодействия этой атаке. 8. Благодарности Основные алгоритмы, которые мы описываем, были разработаны Ван Якобсоном. [Jac88, Jac90]. Кроме того, ограниченная передача [RFC3042] была разработан совместно с Хари Балакришнаном и Салли Флойд.В начальный размер окна перегрузки, указанный в этом документе, является результатом работы с Салли Флойд и Крейгом Партриджем [RFC2414, RFC3390]. В. Ричард («Богатый») Стивенс написал первую версию этого документа. [RFC2001] и является соавтором второй версии [RFC2581]. Это настоящее версия очень выигрывает от его ясности и вдумчивости описание, и мы благодарны Рича за вклад в разъяснение контроля перегрузки TCP, а также в более широком смысле помогая нам разобраться во многих вопросах, связанных с сетями.Мы хотим подчеркнуть, что недостатки и ошибки этого за документ несут полную ответственность текущие авторы. Часть текста из этого документа взята из «TCP / IP Иллюстрированный, Том 1: Протоколы »У. Ричарда Стивенса (Addison-Wesley, 1994) и «TCP / IP Illustrated, том 2: The Реализация »Гэри Р. Райта и У. Ричарда Стивенса (Аддисон- Уэсли, 1995). Этот материал использован с разрешения Эддисон-Уэсли. Анил Агарвал, Стив Арден, Нил Кардуэлл, Норитоши Демизу, Горри Фэрхерст, Кевин Фолл, Джон Хеффнер, Альфред Хёнс, Салли Флойд, Райнер Людвиг, Мэтт Матис, Крейг Партридж и Джо Тач внес ряд полезных предложений.9. Ссылки 9.1. Нормативные ссылки [RFC793] Постел, Дж., «Протокол управления передачей», STD 7, RFC 793, сентябрь 1981 г. [RFC1122] Braden, R., Ed., «Требования к Интернет-хостам — Уровни связи », STD 3, RFC 1122, октябрь 1989 г. [RFC1191] Могул, Дж. И С. Диринг, «Обнаружение MTU пути», RFC 1191, Ноябрь 1990 г. [RFC2119] Брэднер, С., «Ключевые слова для использования в RFC для обозначения Уровни требований », BCP 14, RFC 2119, март 1997 г.Allman и др. Стандарты Track [Страница 15] RFC 5681 TCP Congestion Control, сентябрь 2009 г. 9.2. Информативные ссылки [CJ89] Чиу, Д. и Р. Джайн, «Анализ увеличения / уменьшения Алгоритмы предотвращения перегрузки в компьютерных сетях », Журнал компьютерных сетей и систем ISDN, вып. 17, нет. 1, стр. 1-14, июнь 1989 г. [FF96] Фолл, К. и С. Флойд, «Сравнения на основе моделирования Тахо, Рино и SACK TCP », Обзор компьютерных коммуникаций, Июль 1996 г., ftp: // ftp.ee.lbl.gov/papers/sacks.ps.Z. [Hoe96] Hoe, J., «Улучшение поведения при запуске в условиях перегрузки» Схема управления для TCP », В ACM SIGCOMM, август 1996 г. [HTH98] Хьюз, А., Тач, Дж., И Дж. Хайдеманн, «Проблемы TCP Медленный перезапуск после простоя «, Работа в процессе, март 1998 г. [Jac88] Якобсон, В., «Предотвращение перегрузки и контроль», Компьютер. Коммуникационное обозрение, т. 18, нет. 4, стр. 314-329, авг. 1988. ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z. [Jac90] Якобсон, В., «Избегание модифицированной перегрузки TCP Алгоритм «, список рассылки end2end-Interest, 30 апреля 1990 г. ftp://ftp.isi.edu/end2end/end2end-interest-1990.mail. [MM96a] Матис, М. и Дж. Махдави, «Прямое подтверждение: Уточнение контроля перегрузки TCP », Труды SIGCOMM’96, август 1996 г., Стэнфорд, Калифорния. Доступна с http://www.psc.edu/networking/papers/papers.html [MM96b] Матис, М.и Дж. Махдави, «Снижение скорости TCP вдвое с ограничением Параметры », Технический отчет. Доступен с http://www.psc.edu/networking/papers/FACKnotes/current. [Pax97] Паксон В., «Динамика сквозных интернет-пакетов», Труды SIGCOMM ’97, Канны, Франция, сентябрь 1997 г. [RFC813] Кларк Д., «Окно и стратегия подтверждения в TCP», RFC 813, июль 1982 г. [RFC2001] Стивенс, В., «Медленный запуск TCP, предотвращение перегрузки, быстрый Алгоритмы ретрансляции и быстрого восстановления », RFC 2001, Январь 1997 г.[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, «TCP Варианты выборочного подтверждения «, RFC 2018, октябрь 1996 г. Allman и др. Стандарты Track [стр. 16] RFC 5681 TCP Congestion Control, сентябрь 2009 г. [RFC2414] Оллман, М., Флойд, С., и К. Партридж, «Увеличение числа TCP Начальное окно », RFC 2414, сентябрь 1998 г. [RFC2525] Паксон, В., Оллман, М., Доусон, С., Феннер, В., Гринер, Дж., Небеса, I., Lahey, K., Semke, J., and B. Volz, «Known TCP Проблемы реализации », RFC 2525, март 1999 г. [RFC2581] Оллман, М., Паксон, В., и У. Стивенс, «Перегрузка TCP. Control », RFC 2581, апрель 1999 г. [RFC2883] Флойд, С., Махдави, Дж., Матис, М., и М. Подольски, «An Расширение опции выборочного подтверждения (SACK) для TCP », RFC 2883, июль 2000 г. [RFC2988] Паксон В. и М. Оллман, «Вычисление повторной передачи TCP Таймер », RFC 2988, ноябрь 2000 г.[RFC3042] Оллман, М., Балакришнан, Х., и С. Флойд, «Улучшение Восстановление потерь TCP с использованием ограниченной передачи », RFC 3042, Январь 2001 г. [RFC3168] Рамакришнан, К., Флойд, С., и Д. Блэк, «Добавление Явное уведомление о перегрузке (ECN) для IP «, RFC 3168, Сентябрь 2001 г. [RFC3390] Оллман, М., Флойд, С., и К. Партридж, «Увеличение TCP Начальное окно », RFC 3390, октябрь 2002 г. [RFC3465] Оллман М., «Контроль перегрузки TCP с помощью соответствующего байта. Counting (ABC) », RFC 3465, февраль 2003 г.[RFC3517] Блэнтон, Э., Оллман, М., Фолл, К., и Л. Ван, «A Потеря на основе консервативного выборочного подтверждения (SACK) Алгоритм восстановления для TCP », RFC 3517, апрель 2003 г. [RFC3782] Флойд, С., Хендерсон, Т., и А. Гуртов, «The NewReno Модификация алгоритма быстрого восстановления TCP », RFC 3782, Апрель 2004 г. [RFC4821] Mathis, M. и J. Heffner, «MTU пути уровня пакетирования Discovery », RFC 4821, март 2007 г. [SCWA99] Сэвидж, С., Кардуэлл, Н., Ветералл, Д., и Т. Андерсон, «Контроль перегрузки TCP с помощью неправильно работающего получателя», ACM Computer Communication Review, 29 (5), октябрь 1999 г. [Ste94] Стивенс, В., «TCP / IP Illustrated, Том 1: Протоколы», Аддисон-Уэсли, 1994. Allman и др. Стандарты Track [стр. 17] RFC 5681 TCP Congestion Control, сентябрь 2009 г. [WS95] Райт, Г. и У. Стивенс, «Иллюстрированный протокол TCP / IP, том 2: Реализация «, Addison-Wesley, 1995.Адреса авторов Марк Оллман Международный институт компьютерных наук (ICSI) 1947 Центральная улица Люкс 600 Беркли, Калифорния 94704-1198 Телефон: +1440235 1792 Электронная почта: [email protected] http://www.icir.org/mallman/ Верн Паксон Международный институт компьютерных наук (ICSI) 1947 Центральная улица Люкс 600 Беркли, Калифорния 94704-1198 Телефон: +1 510 / 642-4274 x302 Электронная почта: [email protected] http://www.icir.org/vern/ Итан Блэнтон Университет Пердью Компьютерные науки 305 North University Street West Lafayette, IN 47907 Электронная почта: eblanton @ cs.Purdue.edu http://www.cs.purdue.edu/homes/eblanton/ Allman и др. Стандарты Track [стр. 18]

Потеря сетевых пакетов, повторные передачи и дублирующие подтверждения

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

Что вызывает потерю сетевых пакетов?

Две наиболее распространенные причины потери сетевых пакетов:

• Ошибки второго уровня (L2)
• и перегрузка сети

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

Перегрузка трафика может привести к сбоям ввода / вывода на интерфейсных ссылках, особенно при преобразовании между скоростями каналов (например, 10 Гбит / с на 1 Гбит / с). В этих подключениях исходящий канал может не справиться с объемом входящего трафика, что может привести к отбрасыванию пакетов. Отправитель трафика определит произошедшую потерю и осуществит повторную передачу. Обычно они помечаются как «отброшенные» на интерфейсах.

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

Потеря сетевых пакетов: справляемся ли мы с этим сегодня?

Да. Несмотря на зрелость сетевых каналов со скоростью 10 Гбит / с и выше, потеря пакетов по-прежнему является основным сетевым событием, которое влияет на приложения сегодня.Чтобы устранить эти проблемы, нам сначала нужно понять, как отбрасываются пакеты, как мы можем обнаруживать эти события и как мы можем их решить.

Повторная передача TCP

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

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

Заголовок TCP

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

TCP Дублированные / выборочные подтверждения

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

Дублирующие / выборочные подтверждения TCP

Как это происходит?

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

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

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

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

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

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

Заключение

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

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

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

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

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

Fine-Grained Failover с использованием миграции подключения

Fine-Grained Failover с использованием миграции Connection Migration

Алекс С. Снерен, Дэвид Г. Андерсен и Хари Балакришнан

Лаборатория компьютерных наук Массачусетского технологического института
Кембридж, Массачусетс 02139
{snoeren, dga, hari}@lcs.mit.edu

Абстрактные

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

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

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

Эффективный способ разработать надежную систему из ненадежных компоненты должны использовать избыточность в той или иной форме, а репликация сервера это способ предоставления надежных и доступных услуг на Интернет сегодня. Поскольку большинство веб-соединений длятся относительно недолго периоды времени, проблемы балансировки нагрузки клиентских запросов и восстановление с недоступных серверов-реплик обычно выполняется на степень детализации полного соединения.Действительно, это подход, наблюдаемый в нескольких текущих системах, которые выполняют выбор сервера с использованием интерфейсного транспортного или прикладного уровня переключатель [2,6,11,18,20], или использование глобальной репликации для распространения веб-контента [1,8].

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

Мы разработали и внедрили систему, которая обеспечивает мелкозернистую, аварийное переключение на уровне соединения как на локальном, так и на глобальном сервере реплики, без — интерфейсный транспортный или прикладной уровень выключатель. Таким образом, нет единых точек отказа или потенциальных интерфейсные узкие места в нашей архитектуре. Мы достигаем этого, используя протокол синхронизации сеанса с мягким состоянием между репликой серверов, в сочетании с механизмом возобновления соединения, включенным недавно разработанные механизмы сквозной миграции соединений для транспортных протоколов, таких как TCP [22] и SCTP [25].Конечный результат — надежный, быстрый и детализированный механизм аварийного переключения серверов, который прозрачен для клиентское приложение и в значительной степени не зависит от сервера Приложения. Приложения, которые могут извлечь из этого пользу, включают длительные TCP-соединения (например, HTTP, FTP-передачи), Интернет телефонии и потокового мультимедиа, что позволяет им достичь отказоустойчивость ».

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

Мы обсуждаем несколько вопросов, связанных с проектированием аварийного переключения соединения. механизм в разделе 2. Раздел 3 описывает сквозная архитектура для точного переключения серверов при отказе при длительных переводах. Наша реализация Linux на основе TCP: описано в разделе 4. Раздел 5 содержит исследования производительности, показывающие эффективность аварийного переключения механизм и его устойчивость к недостаткам в мониторинге здоровья подсистема.Мы завершаем синопсисом связанных работ в раздел 6 и суммируйте наш вклад в Раздел 7.

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

(i)

Для любого незавершенного соединения метод определения того, когда (и если) переместить его на другой сервер;

(ii)

процесс выбора для определения набора новых серверов кандидаты; и

(iii)

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

2.1 Мониторинг здоровья

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

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

В этой статье внимание уделяется не новым механизмам нагрузки или работоспособности. мониторинг; вместо этого мы используем соответствующую работу, которая уже была сделано в этой области [3,12,17]. Для целей данной статьи мы предполагаем, что каждый сервер в группа поддержки получает уведомление о сбое сервера всеведущим монитором в то же время. Как экспериментальные результаты в разделе 5 продемонстрировать, однако, наша система позволяет контролировать состояние компонент должен быть относительно простым — и даже чрезмерно реактивный — без существенного снижения производительности.

2.2 Выбор сервера

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

2.3 Перенос и возобновление подключения

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

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

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

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

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

Протокол распределения состояний периодически распространяется по каждому соединение, отображение между состоянием транспортного уровня и объект уровня приложения, отправляемый клиенту (например, TCP порядковый номер и URL-адрес HTTP). В оставшейся части статьи мы будет использовать термин отображение потока для описания задачи перевод конкретной информации о последовательности транспортного уровня в объектные ссылки уровня приложения, понятные серверу. В Состояние транспортного уровня перемещается на новый сервер с использованием защищенного механизм миграции соединения [22].Вместе описанные выше методы позволяют правильно синхронизировать состояние как транспортного уровня, так и приложения, прозрачное для клиента заявление

Рисунок 1: Архитектура аварийного переключения для поддержки группа из двух серверов.

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

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

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

3.1 Группы поддержки

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

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

Ясно, что выбор живого начального сервера очень важен, и большая часть предыдущей работы касалась методов выбора подходящих серверов в широкой области.Хорошие серверы можно определить с помощью BGP метрики [5], карты сети [1] или метрики для конкретных приложений. Точно так же клиентов можно направить на эти серверы используют перенаправление DNS [1], HTTP перенаправление, объявления BGP или anycast [9]. Поскольку наша архитектура позволяет передавать соединения любому другой сервер в любой точке соединения, последствия плохой первоначальный отбор не так серьезен, как в существующих схемах.

Мы строим группы поддержки, генерируя хорошо известный хеш IP-адрес сервера.Установив количество хэш-блоков равным n, серверы равномерно распределены в одну из n групп поддержки. Этот механизм позволяет динамически добавлять и удалять серверы из пула серверов. Когда каждый сервер подключается к сети, он вычисляет хэш адреса интерфейса, а затем начинает рекламировать свой подключения к известному многоадресному адресу для этого хэша значение ³ . Каждый сервер в группе поддержки становится кандидатом на сервер для подключений с нового сервера сразу после получения первого рекламное объявление.Точно так же новый сервер начинает слушать рекламные объявления отправляются на адрес группы, и становится кандидатом сервер для любых соединений, объявленных после его группы членство ⁴ .

Выбор членства в группе поддержки и конечный сервер, который обрабатывает неудавшийся клиент должен быть спроектирован таким образом, чтобы избежать проблема « взрыва сервера », когда все клиенты из отказавшего сервера сходятся на том же сервере замены. Мы предоставляем два механизмы для поддержки предотвращения имплозии.Первый — это инженерный выбор: путем выбора меньшего размера группы поддержки (г членов на группу поддержки из n серверов), мы можем ограничить с высокой вероятностью ожидаемое количество клиентов, которые сходятся на конкретный сервер к O (g / n) части клиентов из мертвых сервер. Второй — задержка возобновления подключения на коэффициент зависимости от нагрузки на каждом сервере, увеличивая вероятность клиент обслуживается менее загруженным сервером. Мы оцениваем эту технику в разделе 5.

3.2 Синхронизация с мягким состоянием

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

Информация о состоянии для конкретного соединения может быть недоступна. на некоторых серверах в группе поддержки, потому что соединение не еще не было объявлено, или потому что все периодические объявления были потерял. Первый режим отказа влияет только на небольшое окно новых соединения, и может быть замаскирован как начальное установление соединения отказ.Мы предполагаем, что соединения являются длительными, поэтому второй режим отказа необходимо защищать более тщательно. Если хотя бы один сервер в группе поддержки имеет информацию о подключении, это может быть восстановлен. Поэтому нам нужно только оценить вероятность что ни у одного сервера нет свежей информации о подключении. Достаточно выбрать подходящую частоту показа рекламы и размер группы поддержки (см., например, анализ аналогичного протокола Raman et al. al. [19]), следовательно, можно добиться достаточная надежность в нашем протоколе синхронизации с заметно меньшая сложность, чем строго согласованный механизм.

3.3 Миграция соединения транспортного уровня

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

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

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

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

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

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

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

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

3.3.1 Требования к протоколу для миграции

Наша архитектура принципиально требует возможности миграции транспортное сообщение. Хотя сегодня это не так широко, мы считают, что эта возможность — мощный способ поддержать оба балансировка нагрузки и мобильность хоста, и могут быть развернуты постепенно, обратно совместимые расширения для протоколов, таких как TCP [22] и как неотъемлемая функция новых протоколов, таких как Stream Control Транспортный протокол (SCTP) [25].

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

3.3.2 Миграция TCP

Хотя это не стандартная функция TCP, были предложены расширения для поддержка миграции подключения, включая недавно предложенный TCP Параметры миграции [22,23]. Используя эти параметры, соответствующие хосты могут сохранять TCP-соединения по адресу изменяется путем создания общего локального токена подключения для каждого связь.Любой партнер может согласовать миграцию на новый адрес с помощью отправка специального сегмента Migrate SYN, содержащего токен предыдущее соединение с нового адреса. Мигрирующий хост не необходимо знать IP-адреса своих новых точек подключения в продвигать.

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

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

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

Разрешая Migrate SYN выходить за пределы текущей последовательности космическое окно, однако злоумышленнику не нужно знать текущий пространство последовательности соединения, чтобы захватить его. Следовательно, в нашем расширенном модели, только защищенный вариант параметров миграции предоставляет защита от перехвата злоумышленником. Защищенная форма Параметры миграции используют обмен ключами Диффи-Хеллмана с эллиптической кривой во время первоначального трехстороннего рукопожатия для согласования криптографически безопасный ключ подключения.Безопасная миграция SYN должна быть криптографически аутентифицирован с использованием этого ключа, следовательно, злоумышленник без знания ключа подключения невозможно перехватить соединение независимо от текущего пространства последовательности.

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

В общем, хост не может определить разницу между Migrate SYN выдается исходным хостом (с нового адреса), который просто не смог получить некоторое количество ACK и новую конечную точку. Поэтому мы оставляем за собой один бит из Migrate SYN для отметки прихода запроса на миграцию от хоста, отличного от того, который инициировал соединение [23].Это позволяет переносить TCP-соединения с помощью один и тот же хост, чтобы избежать негативных последствий для производительности отбрасывание вышедших из строя сегментов при обеспечении правильной работы в лицо смены конечного хоста.

3.3.3 Миграция SCTP

Недавние исследования в области сигнализации IP-телефонии стимулировали разработку новый транспортный протокол транспортной областью IETF (Интернет Инженерная рабочая группа). Предлагаемый стандарт Stream Control Транспортный протокол (SCTP) обеспечивает преимущества перед TCP для подключения к многодомным хостам [25].Рекламируя набор IP-адресов во время установления соединения, многосетевой SCTP соединение поддерживает передачу и получение данных на нескольких интерфейсы. Мы можем использовать эту возможность для поддержки подключения миграция между разными серверами.

Однако, в отличие от параметров TCP Migrate, все адреса, которые будут использоваться для соединение SCTP должно быть указано при установлении соединения. Ограничивая уровень динамизма в пуле серверов, он по-прежнему поддерживает аварийное переключение между серверами, которые были известны первоначальному сервер во время установления соединения.Недавний Интернет В проекте [26] предпринимается попытка решить эту проблему, допуская динамическое добавление и удаление IP-адресов из ассоциации, хотя она требует, чтобы операции были инициированы конечная точка уже в ассоциации. Кроме того, SCTP был предназначен для поддержки многосетевых хостов, а не для изменения адреса, следовательно, он не поддерживает семантику не более одного раза, необходимую для разрешения несколько серверов для одновременной попытки переноса связь. Мы считаем, что это недостаток SCTP, который может быть адресуются одновременно, добавляя поддержку динамических изменений в адресные ассоциации.

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

3.4 Ограничения

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

Независимо от проблем на транспортном и сетевом уровнях, которыми занимается наш архитектура, определенные приложения могут пытаться принудительно применять семантику которые нарушаются при смене сервера; очевидно, что такие приложения не могут обращаться с ними прозрачно.В частности, объект обслуживаемый, возможно, изменился с момента открытия соединения, приводит к неопределенному поведению, если приложение не знает о это. Далее некоторые приложения принимают решения при подключении создание на основе состояния сервера или времени, и не обычно продолжают пересматривать эти условия. Например, текущие приложения могут принимать решения об авторизации на основе IP адрес его исходного однорангового узла, HTTP cookie или клиентский сертификат срок действия которого истек.Такие приложения могут быть уведомлены о однако миграция соединения с помощью преобразователя потоков и разрешена выполнить все необходимые шаги для повторной синхронизации перед возобновлением коробка передач.

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

Наша текущая реализация прототипа поддерживает приложения TCP, использующие Параметры миграции [22,23]. Мягкое состояние механизм распределения и функция отображения потоков реализован как клин , который работает на сервере и прокси подключения для локального контент-сервера.Наша текущая реализация использует Apache 1.3 и совместим с любым программным обеспечением веб-серверов, поддерживает запросы диапазона HTTP / 1.1. Возможна оптимизация производительность путем передачи TCP-ретрансляции ядру после параметры запроса были определены аналогично MSOCKS [14].

4.1 Клин

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

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

Фигура 2: Клин, обрабатывающий новое соединение (слева) и переход на существующее соединение (справа).

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

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

IP-адрес клиента и номер порта.

Порядковый номер приемки.

Поля TCP Migrate (токен подключения, ключ и т. Д.).

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

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

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

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

4.1.1 Распространение информации через мягкое состояние

Обновления информации о мягком состоянии отправляются каждые UPDATE_SEC. секунд, срок действия истек с удаленных серверов после CACHE_TIMEOUT секунд. Правильные значения этих параметров зависят от нескольких факторы [19]: длина соединения, коэффициент потери пакетов между серверами и частота подключения. Наши значения по умолчанию для это частота обновления в три секунды и период ожидания 10 секунд, что приводит к приемлемой частоте обновления, когда обслуживание типичных соединений потокового мультимедиа без ненадлежащего состояния накладные расходы на распространение.Оптимальные значения для этих цифр будут, конечно, варьируются от сайта к сайту.

4.1.2 Постоянные соединения

Наша реализация клина в настоящее время не поддерживает постоянные соединений, но можно было сделать это с незначительными изменениями. Клин потребуется постоянно контролировать клиентскую сторону соединения (вместо того, чтобы слепо передавать соединение соединителю) и смотреть для дальнейших запросов объекта. Когда он получает новый запрос, wedge начал бы объявлять об этом через распределение мягких состояний протокол.Использование методов постоянного подключения LARD обработчик [4], стыковка все еще может выполняться быстро ретрансляция массовых данных с сервера клиенту. На сервере реализация протокола распространения мягкого состояния будет Конечно устраняет эту необходимость.

4.2 Интерфейс разъема

Чтобы новый сервер мог обрабатывать перенесенное соединение, клин должен предварительно загрузить в сокет достаточную транспортную информацию. И наоборот, эта информация должна быть извлечена из сокета на предыдущий сервер и подключился к новому серверу.У нас есть реализованы два новых системных вызова: setsockstate (), и . getsockstate () , чтобы обеспечить эту функциональность.

Вызов getsockstate () объединяет контрольный блок TCP в существующий сокет TCP, в то время как вызов setsockstate () вводит этот информация в неподключенный сокет TCP. Только определенные части блок управления, однако, имеет значение, например, пространство последовательности информация, параметры TCP и любые параметры, заданные пользователем, такие как Зажим MTU.Другое, непереносимое состояние, такое как очередь на повторную передачу, таймеры и окно перегрузки возвращаются функцией getsockstate () , но не устанавливается в новый сокет с помощью setsockstate () . Вызов системного вызова connect () приведет к тому, что сокет будет попытаться перенести соединение (как указано в предварительно загруженном состояние) к новому сокету.

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

4.3 Миграция

На рисунке 3 представлена ​​трассировка tcpdump событие аварийного переключения, собираемое на клиенте. В этом Пример: клиент cl и три сервера sA, sB и sC. К имитировать разнообразный набор реалистичных сетевых условий, серверы маршрутизируются по отдельным каналам DummyNet [21] с время приема-передачи примерно 10 мс, 40 мс и 200 мс соответственно. Каждый канал имеет пропускную способность 128 Кбайт в секунду. Первоначально клиент получает объект из sA.Через некоторое время время, ошибочная констатация смерти одновременно доставляется серверов с помощью смоделированного монитора работоспособности, который объявляет sA мертвым. Этот объявление получено серверами примерно через 0,073 секунды (не показано).

Передача исходных данных:

0,00000 класс 1065> sA .8080:. ack 0505 выигрыш 31856
———— (ошибочно) sA Сообщение о смерти ————
0,08014 sA .8080> cl.1065: P 0505: 1953 (1448) ack 1 win 31856

Успешный переход на соединение с SB:

0,09515 sB .1033> cl.1065: S 0: 0 (0) выигрыш 0 <миграция PRELOAD 1>
0,09583 cl.1065> sB .1033: S 0: 0 (0) ack 1953 win 32120
0,14244 SB .1033> класс 1065:. подтверждение 1 выигрыш 32120

Продолжение передачи данных от sA:

0,17370 sA .8080> cl.1065: P 0505: 1953 (1448) ack 1 win 31856
0.17376 cl.1065> sA .8080: R 1: 1 (0) выигрыш 0

Неудачная попытка миграции подключения, совершенная sC:

0,17423 sC .1499> cl.1065: S 0: 0 (0) выигрыш 0 <миграция PRELOAD 1>
0,17450 класс 1065> sC .1499: R 0: 0 (0) ack 1 win 0

Возобновлена ​​передача данных от SB:

0.24073 SB .1033> cl.1065: P 1953: 3413 (1460) ack 1 win 32120
0,25663 класс 1065> SB .1033:. ack 3413 выиграть 31856
0,33430 SB .1033> cl.1065: P 3413: 4873 (1460) ack 1 win 32120
0,42776 SB .1033> класс 1065: P 4873: 6333 (1460) ack 1 win 32120
0,42784 класс 1065> SB .1033:. ack 6333 победа 31856

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

Как показано на рисунке 3, каждый из других серверов в группа поддержки немедленно пытается перенести соединение.Из-за их несопоставимые задержки пути, Migrate SYNs прибывают в разные раз. При задержке пути всего 20 мс Migrate SYN из sB прибывает первым и принимается клиентом.

Следующий участок трассировки показывает надежность нашей схемы в лицо ошибочных заявлений о смерти. Предыдущая смоделированная объявление монитора работоспособности было ошибочным; СА на самом деле все еще оперативный. Кроме того, есть несколько выдающихся неподтвержденные сегменты данных (включая сегмент, видимый на трассе) в момент времени 0.08014), так как клиент больше не отправляет ACK в sA как только он перешел на SB. Следовательно, время ожидания sA истекает и повторно передает самый последний сегмент данных. Клиент отвечает отправкой RST сегмент, сообщая СА, что он больше не заинтересован в получении трансмиссии. (Остальные повторные передачи и соответствующие RST не показаны для ясности.)

Продолжая, мы видим, что Migrate SYN от другого кандидата сервер, sC наконец прибывает примерно через 100 мс после смерти объявление.Поскольку номер запроса на миграцию (1) идентичен ранее полученный Migrate SYN, клиент отклоняет запрос. Обратите внимание, что если sB умер, и этот Migrate SYN был попыткой sC далее возобновить соединение, номер запроса был бы увеличивается.

Последняя часть графика показывает возобновленную передачу данных, продолжается с последнего непрерывного сегмента полученных данных (как указывается в SYN / ACK, отправленном клиентом). Поскольку путь от клиент к sB, вероятно, отличается от пути к sA, TCP состояние перегрузки сбрасывается, и соединение запускается медленно.

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

5.1 Стабильность сервера

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

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

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

Рисунок 4: Трассы ACK подключения для различные скорости колебаний сервера.

Хотя следы и точные числа, которые мы представляем, относятся к нашей ссылке параметры, они иллюстрируют три важных взаимодействия. Первый интуитивно понятен: чем больше времени между событиями смены сервера, тем выше пропускная способность, потому что меньше сбоев. Этот объясняет общую тенденцию к снижению и уменьшение величины « неровности » на рисунке 5. Второй эффект — за счет увеличения окна при медленном старте; если миграции происходят раньше пропускная способность канала используется полностью, пропускная способность снижается резко, потому что соединение всегда недостаточно использует ссылку.Это происходит при периодах колебаний менее трех секунд в Рисунок 5. Третье взаимодействие происходит, когда миграция происходит во время восстановления потери TCP, либо из-за медленного запуска, либо предотвращение перегрузки. В данном случае модель go-back-n политика ретрансляции во время миграции принудительно устанавливает соединение с отказаться от уже полученных данных. Это взаимодействие объясняет периодический « неровности » на рисунке 5 и обсуждается в более подробности ниже.

Рисунок 5: Время загрузки vs.колебание тарифы. Соединение, полностью обслуживаемое одним сервером, занимает 61,96 секунды. завершить.

Рисунок 6: Последовательность следов колебательного миграционного поведения.

Чтобы проиллюстрировать взаимодействие медленного запуска и восстановления после потери, На рисунке 6 исследуются трассы последовательности для интервала от 35 до 40 секунд подключений, подверженных 2 и 5 секундам колебания. Через 2 секунды соединения все еще наращивают свои размеры окон и потерь не понесли.Через 5 секунд соединения испытывают множественные потери, поскольку медленный запуск начинает переполнить буфер в узком месте. Четыре ретрансляции могут быть считается успешно полученным, пятый, к сожалению, прибывает сразу после Migrate SYN с нового сервера. Поскольку оставшиеся данные не являются смежными, они сбрасываются на приемнике в в соответствии с политикой go-back-n , и повторная передача возобновляется существенно раньше. Подобные взаимодействия потерь отображаются как регулярные паузы на рисунке 4.Независимо от точного период взаимодействия, накладные расходы на переключение сервера для реалистичного процент отказов довольно низок.

5.2 Накладные расходы

Рисунок 7: Накладные расходы на запрос клин как функция размера запроса.

Микро-бенчмарки времени выполнения запроса для выгруженного сервера показаны на рисунке 7. Накладные расходы связанный с обработкой клина становится незначительным, поскольку размер запроса увеличивается до длительных, больших сеансов, для которых наша схема разработан.Воздействие колеблется от дополнительной 1 мс на запрос (80% накладные расходы) для запросов размером 1 КБайт до 12 мс (1%) для запросов 8 МБ.

Накладные расходы на загрузку клина возникают из-за нашего простого сращивания TCP выполнение; мы не приводим здесь его оценку. В методы с использованием ядра, упомянутые в разделе 4 или Методы соединения TCP, описанные Коэном, Рангараджаном и Slye [7] может устранить большую часть накладных расходов на обработку TCP, но не накладные расходы на установление соединения; на сервере реализация может устранить почти все накладные расходы.

5.3 Имплозия

Чтобы изучить степень, в которой выбор сервера зависит от задержки. затронуло взрыв сервера, мы смоделировали 10 000 клиентов, обслуживаемых 10 серверы. (Другое количество клиентов и серверов было почти одинаковым полученные результаты). Клиенты и серверы были размещены на случайной двумерной сетке. изобразить расстояние между ними; возможные задержки варьировались от От 0 мс до 250 мс.

Сначала мы протестировали два глобальных метода. Optimal caps server загрузка 1400 клиентов и глобальная минимальная задержка назначение на серверы. Round-Robin гарантирует, что клиенты равномерно распределены между (фактически случайными) серверами. Далее мы смоделировал три распределенных метода. Distance использует только метрика расстояния для назначения серверов. Случайно выбирает серверы чисто случайно из группы отказов. Backoff использует экспоненциальная отсрочка, основанная на количестве клиентов, размещенных в сервер и количество выдающихся « предложений ».

Метод	Сред.Задержка	Сред. Максимальное количество клиентов
Расстояние	34 мс	2146
Оптимальный	38 мс	1399
Отвод	67 мс	905 905 905 905 905 905 905 905 905 905 905 905 905 905 905
Случайно	94 мс	1160

Таблица 1: Расстояния моделирования и узел с большинством клиентов для разные методы выбора сервера.

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

Устройства перенаправления запросов могут выполнять балансировку нагрузки для каждого соединения, но добиться лучшей производительности и гибкости, если они маршрутизируют запросы на основе содержимого запроса.Многие коммерчески доступные веб-коммутаторы обеспечивают запрос на основе содержимого перенаправление [2,6,11,18] пользователем завершение TCP-соединения клиента во внешнем перенаправителе. Этот перенаправитель интерпретирует объектный запрос аналогично наш клин, а затем передает запрос на соответствующий сервер. Однако в этой архитектуре перенаправитель должен оставаться на пути на время соединения, так как соединение с сервером должны быть соединены с клиентским соединением.

Оперативное перенаправление создает потенциальное узкое место в производительности, а преимущества Соединение TCP [7] и передача соединений напрямую конечные машины в кластере веб-серверов хорошо известны.Раздача механизмы были впервые исследованы Хантом, Наумом и Tracey [13], позже реализованный в LARD (Распределение запросов с учетом местоположения) [17]. LARD был недавно расширен [4] для поддержки запроса передача обслуживания между внутренними серверами для постоянного HTTP / 1.1 соединения [10]. Ключевой компонент LARD реализация — это механизм передачи обслуживания TCP, который позволяет балансировщик нагрузки для передачи подключения к внутренним серверам после решение о балансировке нагрузки было принято. Аналогичный функционал теперь может также можно найти в коммерческом продукте от Resonate [20].Хотя все три механизма прозрачны для клиента, каждый из них требует, чтобы соединение было активно передано передняя часть к внутреннему серверу. ⁷

Необходимость предыдущих методов для поддержания жесткого состояния соединения на клиентская часть позволила разработать системы Интернет-телефонии с надежность, эквивалентная нынешним технологиям с коммутацией каналов. трудно. Новая рабочая группа Reliable Server Pooling (Rserpool) имеет: недавно был сформирован IETF для изучения потребностей таких Приложения.Мы считаем, что наша архитектура учитывает многие из требования, изложенные в уставе рабочей группы [16] и описан в протоколе агрегированного доступа к серверу (ASAP) в Интернете. Проект [24].

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

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

Методы, описанные в этой статье, применимы к множеству системы, в дополнение к традиционному сквозному браузеру-серверу модель. Хотя наша архитектура не требует приложений или коммутаторы транспортного уровня для маршрутизации и мониторинга работоспособности, не исключаю их. Например, некоторые коммерческие продукты (например, Cisco LocalDirector [6]) предлагает использовать два совместно расположенных веб-сервера. переключатели для резервирования.При использовании в длительных соединениях наше решение позволяет легко переносить существующие подключения между несколькими веб-коммутаторами без снижения производительности.

Наш исходный код доступен (под GPL) по адресу http://nms.lcs.mit.edu/software/migrate/.

Список литературы

[1]

Akamai Technologies, Inc. http://www.akamai.com.

[2]

Веб-системы Alteon. Веб-коммутация 7-го уровня. http: //www.alteonwebsystems.ru / products / whitepapers / layer7switching.

[3]

Э. Амир, С. Макканн и Р. Кац. Активный сервисный фреймворк и его применение в реальном времени перекодирование мультимедиа. В Proc. ACM SIGCOMM ’98 , сентябрь 1998 г.

[4]

М. Арон, П. Друшель и В. Цваенепол. Эффективная поддержка P-HTTP на кластерных веб-серверах. В Proc. USENIX ’99 , июнь 1999 г.

[5]

Cisco Systems. Распределенный директор Cisco.http://www.cisco.com/warp/public/cc/pd/cxsr/dd/tech/dd_wp.htm.

[6]

Cisco Systems. Конфигурация аварийного переключения для LocalDirector. http://www.cisco.com/warp/public/cc/pd/cxsr/400/tech/locdf_wp.htm.

[7]

А. Коэн, С. Рангараджан и Х. Слай. О производительности соединения TCP для перенаправления с учетом URL. В Proc. USITS ’99 , октябрь 1999 г.

[8]

Digital Island, Inc. Домашняя страница Digital Island, Inc. http: // www.digitalisland.net.

[9]

З. Фей, С. Бхаттачарджи, Э. В. Зегура и М. Аммар. Новый метод выбора сервера для уменьшения времени отклика реплицированная служба. В Proc. IEEE Infocom ’98 , март 1998 г.

[10]

Р. Филдинг, Дж. Геттис, Дж. Могул, Х. Фристик и Т. Бернерс-Ли. Протокол передачи гипертекста-HTTP / 1.1. RFC 2068, IETF, январь 1997 г.

[11]

Литейные сети. Коммутаторы ServerIron для управления интернет-трафиком.http://www.foundrynet.com/PDFs/ServerIron3_00.pdf.

[12]

А. Фокс, С. Гриббл, Ю. Чават и Э. Брюэр. Масштабируемые сетевые сервисы на основе кластеров. В Proc. ACM SOSP ’97 , октябрь 1997 г.

[13]

Дж. Хант, Э. Нахум и Дж. Трейси. Включение распределения нагрузки на основе содержимого для масштабируемых служб. Технический отчет, IBM T.J. Исследовательский центр Уотсона, май 1997 г.

[14]

Д. Мальц и П. Бхагват. MSOCKS: архитектура для мобильности транспортного уровня.В Proc. IEEE Infocom ’98 , март 1998 г.

[15]

М. Матис, Дж. Махдави, С. Флойд и А. Романов. Параметры выборочного подтверждения TCP. RFC 2018, IETF, октябрь 1996 г.

[16]

Л. Онг и М. Стиллман. Надежный пул серверов. Устав рабочей группы, IETF, декабрь 2000 г. http://www.ietf.org/html.charters/rserpool-charter.html.

[17]

В. С. Пай, М. Арон, Г. Банга, М. Свендсен, П. Друшель, В. Цваенепол и Э. Наум.Распределение запросов с учетом местоположения на кластерных сетевых серверах. В Proc. ASPLOS ’98 , октябрь 1998 г.

[18]

Radware. Директор веб-сервера. http://www.radware.com/archive/pdfs/products/WSD.pdf.

[19]

С. Раман и С. Макканн. Модель, анализ и структура протокола для мягких состояний на основе коммуникация. В Proc. ACM SIGCOMM ’99 , сентябрь 1999 г.

[20]

Резонировать. Central Dispatch 3.0 — Белая книга.http://www.resonate.com/products/pdf/WP_CD3.0___final.doc.pdf.

[21]

Л. Риццо. Dummynet и прямое исправление ошибок. В Proc. Freenix ’98 , июнь 1998 г.

[22]

А.С. Снерен и Х. Балакришнан. Сквозной подход к мобильности хоста. В Proc. ACM / IEEE Mobicom ’00 , страницы 155-166, август 2000 г.

[23]

А.С. Снерен и Х. Балакришнан. Миграция TCP-соединения. Интернет-проект, IETF, ноябрь.2000 г. draft-snoeren-tcp-migrate-00.txt (в стадии разработки).

[24]

Р. Р. Стюарт и К. Се. Агрегированный протокол доступа к серверу (ASAP). Интернет-проект, IETF, ноябрь 2000 г. draft-xie-rserpool-asap-01.txt (в стадии разработки).

[25]

Р. Р. Стюарт, К. Се, К. Морно, К. Шарп, Х. Дж. Шварцбауэр, Т. Тейлор, И. Ритина, М. Калла, Л. Чжан, В. Паксон. Протокол передачи управления потоком. RFC 2960, IETF, октябрь 2000 г.

[26]

Р.Р. Стюарт, К. Се, М. Туэксен, И. Ритина. SCTP динамическое добавление IP-адресов. Интернет-проект, IETF, ноябрь 2000 г. draft-stewart-addip-sctp-sigran-01.txt (в стадии разработки).

---

Сноски:

¹ Фактически это подмножество весь комплект; разделение набора на подмножества повышает масштабируемость.

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

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

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

⁵ Stream mapper не такой Устройство; скорее, это программный модуль, который позволяет серверу приложение для участия в протоколе синхронизации с мягким состоянием и механизм возобновления соединения.

⁶ Это поведение полностью соответствует SACK спецификация [15].

⁷ Внутренняя переадресация [4] позволяет различным серверам обрабатывать последующие запросы, но требует предыдущий сервер для пересылки содержимого (через интерфейс) обратно к клиенту.

Все о протоколе трехстороннего рукопожатия

By Jithin 4 июля, 2019

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

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

Что такое TCP и основные характеристики TCP

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

1) Ориентированный на соединение: TCP — это сервис, ориентированный на соединение, это означает, что все сегменты следуют по одному и тому же пути, и сегменты находятся в порядке доставки, соединение необходимо установить, прежде чем два устройства смогут обмениваться данными.Приложение запрашивает «соединение» с местом назначения и использует соединение для передачи данных.

2) Надежный: сам протокол проверяет, все ли переданное было доставлено на принимающей стороне.

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

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

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

6) Приложение запрашивает «соединение» с пунктом назначения и использует соединение для передачи данных

7) Возможность маршрутизации: TCP / IP — это протокол маршрутизации.

8) Это помогает в разрешении логического адреса.

9) Разрешение имени: помогает преобразовать удобочитаемое имя в IP-адрес.

10) Полный дуплекс: каждое TCP-соединение поддерживает пару байтовых потоков, по одному в каждом направлении.

Что такое квитирование TCP?

Процедура установления соединения между двумя узлами TCP / IP. Известен как рукопожатие синхронизации, синхронизации-подтверждения и подтверждения.Например, если компьютер A передает пакет Synchronize на компьютер B, который отправляет обратно пакет Synchronize-Acknowledge на компьютер A. Затем компьютер A передает пакет подтверждения на компьютер B, и соединение устанавливается. Весь вышеупомянутый процесс называется установлением связи TCP.

TCP — протоколы обмена информацией о состоянии

1) Протокол двустороннего рукопожатия

2) Протокол трехстороннего рукопожатия

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

TCP 3-сторонний процесс установления связи

Для установления соединения используется трехстороннее (или трехэтапное) рукопожатие:

Шаг 1 (SYN):

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

Шаг 2 (SYN + ACK):

В ответ сервер отвечает SYN-ACK, содержащим случайный порядковый номер и номер ACK, подтверждающий порядковый номер клиента. Номер подтверждения устанавливается на единицу больше, чем полученный порядковый номер, то есть X + 1, а порядковый номер, который сервер выбирает для пакета, представляет собой другое случайное число, Y.

Шаг 3 (ACK):

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

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

Как узнать, что TCP дублируется. Дубликат ПТС, то есть

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

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

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

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

И тут возникает вопрос — как себя обезопасить?

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

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

ПТС защита от фальсификации

Первое, на что следует обратить внимание, это сама форма TCP. Он производится на предприятиях Гознака и, как банкноты, имеет свои степени защиты (микротекст, водяные знаки и т. Д.)).

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

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

Заготовка

PTS должна быть хорошего качества. Его не следует «стирать» (иногда на паспорте таким образом уничтожают исходную информацию и печатают новую).К сведению: сотрудники ГИБДД почти никогда не используют лазерные принтеры для заполнения бланков ПТС.

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

И, конечно же, голограмму нельзя заклеивать «скотчем».

Глядя на оформление формы, вы должны увидеть что-то вроде этого.

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

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

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

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

А теперь точки:

1. Идентификационный номер (VIN)

Может быть, а может и не быть (на японских праворульных автомобилях, выпускаемых для внутреннего рынка, а также на старых отечественных автомобилях).VIN должен состоять из 17 символов. При отсутствии идентификационного номера в этом столбце обычно пишется слово «ОТСУТСТВУЕТ».

2. Марка, модель автомобиля.

Здесь все просто и понятно, у каждой машины своя торговая марка.

3. Название (тип ТС).

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

5. Год выпуска ТС

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

6. Модель, номер двигателя.

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

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

И все же на американских машинах номер двигателя все же существует. 🙂

7. Шасси (рама) №

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

8. Кузов (кабина, прицеп) №.

Обязательно проверьте. Остерегайтесь автомобилей с перекрашенными панелями кузова.

9. Цвет кузова (кабина, прицеп).

Не пугайтесь, если на нем написано «серый», и у вас металлический серебристый металлический автомобиль.

Пункты 10 — 15. Понятно без пояснений.

Артикул: 16. Страна-производитель ТС, 17.Утверждение типа транспортного средства, 18. Страна экспорта, 19. Серия, номер ТД, ТПО — на иномарку, ввезенную по всем правилам, заполняется всегда.

Пункт 20. Таможенные ограничения

Вот несколько вариантов заливки. Самый правильный: «ПЛАТЕЖИ ОПЛАТЫ, ДОПУСКАЕТСЯ» , другой вариант: «ТАМОЖЕННЫХ ОГРАНИЧЕНИЙ НЕТ» , ну самый распространенный (для отечественных автомобилей) — незаполненный товар.

До 2007 года на территории Калининградской области действовали таможенные льготы.В паспортах автомобилей с льготным «растаможиванием» указано: «Ввоз на другую часть ТАМОЖЕННОЙ ТЕРРИТОРИИ РОССИЙСКОЙ ФЕДЕРАЦИИ И ТАМОЖЕННОГО СОЮЗА РАЗРЕШЕН ПРИ ОПЛАТЕ ТАМОЖЕННЫХ И ДРУГИХ ПЛАТЕЖЕЙ». Такие автомобили могут эксплуатироваться только на территории Калининградской области.

Подведем итог: для официально ввезенного в Россию из-за границы ПТС автомобиль должен быть оформлен только на таможне. Кроме того, протокол TCP должен быть распечатан на компьютере (лазерные принтеры для заполнения форм TCP в настоящее время не используются), а не выписан вручную.Все пункты в паспорте должны быть заполнены, как указано выше.

Также обратите внимание на количество владельцев. Автомобиль не должен менять владельцев каждый месяц (если так, скорее всего, «заметали следы» ). Лучше, если иномарке в России уже больше полугода, тогда она точно (если угнали в Европе) находится в поисковой базе Интерпола.

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

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

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

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

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

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

Дубликат содержимого

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

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

Документ содержит данные об автомобиле и умещается в 24 столбца:

Марка

• ;
• номер VIN;
Модель
• ;
• тип кузова;
• спецификации;
• года выпуска;
• производитель и др.

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

Характерные отличия дубликата от оригинала:

1. Копия содержит отметку «дубликат», расположенную в левом углу документа.
2. Наносятся специальные водяные знаки.
3. Удивительно, но даже потрепанный документ может служить «доказательством» его легитимности. Если потрепанный, то часто используется.

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

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

• дубликат выдается только владельцу купленного автомобиля;
• утерянный оригинал не подлежит восстановлению;
• обновлена ​​информация о регистрации собственника.

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

Инструкция по получению дубликата

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

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

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

Сотрудники МРЭО проверяют автомобиль, составляя водителю дополнительный акт осмотра. Акт также прилагается к пакету документов. И обязательно заверить подписью официального рецензента. Кроме того, выдается новый сертификат с обновленными данными о транспортном средстве.

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

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

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

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

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

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

Какая информация содержится в TCP?

PTS состоит из 24 столбцов, в которых приводятся следующие сведения об автомобиле:

• VIN код автомобиля. Он состоит примерно из 17 цифр, которые должны совпадать с числами, расположенными на кузове автомобиля.
• Страна-производитель.
• Объем двигателя.
• Тип двигателя.
• Тип конструкции.
• Марка автомобиля.
• Год выпуска и тд.

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

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

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

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

Какие предварительные условия могут способствовать выдаче дубликата TCP?

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

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

Как выглядит дублированный TCP?

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

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

1. Сравнительно недавняя покупка и необъяснимо быстрая продажа.
2. Низкая стоимость.
3. Необоснованная срочность продажи.
4. Транзитные номера на автомобили.

На что следует обратить внимание, когда я сталкиваюсь с дублированием TCP?

• Большое количество автовладельцев.
• Продажа автомобиля происходит очень часто и с коротким интервалом (2-3 месяца).
• Марка, указывающая на причастность к уголовному делу автомобилей (например, дело о разбитых номерах).

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

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

Страница не найдена | MIT

Перейти к содержанию ↓

• Образование
• Исследование
• Инновации
• Прием + помощь
• Студенческая жизнь
• Новости
• Выпускников
• О MIT
• Подробнее ↓
  • Прием + помощь
  • Студенческая жизнь
  • Новости
  • Выпускников
  • О MIT

Меню ↓ Поиск Меню Ой, похоже, мы не смогли найти то, что вы искали!
Попробуйте поискать что-нибудь еще! Что вы ищете? Увидеть больше результатов

Предложения или отзывы?

.