大話web服務器開發

本文純碎處于個人理解不可做科學依據。

前因

工作這么多年斷斷續續看過一些有 web 服務器編程的書，但是一直沒有把自己的理解整理起來，今天索性就做個總結，記得第一次接觸 web 網頁編程是 02 年，那時學校里計算機比賽，學校有個哥們用 ASP 寫了一個電子商務的網站，記憶中那會好像電子商務剛剛起步哈，好生羨慕，處于對技術渴求自己去書店買了網站開發的書，埋頭苦讀有一個月，后來還和同學一起給他叔做了網站，算是練手，很自豪處于程序猿普遍心理，當時心想吊什么哥也能做 web，認識 web 服務器開發是從那時開始的吧，現在回想起來那時真是個菜鳥。

工作中的 web

自從 04 年離校之后直到 06 年才又一次接觸了 web 開發，那時公司有個日本 UPS 監控項目，項目中有個設備需要通過網頁配置設備的參數，由于是嵌入的設備所以用的是 CGI，最早接觸 web 人都知道 CGI，要用這個做網站簡直是跟自己的體力、耐力較勁，一堆堆 HTML 腳本嵌入在C代碼中，一個配置的功能嵌入的 HTML 代碼就差不多有 2 萬行，后期維護更別說了，可是沒辦法因為是嵌入的系統，只有這樣更高效，而且嵌入設備本身自己的資源有限，所以也只能用 CGI，做完這個項目處于對技術的深入了解，買了一些網站開發的書看，記得那會國內做項目用的比較多的是 asp.net 和 JSP，PHP 用的人很少基本上沒有，現如今已經是 2012 年再也沒有接觸過 web 服務器開發了，但這期間一直關注 web 服務器開發相關的技術。

我們都是站在巨人的肩上

談到網頁大家都知道是 HMTL 書寫的一個文件，自從 93 年 HTML 出現以來，是互聯網的發展發生了翻天覆地的變化，說實話 HTML 至今仍是互聯網的根本，多少互聯網的公司在這之后起來又倒下，人類的信息在有 HTML 構建的網中交叉傳播，隨著互聯網的發展人們信息的渴求越來越來大，很多現有的業務已經不能滿足人們的需要，而且隨著 PC 的發展、網絡硬件環境和社會其他行業的信息化的提高，人們對互聯網的需求不僅僅是信息的獲取，更多人把相關的業務和數據處理都放到互聯網上，HTML 由于其特殊性（不需要安裝客戶端），越來越受到人們親來，好多公司把業務處理直接放到互聯網上提供給客戶，在發展的初期技術人員要完成相應的業務，生成指定的頁面只能將 HTML 代碼嵌入到自己的代碼中，根據不同的業務打印出不同的 HTML 頁面，這個時候的網站開發是最初級階段，沒有所謂的 WEB 服務器，技術人員要自己處理網絡連接、業務邏輯、腳本網頁生成、數據訪問，這其中的網絡連接處理就占用很大的開發時間，相當于每次開發技術人員都要先開發一個高效的網絡服務器，而生成 HTML 網頁的代碼由于每次的業務邏輯不同，都要重新實現，并且實際的代碼和 HTML 代碼穿插在一起也增加了項目的維護難度，CGI 就是這么一個東西，估計現在已經沒有人用了，隨著應用的深入和推廣，人們發現好開發人員的好多工作都是重復的勞動，這是有些大一點的公司開始，把這些重復勞動的工作都抽離出來，例如微軟推出了 iis 服務器，96年推出了 ASP 腳本，這樣做得目的就是讓技術人員從繁雜的服務器開發和腳本生成中解脫出來，只專注于業務邏輯的開發，這個時間的發展僅僅經過了一年的時間就出現了很多 web 服務器和服務器端開發腳本，像 PHP 就是在 94 年出現的，比較有名的 Apache 也是在那個時間短出現的，到現在已經出現好多 web 服務器和服務器端腳本語言，例如 Nginx、python、Rube、jsp、lua、lisp 和 asp.net 等等，最值得人們敬畏的是這些都是免費提供給人們使用，今天人們可以站著前人的肩膀上很輕松的開發基于 WEB 的應用，甚至你都不需要懂任何服務器的技術，只需要學會腳本懂得如何處理用戶的需求。

底層的服務器

今天我不需要自己實現一個 web 服務器了，有許多好用的服務器我們可以直接拿來使用，但對于一個真正 geek 程序員，我覺的必須懂一點服務器的原理，作為一個 web 服務器主要解決幾個問題（1）平臺問題，要支持不同的平臺，這就要求服務器在開發過程中內核必須使用標準的 POSIX，同時也要可以跨平臺版本編譯（2）網絡連接高并發的問題（3）HTTP 協議的解析和處理，這三個問題構成了一個 web 服務的內核層，所有的 web 服務器都要解決這三個問題，一個 web 服務器的性能好壞就取決于這三個問題誰解決的更好，除了這些作為一個 web 服務器還有支持可擴展性，提供第三方擴展的開發，可以根據不同的需求附加不同的功能庫，服務器最好還要支持負載均衡的功能，因為隨著訪問量的增加，一個服務器很難應付更多的訪問請求。

我們的腳本

腳本的第一個問題：

HTTP 基于問答的特性決定了腳本的實現，我們知道 HTTP 協議是問答方式的，就是你請求我給你發回內容，這個是有早起的互聯網的特性決定的，也只有這樣互聯網才能更靈活，HTML 的網狀結構才能變成一個空間的網狀結構，因為大家可以不需要關心相互的狀態，只需要一個連接就可以相互傳播和訪問，但對于具體的應用，單獨的一個網站要處理自己的業務，確需要保留場景和業務邏輯的狀態，沒有辦法腳本就必須解決這個問題，幫助網頁維護一個狀態是任何腳本語言必須解決的問題，大部分腳本語言是通過 SESSION 和 COOKIE 來實現的，這幾乎成為一種共識，只要開發服務器端腳本都實現這個功能，當然也可以不通過這個來實現狀態的持久化，可以通過內存服務器，例如 memcache（更高效）等。

腳本的第二個問題：

處理的業務各種各樣，可能有些業務腳本現有的功能只能滿足部分功能，這就要就腳本語言有很好的可擴展性，用戶可以根據自己的需求實現不同的庫，通過腳本調用，達到擴展功能的目的。

腳本的第三個問題：

效率是一個腳本受歡迎的關鍵，這里的效率除了執行效率還有開發效率。