Как понять сетевые протоколы?

Ответ 1

Поскольку я задал этот вопрос, я узнал больше об этой теме, поэтому я постараюсь ответить на него сам.

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

Уровень приложений

Само письмо является запросом прикладного уровня. Например, вы набрали "StackOverflow.com" в своем браузере и нажали Enter. Ваш браузер должен запросить у сервера StackOverflow домашнюю страницу. Поэтому он пишет письмо, в котором говорится: "Уважаемый StackOverflow, не могли бы вы выслать мне свою домашнюю страницу?"

Если автором письма является ваш браузер, получателем письма является программа веб-сервера, работающая в StackOverflow. Браузер хочет, чтобы веб-сервер "ответил" ответом в виде веб-страницы. И браузер, и сервер являются приложениями - программами, работающими на определенных компьютерах.

Поскольку браузеры говорят по HTTP, это то, что он использует для выполнения запроса: в письме говорится что-то вроде "GET /fooobar.com/... ". Браузер также записывает любую информацию cookie, полученную от StackOverflow в прошлый раз ("помните меня? Вы сказали, что мой логин был X"), и добавляет некоторую различную помеченную информацию под названием "заголовки" (такие вещи, как "I'm Firefox" и " Я могу принять HTML или текст "и" со мной все в порядке, если вы сжимаете содержимое с помощью gzip "). Вся эта информация поможет серверу узнать, как персонализировать или настроить свой ответ.

На этом этапе браузер в основном готов. Он передает это письмо операционной системе и говорит: "Не могли бы вы прислать это мне?" ОС говорит: "Конечно". Затем он выполняет некоторую работу по подключению к StackOverflow (подробнее об этом через минуту), а затем сообщает браузеру: "Я работаю над этим. Кстати, вот небольшой почтовый ящик, который я для вас сделал, называется сокетом. Когда Я слышу ответ от StackOverflow, я положу туда его письмо, и вы сможете прочитать его, как файл. " Затем браузер с радостью ждет ответа.

Уровень IP

Чтобы отправить запрос из браузера в StackOverflow, операционная система должна сделать несколько вещей.

Во-первых, он должен найти адрес StackOverflow.com, в частности, IP-адрес. Это делается с помощью DNS (я не буду вдаваться в подробности). Как только он знает IP-адрес, он будет знать, как обернуть запрос в один из "конвертов", называемых IP-уровнем.

Зачем нам нужен уровень IP? Ну, когда-то, мы не сделали.

Почему нам нужен IP

Вы когда-нибудь видели старый фильм, где кто-то делает телефонный звонок, прося оператора подключить их? Оператор физически подключил бы провод от дома № 1 к проводу для дома № 2. До изобретения стека протоколов подключение компьютеров было очень похоже на этот телефонный звонок: вам требовался выделенный провод от точки к точке.

Так, например, если бы компьютерные ученые в Стэнфорде хотели обмениваться данными с данными в Гарварде, они заплатили бы кучу денег, чтобы арендовать выделенный провод между двумя местами ("арендованная линия"). Любые данные, которые попали в один конец, надежно вышли в другом конце. Однако это было очень дорого: представьте, что платите за отдельную линию для каждого места, к которому хотите подключиться!

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

Но это представляло проблему. Если бы все коммуникации проходили по одной линии, как бы данные попали в нужное место? Представьте себе кучу писем, сброшенных на конвейер. Очевидно, что каждое письмо должно быть адресовано кому-то, иначе оно не может быть доставлено.

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

Итак, как только ОС проверила IP-адрес Stackoverflow.com, она помещает HTTP-запрос в IP-конверт. Если это "длинное письмо", слишком большое для одного конверта, ОС разрезает его на части и помещает в несколько IP-конвертов. Каждый конверт говорит что-то вроде "FROM: (ваш IP-адрес); TO: (IP-адрес сервера". Как и HTTP-запрос, IP-пакет содержит некоторую другую информацию заголовка, которую мы не будем здесь рассматривать, но основные идея просто "до" и "от".

Итак, на данный момент письмо готово к отправке, верно?

Грязность IP

Не совсем. Это письмо может легко потеряться! Видите, с IP у нас больше нет выделенной линии с места на место. Если бы мы это сделали, мы были бы уверены, что наши письма были доставлены: до тех пор, пока линия не будет разорвана, все будет проходить.

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

"Здесь письмо направляется в Мехико. Я не знаю точно, как туда добраться, но станция в Хьюстоне должна быть в состоянии приблизить его, поэтому я отправлю его туда. Ах, вот письмо, которое отправляется в Атланту Я отправлю это Шарлотте, они должны быть в состоянии передать это на шаг ближе. "

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

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

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

Ага. Это. Вы можете подумать, что, по крайней мере, было бы достаточно любезно отправить вам записку со словами: "Извините, мы не смогли доставить ваше письмо". Но это не так. Если вы думаете об этом, если маршрутизатор перегружен, это, вероятно, потому что на линиях уже слишком много трафика. Добавление извинений только усугубит проблему. Таким образом, он выбрасывает ваш пакет и не говорит никому.

Очевидно, это проблема для нашего HTTP-запроса. Нам это нужно, чтобы добраться туда, и нам нужен ответ, чтобы получить надежный ответ.

Чтобы убедиться, что он туда добирается, нам нужна какая-то услуга "подтверждение доставки". Для этого мы обернем еще один конверт вокруг нашего HTTP-запроса, прежде чем помещать его в IP-пакеты. Этот слой называется TCP.

TCP

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

Как и предполагалось ранее, TCP позволяет нам добавить "подтверждение доставки" в эту грязную систему доставки. Прежде чем мы обернем наш HTTP-запрос в IP-пакеты, мы сначала поместим его в TCP-пакеты. Каждому из них присваивается номер: пакет 1 из 5, 2 из 5 и т.д. (Схема нумерации на самом деле является более сложной и учитывает байты, а не пакеты, но пока давайте проигнорируем это.)

Основная идея TCP заключается в следующем:

• Сначала клиент и сервер - в данном случае ваша операционная система и серверная операционная система StackOverflow - выполняют "рукопожатие" для установления "соединения". Оба слова нуждаются в кавычках, потому что "рукопожатие" - это на самом деле несколько сообщений взад и вперед, доказывающих, что пакеты могут успешно доставляться туда и обратно, а "соединение" - это не более чем каждая сторона, решающая, что они будут отслеживать пакеты течет между ними.
• Затем они отправляют пакеты назад и вперед; клиент может запрашивать веб-страницу, а сервер может отправлять ее обратно (столько пакетов, сколько требуется).
• Когда одна сторона получает пакеты, она отправляет обратно подтверждающие сообщения, в которых говорится: "Пока я получил ваши пакеты до пакета 100" и так далее. Если одна сторона отправляет пакеты и некоторое время не слышит подтверждения, она будет считать, что они были потеряны, и повторно отправит их.

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

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

Это в основном так - наличие такого рода подтверждения доставки делает ненадежную IP-сеть надежной.

Почему это не было встроено прямо в IP?

UDP

Что ж, у подтверждения есть недостаток: оно замедляет работу. Если что-то пропущено, это нужно повторить. В некоторых случаях это было бы пустой тратой времени, потому что то, что вы действительно хотите, это соединение в реальном времени. Например, если у вас телефонный разговор по IP или вы играете в игру в реальном времени через Интернет, вы хотите знать, что происходит прямо сейчас, даже если это означает, что вы пропустили немного того, что произошло за секунду тому назад. Если вы перестанете повторять что-то, вы потеряете синхронизацию со всеми остальными. В подобных случаях вы можете использовать двоюродного брата TCP, называемого UDP, который не пересылает потерянные пакеты. UDP означает "протокол пользовательских дейтаграмм", но многие считают его "ненадежным протоколом данных". Это не оскорбление; иногда надежность менее важна, чем постоянный ток.

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

Как TCP, так и UDP добавляют к запросу еще одну важную информацию: номер порта.

Номера портов

Помните, что наш первоначальный запрос исходит из браузера и направляется на программу веб-сервера. Но у протокола IP есть только адреса, которые указывают компьютеры, а не приложения, работающие на них. На машине с веб-сервером StackOverflow могут также присутствовать другие серверные программы, которые прослушивают запросы: сервер базы данных, FTP-сервер и т.д. Когда этот компьютер получает запрос, как он узнает, какая программа должна обработать его?

Он будет знать, потому что в запросе TCP есть номер порта. Это просто число, ничего особенного, но условно, что определенные числа интерпретируются как определенные вещи. Например, использование номера порта 80 является обычным способом сказать "это запрос к веб-серверу". Тогда операционная система сервера будет знать, что передать этот запрос программе веб-сервера, а не, скажем, программе FTP-сервера.

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

Подождите, что за сокет?

Розетки

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

Вы можете думать о сокете, как о файле. Файл - это интерфейс, который предоставляет ОС. Там написано: "Вы можете читать и записывать данные здесь, а я позабочусь о том, как на самом деле сохранить их на жестком диске, USB-накопителе или чем-то еще". То, что уникально идентифицирует файл, - это сочетание пути и имени файла. Другими словами, вы можете иметь только один файл, расположенный в той же папке с тем же именем.

Аналогично, сокет - это интерфейс, который предоставляет ОС. Там написано: "Вы можете писать запросы здесь и читать ответы". То, что однозначно идентифицирует сокет, - это сочетание четырех вещей:

• IP-адрес назначения
• Порт назначения
• Исходный IP
• Порт источника

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

Подводя итоги

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

Итак, наш "стек":

• HTTP-запрос ("письмо"). Это прикладной уровень.
• Завернуты в TCP-пакеты ("конверты"). Это транспортный уровень.
• Заворачивается в IP-пакеты ("конверты"). Это уровень IP.

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

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

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

Но вы можете легко опуститься в стек; Вы можете обернуть больше "конвертов" вокруг существующих.

Другие уровни протокола

Когда-то общим "конвертом" для обтекания IP является Ethernet. Например, когда ваш компьютер решает отправить IP-пакеты в Google, он упаковывает их, как мы уже описывали, но для отправки он передает их на вашу сетевую карту. Затем сетевая карта может обернуть IP-пакеты в пакеты Ethernet (или пакеты Token Ring, если у вас есть устаревшие настройки), направив их на ваш маршрутизатор и отправив их туда. Ваш маршрутизатор удаляет эти "конверты" Ethernet, проверяет IP-адрес, решает, кто является ближайшим маршрутизатором, оборачивает другой конверт Ethernet, адресованный этому маршрутизатору, и отправляет пакет.

Другие протоколы также могут быть упакованы. Возможно, два устройства подключены только по беспроводной связи, поэтому они оборачивают свои пакеты Ethernet в протокол Wi-Fi, Bluetooth или 4G. Возможно, ваши пакеты должны пересекать деревню без электричества, поэтому кто-то физически печатает пакеты на бумаге с пронумерованными страницами, проезжает по городу на велосипеде и сканирует их на другом компьютере в порядке номеров страниц. Вуаля! Протокол печати в OCR. Или, может быть, я не знаю, TCP по почтовому голубю будет лучше.

Заключение

Стек протоколов - прекрасное изобретение, и оно работает настолько хорошо, что мы обычно принимаем это как должное.

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

• Прикладной уровень касается только приложений, разговаривающих друг с другом: "Firefox хочет общаться с веб-сервером на StackOverflow.com".
• Транспортный уровень занимается только получением потока пакетов, правильно доставленных из одного приложения в другое: "все пакеты из порта 123 на машине 1 должны попасть в порт 80 на машине 2".
• Уровень IP касается только маршрутизации отдельных пакетов: "этот пакет должен получить следующий IP-адрес".
• Канальный уровень связан только с получением пакетов от одной путевой точки к следующей: "этот пакет Ethernet должен пройти от сетевой карты до маршрутизатора".
• Физический уровень связан только с передачей сигнала: "эти импульсы должны передаваться по этому проводу".

(Хотя эти термины уровня заимствованы из OSI, OSI на самом деле был конкурирующим стандартом для TCP/IP и включал такие вещи, как "уровень сеанса" и "уровень представления", которые TCP/IP не использует. OSI должен был стать более разумная и стандартизированная альтернатива небрежному хакерскому стеку TCP/IP, но, хотя он еще обсуждался, TCP/IP уже работал и получил широкое распространение.)

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

Ответ 2

В течение всего описания сетей TCP/IP (без физического уровня, например, Ethernet) выберите TCP/IP, проиллюстрированный Stevens. Если вы собираетесь выполнять низкоуровневое сетевое программирование, сетевое программирование Unix одним и тем же автором является лучшим.

Ответ 3

Есть причина, по которой вы часто слышите о реализациях TCP/IP, называемых "стек". Часть концепции заключается в том, что у вас есть протокол низкого уровня (Ethernet, PPP, what-have-you), несколько высокоуровневых протоколов, построенных поверх него (IP) и т.д. Это очень похоже на модель OSI и может быть описано в терминах этой модели, хотя TCP/IP разбивает слои немного по-другому. В любом случае, программы обычно отправляют данные с использованием одного из протоколов верхнего уровня и позволяют стеку TCP/IP обрабатывать детали получения данных из точки A в точку B.

TCP находится поверх IP-адреса и позволяет вам воспринимать данные, поступающие и выходящие как пару потоков (один в одном, один выход), а не получение необработанных IP-пакетов и необходимость выяснить, что с ними делать. (Большие преимущества BIG: это упрощает мультиплексирование. Без TCP или UDP и т.п. IP будет почти бесполезным - только одна программа может нормально взаимодействовать с сетью в данный момент времени.)

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

HTTP находится поверх TCP (или SSL, в случае HTTPS) и предоставляет возможность для клиента и сервера передавать целые запросы и ответы вместе с метаданными, описывающими их.

Ответ 4

В школе у нас были компьютерные сети, и нам пришлось купить эту книгу, она действительно помогает. Это объясняет каждый уровень модели OSI. (От интернет-маркировки и маршрутизаторов до уровней протоколов tcp udp до уровня приложений). Если вы хотите получить более базовые знания о том, как все это работает, это необходимо прочитать.

Ответ 5

Есть ли полезная для новичков книга или другой ресурс, который вы бы рекомендовать?

Передача данных и сетевое взаимодействие by Behrouz Forouzan:

Это содержит вступительный материал, и объяснение является новичком. В то же время, он не ошарашен, и материал становится немного сложнее, когда вы продолжаете. Есть очень хорошие диаграммы, объясняющие понятия. Набор верстки является удивительным, и у вас будет много интересных советов, связанных с контентом. Главы упорядочены в соответствии со стеком OSI, как указано в других ответах здесь. Но большая часть математики и выводов для формул для эффективности протокола не объясняются.

Компьютерные сети Эндрю С. Таненбаума

Все найденное в Behrouz Forouzan + множество уравнений.

Моя рекомендация - сначала прочитать первую книгу, и если вам особенно интересно узнать о математике, перейдите ко второй.

Ответ 6

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

Существует несколько широких типов сетевых протоколов, в том числе:

• Сетевые протоколы связи: базовые протоколы передачи данных, такие как TCP/IP и HTTP.

• Протоколы сетевой безопасности: реализуйте безопасность сетевых коммуникаций и включайте HTTPS, SSL и SFTP.

• Протоколы управления сетью: обеспечивают управление сетью и ее обслуживание, включая SNMP и ICMP.

Различные уровни эталонной модели взаимодействия открытых систем (OSI):

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

2. Уровень представления. Этот уровень в эталонной модели OSI имеет дело с указанием формата, который должен использоваться для обеспечения возможности передачи сетевых данных между компьютерами в сети. Уровень представления добавляет форматирование, шифрование и сжатие данных в пакет.

3. Сеансовый уровень. Этот уровень позволяет приложениям, расположенным на разных компьютерах, создавать и закрывать сетевые сеансы. Он также управляет открытыми сетевыми подключениями или сеансами, которые открыты.

4. Транспортный уровень. Транспортный уровень отвечает за то, чтобы данные доставлялись последовательно, безошибочно и эффективно по сети. Транспортный уровень также идентифицирует дублированные пакеты и отбрасывает их. Протоколы транспортного уровня включают протокол управления передачей (TCP) и последовательный обмен пакетами (SPX). Эти протоколы открывают пакеты на принимающем компьютере и также собирают исходные сообщения.

5. Сетевой уровень: этот уровень эталонной модели OSI обеспечивает адресацию сообщений для всех сетей. Он преобразует ваши логические адреса и имена в физические адреса, а затем идентифицирует предпочтительный маршрут от исходного компьютера к конечному компьютеру.

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

7. Физический уровень. Этот уровень размещает данные на физическом носителе, на котором эти данные находятся. Он отвечает за фактическое физическое соединение между двумя компьютерами в сети, которые обмениваются данными.

Функция протоколов на компьютере-отправителе представлена ниже:

• Сегментируйте данные на более мелкие, более управляемые фрагменты или пакеты.

• Добавить адресацию к пакетам.

• Убедитесь, что данные готовы для отправки через сетевую карту (NIC) на сетевой кабель

Функция протоколов на принимающем компьютере кратко изложена ниже:

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

• Удалить всю информацию, касающуюся отправки пакета. Это информация, добавленная в пакет отправляющим компьютером.

• Переместите пакеты в буфер для процесса повторной сборки.

• передавать данные в конкретное приложение.

Протокол Интернета :

Набор протоколов Интернета - это набор протоколов связи, которые реализуют стек протоколов, на которых работает Интернет. Набор протоколов Интернета иногда называют набором протоколов TCP/IP, после TCP\IP, который ссылается на важные протоколы в нем, Протокол управления передачей (TCP) и Протокол Интернета (IP). Набор протоколов Интернета может быть описан по аналогии с моделью OSI, но есть некоторые различия. Также не все слои соответствуют друг другу.

Стек протоколов:

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

Протокол управления передачей (TCP):

Протокол управления передачей является основным протоколом пакета интернет-протоколов. Он возник в реализации сети, в которой он дополняет протокол Интернета. Поэтому весь набор обычно называют TCP/IP. TCP обеспечивает надежную доставку потока октетов по IP-сети. Порядок и проверка ошибок являются основными характеристиками ПТС. Все основные интернет-приложения, такие как World Wide Web, электронная почта и передача файлов, используют TCP.

Интернет-протокол (IP):

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