LINUX.ORG.RU
ФорумTalks

Пишу историю интернетов, помогите дополнить/улучшить/исправить


0

0

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

1. Почти идеальная система.

www еще небыло. Было FTP или Gopher.

Пользователь приходил на "сайт", скачивал нужные документы (описания которых были в Readme, анонсе FTP-директории или прямо в именах файлов), отключался от интернетов и спокойно читал документ. Аналогично было с новостями по NNTP.

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

2. Рождение www

Появились переходы между документами, не нужно было больше знать имя файла, хотя все по прежнему лежало в файлах. Только транспорт был заменен на http, а тип документов на html.

И все были почти счастливы.

3. Шаблоны

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

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

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

Но была проблема: когда надо было добавить новый раздел, нужно было править каждый файл на сервере. А это долго и сложно. И тогда появились шаблоны, позволяющие хранить повторяющиеся части отдельно. И вставлялись они обычно "на лету", дабы не занимать место на сервере. Вместо этого они занимали CPU, так как серверу каждый раз приходилось разбирать эти файлы и вставлять в них шаблонные заготовки. Создавались и отдельные программы, которые эти шаблоны сами вставляли, создавая готовые странички, которые и лежали на сервере. Нагрузка при этом оставалась практически прежней, а вот трафик от этого меньше не становился.

4. Страницы

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

И начали разбивать документы на меленькие страницы, добавляя в код еще и [страница 1], [страница 2], [страница 3], [страница 4], [страница 5], а некоторые, особенно продвинутые веб-мастера, еще и кнопки [назад], [вперед] делали. Конечно, ко всему этому добавлялись еще и шаблоны от оформления. В результате отдельные кусочки страниц стали меньше, а суммарный трафик вырос еще больше. И чем мельче нарезали странички - тем больше он рос. А как мелко нарезать - никто не знал, поэтому каждый делал по своему усмотрению. В результате и владелец убитого модема, и выделенки, должны были кликать по многочисленным кнопкам.

И все тратили свой трафик на эти самые кнопки и оформление.

5. Списки

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

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

А сколько этих ссылок выводить? Ну не все же! Поэтому такие списки тоже дробили на страницы, как и обычные документы.

Особенно продвинутые веб-мастера делали несколько списков, рассортированных по разным критериям, вроде названия, автора, да еще и в разных направлениях. Это мало жрало трафика, так как ими никто не пользовался. Зато жрало место на сервере.

Если сайт делал гуру, то в списках были еще и формы вроде "выводить по [50] записей, сортировать [по имени], фильтровать по [____]". Это еще немного жрало трафика и довольно серьезно ресурсы сервера. Причем на каждом сайте была своя фирменная форма, иногда даже на отдельных разделах сайта. Но это же все в итоге для пользователя, он привыкнет.

И жралось все больше трафика, и все больше ресурсов.

6. Виджеты.

А почему бы не встроить в страницу другие полезные элементы, типа списка "похожих документов", "недавно просмотренных товаров", "поисковые запросы других пользователей", панельку "вы искали" от введенного запроса в поисковике, "комментариев" и многих других, включая часы, показывающие время в Манаме? Ведь навигация по сайту - это и есть по сути виджет, так почему бы не добавить еще и других, [не] менее полезных?

А трафик опять ростет. А добавляемая польза опять сомнительна. Загрузка на сервер может и не рости, если виджеты статичные, т.е. привязаны только к тексту на странице и независят от пользователя (т.е. есть возможность статической генерации/кеширования)

7. Персонализация

А почему бы не сделать так, что на каждой странице будет надпись "Привет, Вася Пупкин!", ведь пользователь может забыть свое имя! А почему бы не предоставить пользователю возможность выбирать цвет дизайна, среди зеленого в красную крапинку, и красного в зеленую крапинку? Ведь шаблоны можно подключать динамически! Это же гениально! В довесок ко всему этому можно прикрутить личные страницы пользователей, почтовую систему, систему рейтингов, игр и взаимоотношений с женщинами. Получаем гламурный Веб2.0. Можно делать деанонимизацию.

А трафик опять растет, пусть и немного. И прилично растет нагрузка на сервер.

8. Кукисы

Персонализация сайта - дело хорошее, но где хранить все настройки? Если хранить на сервере - это как минимум нужен пользовательский аккаунт, а что делать, если нам нужно запомнить, какие именно виджеты включил/выключил пользователь? Как он предпочитает сортировать результаты поиска? А для этого не нужен аккаунт, достаточно Cookies! Правда, дают всего 4кб на настройки, но этого достаточно даже для выбора товаров в инет-лавочках, лежащих на статичных хостингах.

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

9. Аякс

Что-то у нас слишком много трафика идет! А нельзя ли загрузить только часть страницы, догрузить только нужное, не забивая канал? Конечно можно! Для этого нужно использовать то, что нынче называется аяксом, а до этого загружалось через iframe и не имело никакого маркетингового названия. И хоть система позиционируется как XML-based, через нее можно гонять совершенно любые данные.

Благодаря асинхронности многие полагают, что запросы исполняются параллельно, и отправив на сервер 150 мелких запросов они получат в 150 раз более быструю загрузку. При этом многие вообще не в курсе существования заголовков и 3-х пакетного TCP-handshake, используемого при установке соединений (если включен keep-alive, то все запросы пойдут по 1-2 соединениям), что тоже дико жрет трафик. Причем не просто жрет, а еще и насилует сервер. Но это же так легко, когда виджет новостей обновляет сам себя, при этом никак не связан с виджетом последних сообщений! А трафик... Ну ладно, пусть будет чуток больше...

Хотели как лучше, а получилось как всегда.

10. Мультимедиа

Мы нарисовали классную анимацию, как бы нам ее разместить? Нет, сохранить в avi мы не можем, поскольку нужны кодеки, а у пользователя их может не быть! И в проприетарный FLV тоже не будем - флеша тоже может не быть, да и еще куча проблем с ним. Лучше выложим в GIF, всего 10 мегабайт получилось, да и 4 цветов вполне достаточно для нашей анимации.

Мы бы конечно использовали нормальный кодек и уместили все в 300кб, но у кого-то это может и не сработать.

11. Формы

А нельзя ли сделать так, что пользователи будут добавлять к нам свои фотографии? Нужно PHP и какой-то UPLOAD? Да нет проблем. Вот только пользователи пошли невнимательные, постоянно пытаются закачать свои фото в BMP, хотя мы ясно написали про JPEG! Нам не жалко, но трафик то идет! Да еще какой! Ведь только на 5 раз в среднем пользователям удается залить свое фото.

И на странице поиска они зачем-то нажимают кнопку "искать" по 2-3 раза. Ну а что делать, если скрипт не сразу отдает данные. которые он должен сначала найти?

Или введут пароль, но не введут капчу. Сразу за этим правильно вводят капчу, но не вводят пароль. Что с ними делать?

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

Туду:

Интерактивный контент?

Коллаборейшен?

Интерфейсы к внутреннему API?

simple_best_world_web_master
() автор топика

>И в коде каждой страницы появились многочисленные [главная], [о нас], [наши работы], [наши статьи], [наши партнеры].

Для того, чтобы избежать этого, (некоторые) начали использовать "frame"-ы...
И это, на мой взгляд, довольно разумно, но иногда неудобно.

alias-10st
()
Ответ на: комментарий от simple_best_world_web_master

> Трафик вырос, что же с этим делать, ведь пользователи не могут прочитать документы полностью на медленных линиях?

и прикрутили FLASH по несколько МБ, а еще послушались пиарщиков из Apple и стали использовать графические кнопки для передвиженя между элементами сайта......

f3ex ★★
()
Ответ на: комментарий от alias-10st

> начали использовать "frame"-ы...

Ну их вроде всегда нелюбили (неумели готовить), поэтому я их и пропустил. Они были чем-то вроде вездесущей надписи "under construction", которая хоть и везде использовалась, но не была величайшим достижением тех лет

simple_best_world_web_master
() автор топика

>7. Персонализация
Уж лучше про ананимусов напишите

fedkoff
()
Ответ на: комментарий от simple_best_world_web_master

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

Лучше думаю либо отобразить это на схеме либо ввести субиерархию.

А так отличная хроника - видна широта охвата.

gkrellm
()
Ответ на: комментарий от simple_best_world_web_master

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

Веб 2.0 — это не мокрпл, не аякс и не карма.
Веб 2.0 случился, когда пользователь стал более активно участвовать в создании содержимого сайта («prosuming»).

Sphinx ★★☆☆
()

Сынок, что бы ты не писал, всё едино - интернеты скатились в сраное говно (ТМ) Михаил

На этом можешь забить на мемуары и пойти дерябнуть винца.

gharik
()

Во! Вступай в наш клуб "Web/2", "halfweb - контент важнее рюшечек, назад в прошлое", вторым будешь! Хоть регламент напишем, Дмитрий Анатольевич обещал же векторный фидонет - значит нас поддержит, третьим будет!

LordAily
()
Ответ на: комментарий от LordAily

12. Файлы.

Как и 20 лет назад, веб-серверы по прежнему парсят URL и выделяют из него путь к файлу (относительно корня сервера) и имя файла. И это уже не важно, что уже как 10 лет многие сайты построены на 1 файле вроде /cgi-bin/index.cgi, а позже и /index.php, который отвечает за каждую страницу. Что при этом порой скрывается реальное имя (htaccess), или вообще производится разбор URL прямо в WSGI. По сути, файлов на сайтах уже давно не осталось, реально все лежит в СУБД, доступ к которой в лучшем случае прикрыт красивыми именами.

> Во! Вступай в наш клуб "Web/2", "halfweb - контент важнее рюшечек, назад в прошлое", вторым будешь!

Нет, мне это ненужно. Я собираюсь создать веб-сервер, работающий без файлов, в котором будут учтены и исправлены все кривости реализации текущего веба. Систему, в которой не будет кривых форм, куда надо забивать пароль по 10 раз. Принципиальный уход от CGI и его последователей (fcgi/scgi/wsgi), совершенно иной подход к программированию веб-приложений. Никаких костылей в виде JQuery, лучшая поддержка с сервера. Переносимость на мобильные платформы, микроскопический трафик, при этом поддержка больших нагрузок (прототип дает 2к хитов в секунду на динамике, но работы еще идут).

Все, что мне нужно - косяки прошлого и настоящего.

simple_best_world_web_master
() автор топика
Ответ на: комментарий от simple_best_world_web_master

> Я собираюсь создать веб-сервер, работающий без файлов, в котором будут учтены и исправлены все кривости реализации текущего веба. Систему, в которой не будет кривых форм, куда надо забивать пароль по 10 раз. Принципиальный уход от CGI и его последователей (fcgi/scgi/wsgi), совершенно иной подход к программированию веб-приложений. Никаких костылей в виде JQuery, лучшая поддержка с сервера. Переносимость на мобильные платформы, микроскопический трафик, при этом поддержка больших нагрузок

Это пройдет, вместе с прыщами и онанизмом (c)

a3
()
Ответ на: комментарий от simple_best_world_web_master

у него 0 шансов из 0, если оно несовместимо с html/http. Web/2 - это просто навеска, со своими тэгами навигации, связей и систем, и html (а поверх и gzip on-demand) для всех остальных, хоть линксом гляди

LordAily
()
Ответ на: комментарий от simple_best_world_web_master

у него 0 шансов из 0, если оно несовместимо с html/http. Web/2 - это просто навеска, со своими тэгами навигации, связей и систем, и html (а поверх и gzip on-demand) для всех остальных, хоть линксом гляди

а ещё web/2 - это жёсткая централизация

LordAily
()
Ответ на: комментарий от LordAily

> у него 0 шансов из 0, если оно несовместимо с html/http.

Совместимо. И не только с ним. http в моей концепции - это только транспорт, не более.

> Web/2 - это просто навеска, со своими тэгами навигации, связей и систем, и html (а поверх и gzip on-demand) для всех остальных, хоть линксом гляди

Ссылку же! Может мою идею опять кто-то изобрел?

simple_best_world_web_master
() автор топика

>И жралось все больше трафика, и все больше ресурсов.

И катилось все в генну огненную. LOL, пиши еще

Karapuz ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.