流媒体传输协议

　　本篇作为学习Android流媒体的先导，先介绍以下四种协议：RTSP，HTTP，HTTPS和SDP。

1.RTSP协议

1）简介

　　RTSP（Real Time Streaming Protocol），RFC2326，实时流传输协议，是TCP/IP协议体系中的一个应用层协议，该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP在体系结构上位于RTP和RTCP之上，它使用TCP或UDP完成数据传输。HTTP与RTSP相比，HTTP请求由客户机发出，服务器作出响应；使用RTSP时，客户机和服务器都可以发出请求，即RTSP可以是双向的。RTSP是用来控制声音或影像的多媒体串流协议，并允许同时多个串流需求控制，传输时所用的网络通讯协定并不在其定义的范围内，服务器端可以自行选择使用TCP或UDP来传送串流内容，它的语法和运作跟HTTP 1.1类似，但并不特别强调时间同步，所以比较能容忍网络延迟。实现RTSP的控制，还要有专门的媒体播放器和媒体服务器。媒体服务器和媒体播放器的关系是服务器同客户的关系S/C。RTSP是使媒体播放器能够控制多媒体流的传送。RTSP又叫带外协议，多媒体流使用RTP在带内传送。

2)RTSP的报文结构

　　RTSP有两类报文：请求报文和响应报文。请求报文是从客户端向服务器发送请求报文，响应报文是从服务器到客户的应答。

　　RTSP在报文中的每一个字段都是一些ASCII码串，每段的长度都不确定。

　　RTSP报文由三个部分组成，开始行、首部行和实体主体。RTSP请求报文的结构如下所示。

方法如下：

1.OPTION

目的是得到服务器提供的可用方法:

OPTIONS rtsp://192.168.20.136:5000/xxx666 RTSP/1.0 

CSeq: 1         //每个消息都有序号来标记，第一个包通常是option请求消息 

User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10)

服务器的回应信息包括提供的一些方法,例如:

RTSP/1.0 200 OK 

Server: UServer 0.9.7_rc1 

Cseq: 1         //每个回应消息的cseq数值和请求消息的cseq相对应 

Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, SCALE, GET_PARAMETER //服务器提供的可用的方法

2.DESCRIBE

C向S发起DESCRIBE请求,为了得到会话描述信息(SDP):

DESCRIBE rtsp://192.168.20.136:5000/xxx666 RTSP/1.0 

CSeq: 2 

token: 

Accept: application/sdp 

User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10)

服务器回应一些对此会话的描述信息(sdp):

RTSP/1.0 200 OK
Server: UServer 0.9.7_rc1
Cseq: 2
x-prev-url: rtsp://192.168.20.136:5000
x-next-url: rtsp://192.168.20.136:5000
x-Accept-Retransmit: our-retransmit
x-Accept-Dynamic-Rate: 1
Cache-Control: must-revalidate
Last-Modified: Fri, 10 Nov 2006 12:34:38 GMT
Date: Fri, 10 Nov 2006 12:34:38 GMT
Expires: Fri, 10 Nov 2006 12:34:38 GMT
Content-Base: rtsp://192.168.20.136:5000/xxx666/
Content-Length: 344
Content-Type: application/sdp
v=0        //以下都是sdp信息
o=OnewaveUServerNG 1451516402 1025358037 IN IP4 192.168.20.136
s=/xxx666
u=http:///
e=admin@
c=IN IP4 0.0.0.0
t=0 0
a=isma-compliance:1,1.0,1
a=range:npt=0-
m=video 0 RTP/AVP 96     //m表示媒体描述，下面是对会话中视频通道的媒体描述
a=rtpmap:96 MP4V-ES/90000
a=fmtp:96 
profile-level-id=245;
config=000001B0F5000001B509000001000000012000C888B0E0E0FA62D089028307
a=control:trackID=0//trackID＝0表示视频流用的是通道0

3.SETUP
客户端提醒服务器建立会话,并确定传输模式:

SETUP rtsp://192.168.20.136:5000/xxx666/trackID=0 RTSP/1.0     
CSeq: 3
Transport: RTP/AVP/TCP;unicast;interleaved=0-1       
User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10)
//uri中带有trackID＝0，表示对该通道进行设置。

Transport参数设置了传输模式，包的结构。接下来的数据包头部第二个字节位置就是interleaved，它的值是每个通道都不同的，trackID＝0的interleaved值有两个0或1，0表示rtp包，1表示rtcp包，接受端根据interleaved的值来区别是哪种数据包。

服务器回应信息:

RTSP/1.0 200 OK
Server: UServer 0.9.7_rc1
Cseq: 3
Session: 6310936469860791894     //服务器回应的会话标识符
Cache-Control: no-cache
Transport: RTP/AVP/TCP;unicast;interleaved=0-1;ssrc=6B8B4567

4.PLAY

客户端发送播放请求:

PLAY rtsp://192.168.20.136:5000/xxx666 RTSP/1.0
CSeq: 4
Session: 6310936469860791894
Range: npt=0.000-      //设置播放时间的范围
User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10)

服务器回应信息:

RTSP/1.0 200 OK
Server: UServer 0.9.7_rc1
Cseq: 4
Session: 6310936469860791894
Range: npt=0.000000-
RTP-Info: url=trackID=0;seq=17040;rtptime=1467265309      //seq和rtptime都是rtp包中的信息

5.TEARDOWN

客户端发起关闭请求:

TEARDOWN rtsp://192.168.20.136:5000/xxx666 RTSP/1.0
CSeq: 5
Session: 6310936469860791894
User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10)

服务器回应:

RTSP/1.0 200 OK
Server: UServer 0.9.7_rc1
Cseq: 5
Session: 6310936469860791894
Connection: Close

以上方法都是交互过程中最为常用的,其它还有一些重要的方法如：get/set_parameter,pause,redirect等等。

RTSP请求报文的常用方法及作用

方法	作用
OPTIONS	获得服务器提供的可用方法
DESCRIBE	得到会话描述信息
SETUP	客户端提醒服务器建立会话，并确定传输模式
TEARDOWN	客户端发起关闭请求
PLAY	客户端发送播放请求

　　响应报文的结构如下图。

3)RTSP交互过程

C是客户端，S是服务端

① C->S: OPTION request            //询问S有哪些方法可用

S->C: OPTION response        //S回应信息中包括提供的所有可用方法

② C->S: DESCRIBE request      //要求得到S提供的媒体初始化描述信息

S->C: DESCRIBE response      //S回应媒体初始化描述信息，主要是sdp

③ C->S: SETUP request    //设置会话属性，以及传输模式，提醒S建立会话

S->C: SETUP response        //S建立会话，返回会话标识符及会话相关信息

④ C->S: PLAY request          //C请求播放

S->C: PLAY response          //S回应请求信息

S->C: 发送流媒体数据

⑤ C->S: TEARDOWN request     //C请求关闭会话

S->C: TEARDOWN response     //S回应请求

　　上述的过程是标准的RTSP流程，其中第3步和第4步是必需的。

4）RTSP命令的状态转换表

　　RTSP中很多方法与状态无关，但下列方法在定义服务器流资源的分配与应用上起着重要的作用：

(1) SETUP：让服务器给流分配资源，启动RTSP连接。

(2) PLAY与RECORD：启动SETUP分配流的数据传输。

(3) PAUSE：临时停止流，而不释放服务器资源。

(4) TEARDOWN：释放流的资源，RTSP连接停止。

5)点播视频文件的例子

1. OPTIONS
client-->server
========================================================================================================
OPTIONS rtsp://115.182.51.79/zuoyou001.mp4 RTSP/1.0
CSeq: 2
User-Agent: LibVLC/1.1.11 (LIVE555 Streaming Media v2011.05.25)

server-->client
========================================================================================================
RTSP/1.0 200 OK
Server: DSS/6.0.3 (Build/526.3; Platform/FreeBSD; Release/Darwin Streaming Server; State/Development; )
Cseq: 2
Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS, ANNOUNCE, RECORD

2. DESCRIBE
client-->server
========================================================================================================
DESCRIBE rtsp://115.182.51.79/zuoyou001.mp4 RTSP/1.0
CSeq: 3
User-Agent: LibVLC/1.1.11 (LIVE555 Streaming Media v2011.05.25)
Accept: application/sdp

server-->client
========================================================================================================
RTSP/1.0 200 OK
Server: DSS/6.0.3 (Build/526.3; Platform/FreeBSD; Release/Darwin Streaming Server; State/Development; )
Cseq: 3
Last-Modified: Thu, 17 Jan 2002 11:20:30 GMT
Cache-Control: must-revalidate
Content-length: 876
Date: Wed, 04 Jan 2012 06:14:53 GMT
Expires: Wed, 04 Jan 2012 06:14:53 GMT
Content-Type: application/sdp
x-Accept-Retransmit: our-retransmit
x-Accept-Dynamic-Rate: 1
Content-Base: rtsp://115.182.51.79/zuoyou001.mp4/

v=0
o=StreamingServer 3534646499 1011266430000 IN IP4 115.182.51.79
s=/zuoyou001.mp4
u=http:///
e=admin@
c=IN IP4 0.0.0.0
b=AS:632
t=0 0
a=control:*
a=x-copyright: MP4/3GP File hinted with GPAC 0.4.6-DEV (build 1 - May 19 2009) - compiled by Kurtnoise (C)2000-2005 - http://gpac.sourceforge.net
a=range:npt=0-6640.12667
m=video 0 RTP/AVP 96
b=AS:600
a=3GPP-Adaptation-Support:1
a=rtpmap:96 H264/90000
a=control:trackID=65536
a=fmtp:96 profile-level-id=4D401E; packetization-mode=1; sprop-parameter-sets=Z01AHpp0BaGdgIgAAAMACAAAAwGUeLF1,aO48gA==
a=framesize:96 720-400
m=audio 0 RTP/AVP 97
b=AS:32
a=3GPP-Adaptation-Support:1
a=rtpmap:97 mpeg4-generic/24000/2
a=control:trackID=65537
a=fmtp:97 profile-level-id=40; config=131056e59d4800; streamType=5; mode=AAC-hbr; objectType=64; constantDuration=2048; sizeLength=13; indexLength=3; indexDeltaLength=3

3. SETUP
client-->server
========================================================================================================
SETUP rtsp://115.182.51.79/zuoyou001.mp4/trackID=65536 RTSP/1.0
CSeq: 4
User-Agent: LibVLC/1.1.11 (LIVE555 Streaming Media v2011.05.25)
Transport: RTP/AVP/TCP;unicast;interleaved=0-1

server-->client
========================================================================================================
RTSP/1.0 200 OK
Server: DSS/6.0.3 (Build/526.3; Platform/FreeBSD; Release/Darwin Streaming Server; State/Development; )
Cseq: 4
Last-Modified: Thu, 17 Jan 2002 11:20:30 GMT
Cache-Control: must-revalidate
Session: 1837199341906602386
Date: Wed, 04 Jan 2012 06:14:53 GMT
Expires: Wed, 04 Jan 2012 06:14:53 GMT
Transport: RTP/AVP/TCP;unicast;interleaved=0-1;ssrc=0E4646D1

4. SETUP
client-->server
========================================================================================================
SETUP rtsp://115.182.51.79/zuoyou001.mp4/trackID=65537 RTSP/1.0
CSeq: 5
User-Agent: LibVLC/1.1.11 (LIVE555 Streaming Media v2011.05.25)
Transport: RTP/AVP/TCP;unicast;interleaved=2-3
Session: 1837199341906602386

server-->client
========================================================================================================
RTSP/1.0 200 OK
Server: DSS/6.0.3 (Build/526.3; Platform/FreeBSD; Release/Darwin Streaming Server; State/Development; )
Cseq: 5
Session: 1837199341906602386
Last-Modified: Thu, 17 Jan 2002 11:20:30 GMT
Cache-Control: must-revalidate
Date: Wed, 04 Jan 2012 06:14:53 GMT
Expires: Wed, 04 Jan 2012 06:14:53 GMT
Transport: RTP/AVP/TCP;unicast;interleaved=2-3;ssrc=5B56A405

5. PLAY
client-->server
========================================================================================================
PLAY rtsp://115.182.51.79/zuoyou001.mp4/ RTSP/1.0
CSeq: 6
User-Agent: LibVLC/1.1.11 (LIVE555 Streaming Media v2011.05.25)
Session: 1837199341906602386
Range: npt=0.000-

server-->client
========================================================================================================
RTSP/1.0 200 OK
Server: DSS/6.0.3 (Build/526.3; Platform/FreeBSD; Release/Darwin Streaming Server; State/Development; )
Cseq: 6
Session: 1837199341906602386
Range: npt=0.00000-6640.12667
RTP-Info: url=rtsp://115.182.51.79/zuoyou001.mp4/trackID=65536;seq=55088;rtptime=37707334,url=rtsp://115.182.51.79/zuoyou001.mp4/trackID=65537;seq=19114;rtptime=550154668

6. TEARDOWN 
client-->server
========================================================================================================
TEARDOWN rtsp://115.182.51.79/zuoyou001.mp4/ RTSP/1.0
CSeq: 7
User-Agent: LibVLC/1.1.11 (LIVE555 Streaming Media v2011.05.25)
Session: 1837199341906602386

server-->client
========================================================================================================
******

2 HTTP协议

1）HTTP协议简介

　　HTTP是Hyper Text Transfer Protocol（超文本传输协议）的缩写。它的发展是万维网协会（World Wide Web Consortium）和Internet工作小组IETF（Internet Engineering Task Force）合作的结果，（他们）最终发布了一系列的RFC，RFC 1945定义了HTTP/1.0版本。其中最著名的就是RFC 2616。RFC 2616定义了今天普遍使用的一个版本——HTTP 1.1。HTTP是一个应用层协议，由请求和响应构成，是一个标准的客户端服务器模型。HTTP是一个无状态的协议。HTTP协议通常承载于TCP协议之上，有时也承载于TLS或SSL协议层之上，这个时候，就成了我们常说的HTTPS。默认HTTP的端口号为80，HTTPS的端口号为443。如下图所示：

2）HTTP的请求响应模型

　　HTTP协议永远都是客户端发起请求，服务器回送响应。HTTP协议是一个无状态的协议，同一个客户端的这次请求和上次请求是没有对应关系。见下图：

3）工作流程

　　一次HTTP操作称为一个事务，其工作过程可分为四步：

1）首先客户机与服务器需要建立连接。只要单击某个超级链接，HTTP的工作开始。

2）建立连接后，客户机发送一个请求给服务器，请求方式的格式为：统一资源标识符（URL）、协议版本号，后边是MIME信息包括请求修饰符、客户机信息和可能的内容。

3）服务器接到请求后，给予相应的响应信息，其格式为一个状态行，包括信息的协议版本号、一个成功或错误的代码，后边是MIME信息包括服务器信息、实体信息和可能的内容。

4）客户端接收服务器所返回的信息通过浏览器显示在用户的显示屏上，然后客户机与服务器断开连接。

　　如果在以上过程中的某一步出现错误，那么产生错误的信息将返回到客户端，有显示屏输出。对于用户来说，这些过程是由HTTP自己完成的。

　　当我们在浏览器的地址栏输入 www.XXX.com ，然后回车，回车这一瞬间到看到页面到底发生了什么呢？

　　域名解析 --> 发起TCP的3次握手 --> 建立TCP连接后发起http请求 --> 服务器响应http请求，浏览器得到html代码 --> 浏览器解析html代码，并请求html代码中的资源（如js、css、图片等） --> 浏览器对页面进行渲染呈现给用户。

1.域名解析

　　首先Chrome浏览器会解析 www.XXX.com 这个域名（准确的叫法应该是主机名）对应的IP地址。怎么解析到对应的IP地址？

① Chrome浏览器会首先搜索浏览器自身的DNS缓存（缓存时间比较短，大概只有1分钟，且只能容纳1000条缓存），看自身的缓存中是否有www.XXX.com 对应的条目，而且没有过期，如果有且没有过期则解析到此结束。

注：我们怎么查看Chrome自身的缓存？可以使用 chrome://net-internals/#dns 来进行查看

② 如果浏览器自身的缓存里面没有找到对应的条目，那么Chrome会搜索操作系统自身的DNS缓存,如果找到且没有过期则停止搜索解析到此结束.

注：怎么查看操作系统自身的DNS缓存，以Windows系统为例，可以在命令行下使用ipconfig /displaydns 来进行查看

③ 如果在Windows系统的DNS缓存也没有找到，那么尝试读取hosts文件（位于C:\Windows\System32\drivers\etc），看看这里面有没有该域名对应的IP地址，如果有则解析成功。

④ 如果在hosts文件中也没有找到对应的条目，浏览器就会发起一个DNS的系统调用，就会向本地配置的首选DNS服务器（一般是电信运营商提供的，也可以使用像Google提供的DNS服务器）发起域名解析请求（通过的是UDP协议向DNS的53端口发起请求，这个请求是递归的请求，也就是运营商的DNS服务器必须得提供给我们该域名的IP地址），运营商的DNS服务器首先查找自身的缓存，找到对应的条目，且没有过期，则解析成功。如果没有找到对应的条目，则有运营商的DNS代我们的浏览器发起迭代DNS解析请求，它首先是会找根域的DNS的IP地址（这个DNS服务器都内置13台根域的DNS的IP地址），找打根域的DNS地址，就会向其发起请求（请问www.XXX.com这个域名的IP地址是多少啊？），根域发现这是一个顶级域com域的一个域名，于是就告诉运营商的DNS我不知道这个域名的IP地址，但是我知道com域的IP地址，你去找它去，于是运营商的DNS就得到了com域的IP地址，又向com域的IP地址发起了请求（请问www.XXX.com这个域名的IP地址是多少?）,com域这台服务器告诉运营商的DNS我不知道www.XXX.com这个域名的IP地址，但是我知道XXX.com这个域的DNS地址，你去找它去，于是运营商的DNS又向XXX.com这个域名的DNS地址（这个一般就是由域名注册商提供的，像万网，新网等）发起请求（请问www.XXX.com这个域名的IP地址是多少？），这个时候XXX.com域的DNS服务器一查，果真在我这里，于是就把找到的结果发送给运营商的DNS服务器，这个时候运营商的DNS服务器就拿到了www.XXX.com这个域名对应的IP地址，并返回给Windows系统内核，内核又把结果返回给浏览器，终于浏览器拿到了www.XXX.com 对应的IP地址，该进行一步的动作了。

注：一般情况下是不会进行以下步骤的如果经过以上的4个步骤，还没有解析成功，那么会进行如下步骤（以下是针对Windows操作系统）：

⑤ 操作系统就会查找NetBIOS name Cache（NetBIOS名称缓存，就存在客户端电脑中的），那这个缓存有什么东西呢？凡是最近一段时间内和我成功通讯的计算机的计算机名和Ip地址，就都会存在这个缓存里面。什么情况下该步能解析成功呢？就是该名称正好是几分钟前和我成功通信过，那么这一步就可以成功解析。

⑥ 如果第⑤步也没有成功，那会查询WINS 服务器（是NETBIOS名称和IP地址对应的服务器）

⑦ 如果第⑥步也没有查询成功，那么客户端就要进行广播查找

⑧ 如果第⑦步也没有成功，那么客户端就读取LMHOSTS文件（和HOSTS文件同一个目录下，写法也一样）

　　如果第八步还没有解析成功，那么就宣告这次解析失败，那就无法跟目标计算机进行通信。只要这八步中有一步可以解析成功，那就可以成功和目标计算机进行通信。

2.发起TCP的3次握手

　　拿到域名对应的IP地址之后，User-Agent（一般是指浏览器）会以一个随机端口（1024 < 端口 < 65535）向服务器的WEB程序（常用的有httpd,nginx等）80端口发起TCP的连接请求。这个连接请求（原始的http请求经过TCP/IP4层模型的层层封包）到达服务器端后（这中间通过各种路由设备，局域网内除外），进入到网卡，然后是进入到内核的TCP/IP协议栈（用于识别该连接请求，解封包，一层一层的剥开），还有可能要经过Netfilter防火墙（属于内核的模块）的过滤，最终到达WEB程序（本文就以Nginx为例），最终建立了TCP/IP的连接。

1） Client首先发送一个连接试探，ACK=0 表示确认号无效，SYN = 1 表示这是一个连接请求或连接接受报文，同时表示这个数据报不能携带数据，seq = x 表示Client自己的初始序号（seq = 0 就代表这是第0号包），这时候Client进入syn_sent状态，表示客户端等待服务器的回复。

2） Server监听到连接请求报文后，如同意建立连接，则向Client发送确认。TCP报文首部中的SYN 和 ACK都置1 ，ack = x + 1表示期望收到对方下一个报文段的第一个数据字节序号是x+1，同时表明x为止的所有数据都已正确收到（ack=1其实是ack=0+1,也就是期望客户端的第1个包），seq = y 表示Server 自己的初始序号（seq=0就代表这是服务器这边发出的第0号包）。这时服务器进入syn_rcvd，表示服务器已经收到Client的连接请求，等待client的确认。

3） Client收到确认后还需再次发送确认，同时携带要发送给Server的数据。ACK 置1 表示确认号ack= y + 1 有效（代表期望收到服务器的第1个包），Client自己的序号seq= x + 1（表示这就是我的第1个包，相对于第0个包来说的），一旦收到Client的确认之后，这个TCP连接就进入Established状态，就可以发起http请求了。

　　2个计算机通信是靠协议（目前流行的TCP/IP协议）来实现，如果2个计算机使用的协议不一样，那是不能进行通信的，所以这个3次握手就相当于试探一下对方是否遵循TCP/IP协议，协商完成后就可以进行通信了，当然这样理解不是那么准确。

3.建立TCP连接后发起http请求

　　进过TCP3次握手之后，浏览器发起了http的请求（看第包），使用的http的方法 GET 方法，请求的URL是 / ,协议是HTTP/1.0。

4.服务器端响应http请求，浏览器得到html代码

　　服务器端WEB程序接收到http请求以后，就开始处理该请求，处理之后就返回给浏览器html文件。

5. 浏览器解析html代码，并请求html代码中的资源

　　浏览器拿到index.html文件后，就开始解析其中的html代码，遇到js/css/image等静态资源时，就向服务器端去请求下载（会使用多线程下载，每个浏览器的线程数不一样），这个时候就用上keep-alive特性了，建立一次HTTP连接，可以请求多个资源，下载资源的顺序就是按照代码里的顺序，但是由于每个资源大小不一样，而浏览器又多线程请求请求资源，所以从下图看出，这里显示的顺序并不一定是代码里面的顺序。

6.浏览器对页面进行渲染呈现给用户

　　最后，浏览器利用自己内部的工作机制，把请求到的静态资源和html代码进行渲染，渲染之后呈现给用户。

4）协议格式

　　通常HTTP消息包括客户机向服务器的请求消息和服务器向客户机的响应消息。这两种类型的消息由一个起始行，一个或者多个头域，一个指示头域结束的空行和可选的消息体组成。HTTP的头域包括通用头，请求头，响应头和实体头四个部分。每个头域由一个域名，冒号（:）和域值三部分组成。

（1）通用头域

　　通用头域包含请求和响应消息都支持的头域，通用头域包含Cache-Control、Connection、Date、Pragma、Transfer-Encoding、Upgrade、Via。对通用头域的扩展要求通讯双方都支持此扩展，如果存在不支持的通用头域，一般将会作为实体头域处理。

（2）请求消息

1.Host头域

　　Host头域指定请求资源的Intenet主机和端口号，必须表示请求url的原始服务器或网关的位置。HTTP/1.1请求必须包含主机头域，否则系统会以400状态码返回。

2.Referer头域

　　Referer头域允许客户端指定请求uri的源资源地址，这可以允许服务器生成回退链表，可用来登陆、优化cache等。他也允许废除的或错误的连接由于维护的目的被追踪。如果请求的uri没有自己的uri地址，Referer不能被发送。如果指定的是部分uri地址，则此地址应该是一个相对地址。

3.Range头域

　　Range头域可以请求实体的一个或者多个子范围。例如，

表示头500个字节：bytes=0-499

表示第二个500字节：bytes=500-999

表示最后500个字节：bytes=-500

表示500字节以后的范围：bytes=500-

第一个和最后一个字节：bytes=0-0,-1

同时指定几个范围：bytes=500-600,601-999

　　但是服务器可以忽略此请求头，如果无条件GET包含Range请求头，响应会以状态码206（PartialContent）返回而不是以200（OK）。

4.User-Agent头域

　　User-Agent头域的内容包含发出请求的用户信息。

（3）响应消息

1.Location响应头

　　Location响应头用于重定向接收者到一个新URI地址。

2.Server响应头

　　Server响应头包含处理请求的原始服务器的软件信息。此域能包含多个产品标识和注释，产品标识一般按照重要性排序。

（4）实体信息

　　请求消息和响应消息都可以包含实体信息，实体信息一般由实体头域和实体组成。实体头域包含关于实体的原信息，实体头包括Allow、Content-Base、Content-Encoding、Content-Language、Content-Length、Content-Location、Content-MD5、Content-Range、Content-Type、Etag、Expires、Last-Modified、extension-header。

1.Content-Type实体头

　　Content-Type实体头用于向接收方指示实体的介质类型，指定HEAD方法送到接收方的实体介质类型，或GET方法发送的请求介质类型。

2.Content-Range实体头

　　Content-Range实体头用于指定整个实体中的一部分的插入位置，他也指示了整个实体的长度。在服务器向客户返回一个部分响应，它必须描述响应覆盖的范围和整个实体长度。一般格式：

Content-Range:bytes-unitSPfirst-byte-pos-last-byte-pos/entity-legth

　　例如，传送头500个字节次字段的形式：Content-Range:bytes0-499/1234如果一个http消息包含此节（例如，对范围请求的响应或对一系列范围的重叠请求），Content-Range表示传送的范围，Content-Length表示实际传送的字节数。

3.Last-modified实体头

　　Last-modified实体头指定服务器上保存内容的最后修订时间。

3 HTTPS

　　HTTPS（全称：Hypertext Transfer Protocol over Secure Socket Layer），是以安全为目标的HTTP通道，简单讲是HTTP的安全版。即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容请看SSL。

1）实现原理

　　有两种基本的加解密算法类型：

　　（1）对称加密：密钥只有一个，加密解密为同一个密码，且加解密速度快，典型的对称加密算法有DES、AES等；

　　（2）非对称加密：密钥成对出现（且根据公钥无法推知私钥，根据私钥也无法推知公钥），加密解密使用不同密钥（公钥加密需要私钥解密，私钥加密需要公钥解密），相对对称加密速度较慢，典型的非对称加密算法有RSA、DSA等。下面看一下https的通信过程：

2）HTTPS解决的问题：

1 . 信任主机的问题。

　　采用https 的server 必须从CA 申请一个用于证明服务器用途类型的证书。该证书只有用于对应的server 的时候,客户度才信任次主机。所以目前所有的银行系统网站,关键部分应用都是https 的。客户通过信任该证书,从而信任了该主机。其实这样做效率很低,但是银行更侧重安全。这一点对我们没有任何意义,我们的server ,采用的证书不管自己issue 还是从公众的地方issue, 客户端都是自己人,所以我们也就肯定信任该server。

2 . 通讯过程中的数据的泄密和被窜改

　　1. 一般意义上的https, 就是 server 有一个证书。

　　 a) 主要目的是保证server 就是他声称的server。这个跟第一点一样。

　　 b) 服务端和客户端之间的所有通讯,都是加密的。

　　　　i. 具体讲,是客户端产生一个对称的密钥,通过server 的证书来交换密钥。一般意义上的握手过程。

　　　　ii. 加下来所有的信息往来就都是加密的。第三方即使截获,也没有任何意义。因为他没有密钥。当然窜改也就没有什么意义了。

　　2. 少许对客户端有要求的情况下,会要求客户端也必须有一个证书。

　　 a) 这里客户端证书,其实就类似表示个人信息的时候,除了用户名/密码, 还有一个CA 认证过的身份。应为个人证书一般来说上别人无法模拟的,所有这样能够更深的确认自己的身份。

　　b) 目前少数个人银行的专业版是这种做法,具体证书可能是拿U盘作为一个备份的载体。

　　HTTPS 一定是繁琐的：

　　a) 本来简单的http协议,一个get一个response。由于https 要还密钥和确认加密算法的需要。单握手就需要6/7 个往返。任何应用中,过多的round trip 肯定影响性能。

　　 b) 接下来才是具体的http协议,每一次响应或者请求, 都要求客户端和服务端对会话的内容做加密/解密。

　　　　 i. 尽管对称加密/解密效率比较高,可是仍然要消耗过多的CPU,为此有专门的SSL 芯片。如果CPU 信能比较低的话,肯定会降低性能,从而不能serve 更多的请求。

　　　　 ii. 加密后数据量的影响。所以，才会出现那么多的安全认证提示。

3）HTTPS和HTTP的区别

　　1.http和https使用的是完全不同的连接方式,用的端口也不一样,前者是80,后者是443。

　　2.https协议需要到ca申请证书，一般免费证书很少，需要交费。

　　3.http是超文本传输协议，信息是明文传输，https 则是具有安全性的ssl加密传输协议。

　　4.http的连接很简单,是无状态的，而HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全。

4 RTSP协议与HTTP协议的联系与区别

　　RTSP协议负责在服务器和客户端之间建立并控制一个或多个时间上同步的连续流媒体，其目标是像HTTP协议为用户提供文字和图形服务那样为用户提供连续媒体服务。因此，RTSP协议的设计在语法和操作上与HTTP协议很相似，这样，对于HTTP的大部分扩展也适用于RTSP。　　　　

　　但是RTSP协议和HTTP协议在很多方面有着区别：　　

　　1. HTTP是一个无状态协议，而RTSP协议是有状态的。　　

　　2.HTTP本质上是一个非对称协议，客户端提出请求而服务器响应；而RTSP是对称的，服务器和客户端都可发送和响应请求。

5 SDP协议

　　SDP会话描述协议：为会话通知、会话邀请和其它形式的多媒体会话初始化等目的提供了多媒体会话描述。会话目录用于协助多媒体会议的通告，并为会话参与者传送相关设置信息。 SDP 即用于将这种信息传输到接收端。 SDP 完全是一种会话描述格式――它不属于传输协议 ――它只使用不同的适当的传输协议，包括会话通知协议（SAP）、会话初始协议（SIP）、实时流协议（RTSP）、 MIME 扩展协议的电子邮件以及超文本传输协议（HTTP）。SDP 的设计宗旨是通用性，它可以应用于大范围的网络环境和应用程序，而不仅仅局限于组播会话目录。

　　SDP是会话描述协议的缩写，是描述流媒体初始化参数的格式，由IETF作为RFC 4566颁布。

发表于 2017-07-10 20:02 hecheng2009 阅读(2036) 评论(0) 编辑收藏举报

会员力量，点亮园子希望

刷新页面返回顶部

流媒体传输协议

公告