Сколько можно вписать человек в птс: Сколько мест в птс автомобиля

Содержание

Сколько мест в ПТС

Хотите пройти тест по материалам статьи после ее прочтения?

ДаНет

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

Количество мест в ПТС

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

Однако в паспорт транспортного средства можно записать лишь ограниченное число человек. Сколько мест есть в ПТС? Там есть место для 6 собственников.

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

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

Что делать, если место закончилось

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

  1. Собрать документацию, в состав которой входят ПТС и паспорт гражданина, ОСАГО, заключенный договор купли-продажи авто и СТС (свидетельство о регистрации ТС).
  2. Отобрав необходимые бумаги, направляйтесь в МРЭО (Межрайонный регистрационно-экзаменационный отдел). Транспортное средство обычно не требуется пригонять, так как бывает достаточно и официальных бумаг, подтверждающих право собственности. Предоставить машину для осмотра могут потребовать, если возникнут какие-либо сомнения относительно данных и их подлинности.
  3. Заполнив документы, необходимо выплатить пошлину государству. Затем нужно подать заранее собранные документы (п. 1) и бумаги, заполненные в МРЭО (бланк, чек об оплаченной госпошлине).
  4. Сотрудники службы проверят достоверность сведений, а затем выдадут новые ПТС и СТС. Необходимость получения нового свидетельства при смене паспорта ТС обусловлена тем, что серийные номера у них схожи.

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

какое количество владельцев по ПТС допустимо?

Москва, ул. Перерва, д. 21 МО ГИБДД ТНРЭР № 4Круглосуточно+7 (495) 349-05-41
Москва, ул. Вагоноремонтная, д. 27 МО ГИБДД ТНРЭР № 19.00 — 18.00 (пн. — чт.) 9.00 — 17.00 (пт.) Сб. и вс. — выходной+7 (495) 484-93-20
Москва, Волховский переулок, д.16/20, стр.3 МО ГИБДД ТНРЭР № 18.00 — 20.00 (вт.) 8.00 — 18.00 (ср. — пт.) 8.00 — 17.00 (сб.) Пн. и вс. — выходной+7 (499) 261-10-95
Москва, ул. Верхняя Красносельская, д.15 А МО ГИБДД ТНРЭР № 18.00 — 20.00 (вт.) 8.00 — 18.00 (ср. — пт.) 8.00 — 17.00 (сб.) Пн. и вс. — выходной+7 (499) 264-32-53
Москва, Посланников переулок, д. 20 МО ГИБДД ТНРЭР № 1
8.00 — 20.00 (вт.) 8.00 — 18.00 (ср. — пт.) 8.00 — 17.00 (сб.) Пн. и вс. — выходной
+7 (499) 265-11-36
Москва, Сигнальный проезд, д. 9 МО ГИБДД ТНРЭР № 38.00 — 20.00 (ежедневно)+7 (499) 903-69-80 +7 (499) 903-62-54
Москва, проспект Мира, д. 207, кор. 1 МО ГИБДД ТНРЭР № 38.00 — 17.00 (вт. — сб.) Пн. и вс. — выходной+7 (499) 187-17-57
Москва, ул. Юности, д. 3 МО ГИБДД ТНРЭР № 38.00 — 20.00 (вт.) 8.00 — 18.00 (ср. — пт.) 8.00 — 17.00 (сб.) Пн. и вс. 9.00 — 18.00 (только через госуслуги)+7 (495) 375-16-11
Москва, ул. 50-летия Октября, д. 6, кор. 1 МО ГИБДД ТНРЭР № 58.00 — 20.00 (ежедневно) Вс. только через госуслуги+7 (495) 439-16-24
Москва, Хорошевское шоссе, д. 40 МО ГИБДД ТНРЭР № 28.00 — 20.00 (вт.) 8.00 — 18.00 (ср. — пт.) 8.00 — 17.
00 (сб.) Пн. и вс. — выходной
+7 (495) 940-11-19
Москва, ул. Твардовского, д. 8, кор. 5 МО ГИБДД ТНРЭР № 2Для юридических лиц 9.00 — 18.00 (пн. — чт.) 9.00 — 17.00 (пт.) Сб. и вс. — выходной Для физических лиц Круглосуточно (20.00 — 8.00 только через госуслуги)+7 (499) 740-14-15
Москва, ул. Нагатинская, д. 2, стр. 3 МО ГИБДД ТНРЭР № 48.00 — 20.00 (вт.) 8.00 — 18.00 (ср. — пт.) 8.00 — 17.00 (сб.) Пн. 8.00 — 18.00 только через госуслуги Вс. — выходной+7 (499) 782-24-10
Москва, ул. Академика Глушко, д. 13 МО ГИБДД ТНРЭР № 58.00 — 20.00 (ежедневно)+7 (495) 711-81-03
Москва, ул. Лобненская, д. 20 МО ГИБДД ТНРЭР № 18.00 — 20.00 (ежедневно)+7 (495) 485-41-06

Вопросы и ответы

Maria 03. 11.2011 10:15

Добрый день, Андрей! Вы не указали название страховой компании, поэтому постараюсь ответить на ваш вопрос в общих чертах. В большинстве страховых компаний в правилах страхования указано, что страхование не распространяется на детали, имеющие повреждения на момент страхования, либо получившие повреждения не в результате страхового случая в период действия договора страхования. Если у Вас уже повреждена деталь до начала страхования, то у Вас УЖЕ есть необходимость ее ремонта, эксплуатация транспортного средства имеющего повреждения запрещена техническуим регламентом, соответственно, владелец должен отремонтировать транспортное средство, соответственно эти расходы собственник должен был понести как раз до начала страхования, но раз он еще не отремонтировал, то все-равно должен отремонтировать за свои деньги. Т.к. в технических регламентах заводов-изготовителей не предусмотрена частичная покраска кузовной детали, то, соответственно, расходы должны соответствовать покраски детали целиком.
Если клиент в период действия страхового полиса обращается в страховую компанию по проведению ремонтных работ с этой же деталью, то страховая компания, обычно считает, что ремонт который должен был сделать собственник еще до начала страхования — собственник должен сделать сам, а если есть дополнительные повреждения, то страховая компания только их и оплатит. Это общая практика, но есть и исключения, например, некоторые компании в таких случаях оплачивают половину покраски детали, а некоторые компании неоплачивают по данной детали ни окраску, ни замену, ни ремонт. Я думаю, что раз Вам выплатили таким образом, значит в страховой компании сложилась такая практика выплат, и на это есть инструкция головного офиса (на самом деле такие случаи как у Вас бывают достаточно часто). Обращаться в суд советую только с полной уверенностью в своей правоте (пошлина+оценка+юрист достаточно дорого), а это Вы можете узнать только из правил страховой компании. Вы можете обратиться к нам в компанию для бесплатной юридической консультации, для этого Вам нужны будут с собой страховой полис и правила страхования, которые Вам должны были выдать вместе с полисом.
С уважением, Мария Новикова

Регистрация авто без водительских прав

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

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

Рассмотрим несколько примеров:

1. Кандидат в водители еще не закончил обучение в автошколе, а ему подвернулся отличный вариант для покупки.

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

3. Мать, не имеющая прав, покупает автомобиль в кредит для ребенка, обучающегося в ВУЗе.

4. Несовершеннолетний ребенок получает машину в наследство.

На самом деле данный список можно продолжать довольно долго, ситуаций могут быть сотни. Однако объединяет их один общий признак — владелец транспортного средства не имеет водительского удостоверения, т. е. не может управлять машиной. При этом возникает вопрос: «Можно ли купить машину без прав?».

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

1. Оформление покупки транспортного средства

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

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

2. Управление автомобилем по пути домой

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

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

Оформление дополнительных документов на водителя на данном этапе не требуется. В случае остановки сотрудниками ГИБДД нужно будет предъявить им договор купли-продажи и свидетельство о регистрации предыдущего владельца.

3. Прохождение технического осмотра

Примечание. Диагностическая карта не требуется, если автомобилю менее 3-х лет либо у него имеется действующая диагностическая карта.

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

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

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

4. Приобретение страховки ОСАГО

Отсутствие водительского удостоверение не помешает застраховать транспортное средство.

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

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

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

5. Запись на регистрацию автомобиля через Госуслуги

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

Существуют 2 варианта записи:

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

Если заявление подает доверенное лицо, то дополнительно следует заполнить следующие поля:

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

2. В разделе «6 Сведения о доверенности» нужно заполнить следующие поля:

2.1. Номер. Если в доверенности не указан номер, то не заполняйте это поле или введите цифру 1.

2.2. Дата выдачи, указанная в доверенности.

2.3. Кем выдано. ФИО собственника транспортного средства, который выдал доверенность.

6. Оформление автомобиля в ГИБДД

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

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

Подведем итоги данной статьи:

1. Отсутствие водительского удостоверения не является препятствием для покупки транспортного средства.

2. Собственнику в любом случае придется воспользоваться помощью водителя.

3. Возможны 2 варианта использования водителя:

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

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

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

Важно ли количество владельцев в ПТС?

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

Паспорт технического средства (ПТС)

У Audi 100 за 20 лет жизни были три реальных владельца. Первый в Голландии. Отъездив на машине 7 лет (неплохо по их меркам), он продал автомобиль покупателю из России (это было еще до повышения пошлин, тогда пригнать б/у-иномарку из Европы было экономически выгодно). Тот не был перекупщиком, эксплуатировал машину сам и проездил семь лет, после чего продал ее своему знакомому, который ездил еще шесть лет. В итоге, у 20-летнего авто всего три реальных владельца, а в российском ПТС вообще указаны только две фамилии. Шикарно, вот только последний владелец о машине совсем не заботился, поэтому реальное состояние автомобиля было плачевное.

Вторая история. У двухлетнего Renault Logan в ПТС уже 4 собственника. Ужас-ужас, от машины шарахались все потенциальные покупатели, но оказалось все объяснимо. Автомобиль в лизинг покупало юрлицо, поэтому первым владельцем была указана именно лизинговая компания. Долг был выплачен, машину переоформили на само юрлицо, однако оно вскоре обанкротилось и на торгах автомобиль выкупил подсуетившийся частник. Выкупил дешево, поэтому немного повысив цену продал первому попавшемуся перекупщику. «Перекупы» не любят себя вписывать в ПТС (в том числе и потому, что это увеличивает количество владельцев, что плохо воспринимается покупателями), но в этот раз пришлось. Фишка в том, что в юрлице машину особо не эксплуатировали, у нее на момент описанной истории был реальный пробег 12 тысяч километров и состояние, как пишут в объявлениях, «нового авто». Не побоявшийся купить машину уже пятый собственник до сих пор ездит на этом авто и очень доволен, хотя, казалось бы, история выглядит очень мутно.

ПТС

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

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

Проверить автомобиль перед покупкой и понять его реальное состояние

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

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

С 1 ноября в России будет приостановлена выдача бумажных ПТС

С 1 ноября в России будет приостановлена выдача бумажных ПТС. Электронный документ будет включать в себя всю историю автомобиля, в том числе сведения о ДТП. При желании автовладельца в паспорт транспортного средства можно будет добавить стоимость автомобиля. Специалисты ГК «АвтоСпецЦентр» провели опрос среди 890 своих клиентов и выяснили, что они относят к преимуществам цифровых ПТС. 

Более половины опрошенных посетителей дилерских центров АСЦ – 57% (507 человек) предпочитают использовать бумажную версию ПТС, в основном это автовладельцы старше 50 лет. Практически все опрошенные – 97% (863 человека) – назвали главным преимуществом ЭПТС отсутствие ограничений по сроку действия документа. Это означает, что в электронную версию паспорта может вноситься неограниченный объем информации об автомобиле. Например, в нем будут указаны все владельцы транспортного средства с момента покупки. В бумажном ПТС – шесть строк для указания владельцев авто, поэтому очередному собственнику рано или поздно приходится менять документ.

Самыми важными из преимуществ ЭПТС 67% клиентов ГК «АвтоСпецЦентр» (596 человек) назвали информацию о пробеге, 17% (151 человек) – наличие каких-либо ограничений при покупке или продаже, которые вносят банки, лизинговые компании, 10% (89 человек) – информацию о внесении изменений в конструкцию, 8% (71 человек) – сведения о прохождении техосмотра. 

В целом, респонденты поддерживают внедрение электронных паспортов транспортных средств. 54% (480 человек) отметили, что это удобно, 27% (240 человек) сказали, что цифровой формат – это гарантированная защита от потери и кражи документа, 19% (169 человек) уверены, что оформление ЭПТС в ГИБДД нивелирует количество технических ошибок. Помимо этого, электронный документ поможет сократить количество махинаций и мошеннических схем при продаже и регистрации автомобилей на вторичном рынке и упростить регистрацию автомобиля в ГИБДД. 

Дополнительными плюсами ЭПТС по сравнению с бумажной версией 83% опрошенных (738 человек) назвали возможность узнать всю историю авто с момента изготовления до утилизации, 12% (107 человек) – вписать любое количество собственников. При этом 5% (44 человека) опрошенных опасаются, что система электронных паспортов не сможет работать эффективно из-за сбоев в базе данных или утечки информации. 

49% (436 человек) знают, что электронный паспорт ТС может выдать автопроизводитель, если автомобиль производится в России, для иномарок ЭПТС оформляет официальный импортер. Также 70% (623 человека) опрошенных осведомлены, что все новые автомобили сопровождаются только электронными паспортами ТС без бумажных аналогов. 

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

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

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

Сколько человек можно вписать в страховку ОСАГО

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

Как правильно менять сведения в полисе ОСАГО?

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

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

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

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

В дополнительном бланке должна быть указана следующая информация:

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

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

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

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

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

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

Как вписать людей в страховку ОСАГО?

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

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

Для решения вопроса, связанного с вписыванием людей в ОСАГО, невозможно обойтись без дополнительных документов:

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

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

Особенности расчета доплаты

Каждый водитель, который вписывается в страховой полис ОСАГО, получает коэффициент в виде единицы. Именно с момента вписывания автомобилиста в страховку начинается история вождения, которая может быть положительной или отрицательной. За каждый год отсутствия аварий предусматривается скидка в виде пяти процентов.

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

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

критических ресурсов и первые 14 КБ — обзор

Эта страница была первоначально создана и последний раз редактировалась .

Введение

Многие эксперты по веб-производительности рекомендуют размещать все критически важные ресурсы в первых 14 КБ веб-страницы. Это основано на небольшом понимании TCP, который лежит в основе каждого HTTP-соединения — по крайней мере, пока, пока не появятся HTTP / 3 и QUIC. Но так ли это на самом деле? В моей книге «HTTP / 2 в действии» я предположил, что статистика в 14 КБ уже не так актуальна в современном мире, если она когда-либо была, и меня попросили расширить ее — отсюда и этот пост.Но позвольте мне предупредить об этом, сказав, что производительность в Интернете чрезвычайно важна, и есть много, много, много вариантов использования, демонстрирующих это, поэтому я не возражаю против этого, и люди должны оптимизировать это. Только не зацикливайтесь на этом 14-килобайтном номере.

Основы TCP и откуда взято это число 14 КБ

TCP — это протокол гарантированной доставки, для достижения которого используется ряд методов. Сначала он подтверждает все пакеты TCP и повторно отправляет все неподтвержденные пакеты. Кроме того, он очень хорошо действует в сети и запускается медленно и наращивает до полной емкости в процессе, известном как TCP slow start , мягко прощупывая свой путь и проверяя, что он ничего не перегружает и не приводит к потерянным (неподтвержденным) пакетам.Комбинация этих двух вещей означает, что при запуске TCP он позволяет отправить 10 пакетов TCP, прежде чем они должны быть подтверждены. Поскольку эти пакеты подтверждаются, это позволяет отправлять больше пакетов, удваиваясь, чтобы в следующий раз можно было отправить 20 пакетов, затем 40, затем 80 … и т. Д. по мере того, как сеть постепенно набирает полную пропускную способность. Магическое число 14 КБ связано с тем, что каждый TCP-пакет может иметь размер до 1500 байтов, но 40 из этих байтов предназначены для использования TCP (заголовки TCP и т.п.), оставляя 1460 байтов для фактических данных.10 из этих пакетов означают, что вы можете доставить 14 600 байт или около 14 КБ (на самом деле 14,25 КБ).

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

Также следует отметить, что HTML фактически читается большинством браузеров как поток байтов, и поэтому вам не нужно загружать весь HTML, прежде чем браузер начнет его обрабатывать. В основном браузеры тоже довольно нетерпеливы — из-за этих нетерпеливых пользователей — и поэтому начнут смотреть на HTML, как только он начнет поступать.Он может видеть ссылки на CSS, JavaScript и другие ресурсы и начинать их выборку, чтобы отрендерить страницу как можно быстрее. Следовательно, даже если вы не можете отправить всю страницу в первые 14 КБ (хотя, пожалуйста, сделайте это, если можете!), Наличие такого же количества важных данных в этих первых 14 КБ позволит браузеру начать работу с этими данными раньше.

Хотя 14 КБ могут показаться не так уж и много в наши дни многомегабайтных страниц, помните, что вы не пытаетесь уместить всю страницу в этот предел в 14 КБ (хотя снова сделайте это, если можете!), А только пытаетесь оптимизировать то, что браузер видит в этом первом фрагменте данных.Таким образом, размещение всех ваших критически важных ресурсов в первых 14 КБ дает вам наилучшие шансы максимизировать первое чтение браузером и должно привести к более быстрой странице, поэтому эксперты по веб-производительности дают такой совет. В идеальном мире этого будет достаточно даже для начала рендеринга, если вы встроите критический CSS, что мне, кстати, не нравится! — но даже если вы не можете сделать это за один рендеринг в оба конца, также поможет заставить браузер как можно быстрее начать загрузку всех необходимых ресурсов.

14 КБ и современный веб

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

Во-первых, это предположение, что все эти 14 КБ будут использованы для доставки HTML. Даже в старом мире открытого текста HTTP этого не было с кодами ответа HTTP ( 200 OK ) и заголовками ответов HTTP, которые частично занимались этим.В частности, заголовки HTTP-ответов могут быть огромными! Например, заголовок политики безопасности контента Twitter занимает около 5 КБ. Да, HTTP / 2 позволяет сжимать заголовки ответов HTTP, но в основном это работает, сохраняя заголовки из предыдущих запросов и ссылаясь на них в последующих запросах. Это означает, что первый запрос — когда мы больше всего обеспокоены этим пределом в 14 КБ — в значительной степени использует полноразмерные заголовки — хотя это не на 100% точно, поскольку HTTP / 2 все еще может использовать исходную статическую таблицу для общих заголовков и использовать кодировку Хаффмана, а чем ASCII для заголовков чуть меньшего размера, но это лишь частичная оптимизация, и большее преимущество заключается в повторном использовании для второго и последующих запросов.Поскольку я только что представил HTTP / 2, здесь возникает вторая проблема — HTTPS и HTTP / 2. Оба они требуют обмена некоторыми дополнительными сообщениями для установления соединения.

HTTPS требует двух циклов приема-передачи для установки TLS-соединения, предполагая, что используется наиболее часто используемый TLSv1.2, и здесь нет возобновления сеанса, как показано на следующей диаграмме установления связи:

Итак, по крайней мере 2 из 10 ваших TCP-пакетов для отправки израсходованы. TLSv1.3 допускает 1 двусторонний обход (1-RTT) или даже 0 двусторонних обходов (0-RTT) в определенных сценариях, что является одним из его больших преимуществ.Однако я не думаю, что это слишком сильно меняет аргумент, который я собираюсь сделать, потому что, кроме того, сертификаты TLS могут быть довольно большими, что легко требует отправки нескольких пакетов TCP. Таким образом, использование 2 TCP-пакетов, вероятно, ваш лучший вариант для даже для TLSv1.3 и, конечно же, для TLSv1.2.

Тогда предположим, что вы используете HTTP / 2, как и многие популярные сайты, особенно те, которые заботятся о производительности. HTTP / 2 доступен только через HTTPS (по крайней мере, для браузеров) и требует обмена еще несколькими сообщениями для установки соединения HTTP / 2.Для начала клиент должен сначала отправить предисловие к соединению HTTP / 2, затем каждая сторона ДОЛЖНА отправить кадр SETTINGS, и часто один или несколько кадров WINDOWS_UPDATE также отправляются в начале соединения. Только после этого клиент может отправить HTTP-запрос. Это правда, что эти кадры HTTP / 2 не обязательно должны быть отдельными TCP-пакетами, а также не должны подтверждаться перед выполнением клиентских запросов, но они действительно съедают этот начальный лимит в 10 TCP-пакетов.Вдобавок, хотя об этом вряд ли стоит упоминать, так как он такой маленький, но каждому кадру HTTP / 2 также предшествует заголовок размером не менее 9 байтов, в зависимости от точного типа кадра, который далее переходит в этот предел в 14,25 КБ — если мы ‘ Если вы собираетесь подсчитать накладные расходы пакетов TCP, то кажется справедливым сделать то же самое для накладных расходов пакетов HTTP / 2!

Таким образом, если бы статистика 10 пакетов / 14 КБ была точной, то мы были бы по крайней мере вдвое меньше (2 пакета для подтверждения TLS, 2 для ответа на установление соединения HTTP / 2 и 1 для ответа HTTP-заголовка, оставив 5 пакетов), что звучит намного хуже! Однако, с другой стороны, некоторые из этих возвратно-поступательных сообщений будут приводить к TCP ACK, что означает, что у нас будет больше, чем , чем 14 КБ, когда мы перейдем к отправке HTML, а не меньше .Например, TLS требует, чтобы клиенты отвечали во время рукопожатия, что, как мы вскоре увидим, означает, что они также могут одновременно подтверждать некоторые из ранее отправленных TCP-пакетов, увеличивая размер окна перегрузки, поэтому мы уже увеличили это ограничение в 10 пакетов.

Также предполагается, что может быть отправлено только 10 пакетов TCP. Хотя это верно для большинства современных операционных систем, это относительно новое изменение, и ранее в качестве этого ограничения использовались 1, 2, а затем 4 пакета.Можно с уверенностью предположить, что, если вы не работаете на устаревшем оборудовании (и давайте предположим, что те, кто достаточно обеспокоен производительностью, чтобы смотреть на этот предел в 14 КБ, не имеют), тогда он составляет не менее 14 КБ, однако некоторые CDN даже начали подниматься выше. чем 10. До сих пор я не видел никаких предложений по увеличению этого параметра в целом для серверов, но опять же, те, кто интересуется производительностью, вполне могут использовать CDN.

Кроме того, как упоминалось ранее, это число в 14 КБ всегда основывалось на несколько ошибочном предположении — что использование TCP является таким точным и чистым протоколом.Можно сказать, что стеки TCP могут отправлять до 10 пакетов без подтверждения, и что каждое подтверждение всех пакетов в полете удваивает размер окна перегрузки, что означает, что после этих начальных 10 пакетов можно отправить 20 пакетов, затем 40 пакетов, 80 пакеты … и т. д. Однако жизнь редко бывает настолько клинической. Реальность такова, что TCP будет подтверждать получение пакетов все время в зависимости от стека TCP и задействованных таймингов. Предел в 10 пакетов — это всего лишь максимум неподтвержденных пакетов, но довольно часто подтверждение может быть отправлено, скажем, после 5 пакетов.Или даже после 1. Это особенно верно, когда клиенту все равно нужно отправить данные (например, в рамках рукопожатия TLS или как часть настройки соединения HTTP / 2), поэтому в реальности часто (всегда?) окно перегрузки будет больше 10 КБ к тому моменту, когда вы все равно придете для отправки HTML.

Наконец, следует также помнить, что HTML должен доставляться в сжатом виде (gzip или с использованием более нового сжатия brotli), поэтому 10 КБ легко могут быть 50 КБ, если это принять во внимание, поскольку текст (HTML, CSS и JavaScript) сжимается очень хорошо.

Пример из реальной жизни

Поскольку одно из моих замечаний выше заключается в том, что 14 КБ основаны на теории, а не на фактическом использовании, давайте посмотрим на пример из реальной жизни. То, что следует ниже, является лишь одним примером, а не окончательным исследованием или исчерпывающим анализом топовых сайтов X, но, по крайней мере, это покажет, говорю ли я полную чушь или есть что-то в этой бессвязной болтовне. Результаты можно легко повторить, и, если кто-то захочет, он может повторить это в большем масштабе. В любом случае, для этого примера я запустил Chrome с функцией ведения журнала ключей SSL, чтобы Wireshark мог перехватывать все запросы.Как это работает, для тех читателей, которые не знакомы с этим, выходит за рамки этого сообщения в блоге, но есть и другие, которые покажут вам путь. Эта настройка в основном означает, что Chrome работает в обычном режиме, но позволяет Wireshark обнюхивать весь трафик взад и вперед, даже зашифрованный трафик HTTPS, поэтому мы можем точно видеть, что происходит на уровне пакетов TCP.

Затем я подключаюсь к известному веб-сайту (я выбрал https://www.amazon.com) и после проверки IP-адреса, к которому я подключился в инструментах разработчика Chrome, я отфильтровал захват Wireshark только для этого трафика. — как показано на скриншоте ниже:

Для тех, кто не привык к Wireshark, это может немного сбить с толку, но в основном каждая строка представляет собой сообщение, отправляемое по сети.По возможности Wireshark классифицирует тип сообщения на самом высоком уровне протокола (например, TCP, TLS или HTTP / 2) для этого сообщения. Он также вернется к TCP для фрагментов сообщений (например, для сообщений TLS, которые охватывают несколько сообщений TCP, поэтому их нельзя распознать как сообщение TLS до последнего пакета TCP).

На приведенном выше снимке экрана вы можете увидеть все сообщения, возвращаемые от Amazon, и, прежде всего, мы видим сообщение 1241, которое является серверной стороной установления связи TCP (SYN, ACK), затем TCP ACK в сообщении 1250, затем мы видим сообщение TLSv1.2 Server Hello сообщение (1252), за которым следуют 3 сообщения (1253, 1255 и 1257), необходимые для отправки следующей части рукопожатия TLS с сертификатом и данными обмена ключами (обратите внимание, что только последнее из них помечено как TLSv1 .2, поскольку первые два являются просто фрагментами, поэтому помечены как TCP). Также в первых двух из них вы можете увидеть максимальный размер 1500 байт, о котором я говорил ранее. Пакеты TCP действительно имеют только этот максимальный размер, когда есть поток данных для отправки таким образом. После этого есть еще один случайный TCP ACK (1284), прежде чем мы завершим рукопожатие TCP (1285).Далее мы переходим к сообщениям настройки HTTP / 2, описанным выше — к счастью, они маленькие, поэтому их можно поместить в один пакет TCP. После этого у нас есть еще пара TCP ACK, прежде чем мы перейдем к первому реальному HTTP-сообщению (1316), куда мы отправим заголовки ответа (включая код состояния 200 , показанный на снимке экрана). После этого у нас есть еще несколько ACK, прежде чем мы начнем отправлять HTML, который принимает 5 пакетов (1318, 1319, 1321, 1322 и 1324) для первого кадра HTTP / 2 DATA (обратите внимание, что я не показал все кадры DATA в этом скриншот для краткости).Теперь размер окна перегрузки не является чем-то, что фактически передается, поэтому мы можем только догадываться, каков размер к этому моменту, но я думаю, что ясно показать, что гораздо больше, чем просто тело HTML, отправляется обратно, поэтому предположение, что все эти 10 пакетов предназначены только для HTML, это, конечно, неправда.

Давайте теперь посмотрим на клиентскую сторону, изменив фильтр вверху, чтобы вместо него посмотреть на ip.dst :

Здесь мы видим похожую историю с настройкой TCP, сообщениями TLS, сообщениями HTTP / 2 — все это до того, как мы даже запросим домашнюю страницу.Каждый из этих пакетов TCP размером 66 байт — это просто TCP ACK и ничего больше, поэтому это показывает, что TCP ACK происходит все время, даже если другой трафик не отправляется. Однако, когда отправляется другой трафик (например, сообщения TLS или сообщения HTTP / 2), в составе этих сообщений по-прежнему присутствует TCP ACK. Во всех 14 сообщениях, все с TCP ACK, отправляются на сервер после первоначального установления связи TCP до того, как будет отправлен первоначальный запрос GET (и этот запрос также включает ACK, поэтому мы можем получить до 15 пакетов).И, вероятно, еще несколько ACK будут отправлены до начала доставки HTML, и даже больше, пока он будет доставлен. Фактически, давайте посмотрим на обе стороны сразу (что может сначала сбить с толку, поэтому я сначала показал каждую сторону):

Здесь мы видим, что больше ACK было отправлено от клиента к серверу в пакетах 1286, 1289, 1317, 1320, 1323 до того, как первый кадр DATA был возвращен сервером, что означает, что мы получили ACK как минимум 20 пакетов, поскольку HTML начинает течь, так что мы где-то между 28 КБ и 57 КБ, которые могут быть отправлены без подтверждения.Кроме того, как я сказал выше, по мере потоков данных HTML подтверждается больше, как можно увидеть в сообщении 1325 и других сообщениях за пределами экрана. Трудно сказать, блокировался ли HTML когда-либо в ожидании подтверждения TCP, но я подозреваю, что нет. Домашняя страница Amazon не мала (113 КБ в сжатом виде или 502 КБ без сжатия), но из-за экспоненциального увеличения медленного запуска TCP нам нужно всего 3 или 4 цикла подтверждения, чтобы потенциально добраться до точки, где это может быть отправлено. за один раз, как мы уже показали, соединения HTTPS и HTTP / 2 будут иметь несколько циклов приема-передачи.

Глядя только на сообщения HTTP / 2, мы можем видеть устойчивый поток кадров DATA без заметной задержки между ними, что может быть индикатором или ожиданием подтверждений TCP, что, похоже, подтверждает мои подозрения об отсутствии задержки:

Я буду честен здесь, и с временем прохождения туда и обратно 20 мс (которое я измерил через ping ) было бы трудно увидеть такую ​​задержку в любом случае. Плохое соединение может оказать большее влияние. Также следует отметить, что использование дросселирования сети Chrome Dev Tools здесь не поможет, поскольку это искусственное дросселирование внутри Chrome, а не что-либо на сетевом уровне.Я повторил тест с веб-сайтом в оба конца 300 мс и увидел то же самое, но это все еще очень анекдотично, так как я тестирую здесь отдельные сайты, а не провожу обширные полевые исследования.

Тем не менее, суть остается в том, что существует множество TCP-сообщений взад и вперед, так что число 10 TCP / 14 КБ оказалось теоретическим, а не тем, что вы могли бы увидеть в реальном мире, особенно при HTTPS-соединении (и даже больше. так что по HTTP / 2-соединению через HTTPS).

Сводка

Надеюсь, этот пост объяснил, почему я считаю, что число 14 КБ не является абсолютным числом или чем-то, чего веб-разработчики должны придерживаться слишком строго («О нет, я перешел на 15 КБ, должен сбрить еще 1 КБ, или мы не запускается! «).Я уверен, что многие энтузиасты веб-производительности, которые продвигали это число, не хотели, чтобы люди воспринимали его так буквально, но проблема с такими точными числами, особенно если они подкреплены небольшими научными данными, заключается в том, что люди будут воспринимать это как таковое, хотя им не следует этого делать.

Этот пост также не означает, что размер страницы не важен — он очень важен, и я большой поклонник оптимизации веб-производительности! Однако я предостерегаю от абсолютизма. Реальный мир намного сложнее.Общий совет по-прежнему в силе: размещайте важные ресурсы в верхней части страницы, чтобы браузер мог их увидеть как можно скорее и начать работать с ними, и в идеале сделайте свою страницу как можно меньше, чтобы она могла быстро загружаться. Но не переживайте из-за этого волшебного числа в 14 КБ.

Вы согласны или не согласны? У вас есть еще какие-то данные, чтобы подтвердить или опровергнуть то, о чем я говорил выше? Дайте мне знать ниже свои мысли. И если этот пост вас заинтересует, то посмотрите мою книгу — HTTP / 2 в действии.Код скидки 39pollard даст вам скидку 39% при покупке напрямую у Manning.

Эта страница была первоначально создана и последний раз редактировалась .

Твитнуть

Насколько полезна была эта страница?

1 звезда 2 звезды 3 звезды 4 звезды 5 звезд

— Спасибо за ваш отзыв! Сеть

— Разница между ПАКЕТАМИ и ФРЕЙМАМИ

Пакет

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

Рама

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

2) При мультиплексировании с временным разделением (TDM) кадр представляет собой полный цикл событий в пределах периода временного разделения.

3) При записи и воспроизведении фильмов и видео кадр — это одно изображение в последовательности изображений, которые записываются и воспроизводятся.

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

5) В приложениях искусственного интеллекта (AI) кадр — это набор данных с информацией о конкретном объекте, процессе или изображении. Примером может служить система визуального распознавания iris-print, используемая для идентификации пользователей некоторых банковских банкоматов.Эта система сравнивает фрейм данных для потенциального пользователя с фреймами в своей базе данных авторизованных пользователей.

TCP Over IP Bandwidth Overhead

Сколько времени потребуется для передачи файла размером 100 МБ по туннелю IPSec, проходящему по выделенному каналу Ethernet 100 Мбит / с? 1 секунда? Провал! 8 с? Тебе становится теплее. Это почти 8,5 с без IPSec и более 9 с с ним. Что такого особенного в разнице в 1 с? Что ж, экстраполируйте это увеличение, допустим, это 13%, и передача файла, которая должна занять час, на самом деле занимает около 1 часа 8 минут в идеальных условиях без учета накладных расходов приложения.Другими словами, вы потеряли 13% пропускной способности в хороший день только из-за накладных расходов сети.

Вы можете подумать, что эти вопросы бессмысленны в нашем мире с высокой пропускной способностью, но давайте не будем забывать, что для большинства в мире подключение к Интернету в лучшем случае выглядит как модем 9600. Все эти биты и байты имеют значение и для Facebook и Google, когда вы имеете дело с гипермасштабируемым соединением и скоростью передачи данных, сокращение даже 0,5% становится большим делом; SPDY — хороший пример того, как в этом помочь.

Кроме того, когда я хочу что-то понять, я действительно хочу это понять. Когда кто-то из технических специалистов жалуется на производительность сети, мне хотелось бы иметь наготове реальные цифры, объясняющие, почему они никогда, никогда не получат 100 Мб данных по этому каналу Fast Ethernet за 1 секунду. Это вселяет в меня уверенность, зная, что ответы, которые я даю на вопросы о пропускной способности и производительности, не основаны на гипотетических фантазиях (albiet по-прежнему ограничен «дополнительными накладными расходами приложений»).

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

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

Допущения

При формулировании этих расчетов были сделаны следующие допущения;

  • Нет повторных попыток, потери пакетов или других событий
  • Односторонняя передача данных и служебные данные между хостом
  • MTU IP 1500 байт
  • Хост TCP MSS 1460 байт
  • Заголовки пакетов TCP и IP размером 40 байт (без параметров TCP)
  • Использование полнодуплексной среды связи, т.е.е. полная пропускная способность доступна как в восходящем, так и в нисходящем направлении, одновременно
  • Если разделение данных на максимальный размер пакета приводит к дробному, пакет для оставшихся данных должен быть передан, поэтому мы всегда округляем в большую сторону при вычислении количества пакетов

Единицы измерения

Аббревиатуры, используемые для значений данных / трафика в этой статье, представляют собой метрические префиксы (также известные как префиксы SI), обозначающие десятичное умножение (а не двоичные префиксы (основанные на степени двойки), где 1 кбит = 1024 бита), как показано ниже;

  • 1 кБ = 1000 байтов (8000 бит)
  • 1 МБ = 1000000 байтов (8000000 бит)

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

  • Скорости последовательной линии обычно указываются с использованием двоичных префиксов, поэтому 2 Мб E1 фактически равно 2.048Mb с использованием метрических префиксов
  • Скорость Ethernet
  • обычно указывается с использованием метрических префиксов, поэтому канал Ethernet 100 Мбит — это именно то (100000000 бит)
  • Команды Linux отображают информацию о размере файла с использованием метрических префиксов. Однако использование переключателя –human-readable или -h обычно приводит к выводу с использованием двоичных префиксов, что довольно сбивает с толку
  • Windows отображает размеры файлов с использованием двоичных префиксов. Чтобы произвести точные вычисления, просмотрите свойства файла или используйте командную строку, чтобы узнать размер файла в байтах и ​​применить префикс метрики
  • .
  • Большинство других систем хранения используют двоичные префиксы
  • Производители жестких дисков обычно используют метрические префиксы, что означает, что они кажутся меньше, чем указано, когда емкость отображается с использованием двоичных префиксов

Биты и байты

  • 1 байт = 8 бит
  • Размеры файлов обычно указываются в байтах
  • Команды Linux отображают информацию о размере файла в байтах
  • Скорость соединения указана в МБ ( мегабит, ) в секунду, а не в мегабайтах, таким образом (без учета всех накладных расходов) потребуется 8 секунд, чтобы переместить 100 МБ (мегабайт) на 100 МБ (мегабит) в секунду Быстро Канал Ethernet

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

Служебные данные установления связи TCP / IP были проигнорированы, поскольку они незначительны.

Накладные расходы на передачу

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

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

Расчет накладных расходов

Я использовал здесь пять размеров данных, чтобы продемонстрировать, что накладные расходы остаются достаточно стабильными, пока объем данных превышает обычный IP MSS в 1460 байт;

1B данных

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

  • 1B может содержаться в 1 пакете размером не более 1460 байт (TCP MSS по умолчанию)
  • 1 x 40 байтов заголовков TCP и IP равняется 40 байтам, 4100% накладных расходов TCP / IP
  • Таким образом, фактически по сети передается 41 байт данных
1 КБ данных
  • 1 КБ (1000 байтов) может содержаться в 1 пакете размером не более 1460 байтов (1000/1460 = 0,684.)
  • 1 x 40 байтов заголовков TCP и IP равняется 40 байтам, 4% накладных расходов TCP / IP
  • Таким образом, фактически по сети передается 1040 байт данных
20 КБ данных
  • 20kB (20,000Bytes) должны быть разделены на 14 пакетов, каждый пакет не должен превышать 1460Bytes (20,000 / 1460 = 13.70.)
  • 14 x 40 байтов заголовков TCP и IP равны 560 байтам, 2,8% накладных расходов TCP / IP
  • Таким образом, фактически по сети передается 20,560 Байт данных
480 КБ данных
  • 480 КБ (480 000 байтов) необходимо разделить на 329 пакетов, каждый пакет не должен превышать 1460 байтов (480 000/1460 = 328,77.)
  • 329 x 40 байт заголовков TCP и IP равны 13160 байт, 2,74% накладных расходов TCP / IP
  • Таким образом, фактически по сети передается 493160 байт данных
1 МБ данных
  • 1 МБ (1000000 байтов) должен быть разделен на 685 пакетов, каждый пакет не должен превышать 1460 байтов (1000000/1460 = 684.93.)
  • 685 x 40 байтов заголовков TCP и IP равны 27 400 байтам, 2,74% накладных расходов TCP / IP
  • Таким образом, 1027400 байт данных фактически передается по сети

Резюме

Итак, как показано, для полезной нагрузки данных, превышающей общий максимальный размер сегмента полезной нагрузки TCP (MSS), равный 1460 байтам, накладные расходы на пропускную способность TCP через IP составляют приблизительно 2,8% . Это соответствует «эффективности» 97,33% (1460/1500) — другими словами, это то, сколько полосы пропускания остается для фактических данных, если вы помещаете как можно больше данных в каждый пакет.

Однако имейте в виду, что для очень небольших объемов данных (обычно используемых в таких приложениях, как Telnet, эмуляция мэйнфрейма TN3270 и SSH) накладные расходы на пропускную способность TCP через IP могут быть выше 4,000% .

Если вы добавите в смесь Ethernet (и тегирование VLAN) (см. Расчеты из Википедии), то пропускная способность канала 100 Мбит составит 100 X 0,9733 (эффективность TCP / IP) x 0,9728 (эффективность Ethernet (с тегированием)), что равно 94,68 Мбит / с, что, как я предполагаю, означает, что совокупная эффективность составляет 94.68%.

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

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

Если вы ищете аргумент относительно того, почему вам следует использовать Jumbo-кадры в среде LAN, я не думаю, что он есть; тем не менее, как я уже сказал, в некоторых кругах% имеет значение.

Другие статьи из этой серии;

Значок Обложка, использованная в этой статье, принадлежит проекту GNOME и находится под лицензией Creative Commons Attribution-Share Alike 3.0 United States License.

Сеть

— что лучше? Много маленьких TCP-пакетов или один длинный?

Можно использовать много маленьких пакетов.Фактически, если вас беспокоят накладные расходы TCP, просто вставьте буферный поток , который собирает до 1500 символов (или каковы бы ни были ваши TCP MTU, лучше всего запрашивать его динамически), и решите проблему в одном месте. Это избавит вас от накладных расходов в размере ~ 40 байт на каждый дополнительный пакет, который вы в противном случае создали бы.

Тем не менее, все же лучше отправлять меньше данных, и создание более крупных объектов помогает в этом. Конечно, отправить "UID: 10 | 1 | 2 | 3 меньше, чем отправить UID: 10; x: 1UID: 10; y: 2UID: 10; z: 3 .Фактически, также на этом этапе вам не следует изобретать колесо, используйте библиотеку, такую ​​как protobuf , которая может уменьшить такие данные до 10-байтовой строки или меньше.

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

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

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

Насколько большим может быть пакет?

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

Сегодня поговорим о размерах пакетов.

UDP

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

Здесь есть одна интересная вещь: когда вы отправляете UDP-пакет, вы нужно решить, сколько информации и поместить в пакет.

Это означает, что вам нужно знать, сколько данных может поместиться в пакете! Вот диаграмма, показывающая, как выглядит UDP-пакет.16-1 или от 0 до 65535.

Итак, у меня может быть UDP-пакет размером 65535 байт, верно?

Что ж, получается, что если вы отправляете UDP-пакет размером 30 000 байт на Интернет, вероятно, не дойдет. Почему нет? Это из-за Ethernet!

Встречайте: размеры фреймов Ethernet и MTU

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

Каждый пакет находится в кадре Ethernet.Кадры Ethernet могут содержать только 1500 байтов данных. Это называется «Максимальная единица передачи» или «MTU»!

Итак, если я попытаюсь отправить пакет UDP 30 000, используя протокол Ethernet с MTU 1500 байт, что произойдет? Мы не можем отправить 30 000 байт в 1500 байт. Не работает.

Таким образом, произойдет одно из двух: либо из пакета будет сброшено (не отправляется вообще) или фрагментировано .

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

Иногда сетевые реализации разделяют пакеты на несколько шт.Итак, если у вас есть пакет размером 15000 байт, вы можете разделить его до 10 или около того пакетов по 1500 байт.

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

Мне кажется более странным разделить UDP-пакет — если я отправляю вам большой UDP-пакет и он фрагментируется, как мне его собрать? Что, если части, которые расстались вышли из строя? Кто-то в Твиттере сказал мне, что вы можете собрать UDP-пакеты, но я еще не знаю, как это работает.

Я все еще не понимаю, как работает фрагментация пакетов и в каких случаях это приводит к потере пакетов. (фрагментация хуже для TCP пакеты или UDP пакеты?)

Как определить свой MTU?

Что, если вы хотите знать, какое значение MTU находится между двумя точками?

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

  • отправить большой пакет с пометкой «Никогда не фрагментируйте это!»
  • в первой точке, где этот пакет будет фрагментирован, он заметит и отправьте обратно ICMP-пакет, в котором говорится, что пакет фрагментирован (Пакеты ICMP — это то, что маршрутизаторы используют для отправки подобной метаинформации)
  • успехов! Теперь вы знаете первую точку, в которой пакет будет фрагментирован!

Оказывается, в Linux есть инструмент, который это сделает. путь трассировки .

  $ tracepath google.com
1 ?: [LOCALHOST] pmtu 1500
1: OpenWrt.lan 1,705 мс
1: OpenWrt.lan 1.973 мс
2: 10.252.42.193 9.116 мс
3: 10.170.192.58 8.046 мс
asymm 4
  

Я думаю, что MTU в моей локальной сети составляет 1500 байт. Что имеет смысл, я Угадай! Моя локальная сеть в норме.

Дэвид Мюррей рассказал о Path MTU Discovery на Papers We Love Сиэтл, который выглядит довольно интересно.

jumbo-кадра

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

Более новые версии Ethernet поддерживают «jumbo-кадры», что означает, что вы может отправлять большие пакеты.

Эта документация о MTU внутри AW действительно интересна, если вы запускаете экземпляры AW и задаетесь вопросом, как все это применимо к AWS.

вот и все

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

Пошаговое понимание внутреннего устройства TCP для инженеров-программистов и разработчиков систем — Часть 1 | by Kousik Nath

Данные начинают поступать с прикладного уровня (уровень OSI 5, 6, 7). Все виды преобразования данных напр.из ASCII в EBCDIC, на этом уровне происходит шифрование и т. д. Уровень приложения создает заголовок с необходимой информацией, общается с DNS (в сетях Windows, WINS — Windows Internet Name System) для разрешения IP-адреса получателя, упаковывает его с портом назначения для создания адреса сокета, помещает адрес сокета в заголовок , присоединяет байты данных приложения после заголовка, чтобы создать единицу данных. Данные отправляются на транспортный уровень в виде потока байтов, поскольку одновременная передача больших объемов данных ядру была бы неэффективной.

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

Мы обсудим внутреннее устройство TCP-соединений и структуру сегментов TCP позже в этой статье.

Протоколы транспортного уровня передают сегменты на уровень Интернета (уровень IP), где протокол IP подготавливает их к доставке. IP может дополнительно фрагментировать сегменты TCP (это называется фрагментацией ) и прикрепляет заголовок IP поверх, чтобы создать блок данных, называемый дейтаграммой IP ( иногда называют IP-пакетом ) . Если несколько фрагментов создаются из сегмента транспортного уровня, IP назначает уникальный порядковый номер каждому из них, чтобы их можно было собрать на уровне IP на стороне получателя.IP ненадежный, не гарантирует доставку данных. IP обеспечивает отличную абстракцию по базовой сети и может использоваться в гетерогенной сети (т. Е. Сеть, соединяющая два компьютера, может представлять собой любое сочетание Ethernet, ATM, FDDI, Wi-Fi, Token Ring и т. Д.), И это не делает отличие от протоколов верхнего уровня.

Широкое техническое обсуждение IP выходит за рамки данной статьи.

IP-дейтаграммы передаются на уровень канала данных. Самая важная вещь, которую делает этот уровень, — это преобразование IP-адреса в MAC-адрес (физический адрес).Для этого преобразования используется протокол разрешения адресов (ARP). Этот уровень форматирует дейтаграмму в кадр , присоединяя к нему другой заголовок. Заголовок кадра включает в себя поле проверки циклическим избыточным кодом (CRC), которое проверяет наличие ошибок при прохождении кадра по сетевому носителю. Такие протоколы, как PPP, могут создавать прямое сетевое соединение между маршрутами. Затем уровень канала передачи данных передает кадр на физический уровень.

ARP используется преимущественно для преобразования IP-адреса в MAC-адрес Ethernet, но на самом деле его можно использовать для преобразования многих других адресов протоколов сетевого уровня в аппаратные адреса.ARP — это не просто протокол только для IP или только для Ethernet. Фактически не только для IP через Ethernet, ARP также может использоваться для IP через другие технологии LAN, такие как Token Ring, FDDI или IEEE 802.11, ATM и т. Д.

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

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

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

MTU и MSS : MTU или Максимальный блок передачи — это максимальный размер дейтаграммы, поддерживаемый данным канальным уровнем.

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

 MSS = полезная нагрузка TCP или размер данных без заголовка TCP 

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

MSS вычисляется из MTU по следующей формуле:

 MTU = IP-заголовок (минимальный размер = 20 байтов) + TCP-заголовок (минимальный размер = 20 байтов) + полезная нагрузка TCP (или MSS) => MSS = MTU - 40 

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

MTU Размер зависит от уровня канала, не все каналы поддерживают одинаковый размер, некоторые примеры приведены ниже:

Предоставлено: https://community.cisco.com

IP MTU : та же концепция, что и MTU но для уровня IP. Он используется для фрагментации данных на уровне IP. Минимальный размер — 128 байта; максимум зависит от интерфейса носителя.

 IP MTU = IP-заголовок + TCP-заголовок + полезная нагрузка TCP (MSS) 

Изменение значения MTU (с помощью команды настройки интерфейса mtu) может повлиять на значение IP MTU.Если текущее значение IP MTU совпадает со значением MTU, и вы измените значение MTU, значение IP MTU будет автоматически изменено, чтобы соответствовать новому MTU. Однако обратное неверно; изменение значения IP MTU не влияет на значение команды mtu.

См. Следующий рисунок для визуализации MTU , IP MTU и MSS , посмотрите, как заголовки включаются или исключаются при вычислении MSS или MTU . Размер полезной нагрузки 1460 байт для MSS — это просто пример полезной нагрузки, вам не нужно беспокоиться об этом.

Предоставлено: https://www.imperva.com

Некоторые подробности о MSS и MTU также можно найти здесь.

Некоторые данные о размере заголовка и полезной нагрузки

Максимальный размер заголовка HTTP: Спецификация HTTP не говорит о максимально допустимом размере заголовка. Хотя веб-серверы ставят свои ограничения. Apache ограничивает максимальный размер заголовка 8 КБ, Nginx имеет предел от 4 КБ до 8 КБ, предел IIS составляет от 8 КБ до 16 КБ, предел Tomcat составляет от 8 КБ до 48 КБ.

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

Размер сегмента TCP: Минимальный размер заголовка TCP составляет 20 байта, максимальный — 60 байта. Теоретический предел максимально возможного размера сегмента TCP (заголовок + полезная нагрузка) составляет 65535 байта, хотя, как уже описано, MSS (только полезная нагрузка) определяется на основе размера MTU , чтобы избежать фрагментации канального уровня и потери пакетов.

 Размер сегмента TCP = размер заголовка TCP + MSS 

Размер IP-дейтаграммы: Минимальный размер заголовка IP составляет 20 байта, максимальный — 60 байта. Теоретический предел максимально возможного размера IP-дейтаграммы составляет 65535 байта. Хотя практически это не размер по той же причине, что и TCP.

Уровень канала передачи данных / Ethernet Размер кадра: Размер заголовка 18 байта. Заголовок включает MAC-адрес источника и назначения, тип протокола, за которым следует последовательность проверки кадра, помещенная в конце кадра.

Минимальный размер полезной нагрузки на этом уровне составляет 46 байта, максимальный — 1500 байта.

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

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

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

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

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

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

SYN — Клиент выбирает случайный порядковый номер и отправляет пакет SYN с другими флагами и параметрами TCP.

SYN ACK — Сервер увеличивает x на 1 , генерирует собственный случайный порядковый номер y , добавляет свой собственный набор флагов и опций и отправляет ответ.

ACK — Клиент увеличивает x и y на 1 и отправляет последний ответ ACK для завершения рукопожатия.

Предоставлено: HPBN

Клиент немедленно начинает отправку пакетов данных после отправки пакета ACK , но сервер должен дождаться прибытия ACK . Таким образом, SYN -> SYN_ACK занимает полное время кругового обхода в сети, а также ACK добавляет к этому больше времени.Эта задержка установления соединения посредством 3-стороннего рукопожатия очень значительна и приводит к задержке связи между клиентом и сервером. Эта задержка возникает из-за времени распространения между клиентом и сервером, а не из-за пропускной способности какой-либо стороны. Следовательно, управление постоянным TCP-соединением / повторное использование соединения имеет большое значение, а не просто открытие нового соединения каждый раз.

TCP Fast Open

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

TCP Fast Open (TFO) — это механизм, направленный на уменьшение штрафа за задержку, налагаемого на новые TCP-соединения. На основе анализа трафика и эмуляции сети, проведенного в Google, исследователи показали, что TFO, который позволяет передавать данные в пакете SYN, может уменьшить задержку в сети транзакций HTTP на 15%, время загрузки всей страницы в среднем более чем на 10% и в некоторых случаях до 40% в сценариях с высокой задержкой.

Поддержка TFO клиента и сервера теперь доступна в Linux 3.7+ ядер, что делает его жизнеспособным вариантом для новых клиентов и серверов. При этом TFO также не является решением всех проблем. Хотя это может помочь устранить штраф за двусторонний переход при трехстороннем рукопожатии, он также работает только в определенных случаях: существуют ограничения на максимальный размер полезной нагрузки данных в пакете SYN, могут быть отправлены только определенные типы HTTP-запросов, и он работает только для повторных подключений из-за необходимости использования криптографических файлов cookie. Подробное обсуждение возможностей и ограничений TFO см. В последнем проекте IETF
«TCP Fast Open.

Полный жизненный цикл TCP-соединения

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

ЗАКРЫТО : Это состояние можно рассматривать как начальное, а также как конечное состояние для TCP-соединения. Поскольку соединение еще не установлено, первоначальное соединение считается закрытым.

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

SYN_SENT (состояние на стороне получателя): получатель отправляет сегмент SYN серверу, чтобы запустить процесс трехстороннего подтверждения, и переходит в состояние SYN_SENT .

SYN_RECD (состояние на стороне отправителя): отправитель получает (при условии отсутствия потери данных) сегмент SYN, отправляет сегмент SYN_ACK ( SYN + ACK ) получателю, указывая, что он получил запрос подтверждения соединения от получатель.Состояние TCP на стороне сервера теперь SYN_RECD

Клиент все еще находится в состоянии SYN_SENT , он получает сегмент ( SYN_ACK / SYN + ACK ) от сервера, отправляет обратно ACK , указывая на завершение 3 -Подходящее рукопожатие. Сервер все еще находится в состоянии SYN_RECD .

Раздел «Трехстороннее рукопожатие» уже подробно описывает этот механизм.

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

Предоставлено: https://www.ictshore.com/

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

Завершение TCP-соединения — это непростой процесс, это четырехсторонний процесс установления связи.

FIN_WAIT_1 & CLOSE_WAIT : Инициатор отправит ответчику сообщение FIN , он перейдет из состояния ESTABLISHED в состояние FIN_WAIT_1 , а ответчик перейдет в состояние CLOSE_WAIT , как только получит это состояние. FIN , отправка ACK в ответ.

FIN_WAIT_2 : Когда инициатор получает этот ACK , он просто переходит в состояние FIN_WAIT_2 и ничего не делает. Ответчик все еще находится в состоянии CLOSE_WAIT , поскольку он ожидает, пока приложение завершит все свои операции и закроется.

LAST_ACK : как только приложение на стороне респондента завершит работу, ответчик отправит инициатору сообщение FIN , чтобы сообщить, что он также хочет закрыть соединение, таким образом он переходит в состояние LAST_ACK .

TIME_WAIT : как только инициатор получит FIN от ответчика, он отправит ACK и перейдет в состояние TIME_WAIT .

ЗАКРЫТО : как только ответчик получит ACK, он вернется в состояние ЗАКРЫТО . После таймера в две миллисекунды инициатор также перейдет в состояние ЗАКРЫТО, . По словам обеих вовлеченных сторон, соединение теперь разорвано.

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

Предоставлено: https://www.ictshore.com/

Как вы можете видеть на картинке, этот процесс закрытия является абсолютно симметричным . Клиент отправляет серверу FIN, чтобы закрыть соединение, и переходит в состояние FIN_WAIT_1 . В то же время сервер отправляет клиенту FIN с тем же намерением, переходя также в состояние FIN_WAIT_1 . Клиент получает FIN, поэтому он переходит в состояние ЗАКРЫТИЕ, , отправляя ACK.То же самое происходит с сервером, который также получает FIN и переходит в состояние ЗАКРЫТИЕ , отправив ACK. Когда любое из двух устройств получает ACK, оно переходит в состояние TIME_WAIT и, после тайм-аута, в состояние ЗАКРЫТО, . В основном, при одновременном закрытии флаг FIN принимается, находясь все еще в состоянии FIN_WAIT_1 . — https://www.ictshore.com/

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

Предоставлено: github.com

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

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

Предоставлено: Wikipedia

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

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

Почему заголовок TCP содержит только адрес порта, а не IP-адрес?

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

Порядковый номер: 32 бит — Имеет двойную роль:

  • Если установлен флаг SYN ( 1 ), то это начальный порядковый номер.Порядковый номер фактического первого байта данных и подтвержденный номер в соответствующем ACK равны этому порядковому номеру плюс 1.
  • Если флаг SYN сброшен ( 0 ), то это накопленный порядковый номер первый байт данных этого сегмента для текущего сеанса.

Номер подтверждения: 32 бит — Если установлен флаг ACK , то значение этого поля является следующим порядковым номером, который отправитель ACK ожидая.Это подтверждает получение всех предыдущих байтов (если таковые имеются). Первый ACK , отправленный каждой стороной, подтверждает сам начальный порядковый номер другой стороны, но не данные.

Смещение данных: 4 бит — Задает размер заголовка TCP в 32 -битных словах. Минимальный размер заголовка составляет 5 слов, а максимальный — 15 слов, что дает минимальный размер 20 байта и максимум 60 байта, что позволяет использовать до 40 байтов параметров в заголовке.Это поле получило свое название из-за того, что это также смещение от начала сегмента TCP до фактических данных.

Зарезервировано: 3 бит — Для использования в будущем и должен быть установлен на ноль.

Флаги: 9 бит — (также называемые контрольными битами) Содержит 9 1 -битовые флаги:

  • ACK — флаг «Подтверждение», который используется для подтверждения успешного получения сегмента .
  • NS (экспериментальный флаг) — флаг Nonce Sum, используемый для защиты от случайного злонамеренного сокрытия сегментов от отправителя.Дополнительные сведения: RFC 3540
  • ECE — этот флаг отвечает за указание, поддерживает ли узел TCP ECN (явное уведомление о перегрузке). См. RFC 3168 для получения более подробной информации.
  • CWR — «Окно перегрузки уменьшено», используется хостом-отправителем, чтобы указать, что он получил сегмент с установленным флагом ECE. Дополнительные сведения: RFC 3168
  • URG — Флаг URG используется для уведомления получателя о необходимости обработки срочных сегментов перед обработкой всех других сегментов.Получатель будет уведомлен, когда будут получены все известные срочные данные. Подробнее: RFC 6093.
  • PSH — Флаг «Push», как и флаг URG, также указывает получателю обрабатывать сегменты по мере их получения, а не буферизовать их.
  • RST — флаг «Сброс». Когда хост получает неожиданный сегмент TCP, этот хост обычно отвечает, отправляя пакет сброса обратно по тому же соединению. Пакет сброса — это просто пакет без полезной нагрузки и с битом RST, установленным во флагах заголовка TCP.
  • FIN — «Готово», это означает, что больше нет данных от отправителя. Следовательно, он используется в последнем сегменте, отправленном отправителем.

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

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

Указатель срочности: 16 бит — если установлен флаг URG, то это 16-битное поле является смещением от порядкового номера, указывающего последний байт срочных данных.

Опции: Обязательные элементы заголовка TCP занимают 20 байтов. За этими обязательными элементами следуют необязательные.Необязательный элемент состоит из типа необязательного элемента, длины необязательного элемента и значения. Длина сегмента TCP должна быть кратной четырем. Если длина заголовка не кратна четырем, она дополняется параметрами NOP (без операции).

Поскольку длина поля заголовка всего сегмента TCP составляет всего четыре бита, это поле может содержать только максимальное значение 1111 (двоичное) = 15 (десятичное). Длина заголовка определяется кратной четырем, поэтому максимальная длина заголовка может составлять 15 x 4 = 60 байтов.Обязательные элементы занимают 20 байтов, поэтому для дополнительных элементов остается не более 40 байтов.

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

Предоставлено: Общие сведения о TCP / IP — публикация пакетов

Важно понять: как получатель подтверждает полученный сегмент TCP?

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

  • Получатель знает, сколько байтов он получил, скажем, он получил 200 байта данных, поэтому получатель обработал данные до ( 1000 + 200 ) = 1200 смещение уже. В подтверждении получатель отправит 1200 + 1 = 1201 (смещение следующих данных) в качестве номера подтверждения и установит флаг ACK , указывающий, что сегмент представляет подтверждение. Таким образом, при следующей передаче отправитель будет передавать байты данных со смещения 1201 .
  • ИЛИ другой способ: получатель не заботится о количестве полученных байтов, а просто увеличивает порядковый номер, отправленный сервером, на 1 , устанавливает это увеличенное значение (в приведенном выше примере — 1001 ) как последовательность подтверждения номер в заголовке TCP вместе с установленным флагом ACK . Когда отправитель получает ACK , он знает, что получатель полностью получил предыдущий сегмент, и отправляет следующие байты данных со смещениями по запросу.

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

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

Оставайтесь с нами!

Ссылки:

  1. HPBN: высокопроизводительная сеть для браузеров.
  2. https://docs.oracle.com/cd/E18752_01/html/816-4554/ipov-29.html
  3. https://www.pcmag.com/encyclopedia/term/52615/tcp-ip-abc-s
  4. https://community.cisco.com/t5/vpn-and-anyconnect/difference-between- interface-mtu-and-ip-mtu / td-p / 650311
  5. https://stackoverflow.com/questions/686217/maximum-on-http-header-values ​​
  6. http://networkqna.com/what- is-the-difference-between-the-mss-and-mtu /
  7. https://www.custompcreview.com/articles/difference-between-modem-router-switch/
  8. https://www.quora. com / Why-is-a-router-connected-to-the-switch
  9. https: // techdifferences.com / difference-between-tcp-ip-and-osi-model.html
  10. https://www.keycdn.com/support/tcp-flags

1. Обзор TCP / IP — Администрирование сети TCP / IP , 3-е издание [Книга]

Все мы, кто использует настольную систему Unix — инженеры, преподаватели, ученые и бизнесмены — имеют вторую карьеру в системе Unix администраторы. Объединение этих компьютеров в сеть дает нам новые задачи, поскольку сеть администраторы.

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

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

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

Имя «TCP / IP» относится ко всему набору протоколов передачи данных. В Suite получил свое название от двух принадлежащих ему протоколов: Протокол управления передачей (TCP) и Интернет-протокол (IP).TCP / IP — традиционное имя для этого набора протоколов, и это имя используется в эта книга. Набор протоколов TCP / IP также называется Интернет-протоколом. Люкс (IPS). Оба имени приемлемы.

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

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

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

Экспериментальная сеть оказалась настолько успешной, что многие из прикрепленные к нему организации начали использовать его для ежедневных данных коммуникации. В 1975 году сеть ARPAnet была преобразована из экспериментальной сеть к действующей сети, и ответственность за управление сетью было передано Агентству оборонных коммуникаций (DCA). [] Однако развитие ARPAnet не остановилось просто потому что он использовался как оперативная сеть; базовый TCP / IP протоколы были разработаны после того, как сеть заработала.

Протоколы TCP / IP были приняты в качестве военных стандартов (MIL STD) в 1983 году, и все хосты, подключенные к сети, должны были перейти на новые протоколы. Чтобы облегчить это преобразование, Агентство DARPA [] профинансировало Bolt, Beranek и Newman (BBN) на внедрение TCP / IP. в Беркли (BSD) Unix. Так начался союз Unix и TCP / IP.

Примерно в то время, когда TCP / IP был принят в качестве стандарта, термин Интернет вошел в обиход. В 1983 году старый ARPAnet был разделен на MILNET, несекретную часть Defense Data Network. (DDN) и новый ARPAnet меньшего размера.«Интернет» использовался для относятся ко всей сети: MILNET плюс ARPAnet.

В 1985 году Национальный научный фонд (NSF) создал NSFNet и подключил его к существовавшему на тот момент Интернету. Исходный NSFNet связан вместе пять суперкомпьютерных центров NSF. Он был меньше, чем ARPAnet и не быстрее: 56 Кбит / с. Тем не менее создание NSFNet было знаменательное событие в истории Интернета, потому что NSF принес с ним новое видение использования Интернета.NSF хотел расширить сеть для каждого ученого и инженера в Соединенных Штатах. К Чтобы добиться этого, в 1987 году NSF создал новую, более быструю магистраль и трехуровневая топология сети, включающая магистральную, региональную сети и локальные сети. В 1990 году сеть ARPAnet официально перестала существовать. существования, и в 1995 году NSFNet перестала играть роль основного Интернет-центра. магистральная сеть.

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

Интернет вырос далеко за пределы своих первоначальных возможностей.Оригинал сети и агентства, построившие Интернет, больше не играют существенная роль для текущей сети. Интернет эволюционировал из простая магистральная сеть с трехуровневой иерархической структурой, в огромную сеть взаимосвязанных распределенных сетевых узлов. Она имеет росла в геометрической прогрессии с 1983 года — ежегодно увеличиваясь вдвое. Через все этого невероятного изменения одно осталось неизменным: Интернет построен на наборе протоколов TCP / IP.

Признаком успеха сети является неразбериха, которая окружает термин интернет . Первоначально он использовался только как имя сети, построенной на IP. Сейчас интернет — это общий термин, используемый для обозначения целого класса сетей. An Интернет (строчная буква «i») — это любой набор отдельных физических сети, соединенные общим протоколом, чтобы сформировать единый логический сеть. Интернет (прописная буква «I») — это всемирная коллекция взаимосвязанные сети, которые выросли из оригинальной сети ARPAnet, использует IP для соединения различных физических сетей в единую логическую сеть.В этой книге и «Интернет», и «Интернет» относятся к сетям. которые связаны между собой по TCP / IP.

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

Популярность протоколов TCP / IP не росла быстро только потому, что протоколы присутствовали или потому, что подключение к Интернету было обязательным. их использование. Они удовлетворили важную потребность (передача данных по всему миру) в нужное время, и у них было несколько важных функций, которые позволил им удовлетворить эту потребность.Это следующие функции:

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

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

  • Общая схема адресации, допускающая любой TCP / IP. устройство для уникальной адресации любого другого устройства во всей сети, даже если сеть такая же большая, как всемирный Интернет.

  • Стандартизированные протоколы высокого уровня для согласованного, широкого доступные пользовательские сервисы.

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

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

Открытый характер протоколов TCP / IP требует процесса разработки открытых стандартов и общедоступности нормативные документы. Интернет-стандарты разрабатываются Internet Engineering Task Force (IETF) открыто, публично встречи. Протоколы, разработанные в этом процессе, публикуются. как Запросы комментариев (RFC). [] Как следует из заголовка «Запрос комментариев», стиль и содержание этих документов гораздо менее жесткое, чем в большинстве нормативные документы. RFC содержат широкий спектр интересных и полезную информацию, и не ограничиваются формальной спецификацией протоколы передачи данных. Есть три основных типа RFC: стандарты (STD), лучшие текущие практики (BCP) и информационные (К вашему сведению).

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

Предлагаемый стандарт

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

Проект стандарта

Это спецификация протокола, для которой не менее двух существуют независимые, функционально совместимые реализации. Черновик standard — это окончательная спецификация, которая проходит широкое тестирование. Он изменится только в том случае, если тестирование принудительно изменит.

Интернет-стандарт

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

Есть две категории стандартов. Техническая спецификация (TS) определяет протокол. Заявление о применимости (AS) определяет, когда следует использовать протокол. Есть три уровней требований , которые определяют применимость стандарта:

Обязательно

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

Рекомендуется

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

Факультативный

Этот стандарт не является обязательным. Это зависит от программного обеспечения продавец реализовывать это или нет.

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

Experimental

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

Исторический

Исторический RFC устарел и больше не актуален рекомендуется к применению.

Информационный

Информационный RFC предоставляет информацию общего интерес к Интернет-сообществу; это не определяет Стандартный протокол Интернета.

Подмножество информационных RFC называется примечаниями FYI (для вашей информации). Документ для справки — это дается номер FYI в дополнение к номеру RFC. Документы для информации предоставить вводные и справочные материалы об Интернете и Сети TCP / IP.Документы FYI не упоминаются в RFC 2026 и не включены в процесс стандартов Интернета. Но есть несколько доступны интересные документы FYI. []

Еще одна группа RFC, выходящих за рамки документирования протоколов: RFC с лучшими текущими практиками (BCP). ПП официально документировать методы и процедуры. Некоторые из них документируют путь что IETF ведет себя сам; RFC 2026 является примером этого типа BCP. Другие предоставляют инструкции по эксплуатации сети или служба; RFC 1918, Распределение адресов для частных сетей , является примером этого типа BCP.ПП, которые предоставить инструкции по эксплуатации часто представляют большой интерес для сети администраторы.

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

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

Архитектурная модель, разработанная по международным стандартам. Организация (ISO) часто используется для описания структуры и функция протоколов передачи данных. Эта архитектурная модель, который называется Open Systems Interconnect (OSI) Эталонная модель , предоставляет общий справочник для обсуждения связи.Термины, определенные в этой модели, хорошо понятны и широко используются в сообщество передачи данных — настолько широко используется, что трудно обсуждать обмен данными без использования OSI терминология.

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

Рисунок 1-1. Эталонная модель OSI

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

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

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

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

Уровень приложения

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

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

Для совместных приложений для обмена данными они должны согласны с тем, как представлены данные. В OSI презентация Layer предоставляет стандартные процедуры представления данных.Эта функция часто обрабатывается в приложениях в TCP / IP, хотя Протоколы TCP / IP, такие как XDR и MIME, также выполняют эту функцию.

Сеансовый уровень

Как и в случае с уровнем представления, сеансовый уровень не идентифицируется как отдельный уровень в протоколе TCP / IP иерархия. Сеансовый уровень OSI управляет сеансами. (соединения) между взаимодействующими приложениями. В TCP / IP это функция в основном встречается на транспортном уровне, а термин «Сессия» не используется; вместо этого термины «сокет» и «порт» используются для описания пути, по которому взаимодействующие приложения общаются.

Транспортный уровень

Большая часть нашего обсуждения TCP / IP направлена ​​на протоколы, встречающиеся на транспортном уровне. Транспортный уровень в эталонной модели OSI гарантирует, что получатель получит данные точно в том виде, в каком они были отправлены. В TCP / IP эта функция выполняется с помощью протокола управления передачей (TCP). Однако TCP / IP предлагает второй сервис транспортного уровня, Протокол пользовательских дейтаграмм (UDP), который не выполняет сквозной проверки надежности.

Сетевой уровень

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

Уровень канала данных

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

Физический уровень

Физический уровень определяет характеристики оборудование, необходимое для передачи данных сигнал. Такие функции, как уровни напряжения, количество и Расположение контактов интерфейса определяется в этом слое.Примеры стандарты на физическом уровне — это интерфейсные разъемы такие как RS232C и V.35, а также стандарты для проводки в локальной сети, такие как IEEE 802.3. TCP / IP не определяет физические стандарты — он использует существующих стандартов.

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

Хотя нет единого мнения о том, как описывать TCP / IP с помощью многоуровневой модели, TCP / IP обычно рассматривается как состоящий из меньшего количества уровней, чем семь, используемые в модели OSI. Большинство описаний TCP / IP определяют от трех до пяти функциональных уровней в архитектуре протокола. В четырехуровневая модель, показанная на рисунке 1-2 основан на трех уровнях (приложение, хост-хост и Доступ к сети), показанный в модели протокола DOD в DDN Protocol Handbook Volume 1 , с добавлением отдельного Интернет-уровень.Эта модель обеспечивает разумное графическое изображение. представление уровней в иерархии протокола TCP / IP.

Рисунок 1-2. Архитектура TCP / IP

Как и в модели OSI, данные передаются вниз по стеку, когда они отправляется в сеть и поднимается по стеку при получении из сети. Четырехуровневая структура TCP / IP видна в способ обработки данных при передаче по стеку протоколов из Уровень приложения к базовой физической сети.Каждый слой в stack добавляет управляющую информацию для обеспечения правильной доставки. Этот контроль информация называется заголовком , потому что она помещается перед данными, которые должны быть передан. Каждый уровень обрабатывает всю информацию, которую он получает от слой выше как данные, и помещает свой собственный заголовок перед этим Информация. Добавление информации о доставке на каждом уровне называется инкапсуляция . (См. Рисунок 1-3 для иллюстрации это.) При получении данных происходит обратное. Каждый слой полоски выключить его заголовок перед передачей данных на уровень выше. В качестве информация течет вверх по стеку, информация, полученная от нижнего слой интерпретируется и как заголовок, и как данные.

Рисунок 1-3. Инкапсуляция данных

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

На рис. 1-4 показаны термины используются разными уровнями TCP / IP для обозначения данных, которые передан. Приложения, использующие TCP, обращаются к данным как к потоку , а приложения, использующие UDP относится к данным как к сообщению . TCP называет данные сегментом , а UDP называет его данные пакет . Уровень Интернета просматривает все данные в виде блоков называются дейтаграммами .TCP / IP использует множество различных типов базовых сетей, каждый из которых может иметь различную терминологию для данных, которые он передает. Большинство сетей относятся к передаваемым данным как пакетов или кадров . На Рисунке 1-4 показано сеть, которая передает фрагменты данных, которые она вызывает рамки .

Рисунок 1-4. Структуры данных

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

Уровень доступа к сети — это самый нижний уровень иерархии протоколов TCP / IP. В протоколы на этом уровне предоставляют системе средства для доставки данных к другим устройствам в сети с прямым подключением. Этот слой определяет как использовать сеть для передачи дейтаграммы IP. В отличие от более высокого уровня протоколы, протоколы уровня доступа к сети должны знать детали базовая сеть (структура пакетов, адресация и т. д.), чтобы правильно форматировать передаваемые данные в соответствии с сетью ограничения.Уровень доступа к сети TCP / IP может включать в себя функции всех трех нижних уровней эталонной модели OSI (сеть, данные Ссылка и Физический).

Уровень доступа к сети часто игнорируется пользователями. Дизайн TCP / IP скрывает функцию нижних уровней, а наиболее известные протоколы (IP, TCP, UDP и т. д.) являются протоколами более высокого уровня. Как новый появляются аппаратные технологии, новые протоколы доступа к сети должны быть разработан таким образом, чтобы сети TCP / IP могли использовать новое оборудование.Следовательно, существует множество протоколов доступа — по одному для каждого физического сетевой стандарт.

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

Два RFC, которые определяют протоколы уровня доступа к сети являются:

  • RFC 826, Протокол разрешения адресов (ARP) , который сопоставляет IP-адреса с Ethernet адресов

  • RFC 894, Стандарт передачи дейтаграмм IP по сетям Ethernet , в котором указывается, как Дейтаграммы IP инкапсулированы для передачи через Ethernet. сетей

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

уровень выше уровня доступа к сети в иерархии протоколов это Internet Layer . Интернет-протокол (IP) является наиболее важным протоколом на этом уровне. Выпуск IP, используемый в текущем Интернете, — это IP версии 4 (IPv4), которая определена в RFC 791.Есть более свежие версии IP. IP версии 5 является экспериментальный протокол Stream Transport (ST), используемый для данных в реальном времени Доставка. IPv5 так и не вошел в оперативное использование. IPv6 — это стандарт IP что обеспечивает значительно расширенную адресную способность. Поскольку IPv6 использует совершенно другая адресная структура, она не совместима с IPv4. Хотя IPv6 является стандартной версией IP, он еще не получил широкого распространения. в операционных, торговых сетях. Поскольку мы делаем упор на практичность, действующих сетей, мы не рассматриваем IPv6 в деталях.В этой главе а в основной части текста «IP» относится к IPv4. IPv4 — это протокол, который вы настроите в своей системе, когда захотите обменять данные с удаленными системами, и этому посвящен этот текст.

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

Интернет-протокол — это строительный блок Интернета. Его функции включают:

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

  • Определение схемы адресации в Интернете

  • Перемещение данных между уровнем доступа к сети и Транспортный уровень

  • Маршрутизация дейтаграмм на удаленные хосты

  • Выполнение фрагментации и повторной сборки дейтаграмм

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

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

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

Дейтаграмма — это формат пакета, определенный по интернет-протоколу. Фигура 1-5 — графическое представление дейтаграммы IP. В первые пять или шесть 32-битных слов дейтаграммы являются контрольными информация называется заголовком .По умолчанию заголовок состоит из пяти слов; шестой слово не является обязательным. Поскольку длина заголовка переменная, он включает поле под названием Длина заголовка Интернета (МГП), который указывает длину заголовка прописью. В заголовок содержит всю информацию, необходимую для доставки пакет.

Рисунок 1-5. Формат IP-дейтаграммы

Интернет-протокол доставляет дейтаграмму путем проверки Адрес назначения в слове 5 заголовка.Адрес назначения — это стандартный 32-битный IP-адрес, который идентифицирует сеть назначения и конкретный хост в этой сети. (Формат IP-адресов объясняется в главе 2.) Если Адрес назначения — это адрес хоста в локальной сети, пакет доставляется прямо к месту назначения. Если Адрес назначения не находится в локальной сети, пакет перешли в шлюз для доставки. Шлюзы — это устройства, которые переключают пакеты между разными физическими сетями.Решая, какой шлюз для использования называется маршрутизацией . IP принимает решение о маршрутизации для каждого отдельного пакета.

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

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

Рисунок 1-6. Маршрутизация через шлюзы

Системы могут доставлять пакеты только на другие устройства, подключенные к та же физическая сеть. Пакеты от А1 предназначенные для хоста C1 перенаправляются через шлюзы G1 и G2 .Хозяин A1 сначала доставляет пакет на шлюз G1 , с которым он разделяет сеть А . Шлюз G1 обеспечивает пакет на G2 по сети В . Шлюз G2 тогда доставляет пакет непосредственно на хост C1 , потому что они оба подключены к сети C . Хозяин A1 не знает ни о каких шлюзах, кроме шлюз G1 .Он отправляет пакеты, предназначенные для обоих сети C и B к этому локальный шлюз, а затем полагается на этот шлюз для правильной пересылки пакеты по пути к месту назначения. Точно так же хозяин C1 отправляет свои пакеты на G2 выйти на хост в сети A , а также любой хост в сети B .

На рис. 1-7 показано другой взгляд на маршрутизацию. Этот рисунок подчеркивает, что лежащие в основе физические сети, через которые проходит дейтаграмма, могут быть разными и даже несовместимо.Хост A1 на Token Ring сеть направляет дейтаграмму через шлюз G1 для доступа к хосту C1 в сети Ethernet. Шлюз G1 пересылает данные через сеть X.25 на шлюз G2 для доставки на С1 . Дейтаграмма проходит через три физически разные сети, но в конечном итоге приходит в целости и сохранности С1 .

Рисунок 1-7. Сети, шлюзы и хосты

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

Каждый тип сети имеет максимальную единицу передачи (MTU), что является самым большим пакетом, который он может передача. Если дейтаграмма, полученная из одной сети, длиннее, чем MTU другой сети, дейтаграмма должна быть разделена на более мелкие фрагментов для передачи.Этот процесс называется фрагментация . Подумайте о поезде доставка груза стали. Каждый вагон может перевезти больше стали чем грузовики, которые повезут его по шоссе, поэтому каждая железная дорога груз автомобиля разгружается на множество различных грузовиков. Таким же образом что железная дорога физически отличается от шоссе, Ethernet физически отличается от сети X.25; IP должен нарушить Относительно большие пакеты Ethernet на более мелкие пакеты перед этим может передавать их по сертификату X.25 сеть.

Формат каждого фрагмента такой же, как формат любого нормальная дейтаграмма. Слово заголовка 2 содержит информацию, которая идентифицирует каждый фрагмент дейтаграммы и предоставляет информацию о том, как соберите фрагменты обратно в исходную дейтаграмму. В Поле идентификации определяет, какую дейтаграмму принадлежит фрагменту, а поле Fragmentation Offset сообщает, какой части дейтаграмма этот фрагмент есть. В поле «Флаги» есть бит «Больше фрагментов», который сообщает IP если он собрал все фрагменты дейтаграммы.

Передача дейтаграмм на транспортный уровень

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

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

Протокол управляющих сообщений Интернета

Неотъемлемой частью IP является протокол управляющих сообщений Интернета (ICMP), определенный в RFC 792. Этот протокол является частью Интернет-уровня и использует средство доставки IP-дейтаграммы для отправки своих Сообщения.ICMP отправляет сообщения, которые выполняют следующий контроль, отчеты об ошибках и информационные функции для TCP / IP:

Управление потоком

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

Обнаружение недоступных пунктов назначения

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

Перенаправление маршрутов

Шлюз отправляет сообщение перенаправления ICMP, чтобы указать хосту использовать другой шлюз, предположительно потому, что другой шлюз лучше выбор.Это сообщение можно использовать только тогда, когда исходный хост включен. та же сеть, что и оба шлюза. Чтобы лучше это понять, см. Рисунок 1-7. Если хост в сети X.25 отправил дейтаграмму на G1 , можно было бы G1 для перенаправления этого хоста на G2 потому что хост, G1 и G2 все подключен к той же сети. С другой стороны, если хост на сеть Token Ring отправила дейтаграмму на G1 , хост не может быть перенаправлен для использования Г2 .Это потому, что G2 не привязан к токен-рингу.

Проверка удаленных хостов

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

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

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

UDP — ненадежный протокол дейтаграмм без установления соединения. В качестве отмечен, «ненадежный» просто означает, что в протокол для проверки того, что данные достигли другого конца сеть правильно.На вашем компьютере UDP будет доставлять данные правильно. UDP использует 16-битные номера Source Port и Destination Port в слове 1 заголовка сообщения для доставки данных. к правильному процессу подачи заявок. На рисунке 1-8 показано сообщение UDP. формат.

Рисунок 1-8. Формат сообщения UDP

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

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

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

TCP обеспечивает надежность с помощью механизма, называемого Положительное подтверждение с повторной передачей (PAR). Проще говоря, система, использующая PAR, отправляет данные снова , если только не услышит от удаленной системы, что данные поступили нормально. Единица данных, которыми обмениваются сотрудничающие Модули TCP называются сегментом (см. Рис. 1-9). Каждый сегмент содержит контрольную сумму, которую получатель использует для проверки правильности данных. неповрежденный.Если сегмент данных получен неповрежденным, получатель отправляет положительное подтверждение обратно в отправитель. Если сегмент данных поврежден, получатель его отбрасывает. По истечении соответствующего периода тайм-аута отправляющий модуль TCP повторно передает любой сегмент для которое не было получено положительного подтверждения.

Рисунок 1-9. Формат сегмента TCP

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

Тип подтверждения, используемый TCP, называется трехстороннее рукопожатие , поскольку происходит обмен тремя сегментами. На рисунке 1-10 показана простейшая форма. трехстороннего рукопожатия.Хост A начинает соединение, отправив хосту B сегмент с Установлен бит «Синхронизировать порядковые номера» (SYN). Этот сегмент сообщает хосту B что A хочет установить соединение, и он сообщает B , какой порядковый номер хоста будет использовать в качестве начального номера для своих сегментов. (Порядковые номера используются для сохранения данных в правильном порядке.) Хост B отвечает на A с помощью сегмент, в котором установлены биты «Подтверждение» (ACK) и SYN. B ’сегмент s подтверждает получение A ‘сегмент s, и сообщает A с какого порядкового номера будет начинаться хост B . Наконец, хост A отправляет сегмент, подтверждающий получение сегмента B и передает первый фактические данные.

Рисунок 1-10. Трехстороннее рукопожатие

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

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

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

Каждый байт данных нумеруется последовательно от ISN, поэтому Первый реальный байт отправленных данных имеет порядковый номер ISN + 1.В Порядковый номер в заголовке сегмента данных определяет последовательная позиция в потоке данных первого байта данных в сегмент. Например, если первый байт в потоке данных был порядковый номер 1 (ISN = 0) и 4000 байтов данных уже были передается, то первый байт данных в текущем сегменте байт 4001, а порядковый номер будет 4001.

Сегмент подтверждения (ACK) выполняет две функции: положительное подтверждение и управление потоком .Подтверждение сообщает отправителю, сколько данных был получен и сколько еще может принять получатель. В Номер подтверждения — это порядковый номер следующего байта, получатель ожидает получить. Стандарт не требует индивидуальное подтверждение для каждого пакета. Номер подтверждения является положительным подтверждением всех байтов до этого числа. За Например, если первый отправленный байт был пронумерован 1 и 2000 байтов имеют был успешно получен, Номер подтверждения будет 2001 г.

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

На рисунке 1-11 показан протокол TCP. поток данных, который начинается с нулевого начального порядкового номера. принимающая система получила и подтвердила 2000 байтов, поэтому Текущий номер подтверждения — 2001. У получателя также достаточно буферное пространство еще на 6000 байт, поэтому объявлено окно размером 6000. Отправитель в настоящее время отправляет сегмент размером 1000 байт, начиная с с порядковым номером 4001.Отправитель не получил подтверждения для байтов с 2001 г., но продолжает отправлять данные, пока находится в окне. Если отправитель заполняет окно и не получает подтверждение ранее отправленных данных, после соответствующий тайм-аут, отправьте данные снова, начиная с первого неподтвержденный байт.

Рисунок 1-11. Поток данных TCP

На рисунке 1-11 повторная передача началась бы с байта 2001, если не далее получены благодарности.Эта процедура гарантирует, что данные надежно получен на дальнем конце сети.

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

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

Наиболее широко известные и реализованные протоколы приложений являются:

Telnet

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

FTP

Протокол передачи файлов, который используется для интерактивной передачи файлов.

SMTP

Простой протокол передачи почты, который доставляет электронная почта.

HTTP

Протокол передачи гипертекста, страницы по сети.

Хотя HTTP, FTP, SMTP и Telnet являются наиболее широко используемыми С приложениями TCP / IP, вы будете работать со многими другими как пользователь и Системный администратор.Некоторые другие часто используемые приложения TCP / IP являются:

Система доменных имен (DNS)

Также называется службой имен , это приложение сопоставляет IP-адреса с именами, присвоенными сети устройств. DNS подробно обсуждается в этой книге.

Сначала откройте кратчайший путь (OSPF)

Маршрутизация играет центральную роль в работе TCP / IP. OSPF используется сетью устройства для обмена маршрутной информацией.Маршрутизация также является важным тема этой книги.

Сетевая файловая система (NFS)

Этот протокол позволяет совместно использовать файлы с разных хостов на сеть.

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

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