白话 TCP 三次握手与四次分手的过程

这里写链接内容理解 HTTP 协议以及 TCP 三次握手与四次分手的过程
理解 HTTP 协议
超文本传输 ​​ 协议(HTTP)是用于传输诸如 HTML 的超媒体文档的应用层协议,最顶层的协议。HTTP 是无状态协议,意味着服务器不会在两个请求之间保留任何数据(状态)。

关于无状态的理解

可以理解为 HTTP 是没有上下文的,HTTP 无法保存连接双方的状态信息。基于此,知乎上有看到一个很直观的白话例子:

参考:HTTP 是一个无状态的协议。这句话里的无状态是什么意思?

有状态无状态使用 cookie
A:你今天中午吃的啥?A:你今天中午吃的啥A:你今天中午吃的啥
B:吃的大盘鸡B:吃的大盘鸡。B:吃的大盘鸡。
A:味道怎么样呀?A:味道怎么样呀?A:味道怎么样呀?
B:还不错,挺好吃的。B:???啊?啥?啥味道怎么样?B:还不错,挺好吃的

TCP 三次握手与四次分手
TCP 建立连接的时候需要三次握手,断开连接需要四次分手,这个过程是比较抽象的。

整个过程简单白话一下就是:

三次握手
客户端写了一封情书: 我中意你啊(建立连接的请求)
服务端收到了这封情书的回复:哇,我也中意你啊,mua
客户端收到了服务端的 mua :好啊,那我们就在一起吧(真正建立连接)
当然上面这是正常的情况,如果遇到情书发错人(连接出错)的情况,服务端就懒得理了,然后双发就不可能在一起(建立连接)。

为什么 TCP 连接需要三次握手

当然其实会有更多的人疑问,为什么 TCP 连接需要三次握手而不是两次,因为按照上面的意思,客户端来一句:在一起, 服务端回一个:好, 就可以了啊,为什么客户端还要多此一举回复一个“我也好”呢。其实原因很简单,跟 TCP 的特性有关,TCP 通道是不可靠的,而三次握手是满足通道安全的最小握手次数。继续用上面的例子来分析下:

先假设只有两次握手的情况:

客户端写了一封情书: 我中意你啊(建立连接的请求),但是因为某些原因,邮局放假啦,你的情书被搁置在路上了
客户端没有收到回复,于是又写了一封情书:我真的好中意你啊(建立连接的请求)
服务端收到了这封情书的回复:哇,我也中意你啊,mua(建立连接)
到这时,客户端和服务端已经可以愉快的玩耍了。但是忽然,客户端写的第一封情书也到了,服务端看到了,依然回复了句: 死鬼,我知道了
因为 HTTP 是无状态的,客户端不知道服务端回复的是啥,就没理。
服务端就在一直等待中:这个死鬼的情书到底是写给谁,怎么不回复我。于是服务端憔悴至死(资源浪费)
然后是三次握手的情况:

客户端写了一封情书: 我中意你啊(建立连接的请求),但是因为某些原因,有句放假啦,你的情书被搁置在路上了
客户端没有收到回复,于是又写了一封情书:我真的好中意你啊(建立连接的请求)
服务端收到了这封情书的回复:哇,我也中意你啊,mua
客户端收到了服务端的 mua :好啊,那我们就在一起吧(真正建立连接)
到这时,客户端和服务端已经可以愉快的玩耍了。但是忽然,客户端写的第一封情书也到了,服务端看到了,依然回复了句: 死鬼,我知道了
客户端一看,这是错了: 这是情书发错了,别再等了
三次握手的基本情况都老实交代了了,就那样。

四次分手
然后是四次分手,这个就简单的多:

客户端和服务端腻歪了,就说要分手,客户端:分手吧 (关闭连接的请求)
服务端:分就分,但是还有你的一些破东西,还给你(传递向客户端待发送的数据)
客户端收到回复了,就原地待命
服务端数据发送完了:好了,都扔了(数据发送完毕)
客户端接收到数据,然后给个回复:好的,我知道了,拜拜。
以上都是抖机灵的理解。其实 TCP 的三次连接和四次分手要复杂的多,可以参考以下正经的博客:

通俗大白话来理解 TCP 协议的三次握手和四次分手
关于 TCP 的三次握手和四次分手(整理)

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值