HTTP/HTTPS连接过程

HTTP（TCP）连接

三次握手：

1. 客户端发送SYN包到服务端，等待服务端确认；
2. 服务端确认接收SYN包，并发送回来一个SYN+ACK包给客户端；
3. 客户端确认接收，并向服务端发送确认包ACK，连接建立。

为什么是三次握手？？？

因为三次握手是保证client和server端均让对方知道自己具备发送和接收能力的最小次数：

1. client–>server：server确认client具备发送能力
2. server–>client：client确认服务端具备接收和发送能力
3. client–>server：server确认client具备接收能力

那为什么每次还要发送SYN或者ACK？？？

这是为了保证每一次的握手都是对上一次握手的应答，每次握手都会带一个标识 SEQ，后续的ACK都会对这个SEQ进行加一来进行确认。也就是保证每次的握手双方都是同一个”人”，而不是中途被替换了。

四次挥手

1. Client主动发起一个Req给Server，里面包含FIN标识位=1，CLient的Seq序列号N，表示的是当前Client在该连接上的当前序列号；
2. Server端在收到这个含有FIN的Req消息之后，校验无误之后会立马回复ACK消息给CLient端，消息内部包含ACK标志位为1，同时Seq号码是FIN的请求消息的Seq号+1。此时的Sever同时会主动发个结束标识给Server上面的应用层程序，应用层程序可以决定是立马结束，还是等到服务其上面的该连接中的数据处理完了之后，在发送FIN消息给Client来关掉另外的一半连接；
3. Server端在处理完该连接上面的Pending住的数据之后，应用程序会close这个连接。Client会主动发起FIN的Req消息给Client端。消息内部带有，FIN=1的结束符标识位，以及Server端的Seq序列号；
4. Client端在收到对应的FIN消息之后，会主动通知应用层程序，告知这个连接现在需要关闭了。然后，Client会回复ACK消息给Server，以便断开另外一个方向的通道，这个消息包含ACK=1的标识位和FIN的REQ带过来的Seq+1。

为什么是四次挥手？

因为TCP是一个全双工协议，必须单独拆除每一条信道。4次挥手的目的是终止数据传输，并回收资源，此时两个端点两个方向的序列号已经没有了任何关系，必须等待两方向都没有数据传输时才能拆除虚链路，不像初始化时那么简单，发现SYN标志就初始化一个序列号并确认SYN的序列号。因此必须单独分别在一个方向上终止该方向的数据传输。

如果是三次挥手，会怎么样？三次的话，被动关闭端在收到FIN消息之后，需要同时回复ACK和Server端的FIN消息。如果Server端在该连接上面并没有Pending的消息要处理，那么是可以的，如果Server端还需要等待一段时间才可以关闭另外一个方向的连接，那么这样的三次挥手就不能满足条件。

HTTPS建立连接

https在http的基础上添加了ssl/tls这一层来保证双方的可信任和数据传输的安全性，其中ssl是网景公司提出来的，3.0版本之后被互联网标准化组织ISOC接替，发布了ssl的升级版tls1.0。

ssl/tls的协议的基本思路是采用公钥加密法，客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。

如何保证公钥不被篡改

将公钥放在数字证书中，只要证书可信，公钥就是可信的

非对称加密太耗时，如何提高性能

传输内容时使用对称加密，但是在交换对话密钥的时候采用非对称加密来保证密钥传输的安全性

HTTPS建立连接基本流程

首先是和http一样的tcp连接3次握手，然后是ssl/tls连接建立：

1. 客户端发起https请求，服务端返回数字证书和公钥，服务端保留私钥（同时发送tls版本和支持的加密算法）；
2. 客户端收到相应后，对数字证书进行校验，通过的话本地生成一个随机数，这个随机数就是以后传输内容对称加密使用到的密钥，然后用公钥加密后发送给服务端；
3. 服务端接收后用自己的私钥进行非对称解密，拿到客户端的随机数；
4. 服务端将双方协定的对称密钥和加密算法发送给客户端，至此tls建立连接。

所以https的连接建立需要7步。