Сетевой сокет — это программная структура в сетевом узле компьютерной сети , которая служит конечной точкой для отправки и получения данных по сети. Структура и свойства сокета определяются интерфейсом прикладного программирования (API) для сетевой архитектуры. Сокеты создаются только в течение жизненного цикла процесса приложения , работающего в узле.
Из-за стандартизации протоколов TCP/IP в развитии Интернета термин сетевой сокет чаще всего используется в контексте набора протоколов Интернета и поэтому часто также упоминается как сокет Интернета . В этом контексте сокет внешне идентифицируется для других хостов по его адресу сокета , который представляет собой триаду транспортного протокола , IP-адреса и номера порта .
Термин «сокет» также используется для обозначения программной конечной точки внутреннего межпроцессного взаимодействия (IPC) узла, которая часто использует тот же API, что и сетевой сокет.
Использование термина гнездо в программном обеспечении аналогично функции электрического гнездового соединителя , устройства в оборудовании для связи между узлами, соединенными электрическим кабелем . Аналогично, термин порт используется для внешних физических конечных точек на узле или устройстве.
Интерфейс прикладного программирования (API) для стека сетевых протоколов создает дескриптор для каждого сокета, созданного приложением, обычно называемый дескриптором сокета . В Unix-подобных операционных системах этот дескриптор является типом файлового дескриптора . Он сохраняется процессом приложения для использования с каждой операцией чтения и записи на канале связи.
Во время создания с помощью API сетевой сокет привязан к комбинации типа сетевого протокола, который будет использоваться для передачи, сетевого адреса хоста и номера порта . Порты — это пронумерованные ресурсы, которые представляют собой другой тип программной структуры узла. Они используются как типы служб и, будучи созданными процессом, служат компонентом местоположения с внешней (из сети) адресацией, чтобы другие хосты могли устанавливать соединения.
Сетевые сокеты могут быть предназначены для постоянных соединений при обмене данными между двумя узлами или могут участвовать в многоадресных коммуникациях и коммуникациях без установления соединения .
На практике, в связи с распространением протоколов TCP/IP, используемых в Интернете, термин сетевой сокет обычно относится к использованию с Интернет-протоколом (IP). Поэтому его часто также называют интернет-сокетом .
Приложение может взаимодействовать с удаленным процессом, обмениваясь данными с TCP/IP, зная комбинацию типа протокола, IP-адреса и номера порта. Эта комбинация часто называется адресом сокета . Это сетевой дескриптор доступа к сетевому сокету. Удаленный процесс устанавливает сетевой сокет в своем собственном экземпляре стека протоколов и использует сетевой API для подключения к приложению, предоставляя свой собственный адрес сокета для использования приложением.
Стек протоколов , обычно предоставляемый операционной системой (а не как отдельная библиотека, например), представляет собой набор служб, который позволяет процессам взаимодействовать по сети с использованием протоколов, реализуемых стеком. Операционная система пересылает полезную нагрузку входящих IP-пакетов соответствующему приложению, извлекая информацию об адресе сокета из заголовков IP и транспортного протокола и удаляя заголовки из данных приложения.
Интерфейс прикладного программирования (API), который программы используют для взаимодействия со стеком протоколов с помощью сетевых сокетов, называется API сокетов . Разработка прикладных программ, использующих этот API, называется программированием сокетов или сетевым программированием . API интернет-сокетов обычно основаны на стандарте сокетов Беркли . В стандарте сокетов Беркли сокеты являются формой файлового дескриптора из-за философии Unix , что «все является файлом», и аналогий между сокетами и файлами. Оба имеют функции для чтения, записи, открытия и закрытия. На практике различия напрягают аналогию, и на сокете используются разные интерфейсы (отправка и получение). При межпроцессном взаимодействии каждый конец обычно имеет свой собственный сокет.
В стандартных интернет-протоколах TCP и UDP адрес сокета представляет собой комбинацию IP-адреса и номера порта , подобно тому, как один конец телефонного соединения представляет собой комбинацию телефонного номера и определенного расширения . Сокеты не обязательно должны иметь исходный адрес, например, только для отправки данных, но если программа привязывает сокет к исходному адресу, сокет может использоваться для получения данных, отправленных на этот адрес. На основе этого адреса интернет-сокеты доставляют входящие пакеты данных соответствующему прикладному процессу .
Под сокетом часто подразумевают интернет-сокет или TCP-сокет. Интернет-сокет минимально характеризуется следующим:
Различия между сокетом (внутреннее представление), дескриптором сокета (абстрактный идентификатор) и адресом сокета (публичный адрес) тонкие, и они не всегда различаются в повседневном использовании. Кроме того, конкретные определения сокета различаются у разных авторов. В IETF Request for Comments , Internet Standards , во многих учебниках, а также в этой статье термин сокет относится к сущности, которая уникально идентифицируется номером сокета. В других учебниках [1] термин сокет относится к локальному адресу сокета, т. е. «комбинации IP-адреса и номера порта». В первоначальном определении сокета , данном в RFC 147 [2] , поскольку оно было связано с сетью ARPA в 1971 году, «сокет указан как 32-битное число с четными сокетами, идентифицирующими принимающие сокеты, и нечетными сокетами, идентифицирующими отправляющие сокеты». Однако сегодня связь через сокеты является двунаправленной.
В операционной системе и приложении, создавшем сокет, на сокет ссылаются с помощью уникального целочисленного значения, называемого дескриптором сокета .
В операционных системах типа Unix и Microsoft Windows для вывода списка установленных сокетов и связанной с ними информации используются инструменты командной строки netstat или ss [3] .
Этот пример, смоделированный в соответствии с интерфейсом сокетов Беркли, отправляет строку "Hello, world!" через TCP на порт 80 хоста с адресом 203.0.113.0. Он иллюстрирует создание сокета (getSocket), подключение его к удаленному хосту, отправку строки и, наконец, закрытие сокета:
Сокет mysocket = getSocket(тип = "TCP")подключиться(mysocket, адрес = "203.0.113.0", порт = "80")send(mysocket, "Привет, мир!")закрыть(мойсокет)
Доступны несколько типов интернет-розеток:
Другие типы сокетов реализованы поверх других транспортных протоколов, таких как системная сетевая архитектура [10] и сокеты домена Unix для внутреннего межпроцессного взаимодействия.
Компьютерные процессы, которые предоставляют прикладные службы, называются серверами и создают сокеты при запуске, которые находятся в состоянии прослушивания . Эти сокеты ждут инициатив от клиентских программ.
TCP-сервер может обслуживать несколько клиентов одновременно, создавая уникальный выделенный сокет для каждого клиентского соединения в новом дочернем процессе или потоке обработки для каждого клиента. Они находятся в установленном состоянии , когда виртуальное соединение сокет-сокет или виртуальный канал (VC), также известный как сеанс TCP , устанавливается с удаленным сокетом, обеспечивая дуплексный поток байтов .
Сервер может создать несколько одновременно установленных TCP-сокетов с одним и тем же локальным номером порта и локальным IP-адресом, каждый из которых сопоставлен со своим собственным дочерним процессом сервера, обслуживающим свой собственный клиентский процесс. Они рассматриваются операционной системой как разные сокеты, поскольку адрес удаленного сокета (IP-адрес клиента или номер порта) отличается; т. е. поскольку они имеют разные кортежи пар сокетов.
UDP-сокеты не имеют установленного состояния , поскольку протокол не требует установления соединения . Процесс UDP-сервера последовательно обрабатывает входящие датаграммы от всех удаленных клиентов через один и тот же сокет. UDP-сокеты не идентифицируются удаленным адресом, а только локальным адресом, хотя каждое сообщение имеет связанный удаленный адрес, который можно извлечь из каждой датаграммы с помощью сетевого интерфейса прикладного программирования (API).
Соединяющие локальные и удаленные сокеты называются парами сокетов . Каждая пара сокетов описывается уникальным 4-кортежем, состоящим из исходного и конечного IP-адресов и номеров портов, т. е. локальных и удаленных адресов сокетов. [11] [12] Как обсуждалось выше, в случае TCP пара сокетов связана на каждом конце соединения с уникальным 4-кортежем.
Термин сокет восходит к публикации RFC 147 в 1971 году, когда он использовался в ARPANET. Большинство современных реализаций сокетов основаны на сокетах Беркли (1983) и других стеках, таких как Winsock (1991). API сокетов Беркли в Berkeley Software Distribution (BSD) возникло вместе с операционной системой Unix 4.2BSD в качестве API. Однако только в 1989 году Калифорнийский университет в Беркли смог выпустить версии своей операционной системы и сетевой библиотеки, свободные от лицензионных ограничений защищенного авторским правом Unix компании AT&T .
Примерно в 1987 году компания AT&T представила интерфейс транспортного уровня (TLI) на основе STREAMS в UNIX System V Release 3 (SVR3) [13] и продолжила его в Release 4 (SVR4). [14]
Другие ранние реализации были написаны для TOPS-20 , [15] MVS , [15] VM , [15] IBM-DOS (PCIP). [15] [16]
Сокет — это в первую очередь концепция, используемая на транспортном уровне набора протоколов Интернета или сеансовом уровне модели OSI . Сетевое оборудование, такое как маршрутизаторы , которые работают на интернет-уровне , и коммутаторы , которые работают на канальном уровне , не требуют реализации транспортного уровня. Однако сетевые брандмауэры с отслеживанием состояния , трансляторы сетевых адресов и прокси-серверы отслеживают активные пары сокетов. В многоуровневых коммутаторах и поддержке качества обслуживания (QoS) в маршрутизаторах потоки пакетов могут быть идентифицированы путем извлечения информации о парах сокетов.
Необработанные сокеты обычно доступны в сетевом оборудовании и используются для протоколов маршрутизации, таких как IGRP и OSPF , а также для протокола управляющих сообщений Интернета (ICMP).