如何将现有的 udp 应用程序迁移到原始套接字
是否有从普通 udp 套接字（linux、C99/C++、使用 recv 系统调用）迁移到原始套接字的教程？
根据 http://aschauf.landshut.org/fh/linux/udp_vs_raw/ ch03s04.html 原始套接字比 udp 快得多。
应用程序是客户端-服务器。客户端是专有的，必须使用与 udp 服务器完全相同的协议。但是使用原始套接字服务器可以更快一些。我必须在服务器中实现 udp 的哪些部分？有没有“快速迁移”的库？
Is there a tutorial for migration from plain udp sockets (linux, C99/C++, recv syscall is used) to the raw sockets?
According to http://aschauf.landshut.org/fh/linux/udp_vs_raw/ch03s04.html
raw socket is much faster than udp.
Application is client-server. client is proprietary and must use exactly same procotol as it was with udp server. But server can be a bit faster with raw sockets. What parts of udp I must to implement in server? Is there a "quick migration" libraries?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
原始套接字允许您与较低级别的协议进行通信，例如以太网、IP 等。是的，较低级别的协议可以给您带来一些优势，但是您必须在其与所失去的之间取得平衡。
在本例中，您提到服务器是使用 Udp 协议编写的，因此在线上的通信必须是 Udp。现在，如果您要使用原始套接字，则必须确保发送封装在 Udp 数据包中的应用程序数据。您还需要编写代码以确保遵守 Udp 协议和状态机，以便对于服务器而言，您的客户端仅显示为另一个 Udp 客户端。完成所有这些需要编写大量代码，并且有一些缺点，例如增加维护、增加使其正常工作的成本等。
我没有完全阅读您上面链接的论文，但要问自己的问题是，您能得到该研究论文中给出的收益并将其复制到您的场景中？
在我看来，您应该首先尝试找出为什么您的客户端如此缓慢。您有什么要求？您是否有任何衡量标准来衡量什么是优质、快速的客户端？如果我是你，我会首先测量当前的实现，同时记住一些对该场景有用的指标，例如传输的字节/秒等。然后我会分析客户端，看看它在哪里花费了太多时间，并尝试看看是否可以减少开销并使其更快。
总而言之，在向下查看堆栈之前，请先在堆栈顶部（即在您的应用程序中）查找节省的内容。如果你的应用程序写得不好，那么无论你的水平有多低，你都不会看到你期望的性能提升。
A raw socket allows you to communicate with lower level protocols, like Ethernet, IP etc. Yes, going lower can give you some advantages, however you have to balance that with what you are losing.
In this case, you mention that the server is written to use Udp protocol, so on the wire, the communications has to be Udp. Now, if you go to use a raw socket, you will have to make sure to send your application data encapsulated in a Udp packet. You will also need to write code to make sure you obey the Udp protocol and state machine so that to the server, your client appears as just another Udp client. Doing all this requires writing a lot of code, and has some downsides of increased maintenance, increased cost to get it working correctly, etc.
I did not fully read the paper you linked above, but the question to ask yourself is, can you get the gains given in that research paper and replicate them for your scenario?
In my opinion, you should first try to figure out why your client is so slow. What are your requirements? Do you have any metrics as to what constitutes a good, fast client? If I were you, I would first measure the current implementation keeping in mind some metrics that are useful for the scenario, for eg, Bytes/sec transferred, etc. Then I would profile the client to see where it is spending too much time, and try to see if I can reduce the overhead and make it much faster.
To summarize, look for savings in the top of the stack (i.e in your application) before going down the stack. If your app is not written well, then no matter how low you go, you will not see the perf gains you expect.