[计算机网络]IP、UDP、TCP和HTTP报文格式总结

OSI七层参考模型：

详细OSI七层参考模型解析博客

报文封装过程

物理层、数据链路层、网络层代表设备

物理层：网卡，网线，集线器，中继器，调制解调器

数据链路层：网桥，交换机

网络层：路由器

网关工作在第四层传输层及其以上

集线器是物理层设备,采用广播的形式来传输信息。

交换机就是用来进行报文交换的机器。多为链路层设备(二层交换机)，能够进行地址学习，采用存储转发的形式来交换报文.。

路由器的一个作用是连通不同的网络，另一个作用是选择信息传送的线路。选择通畅快捷的近路，能大大提高通信速度，减轻网络系统通信负荷，节约网络系统资源，提高网络系统畅通率。

交换机和路由器的区别

交换机拥有一条很高带宽的背部总线和内部交换矩阵。交换机的所有的端口都挂接在这条总线上，控制电路收到数据包以后，处理端口会查找内存中的地址对照表以确定目的MAC（网卡的硬件地址）的NIC（网卡）挂接在哪个端口上，通过内部交换矩阵迅速将数据包传送到目的端口，目的MAC若不存在则广播到所有的端口，接收端口回应后交换机会“学习”新的地址，并把它添加入内部MAC地址表中。
使用交换机也可以把网络“分段”，通过对照MAC地址表，交换机只允许必要的网络流量通过交换机。通过交换机的过滤和转发，可以有效的隔离广播风暴，减少误包和错包的出现，避免共享冲突。
交换机在同一时刻可进行多个端口对之间的数据传输。每一端口都可视为独立的网段，连接在其上的网络设备独自享有全部的带宽，无须同其他设备竞争使用。当节点A向节点D发送数据时，节点B可同时向节点C发送数据，而且这两个传输都享有网络的全部带宽，都有着自己的虚拟连接。假使这里使用的是10Mbps的以太网交换机，那么该交换机这时的总流通量就等于2×10Mbps＝20Mbps，而使用10Mbps的共享式HUB时，一个HUB的总流通量也不会超出10Mbps。
总之，交换机是一种基于MAC地址识别，能完成封装转发数据包功能的网络设备。交换机可以“学习”MAC地址，并把其存放在内部地址表中，通过在数据帧的始发者和目标接收者之间建立临时的交换路径，使数据帧直接由源地址到达目的地址。

路由器的作用与交换机和网桥非常相似。但是与工作在网络物理层，从物理上划分网段的交换机不同，路由器使用专门的软件协议从逻辑上对整个网络进行划分。例如，一台支持IP协议的路由器可以把网络划分成多个子网段，只有指向特殊IP地址的网络流量才可以通过路由器。对于每一个接收到的数据包，路由器都会重新计算其校验值，并写入新的物理地址。因此，使用路由器转发和过滤数据的速度往往要比只查看数据包物理地址的交换机慢。但是，对于那些结构复杂的网络，使用路由器可以提高网络的整体效率。路由器的另外一个明显优势就是可以自动过滤网络广播。

集线器与路由器在功能上有什么不同?

首先说HUB,也就是集线器。它的作用可以简单的理解为将一些机器连接起来组成一个局域网。而交换机（又名交换式集线器）作用与集线器大体相同。但是两者在性能上有区别：集线器采用的式共享带宽的工作方式，而交换机是独享带宽。这样在机器很多或数据量很大时，两者将会有比较明显的。而路由器与以上两者有明显区别，它的作用在于连接不同的网段并且找到网络中数据传输最合适的路径。路由器是产生于交换机之后，就像交换机产生于集线器之后，所以路由器与交换机也有一定联系，不是完全独立的两种设备。路由器主要克服了交换机不能路由转发数据包的不足。

IP

IP数据报格式

IP数据报分为两个部分，首部和数据部分（TCP、UDP），首部分为固定部分和可变部分。

IPv4

IPv4分类地址

特殊IP地址

IPv6

IPv6数据报格式


IPv4与 IPv6区别

TCP

UDP

UDP首部格式

UDP实现可靠传输

三种使用UDP进行可靠数据传输的协议
RUDP、RTP、UDT

RUDP（Reliable User Datagram Protocol）

可靠用户数据报协议（RUDP）是一种基于可靠数据协议（RDP： RFC908 和 1151 （第二版））的简单分组传输协议。作为一个可靠传输协议，RUDP 用于传输 IP 网络间的电话信号。它允许独立配置每个连接属性，这样在不同的平台可以同时实施不同传输需求下的协议。

RUDP 提供一组数据服务质量增强机制，如拥塞控制的改进、重发机制及淡化服务器算法等，从而在包丢失和网络拥塞的情况下， RTP 客户机（实时位置）面前呈现的就是一个高质量的 RTP 流。在不干扰协议的实时特性的同时，可靠 UDP 的拥塞控制机制允许 TCP 方式下的流控制行为。

为了与网络 TCP 通信量同时工作， RUDP 使用类似于 TCP 的重发机制和拥塞控制算法。在最大化利用可用带宽上，这些算法都得到了很好的证明。
RUDP特性

客户机确认响应服务器发送给客户机的包；

视窗和拥塞控制，服务器不能超出当前允许带宽；
一旦发生包丢失，服务器重发给客户机；
比实时流更快速，称为“缓存溢出”。
用户数据报协议（UDP）

RTP（Real Time Protocol）

RTP，实时协议被用来为应用程序如音频，视频等的实时数据的传输提供端到端（end to end）的网络传输功能。传输的模型可以是单点传送或是多点传送。数据传输被一个姐妹协议——实时控制协议（RTCP）来监控，后者允许在一个大的多点传送网络上监视数据传送，并且提供最小限度的控制和识别功能。

RTP是被IETF在RFC1889中提出来的。顺带提及，RTP已经被接受为实时多媒体传送的通用标准。ITU-T跟IETF都在各自的系统中将这一协议标准化。

1.1 为何需要RTP?

TCP不能支持像交互视频，会议等的实时服务，这一原因是由于TCP只是一个“慢”协议，需要三次握手。就此在IP层上UDP是一个比TCP更好的选择。但是UDP是本质上是一个不可靠协议，不支持在包丢情况下的重传机制。诚然，UDP有一些特性，比如多路复用跟校验和服务，这些都是对实时服务很有利的。为了消除UDP的缺点，RTP是作为应用层而被提出来的。

RTP提供的各种服务包括有效负载识别，序列编号，时间戳和投递监听。RTP能够序列化包，当这些包在收端不是按顺序到达的时。序列号也能被用来识别包丢失。时间戳被用于媒体有效的播放。到达的数据一直被RTCP监听，以通知RTP层来校正其编码和传输的参数。例如，如果RTCP层检测到包丢失，它会通知RTP层减缓发送速率。

尽管RTP有助于实时媒体的有效的播放 ，但是要注意的是RTP自身并不提供任何机制来确保及时传递或提供其他服务质量（QoS）的保证，而是依靠低层服务来完成这些。同样，RTP也不保证投递或防止无序投递。RTP被设计出来主要是为了满足有多个参加者的多媒体会议的需要。RTP也同样适合于象持续数据的储存，分布式交互仿真，主动标记以及应用程序的控制和测量。

1.2 RTP特性一览

RTP提供有效负荷类型识别，乱序重排和利用时间戳的媒体有效播放。

RTCP监控服务质量，也提供在一个当前进行的会话中传送关于参加者的信息作用。

RTP对于下层协议是独立的，它能够工作在像TCP/IP，ATM，帧时延等类型的网络上。

如果被下层网络支持，RTP支持利用多路技术的对于多点的数据传输。

RTP序列号也能被用来确定包的合适位置。例如在视频解码，包无需按序解码。

UDT（UDP-based Data Transfer Protocol）

基于UDP的数据传输协议（UDP-based Data Transfer Protocol，简称UDT）是一种互联网数据传输协议。UDT的主要目的是支持高速广域网上的海量数据传输，而互联网上的标准数据传输协议TCP在高带宽长距离网络上性能很差。 顾名思义，UDT建于UDP之上，并引入新的拥塞控制和数据可靠性控制机制。UDT是面向连接的双向的应用层协议。它同时支持可靠的数据流传输和部分可靠的数据报传输。 由于UDT完全在UDP上实现，它也可以应用在除了高速数据传输之外的其它应用领域，例如点到点技术（P2P），防火墙穿透，多媒体数据传输等等。

UDT是双工的，每个UDT实体有两个部分：发送和接收。发送者根据流量控制和速率控制来发送（和重传）应用程式数据。接收者接收数据包和控制包，并根据接收到的包发送控制包。发送和接收程式共享同一个UDP端口来发送和接收。
接收者也负责触发和处理任何的控制事件，包括拥塞控制和可靠性控制和他们的相对机制，例如RTT估计、带宽估计、应答和重传。
UDT总是试着将应用层数据打包成固定的大小，除非数据不够这么大。和TCP相似的是，这个固定的包大小叫做MSS（最大包大小）。由于期望UDT用来传输大块数据流，我们假定只有很小的一部分不规则的大小的包在UDT session中。MSS能够通过应用程式来安装，MTU是其最优值（包括任何包头）。
UDT拥塞控制算法将速率控制和窗口（流量控制）合并起来，前者调整包的发送周期，后者限制最大的位被应答的包。在速率控制中使用的参数通过带宽估计技术来更新，他继承来自基于接收的包方法。同时，速率控制周期是估计RTT的常量，流控制参数依赖于对方的数据到达速度，另外接收端释放的缓冲区的大小。

UDP构建可靠数据传输
简单来讲，要使用UDP来构建可靠的面向连接的数据传输，就要实现类似于TCP协议的超时重传，有序接受，应答确认，滑动窗口流量控制等机制，等于说要在传输层的上一层（或者直接在应用层）实现TCP协议的可靠数据传输机制，比如使用UDP数据包+序列号，UDP数据包+时间戳等方法，在服务器端进行应答确认机制，这样就会保证不可靠的UDP协议进行可靠的数据传输。

HTTP

浏览器输入一个URL后的过程

当我们在浏览器中输入一个网址，比如www.google.cn，浏览器就会加载出百度的主页。那么浏览器背后完成的具体是怎么样的呢？
总结起来大概的流程是这样的：
（1）浏览器本身是一个客户端，当你输入URL的时候，首先浏览器会去请求DNS服务器，通过DNS获取相应的域名对应的IP
（2）然后通过IP地址找到IP对应的服务器后，要求建立TCP连接
（3）浏览器发送完HTTP Request（请求）包后，服务器接收到请求包之后才开始处理请求包
（4）在服务器收到请求之后，服务器调用自身服务，返回HTTP Response（响应）包
（5）客户端收到来自服务器的响应后开始渲染这个Response包里的主体（body），等收到全部的内容随后断开与该服务器之间的TCP

浏览器输入url访问的过程

前言

当我们在浏览器中输入一个网址，比如www.google.cn，浏览器就会加载出百度的主页。那么浏览器背后完成的具体是怎么样的呢？
总结起来大概的流程是这样的：
（1）浏览器本身是一个客户端，当你输入URL的时候，首先浏览器会去请求DNS服务器，通过DNS获取相应的域名对应的IP
（2）然后通过IP地址找到IP对应的服务器后，要求建立TCP连接
（3）浏览器发送完HTTP Request（请求）包后，服务器接收到请求包之后才开始处理请求包
（4）在服务器收到请求之后，服务器调用自身服务，返回HTTP Response（响应）包
（5）客户端收到来自服务器的响应后开始渲染这个Response包里的主体（body），等收到全部的内容随后断开与该服务器之间的TCP连接。
就可以用下面的这幅图来进行解释

1. DNS解析

在浏览器中输入的是一个网址，是不能直接用来进行连接的，因而就要使用DNS地址解析将输入的URL网址转换为IP地址。查找的流程图是这样的

具体的查找过程和策略可以分为下面这几步：
（1）在浏览器中输入www.google.cn域名，操作系统会先检查自己本地的hosts文件是否有这个网址映射关系，如果有，就先调用这个IP地址映射，完成域名解析。
（2）如果hosts里没有这个域名的映射，则查找本地DNS解析器缓存，是否有这个网址映射关系，如果有，直接返回，完成域名解析。
（3）如果hosts与本地DNS解析器缓存都没有相应的网址映射关系，首先会找TCP/IP参数中设置的首选DNS服务器，在此我们叫它本地DNS服务器，此服务器收到查询时，如果要查询的域名，包含在本地配置区域资源中，则返回解析结果给客户机，完成域名解析，此解析具有权威性。
（4）如果要查询的域名，不由本地DNS服务器区域解析，但该服务器已缓存了此网址映射关系，则调用这个IP地址映射，完成域名解析，此解析不具有权威性。
（5）如果本地DNS服务器本地区域文件与缓存解析都失效，则根据本地DNS服务器的设置（是否设置转发器）进行查询，如果未用转发模式，本地DNS就把请求发至13台根DNS，根DNS服务器收到请求后会判断这个域名(.com)是谁来授权管理，并会返回一个负责该顶级域名服务器的一个IP。本地DNS服务器收到IP信息后，将会联系负责.com域的这台服务器。这台负责.com域的服务器收到请求后，如果自己无法解析，它就会找一个管理.com域的下一级DNS服务器地址(google.com)给本地DNS服务器。当本地DNS服务器收到这个地址后，就会找google.com域服务器，重复上面的动作，进行查询，直至找到www.google.com主机。
（6）如果用的是转发模式，此DNS服务器就会把请求转发至上一级DNS服务器，由上一级服务器进行解析，上一级服务器如果不能解析，或找根DNS或把转请求转至上上级，以此循环。不管是本地DNS服务器用是是转发，还是根提示，最后都是把结果返回给本地DNS服务器，由此DNS服务器再返回给客户机。

2. Socket建立连接

当我们输入这样一个请求时，首先要建立一个socket连接，因为socket是通过ip和端口建立的，所以之前还有一个DNS解析过程，把www.google.com变成ip，如果url里不包含端口号，则会使用该协议的默认端口号。

3. 发送HTTP请求

连接成功建立后，开始向web服务器发送请求，当浏览器向Web服务器发出请求时，它向服务器传递了一个数据块，也就是请求信息，HTTP请求信息由3部分组成：
（1）请求方法URI协议/版本
（2）请求头(Request Header)
（3）请求正文
下面是一个HTTP请求的例子：

1. GET /sample.jsp HTTP/1.1
2. Accept:image/gif.image/jpeg,*/*
3. Accept-Language:zh-cn
4. Connection:Keep-Alive
5. Host:localhost
6. User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)
7. Accept-Encoding:gzip,deflate
8. username=jinqiao&password=1234

3.1 请求方法URI协议/版本

请求的第一行是“方法URL议/版本”：GET/sample.jsp HTTP/1.1``
以上代码中“GET”代表请求方法，/sample.jsp表示URI，HTTP/1.1“`代表协议和协议的版本。
根据HTTP标准，HTTP请求可以使用多种请求方法。例如：HTTP1.1支持7种请求方法：GET、POST、HEAD、OPTIONS、PUT、DELETE和TARCE。在Internet应用中，最常用的方法是GET和POST。
URL完整地指定了要访问的网络资源，通常只要给出相对于服务器的根目录的相对目录即可，因此总是以“/”开头，最后，协议版本声明了通信过程中使用HTTP的版本。

3.2 请求头(Request Header)

请求头包含许多有关的客户端环境和请求正文的有用信息。例如，请求头可以声明浏览器所用的语言，请求正文的长度等。

1. Accept:image/gif.image/jpeg.*/*
2. Accept-Language:zh-cn
3. Connection:Keep-Alive
4. Host:localhost
5. User-Agent:Mozila/4.0(compatible:MSIE5.01:Windows NT5.0)
6. Accept-Encoding:gzip,deflate.

3.3 请求正文

请求头和请求正文之间是一个空行，这个行非常重要，它表示请求头已经结束，接下来的是请求正文。请求正文中可以包含客户提交的查询字符串信息：

username=jinqiao&password=1234

•  

在以上的例子的HTTP请求中，请求的正文只有一行内容。当然，在实际应用中，HTTP请求正文可以包含更多的内容。

3.4 HTTP请求方法：GET方法与POST方法

3.4.1 GET方法

GET方法是默认的HTTP请求方法，我们日常用GET方法来提交表单数据，然而用GET方法提交的表单数据只经过了简单的编码，同时它将作为URL的一部分向Web服务器发送，因此，如果使用GET方法来提交表单数据就存在着安全隐患上。例如
Http://127.0.0.1/login.jsp?Name=zhangshi&Age=30&Submit=%cc%E+%BD%BB
从上面的URL请求中，很容易就可以辩认出表单提交的内容。（？之后的内容）另外由于GET方法提交的数据是作为URL请求的一部分所以提交的数据量不能太大

3.4.2 POST方法

POST方法是GET方法的一个替代方法，它主要是向Web服务器提交表单数据，尤其是大批量的数据。POST方法克服了GET方法的一些缺点。通过POST方法提交表单数据时，数据不是作为URL请求的一部分而是作为标准数据传送给Web服务器，这就克服了GET方法中的信息无法保密和数据量太小的缺点。因此，出于安全的考虑以及对用户隐私的尊重，通常表单提交时采用POST方法。

3.5 各种HTTP请求的含义

GET
通过请求URI得到资源
POST
用于添加新的内容
PUT
用于修改某个内容
DELETE
删除某个内容
CONNECT
用于代理进行传输，如使用SSL
OPTIONS
询问可以执行哪些方法
PATCH
部分文档更改
PROPFIND
查看属性
PROPPATCH
设置属性
MKCOL
创建集合（文件夹）
COPY
拷贝
MOVE
移动
LOCK
加锁
UNLOCK
解锁
TRACE
用于远程诊断服务器
HEAD
类似于GET, 但是不返回body信息，用于检查对象是否存在，以及得到对象的元数据

4. 服务器响应

应答 web服务器收到这个请求，进行处理。从它的文档空间中搜索子目录mydir的文件index.html。如果找到该文件，Web服务器把该文件内容传送给相应的Web浏览器。为了告知浏览器，Web服务器首先传送一些HTTP头信息，然后传送具体内容（即HTTP体信息），HTTP头信息和HTTP体信息之间用一个空行分开。

4.1 HTTP响应报文头

HTTP应答与HTTP请求相似，HTTP响应也由3个部分构成，分别是：
（1）协议状态版本代码描述
（2）响应头(Response Header)
（3）响应正文
下面是一个HTTP响应的例子：

1. HTTP/1.1 200 OK
2. Server:Apache Tomcat/5.0.12
3. Date:Mon,6Oct2003 13:23:42 GMT
4. Content-Length:112
5.  
6. <html>
7. <head>
8. <title>HTTP响应示例<title>
9. </head>
10. <body>
11. Hello HTTP!
12. </body>
13. </html>

协议状态代码描述HTTP响应的第一行类似于HTTP请求的第一行，它表示通信所用的协议是HTTP1.1服务器已经成功的处理了客户端发出的请求（200表示成功）:
HTTP/1.1 200 OK
响应头(Response Header)响应头也和请求头一样包含许多有用的信息，例如服务器类型、日期时间、内容类型和长度等：

1. Server:Apache Tomcat/5.0.12
2. Date:Mon,6Oct2003 13:13:33 GMT
3. Content-Type:text/html
4. Last-Moified:Mon,6 Oct 2003 13:23:42 GMT
5. Content-Length:112

响应正文响应正文就是服务器返回的HTML页面：

1. <html>
2. <head>
3. <title>HTTP响应示例<title>
4. </head>
5. <body>
6. Hello HTTP!
7. </body>
8. </html>

响应头和正文之间也必须用空行分隔。

4.2 HTTP应答码

HTTP应答码也称为状态码，它反映了Web服务器处理HTTP请求状态。HTTP应答码由3位数字构成，其中首位数字定义了应答码的类型：
1XX－信息类(Information),表示收到Web浏览器请求，正在进一步的处理中
2XX－成功类（Successful）,表示用户请求被正确接收，理解和处理例如：200 OK
3XX - 重定向类(Redirection),表示请求没有成功，客户必须采取进一步的动作。
4XX - 客户端错误(Client Error)，表示客户端提交的请求有错误 例如：404 NOT Found，意味着请求中所引用的文档不存在。
5XX - 服务器错误(Server Error)表示服务器不能完成对请求的处理：如 500
对于我们Web开发人员来说掌握HTTP应答码有助于提高Web应用程序调试的效率和准确性。

5. 关闭连接

当应答结束后，Web浏览器与Web服务器必须断开，以保证其它Web浏览器能够与Web服务器建立连接。

 

[计算机网络]TCP三次握手、四次挥手

TCP三次握手可以形象的用下图中的例子来说明

三次握手：

四次挥手：

SDP: Session Description Protocol(会话描述协议)

  SDP: Session Description Protocol(会话描述协议)

(RFC2327)

1.       概述

SDP也是MMUSIC工作组的一个产品,在MBONE内容中用得很多。其目的就是在媒体会话中，传递媒体流信息，允许会话描述的接收者去参与会话。SDP基本上在internet上工作。他定义了绘画描述的统一格式,但并不定义多播地址的分配和SDP消息的传输,也不支持媒体编码方案的协商,这些功能均由下层传送协议完成.典型的会话传送协议包括:SAP(Session Announcement Protocol 会话公告协议),SIP,RTSP,HTTP,和使用MIME的E-Mail.(注意:对SAP只能包含一个会话描述,其它会话传诵协议的SDP可包含多个绘画描述)

SDP包括以下一些方面：

1）会话的名称和目的

2）会话存活时间

3）包含在会话中的媒体信息，包括：

媒体类型(video, audio, etc)

传输协议(RTP/UDP/IP, H.320, etc)

媒体格式(H.261 video, MPEG video, etc)

多播或远端（单播）地址和端口

4）为接收媒体而需的信息(addresses, ports, formats and so on)

5）使用的带宽信息

6）可信赖的接洽信息（Contact information）

 

2.       协议

Session description                                                   //格式及举例

v= (protocol version)                               //v=0

        o= (owner/creator and session identifier).   //o=<用户名><会话id><版本><网络类

//型><地址类型><地址>

//o=sname 1234567890 0987654321 IN

//IP4 126.15.64.3

        s= (session name)                                          //会话名

        i=* (session information)                                   //会话信息

        u=* (URI of description)                                   //u=http://www.zte.com.cn/staff/sdp.ps

        e=* (email address)                                          //e=zte@isi.edu(general text如：王生)

                                                                             //或e=Mr. Wang<wang@zte.com>

        p=* (phone number)                                  //p=+86-0755-26773000-7110(wang)

                                                                             //or p=+1 617 253 6011

        c=* (connection information -如已经包含在所有媒体中则该行不需要)

                                                                             //c=<网络类型><地址信息><连接地址>

                                                                             //多点会议包括TTL

                                                                             //连接地址: <base multicast

//address>/<ttl>/<number of addresses>

                                                                             //c=IN IP4 224.2.13.23/127

                                                                             //c=IN IP4 224.2.1.1/127/3

        b=* (bandwidth information)                      //b=<修改量（CT Conference Total

//IAS Application-specific Max)>:<带宽

//值（kb/s）>

//b=CT:120

One or more time descriptions (see below)

        z=* (time zone adjustments)                       //时区调整

        k=* (encryption key)                                 //k=<方法>:<密钥>或k=<方法>

        a=* (zero or more session attribute lines)     //a=<属性> 或a=<属性>:<值>

Zero or more media descriptions (see below)      

 

各行严格按顺序,其中:

时间描述：

        t= (time the session is active)                   //<开始时间><结束时间>，单位秒，十

//进制NTP

//t=2873397468 2873404969

        r=* (zero or more repeat times)                  //<重复时间><活动持续时间

//以开始时刻为参考的偏移列表>单位秒

//r=604800 3666 90000     或写成

//r=7d 1h 0 25h

媒体描述：

        m= (media name and transport address)    //m=<媒体><端口><传送><格式列表>

                                                                             //m=audio 49170 RTP/AVP 0 3

                                                                             //协议为RTP，剖面为AVP

                                                                             //参考rtp-parameters.txt

        i=* (media title媒体称呼)                           //

        c=* (connection information – 如已经包含在会话级描述则为可选)

        b=* (bandwidth information)                      //同c

        k=* (encryption key)                                 //会话级为摸认值,同c

        a=* (zero or more media attribute lines)              //两种形式：(也同c)（见后说明）

                                                                             //a=<attribute>如：

                                                                             //     a=recvonly

                                                                             //a=<attribute>:<value>

 

注： v,o,s,t,m 为必须的 , 其他项为可选。

         如果 SDP 语法分析器不能识别某一类型 (Type), 则整个描述丢失 ;

         如果 ”a=” 的某属性值不理解 , 则予以丢失

         整个协议区分大小写

         “=” 两侧不允许有空格

         会话级的描述就是媒体级描述的缺省值

         所有均格式为 <type>=<value>

 

 

 

3.       SDP 在 IP 电话中的使用

SDP用于构建INVITE和200 OK响应消息的消息体,供主/被叫用户交换媒体信息.

1.       媒体流的配置

1)      主被叫的媒体描述必须完全对应:主被叫的第n个媒体流(“m=”)对应,都包含”a=rtpmap”.这样的目的是易于适应静态净荷类型到动态净荷类型的转换.

2)      如被叫不想接收主叫提出的某个媒体流则在响应中设置该媒体流的端口号为0.并且,必须返回对应的媒体流行.

2.       单播SDP值的设定

1)      对于只发媒体流,端口号无意义,应设为0.

2)      每个媒体流的净载荷类型例表应传送两个信息:能接受/发送的编译码,和用以标识这些编译码的RTP净载荷类型号.

3)      如对于某一媒体流,主/被叫没有公共的媒体格式,被叫仍然要求返回媒体流的”m=”行,端口好为0,同时,不列净载荷类型.

4)      如果所有媒体流均无公共的媒体格式,则被叫回送400响应(坏请求),并加入304警告头字段(无媒体类型)

3.       多播操作

1)      接受和发送的多播地址是相同的

2)      被叫不允许改变媒体流的只发,只收,或收/发特性

3)      如果被叫不支持多播,则回送400响应和330警告(多播不可用)

4.       延时媒体流

由于主叫可能实际上是一个和其他协议(如H.323)互同的协议的网关,与S其互同的协议要求呼叫建立后进行媒体协商.这样,主叫可以先发不带SDP的INVITE,呼叫建立后可以通过ACK或重新发一个INVITE请求修改被叫的会话描述(SDP).

5.       媒体流保持

如果要求对方进入HOLD,即暂时停止发送一个或多个媒体流,这可以用Re-INVITE,其会话描述和原来的请求或响应中的描述相同,只是,”c=”行中的保持媒体流的地址置为”0.0.0.0”,还有就是Re_INVITE中的Cseq得递增.

6.       对应于SIP中有3个实体字段:

1)      Content-Type: 指明消息体类型,有两种:

                         i.              Application/sdp:表示是SDP会话描述

                       ii.              Text/html:表示是普通文本或HTML格式的描述

2)      Content-Encoding:补充说明消息体类型,使用户可以采用压缩编码编辑消息体

3)      Content-Length:给出消息体的字节数

7.       SDP 各 type 的详细解释 :

协议版本 o= SDP版本目前为0,没有子版本

会话源    v= <用户名>用户在发起主机上登录名,如果主机不支持用户标识的概念,则为”-”

<会话id>一般为数字串,其分配由创建工具决定,建议用网络时间协议(NTP)时

戳,以确保唯一性.

<版本>该会话公告的版本,供公告代理服务器检测同一会话的若干个公告哪个

是最新公告.基本要求是会话数据修改后该版本值递增,建议用NTP时戳

<网络类型>为文本串”IN”

<地址类型>”IP4”(可为域名或点分十进制)/”IP6”(域名或压缩文本地址形式)

<地址>

会话名    s=       ISO 10646字符表示的会话名

会话信息 v=        ISO 10646字符表示的会话信息

URI       u= 能提供会议进一步信息的URI地址

E妹地址 e=给出会议负责人的联系信息,他不一定是创建会议公告的人

电话号码 p=        给出会议负责人的联系信息,他不一定是创建会议公告的人(国际通用形式)

连接数据 c=媒体连接数据，会话级为媒体级的摸认值

带宽       b=       给出会话或媒体所用带宽，单位为kbit/s.修饰语：CT(会议总带宽，表示所有

地点所有媒体的总带宽)，AS(应用特定最大带宽，表示一个地点单一媒体带宽)

时间描述 t=见上

               r=       见上

时区调整 z=        见上

加密密钥         k=已定义的方法有

                   k=clear:<加密密钥>密钥没有变换

                     k=base64:<编码密钥>已编码，因为它含有SDP禁用的字符

                     k=uri:<获得密钥的URI>

                     k=prompt。SDP没有提供密钥但该会话或媒体流是要求加密的。

属性                a=一个m=行可有多个a=行，SDP建议扩展如下：(具体见[1].Page419)

                     会话级：        a=cat:<类别>//给出点分层次式会话分类号,供接收方筛选会话

                                   a=keywds:<关键词>//供接收方筛选会话

                                   a=tool:<工具名和版本号>//创建会话描述的工具名和版本号

a=recvonly/sendrecv/sendonly//收发模式

a=type:<会议类型>//有:广播,聚会,主席主持,测试,H.323

a=charset:<字符集>//显示会话名和信息数据的字符集

a=sdplang:<语言标记>//描述所有语言

a=lang:<语言标记>//会话描述的缺省语言或媒体描述的语言

a=framerate:<帧速率>//单位:帧/秒

a=quality:<质量>//视频的建议质量(10/5/0)

a=fmtp:<格式>< 格式特定参数>//定义指定格式的附加参数

                     媒体级：a=ptime:<分组时间>//媒体分组的时长(单位:秒)

a=recvonly/sendrecv/sendonly//收发模式

a=orient:<白板方向>//指明白板在屏莫上的方向

a=sdplang:<语言标记>//描述所有语言

a=lang:<语言标记>//会话描述的缺省语言或媒体描述的语言

媒体描述        m= <媒体>有5种类型：音频/视频/应用(如白板信息)/数据(不向用户显示的)/控制

<端口>媒体流发往传输层的端口。取决于c=行规定的网络类型和接下来的传

送层协议：对UDP为1024-65535；对分层编码应用（c=行没有多播地址），

要给出多播端口数，如：m=video 49170/2 RTP/AVP 31（表示：端口49170

和49171为第一对RTP/RTCP端口，49172和49173为第二对的端口）。

<传送层协议>与c=行的地址类型有关。对大多的媒体在RTP/UDP上传送，定

义2种：RTP/AVP：IETF RTP协议，音/视频应用文档。在UDP上传诵。

              Udp：UDP协议。

<格式列表>对音/视频，就是音/视频应用文档中规定媒体净荷类型。列表中都

有可能用，但第一个为缺省值，分为静态绑定和动态绑定：静态绑定即使媒体编码方式有净荷类型号完全确定，动态绑定则媒体编码方式（如时钟频率，音频信道数等）没有完全确定，需要进一步的属性说明。分别举例如下：

Alaw的PCM编码单信道Audio，其净荷类型号为8，把它发往UDP端口49232，则：m=audio 49232 RTP/AVP 8

16bit线性编码，双声道立体声，抽样速率16kHz，其动态净荷类型号98，则：m=audio 49232 RTP/AVP 98

       a=rtpmap:98 L16/16000/2

说明：1）a=rtpmap:<净荷类型号><编码名>/<时钟速率>[/<编码参数>]

               对音频，编码参数为音频信道数；对视频没有定义

2）SDP允许rtpmap规定实验性编码格式，但编码名必须以X-起，

表示此格式还没正式登记。

 

4.       SDP Grammar

   announcement =       proto-version

                         origin-field

                         session-name-field

                         information-field

                         uri-field

                         email-fields

                         phone-fields

                         connection-field

                         bandwidth-fields

                         time-fields

                         key-field

                         attribute-fields

                         media-descriptions

 

   proto-version =       "v=" 1*DIGIT CRLF

                         ;this memo describes version 0

   origin-field =        "o=" username space

                         sess-id space sess-version space

                         nettype space addrtype space

                         addr CRLF

   session-name-field = "s=" text CRLF

   information-field =   ["i=" text CRLF]

   uri-field =           ["u=" uri CRLF]

   email-fields =        *("e=" email-address CRLF)

   phone-fields =        *("p=" phone-number CRLF)

   connection-field =    ["c=" nettype space addrtype space

                         connection-address CRLF]

                         ;a connection field must be present

                         ;in every media description or at the

                         ;session-level

   bandwidth-fields =    *("b=" bwtype ":" bandwidth CRLF)

   time-fields =         1*( "t=" start-time space stop-time

                         *(CRLF repeat-fields) CRLF)

                         [zone-adjustments CRLF]

   repeat-fields =       "r=" repeat-interval space typed-time

                         1*(space typed-time)

   zone-adjustments =    time space ["-"] typed-time

                         *(space time space ["-"] typed-time)

   key-field =           ["k=" key-type CRLF]

   key-type =            "prompt" |

                         "clear:" key-data |

                         "base64:" key-data |

                         "uri:" uri

   key-data =            email-safe | "~" | "

   attribute-fields =    *("a=" attribute CRLF)

   media-descriptions = *( media-field

                         information-field

                         *(connection-field)

                         bandwidth-fields

                         key-field

                         attribute-fields )

   media-field =         "m=" media space port ["/" integer]

                         space proto 1*(space fmt) CRLF

   media =               1*(alpha-numeric)

                         ;typically "audio", "video", "application"

                         ;or "data"

   fmt =                 1*(alpha-numeric)

                         ;typically an RTP payload type for audio

                         ;and video media

   proto =               1*(alpha-numeric)

                         ;typically "RTP/AVP" or "udp" for IP4

   port =                1*(DIGIT)

                         ;should in the range "1024" to "65535" inclusive

                         ;for UDP based media

   attribute =           (att-field ":" att-value) | att-field

   att-field =           1*(alpha-numeric)

   att-value =           byte-string

   sess-id =             1*(DIGIT)

                         ;should be unique for this originating username/host

   sess-version =        1*(DIGIT)

                         ;0 is a new session

   connection-address = multicast-address

                         | addr

   multicast-address =   3*(decimal-uchar ".") decimal-uchar "/" ttl

                         [ "/" integer ]

                         ;multicast addresses may be in the range

                         ;224.0.0.0 to 239.255.255.255

   ttl =                 decimal-uchar

   start-time =          time | "0"

   stop-time =           time | "0"

   time =                POS-DIGIT 9*(DIGIT)

                         ;sufficient for 2 more centuries

   repeat-interval =     typed-time

   typed-time =          1*(DIGIT) [fixed-len-time-unit]

   fixed-len-time-unit = "d" | "h" | "m" | "s"

   bwtype =              1*(alpha-numeric)

   bandwidth =           1*(DIGIT)

   username =            safe

                         ;pretty wide definition, but doesn't include space

   email-address =       email | email "(" email-safe ")" |

                         email-safe "<" email ">"

   email =               ;defined in RFC822

   uri=                  ;defined in RFC1630

   phone-number =        phone | phone "(" email-safe ")" |

                         email-safe "<" phone ">"

   phone =               "+" POS-DIGIT 1*(space | "-" | DIGIT)

                         ;there must be a space or hyphen between the

                         ;international code and the rest of the number.

   nettype =             "IN"

                         ;list to be extended

   addrtype =            "IP4" | "IP6"

                         ;list to be extended

   addr =                FQDN | unicast-address

   FQDN =                4*(alpha-numeric|"-"|".")

                         ;fully qualified domain name as specified in RFC1035

   unicast-address =     IP4-address | IP6-address

   IP4-address =         b1 "." decimal-uchar "." decimal-uchar "." b4

   b1 =                  decimal-uchar

                         ;less than "224"; not "0" or "127"

   b4 =                  decimal-uchar

                         ;not "0"

   IP6-address =         ;to be defined

   text =                byte-string

                         ;default is to interpret this as IS0-10646 UTF8

                         ;ISO 8859-1 requires a "a=charset:ISO-8859-1"

                         ;session-level attribute to be used

   byte-string =         1*(0x01..0x09|0x0b|0x0c|0x0e..0xff)

                         ;any byte except NUL, CR or LF

   decimal-uchar =       DIGIT

                         | POS-DIGIT DIGIT

                         | ("1" 2*(DIGIT))

                         | ("2" ("0"|"1"|"2"|"3"|"4") DIGIT)

                         | ("2" "5" ("0"|"1"|"2"|"3"|"4"|"5"))

   integer =             POS-DIGIT *(DIGIT)

   alpha-numeric =       ALPHA | DIGIT

   DIGIT =               "0" | POS-DIGIT

   POS-DIGIT =           "1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9"

   ALPHA =               "a"|"b"|"c"|"d"|"e"|"f"|"g"|"h"|"i"|"j"|"k"|

                         "l"|"m"|"n"|"o "|"p"|"q"|"r"|"s"|"t"|"u"|"v"|

                         "w"|"x"|"y"|"z"|"A"|"B"|"C "|"D"|"E"|"F"|"G"|

                         "H"|"I"|"J"|"K"|"L"|"M"|"N"|"O"|"P"|" Q"|"R"|

                         "S"|"T"|"U"|"V"|"W"|"X"|"Y"|"Z"

   email-safe =          safe | space | tab

   safe =                alpha-numeric |

                         "'" | "'" | "-" | "." | "/" | ":" | "?" | """ |

                         "#" | "$" | "&" | "*" | ";" | "=" | "@" | "[" |

                         "]" | "^" | "_" | "`" | "{" | "|" | "}" | "+" |

                         "~" | "

   space =               %d32

   tab =                 %d9

   CRLF =                %d13.10

 

[References]

1.《IP网络电话技术》人民邮电出版社，糜正琨编著