TCP/IP 協(xié)議介紹

　　在介紹 HTTP 協(xié)議之前，先簡單說一下TCP/IP協(xié)議的相關(guān)內(nèi)容。TCP/IP協(xié)議是分層的，從底層至應(yīng)用層分別為：物理層、鏈路層、網(wǎng)絡(luò)層、傳輸層和應(yīng)用層，如下圖所示：

?

從應(yīng)用層至物理層，數(shù)據(jù)是一層層封裝，封裝的方式一般都是在原有數(shù)據(jù)的前面加一個(gè)數(shù)據(jù)控制頭，數(shù)據(jù)封裝格式如下：

其中，對(duì)于TCP傳輸協(xié)議，客戶端在于服務(wù)器建立連接前需要經(jīng)過TCP三層握手，過程如下：

HTTP協(xié)議簡介

　　超文本傳輸協(xié)議（Hypertext Transfer Protocol，簡稱HTTP）是應(yīng)用層協(xié)議，是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議。所有的www都必須遵守這個(gè)標(biāo)準(zhǔn)，設(shè)計(jì)HTTP最初的目的是為了提供一種發(fā)布和接收HTML頁面的方法。
　　HTTP 是一種請(qǐng)求/響應(yīng)式的協(xié)議。一個(gè)客戶機(jī)與服務(wù)器建立連接后，發(fā)送一個(gè)請(qǐng)求給服務(wù)器；服務(wù)器接到請(qǐng)求后，給予相應(yīng)的響應(yīng)信息。
　　HTTP 的第一版本 HTTP/0.9是一種簡單的用于網(wǎng)絡(luò)間原始數(shù)據(jù)傳輸?shù)膮f(xié)議；
　　HTTP/1.0由 RFC 1945 定義 ，在原 HTTP/0.9 的基礎(chǔ)上，有了進(jìn)一步的改進(jìn)，允許消息以類 MIME 信息格式存　在，包括請(qǐng)求/響應(yīng)范式中的已傳輸數(shù)據(jù)和修飾符等方面的信息；
　　HTTP/1.1(RFC2616) 的要求更加嚴(yán)格以確保服務(wù)的可靠性，增強(qiáng)了在HTTP/1.0 沒有充分考慮到分層代理服務(wù)器、高速緩沖存儲(chǔ)器、持久連接需求或虛擬主機(jī)等方面的效能；
　　安全增強(qiáng)版的 HTTP （即S-HTTP或HTTPS），則是HTTP協(xié)議與安全套接口層(SSL)的結(jié)合，使HTTP的協(xié)議數(shù)據(jù)在傳輸過程中更加安全。

??端口對(duì)應(yīng)的服務(wù)
?? ?21?? ??? ?ftp
?? ?22?? ??? ?ssh sftp
?? ?25?? ??? ?smtp
?? ?3306?? ?mysql
??? 873?? ?? rsync
?? ?161?? ?? snmp
?? ?111?? ?? rpc
?? ?3389?? ?windows 遠(yuǎn)程桌面
?? ?80?? ??? ?http
?? ?443?? ?? https
?? ?110?? ?? pop3
?? ?55?? ??? ?dns

協(xié)議結(jié)構(gòu)

HTTP協(xié)議格式也比較簡單，格式如下：

?

請(qǐng)求頭格式

a) 通用頭(general-header)：
Cache-Control：客戶端希望服務(wù)端如何緩存自己的請(qǐng)求數(shù)據(jù)。
Connection：客戶端是否希望與服務(wù)端之間保持長連接。
Date：只有當(dāng)請(qǐng)求方法為POST或get方法時(shí)客戶端才可能會(huì)有些字段。
Pragma：包含了客戶端一些特殊請(qǐng)求信息。
?

b) 請(qǐng)求頭(request-header)：
Accept： 表明客戶同端可接受的請(qǐng)求回應(yīng)的媒體類型范圍列表?！?”用于按范圍將類型分組，用“*/*”指示可接受全部類型；用“type/*”指示可接受 type類型的所有子類型，
Accept-Charset：客戶端所能識(shí)別的字符集編碼格式，格式：“Accept-Charset: 字符集1[:權(quán)重]，字符集2[:權(quán)重]”，如：“ Accept-Charset: iso-8859-5, unicode-1-1;q=0.8”；
Accept-Language：客戶端所能識(shí)別的語言，格式：“Accept-Language: 語言1[:權(quán)重]，語言2[:權(quán)重]”，如：” Accept-Language: zh, en;q=0.7”；
Host：客戶請(qǐng)求的主機(jī)域名或主機(jī)IP，格式：“Host: 域名或IP[:端口號(hào)]”，如：“Host: www.mysq.com:80“，請(qǐng)求行中若有HTTP/1.1則必須有該請(qǐng)求頭；
User-Agent：表明用戶所使用的瀏覽器標(biāo)識(shí)，主要用于統(tǒng)計(jì)的目的；
Referer：指明該請(qǐng)求是從哪個(gè)關(guān)聯(lián)連接而來；

Accept-Encoding：客戶端所能識(shí)別的編碼壓縮格式，如：“Accept-Encoding: gzip, deflate”。
If- Modified-Since：該字段與客戶端緩存相關(guān)，客戶端所訪問的URL自該指定日期以來在服務(wù)端是否被修改過，如果修改過則服務(wù)端返回新的修改后 的信息，如果未修改過則服務(wù)器返回304表明此請(qǐng)求所指URL未曾修改過。
If-None-Match：該字段與客戶端緩存相關(guān)，客戶端發(fā)送URL請(qǐng)求的同時(shí)發(fā)送該字段及標(biāo)識(shí)，如 果服務(wù)端的標(biāo)識(shí)與客戶端的標(biāo)識(shí)一致，則返回304表明此URL未修改過，如果不一致則服務(wù)端返回完整的數(shù)據(jù)信息，如：“If-None-Match: 0f0a893aad8c61:253, 0f0a893aad8c61:252, 0f0a893aad8c61:251”；
Cookie：為擴(kuò)展字段，存儲(chǔ)于客戶端，向同一域名的服務(wù)端發(fā)送屬于該域的cookie，如：“Cookie: MailUserName=whouse”；

?

c) 實(shí)體頭(entity-header): (此類頭存在時(shí)要求有數(shù)據(jù)體)
Content-Encoding：客戶端所能識(shí)別的編碼壓縮格式，如：“Content-Encoding: gzip, deflate”；
Content-Length：客戶端以POST方法上傳數(shù)據(jù)時(shí)數(shù)據(jù)體部分的內(nèi)容長度，如：“ Content-Length: 24”；
Content- Type：客戶端發(fā)送的數(shù)據(jù)體的內(nèi)容類型，如：“Content-Type: application/x-www-form-urlencoded”為以普通的POST方法發(fā)送的數(shù)據(jù)；“Content-Type: multipart/form-data; boundary=---------------------------5169208281820”，則表明數(shù)據(jù)體由多部分組成，分隔符為 “-----------------------------5169208281820”；

?

響應(yīng)格式

?

a) 通用頭(general-header)：
Cache- Control：服務(wù)端要求中間代理及客戶端如何緩存自己響應(yīng)的數(shù)據(jù)，如“Cache-Control: no-cache”，如：“Cache-Control: private” 不希望被緩存，“Cache-Control: public” 可以被緩存；
Connection：服務(wù)端是否希望與客戶端之間保持長連接，；
Date：只有當(dāng)請(qǐng)求方法為POST或get方法時(shí)客戶端才可能會(huì)有些字段；
Pragma：包含了服務(wù)端一些特殊響應(yīng)信息，如 “Pragma: no-cache” 服務(wù)端希望代理或客戶端不應(yīng)緩存結(jié)果數(shù)據(jù)；
Transfer-Encoding：服務(wù)端向客戶端傳輸數(shù)據(jù)所采用的傳輸模式(僅在HTTP1.1中出現(xiàn))，如：“Transfer-Encoding: chunked”，注：該字段的優(yōu)先級(jí)要高于“Content-Length”　字段的優(yōu)先級(jí)；

Via：一般用在代理網(wǎng)關(guān)向應(yīng)用服務(wù)器發(fā)送的請(qǐng)求頭中，表明該來自客戶端的請(qǐng)求經(jīng)過了網(wǎng)關(guān)代理，
???? 格式為："Via: 請(qǐng)求協(xié)議版本? 網(wǎng)關(guān)標(biāo)識(shí)?? [其它信息] "，
???? 如 ：" Via: 1.1? webcache_250_199.hexun.com:80 (squid)"

?

b）響應(yīng)頭(response-header)：
Accept-Ranges：表明服務(wù)端接收的數(shù)據(jù)單位，如：“Accept-Ranges: bytes”, ；
Location：服務(wù)端向客戶端返回此信息以使客戶端進(jìn)行重定向，如：“Location: http://www.hexun.com”；
Server：服務(wù)端返回的用于標(biāo)識(shí)自己的一些信息，如：“ Server: Microsoft-IIS/6.0”；
ETag：服務(wù)端返回的響應(yīng)數(shù)據(jù)的標(biāo)識(shí)字段，客戶端可根據(jù)此字段的值向服務(wù)器發(fā)送某URL是否更新的信息；

?

c）實(shí)體頭(entity-header): (此類頭存在時(shí)要求有數(shù)據(jù)體)
Content-Encoding：服務(wù)端所響應(yīng)數(shù)據(jù)的編碼格式。
Content-Length：服務(wù)端所返回?cái)?shù)據(jù)的數(shù)據(jù)體部分的內(nèi)容長度。
Content-Type：服務(wù)端所返回的數(shù)據(jù)體的內(nèi)容類型。
Set-Cookie：服務(wù)端返回給客戶端的cookie數(shù)據(jù)。

服務(wù)器返回狀態(tài)碼

1xx：表明服務(wù)端接收了客戶端請(qǐng)求，客戶端繼續(xù)發(fā)送請(qǐng)求；
2xx：客戶端發(fā)送的請(qǐng)求被服務(wù)端成功接收并成功進(jìn)行了處理；
3xx：服務(wù)端給客戶端返回用于重定向的信息；
4xx：客戶端的請(qǐng)求有非法內(nèi)容；
5xx：服務(wù)端未能正常處理客戶端的請(qǐng)求而出現(xiàn)意外錯(cuò)誤。

?比如：

“100”? ; 服務(wù)端希望客戶端繼續(xù)；
“200”? ; 服務(wù)端成功接收并處理了客戶端的請(qǐng)求；
“301”? ; 客戶端所請(qǐng)求的URL已經(jīng)移走，需要客戶端重定向到其它的URL；
“304”? ; 客戶端所請(qǐng)求的URL未發(fā)生變化；
“400”? ; 客戶端請(qǐng)求錯(cuò)誤；
“403”? ; 客戶端請(qǐng)求被服務(wù)端所禁止；
“404”? ; 客戶端所請(qǐng)求的URL在服務(wù)端不存在；
“500”? ; 服務(wù)端在處理客戶端請(qǐng)求時(shí)出現(xiàn)異常；
“501”? ; 服務(wù)端未實(shí)現(xiàn)客戶端請(qǐng)求的方法或內(nèi)容；
“502”? ; 此為中間代理返回給客戶端的出錯(cuò)信息，表明服務(wù)端返回給代理時(shí)出錯(cuò)；
“503”? ; 服務(wù)端由于負(fù)載過高或其它錯(cuò)誤而無法正常響應(yīng)客戶端請(qǐng)求；
“504”? ; 此為中間代理返回給客戶端的出錯(cuò)信息，表明代理連接服務(wù)端出現(xiàn)超時(shí)。

?

HTTP 請(qǐng)求方法

?

GET、POST、HEAD、CONNECT、PUT、DELETE、TRACE、OPTIONS

方法描述

HEAD	與 GET 相同，但只返回 HTTP 報(bào)頭，不返回文檔主體。
PUT	上傳指定的 URI 表示。
DELETE	刪除指定資源。
OPTIONS	返回服務(wù)器支持的 HTTP 方法。
CONNECT	把請(qǐng)求連接轉(zhuǎn)換到透明的 TCP/IP 通道。

?

Html代碼??
a）GET請(qǐng)求

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請(qǐng)求?

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傳參區(qū)別吧，畢竟了解過，
　　1）get參數(shù)通過url傳遞，post放在request body中。
　　2）get請(qǐng)求在url中傳遞的參數(shù)是有長度限制的，而post沒有
　　3）get比post更不安全，因?yàn)閰?shù)直接暴露在url中，所以不能用來傳遞敏感信息。
　　4）get請(qǐng)求只能進(jìn)行url編碼，而post支持多種編碼方get請(qǐng)求會(huì)瀏覽器主動(dòng)cache，而post支持多種編碼方式。
　　5）get請(qǐng)求參數(shù)會(huì)被完整保留在瀏覽歷史記錄里，而post中的參數(shù)不會(huì)被保留。
GET和POST本質(zhì)上就是TCP鏈接，并無差別。但是由于HTTP的規(guī)定和瀏覽器/服務(wù)器的限制，導(dǎo)致他們?cè)趹?yīng)用過程中體現(xiàn)出一些不同，GET產(chǎn)生一個(gè)TCP數(shù)據(jù)包；POST產(chǎn)生兩個(gè)TCP數(shù)據(jù)包。簡單的說：

對(duì)于GET方式的請(qǐng)求，瀏覽器會(huì)把http header和data一并發(fā)送出去，服務(wù)器響應(yīng)200（返回?cái)?shù)據(jù)）；

而對(duì)于POST，瀏覽器先發(fā)送header，服務(wù)器響應(yīng)100 continue，瀏覽器再發(fā)送data，服務(wù)器響應(yīng)200 ok（返回?cái)?shù)據(jù)）。

?

總結(jié)：http協(xié)議通信原理
?? ?１、http是osi模型中應(yīng)用層協(xié)議。http協(xié)議的重要應(yīng)用是www服務(wù)。
?? ?２、DNS解析原理
?? ?３、http請(qǐng)求信息包含的內(nèi)容。
?? ?４、http服務(wù)返回的內(nèi)容，消息主體也消息頭。
?? ?５、用戶通過瀏覽器訪問站服務(wù)器的請(qǐng)求到返回?cái)?shù)據(jù)流程。

靜態(tài)網(wǎng)頁

?? ?概念：在網(wǎng)站設(shè)計(jì)中，純粹HTML格式的網(wǎng)頁（可以包含圖片，JS（前端功能實(shí)現(xiàn)），CSS（樣式）等）通常被稱為“靜態(tài)網(wǎng)頁”。
?? ?特點(diǎn)：所有程序在客戶瀏覽器端解析，客戶端如：IE瀏覽器，你編的是什么，它顯示的就是什么，一旦編寫完成，就不會(huì)有任何改變。維護(hù)和更新比較麻煩。
?? ?（1）靜態(tài)網(wǎng)頁每個(gè)頁面都有一個(gè)固定的URL，且網(wǎng)頁URL一般以.htm、.html、.shtml等常見形式為后綴，而且地址中不含問好“？”或“&”
?? ?（2）網(wǎng)頁內(nèi)容一經(jīng)發(fā)布到網(wǎng)站服務(wù)器上，無論是否有用戶訪問，每個(gè)靜態(tài)網(wǎng)頁的內(nèi)容都是保存在網(wǎng)頁服務(wù)器上的，也就是說，靜態(tài)網(wǎng)頁是實(shí)實(shí)在在保存在服務(wù)器上的文件，每個(gè)網(wǎng)頁都是一個(gè)獨(dú)立的文件
?? ?（3）靜態(tài)網(wǎng)頁的內(nèi)容相對(duì)穩(wěn)定，因此，容易被搜索引擎收錄（優(yōu)點(diǎn)，seo）
?? ?（4）靜態(tài)網(wǎng)頁沒有數(shù)據(jù)庫的支持，在網(wǎng)站制作和維護(hù)方面工作量較大，因此當(dāng)網(wǎng)站信息量很大時(shí)完全依靠靜態(tài)網(wǎng)頁制作的方式比較困難（缺點(diǎn)）
?? ?（5）靜態(tài)網(wǎng)頁的交互性較差，在功能方面有較大的限制（缺點(diǎn)）
?? ?（6）網(wǎng)頁程序在用戶瀏覽器端解析，如IE瀏覽器，這樣程序解析效率更高，由于服務(wù)端不進(jìn)行解析，因此可以接受更多的并發(fā)訪問，當(dāng)客戶端向服務(wù)器請(qǐng)求數(shù)據(jù)時(shí)，服務(wù)器直接把數(shù)據(jù)返回（不做任何解析），當(dāng)客戶端拿到數(shù)據(jù)后，在瀏覽器端解析展現(xiàn)出來。

動(dòng)態(tài)網(wǎng)頁?

擴(kuò)展名：常見擴(kuò)展名為asp,aspx,php,jsp,cgi,perl等

?? ?（1）動(dòng)態(tài)網(wǎng)頁一般以數(shù)據(jù)庫技術(shù)為基礎(chǔ)，可以大大降低網(wǎng)站的維護(hù)工作量
?? ?（2）采用動(dòng)態(tài)網(wǎng)頁技術(shù)的網(wǎng)站可以實(shí)現(xiàn)更多的功能，如用戶注冊(cè)，用戶登錄，在線調(diào)查，投票，用戶管理，訂單管理，發(fā)博文等等
?? ?（3）動(dòng)態(tài)網(wǎng)頁大多并不是獨(dú)立存在于服務(wù)器上的網(wǎng)頁文件，只有當(dāng)用戶請(qǐng)求時(shí)服務(wù)器才返回一個(gè)完整的網(wǎng)頁
?? ?（4）動(dòng)態(tài)網(wǎng)頁中的“?”對(duì)搜索的收錄存在一定的問題，搜索引擎一般不可能從一個(gè)網(wǎng)站的數(shù)據(jù)庫中訪問全部網(wǎng)頁，或者出于技術(shù)方面的考慮，搜索蜘蛛一般不會(huì)區(qū)抓取網(wǎng)址中的“？”后面的內(nèi)容，因此采用動(dòng)態(tài)網(wǎng)頁的網(wǎng)站在進(jìn)行搜索引擎推廣時(shí)需要做一定的技術(shù)處理（偽靜態(tài)）才能適應(yīng)搜索引擎的抓取的要求
?? ?（5）程序在服務(wù)端解析，服務(wù)端：php引擎，java容器(tomcat,resin,jboss)
?? ?（6）由于程序在服務(wù)端解析，因此,會(huì)消耗大量的CPU和內(nèi)存等資源，因此，效率遠(yuǎn)不如靜態(tài)網(wǎng)頁。

偽靜態(tài)

偽靜態(tài)特點(diǎn)：從URL地址里看，給人感覺是靜態(tài)內(nèi)容（如地址結(jié)尾帶html）,通過rewrite規(guī)則實(shí)現(xiàn)URL重寫。地址規(guī)范、美觀、有利于搜索引擎抓取。

?? ?1、動(dòng)態(tài)網(wǎng)頁偽裝成靜態(tài)
?? ?2、目的：便于搜索引擎搜錄，提升用戶訪問量以及用戶體驗(yàn)。
?? ?3、由于僅僅是偽裝，實(shí)際上還是動(dòng)態(tài)，性能沒有提升，轉(zhuǎn)換消耗資源因此性能反而下降。
?? ?4、盡可能轉(zhuǎn)換成真正的靜態(tài)頁面，除非并發(fā)量不是很大，用rewrite實(shí)現(xiàn)偽靜態(tài)。

回到頂部

什么是DNS？

? ?DNS( Domain Name System)是“域名系統(tǒng)”的英文縮寫，是一種組織成域?qū)哟谓Y(jié)構(gòu)的計(jì)算機(jī)和網(wǎng)絡(luò)服務(wù)命名系統(tǒng)，它用于TCP/IP網(wǎng)絡(luò)，它所提供的服務(wù)是用來將主機(jī)名和域名轉(zhuǎn)換為IP地址的工作。DNS就是這樣的一位“翻譯官”，它的基本工作原理可用下圖來表示。

?

Dns服務(wù)的工作過程

當(dāng) DNS 客戶機(jī)需要查詢程序中使用的名稱時(shí)，它會(huì)查詢本地DNS 服務(wù)器來解析該名稱?？蛻魴C(jī)發(fā)送的每條查詢消息都包括3條信息，以指定服務(wù)器應(yīng)回答的問題。
1）?指定的 DNS 域名，表示為完全合格的域名 (FQDN) 。
2）?指定的查詢類型，它可根據(jù)類型指定資源記錄，或作為查詢操作的專門類型。
3）?DNS域名的指定類別，它始終應(yīng)指定為 Internet 類別。
??? DNS 查詢以各種不同的方式進(jìn)行解析。客戶機(jī)有時(shí)也可通過使用從以前查詢獲得的緩存信息就地應(yīng)答查詢。DNS 服務(wù)器可使用其自身的資源記錄信息緩存來應(yīng)答查詢，也可代表請(qǐng)求客戶機(jī)來查詢或聯(lián)系其他 DNS 服務(wù)器，以完全解析該名稱，并隨后將應(yīng)答返回至客戶機(jī)。這個(gè)過程稱為遞歸。
??? 另外，客戶機(jī)自己也可嘗試聯(lián)系其他的 DNS 服務(wù)器來解析名稱。如果客戶機(jī)這么做，它會(huì)使用基于服務(wù)器應(yīng)答的獨(dú)立和附加的查詢，該過程稱作迭代，即DNS服務(wù)器之間的交互查詢就是迭代查詢。

DNS解析流程圖（來源于網(wǎng)絡(luò)）

1、在瀏覽器中輸入www.baidu.com域名，操作系統(tǒng)會(huì)先檢查自己本地的hosts文件是否有這個(gè)網(wǎng)址映射關(guān)系，如果有，就先調(diào)用這個(gè)IP地址映射，完成域名解析。?

2、如果hosts里沒有這個(gè)域名的映射，則查找本地DNS解析器緩存，是否有這個(gè)網(wǎng)址映射關(guān)系，如果有，直接返回，完成域名解析。?

3、如果hosts與本地DNS解析器緩存都沒有相應(yīng)的網(wǎng)址映射關(guān)系，首先會(huì)找TCP/ip參數(shù)中設(shè)置的首選DNS服務(wù)器，在此我們叫它本地DNS服務(wù)器，此服務(wù)器收到查詢時(shí)，如果要查詢的域名，包含在本地配置區(qū)域資源中，則返回解析結(jié)果給客戶機(jī)，完成域名解析，此解析具有權(quán)威性。?

4、如果要查詢的域名，不由本地DNS服務(wù)器區(qū)域解析，但該服務(wù)器已緩存了此網(wǎng)址映射關(guān)系，則調(diào)用這個(gè)IP地址映射，完成域名解析，此解析不具有權(quán)威性。?

5、如果本地DNS服務(wù)器本地區(qū)域文件與緩存解析都失效，則根據(jù)本地DNS服務(wù)器的設(shè)置（是否設(shè)置轉(zhuǎn)發(fā)器）進(jìn)行查詢，如果未用轉(zhuǎn)發(fā)模式，本地DNS就把請(qǐng)求發(fā)至根DNS，根DNS服務(wù)器收到請(qǐng)求后會(huì)判斷這個(gè)域名(.com)是誰來授權(quán)管理，并會(huì)返回一個(gè)負(fù)責(zé)該頂級(jí)域名服務(wù)器的一個(gè)IP。本地DNS服務(wù)器收到IP信息后，將會(huì)聯(lián)系負(fù)責(zé).com域的這臺(tái)服務(wù)器。這臺(tái)負(fù)責(zé).com域的服務(wù)器收到請(qǐng)求后，如果自己無法解析，它就會(huì)找一個(gè)管理.com域的下一級(jí)DNS服務(wù)器地址(baidu.com)給本地DNS服務(wù)器。當(dāng)本地DNS服務(wù)器收到這個(gè)地址后，就會(huì)找baiducom域服務(wù)器，重復(fù)上面的動(dòng)作，進(jìn)行查詢，直至找到www.qq.com主機(jī)。?

6、如果用的是轉(zhuǎn)發(fā)模式，此DNS服務(wù)器就會(huì)把請(qǐng)求轉(zhuǎn)發(fā)至上一級(jí)DNS服務(wù)器，由上一級(jí)服務(wù)器進(jìn)行解析，上一級(jí)服務(wù)器如果不能解析，或找根DNS或把轉(zhuǎn)請(qǐng)求轉(zhuǎn)至上上級(jí)，以此循環(huán)。不管是本地DNS服務(wù)器用是是轉(zhuǎn)發(fā)，還是根提示，最后都是把結(jié)果返回給本地DNS服務(wù)器，由此DNS服務(wù)器再返回給客戶機(jī)。

技術(shù)的提升是量的積累,思想的提升是質(zhì)的飛越

總結(jié)

以上是生活随笔為你收集整理的Http与WWW服务精解的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。