Установление TCP соединения. Как работает TCP

Установка TCP-соединения

В протоколе TCP-соединения устанавливаются с помощью «тройного рукопожатия», описанного в разделе «Установка соединения». Чтобы установить соединение, одна сторона (например, сервер) пассивно ожидает входящего соединения, выполняя примитивы LISTEN и ACCEPT, либо указывая конкретный источник, либо не указывая его.

Другая сторона (например, клиент) выполняет примитив CONNECT, указывая IP-адрес и порт, с которым он хочет установить соединение, максимальный размер TCP-сегмента и, по желанию, некоторые данные пользователя (например, пароль). Примитив CONNECT посылает TCP-сегмент с установленным битом SYN и сброшенным битом АСК и ждет ответа.

Когда этот сегмент прибывает в пункт назначения, TCP-сущность проверяет, выполнил ли какой-нибудь процесс примитив LISTEN, указав в качестве параметра тот же порт, который содержится в поле Порт получателя. Если такого процесса нет, она отвечает отправкой сегмента с установленным битом RST для отказа от соединения.

Если какой-либо процесс прослушивает какой-либо порт, то входящий ТСР-сегмент передается этому процессу. Последний может принять соединение или отказаться от него. Если процесс принимает соединение, он отсылает в ответ подтверждение. Последовательность TCP-сегментов, посылаемых в нормальном случае, (рис. а) Обратите внимание на то, что сегмент с установленным битом SYN занимает 1 байт пространства порядковых номеров, что позволяет избежать неоднозначности в их подтверждениях.

Если два хоста одновременно попытаются установить соединение друг с другом, то последовательность происходящих при этом событий будет соответствовать рис. б. В результате будет установлено только одно соединение, а не два, так как пара конечных точек однозначно определяет соединение. То есть если оба соединения пытаются идентифицировать себя с помощью пары (х, у), делается всего одна табличная запись для (х, у).

Начальное значение порядкового номера соединения не равно нулю по обсуждавшимся выше причинам. Используется схема, основанная на таймере, изменяющем свое состояние каждые 4 мкс. Для большей надежности хосту после сбоя запрещается перезагружаться ранее чем по прошествии максимального времени жизни пакета. Это позволяет гарантировать, что ни один пакет от прежних соединений не бродит где-нибудь в Интернете.

Разрыв соединения TCP

Хотя TCP-соединения являются полнодуплексными, чтобы понять, как происходит их разъединение, лучше считать их парами симплексных соединений. Каждое симплексное соединение разрывается независимо от своего напарника. Чтобы разорвать соединение, любая из сторон может послать TCP-сегмент с установленным в единицу битом FIN, что означает, что у него больше нет данных для передачи. Когда этот TCP-сегмент получает подтверждение, это направление передачи закрывается. Тем не менее, данные могут продолжать передаваться неопределенно долго в противоположном направлении. Соединение разрывается, когда оба направления закрываются. Обычно для разрыва соединения требуются четыре TCP-сегмента: по одному с битом FIN и по одному с битом АСК в каждом направлении. Первый бит АСК и второй бит FIN могут также содержаться в одном ТСР-сегменте, что уменьшит количество сегментов до трех.

Как при телефонном разговоре, когда оба участника могут одновременно попрощаться и повесить трубки, оба конца TCP-соединения могут послать FIN-cerменты в одно и то же время. Они оба получают обычные подтверждения, и соединение закрывается. По сути, между одновременным и последовательным разъединениями нет никакой разницы.

Чтобы избежать проблемы двух армий, используются таймеры. Если ответ на посланный FIN-сегмент не приходит в течение двух максимальных интервалов времени жизни пакета, отправитель разрывает соединение. Другая сторона в конце концов заметит, что ей никто не отвечает, и также разорвет соединение. Хотя такое решение и не идеально, но, учитывая недостижимость идеала, приходится пользоваться тем, что есть. На практике проблемы возникают довольно редко.

Управление передачей в TCP

Как уже было сказано ранее, управление окном в TCP не привязано напрямую к подтверждениям, как это сделано в большинстве протоколов передачи данных. Например, предположим, что у получателя есть 4096-байтовый буфер. Если отправитель передает 2048-байтовый сегмент, который успешно принимается получателем, то получатель подтверждает его получение. Однако при этом у получателя остается всего лишь 2048 байт свободного буферного пространства (пока приложение не заберет сколько-нибудь данных из буфера), о чем он и сообщает отправителю, указывая соответствующий размер окна (2048) и номер следующего ожидаемого байта.

После этого отправитель посылает еще 2048 байт, получение которых подтверждается, но размер окна объявляется равным 0. Отправитель должен прекратить передачу до тех пор, пока получающий хост не освободит место в буфере и не увеличит размер окна.

При нулевом размере окна отправитель не может посылать сегменты, за исключением двух случаев. Во-первых, разрешается посылать срочные данные, например, чтобы пользователь мог уничтожить процесс, выполняющийся на удаленной машине. Во-вторых, отправитель может послать 1-байтовый сегмент, прося получателя повторить информацию о размере окна и ожидаемом следующем байте. Стандарт TCP явно предусматривает эту возможность для предотвращения тупиковых ситуаций в случае потери объявления о размере окна.

Отправители не обязаны передавать данные сразу, как только они приходят от приложения. Также никто не требует от получателей посылать подтвержде­ния как можно скорее. Например TCP-сущность, получив от прило­жения первые 2 Кбайт данных и зная, что доступный размер окна равен 4 Кбайт, была бы совершенно права, если бы просто сохранила полученные данные в буфере до тех пор, пока не прибудут еще 2 Кбайт данных, чтобы передать сразу сегмент с 4 Кбайт полезной нагрузки. Эта свобода действий может использоваться для улучшения производительности.

Рассмотрим TELNET-соединение с интерактивным редактором, реагирующим на каждое нажатие клавиши. В худшем случае, когда символ прибывает к передающей TCP-сущности, она создает 21-байтовый TCP-сегмент и передает его IP-уровню, который, в свою очередь, посылает 41-байтовую IP-дейтаграмму.

На принимающей стороне TCP-сущность немедленно отвечает 40-байтовым подтверждением (20 байт TCP-заголовка и 20 байт IP-заголовка). Затем, когда редактор прочитает этот байт из буфера, TCP-сущность пошлет обновленную информацию о размере буфера, передвинув окно на 1 байт вправо. Размер этого пакета также составляет 40 байт. Наконец, когда редактор обработает этот символ, он отправляет обратно эхо, передаваемое 41-байтовым пакетом. Итого для каждого введенного с клавиатуры символа пересылается четыре пакета общим размером 162 байта. В условиях дефицита пропускной способности линий этот метод работы нежелателен.

Для улучшения ситуации многие реализации TCP используют задержку подтверждений и обновлений размера окна на 500 мс в надежде получить дополни­тельные данные, вместе с которыми можно будет отправить подтверждение од­ним пакетом. Если редактор успеет выдать эхо в течение 500 мс, удаленному пользователю нужно будет выслать только один 41-байтовый пакет, таким образом, нагрузка на сеть снизится вдвое.

Хотя такой метод задержки и снижает нагрузку на сеть, тем не менее, эффективность использования сети отправителем продолжает оставаться невысокой, так как каждый байт пересылается в отдельном 41-байтовом пакете. Метод, позволяющий повысить эффективность, известен как алгоритм Нагля (Nagle, 1984). Предложение Нагля звучит довольно просто: если данные поступают отправителю по одному байту, отправитель просто передает первый байт, а остальные помещает в буфер, пока не будет получено подтверждение приема первого байта. После этого можно переслать все накопленные в буфере символы в виде одного TCP-сегмента и снова начать буферизацию до получения подтверждения отосланных символов. Если пользователь вводит символы быстро, а сеть медленная, то в каждом сегменте будет передаваться значительное количество символов, таким образом, нагрузка на сеть будет существенно снижена. Кроме того, этот алгоритм позволяет посылать новый пакет, даже если число символов в буфере превышает половину размера окна или максимальный размер сегмента.

Алгоритм Нагля широко применяется различными реализациями протокола TCP, однако иногда бывают ситуации, в которых его лучше отключить. В частности, при работе приложения X-Windows в Интернете информация о перемещениях мыши пересылается на удаленный компьютер. (X-Window - это система управления окнами в большинстве ОС типа UNIX). Если буферизировать эти данные для пакетной пересылки, курсор будет перемещаться рывками с большими паузами, в результате чего пользоваться программой будет очень сложно, почти невозможно.

Еще одна проблема, способная значительно снизить производительность протокола TCP, известна под именем синдрома глупого окна (Clark, 1982). Суть проблемы состоит в том, что данные пересылаются TCP-сущностью крупными блоками, но принимающая сторона интерактивного приложения считывает их посимвольно.

Рассмотрим на примере - начальное состояние таково: TCP-буфер приемной стороны полон, и отправителю это известно (то есть размер его окна равен 0). Затем интерактивное приложение читает один символ из TCP-потока. Принимающая TCP-сущность радостно сообщает отправителю, что размер окна увеличился, и что он теперь может послать 1 байт. Отправитель повинуется и посылает 1 байт. Буфер снова оказывается полон, о чем получатель и извещает, посылая подтверждение для 1-байтового сегмента с нулевым размером окна. И так может продолжаться вечно.

Дэвид Кларк (David Clark) предложил запретить принимающей стороне отправлять информацию об однобайтовом размере окна. Вместо этого получатель должен подождать, пока в буфере не накопится значительное количество сво­бодного места. В частности, получатель не должен отправлять сведения о новом размере окна до тех пор, пока он не сможет принять сегмент максимального размера, который он объявлял при установке соединения, или его буфер не освободился хотя бы наполовину.

Кроме того, увеличению эффективности отправки может способствовать сам отправитель, отказываясь от отправки слишком маленьких сегментов. Вместо этого он должен подождать, пока размер окна не станет достаточно большим для того, чтобы можно было послать полный сегмент или, по меньшей мере, равный половине размера буфера получателя. (Отправитель может оценить этот размер по последовательности сообщений о размере окна, полученных им ранее.)

В задаче избавления от синдрома глупого окна алгоритм Нагля и решение Кларка дополняют друг друга. Нагль пытался решить проблему приложения, предоставляющего данные TCP-сущности посимвольно. Кларк старался разрешить проблему приложения, посимвольно получающего данные у TCP. Оба решения хороши и могут работать одновременно. Суть их состоит в том, чтобы не посылать и не просить передавать данные слишком малыми порциями.

Принимающая TCP-сущность может пойти еще дальше в деле повышения производительности, просто обновляя информацию о размере окна большими порциями. Как и отправляющая TCP-сущность, она также может буферизировать данные и блокировать запрос на чтение READ, поступающий от приложения, до тех пор, пока у нее не накопится большого объема данных. Таким образом, снижается количество обращений к TCP-сущности и, следовательно, снижаются накладные расходы. Конечно, такой подход увеличивает время ожидания ответа, но для неинтерактивных приложений, например при передаче файла, сокращение времени, затраченного на всю операцию, значительно важнее увеличения времени ожидания ответа на отдельные запросы.

Еще одна проблема получателя состоит в сегментах, полученных в неправильном порядке. Они могут храниться или отвергаться по усмотрению получателя. Разумеется, подтверждение может быть выслано, только если все данные вплоть до подтверждаемого байта получены. Если до получателя доходят сегменты О, 1, 2, 4, 5, 6 и 7, он может подтвердить получение данных вплоть до последнего байта сегмента 2. Когда у отправителя истечет время ожидания, он передаст сегмент 3 еще раз. Если к моменту прибытия сегмента 3 получатель сохранит в буфере сегменты с 4-го по 7-й, он сможет подтвердить получение всех байтов, вплоть до последнего байта сегмента 7.

- 1

Когда два хоста осуществляют коммуникацию посредством TCP, соединение установливается прежде, чем может начаться обмен данными. После того, как коммуникация закончена, сессии закрываются, а соединение завершается. Механизмы соединения и сессий делают возможной функцию надежности TCP.

Смотрите рисунок, чтобы проследить шаги создания и завершения TCP соединения.

Хост отслеживает каждый сегмент данных в пределах сессии и обменивается информацией о том, какие данные получены каждым узлом, используя информацию в заголовке TCP .

Каждое соединение включает односторонние коммуникационные потоки, или сессии, чтобы установить и закончить TCP процесс между конечными устройствами. Чтобы установить соединение, хосты выполняют трехэтапное квитирование . Контрольные биты в заголовке TCP указывают на прогресс и состояние соединения. Трехэтапное квитирование:

• Устанавливает, что устройство назначения присутствует в сети
• Проверяет, что устройство назначения имеет активную службу и принимает запросы на номер порта назначения, который намеревается использовать клиент для сессии
• Сообщает устройству назначения, что клиент источника намеревается установить коммуникационную сессию на этот номер порта

В TCP соединениях, хост, выступающий в роли клиента, начинает сеанс с сервером. Чтобы понять, как работает трехэтапное квитирование, используемое процессе TCP соединения, следует рассмотреть различные значения, которыми обмениваются оба узла. Три шага в создании TCP соединения - это:

1. Клиент-инициатор посылает сегмент, содержащий начальный номер последовательности, который служит запросом к серверу, чтобы начать коммуникационную сессию.

2. Сервер отвечает сегментом, содержащим значение подтверждения, равное полученному номеру последовательности плюс 1, а также свое собственное значение последовательности синхронизации. Это значение на единицу больше чем номер последовательности, потому что ACK (подтверждение) всегда является следующим ожидаемым Байтом или Октетом. Это значение подтверждения позволяет клиенту привязать ответ обратно к исходному сегменту, который посылается на сервер.

3. Клиент-инициатор отвечает значением подтверждения, равным номеру последовательности, который он получил, плюс один. Это шаг завершает процесс установления соединения.

Внутри заголовка сегмента TCP есть шесть 1-битовых полей, которые содержат контрольную информацию, используемую, чтобы управлять процессами TCP. Это поля:

URG - Поле "Указатель важности" задействовано

ACK - Поле "Номер подтверждение" задействовано

PSH - Функция Push (протолкнуть данные, накопившиеся в буфере, в приложение пользователя)

RST - Сброс соединения

FIN - Больше нет данных от отправителя, завершение соединения

Эти поля называют флагами, поскольку каждое из этих полей занимает только один бит и поэтому может принимать только два значения: 1 или 0. Когда значение бита установлено в 1, оно указывает на то, какая контрольная информация в сегменте.

Завершение TCP соединения происходит в четыре шага, в результате обмена соответствующими значениями этих флагов.

Доброго времени суток, дорогие читатели.
По многочисленным просьбам сегодня я публикую для Вас статью, которая познакомит Вас с основами основ терминов компьютерной сети, а именно:

• Сетевые протоколы - что это за страшные названия и с чем их едят
• UDP, TCP, ICMP , - что, зачем и в чем разница
• IP -адрес, - у всех есть, но не все знают нафига эта штука:-)
• Маска адреса (подсеть)
• Шлюз (gateway)
• Несколько слов о таблицах маршрутизации
• Порты, - что это на самом деле
• MAC -адрес

Примерно так.

Статья, думаю, будет полезна всем от мала до велика, ибо содержит не столько набор странных непонятных действий или слов, сколько блок доступным языком изложенной информации, которая, как минимум, даст Вам понимание как вообще это всё работает и зачем это нужно. Поехали.

Сетевые протоколы TCP/IP, NWLink IPX/SPX, NetBEUI

Давайте начнем с того, что вообще такое сетевой протокол и с чем его едят.
Сетевой протокол - это набор программно реализованных правил общения между компьютерами. Этакий язык, на котором компьютеры разговаривают друг с другом и передают информацию. Ранее компьютеры были, так сказать, многоязычны и в старых версиях Windows использовался целый набор протоколов, - TCP/IP, NWLink IPX/SPX, NetBEUI . Ныне же пришли к общей договоренности, и стандартом стало использование исключительно протокола TCP/IP , а посему речь далее пойдет именно о нем.

Когда говорят о TCP/IP , то обычно подразумевают под этим именем множество различных.. правил или, скажем, стандартов, которые прописаны с использованием (или под использование) этого протокола. Так, например, есть правила, по которым осуществляется обмен сообщениями между почтовыми серверами и есть правила, по которым конечный пользователь получает в свой ящик письма. Имеются правила для проведения видео-конференций и правила для организации "телефонных" переговоров по Интернету. Фактически, это даже не то чтобы правила.. Скорее этакая грамматика, что ли. Ну знаете, в английском одна структура построения диалогов, в французском другая.. Вот и в TCP/IP нечто подобное, т.е. некая связка различных грамматических правил представляет собой как раз цельный протокол TCP/IP или, точнее говоря, стек протоколов TCP/IP .

Сетевые протоколы UDP, TCP, ICMP

В рамках протокола TCP/IP для передачи данных используются протоколы - TCP и UDP . Многие наверняка слышали, что есть порты как TCP , так и UDP , но не все знают в чем разница и что это вообще. И так..

Передача данных по протоколу TCP (Transmission Control Protocol - Протокол Управления Передачей) предусматривает наличие подтверждений получения информации. "-Ну, мол, - получил? -Получил!" Если же передающая сторона не получит в установленные сроки необходимого подтверждения, то данные будут переданы повторно. Поэтому протокол TCP относят к протоколам, предусматривающим соединение, а UDP (User Datagram Protocol - Протокол Пользовательских Датаграмм) - нет. UDP применяется в тех случаях, когда не требуется подтверждения приема (например, DNS-запросы или IP-телефония (яркий представитель которой, - Skype)). То есть разница заключается в наличии подтверждения приема. Казалось бы "Всего то!", но на практике это играет важную роль.

Есть еще так же протокол ICMP (Internet Control Message Protocol - межсетевой протокол управляющих сообщений), который используется для передачи данных о параметрах сети. Он включает в себя служебные типы пакетов, таки как ping, distination unreachable, TTL и пр.

Что такое IP-адрес

У всех он есть, но не все имеют представление что за адрес такой и почему вообще без него нельзя. Рассказываю.

IP -адрес - 32 -х битное число, используемое для идентификации компьютера в сети. Адрес принято записывать десятичными значениями каждого октета этого числа с разделением полученных значений точками. Например, 192.168.101.36

IP- адреса уникальны, - это значит, что каждый компьютер имеет свое собственное сочетание цифр, и в сети не может быть двух компьютеров с одинаковыми адресами. IP -адреса распределяются централизованно, интернет-провайдеры делают заявки в национальные центры в соответствии со своими потребностями. Полученные провайдерами диапазоны адресов распределяются дальше между клиентами. Клиенты, в свою очередь, сами могут выступать в роли провайдера и распределять полученные IP -адреса между субклиентами и т.д. При таком способе распределения IP -адресов компьютерная система точно знает "расположение" компьютера, имеющего уникальный IP -адрес; - ей достаточно переслать данные в сеть "владельца", а провайдер в свою очередь проанализирует пункт назначения и, зная, кому отдана эта часть адресов, отправит информацию следующему владельцу поддиапазона IP -адресов, пока данные не поступят на компьютер назначения.

Для построения же локальных сетей выделены спец.диапазоны адресов. Это адреса 10.x.x.x , 192.168.x.x , 10.x.x.x , c 172.16.x.x по 172.31.x.x , 169.254.x.x , где под x - имеется ввиду любое число это от 0 до 254 . Пакеты, передаваемые с указанных адресов, не маршрутизируется, иными словами, попросту не пересылаются через Интернет, а поэтому в различных локальных сетях компьютеры могут иметь совпадающие адреса из указанных диапазонов. Т.е., в компании ООО "Рога и копыта " и ООО "Вася и компания " могут находится два компьютера с адресами 192.168.0.244 , но не могут, скажем, с адресами 85.144.213.122 , полученными от провайдера интернета, т.к. в интернете не может быть два одинаковых IP -адреса. Для пересылки информации с таких компьютеров в Интернет и обратно используются спец.программы и устройства, которые заменяют локальные адреса реальными при работе с интернетом. Иными словами, данные в Сеть пересылаются с реального IP -адреса, а не с локального. Этот процесс происходит не заметно для пользователя и называется трансляцией адресов. Хочется так же упомянуть, что в рамках одной сети, скажем, компании, ООО "Рога и копыта ", не может быть два компьютера с одним локальным IP-адресом, т.е., в указанном выше примере имелось ввиду, что один компьютер с адресом 192.168.0.244 в одной компании, второй с таким же адресом - в другой. В одной же компании два компьютера с адресом 192.168.0.244 попросту не уживутся.

Вы наверняка слышали такие термины как внешний IP и внутренний IP , постоянный (статический IP) и переменный (динамический) IP . В двух словах о них:

• внешний IP - это как раз тот самый IP , который выдает Вам провайдер, т.е. Ваш уникальный адрес в интернете, например, - 85.144.24.122
• внутренний IP , - это локальный IP , т.е. Ваш IP в локальной сети, например, - 192.168.1.3
• статический IP - это IP , который не меняется с каждым подключением, т.е. закреплен за Вами твердо и навсегда
• динамический IP , - это плавающий IP -адрес, который меняется с каждым подключением

Тип Вашего IP (статический или динамический) зависит от настроек провайдера.

Что такое маска адреса (подсеть)

Понятие подсети введено, чтобы можно было выделить часть IP -адресов одной организации, часть другой и тд. Подсеть представляет собой диапазон IP-адресов, которые считаются принадлежащими одной локальной сети. При работе в локальной сети информация пересылается непосредственно получателю. Если данные предназначены компьютеры с IP-адресом, не принадлежащим локальной сети, то к ним применяются специальные правила для вычисления маршрута для пересылки из одной сети в другую.

Маска - это параметр, который сообщает программному обеспечению о том, сколько компьютеров объединено в данную группу (подсеть). Маска адреса имеет такую же структуру как и сам IP-адрес: это набор из четырех групп чисел, каждое из которых может быть в диапазоне от 0 до 255 . При этом, чем меньше значение маски, тем больше компьютеров объединено в данную подсеть. Для сетей небольших компаний маска обычно имеет вид 255.255.255.x (например, 255.255.255.224). Маска сети присваивается компьютеру одновременно с IP-адресом. Так, например, сеть 192.168.0.0 с маской 255.255.255.0 может содержать в себе компьютеры с адресами от 192.168.0.1 до 192.168.254 192.168.0.0 с маской 255.255.255.128 допускает адреса от 192.168.0.1 до 192.168.0.127 . Думаю, смысл понятен. Как правило сети с небольшим возможным числом компьютеров используются провайдерами с целью экономии IP-адресов. Например, клиенту, может быть назначен адрес с маской 255.255.255.252 . Такая подсеть содержит в себе только два компьютера.

После того как компьютер получил IP-адрес и ему стало известно значение маски подсети, программа может начать работу в данной локальной подсети. Однако же, чтобы обмениваться информацией с другими компьютерами в глобальной сети, необходимо знать правила, куда пересылать информацию для внешней сети. Для этого служит такая характеристика как адрес шлюза (Gateway).

Что такое Шлюз (Gateway)

Шлюз - это устройство (компьютер или маршрутизатор), которое обеспечивает пересылку информации между различными IP-подсетями. Если программа определяет (по IP и маске), что адрес назначения не входит в состав локальной подсети, то она отправляет эти данные на устройство, выполняющее функции шлюза. В настройках протокола указывают IP-адрес такого устройства.

Хотите знать и уметь, больше и сами?

Мы предлагаем Вам обучение по направлениям: компьютеры, программы, администрирование, сервера, сети, сайтостроение, SEO и другое. Узнайте подробности сейчас!

Для работы только в локальной сети шлюз может не указываться.

Для индивидуальных пользователей, подключающихся к Интернету, или для небольших предприятий, имеющих единственный канал подключения, в системе должен быть только один адрес шлюза, - это адрес того устройства, которое имеет подключение к Интернету. При наличии нескольких маршрутов будет существовать несколько шлюзов. В этом случае для определения пути передачи данных используется таблица маршрутизации.

Что такое таблицы маршрутизации

И вот мы плавно добрались и до них. И так.. Что же за таблицы такие.

Организация или пользователь может иметь несколько точек подключения к Интернету (например, резервные каналы на случай, если у первого провайдера что-то выйдет из строя, а интернет таки очень нужен) или содержать в своей структуре несколько IP -сетей. В этом случае, чтобы система знала каким путем (через какой шлюз) посылать ту или иную информацию, используются таблицы маршрутизации. В таблицах маршрутизации для каждого шлюза указываются те подсети Интернета, для которых через них должна передаваться информация. При этом для нескольких шлюзов можно задать одинаковые диапазоны, но с разной стоимостью передачи данных: например, информация, будет пересылаться по каналу, имеющему самую низкую стоимость, а в случае выхода его из строя по тем или иным причинам, автоматически будет использоваться следующее доступное наиболее дешевое соединение.

Что такое сетевые порты

При передаче данных кроме IP -адресов отправителя и получателя пакет информации содержит в себе номера портов. Пример: 192.168.1.1:80 , - в данном случае 80 - это номер порта. Порт - это некое число, которое используется при приеме и передаче данных для идентификации процесса (программы), который должен обработать данные. Так, если пакет послан на 80 -й порт, то это свидетельствует, что информация предназначена серверу HTTP .

Номера портов с 1 -го до 1023 -й закреплены за конкретными программами (так называемые well-known-порты). Порты с номерами 1024 -65 535 могут быть использованы в программах собственной разработки. При этом возможные конфликты должны решаться самими программами путем выбора свободного порта. Иными словами, порты будут распределяться динамически: возможно, что при следующем старте программа выберет иное значение порта, если, конечно, Вы вручную через настройки не задавали ей порт.

Что есть MAC-адрес

Дело в том, что пересылаемые пакеты в сети адресуются компьютерам не по их именам и не на IP -адрес. Пакет предназначается устройству с конкретным адресом, который и называется MAC -адресом.

MAC-адрес - это уникальный адрес сетевого устройства, который заложен в него изготовителем оборудования, т.е. это этакий проштампованный номер Вашей сетевой карты. Первая половина MAC -адрес представляет собой идентификатор изготовителя, вторая - уникальный номер данного устройства.

Как правило MAC -адрес бывает требуется для идентификации, скажем, у провайдера (если провайдер использует привязку по мак-адресу вместо логина-пароля) или при настройке маршрутизатора.

Где посмотреть все сетевые настройки

Чуть не забыл сказать пару слов о том где можно поглядеть и поменять всё это.

Всем привет сегодня расскажу чем отличается протокол TCP от UDP. Протоколы транспортного уровня, следующие в иерархии за IP, используются для передачи данных между прикладными процессами, реализующимися в сетевых узлах. Пакет данных, поступивший от одного компьютера другому через Интернет, должен быть передан процессу-обработчику, и именно по конкретному назначению. Транспортный уровень принимает на себя ответственность за это. На этом уровне два основных протокола – TCP и UDP.

Что означают TCP и UDP

TCP – транспортный протокол передачи данных в сетях TCP/IP, предварительно устанавливающий соединение с сетью.

UDP – транспортный протокол, передающий сообщения-датаграммы без необходимости установки соединения в IP-сети.

Напоминаю, что оба протокола работают на транспортном уровне модели OSI или TCP/IP, и понимание того чем они отличаются очень важно.

Разница между протоколами TCP и UDP

Разница между протоколами TCP и UDP – в так называемой “гарантии доставки”. TCP требует отклика от клиента, которому доставлен пакет данных, подтверждения доставки, и для этого ему необходимо установленное заранее соединение. Также протокол TCP считается надежным, тогда как UDP получил даже именование “протокол ненадежных датаграмм. TCP исключает потери данных, дублирование и перемешивание пакетов, задержки. UDP все это допускает, и соединение для работы ему не требуется. Процессы, которым данные передаются по UDP, должны обходиться полученным, даже и с потерями. TCP контролирует загруженность соединения, UDP не контролирует ничего, кроме целостности полученных датаграмм.

С другой стороны, благодаря такой не избирательности и бесконтрольности, UDP доставляет пакеты данных (датаграммы) гораздо быстрее, потому для приложений, которые рассчитаны на широкую пропускную способность и быстрый обмен, UDP можно считать оптимальным протоколом. К таковым относятся сетевые и браузерные игры, а также программы просмотра потокового видео и приложения для видеосвязи (или голосовой): от потери пакета, полной или частичной, ничего не меняется, повторять запрос не обязательно, зато загрузка происходит намного быстрее. Протокол TCP, как более надежный, с успехом применяется даже в почтовых программах, позволяя контролировать не только трафик, но и длину сообщения и скорость обмена трафиком.

Давайте рассмотрим основные отличия tcp от udp.

1. TCP гарантирует доставку пакетов данных в неизменных виде, последовательности и без потерь, UDP ничего не гарантирует.
2. TCP нумерует пакеты при передаче, а UDP нет
3. TCP работает в дуплексном режиме, в одном пакете можно отправлять информацию и подтверждать получение предыдущего пакета.
4. TCP требует заранее установленного соединения, UDP соединения не требует, у него это просто поток данных.
5. UDP обеспечивает более высокую скорость передачи данных.
6. TCP надежнее и осуществляет контроль над процессом обмена данными.
7. UDP предпочтительнее для программ, воспроизводящих потоковое видео, видеофонии и телефонии, сетевых игр.
8. UPD не содержит функций восстановления данных

Примерами UDP приложений, например можно привести, передачу DNS зон, в Active Directory, там не требуется надежность. Очень часто такие вопросы любят спрашивать на собеседованиях, так, что очень важно знать tcp и udp отличия.

Заголовки TCP и UDP

Давайте рассмотрим как выглядят заголовки двух транспортных протоколов, так как и тут отличия кардинальные.

Заголовок UDP

• 16 битный порт источника > Указание порта источника для UDP необязательно. Если это поле используется, получатель может отправить ответ этому порту.
• 16 битный порт назначения > Номер порта назначения
• 16 битная длина UDP > Длина сообщения, включая заголовок и данные.
• 16 битная контрольная сумма > Контрольная сумма заголовка и данных для проверки

Заголовок TCP

• 16 битный порт источника > Номер порта источника
• 16 битный порт назначения > Номер порта назначения
• 32 битный последовательный номер > Последовательный номер генерируется источником и используется назначением, чтобы переупорядочить пакеты для создания исходного сообщения и отправить подтверждение источнику.
• 32 битный номер подтверждения > Если установлен бит АСК поля "Управление", в данном поле содержит следующий ожидаемый последовательный номер.
• 4 бита длина заголовка > Информация о начале пакета данных.
• резерв > Резервируются для будущего использования.
• 16 битная контрольная сумма > Контрольная сумма заголовка и данных; по ней определяется, был ли искажен пакет.
• 16 битный указатель срочности > В этом поле целевое устройство получает информацию о срочности данных.
• Параметры > Необязательные значения, которые указываются при необходимости.

Размер окна позволяет экономить трафик, рассмотрим когда его значение равно 1, тут на каждый отправленный ответ, отправитель ждет подтверждения, не совсем рационально.

При размере окна 3, отправитель отправляет уже по 3 кадра, и ждет от 4, который подразумевает, что все три кадра у него есть, +1.

Надеюсь у вас теперь есть представления об отличиях tcp udp протоколов.

TCP - это транспортный механизм, предоставляющий поток данных, с предварительной установкой соединения, за счёт этого дающий уверенность в достоверности получаемых данных, осуществляет повторный запрос данных в случае потери данных и устраняет дублирование при получении двух копий одного пакета. В отличие от UDP , гарантирует, что приложение получит данные точно в такой же последовательности, в какой они были отправлены, и без потерь.

Протокол TCP используется в тех случаях, когда требуется надежная доставка сообщений. Он освобождает прикладные процессы от необходимости использовать таймауты и повторные передачи для обеспечения надежности. Наиболее типичными прикладными процессами, использующими TCP, являются FTP (File Transfer Protocol - протокол передачи файлов) и TELNET. Кроме того, TCP используют система X-Window, rcp (remote copy - удаленное копирование) и другие "r-команды". Большие возможности TCP даются не бесплатно. Реализация TCP требует большой производительности процессора и большой пропускной способности сети. Внутренняя структура модуля TCP гораздо сложнее структуры модуля UDP.

Реализация TCP, как правило, встроена в ядро системы, хотя есть и реализации TCP в контексте приложения.

Когда осуществляется передача от компьютера к компьютеру через Internet, TCP работает на верхнем уровне между двумя конечными системами, например, интернет-браузер и интернет-сервер. Также TCP осуществляет надежную передачу потока байт от одной программы на некотором компьютере в другую программу на другом компьютере. Программы для электронной почты и обмена файлами используют TCP. TCP контролирует длину сообщения, скорость обмена сообщениями, сетевой трафик.

Когда прикладной процесс начинает использовать TCP, то модуль TCP на машине клиента и модуль TCP на машине сервера начинают общаться. Эти два оконечных модуля TCP поддерживают информацию о состоянии соединения, называемого виртуальным каналом. Этот виртуальный канал потребляет ресурсы обоих оконечных модулей TCP. Канал является дуплексным; данные могут одновременно передаваться в обоих направлениях. Один прикладной процесс пишет данные в TCP-порт, они проходят по сети, и другой прикладной процесс читает их из своего TCP-порта.

Протокол TCP разбивает поток байт на пакеты; он не сохраняет границ между записями. Например, если один прикладной процесс делает 5 записей в TCP-порт, то прикладной процесс на другом конце виртуального канала может выполнить 10 чтений для того, чтобы получить все данные. Но этот же процесс может получить все данные сразу, сделав только одну операцию чтения. Не существует зависимости между числом и размером записываемых сообщений с одной стороны и числом и размером считываемых сообщений с другой стороны.

Протокол TCP требует, чтобы все отправленные данные были подтверждены принявшей их стороной. Он использует таймауты и повторные передачи для обеспечения надежной доставки. Отправителю разрешается передавать некоторое количество данных, не дожидаясь подтверждения приема ранее отправленных данных. Таким образом, между отправленными и подтвержденными данными существует окно уже отправленных, но еще неподтвержденных данных. Количество байт, которые можно передавать без подтверждения, называется размером окна. Как правило, размер окна устанавливается в стартовых файлах сетевого программного обеспечения. Так как TCP-канал является дуплексным, то подтверждения для данных, идущих в одном направлении, могут передаваться вместе с данными, идущими в противоположном направлении. Приемники на обеих сторонах виртуального канала выполняют управление потоком передаваемых данных для того, чтобы не допускать переполнения буферов.

Схема работы пользовательского приложения с TCP в общих чертах состоит в следующем. Для передачи данных пользовательскому процессу надо вызвать соответствующую функцию TCP, с указанием на буфер передаваемых данных. TCP упаковывает эти данные в сегменты своего стека и вызывает функцию передачи протокола нижнего уровня, например IP.

На другом конце, получатель TCP группирует поступившие от протокола нижнего уровня данные в принимающие сегменты своего буфера, проверяет целостность данных, передает данные пользовательскому процессу и уведомляет отправителя об их получении.

Пользовательский интерфейс с TCP может выполнять такие команды как открыть (OPEN) или закрыть соединение (CLOSE), отправить (SEND) или принять (RECEIVE) данные, а также получить состояние соединения (STATUS).

В модели межсетевого соединения взаимодействие TCP и протоколов нижнего уровня, как правило, не специфицировано, за исключением того, что должен существовать механизм, который обеспечивал бы асинхронную передачу информации от одного уровня к другому. Результатом работы этого механизма является инкапсуляция протокола более высокого уровня в тело протокола более низкого уровня. Реализуется этот механизм через интерфейс вызовов между TCP и IP.

В результате работы этого механизма каждый TCP пакет вкладывается в «конверт» протокола нижнего уровня, например, IP. Получившаяся таким образом дейтаграмма содержит в себе TCP-пакет так же как TCP пакет содержит пользовательские данные.

Краткое описание протоколов семейства TCP/IP с расшифровкой аббревиатур

• ARP (Address Resolution Protocol, протокол определения адресов) : конвертирует 32-разрядные IP-адреса в физические адреса вычислительной сети, например, в 48-разрядные адреса Ethernet.

• FTP (File Transfer Protocol, протокол передачи файлов) : позволяет передавать файлы с одного компьютера на другой с использованием TCP-соединений. В родственном ему, но менее распространенном протоколе передачи файлов - Trivial File Transfer Protocol (TFTP) - для пересылки файлов применяется UDP, а не TCP.

• ICMP (Internet Control Message Protocol, протокол управляющих сообщений Internet) : позволяет IP-маршрутизаторам посылать сообщения об ошибках и управляющую информацию другим IP-маршрутизаторам и главным компьютерам сети. ICMP-сообщения "путешествуют" в виде полей данных IP-дейтаграмм и обязательно должны реализовываться во всех вариантах IP.

• IGMP (Internet Group Management Protocol, протокол управления группами Internet) : позволяет IP-дейтаграммам распространяться в циркулярном режиме (multicast) среди компьютеров, которые принадлежат к соответствующим группам.

• IP (Internet Protocol, протокол Internet) : низкоуровневый протокол, который направляет пакеты данных по отдельным сетям, связанным вместе с помощью маршрутизаторов для формирования Internet или интрасети. Данные "путешествуют" в форме пакетов, называемых IP-дейтаграммами.

• RARP (Reverse Address Resolution Protocol, протокол обратного преобразования адресов) : преобразует физические сетевые адреса в IP-адреса.

• SMTP (Simple Mail Transfer Protocol, простой протокол обмена электронной почтой) : определяет формат сообщений, которые SMTP-клиент, работающий на одном компьютере, может использовать для пересылки электронной почты на SMTP-сервер, запущенный на другом компьютере.

• TCP (Transmission Control Protocol, протокол управления передачей) : протокол ориентирован на работу с подключениями и передает данные в виде потоков байтов. Данные пересылаются пакетами - TCP-сегментами, - которые состоят из заголовков TCP и данных. TCP - "надежный" протокол, потому что в нем используются контрольные суммы для проверки целостности данных и отправка подтверждений, чтобы гарантировать, что переданные данные приняты без искажений.

• UDP (User Datagram Protocol, протокол пользовательских дейтаграмм) : протокол, не зависящий от подключений, который передает данные пакетами, называемыми UDP-дейтаграммами. UDP - "ненадежный" протокол, поскольку отправитель не получает информацию, показывающую, была ли в действительности принята дейтаграмма.

Состав и предназначение полей заголовка

ТСР-сегменты отправляются как IP-дейтаграммы. Заголовок TCP, следующий за IP-заголовком, содержит информацию TCP-протокола.

Source Port (16 бит). Порт отправителя.

Destination Port (16 бит). Порт получателя.

Sequence Number (32 бита). Номер кадра. Номер кадра первого октета данных в этом сегменте (за исключением пакета, где присутствует флаг SYN). Если в пакете присутствует флаг SYN, то номер данного пакета становится номером начала последовательности (ISN) и номером первого октета данных становится номер ISN+1.

Acknowledgment Number (32 бита). Поле номера кадра подтвержденного получения. Если пакет содержит установленный контрольный бит АСК, то это поле содержит номер следующего пакета данных отправителя, который ожидает получатель. При установленном соединении пакет подтверждения отправляется всегда.

Data Offset (4 бита). Поле величины смещения данных. Оно содержит количество 32-битных слов заголовка TCP-пакета. Это число определяет смещение расположения данных в пакете.

Reserved (6 бит). Резервное поле. Поле зарезервировано.

Флаги управления (слева направо):

• URG: Флаг срочности

• АСК: Флаг пакета, содержащего подтверждение получения

• PSH: Флаг форсированной отправки

• RST: Переустановка соединения

• SYN: Синхронизация чисел последовательности

• FIN: Флаг окончания передачи со стороны отправителя

Window (16 бит). Окно. Это поле содержит количество байт данных, которое отправитель данного сегмента может принять, отсчитанное от номера байта, указанного в поле Acknowledgment Number.

Checksum (16 бит). Поле контрольной суммы. Это поле содержит 16 бит суммы побитных дополнений 16-битных слов заголовка и данных. Если сегмент содержит нечетное число байт заголовка и данных, последний байт дополняется справа нулями. При вычислении контрольной суммы поле контрольной суммы полагается равным нулю.

Urgent Pointer (16 бит). Поле указателя срочных данных. Это поле содержит значение счетчика пакетов, начиная с которого следуют пакеты повышенной срочности. Это поле принимается во внимание только в сегментах с установленным флагом URG.

Options. Поле дополнительных параметров: может быть переменной длины.

Padding. Заполнение: переменная длина. Заполнение (нулями) TCP-заголовка используется для выравнивания его по 32-битному слову.

Эта ссылка на наглядное видео. К сожалению, оно на английском языке, но и так понятно.