C server http: Многопоточный сервер на C# за 15 минут / Хабр

.NET и C# | Протокол HTTP

 Мы запустили ТГ-канал по урокам C#

Toggle navigation

Professor Web

• C# 5.0 и .NET 4.5
  • Руководство C# — Часть 1
  • Руководство C# — Часть 2
  • Основы .NET
  • Сборки .NET
  • Потоки и файлы
  • Работа с сетью
  • Оптимизация приложений
• WPF
  • Основа WPF
  • Элементы управления WPF
  • Привязка и стили
  • Графика и анимация
  • Шаблоны WPF
  • Периферия WPF
• Темы WPF
  • Dark Blue UI
  • Dark Orange UI
• Silverlight 5
• Работа с БД
  • ADO. NET
  • Entity Framework 6
  • SQL Server 2012
  • Оконные функции
• LINQ
  • LINQ to Objects
  • LINQ to XML
  • LINQ to DataSet и SQL
  • LINQ to Entities
  • Parallel LINQ
• ASP.NET
  • Основы ASP.NET
  • Веб-сайты
  • Безопасность
  • Интернет магазин
  • ASP.NET Web Forms 4.5
  • ASP.NET MVC 5
  • Аутентификация
• Windows 8/10
  • WinRT — основы
  • WinRT — расширения
• Программы
  • Expression Blend 4
  • Visual Studio

http-server

Опубликовано: 16 июня 2016 г.

http-server – это простой сервер с командной строкой и нулевой конфигурацией.

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

Установка на глобальном уровне:

Установка с помощью npm:

npm install http-server -g

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

Использование:

http-server [path] [options]

Здесь [path] по умолчанию ./public (если папка существует) и ./ в противном случае.

Установка в качестве приложения node

 mkdir myapp
 cd myapp/
 jitsu install http-server

Если у вас jitsu не установлена, вы можете установить ее так:

npm install jitsu -g

Использование: запуск http-server локально

node bin/http-server

Теперь вы можете посмотреть свой сервер здесь: http://localhost:8080.

Доступные опции:

-p

Порт для использования (по умолчанию 8080)

-a

Адрес для использования (по умолчанию 0.0.0.0)

-d

Показывать списки директорий (по умолчанию True)

-i

Отображать autoIndex (по умолчанию True)

-e или —ext

Значение файла по умолчанию, если оно не указано (по умолчанию ‘html’)

-s или —silent

Скрывать журнал сообщений

—cors

Включить CORS с помощью заголовка Access-Control-Allow-Origin header

-o

Открыть окно браузера после запуска сервера

-c

Задать время кэширования (в секундах) для контролирующего кэш заголовка, например -c10 для 10 секунд (по умолчанию 3600). Чтобы отключить кэширование, используйте -c-1.

-U или —utc

Использовать UTC формат времени в логах.

-P или —proxy

Пересылает все запросы, которые нельзя обработать локально, на заданный URL. Например: -P http://someurl.com.

-S или —ssl

Включить https.

-C или —cert

Путь к файлу SSL-сертификата (по умолчанию cert.pem).

-K или —key

Путь к файлу SSL-ключа (по умолчанию key.pem).

-r или —robots

Ведет к файлу /robots.txt (содержание которого по умолчанию ‘User-agent: *\nDisallow: /’)

-h или —help

Напечатать список и выйти.

Что такое протокол HTTPS и как на него перейти

Протокол HTTPS

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

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

В этой статье я пошагово расскажу и покажу как перевести ваш сайт на HTTPS. Я написал подробные инструкции для пользователей разделенных хостингов с cPanel, администраторов Apache и Nginx на Linux и Unix, а также для администраторов IIS на Windows.

Начнем с самого базового.

HTTP Vs. HTTPS Vs. HTTP / 2 Vs. SSL Vs. TLS: что это такое?

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

Hypertext Transfer Protocol (HTTP)

Базовый протокол передачи данных между клиентом и сервером. Он описывает так вещи как запрос и ответ, сессии, кэш, аутентификация и прочее. Работа над ним (и HTML) была начата в 1989 году Тимом Бернерс-Ли (Tim Berners-Lee) и его командой в CERN. Первая официальная версия протокола (HTTP 1.0) была представлена в 1996 году, а чуть позже, в 1997 была выпущена версия 1.1, которой мы пользуемся и сегодня.

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

Зашифрованный канал устанавливается с помощью протокола Transport Layer Security (TLS), который раньше назывался Secure Socket Layer (SSL). Эти сроки, как правило, взаимозаменяемы, ведь SSL 3.0 был заменен TLS 1.0. SSL был протоколом, разработанным Netscape, в то время как TLS — стандарт IEFT. Все версии SSL (1.0, 2.0, 3.0) считаются устаревшими из-за проблем с безопасностью и будут вызывать предупреждения в браузеров. Версии TLS (1.0, 1.1, 1.2) используются и сейчас, а TLS 1.3 находится в разработке.

То есть, где-то между 1996 и 1997 образовался тот способ передачи данных, который мы знаем (HTTP 1.1 с или без SSL и TLS). Ранее HTTP использовали для общего трафика (например, чтение новостей), а для важного трафика — HTTPS (аутентификация, e-commerce). Но восходящий фокус на приватности привнес свои изменения, и теперь Chrome обозначает HTTP-сайты как «не частные».

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

В HTTP 1.1 безопасное соединение является опцией, в то время как в HTTP / 2 это почти необходимость. В теории данные передавать можно и без этого, но уже большинство разработчиков браузеров сказали которые не будут даже добавлять поддержку HTTP / 2 без TLS.

Предоставляющая HTTPS

Почему все так гоняются за HTTPS, что в нем такого? Его используют по трем причинам:

Конфиденциальность

HTTPS защищает коммуникацию между клиентом и сервером от посторонних лиц. Без HTTPS кто-то может запустить точку доступа Wi-Fi и видеть все данные, за ней идут: номера кредитных карточек, и другие важные данные.

Целостность

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

Идентификация

HTTPS гарантирует, что сайт является именно тем, кем представился. Злоумышленник с точкой доступа может отправлять нам фейковые сайты. HTTPS гарантирует, что сайт, представившийся как example.com действительно example.com

Криптография: короткое интро

Конфиденциальность, гарантия целостности и идентификация — ключевые концепты криптографии, а не фича HTTPS. Рассмотрим их.

Конфиденциальность

Конфиденциальность — основа приватности. Именно она гарантирует, что информацию не получат третьи лица. Обычно для этого информацию обрабатывают таким образом, что она по понятной (так называемой plaintext) становится непонятной (шифротекст, ciphertext). Этот процесс называется шифрованием (encryption). Обратный процесс — расшифровкой (decryption). Делать это можно по-разному, и для этого создано много алгоритмов шифрования.

И если две стороны хотят общаться с шифрованием, они должны согласовать два аспекта:

Алгоритм шифрования.
С какими параметрами, паролем или правилами (секретом) происходит шифрования.
Существует два вида алгоритмов шифрования:

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

Https-шифрование (encryption) и Обратный процесс — расшифровкой (decryption)

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

Как это работает? Представим, что Алиса и Боб хотят обмениваться какой-либо информацией конфиденциально. Каждый из них имеет пару ключей: частный и публичный. Частные ключи известны только их владельцам, публичные доступны любому.

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

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

асимметричные методы шифрования

Возникает вопрос: когда использовать симметричное шифрование, а когда асимметричное? Асимметричное шифрование используется для обмена ключом для дальнейшего общения. В реальной жизни нам не нужно использовать двунаправленный (от Алисы к Бобу и от Боба к Алисе) асимметричное шифрование. Достаточно того, что пару ключей будет одна сторона (сервер), то есть он может принимать и расшифровывать сообщения для него. Обратное направление не защищен — информацию, зашифрованную приватным ключом сервера может расшифровать любой с помощью его публичного ключа. Другая сторона (клиент) начинает общение с сервером направив ему зашифрованное его публичным ключом сообщение со случайно сгенерированным секретом. Теперь сервер (и только он) знает секрет.

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

Первая асимметричная часть рукопожатие (handshake) называется обменом ключами (key exchange).

Целостность

Одной из проблем, которые решает HTTPS является целостность данных:

Были успешно получены все данные?
Не были ли изменены данные (третьей стороной) в процессе обмена?
Чтобы убедиться, что все данные доставлены успешно используют алгоритм message digest. Вычисления кода идентификации сообщений (message authentication code, MAC. Иногда его называют тегом (tag)) — это процесс криптографической хеширования. Требованиями к такого алгоритма является невозможность

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

Идентификация

Как по идентификации? Проблемой приложений с инфраструктурой публичных ключей является то, что обе стороны не могут точно знать кто есть кто, ведь они физически разделены. Для того, чтобы убедиться кем действительно есть другая сторона, существует взаимно доверенное третья сторона — certificate authority (CA). CA выдает сертификаты, подтверждающие, что домен example.com ассоциированный с публичным ключом XXX. В некоторых случаях (сертификаты EV и OV) CA также проверяет принадлежит домен определенной компании. Правдивость этой информации гарантируется (то есть она сертифицирована) certificate authority X, и эта гарантия действительна не ранее даты Y (begins on) и не позднее даты Z (expires on). Вся эта информация хранится в одном документе, называется HTTPS сертификат. Это можно сравнить с государством (которому доверяют все), которая выдает паспорта (сертификаты) людям — все, кто доверяют государству, будут уверены в том, что владелец паспорта является тем, кем представился.

CA — это организации, которым доверено подписывать сертификаты. Операционные системы как Windows, macOS, iOS и Android имеют собственный список доверенных сертификатов. Также его имеет Firefox.

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

Https-механизм называется цепочкой доверия

Вы можете сами добавить CA в список доверенных, это очень удобно при работе с самопидписанимы сертификатами (о них мы поговорим позже).

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

Типы HTTPS сертификатов

Есть несколько типов сертификатов, но все можно разделить по категориям.

1. Валидация сервера- Domain validated (DV)

Самый популярный тип сертификата, он подтверждает, что домен и публичный ключи не подменен. Браузер устанавливает безопасное соединение с сервером и отображает панель с замочком. Кликнув по ней вы увидите надпись «Этот сайт не предоставил информации о владельце», ведь для получения этого сертификата достаточно лишь обладать доменом. DV сертификаты обычно достаточно дешевые (10 USD в год) или вообще бесплатные (см. Let’s Encrypt и Cloudflare ниже).

Extended validation (EV)

EV сертификат гарантирует, что домен принадлежит определенной компании. Это вид сертификата, вызывает наибольшее доверие. Он выдается после проверки CA организации, обладающей доменом. Это проверка:

• владения доменом
• в государственном реестре: действительно существует такая компания, или
• активная она
• в независимых бизнес реестрах (Dunn and Bradstreet, Salesforce connect.data.com, Yellow Pages и т.д.)
• верификационный телефонный звонок
• инспекция всех доменных имен в сертификате

Теперь рядом с замочком отображаться название компании, владеющей доменом, клик по которой покажет детали о компании, например, ее название и адрес. Стоят такие сертификаты от 150 до 300 USD в год.

Organization validated (OV)

Эти сертификаты похожи на EV, они гарантируют, что домен принадлежит организации, но ее название не отображается перед URL. То есть вам нужно соблюсти все правила как и для EV-сертификата, но без его плюсов. Поэтому этот сертификат наименее популярен. Стоит от 40 до 100 USD в год.

2. Количество доменов

Ранее, сертификаты выдавались только для одного домена в CN-поле. Позже было добавлено поле «subject alternative name» (SAN), теперь один сертификат мог работать для нескольких доменов. Сейчас все сертификаты выпускаются по одинаковой технологии, поэтому даже сертификат для одного домена будет поле SAN с этим самым доменом (и его www-версией). Но некоторые компании все еще отдельно продают сертификаты для одного и нескольких доменов.

Один домен

Самый популярный вид сертификата, который покрывает только один домен: example.com и www.example.com

Несколько доменов (UCC / SAN)

Такие типы сертификатов еще называют Unified Communications Certificate (UCC) или Subject Alternative Names (SAN), они могут покрывать сразу несколько доменов (или поддоменов) до определенного лимита. Обычно в цену включена оплата трех-пяти доменов, а остальные можно добавить за дополнительную цену.

Wildcard

Этот тип сертификата покрывает главный домен и все поддомены (* .example.com). Но его ограничением является то, что он покрывает только поддомены основного домена.

Конфигурация

Вспомним, что для обеспечения HTTPS-шифрование нужно:

• Обменяться ключом. Здесь используются асимметричные алгоритмы шифрования.
• Идентификация стороны с помощью HTTPS-сертификата, выдала CA. Используются асимметричные алгоритмы шифрования.
• Шифрования сообщения. Здесь используются симметричные алгоритмы шифрования.
• Подпись сообщения с помощью алгоритмов хеширования.

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

Например, передача ECDHE-RSA-AES256-GCM-SHA384 свидетельствует, что обмен ключом состоится по протоколу Диффи-Хеллмана на эллиптических кривых (Elliptic Curve Diffie-Hellman Ephemeral, ECDHE), сертификат был подписан CA с помощью алгоритма RSA, симметричное шифрование будет происходить по помощью алгоритма AES с длиной ключа в 256 бит с GCM, а целостность сообщения гарантируется алгоритмом SHA-2 с длиной дайджеста в 384 бита.

И поэтому вам нужно будет сделать несколько решений в конфигурации.

Коды

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

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

На Википедии есть сравнительный список алгоритмов и их поддержка различными версиями SSL и TLS.

Очень удобным ресурсом, который поможет настроить HTTPS на сервере есть Mozilla SSL Configuration Generator, позже в этой статье мы воспользуемся им.

Тип ключа

Сертификаты с использованием эллиптической криптографии быстрее и меньше нагружают CPU, чем RSA-сертификаты, играет важную роль на мобильных устройствах. Но некоторые сервисы (на момент написания, 12 июля 2017 года, среди них были Amazon, CloudFront и Heroku) не поддерживают такие сертификаты.

256-битный ECC ключ признано достаточным.

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

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

Процедура получения сертификата

Чтобы получить HTTPS-сертификат нужно выполнить следующее:

• Создайте пару из частного и публичного ключа и подготовьте запрос на подписание сертификата (Certificate Signing Request, CSR), включая информацию об организации и публичный ключ.
• Обратитесь к CA и сделайте запрос на получение HTTPS-сертификата, основанный на вашем CSR.
• Получите подписанный сертификат и установите на своем веб-сервере.

Существует определенный набор файлов, хранящих различные элементы инфраструктуры публичных ключей (public key infrastructure, PKI): частный и публичный ключи, CSR и подписан HTTPS-сертификат. И чтобы все это усложнить, различные стороны используют различные имена и расширения файлов для одних и тех же вещей.

Для начала, существует два формата хранения информации — DER и PEM. Первый является бинарным форматом, а другой это base64-encoded (текстовый) DER-файл. По умолчанию Windows использует DER-формат направления, в то время как мир open-source (Linux, UNIX) используют PEM. Конечно, существуют инструменты для конвертирования между этими двумя форматами.

Файлы, которые мы будем использовать в примерах:

example.com.key — это PEM-форматированный файл сохраняет частный ключ. Расширение .key не явля

Разработка веб-приложений и веб-сервисов на C++. Как это правильно делать

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

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

Компоненты системы взаимодействуют между собой по сети, используя различные протоколы. Также предоставляется способ внешнего взаимодействия с системой. Обычно, в качестве способа интеграции с “внешним миром” реализуется протокол на базе REST (Uber, Яндекс. Диск, DigitalOcean, AWS, список почти бесконечен). Реализовать такое взаимодействие можно чуть ли не в автоматическом режиме (Swagger). Код в этом случае будет сгенерирован для любого языка… но не для С++.

Как же быть, если нам нужно использовать C++, для реализации веб-сервиса, поддерживающего REST-API ? Почему нам может понадобиться именно С++ для этой задачи? Об этом и многом другом поговорим далее.

Веб-фреймворки и Веб-сервера

Итак, веб-сервисы и веб-приложения создаются, как правило, не на С++. Любой другой язык предоставляет массу качественных веб-фреймворков: у Python есть Django, Flask, Tornado; у PHP есть Symfony; у Javascript (Node.js) есть Express; у Java есть Spring Web MVC; у Erlang есть N2O и так далее. Это отличные решения, которые, в первую очередь, позволяют программисту не погружаться в протокол HTTP (RFC2616), а сразу сосредоточиться на бизнес-логике своего приложения. Многие веб-фреймворки имеют в своем составе реализацию ORM, что упрощает работу с базами данных. Кроме этого, веб-фреймворки предоставляют:

• диспетчеризацию URL;
• систему шаблонов, для удобного создания html-страниц;
• средства для интернационализация и локализации;
• авторизацию и аутентификацию;
• и многое другое.

Но одного веб-фреймворка не достаточно для создания веб-сервиса, понадобится еще, как минимум, веб-сервер. В мире не так много веб-серверов, заслуживающих внимание. Это Apache HTTP server, Nginx, lighttpd, Tornado, Node.js, Yaws, Netty. Веб-серверов существует меньше, чем веб-фреймворков, и новые появляются значительно реже (Caddy). Зачем же нужен веб-сервер, если есть веб-фреймворк?

Веб-сервер — это надежная, быстрая, потребляющая небольшое количество ресурсов программа. Веб-сервер способен поддерживать одновременное подключение тысяч клиентов, и не терять при этом работоспособность. Веб-сервер отлично справляется с такими задачами как: шифрование данных (SSL termination), сжатие данных, обслуживание статических запросов, кеширование, балансировка нагрузки и так далее. Веб-фреймворки не касаются решения этих задач. Эти задачи не являются их зоной ответственности. Фактически, установив и настроив веб-сервер на прием запросов из внешнего мира, мы снимаем огромный “пласт” работы с веб-фреймворка (который “как бы спрятан” за веб-сервером). Например, ему больше не обязательно “быть готовым” встретить тысячи пользователей. Вместо этого, мы можем развернуть 20 веб-фреймворков за одним веб-сервером, и тонко настроить балансировку нагрузки.

​

То, что веб-сервер необходимо выбирать именно из числа выше названных, подтверждается крупнейшими компаниями — Яндекс, Google, Facebook, Bloomberg, Amazone — какой бы веб-фреймворк не использовался этими компаниями, неизменным остается то, что никто не пишет свой веб-сервер. Обычно, берут либо Nginx, либо Apache. И это первое, что нам нужно уяснить — при разработки веб-приложения на С++, нам также потребуется веб-сервер из числа названных.

Зачем писать веб-приложение на С++

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

Есть одна, но очень веская причина разрабатывать back-end веб-сервиса на С++ — любой интерпретируемый язык (будь то Python с его несчастным GIL-ом, Ruby, PHP и другие) проиграет  С++ в быстродействии и потреблении ресурсов. Хорошо написанная, и оптимизированная компилятором, программа на С++ будет работать не хуже аналогичного варианта на С. Если, высокая эффективность для вас не главное требование, то возможно С++ не стоит брать для разработки веб-сервиса. Писать на С++ однозначно придется больше и дольше. Однако, есть вы хотите получить максимум КПД от своих вычислительных мощностей (которых всегда не хватает), то вам придется перейти на компилируемый язык. И С++ тут отличный и хорошо знакомый всем кандидат (языки Go и Rust еще не завоевали такой популярности, а Java и C# могут оказаться избыточными для микросервиса).  

Итак, веб-приложение или веб-сервис будем разрабатывать именно на С++.

Почему не нужно писать свой Веб-сервер на Asio

Я очень много разрабатываю с использованием Asio и добиваюсь очень эффективных результатов. Миллионы сообщений переданных по сети в течении всего одной секунды, сериализованных и  зашифрованных. Asio — это отличная библиотека! Но она не подходит для того, чтобы делать на ней веб-сервер… Почему? Ответ — это слишком низкоуровневый подход. Конечно, возможно у вас получится написать эффективный, быстрый и надежный код. Но сколько на это уйдет времени? И будет ли это решение в итоге быстрее, чем Nginx? И главное, как вы будете решать вопрос функциональных возможностей? Давайте просто сравним, что дает нам Asio, и что предлагает его “Java аналог” — Netty:

Asio C++ Library

Netty framework

Сразу скажу, что поддержка SSL и TLS в Asio хуже, чем у Netty. По сути, вам придется напрямую работать с OpenSSL, так как ASIO предоставляет весьма условные классы-обертки. Здесь можно было бы обойтись и вовсе без Asio, так как вся работы возлагается на OpenSSL. Но шифрование в данном случае не главное.

Обратите внимание на протоколы. Asio заканчивается на уровне TCP. Дальше вам всё нужно будет написать самим. Скорее всего потребуются дополнительные библиотеки, чтобы, например, обеспечить сжатие данных в протоколе HTTP, чтобы поддержать протокол Web-сокетов. В конце концов, чтобы просто получить веб-сервер, соответствующий протоколу HTTP/1.1. Ведь в С++ нет даже стандартной библиотеки для парсинга URL (кто считает это ерундой, тот не парсил арабские линки). Всё это вы либо возьмете из внешних библиотек, либо будете очень долго писать сами, либо (что хуже всего) откажетесь вовсе поддерживать (сказав — мне это не нужно).

Какой бы путь вы не выбрали с Asio, вы потеряете очень много времени, и не приблизитесь к решению именно вашей задачи. Вы просто будете писать свой веб-сервер, который в лучше случае сможет работать также надежно и быстро, как Nginx. И который в лучшем случае поддержит хотя бы 10% от того, что сразу идет в базовой конфигурации любого существующего веб-сервера. Вы удовлетворите только собственное желание “попробовать сделать самому”. Пишите на Asio то, что нельзя взять в готовом варианте. Веб-сервер же установите Nginx. На это у вас уйдет 1 минута, и 10 минут, чтобы сконфигурировать его работу.

Почему не нужно брать Веб-сервер на Qt, POCO, Wt C++ или cpp-netlib

К этому моменту мне, возможно, уже удалось отговорить вас писать веб-сервер самостоятельно. Но как насчет Qt? POCO? Wt? Или cpp-netlib? Последняя библиотека, кстати, использует Asio. Все перечисленные инструменты — это C++, а не Java/Python/C. Они имеют хорошие функциональные возможности, готовые реализации веб-серверов, и даже предлагают себя в качестве веб-фреймворков. Как, к примеру, Wt (у Wt на борту есть Bootstrap 2 и 3, что кажется уже перебором). Казалось бы на С++ есть всё готовое. Бери и используй. Но не спешите…

Вот один из многочисленных бенчмарков HTTP-серверов, опубликованный на Хабре. Смотрим результаты: POCO медленнее Nginx-а всего лишь в 5 раз, cpp-netlib медленнее в 20 раз! И вот вопрос: зачем тянуть в проект большие внешние библиотеки, которые изначально хуже, чем тот же Nginx? Nginx активно развивается на протяжении более десяти лет (как и Apache или lighttpd). Повторить эту работу не просто даже специализированным библиотекам. Отмечу, что все перечисленные C++ библиотеки, также уступают в функциональности тому же Apache. Для Apache сообщество на протяжении длительного времени написало такое количество подключаемых модулей, что их трудно все перечислить. 

В итоге, если вы пишете свой веб-сервис или веб-приложение на С++, вам лучше использовать в качестве веб-сервера Nginx, Apache или lighttpd. При чем не нужно компилировать и линковать код этих веб-серверов вместе со своим кодом. Эти сервера должны быть установлены “штатно”, как и любые другие программы, и работать самостоятельно. Нам же остается только найти решение, как “подружить” программу на С++ с внешним веб-сервером. И решение здесь очень простое.

SCGI и FastCGI — способ подружить Веб-сервер и программу на C++

Если эти технологии вам не знакомы, то прочитайте о них на Википедии. В двух словах — это клиент-серверные протоколы взаимодействия веб-сервера и приложения (в нашем случае С++ приложения). Эти два протокола являются дальнейшим развитием протокола CGI. Однако, CGI работает медленно, и лучше этот подход не рассматривать.

FastCGI-приложения используют Unix Domain Sockets или TCP/IP для связи с веб-сервером. Первый вариант менее гибкий, но более быстрый. Второй вариант, это обычное сетевое клиент-серверное взаимодействие. И здесь (внимание) есть смысл применить свои навыки в Asio, и написать эффективный транспорт для общения с веб-сервером! Потому что, только это от вас и требуется.  

Nginх “встретит” запрос пользователя, расшифрует его, определит куда следует направить дальше этот запрос, и передаст его вашему приложению на С++. Дождется ответа от вашего приложения, сожмет и зашифрует данные, а затем передаст их пользователю. Масштабировать такое решение очень легко — просто запустите столько копий FastCGI-приложения сколько потребуется (на разных машинах или на одной), настройте балансировку в Nginx и всё!

С вашего приложения снимается огромная работа, а в замен вам нужно поддержать на выбор FastCGI или SCGI. Тут есть два подхода — либо взять готовые решения, либо совместить, к примеру, свой транспорт на Asio и “чистый” парсер того же протокола SCGI. Кстати, SCGI реально реализовать одному программисту всего за несколько дней в полном объеме (с нуля).

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

В итоге, что мы имеем. При разработке веб-сервиса или веб-приложения на С++ нам нужен внешний хороший веб-сервер, а наша программа на С++ должна поддержать протокол взаимодействия с выбранным веб-сервером — FastCGI или SCGI. Двигаемся дальше: как помочь себе в создании веб-фреймворка на С++.

Как помочь себе в создании веб-фреймворка на С++

Я против написания веб-сервера, но, я “за” написание собственного веб-фреймворка. Вот только рутинную работу, нужно на кого-то переложить. А самим написать самое “вкусное” — тот же диспетчер URL, на шаблонах, с созданием своего DSL (как же без этого). А что значит — рутинная работа?

В начале я описывал, что делает веб-фреймворк, и что делает веб-сервер. Задачи этих двух компонентов не пересекаются (обычно). Веб-сервер мы взяли готовый (например, Nginx), а в своей программе поддержали SCGI, но работа на этом не закончилась. Нам нужно добавить себе в программу те возможности, которые обычно предоставляются веб-фреймворками. И здесь целесообразно использовать по максимум готовые решения.

Например, нам потребуется очень много парсить… В начале нужно парсить URL — задача абсолютно стандартная. Решений очень много — от могучих парсеров по типу Google’s URL parsing library​, до минималистичных библиотек в один исходный файл. Затем, потребуется парсить передаваемые сообщения — это могут быть и данные форм, и Json-данные, и xml-данные. Но тут уже всё зависит от вашего сервиса. Вы, например, вольны отказаться от использования в REST-протоколе формата XML. И тогда парсер xml вам будет не нужен.

Вторая задача, это “общение” с базой данных. Как и в случае с парсерами, вам нужно будет выбрать решение на С++, исходя из потребностей. Если это “традиционная” база данных, возможно вам подойдет SQLAPI++ Library. Если вы используете какую-либо NoSQL базу, то существуют соответствующие клиенты на С++ и для них (например, для MongoDB).

Несколько слов про ORM. Задумайтесь, так ли он нужен в вашем микросервисе? ORM полезен в том случае, когда ваше приложение достаточно большое и совершает много простых запросов к базе. В этом случае, ORM скрывает всю эту “кухню”. Но если ваш микросервис делает всего 10-20 различных запросов к базе, то не стоит создавать весь этот overhead под названием ORM. Это всегда влечет дополнительные накладные расходы. Кроме того, вы лишаете себя возможности оптимизировать каждый из запросов. Лучше напишите эти запросы один раз, и забудьте про ORM. ORM, особенно “самописный”, скорее мешает в дальнейшем сопровождении кода, чем помогает. SQL знаком очень многим, а ORM — это обычная “вкусовщина”.

Сейчас популярны так называемые “микрофреймворки”. В них отсутствует такие возможности как: 

• система рендеринга html-шаблонов
• ORM, и в принципе средства доступа к базам данных
• различные плагины авторизации, аутентификации, роли, работа с email

Всё это легко подключается, если есть такая необходимость. Этому принципу и надо следовать. То что действительно нужно, у вас уже есть — это полноценный безопасный быстрый веб-сервер со всеми его возможностями, библиотеки для разбора URL и JSON, какой-либо драйвер к базе данных. Возможно на этом и следует остановиться. Объединить все компоненты и вашу бизнес-логику в красивое быстрое решение на С++.

Итак. При разработке веб-сервиса или веб-приложения на С++ нам нужен хороший веб-сервер, набор небольших микро-библиотек для парсинга URL, и тех форматов данных, которые будут передаваться, и возможно драйвер для базы данных. Также нам нужно поддержать протокол  FastCGI или SCGI в своей программе на С++. Всё. 

Заключение

Решение, которое вы получите в итоге будет в первую очередь эффективным, надежным и гибким. Все компоненты, от веб-сервера до парсеров, вы сможете в любой момент заменить на более подходящие. Ваши бенчмарки будут показывать отличные результаты, лучше и выше, чем у POCO или cpp-netlib. При этом ваши возможности по масштабированию и расширению функционала не будут ничем ограничены. Нужно интегрировать систему рендеринга html — без проблем, внедрить LDAP аутентификацию — без проблем. Если ничего из этого не нужно — то ваш веб-сервис будет по-настоящему “микросервисом”, и никакого лишнего кода.

Предложенный в этой статье подход не является чем-то новым, скорее наоборот. Спецификация на FastCGI появилась кажется еще в 90-х. В это время появились и веб-сервера, которые поддерживали протокол FastCGI. В подтверждение своих слов привожу ссылку на интересную лекцию от Яндекса: Архитектура высоконагруженного сервиса на примере бэкенда Яндекс.Store. Обратите особое внимание на 8-ой слайд. На нем вы увидите всё о чем было написано в этой статье. 

Нюансы настройки публикации web-сервиса 1С 8.2 в Apache и IIS

Возникла необходимость взаимодействовать с 1C с мобильного клиента под Windows Phone 7/8. Самым простым способом взаимодействия показалось работа через web сервисы, поддерживаемые 1С.

С точки зрения публикации web сервиса особых сложностей нет. Шаги подробно описаны в статьях:

Проблемы возникли с доступом к опубликованному web-сервису 1С. Под IIS 7.5 из под Windows 2008R2 после полудня танцев с бубном проблему решить не удалось. Были изучены статьи и ветки форумов:

но счастье так и не наступило. 

В результате решил, что стоит попробовать поднять web сервис на Apache, поскольку с ним у меня обычно все было несколько проще с настройкой. Итак, на другом порту (8080) на том-же сервере был поднят Apache 2.2.22. В 1С был создан ещё один web сервис и опубликован уже на Apache. С настройками по умолчанию он также не заработал. Разберем ошибки.

Web сервис был опубликован в 1С под именем wsApache.

Публикация web-сервиса 1С под Apache

Соответственно, в указанном при публикации каталоге появился файл default.vrd следующего содержания:

В httpd.conf 1С добавила следующие строчки:

В целом, файлы/изменения создаваемые 1С почти рабочие.  Теперь о проблемах.

Правильный линк на сервис

В некоторых статьях путь к web сервису указан как: http://имя_сервера:порт/имя_при_публикации/alias?wsdl.

В моем случае:

• Имя сервера: s-1s-1-hw
• Порт: 8080
• Имя при публикации: wsApache
• Alias из файла default.vrd: service.1cws

Соответственно, НЕПРАВИЛЬНАЯ ссылка на web сервис 1С такая: http://s-1c-1-hw:8080/wsApache/service.1cws?wsdl

Если использовать такой линк, то 1C 8.2 выдаст сообщение вида:

Правильный вариант:

http://имя_сервера:порт/имя_при_публикации/ws/alias?wsdl.

Это обращение эквивалентно обращению по имени сервиса из default.vrd:

http://имя_сервера:порт/имя_при_публикации/ws/name?wsdl.

В моем случае:

• Name из файла default.vrd: Service

Соответственно, ПРАВИЛЬНЫЙ линк для доступа к web сервису 1С будет такой:

http://s-1c-1-hw:8080/wsApache/ws/service.1cws?wsdl

или такой

http://s-1c-1-hw:8080/wsApache/ws/service?wsdl

Если указать ссылку с суффиксом ?wsdl, то в веб браузере отобразиться XML файл с описанием опубликованного сервиса.

Если указать ссылку без суффикса ?wsdl, то при правильной настройке должна появится страница с гиперссылкой на опубликованный сервис:

http://s-1c-1-hw:8080/wsApache/ws/Service

Авторизация пользователя при обращении к web сервису 1С

Если попытаться получить доступ к web сервису опубликованному под Apache не исправляя файл default.vrd, то появиться стандартный диалог авторизации:

Диалог авторизации на web сервисе 1С

В тестовой базе был заведен тестовый пользователь IUSR с полными правами с пустым паролем. Если ввести в диалог в качестве логина этого пользователя, то авторизация пройдет успешно и отобразиться либо XML файл, либо ссылка на него (см. выше).

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

Это все. В моем случае каких-то дополнительных правок конфиг файлов не потребовалось.

В некоторых статьях указывалось, что нужно убрать из httpd.conf опцию «Options None«. У меня работает в обоих вариантах, т.е. когда строка присутствует и когда она удалена.

Публикация web сервиса 1С на IIS 7.5

Как уже упоминал выше, с публикацией web сервиса на IIS 7.5 с первого раза у меня не задалось, хотя тонкий клиент запускается без проблем. Поскольку пароль в конфигурационном файле по соображениям безопасности меня не устраивал, вернулся к вопросу настройки IIS.  Был опубликован web сервис с именем wsIIS и именем сервиса ServiceIIS и alias-ом serviceIIS.1cws. Галка в чекбоксе «Использовать аутентификацию операционной системы на веб-сервере» для простоты эксперимента была снята.

Публикация web сервиса 1С в IIS 7.5.

Корректная ссылка в моем случае: http://s-1c-1-hw/wsIIS/ws/ServiceIIS?wsdl. При попытке зайти из Chrome/IE получаем ошибку возвращенную IIS:

Ошибка HTTP 401.2 — Unauthorized

дабы избавиться от ошибки правим web.config сформированный 1С следующим образом:

Эта правка эквивалента изменению через консоль управления IIS для нашего опубликованного приложения с именем wsIIS  правил авторизации пользователя.

Настройки IIS 7.5 для доступа к web сервисам 1C

Добавление тегов security в web.config или правка правил авторизации в консоли IIS приводит к тому, что при обращении к сервису по указанной выше ссылке появляется запрос на авторизацию. Вводим нашего тестового пользователя IUSR без пароля и получаем нужный XML файл в ответе сервера.

Прописав в default.vrd логин и пароль пользователя, как было указано выше для Apache, уберем окно авторизации и сервис будет всегда авторизовываться под указанным пользователем. Как проходит авторизация можно посмотреть в логах 1C. Но вариант с прописыванием пользователя в конфигурационный файл — не наш путь, ибо не секьюрно.

Изменим настройки авторизации пользователя (в IIS проверка подлинности), чтобы использовалась Windows авторизация. Сменить можно в консоли управления IIS, либо в конфигурационном  файле. Мне больше нравиться конфигурационный файл. так как проще переносить настройки при миграции на другой сервер.

Поскольку изменения секции web.config <authentication> заблокированы на уровне IIS в файле

%windir%\system32\inetsrv\config\applicationHost.config

нужно зайти туда и сменить «Deny» на «Allow» для секции «authentication»:

после чего РАБОЧИЙ web.config для опубликованного web сервиса 1С будет выглядеть следующим образом:

Эквивалент последней выполненной операции (настройка <authentication>) — публикация сервиса с включенной галкой в чекбоксе «Использовать аутентификацию операционной системы на веб-сервере». 1С при публикации меняет эту настройку не в web.config, а в настройках IIS через API. В любом случае изменения должны быть видны в консоли управления IIS:

Настройка аутентификации при публикации web сервиса 1С в IIS

На всякий случай для проверки настроек при публикации web сервиса имеет смысл в консоли управления IIS зайти в следующие разделы:

Публикация web сервиса 1С в IIS. Настройка через консоль.

После указанной выше настройки web.config, удаляем жестко прописанные логин и пароль из  файла default.vrd. На всякий случай перегружаем IIS. Если для доменных пользователей прописаны корректные соответствия в учетных записях 1С, то авторизация пройдет прозрачно под доменными учетными записями, в чем можно будет убедиться посмотрев в логах авторизации 1С. 

Здесь приводится ряд ошибок IIS (и способы их устранения) которые с высокой вероятностью могут возникнуть при публикации web сервиса 1С на IIS.

Доступ из Visual Studio 2012

Как подробно описано в статье на хабре, чтобы добавить ссылку на опубликованный web сервис 1С в Visual Studio для разработки клиента необходимо создать приложение (например, консольное), кликнуть правой кнопкой мышки на solution и выбрать пункт «Add Service Reference…». Следует обратить внимание на точное указание ссылки непосредственно на WSDL описание, т.е. без указания суффикса ?wsdl Visual Studio ничего не обнаружит.

Добавление reference к web службе 1С из Visual Stiudio.

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

Удачи!!!

Похожее

Типы веб-серверов

Каждый веб-сайт находится на компьютере, известном как веб-сервер. Этот сервер всегда подключен к Интернету. Каждому веб-серверу, подключенному к Интернету, присваивается уникальный адрес, состоящий из четырех чисел от 0 до 255, разделенных точками. Например, 87.250.250.0 или 87.250.250.255.
Когда вы регистрируете веб-адрес, также известный как доменное имя, например maxfad.ru, вы должны указать IP-адрес веб-сервера, на котором будет размещаться сайт. Вы можете загружать выделенные серверы, которые могут поддерживать ваши веб-операции.

Есть четыре ведущих веб-сервера — Apache, IIS, lighttpd и Jagsaw . Теперь мы рассмотрим эти серверы более подробно.
Помимо этих веб-серверов, на рынке есть и другие веб-серверы, но они очень дороги. Основными из них являются iPlanet Netscape , веб-логика Bea и IBM WebSphere .

HTTP-сервер Apache

Это самый популярный веб-сервер в мире, разработанный Apache Software Foundation. Веб-сервер Apache является программным обеспечением с открытым исходным кодом и может быть установлен практически на всех операционных системах, включая Linux, Unix , Windows, FreeBSD, Mac OS X и другие. Около 60% компьютеров веб-сервера запускают веб-сервер Apache.
Вы можете иметь Apache с модулем tomcat для поддержки JSP и J2EE.
Вы можете получить подробную информацию об этом сервере на Apache HTTP Server

Интернет-услуги

Информационный сервер Интернета (IIS) — это высокопроизводительный веб-сервер от Microsoft. Этот веб-сервер работает на платформах Windows NT / 2000 и 2003 (и может также быть в новой версии Windows). IIS поставляется в комплекте с Windows NT / 2000 и 2003; Поскольку IIS тесно интегрирована с операционной системой, поэтому ее легко администрировать.
Вы можете получить подробную информацию об этом сервере в Miscrosoft IIS

Lighttpd

Lighttpd также бесплатный веб — сервер , который распространяется с операционной системой FreeBSD. Этот веб-сервер с открытым исходным кодом является быстрым, безопасным и потребляет намного меньше мощности ЦП. Lighttpd также может работать в операционных системах Windows, Mac OS X, Linux и Solaris.
Вы можете иметь подробную информацию об этом сервере на lighttpd

Веб-сервер Sun Java System

Этот веб-сервер от Sun Microsystems подходит для средних и крупных веб-сайтов. Хотя сервер бесплатный, он не является открытым исходным кодом. Однако он работает на платформах Windows, Linux и Unix . Веб-сервер Sun Java System поддерживает различные языки, скрипты и технологии, необходимые для Web 2.0, такие как JSP, Java Servlets, PHP, Perl, Python, Ruby on Rails, ASP и Coldfusion и т.д.
Вы можете получить подробную информацию об этом сервере на веб-сервере Sun Java System

Jigsaw Server

Jigsaw (сервер W3C) поставляется из консорциума World Wide Web. Он работает с открытым исходным кодом и свободен и может работать на различных платформах, таких как Linux, Unix , Windows, Mac OS X Free BSD и т. Д. Jigsaw написана на Java и может запускать CGI-скрипты и программы PHP.
Вы можете получить подробную информацию об этом сервере на Jigsaw Server

OpenServer

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

Понравилась статья? Поделитесь ею с друзьями и напишите отзыв в комментариях!

Простой веб-сервер TCP / IP

Эта программа реализует (очень) простой веб-сервер.

Проблемы программирования

Проблемы с сетью на самом деле довольно тривиальны. HTTP
по сути является текстовым протоколом, который работает через TCP / IP (хотя
он может работать по любому транспортному протоколу). Основные сетевые шаги
являются:

• Создать прослушивающий сокет
• Принять связь с ним
• Разветвляет дочерний процесс для обслуживания соединения, пока
  родительский процесс возвращается, чтобы принять больше подключений.
• Прочитать HTTP-запрос
• Отправить ответ HTTP
• Отправить запрошенный объект (например, документ HTML)

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

HTTP-запросов может быть простых или полных .Просто
запрос содержит только одну строку и выглядит так:

GET /index.html

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

 GET /index.html HTTP / 1.0
Хост: www.paulgriffiths.net
Пользовательский агент: Lynx / 2.8.1rel.2 libwww-FM / 2.14
Accept-Encoding: gzip, сжатие
Accept-Language: en
<ПУСТОЙ СТРОК> 

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

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

 HTTP / 1.0 200 ОК
Сервер: PGWebServ v0.1
Тип содержимого: текст / html
<ПУСТОЙ СТРОК> 

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

После ответа объект (например, HTML
документ, файл JPEG) передается. Как только это будет завершено,
соединение разорвано.С помощью простого HTTP-запроса только
объект отправлен; HTTP-ответ не создается.

Использование

Эта программа была написана и протестирована на Redhat Linux 6.0.
Его следует без изменений переносить на другие системы UNIX (с
возможное исключение из make-файла), но обычно не
работать на других платформах.

Для простоты список функций этого сервера
довольно ограничен. Например:

• Нет файлов конфигурации; все варианты
  жестко запрограммированный
• Сервер может возвращать только HTML-документы (фактически
  сервер вернет любой файл, но ответ HTTP
  будет указывать длину содержимого как «text / html»
• Нет поддержки CGI или SSI
• Файлы журнала не создаются.
• Важно, за исключением основной ошибки C
  проверка, мер безопасности нет
  включено вообще! Эта программа написана
  для основных учебных и демонстрационных целей. Делать
  , а не запустить его на любой подключенной машине
  во внешнюю сеть.

Источник и загрузка

Простой веб-сервер C ++ загрузить

• Присоединиться / Войти
• Программное обеспечение с открытым исходным кодом
• Программное обеспечение для бизнеса
• Блог
• Около
• Справка
• Подключить

• Конфиденциальность
• Подробнее
• • Статьи
  • Создать
  • Самые популярные проекты
  • Сделок
  • Статус объекта
  • @sfnet_ops
  • @sourceforge
  • Документация участка
  • Запрос на поддержку
  • Условия
  • Отказаться
  • Объявить

о нет! Не удалось загрузить некоторые стили.😵

Пожалуйста, попробуйте перезагрузить эту страницу

Помогите

Создайте

Присоединиться
Авторизоваться

Программное обеспечение с открытым исходным кодом

• Бухгалтерский учет
• CRM
• Бизнес-аналитика

канадских долларов

• PLM
• ударов в минуту
• Управление проектами
• Управление знаниями
• Развитие
• Продажа
• Электронная торговля
• ERP
• HR
• Управление ИТ
• ИТ-безопасность
• Офис
• Наука и техника
• Игры
• Все программное обеспечение

Программное обеспечение для бизнеса

• CRM

  CRM

  Обслуживание клиентов

  Опыт работы с клиентами

  Торговая точка

  Ведущее управление

  Управление событиями

  Опрос

• Финансы

  Финансы

  Бухгалтерский учет

  Выставление счетов и выставление счетов

  Бюджетирование

  Процесс оплаты

  Отчет о затратах

• Разработка приложения

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

  Управление жизненным циклом приложений

  Интеграция

  Разработка с низким кодом

  Разработка без кода

PHP: $ _SERVER — Руководство

Путеводитель по абсолютным путям…

Данные: __FILE__
Тип данных: String
Назначение: Абсолютный путь к запущенному файлу PHP, включая имя файла.
Предостережение: это не файл, вызываемый процессором PHP, это то, что работает. Так что, если вы находитесь внутри include, это include.
Предупреждение: символические ссылки предварительно разрешены, поэтому не доверяйте точному сравнению путей.
Предостережение: не предполагайте, что все операционные системы используют символ «/» в качестве разделителя каталогов.
Работает в веб-режиме: Да
Работает в режиме CLI: Да

Данные: __DIR__
Тип данных: Строка
Цель: Абсолютный путь к запущенному файлу PHP, исключая имя файла.
Предостережение: это не тот файл, который вызывается Процессор PHP, это то, что работает.Так что, если вы находитесь внутри include, это include.
Предупреждение: символические ссылки предварительно разрешены, поэтому не доверяйте точному сравнению путей.
Предостережение: не предполагайте, что все операционные системы используют символ «/» в качестве разделителя каталогов.
Работает в веб-режиме: Да
Работает в режиме CLI: Да

Данные: $ _SERVER [‘SCRIPT_FILENAME’]
Тип данных: Строка
Цель: Абсолютный путь к исходному файлу PHP, включая имя файла
Предостережение: не задано во всех средах PHP может потребоваться настройка путем копирования из __FILE__ перед включением других файлов.
Предостережение: символические ссылки не разрешаются заранее, используйте функцию PHP realpath, если вам нужно ее разрешить.
Предостережение: не предполагайте, что все операционные системы используют символ «/» в качестве разделителя каталогов.
Предупреждение: «Имя файла» заставляет вас думать, что это просто имя файла, но на самом деле это полный абсолютный путь. Считайте идентификатор как «Имя файловой системы (путь) скрипта».
Работает в веб-режиме: Да
Работает в режиме CLI: Да

Данные: $ _SERVER [‘PATH_TRANSLATED’]
Тип данных: Строка
Цель: Абсолютный путь к исходному файлу PHP, включая имя файла.
Предупреждение: вероятно не установлен, лучше просто не использовать.Просто используйте realpath ($ _ SERVER [‘SCRIPT_FILENAME’]) (и имейте в виду, что его, возможно, потребуется эмулировать).
Предупреждение: символические ссылки предварительно разрешены, поэтому не доверяйте точному сравнению путей.
Предостережение: не предполагайте, что все операционные системы используют символ «/» в качестве разделителя каталогов.
Работает в веб-режиме: Да
Работает в режиме CLI: Нет

Данные: $ _SERVER [‘DOCUMENT_ROOT’]
Тип данных: Строка
Цель: Получить абсолютный путь к корню документа веб-сервера. Без слеша в конце.
Предостережение: не доверяйте этой настройке или правильной настройке, если вы не контролируете серверную среду.
Предостережение: символические ссылки могут быть предварительно разрешены или не иметь, используйте функцию PHP ‘realpath’, если вам нужно ее разрешить.
Предостережение: не предполагайте, что все операционные системы используют символ «/» в качестве разделителя каталогов.