移动提供商无法进行 UDP 打孔
实际上，我正在编写一个 android 应用程序，该应用程序接收连接到 PC 的网络摄像头的图片.为了获得更多 fps，我使用 udp 协议而不是 tcp.这个想法是，电脑将图片发送到手机的 ip 和端口.但是电话提供商有不同的公共端口.所以我不能直接打电话.这就是为什么我试图通过 udp 打孔来解决问题，但没有奏效.当我的手机向 pc 发送一个数据包时，pc 会获取手机的公共 ip 和端口.每秒都会发生这种情况以保持连接打开.然后服务器尽可能快地将网络摄像头帧发送到这个 ip 和端口.但手机在 1-2 秒内只收到 10-15 张图片.之后，提供商似乎过滤了每个后续数据包或类似的东西，因为手机没有收到任何进一步的数据包.
actually iam coding an android app that receives the pictures of a webcam that it connected to a pc. To gain more fps i use the udp protocol instead of tcp. The idea is, that the pc sends the pictures to the phone's ip and port. But the provider of the phone has different public ports. so i cant address the phone directly. That's why i tried to solve the problem via udp hole punching, but that didnt work. When my phone sends one packet to the pc, the pc gets the phone's public ip and port. that happens every second to keep the conenction open. Then the server sends the webcame frames to this ip and port as fast as he can. but the phone receives just 10-15 pictures wihtin 1-2 seconds. after that the provider seems to filter every following packet or something like that because the phone doesnt receive any further packet.
现在我的问题是:发生了什么(或提供商在做什么)，我该如何解决这个问题?TCP 协议有效，但由于开销和纠错过多，流式传输速度太慢.
Now my question is: what is happening (or what is the provider doing) and how can i fix this problem? TCP protocol works but is too slow for streaming because of too much overhead and error corrections.
推荐答案
使用 UDP 需要牢记几个问题，这些问题在移动网络上被放大:
There are several issues to keep in mind with UDP, which are magnified on mobile networks:
您可能知道，一旦您发送了一个 UDP 数据报，就绝对不能保证它会通过，如果没有，也无法确定会发生什么.
As you probably know, once you send a UDP datagram, there is absolutely no guarantee that it will get through and no sure way to know what happened if it didn't.
大于大约 1400 字节的有效负载可能会被分解为 IP 片段.接收操作系统可能将它们重新组合成一个完整的数据包，但前提是每个片段都到达.一些路由器任意丢弃片段，一些防火墙在片段包含特定字节模式时丢弃片段，还有一些限制可能发送片段的速率.最好始终保持数据报较小，并自己处理丢失部分的重组和重复.
Payloads larger than roughly 1400 bytes are likely to be broken up into IP fragments. The receiving operating system may reassemble those into a whole packet, but only if every fragment arrives. Some routers drop fragments arbitrarily, some firewalls drop fragments if they contain particular byte patterns, and some limit the rate at which fragments may be sent. Its best to always keep your datagrams small and handle reassembly and repeats of missing pieces yourself.
没有流量控制:如果任何路由器的缓冲区已满，之后的所有内容都会被丢弃.如果缓冲区正在增长但尚未满，一些路由器将开始随机丢弃一定百分比的数据包.如果 UDP 源的速度超过某个任意阈值，某些防火墙会将其列入黑名单.
There is no flow-control: if any router's buffer is full, everything after that is dropped. Some routers will begin randomly dropping a percentage of packets if their buffers are growing but not yet full. Some firewalls will blacklist a UDP source if it goes faster than some arbitrary threshold.
一般而言，设备和防火墙制造商倾向于将 UDP 视为垃圾，因此作为 UDP 开发人员，您必须成为一个特别好的公民才能不被倾倒:调节您的流量，记住丢弃的数据包意味着您可能走得太快，并保持数据包小.在受控环境中可以避免很多问题，但如果应用程序将在野外"部署，则需要大量仔细编程以避免出现问题.
In general, device and firewall makers tend to treat UDP like crap so as a UDP developer you have to be an extra good citizen to not get dumped on: regulate your flow, remember that dropped packets mean you might be going too fast, and keep the packets small. There is a lot you can get away with in a controlled environment, but if the application will be deployed "in the wild" it will take a lot of careful programming to avoid problems.
相关文章