Web技術的發展 網絡發展簡介(三)


在上一篇文章中,對TCP/IP通信協議進行了簡單的介紹
通信協議是通信的理論基石,計算機、操作系統以及各種網絡設備對通信的支持是計算機網絡通信的物質基礎
而web服務則是運行於應用層,借助於應用層的協議,建立了客戶端與服務器,對等層之間的聯系,底層的硬件以及軟件為其提供服務。
本文對web發展架構進行簡單介紹,並且對web開發技術進行簡單介紹,不是要介紹細節,而是要展示一個宏觀的概念。

WEB架構起源

80年代中期ARPANET才逐漸開始進入民用
20世紀90年代之前,因特網的主要使用者還是研究人員、學者和大學生
他們登錄遠程主機,在本地主機和遠程主機之間傳輸文件,收發新聞,收發電子郵件等,但是因特網基本上不為學術界和研究界之外所知。
此時,計算機網絡通信的底層技術已經相對比較成熟,一個叫做Tim的人,開始嘗試建立互聯世界的文檔
其實他並不是第一個有這個想法的人,但是在此之前,鑒於計算機科學技術的發展限制,都並沒有成功
 
1989 CERN (歐洲粒子物理研究所)中由 Tim Berners-Lee 領導的小組
提交了一個針對Internet的新協議和一個使用該協議的文檔系統
該小組將這個新系統命名為 Word Wide Web ,它的目的在於使全球的科學家能夠利用Internet交流自己的工作文檔。
這個新系統被設計為允許Internet上任意一個用戶都可以從許多文檔服務計算機的數據庫中搜索和獲取文檔。
1990年末,這個新系統的基本框架已經在CERN中的一台計算機中開發出來並實現了
1991年該系統移植到了其他計算機平台,並正式發布。
1989年,Tim提出Web計划,1991年正式發布,速度真的好快。
HTML, HTTP, URI,瀏覽器,web服務器,就此發明問世
 
Word Wide Web又被稱為“Web”、“WWW”、“W3”,中文名字為“萬維網”,"環球網"等,常簡稱為Web
萬維網並不等同互聯網,萬維網只是互聯網所能提供的服務其中之一,是靠着互聯網運行的一項服務。
所有連接到網絡上的計算機,通過運行的web服務器程序,提供給內容的所有內容、服務,才是我們說的萬維網
分為Web客戶端和Web服務器程序, WWW可以讓Web客戶端(常用瀏覽器)訪問瀏覽Web服務器上的頁面。
計算機網絡的互連,讓全世界各地的計算機能夠進行通信
而web則讓全世界各地的計算機能夠進行超文本文檔的共享,完成了計算機網絡內容的互連
web的發明,讓互聯網開始爆炸式增長
Web的起源某種程度上可以認為是“一蹴而就”的(我加引號了),不過前提是計算機網絡已經發展到了一定階段,具備了先決條件,而且已經累積了很多計算機科學方面的理論
Tim搭建了web的雛形,設計了web的架構,是BS結構的始祖。
 
web的基本核心就是內容的共享
比如,你問你的語文老師,XXX的作者是誰。
  • 你就是請求發起者,語文老師就是請求應答者;
  • 問題就是資源的標識符;
  • 而你通過語言表達出來,普通話就是協議;
  • 而作者到底是誰,則是被請求的內容;
  • 而內容也有表示形式,比如說出來?寫在紙上交給你?則是超文本格式;
image_5c35493c_462b
BS形式共享超文本文檔的架構方案,定義了瀏覽器客戶端和服務器程序是兩個通訊主體,雙方通過HTTP協議進行對話,通過URI進行資源定位,消息通過HMTL格式化。

web核心組成

  • URI 解決了文檔的命名和尋址識別問題
  • HTTP解決了瀏覽器與服務器應用層之間的交流問題
  • HTML 定義了超文本文檔的表示
  • 瀏覽器用於發起請求,並且解析文檔
  • 服務器用於保存文檔

URI

統一資源標識符(Uniform Resource Identifier,或URI)
URI 采用一種特定語法標識一個資源的字符串,所標識的資源可能是服務器上的一個文件,也可能是一個郵件地址、新聞消息、圖書、人名、互聯網上的主機或者任何其它內容。 
重點在於唯一標識
URI有兩種形式,URL和URN
image_5c35493c_46e2
URL是Uniform Resource Locator的縮寫,譯為“統一資源定位符”
URL的格式由下列三部分組成:
  1. 協議(或稱為服務方式);
  2. 存有該資源的主機名稱(域名)或者IP地址(有時也包括端口號);
  3. 主機資源的具體地址,如目錄和文件名等;
URN是統一資源名稱 (Uniform Resource Name, URN)
URN它命名資源但不指定如何定位資源
 
URI描述了這么一個東西:可以用來唯一標識一個資源,URL和URN是他的兩種具體形式
所以一個URI可能是一個URL,也可能是一個URN,或者二者兼具。
但是任何一個URL或者URN他們肯定都是URI
 
比如,“阿里巴巴馬雲”當你聽到這個名字的時候,你不知道他是誰嗎?這就是唯一標識一個資源URN
但是馬雲在哪里?電話號碼多少?你是不知道的,雖然“馬雲”兩個字可以唯一標識他本人,但是你聯系不上他
如果你有了他家的地址呢?XXX小區XXX號,你就可以定位馬雲的位置了,這就是URL
不管是“阿里巴巴馬雲”還是馬雲家的地址XXX小區XXX號,他們都是URI

HTTP協議

設計HTTP最初的目的是為了提供 一種發布和接收HTML頁面的方法
最早版本是1991年發布的0.9版。該版本極其簡單,只有一個命令GET。
GET /index.html
表示,TCP 連接(connection)建立后,客戶端向服務器請求(request)網頁index.html。
協議規定,服務器只能回應HTML格式的字符串,不能回應別的格式。
HTTP協議就是瀏覽器與web服務器兩個應用之間通信的“協議”“語言”
計算機不能像人類一樣溝通,他只是0,1的世界,想要交流就必須制定通信的格式,而這個HTTP協議就是瀏覽器與Web服務器的溝通方式 
這就是它的根本,如同你對別人豎大拇指表示稱贊,服務器看到GET方法就會返回數據,這就是瀏覽器與服務器溝通交流的方式。
換句話說,人類用語言和文字進行溝通,CS世界中的各種協議,都是計算機的溝通方式。

HTML

HTML超文本標記語言,標准通用標記語言下的一個應用
標准通用標記語言(簡稱“通用標言”),是一種定義電子文檔結構和描述其內容的國際標准語言;
早在萬維網發明之前“通用標言”就已存在,HTML也是由他發展演變而來,
可以簡單理解為一種借助於標記符格式化電子文檔的語言 ,平時的書寫中你可以換行,可以設置標題、段落,但是在電子文檔中如何表達?
計算機不能像人類一樣用眼分辨,用腦思考,想要說明這是一個標題,你必須顯式的告訴他
標記語言就是一種非常合適的解決方案
比如HTML中的"<h1>這是個標題</h1>",h1是標簽,標簽中的內容就是標題,我們使用h1來標志這是一個一級標題,當計算機程序解讀到<h1>時,就可以意識到這是個標題
 
超級文本標記語言是萬維網(Web)編程的基礎,也就是說萬維網是建立在超文本基礎之上的。
超級文本標記語言之所以稱為超文本標記語言,是因為文本中包含了所謂“超級鏈接”點
之所以沒有直接使用通用標記語言,是因為他過於復雜,HTML是簡化的變種。
 
需要注意,電子文檔的出現遠比web起源要早
電子文檔的最初動機就是“將書稿、文件塞到計算機中”,一份文件,有內容也有格式(文字字體,大小,間距等)
電子化的目的是通過計算機呈現,所以電子化不僅僅需要記錄文件的內容,還需要記錄內容的格式(樣式),你講兩行字之間空白多一點,行間距就大一點,在計算機中如何呈現?
HTML就是標記語言的一種應用,他也只是一種電子文檔。

瀏覽器

瀏覽器就是一個應用軟件,他可以通過HTTP協議與服務器進行交互
根本功能也很簡單,發送HTTP請求,解析顯式獲得的響應數據
 
1991年,世界上第一個瀏覽器World Wide Web(后改名為Nexus)由Tim Berners-Lee創建於歐洲核子物理實驗室
同時他還寫了第一個網頁服務器httpd
這個瀏覽器並不支持圖片的顯示
1993年,伊利諾伊大學厄巴納-香檳分校的NCSA組織發表NCSA Mosaic,簡稱Mosaic
是互聯網歷史上第一個獲普遍使用和能夠顯示圖片的網頁瀏覽器
並於1997年1月7日正式終止開發和支持
Mosaic發布后,到底怎么分辨你的瀏覽器是否支持顯示圖片呢?UserAgent就是在這樣的場景下誕生了
Mosaic將自己標志為NCSA_Mosaic/2.0(windows 3.1)
這也是我們使用瀏覽器發送請求的時候請求頭有一個字段為UserAgent的最開始原因
著名的瀏覽器如下,國內的瀏覽器廠商都是用國外的瀏覽器內核
瀏覽器發展歷史:
1991 www(nexus)
1993 Mosaic
1994 Netscape
1996 IE
1996 Opera
2003 safari
2004 firefox
2008 chrome
 
有一篇很有意思的文章, 可以一看
http://www.cnblogs.com/ifantastic/p/3481231.html
https://webaim.org/blog/user-agent-string-history/
 
chrome可以通過在瀏覽器地址欄輸入“about:version”查看UA信息
還可以通過網站查看:http://www.useragentstring.com/
image_5c35493c_3798

服務器

Web服務器是可以向發出請求的瀏覽器提供文檔的程序,也是一種軟件。
遵循HTTP協議,接受瀏覽器客戶端發起的請求,並按照HTTP協議的規定響應的一種軟件。
現在也把提供web服務的專用計算機叫做web服務器,提供web服務的程序叫做web容器。
https://en.wikipedia.org/wiki/Web_server中有關於web server的介紹
還可以通過:https://w3techs.com/technologies/overview/web_server/all  查看目前各大web Server的使用率  
image_5c35493c_1198
現代的web 容器都是強大而復雜的,但是根本是相同的,那就是接受HTTP請求,並且按照HTTP協議進行響應。

WEB周邊組件-域名與DNS

域名(Domain Name),簡稱域名、網域
是由一串用點分隔的名字組成的,表示Internet上某一台計算機或計算機組的名稱
用於在數據傳輸時標識計算機的位置
我們知道計算機在網絡中的通信需要借助於ip地址,但是ip地址即使是點分十進制,依然難以記憶
域名就是為了簡化記憶,更加便於使用
簡言之,域名等於一個ip的名字
如果每個ip相當於電話號碼,那么域名就是姓名
image_5c35493c_311f
姓名和號碼之間必然是要有映射關系
早期,網絡上計算機個數很少
將對應關系保存在一個共享的靜態文件hosts中即可,再由hosts文件來實現網絡中域名的管理
也就是說,大家通過共享這個文件來完成ip與域名的映射,這個hosts文件就是域名IP的解析器
但是隨着網絡上計算機的增多,顯然不能將所有的域名與ip地址的對應關系都記錄在文件中
所以出現了DNS(Domain Name System),為了解決互聯網上域名與IP地址的映射解析
 
百度百科:“域名解析服務,最早於1983年由保羅·莫卡派喬斯發明;
原始的技術規范在882號因特網標准草案(RFC 882)中發布。
1987年發布的第1034和1035號草案修正了DNS技術規范,並廢除了之前的第882和883號草案。
在此之后對因特網標准草案的修改基本上沒有涉及到DNS技術規范部分的改動。
 
現在的操作系統中仍舊保留hosts這一文件,只不過不再是全網的了,已經有專門的DNS了
image_5c35493c_742a
 
域名采用樹狀的層級結構,任何一個連接在互聯網上的主機和路由器,都有一個唯一的層次結構名字,也就是域名
這里的域(domain)是名字空間中的一個可被管理的划分。域還可以划分為子域,而子域還可以繼續被划分為子域
這就形成了子域,二級域,三級域...
每個域名都由一個標號構成,標號之間使用小數點分割,如下圖所示
image_5c35493c_793
可以認為,將域名空間按照頂級域名進行划分,形成了域名的基本格局,就像“四大洋,七大洲”
也可以理解成國家行政區域的划分。
中國
江蘇.中國
南京.江蘇.中國
所以要深入理解域的概念,頂級域的並集就是全部的域空間
比如說,全世界共有XXX個國家和地區,那么,就是只有那么多個國家和地區
任何一個域名,都是一個頂級域名的子域,頂級域的划分,完成了域名空間的頂層管理
DNS規定, 每一個標號不允許超過63個字符,也不區分大小寫 ,標號中除了使用連字符外不能使用其他的標點符號
級別最低的標號位於域名最左邊,級別最高的頂級域名位於域名最右邊
既不規定每一個域名需要有多少個下級域名
也不固定每一級的域名代表什么意思
各級域名由他的上級域名管理機構進行管理
最高的頂級域名由ICANN進行管理
葉子節點指向物理機器
image_5c35493c_3367  

DNS解析過程

上面介紹的域名體系是邏輯上的,DNS服務器的運行按照“區”來進行划分
域名的體系結構按照“域”來划分,服務器實際的查詢解析,則是按照“區”,
簡言之,邏輯上就相當於按照行政區域划分,實際管轄上則是分片區管理
區可能小於或者等於一個域,但是肯定不會大於域
一個區中所有的節點必須是聯通的,每一個區設置相應的 權限域名服務器(authoritative name server), 用來保存該區中所有的域名與IP地址的映射
image_5c35493c_4ab0

域名服務器分類

根域名服務器
最高層次的域名服務器,最重要的域名服務器,所有的根域名服務器都知道所有的頂級域名服務器的域名和IP地址
如果所有的根域名服務器掛掉,整個互聯網將會癱瘓
頂級域名服務器
管理在該頂級域名服務器注冊的所有的二級域名,收到請求后,給出響應(要么直接返回結果,要么給出下一步應該查詢的域名服務器的IP地址)
權限域名服務器
負責一個區的域名服務器
如果一個權限域名服務器不能給出最后的查詢結果,會通知發出請求的DNS客戶,下一步應該找哪個權限域名服務器
本地域名服務器
本地域名服務器不是域名管理層次中的一環,主要作用是為了高效節能
每個互聯網ISP ,每個大學、機構都可以有一個本地域名服務器
windows中關於DNS的設置就是本地域名服務器,也叫做默認域名服務器
image_5c35493c_db8  

查詢方式

查詢方式共有兩種:迭代查詢,遞歸查詢
image_5c35493c_5e68
迭代查詢-->我不知道你找XXX去,一直踢皮球
遞歸查詢-->我去幫你查,一直很仗義
主機向本地域名服務器的查詢一般都是采用遞歸查詢
本地域名服務器向根域名服務器的查詢通常是采用迭代查詢
 
簡單理解就是域名邏輯上是樹形的層級結構,按照域進行划分
DNS域名服務器按照區進行划分,每個區小於等於一個域,對域進行分片管理
DNS的域名服務器就是與域名層次等級結構相對應的一個服務器結構體系  

WEB技術發展

最初,所有Web頁面都是靜態的
用戶請求一個資源,服務再返回這個資源,在瀏覽器中主要展現的是靜態的文本或圖像信息。
GIF圖片則第一次為HTML頁面引入了動態元素
這些網站的Web頁面只是電子形式的文本,內容生成之后就是固定不變的,然后發布到多處
image_5c35493c_41ac
在瀏覽器發展的最初階段,Web頁面的這種靜態性不成問題,科學家只是使用Internet來交換研究論文,大學院校也只是通過Internet在線發布課程信息等
隨着網頁從學術機構走向公眾社會,網頁承載的功能便超出了學術范圍而變得愈加豐富,因此早期網頁的局限性也逐漸顯露出來
學術自然是枯燥的,走向社會就不一樣了,娛樂生活等等,所以用戶自然對web能提供的服務有了更多的需求(期望),這是一個很自然的需求演變

CGI

人們當然不滿足於訪問web服務器上的靜態資源
1993年CGI(Common Gateway Interface)出現了
CGI定義了Web服務器與外部應用程序之間的通信接口標准,Web服務器可以通過CGI執行外部程序,讓外部程序根據Web請求內容生成動態的內容。
通常的處理流程是:
  1. 通過Internet把用戶請求送到web服務器。
  2. web服務器接收用戶請求並交給CGI程序處理。
  3. CGI程序把處理結果傳送給web服務器。
  4. web服務器把結果送回到用戶。 
image_5c35493d_6fd1
服務器在認為這是一個CGI請求時
會調用相關CGI程序,並通過環境變量和標准輸出將數據傳送給CGI程序
CGI程序處理完數據,生成html,然后再通過標准輸出將內容返回給服務器,服務器再將內容交給用戶,CGI進程退出
在這個過程中,服務器的標准輸出對應了CGI程序的標准輸入,CGI程序的標准輸出對應着服務器的標准輸入。
可以理解為,請求轉變為了CGI程序的參數(以環境變量的形式傳遞),CGI的輸出變成了web服務器的響應(CGI程序中直接向標准輸出打印HTML頁面)
 
CGI是一種標准,並不限定語言。所以Java、PHP、Python都可以通過這種方式來生成動態網頁。
它規定了web服務器向CGI程序發送數據的格式約定(比如環境變量中有哪些值),以及響應的約定等內容(生成HTML頁面)。
 
為什么使用CGI接口,而不是直接web服務器就提供這些功能?
如果web服務器提供這些功能,必然會導致web服務器的設計與開發過於復雜
而且,一旦web服務器實現了這些功能,開發者勢必要按照web服務器提供的技術框架基礎下進行開發,大大限制了生產力
所以借助於CGI接口,即能夠提供調用外部程序處理的能力,也將這些功能從web服務器中解耦,解放了生產力。
 
可想而知,有了CGI,web發生了多大的變化
不僅僅可以提供靜態的資源了,還能夠進行動態的處理,數據的計算等

但是,每當一個CGI請求過來時,web服務器會fork一個子進程來執行相應的CGI程序,當請求結束時,該CGI進程也隨之結束
這樣不停fork進程的開銷是非常大的,這是造成CGI程序效率低下的主要原因
后來出現了fastcgi,是改良版的CGI
而且,試想一下,當你要用C語言或者C++等等去一點點的處理html的內容,去拼接,去打印,是不是很辛苦?

char MimeType[]="text/html";

fprintf(stdout, "Content-type: %s\r\n\r\n", MimeType); //輸出響應頭,響應頭之后要加兩個"\r\n"

fprintf(stdout, "<html><head><title>這是一個CGI小程序</title></head>\n");

fprintf(stdout, "<body>這是一個由C編寫的CGI小程序</body></html>\n");

做過js拼接的就可以理解,但是很顯然,之前的CGI比你做過的js的拼接還要惡心  

web編程腳本語言

人們發現,對於一個HTML頁面,往往發生變化的只是很少一部分數據,很大一部分仍舊是靜態的
比如一個只有一個頁面訪問計數器的頁面,唯一動態的數據就是那個“計數”,整個的頁面的其他部分都是靜態的。
是不是可以將不變的部分與變化的部分進行解耦呢?
於是又進化出后來的web編程腳本語言
PHP於1994年由Rasmus Lerdorf創建,剛剛開始是Rasmus Lerdorf為了要維護個人網頁而制作的一個簡單的用Perl語言編寫的程序。
這些工具程序用來顯示 Rasmus Lerdorf 的個人履歷,以及統計網頁流量。
后來又用C語言重新編寫,包括可以訪問數據庫。
他將這些程序和一些表單直譯器整合起來,稱為 PHP/FI,也就是說 最初是C語言編寫的CGI程序的封裝集成整合
PHP實現了與數據庫的交互以及用於生產動態頁面的模板引擎
PHP可以把程序(動態內容)嵌入到HTML(模版)中去執行,不僅能更好的組織Web應用的內容,而且執行效率比CGI還更高
之后96年出現的ASP和98年出現的JSP本質上也都可以看成是一種支持某種腳本語言編程(分別是VB和Java)的模版引擎
web編程腳本語言是CGI的進一步演化與抽象,使CGI的開發使用更加高效易用,核心思想還是CGI
有了這些腳本語言,搭配上后端的數據庫技術,Web的功能更加強勁,可以通過Web技術來構建幾乎所有的應用系統。
image_5c35493d_15c1  

企業開發平台

兩大重要陣營J2EE/.NET  
Sun公司在1998年發表JDK1.2版本的時候, 使用了新名稱Java 2 Platform,即“Java2平台”
修改后的JDK稱為Java 2 Platform Software Develping Kit,即J2SDK。
並分為標准版(Standard Edition,J2SE), 企業版(Enterprise Edition,J2EE),微型版(MicroEdition,J2ME)。J2EE便由此誕生。
 
當Web開始廣泛用於構建大型應用時,系統的穩定性安全性分布式等方面的要求變得更高
在許多企業級應用中,例如數據庫連接、郵件服務、事務處理等都是一些通用企業需求模塊
這些模塊如果每次在開發中都由開發人員來完成的話,將會造成開發周期長和代碼可靠性差等問題
於是許多大公司開發了自己的通用模塊服務,這些服務性的軟件系列統稱為中間件 
J2EE就是使用Java語言,開發企業級web應用的一整套的解決方案
Java Servlet、Java Server Pages (JSP)和Enterprise Java Bean (EJB )是Java EE中的核心規范
Servlet和JSP是運行在服務器端的Web組件
讓Java開發者同時擁有了類似CGI程序的集中處理功能和類似PHP的HTML嵌入功能
此外,Java的運行時編譯技術也大大提高了Servlet和JSP的執行效率
 
Sun正式發布了J2EE版本后,緊接着,遵循J2EE標准,為企業級應用提供支撐平台的各類應用服務軟件爭先恐后地涌現了出來。 
IBM的WebSphere、BEA的WebLogic都是這一領域里最為成功的商業軟件平台。
簡言之,Java本身的跨平台性非常適合web應用開發,Java也抓住了這一機遇,提供了企業級應用一整套的開發方案。

框架的百家爭鳴時代

隨者兩大平台的誕生,web的技術發展趨於成熟與穩定,人們希望能夠更好更快更高效的開發web
各種輔助web開發的技術,百花齊放,百家爭鳴
web應用越來越復雜,各種功能的頁面,各種各樣的URL地址,大量的后台數據 
MVC的概念被引入到web項目中來,出現了Structs   Spring MVC等
控制器Controller負責響應請求,協調Model和View
Model,View和Controller的分開,是一種典型的關注點分離的思想,
不僅使得代碼復用性和組織性更好,使得Web應用的配置性和靈活性更好。
 
此時,數據的訪問也不僅僅是直接sql訪問,出現了ORM(Object Relation Mapping)的概念
2001年出現的Hibernate就是其中的佼佼者
更多的全棧框架開始出現,比如2003年出現的Java開發框架Spring
同時更多的動態語言也被加入到Web編程語言的陣營中
2004年出現的Ruby開發框架Rails,2005出現的Python開發框架Django
都提供了全棧開發框架,或者自身提供Web開發的各種組件,或者可以方便的集成各種組件。

前端技術發展

JavaScript

隨着web服務器的發展,在能夠進行動態數據的處理之后,涌現出來了新的問題。
服務器負責表單的一些校驗工作
看起來好像沒什么,但是站在當時的環境下,在那個絕大多數用戶都在使用調制解調器上網的時代,網絡是很低速的
用戶填寫完一個表單點擊提交,需要很多秒,才能得到服務器的反饋
然而最后完了服務器反饋給你說某個地方填錯了......你是不是會崩潰?
人們希望是否可以在客戶端進行這些基礎校驗工作,這就是Js誕生的背景
JavaScript誕生於1995年,前身是livescript
最開始是由瀏覽器廠商Netscape(網景)着手開發的,起初這是一種“自導自演”的語言。
你可以這么理解,瀏覽器是我自己開發的一個軟件,我為了實現某種功能定義了一些規范條件語法,創造了一種語言
比如我說在我這個軟件內var可以定義一個變量,我的這個軟件就認識這個var,別人家的瀏覽器其實是不認識的
我自己的軟件,可以解釋我自定義的語言
就好比你定義了一個XML文件的格式,然后你編寫相應的方法用於解析XML,是類似的邏輯
 
當然,瀏覽器不止一家,出現了這么一個好東西,大家就會都去搞,撕逼大戰熱火朝天
最終出來機構調節停火,也就是出台了 ECMAScript這是一個 規范
由ECMA-262定義的ECMAScript其實與Web瀏覽器沒有依賴關系,Web瀏覽器只是ECMAScript實現可能的宿主環境之一
 
JavaScript是一個ECMAScript規范的實現,就好像HotSpot遵循java虛擬機規范一樣
完整的js實現包括
1.核心(ECMAScript)
2.文檔對象模型(DOM)
3.瀏覽器對象模型(BOM)

CSS

另外由於項目應用規模的不斷擴大,頁面也越來越越復雜,你會發現,將樣式與模板放到一個頁面上
是一個非常糟糕的設計思路
1996年12月W3C推出了CSS規范的第一個版本
CSS(Cascading Style Sheets,層疊樣式表)是一種將表示樣式應用到標記的系統
CSS以設計、改變其HTML頁面的樣式而知名,並使用於Web和其他媒介,如XML文檔中
CSS依附於HTML的結構對其樣式進行渲染

AJAX/前端框架/Node

而對於瀏覽器端,除了前面提到的js  css
在98年還出現了AJAX,05年之后大放異彩
一個頁面上,有絕大多數的數據是固定不變的,所以演變出模板的形式,動態的渲染數據
然而,在很多時候,也並不是頁面上的數據全部都需要變化,可能需要變化的僅僅只有很細微的一個地方
但是,哪怕你僅僅需要變動的是一個數字而已,也仍舊需要重新載入整個頁面,這顯然是資源的浪費,以及沒必要的等待
ajax就是為了解決這個問題的而出現的一種局部刷新的技術
AJAX即“Asynchronous JavaScript and XML”(異步的JavaScript與XML技術)
指的是一套綜合了多項技術的瀏覽器端網頁開發技術
可以基於JavaScript的XmlHttpRequest的用於創建交互性更強​的Web應用。
 
ajax的出現,可以讓前后端工程師以ajax接口為分界點進行前后端分離
規定好交互接口后,前后端工程師就可以根據約定,分頭開工
開發環境中通過Mock等方式進行測試,同時在特定時間節點進行前后端集成測試。
但是,隨着業務功能的愈發復雜
這種模式本質上和JSP時代的Web開發並無本質區別,只不過是將復雜的業務邏輯從JSP文件轉移到了JavaScript文件中而已。
所以很自然的又把MVC模式應用到了前端
前端開發也出現了大量的MVC框架
比較典型的包括BackboneJS, AngularJS, EmberJS, KnockoutJS。
 
隨着各大瀏覽器的競爭,引擎越來越牛逼
Google V8引擎的性能已經足以運行大型Javascript程序
在V8之上加以網絡、文件系統等內置模塊,形成了如今的Node.js
隨着Node.js的出現,JavaScript開始擁有在服務端運行的能力
它的異步本質使得Node.js在處理I/O密集型業務中優勢凸顯
而大多Web業務中I/O性能都是瓶頸
 
關於網絡的演變,可以查看 http://www.evolutionoftheweb.com/ 圖形化的展示了演進過程。

總結

以上可以看得出來,WEB的發展從提出一直都是在迅猛發展,WEB架構的核心思想一直都沒有變化過:BS結構瀏覽器和服務器,通過HTTP協議交互,借助於URL進行資源定位,最終獲取響應,而響應的內容則是HTML。
盡管WEB的規模在不斷的變化,甚至可以說與日俱增的變化,核心是沒有變化的
而WEB變化的方向也可以說是非常明確的,那就是工作的精細化拆分,不斷地分工,不斷地分工。
最開始需要動態處理的能力,所以借助於CGI程序,將處理能力外包;
項目不斷擴大,所以按照功能進行拆分引入MVC模式;
引入模式后為了更便於開發維護,又出現了各種框架簡化開發;
靜態的模板內容和動態的數據內容相互耦合,所以進行分離;
模板與樣式相互偶爾交織在一起,所以HTML結構與樣式分離;
動態能力全部位於服務器所以出現了JS使客戶端具有處理能力;
同步的處理數據量太大卻有時又沒有必要,所以出現了AJAX;
請求太多,一台服務器無法處理,所以出現了負載均衡;
一個數據庫數據量太大,所以開始分庫分表;
應用體量太大,所以將應用服務本身進行拆分,出現了分布式;
等等................................
可以看得出來,整個WEB項目發展基調如此:
活范圍太寬,事兒太多怎么辦?拆分、解耦!!!
活還是太多了干不完,咋整?分工!!!
分工、解耦、拆分、分工、解耦,拆分、水平拆分、垂直拆分、各種拆分.........  


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM