Unix/Linux编程：要认识到TCP是一个可靠的，但不绝对可靠的协议

古城微笑少年丶 2022-10-08 12:26 107阅读 0赞

TCP是一个可靠的协议。有种说法是“TCP能够保证它所发送的数据的可靠传输”，这不是很恰当。比如对端崩溃时，数据就永远不可能到达对端。

那怎么理解这句话呢？

# 可靠性：是什么，不是什么 #

在考虑TCP中可能出现的各种故障模式之前，要弄清楚TCP的可靠性意味着什么。如果TCP不能保证将提交给它的所有数据都传送出去，又能保证什么呢？是向谁保证？如下图所示，数据流从应用程序A通过它所在主机的TCP/IP栈向下传输，经过几台中间路由器，通过应用程序B所在的主机的TCP/IP栈向上传输，最后抵达应用程序B。一个TCP段离开应用程序A所在的主机的TCP层时，会被封装到一个IP数据报中，传递给对等主机。它可能需要经过很多路由器，这些路由器没有TCP层，它们只是转发了IP数据报  
![在这里插入图片描述][20210621165611182.png]  
我们知道IP是个不可靠的协议，那就应该很清楚，在数据传输路径上，第一个可以讨论**确保可靠传输问题的地方就是应用程序B所在主机的TCP层**。当一个段到达应用程序B所在主机的TCP层时，唯一可以确定的就是这个段已经到达了，但它可能损坏了，可能是重复的数据，可能是错序的，或者是其他一些原因无法接收的。注意，发送端TCP无法对这些抵达接收端TCP的段做出任何保证

但接收方TCP要向发送方TCP确认，也就是说它ACK的数据以及在此数据之前到达的所有数据在TCP层已经正确收到了，发送端TCP可以安全的删除这些数据的副本了，这并不意味着已经将数据传送，或者总是可以将数据传送给应用程序。比如，接收端主机可能在刚刚对数据进行了ACK，但应用程序还没有将其读走之前，就崩溃了。这个问题值得进一步讨论：TCP向发送端提供的唯一一个数据接收通知就是这个ACK。发送端应用程序无法从TCP自身排队对等实体应用程序是否真的收到数据了。稍后我们会说明，这是应用程序编写者要弄清楚的一种TCP故障模式。

另一个可以**确保可靠传输问题的地方是应用程序B**。我们知道，无法保证应用程序A发送的所有数据都会到达。**TCP能够向应用程序B保证的是所有到达的数据都是按序而且未受损的**

> 因特网校验和仅仅能够确保数据未损坏

# 故障模式 #

前面我们已经提到过一种TCP故障模式了：**TCP已经ACK了数据实际上可能不会抵达目的应用程序**。和我们要讨论的大部分故障模式一样，这是相当罕见的事情，即使发生这种事情，影响也不会太严重。重要的是网络程序员需要知道这种可能性的存在，要对(各种)故障模式可能带来的不良后果有所预防。要避免这样一种看法：TCP会做好一切准确，我们不需要为应用程序协议的健壮性操作。

前面讨论的故障模式由很明确的解决方案。对应用程序来说，明确的知道对端收到了某个特定的报文是非常重要的，其对端就必须将收到的报文通知给发送端。通常，这种确认信息都是隐式的。比如，如果客户端向服务器请求了一些数据，服务器进行了响应，那么，这个响应就隐式的确认收到了原始请求。 技巧：考虑两条TCP连接介绍了一种处理显示服务器确认的方式。

一个更难解决的问题是如果服务器没有对收到的报文进行确认，客户端会怎么做？当然，这与特定的网络程序由很大关系，没有一个统一的解决方案。但我们应该注意到，仅仅重发请求可可能无法解决问题（比如，我们不可能请求银行进行两次转换）。数据库系统使用三阶段提交协议来处理这种类型的问题，某些应用程序可能会使用类似的策略来确保操作“最多执行一次”。

TCP是一个端对端协议，也就是说它自己要在对等体之间提供可靠的传输机制。但是，认识到“端点”位于对等的TCP层，而不是对等的应用程序是非常重要的。要求进行段堆段确认的应用程序必须自身提供此项功能。

其他常见故障模式：**只要两个对等实体仍然连着，TCP就能保证将数据按序、无损坏的传送。只有连接中断时才会出现故障**。什么类型的事件会造成这种中断呢？有三种情况可能会引发此类问题

*  永久或者临时的网络中断
 *  对等的实体程序邓肯
 *  运行对等应用程序的主机崩溃

我们会看到，在发送端应用程序中，这些事件会以不同的方式显示出来

## 网络中断 ##

路由器或者骨干链路损毁，网线送了…很多原因都会造成网络的中断。在端点之外发生的损毁往往是临时的，因为路由协议会发现问题，并使路由绕开出问题的节点。

> 这里的端点(endpoint)是指应用程序所处的LAN或者主机

端点出问题时，通常没有备用路径，所以问题会一直存在，直到端点修复为止。

除非中间路由发送一条ICMP报文，说明目的网络或者主机不可达，否则应用程序及其TCP/IP栈都无法立即知道中断的发送。在这种情况下，发送端最终会超时，并重新发送所有未被确认的段。在发送端TCP放弃发送，丢弃连接并报告错误之前会一直持续这种操作。在传统BSD栈中，发送端TCP会重传12次(大约9分钟)之后放弃。

## 对等实体程序崩溃 ##

> 如果对等实体程序崩溃或者终止，会发生什么情况？

首先要意识到从应用程序的角度来看，对等实体崩溃和对等实体调用close以及exit是无法区分的。在这两种情况下，对等实体的TCP都会向我们的TCP发送一个FIN。FIN作为EOF使用，表示发送它的那一端已经没有数据要发送了（这并不一定表示发送FIN的这端已经退出了，甚至无法说明它不愿意接收更多数据）。如果需要通知的话，如何通知应用程序收到了FIN要取决于FIN到达时它正在做什么事情。为了说明可能发生的各种情况，我们构建了一个小型的TCP客户端，可以从stdin读取一行数据，将其发送给一台服务器，读取服务器的应答，并将其写入stdout。

下面是TCP客户端，用于读入并写出数据行：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70]

*  8-9：将应用程序作为TCP客户端初始化，并将其连接到命令行指定的服务器和端口上去。
 *  10-15：从stdin读入一行数据，并将其发送给服务器，直到在stdin上收到EOF为止
 *  16-20：向服务器发送数据之后，读入一行应答。readline函数会从套接字读取数据，直到遇到一个换行符位置。如果对readline的调用失败或者返回了一个EOF，就输出一条诊断信息并退出
 *  22：否则，将应答写入stdout

为了测试这个客户端程序，我们编写了一个服务端，这个服务器只是循环的从客户读入行，并返回一些报文说明它收到了多少行数据。为了模拟服务器端的处理延迟，在收到报文和发送应答之间睡眠了5秒：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 1]  
要了解服务器崩溃时会发生什么情况，测试上面程序(客户端)其效果如下：  
![在这里插入图片描述][20210621175626742.png]  
向服务器发送一条报文，5s之后会得到预期的应答。此时，杀死服务器进程，模拟一次服务器崩溃。客户端不会发生任何事情，因为客户端被阻塞在了fgets调用上，而TCP无法通知客户端它已经从另一端收到了一个EOF(FIN)。如果没有其他事情发生，客户端会永远阻塞在对fgets的调用上，无法得知对端已经终止了。

接下来，在客户端上再输入一行数据。客户端会立即失效，说明服务器主机已经重置了连接。实际上客户端从fgets返回时，还是不知道服务器发来了EOF。对应用程序来说，在收到FIN之后发送数据时完全合法的，因此，客户端的TCP栈会尝试向服务器发送第二行数据。TCP到数据之后，由于连接已经不复存在了，所以它会恢复RST（重置），此时服务器已经终止了。客户端调用readline时，内核会返回一个ECONNRESET错误来通知客户端收到了一条重置消息。如下显示了这些事件的时间线  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 2]

> 如果服务器在完成对请求的处理并应答之前就崩溃了，会发生什么情况？

![在这里插入图片描述][20210621180250827.png]  
向服务器发送一行数据，然后在服务器从对sleep的调用中醒来之前终止。这样可以模拟服务器在处理完请求之前就崩溃的情况。这一次，客户端会立即收到错误消息，什么服务器已经终止了。在这里，收到FIN时，客户阻塞在对readline的调用中，而TCP只要让readline返回一个EOF就可以立即通知客户端。时间线如下：

![在这里插入图片描述][20210621180447960.png]  
如果忽略了连接重置错误并继续发送数据，就会出现第三种情况。为了模拟这种情况，对跟在readline的后面的errno调用进行修改，使其输出一条诊断信息但并不退出。也就是说，客户端的第17行修改为：  
![在这里插入图片描述][20210621180708522.png]  
然后重新运行第一个测试，代码如下：  
![在这里插入图片描述][20210621180724203.png]  
输入第二数据行时，客户端会像以前一样立即报告同样的错误(连接被对等实体重置了)，但是它并没有终止。相反，它又调用了一次fgets以解析出给服务器的输入。输入第三行数据时，客户端会立即终止，从shell可知，我们被SIGPIPE信号终止了。在这种情况下，像以前一样，第二次发送会引发一个RST，不过我们将其忽略了。但收到这个RST之后，TCP会丢弃连接，所以在试图发送第三行数据时，它会立即调用SIGPIPE信号终止客户端。

## 对等实体的主机崩溃 ##

这种故障模式与对等实体程序崩溃不同，因为对等实体的TCP无法通过FIN来通知我们的应用程序，其对等实体已经不在运行了。

在对等实体主机重启之前，这个错误看起来和网络故障一样：对等实体的TCP不再应答了。和网络故障的情况一样，我们的应用程序TCP会持续重传未经确认的段。最终，如果对等实体主机没有重启，它就会放弃并向应用程序返回一条ETIMEDOUT错误、

如果在我们的TCP放弃并丢弃连接之前，对等实体主机就重启了，会发生什么情况呢？在这种情况下，会有重传的段到达对等实体刚刚重启的主机，而这台主机没有连接记录。在这种情况下，TCP技术规范要求接收端主机应答一个RST。这样发送端主机才会丢弃连接，应用程序才会收到一个ECONNRESET错误或者在下一条写操作是得到一个SIGPIPE信号或者EPIPE错误

[20210621165611182.png]: /images/20221005/8099bb9cc9b044e0af47d123bfc1ba83.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70]: /images/20221005/0a79bb671e254559897d4326863d253a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 1]: /images/20221005/b8225f108dde4c389c7cbc1de3e9233a.png
[20210621175626742.png]: /images/20221005/db323ccef95c46119d6dfa34df3971cb.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 2]: /images/20221005/5354860ff61247f087ff0fa7b843c63a.png
[20210621180250827.png]: /images/20221005/f3c8d6ca564146768df3dc1911b36029.png
[20210621180447960.png]: /images/20221005/0056ad257d714097a37de5f0bb29c7cb.png
[20210621180708522.png]: /images/20221005/ab9ef6c48c3747ca8d7e00450d604b0e.png
[20210621180724203.png]: /images/20221005/f78b71f1fa3e4967b945458065a5a9ff.png