Протокол TCP | Курс "Компьютерные сети"
ฝัง
- เผยแพร่เมื่อ 7 ก.พ. 2025
- Видеолекция по протоколу TCP.
Лекции по курсу "Компьютерные сети" - goo.gl/0aIOuf
TCP (Transmission Control Protocol, протокол управления передачей) - протокол транспортного уровня стека TCP/IP. Он предоставляет сервис надежной передача потока байт (reliable byte stream). TCP предоставляет следующие гарантии:
Доставка данных.
Сохранения порядка следования сообщений.
Транспортная подсистема получает от приложения данные в виде потока байт. Поток разбивается на отдельные части, которые называются сегменты. Сегменты передаются от отправителя к получателю независимо друг от друга. Получатель собирает сегменты и передает принимающему приложению поток байт.
Для гарантии доставки TCP использует подтверждение получения данных. Получатель, после приема очередной порции данных, передает отправителю подтверждения о получении. В случае, если подтверждение не пришло, отправитель передает данные еще раз.
В TCP подтверждается не получение каждого сегмента, а получение нескольких сегментов. Это сделано для увеличения скорости передачи данных: отправитель может передать без остановки несколько сегментов, не дожидаясь прихода подтверждения. Такой тип подтверждения называется кумулятивный: подтверждается получение последнего сегмента, и всех предыдущих. Количество сегментов, которые отправитель может передать без подтверждения, называется размер скользящего окна.
Однако только подтверждения и повторной отправки недостаточно для надежной передачи потока байт. В дополнение к потере данных возможна и другая проблема: нарушение порядка следования сообщений:
Сегменты приходят в неправильном порядке.
Сегменты дублируются.
Для сохранения порядка следования сообщений используется нумерация сообщений. Особенность протокола TCP в том, что он нумерует не сегменты, а байты в сегментах. Нумерация сообщений позволяет расставить перепутанные сегменты в правильном порядке, а также не учитывать дублирующийся сегменты.
Перед отправкой данных по TCP необходимо установить соединение. Задачи соединения:
Убедиться, что отправитель и получатель хотят передавать данные друг другу.
Договориться о нумерации потока байт.
Договорится о параметрах соединения (максимальный размер сегмента и т.п.).
После завершения передачи данных соединение TCP разрывается.
Практические занятия по курсу "Компьютерные сети" - goo.gl/YP3l83
Мой канал с краткими и понятными объяснениями сложных тем в ИТ и компьютерных науках:
goo.gl/kW93MA
Чувак ты гениален! Во время просмотра возникает куча вопросов, и ты по ходу рассказа именно на них и отвечаешь!! Спасибо за качественные труды
+tecktart tecktart, спасибо за хороший отзыв. Рад, что понравилось!
да. только Эндрю - не чувак тебе. Ясненько, чувачочек?
У меня возникает столько вопросов, что ответить на все невозможно. Я использую для этого Chatgpt)
Naruto тебе не чувачок, приятель@@manOfPlanetEarth
Ваш курс по сетям это лучшее что я видел и слышал, спасибо большое!
Андрей, здравствуйте! К сожалению, только сейчас добрался до Ваших лекций, но они очень крутые! Ставлю под всеми видео лайки, а сами лекции конспектирую и рисую. Также друзьям рассказал о Ваших лекциях и говорю, что они просто легкие, по существу и всё понятно! Очень нравится!
Спасибо за приятный отзыв и за помощь в распространении курса!
Как же хорошо, что наткнулся на ваш замечательный канал... а то уже вообще в отчаяние падал... думал не осилю.
Спасибо за приятный отзыв! Уверен, что все получиться!
С удовольствием пробежал курс для освежения старых знаний и вскрытия темных пятен. Большое спасибо за твою работу, дружище!
+Moral Proxy спасибо за помощь с распространением. Отличная идея с раздачей на рутрекере, постараюсь сделать.
Спасибо! Самые лаконичные уроки! Очень внятно и быстро! не приходится смотреть на скорости 2)))
Пожалуйста! Рад, что нравится!
Спасибо большое за ваши лекции))) Благодаря вам идет развитие. ЕЩе раз спасибо
Пожалуйста! Успехов в развитии!
ну развитие идёт благодаря твоей не лени всё же) лекции это инструмент.
@@w1tcherj но все же думаю справедливо отметить что инструменты также бывают разными. Как по мне лекции Андрея очень толковый инструмент - все по сути, лаконично и при этом доходчиво. Конечно возникают вопросы (они всегда возникают), но благо - есть возможность задать эти вопросы автору лекций в комментариях.
Спасибо за отличную работу!!!
Однозначно лайк, подписка
И самое главное - смотрим рекламу полностью, не пропускаем, чтоб автору заплатили - поскольку это будет справедливо
Без воды, без лишнего, все ясно и понятно
Спасибо за поддержку!
Я в шоке от вас спасибо огромное читал книгу думал это не моё но вы спасаете спасибо огромное
Да, сети сложно понять по книгам, т.к. в них много технических деталей, которые при первом знакомстве являются избыточными.
Спасибо за Ваш труд, просто и доступно.
Пожалуйста!
отлично! привет из Казахстана брат!
+Ануарбек Аманов Спасибо! Рад, что смотрят не только из России!
+Andrey Sozykin
Ещё привет из Казахстана, очень интересно, компактно и доходчиво объяснено, Спасибо!
Привет из Германии от студентов Computer Science :)
Спасибо вам, Андрей!
Пожалуйста!
Спасибо! Полезно и понятно!
Спасибо.
Qilgan bu yaxshi amallariyezni ajrini bersin.
Ochen krasivo zdelona video kurs
spasibo
+atilla atilla, спасибо!
Большое спасибо
Пожалуйста!
Спасибо, приятно слушать
Четко и понятно
+Саша Саранин, пожалуйста! Рад, что нравится!
Вопрос по времени (2:30)
Что происходит в этой ситуации:
1. Отправитель отправил
2. Получатель молчит
3. Отправитель засек таймер
4. Получатель получил пакет
5. Получатель пересылает ОК
6. Отправитель отправляет повторно
7. Отправитель получает сообщение, что пакет дошел до получателя
8. Получатель получил второй пакет
Что он будет с ним делать, если отправил уже ОК?
У меня есть две теории:
1. Он узнает этот пакет, поэтому проигнорит
2. Он снова отправит ОК, а отправитель узнает тоже узнает этот пакет и поймет, что он получил два подтверждения на один и тот же пакет, в следствии чего продолжит передачу пакетов
а там дальше ответ есть :D
Хотя здесь ответ от таймингов зависит, но такое вряд ли бывает
отличные уроки, доступно изложено. Правда немного рассинхронизация звука с видеорядом
+Criptex57 спасибо за замечание. Постараюсь исправить в следующих лекциях.
Доброго дня, Андрей! Вы сказали что IP не сохраняет порядок сегментов, но у меня вопрос. Разве при передачи пакетов в Сетевом Уровне не сохраняется порядок? Когда пакет делится на фрагменты то у каждого из них есть собственный номер смещения. 0, 185, 370. Разве это не указывает на порядок потока байт?
Спасибо за видео!
Пожалуйста!
Боже, спасибо вам
Пожалуйста!
Пересказ от Яндекса:
00:00 Протокол Ти-Си-Пи
* Ти-Си-Пи находится на транспортном уровне модели взаимодействия открытых систем и стека протоколов Ти-Си-Пи-Ай-Пи.
* Ти-Си-Пи обеспечивает надежную доставку данных и гарантирует сохранение порядка следования сообщений от приложения.
* Ти-Си-Пи использует подтверждение получения сообщения и повторную отправку данных для обеспечения гарантии доставки данных.
02:37 Скользящее окно и нумерация байтов
* Ти-Си-Пи использует скользящее окно для подтверждения нескольких сегментов данных.
* Для обеспечения сохранения порядка следования сообщений, все сообщения нумеруются в Ти-Си-Пи.
* Нумерация байтов используется для восстановления порядка следования сообщений при их получении.
06:07 Соединение и завершение передачи данных
* Ти-Си-Пи использует соединение для установления связи между отправителями и получателями.
* Соединение необходимо установить перед началом передачи данных и разорвать после завершения передачи.
* При установке соединения, отправители и получатели договариваются о нумерации потока байт и некоторых параметрах соединения.
Спасибо!
Рад, что нравится.
Уже дошел до этого видео а так и не понял одну наверное простую вещь : пакет каждого уровня содержит внутри себя пакет уровня выше ? например сетевой пакет содержит пакет транспортного уровня а сам сетевой пакет пришел внутри канального пакета
Да, именно так.
ну представь конфету-это информация, обёртка-заголовок уровня прикладного, ещё раз оберни её обёрткой-заголовок транспортного уровня и так далее.
Только это не пакеты, а заголовки и заголовок на каждом уровне по разному называется, на канальном фрэйм или кадр на сетевом пакет на транспортном сегмент
@@sammyel4eg В кадр, пакет и сегмент входят данные вышестоящих уровней. Так что они состоят из заголовка (кадра, пакета, сегмента) + данные. Например, так и говорят - заголовок IP-пакета, заголовок кадра..
@@idgordeev не чего не понял из вашего ответа, что именно вы хотели донести?
спасибо
+vlad komar, пожалуйста!
спасибо!!!
Пожалуйста!
Первая задача соединения получается и есть Three-Way-Handshake?
Здравствуйте,Андрей! Какое максимальное количество повторений передачи одного и того же сегмента? сколько угодно , пока не получит ACK?
Спасибо за интересный вопрос, понадобилось некоторое время, чтобы разобраться. Количество повторений передачи пакетов ограничено и зависит от операционной системы.
В Windows для этого есть параметр TcpMaxDataRetransmissions (support.microsoft.com/en-us/help/170359/how-to-modify-the-tcp-ip-maximum-retransmission-time-out), значение по-умолчанию 5.
В Linux есть два параметра: tcp_retries1 и tcp_retries2. Первый параметр говорит сколько раз TCP будет повторно отправлять сегмент без уведомления сетевого уровня о проблемах. Значение по-умолчанию 3. После этого будет проведена попытка перестроить таблицу маршрутизации и снова отправить пакет. Количество повторений после вовлечения в устранение проблем сетевого уровня задается параметром tcp_retries2, значение по-умолчанию 15. Более подробно - stackoverflow.com/questions/5227520/how-many-times-will-tcp-retransmit
Спасибо за развернутый ответ!
sposibo vam
+arzu samir, пожалуйста.
Есть вопрос относительно TCP. Везде сказано, что этот протокол надёжный, то есть обеспечивает гарантированную доставку данных. Однако я видел приложение, передававшее данные телеметрии по протоколу HTTP (а HTTP, как известно, работает поверх TCP). И в этом приложении дополнительно высылалась контрольная сумма данных на случай, если данные будут повреждены. При этом данные в этом приложении действительно периодически портились и терялись, и контрольная сумма была введена не зря. Возникает тогда логичный вопрос: как такое возможно, если TCP специально был создан для гарантии доставки данных в целости и сохранности? Почему он этого не обеспечивает?
+Sergey Ufimtsev, алгоритм расчета контрольной суммы CRC, который используется для обнаружения ошибок в TCP (а также в UDP и Ethernet), несовершенен. Он гарантированно обнаруживает однократную ошибку, но некоторые более сложные виды ошибок обнаружить не может. Такие ошибки возникают редко и обычно на работу не влияют. Например, если вы скачаете по HTTP документ, в котором исказится один или два текстовых символа, то смысл все равно понять можно.
Но в вашем случае данных, скорее всего, передается много. По некоторым оценкам, если использовать GigabitEthrnet, ошибки, которые не обнаруживает CRC в TCP, возникают каждые 34 часа. Наверняка у вас данные передаются круглосуточно. Тогда не удивительно, что периодически они портятся.
Более подробно можно почитать:
The Limitations of the Ethernet CRC and TCP/IP checksums for error detection -noahdavids.org/self_published/CRC_and_checksum.html
Performance of Checksums and CRCs over Real Data - ccr.sigcomm.org/archive/1995/conf/partridge.pdf
Спасибо!
Андрей, а как получатель понимает какой байт +1 отправить вместе с ACK? Это они уже решил на этапе установки соединения с отправителем?
Спасибооооо
Пожалуйста!
Все понятно
Здравствуйте, Андрей!
Вы говорите тут - 05:11 следующее: "Если сегменты придут в неправильном порядке, то получатель по номерам байтов всегда сможет выставить их в правильной последовательности."
У меня вопрос такой: если предположить, что получателю придут сегменты разных потоков байт, как получатель поймет, что это сегменты разных потоков байт?
Например, получателю пришел, условно говоря, последний сегмент потока 2 раньше, чем последний сегмент потока 1. При этом по размеру потоки байт одинаковы, следовательно и номера байт в сегментах будут совпадать. Как получателю определиться в такой ситуации с правильной последовательностью?
Спасибо.
я правильно понял, что для каждого потока байт устанавливается свое отдельное соединение? И таким образом выходит, что вышеуказанной ситуации не может случиться на практике? То есть сегменты разных потоков байт не смогут быть смешаны в пределах одного соединения?
Для каждого потока байт действительно устанавливается новое соединение.
При установке соединения выбирается начальный номер последовательности байтов так, чтобы не совпадать с другими возможными соединениями.
Алгоритм описан в документе RFC 793, раздел Initial Sequence Number Selection.
Андрей, почему нельзя нумеровать данные в потоке байт начиная с нуля? В чем здесь недостаток с точки зрения практической реализации?
+Nikita Andrich, есть несколько проблем:
1. Мы отправили запрос на установку соединения SYN, получатель выслал нам в ответ SYN + ACK, но этот ответ до нас не дошел. Мы повторно отправляем SYN. Как получателю определить, это новый запрос на соединение, или повторный запрос на первое соединение? Если байты нумеровать с 0, то их отличить нельзя. А если каждый запрос на соединение использует разную нумерацию, то путаницы не будет.
2. Предположим мы установили соединение, передали небольшое количество данных (5-10 сегментов), и разорвали его. Но в сети осталось несколько сегментов от соединения. Мы тут же открываем новое соединение и передаем новые данные. Если нумеровать байты в потоке с 0, то получатель может увидеть как новые данные, так и данные от предыдущего соединения (которые задержались в сети) и может их перепутать. Отсюда дополнительное требование: номера байтов для отдельных соединений не должны совпадать между собой.
Andrey Sozykin, круто, спасибо за объяснение!
Какой таймер ожидание подтверждения у TCP?
Начальное значение 3 секунды. В процессе работы TCP значение пересчитывается в зависимости от скорости ответов. Алгоритм расчета приведен в RFC 6298 - tools.ietf.org/html/rfc6298
очень толково, кратко и при этом понятно
остался только один вопрос - а что будет если сегмент дошел, но некоторые биты в данных были инвертированы, например из-за помех? или этим занимаются более низкие уровни?
Да, это делается на канальном уровне. В Ethernet простая проверка по контрольной сумме.
@@AndreySozykin но ведь Ethernet не гарантирует доставку? т.е. если контрольная сумма не совпадет, кадр просто отбросится. Как тогда нам получить бракованный пакет и исправить его а не отбросить?
@AndreySozykin на ip уровне есть фрагментация, которая позволяет разбить и собрать обратно один большой набор байт на несколько ip-пакетов, при этом гарантируется порядок пакетов, но не гарантируется доставка.
Для чего тогда tcp-уровню делить поток байт на сегменты, если это уже делается уровнем ниже в ip?
Very good
Thank you!
умничка
+Lisa Fox, спасибо!
годнота
Спасибо!
пасиб
+Gumball Watterson, пожалуйста!
надеюсь что мне поможет на экзамене! Спасибо!
+tred gelever Я тоже надеюсь, что поможет :)
4:02 не пойму как может отправляться следующий сегмент если подтверждение ещё не пришло
Здравствуйте Андрей! Возможно вопрос не относится данном видео но все же спрошу. На коммутаторах на портах есть значения mtu 1500byte это означает что через порт будет пропускаться сообщения с максимальным размером 1500 байт?
сегмент так сказать
@@yerbossynov да, но КАДР размером не более 1500 байт.
@@w1tcherj не верно, "ПАКЕТ" не более 1500 байт, опять же производители по разному это значение закладывают, даже у cisco в разных версиях оборудования по разному, вообще нормальный фрэйм (кадр) 1518, но коммутаторы чаще всего не учитывают l2 заголовки, по-этому указывается 1500, 18 байт это mac dst 6 байт, mac src 6 байт, ethertype 2 байта и в конце 4 байта FCS (CRC).
Андрей,правильно ли я понимаю, что допустим при отправлении файл размером 1GB делится на 1024байт (1 сегмент) и получаем 1 073 741 824байт / 1024=1048576 - количество сегментов при отправке файла размером 1GB?
Если размер сегмента 1024 байта, то правильно.
@@AndreySozykin а все таки от чего зависит размер сегмента? от mtu технологии канального уровня?
О подстригся по сравнению с с протоколом UDP (это шутка, на само деле всё очень доступно объясняет )
Лол))))
У меня проблема с этой лекцией.
Ранее было сказано что именно канальный уровень обнаруживает и исправляет такие ошибки, в этой лекции эта функция уже на транспортном уровне.
Еще будут видео?
Подписка
Спасибо!
интересно и понятно
^_^
super prosto
Спасибо!
Здравствуйте. А что если в момент отправки пакета клиенту-сервера наш роутер уйдет в перезагрузку? Будет ли доставлен пакет после поднятия роутера?
Здравствуйте, у вас есть видео про tcp udp порты и разделение портов на три диапазона
под сегментами, я так понимаю, вы подразумеваете пакеты
В TCP/IP используются разные названия для сообщений на разных уровнях. Пакеты - это сообщения сетевого уровня. На канальном уровне сообщения называются кадрами. На транспортном целых два названия: сегменты для протокола TCP и датаграммы для UDP.
Сасибо
Никак не могу понять ни osi, ни tcp/ip. Вы говорите, что TCP приходит поток данных, но ведь ему приходят данные в виде IP-пакетов или нет? Или один протокол в другом? Я запутался, плохо быть тупым. Что вообще происходит при просто скачивании файла, просмотре видео или разговоре по скайпу?
Один протокол в другом. Это называется инкапсуляция.
А почему нельзя было также отправить пакет, и работать именно с ним, а не "конвертировать" его назад в поток байтов?
+Pavel Kenov, потому что это разные задачи. Например, мы хотим передать по сети большой файл. А сеть умеет передавать только отлельные пакеты. В этом случае каждое приложение должно само уметь разделять файл на отдельные пакеты, передавать по сети, а затем собирать снова. Причем размер пакета может быть разным в зависимости от конфигурации сети. Проще на уровне сети сделать сервис "передача потока байт". Сетевой стек получит файл от приложения, сам разобъет его на пакеты, как нужно, а на стороне получателя соберет. Приложение получатель получит готовый файл.
Возникает вопрос если мы нумеруем не сегменты (сообщения), а байты, то как передавать файлы больше 4gb в рамках одной TCP сессии?
Почему 4GB, т.к поле ACK number имеет размер 32бита
Нашёл ответ?)
Насколько я знаю там ещё иницииация на завершение есть (tear down)
А где +1 там же ACK должен быт +1 или я ошебаюс я уже зпутася
+Ando Rubekyan, в подтверждении должен быть обязательно установлен флаг ACK и записан номер следующего ожидаемого байта (+1)
И ешо такои бапроскогта скажем копютер отправляет запрос (SYN) серверу с кокип то числом скажем 100 и получает ответ (SYN 300 / ACK 101) и вответ ACK . Откуда они берут числа произволно или откудо то я понемаю чо +1 ето потверждение но не понемаю почему +1 и непонемаю почему у тебя нет етого +1 в ACK. прошу обяцни если несложно негде не написано я уже 2 дня хочу понят но негде не нахажу обяснениа. Я хочу филтор создат для филтрации TCP пакета и мне нужно понят кок оно работает чтобы ненужние логи филтроват. Заране спасибо.
+Ando Rubekyan подробнее описано в видео по установке соединения в TCP: th-cam.com/video/vt69HEbZ_pI/w-d-xo.html
Вкратце: начальные номера байтов для нумерации выбирают по достаточно сложному алгоритму, чтобы в разных соединениях они не совпадали. +1 в подтверждении - это просто такая особенность TCP, никакого особого смысла в этом нет. Передается не номер последнего полученного байта, а номер первого ожидаемого.
А снизу написано "протокол udp", но это была прошлая тема
Да, ошибка при оформлении презентации.
@@AndreySozykin спасибо за чётко структурированную и понятную презентацию. Очень приятно смотреть на такую хорошую подачу информации. Ничего лишнего и всё по делу.
G
Грамотно, последовательно, есть множество тем по-порядку! Это ок, но всё же ты невероятно душный и скучный: тебя удобно слушать, когда срочно надо уснуть.
Спасибо!
спасибо
Пожалуйста!
Спасибо
Пожалуйста!
Спасибо
Пожалуйста!