精华区 [关闭][返回]

当前位置:网易精华区>>讨论区精华>>电脑技术>>● 计算机安全>>◇百家争鸣◇>>Free (小光) 对于OICQ的回复

主题:Free (小光) 对于OICQ的回复
发信人: ciert()
整理人: williamlong(2001-11-21 20:50:30), 站内信件
【 在 ciert (安安) 的大作中提到: 】  
:   我对Oicq目前协议的初步看法  
:     
:   在粗略看了oicq采用的实现方式以后,我感觉非常失望。  
:   理由如下,  
:   OICQ协议完全采用UDP封装,众所周知,UDP是不可靠  
:   传输协议,但是效率比较高,同时协议封装和实现都很  
:   简单。TCP协议比UDP协议消耗更多的CPU时间,相比而言  
:   产生一个TCP连接和发送一个UDP包而言,TCP的开销很大,  
:   这在服务器端更加明显。  
:   但是,采用UDP包带来的首先是安全性问题。  

呵呵,首先感谢这位网友的热心,不过还是想告诉你几点  
1)下个版本的OICQ协议将全部采用128位不对称算法加密  
2) 如果用TCP连接的话,请你给出一个能同时容纳10000个连接以上的方案  
3) 建议你好好看看TCP连接的原理,它为什么能实现可靠连接,TCP并不是  
   比UDP的线路要高档一些,它也会丢包,但是它是把包重发机制封装了起  
   来,因此采用TCP连接和采用UDP连接所传输的数据量是差不多的,而且  
   在线路好的情况下,UDP的数据量要更小一些。  
4) 你对重复发UDP包的机制判断有些错误,OICQ并不是拼命向服务器发包  
   直到有返回,而是间隔5秒,一般来说5秒都没有返回的时候这个包在  
   去的路上就丢了的可能性为50%,因此这样做带来的额外的开销对于服  
   务器而言并没有你所描述的那么重,相反,采用udp机制的节约下来的  
   开销已经远远抵了TCP永久连接的可怕开销  
     

:   目前我对OICQ协议的实现方式的评价是:很差。  
所以,在没有经过通盘考虑的情况下,不要妄下结论:)  
不过还是非常感谢你对我们的关心和建议。  


【 在 ciert (安安) 的大作中提到: 】  
:     
:   请看任何一个成功的C2C的电子商务站点。:) 或者例如hotmail之类的   
:   免费mail站点。并发连接数都不小于5000,同时承担和OICQ相比不可比拟的   
:   数据传输量。   
喝喝,要知道http连接属于短连接模式,并且非常容易  
平行扩展到很多台机器上,可是你见过同时容纳10000个  
连接的聊天室吗,用tcp和服务器做通讯的类似的icq产品  
也不是没有,可是你可以自己去问问他们服务器的负荷是  
怎么样的  
:     
:   服务器与客户机之间的通讯确实可以部分/全部采用UDP,但是不应该用在   
:   客户的互相通讯之中。    
:     
:   也可以包括著名的download站点,例如ftp.download.com   
喝喝,似乎绝大多数ftp站点都不是无限制让用户连入的吧  
:     
:   :  3) 建议你好好看看TCP连接的原理,它为什么能实现可靠连接,TCP并不是    
:   :     比UDP的线路要高档一些,它也会丢包,但是它是把包重发机制封装了起    

:   :     来,因此采用TCP连接和采用UDP连接所传输的数据量是差不多的,而且    
:   :     在线路好的情况下,UDP的数据量要更小一些。    
:   TCP协议我也学过:), TCP连接重发原理绝对不是靠每若干秒种重发。:),按照  
:   目前的网络状况,TCP包的正常重发率根据 SNIFFER平均小于5% ( LAN里小于  
:   1% ),危言耸听的不是我。我只是靠一些事实数据根据。 退一万步而言,即使  
:   TCP重发率达到100%,发送一个"hi"信息也用不了 2K吧? 利用TCP原理此信息  
:   用OICQ封装后,网络开销不会超过128Byte ,无他,只是16倍的相差而已。如  
:   果仅仅从这点上有任何争议,我可以把所有的包的每个byte都写出来。  

呵呵,就算你这个2k是你测出来的,那不过是一种最最极端的情况,在网络情况
 
  
好的时候一般最多三个包重发即可以到达目的地,这样的通信量也不过60个字节
 
  
而已,况且绝大多数情况下每次的通信量不会超过500个字节,而我想目前中国的
 
  
网民里似乎绝大多数都不是按流量计费的吧,即使按流量计费,这点通信量也要
 
  
远远小于看网页的通信量,因此似乎这个问题并不是OICQ目前的协议模式好坏  


的关键。  
好,我们再来探讨一下客户机之间采用TCP的问题,没错ICQ的客户机之间采用  


的是TCP连接,可是要知道国内的网络情况非常复杂,抛开169不说,还有有非  


常多的用户使用的是proxy共享上网,而这些proxy绝大多数是三元素proxy,这样 
 

有一个好处就是在server上记录到的client的udp端口其他客户机也同样能够向 
 

这个端口发包,proxyserver会把这个包转发给client,这样一个客户机就可以  


直接向proxy内部的机器主动发送信息而无须通过服务器中转,而且两个同在  

proxy后面的客户机也可以相互直接通信而无须通过服务器中转,而如果采用TCP
 
  
方式的话这些是不可能做到的,这也是为什么广大用户纷纷觉得OICQ要比ICQ发 
 

信息快得多的原因之一。此外采用TCP连接可能更不安全,一点不懂网络知识的 
 

人用netstat就可以看到对方的IP,这样带来的危险要远远超过upd可以伪装源地 
 

址进行攻击带来的危险(因为即使你知道了源地址,大多数情况下你也无能为力
 
)  
当然,采用tcp不是没有好处,但是作为一个系统来考虑,需要权衡各方面的利弊
 
  
来作出一个选择,不可能让你占尽所有的优点,可以这么说,OICQ之所以如此深
 
  
受广大用户的喜爱,采用UDP协议功不可没。此外可以告诉你的是OICQ是目前  

唯一教育网上能够使用的ICQ,如果采用TCP的话,oh,MY god~~~~  

:     
:   :  4) 你对重复发UDP包的机制判断有些错误,OICQ并不是拼命向服务器发包    
:   :     直到有返回,而是间隔5秒,一般来说5秒都没有返回的时候这个包在    
:   :     去的路上就丢了的可能性为50%,因此这样做带来的额外的开销对于服    
:   :     务器而言并没有你所描述的那么重,相反,采用udp机制的节约下来的    
:   :     开销已经远远抵了TCP永久连接的可怕开销    
:   我举的"hi"的例子是 Sniffer下的原始记录,并非我的判断失误:)   
:     
:   我的意思是,现在采用的连接方式对服务器负担确实很轻,但是对于网络   
:   和用户未免不够负责。   
:   分析OICQ协议也并非因为协议本身的好坏,是出于探索的目的:)。   
:     
:   谢谢您很诚意地纠正我的意见,我相信OICQ的开发者作了相当的权衡,  
:   但是只考虑开销(当然,目前开销仍然不是最合理),完全忽略安全性是我  
:   作为一个对安全比较关心的“网友”所不愿意看到的。  

好了,最后再来探讨你所说的安全性的问题,其实仔细想想,如果不对信息流  


加密的话无论是UDP还是TCP都一是一样的,安不安全和协议本身没有多大关系  


因此说采用UDP就是对用户不负责任的说法未免有些牵强,难道采用TCP协议就  


算是对用户负责了么?  
由于开发初期人手的问题造成了明文协议的历史遗留问题,我们也感觉颇为遗憾
 
  
但是作为一个聊天系统,我们要做的好,侧重点同电子商务是不同的,否则也许
 
  
我们的系统非常安全,可是并不好用,只能说是本末倒置了,相信随着OICQ的不
 
  
断完善,在这方面我们会投入更大的精力。  

:     
:   和我上封帖子里写的那样,OICQ是个好的开端,而且对将来的电子商务等  
:   网络市场开发和营销都是个良好基础,如果放眼将来,安全性绝对是很重要  
:   的部分。 从这个意义上而言,128bit的加密是个必备的选择。  

最后想说的一点就是,不同的系统有不同的侧重点,要想做好一个系统,必须  


要权衡到各种利弊进行通盘的考虑,也许我们看问题的出发点不同,我们做的  


是一个系统,而你看到的只是这个系统的某一个方面,因此我觉得在没有进行  


全面细致地考虑的情况下就作出“很差”评价是不太负责任的。  

-------------------------------------------


--
※ 来源:.月光软件站 http://www.moon-soft.com.[FROM: 202.109.32.2]

[关闭][返回]