Читать книгу Основы разработки веб-приложений и сайтов. Путеводитель по веб-технологиям - Алан Мурадов - Страница 3

Описание архитектуры

Теперь же перейдем к тому как технология сама по себе выглядит. Выглядит она следующим образом: если используется технология или архитектура как принято называть «клиент-сервер» т.е. архитектура клиент-сервер строится вокруг следующего взаимодействия: т.е. клиент посылает запросы к серверу, а сервер посылает ответы клиенту. На самом деле в классическом HTTP обмене между сервером с протоколом HTTP и клиентом, которые посылают по этому протоколу запросы вообще говоря на этом все и кончается. Это соединение устанавливается поверх транспорта TCP, т.е. в протоколе TCP IP имеется 2 транспорта дейтаграммный транспорт, в частности котором работают сейчас службы DNS, а все остальные сервисы в основном работают вокруг транспорта TCP так называемая «надежная доставка сообщений». Вот HTTP оно работает поверх TCP на 80 порту, очень часто это можно видеть, когда вы смотрите логи и там записаны то как, происходит обмен между клиентом и сервером то там как раз по 80 порту TCP у вас все это туда-сюда «ходит и бродит». И для того чтобы сократить обмен и зафильтровать какие-то вещи, администраторы весь 80 траффик заворачивают на прокси сервера, в который вас куда-то пускают, а куда-то не пускают. Вот обычно это все так и устроено.

Вот вы пользуетесь на своем компьютере браузером, это может быть Chrome, Explorer, Firefox, это может быть Mozilla всякая, это может быть Opera, любители же Mac соответственно Safari и т.д. их великое множество. На самом деле кроме того, что вы можете видеть глазами клиентов существуют еще и другие клиенты. Это всякого рода боты поисковых систем, Яндекс бот, Рамблер бот, Гугл бот и т.д. которые ходят и опрашивают HTTP сервера ресурса и срисовывают с них страницы и потом отправляют их в систему индексирования.

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

На самом деле это вот классический HTTP обмен, не единственный, помимо него, сегодня мы пользуемся протоколом HTTP 1.1, который позволяет держать сервер в некотором ожидании, т.е. в режиме keep alive для того, чтобы можно было за TCP Connect, за один TCP сеанс передать несколько HTTP транзакции для того чтобы не поднимать новые TCP соединении. Ну для чего это нужно достаточно понятно. У вас как правило страницы состоят не только из HTML кода, помимо него у вас на странице есть картинок множество, у вас там метрики какие-то стоят, кто-то на рекламе Гугла зарабатывает Google Adsense, кто-то пытается амазоновские книжки где-то там разместить, участвовать во всяких реферальных программах, и т.д. Все вот это на самом деле таскания какого-то контента к пользователю, который заходит в сеть и открывает в браузере какую-то страницу и если весь этот контент тянется с одного сервера, конечно желательно, особенно если у вас широкополосный доступ, а не какой-то Dial-up, то как правило все это за один TCP коннект, через несколько HTTP транзакции вы это все к себе загружаете.

Когда мы говорим об HTTP – мы говорим о протоколе, который не ориентирован на удержания соединения. Вот если взять, например, FTP, если взять telnet, если взять ssh какой-нибудь (защищенные терминальные протоколы) то вот эти протоколы ориентированного соединения. Вы открываете TCP сессию, вы проходите авторизацию и у вас удерживается соединение постоянная и вы постоянно работаете. А если же говорить о HTTP, то у вас устанавливается соединение только на запрос-ответы и после этого соединение теряется. Отсюда возникает масса проблем связанных с поддержкой например пользовательского доступа к каким то подписным ресурсам т.е. когда вы аутентифицировались, потом вас надо как пользователя запомнить, сервер вообще-то проще говоря вас потерял, потому что TCP соединение прервалось и в результате когда вы к нему снова заходите, т.е. посылаете HTTP запрос вы одновременно посылаете массу служебной информации для того чтобы сервер осуществил так называемый user tracking т.е. запомнил что вы уже приходили, что вы уже сказали, что это вы, что вы осуществили определённую последовательность каких-то действий и что вам можно делать тото сёто пятое и десятое . Т.е. вот такие-то особенности HTTP протокола который не ориентированного соединения заставляет нас городить целый огород связанный с поддержкой сессии, которые вот самим протоколом очень долгое время не поддерживались, имеется ввиду, что не ориентировались они на TCP соединения, значит сейчас есть механизм «Куки» который позволяет это делать.

Мульти протокольные клиенты

На самом деле сами браузеры – они представляют из себя мульти протокольных клиенты, не очень хорошее слово – не благозвучное, но так оно на самом деле и есть, потому что вот Firefox, Explorer и прочие клиенты они вам позволяют взаимодействовать не только с HTTP сервером. Например, очень часто вас перебрасывают на FTP соединения, но FTP сервер это не HTTP сервер, это уже совершенно другое соединение и взаимодействие уже совершенно по другому протоколу. Мульти протокольные браузеры, они же мульти протокольные клиенты позволяют вам проще говоря построить систему вокруг различных протоколов доступа к информационным ресурсам в сети. HTTP протокол является основным базовым протоколом всемирной паутины и в основном через него происходит обмен информации.

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

Средства обработки контента

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

Когда речь идет об интерпретации HTML кода,       Когда речь идет об интерпретации HTML кода, т.е. HTML разметки, запускается так называемый HTML парсер в рамках браузера. Очень часто в начале HTML документа стоит, так называемый document type definition, потому что фактически вы имеете дело с HTML документом и вы всегда можете запросить валидатор, который проверит вам синтаксис этого HTML документа. Многие программы редакторы html кода вставляют тег Doctype автоматически, в принципе неплохо и вставлять руками, потому что на самом деле когда загружается документ то браузер запрашивает валидатор и смотрит действительно ли соответствует ваш документ тому описанию, которое у вас в doctype definition указано. Оно может быть русским, английским и т.д.

Параллельно при просмотре документа у вас запускаются масса прочих всяких компонентов, т.е. как только натыкается       Параллельно при просмотре документа у вас запускаются масса прочих всяких компонентов, т.е. как только натыкается html парсер на элемент разметки image он запускает скачивания этих самых картинок и соответственно запускает так называемые плагины, которые встроены в браузер-компонент, который отображают различные графические форматы. Т.е. на самом деле программы, которые отображают gif, jpeg, png и прочие форматы они не являются неотъемлемой частью браузера. Они являются компонентами написанные с использованием соответствующего application program interface, так называемый API и поэтому в принципе, когда клиент сообщает серверу или посылает запросы серверу то там есть такая штука, которая называется Accept (принимаю информацию) и вот в этом Accept он перечисляет какие форматы той же графики он может отобразить и вообще говоря сервер по идее должен читать вот эти самые Accept и посылать туда только те картинки, которые вообще говоря браузер может отобразить.

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

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

URI и URL

Загрузка же самих документов, т.е. как адресуется вся эта информация в сети она происходит через универсальный локатор ресурсов. На самом деле мы привыкли говорить что это URL т.е. Universal Resource Locator, вообще то говоря спецификация называется URI и RFC (Request for Comments ) так называемые стандарты интернета, они вообще то говоря вот в данной конкретной части они определены для URI (Universal Resource, Identifier), а вот реализация этого самого Identifier в рамках html она собственно и называется универсальный локатор ресурсов, потому что вообще то говоря, вот реализация URI для электронной почты она называется URM.

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

Html на самом деле задает структура документа, т.е. первоначально в 90м году он совмещал внутри себя 2 функции. – функция, определяющая структуру документа: параграфы, списки, общая часть документа, какие-то параметры, которые характеризуют или описывают документ целиком, заголовки, структурировал сам текст. Самый простой момент – это когда вы говорите о дереве каком-то, значит это так называемый sitemap (карты сайта) – обычно их называют навигационными страницами, которые состоят сплошь из гипертекстовых ссылок. Их как правило принято отделять от так называемых информационных страниц, где у вас там просто картинки размещены или какие-то тексты, или еще что-то, т.е. на самом деле у вас вообще то говоря существует как-бы структура страницы и существует способ отображение этой страницы на различных устройствах, на различных медиа.