《多媒體通信》第4章 通信協(xié)議-v1.4

《多媒體通信》

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

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

LayerNetworkLayerIPICMPIGMPARPRARPTransportLayerTCPSCTPUDPApplicationLayerFTPDNSHTTPSNMPSIP???2.2IP協(xié)議InternetProtocol根據(jù)IP地址進(jìn)行路由不保證服務(wù)質(zhì)量IPv4IPv6（本節(jié)針對的是IPv4）IP地址(IPv4)長度為32bit，共4,294,967,296點(diǎn)分十進(jìn)制記法（Dotted-decimalnotation）0111100000100011000101101111100048分為“子網(wǎng)地址”和“主機(jī)地址”二級結(jié)構(gòu)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協(xié)議的版本號。對于IPv4，此值為4IPv4header可選項目的IP地址(32bits)源IP地址(32bits)TTL8bitsHeaderChecksum16bitsProtocol8bitsIdentification16bitsFragmentationOffset13bitsFlag3bitsVER4bitsDS8bitsHLEN4bitsTotalLength16bitsIPHeaderData20~60bytes20~65536bytes以32比特字長為單位的首部長度，即長度=n*4bytes，n取值為5~15，所以首部長度為20~60bytesIPv4header可選項目的IP地址(32bits)源IP地址(32bits)TTL8bitsHeaderChecksum16bitsProtocol8bitsIdentification16bitsFragmentationOffset13bitsFlag3bitsVER4bitsDS8bitsHLEN4bitsTotalLength16bitsIPHeaderData20~60bytes20~65536bytesDifferentiatedServices，規(guī)定了本數(shù)據(jù)報的處理方式IPv4header可選項目的IP地址(32bits)源IP地址(32bits)TTL8bitsHeaderChecksum16bitsProtocol8bitsIdentification16bitsFragmentationOffset13bitsFlag3bitsVER4bitsDS8bitsHLEN4bitsTotalLength16bitsIPHeaderData20~60bytes20~65535bytes總長度，以字節(jié)為單位的IP數(shù)據(jù)報長度，包括首部和數(shù)據(jù)中的字節(jié)數(shù)，20~65535之間IPv4header可選項目的IP地址(32bits)源IP地址(32bits)TTL8bitsHeaderChecksum16bitsProtocol8bitsIdentification16bitsFragmentationOffset13bitsFlag3bitsVER4bitsDS8bitsHLEN4bitsTotalLength16bitsIPHeaderData20~60bytes20~65535bytes在分片（Fragment）的情況下，此字段為惟一標(biāo)識該數(shù)據(jù)報的整數(shù)。其主要目的是為了讓目的主機(jī)知道到達(dá)的數(shù)據(jù)報片屬于哪個數(shù)據(jù)報IPv4header可選項目的IP地址(32bits)源IP地址(32bits)TTL8bitsHeaderChecksum16bitsProtocol8bitsIdentification16bitsFragmentationOffset13bitsFlag3bitsVER4bitsDS8bitsHLEN4bitsTotalLength16bitsIPHeaderData20~60bytes20~65535bytesbit0：保留，必須為0bit1：Don’tFragment(DF)如果此bit置1，則不允許分片bit2：MoreFragment(MF)如果當(dāng)前數(shù)據(jù)報片為最后一片，則為0，否則為1IPv4header可選項目的IP地址(32bits)源IP地址(32bits)TTL8bitsHeaderChecksum16bitsProtocol8bitsIdentification16bitsFragmentationOffset13bitsFlag3bitsVER4bitsDS8bitsHLEN4bitsTotalLength16bitsIPHeaderData20~60bytes20~65535bytes在分片的情況下，表示此分片所攜帶的數(shù)據(jù)在原始數(shù)據(jù)報中以8字節(jié)為單位的偏移量，從零開始計數(shù)。如果未分片，則為0分片（Fragmentation）HeaderMTU（最大傳輸單元）IP數(shù)據(jù)報Trailer網(wǎng)絡(luò)層鏈路層網(wǎng)絡(luò)MTUTokenRing(16Mbps)17914TokenRing(4Mbps)4464FDDI4352WLAN7981EthernetV21500EthernetwithLLC/SNAP/PPPoE1492在傳輸過程中，如果IP數(shù)據(jù)報長度，超過了鏈路層的MTU，則：1）分片2）不分片（如DF=1），丟棄數(shù)據(jù)報在傳輸過程中，可能會被多次分片在最后的接收端進(jìn)行重裝IPv4header可選項目的IP地址(32bits)源IP地址(32bits)TTL8bitsHeaderChecksum16bitsProtocol8bitsIdentification16bitsFragmentationOffset13bitsFlag3bitsVER4bitsDS8bitsHLEN4bitsTotalLength16bitsIPHeaderData20~60bytes20~65535bytesTimetoLive，為該數(shù)據(jù)報在互聯(lián)網(wǎng)中允許存在的時間，以秒為單位。絕大多數(shù)路由器只是簡單地在數(shù)據(jù)報經(jīng)過時將該值減1，減為0時丟棄該數(shù)據(jù)報IPv4header可選項目的IP地址(32bits)源IP地址(32bits)TTL8bitsHeaderChecksum16bitsProtocol8bitsIdentification16bitsFragmentationOffset13bitsFlag3bitsVER4bitsDS8bitsHLEN4bitsTotalLength16bitsIPHeaderData20~60bytes20~65535bytes指出此數(shù)據(jù)報攜帶的傳輸層數(shù)據(jù)使用何種協(xié)議，常見的有：ICMP(1),IGMP(2),TCP(6),UDP(17),SCTP(132)IPv4header可選項目的IP地址(32bits)源IP地址(32bits)TTL8bitsHeaderChecksum16bitsProtocol8bitsIdentification16bitsFragmentationOffset13bitsFlag3bitsVER4bitsDS8bitsHLEN4bitsTotalLength16bitsIPHeaderData20~60bytes20~65535bytes此字段只檢驗數(shù)據(jù)報的首部，不包括數(shù)據(jù)部分。校驗時也不包括checksum自己UnderlyingLANorWANtechnologyNetworkInterface

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

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

(IP,Port)Socket

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

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

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

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

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

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

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

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

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

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

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

亂序，此時TCP會緩存

之。TCP保證向應(yīng)用層

遞交的數(shù)據(jù)，一定是正

常順序的?？焖僦貍鰿lientServerseq:101-200ack:xseq:201-300ack:xseq:301-400ack:xseq:401-500ack:xack:301seq:301-400ack:xtimeout接收緩沖區(qū)空洞ack:301seq:501-600ack:xack:301seq:601-700ack:xack:301ack:701規(guī)則：如果收到連續(xù)的3個重復(fù)的ACK，立即重傳ACK丟失（自動恢復(fù)）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確認(rèn)到達(dá)的時間概率分布不是很集中，所以確定超時重發(fā)的時間就很困難TCP采用了一種自適應(yīng)算法來計算重發(fā)超時時間。這種算法把每次每個報文段發(fā)出的時間和收到此報文段確認(rèn)的時間都記錄下來，兩時間之差稱為報文段的往返時延注：重傳報文不參與計算針對所有發(fā)送正確的報文段的往返時延進(jìn)行加權(quán)平均，得到報文段的平均往返時延RT，而將TCP測量到的本次往返時延設(shè)為M，則按照下列公式進(jìn)行計算修正的RT：

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

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

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

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

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

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

PacketUnderlyingLANorWANtechnologyNetworkInterface

LayerNetworkLayerIPICMPIGMPARPRARPTransportLayerRTPUDPApplicationLayerH.261MPEGAudioPCMMPEG1VideoMotionJPEG???MPEG2VideoRTP

PacketUDPheaderRTPheaderRTPPayloadPaddingPadcount變長，最小12字節(jié)RTP端口為在會話初始階段隨機(jī)選取的偶數(shù)Payload的長度，需要在開銷和時延之間做權(quán)衡；一般來說，packet盡可能小，這樣的話packet丟失造成的媒體質(zhì)量損失也越??；比如20ms的未壓縮話音數(shù)據(jù)時160bytes，丟失20ms的話音數(shù)據(jù)，基本感覺不到。有的系統(tǒng)要求固定大小的packet，此時需要進(jìn)行填充1字節(jié)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，現(xiàn)在是2Synchronizationsourceidentifier(SSRC)(32bits)Timestamp(32bits)SequenceNumber16bitsRTPHeaderMediaData(Payload)VERPCCPTContributoridentifier(CSRC)(32bits)Contributoridentifier(CSRC)(32bits)???XMPadding，1bit，用來指示在RTP

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

packetn-1RTP

packetnTimestamp和