Пора применить эрланг по его прямому назначению -- для реализации сетевого сервиса. Чаще всего такие сервисы делают на базе веб-сервера, поверх протокола HTTP . Но мы возьмем уровень ниже -- TCP и UDP сокеты.
Я полагаю, вы уже знаете, как устроена сеть, что такое Internet Protocol , User Datagram Protocol и Transmission Control Protocol . Эта тема большинству программистов известна. Но если вы почему-то ее упустили, то придется сперва наверстать упущенное, и потом вернуться к этому уроку.
Вспомним в общих чертах, что такое UDP:
Для работы с UDP используется модуль gen_udp .
Давайте запустим две ноды и наладим общение между ними.
На 1-й ноде откроем UDP на порту 2000:
1> {ok, Socket} = gen_udp:open(2000, ). {ok,#Port<0.587>}
Вызываем gen_udp:open/2 , передаем номер порта и список опций. Список всех возможных опций довольно большой, но нас интересуют две из них:
binary -- сокет открыт в бинарном режиме. Как вариант, сокет можно открыть в текстовом режиме, указав опцию list . Разница в том, как мы интерпретируем данные, полученные из сокета -- как поток байт, или как текст.
{active, true} -- сокет открыт в активном режиме, значит данные, приходящие в сокет, будут посылаться в виде сообщений в почтовый ящик потока, владельца сокета. Подробнее об этом ниже.
На 2-й ноде откроем UDP на порту 2001:
1> {ok, Socket} = gen_udp:open(2001, ). {ok,#Port<0.587>}
И пошлем сообщение с 1-й ноды на 2-ю:
2> gen_udp:send(Socket, {127,0,0,1}, 2001, <<"Hello from 2000">>). ok
Вызываем gen_udp:send/4 , передаем сокет, адрес и порт получателя, и само сообщение.
Адрес может быть доменным именем в виде строки или атома, или адресом IPv4 в виде кортежа из 4-х чисел, или адресом IPv6 в виде кортежа из 8 чисел.
На 2-й ноде убедимся, что сообщение пришло:
2> <0.587>,{127,0,0,1},2000,<<"Hello from 2000">>} ok
Сообщение приходит в виде кортежа {udp, Socket, SenderAddress, SenderPort, Packet} .
Пошлем сообщение с 2-й ноды на 1-ю:
3> gen_udp:send(Socket, {127,0,0,1}, 2000, <<"Hello from 2001">>). ok
На 1-й ноде убедимся, что сообщение пришло:
3> flush(). Shell got {udp,#Port<0.587>,{127,0,0,1},2001,<<"Hello from 2001">>} ok
Как видим, тут все просто.
И gen_udp , и gen_tcp , оба имеют одну важную настройку: режим работы с входящими данными. Это может быть либо активный режим {active, true} , либо пассивный режим {active, false} .
В активном режиме поток получает входящие пакеты в виде сообщений в своем почтовом ящике. И их можно получить и обработать вызовом receive, как любые другие сообщения.
Для udp сокета это сообщения вида:
{udp, Socket, SenderAddress, SenderPort, Packet}
мы их уже видели:
{udp,#Port<0.587>,{127,0,0,1},2001,<<"Hello from 2001">>}
Для tcp сокета аналогичные сообщения:
{tcp, Socket, Packet}
Активный режим прост в использовании, но опасен тем, что клиент может переполнить очередь сообщений потока, исчерпать память и обрушить ноду. Поэтому рекомендуется пассивный режим.
В пассивном режиме данные нужно забрать самому вызовами gen_udp:recv/3 и gen_tcp:recv/3 :
Gen_udp:recv(Socket, Length, Timeout) -> {ok, {Address, Port, Packet}} | {error, Reason} gen_tcp:recv(Socket, Length, Timeout) -> {ok, Packet} | {error, Reason}
Здесь мы указываем, сколько байт данных хотим прочитать из сокета. Если там есть эти данные, то мы получаем их сразу. Если нет, то вызов блокируется, пока не придет достаточное количество данных. Можно указать Timeout, чтобы не блокировать поток надолго.
Однако, gen_udp:recv игнорирует аргумент Length, и возвращает все данные, которые есть в сокете. Или блокируется и ждет каких-нибудь данных, если в сокете ничего нет. Непонятно, зачем вообще аргумент Length присутствует в АПИ.
Для gen_tcp:recv аргумент Length работает как надо. Если только не указана опция {packet, Size} , о которой речь пойдет ниже.
Еще есть вариант {active, once} . В этом случае сокет запускается в активном режиме, получает первый пакет данных как сообщение, и сразу переключается в пассивный режим.
Вспомним в общих чертах, что такое TCP:
Надо заметить, что долго держать постоянные соединения с многими тысячами клиентов накладно. Все соединения должны работать независимо друг от друга, а это значит -- в разных потоках. Для многих языков программирования (но не для эрланг) это серьезная проблема.
Именно поэтому так популярен протокол HTTP, который хоть и работает поверх TCP сокета, но подразумевает короткое время взаимодействия. Это позволяет относительно небольшим числом потоков (десятки-сотни) обслуживать значительно большее число клиентов (тысячи, десятки тысяч).
В некоторых случаях остается необходимость иметь долгоживущие постоянные соединения между клиентом и сервером. Например, для чатов или для многопользовательских игр. И здесь эрланг имеет мало конкурентов.
Для работы с TCP используется модуль gen_tcp .
Работать с TCP сокетом сложнее, чем с UDP. У нас появляются роли клиента и сервера, требующие разной реализации. Рассмотрим вариант реализации сервера.
Module(server). -export(). start() -> start(1234). start(Port) -> spawn(?MODULE, server, ), ok. server(Port) -> io:format("start server at port ~p~n", ), {ok, ListenSocket} = gen_tcp:listen(Port, ), ) || Id <- lists:seq(1, 5)], timer:sleep(infinity), ok. accept(Id, ListenSocket) -> io:format("Socket #~p wait for client~n", ), {ok, _Socket} = gen_tcp:accept(ListenSocket), io:format("Socket #~p, session started~n", ), handle_connection(Id, ListenSocket). handle_connection(Id, ListenSocket) -> receive {tcp, Socket, Msg} -> io:format("Socket #~p got message: ~p~n", ), gen_tcp:send(Socket, Msg), handle_connection(Id, ListenSocket); {tcp_closed, _Socket} ->
Есть два вида сокета: Listen Socket и Accept Socket . Listen Socket один, он принимает все запросы на соединение. Accept Socket нужно много, по одному для каждого соединения. Поток, в котором создается сокет, становится владельцем сокета. Если поток-владелец завершается, то сокет автоматически закрывается. Поэтому для каждого сокета мы создаем отдельный поток.
Listen Socket должен работать всегда, а для этого его поток-владелец не должен завершаться. Поэтому в server/1 мы добавили вызов timer:sleep(infinity) . Это заблокирует поток и не даст ему завершиться. Такая реализация, конечно, учебная. По хорошему нужно предусмотреть возможность корректно остановить сервер, а здесь этого нет.
Accept Socket и поток для него можно было бы создавать динамически, по мере появления клиентов. В начале можно создать один такой поток, вызвать в нем gen_tcp:accept/1 и ждать клиента. Этот вызов является блокирующим. Он завершается, когда появляется клиент. Дальше можно обслуживать текущего клиента в этом потоке, и создать новый поток, ожидающий нового клиента.
Но здесь у нас другая реализация. Мы заранее создаем пул из нескольких потоков, и все они ждут клиентов. После завершения работы с одним клиентом сокет не закрывается, а ждет нового. Таким образом, вместо того, чтобы постоянно открывать новые сокеты и закрывать старые, мы используем пул долгоживущих сокетов.
Это эффективнее при большом количестве клиентов. Во-первых, из-за того, что мы быстрее принимаем соединения. Во-вторых, из-за того, что мы более аккуратно распоряжаемся сокетами как системным ресурсом.
Потоки принадлежат эрланговской ноде, и мы можем создавать их сколько угодно. Но сокеты принадлежат операционной системе. Их количество лимитировано, хотя и довольно большое. (Речь идет о лимите на количество файловых дескрипторов, которое операционная система позволяет открыть пользовательскому процессу, обычно это 2 10 - 2 16).
Размер пула у нас игрушечный -- 5 пар поток-сокет. Реально нужен пул из нескольких сотен таких пар. Хорошо бы еще иметь возможность увеличивать и уменьшать этот пул в рантайме, чтобы подстраиваться под текущую нагрузку.
Текущая сессия с клиентом обрабатывается в функции handle_connection/2 . Видно, что сокет работает в активном режиме, и поток получает сообщения вида {tcp, Socket, Msg} , где Msg -- это бинарные данные, пришедшие от клиента. Эти данные мы отравляет обратно клиенту, то есть, реализуем банальный эхо-сервис:)
Когда клиент закрывает соединение, поток получает сообщение {tcp_closed, _Socket} , возвращается обратно в accept/2 и ждет следующего клиента.
Вот как выглядит работа такого сервера с двумя telnet-клиентами:
$ telnet localhost 1234 Trying 127.0.0.1... Connected to localhost. Escape character is "^]". hello from client 1 hello from client 1 some message from client 1 some message from client 1 new message from client 1 new message from client 1 client 1 is going to close connection client 1 is going to close connection ^] telnet> quit Connection closed.
$ telnet localhost 1234 Trying 127.0.0.1... Connected to localhost. Escape character is "^]". hello from client 2 hello from client 2 message from client 2 message from client 2 client 2 is still active client 2 is still active but client 2 is still active but client 2 is still active and now client 2 is going to close connection and now client 2 is going to close connection ^] telnet> quit Connection closed.
2> server:start(). start server at port 1234 ok Socket #1 wait for client Socket #2 wait for client Socket #3 wait for client Socket #4 wait for client Socket #5 wait for client Socket #1, session started Socket #1 got message: <<"hello from client 1\r\n">> Socket #1 got message: <<"some message from client 1\r\n">> Socket #2, session started Socket #2 got message: <<"hello from client 2\r\n">> Socket #2 got message: <<"message from client 2\r\n">> Socket #1 got message: <<"new message from client 1\r\n">> Socket #2 got message: <<"client 2 is still active\r\n">> Socket #1 got message: <<"client 1 is going to close connection\r\n">> Socket #1, session closed Socket #1 wait for client Socket #2 got message: <<"but client 2 is still active\r\n">> Socket #2 got message: <<"and now client 2 is going to close connection\r\n">> Socket #2, session closed Socket #2 wait for client
Это все хорошо, но хороший сервер должен работать в пассивном режиме. То есть, он должен получать данные от клиента не в виде сообщений в почтовый ящик, а вызовом gen_tcp:recv/2,3 .
Нюанс в том, что тут нужно указать, сколько данных мы хотим прочитать. А откуда сервер может знать, сколько данных ему прислал клиент? Ну, видимо, клиент сам должен сказать, сколько данных он собирается прислать. Для этого клиент сперва посылает небольшой служебный пакет, в котором указывает размер своих данных, и затем посылает сами данные.
Теперь нужно решить, сколько байт должен занимать этот служебный пакет. Если это будет 1 байт, то в него нельзя упаковать число больше 255. В 2 байта можно упаковать число 65535, в 4 байта 4294967295. 1 байт, очевидно, мало. Вполне вероятно, что клиенту будет нужно послать данных больше, чем 255 байт. Заголовок в 2 байта вполне подходит. Заголовок в 4 байта иногда бывает нужен.
Итак, клиент посылает служебный пакет размером в 2 байта, где указано, сколько данных последуют за ним, а затем сами эти данные:
Msg = <<"Hello">>,
Size = byte_size(Msg),
Header = <
Полный код клиента:
Module(client2).
-export().
start() ->
start("localhost", 1234).
start(Host, Port) ->
spawn(?MODULE, client, ).
send(Pid, Msg) ->
Pid ! {send, Msg},
ok.
stop(Pid) ->
Pid ! stop,
ok.
client(Host, Port) ->
io:format("Client ~p connects to ~p:~p~n", ),
{ok, Socket} = gen_tcp:connect(Host, Port, ),
loop(Socket).
loop(Socket) ->
receive
{send, Msg} ->
io:format("Client ~p send ~p~n", ),
Size = byte_size(Msg),
Header = <
Сервер сперва читает 2 байта, определяет размер данных и затем читает все данные:
{ok, Header} = gen_tcp:recv(Socket, 2),
<
В коде сервера функции start/0 и start/1 не изменились, остальное немного поменялось:
Server(Port) ->
io:format("start server at port ~p~n", ),
{ok, ListenSocket} = gen_tcp:listen(Port, ),
) || Id <- lists:seq(1, 5)],
timer:sleep(infinity),
ok.
accept(Id, ListenSocket) ->
io:format("Socket #~p wait for client~n", ),
{ok, Socket} = gen_tcp:accept(ListenSocket),
io:format("Socket #~p, session started~n", ),
handle_connection(Id, ListenSocket, Socket).
handle_connection(Id, ListenSocket, Socket) ->
case gen_tcp:recv(Socket, 2) of
{ok, Header} -> <
Пример сессии со стороны клиента:
2> Pid = client2:start(). Client <0.40.0> connects to "localhost":1234 <0.40.0> 3> client2:send(Pid, <<"Hello">>). Client <0.40.0> send <<"Hello">> ok Client <0.40.0> got message: <<"Hello">> 4> client2:send(Pid, <<"Hello again">>). Client <0.40.0> send <<"Hello again">> ok Client <0.40.0> got message: <<"Hello again">> 5> client2:stop(Pid). Client <0.40.0> closes connection and stops ok
И со стороны сервера:
2> server2:start(). start server at port 1234 ok Socket #1 wait for client Socket #2 wait for client Socket #3 wait for client Socket #4 wait for client Socket #5 wait for client Socket #1, session started Socket #1 got message: <<"Hello">> Socket #1 got message: <<"Hello again">> Socket #1, session closed Socket #1 wait for client
Все это хорошо, но на самом деле нет необходимости вручную разбираться с заголовочным пакетом. Это уже реализовано в gen_tcp . Нужно указать размер служебного пакета в настройках при открытии сокета на стороне клиента:
{ok, Socket} = gen_tcp:connect(Host, Port, ),
и на стороне сервера:
{ok, ListenSocket} = gen_tcp:listen(Port, ),
и необходимость самому формировать и разбирать эти заголовки пропадает.
На стороне клиента упрощается отправка:
Gen_tcp:send(Socket, Msg),
и на стороне сервера упрощается получение:
Handle_connection(Id, ListenSocket, Socket) -> case gen_tcp:recv(Socket, 0) of {ok, Msg} -> io:format("Socket #~p got message: ~p~n", ), gen_tcp:send(Socket, Msg), handle_connection(Id, ListenSocket, Socket); {error, closed} -> io:format("Socket #~p, session closed ~n", ), accept(Id, ListenSocket) end.
Теперь при вызове gen_tcp:recv/2 мы указываем Length = 0. gen_tcp сам знает, сколько байт нужно прочитать из сокета.
Кроме варианта со служебным заголовком, есть и другой подход. Можно читать из сокета по одному байту, пока не встретится специальный байт, символизирующий конец пакета. Это может быть нулевой байт, или символ перевода строки.
Такой вариант характерен для текстовых протоколов (SMTP, POP3, FTP).
Писать свою реализацию чтения из сокета нет необходимости, все уже реализовано в gen_tcp . Нужно только указать в настройках сокета вместо {packet, 2} опцию {packet, line} .
{ok, ListenSocket} = gen_tcp:listen(Port, ),
В остальном код сервера остается без изменений. Но теперь мы можем опять вернуться к telnet-клиенту.
$ telnet localhost 1234 Trying 127.0.0.1... Connected to localhost. Escape character is "^]". hello hello hello again hello again ^] telnet> quit Connection closed.
TCP-сервер, текстовый протокол и telnet-клиент нам понадобятся в курсовой работе.
Последнее обновление: 31.10.2015
Протокол UDP не требует установки постоянного подключения, и, возможно, многим покажется легче работать с UDP, чем с TCP. Большинство принципов при работе с UDP те же, что и с TCP.
Вначале создается сокет:
Socket socket = new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp);
Если сокет должен получать сообщения, то надо привязать его к локальному адресу и одному из портов с помощью метода Bind:
IPEndPoint localIP = new IPEndPoint(IPAddress.Parse("127.0.0.1"), 5555); socket.Bind(localIP);
После этого можно отправлять и получать сообщения. Для получения сообщений используется метод ReceiveFrom() :
Byte data = new byte; // буфер для получаемых данных //адрес, с которого пришли данные EndPoint remoteIp = new IPEndPoint(IPAddress.Any, 0); int bytes = socket.ReceiveFrom(data, ref remoteIp);
В качестве параметра в метод передается массив байтов, в который надо считать данные, и удаленная точка, с которой приходят эти данные. Метод возвращает количество считанных байтов.
Для отправки данных используется метод SendTo() :
String message = Console.ReadLine(); byte data = Encoding.Unicode.GetBytes(message); EndPoint remotePoint = new IPEndPoint(IPAddress.Parse("127.0.0.1"), remotePort); listeningSocket.SendTo(data, remotePoint);
В метод передается массив отправляемых данных, а также адрес, по которому эти данные надо отправить.
Создадим программу UDP-клиента:
Using System; using System.Text; using System.Threading.Tasks; using System.Net; using System.Net.Sockets; namespace SocketUdpClient { class Program { static int localPort; // порт приема сообщений static int remotePort; // порт для отправки сообщений static Socket listeningSocket; static void Main(string args) { Console.Write("Введите порт для приема сообщений: "); localPort = Int32.Parse(Console.ReadLine()); Console.Write("Введите порт для отправки сообщений: "); remotePort = Int32.Parse(Console.ReadLine()); Console.WriteLine("Для отправки сообщений введите сообщение и нажмите Enter"); Console.WriteLine(); try { listeningSocket = new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp); Task listeningTask = new Task(Listen); listeningTask.Start(); // отправка сообщений на разные порты while (true) { string message = Console.ReadLine(); byte data = Encoding.Unicode.GetBytes(message); EndPoint remotePoint = new IPEndPoint(IPAddress.Parse("127.0.0.1"), remotePort); listeningSocket.SendTo(data, remotePoint); } } catch (Exception ex) { Console.WriteLine(ex.Message); } finally { Close(); } } // поток для приема подключений private static void Listen() { try { //Прослушиваем по адресу IPEndPoint localIP = new IPEndPoint(IPAddress.Parse("127.0.0.1"), localPort); listeningSocket.Bind(localIP); while (true) { // получаем сообщение StringBuilder builder = new StringBuilder(); int bytes = 0; // количество полученных байтов byte data = new byte; // буфер для получаемых данных //адрес, с которого пришли данные EndPoint remoteIp = new IPEndPoint(IPAddress.Any, 0); do { bytes = listeningSocket.ReceiveFrom(data, ref remoteIp); builder.Append(Encoding.Unicode.GetString(data, 0, bytes)); } while (listeningSocket.Available > 0); // получаем данные о подключении IPEndPoint remoteFullIp = remoteIp as IPEndPoint; // выводим сообщение Console.WriteLine("{0}:{1} - {2}", remoteFullIp.Address.ToString(), remoteFullIp.Port, builder.ToString()); } } catch (Exception ex) { Console.WriteLine(ex.Message); } finally { Close(); } } // закрытие сокета private static void Close() { if (listeningSocket != null) { listeningSocket.Shutdown(SocketShutdown.Both); listeningSocket.Close(); listeningSocket = null; } } } }
Вначале пользователь вводит порты для приема данных и для отправки. Предполагается, что два приложения клиента, которые будут между собой взаимодействовать, запущены на одной локальной машине. Если адреса клиентов различаются, то можно предусмотреть и ввода адреса для отправки данных.
После ввода портов запускается задача на прослушивание входящих сообщений. В отличие от tcp-сервера здесь не надо вызывать методы Listen и Accept. В бесконечном цикле мы напрямую можем получить получение данные с помощью метода ReceiveFrom() , который блокирует вызывающий поток, пока не придет очередная порция данных.
Этот метод возвращает через ref-параметр удаленную точку, с которой получены данные:
IPEndPoint remoteFullIp = remoteIp as IPEndPoint;
То есть, не смотря на то, что в данном случае прием и отправка сообщений разграничены и текущий клиент отправляет данные только на введенный вначале порт, но мы вполне можем добавить возможность ответа на сообщения, используя данные полученной удаленной точки (адрес и порт).
В главном потоке происходит отправка сообщений с помощью метода SendTo()
Таким образом, приложение сразу осуществляет функции и сервера, и клиента.
Теперь запустим две копии приложения и введем разные данные для портов. Первый клиент:
Введите порт для приема сообщений: 4004 Введите порт для отправки сообщений: 4005 Для отправки сообщений введите сообщение и нажмите Enter 127.0.0.1:4005 - привет порт 4004 добрый день, порт 4005 чудная погодка
Второй клиент:
Введите порт для приема сообщений: 4005 Введите порт для отправки сообщений: 4004 Для отправки сообщений введите сообщение и нажмите Enter привет порт 4004 127.0.0.1:4004 - добрый день, порт 4005 127.0.0.1:4004 - чудная погодка
Сокеты
Сокет - это один конец двустороннего канала связи между двумя программами, работающими в сети. Соединяя вместе два сокета, можно передавать данные между разными процессами (локальными или удаленными). Реализация сокетов обеспечивает инкапсуляцию протоколов сетевого и транспортного уровней.
Первоначально сокеты были разработаны для UNIX в Калифорнийском университете в Беркли. В UNIX обеспечивающий связь метод ввода-вывода следует алгоритму open/read/write/close. Прежде чем ресурс использовать, его нужно открыть, задав соответствующие разрешения и другие параметры. Как только ресурс открыт, из него можно считывать или в него записывать данные. После использования ресурса пользователь должен вызывать метод Close(), чтобы подать сигнал операционной системе о завершении его работы с этим ресурсом.
Когда в операционную систему UNIX были добавлены средства межпроцессного взаимодействия (Inter-Process Communication, IPC) и сетевого обмена, был заимствован привычный шаблон ввода-вывода. Все ресурсы, открытые для связи, в UNIX и Windows идентифицируются дескрипторами. Эти дескрипторы, или описатели (handles) , могут указывать на файл, память или какой-либо другой канал связи, а фактически указывают на внутреннюю структуру данных, используемую операционной системой. Сокет, будучи таким же ресурсом, тоже представляется дескриптором. Следовательно, для сокетов жизнь дескриптора можно разделить на три фазы: открыть (создать) сокет, получить из сокета или отправить сокету и в конце концов закрыть сокет.
Интерфейс IPC для взаимодействия между разными процессами построен поверх методов ввода-вывода. Они облегчают для сокетов отправку и получение данных. Каждый целевой объект задается адресом сокета, следовательно, этот адрес можно указать в клиенте, чтобы установить соединение с целью.
Существуют два основных типа сокетов - потоковые сокеты и дейтаграммные.
Потоковый сокет - это сокет с установленным соединением, состоящий из потока байтов, который может быть двунаправленным, т, е. через эту конечную точку приложение может и передавать, и получать данные.
Потоковый сокет гарантирует исправление ошибок, обрабатывает доставку и сохраняет последовательность данных. На него можно положиться в доставке упорядоченных, сдублированных данных. Потоковый сокет также подходит для передачи больших объемов данных, поскольку накладные расходы, связанные с установлением отдельного соединения для каждого отправляемого сообщения, может оказаться неприемлемым для небольших объемов данных. Потоковые сокеты достигают этого уровня качества за счет использования протокола Transmission Control Protocol (TCP) . TCP обеспечивает поступление данных на другую сторону в нужной последовательности и без ошибок.
Для этого типа сокетов путь формируется до начала передачи сообщений. Тем самым гарантируется, что обе участвующие во взаимодействии стороны принимают и отвечают. Если приложение отправляет получателю два сообщения, то гарантируется, что эти сообщения будут получены в той же последовательности.
Однако, отдельные сообщения могут дробиться на пакеты, и способа определить границы записей не существует. При использовании TCP этот протокол берет на себя разбиение передаваемых данных на пакеты соответствующего размера, отправку их в сеть и сборку их на другой стороне. Приложение знает только, что оно отправляет на уровень TCP определенное число байтов и другая сторона получает эти байты. В свою очередь TCP эффективно разбивает эти данные на пакеты подходящего размера, получает эти пакеты на другой стороне, выделяет из них данные и объединяет их вместе.
Потоки базируются на явных соединениях: сокет А запрашивает соединение с сокетом В, а сокет В либо соглашается с запросом на установление соединения, либо отвергает его.
Если данные должны гарантированно доставляться другой стороне или размер их велик, потоковые сокеты предпочтительнее дейтаграммных. Следовательно, если надежность связи между двумя приложениями имеет первостепенное значение, выбирайте потоковые сокеты.
Сервер электронной почты представляет пример приложения, которое должно доставлять содержание в правильном порядке, без дублирования и пропусков. Потоковый сокет рассчитывает, что TCP обеспечит доставку сообщений по их назначениям.
Дейтаграммные сокеты иногда называют сокетами без организации соединений, т. е. никакого явного соединения между ними не устанавливается - сообщение отправляется указанному сокету и, соответственно, может получаться от указанного сокета.
Потоковые сокеты по сравнению с дейтаграммными действительно дают более надежный метод, но для некоторых приложений накладные расходы, связанные с установкой явного соединения, неприемлемы (например, сервер времени суток, обеспечивающий синхронизацию времени для своих клиентов). В конце концов на установление надежного соединения с сервером требуется время, которое просто вносит задержки в обслуживание, и задача серверного приложения не выполняется. Для сокращения накладных расходов нужно использовать дейтаграммные сокеты.
Использование дейтаграммных сокетов требует, чтобы передачей данных от клиента к серверу занимался User Datagram Protocol (UDP) . В этом протоколе на размер сообщений налагаются некоторые ограничения, и в отличие от потоковых сокетов, умеющих надежно отправлять сообщения серверу-адресату, дейтаграммные сокеты надежность не обеспечивают. Если данные затерялись где-то в сети, сервер не сообщит об ошибках.
Кроме двух рассмотренных типов существует также обобщенная форма сокетов, которую называют необрабатываемыми или сырыми.
Главная цель использования сырых сокетов состоит в обходе механизма, с помощью которого компьютер обрабатывает TCP/IP. Это достигается обеспечением специальной реализации стека TCP/IP, замещающей механизм, предоставленный стеком TCP/IP в ядре - пакет непосредственно передается приложению и, следовательно, обрабатывается гораздо эффективнее, чем при проходе через главный стек протоколов клиента.
По определению, сырой сокет - это сокет, который принимает пакеты, обходит уровни TCP и UDP в стеке TCP/IP и отправляет их непосредственно приложению.
При использовании таких сокетов пакет не проходит через фильтр TCP/IP, т.е. никак не обрабатывается, и предстает в своей сырой форме. В таком случае обязанность правильно обработать все данные и выполнить такие действия, как удаление заголовков и разбор полей, ложится на получающее приложение - все равно, что включить в приложение небольшой стек TCP/IP.
Однако нечасто может потребоваться программа, работающая с сырыми сокетами. Если вы не пишете системное программное обеспечение или программу, аналогичную анализатору пакетов, вникать в такие детали не придется. Сырые сокеты главным образом используются при разработке специализированных низкоуровневых протокольных приложений. Например, такие разнообразные утилиты TCP/IP, как trace route, ping или arp, используют сырые сокеты.
Работа с сырыми сокетами требует солидного знания базовых протоколов TCP/UDP/IP.
Порт определен, чтобы разрешить задачу одновременного взаимодействия с несколькими приложениями. По существу с его помощью расширяется понятие IP-адреса. Компьютер, на котором в одно время выполняется несколько приложений, получая пакет из сети, может идентифицировать целевой процесс, пользуясь уникальным номером порта, определенным при установлении соединения.
Сокет состоит из IP-адреса машины и номера порта, используемого приложением TCP. Поскольку IP-адрес уникален в Интернете, а номера портов уникальны на отдельной машине, номера сокетов также уникальны во всем Интернете. Эта характеристика позволяет процессу общаться через сеть с другим процессом исключительно на основании номера сокета.
За определенными службами номера портов зарезервированы - это широко известные номера портов, например порт 21, использующийся в FTP. Ваше приложение может пользоваться любым номером порта, который не был зарезервирован и пока не занят. Агентство Internet Assigned Numbers Authority (IANA) ведет перечень широко известных номеров портов.
Обычно приложение клиент-сервер, использующее сокеты, состоит из двух разных приложений - клиента, инициирующего соединение с целью (сервером), и сервера, ожидающего соединения от клиента.
Например, на стороне клиента, приложение должно знать адрес цели и номер порта. Отправляя запрос на соединение, клиент пытается установить соединение с сервером:
Если события развиваются удачно, при условии что сервер запущен прежде, чем клиент попытался с ним соединиться, сервер соглашается на соединение. Дав согласие, серверное приложение создает новый сокет для взаимодействия именно с установившим соединение клиентом:
Теперь клиент и сервер могут взаимодействовать между собой, считывая сообщения каждый из своего сокета и, соответственно, записывая сообщения.
Поддержку сокетов в.NET обеспечивают классы в пространстве имен System.Net.Sockets - начнем с их краткого описания.
| Класс | Описание |
|---|---|
| MulticastOption | Класс MulticastOption устанавливает значение IP-адреса для присоединения к IP-группе или для выхода из нее. |
| NetworkStream | Класс NetworkStream реализует базовый класс потока, из которого данные отправляются и в котором они получаются. Это абстракция высокого уровня, представляющая соединение с каналом связи TCP/IP. |
| TcpClient | Класс TcpClient строится на классе Socket, чтобы обеспечить TCP-обслуживание на более высоком уровне. TcpClient предоставляет несколько методов для отправки и получения данных через сеть. |
| TcpListener | Этот класс также построен на низкоуровневом классе Socket. Его основное назначение - серверные приложения. Он ожидает входящие запросы на соединения от клиентов и уведомляет приложение о любых соединениях. |
| UdpClient | UDP - это протокол, не организующий соединение, следовательно, для реализации UDP-обслуживания в.NET требуется другая функциональность. |
| SocketException | Это исключение порождается, когда в сокете возникает ошибка. |
| Socket | Последний класс в пространстве имен System.Net.Sockets - это сам класс Socket. Он обеспечивает базовую функциональность приложения сокета. |
Класс Socket играет важную роль в сетевом программировании, обеспечивая функционирование как клиента, так и сервера. Главным образом, вызовы методов этого класса выполняют необходимые проверки, связанные с безопасностью, в том числе проверяют разрешения системы безопасности, после чего они переправляются к аналогам этих методов в Windows Sockets API.
Прежде чем обращаться к примеру использования класса Socket, рассмотрим некоторые важные свойства и методы этого класса:
| Свойство или метод | Описание |
|---|---|
| AddressFamily | Дает семейство адресов сокета - значение из перечисления Socket.AddressFamily. |
| Available | Возвращает объем доступных для чтения данных. |
| Blocking | Дает или устанавливает значение, показывающее, находится ли сокет в блокирующем режиме. |
| Connected | Возвращает значение, информирующее, соединен ли сокет с удаленным хостом. |
| LocalEndPoint | Дает локальную конечную точку. |
| ProtocolType | Дает тип протокола сокета. |
| RemoteEndPoint | Дает удаленную конечную точку сокета. |
| SocketType | Дает тип сокета. |
| Accept() | Создает новый сокет для обработки входящего запроса на соединение. |
| Bind() | Связывает сокет с локальной конечной точкой для ожидания входящих запросов на соединение. |
| Close() | Заставляет сокет закрыться. |
| Connect() | Устанавливает соединение с удаленным хостом. |
| GetSocketOption() | Возвращает значение SocketOption. |
| IOControl() | Устанавливает для сокета низкоуровневые режимы работы. Этот метод обеспечивает низкоуровневый доступ к лежащему в основе классу Socket. |
| Listen() | Помещает сокет в режим прослушивания (ожидания). Этот метод предназначен только для серверных приложений. |
| Receive() | Получает данные от соединенного сокета. |
| Poll() | Определяет статус сокета. |
| Select() | Проверяет статус одного или нескольких сокетов. |
| Send() | Отправляет данные соединенному сокету. |
| SetSocketOption() | Устанавливает опцию сокета. |
| Shutdown() | Запрещает операции отправки и получения данных на сокете. |
35 ответов
Сокет TCP является экземпляром конечной точки , определяемым IP-адресом и портом в контексте определенного TCP-соединения или состояния прослушивания.
Порт - это идентификатор виртуализации , определяющий конечную точку службы (в отличие от конечной точки экземпляра службы или ее идентификатора сеанса).
Сокет TCP не является соединением , это конечная точка определенного соединения.
Могут быть параллельные подключения к конечной точке службы , поскольку соединение идентифицируется как локальными, так и удаленными конечными точками, что позволяет трафику маршрутизироваться в конкретный экземпляр службы.
Для данной комбинации адресов и портов может быть только один разъем-слушатель.
Это был интересный вопрос, который заставил меня пересмотреть некоторые вещи, которые, как я думал, я знал наизнанку. Вы бы подумали, что такое имя, как "сокет", было бы само собой разумеющимся: очевидно, было выбрано, чтобы вызвать образы конечной точки, в которую вы подключаете сетевой кабель, там есть сильные функциональные параллели. Тем не менее, на сетевом языке слово "сокет" несет столько багажа, что необходимо тщательное повторное рассмотрение.
В самом широком смысле, порт является точкой входа или выхода. Французское слово porte, хотя и не используется в сетевом контексте, буквально означает дверь или шлюз, что еще раз подчеркивает тот факт, что порты являются транспортными конечными точками, отправляете ли вы данные или крупные стальные контейнеры.
В целях этой дискуссии я ограничу рассмотрение контекста сетей TCP-IP. Модель OSI очень хорошо, но никогда не была полностью реализована, а тем более широко развернута в условиях высокого напряжения с высоким трафиком.
Комбинация IP-адреса и порта строго известна как конечная точка и иногда называется сокетом. Это использование связано с RFC793, оригинальной спецификацией TCP.
TCP-соединение определяется двумя конечными точками aka сокетами.
Конечная точка (сокет) определяется комбинацией сетевого адреса и идентификатора порта. Обратите внимание, что адрес/порт не полностью идентифицирует сокет (подробнее об этом позже).
Назначение портов - это различать несколько конечных точек на заданном сетевом адресе. Можно сказать, что порт является виртуализированной конечной точкой. Эта виртуализация делает возможным несколько параллельных подключений на одном сетевом интерфейсе.
Это пара сокетов (4-кортеж состоящий из IP-адреса клиента, номер порта клиента, IP-адрес сервера, и номер порта сервера), который указывает две конечные точки, которые однозначно идентифицирует каждое TCP-соединение в интернет. (TCP-IP Illustrated Volume 1, W. Richard Stevens)
В большинстве языков, основанных на C, TCP-соединения устанавливаются и обрабатываются с использованием методов в экземпляре класса Socket. Хотя распространено работать на более высоком уровне абстракции, обычно это экземпляр класса NetworkStream, он обычно предоставляет ссылку на объект сокета. К кодеру этот объект сокета, как представляется, представляет соединение, потому что соединение создается и управляется с помощью методов объекта сокета.
В С#, чтобы установить TCP-соединение (к существующему слушателю), вы сначала создаете TcpClient. Если вы не укажете конечную точку для конструктора TcpClient, она использует значения по умолчанию - так или иначе определяется локальная конечная точка. Затем вы вызываете Connect метод на созданном экземпляре. Этот метод требует параметра, описывающего другую конечную точку.
Все это немного запутывает и заставляет вас поверить, что сокет - это соединение, которое является блокировкой. Я работал под этим недоразумением, пока Ричард Дорман не задал вопрос.
Проделав много чтения и мышления, я теперь убежден, что было бы гораздо разумнее иметь класс TcpConnection с конструктором, который принимает два аргумента: LocalEndpoint и RemoteEndpoint. Вероятно, вы могли бы поддержать один аргумент RemoteEndpoint, когда допустимы значения по умолчанию для локальной конечной точки. Это неоднозначно для многоъядерных компьютеров, но неоднозначность может быть решена с использованием таблицы маршрутизации путем выбора интерфейса с кратчайшим маршрутом к удаленной конечной точке.
Ясность будет повышена и в других отношениях. Сокет не идентифицируется комбинацией IP-адреса и порта:
[...] TCP демультиплексирует входящие сегменты, используя все четыре значения, которые содержат локальные и внешние адреса: IP-адрес получателя, номер порта назначения, IP-адрес источника и номер порта источника. TCP не может определить, какой процесс получает входящий сегмент, только глядя на порт назначения. Кроме того, единственная из [различных] конечных точек в [данном номере порта], которая будет принимать входящие запросы на соединение, является одной в состоянии прослушивания. (p255, TCP-IP Illustrated Volume 1, W. Richard Stevens)
Как вы можете видеть, не просто возможно, но вполне вероятно, что сетевая служба имеет множество сокетов с одним и тем же адресом/портом, но только один сокет-слушатель в конкретной комбинации адресов/портов. Типичные реализации библиотеки представляют собой класс сокетов, экземпляр которого используется для создания и управления соединением. Это крайне неудачно, поскольку оно вызывает путаницу и привело к широкому сочетанию двух концепций.
Хаграваль не верит мне (см. комментарии), так что здесь настоящий образец. Я подключил веб-браузер к http://dilbert.com , а затем запустил netstat -an -p tcp . Последние шесть строк вывода содержат два примера того, что адреса и порта недостаточно, чтобы однозначно идентифицировать сокет. Существует два разных соединения между 192.168.1.3 (моя рабочая станция) и 54.252.92.236:80
TCP 192.168.1.3:63240 54.252.94.236:80 SYN_SENT TCP 192.168.1.3:63241 54.252.94.236:80 SYN_SENT TCP 192.168.1.3:63242 207.38.110.62:80 SYN_SENT TCP 192.168.1.3:63243 207.38.110.62:80 SYN_SENT TCP 192.168.1.3:64161 65.54.225.168:443 ESTABLISHED
Поскольку сокет является конечной точкой соединения, есть два сокета с комбинацией адресов/портов 207.38.110.62:80 и еще два с комбинацией адресов/портов 54.252.94.236:80 .
Я думаю, что неправильное понимание Хаграваля возникает из моего очень осторожного использования слова "идентифицирует". Я имею в виду "полностью, однозначно и однозначно идентифицировать". В приведенном выше примере имеются две конечные точки с комбинацией адрес/порт 54.252.94.236:80 . Если у вас есть адрес и порт, у вас недостаточно информации, чтобы разделить эти разъемы. Недостаточно информации для идентификации сокета.
В абзаце втором раздела 2.7 RFC793 говорится:
Соединение полностью определяется парой сокетов на концах. локальная розетка может участвовать во многих соединениях с различными зарубежными Розетки.
Это определение сокета не полезно с точки зрения программирования, поскольку оно не совпадает с объектом сокета, который является конечной точкой для определенного соединения. Для программиста, и большая часть этой аудитории является программистом, это жизненно важное функциональное различие.
TCP-IP Иллюстрированный том 1 Протоколы, W. Richard Stevens, 1994 Addison Wesley
Сокет представляет собой одно соединение между двумя сетевыми приложениями. Эти два приложения номинально работают на разных компьютерах, но сокеты также могут использоваться для межпроцессного взаимодействия на одном компьютере. Приложения могут создавать несколько сокетов для связи друг с другом. Сокеты являются двунаправленными, что означает, что обе стороны соединения способны отправлять и получать данные. Поэтому сокет может быть создан теоретически на любом уровне модели OSI с 2 вверх. Программисты часто используют сокеты в сетевом программировании, хотя и косвенно. Библиотеки программирования, такие как Winsock, скрывают многие низкоуровневые детали программирования сокетов. Розетки широко используются с начала 1980-х годов.
Порт представляет собой конечную точку или "канал" для сетевой связи. Номера портов позволяют различным приложениям на одном компьютере использовать сетевые ресурсы, не мешая друг другу. Номера портов наиболее часто встречаются в сетевом программировании, особенно в программировании сокетов. Иногда, однако, номера портов становятся видимыми для случайного пользователя. Например, некоторые веб-сайты, которые человек посещает в Интернете, используют следующий URL-адрес:
С некоторой аналогией
Хотя для сокетов уже было дано много технических деталей ... Я хотел бы добавить свой ответ, на всякий случай, если кто-то все еще не может почувствовать разницу между ip, портом и сокетами
Рассмотрим сервер S ,
и скажем, человеку X, Y, Z нужна служба (скажем, служба чата) с этого сервера S
IP-адрес говорит → кто? тот сервер чата "S", с которым X, Y, Z хочет связаться
хорошо, вы получили "кто сервер"
но предположим, что сервер "S" также предоставляет некоторые другие услуги другим людям, скажем, "S" предоставляет услуги хранения для лиц A, B, C
порт говорит ---> который? сервис, который вам (X, Y, Z) нужен, т.е. сервис чата, а не сервис хранения
ладно.., вы заставляете сервер знать, что вам нужен чат-сервис, а не хранилище
вам три года, и сервер может захотеть идентифицировать все три по-разному
приходит розетка
теперь сокет говорит → какой? конкретное соединение
то есть, скажем,
розетка 1 для человека X
розетка 2 для человека Y
и розетка 3 для человека Z
Я надеюсь, что это помогает кому-то, кто был все еще смущен:)
Во-первых, я думаю, мы должны начать с небольшого понимания того, что составляет получение пакета от A до B.
Общим определением для сети является использование модели OSI , которая разделяет сеть на несколько слоев в соответствии с назначением. Есть несколько важных, которые мы рассмотрим здесь:
TCP содержит, помимо прочего, концепцию ports . Это фактически разные конечные точки данных на том же IP-адресе, к которому может привязываться Internet Socket (AF_INET).
Короткий короткий ответ.
A порт может быть описан как внутренний адрес внутри хоста, который идентифицирует программу или процесс.
A socket можно описать как программный интерфейс , позволяющий программе общаться с другими программами или процессами, в Интернете или локально.
Как правило, вы получите много теоретического, но один из самых простых способов различить эти два понятия заключается в следующем:
Чтобы получить услугу, вам нужен сервисный номер. Этот сервисный номер называется портом. Просто как тот.
Например, HTTP как служба работает на порту 80.
Теперь многие люди могут запросить услугу, и соединение с клиент-сервером установлено. Будет много связей. Каждое соединение представляет клиента. Чтобы поддерживать каждое соединение, сервер создает сокет для каждого соединения для поддержки своего клиента.
Кажется, что есть много ответов, сравнивающих сокет с соединением между двумя ПК. Я думаю, что это абсолютно неверно. Сокет всегда был конечной точкой на 1 ПК, который может быть или не быть подключен - конечно, мы все использовали приемник или UDP-сокеты * в какой-то момент. Важная часть заключается в том, что он адресный и активный. Отправка сообщения в файл 1.1.1.1:1234 вряд ли будет работать, поскольку для этой конечной точки нет сокета.
Сокеты специфичны для протокола - поэтому реализация уникальности заключается в том, что TCP / и UDP / использует * (ipaddress: порт), отличается от, например, IPX (Сеть, Node и... гейм, сокет - но другой сокет, чем под общим термином "сокет". Номера сокетов IPX эквивалентны IP-портам). Но все они предлагают уникальную адресуемую конечную точку.
Поскольку IP стал доминирующим протоколом, порт (в сетевых терминах) стал сингулярным с номером порта UDP или TCP, который является частью адреса сокета.
UDP не имеет отношения к подключению - это означает, что виртуальная схема между двумя конечными точками никогда не создается. Однако в качестве конечной точки мы по-прежнему относимся к UDP-сокетам . Функции API дают понять, что оба являются просто разными типами сокетов. SOCK_DGRAM - это UDP (просто отправка сообщения), а SOCK_STREAM - TCP (создание виртуальной схемы).
Технически, заголовок IP содержит IP-адрес, а протокол поверх IP (UDP или TCP) содержит номер порта. Это позволяет использовать другие протоколы (например, ICMP , которые не имеют номеров портов, но имеют информацию о IP-адресе).
Это термины из двух разных доменов: "порт" - это концепция из сетей TCP/IP, "сокет" - это API (программирование). "Сокет" создается (в коде), беря порт, имя хоста или сетевой адаптер и объединяя их в структуру данных, которую вы можете использовать для отправки или получения данных.
Соединения TCP-IP - это двунаправленные пути, соединяющие один адрес: комбинация портов с другим адресом: комбинация портов. Поэтому, всякий раз, когда вы открываете соединение с локальной машины на порт на удаленном сервере (например, www.google.com:80), вы также связываете новый номер порта на вашем компьютере с подключением, чтобы сервер мог отправлять вещи назад к вам (например, 127.0.0.1:65234). Полезно использовать netstat для просмотра ваших соединений с компьютером:
> netstat -nWp tcp (on OS X) Active Internet connections Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp4 0 0 192.168.0.6.49871 17.172.232.57.5223 ESTABLISHED ...
Сокет - это особый тип дескриптора файла, который используется процессом для запроса сетевых сервисов из операционной системы. Адрес сокета - это тройной: {protocol, local-address, local-process}, где локальный процесс идентифицируется номером порта.
В наборе TCP/IP, например:
{tcp, 193.44.234.3, 12345}
Разговор - это линия связи между двумя процессами, таким образом изображающая связь между двумя. Ассоциацией является 5-кортеж, который полностью определяет два процесса, которые содержат соединение: {protocol, local-address, local-process, foreign-address, foreign-process}
В наборе TCP/IP, например:
{tcp, 193.44.234.3, 1500, 193.44.234.5, 21}
может быть допустимой ассоциацией.
Полу-ассоциация: {протокол, локальный адрес, локальный процесс}
{protocol, foreign-address, foreign-process}
которые определяют каждую половину соединения.
Полусвязь также называется сокет или транспортный адрес. То есть, сокет является конечной точкой для связи, которая может быть названа и адресована в сети. Интерфейс сокета является одним из нескольких интерфейсов прикладного программирования (API) для протоколов связи. Разработанный как универсальный коммуникационный интерфейс программирования, он впервые был внедрен системой UNIX 4.2BSD. Хотя он не был стандартизирован, он стал фактическим промышленным стандартом.
Порт был самой легкой частью, это просто уникальный идентификатор сокета. Сокет - это то, что процессы могут использовать для установления соединений и общения друг с другом. У Tall Jeff была отличная телефонная аналогия, которая не была идеальной, поэтому я решил ее исправить:
Приложение состоит из пары процессов, которые обмениваются данными по сети (пара клиент-сервер). Эти процессы отправляют и получают сообщения в сеть и из нее через программный интерфейс сокет . Учитывая аналогию, представленную в книге "Компьютерная сеть: подход сверху вниз". Существует дом, который хочет общаться с другим домом. Здесь дом аналогичен процессу и двери к розетке. Процесс отправки предполагает, что на другой стороне двери есть инфраструктура, которая будет передавать данные в пункт назначения. Как только сообщение поступит с другой стороны, оно проходит через дверь приемника (гнездо) в дом (процесс). Эта иллюстрация из той же книги может помочь вам:
Сокеты являются частью транспортного уровня, который обеспечивает логическую связь с приложениями. Это означает, что с точки зрения приложения оба узла напрямую связаны друг с другом, хотя между ними существует множество маршрутизаторов и/или переключателей. Таким образом, сокет не является самим соединением, это конечная точка соединения. Протоколы транспортного уровня реализуются только на хостах, а не на промежуточных маршрутизаторах.
Порты
предоставляют средства внутренней адресации для машины. Основная цель - позволить нескольким процессам отправлять и получать данные по сети без вмешательства в другие процессы (их данные). Все сокеты снабжены номером порта. Когда сегмент поступает на хост, транспортный уровень исследует номер порта назначения сегмента. Затем он переводит сегмент в соответствующий сокет. Это задание доставки данных в сегменте транспортного уровня в правильный сокет называется демпплексированием
. Затем данные сегмента передаются процессу, присоединенному к сокету.
Сокет - это структура вашего программного обеспечения. Это более-менее файл; он имеет операции, такие как чтение и запись. Это не физическая вещь; это способ для вашего программного обеспечения ссылаться на физические вещи.
Порт - вещь, подобная устройству. Каждый хост имеет одну или несколько сетей (физически); хост имеет адрес в каждой сети. Каждый адрес может иметь тысячи портов.
Только один сокет может использовать порт по адресу. Розетка распределяет порт примерно так же, как выделение устройства для ввода/вывода файловой системы. Как только порт будет выделен, никакой другой сокет не сможет подключиться к этому порту. Порт будет освобожден, когда сокет будет закрыт.
Сокет - это одна конечная точка двусторонней линии связи между двумя программами, запущенными в сети. Сокет привязан к номеру порта, так что уровень TCP может идентифицировать приложение, для которого данные предназначены для отправки.
Относительная терминология TCP/IP, которую я предполагаю, подразумевает этот вопрос. В условиях неспециалиста:
PORT - это номер телефона определенного дома в определенном почтовом индексе. Почтовый код города можно рассматривать как IP-адрес города и всех домов в этом городе.
SOCKET, с другой стороны, больше похож на установленный телефонный звонок между телефонами пары домов, разговаривающих друг с другом. Эти звонки могут быть установлены между домами в одном городе или двумя домами в разных городах. Это тот временный установленный путь между двумя телефонами, говорящими друг с другом, что является SOCKET.
Порт и сокет можно сравнить с отделением банка.
Номер здания "Банка" аналогичен IP-адресу. Банк имеет различные разделы, такие как:
Таким образом, 1 (отдел сберегательного счета), 2 (отдел персональных кредитов), 3 (отдел жилищных кредитов) и 4 (отдел рассмотрения жалоб) являются портами.
Теперь позвольте нам сказать, что вы идете, чтобы открыть сберегательный счет, вы идете в банк (IP-адрес), затем вы идете в "отдел сберегательного счета" (порт № 1), затем вы встречаете одного из сотрудников, работающих в "отдел сберегательного счета" ". Давайте позвоним ему SAVINGACCOUNT_EMPLOYEE1 для открытия счета.
SAVINGACCOUNT_EMPLOYEE1 - ваш дескриптор сокета, поэтому может быть от SAVINGACCOUNT_EMPLOYEE1 до SAVINGACCOUNT_EMPLOYEEN. Это все дескрипторы сокетов.
Аналогичным образом, другие отделы будут иметь работу под их руководством, и они аналогичны сокету.
Сокет является конечной точкой связи. Сокет не имеет прямого отношения к семейству протоколов TCP/IP, его можно использовать с любым протоколом, поддерживаемым вашей системой. API сокета C ожидает, что вы сначала получите пустой объект сокета из системы, который затем можно будет привязать к локальному адресу сокета (чтобы напрямую получать входящий трафик для протоколов без установления соединения или принимать входящие запросы на соединение для протоколов, ориентированных на установление соединения) или что вы можете подключиться к адресу удаленного сокета (для любого типа протокола). Вы можете даже сделать и то и другое, если хотите контролировать оба: локальный адрес сокета, к которому привязан сокет, и адрес удаленного сокета, к которому подключен сокет. Для протоколов без установления соединения подключение сокета даже необязательно, но если вы этого не сделаете, вам также придется передавать адрес назначения с каждым пакетом, который вы хотите отправить через сокет, как иначе, как бы сокет знал, куда отправить эти данные для? Преимущество заключается в том, что вы можете использовать один сокет для отправки пакетов на разные адреса сокетов. После того, как вы настроили сокет и, возможно, даже подключили его, считайте его двунаправленным каналом связи. Вы можете использовать его для передачи данных в какой-либо пункт назначения, а другой пункт назначения может использовать его для передачи данных вам. То, что вы пишете в сокет, отправляется, а то, что было получено, доступно для чтения.
С другой стороны, порты - это то, что есть только у определенных протоколов стека протоколов TCP/IP. TCP и UDP пакеты имеют порты. Порт - это просто число. Комбинация порта источника и порта назначения определяет канал связи между двумя хостами. Например, у вас может быть сервер, который должен быть и простым HTTP-сервером, и простым FTP-сервером. Если сейчас приходит пакет для адреса этого сервера, как он узнает, является ли это пакет для HTTP или FTP-сервера? Что ж, он будет знать, так как HTTP-сервер будет работать на порту 80, а FTP-сервер - на порту 21, поэтому, если пакет поступает с портом назначения 80, он предназначен для HTTP-сервера, а не для FTP-сервера. Также пакет имеет порт источника, поскольку без такого порта источника сервер может иметь только одно подключение к одному IP-адресу за раз. Порт источника позволяет серверу различать идентичные соединения: все они имеют один и тот же порт назначения, например, порт 80, один и тот же IP-адрес назначения, всегда один и тот же адрес сервера и один и тот же IP-адрес источника, поскольку все они исходят от одного и того же клиент, но так как они имеют разные исходные порты, сервер может отличить их друг от друга. И когда сервер отправляет обратно ответы, он делает это с портом, с которого поступил запрос, таким образом, клиент также может различать разные ответы, которые он получает.
Один порт может иметь один или несколько разъемов, подключенных к другому внешнему IP-адресу, например, к нескольким розеткам.
TCP 192.168.100.2:9001 155.94.246.179:39255 ESTABLISHED 1312 TCP 192.168.100.2:9001 171.25.193.9:61832 ESTABLISHED 1312 TCP 192.168.100.2:9001 178.62.199.226:37912 ESTABLISHED 1312 TCP 192.168.100.2:9001 188.193.64.150:40900 ESTABLISHED 1312 TCP 192.168.100.2:9001 198.23.194.149:43970 ESTABLISHED 1312 TCP 192.168.100.2:9001 198.49.73.11:38842 ESTABLISHED 1312
Socket - это абстракция, предоставляемая ядром пользовательским приложениям для ввода/вывода данных. Тип сокета определяется протоколом его обработки, IPC-связью и т.д. Поэтому, если кто-то создает сокет TCP, он может делать манипуляции, такие как чтение данных в сокет и запись данных на него с помощью простых методов и обработки протокола нижнего уровня, таких как преобразования TCP и пересылка пакетов на более низкие сетевые протоколы выполняется конкретной реализацией сокета в ядре. Преимущество заключается в том, что пользователю не нужно беспокоиться о том, как обращаться с конкретными конкретными протоколами, а также просто читать и записывать данные в сокет, как обычный буфер. То же самое верно в случае IPC, пользователь просто считывает и записывает данные в сокет, а ядро обрабатывает все детали нижнего уровня в зависимости от типа созданного сокета.
