Http与WWW服务精解
TCP/IP 協議介紹
在介紹 HTTP 協議之前，先簡單說一下TCP/IP協議的相關內容。TCP/IP協議是分層的，從底層至應用層分別為：物理層、鏈路層、網絡層、傳輸層和應用層，如下圖所示：
?
從應用層至物理層，數據是一層層封裝，封裝的方式一般都是在原有數據的前面加一個數據控制頭，數據封裝格式如下：
其中，對于TCP傳輸協議，客戶端在于服務器建立連接前需要經過TCP三層握手，過程如下：
HTTP協議簡介
超文本傳輸協議（Hypertext Transfer Protocol，簡稱HTTP）是應用層協議，是互聯網上應用最為廣泛的一種網絡協議。所有的www都必須遵守這個標準，設計HTTP最初的目的是為了提供一種發布和接收HTML頁面的方法。
HTTP 是一種請求/響應式的協議。一個客戶機與服務器建立連接后，發送一個請求給服務器；服務器接到請求后，給予相應的響應信息。
HTTP 的第一版本 HTTP/0.9是一種簡單的用于網絡間原始數據傳輸的協議；
HTTP/1.0由 RFC 1945 定義 ，在原 HTTP/0.9 的基礎上，有了進一步的改進，允許消息以類 MIME 信息格式存 在，包括請求/響應范式中的已傳輸數據和修飾符等方面的信息；
HTTP/1.1(RFC2616) 的要求更加嚴格以確保服務的可靠性，增強了在HTTP/1.0 沒有充分考慮到分層代理服務器、高速緩沖存儲器、持久連接需求或虛擬主機等方面的效能；
安全增強版的 HTTP （即S-HTTP或HTTPS），則是HTTP協議與安全套接口層(SSL)的結合，使HTTP的協議數據在傳輸過程中更加安全。
??端口對應的服務
?? ?21?? ??? ?ftp
?? ?22?? ??? ?ssh sftp
?? ?25?? ??? ?smtp
?? ?3306?? ?mysql
??? 873?? ?? rsync
?? ?161?? ?? snmp
?? ?111?? ?? rpc
?? ?3389?? ?windows 遠程桌面
?? ?80?? ??? ?http
?? ?443?? ?? https
?? ?110?? ?? pop3
?? ?55?? ??? ?dns
協議結構
HTTP協議格式也比較簡單，格式如下：
?
請求頭格式
a) 通用頭(general-header)：
Cache-Control：客戶端希望服務端如何緩存自己的請求數據。
Connection：客戶端是否希望與服務端之間保持長連接。
Date：只有當請求方法為POST或get方法時客戶端才可能會有些字段。
Pragma：包含了客戶端一些特殊請求信息。
?
b) 請求頭(request-header)：
Accept： 表明客戶同端可接受的請求回應的媒體類型范圍列表。“*”用于按范圍將類型分組，用“*/*”指示可接受全部類型；用“type/*”指示可接受 type類型的所有子類型，
Accept-Charset：客戶端所能識別的字符集編碼格式，格式：“Accept-Charset: 字符集1[:權重]，字符集2[:權重]”，如：“ Accept-Charset: iso-8859-5, unicode-1-1;q=0.8”；
Accept-Language：客戶端所能識別的語言，格式：“Accept-Language: 語言1[:權重]，語言2[:權重]”，如：” Accept-Language: zh, en;q=0.7”；
Host：客戶請求的主機域名或主機IP，格式：“Host: 域名或IP[:端口號]”，如：“Host: www.mysq.com:80“，請求行中若有HTTP/1.1則必須有該請求頭；
User-Agent：表明用戶所使用的瀏覽器標識，主要用于統計的目的；
Referer：指明該請求是從哪個關聯連接而來；
Accept-Encoding：客戶端所能識別的編碼壓縮格式，如：“Accept-Encoding: gzip, deflate”。
If- Modified-Since：該字段與客戶端緩存相關，客戶端所訪問的URL自該指定日期以來在服務端是否被修改過，如果修改過則服務端返回新的修改后 的信息，如果未修改過則服務器返回304表明此請求所指URL未曾修改過。
If-None-Match：該字段與客戶端緩存相關，客戶端發送URL請求的同時發送該字段及標識，如 果服務端的標識與客戶端的標識一致，則返回304表明此URL未修改過，如果不一致則服務端返回完整的數據信息，如：“If-None-Match: 0f0a893aad8c61:253, 0f0a893aad8c61:252, 0f0a893aad8c61:251”；
Cookie：為擴展字段，存儲于客戶端，向同一域名的服務端發送屬于該域的cookie，如：“Cookie: MailUserName=whouse”；
?
c) 實體頭(entity-header): (此類頭存在時要求有數據體)
Content-Encoding：客戶端所能識別的編碼壓縮格式，如：“Content-Encoding: gzip, deflate”；
Content-Length：客戶端以POST方法上傳數據時數據體部分的內容長度，如：“ Content-Length: 24”；
Content- Type：客戶端發送的數據體的內容類型，如：“Content-Type: application/x-www-form-urlencoded”為以普通的POST方法發送的數據；“Content-Type: multipart/form-data; boundary=---------------------------5169208281820”，則表明數據體由多部分組成，分隔符為 “-----------------------------5169208281820”；
?
響應格式
?
a) 通用頭(general-header)：
Cache- Control：服務端要求中間代理及客戶端如何緩存自己響應的數據，如“Cache-Control: no-cache”，如：“Cache-Control: private” 不希望被緩存，“Cache-Control: public” 可以被緩存；
Connection：服務端是否希望與客戶端之間保持長連接，；
Date：只有當請求方法為POST或get方法時客戶端才可能會有些字段；
Pragma：包含了服務端一些特殊響應信息，如 “Pragma: no-cache” 服務端希望代理或客戶端不應緩存結果數據；
Transfer-Encoding：服務端向客戶端傳輸數據所采用的傳輸模式(僅在HTTP1.1中出現)，如：“Transfer-Encoding: chunked”，注：該字段的優先級要高于“Content-Length” 字段的優先級；
Via：一般用在代理網關向應用服務器發送的請求頭中，表明該來自客戶端的請求經過了網關代理，
???? 格式為："Via: 請求協議版本? 網關標識?? [其它信息] "，
???? 如 ：" Via: 1.1? webcache_250_199.hexun.com:80 (squid)"
?
b）響應頭(response-header)：
Accept-Ranges：表明服務端接收的數據單位，如：“Accept-Ranges: bytes”, ；
Location：服務端向客戶端返回此信息以使客戶端進行重定向，如：“Location: http://www.hexun.com”；
Server：服務端返回的用于標識自己的一些信息，如：“ Server: Microsoft-IIS/6.0”；
ETag：服務端返回的響應數據的標識字段，客戶端可根據此字段的值向服務器發送某URL是否更新的信息；
?
c）實體頭(entity-header): (此類頭存在時要求有數據體)
Content-Encoding：服務端所響應數據的編碼格式。
Content-Length：服務端所返回數據的數據體部分的內容長度。
Content-Type：服務端所返回的數據體的內容類型。
Set-Cookie：服務端返回給客戶端的cookie數據。
服務器返回狀態碼
1xx：表明服務端接收了客戶端請求，客戶端繼續發送請求；
2xx：客戶端發送的請求被服務端成功接收并成功進行了處理；
3xx：服務端給客戶端返回用于重定向的信息；
4xx：客戶端的請求有非法內容；
5xx：服務端未能正常處理客戶端的請求而出現意外錯誤。
?比如：
“100”? ; 服務端希望客戶端繼續；
“200”? ; 服務端成功接收并處理了客戶端的請求；
“301”? ; 客戶端所請求的URL已經移走，需要客戶端重定向到其它的URL；
“304”? ; 客戶端所請求的URL未發生變化；
“400”? ; 客戶端請求錯誤；
“403”? ; 客戶端請求被服務端所禁止；
“404”? ; 客戶端所請求的URL在服務端不存在；
“500”? ; 服務端在處理客戶端請求時出現異常；
“501”? ; 服務端未實現客戶端請求的方法或內容；
“502”? ; 此為中間代理返回給客戶端的出錯信息，表明服務端返回給代理時出錯；
“503”? ; 服務端由于負載過高或其它錯誤而無法正常響應客戶端請求；
“504”? ; 此為中間代理返回給客戶端的出錯信息，表明代理連接服務端出現超時。
?
HTTP 請求方法
?
GET、POST、HEAD、CONNECT、PUT、DELETE、TRACE、OPTIONS
| HEAD | 與 GET 相同，但只返回 HTTP 報頭，不返回文檔主體。 |
| PUT | 上傳指定的 URI 表示。 |
| DELETE | 刪除指定資源。 |
| OPTIONS | 返回服務器支持的 HTTP 方法。 |
| CONNECT | 把請求連接轉換到透明的 TCP/IP 通道。 |
?
Html代碼??
a）GET請求
GET http://mail.test.com/ HTTP/1.1 ? Host: mail.test.com ? User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; zh-CN; rv:1.8.1) Gecko/20061010 Firefox/2.0 ? Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 ? Accept-Language: en-us,zh-cn;q=0.7,zh;q=0.3 ? Accept-Encoding: gzip,deflate ? Accept-Charset: gb2312,utf-8;q=0.7,*;q=0.7 ? Keep-Alive: 300 ? Proxy-Connection: keep-alive ??
b）POST請求?
POST / HTTP/1.1 ? Accept: image/gif, image/x-xbitmap, image/jpeg, application/vnd.ms-powerpoint, application/msword, */* ? Accept-Language: zh-cn ? Content-Type: application/x-www-form-urlencoded ? Accept-Encoding: gzip, deflate ? User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) ? Host: www.test.com ? Content-Length: 24 ? Connection: Keep-Alive ? Cache-Control: no-cache ?name=value&submitsubmit=submit
c）POST方式上傳文件
POST http://www.test.comt/upload_attach?uidl=%3C HTTP/1.1 ? Host: www.test.com ? User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; zh-CN; rv:1.8.1) Gecko/20061010 Firefox/2.0 ? Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 ? Accept-Language: en-us,zh-cn;q=0.7,zh;q=0.3 ? Accept-Charset: gb2312,utf-8;q=0.7,*;q=0.7 ? Content-Type: multipart/form-data; boundary=---------------------------5169208281820 ? Content-Length: 449 ?-----------------------------5169208281820 ? Content-Disposition: form-data; name="file_1"; filename="" ? Content-Type: application/octet-stream ?-----------------------------5169208281820 ? Content-Disposition: form-data; name="file_0"; filename="test.txt" ? Content-Type: text/plain ?hello world! ?-----------------------------5169208281820 ? Content-Disposition: form-data; name="oper" ?upload ? -----------------------------5169208281820-- ??
雖然我不寫代碼，但是還是說一下get與post傳參區別吧，畢竟了解過，
1）get參數通過url傳遞，post放在request body中。
2）get請求在url中傳遞的參數是有長度限制的，而post沒有
3）get比post更不安全，因為參數直接暴露在url中，所以不能用來傳遞敏感信息。
4）get請求只能進行url編碼，而post支持多種編碼方get請求會瀏覽器主動cache，而post支持多種編碼方式。
5）get請求參數會被完整保留在瀏覽歷史記錄里，而post中的參數不會被保留。
GET和POST本質上就是TCP鏈接，并無差別。但是由于HTTP的規定和瀏覽器/服務器的限制，導致他們在應用過程中體現出一些不同，GET產生一個TCP數據包；POST產生兩個TCP數據包。簡單的說：
對于GET方式的請求，瀏覽器會把http header和data一并發送出去，服務器響應200（返回數據）；
而對于POST，瀏覽器先發送header，服務器響應100 continue，瀏覽器再發送data，服務器響應200 ok（返回數據）。
?
總結：http協議通信原理
?? ?１、http是osi模型中應用層協議。http協議的重要應用是www服務。
?? ?２、DNS解析原理
?? ?３、http請求信息包含的內容。
?? ?４、http服務返回的內容，消息主體也消息頭。
?? ?５、用戶通過瀏覽器訪問站服務器的請求到返回數據流程。
靜態網頁
?? ?概念：在網站設計中，純粹HTML格式的網頁（可以包含圖片，JS（前端功能實現），CSS（樣式）等）通常被稱為“靜態網頁”。
?? ?特點：所有程序在客戶瀏覽器端解析，客戶端如：IE瀏覽器，你編的是什么，它顯示的就是什么，一旦編寫完成，就不會有任何改變。維護和更新比較麻煩。
?? ?（1）靜態網頁每個頁面都有一個固定的URL，且網頁URL一般以.htm、.html、.shtml等常見形式為后綴，而且地址中不含問好“？”或“&”
?? ?（2）網頁內容一經發布到網站服務器上，無論是否有用戶訪問，每個靜態網頁的內容都是保存在網頁服務器上的，也就是說，靜態網頁是實實在在保存在服務器上的文件，每個網頁都是一個獨立的文件
?? ?（3）靜態網頁的內容相對穩定，因此，容易被搜索引擎收錄（優點，seo）
?? ?（4）靜態網頁沒有數據庫的支持，在網站制作和維護方面工作量較大，因此當網站信息量很大時完全依靠靜態網頁制作的方式比較困難（缺點）
?? ?（5）靜態網頁的交互性較差，在功能方面有較大的限制（缺點）
?? ?（6）網頁程序在用戶瀏覽器端解析，如IE瀏覽器，這樣程序解析效率更高，由于服務端不進行解析，因此可以接受更多的并發訪問，當客戶端向服務器請求數據時，服務器直接把數據返回（不做任何解析），當客戶端拿到數據后，在瀏覽器端解析展現出來。
動態網頁?
擴展名：常見擴展名為asp,aspx,php,jsp,cgi,perl等
?? ?（1）動態網頁一般以數據庫技術為基礎，可以大大降低網站的維護工作量
?? ?（2）采用動態網頁技術的網站可以實現更多的功能，如用戶注冊，用戶登錄，在線調查，投票，用戶管理，訂單管理，發博文等等
?? ?（3）動態網頁大多并不是獨立存在于服務器上的網頁文件，只有當用戶請求時服務器才返回一個完整的網頁
?? ?（4）動態網頁中的“?”對搜索的收錄存在一定的問題，搜索引擎一般不可能從一個網站的數據庫中訪問全部網頁，或者出于技術方面的考慮，搜索蜘蛛一般不會區抓取網址中的“？”后面的內容，因此采用動態網頁的網站在進行搜索引擎推廣時需要做一定的技術處理（偽靜態）才能適應搜索引擎的抓取的要求
?? ?（5）程序在服務端解析，服務端：php引擎，java容器(tomcat,resin,jboss)
?? ?（6）由于程序在服務端解析，因此,會消耗大量的CPU和內存等資源，因此，效率遠不如靜態網頁。
偽靜態
偽靜態特點：從URL地址里看，給人感覺是靜態內容（如地址結尾帶html）,通過rewrite規則實現URL重寫。地址規范、美觀、有利于搜索引擎抓取。
?? ?1、動態網頁偽裝成靜態
?? ?2、目的：便于搜索引擎搜錄，提升用戶訪問量以及用戶體驗。
?? ?3、由于僅僅是偽裝，實際上還是動態，性能沒有提升，轉換消耗資源因此性能反而下降。
?? ?4、盡可能轉換成真正的靜態頁面，除非并發量不是很大，用rewrite實現偽靜態。
回到頂部
什么是DNS？
? ?DNS( Domain Name System)是“域名系統”的英文縮寫，是一種組織成域層次結構的計算機和網絡服務命名系統，它用于TCP/IP網絡，它所提供的服務是用來將主機名和域名轉換為IP地址的工作。DNS就是這樣的一位“翻譯官”，它的基本工作原理可用下圖來表示。
?
Dns服務的工作過程
當 DNS 客戶機需要查詢程序中使用的名稱時，它會查詢本地DNS 服務器來解析該名稱。客戶機發送的每條查詢消息都包括3條信息，以指定服務器應回答的問題。
1）?指定的 DNS 域名，表示為完全合格的域名 (FQDN) 。
2）?指定的查詢類型，它可根據類型指定資源記錄，或作為查詢操作的專門類型。
3）?DNS域名的指定類別，它始終應指定為 Internet 類別。
??? DNS 查詢以各種不同的方式進行解析。客戶機有時也可通過使用從以前查詢獲得的緩存信息就地應答查詢。DNS 服務器可使用其自身的資源記錄信息緩存來應答查詢，也可代表請求客戶機來查詢或聯系其他 DNS 服務器，以完全解析該名稱，并隨后將應答返回至客戶機。這個過程稱為遞歸。
??? 另外，客戶機自己也可嘗試聯系其他的 DNS 服務器來解析名稱。如果客戶機這么做，它會使用基于服務器應答的獨立和附加的查詢，該過程稱作迭代，即DNS服務器之間的交互查詢就是迭代查詢。
DNS解析流程圖（來源于網絡）
1、在瀏覽器中輸入www.baidu.com域名，操作系統會先檢查自己本地的hosts文件是否有這個網址映射關系，如果有，就先調用這個IP地址映射，完成域名解析。?
2、如果hosts里沒有這個域名的映射，則查找本地DNS解析器緩存，是否有這個網址映射關系，如果有，直接返回，完成域名解析。?
3、如果hosts與本地DNS解析器緩存都沒有相應的網址映射關系，首先會找TCP/ip參數中設置的首選DNS服務器，在此我們叫它本地DNS服務器，此服務器收到查詢時，如果要查詢的域名，包含在本地配置區域資源中，則返回解析結果給客戶機，完成域名解析，此解析具有權威性。?
4、如果要查詢的域名，不由本地DNS服務器區域解析，但該服務器已緩存了此網址映射關系，則調用這個IP地址映射，完成域名解析，此解析不具有權威性。?
5、如果本地DNS服務器本地區域文件與緩存解析都失效，則根據本地DNS服務器的設置（是否設置轉發器）進行查詢，如果未用轉發模式，本地DNS就把請求發至根DNS，根DNS服務器收到請求后會判斷這個域名(.com)是誰來授權管理，并會返回一個負責該頂級域名服務器的一個IP。本地DNS服務器收到IP信息后，將會聯系負責.com域的這臺服務器。這臺負責.com域的服務器收到請求后，如果自己無法解析，它就會找一個管理.com域的下一級DNS服務器地址(baidu.com)給本地DNS服務器。當本地DNS服務器收到這個地址后，就會找baiducom域服務器，重復上面的動作，進行查詢，直至找到www.qq.com主機。?
6、如果用的是轉發模式，此DNS服務器就會把請求轉發至上一級DNS服務器，由上一級服務器進行解析，上一級服務器如果不能解析，或找根DNS或把轉請求轉至上上級，以此循環。不管是本地DNS服務器用是是轉發，還是根提示，最后都是把結果返回給本地DNS服務器，由此DNS服務器再返回給客戶機。
技術的提升是量的積累,思想的提升是質的飛越
總結
以上是生活随笔為你收集整理的Http与WWW服务精解的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： java文件全是数字编码_批量将Java
- 下一篇： 场景编辑器 Scene Building