关于网络通信的一些问题

HTTP和HTTPS的区别

HTTP：互联网上应用最为广泛的一种网络通信协议。是基于TCP的。

HTTPS：HTTP的加强版，即HTTP+SSL/TLS（security socket layer）。当前架构下最为安全的解决方案

1. HTTP是无状态的简单连接，而HTTPS是经过证书加密的，安全性更高；
2. HTTP是免费的，而HTTPS的证书部分是收费的，安全性越高就越贵；
3. HTTPS握手协议比较费时，会影响服务的吞吐量和响应速度；
4. HTTPS只是相对安全，但是面对DDOS时，还可能会起副作用。

 HTTPS通过对称加密，非对称加密，数字证书等方式保证数据传输的安全

HTTP的响应和请求都是明文的，报文非常容易被解读。因此我们引入了TLS/SSL来对HTTP请求进行加密，也就有了HTTPS

TLS如何握手：

首先是TCP的三次握手

客户端会告诉服务器是否支持TLS与版本+随机数1+加密套件

服务端收到后会发给客户端自己是否支持TLS与版本+随机数2+加密套件中选择了一个

服务端再发送一个响应出示自己的证书；然后服务器会把公钥发送给客户端。最后服务端告诉客户端：发送完毕

此时客户端已与服务端达成了TLS的一致，客户端用收到的公钥随机数3进行加密生成预主密钥并发送。

服务端用密钥解密收到的预主密钥，获取随机数3。

双方用随机数123生成一个会话密钥，这时双方就可以用这个会话密钥进行交流了

 

 

关于cookie storage session token

cookie：由服务端发送给客户端，并存储在客户端的数据片段，容易被篡改，安全性较低

session：在服务端生成的会话信息，生成后会发送sessionId给客户端，客户端通过cookie（或其他方式）携带sessionId

storage：客户端存储数据的方式，相对于cookie具有更大的空间与更好的性能

token：身份认证与授权的令牌，服务端生成并签发给客户端，在请求头中作为一部分发给服务端，能够实现无状态认证与授权（不需要服务器去维护关于用户会话的信息），并且在分布式中可以跨域使用。

cookie+session方案：早期使用的登录方案，在分布式项目中，需要额外拓展：

session黏贴：在负载均衡中，通过机制保证所有的session请求都会打在一个tomcat实例中。缺点：一旦这个实例失效了，所有session就都不能用了

session复制：随机tomcat保存session，但是session会复制到集群中的其他实例。缺点：复制过程中，会容易产生session丢失

session共享：类似token的存储，新增一个中间件（例如redis）将session存在中间件中，这样所有的tomcat实例都可以正常存取

storage+token：springsecurity就是使用的这一方案，token存于storage中，请求的时候在请求头发送，在redis中认证token的正确性与时效。在微服务架构中一般在gateway处认证，在module处授权。

 

JAVA的IO模型：BIO NIO AIO IO多路复用

BIO：同步阻塞IO，BIO需要线程主动去查询是否有数据可读，读取数据时线程会阻塞住，处理完一个socket才能处理下一个。

这种模式简单，但是会给服务端造成很大的压力，每个客户端访问都需要开启一个线程。可靠性很差，吞吐量低。不过JDK1.4之前只能使用BIO

NIO（应用最多最广）：同步非阻塞IO，也需要线程主动去查询是否有数据可读，但是读取数据时线程不会阻塞住

这种模式解决了BIO线程太多的问题，把所有客户端的访问都交给selector去管理。可靠性比BIO强，吞吐量比BIO高，适用于连接比较多且比较短的场景（聊天室）

AIO（异步通知需要操作系统执行）：异步非阻塞IO，有数据可读时socket会主动推给线程，读取数据也不会阻塞住

适用于连接又多又长的场景JDK7+才支持

 

select poll epoll：多路复用机制：让单个线程监听多个描述符，当某个描述符就位后让线程进行相应的读写操作

select模型：使用数组存储socket连接文件描述符，通过轮询判断是否发生IO事件

poll模型：使用链表存储socket连接文件描述符，同样通过轮询判断是否发生IO事件

epoll模型：事件通知模型，发生IO事件时，不需要像上述模型主动轮询，等推送即可

 

TCP的三次握手与四次挥手

TCP协议是网络数据传输层协议，负责数据传输

三次握手：客户端向服务端发送SYN，服务端收到SYN后向客户端发送SYN_ACK，客户端收到SYN_ACK后向服务端发生ACK

为什么三次握手而非两次：如果是两次握手则是客户端向服务端发生SYN，服务端接到SYN后返给客户端SYN_ACK。问题是如果服务端返给客户端SYN_ACK由于网络问题失败了，那就会导致服务端认为已经建立了连接，而实际没有连接，这样会造成资源浪费。总的来说就是因为网络不可靠

四次挥手：客户端向服务端发生FIN，服务端收到FIN后给客户端发送ACK：告诉客户端不需要再发FIN，但是我这还有数据要处理。处理完成后服务端再发FIN，客户端收到FIN后向服务端发生ACK，客户端断开连接

 

TCP如何保证可靠传输

1.建立连接：三次握手保证链接实体真实存在

2.序号机制：保证数据按序完整到达

3.数据校验：保温头有校验和，用于校验报文是否损坏

4.超时重传：超过一定时间内不应答，发送方会重新发送

5.流量控制：滑动窗口机制

6.拥塞控制 7.合理分片

 

tomcat如何优化

按JVM调优的方式调整；修改线程数，tomcat默认最大线程数是200，最大连接数是10000；

调整IO模型：使用AIO（NIO2）或者APR。高并发的情况下，抛开最次的BIO不谈，NIO是这三个里最差的。AIO不如APR的地方在于AIO必须要tomcat8+，而APR只需要tomcat5.5+即可。如何调整IO模型：直接安装APR模型，然后在conf里配置一下。

 

什么是跨域请求CORS

跨域请求即浏览器内发出ajax请求时，会查看请求url的协议、地址、端口是否相同，如果不一致则无法访问。当然src属性是可以访问的

如何处理CORS问题：

前后端分离项目需要标注哪些可以放行。

在SSO中，可以采用后台回调方式实现（例如使用HTTPCLlient调用目标接口）

通过NGINX代理

 

浏览器是如何发送一个请求的

解析用户的URL，生成一个http格式的请求

根据URL去hosts文件查找是否有映射IP，如果没有就去根据DNS去解析，得到目标IP地址

通过操作系统将请求通过四层网络协议发送到指定服务器

服务器根据请求所指定的端口，将请求传给对应的程序，程序根据http协议的格式进行解析，得到访问的servlet

servlet处理请求，在springMVC中就是用dispatcherServlet找到对应的controller方法返回相应的结果：view或方法上有requestBody，通过HttpMessageConverter来返回结果转换为JSON响应

tomcat获得响应结果后再封装成HTTP响应格式，通过网络发生给对应客户端

 

如何搭建一个开放授权平台

待接入的第三方应用在开放授权平台进行注册，提供clientID，消息推送地址，密钥等信息

关于使用消息推送地址：有一定安全程度，即使信息都被破解了，返回给发送者的消息也只是通知服务端接收到信息。而真正需要的信息永远是发给具体消息推送地址的。异步推送使用体验比较好

关于密钥：公钥发给第三方应用，私钥由平台保存。第三方应用采用公钥加密，授权平台接收到消息后用密钥解密