Протокол tcp простым и понятным языком

Сравнение UDP и TCP

Основная статья: Транспортный уровень

TCP — ориентированный на соединение протокол, что означает необходимость «рукопожатия» для установки соединения между двумя хостами. Как только соединение установлено, пользователи могут отправлять данные в обоих направлениях.

Надёжность — TCP управляет подтверждением, повторной передачей и тайм-аутом сообщений. Производятся многочисленные попытки доставить сообщение. Если оно потеряется на пути, сервер вновь запросит потерянную часть. В TCP нет ни пропавших данных, ни (в случае многочисленных тайм-аутов) разорванных соединений.

Упорядоченность — если два сообщения последовательно отправлены, первое сообщение достигнет приложения-получателя первым. Если участки данных прибывают в неверном порядке, TCP отправляет неупорядоченные данные в буфер до тех пор, пока все данные не могут быть упорядочены и переданы приложению.

Тяжеловесность — TCP необходимо три пакета для установки сокет-соединения перед тем, как отправить данные. TCP следит за надёжностью и перегрузками.

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

UDP — более простой, основанный на сообщениях протокол без установления соединения. Протоколы такого типа не устанавливают выделенного соединения между двумя хостами. Связь достигается путём передачи информации в одном направлении от источника к получателю без проверки готовности или состояния получателя. В приложениях для голосовой связи через интернет-протокол (Voice over IP, TCP/IP) UDP имеет преимущество над TCP, в котором любое «рукопожатие» помешало бы хорошей голосовой связи. В VoIP считается, что конечные пользователи в реальном времени предоставят любое необходимое подтверждение о получении сообщения.

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

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

Легковесность — никакого упорядочивания сообщений, никакого отслеживания соединений и т. д. Это небольшой транспортный уровень, разработанный на IP.

Датаграммы — пакеты посылаются по отдельности и проверяются на целостность только если они прибыли. Пакеты имеют определенные границы, которые соблюдаются после получения, то есть операция чтения на сокете-получателе выдаст сообщение таким, каким оно было изначально послано.

Нет контроля перегрузок — UDP сам по себе не избегает перегрузок. Для приложений с большой пропускной способностью возможно вызвать коллапс перегрузок, если только они не реализуют меры контроля на прикладном уровне.

Объяснение по материалам сайта CITForum

Порт – Часть сокета, указывающая логический канал ввода или вывода для процесса, имеющего дело с данными.Сокет – Адрес, который особым образом включает в себя идентификатор порта. А именно, он включает связь Internet адреса с TCP портом.

Порт – это программное понятие, которое используется клиентом или сервером для посылки или приема сообщений; порт идентифицируется 16-битовым числом. Серверные процессы обычно ассоциируются с фиксированным числом, например числом 25 для SMTP или 6000 для X Windows. Номер порта является известным, так как он требуется, помимо IP-адреса получателя, при установлении соединения с конкретным хостом и сервисом. Клиентские процессы, с другой стороны, запрашивают номер порта у операционной системы в начале работы; и номер порта является случайным, хотя в некоторых случаях он является следующим в списке свободных номеров портов.

Существует достаточно распространенное правило, согласно которому только привилегированные процессы сервера, то есть те процессы, которые работают с привилегиями суперпользователя UNIX, могут использовать порты с номерами меньше, чем 1024 ( так называемые привилегированные порты). Сервера в основном используют порты с номерами меньше, чем 1024, а клиенты как правило должны запрашивать непривилегированные порты у ОС. Хотя это правило и не является обязательным для исполнения и не требуется спецификацией протоколов TCP/IP, системы на основе BSD соблюдают его.
В протоколе TCP также, как и в UDP, для связи с прикладными процессами используются порты. Номера портам присваиваются аналогичным образом: имеются стандартные, зарезервированные номера (например, номер 21 закреплен за сервисом FTP, 23 – за telnet), а менее известные приложения пользуются произвольно выбранными локальными номерами.

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

Соединение в протоколе TCP идентифицируется парой полных адресов обоих взаимодействующих процессов (оконечных точек). Адрес каждой из оконечных точек включает IP-адрес (номер сети и номер компьютера) и номер порта. Одна оконечная точка может участвовать в нескольких соединениях.

Установление соединения выполняется в следующей последовательности:

• При установлении соединения одна из сторон является инициатором. Она посылает запрос к протоколу TCP на открытие порта для передачи (active open).
• После открытия порта протокол TCP на стороне процесса-инициатора посылает запрос процессу, с которым требуется установить соединение.
• Протокол TCP на приемной стороне открывает порт для приема данных (passive open) и возвращает квитанцию, подтверждающую прием запроса.
• Для того чтобы передача могла вестись в обе стороны, протокол на приемной стороне также открывает порт для передачи (active port) и также передает запрос к противоположной стороне.
• Сторона-инициатор открывает порт для приема и возвращает квитанцию. Соединение считается установленным. Далее происходит обмен данными в рамках данного соединения.

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

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

• IP-адрес источника – адрес системы, которая послала пакет
• IP-адрес получателя – адрес системы, которая принимает пакет
• порт отправителя – порт соединения в системе-отправителе
• порт получателя – порт соединения в системе-получателе

Почему бы просто не разрешить отправлять UDP?

абсолютно ужасная идея

1. Веб-сайты смогли бы запускать DDoS-атаки, координируя массовую рассылку UDP-пакетов из браузеров.
2. Появились бы новые дыры в безопасности, потому что JavaScript, выполняемый на веб-страницах, мог бы создавать вредоносные UDP-пакеты для «прощупывания» внутренней системы корпоративных сетей и передавать отчёты по HTTPS.
3. UDP-пакеты не шифруются, поэтому атакующему очень просто организовать сниффинг и чтение всех данных, передаваемых в этих пакетах, или даже изменять их при передаче. Обеспечение возможности передачи браузерами незашифрованных пакетов стало бы огромным шагом назад в сетевой безопасности.
4. В UDP отсутствует аутентификация, поэтому выделенный сервер, считывающий отправленные браузером пакеты, должен был бы применять собственный метод валидности подключающихся к нему пользователей. Такие трудозатраты гораздо выше тех усилий, которые разработчики игр готовы вложить в решение этой проблемы.

Расчёт контрольной суммы

Метод для вычисления контрольной суммы определён в RFC 1071.

Перед расчётом контрольной суммы, если длина UDP-сообщения в байтах нечётна, то UDP-сообщение дополняется в конце нулевым байтом (псевдозаголовок и добавочный нулевой байт не отправляются вместе с сообщением, они используются только при расчёте контрольной суммы). Поле контрольной суммы в UDP-заголовке во время расчёта контрольной суммы принимается нулевым.

Для расчёта контрольной суммы псевдозаголовок и UDP-сообщение разбивается на двухбайтные слова. Затем рассчитывается сумма всех слов в арифметике обратного кода (то есть кода, в котором отрицательное число получается из положительного инверсией всех разрядов числа и существует два нуля: 0х0000 (обозначается +0) и (обозначается −0)). Результат записывается в соответствующее поле в UDP-заголовке.

Значение контрольной суммы, равное 0х0000 (+0 в обратном коде), зарезервировано и означает, что для посылки контрольная сумма не вычислялась. В случае, если контрольная сумма вычислялась и получилась равной 0х0000, то в поле контрольной суммы заносят значение (-0 в обратном коде).

При получении сообщения получатель считает контрольную сумму заново (уже учитывая поле контрольной суммы), и, если в результате получится −0 (то есть ), то контрольная сумма считается сошедшейся. Если сумма не сходится (данные были повреждены при передаче, либо контрольная сумма неверно посчитана на передающей стороне), то решение о дальнейших действиях принимает принимающая сторона. Как правило, в большинстве современных устройств, работающих с UDP/IP-пакетами имеются настройки, позволяющие либо игнорировать такие пакеты, либо пропускать их на дальнейшую обработку, невзирая на неправильность контрольной суммы.

Пример расчёта контрольной суммы

Для примера рассчитаем контрольную сумму нескольких 16-битных слов: .

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

0x398a + 0xf802 = 0x1318c → 0x318d (перенос в старший разряд)
0x318d + 0x14b2 = 0x0463f → 0x463f (число положительное)
0x463f + 0xc281 = 0x108c0 → 0x08c1

В конце выполняется инверсия всех битов получившегося числа

или, иначе — .
Это и есть искомая контрольная сумма.

В документе RFC 1071 приведены и другие способы расчёта контрольной суммы, в частности, с использованием 32х-разрядной арифметики.

Описание

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

Процесс программы, желающей обмениваться данными по сети, может (например, при создании socket):

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

Обмен данными по сети ведётся между двумя процессами по определённому протоколу. Для установки соединения необходимы:

• номер протокола;
• два IP-адреса (адрес хоста-отправителя и адрес хоста-получателя для построения маршрута между ними);

два номера порта (порт процесса-отправителя и порт получателя).

Порт процесса-отправителя (источника) может быть постоянным (статическим) или назначаться динамически для каждого нового сеанса связи.

При соединении по протоколу TCP порт процесса-отправителя используется:

• операционной системой хоста-получателя для отправки пакета-подтверждения о получении данных;
• процессом-получателем для отправки пакета-ответа.

При соединении по протоколу UDP допустимо вместо порта процесса-отправителя указывать число ноль, означающее «порт не указан».

При соединении по протоколу SCTP в рамках ассоциации может использоваться:

• несколько портов процесса-отправителя (источника)
• несколько портов процесса-получателя.

Так как IP-адрес хоста-отправителя и номер порта процесса-отправителя являются аналогом обратного адреса, записываемого на почтовых конвертах (позволяют получателю отправить ответ отправителю), номер порта процесса-отправителя иногда называют «обратным» портом.

Если на хосте какой‑либо процесс постоянно использует один номер порта (например, процесс программы, реализующей web-сервер, может использовать порт 80 для приёма и передачи данных), говорят, что порт является «открытым».

Термины «открытый порт» и «закрытый порт» (заблокированный) также используются, когда речь идёт о фильтрации сетевого трафика.

Если процесс получил номер порта у ОС («открыл порт») и «держит его открытым» для приёма и передачи данных, говорят, что процесс «прослушивает» (разг. слушает, от англ. listen) порт.

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

Если хост получит пакет, порт процесса-отправителя называется «удалённым» (англ. remote) портом или «открытым на другом хосте», а порт процесса получателя — «локальным» портом, то есть открытым на текущем хосте. Если хост отправил пакет, порт процесса-отправителя называется «локальным» портом (открытым на текущем хосте), а порт процесса-получателя — «удалённым» портом (открытым на другом хосте).

Номера портов для протоколов прикладного уровня модели TCP/IP (HTTP, SSH и др.) обычно назначаются организацией IANA (англ. internet assigned numbers authority). Однако на практике в целях безопасности номера портов могут выбираться произвольно.

Термин «порт» чаще всего применяется по отношению к протоколам TCP и UDP ввиду популярности этих протоколов. В протоколах SCTP и DCCP используются номера, соответствующие понятию «номер порта» для протоколов TCP и UDP.

В заголовках протоколов TCP и UDP для хранения номеров портов выделены поля размером 16 бит. Для протокола TCP порт с номером 0 зарезервирован и не может использоваться. Для протокола UDP указание порта процесса-отправителя («обратного» порта) не является обязательным, и порт с номером 0 означает отсутствие порта. Таким образом, номер порта — число в диапазоне от 1 до 216-1=65 535.

Принципы надежной передачи данных

Надежная передача данных по совершенно надежному каналу

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

Надежная передача данных по каналу с возможными ошибками

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

В таком случае применяются механизмы:

• обнаружения ошибки;
• обратной связи;
• повторной передачи.

Протоколы надежной передачи данных, обладающие подобными механизмами многократного повторения передачи, называются протоколами с автоматическим запросом повторной передачи (Automatic Repeat reQuest, ARQ).
Дополнительно, стоит предусмотреть возможность ошибок и в квитанциях, когда принимающая сторона не получит никакой информации о результатах передачи последнего пакета.
Решение этой задачи, используемое в том числе в TCP, состоит в добавлении в пакет данных нового поля, содержащего порядковый номер пакета.

Надежная передача данных по ненадежному каналу, допускающему искажение и потерю пакетов

Одновременно с искажениями, к сожалению, в сети присутствует потеря пакетов.
И для решения этой задачи требуются механизмы:

• определения факта потери пакетов;
• повторной доставки потерянных пакетов принимающей стороне.

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

Итак, мы ознакомились с ключевыми понятиями протоколов надежной передачи данных:

• контрольными суммами;
• порядковыми номерами пакетов;
• таймерами;
• положительными и отрицательными квитанциями.

Но и это не все!

Протокол надежной передачи данных с конвейеризацией

В том варианте, который мы уже рассмотрели, протокол надежной доставки очень неэфективен. Он начинает «тормозить» передачу, обеспечиваемую каналом связи, при увеличении RTT. Для повышения его эффективности, лучшей утилизации пропускной способности канала связи применяют конвейеризацию.

Применение конвейеризации приводит к:

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

Диапазон порядковых номеров и требования к размерам буферов зависят от действий, предпринимаемых протоколом в ответ на искажение, потерю и задержку пакета. В случае конвейеризации существуют два метода исправления ошибок:

• возвращение на N пакетов назад;
• выборочное повторение.

Возвращение на N пакетов назад — протокол скользящего окна

Отправитель должен поддерживать три типа событий:

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

Выборочное повторение

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

Сравнение с моделью OSI

Три верхних уровня в модели OSI, то есть уровень приложения, уровень представления и уровень сеанса, отдельно не различаются в модели TCP/IP, которая имеет только прикладной уровень над транспортным уровнем. Хотя некоторые чистые приложения протокола OSI, такие как X.400, также объединяют их, нет требования, чтобы стек протокола TCP/IP должен накладывать монолитную архитектуру над транспортным уровнем. Например, протокол NFS-приложений работает через протокол представления данных External Data Representation (XDR), который, в свою очередь, работает по протоколу Remote Procedure Call (RPC). RPC обеспечивает надежную передачу данных, поэтому он может безопасно использовать транспорт UDP с максимальным усилием.

Различные авторы интерпретировали модель TCP/IP по-разному и не согласны с тем, что уровень связи или вся модель TCP/IP охватывает проблемы уровня OSI уровня 1 (физический уровень) или предполагается, что аппаратный уровень ниже уровня канала.

Несколько авторов попытались включить слои 1 и 2 модели OSI в модель TCP/IP, поскольку они обычно упоминаются в современных стандартах (например, IEEE и ITU). Это часто приводит к модели с пятью слоями, где уровень связи или уровень доступа к сети разделяются на слои 1 и 2 модели OSI.

Например, считается, что уровни сеанса и представления пакета OSI включены в прикладной уровень пакета TCP/IP. Функциональность уровня сеанса можно найти в протоколах, таких как HTTP и SMTP, и более очевидна в таких протоколах, как Telnet и протокол инициации сеанса (SIP). Функциональность уровня сеанса также реализована с нумерацией портов протоколов TCP и UDP, которые охватывают транспортный уровень в наборе TCP/IP. Функции уровня представления реализуются в приложениях TCP/IP со стандартом MIME при обмене данными.

Конфликты очевидны также в оригинальной модели OSI, ISO 7498, когда не рассматриваются приложения к этой модели, например, ISO 7498/4 Management Framework или ISO 8648 Internal Organization of the Network layer (IONL). Когда рассматриваются документы IONL и Management Framework, ICMP и IGMP определяются как протоколы управления уровнем для сетевого уровня. Аналогичным образом IONL предоставляет структуру для «зависимых от подсетей объектов конвергенции», таких как ARP и RARP.

Протоколы IETF могут быть инкапсулированы рекурсивно, о чем свидетельствуют протоколы туннелирования, такие как Инкапсуляция общей маршрутизации (GRE). GRE использует тот же механизм, который OSI использует для туннелирования на сетевом уровне.
Существуют разногласия в том, как вписать модель TCP/IP в модель OSI, поскольку уровни в этих моделях не совпадают.

К тому же, модель OSI не использует дополнительный уровень — «Internetworking» — между канальным и сетевым уровнями. Примером спорного протокола может быть ARP или STP.

Вот как традиционно протоколы TCP/IP вписываются в модель OSI:

Обычно в стеке TCP/IP верхние 3 уровня модели OSI (прикладной, представления и сеансовый) объединяют в один — прикладной. Поскольку в таком стеке не предусматривается унифицированный протокол передачи данных, функции по определению типа данных передаются приложению.