我用UDP实现TCP内核代码的话，　性能会降低多少?

最近看了<<TCP/IP详解>>, 想用UDP的用户层函数实现TCP的内核代码, 不知同样的功能在用户层实现会比内核实现慢多少?
希望了解的指点一下

解决方案 »

  1.   

    其实自己实现那些功能也是有目的的
    因为偶要用到多播功能,无奈TCP不支持多播，所以只好用UDP实现超时重发，流量控制等功能了，但又不知道万一这么多代码会降低性能，听说TCP协议实现代码有8000行的哦
      

  2.   

    我写过TCP协议,性能影响和你编程水平有关,如果有OS作者的水平,性能降低不多,如果内存管理,最重要的是流缓冲写的效率不高,那性能就不可像想了,实际上,最好的解决办法,根据你的实际需要设计一个仿TCP的协议,才是最可行的
      

  3.   

    TCP别人不做多播是有理由的,你强行用udp来做tcp,还不如在下层直接改tcp协议呢
      

  4.   

    因为偶要用到多播功能,无奈TCP不支持多播，所以只好用UDP实现超时重发，流量控制等功能了
    ---------------------------------------------------------------------
    我想问一下，多播怎么实现超时重发收到就发应答包？
    有一个结点没收到如何重发？
      

  5.   

    有延时发送ack啊， 并不是随时都要发送ack, server专门一个线程收ack固定通知主线程就行了
    当然如果在固定时间没有收到就认为那个是受到错误的包了
      

  6.   

    就是客户端没有收到数据报，就发ACK。
    但是有一个结点没收到如何重发？多个节点没有收到如何重发？
      

  7.   

    UDP广播一般是在局域网内的,重发ACK的机会不多,效率我想还行,如果网络环境不行,那效率就很低了
      

  8.   

    UDP的效率肯定比ＴＣＰ高的
    在上层封装ＵＤＰ实现ＴＣＰ功能是很常用的一种方法，也就是所说的可靠ＵＤＰ，一般ＩＭ传语音视频或文件都采用这种方法。如果实现好的话，绝对比单纯使用ＴＣＰ高，不会慢。因为可以自己控制丢包，重传，排序
      

  9.   

    你这个我觉得做起开可行性不大
    既然多播
    如果100个人接受数据
    99个收到了
    1个没收到
    你是否需要重新发送呢
    这样可就造成了巨大的浪费啊 
    多播基于UDP是有道理的
    如果非要搞个可靠多播
    不如让你所有的多播接收者组织成环状或者树状
    使用一些P2P技术进行多播呢
      

  10.   

    "UDP的用户层函数实现TCP的内核代码" ,是不是要实现udp的可靠传输啊?
    我写过类似的代码,传输速度没有达到TCP的速度,原因是水平时间有限.
    个人认为实现udp的可靠传输速度超过TCP是可能的,要针对应用优化算法,不要想完全实现TCP的算法. 比如应用于文件传输,就可以有针对性的优化,适当增大滑动窗口,优化三次握手过程,增加选择确认,在慢启动过程中适当调节拥塞窗口初始值....多播,组播了解还不够深入,感觉还只适用于局域网.如果要实现UDP的应用层组播,应该还有更多问题值得大家探讨.
      

  11.   

    我也曾经想做过同样的事，目的不是为了多播而是为了穿透NAT的可靠数据传输。然后实现起来确实有一定的难度，可惜的是我没有做完就不得不采用其它方式来替代这个方法，所以最后也不知道到底效率如何！希望你能成功，有机会大家探讨一下。
      

  12.   

    如果是用UDP在用户空间实现TCP功能效率肯定会低,原因如下
    1.楼主的水平肯定没有OS内核和TCP协议栈开发人员高.
    2.TCP一般是集成在内核中实现的,效率较高.UPD来实现TCP在内核和用户态切换的次数肯定会多于TCP,增加了系统开销.TCP实现中 ACE包,传输确认,超时重传都是在内核中完成.自己实现的所有的这些工作都会在用户层计算,然后在通过内核->驱动->网卡 发送数据多了一个用户向内核切换的过程.
    3.数据传输环节少.很多高性能的程序直接把网络数据拷贝到用户空间(win32的完成端口等),如果是与用UDP来实现.数据发送和接受都不可能做到zero-copy.
    当然以上这只是效率问题.
    对于大多数需要使用UDP来做可靠传输的可能更多考虑nat穿透,传输实时,系统的效率并非主要的考虑的.
      

  13.   

    与其用UDP实现TCP，何不直接在TCP层做类似多播的事情。例如，你要发送给100个结点，用TCP一一发即可
      

  14.   

    tcp绝对有值得改进的地方,比如返回确认的范围.
    我认为udp模仿tcp一定要根据具体应用优化.
      

  15.   

    基本同意 neil78duan(失落得程序员) 的说法
      

  16.   

    同意楼上的.我所说的主要是从host(主机)效率肯定会下降.如果单从单一系统(自己在UDP基础上开发的可靠连接)的角度上来说发送接受的速度也许会很好,但是对整个网络来说也许是灾难.因为当网络拥塞的时候你还在拼命的发送,那可能会舍弃大我成就小我.呵呵!
    从我的测试来看网络传输从发送到接受的时间两者几乎看不到差别.但没有验证当网络吞吐量大的时候主机和网络的传输速度!
      

  17.   

    那你可以试试用DUP的方式来传输文件
    如果不出意外的话,你收到的文件根本无法使用
    因此,你不得不编写个程序,实现发送方和接受方对包的序号进行检测,和排序是不是增加了很多开销?性能你说降低了多少?