tcp进程处理失败的连接的方法是：1. 超时重传；2. 快速重传；3. sack 重传。其中，发送方有两种选择：a，默认 3 发送失败，重新发送3；b ，默认 3 4 5 发送失败，重传 3 4 5。
一、tcp进程处理失败的连接的方法
1.超时重传
发送方不知道3 4 5 的接收情况，接收方一直在等 3，这中方式会有比较严重的问题。
发送方有两种选择：
A，默认 3 发送失败，重新发送3
b，默认 3 4 5 发送失败，重传 3 4 5
a的方式，只传 3可能会慢，b的方式传 3 4 5 很快但是占用带宽，timeout也可能很长，这两个都不是最后的方法。
2.快速重传
tcp还有一种快速重传的算法，Fast-Retransmit是以数据驱动重传，不是timeout时间驱动。
怎么是以数据驱动呢？
就是如果只收到 1 2 ，回复ack 3 ，随后收到了 4 5 但是还没收到 3， 4 5的ack也回复 3 3，这样发送方会收到3个一样的ack，会知道传输出了问题
这就是大部分tcp数据驱动重传机制（什么？大部分tcp，总共是有几个版本的..）。
这种方式还不是较好的，只是解决了timeout的问题，回传的个数还是没解决，比如一次发了20条，就不知道是哪3个发的ack了，需要回传这20条。。
3.sack 重传
选择性重传，Selective Acknowledgement（sack），tcp的头会多一个SACK，快速重传的ACK还在。
sack只回复已经到达的碎片，这样发送端就能准确知道是重传那部分字节流。在Linux可以用tcp_sack这个字段开启这个功能，2.4版之后的Linux默认开启。
延伸阅读：
二、服务器进程终止处理方法
当服务器进程终止时，客户TCP允许接着把数据发送给服务器。TCP允许这么做，因为客户TCP接收到FIN只是表示服务器进程已关闭了连接的服务器端，从而不再往其中发送任何数据而已。FIN的接收并没有告知客户TCP服务器进程已经终止。
当服务器TCP接收到来自客户的数据时，既然先前打开的那个套接字的进程已经终止，于是响应以一个RST。
然而客户看不到这个RST，因为它在调用writen后立刻调用了readline，并且由于第二步中接收的FIIN，所调用的readline立刻返回0(表示EOF)。我们的客户此时并为预期收到EOF，于是以出错信息，“server terminated prematurely”（服务器过早终止）退出。
我们的上述讨论还取决于本例子的时序。客户调用readline即可能发生在服务器在的RST被客户接收到之前，也可能发生在接收到之后，如果readline发生在收到RST之前（那么客户接收到的是一个为预期的EOF；否则结果是由readline返回一个ECONNRESET 对方复位连接错误）。
以上就是关于tcp进程如何处理失败的连接的内容希望对大家有帮助。
