理解 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 是无状态的，客户端不知道服务端回复的是啥，就没理。
- 服务端就在一直等待中：这个死鬼的情书到底是写给谁，怎么不回复我。于是服务端憔悴至死（资源浪费）
然后是三次握手的情况：
扫描二维码关注公众号，回复：
1122838 查看本文章
- 客户端写了一封情书： 我中意你啊（建立连接的请求），但是因为某些原因，有句放假啦，你的情书被搁置在路上了
- 客户端没有收到回复，于是又写了一封情书：我真的好中意你啊（建立连接的请求）
- 服务端收到了这封情书的回复：哇，我也中意你啊，mua
- 客户端收到了服务端的 mua ：好啊，那我们就在一起吧（真正建立连接）
- 到这时，客户端和服务端已经可以愉快的玩耍了。但是忽然，客户端写的第一封情书也到了，服务端看到了，依然回复了句： 死鬼，我知道了
- 客户端一看，这是错了： 这是情书发错了，别再等了
三次握手的基本情况都老实交代了了，就那样。
四次分手
然后是四次分手，这个就简单的多：
- 客户端和服务端腻歪了，就说要分手，客户端：分手吧 （关闭连接的请求）
- 服务端：分就分，但是还有你的一些破东西，还给你（传递向客户端待发送的数据）
- 客户端收到回复了，就原地待命
- 服务端数据发送完了：好了，都扔了（数据发送完毕）
- 客户端接收到数据，然后给个回复：好的，我知道了，拜拜。
以上都是抖机灵的理解。其实 TCP 的三次连接和四次分手要复杂的多，可以参考以下正经的博客：