标签：处理 http 释放 -- 分享图片 内容 led 兴趣 协议
之前在张神的QQ群里偶尔间聊到了关于这个的问题，我这里写一下我所认知的三次握手&四次挥手，若有错误之处，请路过的大佬们指正。
首先简单的科普一下什么是三次握手，什么是四次挥手。
1、三次握手：
C-->S：[SYN] 在么 syn:synchronization(同步)
S-->C：[SYN,ACK] 在 ack:acknowledgement(确认:告知已收到)
C-->S：[ACK] 知道了 fin:finish(结束)
2、四次挥手：
C-->S：[FIN] 我要关闭连接了
S-->C：[ACK] 知道了，等我先把数据发完
S-->C：[FIN] 我也关闭连接了
C-->S：[ACK] 好的，知道了
首先明确一点，TCP协议是一种可靠的传输层协议，而http协议是属于应用层的协议。所谓的三次握手和四次挥手是针对TCP连接来说的。建立TCP连接时，会发生三次握手，用来保障通讯双方有通信的基础。关闭TCP连接时会发生四次挥手，用来保障通讯双方可以安全的释放TCP通信的数据。
那么为什么时常听到有人说“为什么http请求需要三次握手&四次挥手”?
这句话本身是有点毛病的，就像上面说的，三次握手与四次挥手针对的是TCP连接，http协议本身是不会去关注这一块的，也不会去处理任何的[SYN]、[ACK]、[FIN]等。仅仅是因为现有的http协议用的是TCP作为传输层(http协议没有规定具体使用哪个传输层协议)，我去百度翻了一波HTTP 1.1 RFC 261，找了段话，见下图
所以如果传输层使用的不是TCP的话，那就不一定是有三次握手之类的。
--------------------------------------分隔线---------------------------------------
PS：五一放假，开发们都跑了，Bug都没人改，点个外卖继续写点什么吧。
https，是以安全为目标的HTTP通道，简单的来说就是http的安全版。可以这样理解https=http+SSL(TLS)。那么https是怎么来保证安全的呢，说一个故事吧：
1、A和B通信，通过信鸽传送。
这种情况下，第三者C可以截获信鸽得知AB之间的通信内容。
2、为了防止这种情况，AB约定用一种加密方式进行信息的传输。（对称加密）
但是这种情况下，AB见不到面，约定的这个加密方式如何通知对方呢？
3、A先把信鸽给B，然后B收到信鸽寄回一个开着的盒子，钥匙在B自己手中。然后A把信放进盒子，锁上寄送给B。B收到之后用钥匙打开阅读信的内容。(术语中，盒子称之为公钥，打开盒子的钥匙称之为私钥)(非对称加密)
这种情况，又会有一个新的问题，如何确定这个盒子是B给的？
4、B可以在盒子上签名做个标记
这种情况，C可以通过模仿B的签名来更改盒子而获得通信的内容。
5、找个会给任何人签名且所有人都信任他只会对确定的合法的人签名标记盒子。即这个人只有真正确定要签名的人是B，才会在盒子上签上属于B的标记(术语中，这个人称之为认证机构)
故事说完了，说的不是很详细。有兴趣的看客，可以专门去看看对应的书籍，这里只是做一个简单的科普说明。上面用颜色标记了两个名词，这里简单解释下：
1)对称加密：同一个密钥可以同时用作信息的加密和解密，也称之为单密钥加密。简单的来说就是你知道加密方式，那么你也就知道了解密方式。
2)非对称加密：区别于对称加密，需要两个密钥来进行加密和解密，这两个秘钥是公开密钥(简称公钥)和私有密钥(简称私钥)。
非对称加密和对称加密相比，安全性更好(毕竟不需要像对称加密那样在通信之前先同步秘钥)。但是它的加解密消耗时间长，速度慢，性能不佳，只适合少量数据的加密。所以实际应用场景中，一般用非对称加密来传输对称加密的密钥。
以上，就是这篇博客的全部了。要去点点点了......
___山水一程，三生有幸
标签：处理 http 释放 -- 分享图片 内容 led 兴趣 协议
原文地址：https://www.cnblogs.com/zichuan/p/8966648.html
