《多媒體通信》

西安電子科技大學通信工程學院第四章通信協議多媒體應用對網絡的需求TCP/IP第四章通信協議RTP/RTCPRSVP多媒體應用對網絡的需求TCP/IP一、多媒體應用對網絡的需求RTP/RTCPRSVP音頻流和視頻流通信模式對話及其多方通信存儲式實時流交互式一對一會議單播組播廣播流媒體（StreamingMedia）應用主要是音頻流和視頻流的應用特點發送端（服務器）不斷地發送媒體數據，數據在網絡上傳送接收端持續接收，同時播放出來從發送端到接收端，媒體信息通過網絡有向流動，稱之為流媒體，以區別于下載后播放的模式媒體服務器緩沖區計算機流媒體語音通話及多方通信單向時延要求小于100ms，超過350ms的時延，對話過程就難以繼續特點數據雙向流動持續接收，同時播放出來對實時性要求更高緩沖區計算機雙向語音通話緩沖區計算機通信模式單播、組播、廣播Client-Server模式、P2P模式廣播（broadcast）組播（multicast）單播（unicast）P2P模式客戶端進程服務器進程請求響應Client-Server模式多媒體應用的特點恒定比特率vs可變比特率下載傳輸vs流式傳輸對稱信道vs非對稱信道實時vs非實時多媒體應用的需求綜合業務要求多種傳輸模式要求帶寬要求時延和抖動要求實時性要求可靠性（差錯率）要求協議體系結構應用/業務(文件/話音/視頻/會議/郵件/遠程共享）媒體流編解碼協議H.264/iLBC/G.729RTP信令/協議DNSRTCPSIP/XMPPHTTPUDPTCPIP多媒體應用對網絡的需求TCP/IP二、TCP/IPRTP/RTCPRSVP2.1網絡體系結構協議、層、接口協議（Protocol）：為網絡數據交換而制定的規則、約定與標準網絡協議的三要素：語義、語法與時序語義：用于解釋比特流的每一部分的意義語法：語法是用戶數據與控制信息的結構與格式，以及數據出現的順序的意義時序：事件實現順序的詳細說明層（Layer）層次是人們對復雜問題處理的基本方法；將總體要實現的很多功能分配在不同層次中對每個層次要完成的服務及服務要求都有明確規定不同的系統分成相同的層次最低層之間存在著”物理”通信對等層次之間存在著“虛擬”通信對不同系統的對等層之間的通信有明確的通信規定高層使用低層提供的服務時，并不需要知道低層服務的具體實現方法接口（Interface）接口是同一系統內相鄰層之間交換信息的連接點同一個結點的相鄰層之間存在著明確規定的接口，低層向高層通過接口提供服務只要接口條件不變、低層功能不變，低層功能的具體實現方法與技術的變化不會影響整個系統的工作網絡體系結構（NetworkArchitecture）一個功能完備的計算機網絡需要制定一整套復雜的協議集網絡層次結構模型與各層協議的集合稱為網絡體系結構網絡體系結構對計算機網絡應該實現的功能進行了精確的定義有兩種經典的體系結構模型：OSI模型和TCP/IP模型OSI7層參考模型12PhysicalDataLinkNetworkTransportSessionPresentationApplication34567TCP/IP參考模型12PhysicalDataLinkNetworkTransportSessionPresentationApplication34567NetworkInterfaceInternetTransportApplicationOSIModelTCP/IPModel層描述協議Application定義了TCP/IP應用協議以及主機程序與要使用網絡的傳輸層服務之間的接口HTTP,

Telnet,FTP,DNS,SMTPTransport提供主機之間的通訊會話管理。定義了傳輸數據時的服務級別和連接狀態TCP,UDPInternet將數據裝入IP數據報，包括用于在主機間以及經過網絡轉發數據報時所用的源和目標的地址信息。實現IP數據報的路由IP,ICMP,ARP,RARPNetworkInterface詳細指定如何通過網絡實際發送數據，包括直接與網絡媒體（如同軸電纜、光纖或雙絞銅線）接觸的硬件設備如何將比特流轉換成電信號Ethernet,TokenRing,FDDIUnderlyingLANorWANtechnologyNetworkInterface

LayerNetworkLayerIPICMPIGMPARPRARPTransportLayerTCPSCTPUDPApplicationLayerFTPDNSHTTPSNMPSIP???2.2IP協議InternetProtocol根據IP地址進行路由不保證服務質量IPv4IPv6（本節針對的是IPv4）IP地址(IPv4)長度為32bit，共4,294,967,296點分十進制記法（Dotted-decimalnotation）0111100000100011000101101111100048分為“子網地址”和“主機地址”二級結構Privateaddress10.x.x.x172.16.x.x

~172.31.x.x192.168.x.xIPv4header可選項目的IP地址(32bits)源IP地址(32bits)TTL8bitsHeaderChecksum16bitsProtocol8bitsIdentification16bitsFragmentationOffset13bitsFlag3bitsVER4bitsDS8bitsHLEN4bitsTotalLength16bitsIPHeaderData20~60bytes20~65536bytesIPv4header可選項目的IP地址(32bits)源IP地址(32bits)TTL8bitsHeaderChecksum16bitsProtocol8bitsIdentification16bitsFragmentationOffset13bitsFlag3bitsVER4bitsDS8bitsHLEN4bitsTotalLength16bitsIPHeaderData20~60bytes20~65536bytes版本字段，表示IP協議的版本號。對于IPv4，此值為4IPv4header可選項目的IP地址(32bits)源IP地址(32bits)TTL8bitsHeaderChecksum16bitsProtocol8bitsIdentification16bitsFragmentationOffset13bitsFlag3bitsVER4bitsDS8bitsHLEN4bitsTotalLength16bitsIPHeaderData20~60bytes20~65536bytes以32比特字長為單位的首部長度，即長度=n*4bytes，n取值為5~15，所以首部長度為20~60bytesIPv4header可選項目的IP地址(32bits)源IP地址(32bits)TTL8bitsHeaderChecksum16bitsProtocol8bitsIdentification16bitsFragmentationOffset13bitsFlag3bitsVER4bitsDS8bitsHLEN4bitsTotalLength16bitsIPHeaderData20~60bytes20~65536bytesDifferentiatedServices，規定了本數據報的處理方式IPv4header可選項目的IP地址(32bits)源IP地址(32bits)TTL8bitsHeaderChecksum16bitsProtocol8bitsIdentification16bitsFragmentationOffset13bitsFlag3bitsVER4bitsDS8bitsHLEN4bitsTotalLength16bitsIPHeaderData20~60bytes20~65535bytes總長度，以字節為單位的IP數據報長度，包括首部和數據中的字節數，20~65535之間IPv4header可選項目的IP地址(32bits)源IP地址(32bits)TTL8bitsHeaderChecksum16bitsProtocol8bitsIdentification16bitsFragmentationOffset13bitsFlag3bitsVER4bitsDS8bitsHLEN4bitsTotalLength16bitsIPHeaderData20~60bytes20~65535bytes在分片（Fragment）的情況下，此字段為惟一標識該數據報的整數。其主要目的是為了讓目的主機知道到達的數據報片屬于哪個數據報IPv4header可選項目的IP地址(32bits)源IP地址(32bits)TTL8bitsHeaderChecksum16bitsProtocol8bitsIdentification16bitsFragmentationOffset13bitsFlag3bitsVER4bitsDS8bitsHLEN4bitsTotalLength16bitsIPHeaderData20~60bytes20~65535bytesbit0：保留，必須為0bit1：Don’tFragment(DF)如果此bit置1，則不允許分片bit2：MoreFragment(MF)如果當前數據報片為最后一片，則為0，否則為1IPv4header可選項目的IP地址(32bits)源IP地址(32bits)TTL8bitsHeaderChecksum16bitsProtocol8bitsIdentification16bitsFragmentationOffset13bitsFlag3bitsVER4bitsDS8bitsHLEN4bitsTotalLength16bitsIPHeaderData20~60bytes20~65535bytes在分片的情況下，表示此分片所攜帶的數據在原始數據報中以8字節為單位的偏移量，從零開始計數。如果未分片，則為0分片（Fragmentation）HeaderMTU（最大傳輸單元）IP數據報Trailer網絡層鏈路層網絡MTUTokenRing(16Mbps)17914TokenRing(4Mbps)4464FDDI4352WLAN7981EthernetV21500EthernetwithLLC/SNAP/PPPoE1492在傳輸過程中，如果IP數據報長度，超過了鏈路層的MTU，則：1）分片2）不分片（如DF=1），丟棄數據報在傳輸過程中，可能會被多次分片在最后的接收端進行重裝IPv4header可選項目的IP地址(32bits)源IP地址(32bits)TTL8bitsHeaderChecksum16bitsProtocol8bitsIdentification16bitsFragmentationOffset13bitsFlag3bitsVER4bitsDS8bitsHLEN4bitsTotalLength16bitsIPHeaderData20~60bytes20~65535bytesTimetoLive，為該數據報在互聯網中允許存在的時間，以秒為單位。絕大多數路由器只是簡單地在數據報經過時將該值減1，減為0時丟棄該數據報IPv4header可選項目的IP地址(32bits)源IP地址(32bits)TTL8bitsHeaderChecksum16bitsProtocol8bitsIdentification16bitsFragmentationOffset13bitsFlag3bitsVER4bitsDS8bitsHLEN4bitsTotalLength16bitsIPHeaderData20~60bytes20~65535bytes指出此數據報攜帶的傳輸層數據使用何種協議，常見的有：ICMP(1),IGMP(2),TCP(6),UDP(17),SCTP(132)IPv4header可選項目的IP地址(32bits)源IP地址(32bits)TTL8bitsHeaderChecksum16bitsProtocol8bitsIdentification16bitsFragmentationOffset13bitsFlag3bitsVER4bitsDS8bitsHLEN4bitsTotalLength16bitsIPHeaderData20~60bytes20~65535bytes此字段只檢驗數據報的首部，不包括數據部分。校驗時也不包括checksum自己UnderlyingLANorWANtechnologyNetworkInterface

LayerNetworkLayerIPICMPIGMPARPRARPTransportLayerTCPSCTPUDPApplicationLayerFTPDNSHTTPSNMPSIP???2.3UDP協議UDP(UserDatagramProtocol)簡單、高效無連接服務，不保證可靠傳輸相對于IP協議來說，唯一增加的功能是提供對協議端口的管理在多媒體系統中大量應用沒有確認、重傳等機制可靠傳輸問題，由應用層的協議來處理PortandSocketNetworkInterfaceNetworkTransportApplicationP1NetworkInterfaceNetworkTransportApplicationP2P3NetworkInterfaceNetworkTransportApplicationP4ProcessSocketSocket=IPAddress+Port端口UDP/TCP協議7TCP/UDPEchoProtocol20TCP/UDPFTPdatatransfer21TCPFTPcontrol(command)22TCP/UDPSecureShell23TCP/UDPTelnet80TCPHTTP161UDPSNMPWellKnownPort/assignments/service-names-port-numbers/service-names-port-numbers.txtUDPheaderTotalLength16bitsChecksum16bitsSourcePortNumber16bitsDestinationPortNumber16bitsUDPHeaderData8bytesDataIPHeaderTotalLength16bitsChecksum16bitsSourcePortNumber16bitsDestinationPortNumber16bitsUDPHeaderData8bytesUDPheaderUDP報文總長度，包括UDP頭2.4TCP協議UnderlyingLANorWANtechnologyNetworkInterface

LayerNetworkLayerIPICMPIGMPARPRARPTransportLayerTCPSCTPUDPApplicationLayerFTPDNSHTTPSNMPSIP???TCP(TransferControlProtocol)面向連接的服務，提供可靠的全雙工數據傳輸非常復雜的協議應用于對數據正確性要求高的場合連接建立、拆除編號、確認差錯控制、重傳流量控制擁塞控制端到端流式傳輸TCP連接某臺主機IP地址是，有一個進程在1234端口上監聽，等待客戶端的連接。請問此進程最多可以建立多少條TCP連接？一條TCP連接，由5個元素唯一確定：Socket

(IP,Port)Socket

(IP,Port)TCPTCPTCP流式傳輸字節流接收進程發送進程發送和接收緩沖區TCP報文段（Segment）TCPHeader可選項及填充Checksum(16bits)Acknowledgment

Number(32bits)SequenceNumber(32bits)SourcePortAddress16bitsDestinationPortAddress16bitsTCPHeaderDataHLEN4bitsURGReserved6bitsACKPSHRSTSYNFINWindowSize16bitsUrgentPointer(16bits)TCP頭分為固定長度部分和可選項部分。固定長度部分：固定為20Bytes可選項部分：長度為0~40BytesTCP頭長度必須是4的整數倍（按字節數算）可選項及填充Checksum(16bits)Acknowledgment

Number(32bits)SequenceNumber(32bits)SourcePortAddress16bitsDestinationPortAddress16bitsTCPHeaderDataHLEN4bitsURGReserved6bitsACKPSHRSTSYNFINWindowSize16bitsUrgentPointer(16bits)發送序號。TCP的序號編號是對每一個字節進行編號，因此在這個字段中給出的數字是本報文段所發送的數據部分的第一個字節的序號可選項及填充Checksum(16bits)Acknowledgment

Number(32bits)SequenceNumber(32bits)SourcePortAddress16bitsDestinationPortAddress16bitsTCPHeaderDataHLEN4bitsURGReserved6bitsACKPSHRSTSYNFINWindowSize16bitsUrgentPointer(16bits)確認序號。指的是期望收到對方下次發送的數據報的第一個字節的序號，也就是期望收到的下一個報文段的首部中的發送序號，同時確認以前收到的報文可選項及填充Checksum(16bits)Acknowledgment

Number(32bits)SequenceNumber(32bits)SourcePortAddress16bitsDestinationPortAddress16bitsTCPHeaderDataHLEN4bitsURGReserved6bitsACKPSHRSTSYNFINWindowSize16bitsUrgentPointer(16bits)TCP頭長度，以4字節為一單位，取值范圍為5~15，即TCP頭長度范圍是20~60字節URGACKPSHRSTSYNFIN標志含義URG后面的UrgentPointer是否有效ACKAcknowledgment是否有效PSH緊迫比特（Requestforpush）RSTReset連接SYN同步比特（Synchronizesequencenumber）FIN終止連接可選項及填充Checksum(16bits)Acknowledgment

Number(32bits)SequenceNumber(32bits)SourcePortAddress16bitsDestinationPortAddress16bitsTCPHeaderDataHLEN4bitsURGReserved6bitsACKPSHRSTSYNFINWindowSize16bitsUrgentPointer(16bits)為發送方接收窗口的大小，單位為字節，2~65535通過Windowscale選項，可以將窗口大小擴大到65535~1GB可選項及填充Checksum(16bits)Acknowledgment

Number(32bits)SequenceNumber(32bits)SourcePortAddress16bitsDestinationPortAddress16bitsTCPHeaderDataHLEN4bitsURGReserved6bitsACKPSHRSTSYNFINWindowSize16bitsUrgentPointer(16bits)校驗和，用來檢驗首部和數據部分以及偽首部之和可選項及填充Checksum(16bits)Acknowledgment

Number(32bits)SequenceNumber(32bits)SourcePortAddress16bitsDestinationPortAddress16bitsTCPHeaderDataHLEN4bitsURGReserved6bitsACKPSHRSTSYNFINWindowSize16bitsUrgentPointer(16bits)當URG=1時有效，UrgentPointer指示了Urgent數據長度（從TCP

Data部分的第一個字節起算）。在現代的TCP實現中，基本不用。可選項和填充可選項及填充單字節多字節Endofoptionlist(EOP)Nooperation(NOP)MaximumSegementSize(MSS)WindowscalefactorTimestampSACKpermittedSACKTCPOption部分最多40字節可以有多個Option，每個Option的結構為：Option-Kind1ByteOption-Length1ByteOption-Data變長Kind0123845Endofoptionlist(單字節)EOP只能用一次，表示可選項結束用于填充，保證可選項總長度是4字節的倍數Kind:000000000Nooperationoption(單字節)NOP可用多次用于對齊每個選項（4字節的整數倍）Kind:100000001Maximumsegmentsize(4字節)在連接建立階段協商，在通信過程中保持不變Kind:200000010Length:400000100MSSvalue2bytesWindowscalefactor(3字節)在連接建立階段協商，在通信過程中保持不變Kind:300000010Length:300000011factorvalue1bytesTimestamp(10字節)Kind:800001000Length:1000001010Data8bytesSACKpermitted(2字節)是否允許選擇重傳Kind:400000100Length:200000010SACKoption(n字節)Kind:500000101LengthDataTCP的編號與確認在TCP報文段首部含有確認序號字段，通過它可以完成TCP報文的確認捎帶確認ACK標志置1對接收到的數據的最高序號進行確認，返回的確認序號是已經收到的數據的最高序號加1由于TCP采用全雙工的通信方式，因此進行通信的每一方都不必專門發送確認報文段，可以在傳送數據的同時進行確認TCP連接建立seq:1000SSYNseq:1001ack:6001rwnd:10000ACKAseq:6000ack:1001rwnd:5000SSYN+ACKAClientServerA：ACK標志S：SYN標志ActiveOpenPassiveOpenSYN報文不允許攜帶任何數據，但是占用一個sequencenumberSYN+ACK報文不允許攜帶任何數據，但是占用一個sequencenumberACK中同時指定了Server端的接收窗口ACK報文如果不攜帶數據，則不占用sequencenumber。在此例中，意味著Client發出的下一個數據包，seq仍然是1001ACK中指定了Client端的接收窗口TCP數據傳輸seq:3000ack:6501AClientServerA：ACK標志P：PSH標志seq:1001ack:6001PDatabytes:1001~2000Aseq:2001ack:6001PDatabytes:2001~3000Aseq:6001ack:3001Databytes:6001~6500APSH和URG標志在接收端，有TCP緩沖區。正常情況下，會等到TCP緩沖區都填滿后才向上層（應用層）交付。PSH=1：控制接收方，接收方在收到PSH標志的TCP報文后，需立即將這個報文（包括在緩沖區中滯留的數據）遞交給上層（應用層）進程URG=1：TCP報文中第一字節到UrgentPointer中所指的字節，這部分數據被稱為“緊急數據”，接收方在收到這些緊急數據后，不進入TCP緩沖區，直接遞交給上層進程，而報文中非“緊急”的數據，仍然需要放入TCP緩沖區的TCP連接拆除（3步拆除）seq:xack:y+1ACKAseq:yack:x+1FFIN+ACKAClientServerA：ACK標志F：FIN標志ActiveClosePassiveCloseFIN報文如果不攜帶任何數據，則占用一個sequencenumberseq:xack:yFFINACK報文如果不攜帶數據，則不占用sequencenumberFIN+ACK報文如果不攜帶任何數據，則占用一個sequencenumberTCP連接半關閉

（4步拆除）seq:xack:z+1ACKAClientServerA：ACK標志F：FIN標志ActiveClosePassiveCloseseq:xack:yFFINseq:y+1ack:x+1ACKAseq:zack:x+1FFINServer可繼續向Client發數據Client可向Server發ACKTCP狀態機狀態含義CLOSEDThereisnoconnectionLISTENPassiveopenreceived;waitingforSYNSYN-SENTSYNsent;waitingforACKSYN-RCVDSYN+ACKsent;waitingforACKESTABLISHEDConnectionestablished;datatransferinprogressFIN-WAIT-1FirstFINsent;waitingforACKFIN-WAIT-2ACKtofirstFINreceived;waitingforsecondFINCLOSE-WAITFirstFINreceived,ACKsent;waitingforapplicationtocloseTIME-WAITSecondFINreceived,ACKsent;waitingfor2MSLtimeoutLAST-ACKSecondFINsent;waitingforACKCLOSINGBothsideshavedecidedtoclosesimultaneously正常情況下的狀態變化圖TCP流量控制機制防止快速的發送數據時超過接收者的能力基于滑動窗口的流控機制以Byte為單位可變窗口大小接收窗口大小：由接收端確定???m-1mm+1???n-1nn+1???ClosingOpening滑動窗口WindowsSize=min(rwnd,cwnd)rwnd：接收窗口cwnd：擁塞窗口rwnd：接收窗口，表明接收方當前的窗口大小，由對方（接收方）決定cwnd：沖突窗口，由己方根據擁塞算法計算得到???m-1mm+1???n-1nn+1???收到ACK后窗口前移滑動窗口已發送并被確認的已發送未確認的可繼續發送不可發送的1100已發送并被確認1012002013003014004015005016006017007018008019009011000可繼續發送發送窗口指針收到確認后窗口前移不可發送(1)窗口大小為40011001012002013003014004015005016006017007018008019009011000發送窗口不可發送(2)發送400B，收到ACK=201,rwnd=400，還可繼續發送200已發送未確認可以繼續發送指針已發送并被確認11001012002013003014004015005016006017007018008019009011000發送窗口不可發送(3)收到ACK=401,rwnd=500可以繼續發送指針糊涂窗口綜合癥（SillyWindowSyndrome）現象當發送端應用進程產生數據很慢、或接收端應用進程處理接收緩沖區數據很慢，或二者兼而有之；就會使應用進程間傳送的報文段很小，特別是有效載荷很小。極端情況下，有效載荷可能只有1個字節；而傳輸開銷有40字節(20字節的IP頭+20字節的TCP頭)這種現象就叫糊涂窗口綜合癥類別發送端：像Telnet應用接收端：TCP緩沖區慢，上層處理慢，導致窗口很小措施發送端：避免在每個數據段中只傳送少量數據（延遲通告、推遲確認）接收端：避免發送小容量的窗口通告TCP的差錯控制（ErrorControl）差錯檢測的三種途徑：檢驗和、確認和超時每一個報文段都包括檢驗和字段，用來檢查報文段是否受損；若報文段受到損傷，就由目的TCP將其丟棄TCP使用確認的方法來證實收到了某些報文段，表明它們已經無損傷地到達了目的TCPTCP不使用否認（NAK,Negativeacknowledge）。若一個報文段在超時截止期之前未被確認，則被認為是受到損傷或已丟失ClientServerseq:1201-1400ack:4001seq:4001-5000ack:1401ack:5001seq:5001-6000ack:1401seq:6001-7000ack:1401ack:7001正常流程規則：ACK報文不消耗sequence

number，并且不需要確認往返時延（RTT：Round-TripTime）報文丟失ClientServerseq:501-600ack:xseq:601-700ack:xseq:701-800ack:xseq:801-900ack:xack:701ack:701seq:701-800ack:xack:901timeout接收緩沖區空洞規則：如果重傳定時器超時，立即重傳ACK報文不需要重傳定時器接收到的報文，可能

亂序，此時TCP會緩存

之。TCP保證向應用層

遞交的數據，一定是正

常順序的。快速重傳ClientServerseq:101-200ack:xseq:201-300ack:xseq:301-400ack:xseq:401-500ack:xack:301seq:301-400ack:xtimeout接收緩沖區空洞ack:301seq:501-600ack:xack:301seq:601-700ack:xack:301ack:701規則：如果收到連續的3個重復的ACK，立即重傳ACK丟失（自動恢復）ClientServerseq:101-200ack:xseq:201-300ack:xseq:301-400ack:xseq:401-500ack:xack:301ack:501ACK丟失（超時重傳）ClientServerseq:101-200ack:xseq:201-300ack:xack:301ack:301timeoutseq:101-200ack:x超時時間在傳輸層中，TCP確認到達的時間概率分布不是很集中，所以確定超時重發的時間就很困難TCP采用了一種自適應算法來計算重發超時時間。這種算法把每次每個報文段發出的時間和收到此報文段確認的時間都記錄下來，兩時間之差稱為報文段的往返時延注：重傳報文不參與計算針對所有發送正確的報文段的往返時延進行加權平均，得到報文段的平均往返時延RT，而將TCP測量到的本次往返時延設為M，則按照下列公式進行計算修正的RT：

α是修正因子，一般取7/8TCP的擁塞控制（CongestionControl）路由器中的隊列負載和時延、吞吐量的關系ClientServersegment1ack2segment2segment3ack4segment4segment5segment6segment7ack8cwnd=2cwnd=4cwnd=1cwnd=8慢啟動階段：cwnd指數遞增(Exponentialgrowth)TCP在連接建立成功后，如果立即向網絡中發送大量的數據包，這樣很容易導致網絡中路由器緩存空間耗盡，從而發生擁塞。因此新建立的連接不能夠一開始就大量發送數據包，而只能根據網絡情況逐步增加每次發送的數據量，以避免上述現象的發生cwnd的單位：MSS(最大報文段)在以太網中，MSS一般為1460，PPPoE為1452慢啟動(Slowstart)ClientServersegment1ack2segment2segment3ack4segment4segment5segment6ack7cwnd=x+1cwnd=x+2cwnd=xcwnd=x+3擁塞避免階段：cwnd加性遞增(Additiveincrese)慢啟動算法中，cwnd增長的很快，從而最大程度利用網絡帶寬資源，但是cwnd不能一直這樣無限增長下去，一定需要某個限制TCP使用了一個叫慢啟動門限(ssthresh,slowstartthreshold)的變量，當cwnd超過該值后，慢啟動過程結束，進入擁塞避免階段在擁塞避免階段，cwnd加性遞增。這樣就可以避免增長過快導致網絡擁塞，慢慢的增加調整到網絡的最佳值擁塞避免(Congestionavoidance)如何檢測擁塞？TCP認為，如果發生了重傳，則說明發生了“擁塞”發生“擁塞”（重傳）的兩個原因：收到3個相同ACK（快速重傳）超時重傳重新開始一個“慢啟動”過程重新開始一個“擁塞避免”過程沖突避免慢啟動closecwnd≥ssthreshclose3ACKsTimeout連接終止擁塞ssthresh=1/2windowcwnd=ssthreshssthresh=1/2windowcwnd=1MSS擁塞連接建立連接終止一個例子UnderlyingLANorWANtechnologyNetworkInterface

LayerNetworkLayerIPICMPIGMPARPRARPTransportLayerTCPSCTPUDPApplicationLayerFTPDNSHTTPSNMPSIP???2.5SCTP協議SCTP（StreamControlTransmissionProtocol）SCTP是IETF新定義的一個傳輸層協議（2000年）可靠的通用傳輸層協議。綜合了UDP和TCP的優點提供穩定、有序的數據傳遞服務（類似于TCP）面向消息（Message）的服務（類似于UDP）在H.323,SIP中有應用SCTP的高級特性多宿主（Multi-homing）多流（Multi-streaming）初始化保護（Initiationprotection）消息分幀（Messageframing）可配置的無序發送（Configurableunordereddelivery）平滑關閉（Gracefulshutdown）SCTP特性：多宿主（Multi-homing）多宿主主機就是一臺具有多個網絡接口的主機，因此可以通過多個IP地址來訪問這臺主機在TCP中，連接（connection）是指兩個端點之間的一個通道SCTP引入了聯合（association）的概念，它也是存在于兩臺主機之間，但可以使用每臺主機上的多個接口進行協作多宿主特性為應用程序提供了比TCP更高的可用性ServerHost(TCP)ClientHost(TCP)c0s0NetworkServerHost(SCTP)ClientHost(SCTP)c0s0Network1c1s1Network2TCPSCTP一個主機有多個接口（網卡），綁定到多個IP地址Association:有兩條連接：c0–s0,c1—s1SCTP負責使用內嵌的heartbeat機制來監視聯合的路徑；在檢測到一條路徑失效時，協議就會通過另外一條路徑來發送通信數據。應用程序甚至都不必知道發生了故障恢復。SCTP特性：多流（Multi-streaming）SCTP能夠在一個聯合中支持多流機制一個聯合中的所有流都是獨立的，但均與該聯合相關Stream0Stream1???StreamNSCTPAssociation每個流都給定了一個流編號，它被編碼到SCTP報文中，通過聯合在網絡上傳送SCTP特性：初始化保護（Initiationprotection）TCP采用三次握手服務器收到SYN后，回復SYN+ACK，同時分配服務器資源SYNFlooding攻擊：客戶端而已發起大量SYN請求，但不響應后續的服務器應答報文。服務器最終資源耗盡。SCTP采用四次握手ClientServer①INIT②INIT-ACK③COOKIE-ECHO④COOKIE-ACK客戶端使用INIT發起連接服務器使用INIT-ACK進行響應，其中包括了cookie（這個連接的唯一標識）客戶機然后就使用一個COOKIE-ECHO報文進行響應，其中包含了服務器所發送的cookie服務器要為這個連接分配資源，并通過向客戶機發送一個COOKIE-ACK報文對其進行響應分配資源SCTP特性：消息分幀（Messageframing）使用消息分幀機制，就可以保護消息只在一個邊界內通過socket進行通信面向消息的協議：如果客戶機向服務器先發送100個字節，然后又發送50個字節。那么服務器就會在兩次讀取操作中分別讀取到100個字節和50個字節UDP也是這樣進行操作，這對于面向消息的協議非常有益與此不同，TCP是按照字節流的方式進行操作，需要在接收方應用層進程進行幀識別和定界TCPConnectionWritet0Writet1ReadtnUDPSocket/SCTPAssociationWritet0Writet1ReadtnReadtn-1SCTP特性：可配置的無序發送（Configurableunordereddelivery）SCTP是基于消息的可靠傳輸協議這種特性在有些面向消息的應用中可能非常有用（如果其中的消息都是獨立的，次序并不重要的話）如果需要，可以在SCTP中配置流來接受無序的消息SCTP特性：平滑關閉（Gracefulshutdown）TCP有“半關閉(Half-close)”狀態，但是在實際應用中很少使用所以SCTP就放棄了這個特性：當一端關閉自己的套接字時（導致產生一個SHUTDOWN原語），對等的兩端全部需要關閉，將來任何一端都不允許再進行數據的傳輸了PeerPeerSHUTDOWNSHUTDOWN-ACKSHUTDOWN-COMPLETION多媒體應用對網絡的需求TCP/IP三、RTP/RTCPRTP/RTCPRSVPCasestudy：實時多媒體流的傳輸Internet服務器客戶端VideoframeInternet服務器客戶端00:00:0000:00:1000:00:2000:00:3000:00:0100:00:1100:00:2100:00:31FirstPacketSecondPacketThirdPacket每個Packet包含10秒的video數據假設：時延固定為1秒實時視頻流傳輸發送時間接收并立即播放時間Internet服務器客戶端00:00:0000:00:1000:00:2000:00:3000:00:0100:00:1500:00:2700:00:37FirstPacket

(delay:1s)SecondPacket(delay:5s)ThirdPacket(delay:7s)發送時間接收并立即播放時間Jitter每個Packet時延不一致，時延的變化量稱為Jitter。此時，如果客戶端在收到數據立即播放時，會出現停頓（數據有空白期）。如果Jitter太大，雖然Packet最終到達了客戶端，但由于錯過了播放時間，仍然會被丟掉4秒2秒Internet服務器客戶端00:00:0000:00:1000:00:2000:00:3000:00:0100:00:1500:00:2700:00:37FirstPacket

(timestamp=0)SecondPacket(timestamp=10)ThirdPacket(timestamp=20)發送時間接收時間解決辦法為每個packet加上時間戳（timestamp），這個時間戳是每個Packet相對于第一個Packet的時延（相對時延）。時間都是在發送端計算的。接收到packet后，不要立即播放。這里是等待了7秒播放時間00:00:0800:00:1800:00:2800:00:387秒4秒2秒2ndPacket(TS=10)為了解決這個問題，需要使用Playbackbuffer

(又稱Jitterbuffer)1stPacket(TS=0)播放（定速）00:00:01到達（變速）00:00:08(1stpacket到達時間)(1st

packet播放時間)buffer中有7秒的數據1stPacket(TS=0)播放（定速）00:00:15到達（變速）00:00:18(2ndpacket到達時間)(2nd

packet播放時間)buffer中有3秒的數據3rdPacket(TS=20)2ndPacket(TS=10)1stPacket(TS=0)播放（定速）00:00:27到達（變速）00:00:28(3rdpacket到達時間)(3rdpacket播放時間)buffer中有1秒的數據3rdPacket(TS=20)2ndPacket(TS=10)1stPacket(TS=0)播放（定速）00:00:27到達（變速）00:00:38(到達時間)buffer已空00:00:1500:00:01TimeBytes(Sequencenumbers)播放（CBR）數據產生（CBR）數據到達（VBR）時延最大播放時延（orMaxBufferDuration）（or允許的最大Jitter）CBR:ConstantBitRateVBR:VariableBitRateBuffersizeBufferdurationBuffer將空流暢播放區域Buffer空了，播放被迫停止實時媒體傳輸需要：為了保證重放時的時間順序，以及去除Jitter，需要時間戳(timestamp)為了保證數據的順序，需要序號(sequencenumber)很多應用，比如視頻會議，需要向多個客戶端發送數據，所以有時候需要多播(multicast)在擁塞控制等場合，可能需要修改編碼參數(encodingparameter)為了在接收端能正確地重放，可能需要提供編碼協商(choiceofencoding)同時播放音視頻，需要提供混合器(mixer)為了在低帶寬網絡上傳輸高帶寬流，需要提供轉換器(translator)實時數據可否用TCP傳輸？TCP在丟包的時候，需要等待重傳，導致了大的時延TCP不支持多播TCP的擁塞控制機制，當丟包時，進入慢啟動流程，cwnd降低的太快。對音視頻流傳輸有影響TCP頭開銷太大（TCP：20bytes，UDP：8bytes）TCP報文中沒有包含必要的時間戳

信息TCP不允許丟包，而在音視頻應用中，可以容忍一定程度的丟包和多媒體通信相關的一些協議功能協議含義媒體描述SDPSessionDescriptionProtocol描述了會話數據和媒體內容媒體通信控制RTCPReal-TimeControlProtocol用于多媒體會話中的通信控制媒體傳輸RTPReal-timeTransportProtocol用于多媒體會話中的媒體流傳輸資源預約RSVPResourceReservationProtocol實現QoS會話管理SIPSessionInitiationProtocol媒體會話建立實時流傳輸RTSPReal-TimeStreamingProtocol實時流傳輸，用戶可控制(啟停、快進、暫停….)SonetATMPPPAAL3/4AAL5EthernetV.34PPPIPv4,IPv6TCPUDPH.323SIPSDPRTSPRSVPRTCPRTPH.261,MPEGKernelApplicationdaemonSignalingQualityofServiceMediatransportReservationMeasurement物理層鏈路層網絡層傳輸層應用層3.1RTP協議RTP(Real-timeTransportProtocol)提供實時數據（如交互式的音頻和視頻）的端到端傳輸服務RTP沒有連接的概念，它不是典型意義上的傳輸層協議，必須建立在底層的面向連接或無連接的傳輸協議之上傳輸層協議通常使用UDP，但也可以使用其它協議，如SCTP介于應用層和UDP之間的協議（RTP屬于那一層，尚有爭論）RTP本身不提供任何可靠性機制，但可以：通過加入時間戳，使得終端系統可以消除/降低時延抖動在一個多媒體會話中，同步多路音視頻流音視頻流的復用（Multiplexing）一種編碼到另外一種編碼的轉換RTCP協議可提供QoS反饋，多個媒體流同步等，一般和RTP配合使用在實際系統中，一般和如下協議配合使用RTCP信令協議，如H.323,SIP,XMPP等媒體描述協議，如SDPRTPSession每個多媒體流都建立一個RTPSession一個Session由IP地址和一對RTP/RTCP端口組成一般RTP使用偶數端口，RTCP使用相鄰的大的奇數端口（注意不是固定端口）這些端口號一般由其它會話建立協議商定（out-of-band）比如，audio和video用不同的stream，接收方可選擇某個特定的流RTP協議中的數據單元是

PacketUnderlyingLANorWANtechnologyNetworkInterface

LayerNetworkLayerIPICMPIGMPARPRARPTransportLayerRTPUDPApplicationLayerH.261MPEGAudioPCMMPEG1VideoMotionJPEG???MPEG2VideoRTP

PacketUDPheaderRTPheaderRTPPayloadPaddingPadcount變長，最小12字節RTP端口為在會話初始階段隨機選取的偶數Payload的長度，需要在開銷和時延之間做權衡；一般來說，packet盡可能小，這樣的話packet丟失造成的媒體質量損失也越小；比如20ms的未壓縮話音數據時160bytes，丟失20ms的話音數據，基本感覺不到。有的系統要求固定大小的packet，此時需要進行填充1字節Synchronizationsourceidentifier(SSRC)(32bits)Timestamp(32bits)SequenceNumber16bitsRTPHeaderMediaData(Payload)RTP

HeaderVERPCCPTContributoridentifier(CSRC)(32bits)Contributoridentifier(CSRC)(32bits)???XM最少12bytesSynchronizationsourceidentifier(SSRC)(32bits)Timestamp(32bits)SequenceNumber16bitsRTPHeaderMediaData(Payload)VERPCCPTContributoridentifier(CSRC)(32bits)Contributoridentifier(CSRC)(32bits)???XMVersion，2bits，現在是2Synchronizationsourceidentifier(SSRC)(32bits)Timestamp(32bits)SequenceNumber16bitsRTPHeaderMediaData(Payload)VERPCCPTContributoridentifier(CSRC)(32bits)Contributoridentifier(CSRC)(32bits)???XMPadding，1bit，用來指示在RTP

Packet的末尾，是否有填充（padding）數據。在有填充的情況下，最后一個byte的值用來指示填充字節的長度（包括長度自己）Synchronizationsourceidentifier(SSRC)(32bits)Timestamp(32bits)SequenceNumber16bitsRTPHeaderMediaData(Payload)VERPCCPTContributoridentifier(CSRC)(32bits)Contributoridentifier(CSRC)(32bits)???XMExtension，1bit，用來指示在標準RTP頭（12bytes）和payload之間，是否存在擴展數據Synchronizationsourceidentifier(SSRC)(32bits)Timestamp(32bits)SequenceNumber16bitsRTPHeaderMediaData(Payload)VERPCCPTContributoridentifier(CSRC)(32bits)Contributoridentifier(CSRC)(32bits)???XMCSRCCount，4bits，CSRCidentifier的數目。取值0~15，每個Identifier為32bitsSynchronizationsourceidentifier(SSRC)(32bits)Timestamp(32bits)SequenceNumber16bitsRTPHeaderMediaData(Payload)VERPCCPTContributoridentifier(CSRC)(32bits)Contributoridentifier(CSRC)(32bits)???XMMarker（標記），1bit，由profile定義，。允許重要事件如幀邊界在數據包流中進行標記Synchronizationsourceidentifier(SSRC)(32bits)Timestamp(32bits)SequenceNumber16bitsRTPHeaderMediaData(Payload)VERPCCPTContributoridentifier(CSRC)(32bits)Contributoridentifier(CSRC)(32bits)???XMPayloadType，7bits，表示Payload部分的數據類型TypeApplicationTypeApplicationTypeApplication0PCMμAudio7LPCAudio15G.728Audio110168PCMAAudio26MotionJPEG2G.721Audio9G.722Audio31H.2613GSMAudio10~11L16Audio32MPEG1Video5~6DV14Audio14MPEGAudio33MPEG2VideoPayloadTypeSynchronizationsourceidentifier(SSRC)(32bits)Timestamp(32bits)SequenceNumber16bitsRTPHeaderMediaData(Payload)VERPCCPTContributoridentifier(CSRC)(32bits)Contributoridentifier(CSRC)(32bits)???XMRTPPacket序號，16bits，每發送一個RTP數據包，序列號增加1。接收方可以依次檢測數據包的丟失并恢復數據包序列。16bits到達最大值后，可以回卷Synchronizationsourceidentifier(SSRC)(32bits)Timestamp(32bits)SequenceNumber16bitsRTPHeaderMediaData(Payload)VERPCCPTContributoridentifier(CSRC)(32bits)Contributoridentifier(CSRC)(32bits)???XMTimestamp，32bits，反映RTP數據包中的第一個八位組(Octet)的采樣時間。采樣時間必須通過時鐘及時提供線性無變化增量獲取，以支持同步和抖動計算Timestamp和SequenceNumberTimestamp：是一個相對時間，表示本Frame的第一個octet的“時間戳”，起始值要求是隨機數。Timestamp的單位一般是“sampling”。比如8K采樣，那么timestamp的單位就是125us。也可以理解為“樣點數”。SequenceNumber：RTPpacket序號。如果一個Frame比較大，被分成了多個Packet傳輸，則這些packet的Timestamp相同，sequencenumber不同。Timestamp和SequenceNumber(Audio)8000Hz采樣（125μs）一個RTPpacket承載20ms的話音，每個RTPpacket由獨立的UDPdatagram傳送Timestamp增長幅度：20ms/125μs=160（20ms中包含了160個采樣點）Packetrate：1sec/20ms=50Hz每個RTPpayload長度：160*8=1280Sequencenumber：每個RTPpacket加1ts=xsn=yAudioStreamts=x+160sn=y+1AudioStreamRTP

packetn-1RTP

packetnTimestamp和