Общ преглед на клиент-сървър - Научете уеб разработка | MDN

Общ преглед на клиент-сървър

Сега, след като знаете целта и потенциалните ползи от програмирането от страна на сървъра, ще разгледаме подробно какво се случва, когато сървърът получи „динамична заявка“ от браузър. Тъй като повечето сървърни кодове на уебсайтове обработват заявки и отговори по подобен начин, това ще ви помогне да разберете какво трябва да направите, когато пишете по-голямата част от собствения си код.

Предварителни изисквания: Начална компютърна грамотност. Основно разбиране за това какво е уеб сървър. Цел: Да се ​​разберат взаимодействията клиент-сървър в динамичен уебсайт и по-специално какви операции трябва да бъдат извършени от кода от страна на сървъра.

В дискусията няма истински код, защото все още не сме избрали уеб рамка, която да използваме, за да напишем нашия код! Тази дискусия обаче все още е много уместна, тъй като описаното поведение трябва да бъде приложено от вашия код от страна на сървъра, независимо кой език за програмиране или уеб рамка сте избрали.

Уеб браузърите комуникират с уеб сървърите чрез протокола за прехвърляне на хипертекст (HTTP). Когато щракнете върху връзка в уеб страница, изпратите формуляр или стартирате търсене, браузърът изпраща HTTP заявка до сървъра.

Тази заявка включва:

URL адрес, идентифициращ целевия сървър и ресурс (напр. HTML файл, конкретна точка от данни на сървъра или инструмент за изпълнение). Метод, който дефинира необходимото действие (например за получаване на файл или за запазване или актуализиране на някои данни). Различните методи/глаголи и свързаните с тях действия са изброени по-долу: GET: Вземете конкретен ресурс (напр. HTML файл, съдържащ информация за продукт или списък с продукти). POST: Създайте нов ресурс (напр. добавете нова статия към wiki, добавете нов контакт към база данни).HEAD: Вземете информацията за метаданни за конкретен ресурс, без да получавате тялото, както би GET. Можете например да използвате заявка HEAD, за да разберете последния път, когато даден ресурс е бил актуализиран, и след това да използвате само (по-„скъпата“) заявка GET, за да изтеглите ресурса, ако е променен. PUT: Актуализирайте съществуващ ресурс (или създайте нов, ако не съществува). DELETE: Изтриване на посочения ресурс. TRACE, OPTIONS, CONNECT, PATCH: Тези глаголи са за по-рядко срещани/напреднали задачи, така че няма да ги разглеждаме тук. Допълнителна информация може да бъде кодирана със заявката (например данни от HTML формуляр). Информацията може да бъде кодирана като: URL параметри: GET заявките кодират данни в URL адреса, изпратен до сървъра, като добавят двойки име/стойност в края му — например http://mysite.com?name=Fred&age=11. Винаги имате въпросителен знак (?), разделящ останалата част от URL адреса от URL параметрите, знак за равенство (=), разделящ всяко име от свързаната с него стойност, и амперсанд (&), разделящ всяка двойка. URL параметрите по своята същност са „несигурни“, тъй като могат да бъдат променяни от потребителите и след това повторно изпращани. В резултат на това URL параметрите/GET заявките не се използват за заявки, които актуализират данни на сървъра. Публикувайте данни. POST заявките добавят нови ресурси, данните за които са кодирани в тялото на заявката. Бисквитки от страна на клиента. Бисквитките съдържат данни за сесията на клиента, включително ключове, които сървърът може да използва, за да определи техния статус на влизане и разрешения/достъпи до ресурси.

Уеб сървърите изчакват съобщенията за заявка на клиента, обработват ги, когато пристигнат, и отговарят на уеб браузъра със съобщение HTTP Response. Отговорът съдържа код на състоянието на HTTP отговор, показващ дали заявката е успешна или не (напр. „200 OK“ за успех, „404 не е намерен“, ако ресурсът не може да бъде намерен, „403 забранен“, ако потребителят не е упълномощен да вижда ресурс и т.н.). Тялото на успешен отговор на GET заявка ще съдържа искания ресурс.

Когато се върне HTML страница, тя се изобразява от уеб браузъра. Като част от обработката браузърът може да открие връзки към други ресурси (напр. HTML страница обикновено препраща към JavaScript и CSS страници) и ще изпрати отделни HTTP заявки за изтегляне на тези файлове.

Както статичните, така и динамичните уебсайтове (обсъдени в следващите раздели) използват точно един и същ комуникационен протокол/модели.

Можете да направите проста GET заявка, като щракнете върху връзка или потърсите в сайт (като начална страница на търсачка). Например HTTP заявката, която се изпраща, когато извършвате търсене в MDN за термина „общ преглед на клиентски сървър“, ще изглежда много като текста, показан по-долу (няма да е идентичен, защото части от съобщението зависят от вашия браузър/настройка ).

Форматът на HTTP съобщенията е дефиниран в "уеб стандарт" (RFC7230). Не е необходимо да знаете това ниво на детайлност, но поне сега знаете откъде идва всичко това!

Заявката

Всеки ред от заявката съдържа информация за нея. Първата част се нарича заглавка и съдържа полезна информация за заявката, по същия начин, по който HTML главата съдържа полезна информация за HTML документ (но не и самото съдържание, което е в тялото):

GET /en-US/search?q=client+server+overview&topic=apps&topic=html&topic=css&topic=js&topic=api&topic=webdev HTTP/1.1 developer.mozilla.org keep-alive без кеш без кеш 1 Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, като Gecko) Chrome/52.0.2743.116 Safari/537.36 text/html,application/xhtml+xml,application/xml;q= 0.9,image/webp,*/*;q=0.8 https://developer.mozilla.org/en-US/ gzip, deflate, sdch, br ISO-8859-1,UTF-8;q=0.7,*; q=0.7 en-US,en;q=0.8,es;q=0.6 sessionid=6ynxs23n521lu21b1t136rhbv7ezngie; csrftoken=zIPUJsAZv6pcgCBJSCj1zU6pQZbfMUAT; dwf_section_edit=Невярно; dwf_sg_task_completion=Невярно; _gat=1; _ga=GA1.2.1688886003.1471911953; ffo=true

Първият и вторият ред съдържат повечето от информацията, за която говорихме по-горе:

Типът заявка (GET). URL адресът на целевия ресурс (/en-US/search). Параметрите на URL адреса (q=client%2Bserver%2Boverview&topic=apps&topic=html&topic=css&topic=js&topic=api&topic=webdev). Целевият/хост уебсайт (developer.mozilla.org). Краят на първия ред включва също кратък низ, идентифициращ конкретната версия на протокола (HTTP/1.1).

Последният ред съдържа информация за бисквитките от страна на клиента — можете да видите, че в този случай бисквитката включва идентификатор за управление сесии (бисквитка: sessionid=6ynxs23n521lu21b1t136rhbv7ezngie; ...).

Останалите редове съдържат информация за използвания браузър и вида отговори, които може да обработва. Например можете да видите тук, че:

Моят браузър (User-Agent) е Mozilla Firefox (Mozilla/5.0). Може да приема gzip компресирана информация (Accept-Encoding: gzip). Може да приема посочения набор от знаци (Accept-Charset: ISO-8859-1,UTF-8;q=0.7,*;q=0.7) и езици (Accept-Language: de,en;q=0.7,en- us;q=0,3). Редът Referer указва адреса на уеб страницата, която съдържа връзката към този ресурс (т.е. произхода на заявката, https://developer.mozilla.org/en-US/).

HTTP заявките могат също да имат тяло, но в случая е празно.

Отговорът

Първата част от отговора за тази заявка е показана по-долу. Заглавката съдържа информация като следната:

Първият ред включва кода за отговор 200 OK, който ни казва, че заявката е успешна. Можем да видим, че отговорът е във формат text/html (Content-Type). Можем също да видим, че използва набора от символи UTF-8 (Content-Type: text/html; charset=utf-8). Главата също така ни казва колко е голяма (Content-Length: 41823).

В края на съобщението виждаме съдържанието на тялото — което съдържа действителния HTML, върнат от заявката.

HTTP/1.1 200 OK Apache developer1.webapp.scl3.mozilla.com Accept,Cookie, Accept-Encoding text/html; charset=utf-8 Wed, 07 Sep 2016 00:11:31 GMT timeout=5, max=999 Keep-Alive DENY GET caching 41823...

Останалата част от заглавката на отговора включва информация за отговора (напр. когато е генериран), сървъра и как очаква браузърът да обработи страницата (напр. X-Frame-Options: линията DENY казва на браузъра да не позволява тази страница да бъде вградена в друг сайт).

HTTP POST се прави, когато изпратите формуляр, съдържащ информация, която да бъде запазена на сървъра.

Заявката

Текстът по-долу показва HTTP заявката, направена, когато потребител изпрати нови подробности за профила на този сайт. Форматът на заявката е почти същият като примера за GET заявка, показан по-рано, въпреки че първият ред идентифицира тази заявка като POST.

POST /en-US/profiles/hamishwillee/edit HTTP/1.1 developer.mozilla.org keep-alive 432 no-cache no-cache https://developer.mozilla.org 1 Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit /537.36 (KHTML, като Gecko) Chrome/52.0.2743.116 Safari/537.36 application/x-www-form-urlencoded text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/* ;q=0.8 https://developer.mozilla.org/en-US/profiles/hamishwillee/edit gzip, deflate, br en-US,en;q=0.8,es;q=0.6 sessionid=6ynxs23n521lu21b1t136rhbv7ezngie; _gat=1; csrftoken=zIPUJsAZv6pcgCBJSCj1zU6pQZbfMUAT; dwf_section_edit=Невярно; dwf_sg_task_completion=Невярно; _ga=GA1.2.1688886003.1471911953; ffo=truecsrfmiddlewaretoken=zIPUJsAZv6pcgCBJSCj1zU6pQZbfMUAT&user-username=hamishwillee&user-fullname=Hamish+Willee&user-title=&user-organization=&user-location=Australia&user-locale=en-US&u ser-timezone= Австралия%2FМелбърн&user-irc_nickname=&user-interests=&user-expertise=&user-twitter_url=&user-stackoverflow_url=&user-linkedin_url=&user-mozillians_url=&user-facebook_url=

Основната разлика е, че URL адресът няма никакви параметри. Както можете да видите, информацията от формуляра е кодирана в тялото на заявката (например пълното име на новия потребител е зададено чрез: &user-fullname=Hamish+Willee).

Отговорът

Отговорът от заявката е показан по-долу. Кодът на състоянието на „302 Found“ казва на браузъра, че публикацията е успешна и че трябва да издаде втора HTTP заявка, за да зареди страницата, посочена в полето Location. В противен случай информацията е подобна на тази за отговора на GET заявка.

HTTP/1.1 302 НАМЕРЕНО Apache developer3.webapp.scl3.mozilla.com Cookie Accept-Encoding text/html; charset=utf-8 Wed, 07 Sep 2016 00:38:13 GMT https://developer.mozilla.org/en-US/profiles/hamishwillee timeout=5, max=1000 Keep-Alive DENY не може да се кешира; заявката не беше GET или HEAD 0

Забележка: HTTP отговорите и заявките, показани в тези примери, бяха уловени с помощта на приложението Fiddler, но можете да получите подобна информация с помощта на уеб снифери (напр. Websniffer) или анализатори на пакети като Wireshark. Можете да опитате това сами. Използвайте някой от свързаните инструменти и след това навигирайте през сайт и редактирайте информацията в профила, за да видите различните заявки и отговори. Повечето съвременни браузъри също имат инструменти, които наблюдават мрежовите заявки (например инструмента Network Monitor във Firefox).

Статичният сайт е този, който връща едно и също твърдо кодирано съдържание от сървъра, когато се поиска определен ресурс. Така например, ако имате страница за продукт на /static/myproduct1.html, същата тази страница ще бъде върната на всеки потребител. Ако добавите друг подобен продукт към вашия сайт, ще трябва да добавите друга страница (напр. myproduct2.html) и т.н. Това може да започне да става наистина неефективно - какво се случва, когато стигнете до хиляди страници с продукти? Бихте повторили много код на всяка страница (основния шаблон на страницата, структура и т.н.) и ако искате да промените нещо в структурата на страницата – като например добавяне на нова секция „свързани продукти“ например – тогава бихте трябва да промените всяка страница поотделно.

Забележка: Статичните сайтове са отлични, когато имате малък брой страници и искате да изпратите едно и също съдържание на всеки потребител. Те обаче могат да имат значителни разходи за поддръжка, тъй като броят на страниците става по-голям.

Нека обобщим как работи това, като погледнем отново диаграмата на статичната архитектура на сайта, която разгледахме в последната статия.

Когато потребител иска да навигира до страница, браузърът изпраща HTTP GET заявка, указваща URL адреса на неговата HTML страница. Сървърът извлича искания документ от своята файлова система и връща HTTP отговор, съдържащ документа и код на състоянието на HTTP отговор „200 OK“ (указващ успех). Сървърът може да върне различен код на състояние, например „404 Не е намерен“, ако файлът не присъства на сървъра, или „301 Преместен за постоянно“, ако файлът съществува, но е бил пренасочен към друго местоположение.

Сървърът за статичен сайт ще трябва да обработва само GET заявки, тъй като сървърът не съхранява никакви модифицируеми данни. Той също така не променя отговорите си въз основа на данни от HTTP заявка (напр. URL параметри или бисквитки).

Въпреки това разбирането как работят статичните сайтове е полезно, когато изучавате програмиране от страна на сървъра, тъй като динамичните сайтове обработват заявки за статични файлове (CSS, JavaScript, статични изображения и т.н.) по абсолютно същия начин.

Динамичен сайт е този, който може да генерира и връща съдържание въз основа на конкретния URL адрес на заявката и данни (вместо винаги да връща един и същ твърдо кодиран файл за определен URL адрес). Използвайки примера на продуктов сайт, сървърът ще съхранява „данни“ за продукта в база данни, а не в отделни HTML файлове. При получаване на HTTP GET заявка за продукт, сървърът определя идентификатора на продукта, извлича данните от базата данни и след това конструира HTML страницата за отговор чрез вмъкване на данните в HTML шаблон. Това има големи предимства пред статичен сайт:

Използването на база данни позволява информацията за продукта да се съхранява ефективно по лесно разширяем, модифицируем и търсещ начин.

Използването на HTML шаблони прави много лесно промяната на HTML структурата, защото това трябва да се направи само на едно място, в един шаблон, а не в потенциално хиляди статични страници.

Този раздел предоставя преглед стъпка по стъпка на „динамичния“ HTTP цикъл на заявка и отговор, надграждайки това, което разгледахме в последната статия с много повече подробности. За да „запазим нещата реални“, ще използваме контекста на уебсайт на мениджър на спортен отбор, където треньорът може да избере името на своя отбор и размера на отбора в HTML формуляр и да получи предложение за „най-добър състав“ за следващата си игра.

Диаграмата по-долу показва основните елементи на уебсайта на „треньор на отбор“, заедно с номерирани етикети за последователността от операции, когато треньорът има достъп до своя списък с „най-добри отбори“. Частите на сайта, които го правят динамичен, са уеб приложението (така ще наричаме кода от страна на сървъра, който обработва HTTP заявки и връща HTTP отговори), базата данни, която съдържа информация за играчи, отбори, треньори и техните връзки и HTML шаблони.

След като треньорът изпрати формуляра с името на отбора и броя на играчите, последователността на операциите е:

Уеб браузърът създава HTTP GET заявка към сървъра, като използва основния URL адрес за ресурса (/best) и кодира отбора и номера на играча или като URL параметри (напр. /best?team=my_team_name&show=11) или като част от шаблонът на URL (напр. /best/my_team_name/11/). Използва се GET заявка, защото заявката само извлича данни (не модифицира данни). Уеб сървърът открива, че заявката е „динамична“ и я препраща към уеб приложението за обработка (уеб сървърът определя как да обработва различни URL адреси въз основа на правила за съвпадение на шаблони, дефинирани в неговата конфигурация). Уеб приложението идентифицира, че намерението на заявката е да получи „списък с най-добри отбори“ въз основа на URL адреса (/най-добър/) и намира необходимото име на отбора и броя на играчите от URL адреса. След това уеб приложението получава необходимата информация от базата данни (използвайки допълнителни „вътрешни“ параметри, за да определи кои играчи са „най-добри“ и евентуално също така получава самоличността на влезлия треньор от бисквитка от страна на клиента). Уеб приложението динамично създава HTML страница, като поставя данните (от базата данни) в контейнери в HTML шаблон. Уеб приложението връща генерирания HTML към уеб браузъра (чрез уеб сървъра), заедно с HTTP код за състояние 200 („успех“). Ако нещо попречи на връщането на HTML, тогава уеб приложението ще върне друг код — например „404“, за да покаже, че екипът не съществува. След това уеб браузърът ще започне да обработва върнатия HTML, като изпраща отделни заявки за получаване на всички други CSS или JavaScript файлове, които препраща (вижте стъпка 7). Уеб сървърът зарежда статични файлове от файловата система и ги връща директно в браузъра (отново правилното обработване на файлове се основава на правила за конфигуриране и съвпадение на URL шаблони).

Операция за актуализиране на запис в базата данни ще бъде обработена по подобен начин , с изключение на това, че като всяка актуализация на база данни, HTTP заявката от браузъра трябва да бъде кодирана като POST заявка.

Работата на уеб приложението е да получава HTTP заявки и да връща HTTP отговори. Въпреки че взаимодействието с база данни за получаване или актуализиране на информация е много често срещана задача, кодът може да прави други неща едновременно или изобщо да не взаимодейства с база данни.

Добър пример за допълнителна задача, която уеб приложение може да изпълнява, е изпращането на имейл до потребителите, за да потвърдят регистрацията си в сайта. Сайтът може също така да извършва регистриране или други операции.

Кодът на уебсайта от страна на сървъра не трябва да връща HTML фрагменти/файлове в отговора. Вместо това може динамично да създава и връща други типове файлове (текст, PDF, CSV и т.н.) или дори данни (JSON, XML и т.н.).

Идеята за връщане на данни към уеб браузър, така че той да може динамично да актуализира собственото си съдържание (AJAX), съществува от доста време. Съвсем наскоро станаха популярни „приложения с една страница“, където целият уебсайт е написан с един HTML файл, който се актуализира динамично, когато е необходимо. Уебсайтовете, създадени с помощта на този стил на приложение, натоварват много изчислителни разходи от сървъра към уеб браузъра и могат да доведат до уебсайтове, които изглеждат да се държат много повече като естествени приложения (силно отзивчиви и т.н.).

Сървърните уеб рамки правят много по-лесно писането на код за обработка на операциите, описани по-горе.

Една от най-важните операции, които извършват, е предоставянето на прости механизми за съпоставяне на URL адреси за различни ресурси/страници към специфични манипулиращи функции. Това улеснява съхраняването на кода, свързан с всеки тип ресурс, отделно. Освен това има предимства по отношение на поддръжката, тъй като можете да промените URL адреса, използван за доставяне на определена функция, на едно място, без да се налага да променяте функцията за обработка.

Например, разгледайте следния код на Django (Python), който съпоставя два URL шаблона с две функции за изглед. Първият модел гарантира, че HTTP заявка с URL адрес на ресурс /best ще бъде предадена на функция с име index() в модула за изгледи. Заявка, която има модела "/best/junior", вместо това ще бъде предадена на функцията за изглед junior().

от django.conf.urls импортиране на urlfrom. import viewsurlpatterns = [url(r'^$', views.index),url(r'^junior/$', views.junior),]

Забележка: Първите параметри във функциите url() може да изглеждат малко странно (напр. r'^junior/$'), защото използват техника за съвпадение на шаблони, наречена "регулярни изрази" (RegEx или RE). Не е нужно да знаете как работят регулярните изрази на този етап, освен че ни позволяват да съпоставяме шаблони в URL адреса (вместо твърдо кодираните стойности по-горе) и да ги използваме като параметри в нашите функции за преглед. Като пример, един наистина прост RegEx може да каже "съвпада с една главна буква, последвана от между 4 и 7 малки букви."

Уеб рамката също улеснява извличането на информация от базата данни с функция за изглед. Структурата на нашите данни е дефинирана в модели, които са класове на Python, които дефинират полетата, които да се съхраняват в основната база данни. Ако имаме модел с име Team с поле "team_type", тогава можем да използваме прост синтаксис на заявка, за да върнем всички екипи, които имат определен тип.

Примерът по-долу получава списък на всички отбори, които имат точния (чувствителен към малки и главни букви) team_type на „junior“ — обърнете внимание на формата: име на полето (team_type), последвано от двойна долна черта, и след това типа съвпадение, което да използвате (в точно в този случай). Има много други видове съвпадения и можем да ги веригираме. Можем също да контролираме реда и броя на върнатите резултати.

от django.shortcuts import renderfrom .models import Teamdef junior(request):list_teams = Team.objects.filter(team_type__exact="junior")context = {'list': list_teams}return render(request, 'best/index.html' , контекст)

След като функцията junior() получи списъка с младши отбори, тя извиква функцията render(), като предава оригиналния HttpRequest, HTML шаблон и обект „контекст“, определящ информацията, която трябва да бъде включена в шаблон. Функцията Therender() е удобна функция, която генерира HTML с помощта на контекст и HTML шаблон и го връща в обект HttpResponse.

Очевидно уеб рамките могат да ви помогнат с много други задачи. Обсъждаме много повече предимства и някои популярни възможности за избор на уеб рамка в следващата статия.

На този етап трябва да имате добър преглед на операциите, които кодът от страната на сървъра трябва да изпълнява, и да знаете някои от начините, по които уеб рамката от страна на сървъра може да направи това по-лесно.

В следващия модул ще ви помогнем да изберете най-добрата уеб рамка за вашия първи сайт.