Что такое веб-программирование

Спасибо заметке MpaK-а, которая подтолкнула написать меня следующее.

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

1. Сайт делится на две части: серверную и клиентскую часть. Серверная выполняется на сервере, а клиентсткая — в браузере.

2. Клиентская часть не имеет прямого доступа к данным на сервере. Браузер не может записать данные на сервер. Даже когда вы пишете в форму комментирования и нажимаете на кнопку. Клиентская часть не пишет данные на сервер, а только отображает их.

3. Общение между клиентской стороной и серверной идет посредством протокола HTTP. Клиентская взаимодействует с сервером посредством запросов с заголовками запросов, а серверная — посредством ответов с заголовками ответов.

4. Сервер не может делать запросы к клиенту. Сервер может только отвечать на запросы клиентской части в браузере.

5. Сервер не хранит текущее состояния пользователей. Ему все равно на какой странице вы сейчас находитесь. Время жизни скрипта на сервере меньше секунды.

6. Сервер каждое ваше нажатие на ссылку заново проводит вашу авторизацию. При помощи COOKIES. Это текстовая строка, которая передается в заголовках запроса к серверу.

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

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

Комментарии и костыли.

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

Я сказал, что сервер не хранит текущее состояние пользователя, но как же сессии? Конечно, везде есть свои механизмы сессий. Это хранилище, куда можно сохранять состояние пользователя, которое будет прозрачно общим между отдельными запросами клиентской части к серверу. Но увы практика показывает, что это дополнительная свалка мусора, еще один источник ошибок и узкое место в производительности. Лучше избегать сессий.

Добро пожаловать.

После того, как прийдет понимание клиент-серверной идеологии веба (или параллельно с этим) можно по шагам выполнить туториал для какого-нибудь популярного фреймворка — Ruby On Rails, Django. Как альтернатива чтению чужого кода.

18 комментариев

avatar
  • MpaK
  • +1
Ух ты как всё и вся ужал в маленьком тексте. Для совсем начинающих наверное как-то не совсем тема раскрыта покажется.
Я даже всё понял, надеюсь остальные тоже ;-)

Кстати, по 5. и 8. пункту на примере mod_perl можно показать, что не так, а живут скрипты в памяти до перегруза Апач сервера и могут хранить общее состояние и обмены.

«Лучше избегать сессий.» как-то кардинально. Нагрузка да дикая при сессиях если хранить в базе, файлах или памяти, но отличный способ хранить в Cookies, Rails и CodeIgniter это пропагандируют и вполне успешно.
avatar
Небезопасно хранить важные данные в Cookies ) А для меня все данные, которые влияют на логику приложения — важные )

Что в Rails, что в CodeIgniter, по-умолчанию, данные хранятся в незашифрованном виде + хэш. И оба руководства рекомендуют для важных данных использовать БД + ключ в Cookies.

А защита от Replay-attacks напрочь убирает преймущества хранилища в Cookies: guides.rubyonrails.org/security.html#replay-attacks-for-cookiestore-sessions

Вроде так.
avatar
  • MpaK
  • 0
Один флаг в конфиге и они уже зашифрованы :)

Ну, то что сессии охранять надо это да, если данные есть которые своруют, а просто так зря дергать их из базы наверное смысла нет, это конечно.
avatar
Короче, не люблю я их. Я люблю REST. Stateless это его основа :)
avatar
  • MpaK
  • 0
кстати, забавная штука получается с этим OAuth, которая чуток как раз нарушает идеологию Stateless ведь после первой авторизации и подтверждения, для следующих REST запросов например в Twitter всё же нужно передавать сгенерированный токен.
avatar
В принципе, косвенно токен можно считать за логин пользователя.

В АПИ Яндекс.Фоток, например, тоже передается токен, но там и без него есть логин пользователя. Более красиво.

Но я считаю, нарушало бы тогда, когда для получения результата существовала необходимость узнавать текущее состояние.
avatar
  • MpaK
  • 0
Ну как бы идея-то разрушена, когда текущее состояние не зависит от предыдущего, зависит, он тебе или отдаст твиты или не отдаст :)
avatar
  • amel
  • 0
'А второй вариант — сервер не закрывает соединение с клиентом пока не получит данные, что вызывает необходимость переделывать инфраструктуру на сервере.'
Почему? Тот же Ape легко прикручивается к любому unix-серверу и вот тебе готовый push.

avatar
Прикручивание = переделывание инфраструктуры. Обычный хостинг Nginx + Apache уже не подходит.
P.S. Протокол на это не рассчитан, вот и начались костыли.
avatar
Еще есть Dklab Realplexor, но его тоже надо устанавливать на сервер.
dklab.ru/lib/dklab_realplexor/
avatar
  • amel
  • 0
Realplexor хуже чем Ape, чем конкретно уже не помню, но когда экспериментировал ape дал лучшие результаты и проще установился.
А по поводу обычного хостинга — так редко когда такие проекты, где реально нужен push ставят не на vds.
avatar
Все равно это не полноценная замена установленному TCP соединению. Лучше уж эмулировать WebSockets через Flash.
avatar
  • amel
  • 0
Я против флеша.
avatar
Flash можно не любить, но до некоторых пор иначе никак нельзя было сделать:
— Хранение данных на стороне пользователя до 100кб. Cookies только 4кб и каждый раз передаются в заголовках.
— Копирование в буфер обмена. Средствами JS только для IE.
— Нестандартные шрифты (sIFR). Cufon (Canvas/VML) появился значительно позже.
— Настоящие постоянные соединения (XMLSocket).
— Проигрывание видео с ускорением.
— Проигрывание звука.

Завидую тем, кто будет разрабатывать во времена HTML5.
avatar
  • MpaK
  • 0
«Завидую тем, кто будет разрабатывать во времена HTML5.»
как-то ты пессимистично :) меняешь деятельность или думаешь на нашем веку этого не случится?
avatar
Я не смогу забыть этого ужаса.
avatar
  • MpaK
  • +1
Дальше будет хуже :)))
avatar
  • MpaK
  • +1
Тут проблемы с памятью на каждое подключение, префорками, но главное, как этим всем балансировать???
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.