1. SEO курс
Лекция 11
От заявка до рендиране
Лили Грозева
allviaweb.com

2. Въведение

3. 1.1 защо е нужно да познаваме рендирането?
За да маркетирате в технологична среда, е важно да знаете как
работи мрежата.
В тази лекция ще научим:
● как URL се възприема от компютъра ви, и коя част какво
означава
● как компютъра ви повиква страница, и какво представлява
повикването (request)
● основи на уеб протоколите и защо HTTPS е по-труден за
сървъра

4. 1.1 защо е нужно да познаваме рендирането?
● какво става когато вашият request достигне уеб сървъра и как
се конструира резултата
● какво е каширане и как с него можете да видите друга
версия на страницата, вместо тази която сте очаквали
● преглед на това какво се случва с браузъра ви, когато
получава съставните части на уеб страницата и как ги
подрежда във вида, който вие виждате
Практически, рендирането е важно, защото познавайки го, ще
сте наясно защо маркетинговите ви кампании се провалят.
Допълнителна информация можете да намерите и тук.

5. Проверяване на уеб
адрес

6. 2.1 части на уеб адреса и предназначението им

7. 2.1 части на уеб адреса и предназначението им
● TLD на домейна, казва кой е отговорен за този домейн, и
също къде да намерите whois информация и информация за
nameservers където се хоства домейна
● домейна ни дава достатъчно информация за да направим
look-up на тези nameservers, например така
● събдомейна сформира част от рикуеста до тези
неймсървъри, за да намери локацията на уеб сървъра, който
ще ни предостави страницата
Всеки притежател на домейн, избира какви събдомейни да има и
накъде да сочат, когато им избира имената.

8. 2.2 DNS (Domain Name Server)
За да намери уеб сървъра, който ще сервира страницата, търсим
DNS записа на събдомейна - това е работа на неймсървърите. В
контекста на сервирането на уеб страници търсим:
● A record (Address record) представляващ IP адреса на
събдомейна (IP е Internet protocol)
● CNAME record (Canonical Name record), който връща другите
имена под които е познат домейна (т.нар. alias)
И двата вида проверки, могат да се извършват на сайтове на
трети лица като тези:
http://www.websitepulse.com/help/tools.php
http://network-tools.com/

9. 2.3 IP протоколи
Дали директно чрез A record, или индиректно чрез CNAME, това
винаги резултира в IP адреса на събдомейна. IP адреса е адрес,
който дава навигационна информация за компютъра ви да
намери уеб сървъра на който е тази страница.
Повечето IP адреси са сетове от числа от 0 до 255 и изглеждат по
този начин:
74.125.227.115
Горният тип са известни като IPv4 или 32-битови IP адреси. С
разрастването на интернет и свързаните към него устройства,
вече навлиза и IPv6, който стандарт е в 128-битови числа.

10. 2.4 TTL (Time to live)
Компютърът ни търси указания неймсървър в whois records, ако
нито той нито нашия ISP го няма запазен. На практика
функционира сложна система за каширане, и твърде малко
заявки стигат до неймсървърите - почти всичко се пази.
Времето, за пазене на това каше се определя с мярката Time to
live (TTL) и обикновено варира от няколко секунди до ден. Когато
ТТL е високо, и сменяте информация за DNS или неймсървъри -
това означава че промените които сте направили ще се опреснят
след 1-2 дни. (пренасочване на неймсървъри, смяна на whois
информация и тн.)

11. Повикване (request)
на уеб страница

12. 3.1 HTTP (Hypertext Transfer Protocol)
Веднъж, след като компютърът ви е идентифицирал къде да иде
да изтегли страницата, то той комуникира това с този сървър,
чрез HTTP протокол. Протоколът, с който се усъществява
комуникацята се разпознава с началото на адреса в браузъра.
HTTP се дефинира с няколко команди и асоцииран синтаксис.
Рикуестите изглеждат горе долу така:
GET /thispage.html HTTP/1.1

13. 3.1 HTTP/1.0
Първата версия на HTTP (HTTP/1.0) има три основни команди:
● GET - най-простият вид заявка, като просто “иска” страницата от
сървъра
● HEAD - идентична на GET, но връща само мета информацията в
head на страницата
● POST - като GET изпраща информация до сървъра, но може да се
използва от него, за да се зареди различна страница или да се
промени статуса на базата данни или на сървъра. Такава
команда се използва например, когато се попълват уеб форми.

14. 3.1 HTTP/1.0
И GET и HEAD са идемпотентни, което означава че те като команди,
не променят нищо важно на сървъра. Обикновено заявките се
логват, но самият ресурс не се променя. POST ( и някои рикуести от
HTTP 1.1) обаче променят информацията на сървъра.

15. 3.2 HTTP/1.1
С въвеждането на HTTP/1.1 се добавят някои нови команди:
● OPTIONS - връща HTTP методите, поддържани от този вид сървър
● PUT - ъплоудва версия на ресурса
● DELETE - изтрива ресурса
● TRACE - отговаря с копие на търсения ресурс (използва се,
защото някои по-напреднали сървъри си правят промени)

16. 3.2 HTTP/1.1
Сървърът отговаря с:
● статус код - 200ОК, 404 и тн;
● хедър - дава мета информацията за страницата, като енкодинга
й примерно
● празна линия, разделяща хедъра с body текста
Така че отговора на:
GET /thispage.html HTTP/1.1
Може да изглежда така:
HTTP/1.1 200 OK
Content-Type: text/html
<html><body>The simplest HTML possible</body></html>

17. 3.4 Бисквитки (cookies)
● 200 - OK
● 301 - постоянно пренасочване
● 302 - временно пренасочване
● 401 - неооторизиран достъп; често иска оторизация
● 403 - забранен достъп
● 404 - не е намерена
● 410 - умишлено изтриване, за разлика от 404, което е грешка
● 500 - вътрешна грешка на сървъра
● 503 - услугата не е налична - най-безопасният вид грешка, с
който да покажете на търсачките, че в момента сайта ви не
работи

18. 3.5 Лог файлове (Log files)
Повечето сървъри пазят записи със заявките, които са получили:
● IP адреса от който е получена заявката
● оторизацията получена при заявката за информация
● време и час на зареждане на информацията
● самата заявена информация
● статус кода, генериран при заявката
● големината на отговора (в Мб)
● реферала (страницата от която е кликнал човека за да се зареди
тази страница, тоест линк)
● user-agent на браузъра

19. 3.5 Лог файлове (Log files)
Ако прегледате истински лог файлове, ще видите че заявките са
разпределени по клъстъри както са групирани при зареждане на
парчетата от страниците. Тоест горе долу в този ред:
● CSS файлове (.css) за стилизация на страницата
● JavaScript файлпве (.js) за скриптове и интеракция
● изображения (.png, .jpg, .gif и тн)
● видео (директно или ембеднати Flash файлове); имайте предвид
че ако са ембеднати от външни сайтове като Youtube, то те се
зареждат като външни файлове, тоест последни
● външни скриптове (GA, реклами и тн)

20. 3.5 HTTPS сигурност
Всички примери досега са за варианта, в който връзката е HTTP и е
общовалидно и за HTTPS. Единственото, което се променя е начина
по който се пренасят данните.
HTTPS енкриптира заявката и отговора на сървъра използвайки SSL
(Secure Sockets Layer) или по-ъпггрейднатата версия TLS (Transport
Layer Security). И в двата варианта, информацията е защитена, и
валидизират че сървъра наистина принадлежи на компанията, за
която се представя.

21. 3.5 HTTPS сигурност
Базисните детайли по криптирането са:
● браузърите идват с инсталирани root сертификати, които
удостоверяват че някои авторитетни организации вярват на
HTTPS сайта
● връзката със secure сървъра започва с идентификация на
сървъра (и се свързва с root сертификат за удостоверение)
● в този първи контакт се разменят т.нар. encryption keys, с който
се продължава безопасната комуникация
● след това, както при HTTP протоколирането, но с един
допълнителен леър на закодиране най-отгоре

22. 3.5 HTTPS сигурност
HTTPS не е панацея за сигурността онлайн. Например, HTTPS не се
справя с:
● всички елементи на страницата да са сигурни - това зависи от
браузъра
● сигурността на уеб сървъра
● скриптовете на страницата от трети страни
● сигурността на връзката е такава от вас към уебсайта, но след
като дадете данните на сайта, няма гаранция че се използва
крииптирана връзка за да се изпратят на друго място

23. Сервиране на уеб
страница

24. 4.1 основни положения
В най-простия пример, един сървър получава една заявка за
страница чрез HTTP и се справя сам с нея.
Такъв сървър може да бъде една физическа машина, или
виртуален сървър, където много клиентски уебсайтове се
обслужват от една и съща програма или комбинация от двете.
Множество виртуални сървъри, поместени на една физическа
машина.
Споделените хостинг платформи използват хостнейм в HTTP
заявката за да доставят точният уебсайт. Това се случва горе
долу така.

25. 4.1 основни положения
Най-разпространеният сървър е Apache - безплатен сървър с
отворен код наличен за всички операционни системи. Други
популярни сървъри са Microsoft IIS Platform и Ngnix.
На теория вида на сървъра не е проблем за оптимизацията. На
практика, всички сървъри си имат своите особености. Например
Microsoft IIS по подразбиране сервира 302 пренасочвания, вместо
301.
Продукти като Builtwith помагат да видите какви технологии са
използвани при различните сайтове.

26. 4.1 основни положения
В практиката обаче, не се използват толкова опростени
постановки. Детайлният сетъп на сървъра обикновено е
прозрачен за браузъра, а от там и за търсачките.
Трябва да ви интересува скоростта с която се зареждат
страниците, а не как точно се случва това.

27. 4.2 статични ресурси и прости скриптове
Най-прости са заявките за статични ресурси (можете да мислите
за статичните ресурси като за файлове в папка). Статични най-
често са изображенията и файловете, които не се променят често
като CSS файловете. Те могат смело да се кашират.
Други теоритично статични файлове, са ресурсите генерирани от
простите скриптове. Най-разпространени сред тях са PHP
скриптовете. Когато сървъра получи заявка за страница на PHP,
скрипта се изпълнява и резултата му се предоставя като
“страница”.

28. 4.2 Frameworks за уеб разработка
С усложняването на уеб приложенията, се разработиха и много
по-сложни езици за програмиране и програмни среди. Тези
приложения често се разработват в среди като Ruby on Rails,
Django for Phython и .NET на Microsoft. Средите за програмиране
осъществяват голяма част от задачите на разработчика (като
интеракцията с бази данни) и осигуряват едновременно по-бърза
разработка, или разработка на по-сложни приложения.
Йерархично, сложността изглежда така:
● най-просто: сервиране на статични файлове, точно както са
на диска
● базово: сервиране на резултат от един скрипт
● среда за програмиране: URL се използва като изходящи данни
за функция, и уеб сървъра връща като информация резултат
от едно приложение.

29. Каширане

30. 5.1 Каширане с проксита
Независимо от това, че за каширането се използва уеб
приложение, много уебсайтове прилагат каше леър и сервират
резултата му, без изобщо да притесняват приложението.
Принципно е възможно, да се разбере дали даден уебсайт не
използва Varnish proxy, но трябва да е ясно и от съдържанието
което се сервира.
Повече за сервираното с каше съдържание, можете да видите
тук.

31. 5.2 Content Delivery Networks (CDN)
CDN са една стъпка нагоре след Varnish cache. Което пак е каше,
но е на трето лице и то което е най-близо до потребителя.
Използват се за увеличаване на скоростта на зареждане на
страниците. Най-популярните сред тях са Amazon Cloud Format,
Akamai и CloudFlare.

32. Браузъри и
рендиране