个人专题目录
10. 网络通信与协议
10.1 http和https的区别，https原理，http2.0与1.0的区别
HTTP和HTTPS的区别
HTTPS：是以安全为目标的HTTP通道，简单讲是HTTP的安全版，即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。
HTTPS协议的主要作用可以分为两种：一种是建立一个信息安全通道，来保证数据传输的安全；另一种就是确认网站的真实性。
两者主要区别如下：
- https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。
- http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。
- http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
- http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。
HTTP/2采用二进制格式而非文本格式
HTTP/2是完全多路复用的，而非有序并阻塞的——只需一个连接即可实现并行
使用报头压缩，HTTP/2降低了开销
HTTP/2让服务器可以将响应主动“推送”到客户端缓存中
1.多路复用和二进制帧
HTTP 性能优化的关键并不在于高带宽，而是低延迟。TCP 连接会随着时间进行自我「调谐」，起初会限制连接的最大速度，如果数据成功传输，会随着时间的推移提高传输的速度。这种调谐则被称为 TCP 慢启动。由于这种原因，让原本就具有突发性和短时性的 HTTP 连接变的十分低效。
HTTP/2 通过让所有数据流共用同一个连接，可以更有效地使用 TCP 连接，让高带宽也能真正的服务于 HTTP 的性能提升。
2.首部压缩
在 HTTP/1 中，HTTP 请求和响应都是由「状态行、请求 / 响应头部、消息主体」三部分组成。一般而言，消息主体都会经过 gzip 压缩，或者本身传输的就是压缩过后的二进制文件（例如图片、音频），但状态行和头部却没有经过任何压缩，直接以纯文本传输。
头部压缩需要在支持 HTTP/2 的浏览器和服务端之间：
- 维护一份相同的静态字典（Static Table），包含常见的头部名称，以及特别常见的头部名称与值的组合；
- 维护一份相同的动态字典（Dynamic Table），可以动态的添加内容；
- 支持基于静态哈夫曼码表的哈夫曼编码（Huffman Coding）；
10.2 Http报文格式
Http请求报文格式：1.请求行 2.Http头 3.报文主体
请求行由三部分组成，分别是请求方法，请求地址，Http版本
Http头：有三种，分别为请求头（request header），普通头（General Header）和实体头（entity header）。Get方法没有实体头。
报文主体：只在POST方法请求中存在。
Http响应报文：1.状态行 2.Http头 3.返回内容
状态行：第一部分为Http版本，第二部分为响应状态码 第三部分为状态码的描述
其中第三部分为状态码的描述，信息类100-199 响应成功200-299 重定向类300-399 客户端错误400-499 服务器端错误500-599
常见的
100 continue 初始请求已接受，客户端应继续发送请求剩余部分
200 OK
202 Accepted 已接受，处理尚未完成
301 永久重定向
302 临时重定向
400 Bad Request
401 Unauthorized
403 Forbidden 资源不可用
404 Not Found
500 Internal Server Error 服务器错误
502 Bad Gateway
503 Service Unavailable 服务器负载过重
504 Gateway Timeout 未能及时从远程服务器获得应答
Http头：响应头（Response Header），普通头（General Header）和实体头(Entity Header)
返回内容：即Http请求的信息，可以是HTML也可以是图片等等。
10.3 TCP连接建立和释放的过程
SYN置1和FIN的报文段要消耗一个序号。
客户端连接状态变迁：CLOSED -> 主动打开,发送SYN=1 -> SYN_SENT -> 收到服务器的SYN=1和ACK时,发送三次握手的最后一个ACK
-> ESTABLISHED -> 数据传送 -> 主动关闭 -> 发送FIN=1,等待确认ACK的到达 -> FIN_WAIT_1 -> 收到确认ACK后 -> FIN_WAIT_2
-> 收到服务器发送的FIN=1报文，响应，发送四次挥手的的最后一个确认ACK -> 进入TIME_WAIT状态
-> 经过2倍报文寿命，TCP删除连接记录 -> 回到CLOSED状态
客户端状态：CLOSED - SYN_SENT- ESTABLISHED - FIN_WAIT_1 - FIN_WAIT_2 - TIME_WAIT - CLOSED
服务器端连接状态变迁：CLOSED -> 被动打开 -> LISTEN -> 收到SYN=1的报文，发送SYN=1和确认ACK -> 进入SYN_RCVD -> 收到三次握手
的最后一个确认ACK -> ESTABLISHED -> 数据传送 -> 数据传送完毕，收到FIN=1 -> 发送确认ACK并进入CLOSED_WAIT -> 发送FIN=1给客户端 -> LAST_ACK
-> 收到客户端四次挥手的最后一个确认ACK -> 删除连接记录 -> 回到CLOSED状态
服务器端：CLOSED - LISTEN - SYN_RCVD - ESTABLISHED - CLOSED_WAIT - LAST_ACK - CLOSED
10.3.1 TCP的三次握手和四次挥手的过程
以客户端为例
连接建立（三次握手）：首先Client端发送连接请求报文SYN并进入SYN_SENT状态，Server收到后发送ACK+SYN报文，并为这次连接分配资源。Client端接收到Server端的SYN+ACK后发送三次握手的最后一个ACK，并分配资源，连接建立。
连接释放（四次挥手）：假设Client端发起断开连接请求，首先发送FIN=1,等待确认ACK的到达 -> FIN_WAIT_1 -> 收到Server端的确认ACK后时 -> FIN_WAIT_2
->收到服务器发送的FIN=1报文，响应，发送四次挥手的的最后一个确认ACK ->进入TIME_WAIT状态
-> 经过2倍报文寿命，TCP删除连接记录 -> 回到CLOSED状态
10.3.2 为什么连接建立是三次握手，而连接释放要四次挥手？
因为当Server端收到Client端发送的SYN连接请求报文后，可以直接发送SYN+ACK报文，其中ACK用来应答，SYN用来同步。但是关闭连接时，当Server端收到FIN报文后，并不会立即关闭socket，所以先回复一个ACK，告诉Client端“你的FIN我收到了”，只有等Server端的所有报文发送完了，Server端才发送FIN报文，因此不能一起发送，故需要四次挥手。
10.3.3 为什么TIME_WAIT状态需要2MSL（最大报文段生存时间）才能返回Closed状态？
这是因为虽然双方都同意关闭连接了，而且四次挥手的报文也都协调发送完毕。但是我们必须假想网络是不可靠的，无法保证最后发送的ACK报文一定被对方收到，因此处于LAST_ACK状态下的
Server端可能会因未收到ACK而重发FIN，所以TIME_WAIT状态的作用就是用来重发可能丢失的ACK报文。
10.4 Post和Get的区别
- 安全性上说：get的方式是把数据在地址栏中明文的形式发送，URL中可见，POST方式对用户是透明的，安全性更高。
- 数据量说：Get传送的数据量较小，一般不能大于2KB，POST传送的数据量更大。
- 适用范围说：查询用Get，数据添加、修改和删除建议Post
- post请求的过程：
- 浏览器请求tcp连接（第一次握手）
- 服务器答应进行tcp连接（第二次握手）
- 浏览器确认，并发送post请求头（第三次握手，这个报文比较小，所以http会在此时进行第一次数据发送）
- 服务器返回100 Continue响应
- 浏览器发送数据
- 服务器返回200 OK响应
- get请求的过程：
- 浏览器请求tcp连接（第一次握手）
- 服务器答应进行tcp连接（第二次握手）
- 浏览器确认，并发送get请求头和数据（第三次握手，这个报文比较小，所以http会在此时进行第一次数据发送）
- 服务器返回200 OK响应
10.5 Cookie 和 Session的区别
- cookie数据存放在客户的浏览器上，session数据放在服务器上。
- cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗
考虑到安全应当使用session。 - session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能
考虑到减轻服务器性能方面，应当使用COOKIE。 - 单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。
- 所以个人建议：
将登陆信息等重要信息存放为SESSION
其他信息如果需要保留，可以放在COOKIE中
10.6 IO 和 NIO的区别，NIO优点
IO NIO
面向流 面向缓冲
阻塞IO 非阻塞IO
无 选择器
10.7 一致性 Hash 算法
https://www.cnblogs.com/lpfuture/p/5796398.html