Компьютерные сети

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

Протоколы: HTTP, SMTP, POP3, IMAP, FTP.

Обеспечивает взаимодействие сети и пользователя. Уровень разрешает приложениям пользователя иметь доступ к сетевым службам, таким как обработчик запросов к базам данных, доступ к файлам, пересылке электронной почты. Также отвечает за передачу служебной информации, предоставляет приложениям информацию об ошибках и формирует запросы к уровню представления. Пример: HTTP, POP3, SMTP.

Содержит набор популярных протоколов, необходимых пользователям. Одним из наиболее распространенных является протокол передачи гипертекста HTTP (HyperText Transfer Protocol), который составляет основу технологии Всемирной Паутины. Когда браузер запрашивает веб-страницу, он передает ее имя (адрес) и рассчитывает на то, что сервер будет использовать HTTP. Сервер в ответ отсылает страницу. Другие прикладные протоколы используются для передачи файлов, электронной почты, сетевых рассылок.

На этом уровне передаваемые данные называются сообщениями.

Общие замечания относительно OSI ISO

· Избыточность и низкая функциональность верхних уровней.

· Учет в стандартах всех теоретически возможных ситуаций.

· Сложность спецификаций для реализации.

· Очень высокие требования к ресурсам сетевых компьютеров.

Сегодня это референтная (ссылочная) модель.

Хотя поддержка этого стека на правительственном уровне (США, Германия, Россия,…) продолжается, это маргинальное течение в современных сетевых технологиях.

Эталонные модели OSI и TCP

Согласно терминологии TCP/IP элементы сетевого уровня называются подсетями (subnetworks). Идеология TCP/IP допускает, чтобы в качестве «подсетей» выступали реальные сети с их собственными стеками протоколов, узлами, шлюзами и т. п.

Реализация протоколов TCP/IP оказалась наиболее удачной в версиях BSD4.2 и BSD4.3 операционной системы UNIX. Эта реализация является эталоном для всех последующих.

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

ARPANET была исследовательской сетью, финансируемой Министерством обороны США. В конце концов она объединила сотни университетов и правительственных зданий при помощи выделенных телефонных линий. Когда впоследствии появились спутниковые сети и радиосети, возникли большие проблемы при объединении с ними других сетей с помощью имеющихся протоколов. Понадобилась новая эталонная архитектура. Таким образом, возможность объединять различные сети в единое целое являлась одной из главных целей с самого начала. Позднее эта архитектура получила название эталонной модели TCP/IP в соответствии со своими двумя основными протоколами.

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

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

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

Пакеты сетевого протокола IP могут содержать код, указывающий, какой именно протокол следующего уровня нужно использовать, чтобы извлечь данные из пакета. Это число -- уникальный IP-номер протокола. ICMP и IGMP имеют номера, соответственно, 1 и 2. Как система узнает, кому отдать пришедший пакет выше? Ведь на верхнем уровне может быть несколько протоколов. На межсетевом уровне эту проблему решает IP-код верхнего протокола, на транспортном - номер порта.

UDP (IP идентификатор 17) (служба ненадежной, но быстрой, передачи) - протокол передачи датаграмм без установления соединения. Также его называют протоколом «ненадёжной» передачи, в смысле невозможности удостовериться в доставке сообщения адресату, а также возможного перемешивания пакетов. Однако UDP-датаграммы имеют поле контрольная сумма сообщения, что гарантирует правильность доставки сообщения, в случае, если оно дошло до адресата.

TCP (IP идентификатор 6) (служба надежной передачи данных, устанавливающей логическое соединение) - «гарантированный» транспортный механизм с предварительным установлением соединения, предоставляющий приложению надёжный поток данных, дающий уверенность в безошибочности получаемых данных, перезапрашивающий данные в случае потери и устраняющий дублирование данных. TCP позволяет регулировать нагрузку на сеть, а также уменьшать время ожидания данных при передаче на большие расстояния. Более того, TCP гарантирует, что полученные данные были отправлены точно в такой же последовательности.

TCP и UDP используют для определения протокола верхнего уровня число, называемое портом. Существует список стандартных портов TCP и UDP.

HTTP - протокол TCP-порт 80 или 8080.

Важнейшим направлением стандартизации в области вычислительных сетей является стандартизация коммуникационных протоколов. В настоящее время в сетях используется большое количество стеков коммуникационных протоколов. Наиболее популярны следующие стеки: TCP/IP, IPX/SPX, NetBIOS/SM, DECnet, SNA, OSI.

Все эти стеки, кроме SNA на нижних уровнях -- физическом и канальном, -- используют одни и те же хорошо стандартизованные протоколы Ethernet, Token Ring, FDDI и ряд других, которые позволяют задействовать во всех сетях одну и ту же аппаратуру. Зато на верхних уровнях все стеки работают по своим протоколам. Эти протоколы часто не соответствуют рекомендуемому моделью OSI разбиению на уровни. В частности, функции сеансового и представительного уровня, как правило, объединены с прикладным уровнем. Такое несоответствие связано с тем, что модель OSI появилась как результат обобщения уже существующих и реально используемых стеков, а не наоборот.

Приведены основные используемые в сетях Windows 2000 стеки протоколов. Для функционирования Windows 2000 достаточно стека TCP/ IP -- стандарта передачи в сети Интернет. Поддерживаются также стек IPX/SPX -- стек маршрутизируемых протоколов, появившийся в сетях NetWare, Microsoft -- версия которого называется NWLink, а также NetBIOS/SMB -- стек небольших и быстрых, но немаршрутизируемых протоколов.

Принципы работы служб прикладного уровня

Сетевая служба - это набор функций, которые уровень выполняет для вышележащего уровня (например, коррекция ошибок).

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

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

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

Cетевой адрес процесса - это пара «IP адрес: номер порта» (например, 127.0.0.1: 80).

От 1 до 1023 - хорошо известные номера портов, от 1023 до 65 535 - другие.

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

Cетевое взаимодействие процессов

Процесс обращается к службам транспортного уровня: TCP и UDP.

Клиентская сторона приложения (службы).

Серверная сторона приложения (службы).

Протокол.

Клиенты и серверы - программы, т.е. процессы.

На одном компьютере могут быть запущено несколько клиентов или несколько серверных процессов.

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

Примеры служб и протоколов. WWW (HTTP, 80), E-mail (SMTP, 25; POP3, 110; IMAP, 143), DNS (DNS, 53), FTP (FTP, 21,20), Telnet (Telnet, 23); SSH (SSH, 22), синхронизация часов (NTP, 123), передача мультимедиа (RTSP, 554), совместный доступ к файлам (SMB, 445 или NFS, 2049), DNS (Domain Name System), NTP (Network Time Protocol), RTSP (потоковый протокол реального времени (Real Time Streaming Protocol)), SMB (server message block) (см. Samba), NFS (network file system).

Прикладной уровень

Службы разрешения имен

· Файл hosts.txt - файл статического сопоставления имен компьютеров и их ip-адресов.

· Служба разрешения имен NetBIOS и ее реализация в Windows - WINS (Windows Internet Naming Service).

o Файл lmhosts - файл статического сопоставления NetBIOS-имен и ip-адресов.

· DNS' (Domain Name System) - стандартная служба разрешения имен в Интернет.

Файлы hosts и lmhosts находятся в C:\WINDOWS\system32\drivers\etc\

Доменные имена компьютеров

Каждый компьютер в Интернете имеет свой IP-адрес. Сейчас распространены IP-адреса версии 4. Они представляют собой 4 числа, каждое из которых от 0 до 255. Такой адрес удобен при маршрутизации, так как определяет месторасположение компьютера в сети Интернет, однако, такие числа совсем неудобны для восприятия человеком. Более того, если, например, ваш e-mail: sasha007@207.176.39.176 и ваша почтовая служба решила сменить сервер, то вместе с ним изменится и e-mail. Гораздо лучше, когда компьютер имеет мнемоническое имя, например, mail.ru, sasha007@mail.ru. Существует файл hosts (и в UNIX, и в Windows), в котором можно прописывать адреса серверов, с которыми вы регулярно работаете.

Доменные имена компьютеров

DNS -- иерархическая структура имен. Существует «корень дерева» с именем "." (точка). Так как корень един для всех доменов, то точка в конце имени обычно не ставится, но используется в описаниях DNS. Ниже корня лежат домены первого уровня.

Домены верхнего уровня разделяются на две группы: родовые домены и домены государств. К родовым относятся домены com (commercial -- коммерческие организации), edu (educational -- учебные заведения), gov (government -- федеральное правительство США), int (international -- определенные международные организации), net (network -- сетевые операторы связи) и org (некоммерческие организации). За каждым государством в соответствии с международным стандартом ISO 3166 закреплен домен государства. Ниже находятся домены второго уровня, например, sfedu.ru. Еще ниже -- третьего (math.sfedu.ru) и т.д. В ноябре 2000 года ICANN было утверждено 4 новых родовых имени доменов верхнего уровня, а именно: biz (бизнес), info (информация), пате (имена людей) и pro (специали-сты, такие как доктора и адвокаты). Кроме того, по просьбе соответствующих отраслевых организаций были введены еще три специализированных имени доменов верхнего уровня: aero (аэрокосмическая промышленность), coop (кооперативы) и museum (музеи). В буду-щем появятся и другие домены верхнего уровня. Можно регистрировать домены на кириллице, вот пример работающего сайта: http://цюрих.com/. В конце 2008г. появится домен верхнего уровня .РФ. В принципе, получить домен второго уровня типа name-of-company.com несложно. Надо лишь проверить, не занято ли желаемое имя домена кем-то другим и не является ли оно чьей-нибудь торговой маркой

Имена доменов нечувствительны к изменению регистра символов. Так, например, edu и EDU означают одно и то же. Обычно разрешается регистрация доменов длиной до 63 символов, а длина полного пути не должна превосходить 255 символов. Размер доменного имени ограничивается по административным и техническим причинам.

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

Служба трансляции имен DNS

Клиенты DNS - специализированные библиотеки (или программы) для работы с DNS (в Windows - служба «DNS-клиент»).

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

Порт сервера - 53.

Серверное ПО: Berkeley Internet Name Domain (BIND) (демон named), NSD (name server daemon), Windows DNS Server

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

В общих чертах система DNS применяется следующим образом. Для преобразования имени в IР-адрес прикладная программа обращается к библиотечной процедуре, называющейся распознавателем, передавая ей имя в качестве параметра. Распознаватель посылает UDP-пакет локальному DNS-серверу, который ищет имя в базе данных и возвращает соответствующий IР-адрес распознавателю, который, в свою очередь, передает этот адрес вызвавшей его прикладной программе. Имея IР-адрес, программа может установить TCP-соединение с адресатом или послать ему UDP-пакеты.

Система DNS не только отыскивает IP-адрес по заданному имени хоста, но способна выполнять и обратную операцию, т.е. по IP-адресу определять имя хоста в сети. Многие веб- и FTP-серверы в сети Internet ограничивают доступ на основе домена, к которому принадлежит обратившийся к ним клиент. Получив от клиента запрос на установку соединения, сервер передает IP-адрес клиента DNS-серверу как обратный DNS-запрос. Если клиентская зона DNS настроена правильно, то на запрос будет возвращено имя клиентского хоста, на основе которого затем принимается решение о том, допустить данного клиента на сервер или нет.

Дополнительные функции DNS-сервера

1. Поддержка псевдонимов серверов. Пример: mmcs.sfedu.ru, web.mmcs.sfedu.ru и web.mmcs.rsu.ru имеют один и тот же ip-адрес

2. Поддержка почтового сервера домена.

3. Распределение нагрузки между серверами.

4. Кэширование (авторитетная и неавторитетная информация).

5. Поддержка почтового сервера домена. Можно узнать ip-адрес почтового сервера в домене (используется при пересылке почты).

6. Распределение загрузки между серверами. Одно доменное имя соответствует нескольким серверам, следовательно, по запросу служба может вернуть несколько IP-адресов. Наример, www.microsoft.com обслуживает несколько серверов. При этом первый по списку сервер меняется от запроса к запросу. Системы обычно берут первый IP-адрес. Загрузка происходит одновременно (то к одному серверу - то к другому), но мы, как пользователи, этого не замечаем.

Корневые серверы DNS -- это серверы DNS, содержащие информацию о доменах верхнего уровня (edu, org, com, ru, …), конкретнее -- указатели на серверы DNS, поддерживающие работу каждого из этих доменов.

Authoritative DNS-server -- сервер, отвечающий за какую-либо зону.

Корневые серверы DNS обозначаются латинскими буквами от «A» до «М». Их всего 13 штук (+ куча зеркал). Они управляются различными организациями, действующими по согласованию с ICANN. Количество серверов ограничено в связи с максимальным объёмом UDP-пакета (большее количество серверов потребовало бы перехода на TCP-протокол для получения ответа, что существенно увеличит нагрузку).

У многих корневых серверов DNS существуют зеркала. В частности, российское зеркало сервера F расположено в РосНИИРОС. IP-адреса корневых DNS-серверов можно получить командой «dig. NS» (dig точка NS; точка - корневой домен).

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

Рассмотрим схему подачи запроса серверу. Студент Стэнфордского университета с университетского компьютера пытается зайти на сайт воскресной школы мехмата sunschool.math.sfedu.ru. Чтобы определить IP-адрес компьютера sunschool.math.sfedu.ru, браузер студента вызывает DNS-клиент (resolver) - функцию API операционной системы. Она, используя IP-адрес локального DNS-сервера из настроек сети на компьютере студента, посылает запрос в виде UDP-пакета DNS-серверу. Пусть сервер будет atalante.stanford.edu.

Предположим, что локальный сервер Стэнфордского университета имен не знает IP-адреса sunschool.math.sfedu.ru. Тогда он посылает запрос одному из корневых серверов, адреса которых содержатся в его базе данных, пусть это будет f.root-servers.net. Таким образом получается рекурсивный запрос: DNS-клиент студента обращается к локальному DNS-серверу, а тот к корневому.

Маловероятно, что корневой сервер знает адрес хоста sunschool.math.sfedu.ru. Скорее всего он даже не знает адреса сервера sfedu.ru, однако он должен знать все свои дочерние домены - домены верхнего уровня. Но продолжать рекурсию он не будет. Дело в том, что корневые домены сильно загружены запросами, поэтому сконфигирированы так, что возвращают список DNS-серверов, которые должны больше знать о sunschool.math.sfedu.ru - это DNS-серверы домена ru. Получив список DNS-серверов, локальный сервер Стэнфордского университета направляет запрос одному из серверов списка (обычно первому), например, ns.ripn.net. Тот тоже загружен и возвращает адреса DNS-серверов дочерней зоны sfedu.ru. Последние два запроса называются итеративными (от слова «итерация»). Затем локальный сервер Станфордского университета обращается к первому в списке серверу домена sfedu.ru. Пусть это будет ns.sfedu.ru. В данном примере оказалось, что он тоже не знает IP-адреса sunschool.math.sfedu.ru. DNS-сервер нашего университета не так загружен, как корневые серверы или серверы доменов верхнего уровня, поэтому его сконфигурировали выполнять рекурсивные запросы. Он обращается к серверу домена math.sfedu.ru - это ns.math.sfedu.ru, получает искомый IP-адрес и возвращает его в ответе локальному серверу Стэнфордского университета, который, в свою очередь, сообщает его компьютеру студента.

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

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

Отметим также, что использование файла hosts лежит в основе многих «ускорителей Интернета» -- такие программы просто записывают адреса серверов, к которым вы обращаетесь, в файл hosts и при следующем обращении берут данные из него, не тратя время на запрос к DNS-серверу.

Структура DNS-сообщения

Запросы и ответы имеют один формат и состоят из:

· заголовка, включающего в себя идентификатор, размер сообщения, количество вопросов/ответов и т.д. (12 байтов);

· секции вопросов (название, тип);

· секции ответов (набор RR (resource record) -- записей из БД DNS);

· секции полномочности, которая содержит ссылки на полномочные сервера («Не знаю, но знаю у кого спросить»);

· дополнительной информации (IP-адреса тех, у кого можно еще спросить).

Это часть описания DNS-протокола.

Результат, возвращаемый командой dig:

;; ->>HEADER<<-opcode: QUERY, status: NOERROR, id: 42772

;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 7, ADDITIONAL: 7

;; QUESTION SECTION:

;sunschool.math.sfedu.ru. IN A

;; AUTHORITY SECTION:

ru. 172800 IN NS NS9.RIPN.NET.

ru. 172800 IN NS AUTH60.NS.UU.NET.

ru. 172800 IN NS NS.RIPN.NET.

ru. 172800 IN NS NS5.MSK-IX.NET.

;; ADDITIONAL SECTION:

NS.RIPN.NET. 172800 IN A 194.85.105.17

NS5.MSK-IX.NET. 172800 IN A 193.232.128.6

NS9.RIPN.NET. 172800 IN A 194.85.252.62

AUTH60.NS.UU.NET. 172800 IN A 198.6.1.181

dig @f.root-servers.net sunschool.math.sfedu.ru IN A -- спрашиваем у одного из корневых серверов адрес воскресной школы мехмата. Сервер отсылает нас к DNS-серверам зоны ru. Секции ответов нет - она пустая, т.е. корневой сервер не знает адреса воскресной школы. Зато он знает у кого можно спросить еще. В дополнении указаны IP-адреса серверов, у которых можно спросить.

Сервер DNS для Linux

BIND (Berkeley Internet Name Domain) -- программный пакет системы DNS для UNIX систем. Функции сервера DNS в этом пакете реализует программа named (от «name daemon»). На большинстве корневых серверов стоит BIND.

Конфигурационные файлы: /etc/host.conf - определяются методы и порядок преобразования имен ОС Linux; /etc/named.conf - опции программы named и список файлов, в которых находятся описания зон.

Пример файла /etc/host.conf

1 order hosts,bind

2 multi on

В первой строке указывается порядок преобразования имен хостов. Здесь операционной системе Linux указывается, что в первую очередь она должна обращаться к файлу /etc/hosts и искать хост там, а затем попытаться преобразовать имя с помощью системы DNS (bind), если не удалось этого сделать с помощью /etc/hosts.

Пример файла /etc/named.conf для кэширующего DNS-сервера

1 options {

2 directory "/var/named;

3 };

4

5 zone "." {

6 type hint;

7 file "root.cache";

8

9 };

10

11

12 zone "localhost" {

13 type master;

14 file "pri/localhost";

15 };

16

17 zone."0.0.127.in-addr.arpa" {

18 type master;

19 file "pri/127.0.0";

20 };

Дополнения к файлу /etc/named.conf с описанием зоны:

1 zone smallorg.org {

2 type master

3 file "pri/smallorg.org";

4 };

5

6 zone 0.163.192 in -addr.arpa {

7 type master;

8 file "pri/192.168.0";

9 };

http://it.mmcs.rsu.ru/wiki/%D0%A4%D0%B0%D0%B9%D0%BB:%D0%A2%D0%B8%D0%BF%D1%8B_%D0%B7%D0%B0%D0%BF%D0%B8%D1%81%D0%B5%D0%B9_%D0%B2_%D0%B1%D0%B0%D0%B7%D0%B5_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85_DNS-%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80%D0%B0.gif

Типы записей в базе данных DNS-сервера

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

Прежде всего в базе данных сервера DNS должна быть объявлена зона (логический узел в дереве DNS-имён), за которую данный сервер несет ответственность. Далее в ней должны быть объявлены все хост-компьютеры, имеющиеся в зоне. И, наконец, в базе данных можно объявлять специальную информацию, касающуюся зоны (например, о серверах электронной почты и DNS-серверах). Формат записи базы данных был разработан таким образом, чтобы DNS-сервер мог почерпнуть из нее любую информацию, нужную для его работы. В таблице приведены основные типы исходных записей, которые могут присутствовать в базе данных DNS. База данных DNS в последнее время стала темой для дискуссий среди исследователей, так как многие хотят дополнить ее новыми возможностями и наряду с этим повысить уровень безопасности. В настоящее время в базу данных DNS постоянно вносятся новые типы записей. В таблице отражены лишь основные типы записей, которые необходимы для открытия и ведения новой зоны в базе данных DNS.

Зона и серверы имен

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

Консорциум Всемирной паутины

С 1994 года основную работу по развитию Всемирной паутины взял на себя Консорциум Всемирной паутины (англ. World Wide Web Consortium, W3C), основанный и до сих пор возглавляемый Тимом Бернерсом-Ли. Данный Консорциум -- организация, разрабатывающая и внедряющая технологические стандарты для Интернета и Всемирной паутины. Миссия W3C: «Полностью раскрыть потенциал Всемирной паутины, путём создания протоколов и принципов, гарантирующих долгосрочное развитие Сети». Две другие важнейшие задачи Консорциума -- обеспечить полную «интернационализацию Сети» и сделать Сеть доступной для людей с ограниченными возможностями.

W3C разрабатывает для Интернета единые принципы и стандарты (называемые «Рекомендациями», англ. W3C Recommendations), которые затем внедряются производителями программ и оборудования. Таким образом достигается совместимость между программными продуктами и аппаратурой различных компаний, что делает Всемирную сеть более совершенной, универсальной и удобной. Все Рекомендации Консорциума Всемирной паутины открыты, то есть не защищены патентами и могут внедряться любым человеком без всяких финансовых отчислений консорциуму.

Клиенты WWW

URL

Веб-браузеры

Веб-браузер (Web browser) 3 это программа для запросов и отображения вебстраниц, и перехода от одной страницы к другой.

URL (Uniform Resourse Locator) -- универсальный адрес ресурса.

Изначальное предложение, создать паутину из связанных друг с другом документов пришло от физика центра CERN Тима Бернерс-Ли (Tim Berners-Lee) в марте 1989 года. Первый (текстовый) прототип заработал спустя 18 месяцев. В декабре 1991 году на конференции Hypertext'91 в Сан-Антонио в штате Техас была произведена публичная демонстрация.

Эта демонстрация, сопровождаемая широкой рекламой, привлекла внимание других ученых. Марк Андрессен (Marc Andreessen) в университете Иллинойса начал разработку первого графического браузера, Mosaic. Программа увидела свет в феврале 1993 года и стала популярной.

В 1994 году CERN и Массачусетский технологический институт (M.I.T., Massachusetts Institute of Technologies) подписали соглашение об основании WWW-консорциума (World Wide Web Consortium, иногда применяется сокращение W3C) -- организации, цель которой заключалась в дальнейшем развитии приложения Web, стандартизации протоколов и поощрении взаимодействия между отдельными сайтами. Бернерс-Ли стал директором консорциума. Хотя о Всемирной паутине уже написано очень много книг, лучшее место, где вы можете получить самую свежую информацию о ней, это сама Всемирная паутина. Домашнюю страницу консорциума можно найти по адресу http://www.w3.org. На этой странице заинтересованный читатель найдет ссылки на другие страницы, содержащие информацию обо всех документах консорциума и о его деятельности.

В апреле 1994 года Марк Андрессен и Джим Кларк, бывший профессор Стенфордского университета, образовали корпорацию Netscape Communication. В состав корпорации вошли многие ученые, вместе с Андрессеном занимавшиеся созданием браузера Mosaic, и в октябре 1994 года вышла в свет бета-версия продукта Netscape Navigator 1.0. В последующие годы компания приложила множество усилий для развития нового браузера и других технологий: web-серверов, коммерческих серверов, почтовых серверов, серверов новостей, прокси-серверов, программ чтения электронной почты и др. Netscape Communication по праву можно считать одной из самых прогрессивных и успешных Интернет-компаний середины 1990-х, а в августе 1995 года громкий публичный успех пришел к браузеру Netscape.

Компания Microsoft, изначально не проявлявшая значительной активности по продвижению своих интересов в Интернет, выпустила 1-ю версию браузера Microsoft Internet Explorer в августе 1995 года. Продукт не отличался изяществом и скоростью^{[источник?]}, однако компания вложила значительные инвестиции в его развитие, и к 1997 году Microsoft и Netscape шли бок о бок в «браузерной гонке».

11 июня 1997 года Netscape выпустила версию 4.0 своего браузера, а 30 сентября вышла в свет версия 4.0 Microsoft Internet Explorer. В то время еще не сложилось устоявшегося мнения о том, какой из браузеров лучше, а компания Microsoft, обладавшая монополией на свою операционную систему Windows, набирала все большую коммерческую мощь.

В 1997 году компания Netscape допустила ряд решающих просчетов: не была осознана важность создания портала на основе web-сайта компании, кроме того, было принято ошибочное решение о полном переходе браузера на Java-технологию. В конечном счете, 1998 год ознаменовался для Netscape Communication снижением ее доли на рынке браузеров и других продуктов, в конце года она была приобретена компанией America Online, а Марк Андрессен и большая часть его команды покинули свое бывшее детище.

Acid3 -- тест поддержки браузером веб-стандартов. Он осуществляет проверку 100 вероятно уязвимых мест в HTTP, HTML, CSS, ECMAScript, SVG и XML, а также проверяет работу с DOM. Намеренно выбирались такие тесты, которые не проходила сборка хотя бы одного из браузеров того времени (последние 16 тестов -- Firefox или Safari).

Другие клиенты

· Мобильный телефон может получить доступ к ресурсам веб-сервера.

· Другие интеллектуальные устройства или бытовая техника.

· Специальное программное обеспечение может самостоятельно обращаться к веб-серверам для получения обновлений или другой информации.

Веб-серверы

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

Дополнительные функции веб-серверов

· ведение журнала обращений пользователей к ресурсам;

· аутентификация пользователей;

· поддержка динамически генерируемых страниц;

· поддержка HTTPS для защищённых соединений с клиентами.

Стандартный порт: 80/TCP (8080).

Популярные веб-серверы

· Apache;

· Microsoft Internet Information Services (IIS);

· nginx;

Cвободный веб-сервер, пользующийся большой популярностью на крупных сайтах (yandex.ru).

· lighttpd

Cвободный веб-сервер, разрабатываемый с расчётом на быстроту и защищённость, а также соответствие стандартам (ya.ru).

Установка и настройка Apache

Файл apache\conf\httpd.conf ServerName localhost AddDefaultCharset windows-1251 Listen 80 DirectoryIndex index.php index.htm index.html

HomServ -- дистрибутив для Microsoft Windows, включающий Apache, PHP, MySQL, phpMyAdmin. Denwer -- дистрибутив для Microsoft Windows, включающий Apache. Apache после установки создает каталог, где хранятся странички.

Протокол HTTP (HyperText Transfer Protocol)

Порядок запроса страницы http://www.math.rsu.ru/index.html:

1. Браузер определяет IP-адрес сервера, по известному имени из URL.

2. Устанавливает TCP-соединение с сервером.

3. Отправляет текстовый запрос:

4. GET /index.html HTTP/1.1

5. User-Agent: Opera/9.24 (Windows NT 5.1; U; ru)

6. Host: www.math.rsu.ru

Connection: Keep-Alive

7. Сервер получает запрос и находит требуемый ресур.

Рассмотрим запрос поробнее. GET - команда веб-серверу (тип запроса). Такие команды называются «методами». /index.html - URI (Uniform Resource Identifier) - имя ресурса. HTTP/1.1 - протокол HTTP версии 1.1. Host: www.math.rsu.ru. Connection: Keep-Alive - не разрывать TCP-соединение (еще есть close).

Протокол HTTP версии 1.0 поддерживал только непостоянные соединения. Для веб-страницы, состоящей, например, из текста и 10 картинок в случае непостоянного соединения приходится 11 раз устанавливать и разрывать TCP-соединения, а это долгая процедура (см. лекцию про TCP, транспортный уровень). В HTTP 1.1 добавили возможность устанавливать постоянные соединения, да еще с конвейеризацией. В соединениях без конвейеризации клиент посылает запрос серверу после того как закончит прием текущего объекта. В соединениях с конвейеризацией клиент запрашивает объекты (например, картинки) сразу после обнаружения ссылки на них в HTML-документе, не дожидаясь окончания приема текста.

При помощи сниффера (например, Wireshark) можно получить данные реальных запросов:

Приведем пример запроса браузера:

GET /index.html HTTP/1.1 // обязательная строка

User-Agent: Opera/9.24 (Windows NT 5.1; U; ru)

Host: www.math.rsu.ru // обязательная строка

Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1

Accept-Language: ru,en;q=0.9

Accept-Charset: iso-8859-1, utf-8, utf-16, *;q=0.1

Connection: Keep-Alive

Ответ сервера мехмата: <pre><nowiki>HTTP/1.1 200 OK Date: Mon, 07 Jul 2008 15:10:06 GMT Server: Apache/1.3.37 (Unix) mod_perl/1.29 PHP/4.4.6 mod_ssl/2.8.28 OpenSSL/0.9.8e rus/PL30.22 Last-Modified: Tue, 17 Jun 2008 12:22:22 GMT ETag: "73619c-1d0d-4857ac7e" Accept-Ranges: bytes Content-Length: 7437 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: text/html <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <title>Учебно-научный центр "Механика. Математика"</title> и т.д.</nowiki></pre>

HTTP-ответ сервера

Сервер формирует ответ, состоящий из заголовка и тела.

'''HTTP/1.1 200 OK

Server: Apache/1.3.37 (Unix) mod_perl/1.29 PHP/4.4.6

Last-Modified: Tue, 17 Jun 2008 12:22:22 GMT

Content-Length: 7437

Keep-Alive: timeout=15, max=100

Connection: Keep-Alive

Content-Type: text/html'''

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html><head> <title>Учебно-научный центр "Механика. Математика"...

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

Коды ошибок, возвращаемых веб-сервером.

200 OK: Запрос успешно обработан, объект получен и включен в ответ.

301 Moved Permanently: Объект был перемещен; новый URL-адрес указан в строке ответа Location:. Программа клиента автоматически выполнит запрос по новому адресу.

400 Bad Request: Общая ошибка, вызванная невозможностью интерпретации запроса сервером.

404 Not Found: Запрашиваемый документ не найден на сервере.

505 HTTP Version Not Supported: Указанная в запросе версия HTTP не поддерживается сервером.

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

Рендеринг - процесс отображения страницы.

Передача данных от клиента на сервер по протоколу HTTP

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

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

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

CGI-приложения

CGI (Common Gateway Interface) -- стандарт обмена данными между прикладной программой, выполняемой по запросу пользователя, и HTTP-сервером, который данную программу запускает.

Данные передаются программе:

· через переменные окружения;

· на стандартный вход.

Программа передает данные серверу через стандартный выход. Формат такой же как у HTTP-ответа.

Common Gateway Interface -- «общий интерфейс шлюза». Здесь Gateway (шлюз) -- программа, которая работает по такому интерфейсу совместно с веб-сервером (многие предпочитают названия «скрипт» (сценарий) или «CGI-программа»).

Задача веб-сервера - отвечать на запросы клиентов. Сервер анализирует каждый запрос. Если клиенту нужен html-файл (не обязательно html), то сервер просто возвращает содержимое этого файла. А если клиент указывает в запросе на выполняемую программу и посылает в добавок аргументы для этой программы, сервер должен запустить эту программу с указанными аргументами и послать пользователю результат ее выполнения.

CGI определяет стандарты такого запуска программ на сервере: как информация из запроса и данные о сервере передаются программе (что через командную строку, что через переменные окружения) и как программа может возвратить дополнительную информацию о результате (например, его тип) в виде заголовков.

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

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

В веб-сервере Apache, например, такая настройка может производится при помощи общего файла настроек httpd.conf или с помощью файла.htaccess в том каталоге, где содержится этот скрипт. Также Apache позволяет запускать все скрипты, имеющие расширение.cgi.

Методы HTTP-запросов

GET - запрашивает содержимое указанного ресурса. В случае наличия у ресурса параметров, они передаются в URI: http://www.example.net/resource?param1=value1&param2=value2 POST - передает пользовательские данные (например, из HTML-формы) заданному ресурсу HEAD - запрашивает заголовок указанного ресурса PUT - загружает указанный ресурс на сервер DELETE - удаляет указанный ресурс

Методы

· OPTIONS

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

GET

Запрашивает содержимое указанного ресурса. Запрашиваемый ресурс может принимать параметры (например, поисковая система может принимать в качестве параметра искомую строку). Они передаются в строке URI (например: http://www.example.net/resource? param1=value1&param2=value2). Параметры - это и есть данные от клиента: имя и пароль, строка запроса к поисковой системе и т.п. Согласно стандарту HTTP, запросы типа GET считаются идемпотентными -- многократное повторение одного и того же запроса GET должно приводить к одинаковым результатам (при условии, что сам ресурс не изменился за время между запросами). Это позволяет кэшировать ответы на запросы GET.

· HEAD

Аналогичен методу GET, за исключением того, что в ответе сервера отсутствует тело. Это полезно для извлечения метаданных, заданных в заголовках ответа, без пересылки всего содержимого.

· POST

Передаёт пользовательские данные (например, из HTML-формы) заданному ресурсу. Например, в блогах посетители обычно могут вводить свои комментарии к записям в HTML-форму, после чего они передаются серверу методом POST и он помещает их на страницу. При этом передаваемые данные (в примере с блогами -- текст комментария) включаются в тело запроса. В отличие от метода GET, метод POST не считается идемпотентным, то есть многократное повторение одних и тех же запросов POST может возвращать разные результаты (например, после каждой отправки комментария будет появляться одна копия этого комментария).

· PUT

Загружает указанный ресурс на сервер.

· DELETE

Удаляет указанный ресурс.

· TRACE

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

· CONNECT

Для использования вместе с прокси-серверами, которые могут динамически переключаться в туннельный режим SSL.

В основном используются методы GET и POST.

Метод POST

После нажатия на кнопку «отправить» браузер посылает серверу сообщение. Приводим реальные данные, перехваченные сниффером. Запрос браузера к серверу, установленному на этом же компьютере:

(1) POST /action.php HTTP/1.1

(2) Host: test1.ru

(3) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.11) Gecko/20070324 (Debian-1.8.0.11-2) Epiphany/2.14

(4) Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

(5) Accept-Encoding: gzip,deflate

(6) Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

(7) Keep-Alive: 300

(8) Connection: keep-alive

(9) Referer: http://test1.ru/

(10) Content-Type: application/x-www-form-urlencoded

(11) Content-Length: 18

(12)

(13) name=sergey&age=26

(1) action.php -- это программа на сервере, которой передаются введенные данные. По этим данным она сгенерирует html-страницу, которая затем будет отправлена сервером браузеру.

(3) Это браузер ОС Linux Debian, установленной у клиента на виртуальной машине. Виртуальной машиной пришлось воспользоваться, так как сниффер не может перехватить запрос от браузера на локальной машине направленный к серверу на той же машине, т.е. через интерфейс 127.0.0.1.

(10) Тип передаваемого содержимого.

(11) Размер содержимого.

(12) Содержимое.

Приведем код HTML-странички (об HTML будем говорить позже):

<form action="action.php" method="POST">

Ваше имя: <input type="text" name="name" /><br><br>

Ваш возраст: <input type="text" name="age" /><br><br>

<input type="submit" value="Отправить">

</form>

Передача данных CGI-приложению

Передача данных CGI-приложению может осуществляться методами GET и POST.	GET	POST
Как данные передаются серверу	В url	В теле запроса
Как сервер передает данные программе	Через переменные окружения (QUERY_STRING)	Через поток стандартного ввода
Используется для передачи	небольших массивов данных	больших, в частности TEXTAREA и файлов

Кодирование и формат отправляемых данных

По умолчанию - application/x-www-form-urlencoded Все символы не из первой половины ASCII заменяются их кодами, например, “a” на “%E0”. Пробелы - на «+», «&» - на «%26».

multipart/form-data - используется для отправки двоичных данных и данных смешанного типа.

Существует два типа кодирования содержания (тела) HTTP-сообщения, которые можно определить в форме:

· application/x-www-form-urlencoded

· multipart/form-data

Первый тип кодирования выбирается по умолчанию и является основным способом. В URL документа можно использовать только символы набора Latin1. Это первая половина таблицы ASCII за вычетом первых 20 символов. Все остальные символы заменяются своими шестнадцатеричными эквивалентами. Кроме того, такие символы, как "+" или "&", играют роль разделителей или коннекторов. Если они встречаются в значении поля, то тоже заменяются на шестнадцатеричный эквивалент. Наиболее характерно это для работы с русским алфавитом. Поэтому скрипт, который принимает запросы, должен уметь эти символы декодировать.

Второй тип применяется для передачи двоичной информации в теле HTTP-сообщения. Если проводить аналогии с электронной почтой, то multipart/form-data обеспечивает присоединение файла данных (attachment) к HTTP-запросу. Наиболее типичным примером является передача файла с машины пользователя на сервер:

<FORM ACTION=script.cgi METHOD=post

ENCTYPE=multipart/form-data>

<INPUT NAME=n1 VALUE="Поле1">

<INPUT NAME=n2 TYPE=file>

<INPUT TYPE=BUTTON VALUE="Отправить">

</FORM>

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

Сообщение типа "multipart/form-data" состоит из нескольких частей, каждая их которых представляет успешный управляющий элемент. Части отправляются обрабатывающему агенту в том порядке, в котором соответствующие управляющие элементы представлены в потоке документа. Границы частей не должны находиться в данных.

Как и во всех составных типах MIME, каждая часть имеет необязательный заголовок "Content-Type", для которого по умолчанию устанавливается значение "text/plain". Агенты пользователей должны предоставлять заголовок "Content-Type" с параметром "charset".

Каждая часть должна содержать:

· заголовок "Content-Disposition", имеющий значение "form-data";

· атрибут именования, определяющий имя соответствующего управляющего элемента. Имена управляющих элементов, изначально закодированные с использованием наборов символов, отличных от ASCII, могут кодироваться с помощью метода, описанного в [RFC2045].

application/x-www-form-urlencoded

BigText= TextTextText&pol1= m

multipart/form-data

------------Gt1CO3wAR7XTbm1eE7LoA6

Content-Disposition: form-data; name="BigText "

TextTextText

------------Gt1CO3wAR7XTbm1eE7LoA6

Content-Disposition: form-data; name="pol1 "

m

------------Gt1CO3wAR7XTbm1eE7LoA6--

multipart/form-data - для отправки больших объемов данных или двоичных файлов

Пример CGI-скрипта (GET) на PascalABC

s:=Environment.GetEnvironmentVariable('QUERY_STRING');

writeln(file,'Переменная окружения QUERY_STRING: ',s);

writeln('Content-Type: text/html');

writeln(`');

writeln('<html> <head> <title> OK </title> </head> <body> <h1> Введенные в форму данные успешно записаны в файл zapros_get.txt </h1></body>')

Пример CGI-скрипта (POST) на PascalABC

Val(Environment.GetEnvironmentVariable('CONTENT_LENGTH'),n,err);

writeln(file,'Размер: ',n);

writeln(file,'Данные:');

SetLength(s,n);

for i:=0 to n-1 do

read(s[i]);

for i:=0 to n-1 do

write(f,s[i]);

writeln('Content-Type: text/html');

writeln('');

writeln('<html> <head> <title> OK </title> </head> <body> <h1> Введенные в форму данные успешно записаны в файл zapros_post.txt </h1></body>')

Недостатки и альтернативы CGI

Недостаток CGI: вызов программы - «дорогая» операция, особенно если это скрипт, который еще нужно интерпретировать (или откомпилировать).

Альтернативные технологии:

· встроенные в веб-сервер модули (mod_php, mod_perl в Apache);

· Fast CGI.

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

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

В то время как CGI-программы взаимодействуют с сервером через STDIN и STDOUT запущенного CGI-процесса. FastCGI-процессы используют Unix Domain Sockets или TCP/IP для связи с сервером. Благодаря этому, в отличие от обычных CGI-программами, FastCGI-программы могут быть запущены не только на этом же сервере, но и где угодно в сети. Также возможна обработка запросов несколькими FastCGI-процессами, работающими параллельно.

Языки программирования CGI-приложений

· PHP;

· Perl;

· Microsoft ASP.NET (на сервере IIS);

· JSP (Java Server Pages);

· Python;

· Ruby

и любые другие.

Cookies

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

Применяется:

· для отличия пользователей веб-сервером друг от друга;

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

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

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

Сторонние cookies

Иногда веб-странички включают в себя содержимое с других сайтов, например, рекламу с сайта рекламного агентства. Чтобы загрузить этот веб-элемент браузер (вне ведома от пользователя) обращается к серверу рекламного агентства, который может установить cookie. Вот такие cookie называются сторонними. Если такие cookies включают в себя информацию о посещаемом вами сайте, то это дает рекламному агентству возможность следить за вашим перемещением в Интернете по сайтам с его рекламой и выдавать вам рекламу того, чем вы больше интересуетесь. Таким образом нарушается тайна частной жизни пользователей. В штатах устанавливать такие cookie запрещено законом.

Механизм Cookies

Сервер ( CGI-программа) может установить cookie в ответ на запрос браузера. Для этого в заголовок ответа он добавляет строчку Set-Cookie, например,

Set-Cookie: sessionID=678893467800; lang= ru; domain=mydomain.com; expires=09-Nov-08 23:12:40

Браузер соxраняет cookie и затем посылает на этот сервер в виде строки Cookie в заголовке каждого запроса, например,

Cookie: sessionID=678893467800; lang= ru;

Куки также может быть установлена и самим браузером через JavaScript, который поддерживается большинством современных браузеров. Браузер должен соxранять куки на период определенный для ее времени жизни и посылать куки на сервер в заголовке запроса (request header) Cookie. В запросе посылаются только те куки, которые соответствуют домену, пути и протоколу для которых куки была установлена Клиент (браузер) имеет следующие ограничения для cookies, например: всего может храниться до 300 значений cookies, каждый cookie не может превышать 4Кбайт, с одного сервера или домена может храниться до 20 значений cookie.

Главной проблемой является изначальное недоверие пользователей к тому, что удаленные сервера без их (пользователей) ведома и согласия записывают на их собственные локальные диски какую либо информацию. Бытовали также слухи о том, что с помощью механизма cookie можно прочесть любую информацию с любого компьютера. Это неправда, к тому же современные версии браузеров позволяют контролировать прием cookie или вовсе блокировать его. Кроме того, появилось множество специальных утилит для управления приемом cookie, так называемые Cookie Managers. Другая сторона этой проблемы заключается в том, что на узлах Сети аккумулируются огромные массивы данных с персональной информацией, необходимые для коммерческих серверов. Вот здесь и появляются повышенные требования к защите от несанкционированного доступа к этим данным. Пользователи таких серверов должны быть уверены, что их имена, адреса электронной почты, телефонные номера и проч., не попадут в чужие руки. В противном случае последствия могут оказаться катастрофическими для "проштрафившихся" коммерческих серверов.