計算機(jī)網(wǎng)絡(luò)（本科）第七章 互聯(lián)網(wǎng)(Internet)協(xié)議及應(yīng)用

TCP/IP協(xié)議及應(yīng)用第七章主要內(nèi)容協(xié)議棧IP地址TCP/IP協(xié)議IPv61、TCP/IP協(xié)議棧ApplicationPresentationSessionTransportNetworkDatalinkPhysical12345672、IP地址IPv42.1IPv42.1IPv4邏輯地址分類2.1IPv4地址范圍2.1IPv4-特殊地址網(wǎng)絡(luò)地址2.1IPv4-特殊地址指定網(wǎng)絡(luò)廣播地址（路由器可轉(zhuǎn)發(fā)）2.1IPv4-特殊地址受限廣播地址（路由器不轉(zhuǎn)發(fā)）2.1IPv4-特殊地址回環(huán)地址2.1IPv4-特殊地址

公共地址IETF分別從A、B、C三類地址中取出一段地址范圍保留用作內(nèi)部網(wǎng)絡(luò)地址，他們分別是：

～55

～55

～55

這些地址范圍是專門用來標(biāo)識內(nèi)部網(wǎng)絡(luò)的，不能用來訪問Internet，因為Internet上路由器不會轉(zhuǎn)發(fā)目標(biāo)地址在上述三個范圍內(nèi)的數(shù)據(jù)包。公共地址與Internet的互連NAT專用網(wǎng)本地主機(jī)x1.x2.x3.x4源地址a3.b3.c3.d3a1.b1.c1.d1a2.b2.c2.d2….dn公共IP地址庫源地址x1.x2.x3.x4源地址x1.x2.x3.x4Internet2.1IPv4-特殊地址2.1IPv4-特殊地址

物理地址（48bits）

Ipconfig/all RoutePrint特殊地址小結(jié)特殊地址網(wǎng)絡(luò)地址，不可以用作主機(jī)地址廣播地址，不可以用作主機(jī)地址回環(huán)地址公共地址內(nèi)部地址一個主機(jī)發(fā)送一個分組時如何發(fā)現(xiàn)目的地在那里？網(wǎng)絡(luò)掩碼2.2IPv4NetworkMaskDef.網(wǎng)絡(luò)掩碼：用于標(biāo)志網(wǎng)絡(luò)地址和主機(jī)地址的代碼。不同類型的網(wǎng)絡(luò)（A、B、C）具有不同的網(wǎng)絡(luò)掩碼

網(wǎng)絡(luò)地址的獲?。哼壿嫛芭c”2.2Sub-NetworkMask劃分網(wǎng)絡(luò)號和主機(jī)邊界對子網(wǎng)進(jìn)行精確的劃分，減小子網(wǎng)絡(luò)空間子網(wǎng)掩碼就是將Hostid的一部分作為網(wǎng)絡(luò)Netid的延伸掩碼地址的格式：前N位1+后M位0=32掩碼地址“與”IP地址=對應(yīng)子網(wǎng)的“實際網(wǎng)絡(luò)地址”路由特點子網(wǎng)劃分對外部的路由器是透明的對子網(wǎng)內(nèi)部的路由器是不透明的2.2Sub-NetworkMask子網(wǎng)掩碼舉例路由器xxxxxxxxxxxxxx路由器202.183.56.xxxxxxxxx子網(wǎng)掩碼舉例學(xué)校將（C類地址）分配給兩個系，每個系約有120臺計算機(jī)。掩碼地址可定義為：28系1地址范圍：—26

子網(wǎng)地址：110010101011011100111000 0xxxxxxx系2地址范圍：29—54

子網(wǎng)地址：110010101011011100111000 1xxxxxxx思考題：已知網(wǎng)絡(luò)地址今有A、B、C三個機(jī)構(gòu)需要的ip地址分別為120、60和62個，如何劃分子網(wǎng)，子網(wǎng)掩碼、地址和ip地址范圍是多少？3TCP/IP協(xié)議網(wǎng)絡(luò)層協(xié)議:ICMPIGMPARPRARP傳輸層協(xié)議:UDPTCP應(yīng)用層協(xié)議:SMTP/POPHTTPDNSFTP…不同層次的協(xié)議數(shù)據(jù)幀的分用過程3.1網(wǎng)絡(luò)層協(xié)議網(wǎng)絡(luò)層協(xié)議格式頭格式ARP/RARPICMPIGMPVersionIHLTypeofServiceTotallengthofIPdatagramIdentificationFlagsFragmentoffsetTime-to-liveProtocolHeaderchecksum(forerrorcontrol)

SourceIPaddressDestinationIPaddressOptionsPaddingPayloadofIPdatagramVersion(4bits):tellsthatthisisIPVersion4(IPv4)IPv4headerstructureIPv4headerstructureVersionIHLTypeofServiceTotallengthofIPdatagramIdentificationFlagsFragmentoffsetTime-to-liveProtocolHeaderchecksum(forerrorcontrol)

SourceIPaddressDestinationIPaddressOptionsPaddingPayloadofIPdatagramHeaderlength(4bits)isneededsinceOptions

+

Paddingcanvaryinlength.Options：Security(packetclassification),Strictsourcerouting(thewholeroutinglist),Loosesourcerouting(themandatoryroutinglist),Recordroute(recordtheIPaddressofeachhop),Timestamp(recordtheIPaddressandtimestampofeachhop).IPv4headerstructureVersionIHLTypeofServiceTotallengthofIPdatagramIdentificationFlagsFragmentoffsetTime-to-liveProtocolHeaderchecksum(forerrorcontrol)

SourceIPaddressDestinationIPaddressOptionsPaddingPayloadofIPdatagramToS=TypeofService(8bits)isusedforQoSmanagementpurposes.Thefirst3bitsofTOSindicatepriorities,0beinglow(normalpacket)and7beinghigh(networkcontrolpacket);thenext3bitsindicateservicetypes,beingdelay,throughput,andreliability;thelast2bitsarereserved.Sourcecoulduseservicetypebitstoindicatetheroutingmetricstobeused.IPv4headerstructureVersionIHLTypeofServiceTotallengthofIPdatagramIdentificationFlagsFragmentoffsetTime-to-liveProtocolHeaderchecksum(forerrorcontrol)

SourceIPaddressDestinationIPaddressOptionsPaddingPayloadofIPdatagramDatagramlength(16bits):sincethisfieldis16bitslong,theIPdatagramcancontainupto216=65535bytes(intheory).Mostrouters,however,cannothandlesuchlargedatagrams.SEU

31IPv4headerstructureVersionIHLTypeofServiceTotallengthofIPdatagramIdentificationFlagsFragmentoffsetTime-to-liveProtocolHeaderchecksum(forerrorcontrol)

SourceIPaddressDestinationIPaddressOptionsPaddingPayloadofIPdatagramIPfragmentation:alargeIPdatagrammaybefragmented(inanyrouteralongthepath)andwillbereassembledatthedestination.Flags:1stbit–reserved;2ndbit–DF,0＝fragmentyes,1＝fragmentno;3rdbit–MF,0＝lastfragment,1＝morefragment.AllfragmentscontainthesamenumberHasvaluezeroinlastfragmentPositionoffragmentinoriginaldatagramIPv4headerstructureVersionIHLTypeofServiceTotallengthofIPdatagramIdentificationFlagsFragmentoffsetTime-to-liveProtocolHeaderchecksum(forerrorcontrol)

SourceIPaddressDestinationIPaddressOptionsPaddingPayloadofIPdatagramTime-to-live(8bits):thisnumberisdecreasedbyoneineachrouteralongthepath.Ifnumberzeroisreachedinarouter,IPdatagramisdiscardedandroutersendsanICMPmessage(TTLexpired)tothesourceofthedatagram.SEU

33IPv4headerstructureVersionIHLTypeofServiceTotallengthofIPdatagramIdentificationFlagsFragmentoffsetTime-to-liveProtocolHeaderchecksum(forerrorcontrol)

SourceIPaddressDestinationIPaddressOptionsPaddingPayloadofIPdatagramProtocolfield(8bits):describeswhichhigherlayerprotocolisused(TCP,UDP,SCTP...).TheheaderofthisupperprotocolislocatedatthebeginningoftheIPdatagrampayload.e.g.6＝TCP,17＝UDP,1＝ICMP,89＝OSPF,etc.Startshere...SEU

34IPv4headerstructureVersionIHLTypeofServiceTotallengthofIPdatagramIdentificationFlagsFragmentoffsetTime-to-liveProtocolHeaderchecksum(forerrorcontrol)

SourceIPaddressDestinationIPaddressOptionsPaddingPayloadofIPdatagramHeaderchecksum(16bits):usedforerrorcontrol(ifused,routersalongthepathhavetorecalculatethechecksum).ThiskindoferrorcontrolisnotusedinIPv6(sincethesameerrorcontrolfunctionisofferedbyTCP-andevenUDP).SEU

35IPv4headerstructureVersionIHLTypeofServiceTotallengthofIPdatagramIdentificationFlagsFragmentoffsetTime-to-liveProtocolHeaderchecksum(forerrorcontrol)

SourceIPaddressDestinationIPaddressOptionsPaddingPayloadofIPdatagramSourceanddestinationIPaddress(32bitseach):notethattheseaddressesarenotchangedinroutersalongtheroute.通過捕獲的分組查看IP頭格式地址解析協(xié)議(ARP/RARP)ARP/RARPARP幀格式ARP分組格式以太網(wǎng)為1IP0800硬件地址長度協(xié)議地址長度ARPexamplebroadcastunicast使用ARP協(xié)議的四種情況ARP緩存-cacheArp–a–g–s–d主機(jī)內(nèi)設(shè)置緩沖區(qū)，是為了快速查找通過主機(jī)演示Arp-aArp–dArp–sC:\DocumentsandSettings\Administrator>PING99Pinging99with32bytesofdata:Replyfrom99:bytes=32time<1msTTL=128Replyfrom99:bytes=32time<1msTTL=128Replyfrom99:bytes=32time<1msTTL=128Replyfrom99:bytes=32time<1msTTL=128Pingstatisticsfor99:Packets:Sent=4,Received=4,Lost=0(0%loss),Approximateroundtriptimesinmilli-seconds:Minimum=0ms,Maximum=0ms,Average=0msC:\DocumentsandSettings\Administrator>ARP-DC:\DocumentsandSettings\Administrator>ARP-ANoARPEntriesFoundC:\DocumentsandSettings\Administrator>ARP-S9900-88-88-88-88-88C:\DocumentsandSettings\Administrator>APR-A'APR'不是內(nèi)部或外部命令，也不是可運(yùn)行的程序或批處理文件。C:\DocumentsandSettings\Administrator>ARP-AInterface:920x10005InternetAddressPhysicalAddressType9900-88-88-88-88-88staticC:\DocumentsandSettings\Administrator>PING99Pinging99with32bytesofdata:Requesttimedout.Requesttimedout.Requesttimedout.Requesttimedout.Pingstatisticsfor99:Packets:Sent=4,Received=0,Lost=4(100%loss),C:\DocumentsandSettings\Administrator>ARP-DC:\DocumentsandSettings\Administrator>ARP-ANoARPEntriesFoundC:\DocumentsandSettings\Administrator>PING99Pinging99with32bytesofdata:Replyfrom99:bytes=32time<1msTTL=128Replyfrom99:bytes=32time<1msTTL=128Replyfrom99:bytes=32time<1msTTL=128Replyfrom99:bytes=32time<1msTTL=128Pingstatisticsfor99:Packets:Sent=4,Received=4,Lost=0(0%loss),Approximateroundtriptimesinmilli-seconds:Minimum=0ms,Maximum=0ms,Average=0msC:\DocumentsandSettings\Administrator>通過sniffer工具察看保存結(jié)果Arp欺騙A:ip地址

硬件地址AA:AA:AA:AA:AA:AA

B:ip地址

硬件地址BB:BB:BB:BB:BB:BB

C:ip地址

硬件地址CC:CC:CC:CC:CC:CC

Arp欺騙的實施研究這臺主機(jī)，發(fā)現(xiàn)這臺主機(jī)的漏洞。根據(jù)發(fā)現(xiàn)的漏洞使主機(jī)A當(dāng)?shù)?，暫時停止工作。這段時間里，入侵者把自己的ip改成

發(fā)一個源ip地址為,源MAC地址為BB:BB:BB:BB:BB:BB的包給主機(jī)C，要求主機(jī)C更新自己的arp轉(zhuǎn)換表。主機(jī)更新了arp表中關(guān)于主機(jī)A的ip-->mac對應(yīng)關(guān)系。防火墻失效了，入侵的ip變成合法的mac地址，可以telnet了。ARP欺騙的防范不要把網(wǎng)絡(luò)安全信任關(guān)系建立在ip地址的基礎(chǔ)上或硬件mac地址基礎(chǔ)上，理想的關(guān)系應(yīng)該建立在ip+mac基礎(chǔ)上。設(shè)置靜態(tài)的mac-->ip對應(yīng)表，不要讓主機(jī)刷新設(shè)定好的轉(zhuǎn)換表。ARPProxyRARPRARPRARP思考題：1、如何利用ARP協(xié)議實現(xiàn)一個LAN內(nèi)的IP地址使用情況監(jiān)控？2、ARP攻擊的基本原理?3.1.2ICMP用于網(wǎng)絡(luò)設(shè)備和結(jié)點之間的控制和差錯報文的傳輸（主機(jī)之間，而不是應(yīng)用之間）Errormessage—一些網(wǎng)絡(luò)錯誤信息Ping—測試工具Traceroute—路由跟蹤

windowstracert封裝于IP數(shù)據(jù)包內(nèi)部ICMPICMP報文分類覆蓋整個ICMP報文共有15種類型ICMP報文分類ICMP報文分類ICMP差錯報文ICMP差錯報文封裝形式ICMP差錯報文包含原ip數(shù)據(jù)報的頭部和前8個數(shù)據(jù)字節(jié)，目的是使接受該ICMP報文的主機(jī)識別上層協(xié)議與應(yīng)用進(jìn)程ICMP差錯報文目的不可達(dá)網(wǎng)1網(wǎng)2網(wǎng)3網(wǎng)4主機(jī)A主機(jī)BR1R2R3ICMP報文返回ICMP差錯報文重定向－分組中含有路由信息，路由優(yōu)化A要發(fā)送分組到B，通過默認(rèn)路由到R1，R1轉(zhuǎn)發(fā)時發(fā)現(xiàn)下一跳是R2，并且A、R1、R2直接互聯(lián)。ICMP差錯報文重定向重定向報文只能由路由器產(chǎn)生重定向報文是用于主機(jī)而不是路由器的ICMP查詢報文ICMP查詢報文時間戳請求報文ID和SN由發(fā)送端任意確定ICMP查詢報文請求回顯－pingTRACEROUTE（LINUX）TRACERT（WINDOWS）的基本原理是什么（思考題）通過sniffer展示3.1.3IGMPMulticastInternetGroupManagementProtocolRFC1112IGMP報文格式報文類型類型1：多播路由器查詢報文，組地址為0類型2：主機(jī)組播報告報文，組地址為該主機(jī)加入的組播組。多播地址通用多播地址：永久多播組

子網(wǎng)內(nèi)所有系統(tǒng)組

子網(wǎng)內(nèi)所有路由器

NTP網(wǎng)絡(luò)時間協(xié)議組

……….多播地址轉(zhuǎn)換多播組地址到以太網(wǎng)物理地址轉(zhuǎn)換以太網(wǎng)物理多播地址：01.00.5e.00.00.00~01.00.5e.7f.ff.ff轉(zhuǎn)換5位沒有進(jìn)行映射每個物理多播地址對應(yīng)32個組播地址以太網(wǎng)多播標(biāo)志應(yīng)用層組播應(yīng)用層組播，就是在應(yīng)用層實現(xiàn)組播功能而不需要網(wǎng)絡(luò)層的支持。這樣就可以避免出現(xiàn)由于網(wǎng)絡(luò)層遲遲不能部署對組播的支持而使組播應(yīng)用難以進(jìn)行的情況。3.2傳輸層協(xié)議傳輸層的位置和特點TCPUDP3.2傳輸層協(xié)議3.2.1TCP協(xié)議概述TCP協(xié)議概述面向連接連接定義：四元組（客戶IP地址、客戶端口號、服務(wù)器IP地址和服務(wù)器端口號）；應(yīng)用程序利用TCP協(xié)議進(jìn)行數(shù)據(jù)傳輸之前，首先建立基于TCP的四元組邏輯連接；進(jìn)行數(shù)據(jù)傳輸之前進(jìn)行“握手”，雙工通信。Tcp協(xié)議概述可靠傳輸服務(wù)TCP協(xié)議利用網(wǎng)絡(luò)層的IP協(xié)議進(jìn)行數(shù)據(jù)傳輸，而IP協(xié)議是一種不可靠協(xié)議。（丟包，失序），如何獲得可靠性？數(shù)據(jù)分割使之適于網(wǎng)絡(luò)傳輸定時重傳機(jī)制校驗和重復(fù)丟棄和失序糾正流量控制Tcp協(xié)議概述面向字節(jié)流的傳送服務(wù)

TCP協(xié)議將應(yīng)用程序需要傳輸?shù)臄?shù)據(jù)理解為按順序排列的二進(jìn)制位，并按八位字節(jié)為基本單位，形成有序的八位字節(jié)流。發(fā)送方將數(shù)據(jù)以字節(jié)流的順序遞交給下層的TCP協(xié)議進(jìn)行傳輸，TCP協(xié)議在組織傳輸時并不關(guān)心數(shù)據(jù)的結(jié)構(gòu)，接收方的TCP協(xié)議將數(shù)據(jù)以相同的字節(jié)流順序交給接收方的程序。TCPConnectanddisconTCPConnectanddisconConnect：（socket)1)請求端（通常稱為客戶）發(fā)送一個syn段指明客戶打算連接的服務(wù)器的端口，以及初始序號；2)服務(wù)器發(fā)回包含服務(wù)器的初始序號的syn報文段作為應(yīng)答。同時，將確認(rèn)序號設(shè)置為客戶的ISN+1；3)客戶將確認(rèn)序號設(shè)置為服務(wù)器的ISN+1。TCPConnectanddiscon關(guān)閉連接TCPConnectanddiscon關(guān)閉連接1、建立一個連接需要三次握手，而終止一個連接要經(jīng)過4次握手；2、TCP連接是全雙工（即數(shù)據(jù)在兩個方向上能同時傳遞），因此每個方向必須單獨地進(jìn)行關(guān)閉；3、收到一個FIN只意味著在這一方向上沒有數(shù)據(jù)流動，一個TCP連接在收到一個FIN后仍能發(fā)送數(shù)據(jù)。TCPConnectanddiscon半關(guān)閉TCPConnectanddisconTCP狀態(tài)圖TCP超時與重傳通信端收到對方分組后發(fā)送確認(rèn)信息ACK發(fā)送端等待ACK發(fā)送后啟動定時器，超時重傳HowtoGetRTTTCP最大Max-Send-SegmentMSS=Min（MTU，SMSS，RMSS）通過Sniffer展示3.2.2UDPTCP/UDP協(xié)議對比首先，TCP是一種面向連接的協(xié)議，而UDP是無連接的協(xié)議。這其中的區(qū)別在于：第一，TCP協(xié)議是以連接作為協(xié)議數(shù)據(jù)的最終目標(biāo)的。UDP協(xié)議則是以目標(biāo)端口作為協(xié)議數(shù)據(jù)的最終目標(biāo)。因此，TCP的協(xié)議端口是可以復(fù)用的，UDP協(xié)議的端口在同一時間則只能為一個應(yīng)用程序所用。第二，一個連接是由兩個端點構(gòu)成的，并為該連接分配一定的資源（緩沖區(qū)）。UDP協(xié)議則不需要這個過程，可以直接發(fā)送和接收數(shù)據(jù)。TCP/UDP協(xié)議對比其次，TCP提供的是可靠的傳輸服務(wù)，而UDP協(xié)議提供的是不可靠的服務(wù)。使用不可靠的服務(wù)進(jìn)行數(shù)據(jù)傳輸時，數(shù)據(jù)可能會丟失，失序，重復(fù)等。而可靠的服務(wù)能保證發(fā)送方發(fā)送的數(shù)據(jù)能原樣到達(dá)接收方。最后，TCP提供的是面向字節(jié)流的服務(wù)。應(yīng)用程序只需將要傳輸?shù)臄?shù)據(jù)以字節(jié)流的形式提交給TCP協(xié)議，在連接的另一端，數(shù)據(jù)以同樣的字節(jié)流順序出現(xiàn)在接收程序中。而UDP協(xié)議的傳輸單位是數(shù)據(jù)塊，一個數(shù)據(jù)塊只能封裝在一個UDP數(shù)據(jù)包中。TCP/UDP應(yīng)用對比可靠應(yīng)用需要TCP協(xié)議TCP協(xié)議的連接建立需要一定時間，不適于實時性要求的應(yīng)用而用UDP協(xié)議具有一定丟失不敏感的應(yīng)用使用UDP協(xié)議思考題：UDP協(xié)議是不可靠協(xié)議，通常在時實性較強(qiáng)的應(yīng)用中使用，為什么？若發(fā)送的重要命令或數(shù)據(jù)丟失如何解決？3.3應(yīng)用層協(xié)議電子郵件原理與協(xié)議httpDNSFTP3.3.1Mail3.3.1MailProtocolSMTP：PostelJB.SimpleMailTransferProtocol.RFC821[EB/OL]./rfc/rfc0821.txtPOP：MyersJ.PostOfficeProtocol-Version3.RFC1939[EB/OL]./rfc/rfcl939.txt3.3.1MailTheoryFoxmailOutlookSENDMAILQMAILSMTPPOP3.3.1MailFormatrfc822Rfc822

定義電子郵件文本(textual)信息交換標(biāo)準(zhǔn)格式、詳細(xì)的信息頭格式和單一信息體(BODY)格式,它針對的是基于ASCII字符集的純文本格式,它的不足之處主要表現(xiàn)在:1、對于圖形圖像、語音、結(jié)構(gòu)化文本等多媒體信息并沒有提供相應(yīng)的表示機(jī)制.2、與基于X.400的主機(jī)之間無法進(jìn)行完整的信息交換.3、不支持同一郵件信息內(nèi)的多個信息體格式.3.3.1MailFormat-MIMERFC1341(RFC2231、RFC2646等) MIME（MultipurposeInternetMailExtensions）在幾個方面進(jìn)行了擴(kuò)展.它主要包含如下功能:1、MIME版本的頭域(Field),用以指明該郵件信息頭符合本協(xié)議.2、內(nèi)容類型頭域,用于指明信息體的類型及子類型.3、內(nèi)容傳輸編碼頭,用來指明信息編碼,主要分為五種編碼: 8bit、7bit、binary、quotedprintable和base643.3.1MIME－多用途郵件格式3.3.1MIME－base64編碼目的將其它格式的文檔轉(zhuǎn)換為7位的數(shù)據(jù)流；用于對圖像、聲音和執(zhí)行文件等。方法將文件看作二進(jìn)制流，每6位形成一組，作為索引號碼選擇對應(yīng)的可傳輸字符；對應(yīng)的64個字符為(A-Z,a-z,0-9,+,-)，其對應(yīng)的編號為0-63。3.3.1MIME－base64編碼3.3.1MIME－Quoted-printable目的將非ASCII表示轉(zhuǎn)換為ASCII表示方法將非ASCII表示的數(shù)值用兩個十六進(jìn)制數(shù)表示，如89H表示為ASCII的編碼38H和39H兩個十六進(jìn)制數(shù)，然后前面加上“=”的ASCII編碼。3.3.1MIME－Quoted-printable3.3.1MailFormat郵件地址3.3.1MailFormat傳統(tǒng)信件與email3.3.1SMTPConnect25ConnectionestablishmentMessage

transferConnectiontermination3.3.1Pop-postofficeprotocolpop33.3.1垃圾郵件（SPAM）《中國互聯(lián)網(wǎng)協(xié)會反垃圾郵件規(guī)范》對垃圾郵件作了如下界定：

收件人事先沒有提出要求或者同意接收的廣告、電子刊物、各種形式的宣傳品等宣傳性的電子郵件；收件人無法拒收的電子郵件；隱藏發(fā)件人身份、地址、標(biāo)題等信息的電子郵件；含有虛假的信息源、發(fā)件人、路由等信息的電子郵件。（SPAM）的產(chǎn)生

著名的垃圾郵件事件是在1994年4月份，Canter和Siegel的法律事務(wù)所把一封標(biāo)題為“GreenCardSpam”的移民顧問服務(wù)廣告郵件發(fā)到6000多個新聞組，形成典型的垃圾郵件，并引起接收者的公憤，以至于人們以該郵件標(biāo)題的最后一個單詞“Spam”作為垃圾郵件的稱呼。

（SPAM）的危害CNNIC于2005年7月發(fā)布《第十六次中國互聯(lián)網(wǎng)絡(luò)發(fā)展?fàn)顩r統(tǒng)計報告》顯示，中國網(wǎng)民平均每周收到14.5封電子郵件，其中垃圾郵件占了9.3封，垃圾郵件數(shù)量長期以來超過正常郵件數(shù)量（SPAM）的危害中網(wǎng)民每周收到和發(fā)出的電子郵件

（SPAM）的處理基于客戶端和服務(wù)器端BlackMenuWhiteMenu基于規(guī)則（rule）的郵件過濾基于概率統(tǒng)計的過濾方法（SPAM）的處理（統(tǒng)計過濾）（SPAM）的處理（SPAM）的處理基于網(wǎng)絡(luò)行為（規(guī)則）3.3.2HTTP/WWWHTTP－HypertextTransferProtocol無狀態(tài)協(xié)議WWW的核心協(xié)議應(yīng)用層1990－Rfc2616－h(huán)ttp1.1HTTPParadigmHTTPMessagetypesHTTPRequestMessageHTTPRequestLineHTTPMethodGETHEADPOSTPUTDELETEHTTPGETGET后跟隨一個網(wǎng)頁的位置，服務(wù)器接受請求并返回其請求的頁

面。除了頁面位置作參數(shù)之外，請求還可以跟隨協(xié)議的版本如HTTP/1.0等作為參數(shù)，以發(fā)送給服務(wù)器更多的信息。HTTPPOSTPOST請求要求服務(wù)器接收大量的信息，除了POST后面跟隨的參數(shù)之外，瀏覽器還會在后面持續(xù)發(fā)送數(shù)據(jù)，讓服務(wù)器進(jìn)行處理。通常，POST方法是和CGI程序分不開的，服務(wù)器應(yīng)該啟動一個CGI程序來處理POST發(fā)送來的數(shù)據(jù)。

HTTPHEADHEAD請求在客戶程序和服務(wù)器之間進(jìn)行交流，而不會返回具體的文檔。當(dāng)使用GET和

POST方法時，服務(wù)器最后都將結(jié)果文檔返回給客戶程序，瀏覽器將刷新顯示。而HEAD請求則不同，它僅僅交流一些內(nèi)部數(shù)據(jù)，這些數(shù)據(jù)不會影響瀏覽的過程。因此HEAD方法通常不

單獨使用，而是和其他的請求方法一起起到輔助作用。HTTPURLHTTPResponsemessageHTTPStatuslineHTTPSTATUSCODEHTTP示例GETHTTPHEADHTTPPOSTWeb標(biāo)準(zhǔn)()Web1.0

1989年，在CERN任職的英國人TimBerners.Lee發(fā)明了WorldWideWeb，通過WEB，互聯(lián)網(wǎng)上的資源可以在一個網(wǎng)頁里比較直觀的表示出來；而且資源之間，在網(wǎng)頁上可以相互鏈接。

1994年，斯坦福大學(xué)兩位博士生楊致遠(yuǎn)和DavidFilo共同創(chuàng)辦了雅虎，為用戶提供導(dǎo)航服務(wù)，并提出了互聯(lián)網(wǎng)黃頁概念。

1997年，Google創(chuàng)始人LarryPage和SergeyBrin在斯坦福大學(xué)開發(fā)出一套用于網(wǎng)頁評級的系統(tǒng)，隨后推出了大受歡迎的搜索服務(wù)。

Web標(biāo)準(zhǔn)web2.0

2004年O’ReillyMediaInc.副總裁DaleDougherty在公司的一次籌備會上偶然提出了Web2.0一詞，全球第一次Web2.0大會于2004年10月在美國舊金山召開。從此，Web2.0這一概念以不可思議的速度在全球傳播開來。

Web2.0核心是以人為中心。為用戶提供更方便工具，鼓勵提供內(nèi)容。根據(jù)用戶在互聯(lián)網(wǎng)上留下的痕跡，組織瀏覽線索，提供相關(guān)的服務(wù)，給用戶創(chuàng)造新的價值。Web2.0是相對Web1.0的新一類互聯(lián)網(wǎng)應(yīng)用的統(tǒng)稱。Web2.0技術(shù)主要包括：博客（BLOG）、RSS、百科全書（Wiki）、網(wǎng)摘、社會網(wǎng)絡(luò)（SNS）、P2P、即時信息（IM）等。

WWW－worldwideweb目標(biāo)支持構(gòu)建分布式的協(xié)作超媒體信息系統(tǒng)，將整個因特網(wǎng)的信息資源組合在一起，信息以頁面的形式提供給客戶。頁面及其關(guān)系以鏈接的方式形成—超文本；混合了音頻/視頻的內(nèi)容，需要多種播放媒體的支持—超媒體?？蛻魴C(jī)服務(wù)器因特網(wǎng)瀏覽表示W(wǎng)WW－worldwidewebHypertextBrowerstructureWeb類型Web技術(shù)發(fā)展的第一階段——靜態(tài)文檔

主要以靜態(tài)文檔形式提供信息Web技術(shù)發(fā)展的第二階段——動態(tài)頁面以數(shù)據(jù)庫為后臺數(shù)據(jù)支撐，提供動態(tài)交互Web技術(shù)發(fā)展的第三階段——實時可伸縮的事務(wù)處理電子商務(wù)需求，實時、可擴(kuò)展和安全需求htmlxmlxhtmlHTML三個主要缺點:

1、不能適應(yīng)現(xiàn)在越多的網(wǎng)絡(luò)設(shè)備和應(yīng)用的需要，比如手機(jī)、PDA、信息家電都不能直接顯示HTML; 2、由于HTML代碼不規(guī)范、臃腫，瀏覽器需要足夠智能和龐大才能夠正確顯示HTML; 3、數(shù)據(jù)與表現(xiàn)混雜，你的頁面要改變顯示，就必須重新制作HTML。XML XML是一種簡單、與平臺無關(guān)并被廣泛采用的標(biāo)準(zhǔn)。

XML標(biāo)記用于定義數(shù)據(jù)本身的結(jié)構(gòu)和數(shù)據(jù)類型，XML相對于HTML的優(yōu)點是它將用戶界面與結(jié)構(gòu)化數(shù)據(jù)分隔開來。htmlxmlxhtmlXML是web發(fā)展的趨勢，XHTML是一個基于XML的置標(biāo)語言，XHTML就是一個扮演著類似HTML的角色的XML，所以，本質(zhì)上說，XHTML是一個過渡技術(shù)，結(jié)合了XML(有幾分)的強(qiáng)大功能及HTML(大多數(shù))的簡單特性。XHTML是當(dāng)前替代HTML4標(biāo)記語言的標(biāo)準(zhǔn)，使用XHTML1.0。WebphishingWebphishingAPWGSPONSORS

：APWGGlobalResearchPartners:

典型攻擊手段（S1:Email發(fā)送）S2：訪問假網(wǎng)頁

Visiblelink:/us/cgi-bin/webscr?cmd=_login-run

Actuallinkto:03/icons/.cgi-bin/paypal/cgi-bin/webscrcmd_login.php

PhishsiteIP:03WebphishinghandlingHtmlimageWebphishinghandlingWebphishinghandling3.3.3DNS主機(jī)名域名域名服務(wù)器地址域名系統(tǒng)配置DNS域名系統(tǒng)（DNS）是一種用于TCP/IP應(yīng)用程序的分布式數(shù)據(jù)庫，它提供主機(jī)名字和IP地址之間的轉(zhuǎn)換及有關(guān)電子郵件的選路信息。每個站點（如大學(xué)中的系、校園、公司或公司中的部門）保留它自己的信息數(shù)據(jù)庫，并運(yùn)行一個服務(wù)器程序供Internet上的其他系統(tǒng)（客戶程序）查詢。DNS提供了允許服務(wù)器和客戶程序相互通信的協(xié)議。從應(yīng)用的角度上看，對DNS的訪問是通過一個地址解析器（resolver）來完成的。在Unix主機(jī)中，該解析器主要是通過兩個庫函數(shù)gethostbyname（）和gethostbyaddr（）來訪問。DNSRFC1034[Mockapetris1987a]說明了DNS的概念和功能，RFC1035[Mockapetris1987b]詳細(xì)說明了DNS的規(guī)范和實現(xiàn)。DNS最常用的版本（包括解析器和名字服務(wù)器）是BIND—伯克利Internet域名服務(wù)器。DNS層次組織DNS層次組織DNS邏輯層次頂級域名三個部分：1)arpa是一個用作地址到名字轉(zhuǎn)換的特殊域2)7個3字符長的普通域3)所有2字符長的域均是基于ISO3166中定義的國家代碼，這些域被稱為國家域，或地理域。主、輔域名服務(wù)器一個名字服務(wù)器負(fù)責(zé)一個或多個區(qū)域。一個區(qū)域的管理者必須為該區(qū)域提供一個主名字服務(wù)器和至少一個輔助名字服務(wù)器。主、輔名字服務(wù)器必須是獨立和冗余的，以便當(dāng)某個名字服務(wù)器發(fā)生故障時不會影響該區(qū)域的名字服務(wù)。主、輔名字服務(wù)器的主要區(qū)別在于主名字服務(wù)器從磁盤文件中調(diào)入該區(qū)域的所有信息，而輔名字服務(wù)器則從主服務(wù)器調(diào)入所有信息。我們將輔名字服務(wù)器從主服務(wù)器調(diào)入信息稱為區(qū)域傳送。DNS分組格式DNS分組格式這個報文由12字節(jié)長的首部和4個長度可變的字段組成。標(biāo)識字段由客戶程序設(shè)置并由服務(wù)器返回結(jié)果?？蛻舫绦蛲ㄟ^它來確定響應(yīng)與查詢是否匹配。標(biāo)志字段0-query1-response0-stdquery（ip）1-inversequery2-serverqueryAuthoritativeanswer1-recursive0-iterativequerystatesDNStypesFormatofQuery&AnswerWhatprotocol-udp/tcpClient(resolver)Client(resolver)MainserveradditionalserverUdp/tcpUdp/tcptcpPort:53NamelengthDomainnameName=label.label…label.Lengthoflabel<=63octetLengthofname<=255octetDNSdomainnamestructureDNSQueryProcessIterative

inwhichtheserverreferstheclienttoanotherserverandletstheclientpursuethequery.Recursive

inwhichthefirstserverpursuesthequeryfortheclientatanotherserver. Bothapproacheshaveadvantagesanddisadvantages,buttheiterativeapproachispreferredforthedatagramstyleofaccess.Thedomainsystemrequiresimplementationoftheiterativeapproach,butallowstherecursiveapproachasanoption.Instanceofiterativequery迭代方式IptteduibmMITseutsinghuapku......wwwemailftpUser用戶主機(jī)：應(yīng)用程序調(diào)用Gethostbyname()--resolver主機(jī)調(diào)用MIT域名服務(wù)器（請求解析）

UserMITDNSeduDNSrootcnDNSEDNSSDNSMITDNSeduDNSrootcnDNSDNSDNSUser遞歸方式3.3.4Ftp協(xié)議標(biāo)準(zhǔn)（rfc0959）

FTP提供的文件傳送是將一個完整的文件從一個系統(tǒng)復(fù)制到另一個系統(tǒng)中。要使用FTP

，就需要有登錄服務(wù)器的注冊帳號，或者通過允許匿名FTP的服務(wù)器來使用。FTP協(xié)議為應(yīng)用層協(xié)議，傳輸層協(xié)議為TCP協(xié)議Ftp協(xié)議user-FTPprocess

Asetoffunctionsincludingaprotocolinterpreter,adatatransferprocessandauserinterfacewhichtogetherperformthefunctionoffiletransferincooperationwithoneormoreserver-FTPprocesses.Theuserinterfaceallowsalocallanguagetobeusedinthecommand-replydialoguewiththeuserserver-FTPprocess

Aprocessorsetofprocesseswhichperformthefunctionoffiletransferincooperationwithauser-FTPprocessand,possibly,anotherserver.Thefunctionsconsistofaprotocolinterpreter(PI)andadatatransferprocess(DTP)Ftp協(xié)議PI：Theprotocolinterpreter.server-DTP：Thedatatransferprocess,initsnormal"active"state,establishesthedataconnectionwiththe"listening"dataport.user-DTP：Thedatatransferprocess"