|
用戶在web瀏覽器（如IE）地址欄輸入URL（統(tǒng)一資源定位符）“youngyl.360doc.com”，然后回車： 一.通過DNS服務(wù)器將域名解析為IP地址（假設(shè)DNS和我們的主機在一個網(wǎng)段）： （一）用戶主機向其本地域名服務(wù)器發(fā)出DNS請求報文： （主機向本地域名服務(wù)器的查詢采用的是遞歸查詢） 1.主機應(yīng)用程序（瀏覽器）產(chǎn)生一個DNS請求報文（應(yīng)用層），將請求傳遞給傳輸層。 2.傳輸層通過UDP（User Datagram Protocol，用戶數(shù)據(jù)報協(xié)議）或TCP（Transmission Control Protocol，傳輸控制協(xié)議）把DNS請求報文封裝成用戶數(shù)據(jù)報（UDP）或報文段（TCP），再傳遞給網(wǎng)絡(luò)層。 3.網(wǎng)絡(luò)層把傳輸層傳下來的信息當(dāng)作數(shù)據(jù)部分，加上自己的頭部，將其封裝成IP數(shù)據(jù)報（如果太長要切分成IP數(shù)據(jù)報片），IP數(shù)據(jù)報的源地址是當(dāng)前主機IP地址，目的地址是本地域名服務(wù)器的IP地址，通過ARP（Address Resolution Protocol，地址解析協(xié)議）協(xié)議得到DNS服務(wù)器的MAC地址（一說是在數(shù)據(jù)鏈路層，注1），然后把IP數(shù)據(jù)報傳送給數(shù)據(jù)鏈路層。 4.數(shù)據(jù)鏈路層（三個基本問題：封裝成幀，透明傳輸，差錯檢測）將網(wǎng)絡(luò)層傳下來的IP數(shù)據(jù)報組裝成幀，以后把數(shù)據(jù)幀通過以太網(wǎng)傳輸給DNS服務(wù)器（本地域名服務(wù)器）。 5.DNS服務(wù)器再將收到的幀向上傳給傳輸層，得到UDP（TCP）報文。通過UDP（TCP）報文中指定的端口號傳給DNS應(yīng)用程序。 6.本地域名服務(wù)器收到請求后，查詢本地緩存（高速緩存），如果要解析的域名在當(dāng)前的DNS服務(wù)器中有相應(yīng)的表項，DNS服務(wù)器通過DNS應(yīng)答將得到的IP地址返回給請求的主機。如果沒有記錄，本地DNS服務(wù)器還要向上級的DNS服務(wù)器發(fā)出DNS查詢請求（以DNS客戶的身份向根域名服務(wù)器發(fā)出解析請求，本地域名服務(wù)器向根域名服務(wù)器的查詢采用迭代查詢）：（1）根域名服務(wù)器收到請求后，判斷該域名屬于.com域，將對應(yīng)的頂級域名服務(wù)器dns.com的IP地址返回給本地域名服務(wù)器。（2）本地DNS服務(wù)器向頂級域名服務(wù)器dns.com發(fā)出解析請求報文。（3）頂級域名服務(wù)器dns.com收到請求后，判斷該域名屬于360doc.com域，故將對應(yīng)的授權(quán)（權(quán)限）域名服務(wù)器dns.360doc.com的IP地址返回給本地域名服務(wù)器。（4）本地DNS域名服務(wù)器向授權(quán)域名服務(wù)器dns.360doc.com發(fā)起解析請求報文。（5）授權(quán)域名服務(wù)器dns.360.com收到請求后，將查詢結(jié)果返回本地域名服務(wù)器。（6）本地域名服務(wù)器將查詢結(jié)果保存到本地緩存，同時返回給客戶機。 （二）此時雖然瀏覽器得到對方的IP地址了，但仍不能發(fā)出請求。 要和對方服務(wù)器建立一個TCP（傳輸控制協(xié)議，TCP和UDP同屬傳輸層，但是TCP協(xié)議是個可靠的面向連接的協(xié)議，要比UDP復(fù)雜的多。TCP更適合要求可靠傳輸?shù)膽?yīng)用。）連接。 建立連接通過三次握手方法（注2），這里和以下發(fā)送的TCP報文同樣要傳給下一層：網(wǎng)絡(luò)層。同樣的，IP層給TCP報文加上IP報頭，發(fā)送給路由器（假設(shè)主機和web服務(wù)器不在同一個網(wǎng)內(nèi)），路由器根據(jù)報文中的目的IP地址決定下一跳的IP地址和端口。這個決定需要查詢它自身的路由表（而路由表的維護需要路由協(xié)議，比如OSPF等）。IP報文可能通過多個路由器的轉(zhuǎn)發(fā)，終于到達了對方的服務(wù)器。再剝掉IP報頭遞交給上層。 建立好了TCP連接，以后發(fā)送的數(shù)據(jù)都可以這條可靠的連接傳輸了。和WEB服務(wù)器之間的TCP連接建立成功。就可以發(fā)送請求了。下一步用HTTP協(xié)議請求網(wǎng)頁內(nèi)容。WEB服務(wù)器收到請求，就可以將HTTP響應(yīng)信息通過剛才建立好的TCP連接送回給請求方。 （三）通過以上過程的描述我們可以發(fā)現(xiàn)，在發(fā)出web請求后所需要的協(xié)議有： hｔｔｐ協(xié)議、用戶數(shù)據(jù)報協(xié)議、地址解析協(xié)議、TCP協(xié)議、路由協(xié)議和IP協(xié)議。它們的作用分別是，http協(xié)議：超文本傳送協(xié)議 (HTTP) 是一種通信協(xié)議，它允許將超文本標記語言 (HTML) 文檔從Web 服務(wù)器傳送到 Web 瀏覽器。HTML 是一種用于創(chuàng)建文檔的標記語言，這些文檔包含到相關(guān)信息的鏈接。您可以單擊一個鏈接來訪問其它文檔、圖像或多媒體對象，并獲得關(guān)于鏈接項的附加信息。HTTP工作在TCP/IP協(xié)議體系中的TCP協(xié)議上。 用戶數(shù)據(jù)報協(xié)議（ＵＤＰ）：U D P是一個簡單的面向數(shù)據(jù)報的運輸層協(xié)議，進程的每個輸出操作都正好產(chǎn)生一個U D P數(shù)據(jù)報，并組裝成一份待發(fā)送的I P數(shù)據(jù)報，提供面向事務(wù)的簡單不可靠信息傳送服務(wù)。 地址解析協(xié)議（ARP）：實現(xiàn)通過IP地址得知其物理地址。在TCP/IP網(wǎng)絡(luò)環(huán)境下，每個主機都分配了一個32位的IP地址。為了讓報文在物理網(wǎng)路上傳送，必須知道對方目的主機的物理地址。這樣就存在把IP地址變換成物理地址的地址轉(zhuǎn)換問題。就比如以太網(wǎng)環(huán)境，為了正確地向目的主機傳送報文，必須把目的主機的32位IP地址轉(zhuǎn)換成為48位以太網(wǎng)的地址。這就需要在互連層有一組服務(wù)將IP地址轉(zhuǎn)換為相應(yīng)物理地址，這組協(xié)議就是ARP協(xié)議。 路由協(xié)議：路由協(xié)議通過在路由器之間共享路由信息來支持可路由協(xié)議。路由信息在相鄰路由器之間傳遞，確保所有路由器知道到其它路由器的路徑?？傊酚蓞f(xié)議創(chuàng)建了路由表，描述了網(wǎng)絡(luò)拓撲結(jié)構(gòu)；路由協(xié)議與路由器協(xié)同工作，執(zhí)行路由選擇和數(shù)據(jù)包轉(zhuǎn)發(fā)功能。 TCP協(xié)議和IP協(xié)議組成一個體系，即TCP/IP協(xié)議（TCP傳輸控制協(xié)議和IP互聯(lián)網(wǎng)協(xié)議），它由網(wǎng)絡(luò)層的IP協(xié)議和傳輸層的TCP協(xié)議組成, TCP/IP 定義了電子設(shè)備如何連入因特網(wǎng)，以及數(shù)據(jù)如何在它們之間傳輸?shù)臉藴?。協(xié)議采用了4層的層級結(jié)構(gòu)，每一層都呼叫它的下一層所提供的網(wǎng)絡(luò)來完成自己的需求。通俗而言：TCP負責(zé)發(fā)現(xiàn)傳輸?shù)膯栴}，一有問題就發(fā)出信號，要求重新傳輸，直到所有數(shù)據(jù)安全正確地傳輸?shù)侥康牡?。而IP是給因特網(wǎng)的每一臺電腦規(guī)定一個地址。 注1：在OSI模型中ARP協(xié)議屬于鏈路層；而在TCP/IP模型中，ARP協(xié)議屬于網(wǎng)絡(luò)層。 1)ARP分層的位置是TCP/IP的網(wǎng)絡(luò)層 2)ARP報文是由以太網(wǎng)幀進行封裝傳輸?shù)?。沒有封裝進IP包。 3）實際上，對網(wǎng)絡(luò)接口層的以太網(wǎng)幀來講，它們同樣是幀的上層協(xié)議，當(dāng)收到以太幀 時，根據(jù)幀的協(xié)議字段判斷是送到ARP還是IP。 4）之所以不把它放在數(shù)據(jù)鏈路層，是因為它并不具備數(shù)據(jù)鏈路層的功能，它的作用是 為數(shù)據(jù)鏈路層提供接收方的幀地地址。 另外，我也建議讀《TCP/IP詳解》卷一里面有 圖，明確它的位置屬于網(wǎng)絡(luò)層（畫的時候，ARP，RARP畫在IP層稍下端，而ICMP和I GMP畫在IP層的上部，因為這二個協(xié)議是由IP進行封裝的。）  注2：TCP頭部： 其中 ACK SYN 序號 這三個部分在以下會用到，它們的介紹也在下面。
暫時需要的信息有： ACK ： TCP協(xié)議規(guī)定，只有ACK=1時有效，也規(guī)定連接建立后所有發(fā)送的報文的ACK必須為1 SYN(SYNchronization) ： 在連接建立時用來同步序號。當(dāng)SYN=1而ACK=0時，表明這是一個連接請求報文。對方若同意建立連接，則應(yīng)在響應(yīng)報文中使SYN=1和ACK=1. 因此, SYN置1就表示這是一個連接請求或連接接受報文。 FIN （finis）即完，終結(jié)的意思， 用來釋放一個連接。當(dāng) FIN = 1 時，表明此報文段的發(fā)送方的數(shù)據(jù)已經(jīng)發(fā)送完畢，并要求釋放連接。
三次握手的過程：
首先由Client發(fā)出請求連接即 SYN=1 ACK=0 (請看頭字段的介紹), TCP規(guī)定SYN=1時不能攜帶數(shù)據(jù)，但要消耗一個序號,因此聲明自己的序號是 seq=x 然后 Server 進行回復(fù)確認，即 SYN=1 ACK=1 seq=y, ack=x+1, 再然后 Client 再進行一次確認，但不用SYN 了，這時即為 ACK=1, seq=x+1, ack=y+1. 然后連接建立，為什么要進行三次握手呢（兩次確認）。
下面是釋放連接的過程：
當(dāng)客戶A 沒有東西要發(fā)送時就要釋放 A 這邊的連接，A會發(fā)送一個報文（沒有數(shù)據(jù)），其中 FIN 設(shè)置為1, 服務(wù)器B收到后會給應(yīng)用程序一個信，這時A那邊的連接已經(jīng)關(guān)閉，即A不再發(fā)送信息（但仍可接收信息）。 A收到B的確認后進入等待狀態(tài)，等待B請求釋放連接， B數(shù)據(jù)發(fā)送完成后就向A請求連接釋放，也是用FIN=1 表示， 并且用 ack = u+1(如圖）， A收到后回復(fù)一個確認信息，并進入 TIME_WAIT 狀態(tài)， 等待 2MSL 時間。 為什么要等待呢？ 為了這種情況： B向A發(fā)送 FIN = 1 的釋放連接請求，但這個報文丟失了， A沒有接到不會發(fā)送確認信息， B 超時會重傳，這時A在 WAIT_TIME 還能夠接收到這個請求，這時再回復(fù)一個確認就行了。（A收到 FIN = 1 的請求后 WAIT_TIME會重新記時） 另外服務(wù)器B存在一個?；顮顟B(tài)，即如果A突然故障死機了，那B那邊的連接資源什么時候能釋放呢？ 就是保活時間到了后，B會發(fā)送探測信息， 以決定是否釋放連接。 |
|
|
