为什么TCP是个可靠的协议?

 

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

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

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

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

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

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

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