欢迎来到三一办公! | 帮助中心 三一办公31ppt.com(应用文档模板下载平台)
三一办公
全部分类
  • 办公文档>
  • PPT模板>
  • 建筑/施工/环境>
  • 毕业设计>
  • 工程图纸>
  • 教育教学>
  • 素材源码>
  • 生活休闲>
  • 临时分类>
  • ImageVerifierCode 换一换
    首页 三一办公 > 资源分类 > PPTX文档下载  

    计算机网络-Chapter_9_V7.0-课件.pptx

    • 资源ID:3917430       资源大小:1.25MB        全文页数:77页
    • 资源格式: PPTX        下载积分:16金币
    快捷下载 游客一键下载
    会员登录下载
    三方登录下载: 微信开放平台登录 QQ登录  
    下载资源需要16金币
    邮箱/手机:
    温馨提示:
    用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)
    支付方式: 支付宝    微信支付   
    验证码:   换一换

    加入VIP免费专享
     
    账号:
    密码:
    验证码:   换一换
      忘记密码?
        
    友情提示
    2、PDF文件下载后,可能会被浏览器默认打开,此种情况可以点击浏览器菜单,保存网页到桌面,就可以正常下载了。
    3、本站不支持迅雷下载,请使用电脑自带的IE浏览器,或者360浏览器、谷歌浏览器下载即可。
    4、本站资源下载后的文档和图纸-无水印,预览文档经过压缩,下载后原文更清晰。
    5、试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。

    计算机网络-Chapter_9_V7.0-课件.pptx

    Computer Networking:A Top Down Approach,A note on the use of these Powerpoint slides:Were making these slides freely available to all(faculty,students,readers).Theyre in PowerPoint form so you see the animations;and can add,modify,and delete slides(including this one)and slide content to suit your needs.They obviously represent a lot of work on our part.In return for use,we only ask the following:,If you use these slides(e.g.,in a class)that you mention their source(after all,wed like people to use our book!)If you post any slides on a www site,that you note that they are adapted from(or perhaps identical to)our slides,and note our copyright of this material.Thanks and enjoy!JFK/KWR All material copyright 1996-2016 J.F Kurose and K.W.Ross,All Rights Reserved,7th edition Jim Kurose,Keith RossPearson/Addison WesleyApril 2016,Chapter 9Multimedia Networking,9-1,Multimedia Networking,Multimedia networking:outline,9.1 multimedia networking applications9.2 streaming stored video9.3 voice-over-IP9.4 protocols for real-time conversational applications9.5 network support for multimedia,9-2,Multimedia Networking,Multimedia:audio,analog audio signal sampled at constant ratetelephone:8,000 samples/secCD music:44,100 samples/seceach sample quantized,i.e.,roundede.g.,28=256 possible quantized valueseach quantized value represented by bits,e.g.,8 bits for 256 values,time,audio signal amplitude,analogsignal,quantized value ofanalog value,quantization error,sampling rate(N sample/sec),9-3,Multimedia Networking,Multimedia:audio,example:8,000 samples/sec,256 quantized values:64,000 bpsreceiver converts bits back to analog signal:some quality reductionexample ratesCD:1.411 MbpsMP3:96,128,160 kbpsInternet telephony:5.3 kbps and up,9-4,Multimedia Networking,video:sequence of images displayed at constant ratee.g.,24 images/secdigital image:array of pixelseach pixel represented by bitscoding:use redundancy within and between images to decrease#bits used to encode imagespatial(within image)temporal(from one image to next),Multimedia:video,frame i,frame i+1,temporal coding example:instead of sending complete frame at i+1,send only differences from frame i,9-5,Multimedia Networking,Multimedia:video,frame i,frame i+1,temporal coding example:instead of sending complete frame at i+1,send only differences from frame i,CBR:(constant bit rate):video encoding rate fixedVBR:(variable bit rate):video encoding rate changes as amount of spatial,temporal coding changes examples:MPEG 1(CD-ROM)1.5 MbpsMPEG2(DVD)3-6 MbpsMPEG4(often used in Internet,1 Mbps),9-6,Multimedia Networking,Multimedia networking:3 application types,streaming,stored audio,videostreaming:can begin playout before downloading entire filestored(at server):can transmit faster than audio/video will be rendered(implies storing/buffering at client)e.g.,YouTube,Netflix,Huluconversational voice/video over IP interactive nature of human-to-human conversation limits delay tolerancee.g.,Skypestreaming live audio,videoe.g.,live sporting event(futbol),9-7,Multimedia Networking,Multimedia networking:outline,9.1 multimedia networking applications9.2 streaming stored video9.3 voice-over-IP9.4 protocols for real-time conversational applications9.5 network support for multimedia,9-8,Multimedia Networking,Streaming stored video:,Cumulative data,time,9-9,Multimedia Networking,Streaming stored video:challenges,continuous playout constraint:once client playout begins,playback must match original timing but network delays are variable(jitter),so will need client-side buffer to match playout requirementsother challenges:client interactivity:pause,fast-forward,rewind,jump through videovideo packets may be lost,retransmitted,9-10,Multimedia Networking,constant bit rate videotransmission,Cumulative data,time,client-side buffering and playout delay:compensate for network-added delay,delay jitter,Streaming stored video:revisited,9-11,Multimedia Networking,Client-side buffering,playout,variable fill rate,x(t),client application buffer,size B,playout rate,e.g.,CBR r,buffer fill level,Q(t),video server,client,9-12,Multimedia Networking,Client-side buffering,playout,variable fill rate,x(t),client application buffer,size B,playout rate,e.g.,CBR r,buffer fill level,Q(t),video server,client,1.Initial fill of buffer until playout begins at tp,2.playout begins at tp,3.buffer fill level varies over time as fill rate x(t)varies and playout rate r is constant,9-13,Multimedia Networking,playout buffering:average fill rate(x),playout rate(r):x r:buffer will not empty,provided initial playout delay is large enough to absorb variability in x(t)initial playout delay tradeoff:buffer starvation less likely with larger delay,but larger delay until user begins watching,variable fill rate,x(t),client application buffer,size B,playout rate,e.g.,CBR r,buffer fill level,Q(t),video server,Client-side buffering,playout,9-14,Multimedia Networking,Streaming multimedia:UDP,server sends at rate appropriate for client often:send rate=encoding rate=constant ratetransmission rate can be oblivious to congestion levelsshort playout delay(2-5 seconds)to remove network jittererror recovery:application-level,time permittingRTP RFC 2326:multimedia payload typesUDP may not go through firewalls,9-15,Multimedia Networking,Streaming multimedia:HTTP,multimedia file retrieved via HTTP GETsend at maximum possible rate under TCPfill rate fluctuates due to TCP congestion control,retransmissions(in-order delivery)larger playout delay:smooth TCP delivery rateHTTP/TCP passes more easily through firewalls,variable rate,x(t),TCP send buffer,videofile,TCP receive buffer,application playout buffer,server,client,9-16,Multimedia Networking,Multimedia networking:outline,9.1 multimedia networking applications9.2 streaming stored video9.3 voice-over-IP9.4 protocols for real-time conversational applications9.5 network support for multimedia,9-17,Multimedia Networking,Voice-over-IP(VoIP),VoIP end-end-delay requirement:needed to maintain“conversational”aspecthigher delays noticeable,impair interactivity 400 msec badincludes application-level(packetization,playout),network delayssession initialization:how does callee advertise IP address,port number,encoding algorithms?value-added services:call forwarding,screening,recordingemergency services:911,9-18,Multimedia Networking,VoIP characteristics,speakers audio:alternating talk spurts,silent periods.64 kbps during talk spurtpkts generated only during talk spurts20 msec chunks at 8 Kbytes/sec:160 bytes of dataapplication-layer header added to each chunkchunk+header encapsulated into UDP or TCP segmentapplication sends segment into socket every 20 msec during talkspurt,9-19,Multimedia Networking,VoIP:packet loss,delay,network loss:IP datagram lost due to network congestion(router buffer overflow)delay loss:IP datagram arrives too late for playout at receiverdelays:processing,queueing in network;end-system(sender,receiver)delaystypical maximum tolerable delay:400 msloss tolerance:depending on voice encoding,loss concealment,packet loss rates between 1%and 10%can be tolerated,9-20,Multimedia Networking,constant bit ratetransmission,Cumulative data,time,Delay jitter,end-to-end delays of two consecutive packets:difference can be more or less than 20 msec(transmission time difference),9-21,Multimedia Networking,VoIP:fixed playout delay,receiver attempts to playout each chunk exactly q msecs after chunk was generated.chunk has time stamp t:play out chunk at t+q chunk arrives after t+q:data arrives too late for playout:data“lost”tradeoff in choosing q:large q:less packet losssmall q:better interactive experience,9-22,Multimedia Networking,sender generates packets every 20 msec during talk spurt.first packet received at time r first playout schedule:begins at p second playout schedule:begins at p,VoIP:fixed playout delay,9-23,Multimedia Networking,Adaptive playout delay(1),goal:low playout delay,low late loss rateapproach:adaptive playout delay adjustment:estimate network delay,adjust playout delay at beginning of each talk spurtsilent periods compressed and elongatedchunks still played out every 20 msec during talk spurtadaptively estimate packet delay:(EWMA-exponentially weighted moving average,recall TCP RTT estimate):,di=(1-a)di-1+a(ri ti),delay estimate after ith packet,small constant,e.g.0.1,time received-,time sent(timestamp),measured delay of ith packet,9-24,Multimedia Networking,also useful to estimate average deviation of delay,vi:,estimates di,vi calculated for every received packet,but used only at start of talk spurtfor first packet in talk spurt,playout time is:remaining packets in talkspurt are played out periodically,vi=(1-b)vi-1+b|ri ti di|,playout-timei=ti+di+Kvi,Adaptive playout delay(2),9-25,Multimedia Networking,Q:How does receiver determine whether packet is first in a talkspurt?if no loss,receiver looks at successive timestampsdifference of successive stamps 20 msec-talk spurt begins.with loss possible,receiver must look at both time stamps and sequence numbersdifference of successive stamps 20 msec and sequence numbers without gaps-talk spurt begins.,Adaptive playout delay(3),9-26,Multimedia Networking,VoiP:recovery from packet loss(1),Challenge:recover from packet loss given small tolerable delay between original transmission and playouteach ACK/NAK takes one RTTalternative:Forward Error Correction(FEC)send enough bits to allow recovery without retransmission(recall two-dimensional parity in Ch.5)simple FECfor every group of n chunks,create redundant chunk by exclusive OR-ing n original chunkssend n+1 chunks,increasing bandwidth by factor 1/ncan reconstruct original n chunks if at most one lost chunk from n+1 chunks,with playout delay,9-27,Multimedia Networking,another FEC scheme:“piggyback lower quality stream”send lower resolutionaudio stream as redundant informatione.g.,nominal stream PCM at 64 kbpsand redundant streamGSM at 13 kbps,non-consecutive loss:receiver can conceal loss generalization:can also append(n-1)st and(n-2)nd low-bit ratechunk,VoiP:recovery from packet loss(2),9-28,Multimedia Networking,interleaving to conceal loss:audio chunks divided into smaller units,e.g.four 5 msec units per 20 msec audio chunkpacket contains small units from different chunks,if packet lost,still have most of every original chunkno redundancy overhead,but increases playout delay,VoiP:recovery from packet loss(3),9-29,Multimedia Networking,Voice-over-IP:Skype,proprietary application-layer protocol(inferred via reverse engineering)encrypted msgsP2P components:,Skype clients(SC),clients:Skype peers connect directly to each other for VoIP call,super nodes(SN):Skype peers with special functions,overlay network:among SNs to locate SCs,login server,9-30,Multimedia Networking,P2P voice-over-IP:Skype,Skype client operation:,1.joins Skype network by contacting SN(IP address cached)using TCP,2.logs-in(username,password)to centralized Skype login server,3.obtains IP address for callee from SN,SN overlayor client buddy list,4.initiate call directly to callee,9-31,Multimedia Networking,problem:both Alice,Bob are behind“NATs”NAT prevents outside peer from initiating connection to insider peerinside peer can initiate connection to outside,relay solution:Alice,Bob maintain open connection to their SNsAlice signals her SN to connect to BobAlices SN connects to Bobs SNBobs SN connects to Bob over open connection Bob initially initiated to his SN,Skype:peers as relays,9-32,Multimedia Networking,Multimedia networking:outline,9.1 multimedia networking applications9.2 streaming stored video9.3 voice-over-IP9.4 protocols for real-time conversational applications:RTP,SIP9.5 network support for multimedia,9-33,Multimedia Networking,Real-Time Protocol(RTP),RTP specifies packet structure for packets carrying audio,video dataRFC 3550RTP packet provides payload type identificationpacket sequence numberingtime stamping,RTP runs in end systemsRTP packets encapsulated in UDP segmentsinteroperability:if two VoIP applications run RTP,they may be able to work together,9-34,Multimedia Networking,RTP runs on top of UDP,RTP libraries provide transport-layer interface that extends UDP:port numbers,IP addresses payload type identification packet sequence numbering time-stamping,9-35,Multimedia Networking,RTP example,example:sending 64 kbps PCM-encoded voice over RTPapplication collects encoded data in chunks,e.g.,every 20 msec=160 bytes in a chunkaudio chunk+RTP header form RTP packet,which is encapsulated in UDP segment,RTP header indicates type of audio encoding in each packetsender can change encoding during conference RTP header also contains sequence numbers,timestamps,9-36,Multimedia Networking,RTP and QoS,RTP does not provide any mechanism to ensure timely data delivery or other QoS guaranteesRTP encapsulation only seen at end systems(not by intermediate routers)routers provide best-effort service,making no special effort to ensure that RTP packets arrive at destination in timely matter,9-37,Multimedia Networking,RTP header,payload type(7 bits):indicates type of encoding currently being used.If sender changes encoding during call,sender informs receiver via payload type fieldPayload type 0:PCM mu-law,64 kbpsPayload type 3:GSM,13 kbpsPayload type 7:LPC,2.4 kbpsPayload type 26:Motion JPEGPayload type 31:H.261Payload type 33:MPEG2 videosequence#(16 bits):increment by one for each RTP packet sentdetect packet loss,restore packet sequence,9-38,Multimedia Networking,timestamp field(32 bits long):sampling instant of first byte in this RTP data packetfor audio,timestamp clock increments by one for each sampling period(e.g.,each 125 usecs for 8 KHz sampling clock)if application generates chunks of 160 encoded samples,timestamp increases by 160 for each RTP packet when source is active.Timestamp clock continues to increase at constant rate when source is inactive.SSRC field(32 bits long):identifies source of RTP stream.Each stream in RTP session has distinct SSRC,RTP header,9-39,Multimedia Networking,RTSP/RTP programming assignment,build a server that encapsulates stored video frames into RTP packetsgrab video frame,add RTP headers,create UDP segments,send segments to UDP socketinclude seq numbers and time stampsclient RTP provided for youalso write client side of RTSPissue play/pause commandsserver RTSP provided for you,9-40,Multimedia Networking,Real-Time Control Protocol(RTCP),works in conjunction with RTPeach participant in RTP session periodically sends RTCP control packets to all other participants,each RTCP packet contains sender and/or receiver reportsreport statistics useful to application:#packets sent,#packets lost,interarrival jitterfeedback used to control performancesender may modify its transmissions based on feedback,9-41,Multimedia Networking,RTCP:multiple multicast senders,each RTP session:typically a single multicast address;all RTP/RTCP packets belonging to session use multicast addressRTP,RTCP packets distinguished from each other via distinc

    注意事项

    本文(计算机网络-Chapter_9_V7.0-课件.pptx)为本站会员(牧羊曲112)主动上传,三一办公仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知三一办公(点击联系客服),我们立即给予删除!

    温馨提示:如果因为网速或其他原因下载失败请重新下载,重复下载不扣分。




    备案号:宁ICP备20000045号-2

    经营许可证:宁B2-20210002

    宁公网安备 64010402000987号

    三一办公
    收起
    展开