1. Строка состояния.
2. Поля заголовка.
3. Пустая строка.
4. Тело ответа.
Ответ сервера клиенту начинается со строки состояния, которая имеет следующий формат:
Версия_протокола Код_ответа Пояснительное_сообщение
- Версия_протокола задается в том же формате, что и в запросе клиента, и имеет тот же смысл.
- Код_ответа - это трехзначное десятичное число, представляющее в закодированном виде результат обслуживания запроса сервером.
- Пояснительное_сообщение дублирует код ответа в символьном виде. Это строка символов, которая не обрабатывается клиентом. Она предназначена для системного администратора или оператора, занимающегося обслуживанием системы, и является расшифровкой кода ответа.
Из трех цифр, составляющих код ответа, первая (старшая) определяет класс ответа, остальные две представляют собой номер ответа внутри класса. Так, например, если запрос был обработан успешно, клиент получает следующее сообщение:
HТТР/1.0 200 ОК
Как видно, за версией протокола HTTP 1.0 следует код 200. В этом коде символ 2 означает успешную обработку запроса клиента, а остальные две цифры (00) — номер данного сообщения.
В используемых в настоящее время реализациях протокола HTTP первая цифра не может быть больше 5 и определяет следующие классы ответов.
- 1 - специальный класс сообщений, называемых информационными. Код ответа, начинающийся с 1, означает, что сервер продолжает обработку запроса. При обмене данными между HTTP-клиентом и HTTP-сервером сообщения этого класса используются достаточно редко.
- 2 - успешная обработка запроса клиента.
- 3 - перенаправление запроса. Чтобы запрос был обслужен, необходимо предпринять дополнительные действия.
- 4 - ошибка клиента. Как правило, код ответа, начинающийся с цифры 4, возвращается в том случае, если в запросе клиента встретилась синтаксическая ошибка.
- 5 - ошибка сервера. По тем или иным причинам сервер не в состоянии выполнить запрос.
Примеры кодов ответов, которые клиент может получить от сервера, и поясняющие сообщения показаны на рис.6.4.
Рис.6.4. Классы кодов ответа сервера.
В ответе используется такая же структура полей заголовка, как и в запросе клиента. Поля заголовка предназначены для того, чтобы уточнить ответ сервера клиенту. Описание некоторых из полей показано на рис.
Рис.6.5. Поля заголовка ответа веб-сервера.
В теле ответа содержится код ресурса, передаваемого клиенту в ответ на запрос. Это не обязательно должен быть HTML-текст веб-страницы. В составе ответа могут передаваться изображение, аудио-файл, фрагмент видеоинформации, а также любой другой тип данных, поддерживаемых клиентом. О том, как следует обрабатывать полученный ресурс, клиенту сообщает содержимое поля заголовка Content-type.
Поля заголовка и тело сообщения могут отсутствовать, но строка состояния является обязательным элементом, так как указывает на тип запроса/ответа.
Поле с именем Content-type может встречаться как в запросе клиента, так и в ответе сервера. В качестве значения этого поля указывается MIME-тип содержимого запроса или ответа. MIME-тип также передается в поле заголовка Accept, присутствующего в запросе.
1.6.10 Cookie
В общем случае для каждого запрашиваемого ресурса открывается новое соединение. При этом ни HTTP-клиент, ни HTTP-сервер не хранят информацию даже о последнем соединении. Поэтому если HTTP-клиент после запроса какого-либо ресурса повторно запрашивает с того же сервера другой ресурс, то сервер не может определить тот же это клиент либо другой. В то же время для решения многих задач необходимо идентифицировать клиента на время сеанса работы пользователя, или даже между сеансами пользователя. Например, это может понадобиться для организации различных систем голосования и опроса пользователей, виртуальных магазинов, для аутентификации пользователей и сохранения различных настроек для каждого пользователя. Использование постоянного HTTP соединения в этом случае не решает проблему, поскольку такое соединение предназначено для последовательного запроса нескольких документов. Постоянное соединение не может оставаться активным на время всего сеанса работы пользователя, так как оно будет разорвано сервером по истечению сравнительно небольшого таймаута, если от клиента не поступает никаких данных.
Для решения этой проблемы протокола HTTP разработан специальный механизм cookies. В этом случае информацию о соединении должен хранить HTTP-клиент, например браузер. Для реализации этого механизма используются два дополнительных поля HTTP-заголовка Set-Cookie и Cookie. Схема взаимодействия клиента и сервера при использовании механизма cookies, выглядит следующим образом:
• клиент запрашивает какой-либо документ с сервера, например, обращается к CGI-модулю;
• сервер включает в заголовок ответа поле Set-Cookie, в котором сообщает клиенту информацию, предназначенную для сохранения, и параметры, задающие область действия этой информации;
• при каждом следующем запросе клиент возвращает серверу сохраненную информацию с помощью поля Cookie в заголовке запроса, если запрашиваемый ресурс попадает в область действия, заданной сервером;
• CGI-модуль или другой ресурс на сервере может проанализировать
значение поля Cookie и идентифицировать клиента.
Первоначально механизм cookies был описан в спецификации "Netscape Communications Persistent Client State HTTP Cookies", в дальнейшем был принят RFC-2109 "HTTP State Management Mechanism", описывающий этот механизм. Общий принцип работы и формат полей заголовка у этих спецификаций совпадают, однако они имеет небольшие различия в параметрах заголовков.
В спецификации RFC-2109 поле Set-Cookie выглядит следующим образом:
Set-Cookie: NAME=VALUE; Comment=comment; Domain=domain; Max-
Age=delta-seconds; Path=path; Secure; Version=1
Обязательными параметрами являются NAME и Version. RFC-2109 описывает версию 1, если параметр Version опущен, то используется спецификация netscape. Вместо параметра Max-Age используется параметр Expires и отсутствует параметр Comment. Остальные параметры идентичны. Параметр NAME задает данные, которые должны быть сохранены клиентом. Параметр Domain задает имя домена, для которого действительно значение переданного cookie. Используется доменное имя сервера, который сформировал ответ. Параметр Path задает каталог на сервере, для документов которого действительно значение переданного cookie. Если указан "Path=/", то cookie действительны для всего сервера. Если параметр опущен, то используется каталог, из которого был запрошен документ. Если присутствует поле Secure, то cookie передаются только по защищенному HTTPS соединению. Параметры Max-Age и Expires задают срок действия cookie. Max-Age содержит количество секунд, по истечению которых переданный cookie считается недействительным и должен быть удален браузером. А поле Expires содержит дату, после наступления которой переданный cookie считается недействительным. Если поля опущены, то cookie действительны только на время одного сеанса пользователя, и браузер не должен сохранять значение cookie на диске.
В спецификации RFC-2109 поле Cookie выглядит следующим образом:
Cookie: $Version=1; NAME1=VALUE1; $Path=path1; $Domain=domain1;
NAME2=VALUE2; $Path=path2; $Domain=domain2
Для каждого значения cookie, параметры которого удовлетворяют запрашиваемому ресурсу, браузер включает параметр NAME=VALUE. Параметры $Path и $Domain, являются необязательными в RFC-2109 и отсутствуют в спецификации netscape.
Рассмотрим пример взаимодействия клиента и сервера при использовании механизма cookie.
1. HTTP-клиент ⇒ HTTP-сервер
POST /forum/cgi-bin/login.cgi HTTP/1.1
Host: www.volpi.ru
… … …
user=serg&pass=secret
2. HTTP- сервер ⇒ HTTP- клиент
HTTP/1.1 200 OK
Set-Cookie: user=serg; Version=1; Path=/forum
… … …
3. HTTP-клиент ⇒ HTTP-сервер
POST /forum/cgi-bin/sendmes.cgi HTTP/1.1
Host: www.volpi.ru
Cookie: $Version=1; user=serg; $Path=/forum
…... …
Таким образом, cookie представляет собой всего лишь блок данных, хранящийся на стороне клиента. Формирование и анализ этих данных должны выполняться на стороне сервера, например с помощью CGI-модулей. При сохранении cookie браузер должен придерживаться следующих ограничений:
• всего может храниться до 300 значений cookies
• каждый cookie не может превышать 4Кбайт
• с одного сервера или домена может храниться до 20 значений cookie
Следует отметить, что механизм cookies нельзя назвать надежным механизмом идентификации пользователей. Поскольку браузер может удалить сохраненные cookies, например при нехватке свободного места, либо вообще не поддерживать механизма cookies. Кроме того, пользователь может запретить в браузере поддержку cookies, или удалить сохраненные на диске cookies вручную.
1.7. Программирование в Интернет
1.7.1 Программирование в Интернет
Веб-программирование - раздел программирования, ориентированный на разработку динамических Internet-приложений. Языки веб-программирования - это соответственно языки, которые в основном предназначены для работы с интернет-технологиями. Языки веб-программирования делятся на две группы: клиентские и серверные.
Клиентские языки
Клиентские языки обрабатываются на стороне пользователя, а если проще — программы на клиентском языке обрабатывает браузер. Отсюда следует и недостаток — обработка скрипта зависит от браузера пользователя, и пользователь имеет полномочия настроить свой браузер так, чтобы он вообще игнорировал скрипты. При этом, если браузер старый, он может не поддерживать тот или иной язык или версию языка, на которую опирался разработчик. С современными браузерами таких проблем возникать не должно, к тому же языки программирования не так уж часто кардинально обновляются (раз в несколько лет) и лучшие из них давно известны. Также код клиентского скрипта может посмотреть каждый, выбрав в меню «Вид» своего браузера вкладку «Исходный код».
Преимущество же клиентского языка заключается в том, что обработка скриптов на таком языке может выполняться без отправки документа на сервер. Программа сразу проверит правильное заполнение формы перед отправкой, и, если необходимо, выведет ошибку.
Самым распространенным из клиентских языков является JavaScript, разработчиками которого является компания Netscape совместно с компанией Sun Microsystems. Ещё один популярный язык — это VBScript от Microsoft.
Серверные языки
Когда пользователь дает запрос на какую-либо страницу, то вызванная страница сначала обрабатывается на сервере, то есть выполняются все программы, связанные со страницей, и только потом возвращается к посетителю по сети в виде файла. Этот файл может иметь расширения: HTML, PHP, ASP, Perl, SSI, XML, DHTML, XHTML.
Работа программ уже полностью зависима от сервера, на котором расположен сайт, и от того, какая версия того или иного языка поддерживается.
Важной стороной работы серверных языков является возможность организации непосредственного взаимодействия с системой управления базами данных (или СУБД) — сервером, на котором упорядоченно хранится информация, которая может быть вызвана в любой момент. Популярными среди систем управления базами данных являются:
- Firebird
- IBM DB2
- IBM DB2 Express-C
- Microsoft SQL Server
- Microsoft SQL Server Express
- mSQL
- MySQL
- Oracle
- PostgreSQL
- SQLite
- Sybase Adaptive Server Enterprise
1.7.2 Серверное и клиентское ПО
Сервер - программный компонент вычислительной системы, выполняющий сервисные (обслуживающие) функции по запросу клиента, предоставляя ему доступ к определённым ресурсам или услугам.
У слова «сервер», также есть первое значение — компьютер выполняющий только серверные задачи, или компьютер, специализированный для использования в качестве аппаратной базы для серверов услуг (иногда — услуг определенного направления).
Аппаратными серверами (аппаратное обеспечение) называются узкоспециализированные решения со встроенным программным обеспечением, определяющим специализацию и возможные предоставляемые услуги. Аппаратные серверы, как правило, более просты и надежны в эксплуатации, потребляют меньше электроэнергии и, иногда, более дешевы. Но вместе с тем они менее гибки и, часто, ограничены в ресурсах.
Важно понимать что сервер, (то есть сервер, предоставляющий какой-либо сервис), всегда является программой, выполняющейся на каком-то аппаратном обеспечении. Без этой программы аппаратное обеспечение не может ничего предоставлять. Даже в «аппаратных серверах» сервис, также, предоставляется программным обеспечением. Иногда сервером услуги называют программное и аппаратное обеспечение в целом, в особенности если этот программно-аппаратный комплекс выполняет только одну задачу.
Теоретически, на одной единице аппаратного обеспечения, может одновременно выполняться произвольное количество серверов (за исключением серверов конфликтующих между собой по ресурсам или их количеству), они будут делить между собой аппаратные ресурсы. Практически, между крайностями «один компьютер — одна услуга» и «один компьютер — все услуги» каждый находит свой компромисс.
Серверы услуг можно запускать на рабочей станции, чтобы они работали в фоне разделяя ресурсы компьютера с программами, запускаемыми пользователем. Такой режим работы называется «невыделенным», в отличие от «выделенного», когда компьютер выполняет только сервисные функции. Строго говоря, на рабочей станции и без того, всегда работает несколько серверов — сервер удаленного доступа, сервер удаленного доступа к файловой системе и системе печати, и прочие удаленные и внутренние серверы.
Клиент - аппаратный или программный компонент вычислительной системы, посылающий запросы серверу.
Программа, являющаяся клиентом, взаимодействует с сервером, используя определённый протокол. Она может запрашивать с сервера какие-либо данные, манипулировать данными непосредственно на сервере, запускать на сервере новые процессы и т. п. Полученные от сервера данные клиентская программа может предоставлять пользователю или использовать как-либо иначе, в зависимости от назначения программы. Программа-клиент и программа-сервер могут работать как на одном и том же компьютере, так и на разных. Во втором случае для обмена информацией используется сетевое соединение.
Разновидностью клиентов являются терминалы - рабочие места на многопользовательских ЭВМ, оснащённые монитором с клавиатурой, и не способные работать без сервера. В 1990-е годы появились сетевые компьютеры — нечто среднее между терминалом и персональным компьютером. Сетевые компьютеры имеют упрощённую структуру и во многом зависят от сервера.
Тем не менее, не всегда под клиентом подразумевается компьютер со слабыми вычислительными ресурсами. Чаще всего понятия «клиент» и «сервер» описывают распределение ролей при выполнении конкретной задачи, а не вычислительные мощности. На одном и том же компьютере могут одновременно работать программы, выполняющие как клиентские, так и серверные функции. Например, веб-сервер может в качестве клиента получать данные для формирования страниц от SQL-сервера.
1.7.3 Программы, выполняющиеся на клиенте (JavaScript, Java-аплеты)
Одним из типов программ, предназначенных для выполнения на клиент-машине, являются сценарии, например, JavaScript (VBScript). Исходный текст сценария представляет собой часть веб-страницы, поэтому сценарий JavaScript передается клиенту вместе с документом, в состав которого он входит. Обрабатывая HTML-документ, браузер обнаруживает исходный текст сценария и запускает его на выполнение.
Ко всем программам, которые передаются с сервера на клиент-машины и запускаются на выполнение, предъявляется одно общее требование: эти программы должны быть лишены возможности обращаться к ресурсам компьютера, на котором они выполняются. Такое требование вполне обосновано. Ведь передача по сети и запуск Java-апплетов и JavaScript-сценариев происходит автоматически без участия пользователя, поэтому работа этих программ должна быть абсолютно безопасной для компьютера. Другими словами, языки, предназначенные для создания программ, выполняющихся на клиент-машине, должны быть абсолютно непригодны для написания вирусов и подобных программ.
Краткая характеристика VBScript
Visual Basic Scripting Edition (обычно просто VBScript) — сценарный язык программирования, интерпретируемый компонентом Windows Script Host. Он широко используется при создании скриптов в операционных системах семейства Microsoft.
Язык был создан компанией Microsoft как замена устаревшему пакетному языку, интерпретируемому приложением command.com. Синтаксис VBScript является упрощенной версией синтаксиса языка Visual Basic.
Сценарии на языке VBScript чаще всего используются в следующих областях, использующих программные продукты Microsoft:
- автоматизация администрирования систем Windows;
- серверный программный код в страницах ASP;
- клиентские сценарии в браузере Internet Explorer.
Java-апплеты
Java-апплет - это программа, написанная на языке Java и откомпилированная в байт-код. Выполнется в браузере с использованием виртуальной Java-машины (JVM). Апплеты используются для предоставления интерактивных возможностей веб-приложений, которые не возможны в HTML. Так как байт-код Java платформо-независим, то Java-апплеты могут выполняться браузерами на многих операционных платформах.
Java-сервлеты являются серверными приложениями, но они отличаются от апплетов языком, функциями и другими характеристиками.
Предназначены Java-апплеты для выполнения в безопасной среде с целью предотвращения их доступа к локальным ресурсам клиентского компьютера.
Код апплета загружается с веб-сервера, и браузер либо вставляет апплет в веб-страницу;
либо открывает отдельное окно с собственным пользовательским интерфейсом апплета.
Апплет может быть внедрен в веб-страницу с помощью использования HTML тэга <applet>, или (что рекомендуется) тэга <object>.
Можно назвать следующие преимущества Java-апплетов:
- работают практически на большинстве операционных платформ;
- поддерживаются большинством браузеров;
- кэшируются в большинстве браузеров, что существенно ускоряет их загрузку при возвращении на веб-страницу;
- после первого запуска апплета, когда Java-машина уже выполняется и быстро запускается, выполнение апплетов происходит существенно быстрее;
- загружаются со скоростью сопоставимой с програмами на других компилируемых языках, например C++, но во много раз быстрее чем на JavaScript.
При этом у Java-апплетов имеются и недостатки:
- требуется установка Java-расширения, которые доступны по умолчанию не во всех браузерах;
- проблемы реализации Java-расширений для 64-разрядных процессоров;
- не могут запускаться до первой загрузки виртуальной Java-машина, что может занимать значительное время;
- разработка пользовательского интерфейса с использованием апплетов является более сложной задачей по сравнению с HTML;
- не имеют прямого доступа к локальным ресурсам клиентского компьютера;
- некоторые апплеты привязаны к использованию определенной среды времени выполнения Java (JRE).
1.7.4 Программы, выполняющиеся на сервере
Код программы, работающей на сервере, не передается клиенту. При получении от клиента специального запроса, предполагающего выполнение такой программы, сервер запускает ее и передает параметры, входящие в состав запроса. Средства для генерации подобного запроса обычно входят в состав HTML-документа.
Результаты своей работы программа оформляет в виде HTML-документа и передает их веб-серверу, а последний, в свою очередь, дополняет полученные данные HTTP-заголовком и передает их клиенту. Взаимодействие клиента и сервера в этом случае показано на рисунке 5.1.
Рис. 5.1. Взаимодействие клиента с программой, выполняющейся на сервере
1.7.5 Спецификация CGI
Спецификация CGI, разработанная в NCSA, впервые была включена в свободнораспространяемые серверы NCSA. В то время это был колоссальный шаг вперед по сравнению с механизмами подключения внешних программ к серверу CERN. Разработчики сайтов получили простую возможность включить в свои страницы практически все локальные информационные ресурсы организации и таким образом обеспечить удаленный доступ к ним по сети.
Интересно, что параллельно с появлением спецификации CGI в стандарт HTML были введены формы. Собственно, формы и CGI - две стороны одной медали. И формы, и CGI были первоначально предназначены для обмена данными между прикладной программой и программой просмотра гипертекстовых страниц. При этом CGI предполагалось использовать не только в Web, но и для расширения возможностей других информационных технологий Internet.
Вот как в данном случае выглядит взаимодействие с сервером. Программа-браузер отправляет запрос серверу. В качестве URL в запросе используется адрес CGI-скрипта. При этом данные могут содержаться как в самой спецификации URL, так и в теле HTTP-сообщения. Сервер определяет тип URL, то есть то, что это именно скрипт, а не HTML-страница, либо по маршрутному имени ресурса (обычно - каталог cgi-bin), либо по расширению имени файла (обычно *.cgi). После этого сервер порождает процесс-потомок, передает в него значения переменных окружения, которые порождаются в соответствии со спецификацией CGI, загружает CGI-скрипт и передает ему управление. CGI-скрипт анализирует окружение; если необходимо, считывает данные из потока стандартного ввода, который организован сервером; производит обработку информации, определенную алгоритмом, реализованным в скрипте; и возвращает результат вычислений через свой стандартный вывод в форме, определенной в спецификации CGI. После этого процесс, завершается. Взаимодействие браузера, сервера и скрипта в этом случае носит разовый характер и по своей природе не ориентировано на длительный диалог.
Перечислим основные преимущества такого решения: простота, независимость, выполнение в отдельном адресном пространстве, открытый стандарт.
Простота заключается в том, что прикладному программисту, знакомому с основами программирования для ОС Unix, не требуется изучать каких-либо еще спецификаций. Все взаимодействие прикладной программы с сервером основывается на знании окружения, в котором функционирует программа, и правил ввода/вывода данных через стандартные ввод/вывод. Фактически надо просто, используя функцию getenv(), получить значение переменной окружения и вывести всю информацию через стандартные функции форматной печати - printf(). Если программа работает в режиме обмена данными через командную строку и стандартный вывод, то для ее подключения к серверу необходимо затратить минимум усилий. Сложнее подключать программы с развитым графическим пользовательским интерфейсом, но обычно в "грамотно" написанных программах интерфейсный модуль выделен и допускает простую замену.
Независимость подразумевает возможность написания программы на любом из универсальных языков программирования или скриптов на языках программирования сценариев, например командных языках. В этом случае абсолютно не имеет значения язык, на котором написан сервер. Взаимодействие, организованное через переменные окружения, командную строку и стандартные ввод/вывод, осуществляется всегда одинаково в конкретной операционной среде.
С точки зрения влияния прикладной программы на операционную среду или на сервер спецификация CGI также выглядит безупречно. Скрипт запускается в своем адресном пространстве и никак не влияет на другие компоненты, которые система исполняет одновременно со скриптом.
Спецификация CGI является открытым стандартом. Это означает, что скрипт, написанный для одного сервера, будет прекрасно работать и с другими серверами, поддерживающими спецификацию. В этом легко может убедиться любой, кто пожелает мигрировать, скажем, с сервера NCSA или CERN на Apache или обратно. Единственное исключение составляют продукты Microsoft. Но даже в этом случае, как правило, переносимость скриптов от одного сервера к другому сохраняется.
Спецификация CGI не зависит от платформы. Действительно, в любой операционной среде есть переменные окружения и понятия стандартных потоков ввода, вывода и ошибок. В частности, это позволяет выполнять скрипты, разработанные для ОС Unix, в среде MS-DOS. Типичным примером является скрипт Imagemap. Любопытно, что при переносе его на MS-DOS сохранилась даже ошибка с обработкой конца файла при просмотре описаний разбиения графического образа на фрагменты.
Естественно, что при всех своих несомненных достоинствах CGI имеет и недостатки. Главным из них является низкая скорость реакции на запрос пользователя. В то время, когда NCSA ввел в обращение CGI, количество обращений к сайту было невелико. О масштабах AltaVista или Lycos не могло быть и речи. В этих условиях можно было пренебречь скоростью в угоду простоте и надежности. Главной причиной медленного отклика является порождение полноценного процесса при обращении к скрипту. Это тем более выглядит нелепо, если даже Apache для повышения своей "реактивности" при старте запускает сразу несколько серверов-потомков, ускоряющих обработку запросов пользователей. Если при этом через данных потомков обращаются к CGI-скриптам, то весь выигрыш оказывается потерян.
Другим недостатком скриптов является тот факт, что использовать их можно только для ответа клиенту. Провести их обработку стандартными средствами сервера перед отправкой клиенту уже нельзя. Для этого приходится пользоваться отложенным обращением к результатам работы скрипта, которые предварительно помещаются в файл.
1.7.6 Perl
Perl - высокоуровневый интерпретируемый динамический язык программирования общего назначения, созданный Ларри Уоллом, лингвистом по образованию. Название языка представляет собой аббревиатуру, которая расшифровывается как Practical Extraction and Report Language «практический язык для извлечения данных и составления отчётов». Первоначально аббревиатура состояла из пяти символов и в таком виде в точности совпадала с английским словом pearl, жемчужина. Но затем стало известно, что такой язык существует (см. en:PEARL) и букву «а» убрали.
Согласно Ларри Уоллу, Perl имеет два девиза. Первый — «There’s more than one way to do it» («Есть больше одного способа сделать это», также известный как TMTOWTDI); второй — «Easy things should be easy and hard things should be possible» («Простые вещи должны быть простыми, а сложные вещи — возможными»).
Основной особенностью языка считаются его богатые возможности для работы с текстом, в том числе реализованные при помощи регулярных выражений. Перл унаследовал много свойств от языков Си, shell script, awk.
Perl также знаменит огромной коллекцией дополнительных модулей CPAN.
Синтаксис Perl имеет много общего с синтаксисом языков Си, Awk, sed и shell.
Первая строка исходного кода может начинаться с «#!/Путь/к/Perl [-ключи]» -что указывает системе путь к интерпретатору Perl для выполнения программы в UNIX системах и выполнения их на веб-сервере. Изначально обработка такой строки — это функция shell, но Perl при выполнении программы также проверяет эту строку и читает из неё ключи, игнорируя путь к интерпретатору.
Основные типы данных: скаляр, массив, хеш-таблица, функция, запись таблицы символов. Переменные разных типов отличаются знаком, который стоит перед именем переменной.
Скалярные переменные используются для хранения одиночных значений. Они могут содержать числа, строки и ссылки на другие объекты. Перед именем скалярной переменной необходимо ставить знак доллара '$'. Тип скалярной переменной не фиксирован и определяется динамически в зависимости от контекста.