【導(dǎo)讀】服務(wù)和流媒體服務(wù)。其中服務(wù)能提供閱讀和瀏覽功能，ftp服務(wù)能夠提供文件的上傳和下載功能，流。師的指導(dǎo)下進行的研究工作及取得的成果。盡我所知，除文中特別加。而使用過的材料。究所取得的研究成果。除了文中特別加以標(biāo)注引用的內(nèi)容外，本論文。不包含任何其他個人或集體已經(jīng)發(fā)表或撰寫的成果作品。究做出重要貢獻的個人和集體，均已在文中以明確方式標(biāo)明。全意識到本聲明的法律后果由本人承擔(dān)。同意學(xué)校保留并向國家有關(guān)部門或機構(gòu)送交論文的復(fù)印件和電子版，允許論文被查閱和借閱。本人授權(quán)大學(xué)可以將本學(xué)位。印或掃描等復(fù)制手段保存和匯編本學(xué)位論文。涉密論文按學(xué)校規(guī)定處理。程序清單等），文科類論文正文字?jǐn)?shù)不少于萬字。有圖紙應(yīng)符合國家技術(shù)標(biāo)準(zhǔn)規(guī)范。圖表整潔，布局合理，文字注釋必須使用工程。設(shè)計是否有創(chuàng)意？

　　

【正文】 行編碼來保證數(shù)據(jù)的機密性，以防數(shù)據(jù)在傳輸過程中被他人截獲而失密。 IPSec 的認(rèn)證報頭（ Authentication Header， AH）協(xié)議定義了認(rèn)證的應(yīng)用方法，安全負(fù)載封裝（ Encapsulating Security Payload， ESP）協(xié)議定義了加 密和可選認(rèn)證的應(yīng)用方法。在實際進行 IP 通信時，可以根據(jù)安全需求同時使用這兩種協(xié)議或選擇使用其中的一種。 AH和 ESP 都可以提供認(rèn)證服務(wù)，不過， AH提供的認(rèn)證服務(wù)要強于 ESP。 做為 IPv6 的一個組成部分， IPSec 是一個網(wǎng)絡(luò)層協(xié)議。它從底層開始實施安全策略，避免了數(shù)據(jù)傳輸（直至應(yīng)用層）中的安全問題。但它只負(fù)責(zé)其下層的網(wǎng)絡(luò)安全，并不負(fù)責(zé)其上層應(yīng)用的安全，如 Web、電子郵件和文件傳輸?shù)取? 作為 IPSec 的一項重要應(yīng)用， IPv6 集成了虛擬專用網(wǎng)（ VPN）的功能，使用 IPv6 可以更容易地、實現(xiàn)更為安全可靠的虛擬專用網(wǎng) 。 域名解析 在 IPv6 中，域名的體系結(jié)構(gòu)仍然保持了 IPv4 的層次原理。而且 IPv6 地址本身的層級體系也就更加支持了域名解析體系中的地址集聚和地址更改。同樣，在 IPv6 的域名解析中包括了正向解析和反向解析。正向解析是從域名到 IP 地址的解釋。 IPv6 地址的正向解析目前有兩種資源記錄，即“ AAAA”和“ A6”記錄。其中“ AAAA”較早提出，它是對 IPv4 協(xié)議“ A”錄的簡單擴展，由于 IP 地址由 32 位擴展到 128 位，擴大了 4倍，所以資源記錄由“ A”擴大成 4個“ A”。但“ AAAA”用來表示域名和 IPv6 地 址的對應(yīng)關(guān)系，并不支持地址的層次性。“ A6”是在 RFC2874 基礎(chǔ)上提出，它是把一個 IPv6 地址根據(jù)其本身的層次性分解，然后多個“ A6”記錄建立聯(lián)系，每個“ A6”記錄都只包含了 IPv6 地址的一部分，結(jié)合后拼裝成一個完整的 IPv6 地址。反向解析則是從 IP 地址到域名的解釋。它與 IPv4 的“ PTR”一樣，但地址表示形式有兩種。一種是用“ .”分隔的半字節(jié) 16進制數(shù)字格式（ Nibble Format），低位地址在前，高位地址在后，域后綴是“ .”。另一種是二進制串（ Bitstring）格式，以“ \[”開 頭， 16 進制地址（無分隔符，高位在前，低位在后）居中，地址后加“ ]”，域后綴是“ .”。 在移動過程中的 DNS 根據(jù)“無狀態(tài)”和“有狀態(tài)”兩種地址配置方式，也分為“無狀態(tài)”和“有狀態(tài)”兩類。在無狀態(tài)的方式下，需要為子網(wǎng)內(nèi)部的 DNS 服務(wù)器配置站點范圍內(nèi)的任播地址。要進行自動配置的節(jié)點以該任播地址為目的地址發(fā)送服務(wù)器發(fā)現(xiàn)請求，詢問 DNS 服務(wù)器地址、域名和搜索路徑等 DNS 信息。這個請求到達距離最近的 DNS 服務(wù)器，服務(wù)器根據(jù)請求，回答 DNS 服務(wù)器單播地址、域名和搜索路徑等 DNS 信息。節(jié)點根據(jù)服務(wù)器的應(yīng)答 配置本機 DNS信息，以后的 DNS 請求就直接用單播地址發(fā)送給 DNS 服務(wù)器。當(dāng)然，也可以不采取任播地址的方法，但是相對來說，從安全性等問題上考慮，一般采取此種方式。在有狀態(tài)的DNS服務(wù)器發(fā)現(xiàn)方式下，是通過類似 DHCP 這樣額外的服務(wù)器把 DNS服務(wù)器地址、域名和搜索路徑等 DNS 信息告訴節(jié)點。 第二 章 IPv6 的 服務(wù)分析 協(xié)議簡介 協(xié)議 簡介 我們在瀏覽器的地址欄里輸入的網(wǎng)站地址叫做 URL(Uniform Resource Locator，統(tǒng)一資源定位符 )。就像每家每戶都 有一個門牌地址一樣，每個網(wǎng)頁也都有一個 Inter 地址。當(dāng)你在瀏覽器的地址框中輸入一個 URL 或是單擊一個超級鏈接時， URL 就確定了要瀏覽的地址。瀏覽器通過超文本傳輸協(xié)議 (HTTP)，將 Web 服務(wù)器上站點的網(wǎng)頁代碼提取出來，并翻譯成漂亮的網(wǎng)頁。因此，在我們認(rèn)識 HTTP 之前，有必要先弄清楚 URL 的組成 ,例如： 1. 服務(wù)器顯示 Web 頁，通常不用輸 入； ：代表一個 Web(萬維網(wǎng) )服務(wù)器； ：這是裝有網(wǎng)頁的服務(wù)器的域名，或站點服務(wù)器的名稱； ：為該服務(wù)器上的子目錄，就好像我們的文件夾； ： 是文件夾中的一個 HTML 文件 (網(wǎng)頁 )。 我們知道， Inter 的基本協(xié)議是 TCP/IP 協(xié)議，然而在 TCP/IP 模型最上層的是應(yīng)用層 (Application Layer)，它包含所有高層的協(xié)議。高層協(xié)議有：文件傳輸協(xié)議 FTP、電子郵件傳輸協(xié)議 SMTP、域名系統(tǒng)服務(wù) DNS、網(wǎng)絡(luò)新聞傳輸 協(xié)議 NNTP 和 HTTP 協(xié)議等。 HTTP 協(xié)議 (Hypertext Transfer Protocol，超文本傳輸協(xié)議 )是用于從 WWW 服務(wù)器傳輸超文本到本地瀏覽器的傳送協(xié)議。它可以使瀏覽器更加高效，使網(wǎng)絡(luò)傳輸減少。它不僅保證計算機正確快速地傳輸超文本文檔，還確定傳輸文檔中的哪一部分，以及哪部分內(nèi)容首先顯示 (如文本先于圖形 )等。這就是你為什么在瀏覽器中看到的網(wǎng)頁地址都是以“ 開頭的原因。 自 WWW 誕生以來，一個多姿多彩的資訊和虛擬的世界便出現(xiàn)在我們眼前，可是我們怎么能夠更加容易地 找到我們需要的資訊呢？當(dāng)決定使用超文本作為 WWW 文檔的標(biāo)準(zhǔn)格式后，于是在 1990 年，科學(xué)家們立即制定了能夠快速查找這些超文本文檔的協(xié)議，即 HTTP 協(xié)議。經(jīng)過幾年的使用與發(fā)展，得到不斷的完善和擴展，目前在 WWW 中使用的是 HTTP/ 的第六版。，它是支持 IPv6 的。 協(xié)議的運做方式 HTTP 協(xié)議是基于請求 /響應(yīng)范式的。一個客戶機與服務(wù)器建立連接后，發(fā)送一個請求給服務(wù)器，請求方式的格式為，統(tǒng)一資源標(biāo)識符、協(xié)議版本號，后邊是 MIME 信息包括請求修飾符、客戶機信息和可能的內(nèi)容。服務(wù)器接到請求后 ，給予相應(yīng)的響應(yīng)信息，其格式為一個狀態(tài)行包括信息的協(xié)議版本號、一個成功或錯誤的代碼，后邊是 MIME 信息包括服務(wù)器信息、實體信息和可能的內(nèi)容。 許多 HTTP 通訊是由一個用戶代理初始化的并且包括一個申請在源服務(wù)器上資源的請求。最簡單的情況可能是在用戶代理 (UA)和源服務(wù)器 (O)之間通過一個單獨的連接來完成 (見圖 )。 圖 當(dāng)一個或多個中介出現(xiàn)在請求／響應(yīng)鏈中時，情況就變得復(fù)雜一些。中介由三種：代理(Proxy)、網(wǎng) 關(guān) (Gateway)和通道 (Tunnel)。一個代理根據(jù) URI 的絕對格式來接受請求，重寫全部或部分消息，通過 URI 的標(biāo)識把已格式化過的請求發(fā)送到服務(wù)器。網(wǎng)關(guān)是一個接收代理，作為一些其它服務(wù)器的上層，并且如果必須的話，可以把請求翻譯給下層的服務(wù)器協(xié)議。一個通道作為不改變消息的兩個連接之間的中繼點。當(dāng)通訊需要通過一個中介 (例如：防火墻等 )或者是中介不能識別消息的內(nèi)容時，通道經(jīng)常被使用。圖 圖 上面的圖 表明了在用戶代理 (UA)和源服務(wù)器 (O)之間有三個中介 (A,B 和 C)。一個通過整個鏈的請求或響應(yīng)消息必須經(jīng)過四個連接段。這個區(qū)別是重要的，因為一些 HTTP 通訊選擇可能應(yīng)用于最近的連接、沒有通道的鄰居，應(yīng)用于鏈的終點或應(yīng)用于沿鏈的所有連接。盡管圖 是線性的，每個參與者都可能從事多重的、并發(fā)的通訊。例如， B可能從許多 客戶機接收請求而不通過 A，并且 /或者不通過 C 把請求送到 A，在同時它還可能處理 A 的請求。 任何針對不作為通道的匯聚可能為處理請求啟用一個內(nèi)部緩存。 緩存的效果是請求 /響應(yīng)鏈被縮短，條件是沿鏈的參與者之一具有一個緩存的響應(yīng)作用于那個請求。下圖說明結(jié)果鏈，其條件是針對一個未被 UA 或 A 加緩存的請求， B有一個經(jīng)過 C來自 O 的一個前期響應(yīng)的緩存拷貝。圖 圖 在 Inter 上， HTTP 通訊通常發(fā)生在 TCP/IP 連接之上。缺省端口是 TCP80，但其它的端口也是可用的。但這并不預(yù)示著 HTTP 協(xié)議在 Inter 或其它網(wǎng)絡(luò)的其它 協(xié)議之上才能完成。 HTTP 只預(yù)示著一個可靠的傳輸。 以上簡要介紹了 HTTP 協(xié)議的宏觀運作方式，下面介紹一下 HTTP 協(xié)議的內(nèi)部操作過程。 首先，簡單介紹基于 HTTP 協(xié)議的客戶 /服務(wù)器模式的信息交換過程，如圖 所示，它分四個過程，建立連接、發(fā)送請求信息、發(fā)送響應(yīng)信息、關(guān)閉連接。 圖 在 WWW 中，“客戶”與“服務(wù)器”是一個相對的概念，只存在于一個特定的連接期間，即在某個連接中的客戶在另一個連接中可能作為服務(wù)器。 WWW 服務(wù)器運行時，一直在 TCP80端口 (WWW 的缺省端口 )監(jiān)聽，等待連接的出現(xiàn)。 下面，討論 HTTP 協(xié)議下客戶 /服務(wù)器模式中信息交換的實現(xiàn)。 連接的建立是通過申請?zhí)捉幼?(Socket)實現(xiàn)的?？蛻舸蜷_一個套接字并把它約束在一個端口上，如果成功，就相當(dāng)于建立了一個虛擬文件。以后就可以在該虛擬文件上寫數(shù)據(jù)并通過網(wǎng)絡(luò)向外傳送。 打開一個連接后，客戶機把請求消息送到服務(wù)器的停留端口上，完成提出請求動作。 請求消息的格式為： 請求消息 =請求行 (通用信息 |請求頭 |實體頭 )CRLF[實體內(nèi)容 ] 請求行 =方法 請求 URL HTTP 版本號 CRLF 方法 =GET|HEAD|POST|擴展方法 URL=協(xié)議名稱 +宿主名 +目錄與文件名 請求行中的方法描述指定資源中應(yīng)該執(zhí)行的動作，常用的方法有 GET、 HEAD 和 POST。不同的請求對象對應(yīng) GET 的結(jié)果是不同的，對應(yīng)關(guān)系如下： 對象 GET 的結(jié)果 文件 文件的內(nèi)容 程序 該程序的執(zhí)行結(jié)果 數(shù)據(jù)庫查詢 查詢結(jié)果 HEAD—— 要求服務(wù)器查找某對象的元信息，而不是對象本身。 POST—— 從客戶機向服務(wù)器傳送數(shù)據(jù)，在要求服務(wù)器和 CGI做進一步處理時會用到 POST方法。 POST 主要用于發(fā)送 HTML 文本中 FORM 的內(nèi)容，讓 CGI 程序處理。 一個請求的例子為： 頭信息又稱為元信息，即信息的信息，利用元信息可以實現(xiàn)有條件的請求或應(yīng)答。 請求頭 —— 告訴服務(wù)器怎樣解釋本次請求，主要包括用戶可以接受的數(shù)據(jù)類型、壓縮方法和語言等。 實體頭 —— 實體信息類型、長度、壓縮方法、最后一次修改時間、數(shù)據(jù)有效期等。 實體 —— 請求或應(yīng)答對象本身。 服務(wù)器在處理完客戶的請求之后，要 向客戶機發(fā)送響應(yīng)消息。 HTTP/ 的響應(yīng)消息格式如下： 響應(yīng)消息 =狀態(tài)行 (通用信息頭 |響應(yīng)頭 |實體頭 ) CRLF 〔實體內(nèi)容〕 狀態(tài)行 =HTTP 版本號 狀態(tài)碼 原因敘述 狀態(tài)碼表示響應(yīng)類型 1 保留 2 表示請求成功地接收 3 為完成請求客戶需進一步細(xì)化請求 4 客戶錯誤 5 服務(wù)器錯誤 響應(yīng)頭的信息包括：服務(wù)程序名，通知客戶請求的 URL 需要認(rèn)證，請求的資源何時能使用。 客戶和服務(wù)器雙方都可以通過關(guān)閉套接字來結(jié)束 TCP/IP 對話 IPv6 在傳輸 層和應(yīng)用層的特點 應(yīng)用層： 萬維網(wǎng) (WWW)和 今使用最廣泛的應(yīng)用。 WWW 和 客戶必須指向 Inter 上的服務(wù)器才能工作。傳統(tǒng)上這些客戶能夠接受節(jié)點的主機名或其 I P 地址。在使用域名時，可調(diào)用域名系統(tǒng) (DNS)來獲得與主機名對應(yīng)的 IP 地址，然后在傳輸層和網(wǎng)際層使用。 對于簡單的應(yīng)用，很容易使其與 IPv6 一起工作：可以重寫軟件，使其能接受和正確處理 IPv4 地址和 IPv6 地址；或者要求只能按主機名來訪問。前一種方法保留了應(yīng)用直接對節(jié)點尋址的能力，但相對而言比較復(fù)雜；而后一種方法只是去 掉了大多數(shù)用戶不使用甚至不需要的功能。 但是，考慮到對 IPv6 提供的安全性、服務(wù)質(zhì)量或其他特性的需要，有些應(yīng)用希望使用IPv6 服務(wù)，這樣就需要更廣泛的更新。 傳輸層： 大多數(shù)情況下， IP 地址與應(yīng)用層協(xié)議無關(guān)，但是與傳輸層協(xié)議卻有很大關(guān)系。 UDP 和TCP 的偽頭都使用了源 IP 地址和目的 IP 地址，而且 TCP 電路是由源節(jié)點和目的節(jié)點的 IP地址和端口號來定義的。如果要與 IPv6 互操作，至少要修改 UDP 和 TCP，以適應(yīng) 128 位 IPv6地址。這意味著 UDP 和 TCP 需要識別 IPv6 地址，并能正確計算偽頭。對于 TCP，其實現(xiàn) 還必須能夠管理基于 IPv6 地址的電路。 在第一個 IPv6 RFC 發(fā)布之后，出現(xiàn)了一些顧慮，即需要 TCPng 來補充 IPng。目前 TCP在處理移動節(jié)點時有一點問題：確定 TCP 電路需要源節(jié)點和目的節(jié)點的 IP 地址。如果在 TCP交互期間，一方或雙方的 IP 地址有所改變，則電路的標(biāo)識就會出現(xiàn)問題。移動節(jié)點從一個網(wǎng)絡(luò)地址向另一個網(wǎng)絡(luò)地址轉(zhuǎn)換時就會出現(xiàn)這種情況。 Apache 的 IPv6 支持 Apache 服務(wù)器簡介 Apache 是世界排名第一的 Web 服務(wù)器 , 根據(jù) Netcraft()所作的調(diào)查 ,世界上百分之五十以上的 W