HTTP和HTTPS
简述一次完整的Http请求过程
通过域名请求后————>DNS域名解析为ip地址————>中间路由跳转————>直接访问ip地址进行三次握手————>tcp三次握手成功后进行通信响应———>tcp四次挥手结束通信
客户端：
- 在浏览器输入网址。
- 浏览器解析网址，并生成http请求消息。
- 浏览器调用系统解析器，发送消息到DNS服务器查询域名对应的ip。
- 拿到ip后，和请求消息一起交给操作系统协议栈的TCP模块。
- 将数据分成一个个数据包，并加上TCP报头形成TCP数据包。
- TCP报头包括发送方端口号、接收方端口号、数据包的序号、ACK号。
- 然后将TCP消息交给IP模块。
- IP模块会添加IP头部和MAC头部。
- IP头部包括IP地址，为IP模块使用，MAC头部包括MAC地址，为数据链路层使用。
- IP模块会把整个消息包交给网络硬件，也就是数据链路层，比如以太网，WIFI等。
- 然后网卡会将这些包转换成电信号或者在光信号，通过网线或者光纤发送出去，再由路由器等转发设备送达接收方。
服务器端：
- 数据包到达服务器的数据链路层，比如以太网，然后会将其转换为数据包（数字信号）交给IP模块。
- IP模块会将MAC头部和IP头部后面的内容，也就是TCP数据包发送给TCP模块。
- TCP模块会解析TCP头信息，然后和客户端沟通表示收到这个数据包了。
- TCP模块在收到消息的所有数据包之后，就会封装好消息，生成相应报文发给应用层，也就是HTTP层。
- HTTP层收到消息，比如是HTML数据，就会解析这个HTML数据，最终绘制到浏览器页面上。
简述三次握手和四次挥手
三次握手：
客户端发送一个随机seq=100
服务端返回一个随机seq=200，ack=100+1
客户端返回一个ack=200+1
四次挥手：
客户端发送一个FIN=1，seq=100
服务端发送一个ack=100+1
服务端发送一个FIN=1，seq=200
客户端发送一个ack=200+1
服务端发送两次的原因是需要等待服务器处理当前任务完毕。
为什么需要三次握手而不是2次或者4次？
防止已失效的连接请求又传送到服务器端，因而产生错误
两次的话，服务端是不知道自己的请求是否成功发送到客户端的。但是服务端又会认为连接建立成功了。假设第二次丢失了，客户端认为服务端没有响应，就会重发一次，这样已经失效的连接请求就会传送到服务端。
tcp是可靠的双方通信协议，所以双方都会生成一个初始的序列号供双方确认，如果改成两次，只会确定客户端对于服务端具有可靠性，而服务端对客户端没有可靠性
四次的话，太过繁琐
为什么握手需要三次？挥手却需要四次？
因为挥手的时候需要等待服务器将本次连接中的所有保文都处理完，在发送关闭状态，说白了，服务器需要等待自身进入可关闭状态
握手可以携带数据信息吗？
第三次请求可以携带数据信息，客户端认为连接已经建立的，就可以携带参数，但是前两次不能，容易造成对服务器的攻击
为什么TIME_WAIT状态需要等待2MSL才能转换到CLOSE状态？
- 保证最后一次能成功到达服务器。最后一次客户端发送给服务端的确认信息可能丢失，如果丢失，服务端会有重试机制，等待一来一回的时间，也就是2MSL的时间，如果没有接收到服务端的重试请求，就认为服务端接收了，等到了就刷新2MSL时间
- 等待2MSL的时间也是为了防止失效连接的请求报文会出现在新连接中，防止第三次重试请求能被客户端接受，不会干扰其他请求
SSL层在传输层还是应用层？
SSL层在传输层和应用层之间，是一个SSL层
TCP和UDP的区别？
1、基于连接与无连接；
2、对系统资源的要求（TCP较多，UDP少）；
3、UDP程序结构较简单；
4、流模式与数据报模式 ；
5、TCP保证数据正确性，UDP可能丢包；
6、TCP保证数据顺序，UDP不保证。
常见状态码
-
1XX - 临时消息。服务器收到请求，需要请求者继续操作。
-
2XX - 请求成功。请求成功收到，理解并处理。
-
3XX - 重定向。需要进一步的操作以完成请求。
-
4XX - 客户端错误。请求包含语法错误或无法完成请求。
-
5XX - 服务器错误。服务器在处理请求的过程中发生了错误。
200：客户端请求成功
301：资源（网页等）被永久转移到其他URL
302：重定向，临时跳转
400：客户端请求存在语法错误，不能给被服务器理解（Bad Request）
404：请求资源不存在，错误的URL
500：服务器内部发生了不可预料的错误
502：网关错误（Bad Getway）
503：服务器当前不能处理客户端的请求，一段时间后可能恢复正常。（Server Unavailable）
简述TCP和UDP的区别
TCP：需要数据准确、顺序不能错、要求稳定可靠的场景就需要用到TCP。
UDP：数据即时性
socket
tcp内部是由socket协议填充的
简述https的加密过程
RSA是非对称加密，AES是对称加密
- 客户端请求服务端进行访问
- 服务端创建RSA，获得私钥和公钥
- 服务端发送公钥给客户端
- 客户端经过复杂的证书验证
- 客户端生成AES密钥
- 将AES密钥经过RSA公钥加密后发送给服务端
- 服务端通过RSA私钥解密获取AES密钥
- 客户端和服务端后续通过AES密钥进行通信
为什么要使用RSA加密形式交换AES密钥，不直接使用RSA加密？
因为RSA加密有性能上的损耗，加解密过程会比较耗时，不适用于频繁通信过程，而AES加密比较快捷
简述中间人攻击，如何解决？（dns劫持）
- 客户端访问域名A，向服务端进行请求
- 中间人劫持dns，使之指向私人ip B。即客户端同B建立https连接
- B在和A建立https连接
- 服务端创建RSA，获得公钥（S）和私钥（S）
- 服务端发送公钥（S）给客户端
- 中间人拦截信息，获得公钥（S）
- 生成RSA公钥（中）和私钥（中），并将公钥（中）发送给客户端
- 客户端生成AES密钥
- 使用公钥（中）加密AES密钥，并发送给服务端
- 中间人拦截信息，获得加密信息，使用私钥（中）进行解密，获得AES密钥
- 中间人使用公钥（S）加密AES密钥，并发送给服务端
- 服务端通过私钥（S）进行解密，获得AES密钥。
到此为止，中间人持有客户端和服务端交换的AES密钥，可以进行消息拦截，并解密信息
解决方案：将RSA公钥交给CA机构，CA机构添加上域名，有效期等将其制作成证书，在用CA机构的私钥进行加密后放置在服务器上，当客户端请求时，返回加密后信息，客户端从CA机构获取公钥（一般情况下内置在机器中）进行解密，成功解密后，获取的信息，域名等可以匹配上，则CA验证通过，获得服务器公钥，走下面流程。
https 无法防止中间人攻击，只有做证书固定ssl-pinning 或者 apk中预置证书做自签名验证可以防中间人攻击
证书固定（Certificate Pinning）是指Client端内置Server端真正的公钥证书。在HTTPS请求时，Server端发给客户端的公钥证书必须与Client端内置的公钥证书一致，请求才会成功。
http分层
dns污染
国家或地区防止摸一个网站被访问，是dns发送出错误的ip地址，使之无法访问
使用代理服务器和vpn
http1.0、http1.1和http2.0的区别
1.0：短暂连接，重复访问，连接无法复用
1.1：支持持久连接，长连接，优化1.0带来的性能问题，可以多路复用（数量限制），串行处理，一条失败，后续全部失败，同步
2.0：优化多路复用机制，header压缩，并行处理，异步
3.0：UDP
