110,539
社区成员
发帖
与我相关
我的任务
分享网络通讯可靠性怎么保证？
做C/S模式的程序，客户端和服务器端之间采用TCP通讯，是那种实时控制的程序，应该怎么避免出现数据包丢失的情况？经实际测试，确实有可能发送的数据包，接收端没有收到或者校验和错误。
我现在用的方法是接收端接收到数据包后，给发送端再发送一个确认包，如果发送端没有收到确认包，则重发，相当于一次握手。不过我觉得这种方法第一时间比较长，效率不高。第二网络流量会增加一倍。
各位有没有什么好的实现方法来处理的？
我现在用的方法是接收端接收到数据包后，给发送端再发送一个确认包，如果发送端没有收到确认包，则重发，相当于一次握手。不过我觉得这种方法第一时间比较长，效率不高。第二网络流量会增加一倍。
各位有没有什么好的实现方法来处理的？
...全文
请发表友善的回复…
发表回复
ttianqq 2009-11-28
- 打赏
- 举报
继续研究研究
soaringbird 2009-11-27
- 打赏
- 举报
可以要求接收方回发确认包，但不是收到后马上回发，而是处理完毕（比如解析、保存到数据库中等之类的处理）后发送。发送方如果超时未收到确认包，就重发数据。确认包就不用重发机制了，一方重发即可。
zzmwmh 2009-11-27
- 打赏
- 举报
怎样也不能保证100%吧
ttianqq 2009-11-27
- 打赏
- 举报
[Quote=引用 4 楼 cuike519 的回复:]
TCP不是可靠连接么...
什么情况丢包？握手是TCP本身协议规定的，TCP本身就要求握手和确认，如果你是建立在TCP上的通信上可以认为是可靠连接。
如果是UDP需要确认数据包是否送达，UDP的可靠性要应用层来完成。
[/Quote]
我知道TCP本身有握手确认，但是实际测试中，还是有几率出现数据包丢失的情况，我需要保证不能出现丢包的情况
TCP不是可靠连接么...
什么情况丢包？握手是TCP本身协议规定的，TCP本身就要求握手和确认，如果你是建立在TCP上的通信上可以认为是可靠连接。
如果是UDP需要确认数据包是否送达，UDP的可靠性要应用层来完成。
[/Quote]
我知道TCP本身有握手确认，但是实际测试中，还是有几率出现数据包丢失的情况，我需要保证不能出现丢包的情况
cuike519 2009-11-27
- 打赏
- 举报
TCP不是可靠连接么...
什么情况丢包？握手是TCP本身协议规定的，TCP本身就要求握手和确认，如果你是建立在TCP上的通信上可以认为是可靠连接。
如果是UDP需要确认数据包是否送达，UDP的可靠性要应用层来完成。
什么情况丢包？握手是TCP本身协议规定的，TCP本身就要求握手和确认，如果你是建立在TCP上的通信上可以认为是可靠连接。
如果是UDP需要确认数据包是否送达，UDP的可靠性要应用层来完成。
zhnzzy 2009-11-27
- 打赏
- 举报
socket通讯看看
ttianqq 2009-11-27
- 打赏
- 举报
[Quote=引用 1 楼 yangjianpro163 的回复:]
给发送端再发送一个确认包，如果发送端没有收到确认包，则重发，
--------------------------
那如果确实发了确认包，而这个确认包在中途丢包了，怎么办？ 也重发？
[/Quote]
对 目前是这么处理的，只要发送端没有收到确认包，就重发，接收端接收到了重复的数据包不处理就行了。
觉得这样处理比较复杂，想找一个高效安全的方式
给发送端再发送一个确认包，如果发送端没有收到确认包，则重发，
--------------------------
那如果确实发了确认包，而这个确认包在中途丢包了，怎么办？ 也重发？
[/Quote]
对 目前是这么处理的，只要发送端没有收到确认包，就重发，接收端接收到了重复的数据包不处理就行了。
觉得这样处理比较复杂，想找一个高效安全的方式
yangjianpro163 2009-11-27
- 打赏
- 举报
给发送端再发送一个确认包，如果发送端没有收到确认包，则重发，
--------------------------
那如果确实发了确认包，而这个确认包在中途丢包了，怎么办？ 也重发？
--------------------------
那如果确实发了确认包，而这个确认包在中途丢包了，怎么办？ 也重发？
jnyds 2009-11-27
- 打赏
- 举报
关注中……
CGabriel 2009-11-27
- 打赏
- 举报
TCP 协议是面向连接的协议，只会断线，绝不丢包。
由于 TCP 是一个基于流的程序，所以很多不成熟的程序都无法 100% 正确地重组数据报。
因此，很多人“以为” 是网络丢包。
图书馆或者书店有大量关于 TCP 协议具体实现的书籍，上面说的很详细。
由于 TCP 是一个基于流的程序，所以很多不成熟的程序都无法 100% 正确地重组数据报。
因此，很多人“以为” 是网络丢包。
图书馆或者书店有大量关于 TCP 协议具体实现的书籍，上面说的很详细。
wartim 2009-11-27
- 打赏
- 举报
TCP也会丢包，只要知道为什么，就能有针对性地处理
基本上是由于发送方和接收方速度不匹配造成缓冲溢出
非对称丢包特性对TCP吞吐量的影响
http://cache.baidu.com/c?m=9f65cb4a8c8507ed4fece76310478027474380146b80c7150892d213cf3101061471e3cc70745713d3b22d3b1ccf1e1eb7b0706f44426be6fdb9ea57aefad97949f94523706bc41746c75cf28b102a8771d24de9de0e97bee741e0b9a2d1c82022dd53746df0f69c290403bb6de76347&p=8978c64ad78911a05fafc6377f&user=baidu
............
2. 非对称信道对TCP产生影响的方面
在进行模型分析前,我们必须考察非对称性给TCP带来的各种影响.从而比较这些影
响的严重程度,并在建模中体现其中重要的因素.非对称性对TCP的影响一般体现在,由
于回传链路传送确认包的能力不足,从而干扰了TCP源端对网络状态的估计,进而影响新
数据包的发送,最终导致TCP性能下降.其主要影响有:
1) 降低窗口增长速度.由于TCP仅在收到有效确认时,才调用其增长窗口函数.
确认包丢失造成有效确认变少,从而导致窗口增长速度减慢,降低了链路利用率.
2) 增加前向链路突发.由于受拥塞窗口的限制,TCP只有在收到新的有效确认时,
才能发送新的数据包.再回传路径带宽不足或高误码率是,很容易发生确认包丢
失.而本该发送的新数据,由于确认包丢失则不能发送.当后续确认到达源端时,
原来待发的数据就会和新确认所对应的数据包同时发出,造成突发.当丢失较多
的确认包后有效确认到达时,源端就有可能在短时间内发送过多的数据,造成前
向链路缓存溢出,产生丢包.
3) 降低快速恢复算法的成功概率(增加了超时重传的概率).TCP只有在收到三个重
复确认后才进入快速恢复.而在恢复过程中,源端仍然需要持续地收到确认包,
以完成快速恢复.因此,快速恢复能够成功的一个必要条件是源端能够收到足够
的确认包.而非对称性使确认包丢失的概率大大增加,从而降低了快速恢复的成
功率.
对于以上因素,因素1和3是可以在模型中讨论的.而对于2,由于涉及到丢包过程的
细节而无法直接讨论.因为这种细节会随网络配置不同而变化,很难找到统一的办法来为之
建模.因此我们采用把丢包率作为已知条件,从而回避了这个问题.因此本文的模型可以说
考虑了所有由非对称性而引起的主要因素.
............
基本上是由于发送方和接收方速度不匹配造成缓冲溢出
非对称丢包特性对TCP吞吐量的影响
http://cache.baidu.com/c?m=9f65cb4a8c8507ed4fece76310478027474380146b80c7150892d213cf3101061471e3cc70745713d3b22d3b1ccf1e1eb7b0706f44426be6fdb9ea57aefad97949f94523706bc41746c75cf28b102a8771d24de9de0e97bee741e0b9a2d1c82022dd53746df0f69c290403bb6de76347&p=8978c64ad78911a05fafc6377f&user=baidu
............
2. 非对称信道对TCP产生影响的方面
在进行模型分析前,我们必须考察非对称性给TCP带来的各种影响.从而比较这些影
响的严重程度,并在建模中体现其中重要的因素.非对称性对TCP的影响一般体现在,由
于回传链路传送确认包的能力不足,从而干扰了TCP源端对网络状态的估计,进而影响新
数据包的发送,最终导致TCP性能下降.其主要影响有:
1) 降低窗口增长速度.由于TCP仅在收到有效确认时,才调用其增长窗口函数.
确认包丢失造成有效确认变少,从而导致窗口增长速度减慢,降低了链路利用率.
2) 增加前向链路突发.由于受拥塞窗口的限制,TCP只有在收到新的有效确认时,
才能发送新的数据包.再回传路径带宽不足或高误码率是,很容易发生确认包丢
失.而本该发送的新数据,由于确认包丢失则不能发送.当后续确认到达源端时,
原来待发的数据就会和新确认所对应的数据包同时发出,造成突发.当丢失较多
的确认包后有效确认到达时,源端就有可能在短时间内发送过多的数据,造成前
向链路缓存溢出,产生丢包.
3) 降低快速恢复算法的成功概率(增加了超时重传的概率).TCP只有在收到三个重
复确认后才进入快速恢复.而在恢复过程中,源端仍然需要持续地收到确认包,
以完成快速恢复.因此,快速恢复能够成功的一个必要条件是源端能够收到足够
的确认包.而非对称性使确认包丢失的概率大大增加,从而降低了快速恢复的成
功率.
对于以上因素,因素1和3是可以在模型中讨论的.而对于2,由于涉及到丢包过程的
细节而无法直接讨论.因为这种细节会随网络配置不同而变化,很难找到统一的办法来为之
建模.因此我们采用把丢包率作为已知条件,从而回避了这个问题.因此本文的模型可以说
考虑了所有由非对称性而引起的主要因素.
............
烈火蜓蜻 2009-11-27
- 打赏
- 举报
[Quote=引用楼主 ttianqq 的回复:]
做C/S模式的程序，客户端和服务器端之间采用TCP通讯，是那种实时控制的程序，应该怎么避免出现数据包丢失的情况？经实际测试，确实有可能发送的数据包，接收端没有收到或者校验和错误。
我现在用的方法是接收端接收到数据包后，给发送端再发送一个确认包，如果发送端没有收到确认包，则重发，相当于一次握手。不过我觉得这种方法第一时间比较长，效率不高。第二网络流量会增加一倍。
各位有没有什么好的实现方法来处理的？
[/Quote]
兄弟，这个是TCP需要保证的事，如果你想这么做，就感觉脱裤放屁，多此一举了，
TCP就是可以保证先发送的包，不丢包，且一定按顺序送到，如果TCP做不到，你无论做什么努力也是没有用，因为硬件网络出问题了，这个软件是没有办法解决。 不需要做些没有必要做的事，
不过，如果你的这个提法是针对UDP的话，这个贴子可以继续讨论
做C/S模式的程序，客户端和服务器端之间采用TCP通讯，是那种实时控制的程序，应该怎么避免出现数据包丢失的情况？经实际测试，确实有可能发送的数据包，接收端没有收到或者校验和错误。
我现在用的方法是接收端接收到数据包后，给发送端再发送一个确认包，如果发送端没有收到确认包，则重发，相当于一次握手。不过我觉得这种方法第一时间比较长，效率不高。第二网络流量会增加一倍。
各位有没有什么好的实现方法来处理的？
[/Quote]
兄弟，这个是TCP需要保证的事，如果你想这么做，就感觉脱裤放屁，多此一举了，
TCP就是可以保证先发送的包，不丢包，且一定按顺序送到，如果TCP做不到，你无论做什么努力也是没有用，因为硬件网络出问题了，这个软件是没有办法解决。 不需要做些没有必要做的事，
不过，如果你的这个提法是针对UDP的话，这个贴子可以继续讨论
NealXX 2009-11-27
- 打赏
- 举报
Up,学习了
卧_槽 2009-11-27
- 打赏
- 举报
把你网线拔了，你怎么保证都没用
ximengchang 2009-11-27
- 打赏
- 举报
1、数据加密传输
2、做数据验证
可以参考易宝支付
2、做数据验证
可以参考易宝支付
littlegang 2009-11-27
- 打赏
- 举报
tcp的可靠连接，是保障了单次包发送的可靠
lz要实现tcp之上的可靠性，可以参考tcp里面的“窗口”确认方式
也就是窗口最大 2n， 当在较短的时间内对方收到 x个包（x<N），只要确认最后那个x就可以了，发送方得到x，就发送x以后的包，如规定时间内没收到，则重新发送 上次x之后的包
接收方收到后，要判断重复部分的包，加以丢弃
lz要实现tcp之上的可靠性，可以参考tcp里面的“窗口”确认方式
也就是窗口最大 2n， 当在较短的时间内对方收到 x个包（x<N），只要确认最后那个x就可以了，发送方得到x，就发送x以后的包，如规定时间内没收到，则重新发送 上次x之后的包
接收方收到后，要判断重复部分的包，加以丢弃
CPU_2 2009-11-27
- 打赏
- 举报
呵呵，我最近也做了一个C#winform的DEMO,也是关于SOCKET的就是客户端和服务器的问题,客户端在登录的时候输入用户名和密码,发送给服务器,服务器验证,如果通过则发送成功的信息给他,如果失败则发送失败的消息给他,客户成功登录后可以进行其它的相关操作,比较要修改自已的密码,然后又发送消息给服务器,服务器依据作出响应,然后执行完后又返回给客户端提示成功与否,然后客户端的客户还可以在客户端进行有权限的数据信息查看,(这也要发信息给服务器,服务器收到信息后按要求返回信息给客户端)这样的一个过程.现在我客户端用到的是异步,服务器也用异步,但客户端好像写得有问题,所以真诚的请教一下楼主能不能加我QQ383638323备注（SOCKET）,请教一下，谢谢！
Red_angelX 2009-11-27
- 打赏
- 举报
1.增加确认包.
2.包里增加连续的seq号
2.包里增加连续的seq号
ttianqq 2009-11-27
- 打赏
- 举报
[Quote=引用 11 楼 wodegege10 的回复:]
TCP协议已经保证了数据的完整性
若是有丢包，它自己会重发
[/Quote]
在实际测试中，还是会有发送端发送的命令，接收端没有收到，或者收到的效验和不正确的情况，很少，但是有，我现在需要可靠
TCP协议已经保证了数据的完整性
若是有丢包，它自己会重发
[/Quote]
在实际测试中，还是会有发送端发送的命令，接收端没有收到，或者收到的效验和不正确的情况，很少，但是有，我现在需要可靠
zuoming120 2009-11-27
- 打赏
- 举报
d
加载更多回复（4）
