Сервер на платформе Node.js. HTTP и не только::Журнал СА 1-2.2014
www.samag.ru
     
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
Журнал "Системный администратор"
Журнал «БИТ»
Наука и технологии
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Контакты
   

  Опросы
1001 и 1 книга  
12.02.2021г.
Просмотров: 11783
Комментарии: 20
Коротко о корпусе. Как выбрать системный блок под конкретные задачи

 Читать далее...

11.02.2021г.
Просмотров: 13053
Комментарии: 13
Василий Севостьянов: «Как безболезненно перейти с одного продукта на другой»

 Читать далее...

20.12.2019г.
Просмотров: 19733
Комментарии: 3
Dr.Web: всё под контролем

 Читать далее...

04.12.2019г.
Просмотров: 16699
Комментарии: 13
Особенности сертификаций по этичному хакингу

 Читать далее...

28.05.2019г.
Просмотров: 17411
Комментарии: 8
Анализ вредоносных программ

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

 Сервер на платформе Node.js. HTTP и не только

Архив номеров / 2014 / Выпуск №1-2 (134-135) / Сервер на платформе Node.js. HTTP и не только

Рубрика: Разработка /  Веб-технологии

Кирилл Сухов КИРИЛЛ СУХОВ, веб-программист в дистрибьюторской компании MICS. Занимается проектированием и разработкой различных интернет-сервисов, sukhov-kirill@yandex.ru

Сервер на платформе Node.js
HTTP и не только

Продолжаем осваивать серверную JavaScript-платформу Node.js. Разберемся, почему она именно «серверная» и насколько справляется с этой ролью. TCP, UDP, HTTP, HTTPS – если честно, для Node доступно все

В составе Node.js довольно много средств реализации сетевого взаимодействия, что не удивительно, учитывая начальное предназначение этой системы. Собственно, в первой статье данного цикла [1] мы и начали ее изучение с построения простого HTTP-сервера. Теперь давайте разберемся в вопросе более капитально, подробно рассмотрим различные сетевые ипостаси Node.js. И начнем с фундаментального уровня.

Создаем TCP-сервер

Протокол TCP, как известно, является базовым для большинства интернет-приложений. На платформе Node.js он реализован в модуле net, входящем в ядро системы. Построить TCP-сервер – задача довольно тривиальная. В отличие от HTTP-сервера функция обратного вызова, являющаяся аргументом при создании TCP-сервера, принимает только один аргумент – экземпляр соединения. Он же сокет:

var net = require('net');

var server = net.createServer( function(socket) {

console.log('Соединение с '+socket.remoteAddress+": "+socket.remotePort);

}).listen(8080);

console.log('listening on port 8080');

Запускаем этот сценарий:

$ node tcp2.js

listening on port 8080

И «стучимся» браузером по адресу http://localhost:8080. В самом браузере, естественно, ничего не отобразится, зато в консоли появится запись, подобная этой:

Соединение с 127.0.0.1:63948

Тут мы видим IP-адрес, с которого поступил запрос, и номер созданного TCP-сокета.

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

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

И да, разъемы на корпусе материнской платы к этим сокетам отношения не имеют.

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

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

TCP сокеты – это не единственный вид подобного рода объектов. С начала 80-х годов известны BSD-сокеты (Сокеты Беркли) – POSIX-стандарт для межпроцессорного взаимодействия (IPC), их воплощение – Unix-сокеты (Unix domain socket), схожие с интернет-сокетами, но не использующие сетевой протокол для обмена данными. Даже в семействе TCP/IP существуют еще UDP-сокеты, причем порт TCP будет указывать совсем не тот локальный адрес, что и порт UDP с тем же номером.

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

Статью целиком читайте в журнале «Системный администратор», №1-2 за 2014 г. на страницах 102-110.


Комментарии отсутствуют

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru