TCP为什么是个可靠的协议

  一直以来，我们都被告知TCP是可靠的。但为什么是可靠的，很多人都会说“三次握手、四次挥手”。然后我们就进入一个误区：TCP可靠是因为它在建立链路时进行了“多次”地确认。然后又有人问，“多次确认就可靠了吗？”专家想了一会，说：“这只是相对的……”

  回顾一下，网络书籍里面有一个很著名的问题，“红军和蓝军通信联合进攻山下的敌军的例子，第一天红军发了条信息要蓝军第二天一起进攻，蓝军收到之后，发一条确认信息，但是蓝军担心的是‘确认信息’如果也不可靠而没有成功到达红军那里，那自己不是很危险？于是红军再发一条‘对确认的确认信息’，但同样的问题还是不能解决，红军仍然不敢贸然行动。”这个问题简直就是故意在讽刺“三次握手”。

 根据这个故事回到“三次握手”，客户在第三次ACK后，他想，“万一服务器没有收到怎么办呢？”这个问题只能让服务器再发一个应答来解决，然后服务器就会遇到同样的一个问题，如此不断地纠结下去……而事实上，TCP连接建立时只到客户第三次ACK就结束了，这能说是“可靠”的协议吗？

  如果按照“红军蓝军问题”的思路想下去，那就没出路了。就该问题目前的条件而言，是永远没有结果的，因为信息发送方在对方不应答的前提之下，永远不能保证对方是否已经收到，不管信息发送多少次。实际打仗时，最终就只能演变成“默契”问题了，“默契”有没有办法用逻辑来解释，不管大家知不知道，反正我是不知道的。

  那TCP难道是不可靠的?其实不然。理解的误区就在网络协议和行军打仗的差异上。

  庆幸的是，网络协议和军队打仗是不一样的，军队打仗时如果不能确保消息的正确传递和步调同步，那是不能轻易出动的，人死不能复生啊。但是数据发送异常后可以重发，这不存在问题。另外，客户端在发送数据时，只要确保服务器已经收到数据就可以了，不需要服务器关心客户端是否收到应答。这一点也是和“红军蓝军问题”不一样的，这就不会造成死循环的问题。

  具体理解一下，网络协议中，客户端和服务器在发送数据时并不要求两端要同时发送数据，甚至两端发送的数据内容也不存在必然的联系。不像两军进攻，要讲究目的相同，出发时间相同。细细分析，TCP在发送数据时，都只关心对端是否已经收到自己发送的数据，即只要收到对方对自己发送的数据确认就可以了。换句话说，每一端（客户端或者服务器）都很“自私”，只保证对方已经收到自己发送的数据就OK了。

  按照上面的说法，分析一下TCP交互的过程。客户要进入ESTABLISHED，因此，客户端发送SYN告诉服务器要打开链路，收到ACK后，表示服务器已经同意了，OK，客户进入ESTABLISHED状态。只是客户建立连接不行啊，服务器还没进入ESTABLISHED状态呢，所以服务器在应答时一并发送了自己的SYN，收到客户端的ACK后，自己才进入ESTABLISHED状态，然后才可以接受客户端发过来的数据。

  然后，分析一下数据传输时，数据发送方在收到应答后，表示对方收到数据了，自己就可以将刚才发送过的数据清空了。无需再告诉对方，我已经收到你的应答了，没有意义。同样的，四次挥手也同样符合上述说法。

  又要回到起初的问题了，“三次握手”第三个ACK应答丢失了怎么办？现在应该很好理解，第三个ACK其实是对服务器SYN的应答，应答丢了，服务器就不得不重发SYN。又有人要问，万一重发后还是没ACK怎么呢，其实，这是没关系的，这个时候服务器等待ACK超时，自然会把套接口关掉，置为异常状态。如果后面客户端发送的数据到达，服务器也会响应RST，来告诉客户端这一异常，而不是ACK客户端过来的数据。客户端和服务器不需要像打仗那样保持同步（一同进入ESTABLISHED），只要各自能够兼容状态不同步带来的异常就可以了。

  最后回到最根本的问题，TCP是否是个可靠的协议，答案是肯定的。TCP保证的是自己的行为被别人确认，而不是确认别人的应答。这里所谓的行为便是“我要SYN”、“我要发送数据”、“我要FIN”……在网络编程中，时刻存在着“主-从”关系，这两者的地位不是固定的，谁发生了行为谁就是“主”，谁接受了行为就是“从”，“主”在乎的是“从”之后的应答，而“从”在乎的是“主”实际的行为。对于正常的行为与应答，他们就可取所需，完成一次正常的交互和状态变迁；对于异常的行为，“从”不给出“主”最在乎的应答，给出相应的错误提示；对于异常的应答，“主”做出相应的反应（比如通知应用进程关闭套接字）。