20Авг

Что делать если в птс нет места: Что, если для нового владельца автомобиля нет места в ПТС?

Содержание

Закончился ПТС — нет места для новых записей, что делать?

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

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

Причины замены ПТС

Есть причины, которые требуют замены данного документа, и основные среди них это:

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

Что делать если в ПТС нет места

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

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

  1. Паспорт владельца ТС, который пишет заявление о необходимости замены ПТС. Если обратиться к Положению о ПТС, то там сказано, что заявителем может быть владелец машины или собственник.
  2. Предыдущий ПТС, в котором все пустые строки были заполнены нужно сдать в орган ГИБДД. Документ будет принимать должностное лицо, которое проведет его осмотр и сверку данных с электронной базой. Информация о машине, обозначенная в ПТС, в обязательном порядке должна совпадать с регистрационными данными ТС. При замене ПТС пристальное внимание будет уделено сведениям о номере кузова, цвете, дате, когда машина была изготовлена, номере двигателя. В разделе «Особые отметки» ПТС есть данные, и должностное лицо займется их сверкой. Это нужно сделать для того чтобы подтвердить подлинность предоставленного ПТС и идентифицировать машину. Когда проверка подойдет к концу, и данные будут подтверждены, старый паспорт подлежит уничтожению уполномоченным на данную процедуру органом.
  3. Заявление. При обращении в соответствующие органы должностные лица дадут вам типовой бланк. Заявление заполняется в одном экземпляре, и в нем нужно прописать просьбу о том, что старый ПТС требует замены. Уделите внимание заполнению данной бумаги, так как в ней запрещаются исправления, помарки, перечеркивание. Лишние цифры, буквы, запятые или прочие обозначения тоже под запретом. Если у вас есть сомнения в правильности заполнения заявления, рекомендуем раскошелиться, и передать эту заботу в руки специалиста, работающего в пункте регистрации.
  4. Чек, подтверждающий, что государственная пошлина за данную процедуру была уплачена.
  5. Документ, подтверждающий, что владельцем машины является заявитель. Понадобится иметь при себе правоустанавливающие документы. Это может быть договор купли-продажи ТС, в котором прописаны полные сведения о покупателе и продавце, идентификационные данные о машине. Документ должен быть скреплен личными подписями участников сделки. В договоре в обязательном порядке должна быть обозначена цена предмета договора. Если должностные лица регистрирующего органа во время проверки выявят несостыковки данных, то это может поставить под сомнение подлинность договора купли-продажи машины.
  6. Полис ОСАГО, так как машину не поставят на учет до того момента, пока владелец не посетит страховую компания для оформления страхования гражданской ответственности. Чтобы оформить страховку стало возможным, владелец обязан заранее пройти технический осмотр машины. Данную процедуру осуществляют органы ГИБДД.

Выдача дубликата ПТС вместо старого

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

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

Важные нюансы замены паспорта перед продажей транспортного средства

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

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

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

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

Что делать, если закончился ПТС (закончилось место)?

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

Необходимость ПТС

ПТС является важным юридическим документом, «характеризующим» автомобиль.
Он необходим для:

  1. упорядочения процедуры допуска транспорта к участию в дорожном движении;
  2. ужесточения контроля над ввозимыми в РФ автотранспортными средствами;
  3. повышения эффективности предотвращения краж и угонов автомобилей.

Причины замены паспорта

Среди главных оснований замены ПТС можно отметить:

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

Что делать, если в ПТС закончилось место?

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

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

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

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

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

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

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

Выдача дубликата ПТС взамен старого

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

Должностные лица указывают в новом ПТС серию предыдущего паспорта, а также фиксируют дату замены документа дубликатом.

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

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

Аспекты замены паспорта перед продажей машины

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

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

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

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

замена птс в связи с отсутствием свободного места

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

Значение ПТС

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

ПТС нужен для того, чтобы:

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

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

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

Как заменить ПТС, в котором нет места?

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

Таким образом вы сможете обезопасить себя от ошибок и сэкономить время.

Для замены потребуется ряд документов:

  • паспорт;
  • написанной заявление для замены документа;
  • старый образец ПТС;
  • ОСАГО;
  • документ с подтверждением права собственности.
  • квитанция по уплате.
Как выдается дубликат?

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

Перед продажей автомобиля

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

Важные аспекты

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

 

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

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

Что делать, если в ПТС нет места для нового владельца?

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

Когда разрешено менять

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

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

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

Читайте также:Как можно вписать нового владельца, если закончилось место в ПТС

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

  1. Заявление, которое составляется на специальном бланке. Его вам предоставят в организации, в которую вы обратитесь. Просьба составляется в единственном экземпляре и должна содержать объяснение причины замены, также она быть составлена максимально грамотно, ее содержание должно быть кратким, но в то же время четко сформированное. Если вы не уверены в своих силах, то обратитесь с просьбой о помощи к сотрудникам пункта регистрации.
  2. Удостоверение личности гражданина, который просит о выдачи дубликата. Обычно в качестве заявителя выступает владелец средства передвижения.
  3. Старый заполненный паспорт транспортного средства следует передать в органы Госавтоинспекции. Ее сотрудники проверят старый документ и сверят с базой данных. Вся информация из ПТС должна беспрекословно соответствовать информации из электронной базы. Уполномоченное лицо также проверит сам автомобиль на соответствие, в частности, внимание обращают на цвет, ВИН-номер, номер кузова/шасси и дату производства авто. После того как проверят всю информацию, заполненный ПТС будет уничтожен.
  4. Страховой полис ОСАГО. Без него ни при каких обстоятельствах транспортное средство не будет поставлено на учет. Чтобы получить страховой полис, следует позаботиться о своевременном прохождении технического осмотра средства передвижения.
  5. Помимо этого, стоит предъявить документ, который является правоустанавливающей документацией, чаще всего это договор купли-продажи или дарственный договор.
  6. И напоследок следует представить квитанции об уплате государственной пошлины.

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

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

Как действовать, когда паспорт закончился

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

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

Заключение

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

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


Как заполнить ПТС при покупке машины?

Добрый день, уважаемый читатель.

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

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

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

Правила оформления ПТС

Нормативный документ, который рассказывает о том, как именно должен заполняться паспорт транспортного средства, — Приказ министерства внутренних дел Российской Федерации «Об утверждении форм документов, идентифицирующих транспортное средство, и требований к ним».

Обратимся к подпункту 32.2 приложения 3 к приказу МВД:

32.2. При совершении в установленном порядке сделок, направленных на отчуждение и приобретение права собственности на транспортные средства:

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

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

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

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

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

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

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

Образец заполнения ПТС

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

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

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

Все поля паспорта транспортного средства заполняются «от руки». После внесения нового собственника раздел паспорта должен иметь такой вид:

В этом примере договор купли-продажи заключен между физическими лицами, поэтому поля «место печати» («м. п.») не заполнены.

Оформление ПТС при продаже машины

В данном примере в качестве продавца выступает Иванов Иван Иванович, а в качестве покупателя — Петров Петр Петрович. Между ними заключен стандартный договор купли-продажи автомобиля, который не имеет номера. Акт передачи автомобиля не составлялся.

ПолеЧто вносится?Пример заполнения
Наименование (ф.и.о.) собственникаФамилия, имя и отчество покупателя (по паспорту)Петров Петр Петрович
АдресАдрес постоянной регистрации (прописки) покупателя (по паспорту)г. Москва, ул. Профсоюзная, д.12, кв.5
Дата продажи (передачи)Дата акта передачи автомобиля или дата составления договора купли-продажи (если акт не составлялся)19 мая 2020 года
Документ на право собственностиДоговор купли продажи, его номер (если есть) и дата составленияДоговор купли-продажи от 19 мая 2020 года
Подпись прежнего собственникаПодпись продавцаИванов
Подпись настоящего собственникаПодпись покупателяПетров

Примечание. Если при оформлении сделки кроме договора купли-продажи был оформлен акт передачи автомобиля, то в поле «Дата продажи (передачи)» вносится не дата заключения договора, а дата из акта приема-передачи.

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

Договор купли-продажи №183 от 19 мая 2020 года

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

Перейдем к более сложной ситуации:

В качестве продавца все также выступает Иванов Иван Иванович, а в качестве покупателя — Петров Петр Петрович.

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

То есть машина продана по следующей схеме:
Андреев — Иванов — Петров

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

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

Кроме того, покупателю передается договор от 5 апреля 2020 года, который заключен между Андреевым и Ивановым (он требуется в ГИБДД).

ПолеЧто вносится?Пример заполнения
Наименование (ф.и.о.) собственникаФамилия, имя и отчество покупателя (по паспорту)Петров Петр Петрович
АдресАдрес постоянной регистрации (прописки) покупателя (по паспорту)г. Москва, ул. Профсоюзная, д.12, кв.5
Дата продажи (передачи)Дата акта передачи автомобиля или дата составления договора купли-продажи (если акт не составлялся)19 мая 2020 года
Документ на право собственностиДоговор купли продажи, его номер (если есть) и дата составленияДоговор купли-продажи от 19 мая 2020 года
Подпись прежнего собственникаПодпись продавцаИванов
Подпись настоящего собственникаПодпись покупателяПетров

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

Оформление ПТС при дарении машины

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

ПолеЧто вносится?Пример заполнения
Наименование (ф.и.о.) собственникаФамилия, имя и отчество одаряемого (внука)Васильев Лев Леонидович
АдресАдрес постоянной регистрации (прописки) одаряемого (внука)г. Москва, ул. Братиславская, д.31, кв.88
Дата продажи (передачи)Дата акта передачи автомобиля или дата составления договора дарения (если акт не составлялся)19 мая 2020 года
Документ на право собственностиДоговор дарения, его номер (если есть) и дата составленияДоговор дарения от 19 мая 2020 года
Подпись прежнего собственникаПодпись дарителя (дедушки)ВВасильев
Подпись настоящего собственникаПодпись одаряемого (внука)ЛВасильев

Оформление ПТС при вступлении в наследство

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

ПолеЧто вносится?Пример заполнения
Наименование (ф.и.о.) собственникаФамилия, имя и отчество наследника (сына)Бобров Борис Григорьевич
АдресАдрес постоянной регистрации (прописки) наследника (сына)г. Москва, ул. Перекопская, д.112, кв.61
Дата продажи (передачи)Дата выдачи свидетельства о праве на наследство15 мая 2020 года
Документ на право собственностиСвидетельство о правое на наследство, его номер и дата составленияСвидетельство о праве на наследство № 8-1842 от 15 мая 2020 года
Подпись прежнего собственникаНе заполняется
Подпись настоящего собственникаПодпись наследника (сына)Бобров

Оформление ПТС при продаже машины, полученной в наследство

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

ПолеЧто вносится?Пример заполнения
Наименование (ф.и.о.) собственникаФамилия, имя и отчество покупателяПанкратов Павел Петрович
АдресАдрес постоянной регистрации (прописки) покупателяг. Москва, ул. Онежская, д.47, кв.8
Дата продажи (передачи)Дата акта передачи автомобиля или дата составления договора купли-продажи (если акт не составлялся)19 мая 2020 года
Документ на право собственностиДоговор купли продажи, его номер (если есть) и дата составленияДоговор купли-продажи от 19 мая 2020 года
Подпись прежнего собственникаПодпись наследникаОрлов
Подпись настоящего собственникаПодпись покупателяПанкратов

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

Оформление ПТС, если наследников несколько

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

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

ПолеЧто вносится?Пример заполнения
Наименование (ф.и.о.) собственникаФамилия, имя и отчество наследника (сына)Савельев Руслан Константинович
АдресАдрес постоянной регистрации (прописки) наследника (сына)г. Москва, ул. Металлургов, д.17, кв.121
Дата продажи (передачи)Дата выдачи свидетельства о праве на наследство15 мая 2020 года
Документ на право собственностиСвидетельство о правое на наследство, его номер и дата составленияСвидетельство о праве на наследство № 6-937 от 15 мая 2020 года
Подпись прежнего собственникаНе заполняется
Подпись настоящего собственникаПодпись наследника (сына)РСавельев

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

Оформление ПТС, если собственник не меняется

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

Особенности оформления ПТС описываются в подпункте 32.1 приложения 3 к приказу МВД:

32.1. При заполнении паспортов в рамках совершения регистрационных действий с транспортными средствами, не связанных с изменением сведений об их собственниках (владельцах):

  • в строках «Наименование (ф.и.о.) собственника», «Адрес» указываются данные собственников согласно строкам 21 и 22 паспорта;
  • в строках «Дата продажи (передачи)», «Документ на право собственности» производятся записи «отсутствует»;
  • в строке «Подпись настоящего собственника» проставляется подпись собственника либо владельца транспортного средства.

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

В данном случае не имеет смысла самостоятельно вносить данные о себе в ПТС.

Что делать, если в ПТС нет свободного места?

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

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

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

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

Удачи на дорогах!

udp — Могу ли я использовать широковещательную или многоадресную рассылку для TCP?

Обычно я не публикую здесь, но мне просто нужно было добавить небольшое пояснение к рассуждениям здесь. Ответ Штеффена правильный. Нет, нельзя! идеально. В остальном позвольте мне ответить, что UDP — правильный протокол для отправки многоадресных и широковещательных сообщений. Я выкрикиваю имя Штеффена в переполненной комнате, хочу ли я, чтобы все ответили? Ни за что! Если использовался TCP, все подтвердят мой пакет!

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

Наконец, это приводит нас к надежности UDP. После того, как я проясню это, вернитесь и прочтите абзац над этим еще раз.UDP не является надежным. Это главное различие между TCP и UDP. Итак, вот сделка, есть UDP и R-UDP. R-UDP — это другой RFC (см. Ссылку внизу), чем UDP. Очевидно, этот RFC — это IETF. Могут быть и другие. Они указывают на то, что исходный ответ был правильным, но представленная информация об UDP (RFC 2460) была неправильной. По академическим причинам, а также просто по обыкновению semse

Прочтите про R-UDP здесь RUDP, похоже, не имеет надлежащего RDF. некоторые RFC используются в его концептуализации, но похоже, что он будет использоваться Microsoft, которая отправила IETF какой-то документ для запуска процесса RFC.эта ссылка ниже:

http://www.ietf.org/proceedings/44/I-D/draft-ietf-sigtran-reliable-udp-00.txt

Кроме того, MS опубликовала некоторую информацию ниже вместе с вики-страницей RUDP:

http://www.viavisolutions.com/en-us/literature/microsoft-tv-test-application-notes-en.pdf

ну Очевидно, моя репутация должна быть 10, чтобы разместить более двух ссылок — так что википедия, другая ссылка ищет R-UDP или RUDP

TCP Flow Control

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

Что такое Flow Control (и что это не так)

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

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

Как это работает

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

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

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

Если мы увеличим масштаб, мы увидим что-то вроде этого.

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

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

Чтобы контролировать объем данных, которые может отправить TCP , получатель будет объявлять его Окно приема (rwnd) , то есть свободное место в буфере приема.

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

Окно раздвижное

TCP использует протокол скользящего окна для управления количеством байтов в полете. могу иметь. Другими словами, количество байтов, которые были отправлены, но еще не были отправлены ack ed.

Допустим, мы хотим отправить файл размером 150000 байтов с узла A на узел B. TCP может разбейте этот файл на 100 пакетов по 1500 байт каждый. А теперь скажем, когда соединение между узлом A и B установлено, узел B объявляет о приеме окно размером 45000 байт, потому что оно действительно хочет помочь нам с нашей математикой.

Видя это, TCP знает, что может отправить первые 30 пакетов (1500 * 30 = 45000) прежде, чем он получит подтверждение. Если он получает сообщение ack для первого 10 пакетов (то есть сейчас у нас в полете только 20 пакетов), а прием Окно, присутствующее в этих сообщениях ack , по-прежнему 45000, оно может отправить следующие 10 пакетов, возвращая количество пакетов в полете до 30, что является пределом определяется окном приема. Другими словами, в любой момент времени он может имеют 30 пакетов в полете, которые были отправлены, но еще не отправлены ack ed.

Пример скользящего окна. Как только пакет 3 подтвержден, мы можем сдвинуть окно справа и отправьте пакет 8.

Теперь, если по какой-то причине приложение, читающее эти пакеты в узле B, замедляется вниз, TCP по-прежнему будет подтверждать пакеты, которые были правильно получены, но как эти пакеты необходимо хранить в приемном буфере до тех пор, пока приложение решает их прочитать, окно приема будет меньше, поэтому даже если TCP получает подтверждение для следующих 10 пакетов (это означает, что в настоящее время существует 20 пакетов или 30000 байт в полете), но значение окна приема, полученное в этот ack теперь 30000 (вместо 45000), он не будет отправлять больше пакетов, так как количество байтов в полете уже равно последнему окну приема рекламируется.

Отправитель всегда сохраняет этот инвариант:

  LastByteSent - LastByteAcked <= ReceiveWindowAdvertised
  
Визуализация окна приема

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

Вот простая программа go , которая считывает и распечатывает полученные данные:

  пакет основной

Импортировать (
"буфио"
"fmt"
"сеть"
)

func main () {
слушатель, _: = net.Listen ("tcp", "localhost: 3040")
conn, _: = listener.Accept ()

для {
сообщение, _: = bufio.NewReader (conn) .ReadBytes ('\ n')
fmt.Println (строка (сообщение))
}
}
  

Эта программа просто прослушивает соединения на порту 3040 и распечатывает строка получена.

Затем мы можем использовать netcat для отправки данных в это приложение:

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

Нажмите на изображение, чтобы увеличить его.

Теперь давайте запустим эту команду, чтобы создать поток данных. Он просто добавит строка «foo» в файл, который мы будем использовать для отправки в это приложение:

  $ пока правда; сделать echo "foo"> stream.txt; сделано
  

А теперь отправим в приложение эти данные:

  tail -f stream.txt | NC localhost 3040
  

Теперь, если мы проверим Wireshark , мы увидим много отправляемых пакетов, а окно получения обновляется:

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

  пакет основной

Импортировать (
"буфио"
"fmt"
"сеть"
"время"
)

func main () {
слушатель, _: = net.Listen ("tcp", "localhost: 3040")
conn, _: = listener.Accept ()

для {
сообщение, _: = bufio.NewReader (conn) .ReadBytes ('\ n')
fmt.Println (строка (сообщение))
+ время. сон (1 * время. секунда)
}
}
  

Теперь мы спим в течение 1 секунды, прежде чем мы прочитаем данные из приемного буфера. Если мы снова запускаем netcat и наблюдаем Wireshark , это не займет много времени, пока буфер приема заполнен, и TCP начинает объявлять размер окна 0:

В этот момент TCP прекратит передачу данных, так как буфер получателя полный.

Таймер сохранения

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

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

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

Обзор
  • Управление потоком TCP - это механизм, гарантирующий, что отправитель не перегружает приемник с большим объемом данных, чем он может обработать;
  • С каждым сообщением ack получатель объявляет свое текущее окно приема;
  • Окно приема - это свободное место в буфере приема, то есть rwnd = ReceiveBuffer - (LastByteReceived - LastByteReadByApplication) ;
  • TCP будет использовать протокол скользящего окна, чтобы гарантировать, что у него никогда не будет больше байтов в полете, чем окно, указанное получателем;
  • Когда размер окна равен 0, TCP прекратит передачу данных и начнет постоянный таймер;
  • Затем он будет периодически отправлять получателю небольшое сообщение WindowProbe чтобы проверить, может ли он снова начать получать данные;
  • Когда он получает размер окна, отличный от нуля, он возобновляет передачу.

Если вы хотите узнать больше о TCP (и намного больше ), книга Компьютер Сеть: подход «сверху вниз» - отличный ресурс.

Получить PDF

Лекция

Лекция

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


  • , как и порядковые номера и номера подтверждений, окно TCP считает байты
  • если действует масштабирование окна, окно подсчитывается в единицах 2, 4, 8, 16 или вообще 2 n байт
  • в окне указано, сколько неподтвержденных байтов может иметь отправитель
  • получатель отправляет отправителю окно, чтобы отразить сумму свободное буферное пространство
  • это известно как управление потоком: поскольку отправитель может отправлять не более данные в одно окно за каждый RTT, получатель может замедлить отправителя, отправив небольшое окно


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


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


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


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


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


  • перегрузка может быть обнаружена на маршрутизаторе (или коммутаторе) наблюдая за размерами очереди
  • этот маршрутизатор может отправить сообщение отправителю с запросом замедлить
  • обеспечивает быструю обратную связь, но генерирует дополнительные сообщения (и дополнительная работа для роутера) только тогда, когда сеть перегружена
  • или этот маршрутизатор может изменить отправляемое сообщение для записи это скопление происходит
  • получатель может затем вернуть информацию отправителю в пакеты подтверждения
  • для предоставления обратной связи требуется как минимум одно время приема-передачи.
  • , но маршрутизатор может дать обратную связь, как только очередь начнет расти, поэтому, возможно, не придется отбрасывать пакеты
  • это стратегия, используемая явной перегрузкой TCP / IP Уведомление, ECN
  • маршрутизатор устанавливает поле в заголовке IP для записи того, что пакет столкнулся с перегрузкой
  • приемник устанавливает соответствующий бит ECE (ECN-Echo) в заголовке TCP из аксов
  • отправитель затем замедляется и устанавливает CWR (уменьшенное окно перегрузки) бит в заголовке пакетов, отправленных в прямом направлении


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


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


  • TCP имеет способ управления (дросселирования) скорости отправки: окно управления потоком
  • одна из возможностей - попросить маршрутизаторы изменить (уменьшить) окно, когда пакет испытывает перегрузку
  • это нецелесообразно по двум причинам:
    • он требует, чтобы маршрутизаторы декодировали заголовок TCP всех пакетов переносится, что увеличивает вычислительную нагрузку на роутеры
    • значения окна переносятся в пакете подтверждения, перегрузка (обычно) испытывают в прямом направлении
  • текущий механизм IP ECN (явное уведомление о перегрузке) обходит эти проблемы, помещая биты уведомления о перегрузке в заголовке IP и требуя от принимающего хоста сообщить отправителю TCP
  • в то время IP ICN не был разработан, поэтому была нашел
  • при перегрузке пакеты отбрасываются
  • отправитель TCP должен интерпретировать отбрасывание пакета как признак перегрузки, и уменьшить его окно отправки ниже значения, установленного окном управления потоком, к значению окна перегрузки


  • TCP Reno (модификация TCP Tahoe)
  • TCP-соединение начинается с окна перегрузки в один Максимум Размер сегмента, 1 MSS
  • каждый раз при получении подтверждения окно увеличивается на величину подтвержденных данных
  • , если одно окно перегрузки отправляется каждый RTT, в конце RTT, окно перегрузки должно увеличиться вдвое
  • окно перегрузки растет экспоненциально
  • это называется Медленный старт и продолжается до тех пор, пока:
    • обнаружена потеря пакета, или
    • достигнут заранее определенный порог
  • потеря пакета обнаружена либо тайм-аутом, либо быстрая повторная передача / быстрое восстановление после трех повторяющихся подтверждений
  • при обнаружении потери пакета:
    • порог установлен на половину текущего окна перегрузки,
    • окно перегрузки установлено на 1 (если тайм-аут) или порог (при быстром восстановлении)
    • медленный старт продолжается или начинается


  • экспоненциальный рост очень быстрый и сам по себе может вызвать перегрузку
  • быстрее отправка - это эксперимент: окно, в котором упал экспериментально определен как неустойчивый
  • а какая ставка устойчивая?
  • возможно, но не обязательно, половина окна, в которой пакет была сброшена
  • если истекло время ожидания, будьте осторожны и используйте медленный старт для достичь порога
  • если произошло быстрое восстановление, будьте немного агрессивнее и начните на пороге
  • , а затем медленно увеличивайте до , зонд сети
  • , пока не будет обнаружена другая потеря пакета
  • затем снова установите порог на половину окна перегрузки и начать либо медленный старт, либо линейное увеличение
  • это аддитивное увеличение, мультипликативное уменьшение, AIMD
  • было показано, что любая стратегия, основанная на потере пакетов и убывает медленнее, чем мультипликативно не стабильно, т.е.е. ведет к затору коллапс
  • при условии, что 1 окно перегрузки отправляется каждый RTT, и
  • мы хотели бы увеличивать на 1 MSS каждый RTT, поэтому увеличение по подтвержденным данным должно быть:
    MSS * (данные подтверждены) / окно перегрузки
  • в предлагаемой альтернативе TCP Vegas, TCP отслеживает время приема-передачи, и если оно превышает измеренное минимальное значение, окно уменьшается линейно
  • предполагается, что это линейное уменьшение работает, потому что оно не вызывает такая же загруженность, как у традиционного AIMD


  • под AIMD окно сокращается вдвое, когда пиковая пропускная способность достиг
  • , а затем окно увеличивается на один MSS каждый RTT, пока не достигнет та же скорость отправки
  • предположим, что пропускная способность сети постоянна B
  • игнорируя медленный старт, TCP будет колебаться между входами B / 2 и B, в среднем 3/4 B
  • , поскольку одно окно отправляется каждый RTT, и если W = B / RTT, окно будет варьироваться от W / 2 до W, в среднем 3/4 Вт.
  • это впервые было представлено в 1997 г.
  • более свежая заметка одного из тех же авторов предполагает, что Интернет меньше полагается на взаимодействие конечных систем и многое другое об ограничениях полосы пропускания при доступе ссылка


  • данные, которые не контролируются перегрузкой, например UDP, могут вытеснить данные, которые "хорошо себя ведут"
  • новые транспортные протоколы, такие как Stream Control Transport Протокол (SCTP) и протокол управления перегрузкой дейтаграмм попробуйте заставить UDP "вести себя хорошо"
  • несколько TCP-соединений с одним и тем же узким местом, окно управления потоком и RTT, как правило, сходятся к одному и тому же диапазону окон контроля перегрузки
  • , но соединения с более длительным (более медленным) RTT будут иметь меньшее значение доля пропускной способности по сравнению с соединениями с более короткими RTT
  • и
  • подключения бесплатные! любой желающий получить более высокую долю пропускная способность может открыть больше соединений

TCP vs.UDP: В чем разница?

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

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

Что такое TCP?

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

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

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

Что такое UDP?

User Datagram Protocol (UDP) - это более простой интернет-протокол без установления соединения, в котором не требуются услуги проверки ошибок и восстановления. С UDP нет накладных расходов на открытие соединения, поддержание соединения или завершение соединения; данные непрерывно отправляются получателю, независимо от того, получили он их или нет.

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

В чем разница между TCP и UDP?

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

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

Элемент

TCP

UDP

Статус подключения

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

Протокол без установления соединения без требований к открытию, поддержанию или завершению соединения

Последовательность данных

Последовательность

Невозможно выполнить последовательность

Гарантированная доставка

Может гарантировать доставку данных на маршрутизатор назначения

Не может гарантировать доставку данных в пункт назначения

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

Возможна повторная передача потерянных пакетов

Нет повторной передачи потерянных пакетов

Проверка ошибок

Расширенная проверка ошибок и подтверждение данных

Базовый механизм проверки ошибок с использованием контрольных сумм

Способ передачи

Данные читаются как поток байтов; сообщения передаются на границы сегмента

пакетов UDP с определенными границами; отправляется индивидуально и проверяется на целостность по прибытии

Скорость

Медленнее, чем UDP

Быстрее TCP

Радиовещание

Не поддерживает вещание

Поддерживает вещание

Оптимальное использование

Используется HTTPS, HTTP, SMTP, POP, FTP и т. Д.

Видеоконференцсвязь, потоковая передача, DNS, VoIP и т. Д.

TCP против скорости UDP

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

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

Что лучше для видеоконференцсвязи?

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

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

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

Как включить UDP в Lifesize

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

1. Откройте Lifesize

.

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

2. Выберите настройки

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

Чтобы минимизировать количество портов UDP, доступных для связи, вы можете ограничить диапазон, изменив значения в «Предпочтения»> «Сеть»> «Зарезервированные порты». По умолчанию системы Lifesize обмениваются данными через порты в диапазоне 60000–64999 для видео, голоса, презентаций и управления камерой.

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

Кроме того, диапазон должен начинаться с четного числа и заканчиваться нечетным числом, чтобы общее количество портов было четным. Например, если диапазон начинается с 62000, установите нижний предел на 62000, а верхний предел на 62099, чтобы выделить 100 портов (необходимый минимум).

Обратите внимание, что изменение значений в зарезервированных портах приведет к перезапуску системы.

3. Откройте настройки прокси-сервера

После того, как все ваши настройки заданы, пора открыть настройки прокси-сервера, выбрав «Настройки»> «Сеть»> «Прокси-сервер».

Эта таблица является отличным источником информации о необходимых настройках брандмауэра и прокси, связанных с UDP, поскольку вам потребуется настроить брандмауэр, чтобы разрешить исходящий доступ из вашей сети к вашим портам UDP. Если у вас есть сторонняя интеграция для утвержденных устройств Cisco® и Polycom®, вам будет предоставлен кодек H.460, а также IP-адрес сервера.

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

4. Включить UDP

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

Заключение

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

ПРОЕКТИРОВАНИЕ TCP / IP ДЛЯ TAC IEN-166 Роберт Хинден Bolt Beranek и Newman Inc.Январь 1981 г. IEN-166 Р. Хинден Bolt Beranek и Newman Inc. Январь 1981 г. Оглавление 1 Введение .......................................... 1 2 Общий поток данных ..................................... 2 2.1 Получение данных...................................... 2 2.1.1 Модуль 1822 ....................................... 3 2.1.2 Модуль NCP ........................................ 4 2.1.3 Интернет-модуль ................................... 4 2.1.4 Модуль TCP ........................................ 5 2.1.5 Модуль Telnet ..................................... 6 2.2 Отправка данных ........................................ 7 2.2.1 Модуль Telnet ..................................... 7 2.2.2 Модуль TCP ........................................ 8 2.2.3 Интернет-модуль ................................... 9 2.2.4 Модуль 1822 ....................................... 9 3 Контроль и приоритет ................................. 10 4 Структуры данных ...................................... 11 4.1 Блок сообщений ...................................... 11 4.2 Блок данных протокола ................................ 13 5 Протокол 1822 г. ........................................ 16 6 Интернет-протокол .................................... 17 6.1 Назначение идентификатора .............................. 17 6.2 Поддержка опций ..................................... 17 6.3 Повторная сборка ......................................... 17 6.4 Маршрутизация ............................................ 19 6.5 Сообщения от шлюза к шлюзу ........................ 20 6.6 Тайм-ауты ........................................... 21 7 Протокол управления коробкой передач ........................ 21 7.1 Открытие и закрытие соединения ..................... 21 7.2 Присвоение начального порядкового номера ................. 22 7.3 Поддержка опций ..................................... 22 7.4 Срочные данные ........................................ 23 7.5 Обработка писем в конце ............................. 23 7.6 Повторные передачи .................................... 24 7.7 Подтверждение и стратегия окна ................ 24 7.8 Последовательность ......................................... 25 ЦИФРЫ Данные и поток управления ..................................... 3 Формат блока сообщений ..................................... 12 Формат блока данных протокола ............................... 15 -я- IEN-166 Р. Хинден Bolt Beranek и Newman Inc. Январь 1981 г. Дизайн TCP / IP для TAC 1. Введение Этот документ является рабочим проектным документом для разработка протокола управления передачей (TCP) и Интернет-протокол (IP) для контроллера доступа к терминалу (TAC).TAC - это терминальный контроллер, поддерживающий TCP и NCP. хост для хост-протоколов. Он будет работать на компьютере H-316 с Многолинейный терминальный контроллер (MLC) и хост-интерфейс 1822. Частично он основан на существующем H-316 TIP. Этот документ предназначен в качестве руководства по внедрению TAC. Цель не в том, чтобы написать спецификацию, которая описывает все очень подробно, но чтобы описать в целом система и как ее части взаимодействуют друг с другом.Кроме того, это обсуждает изменения в частях существующего H-316 TIP. Все в этом документе может быть изменено. Как реализация и отладка продолжаются, будет учиться новое. Это потребует переоценки принятых проектных решений. здесь. Несомненно, кое-что изменится. Документ написан с учетом практического знания 316 TIP, Интернет-протокол, протокол управления передачей и Протокол управления сетью. Все числа в этом документе указаны в десятичный.-1- IEN-166 Р. Хинден Bolt Beranek и Newman Inc. Январь 1981 г. 2. Общий поток данных Основная предпосылка при разработке TAC заключается в том, что данные не должны перемещаться между буферами, а указатели на данные должны передаваться между программными модулями. Таким образом, когда сообщение прочитано в буфер, указатели на него передаются между разными модули протокола.Когда символ читается из MLC и помещается в буфер, модули протокола манипулируют буфером указатели, а не сами данные. Это показано на рисунке 1. 2.1 Получение данных Для получения данных из сети читается сообщение из хост-интерфейс 1822 в блок сообщений (MBLK). Если сообщение не поместится в один MBLK, остальное будет прочитано в другие бесплатные MBLK, пока сообщение не будет полностью прочитано. Все MBLK, содержащие одно и то же сообщение, будут связаны вместе.Блок данных протокола (PDB) будет создан, чтобы указать к МБЛК. Указатели, которые передаются между протоколом модули будут указывать на PDB. Подробнее о PDB и MBLK можно найти в разделе «Структуры данных». -2- IEN-166 Р. Хинден Bolt Beranek и Newman Inc. Январь 1981 г. + --------- + + + + --------------- + Сообщение + | TCP || IP || Telnet || 1822 || IMP | +++++++ | | | + ----- + | | | +++++++ || + -------- + | | | | + ------ + / \ / \ || +> | NCP | + + Кувырок + ----- + / / + ---> + + Таблица / / + --- + / / || + ---------- + / / || + + / / | + -----------> + Сообщение + -------------------- + / + ------------> + Буферы + --------------------- + + + + ---------- + Управление -----> Данные -----> -----> Рисунок 1 .Данные и поток управления 2.1.1 Модуль 1822 Модулю 1822 дается указатель на PDB. Этот модуль будет действовать непосредственно на сообщение, если это контрольное сообщение 1822 (т.е. RFNM). Он обновит соответствующую структуру данных до инициировать действие, которое необходимо предпринять. Если PDB содержит 1822 -3- IEN-166 Р. Хинден Bolt Beranek и Newman Inc. Январь 1981 г. сообщение данных, оно будет передано следующему модулю протокола.Какой модуль будет передан, зависит от номера ссылки в 1822 сообщение. Номер ссылки - это старшие 8 бит "идентификатора сообщения". поле в лидере 1822 года. Номер связи с отображением протокола: следующее: Ссылка № Протокол 0 Контроль NCP 2-71 Данные NCP 155 Интернет 2.1.2 Модуль NCP Модуль NCP реализует протокол ARPANET Host-Host. Его функция по существу идентична NCP H-316 TIP.Единственная разница в том, что он будет модифицирован для работы с новые структуры данных PDB и MBLK. Это будет сделано с новым интерфейс и, надеюсь, окажет небольшое влияние на эффективность. Когда модуль NCP завершит работу с сообщением, он передаст сообщение указатель на PDB к модулю Telnet. 2.1.3 Интернет-модуль Когда модуль Интернет-протокола (IP) получает указатель на PDB сначала проверяет контрольную сумму в IP-заголовке, а затем проверяет что адрес назначения правильный (это должен быть адрес -4- ИЭН-166 Р.Hinden Bolt Beranek и Newman Inc. Январь 1981 г. TAC, выполняющего код). Если какая-либо из этих проверок не удалась, дейтаграмма отбрасывается. Кроме того, если адрес назначения был неверно отчет об ошибке IP будет отправлен источнику дейтаграмма. Следующая проверка - действительно ли дейтаграмма фрагментированный. Если да, то IP-модуль выполнит повторную сборку. Это подробно описано в разделе «Интернет Протокол ».Когда IP-модуль получает полную дейтаграмму (либо получен целиком или повторно собран) он передаст его следующему модуль протокола. Какой это модуль, зависит от "Протокола". поле в Интернет-заголовке. Если дейтаграмма получена для протокол, который не поддерживается, он будет удален, а IP-адрес отчет об ошибке отправлен источнику дейтаграммы. Протоколы поддерживаются следующие: Протокол № Название протокола 3 Межсетевой протокол шлюза 6 Протокол управления передачей 71 пакетное ядро 20 TAC Мониторинг 2.1.4 Модуль TCP Когда протокол управления передачей (TCP) получает PDB сначала он проверяет контрольную сумму сообщения и действительность заголовок TCP. Если сообщение, прошедшее эту проверку, предназначено для действующее соединение, и его порядковый номер находится в принимающей В окне TCP-модуль настроит его на открытое соединение. -5- IEN-166 Р. Хинден Bolt Beranek и Newman Inc.Январь 1981 г. При необходимости на этом этапе данные будут упорядочены. Это подробно описано в разделе «Управление коробкой передач. Протокол ». Следующий модуль информируется о наличии данных. для обработки. Управление потоком реализуется с помощью подтверждения TCP. (ACK) и параметры размера окна. Фиксированное количество символы будут буферизированы для каждого соединения. Как персонажи приняты, они будут подтверждены до тех пор, пока не будет достигнуто ограничение.По мере увеличения значения ACK окно будет уменьшаться. соответственно. Когда следующий модуль берет данные из сообщение, буферное пространство становится доступным. Это заставляет TCP продвинуть свое окно, тем самым позволяя удаленному хосту отправлять больше данные. Обычно новые значения ACK и окна отправляются с следующее сообщение с данными от этого соединения. Если ничего нет в ожидании этого подключения, сообщение только с обновленным ACK и значения окна будут отправлены.Это описано более подробно в разделе «Протокол управления передачей». 2.1.5 Модуль Telnet Модулю Telnet дается указатель на PDB, когда есть данные для обработки. Эти данные могут быть от NCP или TCP. -6- IEN-166 Р. Хинден Bolt Beranek и Newman Inc. Январь 1981 г. модули протокола.Достает персонажей из МБЛК, выглядит для команд Telnet и выводит их в MLC. Этот вывод выполняется с использованием существующих «поворотных столов» TIP. Это будет работать используя "OI", что означает, что каждый раз, когда "OI" приходит для порт, Telnet проверит, есть ли еще один символ для вывода. 2.2 Отправка данных Данные, которые отправляются в сеть, обычно поступают из MLC и принимается в формате «Tumble Table». Это блок, который заполняется MLC.Его формат - это одно слово для ввод каждого символа. Младший байт слова - это символ, а старший байт - это номер строки, в которой появился персонаж. Когда блок получен, он передается в Telnet. модуль. Этот модуль выводит персонажей и обрабатывает их. По мере того, как это происходит, другой блок заполняется MLC. 2.2.1 Модуль Telnet Когда модуль Telnet получает символ для порта, он сначала проверяет, есть ли открытое соединение для этого порта.Если нет, то это отбрасывает символ и выводит в порт колокольчик. -7- IEN-166 Р. Хинден Bolt Beranek и Newman Inc. Январь 1981 г. Затем он проверяет, есть ли место в MBLK для другого персонаж. Если нет, то персонаж сбрасывается и колокольчик звено. Если есть место, персонаж помещается в MBLK и правильные указатели продвигаются.Затем Telnet указывает следующий модуль протокола, который есть данные для отправки. В зависимости от какой протокол используется для соединения, это либо модуль NCP или TCP. 2.2.2 Модуль TCP Когда модуль TCP получает сигнал о наличии новых данных который должен быть отправлен, он сначала проверяет, есть ли место в окно отправки для отправки дополнительных данных. Это делается путем проверки того, что последние отправленные, но неподтвержденные данные находятся на правом краю окно отправки. Если места нет, то ничего не будет отправлено.В противном случае модуль TCP настроит указатели в PDB и MBLK, чтобы указать на правильные данные и обновить заголовок TCP. Управление потоком в направлении отправки осуществляется путем поддержания три указателя в PDB. Это указатели на данные в МБЛК. Это указатели на последний ACKed-символ, последний отправленный, но неупакованный символ и последний еще не отправленный символ в МБЛК. Когда данные принимаются, отправляются или помещаются в MBLK, соответствующий указатель продвигается. -8- ИЭН-166 Р.Hinden Bolt Beranek и Newman Inc. Январь 1981 г. Когда модуль TCP готов к отправке данных, он проверяет, посмотреть, может ли модуль 1822 отправлять данные (т.е. нет более восьми незавершенных сообщений). Если данные можно отправить, тогда модуль TCP вычислит контрольную сумму для сообщения и передать указатель PDB в модуль IP. 2.2.3 Интернет-модуль Когда IP-модуль получает указатель на PDB, он сначала проверяет чтобы узнать, знает ли он, куда отправить дейтаграмму.Если пункт назначения находится в той же сети, что и TAC, Интернет модуль будет использовать это как адрес. Если пункт назначения находится на в другую сеть, затем он отправит его на шлюз. В Процедура принятия решения о том, какой шлюз использовать, обсуждается в более Подробно в разделе «Интернет-протокол». Затем модуль IP создаст лидера IP в MBLK и вычислить контрольную сумму лидера. Затем он передаст указатель к сообщению на модуль 1822. 2.2.4 1822 Модуль Когда модуль 1822 получает указатель на PDB, он всегда отправить сообщение, которое он содержит, по назначению, указанному в PDB. Целевой хост будет либо хостом сервера, либо -9- IEN-166 Р. Хинден Bolt Beranek и Newman Inc. Январь 1981 г. шлюз. Модуль 1822 будет отслеживать количество ожидающие (не полученные RFNM) сообщения, отправленные на хост.Этот будет использоваться модулями протокола NCP и TCP, чтобы гарантировать, что IMP никогда не будет блокировать хост-интерфейс TAC из-за наличия более восьми выдающихся сообщений. Когда модуль 1822 отправляет сообщение, он создает 1822 г. лидер в МБЛК. Затем он отправит сообщение на IMP через аппаратное обеспечение интерфейса хоста. 3. Контроль и приоритет Код в TAC будет работать либо на уровне прерывания или в фоновом цикле. Процедуры прерывания будут поддерживать интерфейс хоста, MLC и часы.Кроме того, высокий приоритет подпрограммы протокола будут выполняться на уровне прерывания задачи. Фоновый цикл будет содержать большую часть кода TAC. В здесь будут работать модули протокола. Они будут выполнены в в следующем порядке: ввод 1822, ввод IP, ввод TCP, ввод NCP, Вход Telnet, Выход Telnet, Выход NCP, Выход TCP, Выход IP, и Выход 1822 года. Каждый модуль протокола будет иметь входную очередь. Когда это запускается, он проверяет наличие записи в своей очереди. Если он найдет что-то, он снимает его с очереди и обрабатывает.Некоторые из -10- IEN-166 Р. Хинден Bolt Beranek и Newman Inc. Январь 1981 г. модули протокола будут написаны для обработки всех записей на их очередь перед выходом; другие обработают одну запись и затем выйдите. Модули NCP, TCP и Telnet будут обрабатывать один Вход. Модули 1822 и IP будут обрабатывать все записи.4. Структуры данных В TAC будет использоваться новая система буферов. Это состоит из двух типов блоков: блока сообщений (MBLK) и Блок данных протокола (PDB). Они используются как для приема, так и для передача сообщений и буферизация символов на входе и выход. Структура этих буферов такова, что когда протокол модулю передается сообщение, ему дается указатель на PDB. В PDB включает ссылку на первый MBLK. Основная функция PDB предназначен для сохранения часто используемых вещей в сообщении и для укажите на сообщение.MBLK содержат фактическое сообщение. У них также есть поля для облегчения повторной сборки и определения последовательности. 4.1 Блок сообщений Основная функция блока сообщений (MBLK) - удерживать Сообщения. Он будет использоваться для всех протоколов. Если сообщение будет не помещается в один МБЛК, тогда остаток будет помещен во второй -11- IEN-166 Р. Хинден Bolt Beranek и Newman Inc.Январь 1981 г. МБЛК. Второй будет связан с первым. Длина MBLK будет состоять из 30 или 60 слов. MBLK из 30 слов используется для отправка данных, а для приема используется MBLK из 60 слов. Заголовок MBLK состоит из 4 слов. См. Рисунок 2. для формата блока. "Ссылка" используется для указания на другие МБЛК. Поле "Смещение" используется для пересборки IP. фрагменты и упорядочивание данных TCP.Во время этих операций содержит смещение, где эти данные относятся к данным в предыдущий МБЛК. Ноль означает отсутствие недостающих данных. Это подробно обсуждается в разделе «Повторная сборка». 1 0 0 0 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 + --------------- + --------------- + 0 | Ссылка | Указатель на следующий MBLK + --------------- + --------------- + 1 | Смещение | Используется при повторной сборке и секвенировании + --------------- + --------------- + 2 | Длина | Флаги | Длина данных, битовые флаги + --------------- + --------------- + 3 | Указатель на данные | Указатель на текущие данные + --------------- + --------------- + 4 | | Область, в которой находится сообщение .| Данные | . | | . | Площадь | | | п * | | + --------------- + --------------- + Фигура 2 . Формат блока сообщений _______________ * Где «n» равно 29 или 59, в зависимости от того, является ли блок используется для отправки или получения. -12- IEN-166 Р. Хинден Bolt Beranek и Newman Inc.Январь 1981 г. Поля «Длина» и «Указатель на данные» используются для укажите, где и сколько данных находится в MBLK. Значение они всегда относятся к модулю протокола в настоящее время обработка сообщения. Например: когда сообщение читается в из интерфейса хоста "Указатель на данные" будет указывать на 1822 выноска и "Длина" будет длиной всех данных в этом МБЛК. Когда модуль 1822 готов передать данные в следующий модуль протокола, он настраивает эти поля, чтобы ссылаться на данные после лидера 1822 года.Таким образом, модулю протокола требуется не знаю, какой протокол предшествовал ему. «Флаги» - это битовое поле, содержащее такие вещи, как Конец сообщение, выполняется ввод-вывод, чтение или запись, маленький или большой блок, и т. д. «Область данных» - это место, где хранится фактическое сообщение. В MBLK небольшого размера (30 слов) рассчитан на 1822, IP и Лидер TCP, но нет данных. Большой размер (60 слов) может содержать лидеры плюс до 60 байт данных. 4.2 Блок данных протокола Блок данных протокола - это блок заголовка для одного или нескольких MBLK, составляющие сообщение.Он содержит указатели на первый MBLK, указатели на конкретных лидеров в MBLK, часто доступ к элементам из сообщения и ссылка на следующий PDB. -13- IEN-166 Р. Хинден Bolt Beranek и Newman Inc. Январь 1981 г. Как указывалось ранее, передаются указатели на PDB. между модулями протокола. Когда модуль протокола получает PDB, он ожидает найти одну PDB, которая указывает на один или несколько MBLK.В данные в MBLK должны быть последовательными и не фрагментированный. Для этого необходимо, чтобы каждый модуль протокола гарантировал, что данные, которые он передает следующему модулю, должны быть смежными. Это лучше всего описать на следующем примере: Когда интернет-модуль получает два фрагмента одного и того же дейтаграмме, ему необходимо собрать их, прежде чем он сможет передать их следующий модуль протокола. Что он делает, так это брать MBLK содержащий второй фрагмент и связать их в соответствующий помещает в список МБЛК первого фрагмента.Как это делает это настраивает поля в MBLK, чтобы они указывали на правильный данные. Когда он соединил все MBLK со второго фрагмент, он помещает PDB, который контролировал второй фрагмент, обратно в бесплатный список PDB. Модуль TCP выполняет аналогичную операцию, чтобы упорядочить данные перед их передачей в модуль Telnet. Формат PDB показан на рисунке 3. Первое поле в PDB, «Ссылка на следующий PDB», является указателем. в другой PDB. Это используется для повторной сборки и определения последовательности.В Следующее поле в PDB - это адресное поле. Это либо источник сообщения, если оно было получено, или место назначения, если оно -14- IEN-166 Р. Хинден Bolt Beranek и Newman Inc. Январь 1981 г. 1 0 0 0 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 + --------------- + --------------- + 0 | Ссылка на следующий PDB | Указатель на следующий PDB + --------------- + --------------- + 1 | Сеть | Хост | Источник назначение + --------------- + --------------- + Адрес 2 | | IMP | + --------------- + --------------- + 3 | Идентификация | Идентификация IP + --------------- + --------------- + 4 | Флаги | Протокол | Битовые флаги, протокол # + --------------- + --------------- + 5 | Штамп времени | Отметка времени для старения + --------------- + --------------- + 6 | Указатель на 1-го лидера | Обычно 1822 г. + --------------- + --------------- + 7 | Указатель на 2-го лидера | Обычно IP или NCP + --------------- + --------------- + 8 | Указатель на 3-го лидера | Обычно TCP + --------------- + --------------- + 9 | Указатель на первый МБЛК | Указатель на первый МБЛК + --------------- + --------------- + 10 | Протокол | Переменные, используемые каждым + + модуль протокола 11 | Переменные | + + 12 | Площадь | + + 13 | | + --------------- + --------------- + Рисунок 3.Формат блока данных протокола должен быть отправлен. Поле «Идентификация» - это Интернет. идентификация, которая используется при сборке интернет-фрагментов. Поле «Флаги» - это битовый массив, используемый для таких вещей, как датаграмма. завершено, EOL, срочно, чтение или запись, без блоков, используется, дыра, и т. д. Поле "Протокол" - это протокол между хостами, -15- IEN-166 Р. Хинден Bolt Beranek и Newman Inc.Январь 1981 г. сообщение для. Поле «Отметка времени» используется для тайм-аута. Сообщения. Поля "Выноски указателя" используются для указания на разные лидеры в МБЛК. Это сделано для того, чтобы было легче найти конкретный лидер в сообщении. Они созданы конкретное протокольное сообщение и обращайтесь к разным лидерам в зависимости от того, какие протоколы используются. Поле «Указатель на первый MBLK» - это указатель на первый МБЛК сообщения.«Область переменных протокола» - это временная область, которую может использовать любой модуль протокола, пока он обработка PDB. Пока он управляет PDB, никакие другие модуль изменит эти поля. 5. Протокол 1822 г. Все 1822 сообщения с данными будут переданы непосредственно следующему модуль протокола. Когда модуль 1822 получает управляющее сообщение, он вызовет подпрограмму, предоставленную ему следующим модулем протокола. Например, модуль NCP предоставит подпрограмму для вызова когда модуль 1822 получает «RFNM» по номеру канала NCP.Подпрограммы будут вызываться с указателем на PDB сообщение. Когда процедура возвращается, модуль 1822 отбрасывает сообщение. -16- IEN-166 Р. Хинден Bolt Beranek и Newman Inc. Январь 1981 г. 6. Интернет-протокол 6.1 Назначение идентификатора Когда интернет-модуль получает сообщение для отправки, он генерирует значение для поля «Идентификатор» (ID) в Интернете заголовок.Он делает это, сохраняя 16-битный счетчик, называемый ID. прилавок. Когда ему нужно новое значение, он увеличивает счетчик на one и использует результат. Счетчик ID не будет инициализирован при перезагрузке или перезапуске TAC, чтобы гарантировать, что значения являются последовательными. 6.2 Поддержка опций Интернет-модуль будет активно поддерживать только "Ошибка Отчет "Параметр IP. Ни один из других параметров, определенных в настоящее время" потребует выполнения каких-либо действий со стороны TAC. 6.3 Повторная сборка Когда интернет-модуль получает PDB, который является дейтаграммой фрагмент, он должен собрать его заново.Сначала он смотрит на фрагменты в очереди Internet-Reassembly, чтобы узнать, есть ли другие фрагменты той же дейтаграммы. Это делается путем сравнения адрес источника, идентификатор и номер протокола двух фрагментов. Если -17- IEN-166 Р. Хинден Bolt Beranek и Newman Inc. Январь 1981 г. он не находит совпадения, он добавляет новый PDB в очередь.В в этот момент он также помещает метку времени в PDB. Это будет используется для тайм-аута разобранных фрагментов. Фактический процесс сборки состоит из добавления MBLK. новой дейтаграммы в список MBLK дейтаграммы на очередь. Это делается с помощью параметров «Смещение», «Длина» и Поля «Указатель на данные» в MBLK. На данный момент в обработка фрагмента, фрагмент состоит из одного или нескольких MBLK связаны вместе. Заголовок IP всегда будет первым МБЛК.Поля "Offset" в MBLK все равны нулю (нет отсутствующие данные в самом новом фрагменте). Поля "Длина" содержат длину данных IP (не включая заголовок IP) в каждом МБЛК. Поля «Указатель на данные» указывают на IP-данные. в каждом МБЛК. MBLK новой дейтаграммы добавляются в дейтаграмму на очередь, сравнивая «Смещение фрагмента» в IP-заголовке новую дейтаграмму к «Смещению фрагмента» в IP-заголовке дейтаграмма в очереди повторной сборки.Это делается путем взятия первый MBLK в списке и добавление «Смещения фрагмента» из Заголовок IP в поля «Длина» и «Смещение» в первом MBLK. Если эта сумма больше, чем «Смещение фрагмента» в IP заголовок новой дейтаграммы, затем MBLK новой дейтаграммы должен стоять перед первым MBLK дейтаграммы в исходной -18- IEN-166 Р. Хинден Bolt Beranek и Newman Inc.Январь 1981 г. фрагмент. Если нет, то их следует добавить после. В этом случае процесс сравнения повторяется с остальной частью МБЛК в списке. Когда подходящее место найдено, новые MBLK связаны, а поля нового и старого MBLK отрегулирован. Если новый фрагмент перекрывает существующий, то по при настройке полей «Указатель на данные» и «Длина» перекрытие можно пропустить. Это может привести к тому, что один или несколько MBLK будут отброшен.Когда дейтаграмма полностью собрана, ее можно снято с очереди повторной сборки и передано следующему протоколу модуль. 6.4 Маршрутизация Решение о том, куда отправить дейтаграмму, двоякое. Если целевой хост находится в той же сети, что и TAC, тогда дейтаграмма отправляется непосредственно на этот хост. Если нет, то это должно быть отправлено на шлюз. Интернет-модуль будет вести таблицу, которая будет облегчить маршрутизацию сообщений к хостам в других сетях.В таблица - это список всех сетей (256) и шлюзов, к которым нужно добраться сети. Эта таблица, называемая таблицей сетевого шлюза, будет будут изначально загружены в TAC и будут динамически -19- IEN-166 Р. Хинден Bolt Beranek и Newman Inc. Январь 1981 г. поддерживается TAC. Когда интернет-модулю нужно найти адрес, он ищет в таблице Network-Gateway, чтобы получить адрес шлюза для сеть, в которую он хочет отправить.Если он находит адрес, он его использует. Если запись для сети, которую она хочет, пуста (т. Е. Нет шлюза адрес указан), то Интернет-модуль будет использовать произвольный шлюз. Если интернет-модуль получает сообщение о перенаправлении от шлюз, он обновит таблицу Network-Gateway, чтобы указать правильный шлюз. Это гарантирует, что таблица Network-Gateway содержит актуальную информацию. Если шлюз выходит из строя во время подключения к Интернету модуль очистит запись этой сети в Network-Gateway стол.Затем он попытается использовать произвольный шлюз. Если позже время, Интернет-модуль получает сообщение перенаправления, сообщающее ему чтобы использовать новый шлюз для доступа к сети, он установит запись сети в таблице Network-Gateway для нового шлюза адрес. 6.5 Межсетевые сообщения Интернет-модуль будет поддерживать «От шлюза к шлюзу». протокол в пассивном смысле. Если он получает "Пункт назначения -20- ИЭН-166 Р.Hinden Bolt Beranek и Newman Inc. Январь 1981 г. Недостижимый пакет "или" Пакет с переадресацией "потребуется соответствующее действие. Если он получит что-нибудь еще, он отказаться от сообщения. В частности, если интернет-модуль получает «Пакет подавления источника», он отбрасывает сообщение. Эта стратегия используется из-за ограниченного количества TAC буферизация. Буферы скоро заполнятся из-за данных. не подтверждается (в TCP).Это эффективно ограничит коробка передач. 6.6 Тайм-ауты Интернет-фрагменты будут отброшены, если они не собрана в течение 60 секунд. Когда новый фрагмент повторно собранный в существующий, поле "Тайм-аут" в PDB существующий фрагмент будет обновлен с учетом текущего времени. Это, по сути, сбросит таймер для этого фрагмента. 7. Протокол управления передачей 7.1 Открытие и закрытие соединения Модуль TCP будет иметь конечный автомат, который будет использоваться для установления и закрытия соединений.Процедура открыть соединение - значит передать необходимую информацию (Адрес назначения, сокет и т. Д.) В модуль TCP. Так и будет -21- IEN-166 Р. Хинден Bolt Beranek и Newman Inc. Январь 1981 г. затем запустите конечный автомат, который настроит требуемые структуры данных и откройте соединение. Закрытие соединения будет сделано аналогичным образом.Состояния конечного состояния машина будет похожа на описанную в «IEN-129, DOD Стандартный протокол управления передачей ». Все номера TCP-портов, присвоенные TAC, будут состоять из старшие 8 бит установлены на номер терминала для подключения (1- 64.), а младшие 8 бит установлены на 23. Все соединения сделаны с или от TAC будет использовать этот формат. 7.2 Присвоение начального порядкового номера Модуль TCP будет поддерживать 32-битный счетчик, который будет используется для генерации начальных порядковых номеров (ISN).Счетчик будет увеличиваться на постоянное значение каждый раз, когда H-316 часы тикают, то есть каждые 25,6 мс. Счетчик будет увеличивается на 64. Это будет примерно каждые 4,55 часа. Когда модулю TCP требуется ISN, он читает счетчик и получает значение. 7.3 Поддержка опций Модуль TCP понимает формат всех TCP параметры. Он будет поддерживать режимы «Нет операции» и «Конец варианта». -22- ИЭН-166 Р.Hinden Bolt Beranek и Newman Inc. Январь 1981 г. Список "параметров. Он не поддерживает параметр" Размер буфера ". Если он получает параметр «Размер буфера» со значением, превышающим размер один, он не примет соединение, но сбросит его. 7.4 Срочные данные Когда модуль TCP получает сообщение с действительным срочным Указатель, он устанавливает бит в слове «Флаг» в PDB и сохраняет смещение до конца срочных данных.Когда следующий протокол модуль берет данные из MBLK, он получит указание, что данные, которые он получает, являются срочными. Аналогичным образом, когда модулю TCP предоставляются данные для отправки, модуль протокола, предоставляющий данные, может включать индикацию того, что данные срочные. Модуль TCP будет включать эту информацию во всех отправляемых сообщениях до тех пор, пока не будут отправлены срочные данные. 7.5 Окончание обработки писем Модуль TCP не будет делать ничего особенного при получении сообщение с установленным концом письма (EOL).Модуль TCP всегда представляет все данные следующему модулю протокола, как только он доступный. Следовательно, никакого специального обращения не требуется. -23- IEN-166 Р. Хинден Bolt Beranek и Newman Inc. Январь 1981 г. Модуль TCP будет принимать данные для отправки с EOL. индикация. Он отправит эти данные с установленным в сообщении EOL.Никаких дополнительных данных в сообщении не будет. Если данные требуется для повторной передачи, он будет передан с EOL сохранились. 7.6 Повторные передачи Данные, передаваемые модулем TCP, будут храниться пока он не будет подтвержден удаленным хостом. Если ACK не полученные данные в течение трех секунд будут ретранслируется. Все данные в буфере, которые не подтверждены, будут передано повторно (кроме случая, когда установлен EOL; см. предыдущий раздел).Если данные все еще не подтверждены еще семь секунд, повторная передача произойдет снова. Эта процедура будет продолжена используя ряды 3,7,15,15,30. Если ACK по-прежнему нет, то пользователь будет уведомлен. Ретрансляции будут продолжены каждые 30 секунд, пока пользователь не закроет соединение или модуль TCP получает ACK. 7.7 Подтверждение и стратегия окна Параметры подтверждения (ACK) и окна используются для контролировать, сколько данных удаленный хост может отправить в TAC.В -24- IEN-166 Р. Хинден Bolt Beranek и Newman Inc. Январь 1981 г. Модуль TCP будет передавать данные ACK до предела, который он желает буферизовать для связи. Данные, полученные после достижения этого лимита, будут быть отброшенным. По мере поступления данных, но до следующего модуль протокола забирает его из буфера, окно будет закрывается полученной суммой.Когда предел буфера достигнут, модуль TCP не будет подтверждать новые данные и будет рекламировать нулевое окно. Когда следующий модуль протокола берет данные из буфер, окно будет открыто. Это позволит удаленный хост для отправки большего количества данных. Когда данные отправляются по соединению, текущий ACK и Значения окна всегда включаются в одно и то же сообщение. в случай, когда данные не отправляются и значения ACK и / или Window изменились, используется другая стратегия.Когда указатель ACK расширен, модуль TCP будет ждать одну секунду, чтобы увидеть, есть ли это данные для отправки. Если в течение одной секунды данные не отправлялись, тогда ACK будет отправлен без данных. Новое значение окна будет не отправляются, пока буфер не станет хотя бы наполовину пустым. Этот стратегия предназначена для обеспечения того, чтобы удаленный хост отправлял блоки данных и исключить ненужные повторные передачи. 7.8 Последовательность Когда модуль TCP получает сообщение с данными для соединения, он должен гарантировать, что данные упорядочены до передачи данных -25- ИЭН-166 Р.Hinden Bolt Beranek и Newman Inc. Январь 1981 г. к следующему модулю протокола. Секвенирование выполняется путем сравнения порядковый номер сообщения в текущем «левом окне» Кромка (LWE) и манипулирование «смещением», «длиной» и поля «указатель на данные» MBLK, составляющих сообщение. Для каждого соединения ведется список MBLK, которые последовательность. MBLK в порядке, но данные могут отсутствовать.Когда модуль TCP готов к упорядочиванию данных, сообщение состоит из PDB, за которым следуют один или несколько связанных MBLK вместе. Поле "указатель на данные" указывает на фактический TCP. данные. Поля "смещения" все равны нулю, потому что данные в сообщение является последовательным относительно самого себя. Поле "длина" количество данных в каждом MBLK. Секвенирование выполняется путем связывания MBLK нового сообщение в список последовательности для подключения, для которого сообщение данных предназначено.Это делается с помощью следующих шагов: 1. Вычтите LWE из порядкового номера сообщение. Результат - смещение от LWE. потом установите этот результат в поле «смещение» первого MBLK. Если он равен нулю, это означает, что отсутствующих данных нет. В противном случае результатом будет количество отсутствующих данных. 2. Добавьте MBLK в существующий список. Если нет MBLK в списке, затем новые MBLK становятся списком. В противном случае вставка выполняется следующим образом: а) Найдите позицию, в которую нужно добавить новый MBLK. сложив вместе «смещение» и «длину» первый МБЛК в списке.Если "смещение" нового МБЛК меньше суммы, то новый МБЛК идет перед MBLK в списке. В противном случае добавьте -26- IEN-166 Р. Хинден Bolt Beranek и Newman Inc. Январь 1981 г. "смещение" и "длина" следующего MBLK в список к предыдущей сумме.Повторите эту процедуру пока не будет найден подходящий вариант или до конца списка. б) Свяжите новый MBLK со списком. c) Вычтите ("смещение" + "длина") из предыдущий МБЛК из "зачета" нового МБЛК. г) Вычтите ("смещение" + "длина") нового МБЛК со «зачета» очередного МБЛК. 0 перекрывающиеся данные будут обрабатываться путем настройки поля "длина" в MBLK, поскольку связаны новые MBLK. Результатом этих операций является список MBLK.В Поле "смещение" в MBLK содержит количество отсутствующих данных байты перед ним. Когда MBLK находится в начале списка, нулевое «смещение» означает, что данные упорядочены и могут быть переданы в следующий модуль протокола. Как данные принимаются следующим протоколом модуль, поле "длина" первого MBLK должно быть уменьшено. Когда он равен нулю, блок пуст и может быть отброшен. -27-

Сетевая рабочая группа W.Эдди Запрос комментариев: 4987 Verizon Категория: Информационное Август 2007 Атаки TCP SYN Flooding и общие меры по их устранению Статус этой памятки Эта памятка содержит информацию для Интернет-сообщества. Оно делает не указывать какие-либо стандарты Интернета. Распространение этого памятка не ограничена. Уведомление об авторских правах Авторское право (C) IETF Trust (2007 г.). Абстрактный Этот документ описывает атаки TCP SYN-лавинной рассылки, которые были хорошо известен сообществу уже несколько лет.Различный меры противодействия этим атакам и компромиссы каждой из них, описаны. В этом документе хранятся объяснения атак и общие методы защиты для разработчиков TCP и администраторов TCP-серверов или сетей, но не делает никаких рекомендации на уровне стандартов. Оглавление 1. Введение . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Описание атаки. . . . . . . . . . . . . . . . . . . . . . 2 2.1.История. . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Теория Операции . . . . . . . . . . . . . . . . . . . 3 3. Общая защита. . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Фильтрация. . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Увеличение отставания. . . . . . . . . . . . . . . . . . . . 7 3.3. Уменьшение таймера SYN-RECEIVED. . . . . . . . . . . . . . . 7 3.4. Утилизация самого старого полуоткрытого УТС. . . . . . . . . . . . 7 3.5. Кэш SYN. . . . . . . . . . . . . . . . . . . . . . . . 8 3.6. SYN-файлы cookie. . . . . . . . . . . . . . . . . . . . . . . 8 3.7. Гибридные подходы. . . . . . . . . . . . . . . . . . . . 10 3.8. Межсетевые экраны и прокси. . . . . . . . . . . . . . . . . . 10 4. Анализ. . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Соображения безопасности. . . . . . . . . . . . . . . . . . . 13 6. Благодарности. . . . . . . . . . . . . . . . . . . . . . . 13 7.Информативные ссылки. . . . . . . . . . . . . . . . . . . . 13 Приложение A. Описание файлов cookie SYN. . . . . . . . . . . . . . . 16 Эдди Информационный [Страница 1] RFC 4987 TCP SYN Flooding, август 2007 г. 1. Введение Атака SYN-лавинной рассылки - это метод отказа в обслуживании, влияющий на хосты. которые запускают процессы TCP-сервера. Атака использует сохранение состояния TCP выполняет некоторое время после получения SYN сегмент к порту, который был переведен в состояние LISTEN.Базовый идея состоит в том, чтобы использовать это поведение, заставляя хост сохранять достаточно указать для фиктивных полусоединений, что не осталось ресурсов для устанавливать новые законные связи. Эта атака SYN-флуда была хорошо известна сообществу по много лет, и был замечен в дикой природе операторами сети и конечные хосты. Был разработан и внедрен ряд методов. чтобы сделать SYN-флуд менее эффективным. Несмотря на дурную славу атаки и широко доступные контрмеры, только серия RFC задокументировал уязвимость в качестве примера мотивации для проникновения фильтрация [RFC2827] и не предлагает никаких методов смягчения для реализаций TCP.В этом документе рассматриваются оба вопроса, но не определяет никаких стандартов. Формальные спецификации и требования защитных механизмов выходят за рамки этого документ. Многие средства защиты влияют только на реализацию конечного хоста. без изменения совместимости. Это может не потребовать стандартизация, но их побочные эффекты должны быть, по крайней мере, хорошо понял. Этот документ намеренно фокусируется на атаках SYN-флуда со стороны точка зрения отдельного конечного хоста или приложения как средство отрицания услуга этой конкретной организации.Атаки с высокой скоростью передачи пакетов, которые нацелить возможности сети на обработку пакетов и пропускную способность наблюдались в оперативном режиме. Поскольку такие атаки нацелены на сеть, а не реализация TCP, они выходят за рамки этого документ, независимо от того, используют ли они сегменты TCP SYN как часть атаки, так как характер используемых пакетов не имеет значения сравнение со скоростью передачи пакетов в таких атаках. Большая часть этого документа состоит из трех разделов. Раздел 2 более подробно объясняет атаку SYN-лавинной рассылки.Несколько общих методы смягчения последствий описаны в Разделе 3. Анализ и обсуждение этих методов и их использования представлено в Раздел 4. Дополнительная информация о файлах cookie SYN содержится в Приложение. 2. Описание атаки В этом разделе описывается история и техническая база атака SYN-флуда. Эдди Информационный [Страница 2] RFC 4987 TCP SYN Flooding, август 2007 г. 2.1. История Уязвимость TCP SYN флуда была обнаружена еще в 1994 году Биллом. Чесвик и Стив Белловин [B96]. Они включили, а затем удалили, параграф об атаке в их книге «Межсетевые экраны и Интернет. Безопасность: отражение коварного хакера »[CB94]. К сожалению, нет контрмеры были разработаны в течение следующих двух лет. Атака SYN-флуда была впервые опубликована в 1996 году. выпуск описания и инструмента эксплойтов в журнале Phrack Magazine [P48-13]. Эта статья содержит незначительные неточности. достаточно высокого качества, чтобы быть полезным, а код из статьи был широко распространены и используются.К сентябрю 1996 г. атаки SYN-флуда наблюдались в дикий. В частности, атака на почтовые серверы одного интернет-провайдера привела к широко разрекламированные отключения. CERT быстро выпустил рекомендацию по атака [CA-96.21]. SYN-флуд был особенно серьезным в сравнение с другими известными в то время атаками типа «отказ в обслуживании». Вместо того, чтобы полагаться на обычную тактику грубой силы, просто исчерпывая ресурсы сети, SYN-лавинная атака нацелена на конечный хост ресурсы, для исчерпания которых требуется меньшее количество пакетов.Сообщество быстро разработало множество самых разных методов для предотвращение или ограничение воздействия атак SYN-флуда. Многие из в той или иной степени они были развернуты в Интернете, в обоих конечные хосты и промежуточные маршрутизаторы. Некоторые из этих методов имеют становятся важными частями реализации TCP в определенных операционные системы, хотя некоторые из них значительно отличаются от TCP спецификации, и ни один из этих методов еще не стандартизирован или санкционированы процессом IETF.2.2. Теория Операции Как описано в RFC 793, реализация TCP может разрешить LISTEN состояние, в которое нужно войти со всеми, некоторыми или ни с одним из пары IP-адресов адреса и номера портов, указанные в приложении. Во многих общие приложения, такие как веб-серверы, ни один из удаленных хостов информация заранее известна или предварительно сконфигурирована, так что соединение может быть установленным с любым клиентом, детали которого неизвестны сервер раньше времени. Этот тип "несвязанного" LISTEN является целью Атаки SYN-флуда из-за того, как они обычно реализуются операционные системы.Для успеха атака SYN-флуда полагается на TCP хоста жертвы. поведение реализации. В частности, предполагается, что потерпевший распределяет состояние для каждого сегмента TCP SYN при его получении, и что существует ограничение на количество такого состояния, которое может быть сохранено в Эдди Информационный [Страница 3] RFC 4987 TCP SYN Flooding, август 2007 г. любое время. Текущая базовая спецификация TCP, RFC 793 [RFC0793], описывает стандартную обработку входящих сегментов SYN.RFC 793 описывает концепцию данных блока управления передачей (TCB). структура для хранения всей информации о состоянии для человека связь. На практике операционные системы могут реализовать это концепция несколько отличается, но главное в том, что каждое TCP-соединение требует некоторого места в памяти. Согласно RFC 793, когда SYN получен для локального TCP-порта, где соединение находится в состоянии LISTEN, затем состояние переходит в SYN- ПОЛУЧЕНО, и часть TCB инициализируется информацией из поля заголовка полученного сегмента SYN.На практике многие операционные системы не изменяют TCB в LISTEN, а вместо этого создают копию TCB и выполнить переход состояния и обновление на копировать. Это сделано для того, чтобы локальный TCP-порт мог использоваться совместно несколько отличных связей. Это поведение копирования TCB не действительно необходим для этой цели, но влияет на то, как приложения, которые хотят обрабатывать несколько одновременных подключений через единственный порт TCP пишутся. Решающий результат этого поведение заключается в том, что вместо обновления уже выделенной памяти новый (или неиспользуемая) память должна быть выделена для скопированного TCB.Например, в сетевом коде Linux 2.6.10 "sock" структура используется для реализации концепции TCB. Судя по экспертизе, это структура занимает более 1300 байт для хранения в памяти. В других системах реализующие менее сложные алгоритмы и параметры TCP, накладные расходы может быть меньше, хотя обычно превышает 280 байт [SKK + 97]. Чтобы защитить память хоста от исчерпания запросами на подключение, количество структур TCB, которые могут быть резидентными в любое время, равно обычно ограничивается ядрами операционной системы.Системы различаются в зависимости от того, ограничения применяются глобально или локально для определенного номера порта. Также существуют различия в отношении того, применяются ли ограничения к полной установленные соединения, а также соединения в SYN-RECEIVED. Обычно системы реализуют параметр для типичного системного вызова listen () который позволяет приложению предлагать значение для этого лимита, называемого отставание. При достижении лимита невыполненных работ либо входящие Сегменты SYN игнорируются, или незавершенные соединения в невыполненной работе заменены.Концепция использования бэклога не описана в стандарты, поэтому поведение при сбоях при невыполнении заданий достигнутые значения могут отличаться между стеками (например, TCP RST могут быть сгенерировано). От точного поведения при сбое будет зависеть, будет ли инициирующие хосты продолжают повторно передавать сегменты SYN с течением времени, или быстро перестанут. Эти различия в реализации приемлемы. поскольку они влияют только на поведение локального стека, когда его ресурсы ограничены и не вызывают взаимодействия проблемы.Эдди Информационный [Страница 4] RFC 4987 TCP SYN Flooding, август 2007 г. Атака SYN-флуда не пытается перегрузить сеть. ресурсов или памяти конечного хоста, но просто пытается исчерпать отставание полуоткрытых соединений, связанных с номером порта. Цель состоит в том, чтобы отправить быстрый поток сегментов SYN с IP-адресов. (часто подделываются), которые не будут генерировать ответы на SYN-ACK, которые производятся.Сохраняя бэклог, полный фальшивых полуоткрытых соединения, законные запросы будут отклонены. Три важных Параметры атаки для успеха - размер заграждения, частота, с которой создаются заграждения, и средства выбор IP-адресов для подмены. Размер заграждения Чтобы заграждение было эффективным, его размер должен быть достаточно большим. чтобы добраться до отставания. В идеале размер заграждения не должен превышать отставание, сводя к минимуму объем трафика, который злоумышленник должен источник.Типичные значения невыполненной работы по умолчанию варьируются от полдюжины до несколько десятков, поэтому атака может быть адаптирована к конкретному значение определяется хостом жертвы и приложением. На машинах предназначены для использования в качестве серверов, особенно для большого объема трафика, заделы часто административно настраиваются на более высокие ценности. Частота обстрела Чтобы ограничить время существования полуоткрытого состояния соединения, TCP реализации обычно восстанавливают память из полуоткрытого соединения, если они не открываются полностью через некоторое время период.Например, может быть установлен таймер на 75 секунд [SKK + 97]. при отправке первого SYN-ACK и по истечении срока вызвать SYN-ACK прекратить повторные передачи и освободить УТС. ПТС спецификации не включают в себя отказ от установление соединения через произвольное время. Некоторые пуристы заявили, что реализация TCP должна продолжаться повторная передача сегментов SYN и SYN-ACK без искусственных границ (но с экспоненциальным откатом до некоторой консервативной скорости) до тех пор, пока приложение сдается.Несмотря на это, общие операционные системы сегодня действительно внедряем искусственный лимит на полуоткрытый TCB продолжительность жизни. Например, отступление и остановка после того, как 511 секунд можно наблюдать в 4.4 BSD-Lite [Ste95], и это все еще практикуется в некоторых операционных системах, производных от этого кода. Чтобы оставаться эффективной, атака SYN-флуда должна отправлять новые поток поддельных запросов на соединение, как только TCB из предыдущий заградительный огонь начинают восстанавливать.Частота заграждений адаптированы к восстановлению TCB реализации TCP жертвы таймер. Частоты выше, чем необходимо, отправляют больше пакетов, потенциально привлекает больше внимания, и частоты, которые слишком Эдди Информационный [Страница 5] RFC 4987 TCP SYN Flooding, август 2007 г. низкий позволит окнам времени, когда законные соединения могут быть учредил. Выбор IP-адреса Для эффективной атаки важно, чтобы поддельный IP адреса не реагируют на сегменты SYN-ACK, которые жертва будет генерировать.Если используются адреса обычных подключенных хостов, затем эти хосты отправят жертве сегмент сброса TCP, который немедленно освободит соответствующий TCB и освободит место в невыполнение законных подключений. Код распространенная в оригинальной статье Phrack, использовала единственный источник адрес для всех поддельных сегментов SYN. Это делает атаку сегменты несколько легче идентифицировать и фильтровать. Сильный у злоумышленника будет список неотвечающих и не связанных адресов что он выбирает поддельные адреса источника.Важно отметить, что эта атака направлена ​​на определенные прослушивание приложений на хосте, а не сам хост или сеть. Атака также пытается предотвратить только создание новых входящих подключений к порту жертвы, и не влияет исходящие запросы на соединение или ранее установленные соединения в порт жертвы. На практике злоумышленник может отказаться от использования поддельного IP-адреса. адресов, но вместо этого использовать множество хостов для инициации SYN атака затоплением.Например, набор скомпрометированных хостов под контролем злоумышленника (т. е. «ботнет»). В в этом случае каждый хост, используемый в атаке, должен подавить собственный ответ операционной системы на SYN-ACK, поступающий от цель. Также возможно, что атакующие сегменты TCP поступают более непрерывно, чем терминология "заграждения" используется здесь предполагает; пока скорость новых SYN превышает скорость на котором собираются TCB, атака будет успешной.3. Общая защита В этом разделе обсуждается ряд известных методов защиты. сообществу, многие из которых доступны в готовом виде продукты. 3.1. Фильтрация Поскольку при отсутствии армии контролируемых хостов возможность для этого требуется отправлять пакеты с поддельными исходными IP-адресами атака работает, лишая злоумышленника возможности отправлять поддельный IP-адрес пакеты - эффективное решение, не требующее изменений в TCP. Методы фильтрации, описанные в RFC 2827, 3013 и 3704 Эдди Информационный [Страница 6] RFC 4987 TCP SYN Flooding, август 2007 г. представляют лучшие текущие практики для фильтрации пакетов на основе IP адреса [RFC2827] [RFC3013] [RFC3704].Хотя совершенно эффективно, конечные хосты не должны полагаться на политики фильтрации для предотвращения атак из поддельных сегментов, поскольку глобальное развертывание фильтров не гарантировано и вероятно. Злоумышленник с возможностью использовать группу скомпрометированных хостов или быстро переключаться между разными способами доступа провайдеры также сделают фильтрацию бессильным решением. 3.2. Увеличение отставания Очевидная попытка защиты заключается в том, чтобы конечные хосты использовали более крупный отставание. Лимон показал, что в FreeBSD 4.4, эта тактика имеет некоторые серьезные негативные моменты по мере роста размера бэклога [Lem02]. Реализация не предназначена для масштабирования прошлых невыполненных заказов несколько сотен, а также структуры данных и алгоритмы поиска, которые использование неэффективно из-за больших невыполненных заказов. Разумно предполагаем, что другие реализации TCP имеют аналогичные конструктивные факторы которые ограничивают их производительность из-за большого количества невыполненных работ, и, похоже, не может быть веской причины, по которой стеки следует модернизировать для поддержки чрезвычайно большие задержки, поскольку доступны другие решения.Однако эксперименты с большими задержками с использованием эффективных данных структуры и алгоритмы поиска не проводились, на наш знания. 3.3. Уменьшение таймера SYN-RECEIVED Еще одна быстро реализуемая защита - сокращение времени ожидания. период между получением SYN и получением созданного TCB из-за отсутствия прогресса. Уменьшение таймера, ограничивающего время жизни TCB в SYN-RECEIVED также есть изъяны. В то время как более короткий таймер будет держать попытки фиктивного подключения в течение длительного времени в невыполненной работе, и, таким образом, быстрее освободить место для законных подключений, он может не допустить, чтобы некоторая часть легитимных подключений стала полностью учредил.Эта тактика также неэффективна, потому что она только требует от атакующего увеличить частоту обстрела на линейно пропорциональная сумма. Это сокращение таймера иногда реализуется в ответ на превышение некоторого порога занятости отставания, или некоторая скорость приема SYN. 3.4. Утилизация самого старого полуоткрытого УТС Когда весь бэклог исчерпан, некоторые реализации позволяют входящие SYN для перезаписи самой старой полуоткрытой записи TCB. Этот работает в предположении, что законные соединения могут быть полностью установлен за меньшее время, чем может быть заполнен за счет входящих атаковать SYN.Это может потерпеть неудачу, если скорость атакующих пакетов высока. и / или размер отставания невелик и не является надежной защитой. Эдди Информационный [Страница 7] RFC 4987 TCP SYN Flooding, август 2007 г. 3.5. SYN-кеш Кэш SYN, лучше всего описанный Lemon [Lem02], основан на минимизация количества состояний, которые выделяет SYN, т. е. не немедленно выделяя полный TCB. Полное государственное выделение задерживается до тех пор, пока соединение не будет полностью установлено.Хосты реализация кеша SYN имеет некоторые секретные биты, которые они выбирают из входящие сегменты SYN. Секретные биты хешируются вместе с IP-адреса и TCP-порты сегмента, а также значение хеш-функции определяет место в глобальной хеш-таблице, где неполный TCB хранится. Для каждого значения хеш-функции существует предел сегмента, и когда этот предел достигнут, самая старая запись отбрасывается. Метод кеширования SYN эффективен, потому что секретные биты предотвращают злоумышленник от возможности нацелить определенные хеш-значения для превышение предела ведра, и это ограничивает как время процессора, так и требования к памяти.Оценка кеша SYN, проведенная Лимоном, показывает, что даже в условиях, когда атака SYN-флуда не выполняется. выполнено, из-за измененного пути обработки, подключение установление несколько целесообразнее. При активной атаке SYN Производительность кеша примерно линейно сдвигается распределение времени для установления законных подключений примерно к На 15% дольше, чем без атаки [Lem02]. Если данные сопровождают сегмент SYN, то эти данные не подтвержден или сохранен получателем, и потребует ретрансляция.Это не влияет на надежность данных TCP. услуги передачи, но это влияет на ее производительность до некоторой небольшой степень. SYN, переносящие данные, используются расширениями T / TCP. [RFC1644]. Хотя T / TCP реализован в ряде популярных операционных систем [GN00], в настоящее время, похоже, используется редко. Измерения на пограничном маршрутизаторе одного сайта [All07] зарегистрировали 2 545 785 SYN. сегментов (не SYN-ACK), 36 из которых несли опцию T / TCP CCNEW (или 0,001%). Они поступили с 26 уникальных хостов, и никакие другие T / TCP варианты были просмотрены.Было просмотрено 2287 сегментов SYN с данными (или 0,09% всех сегментов SYN), каждый из которых содержит ровно 24 байта данных. Эти наблюдения показывают, что проблемы с кешами SYN и данными на Сегменты SYN могут не иметь значения при развертывании. 3.6. SYN файлы cookie Файлы cookie SYN идут еще дальше и вообще не выделяют состояние для соединения в SYN-RECEIVED. Вместо этого они кодируют большую часть состояния (и все строго необходимое) заявляют, что они обычно сохранить в порядковом номере, переданном в SYN-ACK.Если SYN не было подделано, то номер подтверждения (вместе с несколькими другие поля) в ACK, который завершает рукопожатие, можно использовать для реконструировать состояние, которое будет помещено в TCB. На сегодняшний день один из Эдди Информационный [Страница 8] RFC 4987 TCP SYN Flooding, август 2007 г. лучшие ссылки на файлы cookie SYN можно найти в сети Дэна Бернштейна сайт [cr.yp.to]. Этот метод использует давно понятое низкое энтропия в полях заголовка TCP [RFC1144] [RFC4413].В Приложении А мы описать технику SYN cookie, чтобы избежать вероятности того, что веб-страница станет недоступной. Точный механизм кодирования состояния в последовательность SYN-ACK количество может зависеть от реализации. Общее соображение что для предотвращения повторного воспроизведения некоторые зависящие от времени случайные биты должны быть встроен в порядковый номер. В одном методе для этих бит и 25 бит для остальных данных [Lem02]. Один из способов закодировать эти бит был для XOR начального порядкового номера, полученного с усеченный криптографический хеш IP-адреса и номера TCP-порта пары и секретные биты.На практике этот хеш был сгенерирован с использованием MD5 [RFC1321]. Вместо этого можно использовать любой аналогичный односторонний хеш не влияя на совместимость, так как значение хеш-функции проверяется тот же хост, который его генерирует. Проблема с файлами cookie SYN заключается в том, что обычно применяемые схемы несовместим с некоторыми опциями TCP, если схема генерации cookie не считает их. Например, кодировка Максимального Размер сегмента (MSS), объявленный в SYN, был адаптирован использование 2 бита порядкового номера для представления 4 предопределенных общих MSS ценности.Аналогичные методы потребуются для некоторых других TCP. параметры, в то время как согласованное использование других параметров TCP может быть обнаружено неявно. Отметка времени в ACK, например, указывает, что Использование метки времени было успешно согласовано для SYN и SYN-ACK, при приеме опции выборочного подтверждения (SACK) на какой-то момент во время соединения подразумевает, что был согласован SACK. Обратите внимание, что блоки SACK обычно не должны отправляться хостом с использованием TCP. файлы cookie, если они не были получены впервые.Для общего однонаправленный поток данных во многих TCP-соединениях, это может быть проблема, поскольку это ограничивает использование SACK. По этой причине файлы cookie SYN обычно не используются по умолчанию в системах, которые их реализуют, и доступны только в условиях высокого напряжения, указывающих на атакой или административным действием. Недавно во FreeBSD была разработана новая технология SYN cookie. 7.0 использует биты опции Timestamp в дополнение к биты порядкового номера для состояния кодирования.Поскольку значение отметки времени отражается обратно в поле Timestamp Echo пакета ACK, любой состояние, сохраненное в опции Timestamp, может быть восстановлено аналогично таким образом, чтобы это было из порядкового номера / подтверждения в базовом SYN cookie. Используя биты отметки времени, можно явно хранить биты состояния для таких вещей, как масштаб окна отправки и получения, SACK-enabled и TCP-MD5-enabled, для которых нет места в типичный файл cookie SYN. Использование меток времени для улучшения компромиссы, присущие файлам cookie SYN, уникальны для FreeBSD Эдди Информационный [Страница 9] RFC 4987 TCP SYN Flooding, август 2007 г. реализация, насколько нам известно.Ограничение заключается в том, что метод может использоваться только в том случае, если сам SYN содержит параметр отметки времени, но эта опция, кажется, широко применяется сегодня, и хосты, которые поддерживает масштабирование окна, а SACK обычно также поддерживает временные метки. Подобно кешам SYN, файлы cookie SYN не обрабатывают данные приложения. совмещены с сегментом SYN. Другая проблема с файлами cookie SYN - для приложений, в которых первый данные приложения отправляются пассивным хостом. Если этот хост обработки большого количества подключений, то потеря пакетов может быть вероятно.Когда подтверждение завершения установления связи от инициатора потеряно, прикладной уровень пассивной стороны никогда не уведомляется о подключения и никогда не отправляет данные, даже если инициатор считает, что соединение было успешно учредил. Пример приложения, в котором первое приложение- данные уровня отправляются пассивной стороной - это SMTP, если он реализован согласно RFC 2821, где сообщение «готово к работе» отправляется пассивная сторона после завершения установления связи TCP.Хотя реализации файлов cookie SYN существуют и развернуты, использование файлов cookie SYN часто отключены в конфигурациях по умолчанию, поэтому неясно, сколько на самом деле существует опыта эксплуатации с ними или при их использовании открываются новые уязвимости. Анекдоты происшествий где файлы cookie SYN использовались на типичных веб-серверах, кажется, указывают на то, что дополнительная нагрузка на обработку вычислений сумм MD5 для каждый полученный пакет SYN не имеет значения по сравнению с потеря доступности приложения без защиты.Для некоторых мобильные или встроенные устройства с вычислительными ограничениями, это ситуация может быть другой. 3.7. Гибридные подходы Можно комбинировать методы кеширования SYN и файлов cookie SYN. Для Например, в случае, если кеш заполнен, тогда файлы cookie SYN могут быть отправлены вместо очистки записей кеша по прибытии новых SYNs. Такие гибридные подходы могут обеспечить сильную комбинацию положительные стороны каждого подхода. Лимон продемонстрировал полезность этого гибрида [Lem02].3.8. Межсетевые экраны и прокси Тактика на основе брандмауэра также может использоваться для защиты конечных хостов от SYN. атаки наводнения. Основная идея - разгрузить соединение процедуры установки на брандмауэр, который проверяет соединение попытки, пока они не будут завершены, а затем проксирует их обратно в защищенные конечные хосты. Это перемещает проблему с конечных хостов на стать проблемой брандмауэра или прокси-сервера и может привести к другим Эдди Информационный [Страница 10] RFC 4987 TCP SYN Flooding, август 2007 г. проблемы, связанные с изменением ожидаемой сквозной семантики TCP.А общая тактика, используемая в этих брандмауэрах и прокси-продуктах, заключается в том, чтобы реализовать один из методов на основе конечного хоста, описанных выше, и экранировать входящие SYN-сообщения из защищенной сети до установления соединения полностью установлено. Это достигается путем подмены источника. адреса нескольких пакетов инициатору и слушателю на разных этапы рукопожатия [Eddy06]. 4. Анализ Некоторые из защит, обсуждаемых в предыдущем разделе, основаны на изменения в поведении внутри сети; через фильтрацию маршрутизатора, межсетевые экраны и прокси.Они могут быть очень эффективными и часто не требуют модификации или настройки программного обеспечения конечного хоста. Данный мобильный характер и динамическое подключение многих конечных хостов, это оптимистично для разработчиков TCP предполагать наличие таких защитные устройства. Разработчики TCP должны предоставить некоторые средства защита от атак SYN-лавинной рассылки в реализациях конечных узлов. Среди модификаций конечного хоста приближаются SYN-кеш и SYN-cookie. кажутся единственными жизнеспособными методами, обнаруженными на сегодняшний день.Увеличение отставание и сокращение таймера SYN-RECEIVED ощутимо проблематично. Кэш SYN подразумевает больший объем памяти, чем Файлы cookie SYN; однако файлы cookie SYN могут быть не полностью совместимы с некоторые параметры TCP и могут препятствовать разработке будущих расширений TCP которые требуют государства. По этим причинам файлы cookie SYN не должны включены по умолчанию в системах, которые их предоставляют. Кеши SYN не имеют те же негативные последствия и могут быть включены по умолчанию режим обработки.В октябре 1996 года Дэйв Борман внедрил в BSDi кеш SYN для BSD / OS, предоставленная сообществу без ограничений. Этот код, кажется, является основой для реализаций SYN-кеша, принятых позже в других вариантах BSD. Кеш использовался, когда отставание стал полным, а не по умолчанию, как мы описали. Примечание к список рассылки tcp-impl объясняет, что этот код не передает повторно SYN-ACK [B97]. Более поздние реализации решили отменить это решение и повторно передать SYN-ACK.Известно, что потеря SYN- Пакеты ACK не редкость [SD01] и могут сильно замедлить производительность соединений при начальных таймерах ретрансляции для SYN слишком консервативны (как в некоторых операционных системах) или повторно переданные SYN теряются. Кроме того, если злоумышленник с флудом SYN имеет высокую скорость отправки, вероятно потеря повторно переданных SYN, поэтому, если SYN-ACK не передаются повторно, вероятность эффективного количество установленных легитимных соединений сокращается. Эдди Информационный [Страница 11] RFC 4987 TCP SYN Flooding, август 2007 г. В 1997 году NetBSD включила модифицированную версию кода Бормана.Два заметных отличия от исходного кода проистекают из решения использовать кеш по умолчанию (для всех подключений). Это подразумевало необходимо выполнить повторную передачу для SYN-ACK и использовать более крупный структуры для хранения более полных данных. Первоначальная структура была 32 байтов для подключений IPv4 и 56 байтов с поддержкой IPv6, в то время как текущая структура FreeBSD имеет длину 196 байт. Как раньше цитируется, Lemon реализовал методы кеширования SYN и файлов cookie в FreeBSD 4.4 [Lem02]. Лимон отмечает, что структура кэша SYN заняла 160 байт по сравнению с 736 для полного TCB (теперь 196 байт для структура кеша). Мы изучили код OpenBSD 3.6 и определили, что он включает аналогичный кэш SYN. Код Linux 2.6.5, также проверенный, содержит SYN cookie. реализация, которая кодирует 8 значений MSS и не использует SYN файлы cookie по умолчанию. Эта функция присутствовала в Linux ядро за несколько лет до версии 2.6.5. Когда кэш SYN и / или файлы cookie SYN реализованы с IPv6, Значение метки потока IPv6, используемое в SYN-ACK, должно соответствовать метка потока, используемая для остальных пакетов в этом потоке.Были ошибки реализации, из-за которых случайные метки потока использоваться в SYN-ACK, сгенерированных SYN-кешем и кодом SYN cookie [MM05]. Начиная с Windows 2000, операционные системы Microsoft Windows есть функция «Защита от TCP SYN атак», которую можно переключать включен или выключен в реестре. По умолчанию этот параметр отключен до Windows 2003. SP1, в котором он включен по умолчанию. Если эта функция включена, когда количество полуоткрытых соединений и полуоткрытых соединений с повторно переданные SYN-ACK превышают настраиваемые пороговые значения, тогда количество повторных передач SYN-ACK до отказа составляет сокращается, а создание "Route Cache Entry" откладывается, что предотвращает некоторые функции (например,g., масштабирование окна) от использования [win2k3-wp]. Некоторые производители коммерческих брандмауэров продают устройства, которые могут уменьшить влияние SYN-лавинной рассылки на конечные хосты путем проксирования соединений. Обнаружение и использование уязвимости SYN-флуда в TCP Дизайн послужил ценным уроком для разработчиков протоколов. Поток Протокол передачи управления [RFC2960], который был разработан более недавно добавили четырехстороннее рукопожатие с файлом cookie без сохранения состояния. компонент на основе для прослушивания.Таким образом, пассивные открытая сторона имеет лучшее свидетельство того, что инициатор действительно существует на заданный адрес до того, как он выделит какое-либо состояние. Идентификация хоста Базовый обмен протокола [MNJH07] аналогичным образом разработан как 4-сторонний рукопожатие, но также включает в себя головоломку, отправленную инициатору, которая должна Эдди Информационный [Страница 12] RFC 4987 TCP SYN Flooding, август 2007 г. быть решенным до того, как какое-либо состояние будет зарезервировано ответчиком.Генерал концепция проектирования безгражданства в настройке протокола, чтобы избежать Атаки отказа в обслуживании обсуждались Аурой и Никандером. [AN97]. 5. Соображения безопасности Атака SYN-флуда на TCP описывалась во многих других публикации, а также детали и код, необходимые для выполнения атаки были легко доступны в течение многих лет. Описывая атаку в этом документ не представляет опасности дальнейшего обнародования этого слабость в немодифицированных TCP-стеках.Несколько широко развернутых действующих системы реализуют методы смягчения, описанные в этом документе. обсуждает, как победить атаки SYN-флуда. По крайней мере в некоторых случаях эти операционные системы не позволяют использовать эти меры противодействия. дефолт; тем не менее, механизмы для защиты от SYN-лавинной рассылки хороши. развернуты и легко включены конечными пользователями. Публикация этого документ не должен влиять на количество атак SYN-флуда наблюдается, и может повысить надежность Интернета до таких атаки, поощряя использование общедоступных средств защиты.6. Благодарности Разговор с Тедом Фабером послужил толчком к написанию этой статьи. документ. Комментарии и предложения от Джо Тач, Дэйва Бормана, Фернандо Гонт, Жан-Батист Маршан, Кристиан Уитема, Кейтлин Бестлер, Пекка Савола, Андре Опперманн, Альфред Хенес, Марк Оллман, Ларс Эггерт, Паси Эронен, Уоррен Кумари, Дэвид Мэлоун, Рон Боника, и Лиза Дюссо были полезны в укреплении этого документа. В оригинальная работа над файлами cookie TCP SYN, представленная в Приложении A, связана с Д.Дж. Бернштейн. Работа над этим документом проводилась в Исследовательском центре Гленна НАСА. Финансирование было частично обеспечено комбинацией Advanced NASA Архитектуры и системы связи, навигации и наблюдения Технологии (ACAST), Sensis Corporation, NASA's Space Рабочая группа по архитектуре связи и НАСА по наукам о Земле Технологический офис. 7. Информативные ссылки [AN97] Аура, Т. и П. Никандеры, "Связи без гражданства", Материалы Первой Международной конференции по Информационная и коммуникационная безопасность, 1997.[All07] Оллман, М., «личное сообщение», февраль 2007 г. Эдди Информационный [Страница 13] RFC 4987 TCP SYN Flooding, август 2007 г. [B96] Беннахум, Д., "PANIX ATTACK", цМем 2.12, октябрь 1996 г., . [B97] Борман, Д., "Re: файлы cookie SYN / RST (был Re: разъяснение ...) ", список рассылки IETF tcp-impl, Июнь 1997 г. [CA-96.21] CERT, "Рекомендации CERT CA-1996-21 TCP SYN Flooding и IP Спуфинг-атаки ", сентябрь 1996 г.[CB94] Чесвик, В. и С. Белловин, «Межсетевые экраны и Интернет. Безопасность », ISBN: 0201633574, январь 1994 г. [Eddy06] Эдди У., "Защита от атак TCP SYN Flooding", Журнал Cisco Internet Protocol, том 8, номер 4, Декабрь 2006 г. [GN00] Гриффин М. и Дж. Нельсон, "T / TCP: TCP для Транзакции », Linux Journal, февраль 2000 г. [Lem02] Лемон, Дж., "Противодействие DoS-атакам SYN Flood с помощью SYN Кэш », BSDCON 2002, февраль 2002 г.[MM05] МакГанн, О. и Д. Мэлоун, "Фильтрация этикеток потока" Осуществимость », Европейская конференция по компьютерным сетям Защита 2005 г., декабрь 2005 г. [MNJH07] Московиц, Р., Никандер, П., Йокела, П., и Т. Хендерсон, "Протокол идентификации хоста", работа в процессе, Июнь 2007 г. [P48-13] daemon9, route и infinity, «Проект Нептун», Phrack Журнал, том 7, выпуск 48, файл 13 от 18 июля 1996 г. [RFC0793] Постел, Дж., «Протокол управления передачей», STD 7, RFC 793, сентябрь 1981 г. [RFC1144] Якобсон, В., "Сжатие заголовков TCP / IP для низкоскоростной последовательные ссылки », RFC 1144, февраль 1990 г. [RFC1321] Ривест Р., "Алгоритм дайджеста сообщений MD5", RFC 1321, апрель 1992 г. [RFC1644] Брейден Б., «T / TCP - расширения TCP для транзакций. Функциональная спецификация », RFC 1644, июль 1994 г. Эдди Информационный [Страница 14] RFC 4987 TCP SYN Flooding, август 2007 г. [RFC2827] Фергюсон П.и Д. Сени, "Фильтрация входящего сетевого трафика: Отражение атак типа "отказ в обслуживании" с использованием IP Подмена адреса источника ", BCP 38, RFC 2827, май 2000 г. [RFC2960] Стюарт, Р., Се, К., Морно, К., Шарп, К., Шварцбауэр, Х., Тейлор, Т., Ритина, И., Калла, М., Чжан, Л., и В. Паксон, "Передача управления потоком Протокол », RFC 2960, октябрь 2000 г. [RFC3013] Killalea, T., "Рекомендуемый интернет-провайдер. Услуги и процедуры безопасности », BCP 46, RFC 3013, Ноябрь 2000 г.[RFC3704] Бейкер, Ф. и П. Савола, "Фильтрация входящего трафика для Многосетевые сети ", BCP 84, RFC 3704, март 2004 г. [RFC4413] Вест, М. и С. Макканн, "Поведение поля TCP / IP", RFC 4413, март 2006 г. [SD01] Седди, Н. и М. Деветсикиотис, "Исследования TCP Механизм тайм-аута повторной передачи ", Труды 2001 Международная конференция IEEE по коммуникациям (ICC 2001), том 6, страницы 1834-1840, июнь 2001 г.[SKK + 97] Шуба, К., Крсул, И., Кун, М., Спаффорд, Э., Сундарам, А. и Д. Замбони, "Анализ отказа в обслуживании Атака на TCP », Материалы симпозиума IEEE 1997 г. о безопасности и конфиденциальности 1997. [Ste95] Стивенс, В. и Г. Райт, "TCP / IP Illustrated, том 2: Реализация », январь 1995 г. [cr.yp.to] Бернштейн, Д., "Файлы cookie SYN", посещение в декабре 2005 г., . [win2k3-wp] Корпорация Microsoft, "Microsoft Windows Server 2003 Подробности реализации TCP / IP », Белая книга, июль 2005 г.Эдди Информационный [Страница 15] RFC 4987 TCP SYN Flooding, август 2007 г. Приложение A. Описание файлов cookie SYN Эта информация взята с веб-страницы Бернштейна о файлах cookie SYN. [cr.yp.to]. Это переписывание технической информации об этом веб-страницу, а не полную замену. Есть и другие немного различные способы реализации концепции SYN cookie, чем точный средства, описанные здесь, хотя основная идея кодирования данных в порядковый номер SYN-ACK является постоянным.SYN cookie - это начальный порядковый номер, отправленный в SYN-ACK, который выбирается исходя из исходной последовательности инициатора подключения номер, MSS, счетчик времени, а также соответствующие адреса и порт числа. Фактические биты, составляющие SYN cookie, выбираются так, чтобы поразрядная разница (исключающее ИЛИ) между последовательностью SYN число и 32-битное количество, вычисленное таким образом, чтобы вышли пять старших битов. из 32-битного значения счетчика по модулю 32, где счетчик увеличивается каждые 64 секунды следующие 3 бита кодируют пригодный для использования MSS, близкий к одному в SYN, а нижние 24 бита - это секрет, выбранный сервером функция пары IP-адресов, пары номеров портов и 32-битный счетчик, используемый для первых 5 бит.Это означает выбор начальный порядковый номер для использования в SYN-ACK соответствует правилу что порядковые номера TCP медленно увеличиваются. Когда соединение в LISTEN получает сегмент SYN, оно может генерировать SYN cookie и отправить его с порядковым номером SYN-ACK, без выделяя любое другое состояние. Если ACK возвращается, разница между подтвержденным порядковым номером и порядковым номером сегмент ACK можно проверить по последним значениям счетчика и вывод секретной функции с учетом этих значений счетчика и IP-адреса и номера портов в сегменте ACK.Если есть совпадение, соединение может быть принято, поскольку оно статистически очень вероятно, что другая сторона получила файл cookie SYN, а не просто угадать допустимое значение cookie. Если совпадений нет, соединение может быть отклонен с помощью эвристики, что, вероятно, не в ответ на недавно отправленный SYN-ACK. При включенных файлах cookie SYN хост сможет продолжать реагировать даже при атаке SYN-флуда. Самая большая цена, которую нужно заплатить для использования файлов cookie SYN заключается в отключении масштабирования окна опция, отключающая высокую производительность.Веб-страница Бернштейна [cr.yp.to] содержит дополнительную информацию о первоначальная концепция и реализация файлов cookie SYN, а также архивы электронных писем, документирующие эту историю. В нем также перечислены некоторые ложноотрицательные утверждения о файлах cookie SYN, и обсуждает снижение уязвимости реализаций файлов cookie SYN к подделка слепого соединения злоумышленником, угадывающим действительные файлы cookie. Эдди Информационный [Страница 16] RFC 4987 TCP SYN Flooding, август 2007 г. Лучшее описание точных алгоритмов файлов cookie SYN находится в части электронного письма от Бернштейна, которое заархивировано на веб-сайте (примечание он не устанавливает верхние пять битов счетчика по модулю 32, так как предыдущее описание использовало, но вместо этого использует 29 бит из второго Операция MD5 и 3 бита для индекса в таблице MSS; установление секретных значений также не обсуждается).Остаток этого раздела взяты из электронного письма Бернштейна [cr.yp.to]: Вот что может потребовать реализация: Поддерживайте два (постоянных) секретных ключа, sec1 и sec2. Поддерживать (постоянную) отсортированную таблицу из 8 общих значений MSS, msstab [8]. Следите за «временем последнего переполнения». Поддерживайте счетчик, который медленно увеличивается с течением времени, и никогда повторяется, например, "количество секунд с 1970, сдвинуто вправо на 6" биты ». Когда SYN приходит от (saddr, sport) к (daddr, dport) с ISN x, найдите наибольший i, для которого msstab [i] RFC 4987 TCP SYN Flooding, август 2007 г. (1) Найдите TCB (saddr, sport, daddr, dport).Если он там, сделано. (2) Если «время последнего переполнения» раньше, чем несколько минут назад, сдавайся. (3) Выясните, имеет ли смысл наш предполагаемый ISN. Этот означает пересчет y, как указано выше, для каждого из счетчиков которые могли быть использованы в последние несколько минут (скажем, последние четыре фишки), и выясняя, есть ли у соответствует ISN в нижних 29 битах. Если никто из них не сделает, сдаться.(4) Создайте новый TCB. Три верхних бита нашего ISN дают полезная MSS. Отключите все навороченные опции. Адрес автора Уэсли М. Эдди Федеральные сетевые системы Verizon НАСА Исследовательский центр Гленна 21000 Brookpark Rd, MS 54-5 Кливленд, Огайо 44135 Телефон: 216-433-6682 Электронная почта: [email protected] Эдди Информационный [Страница 18] RFC 4987 TCP SYN Flooding, август 2007 г. Полное заявление об авторских правах Авторское право (C) IETF Trust (2007 г.).На этот документ распространяются права, лицензии и ограничения. содержится в BCP 78, и, за исключением случаев, изложенных в нем, авторы сохраняют все свои права. Этот документ и содержащаяся в нем информация размещены на Принцип "КАК ЕСТЬ" и ПОСТАВЩИК, ОРГАНИЗАЦИЯ, ПРЕДСТАВЛЯЕМЫЕ ОН / ОНА ИЛИ СПОНСИРУЕТСЯ (ЕСЛИ ЕСТЬ) ИНТЕРНЕТ-ОБЩЕСТВОМ, ДОВЕРИЕМ IETF И ИНТЕРНЕТ-ИНЖИНИРИНГ ЗАДАЧА ОТКАЗЫВАЕТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНОЙ ИЛИ ПОДРАЗУМЕВАЕМЫЕ, ВКЛЮЧАЯ, НО НЕ ОГРАНИЧИВАЯ НИКАКИХ ГАРАНТИЙ, ЧТО ИСПОЛЬЗОВАНИЕ ПРИВЕДЕННАЯ ИНФОРМАЦИЯ НЕ НАРУШАЕТ НИКАКИХ ПРАВ ИЛИ ПОДРАЗУМЕВАЕМЫХ ГАРАНТИИ КОММЕРЧЕСКОЙ ЦЕННОСТИ ИЛИ ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЕННОЙ ЦЕЛИ.Интеллектуальная собственность IETF не занимает никакой позиции относительно действительности или объема каких-либо Права на интеллектуальную собственность или другие права, которые могут быть заявлены на относятся к реализации или использованию технологии, описанной в этот документ или степень, в которой любая лицензия на такие права может быть, а может и нет; и не означает, что предпринял какие-либо независимые усилия для выявления любых таких прав. Информация о процедурах в отношении прав в документах RFC может быть найдено в BCP 78 и BCP 79.Копии раскрытия информации о правах интеллектуальной собственности в секретариат IETF и гарантии предоставления лицензий или результат попытка получить генеральную лицензию или разрешение на использование такие права собственности разработчиков или пользователей этого спецификацию можно получить из он-лайн репозитория IETF IPR по адресу http://www.ietf.org/ipr. IETF приглашает любую заинтересованную сторону довести до ее сведения любые авторские права, патенты или заявки на патенты или другие проприетарные права, которые могут распространяться на технологии, которые могут потребоваться для реализации этот стандарт.Пожалуйста, направьте информацию в IETF по адресу [email protected]. Подтверждение Финансирование функции редактора RFC в настоящее время обеспечивается Интернет-общество. Эдди Информационный [Страница 19]

Обзор протокола Modbus TCP / IP - Real Time Automation, Inc.

Коды исключений

Регистры чтения / записи (FC 23)

Существует определенный набор кодов исключений, которые должны быть возвращены подчиненными в случае проблем.Обратите внимание, что ведущие устройства могут посылать команды «предположительно» и использовать полученные коды успеха или исключения, чтобы определить, на какие команды MODBUS устройство готово ответить, и определить размер различных областей данных, доступных на ведомом устройстве. добавив 0x80 к коду функции запроса и следуя за этим байтом одним байтом причины, например, следующим образом: 03 12 34 00 01 => 83 02 запрос чтения 1 регистра с индексом 0x1234 тип исключения ответа 2 - 'недопустимый адрес данных' Список исключений следующий:

НЕЗАКОННАЯ ФУНКЦИЯ

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

НЕЗАКОННЫЙ АДРЕС ДАННЫХ

Адрес данных, полученный в запросе, не является допустимым адресом для ведомого устройства. Более конкретно, комбинация ссылочного номера и длины передачи недействительна.Для контроллера со 100 регистрами запрос со смещением 96 и длиной 4 будет успешным, запрос со смещением 96 и длиной 5 вызовет исключение 02.

НЕЗАКОННОЕ ЗНАЧЕНИЕ ДАННЫХ

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

ДЛИНА НЕЗАКОННОГО ОТВЕТА

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

ПОДТВЕРЖДЕНИЕ

Специализированное использование в сочетании с командами программирования

ЗАНЯТО ВЕДОМОЕ УСТРОЙСТВО

Специализированное использование в сочетании с командами программирования

ОТРИЦАТЕЛЬНОЕ ПОДТВЕРЖДЕНИЕ

Специальное использование в сочетании с командами программирования

ОШИБКА ЧАСТИЧНОСТИ ПАМЯТИ

Специальное использование в сочетании с кодами функций 20 и 21, чтобы указать, что расширенная файловая область не прошла проверку целостности.

ПУТЬ ШЛЮЗА НЕДОСТУПЕН

Специальное использование в сочетании со шлюзами MODBUS Plus означает, что шлюз не смог выделить ПУТЬ MODBUS Plus для использования для обработки запроса. Обычно означает, что шлюз неправильно настроен.

ШЛЮЗ ЦЕЛЕВОЕ УСТРОЙСТВО НЕ ОТВЕТИЛО

Специальное использование в сочетании со шлюзами MODBUS Plus означает, что от целевого устройства не было получено ответа. Обычно означает, что устройства нет в сети.

Приложения

Руководство по внедрению клиента и сервера

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

Дизайн клиента

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

  • Установите TCP / IP-соединение с портом 502 на желаемом сервере с помощью connect ()
  • Подготовьте запрос MODBUS, закодированный, как описано ранее.
  • Отправьте запрос MODBUS, включая его 6-байтовый префикс MODBUS TCP / IP, в виде единого буфера для передачи с помощью send ().
  • Дождитесь появления ответа в том же соединении TCP / IP.Необязательно, запустите тайм-аут на этом шаге с помощью select (), если вы хотите получать уведомления о проблемах со связью быстрее, чем обычно сообщает TCP / IP.
  • Считайте с помощью recv () первые 6 байтов ответа, которые укажут фактическую длину ответного сообщения.
  • Используйте recv (), чтобы прочитать оставшиеся байты ответа.
  • Если в ближайшем будущем не ожидается дальнейшего обмена данными с этой конкретной целью, закройте соединение TCP / IP, чтобы ресурсы на сервере можно было временно использовать для обслуживания других клиентов.Рекомендуется, чтобы в качестве максимального периода оставалось соединение на клиенте в течение 1 секунды.
  • В случае тайм-аута ожидания ответа выполните одностороннее закрытие соединения, откройте новое и повторно отправьте запрос. Этот метод позволяет клиенту контролировать время повтора, которое превосходит то, что предоставляется по умолчанию TCP / IP. Это также позволяет использовать альтернативные стратегии отката, такие как отправка запроса на альтернативный IP-адрес с использованием полностью независимой сети связи в случае отказа компонента сетевой инфраструктуры.
Конструкция сервера

Сервер MODBUS TCP / IP всегда должен быть спроектирован так, чтобы поддерживать несколько одновременных клиентов, даже если в его предполагаемом использовании только один клиент кажется разумным. Это позволяет клиенту закрывать и повторно открывать соединение в быстрой последовательности, чтобы быстро реагировать на недоставку ответа. Если используется стандартный стек протоколов TCP / IP, можно сэкономить значительные ресурсы памяти за счет уменьшения буфера приема и передачи. размеры. Обычная служба TCP / IP в UNIX или NT обычно выделяет 8 Кбайт или более в качестве приемного буфера для каждого соединения, чтобы стимулировать «потоковую» передачу данных, например, с файловых серверов.Такое буферное пространство не имеет значения в MODBUS TCP / IP, поскольку максимальный размер запроса или ответа составляет менее 300 байт. Часто можно обменять пространство хранения на дополнительные ресурсы подключения. Для обработки нескольких подключений можно использовать многопоточную или однопоточную модель. Описания приведены в следующих разделах.

Многопоточный сервер

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

  • Используйте listen () для ожидания входящих соединений на TCP / IP-порт 502
  • Когда получен новый запрос на соединение, используйте accept (), чтобы принять его и создать новый поток для обработки соединения
  • В новом потоке выполните в бесконечном цикле следующее: ssue запрос recv (6) для 6 байт заголовка MODBUS TCP / IP.Не устанавливайте здесь тайм-аут, вместо этого будьте готовы подождать, пока не поступит запрос или соединение не будет закрыто. Обе ситуации автоматически разбудят поток.
  • Проанализируйте заголовок. Если он кажется поврежденным, например, поле протокола не равно нулю или длина сообщения больше 256, тогда ОДНОСТОРОННЕЕ ЗАКРЫВАЙТЕ СОЕДИНЕНИЕ. Это правильный ответ сервера на ситуацию, подразумевающую, что кодировка TCP / IP неверна.
  • Выполните recv () для оставшихся байтов сообщения, длина которых теперь известна.В частности, обратите внимание, что выполнение recv () с таким ограничением длины будет терпеть клиентов, которые настаивают на «конвейерной обработке» запросов. Любые такие конвейерные запросы останутся в буферах TCP / IP на сервере или на клиенте и будут приняты позже, когда текущий запрос завершит обслуживание.
  • Теперь обработайте входящее сообщение MODBUS, при необходимости приостановив текущий поток до тех пор, пока не будет рассчитан правильный ответ. В конце концов у вас будет либо действительное сообщение MODBUS, либо сообщение EXCEPTION для использования в качестве ответа.
  • Сгенерируйте префикс MODBUS TCP / IP для ответа, скопировав поле «идентификатор транзакции» из байтов 0 и 1 запроса и пересчитав значение поле длины.
  • Отправьте ответ, включая префикс MODBUS TCP / IP, как единый буфер для передачи по соединению, используя send ().
  • Вернитесь назад и дождитесь следующей 6-байтовой записи префикса.
  • В конце концов, когда клиент решит закрыть соединение, recv () 6-байтового префикса завершится ошибкой. Упорядоченное закрытие обычно приводит к recv () с нулевым счетчиком байтов возврата. Принудительное закрытие может вызвать возврат ошибки из recv (). В любом случае закройте соединение и отмените текущий поток.
Однопоточный сервер

Некоторые встроенные системы и старые операционные системы, такие как UNIX и MS-DOS, поощряют обработку нескольких соединений с помощью вызова «select» из интерфейса сокетов. В такой системе вместо обработки отдельных одновременных запросов в их собственном потоке вы можете обрабатывать запросы как несколько конечных автоматов в общем обработчике. Такие языки, как C ++, делают структуру программного обеспечения такой удобной. Теперь структура будет следующей:

  • Инициализировать несколько конечных автоматов, установив их состояние на 'idle' listen () для входящих соединений через порт TCP / IP 502
  • Теперь запустите бесконечный цикл, проверяя порт «прослушивания» и конечные автоматы следующим образом:
    • Если состояние «новый запрос»:
    • Используйте select (), чтобы узнать, поступил ли запрос.Обычно устанавливайте тайм-аут равным нулю, так как вы не хотите приостанавливать процесс из-за отсутствия активности на этом конкретном соединении.
    • Если select () указывает на наличие пакета, используйте recv (6) для чтения заголовка, как в многопоточном случае. Если заголовок поврежден, ЗАКРЫВАЙТЕ СОЕДИНЕНИЕ и переведите конечный автомат в режим ожидания.
    • Если чтение прошло успешно и select () указывает, что доступны дополнительные данные, прочтите остальную часть запроса.
    • Если запрос завершен, измените состояние сеанса на «ожидание ответа».
    • Если recv () возвращается, указывая, что соединение больше не используется, закройте соединение и переустановите конечный автомат в состояние «простоя».
    • Если состояние - «ожидание ответа»
    • Проверьте, доступна ли информация ответа приложения, если она есть, создайте ответный пакет и отправьте его с помощью send (), точно так же, как и в случае многопоточности. Установите состояние «новый запрос».
    • Можно оптимизировать производительность, объединив несколько вызовов select () в один вызов для каждого цикла, не влияя на функциональную структуру приложения.
Требуемая и ожидаемая производительность

Умышленно НЕТ указания требуемого времени ответа для транзакции через MODBUS или MODBUS TCP / IP. Это связано с тем, что ожидается, что MODBUS TCP / IP будет использоваться в самых разнообразных коммуникационных ситуациях, от сканеров ввода-вывода, ожидающих субмиллисекундной синхронизации, до междугородных радиоканалов с задержками в несколько секунд. Кроме того, семейство MODBUS разработано для поощрения автоматического преобразования между сетями с помощью шлюзов «слепого» преобразования.К таким устройствам относятся Schneider «Ethernet to Modbus Plus Bridge» и различные устройства, которые преобразуют последовательные каналы MODBUS TCP / IP в MODBUS. Использование таких устройств подразумевает, что производительность существующих устройств MODBUS согласуется с использованием MODBUS TCP / IP. Как правило, такие устройства, как ПЛК, которые демонстрируют поведение «сканирования», будут отвечать на входящие запросы за одно время сканирования, которое обычно варьируется от 20 мсек до 200 мсек.

С точки зрения клиента, это время должно быть увеличено на ожидаемые задержки транспорта по сети, чтобы определить «разумное» время ответа.Такие транспортные задержки могут составлять миллисекунды для коммутируемого Ethernet или сотни миллисекунд для подключения к глобальной сети. В свою очередь, любое время «тайм-аута», используемое клиентом для инициирования повторной попытки приложения, должно быть больше ожидаемого максимального «разумного» времени ответа. Если этого не сделать, существует вероятность чрезмерной перегрузки на целевом устройстве или в сети, что, в свою очередь, может вызвать дополнительные ошибки. Этой характеристики всегда следует избегать. Таким образом, на практике тайм-ауты клиента, используемые в высокопроизводительных приложениях, всегда могут в некоторой степени зависеть от топологии сети и ожидаемой производительности клиента.Тайм-аут, скажем, 30 мсек, может быть разумным при сканировании 10 устройств ввода-вывода через локальный Ethernet, и каждое устройство обычно отвечает в течение 1 мсек. С другой стороны, значение тайм-аута в 1 секунду может быть более подходящим при контроле медленных ПЛК через шлюз по последовательному каналу, где обычная последовательность сканирования завершается за 300 мс.

Приложения, которые не критичны по времени, часто могут оставлять значения тайм-аута с обычными значениями TCP / IP по умолчанию, которые сообщают о сбое связи через несколько секунд на большинстве платформ.Клиентам рекомендуется закрывать и восстанавливать соединения MODBUS TCP / IP, которые используются только для доступа к данным (не для программирования ПЛК), и где ожидаемое время до следующего использования является значительным, например, дольше одной секунды. Если клиенты следуют этому принципу, это позволяет серверу с ограниченными ресурсами соединения обслуживать большее количество потенциальных клиентов, а также облегчает стратегии восстановления после ошибок, такие как выбор альтернативных целевых IP-адресов. Следует помнить, что дополнительная нагрузка на связь и ЦП, вызванная закрытием и повторным открытием соединения, сравнима с нагрузкой, вызванной ОДНОЙ транзакцией MODBUS.

Кодирование данных для данных, отличных от слов

Самый эффективный метод передачи большого объема информации любого типа по MODBUS: использование кодов функций 3 (регистры чтения), 16 (регистры записи) или, возможно, 23 (регистры чтения / записи) . Хотя эти функции определены в терминах их работы с 16-битными регистрами, они могут использоваться для перемещения любого типа информации с одной машины на другую, если эта информация может быть представлена ​​как непрерывный блок из 16-битных слов. Первоначальные ПЛК с поддержкой MODBUS были специализированными компьютерами, использующими архитектуру с прямым порядком байтов.Большинство современных ПЛК основаны на серийных микропроцессорах, использующих архитектуру с прямым порядком байтов. Тот факт, что MODBUS используется для потенциального обмена данными между этими двумя архитектурами, привносит некоторые тонкости, которые могут увести в ловушку неосторожных. Почти все типы данных, кроме примитивных «дискретных битов» и «16-битных регистров», были введены после принятия микропроцессоров с прямым порядком байтов. Следовательно, представление этих типов данных в MODBUS следует модели с прямым порядком байтов, что означает:
Биты первого регистра 15-0 = биты 15-0 элемента данных
Биты второго регистра 15-0 = биты 31-16 элемента данных
Третий биты регистра 15-0 = биты 47-32 элемента данных и т. д.и т. д.

Номера битов в слове

ПЛК Modicon имеют предопределенные функции на языке лестничной логики 984, которые преобразуют ряд смежных регистров в блок эквивалентной длины из 1-битных «дискретных». Самая распространенная такая функция - BLKM (Block Move). Для согласованности с исходной архитектурой с прямым порядком байтов такие дискретные значения были пронумерованы от наиболее значимого бита к наименее значимому, и, чтобы добавить путаницы, все числовые последовательности начинались с единицы, а не с нуля. (Номера битов в этом документе всегда обозначаются с нуля как младший бит, чтобы соответствовать современной документации по программному обеспечению) Итак, в слове (регистре):
Дискретный 1 будет бит 15 (значение 0x8000)
Дискретный 2 будет битом 14 (значение 0x4000)
Дискретное 3 будет битом 13 (значение 0x2000)
Дискретным 4 будет битом 12 (значение 0x1000)
Дискретным 5 будет битом 11 (значение 0x0800)
Дискретным 6 будет битом 10 (значение 0x0400)
Дискретный 7 будет битом 9 (значение 0x0200)
Дискретным 8 будет битом 8 (значение 0x0100)
Дискретным 9 будет битом 7 (значение 0x0080)
Дискретным 10 будет битом 6 (значение 0x0040)
Дискретным 11 будет битом 5 (значение 0x0020)
Дискретный 12 будет битом 4 (значение 0x0010)
Дискретным 13 будет битом 3 (значение 0x0008)
Дискретным 14 будет битом 2 (значение 0x0004)
Дискретным 15 будет битом 1 (значение 0x0002)
Дискретным 16 будет бит 0 (значение 0x0001)

Когда имеется более 16 бит, например В модуле дискретного ввода с 32 точками дискретные значения с 1 по 16 будут находиться в первом регистре, а дискретные с 17 по 32 - во втором регистре.