Прежде чем мы начнем сегодняшний видеоурок, хочу поблагодарить всех, кто способствовал популярности моего курса на YouTube. Когда я начал его около 8 месяцев назад, то не ожидал такого успеха – на сегодня мои уроки просмотрели 312724 человека, у меня 11208 подписчиков. Мне и не снилось, что это скромное начинание достигнет таких высот. Но не будем терять время и сразу перейдем к сегодняшнему занятию. Сегодня мы восполним пробелы, которые имели место в последних 7 видеоуроках. Хотя сегодня только 6 день, день 3 был разбит на 3 видеоурока, так что фактически сегодня вы посмотрите восьмой видеоурок.
Сегодня мы будем заниматься 3 важными темами: DHCP, передача TCP и наиболее употребительные номера портов. Мы уже говорили об IP-адресах, и одним из важнейших факторов конфигурации IP-адреса является DHCP.
DHCP расшифровывается как «протокол динамической настройки узла», это протокол, который помогает динамически настраивать IP-адреса для хостов. Итак, все мы видели это окно. При нажатии на параметр “получить IP-адрес автоматически” компьютер ищет DHCP-сервер, настроенный в одной подсети и отправляющий различные пакеты и запросы для IP-адреса. Протокол DHCP имеет 6 сообщений, из которых 4 имеют решающее значение для назначения IP-адреса.
Первое сообщение является сообщением обнаружения DHCP DISCOVERY. Сообщение обнаружения DHCP похоже на приветствие. Когда новое устройство заходит в сеть, оно спрашивает, присутствует ли в сети DHCP-сервер.
То, что вы видите на слайде, похоже на широковещательный запрос, кода устройство обращается ко всем устройствам в сети в поисках DHCP-сервера. Как я уже сказал, это широковещательный запрос, поэтому его слышат все устройства сети.
Если в сети есть DHCP-сервер, он отправляет пакет — предложение DHCP OFFER. Предложение означает, что DHCP-сервер в ответ на запрос обнаружения отправляет клиенту конфигурацию, предлагая клиенту принять определенный IP-адрес.
DHCP-сервер резервирует IP-адрес, в данном случае 192.168.1.2, не предоставляет, а именно резервирует за устройством данный адрес. Вместе с этим в пакете предложения содержится собственный IP-адрес DHCP-сервера.
Если в этой сети имеется более одного DHCP-сервера, другой DHCP-сервер, получив широковещательный запрос клиента, также предложил бы ему свой IP-адрес, например, 192.168.1.50. Обычно в одной и той же сети не настраиваются два разных DHCP-сервера, но иногда такое все же случается. Таким образом, когда предложение DHCP отправляется клиенту, он получает 2 предложения DHCP и теперь должен решить, какое предложение DHCP он хочет принять.
Давайте предположим, что клиент принимает первое приложение. Это означает, что клиент отсылает запрос DHCP REQUEST, в котором буквально говорится: «я принимаю IP-адрес 192.168.1.2, предлагаемый DHCP-сервером 192.168.1.1».
Получив запрос, DHCP-сервер 192.168.1.1 отвечает: «хорошо, я это признаю», то есть подтверждает запрос и направляет это подтверждение DHCP ACK клиенту. Но мы помним, что другой DHCP- сервер DHCP зарезервировал для клиента IP-адрес 1.50. Получив широковещательный запрос клиента, он узнает об отказе и поместит этот IP-адрес обратно в пул, чтобы он мог назначить его другому клиенту, если получит другой запрос.
Таковы 4 критических сообщения, которыми обменивается DHCP а начале назначения IP-адресов. Далее у DHCP имеются еще 2 информационных сообщения. Информационное сообщение выдается клиентом, если ему требуется больше информации, чем он получил в предложении DHCP OFFER на втором шаге. Если в предложении DHCP сервер предоставил недостаточно информации или если клиенту нужно больше информации, чем та, что содержалась в пакете предложения, он запрашивает дополнительную DHCP- информацию. Есть еще одно сообщение, которое клиент отсылает серверу – это освобождение DHCP RELEASE. В нем сообщается, что клиент хочет освободить имеющийся у него IP-адрес.
Однако чаще всего случается так, что пользователь отключается от сети раньше, чем клиент успевает послать на сервер DHCP RELEASE. Так происходит при выключении компьютера, которое осуществляем мы с вами. При этом сетевой клиент, или компьютер, просто не имеет времени на то, чтобы сообщить серверу об освобождении использовавшегося адреса, поэтому DHCP RELEASE не является обязательным шагом. Обязательными шагами для получения IP-адреса являются: обнаружение DHCP, предложение DHCP, запрос DHCP и подтверждение DHCP.
В одном из следующих уроков я расскажу, как мы настраиваем DHCP- сервер при создании DNCP- пула. Под пулом подразумевается, что вы сообщаете серверу о назначении IP-адресов в диапазоне от 192.168.1.1 до 192.168.1.254. Таким образом, DHCP-сервер создаст пул, поместит в него 254 IP-адреса и сможет назначать клиентам сети адреса только из этого пула. Так это что-то вроде административной настройки, которую может осуществить пользователь.
Теперь рассмотрим передачу TCP. Не знаю, знакомы ли вы с изображенным на картинке «телефоном», но в детстве мы использовали такие консервные банки, соединенные шнурком, чтобы разговаривать друг с другом.
К сожалению, сегодняшнее поколение не может позволить себе такой «роскоши». Я имею в виду, что сегодня дети находятся перед телевизором с годовалого возраста, они играют в PSP, и, возможно, это спорный вопрос, но я думаю, что у нас было лучшее детство, мы действительно выходили на улицу и играли в игры, а сегодняшних детей не оторвешь от дивана.
Моему сыну всего год, и я уже вижу, что он пристрастился к iPad, я имею в виду, что он еще очень маленький, но мне кажется, что сегодняшние дети уже рождаются со знаниями, как обращаться с электронными гаджетами. Итак, я хотел сказать, что в детстве, когда мы играли, мы дырявили консервные банки, и когда связывали их струной и произносили что-то в одну банку, то на другом конце человек мог услышать, что ему говорят, просто приложив банку к уху. Так что это очень похоже на сетевое соединение.
Сегодня даже для передачи TCP должно имеется соединение, которое необходимо установить до того, как начнется реальная передача данных. Как мы обсуждали в предыдущих уроках, TCP — это передача, ориентированная на предварительное установление соединения с сетью, в то время как UDP — это передача без необходимости установки соединения. Можно сказать, что UDP – это когда я бросаю мяч, и от вас зависит, сможете ли вы его поймать. Готовы вы это сделать или нет, это не моя проблема, я просто собираюсь его бросить.
ТСP больше похоже на то, что вы разговариваете с парнем и заранее предупреждаете его о том, что собираетесь бросить мяч, то есть между вами завязывается связь, и только затем вы бросаете мяч, так что с большой вероятностью ваш партнер будет готов его поймать. Таким образом, TCP фактически строит соединение, а затем начинает осуществлять реальную передачу.
Рассмотрим, как он создает такое соединение. Для создания соединения этот протокол использует 3-х этапное рукопожатие. Это не слишком технический термин, но он давно используется для описания TCP-соединения. 3-х этапное рукопожатие инициируется отправляющим устройством, при этом клиент отправляет серверу пакет с SYN-флагом.
Предположим, что девочка на переднем плане, чье лицо мы можем видеть – это устройство А, а девочка на заднем плане, лица которой не видно – устройство В. Девочка А посылает SYN- пакет девочке В, и та говорит: «отлично, кто-то хочет со мной общаться. Значит, мне нужно ответить, что я готова к общению!» Как это сделать? Можно было бы просто отправить обратно еще один SYN-пакет и затем подтверждение ACK, указывающее на получение исходного SYN- пакета. Но вместо того, чтобы отправлять ACK отдельно, сервер формирует общий пакет, в котором содержится SYN и ACK, и передает его по сети.
Итак, на данный момент устройство А отправило SYN-пакет и получило обратно пакет SYN/ACK. Теперь устройство А должно отправить устройству В пакет ACK, то есть подтвердить то, что оно получило согласие устройства В на установление связи. Таким образом, оба устройства получили пакеты SYN и ACK, и теперь можно сказать, что соединение установлено, то есть осуществлено 3-х этапное рукопожатие по протоколу TCP.
Далее мы рассмотрим технологию TCP Windowing. Проще говоря, это метод, используемый в TCP / IP для согласования возможностей отправителя и получателя.
Предположим, что в Windows мы пытаемся перенести большой файл, скажем, размером 2 ГБ, с одного диска на другой. В самом начале переноса система сообщит нам, что перенос файла займет примерно 1 год. Но несколько секунд спустя система исправится и скажет: «о, подождите минутку, я думаю, что это займет не год, а около 6 месяцев». Пройдет еще немного времени, и Windows сообщит: «я думаю, что возможно, смогу перенести файл за 1 месяц». Затем последует сообщение «1 день», «6 часов», «3 часа», «1 час», «20 минут», «10 минут», «3 минуты». В действительности весь процесс переноса файла займет всего 3 минуты. Как же так получилось? Изначально, когда ваше устройство попытался связаться с другим устройством, оно отправляет один пакет и ждет подтверждения. Если устройство ожидает подтверждения долгое время, оно думает: «если я должно совершить передачу 2 ГБ данных на такой скорости, то это займет около 2 лет». Спустя какое-то время ваше устройство получает ACK и думает: «хорошо, я послал один пакет и получил ACK, следовательно, получатель может принять 1 пакет. Теперь я попробую отправить ему 10 пакетов вместо одного». Отправитель посылает 10 пакетов и через какое-то время получает обратно от принимающего устройства подтверждение АСК, которое означает, что получатель ожидает следующий, 11-й пакет. Отправитель думает: «отлично, раз получатель справился сразу с 10-ю пакетами, теперь я попробую послать ему 100 пакетов вместо десяти». Он посылает 100 пакетов, и получатель отвечает, что получил их и сейчас ожидает 101 пакет. Таким образом, с течением времени количество передаваемых пакетов увеличивается.
Вот почему вы видите стремительное уменьшение времени копирования файла по сравнению с заявленным первоначально — это связано с увеличением возможности передачи большого объёма данных. Однако наступает момент, когда дальнейшее увеличение объема передачи становится невозможным. Предположим, вы передали 10000 пакетов, но буфер устройства получателя способен принять всего 9000. В этом случае получатель отправляет ACK с сообщением: «я принял 9000 пакетов и теперь готов принять 9001». Из этого отправитель делает вывод, что буфер принимающего устройства имеет емкость всего 9000, значит, с этого момента я буду посылать за раз не более 9000 пакетов. При этом отправитель быстро подсчитывает время, которое потребуется ему на передачу оставшегося объёма данных порциями по 9000 пакетов, и выдает 3 минуты. Эти три минуты и являются фактическим временем передачи. Вот что делает TCP Windowing.
Это один из тех механизмов регулирования трафика, где передающее устройство со временем понимает, какова фактическая пропускная способность сети. У вас может возникнуть вопрос, почему они не могут договориться заранее о том, какова емкость принимающего устройства? Дело в том, что технически это невозможно, потому что в сети имеются различные типы устройств. Предположим, у вас есть iPad, и у него скорость приема/передачи данных отличается от iPhone, у вас могут быть разные типы телефонов, или, может быть, у вас очень старый компьютер. Поэтому у всех разная пропускная способность сети.
Поэтому и была разработана технология TCP Windowing, когда передача данных начинается на небольшой скорости или с передачи минимального количества пакетов, постепенно увеличивая «окно» трафика. Вы отправляете один пакет, 5 пакетов, 10 пакетов, 1000 пакетов, 10000 пакетов и медленно приоткрываете это окно все больше и больше, пока «раскрытие» не достигнет максимального возможного значения отправки объема трафика в конкретный промежуток времени. Таким образом, концепция Windowing является частью работы протокола TCP.
Далее мы рассмотрим наиболее распространенные номера портов. Классической является ситуация, при которой у вас есть 1 главный сервер, возможно, это дата-центр. Он включает в себя файловый сервер, веб-сервер, почтовый сервер и DHCP-сервер. Теперь, если один из клиентских компьютеров свяжется с дата-центром, который расположен в середине картинки, тот начнет рассылать клиентским устройствам трафик файлового сервера. Этот трафик показан красным цветом, и для его передачи будет использоваться определенный порт для определенного приложения от определенного сервера.
Каким образом сервер узнал, куда должен идти определенный трафик? Он узнает об этом из номера порта назначения. Если вы посмотрите на фрейм, то увидите, что в каждой передаче данных имеется упоминание номера порта назначения и порта источника. Вы видите, что синий и красный трафик, а синий трафик – это трафик веб-сервера, оба поступают на один и тот же физический сервер, в котором установлены разные серверы. Если это дата-центр, то он использует виртуальные серверы. Так как же они узнали, что красный трафик должен был вернуться к этому левому ноутбуку с этим IP-адресом? Они знают это благодаря номерам портов. Если вы обратитесь к статье Википедии «Список портов TCP и UDP», то увидите, что в ней перечислены все стандартные номера портов.
Если прокрутить эту страницу, то у можно увидеть, насколько велик этот список. Он содержит примерно 61 000 номеров. Номера портов от 1 до 1024 известны как наиболее распространенные номера портов. Например, порт 21/TCP предназначен для передачи команд ftp, порт 22 для ssh, порт 23 – для Telnet, то есть для передачи незашифрованных сообщений. Очень популярный порт 80 служит для передачи данных по протоколу HTTP, а порт 443 служит для передачи зашифрованных данных по протоколу HTTPS, который похож на безопасную версию HTTP.
Некоторые порты предназначены одновременно для TCP и UDP, а некоторые выполняют разные задачи в зависимости от того, какое соединение используется – TCP или UDP. Так, официально порт 80 TCP используется для HTTP, а неофициально порт 80 UDP используется для HTTP, но по другому протоколу HTTP — QUIC.
Поэтому номера портов в TCP не всегда предназначены для того же, что и в UDP. Вам не нужно учить этот список наизусть, его невозможно запомнить, но некоторые популярные и наиболее распространенный номера портов нужно знать. Как я сказал, некоторые из этих портов имеют официальное предназначение, которое описано в стандартах, а некоторые – неофициальное предназначение, как в случае с Сhromium.
Итак, в этой таблице перечислены все распространенные номера портов, и эти номера служат для отправки и получения трафика при использовании конкретных приложений.
Теперь давайте рассмотрим, как данные перемещаются в сети, основываясь на той небольшой информации, которую знаем. Предположим, что компьютер 10.1.1.10 хочет связаться с этим компьютером, или этим сервером, который имеет адрес 30.1.1.10. Под IP-адресом каждого из устройств размещен его MAC-адрес. Я привожу в пример MAC-адрес только с последними 4 знаками, но на практике это 48-битное шестнадцатеричное число с 12 знаками. Так как каждое из этих чисел состоит из 4-х бит, 12 шестнадцатеричных цифр представляют собой 48-битное число.
Как мы знаем, если это устройство хочет связаться с этим сервером, сначала должен быть сделан первый шаг 3-этапного рукопожатия, то есть отправлен SYN-пакет. При создании этого запроса компьютер 10.1.1.10 укажет номер порта источника, который Windows создаёт динамически. Windows случайным образом выбирает номер порта в диапазоне от 1 до 65,000. Но поскольку начальные номера в диапазоне от 1 до 1024 являются широко известными, в данном случае система будет рассматривать номера больше 25000 и создаст случайный порт источника, например, под номером 25113.
Далее система добавит в пакет порт назначения, в данном случае это порт 21, потому что приложение, которое пытается подключиться к этому FTP-серверу, знает, что оно должно отправить FTP-трафик.
Далее наш компьютер говорит: «Хорошо, мой IP-адрес 10.1.1.10, а мне нужно связаться с IP-адресом 30.1.1.10». Оба эти адреса также включаются в пакет, формируя SYN-запрос, и этот пакет не будет изменяться до конца установления соединения.
Я хочу, чтобы вы поняли из этого видео, как данные перемещаются по сети. Когда наш компьютер, отправляющий запрос, видит IP-адрес источника и IP-адрес назначения, он понимает, что адрес назначения не находится в этой локальной сети. Я забыл сказать, что это все /24 IP-адреса. Так что, если вы посмотрите на IP-адреса /24, то поймете, что компьютеры 10.1.1.10 и 30.1.1.10 не находятся в одной сети. Таким образом, компьютер-отправитель запроса понимает, что для того, чтобы выйти из этой сети, он должен обратиться к шлюзу 10.1.1.1, который настроен на одном из интерфейсов маршрутизатора. Он знает, что он должен перейти к 10.1.1.1, и знает свой MAC-адрес 1111, но не знает MAC-адрес шлюза 10.1.1.1. Что же он делает? Он посылает широковещательный ARP-запрос, который получат все устройства в сети, но ответит на него только маршрутизатор с IP-адресом 10.1.1.1.
Маршрутизатор ответит ему своим MAC-адресом АААА, и оба MAC-адреса – источника и назначения — также будут помещены в этот фрейм. Как только фрейм будет готов, перед тем, как покинуть сеть, будет осуществлена проверка целостности данных CRC, представляющая собой алгоритм нахождения контрольной суммы с целью обнаружения ошибок.
Циклический избыточный код CRC означает, что весь этот фрейм, от SYN до последнего MAC-адреса, прогоняется через алгоритм хеширования, скажем, MD5, в результате чего получается значение хеша. Затем значение хеша, или контрольная сумма MD5, помещается в начало фрейма.
Я обозначил её FCS/CRC, потому что FCS – это последовательность проверки кадров, четырехбайтовое значение CRC. Некоторые люди употребляют обозначение FCS, а некоторые — CRC, поэтому я просто указал оба обозначения. Но в принципе это всего лишь значение хеша. Оно нужно для того, чтобы убедиться, что все данные, поступающие по сети, не содержат ошибок. Поэтому, когда этот фрейм достигает маршрутизатора, первое, что сделает маршрутизатор, это вычислит контрольную сумму самостоятельно и сравнит её со значением FCS или CRC, которое содержит полученный фрейм. Таким образом он сможет проверить, что данные, поступившие по сети, не содержат ошибок, после чего удалит контрольную сумму из фрейма.
Дальше роутер посмотрит на MAC-адрес и скажет: «Хорошо, MAC-адрес AAAA означает, что фрейм адресован мне», и удалит часть фрейма, содержащую MAC-адреса.
Посмотрев на IP-адрес назначения 30.1.1.10, он поймет, что этот пакет адресован не ему и должен пройти через маршрутизатор дальше.
Теперь роутер «думает» о том, ему нужно увидеть, где находится сеть с адресом 30.1.1.10. Мы еще не рассматривали полной концепции маршрутизации, но знаем, что роутеры имеют таблицу маршрутизации. В этой таблице есть запись для сети с адресом 30.1.1.0. Как вы помните, это не IP-адрес хоста, а идентификатор сети. Роутер «подумает» о том, что можно достичь адреса 30.1.1.0/24, пройдя через маршрутизатор 20.1.1.2.
Вы можете спросить, откуда он это знает? Просто учтите, что он узнает об этом либо из протоколов маршрутизации, либо из ваших настроек, если вы как администратор настроили статический маршрут. Но в любом случае, таблица маршрутизации этого роутера содержит нужную запись, поэтому он знает, что должен отправить этот пакет в 20.1.1.2. Предполагая, что роутер уже знает MAC-адрес назначения, мы просто продолжим пересылку пакета. Если же он не знает этого адреса, то снова запустит ARP, получит MAC-адрес роутера 20.1.1.2, и процесс отправки фрейма опять продолжится.
Итак, мы предполагаем, что он уже знает MAC-адрес, тогда у нас появится исходный MAC-адрес BBB и MAC-адрес назначения CCC. Роутер снова вычисляет FCS/CRC и помещает его в начало фрейма.
Затем он отправляет этот фрейм по сети, фрейм доходит до маршрутизатора 20.1.12, тот проверяет контрольную сумму, убеждается, что данные не повреждены, и удаляет FCS/CRC. Затем он «обрезает» MAC-адреса, смотрит на пункт назначения и видит, что это адрес 30.1.1.10. Он знает, что этот адрес подключен к его интерфейсу. Тот же процесс формирования фрейма повторяется, роутер добавляет значения MAC-адресов источника и назначения, делает хеширование, прикрепляет хэш к фрейму и отправляет его по сети.
Наш сервер, получив наконец-то адресованный ему SYN-запрос, проверяет контрольную сумму хеша, и если в пакете не содержит ошибок, удаляет хеш. Затем он удаляет MAC-адреса, смотрит на IP-адрес и понимает, что этот пакет адресован именно ему.
После этого он обрезает IP-адреса, относящиеся к третьему уровню модели OSI, и смотрит на номера портов.
Он видит порт 21, который означает FTP-трафик, видит SYN и поэтому понимает, что кто-то пытается установить с ним связь.
Теперь, в соответствие с тем, что мы узнали о рукопожатии, сервер 30.1.1.10 создает пакет SYN/ACK и отправит его обратно компьютеру 10.1.1.10. Получив данный пакет, устройство 10.1.1.10 создаст ACK, пропустит его через сеть таким же образом, как пакет SYN, и после получения ACK сервером соединение будет установлено.
Одна вещь, которую вы должны знать — все это происходит менее чем за секунду. Это очень и очень быстрый процесс, который я постарался замедлить, чтобы вам было все понятно.
