建站有不少技術，如 HTML、HTML五、XHTML、CSS、SQL、JavaScript、PHP、http://ASP.NET、Web Services、瀏覽器腳本、服務器腳本等。它們的區別是什麼？

先普及用戶經過 瀏覽器 訪問網頁 的過程：

　　網頁內容是經過服務器運算得出的結果，將結果(網頁代碼)傳輸給瀏覽器，網頁代碼再經過瀏覽器運算(計算、渲染)，最終展現在用戶的眼前的。

　　至此，咱們知道了有2個運算過程：

　　一、服務器運算

　　二、瀏覽器運算

　　而讓電腦(網站服務器、你的我的電腦)乖乖執行運算，就須要編寫程序腳本即程序代碼。

　　而編寫代碼的過程就叫作：編程。編寫代碼的人叫作：程序員(又戲稱：程序猿、攻城獅)。

　　因此，由運算演變出：

　　一、服務器運算 -> 服務器腳本

　　二、瀏覽器運算 -> 瀏覽器腳本

　　在行業內，將 服務器運算 稱爲 後端；將瀏覽器運算 稱爲 前端；

　　後端更靠近服務器，前段更靠近用戶，這樣比較好記憶。

如下是我近期在學習瞭解網站開發結構時的一份記錄，看到本題就想貼出來，供你們一塊兒參考和糾錯，至於文筆和格式，就不要太關注了...畢竟只是一份簡單的記錄。

　　本文原文連接：網站開發從陌生到了解

　　正文：

　　內容說明本記錄描述本人瞭解網站開發的心路歷程。

　　只記錄我的對於網站知識結構的理解認知，還未涉及開發的具體知識。

　　本記錄沒法告訴你如何去作網站開發，可是或許能夠告訴你要作網站開發都須要作什麼事。

　　本記錄內容爲三不產品：

　　不完整：僅記錄我當前的知道的內容；不許確：僅記錄我對於當前知道的內容的理解，不能保證正確；不詳細：及時是我可以正確理解的內容，也不能保證詳細的描述。本記錄的目的：

　　記錄：記錄和整理我認知網站知識的過程；完善：吸取專家對我記錄的內容的指正和詳細說明；互助：幫助小白（含本身）理解網站結構。適合的讀者本記錄適合對網站開發一竅不通的初學者認知網站基本結構和概念、學習網站開發如何入門，不適合對追求技術深度的大神。

　　本記錄初衷是我的學習記錄，如下是我的發牢騷的部分，沒興趣的能夠直接跳過：

　　----------------------------------------------------------------------------------------------------

　　背景

　　本記錄的起源，來自我想作一個小網站的念想，卻無奈本身悟性太差，參悟了幾年的web編程，面對大量知識點，依然無從下手。具體過程以下：

　　大量全新名詞在接觸網站開發之處，個人眼前首先面對的是大量的新名詞：

　　如JS、Html、JSP、Java、Tomcat、CSS、XML、servlet、PHP、CGI、框架、前端、服務器、http……

　　請忽略以上名詞的雜亂無章……由於這是此時個人腦海真實寫照……

　　雜亂網絡結構看着上面那一堆名詞，我實在無從下手，思考了大約1秒鐘，我決定先放棄具體知識的學習，轉而先搜索網站開發的結構體系，而後準備從體系中入手逐個技術點的學習，因而，我獲得如下開發結構體系：

　　LAMP組合拳、DIV+CSS+JS前端+JQuery技術、J2EE開發、各類模板組件……

　　甚至有些論壇直接就爲爭論哪一個語言好，就打起來了……

　　總之，看了這麼多建議，我內心一陣清涼，以爲原來那些零散的知識點，組合成了一個個巨無霸，更加難理解了……

　　迷茫中嘗試此時我不止一次懷疑過本身的智商，爲何網上的同胞們都那麼輕鬆的聊着那麼複雜的內容，而我卻連大家給個人某個技術的解釋的解釋的解釋都看不懂。

　　在這個迷茫階段，我選擇了不抵抗，決定先不去搞清每一個部分是作什麼用的，直接選擇人家設計好的架構，用就好了，原本設計那些架構就是爲了方便咱們的嘛。

　　因而，我架起了一個個不一樣的網站，看似一切良好，可是......這些網站全都停留在「hello world」的狀態！對於我本身的想法，徹底不知道怎麼去實現...

　　一怒入坑網絡大量信息對於像我同樣網絡開發白癡的如此「友好性」。

　　想簡單偷個懶直接使用現成架構，卻被本身的無知無情的戲謔。

　　一怒之下，我決定將全部名詞所有認識一遍，而後逐個歸類，本身概括出整個網絡開發結構。全面的瞭解作網站須要學哪部分知識，爲何須要這部分知識，要實現什麼功能須要什麼工具，使用工具時須要配置哪些內容等。

　　因而，就出現了下面這一堆誤人誤己的，自認爲是整個網絡開發結構認知的一篇記錄。

　　無論怎樣，有了如下或對或錯的認識，自我感受良好多了，心中的迷茫也少多了，感受本身的白癡級別下降了一級，心情也好多了。

　　如下是本篇記錄的正文，請根據以上背景，酌情考慮是否適合你觀看。

　　觀看本記錄出現的不良反應，本人概不負責。固然，若是對你產生了正面效果，我也不會打劫你。

　　正文：網站開發結構認知

　　網站，對於不少用戶而言，可能認爲眼前瀏覽器中的東西就是網站的所有。其實，那只是冰山一角。

　　———————————————————————————————————————————

　　跳過———————————————————————————————————————————

　　如下好像是正文：

　　網站基本結構首先，咱們來認識一下網站的結構，看看本身在什麼位置，看看咱們還不知道的冰山下層有什麼景象。

　　

　　

　　以上是一個最簡單的概念，用戶、前端和網站服務器三大部分，構成的網站最基本結構。

　　其中開發人員要關心的就是前端和網站服務器的相關開發。

　　固然，對用戶而言，其腦海中對前端的概念一般簡單的理解爲瀏覽器...

　　網站前端接下來，咱們來拆解一下前端開發的結構。前端經常使用的開發語言和運行環境以下表所示。

　　

　　

　　要知道前端是網站和用戶交互的主要接口，用戶不須要管服務器是否靠譜，只須要任性的要求前端給本身展現本身要的東西就好了。這些用戶要的東西就是有這幾種開發語言寫出來的。

　　HTML 超文本標記語言 1989一種文本、圖片、連接等多元素編輯語言。

　　經過這種語言以網站頁面爲編輯區域，任意指定頁面具備哪些元素，包括文字、圖片、多媒體等。

　　並任意指定不一樣元素在頁面的基本格式。如文字字體、大小、位置，圖片大小、位置，連接顏色、狀態變化等等。

　　這種語言利用標籤標記，將多種不一樣類別的元素、甚至不一樣位置的文件關聯在一塊兒，所以叫作超文本標記語言。

　　而且經過定義元素的屬性，設置元素的格式，最終造成總體頁面效果，這種語言能夠利用多種文本編輯工具編輯，例如記事本。只需擴展名修改成.html或.htm便可（這兩種擴展名不是簡單的縮寫關係，詳細本文不討論）造成HTML文件。

　　HTML5就是HTML語言的最新標準，這種標準制定使頁面能夠表現的內容更增強大（至於具體如何強大，我不知道，目前我只知道HTML5是用來定義頁面內容的就足夠了）。

　　好像HTML5標準相關的兩大的權威機構W3C和WHATWG之間對這個標準的細節肯定存在巨大分歧，W3C背後有微軟支持，而WHATWG背後有Mozilla、apple等公司的支持，這部分會涉及到網頁程序和原生APP之間的糾纏，太過複雜，本文就不細說了。

　　最初的HTML只含有較少的元素屬性，只能簡單規定元素的基本格式，隨着網站開發的發展，前端能夠展示的元素格式愈來愈豐富，代碼也愈來愈臃腫。所以逐漸造成了另外一種新的語言CSS，將HTML語言中描述各元素屬性的代碼從HTML文件中抽離出來，使HTML專門描述前端頁面具備什麼內容，CSS語言編寫的CSS文件專門描述HTML中的每一個元素以什麼格式在頁面展現。

　　css 層疊樣式表 1996

　　CSS專門用於描述HTML中各元素用什麼樣式展現。HTML+CSS組合完成頁面內容和格式的設計。

　　不少人喜歡使用HTML中的一種標籤格式來規定頁面內容，再利用CSS規定DIV標籤在頁面擺放格式造成頁面佈局，所以不少網站會提到DIV+CSS前端開發這個概念。

　　CSS主要實現了頁面內容的靜態佈局效果。雖然目前的CSS3標準的出現，使CSS強大到能夠實現不少元素動態變化效果。

　　可是，更復雜的動態變化仍是須要另外一種專門的語言來實現，這就是JS語言。

　　JavaScript 腳本語言 簡稱JS

　　js語言當前廣泛被用於網站開發前端編程，在html提供的內容和css提供的格式以外，由js提供更復雜的界面展現效果和邏輯處理。在此存在不少能夠直接使用的代碼庫，如jQuery等。

　　js語言能夠實現對頁面元素的複雜功能編程，例如頁面的時鐘數字變化效果，圖片的走馬燈輪換效果，粒子動畫效果等。

　　也就是咱們常常看到的炫目的頁面動畫基本都是js語言編寫的。

　　除了能夠看到的動態效果以外，js還能夠實現用戶看不到頁面數據處理工做。例如數據加解密、文字過濾分析等。

　　這些內容都須要編碼實現。

　　以上的html、css、js文件都會下載到用戶的終端設備（計算機、手機、平板燈）上，在用戶設備上被執行，所以，咱們稱它們在前端運行，這裏的「前」是與後臺服務器的「後」相對而言的。

　　腳本語言

　　上文提到js是一種腳本語言，此處插播一下腳本語言的概念。

　　腳本語言是一種逐句執行的直譯語言，也就是這種語言不須要提早編譯，直接由終端（如瀏覽器）解釋運行便可。

　　腳本語言與其餘編程語言的關鍵區別在因而否須要通過編譯連接造成二進制機器語言。

　　咱們知道，其餘編程語言完成程序編寫後，須要經過編譯器的工做，將程序代碼轉變成二進制形式，windows系統中一般是.exe文件，這種文件能夠直接在相應的操做系統中運行。

　　而腳本語言不須要編譯,寫完代碼保存文件以後，便可當即運行。要實現這種效果須要提早在須要運行該腳本文件的系統中安裝相應的腳本軟件。

　　以JS爲例,其腳本文件後綴爲.js，要運行該腳本文件，須要運行環境中安裝js軟件。

　　一般咱們的瀏覽器中已經集成了js解析標準，直接能夠解析js腳本文件，所以，js腳本語言一般被用做前端頁面特殊效果的編程語言。

　　固然,只要具備js的解釋環境(js軟件)就能夠運行js文件，所以js並非侷限於前端開發。隨着node.js等運行環境的出現，js語言逐漸適用於服務器端、客戶端等多種場景。

　　關於一種語言是否適合某種場景,這取決於這種語言的最主要的特性是否適合該場景最須要功能,屬於技術細節,本文不作分析.

　　同屬於腳本語言的還有,PHP/ASP/JSP/python/ruby/VBScript/Perl等.

　　--------------------------------迷茫的分割線--------------------------------------

　　到目前爲止，我好像理解了前端語言的概念（誰知道有多少錯誤），可是前端的本質對於用戶而言並非那麼友好，如下是構成前端內容的html代碼示例，css和js的代碼也相似。

　　

　　

　　就這種內容，我表示前端用戶徹底看不懂啊！

　　因而咱們就須要一個翻譯，給咱們解析一下這花花世界的各類html頁面說的都是些什麼東西。

　　所以，普通用戶要看到前端頁面內容和操做前端頁面都須要經過一個翻譯載體，即瀏覽器來實現。

　　瀏覽器

　　瀏覽器就是對HTML+CSS+JS文件內容進行翻譯，並容許用戶經過頁面與網站進行交互的一種軟件。

　　前面提到的那一堆前端名詞都是開發語言，是語言就具備統一的標準，所以，這些語言都有惟一的嚴格的標準文檔可查詢。

　　可是，瀏覽器就沒有嚴格規定了。只要實現了對以上前端語言的翻譯功能，就能夠成爲網頁瀏覽器。

　　所以也就產生了各類不一樣的內核，以及採用不一樣內核開發的瀏覽器。

　　雖然這些內核的目的都是爲了解析（翻譯）前端語言造成可視化頁面，可是因爲設計理念等細節的差別性，致使不一樣的內核體現出不一樣的特性，例若有的訪問速度快、有的擴展性強、有的大而全、有的小而美等等。

　　瀏覽器的開發團隊和內核的開發團隊不必定是一個團隊。

　　例如webkit、chromium等開源內核，其餘開發團隊或廠商在遵照開源規則的狀況下，能夠自由使用這些內核，進行二次開發，加上本身的外殼、標誌等，造成本身品牌的瀏覽器，因爲開發能力等緣由的差別性，而這些瀏覽器也不可避免的存在各自的優缺點，也就造成咱們選擇瀏覽器的理由。

　　當前主流的瀏覽器內核以下：

　　

　　

　　上表中僅列出部分產品，其中也存在多種雙內核產品，chromium源自Webkit，可是相對原版的Webkit產生了較大的「基因突變」，所以與Webkit並排列出。

　　表中包含了不少咱們平常使用的瀏覽器，也就是經過這些瀏覽器，對前端語言寫成的文件進行解析，在瀏覽器中以友好的可視頁面的形式展現給用戶。

　　此時就可能出現，頁面亂碼或錯誤等狀況，多是前端語言編寫錯誤，也多是瀏覽器內核對前端語言的解析出錯，固然也多是網站服務器端出現了問題。

　　在說服務器端的功能以前，插播幾個前端相關的小知識點：

　　xml/json

　　xml是可擴展標記語言,一般用於傳輸和儲存數據,類似的還有json.

　　前端和服務器之間一般須要一種雙方都承認的格式進行數據的傳遞和存儲。

　　.xml/json或其餘格式指定了數據內容的存儲格式,使用該數據的雙方只需按照規定的格式寫入/讀出內容便可完成數據的傳輸和存儲.

　　以json爲例,其基本格式爲：{標題：內容}，根據這個格式，後臺從json文件中讀出須要的內容，例如{我是標題：我是要被讀出的內容}，並按照這種格式發送給前端，前端經過js等語言對這些內容進行解析便可。

　　前端的一些配置信息，如用戶登陸名稱、性別、網頁底色等信息均可以暫存在xml/json文件中,根據須要隨時讀取.

　　服務器後臺也可將前端須要的數據內容，以xml/json的格式發送給前端，達到數據交互的目的。

　　AJAX  (Asynchronous Javascript And XML)  異步JavaScript和XML

　　這不是一個全新的技術,而是利用已有的js/css/xml等技術達到前端數據及時更新的效果.

　　對用戶而言，前端頁面的刷新就是點擊頁面刷新按鈕 或者F5實現頁面內容的刷新。

　　甚至有不少人不知道頁面刷新這個概念……

　　頁面刷新的目的是讓頁面重新從服務器獲取數據，一般是在頁面長時間未更新數據，至於多長時間算長，沒有定論，幾分鐘、半小時、n小時均可以說是長時間。

　　例如，門戶網站的新聞列表，可能1個小時以內，服務器後臺已增長了不少條新的新聞，前端能夠經過刷新，重新獲取最新的新聞展現在頁面上。

　　再如，網頁文字直播NBA籃球比賽，可能後臺服務器每幾秒就會有一條新的動態，須要用戶連續刷新頁面內容來獲取最新動態。

　　以上的刷新方法是用戶手動對整個頁面內容進行刷新，針對以上的需求，明顯是不合理的，AJAX就是實現了自動更新須要刷新的數據的效果。

　　其基本思路是前端js與後臺不斷通信,及時獲取前端某部分數據的變化信息,及時進行自動數據獲取更新,使用戶無需刷新網頁便可保持頁面數據最新的狀態。例如，球賽文字直播、股票實時信息等。

　　文檔對象模型（Document Object Model，簡稱DOM）

　　DOM是一種獨立的規範。

　　瀏覽器做爲前端的展現工具，按照DOM規範將頁面劃分爲不一樣層次結構，造成多個可操做的對象。例如,window對象、history對象、link對象等。

　　window對象就是用戶看到的頁面、history對象就是瀏覽歷史、link對象就是連接等。

　　例如彈出警告對話框的操做就能夠經過window對象實現。

　　按照這種規範便可直接經過編程操做html頁面的各類元素，控制其顯示/隱藏等效果。

　　js中也提供了符合該規範的api函數接口。經過js能夠動態操做頁面元素的狀態。

　　以上就是對前端的基本認識。有了以上的內容就能夠造成前端頁面了。我就奇怪了，既然這樣就能顯示頁面，要後臺幹什麼。

　　通過我「深刻」思考，終於明白，若是隻有前端，沒有後臺，你的頁面就像一份報紙、一本雜誌，內容是固定的，不會「更新」，除非你再買一本新的；有了後臺，就能夠給前端源源不斷輸送新鮮的內容，讓前端充滿活力。

　　通信協議

　　在講後臺以前，咱們要考慮一個問題，前端怎麼向後臺發送請求，總不會是「SOS」吧；後臺又如何相應請求並返還前端須要的內容。

　　這就須要雙方按照預先協商好的格式（咱們稱之爲協議，就好像接頭暗號同樣），發送數據內容。若是雙方不按照協議發送信息，則對方就沒法知道信息究竟是什麼內容，就沒法進行交流，俗稱「不按套路出牌」。

　　如下幾個概念介紹前端和服務器之間通信的相關知識點。

　　域名 （Domain） 和域名服務器 （DNS）

　　咱們訪問網頁時一般會在地址欄輸入相似論壇 - 與世界分享你的知識、經驗和看法這樣的網站地址（或者經過搜索跳轉），地址欄中的這種地址就是網站的域名，經過這個域名別人就能夠找到這個網站。

　　爲何須要域名話說一開始的時候，並無域名的概念，要連接到服務器，只須要知道服務器的IP地址就能夠了。例如，在地址欄直接輸入60.28.215.70就能夠直接訪問論壇網站了。

　　關於IP相關的網絡知識，內容太大，本文不深刻描述。

　　後來，網站愈來愈多，誰能記住這麼多沒有規律的IP地址啊，因而聰明愛折騰的人們發明了有規律有意義的域名。好比，http://www.qq.com,www.Lenovo.com.cn，這種內容比純數字就好記多了。

　　域名和IP地址是對應的，歸根結底，雖然咱們在瀏覽器輸入的是域名，也會經過相應手段解析成IP地址，進而肯定咱們要訪問的網頁在網絡中的位置。

　　畢竟，雖然咱們認識域名，可是計算機認識的確是IP地址。

　　那麼，咱們輸入的域名由誰來解析呢？這就是DNS的工做了，其做用就是將域名翻譯成IP地址，返回給咱們。能夠簡單的認爲，每一個DNS中存放「一張大表」，其中每一行都是一個IP地址對應一個或多個域名。

　　全世界各地分佈着大量不一樣級別的DNS，幫咱們進行域名和IP之間的解析工做。其中最高級別的DNS有13個，以大寫英文字母A~M命名，分佈於世界幾個主要的城市。

　　若是你的計算機沒法鏈接到DNS，或者鏈接到錯誤的DNS，則沒法經過域名訪問網頁。

　　爲何不少人能夠上qq，卻不能打開網頁，就是由於網頁須要域名解析，而qq直接經過IP地址與服務器交互，無需解析。

　　此時，若是在瀏覽器直接輸入IP地址，就能夠訪問網頁。

　　域名的格式以聯想的官網http://www.Lenovo.com.cn爲例進行介紹。

　　域名分爲4個級別，以符號.做爲分隔符。從左至右，級別遞增。

　　最右側，表示國家。如例子中.cn，表示中國，即該域名爲中國域名。其餘，如美國.us,日本.jp等。右數第二位，表示網站類別。如例子中.com,表示"商業化"，其餘，如.org表示"非盈利機構",.edu表示"教育機構"等.左數第二位，表示企業或組織。如例子中的.Lenovo,表示"聯想公司"。其餘，如.Facebook,.apple分別表示該公司.左數第一位,表示業務類型.如例子中的www表示該頁面爲用戶提供基本web服務,如今一般做爲網站首頁使用.其餘,如mail表示該頁面提供郵箱服務等.

　　最後2級域名內容是能夠自定義的,當前不少人也不會去經過域名去了解頁面內容了,更可能是經過連接跳轉到達指定頁面,頁面連接的用途更可能是給開發人員識別頁面用了.

　　咱們常常提到的域名註冊，就是這東西。我們選好域名，把錢（或者免費）交給DNS管理公司/機構，DNS上就有咱們選的域名和IP了，別人就能夠訪問咱們的網站了。

　　所謂備案，是將域名/IP信息在公安系統登記，後期你作了錯事，人家好找你。。。

　　URL (統一資源定位符)

　　上面介紹了域名的概念,咱們知道前端如何定位服務器的地址,那麼定位服務器地址以後,前端如何定位服務器中的某個內容呢?即用戶在頁面點擊某文章連接,後臺怎麼知道你要的是哪篇文章呢?

　　這僅僅經過域名是沒法解決的,在域名以後,還須要加上具體的文章代號,造成完整的訪問要求,這就是URL.示例若是論壇放到武俠世界會被提問什麼問題？ - 電影,域名後面加上要訪問的問題和答案序號,服務器就知道應該把什麼內容反饋給前端了.

　　好的,有了URL,我們就要說到本節開頭提到的通信協議了.也就是前端有了URL按照什麼格式將其發給後臺,後臺有了內容按照什麼格式反饋給前端.

　　http/https

　　在訪問網站時,咱們常常會在URL以前看到http://這種前綴,這就是前端指定要給後臺發送數據時使用的協議格式,此處用的就是http協議.

　　除了http協議,還有https、ftp、smtp等一系列不一樣的協議，分別用於不一樣的場合。

　　http是超文本傳輸協議，能夠傳輸文字、圖片、多媒體等多種格式內容，適用於網頁，smtp更適合郵件的收發。

　　總之，前端和後臺使用相應的協議，雙方纔能夠通信，不然，雙方對不上暗號，就沒法交互了。

　　接下來，繼續分析後臺內容，想要進一步被我誤導的，請繼續往下看~

　　網站後臺接下來，咱們來拆解一下後臺服務器開發的結構。網站後臺常見的組成結構和相關開發語言或工具以下表所示。

　　

　　

　　網站後臺開發目前而言是百家爭鳴，各類語言、多種框架互相角逐，爭論不休。

　　本記錄當前不會參與那種高深的討論，本記錄只來講一下後臺都有哪些東西，至於具體怎麼選，之後再說……

　　反向代理服務(web server)

　　首先，說一下web server。

　　服務器端，須要接收前端訪問請求,根據請求類型分發給指定模塊進行處理,並完成將處理結果返回給前端的工做,這就是反向代理，也就是web server，例如Nginx/Apache等.

　　web server自己不作網站內容的解析和生成工做，重點在於處理複雜的網絡請求,應對海量的網絡鏈接。起到後臺與前端之間搭建網絡橋樑的做用，經過通信協議，與前端進行數據交互，而數據來源，由後臺其餘處理程序和數據庫等提供。

　　web server的獨立，使後臺處理程序只需專一每一個請求的細節處理,而無需關注請求的來去和排隊管理等機制.對網站開發人員而言，也大大減小了工做量。

　　web server做爲前端後臺之間的銜接工具而存在,其中只有與開發項目相關的部分配置信息,並不存在咱們編寫的數據處理程序內容,所以能夠根據項目須要(性能)隨時更換代理,固然,這種隨時更換可能存在代價.

　　web server可使用Nginx/Apache/tomcat/IIS/lighttpd等現成的工具,也可利用node.js等平臺添加模塊本身造成知足本身要求的代理工具,甚至本身動手從頭開發也能夠,徹底依據本身喜愛和水平.

　　對於我這種菜鳥,就直接選擇Nginx得了.畢竟,我編寫代碼的水平還不足以達到討論哪一個代理優秀的程度,更不用說本身寫代理了，這點自知之明我仍是有的.

　　cgi/fastcgi 通信接口

　　web server接收到前端請求以後，須要將這些請求的內容分發給具體的處理程序進行數據處理。與前端和後臺之間的通信協議類似，此處二者之間也須要定義雙方的通信協議。畢竟，web server種類那麼多，後臺處理程序的種類也那麼多，不統一交流暗號，怎麼進行交互呢。

　　cgi就是早期的雙方交互協議，稱之爲通用網關接口。

　　web server接收到前端請求以後,按照cgi的規則將數據進行整理後發送給後臺處理程序,後臺處理程序接受到數據以後,按照cgi的規則進行解析/處理,而後再次按照cgi規則將處理好的數據返回給web server,完成交互.

　　固然，目前來看cgi存在不少不足，所以出現了fastcgi等改進版，這就須要咱們在web server和後臺處理程序上分別配置通信方式，使二者統一，就能夠完成雙方的通信了。例如，Apache配置爲fastCGI模式，php安裝插件如php-fpm或php-cgi，雙方就能夠通信了。

　　這種配置過程可能很複雜，除了知道這些知識以外，還要考慮服務器的系統（windows or linux等）是否支持某插件安裝等。

　　如何配置就不在本記錄討論範圍了，這裏只要知道須要配置這些東西和爲何須要配置這些東西就能夠了。

　　這裏能夠提一下python這個語言，由於其不像PHP同樣，它不支持fastcgi接口，而是支持wsgi接口。

　　所以，咱們須要一箇中間工具，如flup一邊接受來自web server的fastcgi格式的數據，另外一邊經過wsgi與python處理程序進行交互，達到交互效果。

　　平臺/引擎/運行環境

　　在編程語言發展初期,幾乎每一個功能都須要從新編碼實現,相同的工做在不一樣的人手中重複着一樣的事情,而且只有高級開發人員可以掌握高深的編碼知識.

　　慢慢的,你們意識到這一點,隨之開發人員將編碼中核心部分和常常重複利用的部分抽離出來,作成一個個模塊/庫等形式,最終封裝成一個個開發平臺.例如前面提到的node.js,以及常常見到的.net等.

　　開發平臺中集成了大量核心或者常常被用到的功能,不須要新的開發人員重複開發,只須要安裝開發平臺,並在本身的代碼中調用平臺提供的功能便可.這也是爲何咱們安裝不少軟件的時候,老是提醒咱們安裝.net平臺,由於這些軟件調用了.net平臺中提供的功能.

　　開發平臺在必定程度上強化了某些語言的功能,例如node.js.原本js語言適合於前端應用開發(此時js採用了瀏覽器內置的解釋功能),node.js對js語言高效的解釋效果取代了原有js解釋器的工做,使js語言能夠應對服務器端的需求,即node.js平臺強化了js語言的功能.

　　固然,開發平臺具有何種功能,與對應的語言並無直接關係;開發平臺利用何種語言編寫,與對應的語言也沒有直接關係.仍是以node.js爲例,其採用的是c++語言編寫,並非js語言,所以它才能強化js語言原來沒有的功能.

　　相似開發平臺還有移動端的CM.遊戲開發類的各類引擎其實也可算做開發平臺這種形式.

　　框架

　　服務器後臺存在多種多樣的框架.例如java的SSH/python的django、web.py等等.

　　框架將大量須要重複的編碼工做實如今框架中，減小二次開發的複雜度，這點與平臺有點相似。

　　框架與平臺的不一樣在於:

　　框架實現了完成該功能的總體架構搭建,例如網站後臺框架就實現了各類session會話處理等機制,只需開發人員在總體架構預留的自定義空隙添加我的代碼,與框架互補造成完整的網站後臺;

　　平臺實現了具體細節處理代碼的編寫,並無實現總體的功能,須要開發人員本身利用平臺中提供的零件組裝完整的功能.

　　平臺就像一個大零件箱，裏面有各類型號的小零件，是最基本的組件。

　　框架是一個大功能的骨架，能夠藉助某些平臺提供的小零件進行開發。

　　框架中非公共部分，也就是網站個性化功能實現的部分，就是開發人員下一步須要本身實現的後臺處理程序了。

　　框架每每和後臺處理程序選擇的語言相關,也就是說框架一般是針對某種語言而開發的,用於減輕該種語言開發網站的複雜度.

　　服務端後臺程序

　　服務端後臺程序就是對前端發起的具體請求進行個性化處理的最終場所。

　　例如，前端向後端發起登陸要求，後臺程序是否容許對方登陸就徹底看開發人員的心情了（--!）。

　　這部份內容每每須要訪問服務端的數據庫資料、配置文件、程序算法處理等工做，能夠選擇多種可以完成這類工做的編程語言完成這些功能。

　　例如常見的PHP/JSP/ASP/Python/Ruby等。

　　這部分也就是咱們常常見到討論最火熱的部分，論不一樣語言之間的優劣。仍是那句話，對一個白癡菜鳥而言，任何一個流行的語言的設計思路均可以碾壓我大腦那一點點可憐的編程知識，所以，抓鬮吧騷年，不要再糾結了。惟一的選擇標準應該是該語言可否實現咱們的須要，徹底不須要考慮性能、複雜度（還沒開始幹就考慮安逸了？不客氣的說，就算你選了一個最簡單的語言，你都不知道它哪裏簡單！也就是說，它最大的優勢你已經感覺不到了，那種感受，確定很爽）

　　選了某種語言以後，就能夠選擇用哪一種框架了.

　　此時,問題出現了,還記得web服務器與後臺程序之間通信用的cgi麼?

　　當咱們選擇了web服務器工具和後臺開發語言以後,忽然發現這二者可能不支持統一的通信協議!

　　例如,web服務器只提供cgi插件,然後臺開發語言不支持cgi.

　　咋辦?

　　以python爲例,支持wsgi,所以咱們須要給python一個翻譯,像flup這種工具/插件什麼的,能夠將web服務器的cgi格式與python的wsgi格式進行互相轉換,達到通信的目的.

　　開發工具 (編輯軟件/IDE)

　　所謂開發工具,就是適合於某種開發語言的編輯/管理等方面的工具軟件。例如，咱們編寫文本文檔經常使用notepad、ue、sublime text等，咱們作幻燈片可能會用ppt、Keynote等。這就是適合該種「語言」的開發工具。

　　以VS/Eclipse爲例,他們風格方面存在區別,但都屬於IDE(Integrated Development Environment,集成開發環境),也就是這一個軟件中集成了編輯功能、編譯功能、文件管理功能、項目管理功能，甚至集成了不少插件、模板等內容。擁有這種IDE環境，基本不須要額外的工具，便可完成整個開發過程。

　　固然IDE集成具備便利性也就存在自身的缺點,例如IDE軟件自身體型龐大,一個VS軟件動輒幾G大小;IDE對於新手而言存在大量用不到的功能,或者出現莫名其妙的問題後新手也摸不着頭腦.

　　這裏不深刻分析其優缺點,僅僅使你們瞭解什麼是IDE便可,至於如何選擇,這裏就無論啦.

　　數據庫

　　每個網站上面可能含有大量的數據內容，包括文字、圖片、多媒體等，須要按照必定的格式存儲在一個地方，在咱們經過網頁訪問這些內容時，能夠快速的調用。

　　數據庫就實現了這種功能，咱們能夠把一堆亂七八糟的東西按照設計好的規則扔進數據庫，而後根據須要讀寫就能夠了。

　　數據庫種類不少，有Oracle、SqlServer、MySQL、DB2等，固然到底用不用數據庫軟件也要看開發人員的心情，你非要新建一個文件夾，把各類東西存在裏面管理，誰也管不着。

　　選了數據庫以後，這裏又出現一樣的問題，如何通信。

　　咱們知道，數據庫是經過後臺的程序進行操做的，那麼，咱們的後臺程序如何操做數據庫呢，這兩個東西直接語言互通麼？

　　這裏就要引出下一節的SQL語言概念了。

　　SQL

　　SQL語言是專門用來解決各類不一樣的編程語言和不一樣的數據庫之間進行通信的結構化查詢語言.

　　任何編程語言均可使用SQL語言來操做任何支持SQL語言的數據庫.

　　也就是不管使用c/java仍是python,只要使用"select"這一SQL語言保留字,就能夠從指定的數據庫中篩選數據.具體SQL語言怎麼寫,本身去查書了.

　　固然,這種便利性須要兩方面的支持,第一是編程語言提供SQL支持,第二是數據庫支持.

　　慶幸的是,現在絕大部分的編程語言和數據庫都很好的支持了SQL語言.

　　爲了進一步使數據庫的操做變得簡單,不一樣的語言又存在更便利的封裝.例如JDBC/hibernate等,爲java語言操做數據庫提供了更便捷的API和框架支持.

　　使開發者更加傻瓜式的不須要深刻了解數據庫原理,就能夠輕鬆的利用數據庫管理數據.

　　服務器設備

　　最後說一句，什麼是服務器，成天聽到這東西，到底是什麼。答：它就是一臺外表不一樣的計算機。總體結構和家用計算機基本同樣，只是根據服務器需求的不一樣，多配個網口、強化一下CPU等等。

　　若是對服務器性能要求不高，隨便一臺家用計算機均可以當作服務器使用，只要計算機上安裝了以上提到的這一堆服務器端須要的架構，接入網絡能被訪問，就能夠稱做是一臺服務器。

　　安裝了web server程序的就是web server服務器，安裝了Oracle的就是數據庫服務器，安裝了應用軟件的就是應用服務器，安裝了殺毒軟件、防火牆等的就是安全服務器，只是個名字而已。

　　服務器的位置能夠在你家中、能夠在機房、也能夠是網絡上的計算機（虛擬主機）。

　　web services

　　這東西不是一個單獨的軟件，而是一個總體的服務系統。

　　從名字能夠了解到，這是經過web網絡來實現用戶服務的一套系統。

　　例如，郵件系統web services，就須要實現用戶經過該系統能夠收發郵件處理郵件內容等功能，這一系列功能須要web server、應用服務器、數據庫服務器、安全服務器構成完整的功能架構來支撐功能的實現。

　　所以，web services是一個較大的應用角度的服務概念，而不是單純的技術角度的概念。

　　最後貼上網站總體概念圖

　　

　　其中，紅色部分是須要咱們去學習掌握的語言，須要利用這些語言實現網站先後臺功能；藍色部分是咱們能夠利用的輔助工具、軟件架構，只須要了解用法，進行適當配置，使其在合適的位置發揮功能便可。

　　

　　其中，紅色部分是須要咱們去學習掌握的語言，須要利用這些語言實現網站先後臺功能；藍色部分是咱們能夠利用的輔助工具、軟件架構，只須要了解用法，進行適當配置，使其在合適的位置發揮功能便可。

　　固然，本文和上圖並無列出所有語言、框架等知識，未列出的知識點請自行定位其用途~

　　

=======================結束===========================

　　好吧，至此，我須要瞭解的內容也差很少了，也不知道哪些對哪些錯。 　　若是你看到這篇內容，必定要抱着懷疑的態度去理解，看到你認爲能夠的部分，必定要告訴我，極可能你就是對的~ 　　若是這篇文字對你有幫助，別忘了給我說一下，讓我虛榮一下~ 　　接下來，我就要開始用實踐去驗證啦。 　　若是有可能，我再作實踐的記錄，哈哈~