
netstat -nab показывает порты, программы-владельцы и состояния. Её нужно запускать от имени администратора. Состояние LISTENING означает ожидание подключения, ESTABLISHED означает активный сеанс.Полный текст первых минут лекции «Углублённый урок о TCP и UDP» из видеокурса PracticU – субтитры с временной меткой для каждого абзаца. Так можно прочитать и найти нужные темы ещё до начала обучения.
Здравствуйте, этот урок посвящен транспортному уровню OSI. Тут мы углубимся в TCP и UDP, увидим их внутреннее строение.
Мы увидим, как работает TCP, как создается сэшн, увидим, что такое тройное рукопожатие, сравним TCP и UDP. Рассмотрим overhead, увидим, сколько байтов добавляет TCP и сколько добавляет UDP.
Это углубленная лекция об этих протоколах. Мы воспользуемся учебным пособием компании Cisco. Итак, мы говорим о транспортном уровне. И я вам напоминаю, уровень приложения, то есть наша программа.
Допустим, что-то хочет передать по сети. Например, какой ход я сделал в компьютерной игре в шахматы. Или электронное письмо, или файл через FTP.
В общем, приложение что-то отправляет другому приложению, которое на другом компьютере. И этот запрос, передать что-то туда, приложение дает операционной системе.
Точнее, транспортному уровню. Транспортный уровень – это такая программа внутри операционной системы. Это просто программа, которая делает четыре главные вещи.
У этой программы четыре задачи. Первое – транспортный уровень ведет слежение за сетевой жизнью определенной программы. То есть, когда приходит пакет, в котором ответ этой программе, транспортный уровень знает, что передать этот ответ нужно именно этой программе.
И мы далее увидим, как именно это происходит. Кстати, помните, это происходит с помощью номеров портов. Итак, транспортный уровень отвечает за то, чтобы каждая программа получила свои пакеты, которые для неё предназначены.
И для этого в пакетах указываются номера портов. Следующая обязанность транспортного уровня — это segmenting data.
То есть это разделение на кусочки информации, которую нужно передать. Дело в том, что приложение просто говорит, что нужно передать какой-то большой объём информации, допустим.
Приложение просто даёт транспортному уровню Всю эту информацию целиком. Просто какой-то ряд информации, который может быть очень большим.
Но передача по кабелю так не работает. Нельзя отправить более 1500 байт за раз. Таково ограничение согласно стандарту Ethernet, стандартного обычного сетевого нашего кабеля.
Так вот, именно транспортный уровень делит всю информацию на сегменты, на порции. И если выбран протокол TCP, то транспортный уровень нумерует эти сегменты, убеждается, что они получены на втором конце, а иначе посылает их вновь, а если выбран UDP, то просто делит на порции и ничего не нумерует, не проверяет, не
посылает вновь. То есть транспортный уровень занимается этими самыми порциями, делением информации, которую нужно отправить на порции и всё остальное, если нужно.
Всё, что нужно сделать с этими порциями, если выбран TCP. То есть транспортный уровень — это такая программа, это кусок программы в операционной системе, которая всё это делает.
А на стороне получателя транспортный уровень собирает кусочки вновь в целый ряд. Иногда они приходят не в том порядке, в котором были отосланы.
Потому что, допустим, была пробка в каком-нибудь раутере в Германии, и следующий пакет пошел через Францию, не стал стоять в пробке, и обогнал пакет, который пошел через Германию.
Хотя и вышел позже первого пакета, но пришел раньше первого пакета. И программа-получатель получила середину какой-то информации прежде, чем начало этой информации.
И для того, чтобы уровень приложения получил всю информацию правильно, вновь объединенную из всех пакетов, в правильном порядке, так вот для этого четвёртый уровень, транспортный уровень, должен её правильно собрать.
И ещё одна роль транспортного уровня — это удостоверять программы с помощью как раз номеров портов, которые получают программы. И тут написаны ещё всякие вещи менее важные.
Итак, такова роль транспортного уровня: Получить информацию от приложения, разделить на порции, пронумеровать их, если нужно, и, если нужно, проверить их доставку получателю.
Что я имею в виду под «если нужно» — это значит, что выбран TCP. TCP получает, делит на кусочки, нумерует их и проверяет, а UDP получает, делит на кусочки и отправляет, ничего не проверяя.
Далее, благодаря транспортному уровню возможен приход пакетов на один и тот же компьютер от разных программ и пакеты с электронной почты, и пакеты с видео, и пакеты для веб-браузера, и для мессенджера.
И все это может поступать приложением компьютера одновременно. Если же у нас не было бы транспортного уровня, мы могли бы в одно и то же время обеспечивать связью только одно приложение, а другие приложения получили бы отказ.
Извините, связь занята. Но транспортный уровень обеспечивает связью все программы одновременно. Вот как тут схематично изображено на рисунке.
Пакет каждого цвета транспортный уровень передает соответствующему приложению. Разумеется, вместо цветов в жизни используются номера портов.
Порт – это порядковый номер программы. В пакете указано, к какому порту нужно его доставить. Каждая программа, которой нужна связь, получает номер порта.
Всего портов или программ, нуждающихся в связи, может быть 65 536, то есть 2 в 16 степени. Далее сравним TCP и UDP. два протокола, которые находятся на транспортном уровне.
У этих протоколов разное назначение. У TCP надежная передача информации, то есть пакеты пронумерованы, и происходит ожидание подтверждения их доставки.
И если TCP не дожидается такого подтверждения, то он отправляет вновь. А если долго не получается подтверждение, то TCP решает, что тот компьютер выключен и говорит, что нет связи, что пора отчаяться связаться с ним.
А если же TCP говорит, что все было доставлено, то это значит, что наверняка все доставлено. С помощью TCP работают SMTP и HTTP, веб-странички тоже.
Когда мы работаем с TCP, у нас либо все дошло, либо ничего не дошло. Мы не попадаем в такое положение, когда пришла часть. Вот, например, мне выдалось сообщение, что какого-то компьютера нету.
До этого я пытался связаться с несуществующим компьютером. А UDP гораздо быстрее, потому что он не ждет никаких подтверждений о получении.
Просто отправляет пакеты и все. И у него маленький оверхед. Малослужебной информации в нагрузку к самой информации, которую нужно переправить.
Например, не нужно нумеровать пакеты. Всякую такую информацию нужно указывать на посылке, что занимает место в самом пакете. UDP не требует подтверждений о доставке.
Если кто-то не получил, ничего, продолжаем. Если какая-то информация утеряна по пути, вторая страна даже не узнает о том, что эта информация была вообще отослана.
И лишь информация поступает, UDP сразу же передает ее программе. Все это идеально для телефонии, для беседы по проводам в голос, для передачи видео, для того, чтобы кто-то просматривал это на экране.
UDP лучше, когда информация поступает в прямом эфире, в реальном времени. То есть в тех случаях, когда запоздавшая информация уже не имеет особого смысла. Как, например, в телефонной беседе.
Если вдруг беседа прервалась бы для того, чтобы послушать запоздалое слово, которое было отправлено 10 секунд назад, то из такой беседы ничего бы хорошего не вышло.
Нет же, во время беседы по телефону люди сами восстанавливают потерянную информацию, прекрасно обходясь в этом без помощи компьютера.
Вот для таких вот вещей хорош UDP, а TCP нужен, когда информация должна быть доставлена строго, надёжно. А вот тут мы видим, сколько нагрузки, сколько служебной информации должно быть передано, когда используется TCP и когда используется UDP.
Вот смотрите, тут на рисунке обозначена информация, который хочет передать уровень приложения. Это сама информация, которой хочет обменяться аппликация.
Но смотрите, используя TCP, приходится добавлять 20 байт служебной информации в каждый пакет. А пакет может иметь размер до 1500 байтов. Точнее, до 1400.
Но 20 байт из этого съедаются служебной информации в дополнение к той, которую хочет передать аппликация, что увеличивает нагрузку на проходимой сети, в отличие от UDP, где лишь 8 байт служебной информации.
Дополнительная нагрузка на сеть происходит не лишь за счёт оверхеда, но ещё и за счёт тройного рукопожатия, которое мы вскоре рассмотрим. Начало TCP требует 3 пакета заранее и дополнительных 20 байт на каждый отсылаемый пакет, в отличие от UDP, где это лишь 8 байт.
И эта разница очень важна, ведь пакетов всего проходит очень и очень много. Каждая программа получает порт, который становится ее удостоверяющим номером с точки зрения связи.
Если хотите, ее адресом с точки зрения связи. Ее адресом внутри компьютера. О портах, выданных нашим программам, нам расскажет команда netstat.
У команды netstat есть ряд свитчей, с помощью которых мы задаем, в каком виде мы хотим видеть отчет. "-n", означает, что там, где в отчете представлены адреса IP, их не нужно переводить в имена тех серверов.
потому что для этого netstat делает reverse lookup в DNS, что занимает много времени. Далее A означает "покажи все порты", включая те, которые прослушиваются.
А B означает "покажи также имена экзешников программ, которые взяли себе тот или иной порт". Я запускаю команду, но я забыл стать администратором, а её выполнение требует администраторских прав.
Нужно запустить CMD от лица администратора, и тогда получится выполнить netstat. Я жму run as administrator, Получаю CMD с силой администратора.
И теперь я всемогущ, могу даже увидеть, какие программы заняли какие порты. И смотрите, к примеру, в TCP порт 80 находится у меня в положении прослушивания, listening.
То есть он ждет, что на него позвонят. И что за программа его заняла? Skype. Skype зачем-то взял и занял для себя 80-й порт, что однажды создало мне большое затруднение.
Программисты, которые делали веб-сайт, установили IIS на своем компьютере, чтобы делать сайт. И вдруг этот сайт не работал, потому что IIS берет себе порт 80, но Skype его уже занял.
И я тогда долго морочился и выяснял, почему его веб-сайт не работает. До тех пор, пока не выполнил Netstat и не увидел, что Skype занял 80-й порт, я просто не верил глазам.
Какая наглость! И еще мы тут видим, что Skype занял 443-й, а еще, например, 445-й это служба шейеров. То есть это собственная операционная система.
Вот я тут вижу, что и Dropbox тоже занял себе порт. Впрочем, давайте взглянем на отчет этой команды без B, чтобы было поменее загромождено.
Обратите внимание на порты, которые прослушиваются. Если какой-то хакер хочет атаковать мой компьютер, то он должен подключиться к этим портам, которые listening.
Если вы хотите присоединиться к порту, который не listening, то это все равно, что стучаться в стену. Там никто не ответит, там нет программы, которая разговаривает через этот порт.
А порты, которые в данный момент находятся в положении Established, это порты, через которые сейчас ведётся подключение. Мой компьютер говорит с серверами, которые в интернете.
К примеру, давайте увидим, как этот список увеличится. Выполним ping к какому-нибудь серверу, с которым я ещё не разговариваю. Например, Wynet.
В данный момент у меня нет беседы с сайтом Wynet. С помощью команды ping я хочу узнать его IP, чтобы потом этот IP найти в списке подключений.
IP я узнал, и теперь я зайду на сам сайт. Вы можете видеть, что позади окна CMD я зашел на сайт Ynet. Запомните этот IP, IP Ynet. И теперь мы его найдем в отчете команды netstat.
Мы его найдем не глазами, а более умным способом. С помощью команды findstring. Это экзешник, который идет в комплекте с Windows.
Он лежит в C Windows System 32 и находит строчку с указанной последовательностью символов. Вот, смотрите, я вам покажу, что эта программа действительно существует и лежит в Windows.
dir-disc-c-windows-system32, system32, и тут есть программа по имени findstr.exe. И в качестве ввода нужно ей дать какой-то блок символов, и она выдает из этого блока те строчки, в которых есть указанная вами последовательность символов.
И я хочу строчку, в которой есть IP Ynet. И смотрите, только для беседы с Ynet я использую столько портов. Видите, сколько портов используется? Зачем так много?
А каждый баннер, каждая реклама Являет собой отдельное местоположение в интернете И ведет в отдельное место И создается отдельная беседа с тем местом То есть сервер wine это посылает мне линки в другие места Как правило это идет от баннеров реклам И мой веб-браузер открывает сэшн с каждым из этих мест
Чтобы вдохнуть жизнь во все эти ссылки Давайте рассмотрим эти созданные беседы Протокол TCP От лица какого IP я связываюсь И от какого порта я связываюсь С каким IP я связываюсь?
И с каким портом я связываюсь? И номер сессии. Когда Wynet отправляет мне ответы на мои запросы, то известно, куда именно их передавать.
В какую именно часть окна в веб-браузере. Благодаря тому, что указан IP-адрес и порт отправителя. И, кстати, при каждом запуске веб-браузера порты, которые используются для отправки мне ответа с сервера, будут уже другие.
Я наоткрывал много окон веб-браузера, И можно увидеть, что старые порты начали закрываться, и открываться начали новые. Вот-вот старые закроются, и откроются новые.
Вы заметили, что открывается все больше и больше сэшенов. Это сэшены с Wynet, которые я открыл много раз. Если мы подождем довольно времени, то вы увидите, что сэшен с Wynet начал закрываться.
Управляющий веб-сайтом указывает, сколько времени неактивная беседа все еще остается открытой. Не пугайтесь, вот-вот как следует мы увидим, что такое сэшен.
А сейчас я, по сути, говорю о портах. И порты разделены на три группы. Номера от 0 до 1024 называются хорошо известными портами. Они всегда закреплены за определенными серверскими приложениями.
Это стандарт. Например, порт 25 — это SMTP. Почтовый сервер ждет за портом 25 того, что вы начнете с ним беседу по отсылке письма.
Если бы не было таких стандартных номеров портов, то вам пришлось бы позвонить администрации сервера и сказать, я хочу отправить письмо.
какой порт у вас сейчас прослушивает, где принимают письма. Но благо не нужно никому звонить и узнавать сегодняшним утром, с каким портом они работают, потому что всегда известно, что 80-й порт — это, например, беседа на языке HTTP.
Таким образом известно, как обращаться к самым основным приложениям. Но что по поводу не самых основных? Если я напишу собственную программу, тогда я могу зарегистрировать за собой один из портов от номера 1024 до 49 тысяч.
Мы видим, что разные известные компании уже застолбили за собой некоторые порты. Если я напишу программу, которая прослушивает тот же самый порт, то случится неприятность.
Два приложения, которые работают на одном и том же компьютере и ждут связи через один и тот же порт, такого быть не может, они не будут работать вместе.
Поэтому, если какая-то компания создает какой-то программный продукт, в котором клиентская программа подключается к серверской программе, то получается, что в некотором смысле нужно согласовать это со всем остальным миром, чтобы разные программы были совместимы друг с другом.
Вот для этого и служит вторая группа портов, зарегистрированные порты. Кстати, смотрите, когда я инициирую связь, я могу у себя начать ее с любого порта.
Моя программа-инициатор может занять любой порт, и сервер будет знать, куда мне отправить ответ. Ведь я указываю порт отправителя. Когда я отправляю пакеты Ynet, он видит, что я танцую от порта 4604.
То есть нет никаких затруднений в связи с тем, куда направить ответ. Сложное место — это куда начать контакт, отправляя первый пакет, откуда я знаю, что у Ynet прослушивает порт 80.
То есть когда я пишу серверское приложение, которое сидит всегда в режиме листенинг, то все клиентские приложения должны знать, куда им изначально обращаться, чтобы они всегда смогли подключаться к моей серверской программе.
Именно тут то сложное место, которое требует заранее зарегистрированных или стандартных