TCP没那么难吧?这篇一定要看
想到了这个问题就值得恭喜,因为你不是只满足于“知其然”,而希望“知其所以然”。不过我们也需要想到,既然TCP连接的建立和终止都是同一批人定义的,既然他们能想到在建立连接时节省一步,那么他们没有理由在终止连接时不做节省。之所以没有“节省”,一定是有理由存在的。 没错,确实是有理由的,而且这个理由很好理解,因为建立和终止连接的场景是不一样的。在建立连接之前,客户端和服务器端都不会向对方发送任何数据,所以在服务端返回ACK的时候带上SYN,客户端当然知道这是从服务端收到的第一个数据包。 而在结束连接时,客户端向服务端发送FIN,表示“我这边不会继续发送数据过来了”,服务端响应ACK,这都没有问题。但此时,服务端之前向客户端发送数据的操作可能还没有完成,服务端仍然在向客户端传输数据。如果服务端把FIN和ACK合并起来,就会出现这样的情况:客户端的数据还没有接受完,忽然收到服务端的消息“后续没有数据了,终止连接”。显然,这种情况不应当出现,所以不能把ACK和FIN合并在一起,所以终止连接必须要四步。 最近和实习生聊天,说起开发中遇到的各种问题,以及对应的模型,大家听得入迷。事后有人问我:为什么我们工作中遇不到这么有意思的问题呢?我知道,这是个比较典型的问题。其实答案也很典型:因为你没有去深究问题背后的原型。懂得了背后的原型,就具备了“从已知推导无知”的本领,也具备了“从无知中发现已知”的眼光。 我和朋友聊开发有个共同的判断:TCP的握手和挥手看起来简单,但真让如今的开发人员去设计握手和挥手流程,估计有超过一半的人设计不出稳定、可靠、高效的握手和挥手流程。这样说来,许多业务系统里业务层面的通讯极不可靠,协议设计错漏百出,也是无奈的结果了。 补充一句。我曾在面试中遇到过这样的人,非名校毕业,已经有五年工作经验,除了对流行的框架和热点问题对答如流,对数据库理论、网络基础知识、数据结构和算法依然如数家珍。事实充分证明,不是所有人工作之后就把大学的知识丢个精光的,事实也证明,这样的候选人确实能担大任。 【编辑推荐】
点赞 0 (编辑:惠州站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |