GET 和 POST 的请求的区别
- 传递的参数不同，
POST传递的参数在请求体中，GET传递的参数在url后拼接 GET请求长度受浏览器限制，POST没有POST相对GET请求安全。POST 不可见，get 可见。GET请求一般用于查询，POST一般用于提交某种信息进行某些修改操作GET请求会被浏览器主动缓存，POST不会，要手动设置。
get 请求传参长度的误区
误区：我们经常说 get 请求参数的大小存在限制，而 post 请求的参数大小是无限制的。
- 1.HTTP 协议未规定 GET 和 POST 的长度限制，
- 2.GET 的最大长度限制是因为浏览器和 web 服务器限制了 URI 的长度
- 3.不同的浏览器和 WEB 服务器，限制的最大长度不一样，IE 最大长度为 2kb左右，Chrome 最大长度 8kb左右。
get 和 post 请求在缓存方面的区别
回答：
缓存一般只适用于那些不会更新服务端数据的请求。 一般 get 请求都是查找请求，不会对服务器资源数据造成修改， 而 post 请求一般都会对服务器数据造成修改， 所以，一般会对 get 请求进行缓存，很少会对 post 请求进行缓存。
GET、POST、PUT、PATCH、DELETE 请求的区别
- GET：获取
- POST：新建
- PUT：更新
- PATCH：更新，通常是部分更新
- DELETE：删除
HTTP 和 HTTPS 协议的区别
HTTPS需要CA证书，HTTP不需要HTTP是明文传输，不安全。而HTTPS基于SSL进行加密，相对安全。HTTP端口为80，HTTPS端口443
对 HTTP 请求中的 keep-alive 有了解吗
在HTTP协议中keep-valie是一种长连接。
在HTTP1.0中默认 每次请求/应答 客户端和服务器都会建立一次连接，请求完成后立即断开，这种是短连接。当使用keep-alive后，客户端和服务端的连接持续有效，后续的请求就会避免重复建立连接，减少服务器负担降低延迟，这种就是长连接。
使用方式就是通过在HTTP请求头中添加Connection: keep-alive字段，服务端会在响应头中添加Connection: keep-alive字段通知客户端长连接已经建立。
在HTTP1.1默认开启了长连接，除非在请求或响应头中明确关闭它。
所谓长连接，即在 HTTP 请求建立 TCP 连接时，请求结束，TCP 连接不断开，继续保持一段时间（timeout），在这段时间内，同一客户端向服务器发送请求都会复用该 TCP 连接，并重置 timeout 时间计时器，在接下来 timeout 时间内还可以继续复用 TCP 。这个过程和防抖很相似。
在HTTP2中使用了多路复用，允许在同一个连接上处理多个请求和响应，取代了keep-alive机制。
HTTP 状态码
| 状态码 | 中文描述 |
|---|---|
| 100 | 请求正在处理 |
| 200 | 请求成功。 |
| 201 | 请求成功并且服务器创建了新资源 |
| 202 | 服务器已经接收请求，但尚未处理 |
| 301 | 永久性重定向。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替 |
| 302 | 临时性重定向。与301类似。但资源只是临时被移动。客户端应继续使用原有 URI。 |
| 304 | 资源未修改，服务端未处理，协商缓存生效。 |
| 400 | 客户端请求报文中存在语法错误，服务器无法理解。浏览器会像200 OK一样对待该状态码 |
| 401 | 请求要求用户的身份认证，请求未授权 |
| 403 | 禁止访问 |
| 404 | 服务器上无法找到请求资源 |
| 500 | 服务端错误 |
| 503 | 服务器暂时无法处理请求。 |
301 和 302 常见使用场景：
- 想换个域名，旧的域名不用了，这样用户访问旧域名时用301就重定向到新的域名。
- 登录后重定向到指定的页面，这种场景比较常见就是登录成功跳转到具体的系统页面。
response.setStatus(301);
response.setHeader("Location", "http://127.0.0.1/home.html");
OSI 七层模型
- 应用层
- 表示层
- 会话层
- 传输层
- 网络层
- 数据链路层
- 物理层
TCP / IP 五层协议
-
应用层：
HTTP协议FTP协议DNS查询 -
传输层： 提供通信
UPD无连接 不安全 最大努力传输服务TCP面向连接 数据可靠
-
网络层： 路由器 交换机
-
数据链路层： IP 数据封装成帧 在两个相邻节点间传送
-
物理层： 确保数据在物理媒介上传输
TCP 和 UDP 的区别
TCP 和 UDP都是传输层协议
TCP：
- 面向连接
- 一对一，不支持广播和多播
- 面向字节流
- 可靠传输
- 提供全双工通信
UDP：
- 面向无连接，不需要建立三次握手
- 支持一对一、一对多、多对多方式
- 面向报文
- 不可靠
UDP 协议为什么不可靠？
- 传输数据之前不需要先建立连接
- 双方都不需要确认
- 不跟踪连接
TCP 和 UDP 的应用
TCP 应用层协议
- HTTP：用于在Web浏览器和Web服务器之间传输超文本数据。大多数网站使用TCP上的HTTP来传输网页内容，图像，视频等。
- HTTPS：是安全的HTTP，使用SSL/TLS进行加密。它在TCP上运行，用于安全的网页浏览。
- FTP：用于在客户端和服务器之间传输文件。TCP 确保文件以可靠的方式传输。
UPD应用层协议
- DNS：用于将域名映射到IP地址。
DNS使用UDP进行快速的查询和响应，尽管它不提供数据可靠性。
对 WebSocket 的理解
WebSocket 是一种基于TCP协议 的 全双工通信的网络协议。
与传统的 HTTP1.0 协议不同，HTTP1.0是基于请求-应答模式，即客户端发送请求，服务器返回响应，然后连接关闭。
而 WebSocket 允许客户端和服务器之间保持持久性的连接，双方都可以主动发送数据，而不需要每次通信都建立新的连接。
http1.1 也实现了默认的 keep-alive 长连接模式。
TCP 三次握手
SYN，SYN-ACK，ACK SYN 表示同步序列编号，ACK 表示确认号
第一次握手：客户端向服务端发送一个 SYN 报文段，表示客户端请求建立连接。
第二次握手：服务端收到 SYN 报文段后，向客户端发送一个 SYN-ACK 报文段，表示服务端同意客户端的请求，并要求客户端确认。
第三次握手：客户端收到 SYN-ACK 报文段后，向服务端发送一个 ACK 报文段，表示客户端确认连接建立请求。
四次挥手
TCP 是可以双向传输数据的，也就是 全双工协议。所以双方都可以主动断开连接。
第一次挥手（发送FIN） ： 客户端打算关闭连接，它会发送一个FIN（结束）报文段，进入FIN_WAIT_1 状态。
第二次挥手（发送ACK） ：服务端收到FIN报文段后，发送一个ACK报文段作为回应，并进入CLOSE-WAIT状态。客户端收到ACK后，进入FIN-WAIT-2状态。
第三次挥手（发送FIN） ： 然后服务单会再发送一个FIN报文段，请求关闭连接，进入LAST-ACK状态。
第四次挥手（发送ACK） ：客户端收到服务器的 FIN 包后，发送ACK报文段作为回应，并进入 TIME-WAIT 状态。服务器端收到客户端的确认包 ACK 后进入CLOSED 状态，经过 2MSL 后，客户端才进入 CLOSED 状态。连接被最终关闭。
为什么是四次挥手？
在关闭连接时，当服务端收到客户端端发出的连接释放报文时，很可能并不会立即关闭连接，因为有可能服务端数据还未发送完，所以Server端先回复一个ACK报文，告诉Client端我收到你的连接释放报文了。只有等到Server端所有的报文都发送完了，这时Server端才能发送连接释放报文，之后两边才会真正的断开连接。故需要四次挥手。
对于JSON的了解？
回答：
JSON 是一种基本文本的轻量级的数据交换格式。它可以被任意编程语言读取和作为数据格式来传递。
在项目开发中，我们主要使用 JSON 作为前后端数据交换的方式。在前端我们通过将一个符合 JSON 格式的数据结构序列化为 JSON 字符串，然后将它传递到后端，后端将 JSON 格式的字符串解析后生成对应的数据结构，以此来实现前后端数据的一个传递。
因为 JSON 的语法是基于 js 的，因此很容易将 JSON 和 js 中的对象弄混，但是我们应该注意的是 JSON 和 js 中的对象不是一回事，JSON 中的对象格式更加严格，比如说在 JSON 中属性值不能为函数，不能出现 NaN 这样的属性值，因此大多数的 js 对象是不符合 JSON 对象的格式的。
在 js 中提供了两个函数来实现 js 数据结构和 JSON 格式的转换处理，一个是 JSON.stringify 一个是 JSON.parse
URL 和 URI 的区别？
URI: Uniform Resource Identifier 指的是统一资源标识符
URL: Uniform Resource Location 指的是统一资源定位符
URN: Universal Resource Name 指的是统一资源名称
URI 用唯一的标识来确定一个资源，它是一种抽象的定义，也就是说，不管使用什么方法来定义，只要能唯一的标识一个资源，就可以称为 URI。
URL、URN 是 URI 的子集，URL 可以理解为使用地址来标识资源，URN 可以理解为使用名称来标识资源。
