tcp三次握手与四次分手
2018-02-28 14:31:18
理解 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 的三次连接和四次分手要复杂的多,可以参考以下正经的博客: