主要是工作中不常用，导致记得不是很清晰。但是很重要的知识点，慢慢积累...
1.七层协议
- 从上到下是：应用层、表示层、会话层、传输层、网络层、数据链路层、物理层；
- 协议类型：
应用层中，有FTP：文件传输协议； http：超文本传输协议； SMTP：邮件传输协议； DNS：域名系统；
传输层中，有TCP：传输控制协议； UDP：用户数据协议
2.Http的工作过程
对于请求的地址，从地址中分离出协议名、主机名、端口、对象路径等
地址解析
使用域名系统DNS解析域名，得到主机的IP地址封装HTTP请求数据包
把解析出的信息结合自己本机的信息，封装成一个HTTP请求数据包封装成TCP包，建立TCP连接
（三次连接）客户机发送请求命令
建立连接后，客户机发送一个请求给服务器，请求方式的格式为：统一资源标识符（URL）、协议版本号，后面是MIME信息。服务器响应
服务器是否关闭TCP连接
若在请求头中加入了Connection:keep-alive,则表示仍然保持连接
3.API网关的作用
身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理、限流控制等
Nginx和Api Gateway的说明
总结：现在前后端分离的系统一般都会如下设计：Nginx做静态资源服务器，前端页面调用后端接口时先请求到Nginx，Nginx做负载君合路由到后端网关，然后网关做请求身份验证，日志记录等操作，再转发业务处理接口，处理完返回数据。
4.拦截器和过滤器的区别
5.关于前端提交格式【Content-Type】与后端接受格式 互相对应点
- 前端格式为 Content-Type：application/x-www-form-urlencoded;charset=UTF-8 时（表单提交方式），
后端接受时，在路径的RequestMapping上，加上consumes = MediaType.APPLICATION_FORM_URLENCODED_VALUE；接受的参数可以通过@RequestParam成功获取（不可用@RequestBody接受），后端如下图：
采用其他格式或参数接受，会报如下错误，Content type 'application/x-www-form-urlencoded;charset=UTF-8' not supported
- 当前端格式为 Content-Type：application/json 时（Payload提交方式），后端接受方式为 consumes = MediaType.APPLICATION_JSON_VALUE，参数可通过@RequestBody接受，如下所示：
注：@RequestParam和@RequestBody接受参数，@ReqeustParam底层是通过request.getParameter方式获得参数的，get和post提交都可以接受到；@RequestBody接受的是json对象的字符串，而不是json对象。
6. 运算符
关于运算符，总是容易混淆和遗忘。特总结如下：
- 位运算符
- & 与运算符：参与运算的两个值，如果两个相应位都是1，则该位的结果位1，否则为0；
- | 或运算符：参与运算的两个值，如果其中有一个位是1，则该位的结果为1，否则为0；
- ^ 异或运算符：当两对应的位相异时，结果为1；
- ~ 取反运算符：对数据的每个二进制为取反，即把1改为0，把0改为1；
- << 左移运算符：各二进制位全部左移若干位，由“<<” 右边的数指定移动的位数，高位丢弃，低位补0；相当于乘以2的n次方
- >> 右移运算符：与左移刚好相反。例：11 >> 2，11右移2位，11的二进制为：1011，右移的结果为：0010，即对应的十进制为2。右移n位相当于除以2的n次方，值取商，余数舍弃。
- >>> : 无符号右移，忽略符号位，空位都以0补齐
不断积累中，未完待续...