udp传输加密

⑴ TCP/TLS/UDP 有什么区别

TCP和UDP都是网络层上的协议，是建立在IP层之上的。
TCP是有连接的传输，它通过对它下层IP包的冲突、错误检测和重传，保证了最终接收到的数据是可靠的；UDP是无连接的，数据包发出去就不管了，没有数据包是否成功并且正确发送的检查，不能保证数据传输100%正确，但是开销会比较小。

TLS是在更上一层的协议，他必须建立在可靠的数据传输基础上，所以一般是在TCP之上，当然也可以建立在SCTP之上，但是一定不是UDP之上。TLS全名叫传输层安全（Transpot Layer Security）协议，TLS连接的建立有个标准的握手过程，可以查看RFC2246了解具体的细节。简单的讲，就是通信双方互相验证对方的数字证书，确认对方的身份，并通过密钥交换协议，确定出相互通信时使用的加密算法和密钥，之后的数据通信都使用协商好的加密算法进行加密传输。
它可以保证：1. 与自己通信的一方确实是他自己声明的身份（通过证书检查确认）。 2. 通信时的数据传输的安全的（因为加密过了，中间即使被窃听，也没法解密，没法知道具体的内容）。

⑵ UDP协议和TCP/IP协议有哪些区别

记得好像udp传输协议对传输数据不进行加密和数据完整性验证，tcp/ip则要对数据进行包装，并认证数据完整性。

⑶ 关于udp协议局域网

ip是第三层协议，udp是第四层，就是在ip之上。如果不能收到ip（路由器没有转发），则无法收到udp。标准路由器不具备监听功能，它只负责分析ip，并将其转发到应该去的端口。具备安全策略的路由器会分析第四层，但也仅限于对udp端口的解析（阻止或允许通过），离qq（应用层）还很遥远。所谓窃听，通常需要专用旁路设备，就是将所有到达路由器的信息镜像到这个特殊设备所在端口才行，如入侵检测设备；也可以在路由器中增加监听功能，如入侵防御设备。当然，厂家也很容易在路由设备中预留监听后门，所以一般要害部门不会使用他国的路由设备，或者干脆物理隔绝。

⑷ TCP与UDP之间有什么相同点和不同点

相同点：
1、OSI网络层
它们都根据OSI参考模型生活在同一层。我们称这层为传输层。在套接字之间的这一层中，传
输数据。他们在这方面没有区别。
2、安全
从安全角度来看，TCP和UDP都是相同的。实际上，TCP由于其会话管理而具有一些小优势，
但从总体上看，如果实现SSL，加密等安全机制，则存在安全性。除UDP之外，实现类似TCP
的协议的SSL
/
TLS非常容易。另一方面，像RTP这样的语音通信协议可以升级到SRTP，使底
层UDP更安全。

不同点：
1、数据包结构
UDP具有精简包结构。UDP在其标题部分中仅提供源，目标端口，长度，校验和。TCP在包中
有更多字段，因为TCP传输有更多的步骤和控件来进行包传递。TCP有12个头字段。
2、复杂程度
TCP绝对比UDP协议更复杂。正如我们在上侧看到的，TCP具有很多传输相关机制的区域。例
如，TCP提供了设置传输缓冲区相关内存的窗口机制。UDP只有校验和机制和数据包计数器，
有时候没有实现。
3、算法
要使用TCP传输数据，必须使用名为3次握手的方法创建会话。第一个客户端发送一个包含SYN
标志的数据包，服务器用ACK标志响应，最后一步客户端发送SYNC
+
ACK以完成与相关服务
器的TCP会话。UDP没有任何特殊算法。UDP包直接发送到服务器的端口。管理层通常在上层
应用程序层中执行。
4、速度
TCP协议的复杂性使TCP比UDP慢。至少要发送一个字节，需要进行会话初始化，并在数据传
输后关闭会话。这使TCP变慢。关于TCP的速度已经做了一些工作，但架构是有限的新增强功
能。如果您通过光纤传输UDP，则UDP 速度很快.UDP速度很快，因为没有会话或会话终止的
算法。
5、可靠性
TCP是一种可靠的协议，因为它运行机制来防止数据丢失或更改。TCP使用会话来提高数据传
输的可靠性。同样在数据传输中，在两侧之间检查传输的数据，并且如果发生一些丢失或改
变，则再次重新传输数据。UDP也不可靠。真的不是。但是，如果您希望它是可靠的上层应用
程序级别机制可以实现，但这些将使传输更复杂。
6、协议
在这部分中，列出使用UDP或TCP或两者的协议。
UDP以下协议使用UDP传输。
DHCP
DNS
流
RDP
TFTP
SNMP
VOIP
TCP以下协议使用TCP传输。
HTTP
HTTPS
FTP
SMTP
TELNET

⑸ udp如何保证数据传输的可靠性

UDP要达到TCP的功能就必须实现拥塞控制的功能,而且是在路由之间实现,这个在底层明显是做不到拥塞控制的,在应用层也是做不到的,因为应用层之间和应用程序挂钩,一般只能操控主机的程序,而表示层是处理所有与数据表示及运输有关的问题，包括转换、加密和压缩,在传输层是不可能的,因为你已经使用了UDP协议,无法在本层转换它,所以只有在会话层

⑹ UDP传送数据时，会对数据进行加密吗

不会。
udp的特点就是不加密啊

⑺ UDP与TCP区别

从专业的角度说，TCP的可靠保证，是它的三次握手机制，这一机制保证校验了数据，保证了他的可靠性。而UDP就没有了，所以不可靠。不过UDP的速度是TCP比不了的，而且UDP的反应速度更快，QQ就是用UDP协议传输的，HTTP是用TCP协议传输的，不用我说什么，自己体验一下就能发现区别了。再有就是UDP和TCP的目的端口不一样（这句话好象是多余的），而且两个协议不在同一层，TCP在三层，UDP不是在四层就是七层。

⑻ 如何让UDP实现可靠传输

如何让UDP实现可靠传输
自定义通讯协议，在应用层定义一些可靠的协议，比如检测包的顺序，重复包等问题，如果没有收到对方的ACK，重新发包
UDP没有Delievery Garuantee，也没有顺序保证，所以如果你要求你的数据发送与接受既要高效，又要保证有序，收包确认等，你就需要在UDP协议上构建自己的协议。比如RTCP，RTP协议就是在UPD协议之上专门为H.323协议簇上的IP电话设计的一种介于传输层和应用层之间的协议。
下面分别介绍三种使用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序列号也能被用来确定包的合适位置。例如在视频解码，包无需按序解码。
2.0 技术概览
2.1 RTP
RTP头具有如下的格式。开始的12个八位字节在每一个RTP包中都会出现；而CSRC标识符列表只在通过混合器的包中出现.
Version (V) （版本号）:这个域长度为2比特，标出了RTP的最近版本。当前的版本为2.0
Padding (P) （填充）:这个域长度为1比特，如果P被置位，包在结尾处包含有一个或多个附加的填充字节，这些填充字节不是有效负荷的一部分。填充是一些需要固定块大小的加密算法所要求的，或是为了在低层PDU搬运RTP包。
Extension (X):这个域长度为1比特，如果被置位，固定的头后面紧跟了一个头的扩展。
CSRC count (CC):这个域长度为4比特。这个域表示了跟在固定头后面的CSRC标识符的数目。如前所述，这个域只有在通过一个混合器才有非零值。
Marker bit (M): 这个域长度为1比特，如果M被置位，表示一些重要的项目如帧边界在包中被标记。例如，如果包中有几个比特的当前帧，连同前一帧，那么RTP的这一位就被置位。
Payload type (PT) （有效负荷类型）:这个域长度为7比特，PT指示的是有RTP包中的有效负荷的类型。RTP音频视频简介(AVP)包含了一个默认的有效负荷类型码到有效负荷格式的映射。附加的有效负荷类型可以向IANA注册。
Sequence number（序列号）：这个域长度为16个比特，每送一个RTP包数目就增加一，初始值被设为一个随机数。接收方不仅可以用这个序列号检测包丢失，也可以重组包序列。
Time stamp（时间戳）:这个域长度为32个比特，时间戳反映了RTP数据包的头一个字节的采样时刻。采样时刻必须是由一个单调线性增加的时钟产生，这样做是为了接收方的同步和抖动计算。初始值必须为随机数，这是为了避免对原码的攻击。例如，如果RTP源使用了一个编码器，缓冲20ms的音频数据，那么RTP时间戳必须每个包增加160，无论包是被传递了还是被丢失了。
SSRC:这个域长度为32比特，这个域表示了正在为会话产生RTP包的源。这个标识符是随机选中的，目的是为了避免同一个RTP会话中两个源有相同的标识符。
CSRC list: 这个列表标识了在这个包中对有效负荷起作用的所有源。标识符的最大数目限定为15，这是由CC域所限定的（全零在CC域中是被禁止的）。如果有超过15个的分配源，只有前15个被标识。
仔细观察RTP可以注意到它不像更低层的协议比如PDU一样，包含一个“定边界”的域。这一原因是RTP的有效负荷是跟IP的有效负荷相同，因此也就不需要了。
如果相同的用户在一个会话中使用多个媒体，比如说视频跟音频，每个媒体都会打开单独的RTP会话。因此在RTP层面上不存在多路复用。多路复用由更低层来决定。但是RTCP保留了一个叫CNAME的标识符，这个标识符对于由同一用户初始化的媒体是相同的。因此CNAME是在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协议进行可靠的数据传输，不过这好像也是一个难题！

⑼ 如何在voip中使用rc4对udp收发函数进行加密

qutecom 一个开源的voip客户端
asterisk 开源的ippbx
rc4加密算法简单，快速，据说是比DES算法快10倍。sip 信令本身就属于明文方式传输的，之所以要加密，是为了防止运营商的干扰，使用一个弱的加密算法，是要能防止串改就满足要求了。
rc4 算法可以google原来，用密钥来生成一个256长度的box， 然后box与明文异或操作得到密文，密文再次异或就恢复明文。
下面实现了 qutecom 到asterisk 信令的当向加密，反向的目前还没弄完，等完工了在来补充。

rc4.h
/*
*RC4 functions for HTMLDOC.
*
* Original code by Rob Earhart
* Copyright 1999 by Carnegie Mellon University, All Rights Reserved
*
* Permission to use, , modify, and distribute this software and its
* documentation for any purpose and without fee is hereby granted,
* provided that the above right notice appear in all copies and that
* both that right notice and this permission notice appear in
* supporting documentation, and that the name of Carnegie Mellon
* University not be used in advertising or publicity pertaining to
* distribution of the software without specific, written prior
* permission.
*
* CARNEGIE MELLON UNIVERSITY DISCLAIMS ALL WARRANTIES WITH REGARD TO
* THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
* FITNESS, IN NO EVENT SHALL CARNEGIE MELLON UNIVERSITY BE LIABLE FOR
* ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
* WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
* ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT
* OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/

#ifndef _RC4_H_
# define _RC4_H_

# ifdef __cplusplus
extern "C" {
# endif /* __cplusplus */

/*
* RC4 context...
*/

typedef struct
{
unsigned char sbox[256]; /* S boxes for encryption */
int i, j; /* Current indices into S boxes */
} rc4_context_t;

/*
* Prototypes...
*/

extern void rc4_init(rc4_context_t *context, const unsigned char *key,
unsigned keylen);
extern void rc4_encrypt(rc4_context_t *context, const unsigned char *input,
unsigned char *output, unsigned len);

# ifdef __cplusplus
}
# endif /* __cplusplus */

#endif /* !_RC4_H_ */

rc4.c
/*
* RC4 functions for HTMLDOC.
*
* Original code by Tim Martin
* Copyright 1999 by Carnegie Mellon University, All Rights Reserved
*
* Permission to use, , modify, and distribute this software and its
* documentation for any purpose and without fee is hereby granted,
* provided that the above right notice appear in all copies and that
* both that right notice and this permission notice appear in
* supporting documentation, and that the name of Carnegie Mellon
* University not be used in advertising or publicity pertaining to
* distribution of the software without specific, written prior
* permission.
*
* CARNEGIE MELLON UNIVERSITY DISCLAIMS ALL WARRANTIES WITH REGARD TO
* THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
* FITNESS, IN NO EVENT SHALL CARNEGIE MELLON UNIVERSITY BE LIABLE FOR
* ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
* WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
* ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT
* OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*
* Contents:
*
* rc4_init() - Initialize an RC4 context with the specified key.
* rc4_encrypt() - Encrypt the given buffer.
*/

#include "rc4.h"

/*
* 'rc4_init()' - Initialize an RC4 context with the specified key.
*/

void
rc4_init(rc4_context_t *text, /* IO - Context */
const unsigned char *key, /* I - Key */
unsigned keylen) /* I - Length of key */
{
int i, j; /* Looping vars */
unsigned char tmp; /* Temporary variable */

/*
* Fill in linearly s0=0, s1=1, ...
*/

for (i = 0; i < 256; i ++)
text->sbox[i] = i;

for (i = 0, j = 0; i < 256; i ++)
{
/*
* j = (j + Si + Ki) mod 256
*/

j = (j + text->sbox[i] + key[i % keylen]) & 255;

/*
* Swap Si and Sj...
*/

tmp = text->sbox[i];
text->sbox[i] = text->sbox[j];
text->sbox[j] = tmp;
}

/*
* Initialized counters to 0 and return...
*/

text->i = 0;
text->j = 0;
}

/*
* 'rc4_encrypt()' - Encrypt the given buffer.
*/

void
rc4_encrypt(rc4_context_t *text, /* I - Context */
const unsigned char *input, /* I - Input buffer */
unsigned char *output, /* O - Output buffer */
unsigned len) /* I - Size of buffers */
{
unsigned char tmp; /* Swap variable */
int i, j; /* Looping vars */
int t; /* Current S box */

/*
* Loop through the entire buffer...
*/

i = text->i;
j = text->j;

while (len > 0)
{
/*
* Get the next S box indices...
*/

i = (i + 1) & 255;
j = (j + text->sbox[i]) & 255;

/*
* Swap Si and Sj...
*/

tmp = text->sbox[i];
text->sbox[i] = text->sbox[j];
text->sbox[j] = tmp;

/*
* Get the S box index for this byte...
*/

t = (text->sbox[i] + text->sbox[j]) & 255;

/*
* Encrypt using the S box...
*/

*output++ = *input++ ^ text->sbox[t];
len --;
}

/*
* Copy current S box indices back to context...
*/

text->i = i;
text->j = j;
}

修改exosip项目中的 jcallback.c 在函数cb_udp_snd_message 中修改，加入rc4加密部分
....

if( 1 )
{
rc4_context_t context;
char * key = "*****";
unsigned char * out = NULL;
int i=0;
out = osip_malloc (length);
if (out == NULL)
return -1;
rc4_init(&context,key,16);
rc4_encrypt(&context,message,out,length);

rc4_message = osip_malloc(length+4);
if(rc4_message != NULL)
{
rc4_message[0] = 'R';
rc4_message[1] = 'C';
rc4_message[2] = '4';
rc4_message[3] = ':';
for(i=0;i<length;i++)
{
rc4_message[i+4] = out[i];
}
}
osip_free(out);
}

// Really send the packet over network
if(rc4_message == NULL)
{
i = owsip_send (account, (const void*) message, length, 0, address, OWSL_ADDRESS_SIZE);
}
else
{
i = owsip_send (account, (const void*) rc4_message, length+4, 0, address, OWSL_ADDRESS_SIZE);
osip_free(rc4_message);
}
....

在asterisk 中的chan_sip.c 修改函数 sipsock_read， 添加 接受信令rc4解密代码
.....
if(res>4 && req.data[0]=='R' && req.data[1]=='C' && req.data[2]=='4' && req.data[3]==':')
{
rc4_context_t context;
char * key = "********";
unsigned char * out = NULL;
int i=0;
out = malloc(res-4);
rc4_init(&context,key,16);
rc4_encrypt(&context,req.data+4,out,res-4);
for(i=0;i<res-4;i++)
{
req.data[i] = out[i];
}
free(out);
req.data[res-4] = '/0';
res = res-4;
req.len = res;
}
.....

⑽ 传输层协议除了TCP和UDP还有什么协议

传输层协议除了TCP和UDP还有TLS协议。TLS利用密钥算法在互联网上提供端点身份认证与通讯保密，其基础是公钥基础设施。

不过在实现的典型例子中，只有网络服务者被可靠身份验证，而其客户端则不一定。这是因为公钥基础设施普遍商业运营，电子签名证书通常需要付费购买。协议的设计在某种程度上能够使主从架构应用程序通讯本身预防窃听、干扰和消息伪造。

(10)udp传输加密扩展阅读

TLS协议的优势是与高层的应用层协议（如HTTP、FTP、Telnet等）无耦合。应用层协议能透明地运行在TLS协议之上，由TLS协议进行创建加密通道需要的协商和认证。应用层协议传送的数据在通过TLS协议时都会被加密，从而保证通信的私密性。

TLS协议可选的，必须配置客户端和服务器才能使用。主要有两种方式实现这一目标：一个是使用统一的TLS协议通信端口（例如：用于HTTPS的端口443）；另一个是客户端请求服务器连接到TLS时使用特定的协议机制（例如：邮件、新闻协议和STARTTLS）。

一旦客户端和服务器都同意使用TLS协议，他们通过使用一个握手过程协商出一个有状态的连接以传输数据。通过握手，客户端和服务器协商各种参数用于创建安全连接：

当客户端连接到支持TLS协议的服务器要求创建安全连接并列出了受支持的密码组合（加密密码算法和加密哈希函数），握手开始。