做C/S模式的程序，客户端和服务器端之间采用TCP通讯，是那种实时控制的程序，应该怎么避免出现数据包丢失的情况？经实际测试，确实有可能发送的数据包，接收端没有收到或者校验和错误。 我现在用的方法是接收端接收到数据包后，给发送端再发送一个确认包，如果发送端没有收到确认包，则重发，相当于一次握手。不过我觉得这种方法第一时间比较长，效率不高。第二网络流量会增加一倍。 各位有没有什么好的实现方法来处理的？
调试欢乐多
我知道TCP本身有握手确认，但是实际测试中，还是有几率出现数据包丢失的情况，我需要保证不能出现丢包的情况
更安全的就用SSL (Secure Socket Layer)
SSL协议的工作流程：
服务器认证阶段：1）客户端向服务器发送一个开始信息“Hello”以便开始一个新的会话连接；2）服务器根据客户的信息确定是否需要生成新的主密钥，如需要则服务器在响应客户的“Hello”信息时将包含生成主密钥所需的信息；3）客户根据收到的服务器响应信息，产生一个主密钥，并用服务器的公开密钥加密后传给服务器；4）服务器恢复该主密钥，并返回给客户一个用主密钥认证的信息，以此让客户认证服务器。
用户认证阶段：在此之前，服务器已经通过了客户认证，这一阶段主要完成对客户的认证。经认证的服务器发送一个提问给客户，客户则返回（数字）签名后的提问和其公开密钥，从而向服务器提供认证。
这个应该主要是保证数据的安全性的吧，如果服务器端发送一条控制命令，但是客户端没有收到，用SSL 服务器端能知道么？
若是有丢包，它自己会重发
2.包里增加连续的seq号
也就是窗口最大 2n， 当在较短的时间内对方收到 x个包（x<N），只要确认最后那个x就可以了，发送方得到x，就发送x以后的包，如规定时间内没收到，则重新发送 上次x之后的包
接收方收到后，要判断重复部分的包，加以丢弃
兄弟，这个是TCP需要保证的事，如果你想这么做，就感觉脱裤放屁，多此一举了，
TCP就是可以保证先发送的包，不丢包，且一定按顺序送到，如果TCP做不到，你无论做什么努力也是没有用，因为硬件网络出问题了，这个软件是没有办法解决。 不需要做些没有必要做的事，不过，如果你的这个提法是针对UDP的话，这个贴子可以继续讨论
基本上是由于发送方和接收方速度不匹配造成缓冲溢出非对称丢包特性对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,由于涉及到丢包过程的
细节而无法直接讨论.因为这种细节会随网络配置不同而变化,很难找到统一的办法来为之
建模.因此我们采用把丢包率作为已知条件,从而回避了这个问题.因此本文的模型可以说
考虑了所有由非对称性而引起的主要因素.
............