Содержание к диссертации
Введение
Глава 1. Теоретико-методологические аспекты технической доступности Сетевых ресурсов
1.1. Техническая доступность СИР: сущность, условия и проблемы 10
1.2. СИР: анализ технической доступности 19
1.3. Принципы технической доступности СИР 28
Глава 2. Иерархия принципов технической доступности Сетевых ресурсов
2.1. Принцип сжатия данных 42
2.2. Принцип количества файлов 68
2.3. Принцип буферизации данных 78
2.4. Принцип простоты структуры и алгоритмов 85
2.5. Принцип отсутствия ошибок 101
Заключение 105
Список литературы
- СИР: анализ технической доступности
- Принципы технической доступности СИР
- Принцип количества файлов
- Принцип простоты структуры и алгоритмов
СИР: анализ технической доступности
Информационный ресурс – организованная совокупность информационных объектов [4, 5]. В Сети эта совокупность [3] может быть реализована как в виде веб-сайта или отдельной веб-страницы [14], так и полноценного веб-портала и других формах [6, 7, 9, 19]. Одной из форм Сетевого информационного ресурса является электронная библиотека [28].
Количество СИР постоянно увеличивается. Увеличение их числа приводит к возникновению новых классов проблем [109]. Одновременно с ростом числа СИР растет и общее количество пользователей, в основном, за счет менее подготовленных и технически образованных групп граждан.
В августе 1995 года число открытых СИР, по данным компании Netcraft, не превышало 18 тысяч сайтов [105]. На этом этапе сама ценность представляемой информации была огромной, поэтому пользователи находили способы для ее получения. В связи со слабой распространенностью подключения к Сети (и медленными каналами доступа) информация, в основном, была представлена только в текстовом формате. В этом смысле проблем доступности СИР не существовало, поскольку у подавляющего большинства пользователей они открывались за одинаковое (большое) время [50], составляющее порой несколько десятков секунд.
Только в начале 2000-х годов число СИР стало значительным за счет более широкого использования Интернета для коммерческих, социальных и образовательных нужд. Этому также способствовали популярность блогов, общая доступность СИР и легкость в обращении с ними [105]. Это все привело к тому, что число СИР, доступных публично, превысило 100 миллионов [79, 105].
Значимость СИР сложно переоценить [90]. И это привлекает в Сеть новых и новых пользователей, накладывая новые, более строгие требования на качество создания и функционирования СИР [12, 33, 57, 93]. Одним из условий переработки документальной информации [58] является обеспечение доступности СИР для эффективного освоения [1, 88, 89]. Для полноценного развития СИР необходимо обеспечение не только их освоения, но и полноценной доступности для всех категорий пользователей [10, 16].
Появление большого количества различных СИР [15, 20, 24, 25, 27, 31] для большого количества пользователей с различными типами подключений к Сети [13] и различными физиологическими и техническими особенностями [82, 83] привело к актуализации проблем доступности СИР, эффективное использование которых рассматривается как важнейший фактор социального и экономического развития человечества [2]. Это подразумевает, что при создании СИР необходимо не только учитывать их ценность с точки зрения расположенной на них информации, но и обеспечивать максимальную доступность этой информации для всех категорий пользователей [8, 49, 54].
В 2000 году практически весь сетевой трафик заключался в передачи классических HTML-форматов данных, текстовых и графических, но уже в 2007 году почти весь объем передаваемых данных заключался в видеофайлах, бинарных обновлениях и загрузках программного обеспечения. Средний размер ответа сервера увеличился с 12294 байтов до 68275 байтов, примерно в 5,5 раза. Эффективность (клиентского) кэширования в Интернете упала, поскольку число ответов с динамически создаваемыми данными увеличилось с 21,2% до 37,1% [50]. Это свидетельствует о постоянном увеличении технической сложности СИР, а также о необходимости анализировать эффективность текущих подходов и алгоритмов и использовать новые для создания доступных СИР [87, 121].
Проблема доступности (в широком смысле этого понятия) СИР является одной из основных проблем их развития [28, 29], она затрудняет качественное потребление и обработку информации, не позволяет осваивать новые способы и технологии представления мультимедийных продуктов.
В данной работе рассматривается технический аспект доступности СИР, а именно: доступность как способность услуги информационных технологий или её компонента исполнить требуемую функцию в установленный момент или за установленный период времени [100]. Для отделения технического аспекта доступности СИР от других аспектов доступности (например, доступность для различных категорий пользователей или информационная доступность) вводится понятие технической доступности СИР [53].
Стоит отметить, что рассматриваемые в данной работе средства оптимизации доступности позволяют сделать Сетевой ресурс доступнее (с технической точки зрения), повысить его удобство для всех его пользователей. В зависимости от пользовательских технических особенностей доступа к Сетевому ресурсу и исходной технической доступности СИР эффект от оптимизации может быть как незначительным, так и весьма заметным.
Под СИР здесь понимается не произвольный информационный ресурс, размещенный в Сети, но информационный ресурс, размещенный в Сети и имеющий самостоятельную ценность для пользователя. Например, отдельный CSS-файл не имеет для большинства пользователей самостоятельной ценности, для пользователей будет важен полноценный доступ к вебстранице, на которой этот CSS-файл используется. Но для изображений возможна ситуация, когда ценность имеет каждое отдельное изображение и веб-страница целиком, где все эти изображения используются.
При этом техническая доступность может быть измерена только в определенный, ограниченный промежуток времени. Не имеет смысла говорить о технической доступности СИР без указания периода времени, за который эта техническая доступность была измерена. При измерении технической доступности нужно определить количество пользователей, которые обращались к СИР за определенный период времени, и количество пользователей, которые не получили доступ к СИР за этот же период времени по техническим причинам. Таким образом, техническая доступность СИР может быть определена посредством формулы: ТД А Б (і), где А – количество пользователей, которые смогли получить доступ к данному СИР; Б – общее количество пользователей, которые обращались к данному СИР, включая тех, кто пытался, но не смог получить доступ к данному СИР по каким-либо техническим причинам. Техническая доступность составного (состоящего из других) СИР, может быть определена через техническую доступность каждого отдельного СИР, входящего в состав составного, следующим образом: ТД = (ТД1 + ТД2 + … + ТДN) / N (2), где ТДi – техническая доступность каждого отдельного СИР, а N – число СИР в составном. Возможны другие подходы для расчета технической доступности составного СИР при помощи методов теории массового обслуживания или сценариев использования веб-сайта, а также при помощи приоритетов (весов) для различных веб-страниц и СИР в составе веб-сайта. В данной работе они не рассматриваются.
Существует большое количество систем анализа посещаемости сайта, все из них оперируют терминами пользователь Сетевого ресурса и уникальный пользователь Сетевого ресурса (за определенный период времени). Для определения технической доступности Сетевого ресурса целесообразнее использовать понятие пользователь (поскольку есть слабая техническая возможность зафиксировать посещение Сетевого ресурса). В этом случае понятие пользователь эквивалентно понятию пользователем в случае полной или частичной технической недоступности Сетевого ресурса, учет уникальных пользователей исказит подсчет технической доступности пользовательская сессия или акт доступа к веб-ресурсу.
Принципы технической доступности СИР
В случаях, когда для верстки требуются полупрозрачные изображения, следует использовать формат PNG-24, поддерживающий альфа-каналы [153]. Нужно учесть, что браузер Internet Explorer 6 не поддерживает полупрозрачность в таких изображениях и для их корректного вывода следует применять фильтр AlphaImageLoader [115].
Для изображений с ограниченной палитрой следует применять формат PNG-8. Этот формат, как и формат GIF, позволяет использовать прозрачность (не альфа-каналы), но в большинстве случаев превосходит GIF по качеству сжатия итогового файла. Достигается это за счет более совершенного алгоритма сжатия (фильтрации), которая охватывает и горизонтальные, и вертикальные повторения, а также хорошо работает с градиентами.
Единственным кроссбраузерным форматом, позволяющим отображать анимацию в изображениях, на текущий момент является формат GIF [120].
Для иконок веб-сайта СИР существует специальный формат ICO, однако большинство современных браузеров могут использовать в качестве иконки изображение любого поддерживаемого ими формата [138].
Наибольшего эффекта от оптимизации можно достичь, только используя наиболее подходящий формат для каждого случая. Разделение сложных изображений (содержащих, например полноцветное изображение с некоторым количеством мелкого текста и полупрозрачную рамку) на несколько отдельных изображений, накладывающихся одно на другое, может существенно уменьшить размер веб-страницы СИР [52].
Для ручной оптимизации статических изображений в Windows и Mac OS можно воспользоваться программой Adobe Photoshop [113], для анимированных изображений — Adobe Fireworks [112]. В операционных системах семейства Linux похожие функции выполняет Gimp [133].
Изложенные средства оптимизации подтверждают существование принципа сжатия данных, который можно сформулировать так: у СИР не должно быть избыточной информации (текстовой или графической).
Принцип количества файлов
Для решения проблем технической доступности СИР при большом количестве отдельных файлов необходимо использовать простое объединение текстовых файлов. Уменьшить количество запросов к серверу можно за счет минимизации количества вызовов CSS-файлов. Оптимальное количество таких вызовов — не более двух на страницу [52]. Количество файлов может быть уменьшено за счет подключения на каждой вебстранице только того кода, который нужен на данной веб-странице.
Для корректного отображения веб-страниц СИР в старых версиях браузера Internet Explorer требуется отдельный набор CSS-правил. В таких ситуациях используют условные комментарии. Лучшим примером их применения является следующая конструкция, когда каждый браузер запросит лишь один файл, предназначенный для него [52]: !—[if gt IE 7] !-- link rel=”stylesheet” href=”css/style.css”/ !-- ![endif]- !—[if lt IE 8] link rel=stylesheet href=”css/style.ie.css” ![endif]- На веб-странице часто подключается несколько файлов JavaScript. Уменьшив их количество, можно значительно увеличить итоговую скорость загрузки страницы.
Весь код JS на веб-страницах объединить в одном файле, загружаемом и кэшируемом единожды. Это лучшее решение в том случае, когда кода JavaScript на сайте относительно немного (порядка 50-100 килобайт в сжатом виде).
В ситуации, когда сайт представляет собой сложное веб-приложение и объем кода превышает 100-150 Кб в сжатом виде, у объединения всего кода в одном файле имеется отрицательная сторона: при запросе первой страницы пользователь неизбежно будет загружать часть кода, которую мог бы не загружать вовсе. В крупных веб-приложениях сложно установить все зависимости модулей, — нужный код может многократно повторяться и, разумеется, будет загружаться пользователем несколько раз.
Допустим, на СИР существует определенная последовательность веб-страниц, посещаемых каждым новым пользователем, причем для каждой отдельной веб-страницы требуются разные модули JS. Для страницы P1 — модули F1, F2 и F3, для веб-страницы P2 — модули F1, F3 и F4, а для веб-страницы P3 — модули F1, F3, F5 и F6. Возможны три ситуации.
1. Объекты не объединены в один файл. При загрузке страницы P1 тратится время на загрузку объектов F1, F2 и F3, при загрузке P2 — только объекта F4 (F1 и F3 кэшируются после первой загрузки), а при загрузке P3 — F5 и F6.
2. Все объекты объединены в один файл. При загрузке страницы P1 тратится время на загрузку объектов F1-F6, но при загрузке всех остальных страниц внешние объекты не запрашиваются. 3. Объединены только модули, необходимые для текущей страницы. Для страницы Pi загружаются объекты Fb F2 и F3, для P2 — Fb F3 и F4, для P3 — Fb F3, F5 и Re. В этом случае каждая отдельно взятая страница при пустом кэше будет загружаться быстрее, однако все три страницы подряд будут загружены медленнее, чем в двух описанных выше случаях, т. к. объекты Fi и F3 дважды повторно загрузятся вместе с другими объединенными объектами. Выходом из положения может стать продуманное объединение модулей и выделение их ядра, т. е. набора модулей, используемых на большинстве часто загружаемых пользователями страниц. В приведенном примере таким ядром будут объекты Fi и F3.
В сложных ситуациях задача разбиения может быть легко формализована и решена, однако на практике это почти никогда не требуется, и для нахождения лучшего варианта объединения достаточно рассмотреть описанные выше варианты.
Существует следующая технология объединения изображений для уменьшения числа запросов к серверу [39]. Файл с несколькими объединенными в определенном порядке изображениями (спрайт) загружается единожды, после чего в разных частях страницы отображаются те или иные его области. Возможно даже создание эффектов анимации при помощи объединенных изображений.
Перед объединением изображений следует разбить их на следующие группы: изображения, повторяющиеся по всем направлениям (repeat); изображения, повторяющиеся по горизонтали (repeat-x); изображения, повторяющиеся по вертикали (repeat-y); изображения, не повторяющиеся по вертикали и горизонтали (no-repeat). Эти группы нужны для того, чтобы исключить возможность появления остальных изображений из группы в области другого изображения. Так, изображение с фиксированной высотой, повторяющееся на странице по горизонтали (например, градиентная заливка фона), может находиться в группе аналогичных изображений, выше или ниже их, но никак не слева и не справа.
Если изображение всегда фиксированного размера и не повторяется по какому-либо направлению, его можно размещать в произвольном месте итогового файла.
Если же изображение, к примеру, использовано в списках, в роли маркера, находящегося в фоне элементов списка, необходимо обеспечить пустое пространство в объединенном изображении правее и ниже изображения маркера. В противном случае под текстом списка может оказаться другая часть спрайта. Анимированные изображения нужно объединять отдельно, в зависимости от их размера и палитры, иначе размер объединенного изображения будет значительно превышать сумму размеров исходных изображений [51].
Минусом применения спрайтов является усложнение верстки, однако автоматизация процесса создания спрайтов позволяет устранить этот минус. Плюсом же является уменьшение как числа запросов к серверу, так и непосредственно размера страницы в ряде случаев более чем на 40% [39].
Встраивать изображения прямо в HTML-документ можно, используя схему data:URI. По стандарту RFC 2397 [166] такие URI предназначены для вставки небольших объектов как «непосредственных данных». Синтаксис должен быть следующим: data:[ тип данных ][;base64], данные
В случае изображений необходимо указание mime-типа для них (например, image/gif). После него должно располагаться base64-представление бинарного файла с изображением. Ниже приведен пример такой подстановки: img src=”data:image/png;base64,iVBORwOKGgoAAAANSUhEUgAAABAAAAAQAQMA AAAlPW0iAAAABlBMVEUAAAD///+ 12Z/o \AAm01EQVR4nGP4/5/h/l +G/58ZdrAz3D/M cH8yw83NDDeNGe4Ug9C9zwz3gVLMDA/A6P9/AFGGFyjOXZtQAAAAAElFTkSuQmCC” width=”16” height=”14” alt=”BcTpoeHHoe изображение” / Такие изображения, внедренные в HTML-страницы, разумеется, кэшируются только вместе с самим HTML-документом, содержащим их. Однако учитывая то, что изображения могут быть встроены и в файлы каскадных стилей, можно добиться кэширования этих изображений путем объединения их в одном внешнем CSS-файле. У данного подхода есть следующие минусы: изображения в base64-представлении имеют размер примерно на 33% больше исходного [52]; необходимо вычислять и обновлять base64-представление изображения каждый раз, когда оно меняется; требуется отдельное решение для браузера Internet Explorer версии 7 и ниже.
Решение первой проблемы возможно за счет использования gzip-сжатия файлов CSS, в которых располагаются встроенные изображения. Вторая и третья проблемы легко решаются автоматическим преобразованием изображений в base64-представления при помощи серверных скриптов и созданием альтернативной версии кода для указанных браузеров Internet Explorer [52].
Принцип количества файлов
Эту логику можно применить на любом этапе веб-разработки (как при начальном создании дизайна, так и при пострелизной оптимизации СИР).
На стадии полной загрузки страницы браузер запрашивает картинки и Flash-анимацию, которые заполняют отведенные им места на странице. По мере появления элементов на странице пользователь ощущает, что страница загружается. Обычно окончание этой стадии совпадает для пользователя с окончанием всей загрузки.
Если говорить об ускорении этой стадии, то здесь одной из основных технологий будет именно технология CSS Sprites, которая уже отлично себя зарекомендовала в этом качестве. Однако у нее вместе с очевидными плюсами (значительное уменьшение запросов к серверу, кроссбраузерность) есть и несколько минусов. В частности: несемантическая верстка в случае использования сложных спрайтов. Это приводит к дополнительному времени создания документа (особенно существенно может быть для «старых» браузеров); невозможность комбинирования нескольких осей повторения. Это не очень существенно, поскольку все использование CSS Sprites (как было описано в предыдущем разделе) можно свести к трем основным изображениям; тяжесть изменения картинки в случае сложной геометрии; отображение неверного фона при масштабировании.
Выходом из сложившегося положения является технология data:URI, которая позволяет включать фоновые изображения прямо в CSS-файл в base64-виде. Плюсы данного подхода очевидны: не нужно «склеивать» несколько картинок в один файл, есть возможность объединять различные оси и анимированные с обычными изображениями, полностью отделить содержание (семантику документа) от его представления (оформления и дизайна) и т. д. Но IE вплоть до версии 7 не поддерживает data:URI.
Для устранения приходит технология mhtml (MIME HTML [148]), которую поддерживает по умолчанию только IE (почти в полной мере) и Opera (начиная с версии 9.0). Она позволяет включать base64-данные в CSS-файл в виде комментариев. В этом случае сам файл выступает в двух вариантах: как таблица стилей и как хранилище фоновых картинок.
Если объединить эту технологию с data:URI, то доступность СИР существенно возрастет. Однако есть некоторое количество проблем, связанных с технологией data:URI.
В случае включения фоновых картинок прямо в CSS-файл последний заметно увеличивается в размере (даже при использовании gzip-сжатия). Это значительно увеличивает время предзагрузки (если фоновых картинок больше 10—15 Кб), и пользователь дольше видит белый экран.
Возможным выходом из сложившейся ситуации может стать подключение CSS-файла с фоновыми картинками по комбинированному событию window.onload, что вынесет загрузку элементов дизайна в ту область, где она изначально находилась: на стадию полной загрузки страницы или даже в пост-загрузку. В данном случае мы получаем полную аналогию средства CSS Sprites, только без заявленных выше неудобств.
Описанный выше прием позволит облегчить загрузку только пользователей с включенным (или поддерживаемым) JavaScript (их порядка 98-99%). Однако в ряде проектов этого может быть недостаточно. Для оставшихся пользователей мы можем через noscript подключить нужный нам файл (и конкретно для них замедлить предзагрузку) или поместить вызов этого файла перед /body (что в ряде случаев может быть аналогично подключению стилей в head ).
В качестве еще одного варианта можно рассмотреть создание единственного CSS-файла для таких пользователей, чтобы максимально ускорить им загрузку в случае отключенного JavaScript.
Из-за того, что Safari отличается алгоритмом обновления страницы (что позволяет значительно ускорить отображение самих страниц), для этого браузера не удается загрузить дополнительные стили после отображения первоначальной картинки (на стадии полной загрузки страницы). В этом случае Safari блокирует отрисовку картинки на экран и ожидает загрузку нового файла стилей.
На данный момент для Safari можно безболезненно загружать дополнительные файлы стилей только по полному событию window.onload.
В результате проведенных исследований [52] удалось установить, что в связи с проблемами безопасности в Vista mhtml-технология для отображения фоновых изображений не поддерживается. В этом случае единственным выходом будет подключение конкретно для этого браузера (через JavaScript) общего файла (с использованием CSS Sprites). Для пользователей IE7@Vista с отключенным JavaScript у нас нет другой альтернативы, чем загружать файл только с CSS Sprites или файл с mhtml.
Для автоматизации процесса объединения файлов фоновых изображений можно привести следующий алгоритм: загрузка и анализ всех внутренних ( style ) и внешних ( link ) стилей; выделение background-image в отдельный внешний стиль; загрузка и кодирование в base64 всех изображений, которые найдены в стилях; оптимизация правил с повторяющимися background-image в стилях; удаление CSS-правил с отсутствующими на сервере изображениями (устраняет лишние ненужные запросы); специальное подключение data:URI спрайтов для всех браузеров и отдельно для IE6, Ш7 Vista.
В ходе разработки реализации data:URI спрайтов были проанализированы наиболее часто встречающие варианты CSS-правил. Также был учтен всеми любимый браузер IE. Кому еще не известно: IE не поддерживает до версии 8 технологию data:URI. Однако для него существует альтернативный вариант реализации спрайтов — на основе mhtml-технологии. Другими словами, на данный момент есть возможность получить решение для всех современных браузеров (99% процентов всех используемых браузеров).
Во время тестирования найдена ошибка mhtml-технологии в Vista IE7 — а именно, браузер IE7 в ОС Vista при кэшировании mhtml-файла отказывается показывать изображения (это связано с малодокументированными проблемами безопасности при использовании mhtml в Vista IE7). Если сделать файл некэшируемым, то все работает, как и должно работать, но в случае с кэшированием фоновые изображения не отображаются.
Большие изображения (больше 24 Кб) нельзя включать из принципов кроссбраузерности, они могут формировать CSS Sprites и этим не только уменьшать общее время загрузки, но и формировать наиболее оптимальную визуальную скорость загрузки СИР у конечного пользователя. При этом часть картинок (включенных через комбинированный data:URI) появится сразу же, а часть (включенных через CSS Sprites) — через некоторое время, так как они будут представлены отдельными файлами.
Принцип простоты структуры и алгоритмов
Перед тем как браузер сможет установить соединение с веб-сервером СИР, он должен разрешить доменное имя, т. е., зная его, вычислить IP-адрес сервера. Результат может быть закэширован в браузере и операционной системе пользователя, и задержки при повторном открытии веб-страницы не возникнет.
Если же такой записи в кэше не существует, задержка на время поиска IP-адреса может оказаться значительной и будет зависеть от доступности DNS-сервера, содержащего требуемую информацию (а иногда и от доступности цепочки таких серверов).
Наилучший способ уменьшить временные издержки, связанные с разрешением доменного имени — использовать наименьшее количество различных хостов для размещения внешних информационных ресурсов веб-страниц, в особенности для тех ресурсов, которые требуются для первоначального отображения веб-страницы СИР.
Идеальным с точки зрения минимизации времени разрешения адреса DNS-сервера считается вариант, когда все объекты расположены на том же хосте, откуда была загружена веб-страница. Чем меньше используется хостов, тем больше вероятность того, что браузер сможет повторно использовать уже установленное соединение.
На практике же почти у всех браузеров существуют ограничения на количество одновременных соединений с одним хостом. Принимая во внимание это ограничение, наибольший выигрыш в скорости загрузки страниц можно получить, распределив загружаемые объекты по нескольким (не более 4-6) хостам [51]. Иногда возникает необходимость перенаправить браузер с одного адреса на другой. Причины чаще всего следующие: добавить косую черту к имени домена; предоставить пользователю документ, перемещенный на другой адрес; позволить пользователю обращаться к документам сайта, даже если он ошибся в написании адреса (например, не набрал www в начале адреса); направить пользователя на другие домены первого уровня, основываясь на его географическом месторасположении и данных об используемом им языке; направить пользователя на определенные страницы в зависимости от того, авторизован он или нет; направить пользователя на страницы с другим протоколом (HTTP или HTTPS); отследить и сохранить действия пользователя и т. д. 102 Какой бы ни была причина, каждый редирект порождает дополнительный HTTP-запрос, занимающий определенное время. Поэтому для страниц, для которых скорость загрузки наиболее критична, число редиректов должно быть сведено к минимуму. Для этого необходимо: следить за тем, чтобы ссылки на веб-страницах не вели на адреса, где заведомо будет срабатывать редирект; избегать цепных (последовательных) редиректов; использовать минимальное количество альтернативных адресов для одних и тех же страниц, стараясь предоставить всем пользователям единственный актуальный адрес для каждой страницы; использовать внутренние перенаправления — функцию, доступную в большинстве веб-серверов; использовать средства отслеживания информации о пользователе, не основанные на редиректах; предпочитать серверные редиректы клиентским, которые могут быть заданы при помощи тега meta или JavaScript-обработчика.
Редиректы, отправляющие браузеру код состояния 300, 301 или 302 и заголовок Location, обрабатываются браузером моментально, а при выполнении клиентских редиректов браузеру требуется дополнительное время на разбор полученной веб-страницы. Кроме того, некоторые браузеры могут кэшировать информацию о редиректах, тем самым ускоряя повторную загрузку ранее открытых веб-страниц.
Кроме редиректов необходимо устранить и ошибочные запросы (коды состояния 4xx) для данного СИР.
Устранение программных и аппаратных ошибок СИР Если отказ сервера, на котором расположен сайт, произошел ночью (по времени технической поддержки), а СИР должен быть доступен 24 часа в сутки (например, в связи с широким географическим покрытием пользователей), то это может вылиться в значительные неудобства и значительное снижение технической и серверной доступности.
Распределенная сеть серверов позволяет решить эту проблему: если отказывает один из имеющихся серверов, то его место тут же занимает самый близкий из сетевых соседей. Таким образом, конечный пользователь не замечает каких-либо перебоев в работе сайта.
Дополнительно данные в распределенной сети еще и резервируются на большом количестве серверов, что сводит вероятную возможность их потери практически к нулю: для этого необходимо, чтобы разом отказала вся сеть, а такое статически невозможно, если только не будет заранее тщательно спланировано злоумышленниками с привлечением весьма дорогих технологических средств.
Решение проблемы сетевого расстояния СИР CDN (Content Delivery Network, сеть доставки содержания) — распределенная сеть хранения данных. Предназначена как для обеспечения отказоустойчивости, так и для максимально быстрого времени ответа при запросе файлов.
Благодаря тому, что сетевой маршрут между конечными пользователями и серверами с информацией снижен до минимума (а сами серверы отвечают крайне быстро), скорость прохождения запросов будет весьма значительной.
В качестве примера стоит привести следующие цифры: время ответа обычного сервера, расположенного на VPS (даже не на виртуальном хостинге), составляет 50-200 мс (в зависимости от различных условий, в том числе от загруженности канала). Для CDN это число очень редко превышает 10 мс [52].
Пользовательская нагрузка при использовании CDN распределяется между серверами сети, а исходный сервер может быть использован только для получения обновлений информации. Если обновления происходят крайне редко (и на сайте не представлены динамические страницы, зависящие от поведения пользователя), то для исходного сервера просто не нужны большие мощности, и он может быть заменен на сервер минимальной конфигурации.
Таким образом, вся серверная нагрузка может быть возложена на CDN, а основной сервер будет отвечать только за актуальность представляемой информации.
В некоторых случаях (хостинг программного обеспечения или медиа-материалов, создание интерактивных промо-сайтов) исходный сервер с информацией может быть загружен «медленными» запросами (которые могут длиться минутами и часами, расходуя серверные ресурсы и не давая осуществить более быстрые запросы для получения остальной информации на сайте). В этом случае также выход один — использовать CDN.
CDN позволяет обеспечить одновременное обслуживание десятков и сотен тысяч «медленных» запросов, не требуя при этом дополнительной квалификации от персонала, отвечающего за сайт с исходным контентом. Проводя красочную промо-кампанию, в результате которой планируется обслуживать пользовательские запросы на файлы в несколько (десятков, сотен) Мб, стоит обратить внимание именно на сеть распределенных серверов: она гарантированно не откажет в результате высокой нагрузки.
Сеть распределенных серверов обладает еще одним преимуществом: она позволяет легко наращивать мощности, от обслуживания 1000 человек день до нескольких миллионов и более. Таким образом, резкое увеличение нагрузки никак не скажется на доступности СИР, его содержимое будет отдаваться по-прежнему быстро и без каких-либо перебоев.
Если СИР не создает большой статической нагрузки (оценочно не более 250—500 Кб/с), то можно воспользоваться серверами Google для выдачи файлов СИР [52]. Отмеченные минусы: по умолчанию доступно только большое время кэша, настройка Last-Modified требует дополнительной логики и нагрузки на процессор (может стать критичной при большом количестве мелких файлов); Google CDN не позволяет изменять заголовок Content-Encoding. При настройке архивирования придется положиться на логику серверов Google; процесс обновления сайта может стать достаточно трудоемким, если его не автоматизировать (но автоматизируется он довольно просто). Также в бесплатной версии присутствует ограничение на число ежедневных обновлений файловой системы; Google CDN по умолчанию не доступна из некоторого небольшого количества стран.
Также стоит отметить, что существует возможность полностью прикрепить домен к Google App Engine и применять для обслуживания его содержания какое-либо приложение App Engine. Это позволит (в случае полностью статического сайта) загружать его максимально быстро, совершенно бесплатно используя мощности Google (для среднего СИР это порядка 20 тысяч посетителей в день).
