淘客熙熙

主题:【原创】最后的莫希干人 -- 晨枫

共:💬101 🌺202 新:
分页树展主题 · 全看首页 上页
/ 7
下页 末页
    • 家园 加密可以不增加带宽的

      原文多大,密文就是多大。

      加密的话,只是增加了解密和解密的过程,总的来说是增加了处理时间。我觉得是美国军方没意识到卫星信号也可以被截取吧。

      • 家园 谢谢指出

        离线文件加密和实时streaming加密会不一样吗?离线文件可以把内容打乱,密文不加大;但实时streaming怎么做法呢?

        • 家园 都一样的

          我接触的算法,都是按位或者按块把明文加密成密文,不会增加信息的长度。其实实时的streaming按照目前的网络通信协议,都是一次发送一段信息过去,只要发送的频率够高,在用户那里就表现为连续的流。那么,只需要每次发送的时候把该段信息加密就行了。这样看了,跟离线文件加密没什么不同,都是对一段一段的信息加密。

          • 家园 谢谢

            但遥控要求的帧频很高,也就是说,每秒钟需要把视频打成几十个“包”,然后加密、解密,还不能有时延,能做到吗?

            • 谢谢
              家园 抱歉,这个问题没研究过

              不过加密解密纯粹是考验CPU的能力了,只要CPU运算速度够快,我觉得应该是可以满足得了的。这个问题要这么理解,一般来说,正常的视频要求是1秒显示30帧,如果按照1024*768的分辨率来算,那么只要差不多800K一帧的数据量,那么30帧的话,就要处理差不多30M的数据量。我觉得现在的计算机1秒处理30M的数据,根本不在话下。

              搜索了一下,找了下面一篇文章:

              http://www.eet-china.com/ART_8800247178_675277_TA_c3b48623.HTM

              文中说:

              第一代SSL加速器每秒能处理600个RSA解密算法(图1)。在全速运行条件下,一个每秒运行600个RSA解密算法的系统需要约85Mbps的加密处理能力,对于RC4/MD5密码套件而言,其负载将占1GHz奔腾III CPU处理能力16%,而3DES/SHA-1密码套件则需要144%的CPU处理能力。

              • 家园 这样算法有点疑问

                一秒钟30帧的话,每帧按照1024x768点,那就是786432个像素;每个像素按照24位(high color)算,那就是2.3MB;30帧的话,差不多70MBps的数据量。问题是,不管是CCD还是CMOS,成像和写入闪存是需要时间的。具体多少我说不上来,但肯定是很可观的,剩下给CPU加密、解密加上传、下传、显示的时间就很紧张了。


                本帖一共被 1 帖 引用 (帖内工具实现)
                • 家园 图像不是这样算的

                  你算的是原始图像的数据速率。现在的编码芯片可以处理1920x1080@30fps的输入数据,编码输出是连续的25-50Mbps的数据流,这是在家里看的HDTV的标准。如果要求低一些,可以压缩到12-15Mbps。按下面meokey给的通信卫星速率,这个速率还是可以接受的。

                  至于时间问题不用考虑,只要运算量能够跟上,可以用缓冲区平滑,只是增加一点延迟而已。一般来说,视频编码有100ms左右的延迟,但输出流是平滑的。加密的延迟很低,因为加密通常以8字节左右长度为单位即可。传输延迟分打包和信号传输两部分。打包方面,卫星传输层用的TS协议是47字节/包。信号传输比较麻烦,如果用卫星,那是光传播7.2万公里距离的时间,再加上存储转发的时间。总的来说,总延迟大概有500-1000ms。以你作自动控制的背景,看到这个数字肯定已经晕掉了。但这虽然不能作为自动控制的依据,但作为有人参与的行为控制的依据还是没有大问题的。

                  • 家园 看来时延或许是更大的问题

                    1秒级的时延对于遥控飞机来说是很要命的,打电脑游戏就知道了,要是所有键盘和鼠标命令都要延迟一秒,高手也要发狂。

                    • 家园 所以目前游戏方式的无人机还是不实用的

                      机上AI必须做到能够自动完成大多数“短任务”,比如攻击指定目标、规避导弹、抢占某个位置等,而不能仅仅是“远程线传”。如果大多数短任务可以自动完成,操作员只需要对短任务选优和排序即可。这样的操作可以容许较大的延迟。现在这种远程线传式操作还是比较难以发挥效果。

                • 家园 时间不是问题,带宽是问题

                  因为可以并行计算,硬压缩等等手段。延迟可以控制在毫秒级,就是1/100秒以内。

                  问题是带宽不容易保证,而且干扰没办法解决。要是面对TG,就要准备无人机面对信号中断,没有GPS信号,假指令,信道堵塞/淹没等等情况。没有AI还真不好办。

                • 家园 基本上取像,计算和传输带宽问题都不大

                  工业CCD的取像速率有很多200fps左右,所以不用太担心感光元件的速度问题。而且也没有必要用速度比较慢的闪存,直接在内存处理就可以了,速度要快得多。

                  现在的计算机处理能力很高。如果算法没有太大问题的话,这么算吧:假设编码与加密是通过同一个算法(即在编码的同时可以加密的话),对一个视频帧平均需要3-pass处理,简单算起来就是需要处理3×70Mb约等于30MB的数据。这对现在的计算能力完全是小菜一碟,即使再高2倍都没有问题。但关键就看算法了,如果编码要3-pass,加密再用大素数来个几遍,可能就不太够用了。

                  关于战地带宽,目前找到的资料相互不是非常精确的一致,但总体而言MB级别的资料传输问题不是太大,基本应该能够做到实时或“几乎”实时:

                  已经升空的WGS卫星

                  的工作频带为X波段和Ka波段,瞬时带宽为4.87SGHz,能够为作战用户提供2.4-3.6Gbps的高数据吞吐量

                  先进极高频(AEHF)

                  “军事星”Ⅲ计划卫星将提供相当于当前“军事星”Ⅱ卫星10~12倍的能力和6倍多的数据传输能力

                  TSAT计划

                  其中每颗星的通信容量大约为2-10 Gbps,是目前已升空的WGS和正在研制的AEHF、MUOS的10倍到100倍

                  总结一下,基本上取像部分没有问题了,数据处理能力如果按目前商用标准(3-pass编码,简单加密)也没有问题,战地传输带宽问题似乎也不大。关键问题就是军用标准的视频流编码和加密算法是否会大幅度增加处理时间了。

                • 家园 不用24位,8位就可以了

                  黑白的图像足够判断、操作了。

                  我觉得目前的情况下,也不能做得很即时,可能就是一些策略的判断吧,对于操作员来说。

                  何况,还有通信方面的延时。加密解密的过程相对于通信过程的时间,差不多可以忽略不计了。

                  • 家园 如果用于空战或者对地攻击

                    黑白的会丧失很多战场细节。有人飞机的火控摄像机用黑白没关系,因为那时有人操纵往那里看了,已经知道要看什么了,只是细节问题;无人飞机全靠电视,情况就不一样了。单是保持航线、起飞着陆,黑白、低分辨率问题不大,但要搜索、识别,还是得彩色高分辨率才行。

                    高速机动的时候需要极高的数据率,通信延时已经很要命了,加密、解密不能在增加可以感觉得到的延时了,否则要把控制员逼出病来的。


                    本帖一共被 1 帖 引用 (帖内工具实现)
                    • 家园 目前的无人机还不能进行格斗吧?

                      如果只是进行侦察或者进行袭击任务,那么黑白视频就可以满足操纵的需要了。

                      从网上文章得知,现在的加密算法,一秒钟处理700多M的数据已经不成问题,那么处理几十M的数据,也就是几十分之一秒,这个时间已经可以忍受了。

                      对于计算机的处理来说,计算往往不是问题,性能的瓶颈往往在IO上面,比如写内存、写磁盘、网络通信这些操作,跟加密解密的操作不是一个数量级上面的。

      • 家园 一般来说,如果原文和密文一样大

        解密起来就比较方便了。

        卫星信号可以被截取,这个是基本常识吧,家里架过卫星天线的人应该都知道,没道理美国军方会不知道这个事情。

分页树展主题 · 全看首页 上页
/ 7
下页 末页


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河