http(TCP)三次握手四次挥手：
三次握手：
SYN：同步位。SYN=1 表示进行一个连接请求。
ACK：确认位。ACK=1 表示确认有效，ACK=0 表示确认无效。
ack：确认号。等于对方发送的序号+1。
seq：序号。
握手过程：
- 客A主动发起一个连接请求，即 SYN=1 ，同时带上一个随机生成的序号 x ，即 seq=x。
- 服B在收到请求后进行响应，也将 SYN 设为 1 ，同时确认客A的请求有效，即 ACK=1 ，ack=x+1，将自己随机生成的序号y也传给客A，即 seq=y。
- 客A在收到服B的响应后作出反应，确认有效即 ACK=1，ack=y+1，seq=x+1（因为客A中间没有再向服B发送数据所以x没有改变）。
- 客A和服B进行数据传输。
为什么要是三次握手？
因为三次握手是保证client和server端均让对方知道自己具备发送和接收能力的最小次数。
为什么每次还要发送SYN或者ACK？
为了保证每一次的握手都是对上一次握手的应答，每次握手都会带一个标识 seq，后续的 ack 都会对这个 seq 进行加一来进行确认。也就是保证每次的握手双方都是同一个对象，防止中途被替换了。
四次挥手：
FIN：FIN=1 即断开连接并且客A会不再向服B发送数据。
挥手过程：
- 客A主动发起关闭，即 FIN=1，同时带上随机生成的随机数u，即 seq=u。
- 服B收到请求后进行响应，确认请求有效，即 ACK=1，ack=u+1，同时带上自己生成的随机数 v，即 seq=v。此时服B并没有完全关闭，而是处于半关闭的状态，仍旧能够向客A发生未发送完的数据。
- 当服B把需要发送的数据发送完后就进行剩下的关闭请求操作，即 FIN=1，ACK=1，ack=u+1，因为处于半关闭状态的服B可能对客A发送了数据，所以序号不确定，即 seq=w。
- 客A收到服B的信息后作出响应，即 ACK=1，ack=w+1，因为中间客A没有再进行数据传输所以 u 不变，即 seq=u+1。
- 客A等待一段时间后完成挥手。
推荐视频：TCP协议三次握手与四次挥手
https(SSL/TLS)握手：
HTTPS建立连接基本流程：首先是和http一样的tcp连接3次握手，然后是ssl/tls连接建立。
握手过程：
- 浏览器向服务器发起加密请求，同时传送浏览器支持的协议版本，浏览器随机生成的随机数random1，以及支持的加密方法。
- 服务器收到请求后在获取到的协议版本中选择自己也支持的版本，例如：TLS1.2，选定同样支持的加密方式，例如：RSA，连同自己生成随机数random2和服务器数字证书一起传给浏览器。
- 浏览器收到数字证书后并确认证书合法，使用证书中的公钥加密浏览器随机生成的随机数random3。此时浏览器已经有三个随机数：random1，random2和random3，三个随机数生成此次的会话秘钥。将之前握手的消息生成摘要，然后用生成的会话秘钥加密，然后将被公钥加密的随机数random3，被会话秘钥加密的摘要发送给服务器，同时进行编码变更，告知浏览器端的握手过程已经结束，随后的信息交流都使用各自生成的会话秘钥进行加密交流。
- 服务器收到消息后，使用私钥进行random3的解密，获取第三个随机数，然后也生成此次的会话秘钥，使用会话秘钥对加密的摘要信息进行解密，证明双方生成的会话秘钥是一致的。再将之前的握手信息也生成摘要，使用自己生成的会话秘钥进行加密，将加密的摘要发送给浏览器，同时编码变更以及完成服务器端的握手过程。
- 浏览器接收到加密的摘要后，使用会话秘钥进行解密，确保双方生成的会话秘钥是一致的。
- 接下来就是使用各自生成的会话秘钥进行对称加密的数据传输。
如何保证公钥不被篡改？
将公钥放在数字证书中，只要证书可信，公钥就是可信的。
非对称加密太耗时，如何提高性能？
在生成会话秘钥之前使用非对称加密来保证密钥传输的安全性，在生成会话秘钥之后则使用会话秘钥进行对称加密来保证传输内容的安全性。
为什么要三个随机数？
因为浏览器和服务器各自生成的随机数可能不随机，但是三个伪随机数能够更加接近真实的随机数。
怎么验证数字证书有效？
数字证书有效性验证
推荐视频：简明 HTTPS 协议