ЛЕКЦИИ / Лекции1

ВОПРОС 29 ПЕРЕДАЧА ПАКЕТОВ НА СЕТЕВОМ И КАНАЛЬНОМ УРОВНЯХ рассмотрим как взаимодействуют сетевой и канальный уровни при передаче пакетов по сети. С2 напомню что на канальном уровне выполняется передача данных в одном сегменте сети, а сетевой уровень предназначен для того чтобы объединять такие сегменты в крупную составную сеть. для адресации на канальном уровне используется MAC-адреса, а для адресации на сетевом уровне IP адреса. таким образом каждый пакет, который передается по сети содержит в себе два адреса - IP и MAC-адрес. рассмотрим как эти адреса используются. С3 начнем с простого варианта - когда передача происходит в одном сегменте сети. у нас есть компьютер отправитель с IP и MAC адресами - слева. С4 и есть компьютер получатель в той же сети с IP и MAC-адресами - справа вверху. С5 мы начинаем формировать пакет. в адрес отправителя включаем IP адрес и MAC адрес компьютера отправителя. в адресе получателя включаем IP адрес получателя, но MAC-адреса мы как правило не знаем. С6 для того чтобы узнать MAC адрес по IP адресу используется протокол ARP. С7 компьютер отправитель передает ARP запрос на широковещательный MAC-адрес. какой MAC-адрес у компьютера с таким IP адресом? С8 компьютер получателя отвечает, и говорит что у него вот такой MAC-адрес. С9 мы берем этот MAC адрес, вставляем его в поле MAC-адрес получателя, и наш пакет готов к передаче по сети. С10 получатель передает нам ответ. в адреса отправителя он вставляет свой IP адрес и свой MAC-адрес. наш IP адрес в поле IP адрес получателя и наш MAC адрес в поле MAC адрес получателя. ARP запрос при этом как правило не нужен потому что MAC-адрес нашего компьютера получатель узнал из пакета, который мы ему отправили. С11 теперь рассмотрим более сложный вариант. получатель (право-низ) находятся в другой сети. мы начинаем формировать пакет в адрес отправителя включаем свой IP адрес и свой MAC-адрес. С12 в адрес получателя включаем его IP адрес. теперь нам нужно узнать MAC адрес на который мы будем передавать этот пакет. первое что мы делаем - это проверяем находится ли получатель одной сети с нами. С13 для этого мы берем адрес нашей сети (предположим что он у нас 192,168.1,1/24) и проверяем адрес получателя - подходит он под эту сеть или нет. в нашем случае он не подходит. если получатель находится в другой сети, то мы не можем передать пакет ему напрямую. мы должны передать этот пакет маршрутизатору. адрес маршрутизатора на которые нужно передавать пакет компьютер узнает с помощью таблицы маршрутизации. в нашей сети один маршрутизатор у которого два интерфейса. у него есть IP адреса в каждой из подсетей которые он объединяет, и MAC адреса, которые также разные для разных подсетей. получив IP адрес маршрутизатора из таблицы маршрутизации на компьютер мы ищем MAC-адрес маршрутизатора. как правило для этого используется протокол ARP. С13 и после того как мы определили MAC адрес маршрутизатора, мы записываем его в MAC адрес получателя. пакет сформирован и готов к передаче. мы его передаем на маршрутизатор. С14 маршрутизатор принимает пакет, и готовить его у для передачи по следующей сети. С15 IP адреса отправителя и получателя остаются без изменений. MAC-адреса меняются. в MAC адресе отправителя вставляется MAC адрес маршрутизатора в этой сети. в MAC адресе получателя записывается MAC адрес нашего компьютера получателя. теперь он находится в той сети в который мы передаем пакет, и мы можем узнать этот MAC-адрес с помощью такого ARP. С16 отправитель передает нам ответ. в адресе отправителя указан его IP и MAC-адрес. в IP адресе получателя IP адрес нашего компьютера получателя. в MAC-адресе получателя MAC-адрес маршрутизатора в этой сети. получатель готовит такой пакет и передает его на маршрутизатор. С17 маршрутизатор в свою очередь опять изменяет MAC-адреса в пакете. в поле MAC адрес отправителя записывается MAC адрес маршрутизатора в этой сети, а в поле MAC адрес получателя - адрес нашего компьютера. С18 итак мы рассмотрели как происходит взаимодействие сетевого и их канального уровня при передаче пакетов по сети. IP адреса в пакете всегда остаются постоянными!!! указывается IP адрес отправителя и IP адрес получателя в каких бы сетях они ни находились, и сколько бы маршрутизаторов между ними не было. а MAC адреса отправителя и получателя постоянно меняются. канальный уровень работает по принципу звеньев цепи, если на канальном уровне мы не можем передать пакет непосредственно получателю, то в качестве адреса получателя указывается адрес маршрутизатора. маршрутизатор в свою очередь меняет в пакете в MAC адрес отправителя и MAC адрес получателя. если наш пакет проходит через несколько маршрутизаторов, то такая смена происходит несколько раз. также при передаче пакета используются дополнительные средства сетевого и канального уровня. это протокол ARP для того чтобы по IP адрес у компьютера или маршрутизатора узнать его MAC-адрес. маска подсети - для того чтобы узнать находится ли компьютер получателя в той же самой подсети что и компьютер отправителя, и определить можно ли передать данные напрямую получателю, или необходимо передать их маршрутизатору для последующей пересылки. и если нужно передавать данные маршрутизатору, то используется таблица маршрутизации, либо на хосте, либо на самом маршрутизаторе. ¶

ВОПРОС 30 ТРАНСПОРТНЫЙ УРОВЕНЬ С2 продолжаем двигаться вверх по модели взаимодействия открытых систем. изучили физический и канальный сетевой уровни. переходим к транспортному уровню. это четвертый уровень модель взаимодействия открытых систем. и третий уровень в модели TCP/IP. С3 на канальном уровне мы научились передавать данные между компьютерами либо по проводам, либо без проводов. на сетевом уровне мы узнали как строятся составные сети на основе разных технологий канального уровня. теперь у нас есть следующая задача. на наш компьютер, который подключён к составной сети, приходит пакет. на компьютере работает много сетевых приложений. это может быть электронная почта, скайп, браузер, может быть открыто несколько окон браузеров, и какие то другие приложения. нам необходимо понять какому приложению нужно отправить этот пакет. взаимодействием сетевых приложений как раз и занимается транспортный уровень. С4 задача транспортного уровня это передача данных между процессами на разных хостах. на транспортном уровне необходимо обеспечить адресацию. мы должны знать для какого процесса предназначена тот или иной пакет. важными задачами транспортного уровня является обеспечение надежности передачи данных. транспортный уровень может предоставлять надежность более высокую чем надежности те, которые используются для передачи данных. с другой стороны транспортный уровень может и не предоставлять дополнительный уровень надежности. все зависит от требований конкретного приложения. С5 полностью модель взаимодействия открытых систем выглядит следующим образом - отдельно выделяются хосты - это устройство где работают полезные пользовательские программы, и сетевое оборудование - такое как маршрутизаторы, коммутаторы и другие сетевые устройства. на сетевом оборудовании есть только три уровня - физический и канальный и сетевой. уровни начиная с транспортного работают только на хостах. важной особенностью транспортного уровня является прямое взаимодействие с транспортным уровнем на другом компьютере. на всех остальных уровнях взаимодействия идет по так называемым звеньям цепи. данные передаются от одного сетевого устройства до другого и так пока не дойдут до нужного хоста. транспортный уровень обеспечивает так называемые сквозное соединение. между двумя взаимодействующими хостами может находиться большое количество сетевых устройств, но они не влияют на работу транспортного уровня. поэтому транспортный уровень называется сетенезависимым. он позволяет скрыть от разработчиков приложений детали сетевого взаимодействия. С6 для адресации на транспортном уровне используются так называемые порты. это просто число от единицы до 65535. номера у процессов на одном хосте не должны повторяться, иначе мы не сможем понять какому конкретно процессу отправить пришедшие пакеты. записываются порты следующим образом - IP адрес и порт. таким образом в интернете для того чтобы подключиться к кому-нибудь сервису или службе необходимо указать IP адрес и соответствующий порт. С7 есть три типа портов. хорошо известные порты, зарегистрированные порты, и динамические порты. если мы хотим подключиться к какому-то сервису в интернете - нам нужно указать не только IP адрес, но и порт. поэтому договорились что популярные сервисы будут всегда работать на одних и тех же портах. эти порты называются хорошо известные или широко известные. по английски well now in port. например протокол http работают на порту номер 80. существенное ограничение заключается в том, что запускать сервисы, работающие на хорошо известных портах, могут только пользователи с правами администратора. это Root в unix или администратора в windows. если разрабатываете свой сервис, и хотите чтобы пользователи знали на каком порту он работает, можете зарегистрировать этот порт в организации IANA и выбрать себе порт из диапазона. при этом опять же необходимо смотреть чтобы этот порт не был зарегистрирован никаким другим разработчиком приложений. следует отметить что использование как хорошо известных портов, так и зарегистрированных портов - это просто договорённость. например веб-сервер может работать не только на 80 порту, но и на любом другом. часто используется порт номер 88 или 8080. при этом когда вы подключаетесь к такому Web-серверу вы должны явно указать порт на котором он работает. тоже самое применимо и ко всем остальным сервисам. динамические порты из диапазона 49151-65535 назначаются операционной системой клиентам. клиенту, точно так же как и серверу, необходим не только IP адрес, но и порт. но в случае с клиентом номер порта не имеет принципиального значения, так как клиент отправляет запрос серверу, и сервер в запросе увидит как IP-адрес клиента так и его порт. поэтому операционная система назначает клиентам порты автоматически из диапазона динамических портов. С8 рассмотрим пример сетевого взаимодействия с использованием IP адресов и портов. у нас есть сервер на котором работает веб-сервер на порту номер 80. и также есть клиент, который хочет подключиться к этому веб-серверу. С9 клиент открывает браузер. операционная система автоматически назначают ему порт 50298. С10 браузер выполняет соединение с веб-сервером, запрашивает веб-страницу. С11 веб сервер отправляет ему эту страницу. С12 предположим что дальше клиент решил открыть еще один браузер, и зайти на тот же самый сервер, на ту же самую веб-страницу. операционная система автоматически назначила браузеру порт. это другой номер порта 50302. С13 браузер соединяется с веб-сервером. веб сервер видит в запросе не только IP адрес клиента, но и его порт. С14 поэтому когда приходит ответ он отправляется именно в тот браузер из которого был направлен запрос, а не в другой браузер. благодаря использованию не только IP-адресов, но и портов никакой путаницы не происходит. С15 важной особенностью транспортного уровня является то, что он может обеспечить более высокую надежность, чем сеть которая используется для передачи данных. в настоящее время это эффективно на практике, потому что используются надежные каналы. связи ошибки в этих каналах происходит редко, поэтому можно строить сеть ненадежную, которая будет строить дешево. А ошибки, так как они возникают редко, можно исправлять программно на хостах. на транспортном уровне в модель взаимодействия открытых систем предусмотрено много различных вариантов обеспечения надежности на транспортном уровне. Но на практике чаще всего используется всего две возможности. во-первых транспортный уровень может гарантировать доставку данных. так как сеть у нас ненадежная некоторые пакеты могут потеряться. для того чтобы гарантировать доставку транспортный уровень использует подтверждение. если через определенное время не пришло подтверждение, то тот же самый пакет отправляется снова. также транспортный уровень может гарантировать порядок следования сообщений. так как у нас есть с пакетной коммутацией, разные пакеты могут пойти через разные маршрутизаторы, и может случиться так, что пакет, который был отправлен позже, придёт получателю раньше. для того чтобы решить эту проблему на транспортном уровне используется нумерация сообщений. С16 в стеке протоколов TCP/IP на транспортном уровне используются два протокола - TCP и UDP. TCP это протокол который обеспечивает надежность доставки. он обеспечивает как гарантию доставки, так и гарантию сохранения порядка следования сообщений. протокол UDP не гарантирует доставку, но зато работает быстрее чем протокол TCP. Эти протоколы будет подробно изучать в следующих вопросах. С17 для взаимодействия с транспортным уровнем используется интерфейс сокетов. ранее мы не рассматривали интерфейсы которые используются для взаимодействия между уровней, так как они были скрыты от нас. транспортный уровень - это первый уровень для которого мы рассматриваем интерфейс, так как многие сетевые приложения взаимодействует именно с транспортным уровнем. хотя сейчас все более популярной становятся разработка сетевых приложений которые взаимодействуют не с транспортным, а с прикладным уровнем. интерфейс сокетов мы будем изучать подробно на одной из последующих лекций. С18 итак мы рассмотрели транспортный уровень модели взаимодействия открытых систем. основная задача транспортного уровня - это передача данных между процессами которые работают на разных хостах. для адресации на транспортном уровне используются порты. это просто числа от единицы до 65535. транспортный уровень - это первый сетенезависимый уровень. он есть только на хостах, и взаимодействие ведется с транспортным уровнем на другом хосте. детали промежуточного взаимодействия сетевым оборудованием скрываются от транспортного уровня. транспортный уровень может обеспечить более надежную доставку данных, чем предоставляет сеть, и на практике это эффективно. на транспортном уровне используется протоколы TCP, который гарантируют доставку данных и сохранения порядка следования сообщений, и протокол и UDP, который не гарантирует доставку. и для взаимодействия приложений с транспортным уровнем используется интерфейс сокетов. ¶

ВОПРОС 31 ПРОТОКОЛ UDP С2 UDP это протокол транспортного уровня стека протоколов TCP/IP. на транспортном уровне в стеке TCP/IP используются два протокола. протокол TCP обеспечивает надежную доставку данных, а протокол UDP надежной доставки данных не обеспечивает. С3 UDP расшифровывается как User Datagram Protocol - протокол датаграмм пользователя. сообщения UDP называются дейтаграмма, по аналогии с телеграммой - короткое сообщение которое доставляется быстро. UDP не предоставляют дополнительного уровня надежности по сравнению с протоколом IP. правомерно будет задать вопрос - а зачем нам протокол транспортного уровня, если он не обеспечивает надежность доставки выше чем IP? почему нельзя использовать просто IP для передачи данных? но на транспортном уровне нам необходимо указать порт отправителя и порт получателя. и именно это и делает UDP. С4 формат заголовка UDP очень простой. всего лишь 4 поля. порт отправителя, порт получателя, длина UDP, в которой содержится длина всей дейтаграммы UDP, и контрольную сумму UDP, которые используются для проверки корректности доставки дейтаграммы. С5 на другой вопрос который тоже можно задать - зачем же нам использовать ненадежный протокол транспортного уровня, есть есть протоколу TCP, который гарантирует надежность доставки? преимущество UDP в том что он обеспечивает более высокую скорость по сравнению с TCP так как у него нет накладных расходов на установку и на разрыв соединения. ошибки в современных сетях происходят достаточно редко, и сетевые приложения вполне способны самостоятельно исправлять такие редко возникают ошибки. область применения UDP этой системы которые работают в режиме запрос-ответ, и обмениваются между собой короткими сообщениями. С6 в качестве примера применения UDP рассмотрим систему доменных имен - DNS, но она играет большую роль в работе интернет. DNS позволяют определить по доменному имени соответствующий ему IP адрес. например в доменному имени cisco.com соответствует IP адрес 184.86.0.170. система DNS использует протокол UDP port 53. С7 рассмотрим пример сетевого взаимодействия в DNS. в системе DNS есть сервер, который знает какие IP адреса соответствуют доменным именам, и клиент, который хочет получить такую информацию. клиент DNS направляет запрос серверу - какой IP у какого-то доменного имени. например у cisco.com. С8 сервер DNS получают такой запрос, находит соответствующий IP адрес, и отправляет ответ. взаимодействие происходит с использованием протокола UDP и для получения IP адреса достаточно всего две дейтаграммы. если вы для сброса IP-адреса использовался протокол TCP, то необходимо было бы передать гораздо больше сообщений. подробности работы TCP будем рассматривать в следующих вопросах. Но забегая вперед скажу, что перед тем как запрашивать IP адрес необходимо было бы установить соединение TCP, для этого нужно 3 сообщения, затем запросить IP адрес, получить ответ - еще два сообщения, и после того как ответ получен нужно разорвать соединение - для этого нужно 3 или 4 сообщения. В UDP для получения IP-адреса нужно всего 2 дейтаграммы, что гораздо быстрее. С9 однако недостаток UDP в том что он не обеспечивает надежности передачи данных. поэтому ошибки должно обрабатывать приложение. рассмотрим что произойдет если запрос потерялся. приложение клиента DNS при отправке запроса запускает таймер. С10 если в течение какого-то времени ответ не приходит таймер срабатывает, и тот же самый запрос отправляется еще раз. С11 предположим что в этот раз запрос дошел, и UDP сервер в ответ отправил нам IP адрес который мы ищем. С12 даже с учетом того, что произошла потеря данных, IP адрес все равно будет получен быстрее, чем если бы использовался протокол TCP. однако существенным недостатком использования UDP является то, что приложение должно само обрабатывать ошибочные ситуации. С13 итак мы рассмотрели протоколу UDP - юзер дейтаграмм протокол. протокол дейтаграмм пользователя. он находится на транспортном уровне модели взаимодействия открытых систем стека протоколов TCP/IP. UDP не обеспечивает дополнительную надежность передачи данных, но зато работает быстрее чем TCP. основная задача UDP это указать порты отправителя и порты получателя. и область применения UDP это обмен короткими сообщениями в режиме запрос-ответ ¶

ВОПРОС 32 ПРОТОКОЛ TCP С2 протокол TCP находится на транспортном уровне модели взаимодействия открытых систем и стека протоколов TCP/IP. на этом уровне есть два протокола. протокол UDP, которые мы уже рассматривали, и протокол TCP, который является одним из основных протоколов стека TCP/IP и интернет. С3 TCP расшифровывается как Transmission Control Protocol - протокол управление передач. в отличие от UDP TCP обеспечивает надежную доставку данных. сервис предоставляемые TCP называются надежная передача потока байт, или reliable byte stream. по английски TCP обеспечивают как гарантию доставки данных, так и гарантию сохранения порядка следования сообщений. С4 от приложения протокол TCP получает поток байт, который может быть очень большим. например вы можете скачивать из интернета файл, который составляет несколько мегабайт или несколько гигабайт. данные файлы приходят на транспортный уровень в виде одного большого потока байт. в протоколе TCP поток байт делится на отдельная части, которые называются сегменты. и каждый сегмент отправляется отдельно получателю. получатель со своей стороны принимают сегменты, собирают их в один большой потом байт, и отправляет этот поток байт приложению. С5 для того чтобы обеспечить гарантию доставки данных TCP использует подтверждение получении сообщения. рассмотрим как это работает. отправитель пересылают посетить некоторые сегмент данных. С6 получатель принимает сегмент и посылает отправителю подтверждение. сокращенно ACK, которое говорит о том, что сегмент данных получен. С7 затем отправляется следующий сегмент данных, снова подтверждения, и так далее. С8 а что происходит если произошла ошибка при передаче данных? сегмент данных потерянных в сети, он не доходит до получателя, получатель не отправляет подтверждение сообщения. С9 отправитель при отправке сегмента устанавливает таймер, который задает время ожидания подтверждения, если в течении этого времени подтверждения не пришло, таймер срабатывает, С10 и тот же самый сегмент отправляются повторной. предположим что в этот раз сегмент дошел, С11 получатель отправляет подтверждение, отправитель может передавать следующий сегмент данных. С12 работы протокола TCP отличаются от той схемы которую мы сейчас рассмотрели. подтверждается не каждый сегмент, а несколько сегментов, следующие друг за другом. этот механизм называется скользящее окно, и подробно рассмотрим его в одной из следующих лекций. С13 но подтверждений и повторной отправки данных недостаточно для обеспечения надежной передачи потока байт. это защищают только от потери сегментов, но не обеспечивает сохранение порядка следования сообщений. какие проблемы могут произойти? протокол IP не сохраняет порядок следования сообщений, и поэтому сегменты могут перейти к получателю не в том порядке в котором они были отправлены. кроме того некоторые сегменты могут прийти два и более раз. С14 рассмотрим одну из возможных причин дублирования сегментов. предположим отправитель передал сегмент данных получателю, получатель этот сегмент принял, и передал отправителю подтверждение, но при передаче подтверждения произошла ошибка. С15 отправитель не получил подтверждение, сработал таймер, и тот же самый сегмент данных был отправлен 2 раз. это один из возможных вариантов. на самом деле таких вариантов еще очень много. поэтому в протокол TCP встроен механизм защиты от дублирования и нарушения порядка следования сообщений. С16 механизм очень простой - все сообщения нумеруются. в TCP нумеруются не сегменты, так как разные сегменты могут иметь разный размер, а байты. в нашем примере 4 сегмента. первый сегмент содержит байты от 0 до 1023. второй от 1024 до 2047, и так далее. С17 при передаче отправитель включают в сегмент номер первого байта данных который в нем содержится. например сегмент данных, байт 0 - он содержит байты с 0 до 1023го. С18 получатель отправляет подтверждение, и в подтверждение включает номер следующего байта, которая ожидается - байт 1024. С19 отправитель передает следующий сегмент, включая в него номер 1 байта. сегмент данных, номер первого байта 1024. содержит данные до номера байта 2047. С20 получатель отправляет подтверждение, что он ждет байт с номером 2048. если сегменты придут в неправильном порядке, то получатель по номерам байтов всегда сможет выставить их в правильной последовательности. С21 рассмотрим как решается ситуация с дублированием сегментов. отправитель включает в сегмент номер первого передаваемого байта - 1024. получать отправляет подтверждение, где говорит что ждет байт в 2048. но так как подтверждение не дошло, отправитель передает тот же самый сегмент 1024, однако получатель видит что этот сегмент у него уже есть, поэтому он этот сегмент игнорируют, и снова отправляет подтверждение, где говорит что он ожидает байт 2048. С22 TCP для передачи данных использует соединение. соединению нужно установить перед тем как начать передачу данных, а после того как передача данных завершена соединение разрывается. задача соединения - убедиться в том что отправитель и получатель действительно хотят передавать данные друг другу, договориться о нумерации потоков байт. с точки зрения практической реализации нельзя всегда нумеровать данные в потоке байт с нуля. каждый раз начальное значение для нумерации байт выбираются по определенному алгоритму, и отправитель и получатель должны договориться между собой, какое начальное значение они будут использовать для нумерации потока байт. также при установке соединения происходит договоренность о некоторых параметрах соединения. подробно процесс установки и разрыва соединения TCP рассмотрим в одной из следующих лекций. С23 итак мы рассмотрели протокол TCP - transmission control protocol - протокол управления передачей данных. TCP обеспечивают надежную передачу потока байт от одного приложения к другому. при этом TCP обеспечивает как гарантию доставки данных, так и гарантию сохранении порядка следования сообщений. гарантия доставки данных обеспечивается подтверждением получения сообщений, и повторной отправкой сообщений для которых не пришло подтверждение. а гарантия сохранения порядка следования сообщений реализуется с помощью нумерации байтов в сообщениях. TCP используют соединение между отправителем и получателем, которые необходимо установить до того как начнется передача данных, а после завершения передачи соединение необходимо разорвать. ¶

ВОПРОС 33 ПРОТОКОЛ TCP: СКОЛЬЗЯЩЕЕ ОКНО С2 протокол TCP обеспечивает гарантию доставки данных, для этого используется подтверждение доставки. данные для которых не пришло подтверждение высылаются повторно. сегодня мы поговорим о возможных вариантах подтверждения доставки - остановка ожидания и скользящее окно, которые используются в TCP. С3 сначала рассмотрим остановку и ожидание. отправитель передает данные, и останавливаются ожидая подтверждения. получатель присылает подтверждения, после этого передается следующая порция данных, снова подтверждение, снова данные, и снова подтверждение. другой вариант - скользящее окно. в этом случае отправитель передает сразу несколько порций данных не дожидаясь подтверждения. получатель отправляют одно подтверждение, которые называются кумулятивное. это означает что получатель получил последнюю порцию данных, и все предыдущие. С4 почему на транспортном уровне эффективно использовать скользящее окно? дело в том, что сообщение по сети передается хоть и быстро, но не мгновенно. поэтому в среде передачи данных может находиться некоторый объем данных, которые определяются скоростью передачи данных умноженной на задержку передачи данных. этот объем небольшой для локальных сетей, где я отправитель и получатель у находится рядом друг с другом, поэтому задержка как правило небольшая. в локальных сетях - например в вай фай используется метод подтверждения - остановка и ожидание. в крупных современных сетях с высокоскоростными каналами связи большой протяженности, например если вы хотите скачать чего-нибудь американского сайта, такой объем данных может быть очень большой. и в этой ситуации ожидание подтверждения приводит к существенному снижению производительности. С5 рассмотрим на примере работу сети который я нашел: а сеть уральского отделения российской академии наук. канал Екатеринбург-Пермь. его протяженность четыреста шестьдесят пять километров. скорость 10 гигабит в секунду. так как протяженность достаточно большая - задержка при передаче данных составляет 10 миллисекунд. объем данных сети равен умножаем задержку на скорость передачи данных, получаем 12,5Мб. это означает что отправитель начал передавать данные, и до того как первая порция данных дойдет до получателя он может отправить в сеть 12,5Мб. еще столько же он может отправить в сеть пока до него дойдёт подтверждение получения. таким образом если не останавливать передачу до получения подтверждения можно передать в сеть 25 мегабайт, и только после этого получить подтверждение первой порции данных. если же мы будем останавливаться и ждать получение каждого сегмента, то за секунду мы можем передать всего лишь 50 сегментов. скорость передачи данных в таком режиме будет всего лишь 75 килобайт в секунду. что существенно меньше 10 гбит в секунду пропускной способности канала. поэтому важно использовать скользящее окно, и передавать несколько сегментов сразу, не дожидаясь подтверждения каждого. С6 почему термин называется скользящее окно? удобно представлять себе окно, которое скользит по потоку байт получаемых от приложений. у нас есть поток байт разделенных на отдельные сегменты. часть сегментов уже передана, часть еще не отправлена. для некоторых сегментов, которые уже переданы, получено подтверждение. и отправлено некоторое количество сегментов, соответствующее размеру окна, для которых подтверждение не получено. размер окна - это количество байтов данных которые могут быть переданы без получения подтверждения. в нашем примере размер окна 8 сегментов. С7 что происходит если мы получили очередное подтверждение? С8 мы можем передвинуть окно дальше по данным. в него попадает новая порция не отправленных данных. С9 можно отправить эти данныю получателю. после этого отправитель останавливается, и дожидаются подтверждения получения следующей порции данных. таким образом окно скользит вдоль нашего потока байт от приложения. С10 есть два типа подтверждения которые могут использоваться совместно с алгоритмом скользящего окна. коммулятивное подтверждение, которые мы уже рассматривали, говорит о том что получен указанный байт данных и все предыдущие. такой подход используется в TCP по умолчанию. сейчас, из-за того что распространились высокоскоростные каналы связи большой протяженности, размер окна в TCP может быть увеличен до 1 гигабайта. представьте, что вы передали гигабайт данных, и у вас потерялся всего лишь один сегмент, который находится в середине. с помощью комулятивного подтверждения можете подтвердить получение только первых 500 мегабайт. получится что придётся повторно передавать 500 мегабайт данных которые уже есть у получателя. для устранения этой проблемы предложено так называемые выборочное подтверждение. в этом случае получатель подтверждает получение диапазона принятых байт. он получил первые 500 мегабайт и вторые 500 мегабайт из гигабайта и не получил всего лишь один сегмент. отправитель, вместо вторых 500 мегабайт, повторно передает всего лишь один недостающий сегмент. выборочное подтверждение эффективно при большом размере окна TCP. но выборочное подтверждение по умолчанию не используется. для этого необходимо применение дополнительных полей заголовка TCP, которое называются параметрами. С11 итак мы рассмотрели различные варианты подтверждения сообщений. остановка и ожидание которые используются на канальном уровне, и скользящее окно, которое используется на транспортном уровне в протоколе TCP для того чтобы повысить производительность передачи данных по протяженным высокоскоростным каналам связи, которые сейчас широко используется в интернет. размер окна - это количество байт данных которые могут переданы без получения подтверждения. в TCP используется два варианта подтверждения - кумулятивное и выборочное ¶