一直以来,我们都被告知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”……在网络编程中,时刻存在着“主-从”关系,这两者的地位不是固定的,谁发生了行为谁就是“主”,谁接受了行为就是“从”,“主”在乎的是“从”之后的应答,而“从”在乎的是“主”实际的行为。对于正常的行为与应答,他们就可取所需,完成一次正常的交互和状态变迁;对于异常的行为,“从”不给出“主”最在乎的应答,给出相应的错误提示;对于异常的应答,“主”做出相应的反应(比如通知应用进程关闭套接字)。