为什么三次握手和四次挥手？

http协议流程
1、域名解析
2、TCP三次握手
3、建立连接后发起请求
4、服务端响应请求，返回给浏览器数据
5、浏览器解析html代码，同时请求资源（图片）
6、浏览器进行渲染
7、TCP四次挥手

1、TCP为什么要三次握手？

三次握手（一种情况正常，二种情况由于网络原因C第一次发的短信S没收到）
C：“你看得到我给你发的短信吗？”
S：“我看得到呀，你看得到我给你发的短信吗？”
C：“我能看到，balabalabala”

C：“你看得到我给你发的短信吗？”
C：“你看得到我给你发的短信吗？”//重新发送
S：“我看得到呀”
C：“balabalabala”
C说完断开连接，这时S看到之前的短信，又发了过去，但不能重新建立起连接【因为三次握手需要C的确认，而C认为第一次发送的短信已经失效了，所以不会确认】
S：“我看得到呀，我们可以重新建立连接吗？”
C没有回应，没有重新建立连接

两次握手（一种情况正常，二种情况由于网络原因C第一次发的短信S没收到）
C：“你看得到我给你发的短信吗？”
S：“我看得到呀”
C：“balabalabala”

C：“你看得到我给你发的短信吗？”
C：“你看得到我给你发的短信吗？”//重新发送
S：“我看得到呀”
C：“balabalabala”
C说完断开连接，这时S看到之前的短信，又发了过去，重新建立起连接【因为两次握手不需要C的确认】
S：“我看得到呀，我们重新建立连接吧”
C：“…”

四次握手
C：“你看得到我给你发的短信吗？”
S：“我看得到呀，你看得到我给你发的短信吗？”
C：“我能看到，你看得到我给你发的短信吗？”
C：“…不想跟傻逼说话”

三次握手主要防止已经失效的连接请求报文突然又传送到了服务器，从而产生错误。

假设有这样一种场景，客户端发送了第一个请求连接并且没有丢失，只是因为在网络结点中滞留的时间太长了，由于TCP的客户端迟迟没有收到确认报文，以为服务器没有收到，此时重新向服务器发送这条报文，此后客户端和服务器经过两次握手完成连接，传输数据，然后关闭连接。此时此前滞留的那一次请求连接，网络通畅了到达了服务器，这个报文本该是失效的，但是，两次握手的机制将会让客户端和服务器再次建立连接，这将导致不必要的错误和资源的浪费。

二次握手会导致滞留的那一次请求连接重新让客户端和服务器再次建立连接，这将导致不必要的错误和资源的浪费。

四次握手会显得多余

2、TCP为什么要4次挥手

C：“我要断开连接了”
S：“等一下，等我把话说完着”
S：“我说完了”
C：“好，那我断开连接了”
C说完又等了一会没有再收到S的消息，也断开了连接

详细可以看这篇文章https://blog.csdn.net/dreamispossible/article/details/91345391?utm_medium=distribute.pc_aggpage_search_result.none-task-blog-2_alltop_click~default-2-91345391.nonecase&utm_term=%E5%9B%9B%E6%AC%A1%E6%8C%A5%E6%89%8B&spm=1000.2123.3001.4430