В современном мире (2023 год) все приложения и программы, с которыми мы так или иначе сталкиваемся живут в определенном виртуальном поле, называемом клиент-серверной организацией. Даже если мы запускаем обычный калькулятор на нашем планшете и предназначен он только для простых арифметических операций, он всё равно находится в клиент-серверном пространстве, просто для него ещё не придумано управляющего сервера и он выступает только оффлайн клиентом, т.е. клиентом без взаимодействия с какими-либо ещё клиентами. Если рассматриваем приложения вроде какой-нибудь социальной сети или онлайн-магазина, да что говорить, самый обычный браузер на компьютере – это полноценная часть клиент-серверного пространства, в котором им отведена почётная роль клиента. Сервера находятся где-то далеко, может быть на другом конце света, а может быть в соседнем здании и обрабатывают запросы клиентов. Так устроено это взаимодействие простыми словами. С точки зрения рядового пользователя, это просто приложение, которому нужен интернет и которое с ним как-то взаимодействует. Но мы хотим узнать с точки зрения программирования, и по этому будем рассматривать их независимо друг от друга как совершенно разные части (называемые узлами) этой взаимодействующей системы. Иногда запросов от клиентов происходит так много, что сервера не справляются и тогда было введено новое слово в обиход – “Облако”. Облачные системы – это взаимодействующие между собой сервера, которые в равной степени и взаимозаменяемо могут обрабатывать запросы от множества клиентов в рамках единой задачи. Например, облачные хранилища позволяет обрабатывать запросы от клиентов по хранению каких-либо данных. Желающих хранить данные не на своём компьютере оказалось много, по этому отдельные сервера стали не справляться и их стали объединять в единые сети обмена информации и при этом размещать в разных уголках Земного шара. Так появились облачные хранилища. По этому когда вы отправляете очередную свою фотку в “Облако”, то где она физически будет находиться в мире никто не знает, кроме самой облачной системы. Может в России, может в Африке, а может и так, что часть фотки в Бразилии, а часть во Владивостоке. Облачное хранилище само перераспределяет нагрузку, находит оптимальные алгоритмы хранения и передачи данных в зависимости от спроса, и распределяет всё что в него поступает так, как считает в процессе расчета наиболее рациональным.
Получается, что клиенты и сервер выглядят так:
Когда речь заходит об облаке, это выглядит так:
Так вот, к чему это я…С точки зрения программирования, программист должен понимать где его функционал должен работать на сервере, а где на клиенте. Например, нужно вывести сообщение пользователю, что товара нет в онлайн-магазине. Где должен выполняться этот код, на клиенте или сервере? Оказывается, что для того чтобы это действительно работало, программист должен написать для выполнения на сервере определенный код, который вычислит, что товара больше нет, передать при очередном запросе клиента, что количество некого товара равно нулю. Затем должен написать на клиенте чтобы он с определенной периодичностью опрашивал сервер на предмет изменения количества того или иного товара, принимать количество, и если оно равно нулю, то выдавать на клиенте это сообщение. Т.е. программисту нужно написать одну программу на сервере для ответной реакции по запросу клиента, и другую программу работающую на каждом клиенте, которая опрашивает сервер, выводит сообщения, принимает вводимые данные будь то клики по экрану или адрес получателя, или ваш телефон для связи. Аналогично работают и различные социальные сети. Ваш планшет с определенной периодичностью опрашивает сервер на предмет того, нет ли для вас нового сообщения, в этот момент может заодно передаёт ваше сообщение для кого-то, опрашивает не появилась ли на различных каналах ещё одна новость, не загрузил ли кто новый видос на сервер. К счастью, если вы только начинающий программист, и работаете по этой специальности недавно, то вам не придётся делать программу и для клиента и для сервера, обычно новичков ставят только на клиент и дают документацию о том как нужно обращаться к серверу (так называемые API обмена). Подытоживая сказанное, программист должен чётко и хорошо понимать, что выполняется на сервере, а что на клиенте, в связи с этим и доступные методы, классы и т.п. могут работать в зависимости от того где выполняются, а достаточно часто и могут быть вообще уникальны, только для выполнения на сервере или только для выполнения на клиенте. Например, на клиенте онлайн-магазина нельзя обратиться напрямую к базе данных сервера, а на сервере нельзя вывести сообщение для пользователя.
В клиент серверном варианте есть один нюанс. Одно дело когда у вас приложение онлайн магазина или социальной сети, другое, когда открываете страницу в браузере. Нет, не подумайте чего плохого))), и то и другое действительно клиент-серверное взаимодействие…с точки зрения организации системы. Но с точки зрения программирования, совершенно разное. Дело в том, что приложение уже написано и опубликовано, вы его скачали из магазина приложений в законченном виде, и лишь иногда делаете обновления, когда сочтёте это нужным. Если речь идет о клиент-серверном взаимодействии через браузер, то у вас нет на вашем домашнем компьютере заранее кода сайта чтобы его запустить для обмена с сервером, по этому при каждом обращении к сайту, он сначала выгружает с сервера в ваш браузер некий программный код (называемый обычно скрипт) и запускает его, и вот после этого и происходит взаимодействие клиента и сервера для обмена. Именно по этому раньше распространялось так много вирусов именно через сайты, так как играли злую шутку несовершенство операционных систем, самих браузеров и анализаторов кода, который выполнялся. При появлении мобильных приложений, перед публикацией магазин приложений почти всегда сначала проверяет его на наличие вирусов, вредоносного кода, да и сам разработчик должен быть зарегистрированным в этом магазине и предоставить свои персональные данные, чтобы было с кого спросить. С сайтами так делать в большинстве случаев не получается, т.к. нет механизма достоверной проверки кода этих сайтов (они расположены не централизированно в каком-то магазине, например, в магазине каких-то сайтов, а разбросаны в разных частях света на разных серверах и разных странах с разной юрисдикцией).
В клиент-серверной организации обмена часто всё сводится к тому чтобы передать некую информацию с одного клиента на другого. И это не только работа социальных сетей. Да, обычный онлайн-магазин – это тоже отчасти передача с одного клиента на другого – вы сделали заказ, количество товара на складе уменьшилось, и каждому клиенту рассылается новый остаток после вашего взаимодействия. Иными словами, сервер выполняет роль вычислительного звена и арбитра, можно сказать важного посредника, который организовывает всю работу взаимодействия.
Должен тут же сказать, чтобы не вводить вас в заблуждение, что клиент-серверная организация хотя и является доминирующей в мире информационных технологий, но не является единственной. Погружаться в другие на этом этапе знакомства с ИТ нет, но для эрудиции скажу, – есть ещё так называемые системы “Точка-точка” или “Пир-ту-пир”, или “peer-to-peer”, или они же “p2p”, или они же “Пиринговые сети”. Это систему у которых нет серверов вообще. Они взаимодействуют исключительно на прямом обращении одного клиента к другому, хотя было равно сказать и обращении одного сервера к другому. Типичным примером таких систем являются торрент-клиенты. В схеме это выглядит так:
По этому такие системы, или чаще говоря сети, называют децентрализованными, т.к. тут нет такого центра как сервера или облака в клиент-серверной организации. Сами же звенья этой системы не принято называть сервером или клиентом, а называют их узлами сети. Программист в таких сетях должен свою программу наделить свойствами и клиента и сервера, т.е. она должна уметь периодически опрашивать другие узлы на предмет обмена информацией, как это делает клиент, и как сервер реагировать на запросы других узлов, и отвечать им.
Клиент-серверная организация накладывает определенные правила, особенно если речь идет о взаимодействии вроде как в вашем браузере, когда вы открываете очередную страницу какого-то сайта. Дело в том, что все устройства пользователей разные, разные производители, разные комплектующие, или вообще настолько разные как iOs, Android и MS Windows, а браузер, как я только что сказал, отправляет клиенту код, который должен на нём выполняться. Определить точно не всегда удаётся ввиду того, что часто клиент скрывает достоверную и подробную информацию о своей системе ввиду информационной безопасности, а выполнить код на нём всё равно нужно. По этой причине часть выполнения была возложена на операционные системы, способные воспринимать одни и те же скрипты так, чтобы клиентский компьютер их понял, этот процесс известен ещё со времён языка Бейсик и называется трансляцией. Т.е. сервер отправляет каждому клиенту чаще всего один и тот же скрипт работающий по одинаковому алгоритму, а клиент его уже сам дополнительно анализирует и преобразует в тот код, который поддерживает его устройство. Такой подход называется мультиплатформенным, т.е. один код для разных платформ, по этому к счастью, программисту чаще всего не надо задумываться о том, какое же устройство будет конечным на клиенте, и сосредоточиться только на том функционале, который ему необходимо реализовать; конечное устройство само должно позаботиться о том чтобы правильно воспринять тот или иной скрипт.
Когда речь заходит о взаимодействии в сетях, не важно каких, пиринговых или клиент-серверных, чтобы компьютеры правильно понимали что за информацию они друг другу передают, сама передача должна осуществляться по определенным правилам, называемыми протоколами.
Здесь в терминологии есть путаница, сетью называют как физическую сеть (в виде проводов), логическую сеть, ту самую, которую мы называем интернетом, когда каждый компьютер имеет свой адрес, также называемый IP-адрес (айпи-адрес), и обращение идет по нему, и сетью ещё могут называть бесконечное количество виртуальных сетей, т.е. одних логических сетей внутри других логических сетей, например VPN-сети, пиринговые сети и т.п.
Протоколов придумано великое множество. Есть стандартные, а есть уникальные, придуманные программистами для определенных обменов. Например, есть протокол TCP, который обеспечивает выход компьютера в интернет, он стандартный и строго соответствует всегда одним и тем же правилам, по этому подключенный компьютер в интернет сразу знает как общаться с вашим провайдером или с мобильным оператором. Но есть протоколы, которые никак не стандартизованы, например различные онлайн-магазины, соц.сети. Для них обмен регламентирован только фантазией программистов организовывавших этот обмен. Однако и тут, если обменную систему разрабатывает не один программист, а целая команда, тоже потребуется вводить внутренние стандарты для этой самой команды, и ориентироваться на них. Это означает, что нельзя например взять клиентское приложение одной социальной сети, немного переделать его и оно заработает для другой социальной сети. Вероятность успеха такого подхода стремиться к нулю, и всё по тому, что протоколы обмена будут разными, придуманными своей командой разработки со своей спецификой и особенностями.
В соответствии с вышесказанным, программирование для клиента и для сервера имеет ряд отличий, а также для того и другого придуманы специальные языки программирования. Наиболее известные языки используемые для клиент-серверной организации:
Для клиента:
- Java Android (только для устройств на базе Android)
- Swift (только для систем на базе iOS)
- Javascript (только для браузеров, но для любых устройств)
- Kotlin (для Android)
Для сервера:
- PHP
- Java servlet
- Perl
- Asp
Такие языки как Си и Паскаль позволяют писать как серверное программное обеспечение, так и клиентское, но требует намного более высокой квалификации и опыта. С другой стороны, язык 1С, ввиду специфики самой платформы, позволяет писать код одновременно и для серверной части и для клиентской, при этом требует совершенно иной квалификации, чем программист Си или Паскаль, хотя сам код 1С обладает намного меньшей функциональностью.
Перечисленные языки для клиента так или иначе накладывают ограничения на то, на каком клиенте они будут выполнятся, например, на языке Java Android нельзя написать для устройств на iOS (нет таких компиляторов) и наоборот. Для Javascript нельзя скомпилировать ни для Android, ни для iOS, ни на Windows, но если на этих системах есть браузер, поддерживающий Javascript (а такие браузеры наверно сейчас все), то тогда можно этот код выполнять через этот браузер и на том и на этом устройстве, с той или иной операционной системой.
Подобных ограничений для серверов не бывает, т.к. сервер изначально настраивается на работу с тем или иным кодом (php, java servlet и т.д.) и программный код пишется под определенный транслятор или компилятор, который, как понимаете, изначально всегда известен. Т.е. программист на php сразу будет настраивать или выбирать свой сервер с установленным транслятором php, а например, программист на Java Servlet установит на сервере программу Tomcat. Сами эти языки способы делать практически одно и тоже в примерно равных требованиях к ресурсам, по этому, скорее, это дело вкуса и возможностей, на чём делать сервер.
Сам выбор языка каждый делает тоже по-своему. Я например, сторонник того, чтобы синтаксис что серверных языков, что клиентских был хотя бы чем то похож, по этому изначально выбрал Си-синтаксис подобные языки:
- Сам язык Си
- PHP
- Java
- Javascript
Они позволяют осуществлять различные программные фантазии как на серверах, так и на клиентах, и других языков я сторонюсь только по одной причине – уж больно они не похожи на Си, а часто бывает так, что на решение той или иной проблемы нужно время. Искать проблему одновременно и в серверном коде и клиентском происходит намного быстрее, если сам синтаксис языков похож. Тут нет равных языку 1С, в котором не просто один синтаксис и для клиента и для сервера, так это и есть один и тот же язык)). Плохо, что 1С требует отдельной платформы, да и сервера 1С пока ещё не бесплатные)).
El Vinto, 2023