Comments 31
А тут уже новый протокол (стек) надо изучать "В России разрабатывается на отечественный аналог протокола TCP/IP"
Интересно, что ж значит:
"в нынешнем своем виде отечественный ответ TCP/IP работает лучше зарубежного аналога: «Если задержка или потеря пакетов в TCP происходит в размере одного процента, то TСP восстанавливает эти пакеты в течение 360 сек. Мы восстанавливаем – 5,7 сек». "
Когда ученый изнасиловал журналиста инженер покусал руководителя. Рискну предположить, что они меряли время восстановления полосы (скорости) до прежнего значения, т.е. по факту размер congestion window. В статье, под которой комментируем, кстати, ни слова о том, как именно congestion window уменьшается у TCP при потерях, вопрос рассмотрен только наполовину.
По словам Селютина, в нынешнем своем виде отечественный ответ TCP/IP работает лучше зарубежного аналога. «Если задержка или потеря пакетов в TCP происходит в размере одного процента, то TСP восстанавливает эти пакеты в течение 360 сек. Мы восстанавливаем – 5,7 сек.» – отметил он.
А по словам biff_33, мой принципиально новый протокол ТСP восстанавливает пакеты за -3 (минус 3) секунды. Отрицательное время добавляется к положительному, поэтому мы выходим в 0 задержек или потерь. Дайте мне 100500 миллионов на поддержку, в госдуму пойду, депутатом буду. =)
первая картинка и сразу возникло у меня противоречие. алгоритм балансировки, который показан на картинке что-то типа round-robin, который в аппаратных маршрутизаторах и коммутаторах не используется и проблемы с reorder нет. Есть ECMP с балансировкой аппаратной по hash-функции l3/l4. даже LAGG умеет такую балансировку. в juniper ECMP как per-flow анронсируется в конфиге. Так что UDP пакеты в маршруте будут идти также как и TCP.
Hidden text
на всякий случай ещё, основные отличия простым языком
Я бы рассказал вам шутку про UDP, да боюсь не дойдёт.
А я буду рассказывать шутку про TCP, до тех пор, пока не поймете.
Если можно расскажите про websocket технологии и long pooling типы подключения, да и любые подключения что посчитаете важными) понравилось ваше изложение, спасибо.
Существует два способа установить соединение перед отправкой данных с одного устройства на другое: с установлением соединения (connection-oriented) и без установления соединения (connectionless).
Что-что простите? Существует два способа есть яблоки - с поеданием яблок и без поедания яблок?.. Не понял, что хотел сказать автор этой фразой. Это перевод такой?
некоторые моменты всё же не очень понятны:
1) перегрузка траффика в узлах - а где это может быть и какие для этого условия? Например, есть роутер, 100 Мб соединение и мы вовсю качаем торренты - и они выжирают весь ресурс роутера. И вот мы хотим зайти на хабр посмотреть новости - и после заброса к habr.com от него будет ответ, поделенный на пакеты. И что - пакеты просто пропадут в роутере, их роутер отбросит или будет отбрасывать через один или как там получится - и тогда habr.com будет продолжать последовательную передачу пакетов, проверяя номера и хеши, пока не передаст весь ответ?
просто пытаюсь понять для себя ситуацию "человеческим" языком
2) медленный старт - он сразу по умолчанию срабатывает для tcp или это какая-то реакция на условия в сети? и есть ли быстрый старт?
3) окно перегрузки и окно получателя - такое ощущение, что это - одно и то же или нет? Окно перегрузки - это у отправляющей стороны, а окно получателя - у получателя или как это работает?
4) такое ощущение, что на любую потерю пакетов tcp реагирует снижением скорости, даже если потеря пакетов не была связана с производительностью, это так?
1) Где угодно в сети. В том числе между магистральными провайдерами. Пакеты ждут обработки предыдущих, снижая скорость соединения. При достаточно сильной у пакета уйдёт TTL и он будет отброшен.
2) Алгоритм контроля сети. В RFC объявлен как MUST, что означает "ДОЛЖЕН". Так что да, по умолчанию.
3) Окно перегрузки — сколько отправитель может отправить получателю без подтверждения ACK. Окно получателя — сколько данных получатель может принять для обработки.
4) Алгоритм медленного старта предполагает именно это, да.
TCP гарантирует, что данные не будут повреждены, утеряны,
Если быть точным, то TCP никак не гарантирует доставку данных, а лишь то, что принятые данные всегда корректны.
Первая же картинка - фейк. Маршрутизация работает на уровне L3 и не разбирает, что передается TCP или UDP, поэтому вариант с перемешиванием пакетов может иметь место и при использовании TCP. А вот уже на приемной стороне сетевой стек выполнит для TCP выстраивание пакетов по порядку. Сам текст отдает машинным переводом.
В разделе про Congestion control: "Это происходит до тех пор, пока для какого-то сегмента не будет получено подтверждение..." - имелось в виду "пока не будет НЕ получено (утеряно) подтверждение"?
TCP vs UDP