全套ppt课件-计算机网络自顶向下

上传人:29 文档编号:242861163 上传时间:2024-09-09 格式:PPT 页数:477 大小:7.14MB
返回 下载 相关 举报
全套ppt课件-计算机网络自顶向下_第1页
第1页 / 共477页
全套ppt课件-计算机网络自顶向下_第2页
第2页 / 共477页
全套ppt课件-计算机网络自顶向下_第3页
第3页 / 共477页
点击查看更多>>
资源描述
单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,*,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,第5讲 网络层之二,5b-,*,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,第6讲 数据链路层之二,6b-,*,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,第6讲 数据链路层之三,6c-,*,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,第7讲 多媒体网络,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,第7讲 多媒体网络,第2讲,:,应用层,1,第2讲: 应用层,本讲目标,:,网络应用层的概念和实现,客户端,-,服务器范式,服务模型,通过对常用应用层协议的探讨和分析来学习网络协议,教科书参考,第9章,深层次目标,特定协议,:,http,ftp,smtp,pop,dns,第2讲:应用层1第2讲: 应用层本讲目标: 深层次目标,第2讲,:,应用层,2,应用程序,和,应用层协议,应用程序,:,沟通,分布式的进程,运行在网络主机中的 “用户空间”,在应用程序间交换报文,e.g., email, ftp, Web,应用层协议:,应用层的一个“组成部分”,定义应用程序需交换的报文 和所需采取的动作,使用较低层次所提供的通信服务,(TCP, UDP),application,transport,network,data link,physical,application,transport,network,data link,physical,application,transport,network,data link,physical,第2讲:应用层2应用程序和应用层协议应用程序:沟通, 分布式,第2讲,:,应用层,3,网络应用程序: 一些术语,进程,(Process):,主机中运行中的程序,.,在某些主机中,两个进程使用,进程间通信,(,由,OS,管理).,而运行在不同主机上的进程则使用应用层协议进行通信,用户代理,(,User agent,),:,软件进程,是介于用户(,above,)和网络(,below,)之间的接口,实现应用级协议,Web:,浏览器,E-mail:,OE,、,Foxmail,流媒体,:,media player,第2讲:应用层3网络应用程序: 一些术语进程(Process,第2讲,:,应用层,4,客户端,-,服务器范式,典型的网络应用都是由两个部分组成,:,客户端,和,服务器,application,transport,network,data link,physical,application,transport,network,data link,physical,客户端,:,发起同服务器的联系,(“speaks first”),一般都从服务器请求服务,Web:,客户端由浏览器实现,; e-mail:,通过,OE,、,Foxmial,实现,request,reply,服务器,:,向客户端提供所请求的服务,e.g., Web,服务器发送被请求的,Web,页面,邮件服务器传递,e-mail,第2讲:应用层4客户端-服务器范式典型的网络应用都是由两个部,第2讲,:,应用层,5,应用层协议,(,续,),应用程序接口(,API: application programming interface,),定义应用层和传输层间的接口,插口(,socket: Internet API,),两个进程间的通信, 将数据送入,socket,或从,socket,读出数据,Q:,某个进程如何“认定”另一个 需要与之通信的进程,?,IP,地址,-,运行另一个进程的主机所拥有的,“,端口号(,PORT #,),”,允许接收主机来确定的一个标识,本地进程将报文发送给它,教科书,p232-234,第2讲:应用层5应用层协议(续)应用程序接口(API: ap,第2讲,:,应用层,6,应用进程需要怎样的传输服务,?,数据丢失(,Data loss,),某些应用,(e.g., audio),可以容忍某种程度上的数据丢失,其他应用,(e.g.,文件传输, telnet),要求,100%,可靠的数据传输,实时性(,Timing,),某些应用,(e.g., IP,电话,交互式游戏,),要求较低的时延,带宽(,Bandwidth,),某些应用,(e.g.,多媒体,),对最低带宽有要求,其他应用,(“,弹性应用”,),则可灵活应用所能得到的带宽,第2讲:应用层6应用进程需要怎样的传输服务?数据丢失(Dat,第2讲,:,应用层,7,常用应用程序对传输功能的要求,应用程序,文件传输,e-mail,Web,网页,实时音频,/,视频,存储,音频,/,视频,交互式游戏,金融应用,数据丢失,不丢失,不丢失,不丢失,允许丢失,允许丢失,允许丢失,允许丢失,不丢失,带宽,弹性,弹性,弹性,音频,: 5Kb-1Mb,视频,:10Kb-5Mb,同上,几,Kb/s,以上,弹性,实时性,无,无,无,100s msec,few secs,100s msec,yes and no,第2讲:应用层7常用应用程序对传输功能的要求应用程序数据丢失,第2讲,:,应用层,8,Internet,的传输协议服务,TCP,服务,:,面向连接,:,在客户端和服务器进程之间需要建立连接(,setup,),可靠传输,:,在发送和接受进程之间,流量控制,:,发送数据的速度决不超过接收的速度,拥塞控制,:,当网络超负荷时,束紧发送端口,减缓发送速度,不提供,:,实时性,最小带宽承诺,UDP,服务,:,在客户端和服务器进程之间实现“不可靠的”数据传输,不提供,:,连接建立,可靠性保证,流量控制,拥塞控制,实时性,最小带宽承诺,Q:,既生喻,何生亮,? Why is there a UDP?,第2讲:应用层8Internet 的传输协议服务TCP 服务,第2讲,:,应用层,9,Internet,应用,:,应用,传输协议,应用,e-mail,远程终端访问,Web,文件传输,流媒体,远程文件服务器,IP,电话,应用协议,smtp RFC 821,telnet RFC 854,http RFC 2068,ftp RFC 959,专有协议,(e.g. RealNetworks),NSF,专有协议,(e.g., Vocaltec),所依赖的传输协议,TCP,TCP,TCP,TCP,TCP or UDP,TCP or UDP,typically UDP,第2讲:应用层9Internet应用: 应用, 传输协议应,第2讲,:,应用层,10,http 协议,http: TCP,传输服务,:,客户端启动,TCP,连接,(,创建插口,),到服务器,端口,80,服务器接受来自客户端的,TCP,连接,http,报文,(,应用层协议报文,),在浏览器,(http client),和,Web,服务器,(http server),之间进行交换,关闭,TCP,连接,http,是 “无状态,(,stateless,),”的,服务器不保留任何访问过的请求信息,保留状态的协议很复杂哟,!,过去的历史,(,状态,),需要保留,一旦浏览器,/,服务器崩溃,它们各自的状态视图就会发生分歧,还需要重新核对,小评论,第2讲:应用层10http 协议http: TCP 传输服务,第2讲,:,应用层,11,Web: http,协议,超文本传输协议(,http: hypertext transfer protocol,),万维网应用协议,客户端,/,服务器模式,客户端,:,浏览器请求、接收、展示,Web,对象(,objects,),服务器,:,Web,服务器发送对象对请求进行响应,http1.0: RFC 1945,http1.1: RFC 2068,PC running,Explorer,Server,running,NCSA Web,server,Mac running,Navigator,http request,http request,http response,http response,第2讲:应用层11Web: http 协议超文本传输协议(h,第2讲,:,应用层,12,http,举例,假设用户键入了一个,URL,www.someSchool.edu/someDepartment/home.index,1a,.,http,客户端启动,TCP,连接到,www.someSchool.edu,上的,http,服务器,(,进程,),.,Port 80,是,http,服务器的默认端口,.,2.,http,客户端,发送,http,请求报文,(,包括,URL),进入,TCP,连接插口(,socket,),1b.,在,www.someSchool.edu,上的,http,服务器在,port 80,等待,TCP,的连接请求,. “,接受” 连接并通知客户端,3.,http,服务器接收到请求报文,形成,响应报文(,包含了所请求的对象 ,,someDepartment/home.index,),将报文送入插口(,socket,),time,(,该网页包含文本并引用了,10,jpeg,图片,),第2讲:应用层12http 举例假设用户键入了一个 URL,第2讲,:,应用层,13,http,举例,(,续,.),5,.,http,客户端接收到了包含,html,文件的响应报文。,分析,html,文件,发现,10,个引用的,jpeg,对象,6.,对,10,jpeg,objects,逐个重复,1-5,步,4.,http,服务器关闭,TCP,连接,.,time,第2讲:应用层13http 举例 (续.)5. http 客,第2讲,:,应用层,14,非持续和持续连接,(非持续连接),Non-persistent,http/1.0:,服务器分析请求、响应、关闭,TCP,连接,取对象需要,2 RTTs,TCP,连接,对象请求,/,传送,每次传送都要受到,TCP,连接初始化时的慢启动影响,许多浏览器同时打开多个并行的连接来改善性能,(持续连接),Persistent,http/1.1,的默认设置,在同一,TCP,连接上,:,服务器分析请求、响应请求,分析新的请求、,.,客户端一旦下载到了基本的,html,文件(,base HTML,)马上发送对所有引用对象的请求,.,较少的,RTTs,较少的慢启动,.,第2讲:应用层14非持续和持续连接(非持续连接)Non-pe,第2讲,:,应用层,15,http,报文格式,: request,(请求),two types of http,报文,:,request,response,http,请求,报文,:,ASCII (,可读格式,),GET /somedir/page.html HTTP/1.0,User-agent: Mozilla/4.0,Accept: text/html, image/gif,image/jpeg,Accept-language:fr,(,额外的,carriage return, line feed),请求行,(GET, POST,HEAD,命令,),首部,诸行,回车、换行表示,报文结束,第2讲:应用层15http 报文格式: request(请求,第2讲,:,应用层,16,http,请求报文,:,一般格式,第2讲:应用层16http 请求报文: 一般格式,第2讲,:,应用层,17,http,报文格式,: response,(响应),HTTP/1.0 200 OK,Date: Thu, 06 Aug 1998 12:00:15 GMT,Server: Apache/1.3.0 (Unix),Last-Modified: Mon, 22 Jun 1998 .,Content-Length: 6821,Content-Type: text/html,data data data data data .,状态行,(,协议状态码,状态短语,),首部,诸行,数据, e.g.,被请求的,html,文件,第2讲:应用层17http 报文格式: response(响,第2讲,:,应用层,18,http,响应状态码和短语,200 OK,请求成功,被请求的对象在报文中,301 Moved Permanently,被请求的对象被移动过,新的位置在报文中有说明,(Location:),400 Bad Request,服务器不懂请求报文,404 Not Found,服务器上找不到请求的对象,505 HTTP Version Not Supported,位于(服务器,-,客户端)响应报文的第一行,.,样例,:,第2讲:应用层18http 响应状态码和短语200 OK位于,第2讲,:,应用层,19,自行测试,http (,客户端操作,),1.,用,Telnet,连接测试用的服务器(需要预先登录,UNIX,),:,打开,TCP,连接到,port 80,(,默认的,http,服务器端口,),位于,202.117.35.70,后续键入的内容将发送到,202.117.35.70,的,80,号端口,$,telnet 202.117.35.70,80,2.,键入一条,http,请求报文,:,GET /j1010/hello.htm HTTP/1.0,将该指令键入后,(,按两次回车键,),就将此最短之,(,但是完整的,),GET,请求发到了,http,服务器,3.,请注意观察,http,服务器发回的响应报文,!,第2讲:应用层19自行测试 http (客户端操作)1. 用,第2讲,:,应用层,20,用户,-,服务器的交互,:,认证(,authentication,),认证,:,控制对服务器内容的访问,信用认证,:,一般通过用户名,口令进行,无状态,:,客户端必须在每次请求前进行认证,authorization:,就是要求在每个请求报文中提交认证的首部行,如果客户端没有提交,authorization,:,首部行,服务器将拒绝访问,只是在响应报文首部中发送,WWW authenticate:,client,server,普通,http,请求报文,401:,认证要求,WWW authenticate:,普通,http,请求报文,+,Authorization: ,普通,http,响应报文,普通,http,请求报文,+ Authorization: ,普通,http,响应报文,time,第2讲:应用层20用户-服务器的交互: 认证(authent,第2讲,:,应用层,21,Cookies:,保存 “状态”,服务器产生一个,# ,服务器认识这个,#,以备不时之需,:,认证,记忆用户的前序访问,先前的选择,服务器在响应报文中发送 “,cookie”,给客户端,Set-cookie: 1678453,客户端可以在后继的请求中发送“,cookie”,cookie: 1678453,client,server,普通,http,请求报文,普通,http,响应报文,+,Set-cookie: #,普通,http,请求报文,cookie: #,普通,http,响应报文,普通,http,请求报文,cookie: #,普通,http,响应报文,cookie-,特定的,cookie-,特定的,第2讲:应用层21Cookies: 保存 “状态”服务器产生,第2讲,:,应用层,22,Conditional GET:,客户端缓存机制,目的,:,如果客户端缓存了最新的请求对象,则服务器不必重复发送,客户端,:,在,http,请求报文中声明所缓存拷贝的生成日期,If-modified-since: ,服务器,:,如果客户端缓存的拷贝是最新的,则在响应报文中不发请求的对象,:,HTTP/1.0 304 Not Modified,client,server,http,请求报文,If-modified-since: ,http,响应报文,HTTP/1.0,304 Not Modified,对象未经修改,http,请求报文,If-modified-since: ,http,响应报文,HTTP/1.1 200 OK,对象已,经修改,第2讲:应用层22Conditional GET: 客户端缓,第2讲,:,应用层,23,Web,缓存:代理服务器,(proxy server),用户设置浏览器,: Web,访问经由,代理服务器,客户端发送所有的,http,请求到,代理服务器,代理服务器保存了请求的对象,:,代理服务器返回请求的对象,否则代理服务器从原始服务器请求对象,再将其返回给客户端,目的,:,满足客户端的请求而无需烦扰原始服务器,client,Proxy,server,client,http request,http request,http response,http response,http request,http response,origin,server,origin,server,第2讲:应用层23Web 缓存:代理服务器 (proxy s,第2讲,:,应用层,24,为何,Web,缓存,?,前提,:,缓存与客户端比较“接近,“(e.g.,在同一网络中,),响应时间较短,:,缓存与客户端比较“接近,“,减少了往来与远程服务器间的数据流量,因为从学校或本地,ISP,通往外部的链路往往是网络瓶颈,origin,servers,public,Internet,institutional,network,10 Mbps LAN,1.5 Mbps,access link,institutional,cache,第2讲:应用层24为何Web缓存?前提: 缓存与客户端比较“,第2讲,:,应用层,25,ftp:,文件传输协议,传输文件往来与远程主机,客户端,/,服务器模式,客户端,:,启动传输,(,无论与往来远程主机,),服务器,:,远程主机,ftp: RFC 959,ftp,服务器,:,端口,21,file transfer,FTP,server,FTP,user,interface,FTP,client,local file,system,remote file,system,user,at host,第2讲:应用层25ftp: 文件传输协议传输文件往来与远程主,第2讲,:,应用层,26,ftp:,分离的控制,数据连接,ftp,客户端在,ftp,服务器的 端口,21,进行联系,使用,TCP,作为传输协议,打开两个并行的连接,:,控制,:,在客户端和服务器之间交换命令,响应。称为带外控制:,“out of band control”,数据,:,往来于服务器的文件,ftp,维持状态 (,state,),:,当前目录、先前的认证信息等,FTP,client,FTP,server,TCP control connection,port 21,TCP data connection,port 20,第2讲:应用层26ftp: 分离的控制, 数据连接ftp客户,第2讲,:,应用层,27,ftp,命令,响应,样例命令,:,在控制通道上传送的,ASCII,文本,USER,username,(登录),PASS,password,(登录),LIST,(返回当前目录中的文件列表,),RETR filename,(取,(gets),文件),STOR filename,(,存,(puts),文件到远程主机),返回码样例,状态码和短语,(,同,http),331 Username OK, password required,125 data connection already open; transfer starting,425 Cant open data connection,452 Error writing file,第2讲:应用层27ftp 命令, 响应样例命令:返回码样例,第2讲,:,应用层,28,电子邮件,四个重要组件,:,用户代理,邮件服务器,简单邮件传输协议,: smtp,邮局协议:,pop,用户代理,写作,编辑,阅读邮件报文,e.g., Foxmail, OE, elm, Netscape Messenger,外发,接收的报文存储在邮件服务器中,用户邮箱,外发报文队列,mail,server,user,agent,user,agent,user,agent,mail,server,user,agent,user,agent,mail,server,user,agent,SMTP,SMTP,SMTP,第2讲:应用层28电子邮件四个重要组件: 用户邮箱外发报文队,第2讲,:,应用层,29,电子邮件,:,邮件服务器,Mail Servers,邮箱,包含了收到的用户邮件,(,尚未被阅读,),报文,队列包含了外发的 邮件报文,smtp,协议,用在邮件服务器之间发送邮件,客户端,:,将邮件发送到邮件服务器,“,服务器”,:,接收和转发邮件,mail,server,user,agent,user,agent,user,agent,mail,server,user,agent,user,agent,mail,server,user,agent,SMTP,SMTP,SMTP,第2讲:应用层29电子邮件:邮件服务器Mail Server,第2讲,:,应用层,30,电子邮件,: smtp,RFC 821,使用,tcp,可靠的传送邮件报文,端口,25,直接传输,:,发送服务器到接收服务器,传输的三个阶段,握手,(,打招呼,),报文传输,结束,命令,/,响应交互,命令,:,ASCII,文本,响应,:,状态码和短语,邮件报文必须使用,7-bit ASCII,表示,第2讲:应用层30电子邮件: smtp RFC 821使,第2讲,:,应用层,31,smtp,交互样例(在,UNIX,中用,telnet,),S: 220 X1 NT-ESMTP Server ,C: HELO xqcheng,S: 250 hello ,C: MAIL FROM:,S: 250 ok,C: RCPT TO:,S: 250 ok its for ,C: DATA,S: 354 ok, send it; end with .,C: Hi, I am in XUJI now,Where are you?,C: .,S: 250 Message queued,C: QUIT,S: 221 Goodbye,第2讲:应用层31smtp 交互样例(在UNIX中用teln,第2讲,:,应用层,32,自测,smtp,交互,:,$telnet 202.117.35.170 25,见到邮件服务器的,220,响应后,键入,HELO, MAIL FROM, RCPT TO, DATA, QUIT,命令,上述过程可以不使用用户代理,就能直接将电子邮件发送出去(因为目前大部分邮件服务器的交互过程趋于复杂,本试验不一定都能进行)。,第2讲:应用层32自测 smtp 交互:$telnet 20,第2讲,:,应用层,33,smtp: 评述,smtp,使用持续连接,smtp,要求报文,(,首部,&,信体,),全部使用,7-bit ASCII,码,某些代码组合不允许出现在报文中,(e.g.,CRLF.CRLF,).,此类数据必须进行编码,(,通常使用,base-64,或,quoted printable),smtp,服务器用,CRLF.CRLF,表示邮件报文的结束,与,http,的比较,:,http: pull,(拉),email: push,(推),都使用,ASCII,命令,/,响应交互,状态码,http:,每个对象分装在各自的响应报文中,smtp:,多个对象在一个多分部的报文中传送,第2讲:应用层33smtp: 评述smtp 使用持续连接与,第2讲,:,应用层,34,邮件报文格式,smtp:,交换邮件报文的协议,RFC 822:,文本报文格式标准,:,首部诸行, e.g.,To:,From:,Subject:,不同,于,smtp,命令,!,信体,即 “报文”, ASCII characters only,header,body,空行,第2讲:应用层34邮件报文格式smtp: 交换邮件报文的协议,第2讲,:,应用层,35,邮件格式,:,多媒体扩展,MIME: multimedia mail extension, RFC 2045, 2056,在报文首部附加额外的信息声明,MIME,内容类型,From: alicecrepes.fr,To: bobhamburger.edu,Subject: Picture of yummy crepe.,MIME-Version: 1.0,Content-Transfer-Encoding: base64,Content-Type: image/jpeg,base64 encoded data .,.,.base64 encoded data,多媒体类型,子类型,参数,声明,数据编码方法,MIME,版本,编码后的数据,第2讲:应用层35邮件格式: 多媒体扩展MIME: mult,第2讲,:,应用层,36,MIME,类型声明,Content-Type: type/subtype; parameters,Text,子类型样例,:,plain, html,Image,子类型样例,:,jpeg, gif,Audio,子类型样例,:,basic,(8-bit mu-law encoded),32kadpcm,(32 kbps coding),Video,子类型样例,:,mpeg, quicktime,Application,需使用其他阅读器的数据,子类型样例,:,msword, octet-stream,第2讲:应用层36MIME 类型声明 Content-Ty,第2讲,:,应用层,37,MIME多分部类型,From: alicecrepes.fr,To: bobhamburger.edu,Subject: Picture of yummy crepe.,MIME-Version: 1.0,Content-Type: multipart/mixed; boundary=98766789,-98766789,Content-Transfer-Encoding: quoted-printable,Content-Type: text/plain,Dear Bob,Please find a picture of a crepe.,-98766789,Content-Transfer-Encoding: base64,Content-Type: image/jpeg,base64 encoded data .,.,.base64 encoded data,-98766789-,第2讲:应用层37MIME多分部类型From: alice,第2讲,:,应用层,38,邮件访问协议,SMTP:,发送,/,存储 到接收方的服务器,邮件访问协议,:,从服务器中取信,POP: Post Office Protocol RFC 1939,认证,(agent server),和下载,IMAP: Internet Mail Access Protocol RFC 1730,更多功能,(,更为复杂,),在服务器中操作存储在那里的报文,HTTP: Hotmail , Yahoo! Mail, ,etc.,user,agent,senders mail,server,user,agent,SMTP,SMTP,POP3 or,IMAP,receivers mail,server,第2讲:应用层38邮件访问协议SMTP: 发送/存储 到接收,第2讲,:,应用层,39,POP3,协议,认证阶段,客户端命令,:,user:,用户名,pass:,口令,服务器响应,+OK,-ERR,交互阶段,客户端,:,list:,列出报文号码,retr:,用报文号码取信,dele:,用报文号码删信,quit,C: list,S: 1 498,S: 2 912,S: .,C: retr 1,S: ,S: .,C: dele 1,C: retr 2,S: ,S: .,C: dele 2,C: quit,S: +OK,POP3 server signing off,S: +OK POP3 server ready,C: user alice,S: +OK,C: pass hungry,S: +OK,user successfully logged on,第2讲:应用层39POP3 协议认证阶段 C,第2讲,:,应用层,40,自测,pop3,交互,:,$telnet 202.117.35.70 110,见到,+OK POP3 server ready,响应后,键入,user, pass, list, retr, quit,命令,上述过程可以不使用用户代理,就能察看邮箱中的信件。,第2讲:应用层40自测 pop3交互:$telnet 202,第2讲,:,应用层,41,DNS:,域名系统,自然人,:,诸多定义,:,身份证,姓名,护照,#,因特网主机,路由器,:,IP,地址,(32 bit) ,用于数据报寻址,“,域名”, e.g., ,帮助记忆,Q:,IP,地址和域名之间如何映射,(,转换,) ?,Domain Name System:,分布式数据库:由许多域名服务器按层次构成,应用层协议:,主机、路由器、域名服务器互相通信进行域名解析,(,地址,/,域名翻译,),注意,:,因特网之核心功能,应用层之协议,网络“边缘”上之复杂实体,第2讲:应用层41DNS: 域名系统自然人: 诸多定义:Do,第2讲,:,应用层,42,DNS name servers,没有服务器能够保存所有,Name-to-IP,地址的映射,本地域名服务器,:,每个,ISP,企业可拥有,本地,(,默认,),域名服务器,主机的,DNS,查询首先发往本地域名服务器,授权域名服务器,:,每台主机必须在授权服务器上注册登记,可完成域名,/,地址的转换,为什么不搞集中的,DNS?,单点失败的问题,数据的流通量,远程集中式的数据库,维护问题,难以与时俱进,跟不上发展,!,第2讲:应用层42DNS name servers没有服务器,第2讲,:,应用层,43,DNS:,根域名服务器,当本地域名服务器不能解析时,就向根域名服务器查询,根域名服务器,:,如果域名映射未知,则向授权域名服务器查询,取得映射,将映射返回,本地域名服务器,b USC-ISI Marina del Rey, CA,l ICANN Marina del Rey, CA,e NASA Mt View, CA,f Internet Software C. Palo,Alto, CA,i NORDUnet Stockholm,k RIPE London,m WIDE Tokyo,a NSI Herndon, VA,c PSInet Herndon, VA,d U Maryland College Park, MD,g DISA Vienna, VA,h ARL Aberdeen, MD,j NSI (TBD) Herndon, VA,遍布世界各地的,13,个根域名服务器,第2讲:应用层43DNS: 根域名服务器当本地域名服务器不能,第2讲,:,应用层,44,简单,DNS,举例,主机,ctec,要求,gaia.cs.umass.edu,的,IP,地址,1.,联系本地域名服务器,202.117.0.20,2.,如有必要,202.117.0.20,会联系根域名服务器,3.,如有必要根域名服务器会联系授权域名服务器,dns.umass.edu,requesting host,gaia.cs.umass.edu,root name server,authorititive name server,dns.umass.edu,local name server,202.117.0.20,1,2,3,4,5,6,第2讲:应用层44简单 DNS 举例主机 ctec.xjtu,第2讲,:,应用层,45,DNS,举例,根域名服务器,:,可能不知道授权域名服务器的地址,可能知道,中介域名服务器,:,由它负责联系授权域名服务器,requesting host,gaia.cs.umass.edu,root name server,local name server,202.117.0.20,1,2,3,4,5,6,authoritative name server,dns.cs.umass.edu,intermediate name server,dns.umass.edu,7,8,第2讲:应用层45DNS 举例根域名服务器:requesti,第2讲,:,应用层,46,DNS:,迭代查询,递归查询,:,对根域名服务器造成工作负担,如何减负,?,迭代查询,:,被查询的服务器直接把可查询的服务器地址报回,“,不懂这个域名,但可以从这个服务器查到”,requesting host,surf.eurecom.fr,gaia.cs.umass.edu,root name server,local name server,dns.eurecom.fr,1,2,3,4,5,6,authoritative name server,dns.cs.umass.edu,intermediate name server,dns.umass.edu,7,8,iterated query,第2讲:应用层46DNS: 迭代查询递归查询:request,第2讲,:,应用层,47,DNS: 缓存和更新纪录,一旦,(,任何,),域名服务器得知了某个映射,就将其,缓存,在一定的时间间隔后缓存的条目将会过期,(,自动消除,),更新,/,通知 机制由,IETF,负责设计,RFC 2136,http:/www.ietf.org/html.charters/dnsind-charter.html,第2讲:应用层47DNS: 缓存和更新纪录一旦 (任何) 域,第2讲,:,应用层,48,DNS,纪录,DNS:,存储资源纪录,(RR),的分布式数据库,Type=NS,name,=,域,(e.g. ),value,=,该域授权域名服务器的,IP,地址,RR,格式:,(,name, value, type,ttl),Type=A,name,=,主机名,value,= IP,地址,Type=CNAME,Name,=,别名,is really,value,=,真名,Type=MX,value,=,与,name,相关的邮件服务器域名,第2讲:应用层48DNS 纪录DNS: 存储资源纪录 (RR,第2讲,:,应用层,49,DNS,协议,报文,DNS,协议,:,查询,和,应答,报文,二者格式相同,报文首部,identification:,16 bit #,用于查询,应答报文使用同样的,#,flags:,查询 或 应答,希望递归,可以递归,授权应答,第2讲:应用层49DNS 协议, 报文DNS 协议 : 查询,第2讲,:,应用层,50,DNS,协议,报文,Name, type fields,查询报文,RRs,响应,来自授权服务器的纪录,其他“帮助”信息,第2讲:应用层50DNS 协议, 报文Name, type,第2讲,:,应用层,51,本讲小结,应用服务的要求,:,可靠性,带宽,延迟,客户端,-,服务器范式,Internet,传输服务模型,面向连接的,可靠的,: TCP,不可靠的,数据报,: UDP,Our study of network apps now complete!,特定协议,:,http,ftp,smtp, pop3,dns,第2讲:应用层51本讲小结应用服务的要求:Our study,第2讲,:,应用层,52,本讲小结,典型的请求,/,应答报文交换,:,客户请求信息或服务,服务器用数据,状态码进行响应,报文格式,:,首部,:,说明数据的信息,数据,:,进行通信的信息,Most importantly:,learned about,protocols,控制,vs.,数据报文,in-based, out-of-band,集中式,vs.,非集中式,无状态,vs.,有状态,可靠的,vs.,不可靠的报文传输,“,网络边缘上的复杂实体”,安全性,:,认证,第2讲:应用层52本讲小结典型的请求/应答报文交换:Most,53,第3讲 传输层协议及应用,本讲目的,:,理解传输层服务的原理,:,复用,/,分用,可靠数据传输,流量控制,拥塞控制,Internet,传输层的实现和实例,教科书参考,第3章,本讲概述,:,传输层的服务,复用,/,分用,无连接的传输,: UDP,传输控制协议:,TCP,53第3讲 传输层协议及应用本讲目的: 本讲概述:,54,传输层与网络层的关系,因特网中的传输层充当,“,收发室,”,的角色,因特网中的网络层充当,“,邮递业务,”,的角色,两个层次之间的任务可以互换,但是在实现成本上可能存在巨大差别,54传输层与网络层的关系因特网中的传输层充当“收发室”的角色,55,传输服务和协议,提供运行在不同主机中,进程间,的,逻辑通信,传输协议仅运行在端系统中,传输,vs.,网络层服务,:,网络层,:,在端系统间进行通信,传输层,:,在进程间进行通信,依赖并加强了网络层的服务,application,transport,network,data link,physical,application,transport,network,data link,physical,network,data link,physical,network,data link,physical,network,data link,physical,network,data link,physical,network,data link,physical,logical end-end transport,55传输服务和协议提供运行在不同主机中进程间的逻辑通信 ap,56,传输层协议,Internet,传输服务,:,可靠,按序点对点递交,(TCP),拥塞控制,流量控制,连接建立,不可靠的,(,“,尽力而为,”,),无序的点对点或广播递交,: UDP,不能提供的服务,:,实时性,带宽承诺,可靠的广播通信,application,transport,network,data link,physical,application,transport,network,data link,physical,network,data link,physical,network,data link,physical,network,data link,physical,network,data link,physical,network,data link,physical,logical end-end transport,56传输层协议Internet 传输服务:applicati,57,application,transport,network,M,P2,application,transport,network,应用层对传输协议的复用,/,分用,segment,(段),-,传输层实体间交换数据的单位,TPDU:,传输层数据单元,receiver,H,t,H,n,分用,:,将接收到的段传递给正确的应用层进程,segment,segment,M,application,transport,network,P1,M,M,M,P3,P4,segment,header,application-layer,data,57applicationMP2application应用层,58,应用层对传输协议的复用,/,分用,复用,/,分用,:,基于发送方,接收方的端口号, IP,地址,源,目的端口,#s,存在于每个段中,用于特定应用的常用端口号(,well-known port number,):01023,从多个应用进程获取数据,用首部,(,便于随后的分用,),封装数据,源端口,#,宿端口,#,32 bits,应用层数据,(,报文,),其他首部字段,TCP/UDP,段格式,复用,:,58应用层对传输协议的复用/分用复用/分用:从多个应用进程获,59,复用,/,分用,:,举例,主机,A,服务器,B,source port: x,dest. port: 23,source port:23,dest. port: x,端口的使用,:,简单的,telnet,应用,Web,客户端,主机,A,Web,服务器,B,Web,客户端,主机,C,Source IP: C,Dest IP: B,source port: x,dest. port: 80,Source IP: C,Dest IP: B,source port: y,dest. port: 80,端口的使用,: Web,服务器,Source IP: A,Dest IP: B,source port: x,dest. port: 80,59复用/分用: 举例主机 A服务器 Bsource por,60,UDP:,用户数据报协议,RFC 768,“,最简约的,”,Internet,传输协议,“,尽力而为的,”,服务, UDP,数据段可以,:,丢失,应用数据不按序到达,无连接,:,在,UDP,收发双方之间,无需握手信号,每个,UDP,数据段的操作都互相独立,为什么需要,UDP?,无需建立连接,(,会增加延迟,),简单,:,在收发双方之间没有连接状态,段首较短,无拥塞控制,: UDP,可按需要随时发送,60UDP: 用户数据报协议 RFC 768“最简约的”,61,UDP,: (,续),经常为流媒体应用使用,允许数据丢失,对传输速率敏感,其他,UDP,用途,:,DNS,SNMP,若需要通过,UDP,进行可靠传输,:,在应用层增加可靠性措施,在应用程序中,-,专门的出错恢复机制,!,源端口,#,宿端口,#,32 bits,应用层数据,(,报文,),UDP,数据报格式,length,checksum,长度, UDP,段的字节数,包括首部,61UDP: (续) 经常为流媒体应用使用源端口 #宿端口,62,UDP 校验和(checksum),发送方,:,将段的内容看作一串,16,位整数,checksum:,作段内容的加法,(,补码和,),发送方将补码和放入,UDP checksum,字段,接收方,:,对接收到的段内容进行补码和计算,检查计算结果是否与收到的校验和相等,:,NO,查出错误,YES,没查出错误,.,但是仍有可能存在错误,?,目标,:,检测传输段中的,“,错误,”,(e.g.,位错,),62UDP 校验和(checksum)发送方:接收方:目标:,63,TCP,概述,RFCs: 793, 1122, 1323, 2018, 2581,全双工数据传输,:,在同一连接上双向传输,MSS: maximum segment size,(最大段字节数-1500,536,512),面向连接,:,握手过程,(,交换控制信息,),在交换数据前初始化收发双方的状态,“,三次握手,”,流量控制,:,发送方的发送速度不得超过接收方的处理速度,点对点,:,一个发送方, 一个接收方,可靠,按序的字节流,:,无,“,报文边界,”,,无结构但有顺序,流水式控制,:,TCP,的拥塞和流量控制,设置窗口大小,发送,&,接收缓存,63TCP概述 RFCs: 793, 1122, 1323,64,TCP,段格式,(p80),source port #,dest port #,32 bits,应用数据,(,可变长度,),sequence number,acknowledgement number,rcvr window size,ptr urgent data,checksum,F,S,R,P,A,U,head,len,not,used,Options (,可变长度,-MSS),URG: urgent data,(一般不用),ACK: ACK #,valid,PSH: push data now,(,一般不用,),RST, SYN, FIN:,connection estab,(setup, teardown,commands),# bytes,接收方愿意接受的,按发送数据的字节计算,(,不是按段数,!),Internet,checksum,(as in UDP),64TCP 段格式(p80)source port #des,65,TCP seq. #,s,和,ACKs,Seq. #,s:,该数据段第一个字节在(整个报文)字节流中,“,编号,”,ACKs:,seq #,为预期从对方发来的,“,下一个,”,字节的编号,积累的,ACK,Q:,接收方如何接受失序的数据段,A: TCP,没有定义, -,由程序设计者决定,Host A,Host B,Seq=42, ACK=79, data = C,Seq=79, ACK=43, data = C,Seq=43, ACK=80,User,types,C,host ACKs,receipt,of echoed,C,host ACKs,receipt of,C, echoes,back C,time,简单的,telnet,场景,65TCP seq. #s 和 ACKsSeq. #s:,66,TCP:,可靠数据传输,简化的发送方,假设,wait,for,event,wait,for,event,event:,data received,from application above,event:,timer timeout for,segment with seq # y,event:,ACK received,with ACK # y,create, send segment,retransmit segment,ACK processing,单向数据传输,无流量,拥塞控制,66TCP: 可靠数据传输简化的发送方, 假设
展开阅读全文
相关资源
正为您匹配相似的精品文档
相关搜索

最新文档


当前位置:首页 > 办公文档 > 教学培训


copyright@ 2023-2025  zhuangpeitu.com 装配图网版权所有   联系电话:18123376007

备案号:ICP2024067431-1 川公网安备51140202000466号


本站为文档C2C交易模式,即用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。装配图网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知装配图网,我们立即给予删除!