Windows XP(及更高版本)中的自定义 IP/UDP/RTP 标头 +一般网络问题

发布于 2024-10-13 18:23:18 字数 1816 浏览 2 评论 0原文

问题有点多,抱歉!

我正在做一个语音聊天(VoIP)应用程序,我正在考虑对 IP 和 UDP 标头进行自定义实现,以及主要是序列号的小型额外信息。听起来很像 RTP 是的,但我主要只是对序列号或时间戳感兴趣,并且尝试实现我自己的整个 RTP 听起来就像一场噩梦,涉及所有复杂性和我不太可能使用的数据。

该应用程序的目标操作系统是Windows XP及以上版本。我已阅读 http://msdn.microsoft。 com/en-us/library/ms740548%28v=vs.85%29.aspx 关于 Windows 中的原始套接字主题,现在我只想进行一些确认。 我还有一些一般性的网络问题。

这是以下问题;

1) 根据 MSDN,您不能发送来自网络列表之外的源的自定义 IP 数据包。我从安全视角理解这一点,但是有什么办法解决这个问题吗?我的想法是让两个客户端打开与非 NAT 保护服务器的 UDP 通信,然后让客户端欺骗源标头,使其看起来像是来自服务器而不是彼此的数据包,从而消除了对服务器作为数据中继以通过 NAT,这将改善延迟。 我听说过 winpcap,但我不希望每个客户端都必须安装任何第 3 方应用程序。考虑到 DoS 攻击的数量,肯定有一些方法可以解决这个问题,比如欺骗操作系统用来检查源标头是否合法的网络表?这会触发防病毒系统吗? 我觉得实际使用 IP 标头及以上内容而不是仅仅使用预定义的标头会非常有趣。

2)我一直在使用像JRTPLIB这样的免费RTP库(这可能非常好,无论如何它只是不想为我工作)来让它们工作,这超出了我几乎可以容忍的范围,我正在考虑只是写我自己对 UDP 的解释。像 RTP 这样的应用程序级协议是否只是直接在 UDP 有效负载内构建其标头并随后使用实际数据?考虑到封装过程,我怀疑这一点,但只是想确定一下。 如果是这样,则不需要创建一个 RAW 套接字来实现应用程序级协议,只需创建一个普通的 UDP 套接字,然后再创建上面您自己的有效负载解释?

3) 与 UDP 相比,RTP 不会带来任何性能提升,因为它添加了更多标头,它所做的只是确保数据包根据时间戳和序列号以某种正确的方式到达,对吗? 使用 RTP 实现来满足基本 VoIP 项目需求而不是自己添加基本排序真的那么有用吗?我意识到对于视频会议,也许您真的不希望帧乱序播放,但在音频对话中,您真的会注意到吗?

4) 如果我在 #1 中的解决方案不适用,并且我必须使用服务器作为客户端之间的数据中继,那么多播是否是减少服务器负载的良好解决方案?路由硬件是否足够支持多播?

5)与问题1)相关。为什么路由器/防火墙允许 UDP 打洞之类的功能?例如,两个客户端首先连接到服务器,然后服务器将客户端端口/IP 提供给其他客户端,以便客户端可以在这些端口上相互通信。 为什么防火墙允许从另一个 IP 接收数据,而不是在该端口上建立连接所使用的 IP?听起来像是一个应该很容易过滤的大安全漏洞?我知道源 IP 欺骗会欺骗它,但是这个呢?

6) 要在两方(NAT 后面的客户端,非 NAT 后面的服务器)之间建立 UDP 会话,客户端是否只需向服务器发送数据包,然后允许会话通过防火墙?这意味着客户端也可以从服务器接收。 基于 wiki 上的文章,http://en.wikipedia.org/wiki/UDP_hole_punching

7) SIP 是否依赖于 RTP?出于某种原因,我有这样的印象,但我找不到数据来支持它。我可能计划将来向我的 VoIP 客户端添加软件电话功能,并希望确保我有一个良好的基础(RTP,如果我确实必须,否则我自己的 UDP 解释)

提前致谢!

Lots of questions, I am sorry!

I am doing a voice-chat (VoIP) application and I was thinking of doing a custom implementation of the IP&UDP headers, along with small, extra information mainly seq number. Sounds alot like RTP yes, but I'm mainly just interested in the seq number or timestamp, and trying to implement my own whole RTP sounds like a nightmare with all the complexity involved and data im not likely to use.

Target OS for the application is windows xp and above. I have read http://msdn.microsoft.com/en-us/library/ms740548%28v=vs.85%29.aspx on the topic of Raw sockets in windows, and now I just want some confirmation.
I also have some general networking questions.

Here's the following questions;

1) According to MSDN, you cannot send custom IP packets with a source that is not on the network list. I understand it from a security PoV, but is there any way around this? My idea was to have for example two clients open UDP communication to a non-NAT protected server, and then have the clients spoof the source-header to make it look like packets come from the server instead of each other, thereby eliminating the need for a server as a relay of data to get through NAT, which would improve latency.
I have heard of winpcap but I don't want each client to have to install any 3rd party apps. Considering the number of DoS attacks surely there must be some way around this, like spoofing the network table the OS uses to check if source-header is legit? Will this trigger anti-virus systems?
I feel it would be really fun to actually toy with IP headers and above instead of just using predefined headers.

2) I've been having issues with free RTP libraries like JRTPLIB(which probably is very good anyway it just dosn't want to work for me) to make them work, more than I could almost tolerate, and am thinking of just writing my own interpretation ontop of UDP. Does application-level protcols like RTP simply build their header directly inside the UDP payload with the actual data afterwards? I suspect this considering the encapsulation process but just want to make sure.
If so, one does not need to create a RAW socket to implement application-level protocol, just an ordinary UDP socket and then your own payload interpretation above?

3) RTP does not give any performance boost compared to UDP since it adds more headers, all it does is making sure packets arrive in a sort-of correct manner based on timestamps and sequence numbers, right?
Is it -really- that usefull to use an RTP implementation for your basic VoIP project needs instead of adding basic sequencing yourself? I realise for video conferencing perhaps you reaally don't want frames to play out of order, but in audio conversations, would you really notice it?

4) If my solution in #1 is not applicable and I would have to use a server as a data relay between clients, would multicast be a good solution to reduce server loads? Is multicast supported enough in routing hardware?

5) It is related to question 1). Why do routers/firewalls allow things like UDP hole punching? For example, two clients first conenct to the server, then the server gives a client port / ip on to other clients, so the clients can talk to each other on those ports.
Why would firewalls allow data to be received from another IP than the one used in making the connection on that very port? Sounds like a big security hole that should easly be filtered? I understand that source IP spoofing would trick it, but this?

6) To set up a UDP session between two parties (the client which is behind NAT, server whic his non-NAT) does the client simply have to send a packet to the server and then the session is allowed through the firewall? Meaning the client can receive too from the server.
Based on article at wiki, http://en.wikipedia.org/wiki/UDP_hole_punching

7) Is SIP dependant on RTP? For some reason I got this impression but I cant find data to back it up. I may plan to add softphone functionality to my VoIP client in the future and want to make sure I have a good foundation (RTP if I really must, otherwise my own UDP interpretation)

Thanks in advance!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

平安喜乐 2024-10-20 18:23:19

1,原始套接字对于该应用程序似乎没有必要

2,是的

3,RTP 在 UDP 之上运行,当然它会增加开销。在许多方面,RTP(忽略 RTCP)几乎已经是最低限度了,如果您实现了一个半途而废的替代方案,它最多可以为您节省几个字节,并且您将无法使用许多 RTP 测试工具中的任何一个。

7、SIP完全独立于RTP。 SIP 用于发起会话。 SDP是SIP常用的传输协议,SDP负责RTP视频/语音的协商和控制。

1, Raw sockets seems unnecessary for this application

2, Yes

3, RTP runs on top of UDP, of course it adds overhead. In many ways RTP (ignoring RTCP) is pretty much the bare minimum already and if you implemented a half-way decent alternative it would save you a few bytes at best and you wouldn't be able to use any of the many RTP test tools.

7, SIP is completely independent of RTP. SIP is used to Initiate Sessions. SDP is the protocol commonly transported by SIP, and it is SDP that negotiates and controls RTP video/voice voice.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文