По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Hiya! Merion Metrics our call stats (CDR) application for Asterisk, it shows the most important diagrams and call graphs as well as call history in an easy and convenient format. Showing call stats this way makes them easy to understand for everyone - from CEO to an office manager
About Merion Metrics
Short description of Merion Metrics:
Full statistics - the most important info only: date, time, source and destination of a call, as well as it’s recording;
Free trial - try the whole spectrum of these features - completely for free;
Easy and quick installation - we are always here to help you;
Cross-platform - developed in Java. Compatible with any UNIX platform;
For supervisors - Got tired of heavy and awkward CDR interface in FreePBX? Or maybe you experienced something similar with CDR Viewer? we know that feeling;
Easy to export in PDF and CSV - export all your calls into PDF and send it over to your colleagues in an easy readable format;
Try Merion Metrics for free:
Try Merion Metrics
Merion Metrics Installation
Attention! You should to have a license key from our support team at this point. You can get it by follow link: https://asterisk.merionet.ru/merionmetrics
Of course for your convenience we have a step by step video guide. Enjoy :)
Installation video - guide
Installation guide by plain text
System Requirements
RAM: 256 MB min
CPU: Pentium 2 266 МГц + минимум
Java Runtime Environment (JRE): version 8+
Browser: Internet Explorer 9+
Preparation
Firstly, connect to your Asterisk via SSH using user root.
Directory creation for the app
Run the following commands:
mkdir /home/merionstat
Upload app distro MerionMonitoring-*.*.*.jar into the directory you’ve just created: /home/merionstat. You can do that using WinSCP, for example.
Important: App distro will have a certain version number. Here, in the installation guide, we always put version number as MerionMonitoring-*.*.*.jar. In your case it will be something like MerionMonitoring-1.1.9.jar.
SQL user creation
Follow the link that will generate an uncrackable password and right it down on save it somewhere. After that, execute the following command sequence:
mysql
CREATE USER 'interface'@'localhost' IDENTIFIED BY 'your_password';
GRANT SELECT, CREATE, INSERT ON asteriskcdrdb.* TO 'interface'@'localhost' IDENTIFIED BY 'your_password';
Where your_password - some freshly generated password from the link above пароль. For example:
mysql
CREATE USER 'interface'@'localhost' IDENTIFIED BY '6nzB0sOWzz';
GRANT SELECT, CREATE, INSERT ON asteriskcdrdb.* TO 'interface'@'localhost' IDENTIFIED BY '6nzB0sOWzz';
And yet another reminder – save your password somewhere else.
Call recordings directory
For sake of playing call recordings through our app, you have to do the following:
Generate another password via our password generator and save it;.
Execute the following commands:
mkdir /var/www/html/generated_password
chown asterisk:asterisk /var/www/html/generated_password
chmod 775 /var/www/html/generated_password
For example:
mkdir /var/www/html/5v9MpbtUA8
chown asterisk:asterisk /var/www/html/5v9MpbtUA8
chmod 775 /var/www/html/5v9MpbtUA8
Open file /etc/fstab and add there the following sequence:
/var/spool/asterisk/monitor/ /var/www/html/generated_password/ none rbind 0 0
For example:
/var/spool/asterisk/monitor/ /var/www/html/5v9MpbtUA8/ none rbind 0 0
Save all the changes in fstab file. After that, execute the following command in CLI:
mount -a
Start
Application launch
Run the following commands:
cd /home/merionstat
nohup java -jar MerionMonitoring-*.*.*.jar &
Right after command’s execution press Enter.
Application setup
The first connection
After launching .jar archive, please open the following address in your web-browser: http://your_IP_address:7070/#!/config (You can use any browser, we recommend using Google Chrome). Once it opened, enter your license key – you can get it from our support engineer.
Click “Check the license”. If you encounter any kind of a problem during that phase, please address it to our technical support team: helpdesk@merionet.ru.
After that you have to pass the initial authorization, and to do that, you need to use the following credentials: admin/IEJu1uh32
On the next step you’ll need to configure database connection. If you are using Asterisk IP - PBX, just follow the guide:
Database - mysql or mariadb;
DB host:
If your DB installed on the same server as our application - localhost;
If your DB installed on some kind of external server - IP_address_of_your_database;
DB port - is being set up automatically, so please change it only if your DB is listening for requests on another port;
DB connection string - leave this without changes;
Table name - In case of Asterisk it’s cdr;
Scheme - that should be the name of database, for Asterisk it’s asteriskcdrdb;
User - You created the user some time ago in “SQL user creation” part of this guide. If you copied all the commands without any changes – that would be interface;
Password - the one you’ve probably generated using our password generator;
Voice recordings host - link like http://your_ip_address/generated_password/, where generated_password is a sequence you created on a previous stage Call recordings directory. So, it’s gonna be something like http://192.168.1.7/5v9MpbtUA8/;
Station type - Asterisk;
After you finish all the above, click “Connect”. If something went wrong, address the issue to our support team helpdesk@merionet.ru.
On the next step, you have to match field name in the table with it’s actual meaning. In case of Asterisk you can leave everything as it is.
At the bottom of this page click the button “Set the matches” and “Launch the Application”. Our app will redirect you to the application’s initial page. By default, administrator’s login and password are: admin/admin
Known issues
Application is already launched
If you can’t open the app using the default link http://IP_ADDRESS:7070/#!/config, please check if it wasn’t launched before. To do so, please run the command below:
ps aux | grep Merion
Analyze the command output:
root 4919 0.1 13.1 2120384 801784 ? Sl Dec11 19:12 java -jar MerionMonitoring-*.*.*.jar
If you see something similar, you have to kill the process using it’s PID (marked with orange in output example above). So execute the following command:
kill -9 4919
Check the output again: ps aux | grep Merion
If the one you’ve seen before is gone, then you can try to lauch it again:
cd /home/merionstat
nohup java -jar MerionMonitoring-*.*.*.jar &
Database on the external server
If you are connecting to an external data base, you need to add some additional configuration for MySQL settings, that you’ve done in “SQL user creation”. You might need it if you install call stats app on a different server, not the one you have Asterisk installed on.
In this case you need to run the following commands on the server where you have your DB (usually it’s your Asterisk server):
mysql
GRANT SELECT, CREATE, INSERT ON asteriskcdrdb.* TO 'interface'@'IP_адрес_интерфейса' IDENTIFIED BY ''your_password';
Where:
your_password - password generated with our our tool;
Call_stats_app_IP_ADDRESS - IP-address of the server where you decided to install our Call Stats Application.
For example:
mysql
GRANT SELECT, CREATE, INSERT ON asteriskcdrdb.* TO 'interface'@'192.168.1.78' IDENTIFIED BY '6nzB0sOWzz';
Also, please check that the following ports are open:
3306 - for MySQL and MariaDB;
5432 - for PostgreSQL.
Slow data loading
If you are experiencing some issues with data download – it might be related to the big size of your database.
We recommend to launch our app (.jar file) with some additional keys. According to the “Application launch”, run the following command:
cd /home/merionstat
nohup java -jar MerionMonitoring-*.*.*.jar -Xms128m -Xmx256m &
Where:
-Xms128m - minimal amount of RAM available for the app. In our example – it’s 128 Megabytes.
-Xmx256m - maximum amount of RAM available for the app. In our example – it’s 256 Megabytes;
How to send a request to our support team?
If you are experiencing any technical issues with configuration of our app – we will definitely help you. We’ll need the files from /home/merionstat directory – the one where you’ve put our distro MerionMonitoring-*.*.*.jar, according to step “Directory creation for the app”.
Depending on the phase where you’ve encountered any technical issues, you might have the following files there:
columns_mapping.cfg
configuration.properties
nohup.out
Please send us those files and description of your issue – we’ll try to help you.
Telegram - @merion_support_bot
Email - helpdesk@merionet.ru
Система доменных имен (DNS – Domain Name System) обеспечивает сетевую коммуникацию. DNS может показаться какой-то невидимой силой или сущностью до тех пор, пока что-то пойдет не так, потому что если DNS выйдет из строя, то ничего работать не будет.
В данной статье будут рассмотрены передовые методы и наиболее важные меры безопасности для поддержания работоспособности вашей инфраструктуры DNS. Чтобы создать безопасную и надежную DNS, обязательно изучите перечисленные ниже пункты.
Передовые технологии для обеспечения высокой производительности DNS
Обеспечение избыточности и высокой доступности DNS
DNS является основой сетевых приложений, поэтому инфраструктура DNS должна быть высоко доступной. А чтобы обеспечить необходимый уровень избыточности, в вашей организации должно быть, как минимум, два DNS-сервера, первичный и вторичный.
Чтобы обеспечить работу критически важных для бизнеса систем, необходимо иметь, как минимум, два внутренних DNS-сервера. Все системы активного каталога, обмена данными и электронной почты полагаются на корректную работу DNS. Без исправно функционирующих внутренних DNS-серверов внутренние устройства не будут иметь возможности обмениваться данными.
Если на одном DNS-сервере возникнет проблема, то второй сразу же заменяет его. Администраторы настраивают оборудование так, чтобы автоматически использовался вторичный DNS, если первичный не отвечает. IP-адрес внутреннего DNS-сервера может быть любым в диапазоне IP-адресов частной сети.
Обеспечивая избыточность DNS-серверов, вы можете добиться высокой доступности инфраструктуры DNS. Непрерывная репликация с первичных серверов на вторичные обеспечит синхронизацию ваших DNS-записей и защитит систему от сбоев. Вы можете быть уверены в том, что конечный пользователь всегда будет иметь возможность получить доступ к системам.
Сокрытие DNS-серверов и DNS-информации
Не каждый DNS-сервер и не каждая информация должна быть доступна для всех пользователей.
Во-первых, откройте только те серверы и данные, которые необходимы лицам, непосредственно использующим эти серверы. Это особенно важно, если ваши доменные имена являются общедоступными.
Во-вторых, скройте свой основной DNS-сервер. Внешние пользователи не должны видеть первичные серверы. Записи для этих серверов не должны быть видны ни в одной общедоступной базе данных серверов имен. Запросы от пользователей должны обрабатывать только вторичные DNS-серверы.
Если DNS-сервер доступен за пределами вашей сети, то это должен быть авторитативный DNS-сервер. Внешним пользователям не нужно обращаться к вашим рекурсивным DNS-серверам. Системная конфигурация будет высокопроизводительной только тогда, когда сервер будет отвечать только на итеративные запросы для соответствующих зон, за которые он отвечает.
В довершение ко всему, иметь доступ к первичным серверам должны только системные администраторы и IT-персонал вашей организации. Если ваши первичные DNS-серверы будут открыты для всех внутренних пользователей, то это может создать серьезную угрозу для безопасности. Как показывает практика, лучше скрывать DNS-серверы и некоторые данные от пользователей, которым доступ к ним не нужен.
Нужно ли использовать внешний или внутренний DNS-сервер?
Ответ на данный вопрос зависит от внутренней настройки.
Чтобы устройства в одном домене могли общаться друг с другом, вам необходимо указать внутренний DNS-сервер. Внешние DNS-серверы не могут работать с именами хостов внутренних устройств.
Например, когда компьютер DESKTOP1 отправляет DNS-запрос для офисного принтера или сервера hr-1, только внутренняя DNS может предоставить запись ресурса. Если вы настроите устройство на использование внешнего DNS, например, 8.8.8.8 Google, то вы не сможете использовать внутренние ресурсы.
Во внутренних средах необходимо установить, как первичный, так и вторичный DNS на внутренний сервер имен. Даже если основной DNS-сервер даст сбой, проблем с подключением не будет. Дополнительный DNS-сервер содержит все записи и действует как резервная копия. В случае возникновения какой-либо проблемы, этот сервер отвечает на все запросы до тех пор, пока не заработает основной сервер.
Использование локального или ближайшего DNS-сервера
Офисы крупных организаций часто расположены по всему миру. В таком случае следует настроить локальный DNS-сервер в каждом офисе, если позволяет инфраструктура.
А все потому, что локальный сервер сокращает время ответа на DNS-запросы. Если же запрос проходит через глобальную сеть к удаленному серверу имен, то время загрузки увеличивается.
При большом количестве клиентов, естественно, увеличивается количество DNS-запросов. Одна централизованная группа DNS-серверов, конечно, может обрабатывать все эти запросы, но с большой задержкой. Если компьютеры пользователей будут направляться на локальный или ближайший сервер имен, то время отклика может существенно сократиться.
В таком случае задержка не превышает 50 мс. Более того, это значение обычно даже намного ниже. Использование ближайшего DNS-сервера сокращает время загрузки для всех устройств. Таким образом, вы также уменьшаете нагрузку на удаленный сервер в штаб-квартире и повышаете его производительность. Здесь также остается актуальной рекомендация иметь, как минимум, два DNS-сервера.
Передовые методы обеспечения безопасности DNS
DNS-серверы очень часто становятся целью кибератак. Важным шагом в предотвращении вторжений в вашу организацию является защита инфраструктуры DNS. Чтобы избежать серьезного нарушения настроек DNS, обязательно изучите меры безопасности, описанные ниже.
Ведение журнала DNS-сервера
Ведение журнала DNS-сервера – это один из самых эффективных способов отслеживания активности DNS. Журналы сообщают вам, если кто-то пытается вмешаться в ваши DNS-серверы. Помимо активности пользователей, журналы отладки сообщают вам о проблемах с DNS-запросами или обновлениями.
Журналы DNS также показывают следы отравления кэша. При таком виде атаки злоумышленник изменяет хранящиеся в кэше данные и сбивают пользователей с курса. Например, IP-адрес www.youtube.com может быть заменен на IP-адрес вредоносного сайта. Когда пользователь отправляет запрос в DNS для youtube.com, сервер теперь возвращает неверный IP-адрес. В результате чего пользователи попадают на тот веб-сайт, который они не хотели посещать и становятся мишенью для хакеров.
Несмотря на то, что ведение журнала отладки DNS повышает уровень безопасности, некоторые системные администраторы решают этим пренебречь. Основная причина такого решения – повышение производительности. Отслеживание сетевой активности может помочь вам обнаружить некоторые атаки, такие как DDoS, но не отравление кэша. Поэтому мы настоятельно рекомендуем использовать ведение журналов отладки DNS.
Блокировка кэша DNS
Всякий раз, когда появляется запрос от клиента, DNS находит информацию и сохраняет ее в кэше для будущего использования. Этот процесс позволяет серверу быстрее отвечать на одни и те же запросы. Злоумышленники могут воспользоваться этой функцией путем изменения сохраненной информации.
Следующий шаг после использования журналов отладки DNS – это блокировка кэша DNS. Это функция определяет, когда кэшированные данные могут быть изменены. Сервер хранит информацию о поиске в течение времени, определяемого TTL (Time To Life - время жизни). Если блокировка кэша не используется, то информация может быть перезаписана до истечения TTL. Это оставляет место для атак с отравлением кэша.
В некоторых операционных системах блокировка кэша может быть включена по умолчанию. Масштаб блокировки кэша может достигать 100%. Когда установлено значение 70, то перезапись данных невозможна до истечения 70% TTL. При определении блокировки кэша равным 100 изменение кэшированной информации блокируется до истечения всего TTL.
Фильтрация DNS-запросов для блокировки вредоносных доменов
Фильтрация DNS – это эффективный способ ограничить доступ пользователей к веб-сайту или домену. Основная причина для блокировки разрешения имен для домена – наличие информации о вредоносности этого домена. Когда клиент отправляет запрос на заблокированный веб-сайт, DNS-сервер прекращает любую связь между ними.
DNS-фильтрация значительно снижает вероятность проникновения вирусов и вредоносных программ в вашу сеть. Когда пользователь не может получить доступ к вредоносной странице, то и количество угроз, которые могут проникнуть в вашу инфраструктуру, крайне мало. Таким образом, вашему IT-персоналу не требуется круглосуточно работать, чтобы очищать систему от вирусов.
Помимо соображений безопасности, есть еще одна причина, по которой организации могут заблокировать домен – бизнес-политика или по соображениям производительности. В список заблокированных доменов могут входить социальные сети, азартные игры, порнография, страницы потокового видео или любые другие веб-сайты. DNS может фильтровать запросы по пользователю, группе или блокировать доступ для всех пользователей.
Современные системы обеспечения защиты ПО и брандмауэры имеют DNS-фильтрацию в стандартной комплектации. Некоторые из них предоставляют списки плохих доменов, которые регулярно обновляются. Вы можете использовать готовое программное решение и таким образом автоматизировать фильтрацию DNS, а не добавлять новые записи вручную.
Проверка целостности данных DNS с помощью DNSSEC
Модули безопасности службы доменных имен (DNSSEC – Domain Name System Security Extensions) гарантируют, что пользователи получат действительные ответы на свои запросы. Целостность данных достигается за счет цифровой подписи DNSSEC на данных DNS, предоставляемых серверам имен. Когда конечный пользователь отправляет запрос, DNS-сервер предоставляет цифровую подпись с ответом. Стало быть, пользователи знают, что они получили достоверную информацию в качестве ответа на отправленный ими запрос.
Этот дополнительный уровень безопасности помогает бороться с атаками на протокол DNS. Атаки «спуфинга» DNS и отравления кэша успешно предотвращаются, поскольку DNSSEC обеспечивает целостность данных и авторизацию их источника. В дальнейшем пользователи будут уверены, что посещают именно те страницы, которые хотели посетить.
Настройка списков контроля доступа
Списки контроля доступа (ACL – Access Control Lists) – это еще один способ защиты DNS-серверов от несанкционированного доступа и атак «спуфинга». К вашему основному DNS-серверу доступ должны иметь только системные и IT-администраторы. Настройка ACL для разрешения входящих подключений к серверу имен с определенных хостов гарантирует то, что только определенная часть персонала сможет обращаться к вашим серверам.
Кроме того, ACL должны определять, какие серверы могут выполнять передачу зон. Злоумышленники могут попытаться определить настройки вашей зоны, отправив запросы на передачу зоны через вторичные DNS-серверы. Если вы заблокируете все запросы на передачу зоны через вторичные серверы, то злоумышленник не сможет получить информацию о зоне. Эта конфигурация не позволяет третьим лицам получить представление о том, как организована ваша внутренняя сеть.
Заключение
Всегда есть возможности для улучшения системной архитектуры DNS и ее безопасности. Постоянные угрозы скрываются и ждут, когда появится уязвимость в вашей информационной системе, чтобы воспользоваться ей.
Но тем не менее, если вы будете следовать рекомендациям, описанным в данном руководстве, то вы охватите наиболее важные аспекты, которые необходимы для обеспечения безопасности и отказоустойчивости вашей инфраструктуры DNS.
Транспортный уровень OSI (уровень 4) определяет несколько функций, наиболее важными из которых являются восстановление после ошибок и управление потоком. Точно так же протоколы транспортного уровня TCP / IP также реализуют те же типы функций. Обратите внимание, что и модель OSI, и модель TCP / IP называют этот уровень транспортным. Но, как обычно, когда речь идет о модели TCP / IP, имя и номер уровня основаны на OSI, поэтому любые протоколы транспортного уровня TCP / IP считаются протоколами уровня 4.
Ключевое различие между TCP и UDP заключается в том, что TCP предоставляет широкий спектр услуг приложениям, а UDP-нет. Например, маршрутизаторы отбрасывают пакеты по многим причинам, включая битовые ошибки, перегрузку и случаи, в которых не известны правильные маршруты. Известно, что большинство протоколов передачи данных замечают ошибки (процесс, называемый error detection), и затем отбрасывают кадры, которые имеют ошибки. TCP обеспечивает повторную передачу (error recovery) и помогает избежать перегрузки (управление потоком), в то время как UDP этого не делает. В результате многие прикладные протоколы предпочитают использовать TCP.
Разница между TCP и UDP в одном видео
Однако не думайте, что отсутствие служб у UDP делает UDP хуже TCP. Предоставляя меньше услуг, UDP требует меньше байтов в своем заголовке по сравнению с TCP, что приводит к меньшему количеству байтов служебных данных в сети. Программное обеспечение UDP не замедляет передачу данных в тех случаях, когда TCP может замедляться намеренно. Кроме того, некоторым приложениям, особенно сегодня, к передаче голоса по IP (VoIP) и видео по IP, не требуется восстановление после ошибок, поэтому они используют UDP. Итак, сегодня UDP также занимает важное место в сетях TCP / IP.
В таблице 1 перечислены основные функции, поддерживаемые TCP/UDP. Обратите внимание, что только первый элемент, указанный в таблице, поддерживается UDP, тогда как TCP поддерживаются все элементы в таблице.
Таблица № 1 Функции транспортного уровня TCP/IP
Функции
Описание
Мультиплексирование с использованием портов
Функция, которая позволяет принимающим хостам выбирать правильное приложение, для которого предназначены данные, на основе номера порта.
Восстановление после ошибок (надежность)
Процесс нумерации и подтверждения данных с помощью полей заголовка Sequence и Acknowledgment
Управление потоком с использованием окон
Процесс, использующий размеры окна для защиты буферного пространства и устройств маршрутизации от перегрузки трафиком.
Установление и завершение соединения
Процесс, используемый для инициализации номеров портов, а также полей Sequence и Acknowledgment.
Упорядоченная передача данных и сегментация данных
Непрерывный поток байтов от процесса верхнего уровня, который "сегментируется" для передачи и доставляется процессам верхнего уровня на принимающем устройстве с байтами в том же порядке
Далее описываются возможности TCP, а затем приводится краткое сравнение с UDP.
Transmission Control Protocol
Каждое приложение TCP / IP обычно выбирает использование TCP или UDP в зависимости от требований приложения. Например, TCP обеспечивает восстановление после ошибок, но для этого он потребляет больше полосы пропускания и использует больше циклов обработки. UDP не выполняет исправление ошибок, но требует меньшей пропускной способности и меньшего количества циклов обработки. Независимо от того, какой из этих двух протоколов транспортного уровня TCP / IP приложение выберет для использования, вы должны понимать основы работы каждого из этих протоколов транспортного уровня.
TCP, как определено в Request For Comments (RFC) 793, выполняет функции, перечисленные в таблице 1, через механизмы на конечных компьютерах. TCP полагается на IP для сквозной доставки данных, включая вопросы маршрутизации. Другими словами, TCP выполняет только часть функций, необходимых для доставки данных между приложениями. Кроме того, роль, которую он играет, направлена на предоставление услуг для приложений, установленных на конечных компьютерах. Независимо от того, находятся ли два компьютера в одном Ethernet или разделены всем Интернетом, TCP выполняет свои функции одинаково.
На рисунке 1 показаны поля заголовка TCP. Хотя вам не нужно запоминать названия полей или их расположение, оставшаяся часть этой лекции относится к нескольким полям, поэтому весь заголовок включен сюда для справки.
Сообщение, созданное TCP, которое начинается с заголовка TCP, за которым следуют данные приложения, называется сегментом TCP. В качестве альтернативы также может использоваться более общий термин PDU уровня 4 или L4PDU.
Мультиплексирование с использованием номеров портов TCP
И TCP, и UDP используют концепцию, называемую мультиплексированием. Поэтому этот подраздел начинается с объяснения мультиплексирования с TCP и UDP. После этого исследуются уникальные возможности TCP.
Мультиплексирование по TCP и UDP включает в себя процесс того, как компьютер думает при получении данных. На компьютере может быть запущено множество приложений, таких как веб-браузер, электронная почта или приложение Internet VoIP (например, Skype). Мультиплексирование TCP и UDP сообщает принимающему компьютеру, какому приложению передать полученные данные.
Определенные примеры помогут сделать очевидной необходимость мультиплексирования. Сеть из примера состоит из двух компьютеров, помеченных как Анна и Гриша. Анна использует написанное ею приложение для рассылки рекламных объявлений, которые появляются на экране Григория. Приложение отправляет Григорию новое объявление каждые 10 секунд. Анна использует второе приложение, чтобы отправить Грише деньги. Наконец, Анна использует веб-браузер для доступа к веб-серверу, который работает на компьютере Григория. Рекламное приложение и приложение для электронного перевода являются воображаемыми, только для этого примера. Веб-приложение работает так же, как и в реальной жизни.
На рисунке 2 показан пример сети, в которой Гриша запускает три приложения:
Рекламное приложение на основе UDP
Приложение для банковских переводов на основе TCP
Приложение веб-сервера TCP
Грише необходимо знать, в какое приложение передавать данные, но все три пакета поступают из одного и того же Ethernet и IP-адреса. Вы могли подумать, что Григорий может посмотреть, содержит ли пакет заголовок UDP или TCP, но, как вы видите на рисунке, два приложения (wire transfer и web) используют TCP.
TCP и UDP решают эту проблему, используя поле номера порта в заголовке TCP или UDP соответственно. Каждый из сегментов TCP и UDP Анны использует свой номер порта назначения, чтобы Григорий знал, какому приложению передать данные. На рисунке 3 показан пример.
Мультиплексирование основывается на концепции, называемой сокетом. Сокет состоит из трех частей:
IP-адрес
Транспортный протокол
Номер порта
Итак, для приложения веб-сервера Григория, сокет будет (10.1.1.2, TCP, порт 80), потому что по умолчанию веб-серверы используют хорошо известный порт 80. Когда веб-браузер Анны подключается к веб-серверу, Анна также использует сокет - возможно, такой: (10.1.1.1, TCP, 49160). Почему 49160? Что ж, Анне просто нужен номер порта, уникальный для Анны, поэтому Анна видит этот порт 49160.
Internet Assigned Numbers Authority (IANA), организация, которая управляет распределением IP-адресов во всем мире, и подразделяет диапазоны номеров портов на три основных диапазона. Первые два диапазона резервируют номера, которые IANA затем может назначить конкретным протоколам приложений через процесс приложения и проверки, а третья категория резервирует порты, которые будут динамически выделяться для клиентов, как в примере с портом 49160 в предыдущем абзаце. Имена и диапазоны номеров портов (более подробно описано в RFC 6335):
Хорошо известные (системные) порты: номера от 0 до 1023, присвоенные IANA, с более строгим процессом проверки для назначения новых портов, чем пользовательские порты.
Пользовательские (зарегистрированные) порты: номера от 1024 до 49151, присвоенные IANA с менее строгим процессом назначения новых портов по сравнению с хорошо известными портами.
Эфемерные (динамические, частные) порты: номера от 49152 до 65535, не назначены и не предназначены для динамического выделения и временного использования для клиентского приложения во время его работы.
На рисунке 4 показан пример, в котором используются три временных порта на пользовательском устройстве слева, а сервер справа использует два хорошо известных порта и один пользовательский порт. Компьютеры используют три приложения одновременно; следовательно, открыто три сокетных соединения. Поскольку сокет на одном компьютере должен быть уникальным, соединение между двумя сокетами должно идентифицировать уникальное соединение между двумя компьютерами. Эта уникальность означает, что вы можете использовать несколько приложений одновременно, разговаривая с приложениями, запущенными на одном или разных компьютерах. Мультиплексирование на основе сокетов гарантирует, что данные будут доставлены в нужные приложения.
Номера портов являются важной частью концепции сокетов. Серверы используют хорошо известные порты (или пользовательские порты), тогда как клиенты используют динамические порты. Приложения, которые предоставляют услуги, такие как FTP, Telnet и веб-серверы, открывают сокет, используя известный порт, и прослушивают запросы на подключение. Поскольку эти запросы на подключение от клиентов должны включать номера портов источника и назначения, номера портов, используемые серверами, должны быть известны заранее. Таким образом, каждая служба использует определенный хорошо известный номер порта или номер пользовательского порта. Как общеизвестные, так и пользовательские порты перечислены на www.iana.org/assignments/servicenames-port-numbers/service-names-port-numbers.txt.
На клиентских машинах, откуда исходят запросы, можно выделить любой локально неиспользуемый номер порта. В результате каждый клиент на одном и том же хосте использует другой номер порта, но сервер использует один и тот же номер порта для всех подключений. Например, 100 веб-браузеров на одном и том же хост-компьютере могут подключаться к веб-серверу, но веб-сервер со 100 подключенными к нему клиентами будет иметь только один сокет и, следовательно, только один номер порта (в данном случае порт 80). Сервер может определить, какие пакеты отправлены от какого из 100 клиентов, посмотрев на порт источника полученных сегментов TCP. Сервер может отправлять данные правильному веб-клиенту (браузеру), отправляя данные на тот же номер порта, который указан в качестве порта назначения. Комбинация сокетов источника и назначения позволяет всем участвующим хостам различать источник и назначение данных. Хотя в примере объясняется концепция использования 100 TCP-соединений, та же концепция нумерации портов применяется к сеансам UDP таким же образом.
Почитайте продолжение цикла про популярные приложения TCP/IP.