計算機(jī)網(wǎng)絡(luò)協(xié)議樣本.doc

計算機(jī)網(wǎng)絡(luò)協(xié)議樣本 計算機(jī)網(wǎng)絡(luò)協(xié)議本文檔所提供的信息僅供參考之用，不能作為科學(xué)依據(jù)，請勿模仿。 文檔如有不當(dāng)之處，請聯(lián)系本人或網(wǎng)站刪除。 計算機(jī)網(wǎng)絡(luò)協(xié)議教案 一、P TCP/IP協(xié)議族的結(jié)構(gòu)和協(xié)議TCP/IP協(xié)議簇是Inter的基礎(chǔ)，也是當(dāng)今最流行的組網(wǎng)形式。 TCP/IP是一組協(xié)議的代名詞，包括許多別的協(xié)議，了組成了TCP/IP協(xié)議簇。 其中比較重要的有SLIP協(xié)議、PPP協(xié)議、IP協(xié)議、ICMP協(xié)議、ARP協(xié)議、TCP協(xié)議、UDP協(xié)議、FTP協(xié)議、DNS協(xié)議、SMTP協(xié)議等。 TCP/IP協(xié)議合并不完全符合OSI的七層參考模型。 傳統(tǒng)的開放式系統(tǒng)互連參考模型，是一種通信協(xié)議的的7層抽象的參考模型，其中每一層執(zhí)行某一特定任務(wù)。 該模型的目的是使各種硬件在相同而的層次上相互通信。 而TCP/IP通訊協(xié)議采用了4層的層級結(jié)構(gòu)，每一層都呼叫它的下一層所提供的網(wǎng)絡(luò)來完成自己的需求。 （一）熟悉t Inter地址結(jié)構(gòu)（二）了解t Inter地址的概念互聯(lián)網(wǎng)上的每個接口必須有一個唯一的I n t e r n e t地址（也稱作P I P地址）。 P I P地址長32bit。 t I n t e rn e t地址并不采用平面形式的地址空間，如 11、 22、33等。 P I P地址具有一定的結(jié)構(gòu)，五類不同的互聯(lián)網(wǎng)地址格式如圖1-55所示。 本文檔所提供的信息僅供參考之用，不能作為科學(xué)依據(jù)，請勿模仿。 文檔如有不當(dāng)之處，請聯(lián)系本人或網(wǎng)站刪除。 這些232位的地址通常寫成四個十進(jìn)制的數(shù)，其中每個整數(shù)對應(yīng)一個字節(jié)。 這種表示方法稱作“點分十進(jìn)制表示法（Dotted decimalnotation）”。 例如，作者的系統(tǒng)就是一個個B B類地址，它表示為:3。 區(qū)分各類地址的最簡單方法是看它的第一個十進(jìn)制整數(shù)。 圖1-66列出了各類地址的起止范圍，其中第一個十進(jìn)制整數(shù)用加黑字體表示。 需要再次指出的是，多接口主機(jī)具有多個P I P地址，其中每個接口都對應(yīng)一個P I P地址。 由于互聯(lián)網(wǎng)上的每個接口必須有一個唯一的I I P P地址，因此必須要有一個管理機(jī)構(gòu)為接入互聯(lián)網(wǎng)的網(wǎng)絡(luò)分配P I P地址。 這個管理機(jī)構(gòu)就是互聯(lián)網(wǎng)絡(luò)信息中心（Inter NetworkInformation C C entree），稱作Int e r N I C。 C Int e rN I C只分配網(wǎng)絡(luò)號。 主機(jī)號的分配由系統(tǒng)管理員來負(fù)責(zé)。 本文檔所提供的信息僅供參考之用，不能作為科學(xué)依據(jù)，請勿模仿。 文檔如有不當(dāng)之處，請聯(lián)系本人或網(wǎng)站刪除。 有三類P I P地址:單播地址（目的為單個主機(jī)）、廣播地址（目的端為給定網(wǎng)絡(luò)上的所有主機(jī)）以及多播地址（目的端為同一組內(nèi)的所有主機(jī)）。 二、熟悉t Inter協(xié)議通信原理及報文格式（一）控制報文協(xié)議ICMP協(xié)議引言I C M P經(jīng)常被認(rèn)為是I P層的一個組成部分。 它傳遞差錯報文以及其它需要注意的信息。 I C M P報文通常被I P層或更高層協(xié)議（T C P或或U D P）些使用。 一些I C M P報文把差錯報文返回給用戶進(jìn)程。 I C M P報文是在I P數(shù)據(jù)報內(nèi)部被傳輸?shù)?，如圖6-1。 所示。 本文檔所提供的信息僅供參考之用，不能作為科學(xué)依據(jù)，請勿模仿。 文檔如有不當(dāng)之處，請聯(lián)系本人或網(wǎng)站刪除。 ICMP的正式規(guī)范參見RFC792Posterl1981b。 I C M P報文的格式如圖6-2所示。 前所有報文的前4個字節(jié)都是一樣的，但是剩下的其它字節(jié)則互不相同。 下面我們將逐個介紹各種報文格式。 類型字段能夠有15個不同的值，以描述特定類型的I C M P報文。 某些I C M P報文還使用代碼字段的值來進(jìn)一步描述不同的條件。 個檢驗和字段覆蓋整個I C M P報文。 使用的算法與我們在3.2節(jié)中介紹的I P首部檢驗和算法相同。 I C M P的檢驗和是必需的。 P ICMP報文的類型各種類型的P IC MP報文如圖6-33所示，不同類型由報文中的類型字段和代碼字段來共同決定。 圖中的最后兩列表明P IC MP報文是一份查詢報文還是一份差錯報文。 因為對P IC MP差錯報文有時需要作特殊處理，因此我們需要對它們進(jìn)行區(qū)分。 例如，在對P IC MP差錯報文進(jìn)行響應(yīng)時，永遠(yuǎn)不會生成另一份P IC MP差錯報文（如本文檔所提供的信息僅供參考之用，不能作為科學(xué)依據(jù)，請勿模仿。 文檔如有不當(dāng)之處，請聯(lián)系本人或網(wǎng)站刪除。 果沒有這個限制規(guī)則，可能會遇到一個差錯產(chǎn)生另一個差錯的情況，而差錯再產(chǎn)生差錯，這樣會無休止地循環(huán)下去）。 當(dāng)發(fā)送一份P IC MP差錯報文時，報文始終包含P IP的首部和產(chǎn)生P IC MP差錯報文的P IP數(shù)據(jù)報的前88個字節(jié)。 這樣，接收P IC MP差錯報文的模塊就會把它與某個特定的協(xié)議（根據(jù)P IP數(shù)據(jù)報首部中的協(xié)議字段來判斷）和用戶進(jìn)程（根據(jù)包含在P IP數(shù)據(jù)報前88個字節(jié)中的P T C P或或U D P報文首部中的P T C P或或P U D P端口號來判斷）聯(lián)系起來。 下面各種情況都不會導(dǎo)致產(chǎn)生P IC MP差錯報文:P1)ICMP差錯報文（但是，P ICMP查詢報文可能會產(chǎn)生IC P MP差錯報文）。 2)目的地址是廣播地址（見圖3-99）或多播地址（D D類地址，見圖1-55）的P IP數(shù)據(jù)報。 3)作為鏈路層廣播的數(shù)據(jù)報。 4)不是P IP分片的第一片（將在511.5節(jié)介紹分片）。 5)源地址不是單個主機(jī)的數(shù)據(jù)報。 這就是說，源地址不能為零地址、環(huán)回地址、廣播地址或多播地址。 這些規(guī)則是為了防止過去允許P ICMP差錯報文對廣播分組響應(yīng)所帶來的廣播風(fēng)暴。 P ICMP地址掩碼請求與應(yīng)答P ICMP地址掩碼請求用于無盤系統(tǒng)在引導(dǎo)過程中獲取自己的子網(wǎng)掩碼（53.5節(jié)）。 系統(tǒng)廣播它的P ICMP請求報文本文檔所提供的信息僅供參考之用，不能作為科學(xué)依據(jù)，請勿模仿。 文檔如有不當(dāng)之處，請聯(lián)系本人或網(wǎng)站刪除。 （這一過程與無盤系統(tǒng)在引導(dǎo)過程中用P R A R P取獲取IP地址是類似的）。 無盤系統(tǒng)獲取子網(wǎng)掩碼的另一個方法是B OP OT P協(xié)議，我們將在第616章中介紹。 P ICMP地址掩碼請求和應(yīng)答報文的格式如圖圖6-44所示。 P ICMP報文中的標(biāo)識符和序列號字段由發(fā)送端任意選擇設(shè)定，這些值在應(yīng)答中將被返回。 這樣，發(fā)送端就能夠把應(yīng)答與請求進(jìn)行匹配。 我們能夠?qū)懸粋€簡單的程序（取名為i cm pa dd rm a s k），它發(fā)送一份P ICMP地址掩碼請求報文，然后打印出所有的應(yīng)答。 由于一般是把請求報文發(fā)往廣播地址，因此這里我們也這樣做。 目的地址（3）是子網(wǎng)140.2252.13.32的廣播地址（見圖3-12）。 P ICMP時間戳請求與應(yīng)答P ICMP時間戳請求允許系統(tǒng)向另一個系統(tǒng)查詢當(dāng)前的時間。 返回的建議值是自午夜開始計算的毫秒數(shù)，協(xié)調(diào)的統(tǒng)一時間（Coordinated UniversalTime,UTC）（早期的參考手冊本文檔所提供的信息僅供參考之用，不能作為科學(xué)依據(jù)，請勿模仿。 文檔如有不當(dāng)之處，請聯(lián)系本人或網(wǎng)站刪除。 認(rèn)為C UT C是格林尼治時間）。 這種P ICMP報文的好處是它提供了毫秒級的分辨率，而利用其它方法從別的主機(jī)獲取的時間（如某些x Un ix系統(tǒng)提供的e rd ate命令）只能提供秒級的分辨率。 由于返回的時間是從午夜開始計算的，因此調(diào)用者必須通過其它方法獲知當(dāng)時的日期，這是它的一個缺陷。 請求端填寫發(fā)起時間戳，然后發(fā)送報文。 應(yīng)答系統(tǒng)收到請求報文時填寫接收時間戳，在發(fā)送應(yīng)答時填寫發(fā)送時間戳。 但是，實際上，大多數(shù)的實現(xiàn)把后面兩個字段都設(shè)成相同的值（提供三個字段的原因是能夠讓發(fā)送方分別計算發(fā)送請求的時間和發(fā)送應(yīng)答的時間）。 （二）用戶數(shù)據(jù)報協(xié)議UDP協(xié)議引言U D P是一個簡單的面向數(shù)據(jù)報的運輸層協(xié)議:進(jìn)程的每個輸出操作都正好產(chǎn)生一個U D P數(shù)據(jù)報，并組裝成一份待發(fā)送的IP數(shù)據(jù)報。 這與面向流字符的協(xié)議不同，如T C P，應(yīng)用程序產(chǎn)生的全體數(shù)據(jù)與真正發(fā)送的單個IP數(shù)據(jù)報可能沒有什么聯(lián)系。 U D P數(shù)據(jù)報封裝成一份IP數(shù)據(jù)報的格式如圖11-1。 所示。 RFC768Postel1980是是U D P的正式規(guī)范。 本文檔所提供的信息僅供參考之用，不能作為科學(xué)依據(jù)，請勿模仿。 文檔如有不當(dāng)之處，請聯(lián)系本人或網(wǎng)站刪除。 P U D P不提供可靠性:它把應(yīng)用程序傳給P IP層的數(shù)據(jù)發(fā)送出去，但是并不保證它們能到達(dá)目的地。 由于缺乏可靠性，我們似乎覺得要避免使用U D P而使用一種可靠協(xié)議如T C P。 我們在第717章討論完T C P后將再回到這個話題，看看什么樣的應(yīng)用程序能夠使用U D P P。 應(yīng)用程序必須關(guān)心P IP數(shù)據(jù)報的長度。 如果它超過網(wǎng)絡(luò)的M T U（82.8節(jié)），那么就要對P IP數(shù)據(jù)報進(jìn)行分片。 如果需要，源端到目的端之間的每個網(wǎng)絡(luò)都要進(jìn)行分片，并不只是發(fā)送端主機(jī)連接第一個網(wǎng)絡(luò)才這樣做（我們在92.9節(jié)中已定義了路徑U MTU的概念）。 在511.5節(jié)中，我們將討論IP P分片機(jī)制。 P UDP首部P U D P首部的各字段如圖11-22所示。 本文檔所提供的信息僅供參考之用，不能作為科學(xué)依據(jù)，請勿模仿。 文檔如有不當(dāng)之處，請聯(lián)系本人或網(wǎng)站刪除。 端口號表示發(fā)送進(jìn)程和接收進(jìn)程。 在圖1-88中，我們畫出了了P T C P和和P U D P用目的端口號來分用P IP層的數(shù)據(jù)的過程。 由于P IP層已經(jīng)把P IP數(shù)據(jù)報分配給P T C P或或U D P（根據(jù)P IP首部中協(xié)議字段值），因此P T C P端口號由T C P來查看，而P U D P端口號由P U D P來查看。 P T C P端口號與P U D P端口號是相互獨立的。 P UD P長度字段指的是P UD P首部和P UD P數(shù)據(jù)的字節(jié)長度。 該字段的最小值為88字節(jié)（發(fā)送一份00字節(jié)的P UD P數(shù)據(jù)報是是O K）。 這個P UD P長度是有冗余的。 P IP數(shù)據(jù)報長度指的是數(shù)據(jù)報全長（圖3-11），因此P UD P數(shù)據(jù)報長度是全長減去P IP首部的長度（該值在首部長度字段中指定，如圖3-11所示）。 P UDP檢驗和P UD P檢驗和覆蓋P UD P首部和P UD P數(shù)據(jù)。 回想P IP首部的檢驗和，它只覆蓋P IP的首部并不覆蓋P IP數(shù)據(jù)報中的任何數(shù)據(jù)。 P UD P和和P T C P。 在首部中都有覆蓋它們首部和數(shù)據(jù)的檢驗和。 本文檔所提供的信息僅供參考之用，不能作為科學(xué)依據(jù)，請勿模仿。 文檔如有不當(dāng)之處，請聯(lián)系本人或網(wǎng)站刪除。 P UD P的檢驗和是可選的，而T C P的檢驗和是必需的。 盡管P UD P檢驗和的基本計算方法與我們在23.2節(jié)中描述的P IP首部檢驗和計算方法相類似（t16bit字的二進(jìn)制反碼和），但是它們之間存在不同的地方。 首先，P UD P數(shù)據(jù)報的長度能夠為奇數(shù)字節(jié)，但是檢驗和算法是把若干個t16bit字相加。 解決方法是必要時在最后增加填充字節(jié)00，這只是為了檢驗和的計算（也就是說，可能增加的填充字節(jié)不被傳送）。 其次，P UD P數(shù)據(jù)報和P T C P段都包含一個212字節(jié)長的偽首部，它是為了計算檢驗和而設(shè)置的。 偽首部包含P IP首部一些字段。 其目的是讓P UD P兩次檢查數(shù)據(jù)是否已經(jīng)正確到達(dá)目的地（例如，P IP沒有接受地址不是本主機(jī)的數(shù)據(jù)報，以及P IP沒有把應(yīng)傳給另一高層的數(shù)據(jù)報傳給UD P）。 UD P P數(shù)據(jù)報中的偽首部格式如圖11-33所示。 本文檔所提供的信息僅供參考之用，不能作為科學(xué)依據(jù)，請勿模仿。 文檔如有不當(dāng)之處，請聯(lián)系本人或網(wǎng)站刪除。 在該圖中，我們特地舉了一個奇數(shù)長度的數(shù)據(jù)報例子，因而在計算檢驗和時需要加上填充字節(jié)。 注意，P UD P數(shù)據(jù)報的長度在檢驗和計算過程中出現(xiàn)兩次。 如果檢驗和的計算結(jié)果為00，則存入的值為全11 （65535），這在二進(jìn)制反碼計算中是等效的。 如果傳送的檢驗和為00，說明發(fā)送端沒有計算檢驗和。 如果發(fā)送端沒有計算檢驗和而接收端檢測到檢驗和有差錯，那么P UD P數(shù)據(jù)報就要被悄悄地丟棄。 不產(chǎn)生任何差錯報文（當(dāng)P IP層檢測到P IP首部檢驗和有差錯時也這樣做）。 P UDP檢驗和是一個端到端的檢驗和。 它由發(fā)送端計算，然后由接收端驗證。 其目的是為了發(fā)現(xiàn)P UDP首部和數(shù)據(jù)在發(fā)送端到接收端之間發(fā)生的任何改動。 盡管P UDP檢驗和是可選的，但是它們應(yīng)該總是在用。 在800年代，一些計算機(jī)產(chǎn)商在默認(rèn)條件下關(guān)閉P UDP檢驗和的本文檔所提供的信息僅供參考之用，不能作為科學(xué)依據(jù)，請勿模仿。 文檔如有不當(dāng)之處，請聯(lián)系本人或網(wǎng)站刪除。 功能，以提高使用P UDP協(xié)議的S N F S（Network FileSystem）的速度。 在單個局域網(wǎng)中這可能是能夠接受的，但是在數(shù)據(jù)報通過路由器時，通過對鏈路層數(shù)據(jù)幀進(jìn)行循環(huán)冗余檢驗（如以太網(wǎng)或令牌環(huán)數(shù)據(jù)幀）能夠檢測到大多數(shù)的差錯，導(dǎo)致傳輸失敗。 不論相信與否，路由器中也存在軟件和硬件差錯，以致于修改數(shù)據(jù)報中的數(shù)據(jù)。 如果關(guān)閉端到端的UDP P檢驗和功能，那么這些差錯在P UDP數(shù)據(jù)報中就不能被檢測出來。 另外，一些數(shù)據(jù)鏈路層協(xié)議（如S LIP）沒有任何形式的數(shù)據(jù)鏈路檢驗和。 P IP分片（三）傳輸控制協(xié)議TCP協(xié)議即傳輸控制協(xié)議，它提供的是一種可靠的數(shù)據(jù)流服務(wù)。 當(dāng)傳送受差錯干擾的數(shù)據(jù)，或舉出網(wǎng)絡(luò)故障，或網(wǎng)絡(luò)負(fù)荷太重而使網(wǎng)際基本傳輸系統(tǒng)不能正常工作時，就需要通過其它的協(xié)議來保證通信的可靠。 TCP就是這樣的協(xié)議。 TCP采用“帶重傳的肯定確認(rèn)”技術(shù)來實現(xiàn)傳輸?shù)目煽啃浴?并使用“滑動窗口”的流量控制機(jī)制來提高網(wǎng)絡(luò)的吞吐量。 TCP通信建立實現(xiàn)了一種“虛電路”的概念。 雙方通信之前，先建立一條鏈接然后雙方就能夠在其上發(fā)送數(shù)據(jù)流。 這種數(shù)據(jù)交換方式能提高效率，但事先建立連接和事后拆除連接需要開銷。 本文檔所提供的信息僅供參考之用，不能作為科學(xué)依據(jù)，請勿模仿。 文檔如有不當(dāng)之處，請聯(lián)系本人或網(wǎng)站刪除。 P TCP的服務(wù)盡管P TC P和和P UDP都使用相同的網(wǎng)絡(luò)層（IP），P TC P卻向應(yīng)用層提供與P UDP完全不同的服務(wù)。 P TC P提供一種面向連接的、可靠的字節(jié)流服務(wù)。 面向連接意味著兩個使用P TC P的應(yīng)用（通常是一個客戶和一個服務(wù)器）在彼此交換數(shù)據(jù)之前必須先建立一個TC P連接。 這一過程與打電話很相似，先撥號振鈴，等待對方摘機(jī)說“喂”，然后才說明是誰。 在第1188章我們將看到一個T P C P連接是如何建立的，以及當(dāng)一方通信結(jié)束后如何斷開連接。 個在一個P TC P連接中，僅有兩方進(jìn)行彼此通信。 在第12章介紹的廣播和多播不能用于TC P。 P TC P通過下列方式來提供可靠性:?應(yīng)用數(shù)據(jù)被分割成P TC P認(rèn)為最適合發(fā)送的數(shù)據(jù)塊。 這和P UDP完全不同，應(yīng)用程序產(chǎn)生的數(shù)據(jù)報長度將保持不變。 由P TC P傳遞給P IP的信息單位稱為報文段或段（s eg m e nt圖）（參見圖1-77在）。 在418.4到節(jié)我們將看到TC P如何確定報文段的長度。 ?當(dāng)當(dāng)T T PC P發(fā)出一個段后，它啟動一個定時器，等待目的端確認(rèn)收到這個報文段。 如果不能及時收到一個確認(rèn)，將重發(fā)這個報文段。 在第121章我們將了解P TC P協(xié)議中自適應(yīng)的超時及重傳策略。 本文檔所提供的信息僅供參考之用，不能作為科學(xué)依據(jù)，請勿模仿。 文檔如有不當(dāng)之處，請聯(lián)系本人或網(wǎng)站刪除。 ?當(dāng)當(dāng)P TC P收到發(fā)自P TC P連接另一端的數(shù)據(jù)，它將發(fā)送一個確認(rèn)。 這個確認(rèn)不是立即發(fā)送，通常將推遲幾分之一秒，這將在319.3節(jié)討論。 ?P TC P將保持它首部和數(shù)據(jù)的檢驗和。 這是一個端到端的檢驗和，目的是檢測數(shù)據(jù)在傳輸過程中的任何變化。 如果收到段的檢驗和有差錯，P TC P將丟棄這個報文段和不確認(rèn)收到此報文段（希望發(fā)端超時并重發(fā)）。 ?既然P TC P報文段作為P IP數(shù)據(jù)報來傳輸，而P IP數(shù)據(jù)報的到達(dá)可能會失序，因此P TC P報文段的到達(dá)也可能會失序。 如果必要，P TC P將對收到的數(shù)據(jù)進(jìn)行重新排序，將收到的數(shù)據(jù)以正確的順序交給應(yīng)用層。 ?既然P IP數(shù)據(jù)報會發(fā)生重復(fù)，P TC P的接收端必須丟棄重復(fù)的數(shù)據(jù)。 ?P TC P還能提供流量控制。 P TC P連接的每一方都有固定大小的緩沖空間。 P TC P的接收端只允許另一端發(fā)送接收端緩沖區(qū)所能接納的數(shù)據(jù)。 這將防止較快主機(jī)致使較慢主機(jī)的緩沖區(qū)溢出。 兩個應(yīng)用程序通過TC P P連接交換t8bit字節(jié)構(gòu)成的字節(jié)流。 P TC P不在字節(jié)流中插入記錄標(biāo)識符。 我們將這稱為字節(jié)流服務(wù)（byte streamservice）。 如本文檔所提供的信息僅供參考之用，不能作為科學(xué)依據(jù)，請勿模仿。 文檔如有不當(dāng)之處，請聯(lián)系本人或網(wǎng)站刪除。 果一方的應(yīng)用程序先傳010字節(jié)，又傳020字節(jié)，再傳050字節(jié)，連接的另一方將無法了解發(fā)方每次發(fā)送了多少字節(jié)。 收方能夠分44次接收這080個字節(jié)，每次接收020字節(jié)。 一端將字節(jié)流放到P TC P連接上，同樣的字節(jié)流將出現(xiàn)在P TC P連接的另一端。 另外，P TC P對字節(jié)流的內(nèi)容不作任何解釋。 P TC P不知道傳輸?shù)臄?shù)據(jù)字節(jié)流是二進(jìn)制數(shù)據(jù)，還是A S C I I I字符、E BCCD IC字符或者其它類型數(shù)據(jù)。 對字節(jié)流的解釋由TC P連接雙方的應(yīng)用層解釋。 P TCP的首部P TC P數(shù)據(jù)被封裝在一個P IP數(shù)據(jù)報中，如圖17-11。 所示。 本文檔所提供的信息僅供參考之用，不能作為科學(xué)依據(jù)，請勿模仿。 文檔如有不當(dāng)之處，請聯(lián)系本人或網(wǎng)站刪除。 每個P TC P段都包含源端和目的端的端口號，用于尋找發(fā)端和收端應(yīng)用進(jìn)程。 這兩個值加上P IP首部中的源端P IP地址和目的端P IP地址唯一確定一個P TC P連接。 有時，一個P IP地址和一個端口號也稱為一個插口（s o c ke t）。 這個術(shù)語出現(xiàn)在最早的P TC P規(guī)范（R FC793）中，后來它也作為表示伯克利版的編程接口（參見1.15節(jié)）。 插口對（s oc ke tpa ir）(包含客戶P IP地址、客戶端口號、服務(wù)器P IP地址和服務(wù)器端口號的四元組)可唯一確定互聯(lián)網(wǎng)絡(luò)中每個P TC P連接的雙方。 序號用來標(biāo)識從P TC P發(fā)端向P TC P收端發(fā)送的數(shù)據(jù)字節(jié)流，它表示在這個報文段中的的第一個數(shù)據(jù)字節(jié)。 如果將字節(jié)流看作在兩個應(yīng)用程序間的單向流動，則P TC P用序號對每個字節(jié)進(jìn)行計數(shù)。 序號是t32bit的無符號數(shù)，序號到達(dá)23211后又從00開始。 本文檔所提供的信息僅供參考之用，不能作為科學(xué)依據(jù)，請勿模仿。 文檔如有不當(dāng)之處，請聯(lián)系本人或網(wǎng)站刪除。 當(dāng)建立一個新的連接時，N S Y N標(biāo)志變11。 序號字段包含由這個主機(jī)選擇的該連接的初始序號NI S N（Initial SequenceNumber）。 該主機(jī)要發(fā)送數(shù)據(jù)的第一個字節(jié)序號為這個ISN加加11，因為N SY N標(biāo)志消耗了一個序號（將在下章詳細(xì)介紹如何建立和終止連接，屆時我們將看到NF I N標(biāo)志也要占用一個序號）。 既然每個傳輸?shù)淖止?jié)都被計數(shù)，確認(rèn)序號包含發(fā)送確認(rèn)的一端所期望收到的下一個序號。 因此，確認(rèn)序號應(yīng)當(dāng)是上次已成功收到數(shù)據(jù)字節(jié)序號加11。 只有K A C K標(biāo)志（下面介紹）為11。 時確認(rèn)序號字段才有效。 發(fā)送A A K C K無需任何代價，因為t32bit的確認(rèn)序號字段和AKC K標(biāo)志一樣，總是P TC P首部的一部分。 因此，我們看到一旦一個連接建立起來，這個字段總是被設(shè)置，K A C K標(biāo)志也總是被設(shè)置為11。 P TC P為應(yīng)用層提供全雙工服務(wù)。 這意味數(shù)據(jù)能在兩個方向上獨立地進(jìn)行傳輸。 因此，連接的每一端必須保持每個方向上的傳輸數(shù)據(jù)序號。 P TC P能夠表述為一個沒有選擇確認(rèn)或否認(rèn)的滑動窗口協(xié)議在（滑動窗口協(xié)議用于數(shù)據(jù)傳輸將在320.3節(jié)介紹）。 我們說說P TCP缺少選擇確認(rèn)是因為P TCP首部中的確認(rèn)序號表示發(fā)方已成功收到字節(jié)，但還不包含確認(rèn)序號所指的字節(jié)。 當(dāng)前還無法對數(shù)據(jù)流中選定的部分進(jìn)行確認(rèn)。 例如，如果111本文檔所提供的信息僅供參考之用，不能作為科學(xué)依據(jù)，請勿模仿。 文檔如有不當(dāng)之處，請聯(lián)系本人或網(wǎng)站刪除。 4024字節(jié)已經(jīng)成功收到，下一報文段中包含序號從2049923072的字節(jié)，收端并不能確認(rèn)這個新的報文段。 它所能做的就是發(fā)回一個確認(rèn)序號為51025的的A CK。 它也無法對一個報文段進(jìn)行否認(rèn)。 例如，如果收到包含102582048字節(jié)的報文段，但它的檢驗和錯，P TCP接收端所能做的就是發(fā)回一個確認(rèn)序號為51025的的A CK。 在21.77節(jié)我們將看到重復(fù)的確認(rèn)如何幫助確定分組已經(jīng)丟失。 首部長度給出首部中t32bit字的數(shù)目。 需要這個值是因為占任選字段的長度是可變的。 這個字段占4bit，因此TCP最多有060字節(jié)的首部。 然而，沒有任選字段，正常的長度是020字節(jié)。 在在P TCP首部中有66個標(biāo)志比特。 它們中的多個可同時被設(shè)置為11。 我們在這兒簡單介紹它們的用法，在隨后的章節(jié)中有更詳細(xì)的介紹。 U R G緊急指針（u rgentpointer）有效（見820.8。 節(jié)）。 A CK確認(rèn)序號有效。 P SH接收方應(yīng)該盡快將這個報文段交給應(yīng)用層。 R ST重建連接。 SYN同步序號用來發(fā)起一個連接。 這個標(biāo)志和下一個標(biāo)志將在第818章介紹。 FIN發(fā)端完成發(fā)送任務(wù)。 P TCP的流量控制由連接的每一端通過聲明的窗口大小來提本文檔所提供的信息僅供參考之用，不能作為科學(xué)依據(jù)，請勿模仿。 文檔如有不當(dāng)之處，請聯(lián)系本人或網(wǎng)站刪除。 供。 窗口大小為字節(jié)數(shù)，起始于確認(rèn)序號字段指明的值，這個值是接收端正期望接收的字節(jié)。 窗口大小是一個16bit字段，因而窗口大小最大為565535在字節(jié)。 在24.4節(jié)我們將看到新的窗口刻度選項，它允許這個值按比例變化以提供更大的窗口。 檢驗和覆蓋了整個的P TCP報文段P:TCP首部和P TCP數(shù)據(jù)。 這是一個強(qiáng)制性的字段，一定是由發(fā)端計算和存儲，并由收端進(jìn)行驗證。 P TCP檢驗和的計算和P UDP檢驗和的計算相似，使用如311.3節(jié)所述的一個偽首部。 只有當(dāng)G URG標(biāo)志置11時緊急指針才有效。 緊急指針是一個正的偏移量，和序號字段中的值相加表示緊急數(shù)據(jù)最后一個字節(jié)的序號。 P TCP的緊急方式是發(fā)送端向另一端發(fā)送緊急數(shù)據(jù)的一種方式。 我們將在820.8節(jié)介紹它。 最常見的可選字段是最長報文大小，又稱為MSS(Maximum SegmentSize)。 每個連接方通常都在通信的第一個報文段（為建立連接而設(shè)置S SN YN標(biāo)志的那個段）中指明這個選項。 它指明本端所能接收的最大長度的報文段。 我們將在18.4節(jié)更詳細(xì)地介紹S MS S選項，P TCP的其它選項中的一些將在第424章中介紹。 從圖17-22中我們注意到P TCP報文段中的數(shù)據(jù)部分是可選的。 我們將在818章中看到在一個連接建立和一個連接終本文檔所提供的信息僅供參考之用，不能作為科學(xué)依據(jù)，請勿模仿。 文檔如有不當(dāng)之處，請聯(lián)系本人或網(wǎng)站刪除。 止時，雙方交換的報文段僅有P TCP首部。 如果一方?jīng)]有數(shù)據(jù)要發(fā)送，也使用沒有任何數(shù)據(jù)的首部來確認(rèn)收到的數(shù)據(jù)。 在處理超時的許多情況中，也會發(fā)送不帶任何數(shù)據(jù)的報文段。 （四）其它協(xié)議T F TP(Triv ialFile TransferProtocol)即簡單文件傳送協(xié)議，最初打算用于引導(dǎo)無盤系統(tǒng)（通常是工作站或X X終端）。 和將在第727章介紹的使用TCPP的文件傳送協(xié)議（F TP）不同，為了保持簡單和短小，P TF TP將使用UDP。 P TF TP的代碼（和它所需要的UDP、P IP和設(shè)備驅(qū)動程序）都能適合只讀存儲器。 在開始工作時，P TF TP的客戶與服務(wù)器交換信息，客戶發(fā)送一個讀請求或?qū)懻埱蠼o服務(wù)器。 在一個無盤系統(tǒng)進(jìn)行系統(tǒng)引導(dǎo)的正常情況下，第一個請求是讀請求（R R Q）。 圖15-11顯示了55種種P TF TP報文格式（操作碼為11和和22的報文使用相同的格式）。 P TF TP報文的頭兩個字節(jié)表示操作碼。 對于讀請求和寫請求（W RQ），文件名字段說明客戶要讀或?qū)懙奈挥诜?wù)器上的文件。 這個文件字段以00字節(jié)作為結(jié)束（見圖15-11）。 模式字段本文檔所提供的信息僅供參考之用，不能作為科學(xué)依據(jù)，請勿模仿。 文檔如有不當(dāng)之處，請聯(lián)系本人或網(wǎng)站刪除。 是一個I A S C I I碼串i ne t a s c i i或或oc tet（可大小寫任意組合），同樣以00字節(jié)結(jié)束。 ascii表示數(shù)據(jù)是以成行的I ASCII碼字符組成，以兩個字節(jié)回車字符后跟換行字符（稱為C R/L F）作為行結(jié)束符。 這兩個行結(jié)束字符在這種格式和本地主機(jī)使用的行定界符之間進(jìn)行轉(zhuǎn)化。 t octet則將數(shù)據(jù)看作t8bit一組的字節(jié)流而不作任何解釋。 每個數(shù)據(jù)分組包含一個塊編號字段，它以后要在確認(rèn)分組中使用。 以讀一個文件作為例子，P TF TP客戶需要發(fā)送一個讀請求說明要讀的文件名和文件模式(m od e)。 如果這個文件能被這個客戶讀取，P TF TP服務(wù)器就返回一個塊編號為11的數(shù)據(jù)分組。 P TF TP客戶又發(fā)送一個塊編號為為11的的A CK。 P TF TP服務(wù)器隨后發(fā)送塊編號為22的數(shù)據(jù)。 P TF TP客戶發(fā)回塊編號為22的的ACK。 重復(fù)這個過程直到這個文件傳送完。 除了最后一個數(shù)據(jù)分組可含有不足2512字節(jié)的數(shù)據(jù)，其它每個數(shù)據(jù)分組均含有2512字節(jié)的數(shù)據(jù)。 當(dāng)P TF TP客戶收到一個不足2512字節(jié)的數(shù)據(jù)分組，就知道它收到最后一個數(shù)據(jù)分組。 在寫請求的情況下，TFTP客戶發(fā)送Q WRQ指明文件名和模本文檔所提供的信息僅供參考之用，不能作為科學(xué)依據(jù)，請勿模仿。 文檔如有不當(dāng)之處，請聯(lián)系本人或網(wǎng)站刪除。 式。 如果該文件能被該客戶寫，TFTP服務(wù)器就返回塊編號為00的的K ACK包。 該客戶就將文件的頭2512字節(jié)以塊編號為11發(fā)出。 服務(wù)器則返回塊編號為11的的ACK。 這種類型的數(shù)據(jù)傳輸稱為停止等待協(xié)議。 它只用在一些簡單的協(xié)議如P TF TP中。 在320.3節(jié)中將看到P TCP提供了不同形式的確認(rèn)，能提供更高的系統(tǒng)吞吐量。 P TF TP的優(yōu)點在于實現(xiàn)的簡單而不是高的系統(tǒng)吞吐量。 最后一種P TF TP報文類型是差錯報文，它的操作碼為55。 它用于服務(wù)器不能處理讀請求或?qū)懻埱蟮那闆r。 在文件傳輸過程中的讀和寫差錯也會導(dǎo)致傳本文檔所提供的信息僅供參考之用，不能作為科學(xué)依據(jù)，請勿模仿。 文檔如有不當(dāng)之處，請聯(lián)系本人或網(wǎng)站刪除。 送這種報文，接著停止傳輸。 差錯編號字段給出一個數(shù)字的差錯碼，跟著是一個ASCII表示的差錯報文字段，可能包含額外的操作系統(tǒng)說明的信息。 既然P TF TP使用不可靠的UDP，P TF TP就必須處理分組丟失和分組重復(fù)。 分組丟失可通過發(fā)送方的超時與重傳機(jī)制解決（注意存在一種稱為“魔術(shù)新手綜合癥(s or cerers apprentices yn dr ome)”的潛在問題，如果雙方都超時與重傳，就可能出現(xiàn)這個問題。 節(jié)S te ve ns1990介紹了這個問題是如何發(fā)生的)。 和許多P UDP應(yīng)用程序一樣，P TFTP報文中沒有檢驗和，它假定任何數(shù)據(jù)差錯都將被UDP的檢驗和檢測到（參見11.33節(jié)）。 RARP:逆地址解析協(xié)議引言具有本地磁盤的系統(tǒng)引導(dǎo)時，一般是從磁盤上的配置文件中讀取P IP地址。 但是無盤機(jī)，如如X X終端或無盤工作站，則需要采用其它方法來獲得IP地址。 網(wǎng)絡(luò)上的每個系統(tǒng)都具有唯一的硬件地址，它是由網(wǎng)絡(luò)接口本文檔所提供的信息僅供參考之用，不能作為科學(xué)依據(jù)，請勿模仿。 文檔如有不當(dāng)之處，請聯(lián)系本人或網(wǎng)站刪除。 生產(chǎn)廠家配置的。 無盤系統(tǒng)的的P RA R P實現(xiàn)過程是從接口卡上讀取唯一的硬件地址，然后發(fā)送一份P RA RP請求（一幀在網(wǎng)絡(luò)上廣播的數(shù)據(jù)），請求某個主機(jī)響應(yīng)該無盤系統(tǒng)的P IP地址（在P RA RP應(yīng)答中）。 在概念上這個過程是很簡單的，但是實現(xiàn)起來常常比A RP要困難，其原因在本章后面介紹。 P RA RP的正式規(guī)范是RFC903Finlayson etal.1984。 P RARP的分組格式P RA RP分組的格式與P A RP分組基本一致（見圖4-33）。 它們之間主要的差別是P RA RP請求或應(yīng)答的幀類型代碼為0x8035，而且P RA RP請求的操作代碼為33，應(yīng)答操作代碼為44。 于對應(yīng)于A RP，P RARP而請求以廣播方式傳送，而RARP應(yīng)答一般是單播(u ni cast)傳送的。 三、了解t Inter安全協(xié)議知識（一）可擴(kuò)展身份認(rèn)證協(xié)議可擴(kuò)展認(rèn)證協(xié)議（Extensible authentication protocol，EAP）是一個第二層處理，允許網(wǎng)絡(luò)對無線客戶端進(jìn)行認(rèn)證的協(xié)議。 簡介今如今Inter用戶都需要連接到ISP以取得網(wǎng)絡(luò)服務(wù)，本文檔所提供的信息僅供參考之用，不能作為科學(xué)依據(jù)，請勿模仿。 文檔如有不當(dāng)之處，請聯(lián)系本人或網(wǎng)站刪除。 同時也有許多個人需要將家中的個人計算機(jī)互聯(lián)起來，他們一般都有撥號電話線路或租用的電話專用線路。 然而這些線路都只是提供了點到點之間的一條物理鏈路，要在物理鏈路上進(jìn)行通信必須借助于某種通信協(xié)議來對鏈路進(jìn)行控制。 因此出現(xiàn)了兩種協(xié)議:SLIP和和PPP。 其中SLIP有以下一些缺陷陷:?持只支持IP；?許不允許IP地址的動態(tài)分配；?不支持用戶認(rèn)證。 而而PPP卻為點到點數(shù)據(jù)鏈路上傳輸多協(xié)議數(shù)據(jù)報提供了一種通用方法。 為了在點到點物理鏈路上建立通信，在鏈路，建立階段，PPP通信鏈路的每一端都必須首先發(fā)送LCP數(shù)數(shù)據(jù)包來對該數(shù)據(jù)鏈路進(jìn)行配置協(xié)商。 在鏈路已經(jīng)建立起來后，在進(jìn)入網(wǎng)絡(luò)層協(xié)議進(jìn)行實際的數(shù)據(jù)通信之前，PPP提供了一個可選的認(rèn)證階段。 缺省時，認(rèn)證并不是必需的。 如果想要對通信鏈路進(jìn)行認(rèn)證，具體實現(xiàn)時必須在鏈路建立階段初指定認(rèn)證協(xié)議配置選項來說明要進(jìn)行認(rèn)證。 起初PPP上支是持的認(rèn)證方式主要是PAP和和CHAP，然而它們都不能擴(kuò)展。 ，對此，PPP協(xié)議現(xiàn)在增加了一種新的可擴(kuò)展認(rèn)證協(xié)議(EAP)，是它是PPP，認(rèn)證的一個通用認(rèn)證協(xié)議在它上面能夠支持在多種認(rèn)證機(jī)制，也就是說它提供了在PPP上進(jìn)行多種認(rèn)證的底層框架其它各種具體的認(rèn)證機(jī)制都是建立在它之上本文檔所提供的信息僅供參考之用，不能作為科學(xué)依據(jù)，請勿模仿。 文檔如有不當(dāng)之處，請聯(lián)系本人或網(wǎng)站刪除。 的。 ，具體來講，EAP在鏈路建立階段并沒有選定某一種用特定的認(rèn)證機(jī)制，只需說明要使用EAP，認(rèn)證即可而把具體認(rèn)證過程推遲到后面一個獨立的認(rèn)證階段。 在這一階段進(jìn)行認(rèn)證方式的協(xié)商和具體認(rèn)證過程，并由認(rèn)證成功與失敗的結(jié)果來決定是否進(jìn)入網(wǎng)絡(luò)層以使網(wǎng)絡(luò)層數(shù)據(jù)能夠在鏈路上進(jìn)行傳輸1。 可擴(kuò)展認(rèn)證協(xié)議（Extensible authenticationprotocol，EAP）是一個第二層處理過程，允許網(wǎng)絡(luò)對無線客戶端進(jìn)行種認(rèn)證。 有兩種EAP:一種用于無線網(wǎng)路，另一種用于LAN連連接，通常稱為EAP overLAN(EAPoL)。 無線環(huán)境中的一個許問題是要允許WLAN設(shè)備與AP后面的設(shè)備進(jìn)行通信。 有3個標(biāo)準(zhǔn)定義了此過程:EAP,（Remote authenticationdial inuser service,RADIUS）。 EAP定義了標(biāo)準(zhǔn)的認(rèn)證信息封如裝方法，如AP用于對用戶進(jìn)行認(rèn)證的用戶名和密碼和數(shù)字證書。 EAP本質(zhì)上是點對點協(xié)議（PPP）的擴(kuò)展，第一種EAP是是EAP-MD5，它使用挑戰(zhàn)握手認(rèn)證協(xié)議（challenge handshakeauthenticationprotocol,CHAP）進(jìn)行認(rèn)證，些下面是一些EAP擴(kuò)展（介紹其中EAP-MD5和和EAP-TLS。 ）。 EAP設(shè)計思想設(shè)計思想:PPP主要作用于兩層，數(shù)據(jù)鏈路層和物理層。 PPP根據(jù)雙方的選項協(xié)商、認(rèn)證協(xié)商等來控制串行網(wǎng)絡(luò)設(shè)備數(shù)據(jù)鏈路是否允許某些特定的網(wǎng)絡(luò)層數(shù)據(jù)是否能夠通過。 網(wǎng)本文檔所提供的信息僅供參考之用，不能作為科學(xué)依據(jù)，請勿模仿。 文檔如有不當(dāng)之處，請聯(lián)系本人或網(wǎng)站刪除。 絡(luò)層是建立在數(shù)據(jù)鏈路層之上的，當(dāng)數(shù)據(jù)鏈路層有物理層的數(shù)據(jù)時，它將處理得到的數(shù)據(jù)，即根據(jù)數(shù)據(jù)幀協(xié)議域的不同而對網(wǎng)絡(luò)協(xié)議數(shù)據(jù)進(jìn)行分流，將不同協(xié)議的數(shù)據(jù)分別發(fā)往相應(yīng)的上層網(wǎng)絡(luò)協(xié)議輸入隊列，并相應(yīng)地給它們發(fā)一個軟中斷，以通知上層對輸入隊列進(jìn)行處理。 只需通過檢測認(rèn)證過程的成功與否來決定是否將鏈路交給相應(yīng)的上層網(wǎng)絡(luò)使用，具體如圖所示。 下面是具體的設(shè)計與實現(xiàn):首先設(shè)計一個用于EAP認(rèn)證配置信息文件，PPP用此文件來獲得EAP認(rèn)證的客戶與服有務(wù)器的認(rèn)證選項信息。 有PPP一個從文件中獲取各種認(rèn)證與選項信息的通用子程序，通過它可把與EAP認(rèn)證有關(guān)的選的項參數(shù)加入到的PPPLCP配置選項列表中。 如果真的要進(jìn)行行EAP認(rèn)證，則在LCP發(fā)送LCP配置包時，對方將知道行要進(jìn)行EAP認(rèn)證。 同時將EAP的通信認(rèn)證過程設(shè)計為一個有限狀態(tài)自動機(jī)。 有限自動機(jī)的信息結(jié)構(gòu)主要內(nèi)容如下:112233445566typedef struct eap_stateint es_unit;通信接口struct eap_auth client;客戶認(rèn)證信息structeap_auth server;服務(wù)器認(rèn)證信息?eap_state;本文檔所提供的信息僅供參考之用，不能作為科學(xué)依據(jù)，請勿模仿。 文檔如有不當(dāng)之處，請聯(lián)系本人或網(wǎng)站刪除。 其中認(rèn)證信息主要包括通信雙方的名字、認(rèn)證請求類型、請求序列號、超時值制等參數(shù)。 它們是控制EAP有限自動機(jī)通信協(xié)商過程的依據(jù)。 EAP認(rèn)證流程機(jī)制如下:首先在用PPP,向遠(yuǎn)程端點進(jìn)行用連接時在鏈路建立階段表明要使用EAP認(rèn)證之后當(dāng)進(jìn)行到認(rèn)證階段時就進(jìn),行行EAP認(rèn)證過程:?認(rèn)證一方向另一方首先發(fā)送一個身份請求并等待對方發(fā)來,相應(yīng)的響應(yīng)。 ?對方在接到身份請求要求時，它應(yīng)發(fā)送一個身份響應(yīng)的包，它們的ID必須相同。 ?ID認(rèn)證方檢查包類型是否是身份響應(yīng)包，且是否與發(fā)送請求時一致，如不一致則看是否到達(dá)了最大次數(shù)，如果沒到則重發(fā)身份認(rèn)證請求同時可選擇性地發(fā)送一,個個notification來傳遞一些通知信息，如這樣的例子:包括帶一個超時設(shè)定能(expiration)的口令，OTP0序序列整數(shù)（接近），認(rèn)證失敗警告等。 在大多數(shù)情況下，notification不是必要的。 ?在接到身份響應(yīng)時，認(rèn)證方根據(jù)身份，檢查通信實體數(shù)據(jù)庫，以查找對應(yīng)的認(rèn)證方式如找到則開始發(fā)送相應(yīng)的認(rèn)證請求。 ?對方在接到認(rèn)證請求時,首先檢查它自己是否支持認(rèn)證者所要求的認(rèn)證請求如不支,持,則要發(fā)送一個NAK,否否本文檔所提供的信息僅供參考之用，不能作為科學(xué)依據(jù)，請勿模仿。 文檔如有不當(dāng)之處，請聯(lián)系本人或網(wǎng)站刪除。 認(rèn)包攜帶自己允許的認(rèn)證類型。 如支持則發(fā)送認(rèn)證響應(yīng)。 ?NAK認(rèn)證者檢查響應(yīng)包，如是否認(rèn)包，則重發(fā)對方允許的認(rèn)證請求。 如是上一次的認(rèn)證請求的響應(yīng)，則檢查它是否是它所期待的響應(yīng)以決定認(rèn)證成功與失敗，從而決定鏈路的打開與關(guān)閉。 ?如上一步成功，向?qū)Ψ桨l(fā)送認(rèn)證確認(rèn)包，以使對方把鏈路打開,通知上層網(wǎng)絡(luò)控制協(xié)議進(jìn)行網(wǎng)絡(luò)通信協(xié)議參數(shù)的協(xié)商，隨著各個網(wǎng)絡(luò)控制協(xié)議打開之后，PPP就把數(shù)據(jù)鏈路交給通信網(wǎng)絡(luò)協(xié)議，這時雙方才能夠進(jìn)行實際的通信。 ?PPP當(dāng)所有的上層協(xié)議都不再需要使用此數(shù)據(jù)鏈路時，將發(fā)送中止鏈路請求包來結(jié)束數(shù)據(jù)鏈路。 EAP-MD5用支持使用CHAP和靜態(tài)密碼進(jìn)行認(rèn)證；EAP-TLS；RADIUS定義了如何打包EAP信息，從而在網(wǎng)絡(luò)上傳輸這些信息。 下圖中顯示了所使用的3中標(biāo)準(zhǔn)。 （通常稱將為請求者）如何將EAP信息傳輸?shù)骄W(wǎng)絡(luò)訪問設(shè)備（認(rèn)證者）。 是網(wǎng)絡(luò)訪問設(shè)備能夠是AP,交換機(jī)，路由器，VPN網(wǎng)關(guān)等。 認(rèn)用證者使用RADIUS協(xié)議將這些信息傳輸?shù)秸J(rèn)證服務(wù)器，改本文檔所提供的信息僅供參考之用，不能作為科學(xué)依據(jù)，請勿模仿。 文檔如有不當(dāng)之處，請聯(lián)系本人或網(wǎng)站刪除。 服務(wù)器會確認(rèn)此請求者是否能夠訪問網(wǎng)絡(luò)。 注意，認(rèn)證者處通常沒有本地定義的用戶憑據(jù)，它通常在認(rèn)證服務(wù)器上查找此內(nèi)容。 （二）p ip安全協(xié)議c1IP Sec協(xié)議概述c IPSec是一系列基于P IP網(wǎng)絡(luò)（包括Intra、Extra和和Inter）的，由F IETF正式定制的開放性P IP安全標(biāo)準(zhǔn)，是虛擬專網(wǎng)的基礎(chǔ)，已經(jīng)相當(dāng)成熟可靠。 c IPSec能夠保證局域網(wǎng)、專用或公用的廣域網(wǎng)及t Inter上信息傳輸?shù)陌踩?保證t Inter上各分支辦公點的安全連接:公司能夠借助Inter或公用的廣域網(wǎng)搭建安全的虛擬專用網(wǎng)絡(luò)。 這使得公司能夠不必耗巨資去建立自己的專用網(wǎng)絡(luò)，而只需依托t Inter即能夠獲得同樣的效果。 保證t Inter上遠(yuǎn)程訪問的安全:在計算機(jī)上裝有c IPSec的終端用戶能夠通過撥入所在地的P ISP的方式獲得對公司網(wǎng)絡(luò)的安全訪問權(quán)。 這一做法降低了流動辦公雇員及遠(yuǎn)距離工作者的長途電話費用。 通過外部網(wǎng)或內(nèi)部網(wǎng)建立與合作伙伴的聯(lián)系:IPSec通過認(rèn)證和鑰匙交換機(jī)制確保企業(yè)與其它組織的信息往來的安全性與機(jī)密性。 提高了電子商務(wù)的安全性:盡管在電子商務(wù)的許多應(yīng)用中已嵌入了一些安全協(xié)議，c IPSec的使用仍能夠使其安全級別在原有的基礎(chǔ)上更進(jìn)一步，因為所有由網(wǎng)絡(luò)管理員指定的通信都是經(jīng)過加密和認(rèn)證的。 c IPSec有的主要特征在于它能夠?qū)λ蠵 IP級的通信進(jìn)行加密和認(rèn)證，正是這一點才使IPSec能夠確保包括遠(yuǎn)程登錄、客戶/及服務(wù)器、電子郵件、文件傳輸及b Web訪問在內(nèi)多種應(yīng)本文檔所提供的信息僅供參考之用，不能作為科學(xué)依據(jù)，請勿模仿。 文檔如有不當(dāng)之處，請聯(lián)系本人或網(wǎng)站刪除。 用程序的安全。 IPSec在傳輸層之下，對于應(yīng)用程序來說是透明的。 當(dāng)裝在路由器或防火墻上安裝IPSec時，無需更改用戶或服務(wù)器行系統(tǒng)中的軟件設(shè)置。 即使在終端系統(tǒng)中執(zhí)行IPSec，應(yīng)用程序一類的上層軟件也不會被影響。 IPSec對終端用戶來說是透明的，因此不必對用戶進(jìn)行安全機(jī)制的培訓(xùn)。 如果需要的話，IPSec能夠為個體用戶提供安全保障，這樣做就能夠保護(hù)企業(yè)內(nèi)部的敏感信息。 IPSec正向Inter靠攏。 已經(jīng)有一些機(jī)構(gòu)部分或全部了執(zhí)行了IPSec。 IAB的前任總裁Christian Huitema認(rèn)為，關(guān)證于如何保證Inter安全的討論是他所見過的最激烈的討論之一。 討論的話題之一就是安全是否在恰當(dāng)?shù)膮f(xié)議層上被使供用。 想要提供IP級的安全，IPSec必須成為配置在所有相關(guān)括平臺（包括Windows NT，Unix和和Macint