什么是http服務器

嗶嗶小子  2019-02-25 10:13:43  11595  收藏 18

展開

本篇文章旨在從服務器后台開發的角度剖析一個簡單的http服務器的運行原理.

我們知道瀏覽器是http(s)的客戶端,目的是連接遠程的http服務器,然后服務器返回瀏覽器數據.瀏覽器接收數據解析數據之后展現出來.我們看到的外在表現就是,瀏覽器訪問一個url,然后就得到相應的web頁面.

同樣我們知道,瀏覽器與http服務器是通過http協議,傳輸層是tcp協議,因為他是有連接,可靠的協議.關於http協議簡單的介紹一下:

一個標准的HTTP請求由以下幾個部分組成

1.  
   <request-line>
2.  
   <headers>
3.  
   <CRLF>
4.  
   [ <request-body><CRLF>]

在HTTP請求中，第一行是請求行（request-line），用來說明請求類型、要訪問的資源（URL）以及使用的HTTP版本；
緊接着是多行頭部（headers）信息，用來說明服務器要使用的附加信息；
頭部信息之后是一個回車換行符（\r\n），用於標明頭部信息的結束。
以上是必須內容，根據需要可在頭部信息結束之后增加主體數據（request-body）；

主體數據之后是一個回車換行符（\r\n），用於標明主體數據的結束。

例如，我們可以在IE瀏覽器上輸入下面的網址：

http://localhost:8000/hello/index.html

HTTP請求的頭部信息如下：

1.  
   GET /hello/index.html HTTP/1.1
2.  
   Accept: */*
3.  
   Accept-Language: zh-cn
4.  
   Accept-Encoding: gzip, deflate
5.  
   Host: localhost: 8000
6.  
   Connection: Keep-Alive
7.  
   Cookie: JSESSIONID=BBBA54D519F7A320A54211F0107F5EA6

收到請求數據之后,服務器解析,畢竟是明文字符,這個簡單.然后服務器就知道了客戶端的要求--獲取目錄hello/index.html文件.服務器讀取文件內容發送給瀏覽器就好了.

后來隨着業務邏輯越來越復雜,單單獲取某個html文件功能早已不能滿足需求,個性化需求呼之欲出.比如在線問卷調查表,他究竟是怎么把我們填寫的數據傳遞給服務器的呢?

你可能會說那不是一樣,客戶端發送什么內容,服務器就接收什么內容.可是你想過沒有,每個網站的需求是不一樣的,本來服務器接收到瀏覽器的請求數據已經是夠復雜的了,還讓服務器來解析數據並響應不同的數據處理,這不太現實.

一般的,服務器最好只接收數據,如果讓服務器也處理數據邏輯,勢必會讓服務器變得很復雜,穩定性也得不到保證.

另外一個角度是為了讓程序復用,提高生產效率.也就是說,如果不關注業務邏輯,只注重接收數據,那么服務器程序可以給任何一個開發者使用.換句話說,我們不用從頭開始寫.直接使用現有的高性能的服務器就可以滿足需求了.例如公司白領中午要吃飯,不可能跑回家自己去做飯吃,自己叫外賣就好了.

但是現實問題仍然沒有解決,通過什么方式去處理業務邏輯呢?

你要給手機充電時,把插頭插入插線板就能獲取電了.插線板有接口,提供了電.

同理服務器程序最好也提供接口,瀏覽器通過統一的接口給服務器,然后我們從服務器接口中獲取我們想要的數據.獲取數據之后我們可以把數據交給第三方程序來處理邏輯,這樣就做到與服務器業務分離了,good iead.

事實上,現在的http服務器就是這么做的,不過很復雜而已.下一篇開始為您介紹這些接口.

附錄:HTTP Request Header 請求頭

 

Header	解釋	示例
Accept	指定客戶端能夠接收的內容類型	Accept: text/plain, text/html
Accept-Charset	瀏覽器可以接受的字符編碼集。	Accept-Charset: iso-8859-5
Accept-Encoding	指定瀏覽器可以支持的web服務器返回內容壓縮編碼類型。	Accept-Encoding: compress, gzip
Accept-Language	瀏覽器可接受的語言	Accept-Language: en,zh
Accept-Ranges	可以請求網頁實體的一個或者多個子范圍字段	Accept-Ranges: bytes
Authorization	HTTP授權的授權證書	Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Cache-Control	指定請求和響應遵循的緩存機制	Cache-Control: no-cache
Connection	表示是否需要持久連接。（HTTP 1.1默認進行持久連接）	Connection: close
Cookie	HTTP請求發送時，會把保存在該請求域名下的所有cookie值一起發送給web服務器。	Cookie: $Version=1; Skin=new;
Content-Length	請求的內容長度	Content-Length: 348
Content-Type	請求的與實體對應的MIME信息	Content-Type: application/x-www-form-urlencoded
Date	請求發送的日期和時間	Date: Tue, 15 Nov 2010 08:12:31 GMT
Expect	請求的特定的服務器行為	Expect: 100-continue
From	發出請求的用戶的Email	From: [e-mail]
Host	指定請求的服務器的域名和端口號	Host: www.zcmhi.com
If-Match	只有請求內容與實體相匹配才有效	If-Match: “737060cd8c284d8af7ad3082f209582d”
If-Modified-Since	如果請求的部分在指定時間之后被修改則請求成功，未被修改則返回304代碼	If-Modified-Since: Sat, 29 Oct 2010 19:43:31 GMT
If-None-Match	如果內容未改變返回304代碼，參數為服務器先前發送的Etag，與服務器回應的Etag比較判斷是否改變	If-None-Match: “737060cd8c284d8af7ad3082f209582d”
If-Range	如果實體未改變，服務器發送客戶端丟失的部分，否則發送整個實體。參數也為Etag	If-Range: “737060cd8c284d8af7ad3082f209582d”
If-Unmodified-Since	只在實體在指定時間之后未被修改才請求成功	If-Unmodified-Since: Sat, 29 Oct 2010 19:43:31 GMT
Max-Forwards	限制信息通過代理和網關傳送的時間	Max-Forwards: 10
Pragma	用來包含實現特定的指令	Pragma: no-cache
Proxy-Authorization	連接到代理的授權證書	Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Range	只請求實體的一部分，指定范圍	Range: bytes=500-999
Referer	先前網頁的地址，當前請求網頁緊隨其后,即來路	Referer: http://www.zcmhi.com/archives/71.html
TE	客戶端願意接受的傳輸編碼，並通知服務器接受接受尾加頭信息	TE: trailers,deflate;q=0.5
Upgrade	向服務器指定某種傳輸協議以便服務器進行轉換（如果支持）	Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
User-Agent	User-Agent的內容包含發出請求的用戶信息	User-Agent: Mozilla/5.0 (Linux; X11)
Via	通知中間網關或代理服務器地址，通信協議	Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
Warning	關於消息實體的警告信息	Warn: 199 Miscellaneous warning

--------------------- 
作者：Shonm 
來源：CSDN 
原文：https://blog.csdn.net/zxm342698145/article/details/79995039 
版權聲明：本文為博主原創文章，轉載請附上博文鏈接！