Протокол TCP: соединение | Курс "Компьютерные сети"

Установка соединения в TCP. Трехкратное рукопожатие (SYN, SYN + ACK, ACK). Разрыв соединения: FIN, RST.
Лекции по курсу "Компьютерные сети" - goo.gl/0aIOuf
Лекция "Протокол TCP" - • Протокол TCP | Курс "К...
Лекция "Протокол TCP: формат заголовка" - • Протокол TCP: формат з...
Практические занятия по курсу "Компьютерные сети" - goo.gl/YP3l83
Практика: установка соединения в TCP: • Установка соединения в...
Мой канал с краткими и понятными объяснениями сложных тем в ИТ и компьютерных науках:
goo.gl/kW93MA

[@nikolay_antipin]

Андрей, огромное спасибо за Вашу работу! Изучал по Вашим урокам компьютерные сети, прошёл собеседование!!!

[@aleksandrzaremba6520]

Очень точно, без лишней воды. Благодарю за такой качественный материал

[@andreipomorev6292]

Спасибо за столь полезный набор видео!

[@qcandrey]

Вы далете хорошее дело, спасибо!

[@user-hg9jc9nc3k]

Спасибо большое, лайкаю каждое видео!

[@kseniyasakki4382]

Спасибо вам, Андрей!

[@AndreySozykin]

Пожалуйста!

[@DoubleViolence]

Спасибо! Доступно и понятно!

[@AndreySozykin]

Пожалуйста!

[@Q_School]

Спасибо. Qilgan bu yaxshi amallariyezni ajrini bersin.

[@atillaattila8900]

Spasibo Vam Za Klasnie video kursi

[@AndreySozykin]

+atilla atilla, пожалуйста!

[@AndreySozykin]

+ Иван Николайчук, Именно номер байта. В TCP нумеруются не пакеты, а байты.

[@user-fghjiydsvjk975]

спасибо за лекцию хочу лишь добавить один момент про установку соединения: отправка пустого ack подтверждения не увеличивает счетчик следущего отправляемого сегмента, поясню на примере (пример взят с rfc793 и он же на вики) TCP A (клиент) TCP B (сервер) 1. CLOSED LISTEN //// клиента еще нет, сервер слушает 2. SYN-SENT --> --> SYN-RECEIVED //// клиент отправляет сегмент №100 с syn 3. ESTABLISHED ESTABLISHED //// клиент отправляет пустой сегмент №101, говоря, что ждет №301 5. ESTABLISHED --> --> ESTABLISHED //// и вот тут отправляются данные с №101, чего и ждет сервер если бы мы на шаге 4 отправили бы сегмент с увеличением счетчика до №102, то серверу пришлось бы подтверждать этот ack своим пустым ack-ом и ситуация могла бы усложниться

[@w1tcherj]

а с чего это на 4 шаге мы должны отправлять 102, если на 3 сервер говорит, что получил 100, ждёт 101? мы на 4 и отправили ему 101.

[@Andrzej3935]

Спасибо!

[@andreypolevoy5311]

Лайк, спасибо

[@AndreySozykin]

Пожалуйста!

[@Das.Kleine.Krokodil]

Спасибо

[@user-hh9xr4uj3o]

спасибо!!!

[@AndreySozykin]

Пожалуйста!

[@algmy]

если произойдёт interference в процессе отправки RST, разрыв не произойдёт. Там точно нет никаких ACK?

[@kovalev94]

Спасибо за ваши лекции, очень доступно объясняете. Хотел уточнить один момент, могу ли я использовать RST в плохих целях? Например, если я нахожусь посередине между клиентом и сервером, и вижу что есть установленное соединение, могу ли я сформировать tcp пакет с rst, чтобы закрыть соединение, и делать так постоянно?

[@AndreySozykin]

Да, конечно так можно делать.

[@andreykelip5631]

вижу мышление кибербезопасника! ))

[@user-wt9pp6ud7o]

Добрый день. Спасибо за ваши лекции, узнал много нового, у вас отличная подача материала. Есть один вопрос: при установке соединения клиент отправляет именно номер байта, или номер пакета?

[@trek3456]

На транспортном уровне нет понятия "пакет". Автор в предыдущем комментарии все отлично разъяснил.

[@AndreySozykin]

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

[@MrSorrow]

Благодарю за полезное видео, все четко и понятно. Только два вопроса волнуют... в основном про RST. Это сообщение может вдруг не дойти до пункта назначения? Если может, то какие действия предпринимаются?

[@AndreySozykin]

1. Конечно сообщение RST, как и любые другие сообщения, может не дойти до получателя. 2. Если сообщение RST не дойдёт, то соединение будет закрыто по тайм-ауту.

[@kotpsihopat6392]

Где можно подробнее узнать про процесс нумерации байтов в потоке?

[@AndreySozykin]

В RFC 793 по TCP - tools.ietf.org/html/rfc793#page-24

[@alexzakharchenko8993]

Не понял, что такое "порядковый номер передаваемого байта" и чем он отличается от "номера байта в потоке"? Порядковый номер передаваемого байта - это номер байта начала следующего сегмента от отправителя? А номера байта в потоке - это номер байта от получателя? или как? Тоесть они оба шлют информацию друг другу?

[@w1tcherj]

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

[@-XAH-]

Что нужно ввести в командной строке cmd, чтобы вывести соединения протокола TCP?

[@AndreySozykin]

netstat -a

[@anoname10]

Здравствуйте. Как установить TCP соединение между двумя случайными компьютерами?

[@AndreySozykin]

Один из компютеров должен являться инициатором соединения.

[@ruslanalpysbayev1209]

Очередное спасибо, но я не понял на 1:28 , т.е что значит " номер байта в потоке байт". Пожалуйста, объясните тут по-подробней, если можно.

[@AndreySozykin]

+Ruslan Alpysbayev Протокол TCP получает от приложения поток байт (например, фильм размером 2 ГБ). Этот поток разбивается на отдельные части - сегменты, которые передаются по сети отдельно. Для гарантии доставки используется подтверждение получения сегментов и нумерация. Можно нумеровать сегменты, но по разным причинам это неудобно (например, сегменты могут иметь разный размер). Поэтому TCP вместо сегментов нумерует байты в потоке. Например, первый сегмент содержит байты с 0 по 999, второй с 1000 по 1999 и т.д. (в примере с фильмом до 2 ГБ). Более подробно об этом рассказано в лекции о протоколе TCP: kzbin.info/www/bejne/eXy4gJVqndmheJY На самом деле байты в потоке нумеруются не с 0, а по более сложным правилам. Если всегда начинать нумерацию с 0, то если компьютер захочет открыть два соединения, сегменты из них могут перепутаться. Также есть много других проблем. Поэтому для начального номера байт в потоке выбираются разные числа так, чтобы они не совпадали ни с каким другим соединением на данном компьютере. Алгоритмы достаточно сложные, но для простоты можно представлять себе, что начальный номер байта в потоке выбирается случайным образом. Именно этот номер и указывается в сегменте SYN при установке соединения. Стало ли понятнее?

[@trek3456]

Да, понятно объяснили. Спасибо

[@algmy]

а как может начаться передача сегментов до установки соединени?

[@w1tcherj]

@@algmy никак, вначале соединение и после того как оно установлено передаются сегменты.

[@Nikdoge]

@@w1tcherj Тогда о каких номерах байтов говорится при установке соединения, если никакие сегменты информации ещё не передаются?

[@pie4928]

Что такое RST ? В технологии MACA андрей говорил что RST содержит в себе данные отправителя и размер данных для передачи :/ Что то запутал... А FIN что такое ?!

[@mrpandomim1]

FİN это сообшения для разрыва соеденения , а RST тоже самое просто исполльзуется при критических моментах, если есть какая то ошибка и он разрывает соеденение с обейих сторон тоесть больше не потребуется отправить ACK как в примере с FİN. (2:54)

[@pie4928]

@@mrpandomim1 Спасибо, но я уже давно разобралась :)

[@artimity]

Сколько раз будет соединятся и разрываться канал при скачивании 2 Гб?

[@AndreySozykin]

Сложный вопрос, зависит от качества связи.

[@artimity]

@@AndreySozykin примерно, речь идёт о десятка, сотнях или тысячах?

[@w1tcherj]

А как может быть подтверждение +1 байт, если в самом сегменте больше байт, нежели один?

[@AndreySozykin]

Указывается номер последнего полученного байта +1.

[@w1tcherj]

@@AndreySozykin Я наверно 3 дня назад имел в виду пример на картинке 1:03. Там отправитель отправил сегмент с №7537, а подтверждение №7538. Вопрос был как подтверждение может быть 7538, если сам сегмент+хэдерыL2+L3 размер которых больше) но в примере, скорей всего, для упрощения так сделано.

[@AndreySozykin]

Считаются только байты данных TCP, без заголовков.

[@denzel2412]

Так в чем разница байтов между 36829 и 7538?

[@Enliven89]

байты передаются в обе стороны. 7537 это номер байт, которые отправил левый клиент, 36829 номер байт, которые отправил правый клиент. Поэтому за одно сообщение сообщается номер отправленных сообщение 36829 и подтверждение полученных сообщений 7537. Андрей поясняет значение 7538 тем, что правый клиент ждет следующий байт. Я в других источниках слышал немного иначе, что это фантомный байт, но сходу не объясню.

[@TeuFortMan]

Может не номер байта, а номер некой последовательности? Тут у Вас какая-то не досказанность.

[@kekkekovich3374]

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

[@ilyashevelev9256]

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

[@abdarrahman_l7]

Вы программист?

[@AndreySozykin]

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

[@manOfPlanetEarth]

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

[@artur_kia]

Спасибо

[@AndreySozykin]

Пожалуйста!