# HTTP2新特性

# 二进制分帧

# 首部压缩

# 流量控制

# 多路复用

# 请求优先级

# 服务器推送

# 如何升级HTTP2

TODO

# HTTPS

# https协议过程

1. 爱丽丝给出协议版本号、一个客户端生成的随机数（Client random），以及客户端支持的加密方法。
2. 鲍勃确认双方使用的加密方法，并给出数字证书、以及一个服务器生成的随机数（Server random）。
3. 爱丽丝确认数字证书有效，然后生成一个新的随机数（Premaster secret），并使用数字证书中的公钥，加密这个随机数，发给鲍勃。
4. 鲍勃使用自己的私钥，获取爱丽丝发来的随机数（即Premaster secret）。
5. 爱丽丝和鲍勃根据约定的加密方法，使用前面的三个随机数，生成"对话密钥"（session key），用来加密接下来的整个对话过程。

# TCP三次握手过程

# 为啥需要三次?

主要是为了防止失效的连接请求报文段突然又传送到了B, 因为产生错误

不用三次, 你的意思就是用两次咯? 总不能一次就行了吧? OK, 那就解释为啥子两次不行:

假设一种情况, A发出了一个连接请求, 然后由于网络延迟卡在某个地方了, A的第一次请求发出去没有得到B的ACK确认, TCP不是有超时重发吗对吧? 所以A再一次发出去一个连接请求, 这次很正常, B收到连接请求, 回复A, A收到B的确认信号之后, 连接建立, 开始传送数据. 劈里啪啦, 一顿操作猛如虎, 数据传输完成, 连接断开, 各回各家, 各找各妈. 假设这个时候, 之前A一开始发出的那个卡壳的连接信号, 跨越山海, 终于千里迢迢风尘仆仆赶到了B, B就会误以为这是A又发出来的一个新的连接请求, 于是回复A, 当确认信号到达A的时候, A当然不理会B的这个确认请求, 心里还默默咒骂B是傻冒. 因为B在回复A之后, 就默认连接建立了, 在傻乎乎的占用系统的资源等待A进行数据传输. 说到这, 就已经能够推翻为啥子两次连接不行了吧~

# TCP四次挥手

# 为啥需要四次挥手?

一句话: 不能像握手那样, 一次性回复ACK和FIN(握手是一次性回复ACK和SYN)

因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。

# 为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？

一句话: 需要确认server收到了client的ACK并关闭了

网络是不可靠的, 假设Client发出的最后一个ACK丢包了, 由于Server没有收到ACK, 会重发FIN报文. 所以, Client是不能立刻关闭的, 它必须确认Server收到了它的ACK. 否则, Server端可能永远关闭不了连接! Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器，等待2MSL的时间。如果在该时间内再次收到FIN，那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。