Протокол набор правил общения между клиентом и сервером

Обновлено: 04.07.2024

Модель клиент-сервер - это распределенная структура приложения, которая разделяет задачи или рабочие нагрузки между поставщиками ресурса или службы, называемыми серверами , и инициаторами запросов на обслуживание, называемыми клиентами . Часто клиенты и серверы обмениваются данными по компьютерной сети на отдельном оборудовании, но и клиент, и сервер могут находиться в одной системе. Хост сервера запускает одну или несколько серверных программ, которые делятся своими ресурсами с клиентами. Клиент обычно не делится своими ресурсами, но запрашивает контент или услугу с сервера. Таким образом, клиенты инициируют сеансы связи с серверами, ожидающими входящих запросов. Примерами компьютерных приложений, использующих модель клиент-сервер, являются электронная почта , сетевая печать и World Wide Web .

СОДЕРЖАНИЕ

Роль клиента и сервера

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

Связь между клиентом и сервером

Как правило, служба - это абстракция компьютерных ресурсов, и клиенту не нужно беспокоиться о том, как сервер работает при выполнении запроса и доставке ответа. Клиент должен только понимать ответ, основанный на известном протоколе приложения, то есть содержание и форматирование данных для запрашиваемой услуги.

Пример

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

Этот пример иллюстрирует шаблон проектирования, применимый к модели клиент-сервер: разделение задач .

История ранних веков

Ранней формой клиент-серверной архитектуры является ввод удаленного задания , относящийся, по крайней мере, к OS / 360 (объявлен в 1964 г.), где запрос заключался в выполнении задания , а ответ был выходом.

Формулируя модель клиент-сервер , в 1960 - х и 1970 - х годах, компьютерные ученые строят ARPANET (в Стэнфордском исследовательском институте ) используются термины сервера-хоста (или обслуживания узла ) и пользователя-хост (или с помощью-хоста ), и они появляются в ранние документы RFC 5 и RFC 4. Это использование было продолжено в Xerox PARC в середине 1970-х годов.

Один из контекстов, в котором исследователи использовали эти термины, заключался в разработке языка программирования компьютерной сети под названием Decode-Encode Language (DEL). Цель этого языка состояла в том, чтобы принимать команды от одного компьютера (пользователь-хост), который возвращал бы отчеты о состоянии пользователю, поскольку он закодировал команды в сетевых пакетах. Другой компьютер с функцией DEL, сервер-хост, получил пакеты, декодировал их и вернул отформатированные данные на хост-пользователя. Программа DEL на пользовательском хосте получила результаты для представления пользователю. Это транзакция клиент-сервер. Разработка DEL только началась в 1969 году, когда Министерство обороны США создало ARPANET (предшественник Интернета ).

Клиент-хост и сервер-хост

Клиент-хост и сервер-хост имеют несколько иное значение, чем клиент и сервер . Хост - это любой компьютер, подключенный к сети. В то время как слова сервер и клиент могут относиться либо к компьютеру, либо к компьютерной программе, сервер-хост и пользователь-хост всегда относятся к компьютерам. Хост - это универсальный многофункциональный компьютер; клиенты и серверы - это просто программы, которые работают на хосте. В модели клиент-сервер сервер, скорее всего, будет посвящен задаче обслуживания.

Централизованные вычисления

Модель клиент-сервер не требует, чтобы у хостов-серверов было больше ресурсов, чем у хостов-клиентов. Скорее, он позволяет любому компьютеру общего назначения расширять свои возможности за счет использования общих ресурсов других хостов. Однако при централизованных вычислениях большое количество ресурсов выделяется небольшому количеству компьютеров. Чем больше вычислений выгружается с клиентских хостов на центральные компьютеры, тем проще могут быть клиентские хосты. Он сильно зависит от сетевых ресурсов (серверов и инфраструктуры) для вычислений и хранения. A бездисковая узел загружает даже его операционной системы из сети, и компьютерный терминал не имеет операционной системы на всех; это только интерфейс ввода / вывода для сервера. Напротив, толстый клиент , такой как персональный компьютер , имеет много ресурсов и не полагается на сервер для выполнения основных функций.

По мере того, как с 1980-х до конца 1990-х годов микрокомпьютеры падали в цене и становились все более мощными, многие организации перевели вычисления с централизованных серверов, таких как мэйнфреймы и миникомпьютеры , на толстые клиенты. Это давало более индивидуализированное господство над компьютерными ресурсами, но усложняло управление информационными технологиями . В течение 2000-х веб-приложения стали достаточно зрелыми, чтобы конкурировать с прикладным программным обеспечением, разработанным для конкретной микроархитектуры . Это развитие, более доступное запоминающее устройство и появление сервис-ориентированной архитектуры были одними из факторов, которые привели к появлению в 2010-х годах тенденции к облачным вычислениям .

Сравнение с одноранговой архитектурой

В дополнение к модели клиент-сервер, распределенные вычислительные приложения часто используют равный-равному (P2P) архитектуру приложения.

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

Балансировка нагрузки определяется как методичное и эффективное распределение сетевого трафика или трафика приложений между несколькими серверами в ферме серверов. Каждый балансировщик нагрузки находится между клиентскими устройствами и внутренними серверами, получая и затем распределяя входящие запросы на любой доступный сервер, способный их выполнять.

В одноранговой сети два или более компьютеров ( одноранговых узла) объединяют свои ресурсы и обмениваются данными в децентрализованной системе . Одноранговые узлы - это равноправные или равноправные узлы в неиерархической сети. В отличие от клиентов в сети клиент-сервер или клиент-очередь-клиент , одноранговые узлы взаимодействуют друг с другом напрямую. В одноранговой сети алгоритм в протоколе одноранговой связи балансирует нагрузку , и даже одноранговые узлы со скромными ресурсами могут помочь распределить нагрузку. Если узел становится недоступным, его общие ресурсы остаются доступными, пока его предлагают другие одноранговые узлы. В идеале одноранговому узлу не нужно достигать высокой доступности, потому что другие, избыточные одноранговые узлы компенсируют любое время простоя ресурсов ; при изменении доступности и нагрузочной способности одноранговых узлов протокол перенаправляет запросы.

И клиент-сервер, и главный-подчиненный рассматриваются как подкатегории распределенных одноранговых систем.

В 2014 году в работе SSL обнаружили уязвимость, кроме того он стал устаревать, поэтому на основе SSL 3.0 создали стандарт TLS.

TLS (англ. Transport Layer Security) — криптографический протокол, который обеспечивает защищённую передачу данных от сервера к клиенту. В основе работы TLS симметричное шифрование для конфиденциальности, асимметричная криптография для аутентификации, коды аутентичности для сохранения целостности передаваемой информации. Он учитывает ошибки своего предшественника и продолжает развитие.

По сути различия в принципах работы SSL и TLS минимальны, поэтому когда говорят об SSL, подразумевается TLS.

Принцип работы TLS

Процесс работы TLS можно разбить на несколько этапов:

TLS Handshake
TLS False Start
TLS Chain of trust

TLS Handshake — согласует параметры соединения между клиентом и сервером (способ шифрования, версию протокола), а также проверяет сертификаты. Данная процедура использует большое количество вычислительных ресурсов, поэтому, чтобы каждый раз не устанавливать новое соединение и не проверять сертификаты повторно, была разработана процедура TLS False Start.

TLS False Start — процедура возобновления сессии. Если ранее открывалась сессия между клиентом и сервером, данный этап позволяет пропустить процедуру Handshake, используя данные, которые были сконфигурированы ранее. Однако в целях безопасности каждая сессия имеет свой срок жизни и, если он истек, она будет повторно открыта с помощью процедуры TLS Handshake.

Таким образом, при передаче данных сначала вызывается процедура TLS Handshake или TLS False Start, которая согласовывает параметры, а затем TLS Chain of trust, которая обеспечивает аутентификацию (проверку авторства передаваемой информации).

Подробнее с принципами работы TLS вы можете ознакомиться в официальной документации Datatracker .

Параметры безопасности протокола TLS

Установка SSL/TLS

В компании сайт вы можете выбрать и приобрести , который работает по TLS 1.2:

После выпуска сертификата установите его самостоятельно по одной из инструкций .

Начинайте с очистки кэша и куки

Отключите лишние расширения

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

Попасть в меню управления плагинами достаточно просто. Можете просто скопировать этот путь в своем браузере:

Chrome: chrome://extensions/
Яндекс Браузер: browser://tune/
Opera: opera://extensions
Firefox: about:addons.

Файрвол и антивирус

Последние версии антивирусных программ содержат в себе опцию проверки SST/TLS сертификатов. Опция эта работает в автоматическом режиме. Если антивирусник заметит, что интернет-платформа применяет самоподписанный или плохо защищенный сертификат (бесплатные SSL) – он может ограничить к ней доступ. Это также касается неактуальной версии SSL-протокола.

Часовой пояс

Сертификаты ОС

Поддержка протоколов

На сегодняшний день браузеры не используют ненадежные старые протоколы и уже давно перешли на актуальные. Чтобы активировать устаревшие протоколы SSL/TLS необходимо:

Если и этот способ не помог, то можно попробовать такой вариант:

Заключение

Как показывает практика – на обновленных Windows такие ошибки на сайтах не выскакивают, а клиент и сервер поддерживают совместимые версии ssl-протоколов и наборы шифров соответствуют всем требованиям. В случае с закупками советуем обновить Internet Exprolel и провести настройку доступов, строго придерживаясь указанной в ссылке инструкции.

Протокол SSL

Протокол SSL использует как симметричный, так и асимметричный ключи.

Особенности и назначение протокола SSL

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

Многослойная структура представлена слоем протокола подтверждения подключения и слоем протокола записи. Первым слоем выступает транспортный протокол, например, TCP — вместе с SSL Record Protocol данные слои образуют ядро SSL, которое впоследствии участвует в формировании сложных инфраструктур.

Среди основных особенностей протокола SSL следует отметить программно-платформенную независимость. В настоящее время протокол SSL не обеспечивает должную защиту — на смену ему пришел протокол TLS.

Протокол TLS

К основным мерам безопасности, которые обеспечивает протокол TLS, относятся:

Особенности и назначение протокола TLS

В протоколе TLS используются следующие алгоритмы:

RC4, Triple DES, SEED, IDEA и др. для симметричного шифрования.
RSA, DSA, Diffie-Hellman и ECDSA для проверки подлинности ключей.
MD5, SHA и SHA-256/384 для хэш-функций.

Приложения осуществляют обмен записями, которые хранят в себе данные. Записи могут быть сжаты, дополнены, зашифрованы или же идентифицированы. При этом в каждой записи указываются данные о длине пакета и используемой версии TLS.

В общем случае применение криптографии в протоколах SSL/TLS значительно снижает производительность приложений, зато обеспечивает надежную защиту передачи данных. Протоколы не требуют практически никаких настроек с клиентской стороны, считаются самыми распространенными протоколами защиты в сети интернет.

Довольно часто ситуация с протоколом TLS возникает на браузере IE – популярном инструменте работы со специальными государственными порталами, связанными с различными формами отчётности. Работа с такими порталами требует обязательного наличия браузера Internet Explorer, и именно на нём рассматриваемая проблема возникает особенно часто.

Решение возникшей проблемы может состоять в способах, описанных ниже. Но перед их описанием рекомендую просто перезагрузить ваш ПК – при всей тривиальности данный способ часто оказывается довольно эффективным.

Если же он не помог, тогда выполните следующее:

Заключение

Протокол TLS шифрует интернет-трафик всех видов, тем самым делая безопасными общение и продажи в интернете. Мы расскажем о том, как протокол работает и что нас ждет в будущем.

Из статьи вы узнаете:

Что такое SSL

SSL или слой защищенных сокетов было оригинальным названием протокола, который разработала компания Netscape в середине 90-х. SSL 1.0 никогда не был публично доступным, а в версии 2.0 были серьезные недостатки. Протокол SSL 3.0, выпущенный в 1996, был полностью переделан и задал тон следующей стадии развития.

Что такое TLS

TLS также используется другими приложениями - например, в почте и системах телеконференций.

Как работает TLS

Шифрование необходимо, чтобы безопасно общаться в интернете. Если ваши данные не шифруются, любой может проанализировать их и прочитать конфиденциальную информацию.

Самый безопасный метод шифрования - это асимметричное шифрование . Для этого требуется 2 ключа, 1 публичный и 1 приватный. Это файлы с информацией, чаще всего очень большие числа. Механизм сложный, но если попросту, вы можете использовать публичный ключ, чтобы шифровать данные, но вам нужен приватный ключ, чтобы расшифровывать их. Два ключа связаны с помощью сложной математической формулы, которую сложно хакнуть.

Можно представить публичный ключ как информацию о местоположении закрытого почтового ящика с отверстием, и приватный ключ как ключ, который открывает ящик. Любой, кто знает, где находится ящик, может положить туда письмо. Но чтобы прочитать его, человеку нужен ключ, чтобы открыть ящик.

Так как в асимметричном шифровании применяются сложные математические расчеты, нужно много вычислительных ресурсов. TLS решает эту проблему, используя асимметричное шифрование только в начале сессии, чтобы зашифровать общение между сервером и клиентом. Сервер и клиент должны договориться об одном ключе сессии, который они будут вдвоем использовать, чтобы зашифровать пакеты данных.

Процесс, согласно которому клиент и сервер договариваются о ключе сессии, называется рукопожатием . Это момент, когда 2 общающихся компьютера представляются другу другу.

Процесс TLS-рукопожатия

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

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

Ключ сессии действителен только в течение одной непрерывной сессии. Если по какой-то причине общение между клиентом и сервером прервется, нужно будет новое рукопожатие, чтобы установить новый ключ сессии.

Уязвимости протоколов TLS 1.2 и TLS 1.2

TLS 1.2 - самая распространенная версия протокола. Эта версия установила исходную платформу опций шифрования сессий. Однако, как и некоторые предыдущие версии протокола, этот протокол разрешал использовать более старые техники шифрования, чтобы поддерживать старые компьютеры. К сожалению, это привело к уязвимостям версии 1.2, так как эти более старые механизмы шифрования стали более уязвимыми.

Например, протокол TLS 1.2 стал особенно уязвимым к атакам типа активного вмешательства в соединение, в которых хакер перехватывает пакеты данных посреди сессии и отправляет их после прочтения или изменения их. Многие из этих проблем проявились за последние 2 года, поэтому стало необходимым срочно создать обновленную версию протокола.

TLS 1.3

Версия 1.3 протокола TLS, которая скоро будет финализирована, решает множество проблем с уязвимостями тем, что отказывается от поддержки устаревших систем шифрования.
В новой версии есть совместимость с предыдущими версиями: например, соединение откатится до версии TLS 1.2, если одна из сторон не сможет использовать более новую систему шифрования в списке разрешенных алгоритмов протокола версии 1.3. Однако при атаке типа активного вмешательства в соединение, если хакер принудительно попытается откатить версию протокола до 1.2 посреди сессии, это действие будет замечено, и соединение прервется.

Как включить поддержку TLS 1.3 в браузерах Google Chrome и Firefox

Firefox и Chrome поддерживают TLS 1.3, но эта версия не включена по умолчанию. Причина в том, что она существует пока только в черновом варианте.

Mozilla Firefox

Введите about:config в адресную строку браузера. Подтвердите, что вы осознаете риски.

Откроется редактор настроек Firefox.
Введите в поиске security.tls.version.max
Поменяйте значение на 4, сделав двойной щелчок мышью на нынешнее значение.

Google Chrome

Как проверить, что ваш браузер использует версию 1.2

Напоминаем, что версия 1.3 еще не используется публично. Если вы не хотите
использовать черновой вариант, вы можете остаться на версии 1.2.

Чтобы проверить, что ваш браузер использует версию 1.2, проделайте те же шаги, что и в инструкциях выше, и убедитесь, что:

Для Firefox значение security.tls.version.max равно 3. Если оно ниже, поменяйте его на 3, сделав двойной щелчок мышью на нынешнее значение.
Для Google Chrome: нажмите на меню браузера - выберите Settings - выберите Show advanced settings - опуститесь до раздела System и нажмите на Open proxy settings… :

В открывшемся окне нажмите на вкладку Security и проверьте, чтобы для поля Use TLS 1.2 стояла галочка. Если не стоит - поставьте и нажмите OK:

Быстрый инструмент для проверки версии протокола SSL/TLS браузера

Зайдите в онлайн-инструмент проверки версии протокола SSL Labs . Cтраница покажет в реальном времени используемую версию протокола, и подвержен ли браузер каким-то уязвимостям.

Клиент – локальный компьютер на стороне виртуального пользователя, который выполняет отправку запроса к серверу для возможности предоставления данных или выполнения определенной группы системных действий.

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

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

Если одновременно поступает более одного запроса, то такие запросы устанавливаются в определенную очередь и сервером выполняются по очереди. Порой запросы могут иметь свои собственные приоритеты. Часть запросов с более высокими приоритетами будут постоянно выполняться в первоочередном порядке!

Параметры, которые могут реализоваться на стороне сервера:

Хранение, защита и доступ к данным;
Работа с поступающими клиентскими запросами;
Процесс отправки ответа клиенту.

Параметры, которые могут реализоваться на стороне клиента:

Площадка по предоставлению пользовательского графического интерфейса;
Формулировка запроса к серверу и его последующая отправка;
Получение итогов запроса и отправка дополнительной группы команд (запросы на добавление, обновление информации, удаление группы данных).

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

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

Виды сетевых протоколов

TCP/IP – совокупность протоколов передачи информации. TCP/IP – это особое обозначение всей сети, которая функционирует на основе протоколов TCP, а также IP.

TCP – вид протокола, который является связующим звеном для установки качественного соединения между 2 устройствами, передачи данных и верификации их получения.

MAC – вид протокола, на основании которого происходит процесс верификации сетевых устройств. Все устройства, которые подключены к сети Интернет, содержат свой оригинальный MAC-адрес.

ICMP – протокол, который ответственен за обмен данными, но не используется для процесса передачи информации.

UDP – протокол, управляющий передачей данных, но данные не проходят верификацию при получении. Этот протокол функционирует быстрее, чем протокол TCP.

FTP – протокол передачи информации из особого файлового сервера на ПК конечного пользователя.

POP3 – классический протокол простого почтового соединения, который ответственен за передачу почты.

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

Концепции постройки клиент-серверной системы

Слабый клиент – производительный сервер.
При такой модели весь процесс обработки информации перенесен на мощности сервера, а у пользователя права доступа очень строго ограничены. Сервер начинает отправлять ответ, который вообще не требует дополнительной работы по обработке. Клиент взаимодействует с пользователем: создает и отправляет запрос, принимает входящие итоги и выводит данные на экран пользователя.

Сильный клиент.
Концепция, при которой часть обработки данных предоставляет клиенту. В такой ситуации сервер является простым хранилищем информации, а вся деятельность по обработке и предоставлению данных переносится на ПК пользователя.

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

Есть сразу 2 вида клиент-серверных архитектур:

1. Двухуровневая, состоящая сразу из 2 узлов:

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

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

2. Трехуровневая система состоит из использования таких компонентов:

предоставление информации – графический пользовательский, прикладной объект в виде сервера приложения;
менеджмент ресурсов – сервер БД, который может предоставлять данные.

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

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

Итоги

Нюансы взаимодействия системы клиент-сервер позволяют пользователям разделять определенный функционал и вычислительную нагрузку между подключенными клиентскими веб-продуктами и серверными приложениями при разнообразных процессах тестирования (от тестирования БД до замеров общей производительности системы).

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

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

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

Любое веб-приложение, если оно работает в браузере, работает на 3 основных технологиях: HTML, CSS и JS. Ещё есть WASM, но о нём в этой статье мы говорить не будем.

Все приложения, которыми вы пользуетесь в браузере: GoogleDocs, Notion, Яндекс.Карты, Spotify, YouTube — сделаны с помощью этих технологий.

Но любое сложное приложение — это не только картинка в браузере, это ещё и данные, которые пользователи используют или создают. Эти данные нужно уметь хранить, обрабатывать и выводить.

Хранением и обработкой данных обычно занимается сервер или бэкенд.

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

А архитектура, в которой участвуют сервер (бэкенд) и клиент (браузер, фронтенд) называется клиент-серверной.

Клиент-серверная архитектура

Начнём с самого понятия.

Архитектура — это описание системы на самом высоком уровне.

Клиент-серверная архитектура описывает, как взаимодействуют между собой клиент (в нашем случае фронтенд) и сервер (бэкенд).

Самый канонический вид такой архитектуры таков:

Клиент

Клиент обращается с запросами к серверу.

Запросы могут быть разные. Клиент может попросить сервер отдать какие-то данные или попросить их как-то подготовить перед отдачей. Или же может попросить сервер сохранить что-то, что передаст вместе с запросом сам.

Роль клиента для сервера в том, чтобы сообщить серверу, что нужно сделать с данными, которые хранятся в базе, или с данными, которые он передаёт.

Роль клиента для пользователя в том, чтобы представить данные в удобном виде и предоставить механизмы для их обновления.

Для веба клиент почти всегда браузер.

Сервер

Сервер принимает запросы от клиента.

Его роль в том, чтобы сохранять информацию от клиента в базе данных, обрабатывать её и предоставлять к ней доступ по некоторым правилам. Такие правила обычно называются бизнес-логикой.

На сервере помимо общения с клиентом могут запускаться какие-то фоновые задачи, например, индексирование информации в базе данных для более быстрого поиска, или запуск автоматических email-рассылок.

База данных

База данных (БД) — это хранилище всей пользовательской и служебной информации.

Её роль в том, чтобы обеспечивать быстрый и бесперебойный доступ к этой информации и собственно хранение.

Пример

Возьмём Твиттер. В этом приложении клиентом будет выступать весь его фронтенд: HTML-страницы, CSS-стили, JS-скрипты для взаимодействия пользователя с UI.

Сервером будет его бэкенд. Все технологии, которые используются, чтобы предоставлять информацию из баз данных клиенту через API.

Базами данных (в множественном числе, потому что их много) будут все технологии, которые занимаются хранением, дупликацией, резервированием данных и обеспечением бесперебойной работы.

Развитие веб-приложений

На клиент-серверной архитектуре построена большая часть приложений. Однако первые приложения всё же немного отличались от нынешних в деталях реализации. Главным отличием была полная перезагрузка страницы в ответ на любое действие.

Первые приложения

Самые первые веб-приложения не сильно отличались от обычных сайтов.

По сути это и были сайты, потому что вся бизнес-логика реализовывалась на сервере. Клиент лишь показывал результат в виде HTML-страниц пользователю и посылал запросы на другие страницы.

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

AJAX (Asynchronous JavaScript and XML) — общение между клиентом и сервером без перезагрузки страницы.

При нажатии браузер пошлёт запрос на сервер, в котором сообщит, что ему необходимо отсортировать такой-то список по такому-то критерию.

Сервер обработает запрос, достанет нужные данные, отсортирует их и отправит клиенту готовый кусок интерфейса, который клиент уже вставит в документ.

Заметьте, что мы всё ещё не передаём данные в чистом виде. Сейчас на клиенте мы принимаем кусок HTML-разметки, который потом встраиваем в нужное место в документе.

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

Современные приложения

В современных приложениях между клиентом и сервером общение строится именно на данных, а не на отрендеренных кусках разметки. Чаще всего для такого общения выбирают JSON.

Сейчас большая часть приложений работает так:

Плюсов такого общения (когда передаются только данные) несколько:

Сервер и клиент становятся независимыми друг от друга. Сервер может ничего не знать об устройстве страниц, ему достаточно лишь уметь работать с БД и обрабатывать данные (первичная отрисовка может быть сделана самим сервером с помощью SSR).
Количество информации, которое приходится передавать и принимать, меньше — а это уменьшает объём трафика.
Логика приложения на сервере может быть проще, потому он и клиент становятся менее зависимы друг от друга в плане формата данных.

Разделение ответственности

Такое общение между сервером и клиентом очень напоминает паттерн MVC.

MVC (Model-View-Controller) — структура приложения, в которой за данные, их обработку и их вывод отвечают три разных сущности.

Модель (model) отвечает за данные и их структуру.
Представление (view) — за их отображение.
Контроллер (controller) — за их обработку.

Если попробовать сравнить классическую клиент-серверную архитектуру с MVC, то можно сравнить БД с моделью, сервер с контроллером, а клиент с представлением.

В самых первых приложениях, в принципе, так и было. Сейчас, однако, клиент стал сложнее, поэтому MVC может быть и часть архитектуры клиентского приложения.

MVC на клиенте

Возьмём для примера Notion. Его веб-версия работает прямо в браузере, однако это полноценный текстовый редактор.

Большая часть работы при вводе текста происходит на клиенте. Чтобы такие сложные приложения работали, а в их коде можно было разобраться, клиентский код разработчики тоже стараются писать по правилам и следуя лучшим архитектурным практикам.

Одной из таких практик как раз является разделение данных и представления.

Как бы текстовый редактор сделали 20 лет назад

Если забыть про невозможность сохранить написанное на сервере, то попробовать написать текстовый редактор можно было и тогда. Но, скорее всего, результатом был бы кусок разметки с инлайновыми стилями и текстом внутри.

Работать такими данными, которые перемешаны с особенностями представления, не удобно, а иногда и невозможно.

Текстовые редакторы сейчас

. чаще всего делают, разделяя данные от их представления.

Так нам больше не нужно находить текст и чистить его от стилей, потому что в нём содержится только текст и некоторые его атрибуты.

Это делает работу с данными сильно проще — можно выгрузить документ в разных форматах: .md , .html , .txt .
С таким представлением проще работать в самом коде — отчего и сам код становится проще для понимания.
Его удобнее хранить в памяти, как состояние приложения.

Состояние приложения

Текстовый редактор из нашего примера выше — это приложение с состоянием.

Состояние приложения — это все данные этого приложения на текущий момент.

В случае с текстовым редактором — это весь текст, который пользователь ввёл, а также результаты преобразований над этим текстом.

Разумеется, текстовые редакторы не единственный вид таких приложений. Любое приложение, которое хранит что-то перед отправкой (или даже без отправки) на сервер — это приложение с состоянием.

Плюсы в выделении состояния те же:

данные перестают зависеть от того, как мы хотим их представлять;
их проще обрабатывать и хранить;
представление проще менять.

Как правило, состояние в приложениях на JS — это какой-то объект или массив объектов в памяти.

Такой вид состояния не только удобен в использовании внутри приложения, но ещё и прост в сохранении с помощью JSON.

Кроме этого приложения, в которых за состояние отвечает отдельный модуль, проще развивать и изменять.

Сейчас есть много подходов и инструментов для управления состоянием. Из самых популярных можно назвать: Redux (и основанные на его подходе Vuex, NgRx), MobX, Overmind.

JSON — один из самых популярных форматов данных. Он немногословен, понятен и человеку, и компьютеру, много языков с ним уже умеют работать.

В вебе JSON, можно сказать, стандарт, потому что используется как формат по умолчанию во многих фреймворках.

Состояние из примера выше в формате JSON выглядело бы так:

Запросы и ответы

Как мы помним, клиент-серверная архитектура строится на запросах и ответах. Разберёмся, что использует браузер, чтобы послать на сервер какой-то запрос.

fetch

На уровне приложения мы используем встроенное браузерное API, а именно — fetch . Это глобальный метод для отправки запросов.

В примере выше, чтобы сохранить состояние на сервере, мы бы использовали его примерно так:

Здесь мы отправляем запрос по адресу /api/save-text с телом JSON.stringify(State) . Адрес и тело (данные) — понятно, а что такое method: "POST" ?

Они указывают, какое действие мы хотим выполнить. В примере method: "POST" сообщит серверу, что мы хотим создать новый ресурс и сохранить в него содержимое body .

Если бы мы хотели получить какой-то ресурс, мы бы использовали GET . Для редактирования — PATCH , для замены — PUT , а для удаления — DELETE .

Описывать сам протокол мы не будем, это большая спецификация, для которой бы понадобилась отдельная статья.

REST (Representational State Transfer) — стиль общения компонентов, при котором все необходимые данные указываются в параметрах запроса.

Отличительная особенность этого стиля — это стиль построения адресов и выбор метода.

Как мы можем видеть, основа адреса не меняется, а желаемое действие выражается методом.

Сейчас именно на основе REST работает множество сервисов и приложений.

Развитие веба и объёмы данных

С развитием веба и интернета в целом пришло время больших объёмов данных. Картинки по 10 МБ уже никого не удивляют.

Вместе с большими объёмами пришли и проблемы с их передачей, потому что трафик поначалу был очень дорогим. Он и сейчас в некоторых случаях не дешёвый.

Кэширование

Отчасти решением стало кэширование ресурсов. С картинками это помогло — картинки из кэша не съедают трафик, потому что не гонятся по сети.

Со скриптами и стилями — помогло отчасти, потому что объём лишь одна часть проблемы. Вторая часть — это парсинг и исполнение. Особенно остро эта проблема стоит со скриптами, потому что скрипты весом в 10 МБ уже тоже не редкость.

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

Код-сплиттинг

Одним из решений стал код-сплиттинг. Это техника, при которой в скрипте оказывается только необходимый на конкретной странице код, а остальной код догружается по мере необходимости.

Middle-end

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

REST известен не только своим удобством, но и (иногда) чрезмерной избыточностью.

Проблема в том, что REST система проектируется так, чтобы как можно реже меняться при изменении клиента. Из-за этого данные, отдаваемые в ответ, могут содержать детали, которые клиентом использоваться не будут.

Просто так их убрать зачастую бывает нельзя, потому что это противоречит обратной совместимости. Плодить много однотипных эндпоинтов, которые будут отличаться небольшой деталью — дорого и нецелесообразно.

Поэтому сейчас сообщество смотрит в сторону некого мидл-энда — такого слоя между клиентом и сервером (или сразу БД), который бы удалял всё лишнее, что клиенту не требуется, и отдавал бы лишь необходимые данные, таким образом сократив объём. Как, например, GraphQL.

Заключение

В этой статье мы рассмотрели лишь самые основы работы веб-приложений, не затрагивая деталей.

Мы узнали о клиент-серверной архитектуре, разделении данных от представления и том, как они используются в современных приложениях. Также мы рассмотрели, что такое состояние приложения и поговорили о REST, как одном из распространённых способов построения API.

Эти понятия помогут вам понять работу большей части приложений, с которыми вы можете столкнуться.

Сеть – это структура, позволяющая вычислительным машинам взаимодействовать между собой, отправлять и принимать данные и команды. Сети включают в себя компьютеры, среду передачи информации и, как правило, дополнительное сетевое оборудование, делятся на локальные (LAN, Local Area Network) и глобальные (WAN, Wide Area Network) сети. Для того чтобы компьютеры и сетевое оборудование могли понимать друг друга, были разработаны протоколы компьютерных сетей.

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

Модель сети – теоретическое описание принципов работы набора сетевых протоколов, взаимодействующих друг с другом. Модель обычно делится на уровни, так, чтобы протоколы вышестоящего уровня использовали бы протоколы нижестоящего уровня (точнее, данные протокола вышестоящего уровня передавались бы с помощью нижележащих протоколов – этот процесс называют инкапсуляцией, процесс извлечения данных вышестоящего уровня из данных нижестоящего – деинкапсуляцией). Модели бывают как практические (использующиеся в сетях, иногда запутанные и/или не полные, но решающие поставленные задачи), так и теоретические (показывающие принципы реализации сетевых моделей, приносящие в жертву наглядности производительность/возможности).

Наиболее известные сетевые модели:

1. модель OSI – теоретическая, эталонная модель, описанная в международных стандартах;

2. модель DOD (Модель TCP/IP) – практически использующаяся модель, принятая для работы в Интернете.

3. модель AppleTalk – модель работы сетей с оборудованием фирмы Apple;

4. модель SPX/IPX – модель стека SPX/IPX (семейство протоколов для локальных вычислительных сетей).

Международная организация по стандартизации (International Organization for Standardization, ISO) приняла в качестве эталонной сетевой модели OSI (Open Systems Interconnection Basic Reference Model, базовая эталонная модель взаимодействия открытых систем; 1978 г.). Модель OSI предлагает взгляд на компьютерную сеть с точки зрения измерений. Каждое измерение обслуживает свою часть процесса взаимодействия. Благодаря такой структуре совместная работа сетевого оборудования и программного обеспечения становится гораздо проще и прозрачнее.

Состоит из семи уровней протоколов. Приложения обращаются с сетью с помощью седьмого уровня, называемого прикладным. Модель OSI заканчивается первым уровнем — физическим, на котором определены стандарты, предъявляемые независимыми производителями к средам передачи данных:

1. тип передающей среды (медный кабель, оптоволокно, радиоэфир и др.),

2. тип модуляции сигнала,

3. сигнальные уровни логических дискретных состояний (нуля и единицы).

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

Любой протокол модели OSI должен взаимодействовать либо с протоколами своего уровня, либо с протоколами на единицу выше и/или ниже своего уровня. Взаимодействия с протоколами своего уровня называются горизонтальными, а с уровнями на единицу выше или ниже — вертикальными. Любой протокол модели OSI может выполнять только функции своего уровня и не может выполнять функций другого уровня, что не выполняется в протоколах альтернативных моделей.

Уровни модели OSI:

1. Физический (physical) – на этом уровне осуществляется работа со средой передачи, сигналами и двоичными данными;

2. Канальный (data link) – осуществляется физическая адресация устройств в сети;

3. Сетевой (network) – происходит определение маршрута и логическая адресация устройств;

4. Транспортный (transport) – осуществляется Прямая связь между конечными пунктами и обеспечивается надежность передачи данных;

5. Сеансовый (session) – происходит управление сеансом связи;

6. Представительский (presentation) – обеспечивается представление и шифрование данных;

7. Прикладной (application) – организуется доступ приложение к сетевым службам.

К базовым сетевым технологиям относятся физический и канальный уровни.

Для запоминания названий 7-и уровней модели OSI на русском языке рекомендуют использовать фразу “Просто представь себе тачку, стремящуюся к финишу”, в которой первые буквы слов соответствуют первым буквам названий уровней.

Несмотря на то, что эталонная модель OSI в настоящее время является общепризнанной, исторически и технически открытым стандартом сети Internet являются протокол управления передачей (Transmission Control Protocol — TCP) и Internet-протокол (IP), которые обычно рассматриваются как одно целое и обозначаются TCP/IP. Эталонная модель TCP/IP, разработанная ещё до принятия модели OSI и вне связи с ней, и стек протоколов TCP/IP позволяют организовать связь между двумя компьютерами, расположенными в любых точках земного шара, со скоростью, близкой к скорости света.

Министерство обороны США (Department of Defence — DoD) создало почву для разработки эталонной модели TCP/IP, поскольку оно требовало, чтобы сеть продолжала функционировать в любых условиях, даже в случае ядерной войны. Для более наглядной иллюстрации представим себе мир, находящийся в состоянии ядерной войны, и пронизанный самыми разными типами соединений, включая проводные, микроволновые соединения, оптоволоконные кабели и спутниковую связь.

Предположим далее, что требуется, чтобы информация и данные (в виде пакетов) надежно передавались по этой сети независимо от состояния любого конкретного узла этой сети или состояния другой сети (которая в данном случае может быть уничтожена в ходе военных действий). Министерство обороны требовало, чтобы в любых условиях его данные продолжали передаваться по сети между любыми точками. Эта весьма сложная задача проектирования устойчивой сети привела к созданию сетевой модели TCP/IP (модели DoD), которая с тех пор стала стандартом, на базе которого выросла глобальная сеть Internet. При изучении уровней модели TCP/IP следует помнить о первоначальных целях, которые ставились перед сетью Internet; это поможет понять некоторые, возможно, неясные аспекты проблемы.

Уровни сетевой модели TCP/IP (модели DoD)

Сетевая модель TCP/IP имеет четыре уровня:

Уровень 4 — прикладной уровень или уровень приложений (application);

Уровень 3 — транспортный уровень (transport);

Уровень 2 — межсетевой или Internet-уровень (network);

Уровень 1 — канальный или уровень доступа к сети (data link).

Необходимо отметить, что некоторые уровни модели TCP/IP имеют те же названия, что и у уровней эталонной модели OSI. Однако не следует отождествлять одноименные уровни этих двух моделей. Функции одноименных уровней обеих моделей могут совпадать, но могут и различаться.

Подобное деление, на мой взгляд, упростило понимание того, как организованы компьютерные сети. Такое упрощение никак не затронуло функциональные возможности этой модели. Все функции, присущие модели OSI, полностью поддерживаются этой моделью. Эта сетевая модель также не зависит от среды передачи данных.

Самый нижний уровень модели DOD называется уровнем сетевого доступа (Network Access). Он соответствует двум уровням модели OSI: физическому и канальному. Уровень сетевого доступа отвечает за доставку данных к физическим сетевым устройствам, таким как сетевые адаптеры, в виде кадров (фреймов, от англ. Frame). На нем работают такие протоколы, как Ethernet, IEEE 802.11 (известный как Wi-Fi) и 802.16 (WiMAX), а также некоторые другие, не столь привычные для большинства пользователей. Они служат для того же, для чего обыкновенной почте нужны поезда, самолеты и курьеры, – то есть выступают в качестве транспорта.

Поэтому выше располагаются протоколы транспортного уровня (Transport) модели DOD, который соответствует одноименному уровню OSI. Два самых известных протокола транспортного уровня – TCP и UDP.

Порт – это номер, который по возможности однозначно сопоставляется с протоколом верхнего уровня. Сопоставлением портов TCP и UDP с определенными протоколами прикладного уровня занимается IANA (Internet Assigned Numbers Authority, Администрация адресного пространства Интернет). Примеры некоторых портов приведены в таблице 2.4.1.

Таблица 2.4.1 – Примеры некоторых портов для протоколов прикладного уровня

Для того, чтобы пакет информации попал на нужный компьютер (правильнее сетевой интерфейс) служит протокол IP (Internet Protocol). Это протокол сетевого уровня модели OSI и межсетевого – модели DOD. На данный момент больше всего распространена его четвертая версия, однако мир медленно, но верно готовится переходить на более новую шестую. В четвертой версии протокола адрес сетевого интерфейса (компьютера) имеет вид наподобие 213.192.111.5 – четыре числа от 0 до 255, разделенных точками. На самом деле каждое число от 0 до 255 – это 8 бит, то есть IP-адрес состоит из четырех фрагментов по 8 бит (октетов), а всего из 32 бит. Соответственно, пакет IP содержит IP-адреса получателя и отправителя. В пределах сети каждый сетевой интерфейс снабжается уникальным IP-адресом. То есть в Интернете не может быть двух компьютеров с одинаковыми IP-адресами, так же, как их не может быть в отдельно взятой локальной сети. При этом в разных локальных сетях могут встречаться сетевые карты с одинаковыми IP-адресами. В Интернете они напрямую не видны. Для передачи пакетов IP между разными сетями, например между локальной и Интернетом, используются маршрутизаторы (они же роутеры).

Для использования в локальных сетях выделено три специальных IP-диапазона: 192.168.0.0-192.168.255.255, 172.16.0.0-172.31.255.255, 10.0.0.0-10.255.255.255. Адреса из этих множеств отличаются тем, что в адресном пространстве глобальной сети Интернет они отсутствуют. Это было сделано для того, чтобы при подключении нескольких машин одной локальной сети через общий шлюз не выделять Интернет-адрес на каждую. Благодаря этому адресов Ipv4 хватало на всех до самого недавнего времени. Таким образом, при построении локальной сети адреса ее устройствам назначаются из одного из этих множеств, в зависимости от размера локальной вычислительной сети. В малых офисных и домашних сетях используется диапазон 192.168.0.0-192.168.255.255, в районных адреса от 172.16.0.0 и до 172.31.255.255.

В Интернете адреса выдаются согласно решениям IANA. Эта организация упоминалась выше в связи с припиской портов определенным протоколам прикладного уровня, она же выдает IP-адреса крупным региональным регистраторам, которые раздают их более мелким компаниям, а они уже приписывают IP-адреса конкретным ресурсам. Запас свободных Ipv4-адресов подошел к концу, и именно из-за этого постепенно внедряют Ipv6, в котором адреса имеют длину в 128 бит и пишутся обычно восьмью группами по четыре шестнадцатеричных цифры (от 0 до F).

Windows Sockets

Winsock или Windows Sockets – это интерфейс программирования приложений (API) созданный для реализации программ в сети на основе протоколов TCP/IP.

В настоящее время существует две основные версии Winsock API:

1. WinSock 1.1 – осуществляется поддержка только протоколов TCP/IP;

2. WinSock 2.0 – введена возможность работы с самыми разными сетевыми протоколами и моделями, например SPX/IPX.

Официальная спецификация Winsock разделяет функции на три типа:

1. функции Беркли;

2. информационные функции (получение информации о наименовании доменов, службах, протоколах Интернета);

3. расширения Windows для функций Беркли.

Все функции могут быть блокирующие и неблокирующие. Обычно блокирующие это функции Беркли. То есть при работе такой функции нельзя выполнять другие функции WinSock.

Код программы, осуществляющей инициализацию интерфейса Winsock API (WSA) и его деинициализацию следующий:

const int WINSOCK_VERSION = 0x0101;

if (WSAStartup(WINSOCK_VERSION, &wsaData))

printf(“Winsock startup FAILED!\n”);

printf(“Winsock startup is successful.\n”);

printf(“Winsock cleanup FAILED!\n”);

printf(“Winsock cleanup is successful.\n”);

Программа скомпилирована как консольный проект Win32. Для успешной линковки необходимо добавить в список зависимостей приложения файл wsock32.lib, входящий в состав любого современного компилятора C++ для Windows.

Функция WSAStartup() инициализирует Winsock. Эта функция всегда вызывается самой первой при начале работы с Winsock. Ее прототип следующий:

int WSAStartup (WORD wVersionRequested, LPWSADATA lpWSAData);

Первый параметр – это версия, которая будет использоваться. Младший байт – основная версия, старший байт – расширение версии. То есть в примере, используется версия 1.1. Если инициализация состоялась, то вернется нулевое значение. Инициализация заключается в сопоставлении номера версии и реально существующей библиотеки динамической компоновки (файла с расширением DLL) в системной папке Windows.

Второй параметр – это указатель на структуру WSADATA, в которую возвратятся параметры инициализации. Структура имеет следующее определение:

typedef struct WSAData

unsigned short iMaxSockets;

unsigned short iMaxUdpDg;

char FAR * lpVendorInfo;

> WSADATA, FAR * LPWSADATA;

WSACleanup() завершает использование данного DLL файла и прерывает обращение к функциям Winsock. При удачном выполнении вернется ноль. Результат успешной работы программы приведен на рисунке 2.4.1.

Рисунок 2.4.1 – Инициализация и деинициализация Winsock API

В состав Winsock входит ряд информационных функций, например, для получения сведений об имени компьютера в сети или IP – адреса. Рассмотрим простой пример, выводящий на экран имя локальной машины.

const int WINSOCK_VERSION = 0x0101;

char szInfo[BUFSIZ];

if (WSAStartup(WINSOCK_VERSION, &wsaData))

printf(“Winsock startup FAILED!\n”);

printf(“Winsock startup is successful.\n”);

Ограждение места работ сигналами на перегонах и станциях: Приступать к работам разрешается только после того, когда.

Основные научные достижения Средневековья: Ситуация в средневековой науке стала меняться к лучшему с.

Основные идеи славянофильства: Славянофилы в своей трактовке русской истории исходили из православия как начала.

Основные признаки растений: В современном мире насчитывают более 550 тыс. видов растений. Они составляют около.

Читайте также: