HTTP學習筆記(五)


目前,市場上流行有很多web服務器軟件,每種服務器都有自己的特點。我們在開發的過程中,經常要和它們打交道,所以了解它們的工作原理也是很重要的。

 

幾款比較流行的服務器 

它們會做些什么?

 

第三篇中有這樣的一張圖片,它演示了客戶端和服務器在發起事務時它們需要做的幾個事情。

 

這里就詳細地談談服務器在運行過程中會做什么。

 首先服務器在完全運行起來之后,客戶端就可以向服務器發起連接了(關於這個部分,大家可以看第三篇筆記)。現在的web服務器大多數都是多線程服務器了,一般在服務器上配置連接池,限制連接的數量,可以大大減輕服務器的連接壓力,以保證網絡服務的質量。

在這個階段,服務器也會判斷客戶端的身份,比如一些有惡意行為的IP地址,服務器會拒絕建立連接。

接下來,服務器就會開始接受客戶端發出的報文並解析它們(關於報文可以看第四篇筆記)。服務器首先會讀取報文的起始行。從它請求的方法中以確定這個請求需要給予什么樣子的響應,在這之后,服務器就會去讀取uri,確定資源的地址,最后在這行信息中檢測客戶端使用的http版本,以確定首部的一些信息解讀的方式。之后就是讀取各行的信息,直到檢測到以CRLF Carriage-Return Line-Feed 回車換行)結束的標識。在這之后服務器就會對請求開始處理了,比如像post中的一些數據傳遞到程序中。

此時,服務器要開始很重要的步驟了,找到客戶端希望得到的資源,開始構建一個特別的內容給客戶端,這些都是程序處理的部分了。當然,這里請求的資源使用路徑都是服務器上的虛擬路徑,不是服務器文件系統上的絕對路徑。這個虛擬路徑恰好把資源封閉在一個固定的路徑中,不讓訪問突破規定范圍。在linux中有一種SELinux的機制,進程只能訪問那些在他的任務中所需要文件。

 在確定了要發送的內容之后,服務器會構建一個響應報文並發送它們。這里面通常會包括一個響應主體的MIME類型響應主體的Content-length以及響應主體頁面。發送完畢后,服務器會檢測這是不是一個持久連接,並根據此,決定是不是要關閉連接。

字符編碼

我想凡是做過開發的人一定都遇到過字符編碼亂碼的問題。關於字符編碼的問題非常復雜。其中有一些就和web服務器接收和構建報文有關系。

一個客戶端吧請求報文在發送給服務器時,可以在發送前,在首部通過設置Accept-CharestAccecpt-Encoding告訴服務器自己期待的字符編碼方式。服務器會根據這條信息給予客戶端最優化的方案。但有時,亂碼依舊。而這些亂碼是從哪里來的呢?

 

這要從它的歷史說起了,最早的ASCII碼並不支持中文,為了滿足我們國家的需要,有人對ANSi(ASCII的擴充)碼進行了擴充,制作了GB2312,后來發現GB2312不能顯示一些生僻的字,於是gbk編碼就誕生了,在這之后,有進行了幾次擴展。

但是在ANSi編碼下,同一個編碼值,在不同的編碼體系里代表着不同的字,這就是意味着不同國家的人相互訪問網站的時候,由於不同的編碼,我們就會看見不同的內容(大部分都是不知所雲的亂碼)。

后來有了Unicode編碼,每個符號對應一個唯一的編碼,亂碼問題就不存在了。但是這樣做這個庫就非常龐大,UTF-8可以根據不同的符號自動選擇編碼的長短,這樣又一次提高了字符編碼的效率。

 

所以,utf-8應該是我們最好的選擇。如果我們使用GB2312,我們在URL傳遞中文數據時,就會變成一堆符號和數字,而我們采用utf-8時,就不會有這個問題。有時候,我們很少注意,自己在開發時,頁面本身的字符編碼格式。所以很多不同字符編碼定義,就讓服務器不知所措了,有時候數據庫的字符編碼和接收的字符編碼又是不同的,這里又一次造成了編碼的不和諧。

 


免責聲明!

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



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