спасибо за лекцию хочу лишь добавить один момент про установку соединения: отправка пустого 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-ом и ситуация могла бы усложниться
Спасибо за ваши лекции, очень доступно объясняете. Хотел уточнить один момент, могу ли я использовать RST в плохих целях? Например, если я нахожусь посередине между клиентом и сервером, и вижу что есть установленное соединение, могу ли я сформировать tcp пакет с rst, чтобы закрыть соединение, и делать так постоянно?
Благодарю за полезное видео, все четко и понятно. Только два вопроса волнуют... в основном про RST. Это сообщение может вдруг не дойти до пункта назначения? Если может, то какие действия предпринимаются?
1. Конечно сообщение RST, как и любые другие сообщения, может не дойти до получателя. 2. Если сообщение RST не дойдёт, то соединение будет закрыто по тайм-ауту.
Что такое RST ? В технологии MACA андрей говорил что RST содержит в себе данные отправителя и размер данных для передачи :/ Что то запутал... А FIN что такое ?!
FİN это сообшения для разрыва соеденения , а RST тоже самое просто исполльзуется при критических моментах, если есть какая то ошибка и он разрывает соеденение с обейих сторон тоесть больше не потребуется отправить ACK как в примере с FİN. (2:54)
+Ruslan Alpysbayev Протокол TCP получает от приложения поток байт (например, фильм размером 2 ГБ). Этот поток разбивается на отдельные части - сегменты, которые передаются по сети отдельно. Для гарантии доставки используется подтверждение получения сегментов и нумерация. Можно нумеровать сегменты, но по разным причинам это неудобно (например, сегменты могут иметь разный размер). Поэтому TCP вместо сегментов нумерует байты в потоке. Например, первый сегмент содержит байты с 0 по 999, второй с 1000 по 1999 и т.д. (в примере с фильмом до 2 ГБ). Более подробно об этом рассказано в лекции о протоколе TCP: ua-cam.com/video/CKUOb4htnB4/v-deo.html На самом деле байты в потоке нумеруются не с 0, а по более сложным правилам. Если всегда начинать нумерацию с 0, то если компьютер захочет открыть два соединения, сегменты из них могут перепутаться. Также есть много других проблем. Поэтому для начального номера байт в потоке выбираются разные числа так, чтобы они не совпадали ни с каким другим соединением на данном компьютере. Алгоритмы достаточно сложные, но для простоты можно представлять себе, что начальный номер байта в потоке выбирается случайным образом. Именно этот номер и указывается в сегменте SYN при установке соединения. Стало ли понятнее?
байты передаются в обе стороны. 7537 это номер байт, которые отправил левый клиент, 36829 номер байт, которые отправил правый клиент. Поэтому за одно сообщение сообщается номер отправленных сообщение 36829 и подтверждение полученных сообщений 7537. Андрей поясняет значение 7538 тем, что правый клиент ждет следующий байт. Я в других источниках слышал немного иначе, что это фантомный байт, но сходу не объясню.
Не понял, что такое "порядковый номер передаваемого байта" и чем он отличается от "номера байта в потоке"? Порядковый номер передаваемого байта - это номер байта начала следующего сегмента от отправителя? А номера байта в потоке - это номер байта от получателя? или как? Тоесть они оба шлют информацию друг другу?
короче. Есть два поля в TCP. Первое используется для обозначения байт которые ты отправляешь и нумеруется лишь первый байт в сегменте. Второе поле используется для подтверждения, номер байта, которое ты ожидаешь. Они оба шлют друг другу.
как я понял, это пример для случая, когда обе стороны сразу после установления соединения будут передавать друг другу данные🤔 Т.е. у каждой стороны есть свой поток байт для передачи и, соответственно, требуются два отсчета для этих потоков байт. Одна сторона отправляет SYN, другая присылает ей ACK, и заодно другая сторона отправляей первой стороне СВОЙ☝🏼 SYN, на который хотела бы получить от первой стороны соответствующий ACK. Просто тут совмещены отправка второй стороной ACK и своего же SYN и из-за этого черт ногу сломит. Я сначала тоже нихрена не понял. В общем, это место мутное и его можно было объяснить гораздо лучше. Да, я не дописал мысль! Вот эти номера байтов в потоке байт после "SYN" - это и есть предлагаемые начала отсчета байт в каждом потоке. Я ТАК додумал. Типа, первая сторона: "я начинаю отсчитывать свой поток не с нуля, а с 7537", а другая сторона: "а я начинаю отсчитывать свой поток не с нуля, а с 36829"
Добрый день. Спасибо за ваши лекции, узнал много нового, у вас отличная подача материала. Есть один вопрос: при установке соединения клиент отправляет именно номер байта, или номер пакета?
@@AndreySozykin Я наверно 3 дня назад имел в виду пример на картинке 1:03. Там отправитель отправил сегмент с №7537, а подтверждение №7538. Вопрос был как подтверждение может быть 7538, если сам сегмент+хэдерыL2+L3 размер которых больше) но в примере, скорей всего, для упрощения так сделано.
@@AndreySozykin видать, когда долго работали, старались вникнуть в суть всего. это видно по такому осмысленному курсу по сетям. годы идут, а курс всё такой же четкий.
Андрей, огромное спасибо за Вашу работу! Изучал по Вашим урокам компьютерные сети, прошёл собеседование!!!
Очень точно, без лишней воды. Благодарю за такой качественный материал
Согласен с большинством комментаторов - материал на курсе очень доходчивый и крайне полезный сразу с практической точки зрения. Автору канала спасибо!
спасибо за лекцию
хочу лишь добавить один момент про установку соединения: отправка пустого 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-ом
и ситуация могла бы усложниться
а с чего это на 4 шаге мы должны отправлять 102, если на 3 сервер говорит, что получил 100, ждёт 101? мы на 4 и отправили ему 101.
Вы далете хорошее дело, спасибо!
Спасибо за столь полезный набор видео!
Спасибо большое, лайкаю каждое видео!
Spasibo Vam Za Klasnie video kursi
+atilla atilla, пожалуйста!
Спасибо.
Qilgan bu yaxshi amallariyezni ajrini bersin.
Спасибо вам, Андрей!
Пожалуйста!
Спасибо! Доступно и понятно!
Пожалуйста!
+ Иван Николайчук, Именно номер байта. В TCP нумеруются не пакеты, а байты.
Лайк, спасибо
Пожалуйста!
Спасибо за ваши лекции, очень доступно объясняете.
Хотел уточнить один момент, могу ли я использовать RST в плохих целях?
Например, если я нахожусь посередине между клиентом и сервером, и вижу что есть установленное соединение, могу ли я сформировать tcp пакет с rst, чтобы закрыть соединение, и делать так постоянно?
Да, конечно так можно делать.
вижу мышление кибербезопасника! ))
Спасибо!
если произойдёт interference в процессе отправки RST, разрыв не произойдёт. Там точно нет никаких ACK?
спасибо!!!
Пожалуйста!
Благодарю за полезное видео, все четко и понятно. Только два вопроса волнуют... в основном про RST. Это сообщение может вдруг не дойти до пункта назначения? Если может, то какие действия предпринимаются?
1. Конечно сообщение RST, как и любые другие сообщения, может не дойти до получателя.
2. Если сообщение RST не дойдёт, то соединение будет закрыто по тайм-ауту.
Что нужно ввести в командной строке cmd, чтобы вывести соединения протокола TCP?
netstat -a
Что такое RST ? В технологии MACA андрей говорил что RST содержит в себе данные отправителя и размер данных для передачи :/ Что то запутал... А FIN что такое ?!
FİN это сообшения для разрыва соеденения , а RST тоже самое просто исполльзуется при критических моментах, если есть какая то ошибка и он разрывает соеденение с обейих сторон тоесть больше не потребуется отправить ACK как в примере с FİN. (2:54)
@@Yato私菜 Спасибо, но я уже давно разобралась :)
Здравствуйте. Как установить TCP соединение между двумя случайными компьютерами?
Один из компютеров должен являться инициатором соединения.
Очередное спасибо, но я не понял на 1:28 , т.е что значит " номер байта в потоке байт". Пожалуйста, объясните тут по-подробней, если можно.
+Ruslan Alpysbayev Протокол TCP получает от приложения поток байт (например, фильм размером 2 ГБ). Этот поток разбивается на отдельные части - сегменты, которые передаются по сети отдельно. Для гарантии доставки используется подтверждение получения сегментов и нумерация.
Можно нумеровать сегменты, но по разным причинам это неудобно (например, сегменты могут иметь разный размер). Поэтому TCP вместо сегментов нумерует байты в потоке. Например, первый сегмент содержит байты с 0 по 999, второй с 1000 по 1999 и т.д. (в примере с фильмом до 2 ГБ).
Более подробно об этом рассказано в лекции о протоколе TCP:
ua-cam.com/video/CKUOb4htnB4/v-deo.html
На самом деле байты в потоке нумеруются не с 0, а по более сложным правилам. Если всегда начинать нумерацию с 0, то если компьютер захочет открыть два соединения, сегменты из них могут перепутаться. Также есть много других проблем. Поэтому для начального номера байт в потоке выбираются разные числа так, чтобы они не совпадали ни с каким другим соединением на данном компьютере. Алгоритмы достаточно сложные, но для простоты можно представлять себе, что начальный номер байта в потоке выбирается случайным образом. Именно этот номер и указывается в сегменте SYN при установке соединения.
Стало ли понятнее?
Да, понятно объяснили. Спасибо
а как может начаться передача сегментов до установки соединени?
@@algmy никак, вначале соединение и после того как оно установлено передаются сегменты.
@@w1tcherj Тогда о каких номерах байтов говорится при установке соединения, если никакие сегменты информации ещё не передаются?
Так в чем разница байтов между 36829 и 7538?
байты передаются в обе стороны. 7537 это номер байт, которые отправил левый клиент, 36829 номер байт, которые отправил правый клиент. Поэтому за одно сообщение сообщается номер отправленных сообщение 36829 и подтверждение полученных сообщений 7537. Андрей поясняет значение 7538 тем, что правый клиент ждет следующий байт. Я в других источниках слышал немного иначе, что это фантомный байт, но сходу не объясню.
Где можно подробнее узнать про процесс нумерации байтов в потоке?
В RFC 793 по TCP - tools.ietf.org/html/rfc793#page-24
Сколько раз будет соединятся и разрываться канал при скачивании 2 Гб?
Сложный вопрос, зависит от качества связи.
@@AndreySozykin примерно, речь идёт о десятка, сотнях или тысячах?
Спасибо
Не понял, что такое "порядковый номер передаваемого байта" и чем он отличается от "номера байта в потоке"?
Порядковый номер передаваемого байта - это номер байта начала следующего сегмента от отправителя? А номера байта в потоке - это номер байта от получателя? или как? Тоесть они оба шлют информацию друг другу?
короче. Есть два поля в TCP. Первое используется для обозначения байт которые ты отправляешь и нумеруется лишь первый байт в сегменте. Второе поле используется для подтверждения, номер байта, которое ты ожидаешь. Они оба шлют друг другу.
как я понял, это пример для случая, когда обе стороны сразу после установления соединения будут передавать друг другу данные🤔 Т.е. у каждой стороны есть свой поток байт для передачи и, соответственно, требуются два отсчета для этих потоков байт. Одна сторона отправляет SYN, другая присылает ей ACK, и заодно другая сторона отправляей первой стороне СВОЙ☝🏼 SYN, на который хотела бы получить от первой стороны соответствующий ACK. Просто тут совмещены отправка второй стороной ACK и своего же SYN и из-за этого черт ногу сломит. Я сначала тоже нихрена не понял. В общем, это место мутное и его можно было объяснить гораздо лучше.
Да, я не дописал мысль! Вот эти номера байтов в потоке байт после "SYN" - это и есть предлагаемые начала отсчета байт в каждом потоке. Я ТАК додумал. Типа, первая сторона: "я начинаю отсчитывать свой поток не с нуля, а с 7537", а другая сторона: "а я начинаю отсчитывать свой поток не с нуля, а с 36829"
Добрый день.
Спасибо за ваши лекции, узнал много нового, у вас отличная подача материала.
Есть один вопрос: при установке соединения клиент отправляет именно номер байта, или номер пакета?
На транспортном уровне нет понятия "пакет". Автор в предыдущем комментарии все отлично разъяснил.
Наверное, в вопросе имелось с виду номер сегмента, а не пакета.
Указывается именно номер байта.
Может не номер байта, а номер некой последовательности? Тут у Вас какая-то не досказанность.
А как может быть подтверждение +1 байт, если в самом сегменте больше байт, нежели один?
Указывается номер последнего полученного байта +1.
@@AndreySozykin Я наверно 3 дня назад имел в виду пример на картинке 1:03. Там отправитель отправил сегмент с №7537, а подтверждение №7538. Вопрос был как подтверждение может быть 7538, если сам сегмент+хэдерыL2+L3 размер которых больше) но в примере, скорей всего, для упрощения так сделано.
Считаются только байты данных TCP, без заголовков.
Андрей, для чего нам третий пакет (ACK), если мы уже на втором этапе (SYN, ACK) можем передавать сообщение?
Вероятно для того, чтобы каждый компьютер получил подтверждение, чтобы убедиться, что соединение установлено.
Вы программист?
Нет, я преподаватель университета. Но учился на ИТ-шинка и долго работал системные инженером по серверам и сетям.
@@AndreySozykin
видать, когда долго работали, старались вникнуть в суть всего. это видно по такому осмысленному курсу по сетям.
годы идут, а курс всё такой же четкий.
Спасибо
Пожалуйста!