get/post请求有什么区别
- post更安全（不会作为url的一部分，不会被缓存、保存在服务器日志、以及浏览器浏览记录中）
- post发送的数据更大（get有url长度限制）
- post能发送更多的数据类型（get只能发送ASCII字符）
- post比get慢
- post用于修改和写入数据，get一般用于搜索排序和筛选之类的操作（淘宝，支付宝的搜索查询都是get提交），目的是资源的获取，读取数据
浏览器缓存相关（强缓存、协商缓存，对应属性介绍...）
你知道304吗？图解强缓存和协商缓存 - 掘金 (juejin.cn)
强制缓存是什么
强制缓存就是文件直接从本地缓存中获取，不需要发送请求。
从上图可以看到，当初次请求时，浏览器会向服务器发起请求，服务器接收到浏览器的请求后，返回资源并返回一个
Cache-Control 给客户端，该 Cache-Control 一般设置缓存的最大过期时间。
浏览器再次发送请求时，它会先检查它的 cache-control 是否过期，如果没有过期则直接从本地缓存中拉取资源，返回到客户端，而无需再经过服务器。
本地缓存资源又分为内存缓存和硬盘缓存。
Cache-Control的值
协商缓存
- 协商缓存，也叫对比缓存。
- 它是一种服务端的缓存策略，即通过服务端来判断某件事情是不是可以被缓存。
- 服务端判断客户端的资源，是否和服务端资源一样，如果一致则返回
304，反之返回200和最新的资源。
首先，如果客户端是第一次向服务器发出请求，则服务器返回资源和相对应的资源标识给浏览器。该资源标识就是对当前所返回资源的一种唯一标识，可以是Etag或者是Last-Modified，这两个字段将在图例结束后展开讲解。
之后如果浏览器再次发送请求时，浏览器就会带上这个资源标识。此时，服务端就会通过这个资源标识，可以判断出浏览器的资源跟服务端此时的资源是否一致，如果一致，则返回304，即表示Not Found 资源未修改。如果判断结果为不一致，则返回200，并返回资源以及新的资源标识。至此就结束了协商缓存的过程。
在响应头部 Response Headers 中，有两种资源标识：
Last-Modified资源的最后修改时间，对应请求头为If-Modified-Since；Etag资源的唯一标识，所谓唯一，可以想象成时人类的指纹，具有唯一性；但Etag的本质是一个字符串；对应请求头为If-None-Match。
Last-Modified 和 Etag
-
当响应头部
Response Headers同时存在Last-Modified和Etag的值时，会优先使用Etag； -
Last-Modified只能精确到秒级； -
如果资源被重复生成，而内容不变，则
Etag更精确。
http常见的响应码，拒绝服务资源是哪个（403）
1xx：信息性状态码
- 100 Continue：客户端应继续发送请求。
- 101 Switching Protocols：服务器要求客户端切换协议。
成功状态码
- 200 OK：请求成功。
- 201 Created：请求已成功并创建了新的资源。
- 204 No Content：服务器成功处理了请求，但没有返回任何内容。
3xx：重定向状态码
- 301 Moved Permanently：资源的URL已永久更改，需要更新链接。
- 302 Found：资源的URL临时性更改。
- 304 Not Modified：客户端缓存的资源仍然有效，无需重新传输。
4xx：客户端错误状态码
- 400 Bad Request：服务器无法理解请求的语法。
- 403 Forbidden：服务器拒绝请求。
- 404 Not Found：请求的资源不存在。
5xx：服务器错误状态码
- 500 Internal Server Error：服务器遇到了意外情况。
- 501（尚未实施）：服务器不具备完成请求的功能。 例如，服务器无法识别请求方法时可能会返回此代码
- 502（错误网关）： 服务器作为网关或代理，从上游服务器收到无效响应
- 503 Service Unavailable：服务器当前无法处理请求。
- 504（网关超时）： 服务器作为网关或代理，但是没有及时从上游服务器收到请求
说说https的内在原理，ssl握手过程
证书验证阶段
- 浏览器发起 HTTPS 请求
- 服务端返回 HTTPS 证书
- 客户端验证证书是否合法，如果不合法则提示告警
数据传输阶段
- 当证书验证合法后，在本地生成随机数
- 通过公钥加密随机数，并把加密后的随机数传输到服务端
- 服务端通过私钥对随机数进行解密
- 服务端通过客户端传入的随机数构造对称加密算法，对返回结果内容进行加密后传输
为什么数据传输是用对称加密？
首先，非对称加密的加解密效率是非常低的，而 http 的应用场景中通常端与端之间存在大量的交互，非对称加密的效率是无法接受的；
另外，在 HTTPS 的场景中只有服务端保存了私钥，一对公私钥只能实现单向的加解密，所以 HTTPS 中内容传输加密采取的是对称加密，而不是非对称加密。
为什么需要 CA 认证机构颁发证书？
首先我们假设不存在认证机构，任何人都可以制作证书，这带来的安全风险便是经典的 “中间人攻击” 问题。中间人通过伪造的证书骗取服务端的信任，从而截取到客户端和服务端的所有数据。
用了HTTPS会被抓包吗？
HTTPS 的数据是加密的，常规下抓包工具代理请求后抓到的包内容是加密状态，无法直接查看。 但是，正如前文所说，浏览器只会提示安全风险，如果用户授权仍然可以继续访问网站，完成请求。 因此，只要客户端是我们自己的终端，我们授权的情况下，便可以组建中间人网络，而抓包工具便是作为中间人的代理。
既然 HTTPS 不能防抓包，那 HTTPS 有什么意义？
HTTPS 可以防止用户在不知情的情况下通信链路被监听，对于主动授信的抓包操作是不提供防护的，因为这个场景用户是已经对风险知情。要防止被抓包，需要采用应用级的安全防护，例如采用私有的对称加密，同时做好移动端的防反编译加固，防止本地算法被破解。
keep-alive和多路复用的区别
参考文档 了解 HTTP/1.x 的 keep-alive 吗？它与 HTTP/2 多路复用的区别是什么？ - 掘金 (juejin.cn)
- HTTP/1.x 是基于文本的，只能整体去传；HTTP/2 是基于二进制流的，可以分解为独立的帧，交错发送
- HTTP/1.x keep-alive 必须按照请求发送的顺序返回响应；HTTP/2 多路复用不按序响应
- HTTP/1.x keep-alive 为了解决队头阻塞，将同一个页面的资源分散到不同域名下，开启了多个 TCP 连接；HTTP/2 同域名下所有通信都在单个连接上完成
- HTTP/1.x keep-alive 单个 TCP 连接在同一时刻只能处理一个请求（两个请求的生命周期不能重叠）；HTTP/2 单个 TCP 同一时刻可以发送多个请求和响应
http2.0的特性
- 使用二进制格式传输，更高效、更紧凑。
- 对报头压缩，降低开销。
- 多路复用，一个网络连接实现并行请求。
- 服务器主动推送，减少请求的延迟。
- 默认使用加密。
http2.0 头部压缩(HPACK)原理
参考文档[HTTP/2 HPACK 实际应用举例 (halfrost.com)]
- 头信息使用gzip或compress压缩后再发送
- 消息发送端和消息接受端共同维护一份静态表(静态表中有61个预定义的key)和一份动态表（这两个合起来充当字典的角色），每次请求时，发送方根据字典的内容以及一些特定指定，编码压缩消息头部，
- 接收方根据字典进行解码，并且根据指令来判断是否需要更新动态表
tcp 三次握手
参考 前端面试高频题，八股文精华篇 - 掘金 (juejin.cn)
握手 所谓三次握手(Three-way Handshake)，是指建立一个 TCP 连接时，需要客户端和服务器总共发送3个报文。
- 第一次握手，发送端首先发送一个带SYN（synchronize）标志的数据包给接收方，第一次的seq序列号是随机产生的，这样是为了网络安全，如果不是随机产生初始序列号，黑客将会以很容易的方式获取到你与其他主机之间的初始化序列号，并且伪造序列号进行攻击
- 第二次握手，接收端收到后，回传一个带有SYN/ACK（acknowledgement）标志的数据包以示传达确认信息SYN 是为了告诉发送端，发送方到接收方的通道没问题；ACK 用来验证接收方到发送方的通道没问题
- 第三次握手，发送端再回传一个带ACK标志的数据包，代表握手结束，若在握手某个过程中某个阶段莫名中断，TCP协议会再次以相同的顺序发送相同的数据包
为什么需要三次握手？
为了实现可靠数据传输，TCP协议的通信双方，都必须维护一个序列号，以标识发送出去的数据包中，哪些是已经被对方收到的。三次握手的过程即是通信双方相互告知序列号起始值，并确认对方已经收到了序列号起始值的必经步骤 如果只是两次握手，至多只有连接发起方的起始序列号能被确认，另一方选择的序列号则得不到确认
TCP 四次挥手
- 客户端发送一个 FIN，用来关闭服务端到客户端的数据传送
- 服务端收到这个 FIN，它发回一 个 ACK，确认序号为收到的序号加1 。和 SYN 一样，一个 FIN 将占用一个序号
- 服务端关闭与客户端的连接，发送一个FIN给客户端
- 客户端发回 ACK 报文确认，并将确认序号设置为收到序号加1
udp和tcp区别
- TCP是面向连接的，UDP是无连接的
- TCP是可靠的，UDP是不可靠的
- TCP是面向字节流的，UDP是面向数据报文的
- TCP只支持点对点通信，UDP支持一对—，—对多，多对多
- TCP有拥塞控制机制，UDP没有
- TCP协议下双方发送接受缓冲区都有，UDP并无实际意义上的发送缓冲区，但是存在接受缓冲区
TCP 和UDP的应用场景
TCP应用场景: 效率要求相对低，但对准确性要求相对高的场景。举几个例子:文件传输（准确高要求高、但是速度可以相对慢)、接收邮件、远程登录。
UDP应用场景: 效率要求相对高，对准确性要求相对低的场景。举几个例子:QQ聊天、在线视频、网络语音电话(即时通讯，速度要求高，但是出现偶尔断续不是太大问题，并且此处完全不可以使用重发机制)、广播通信(广播、多播)。
dns原理
参考DNS原理及解析过程详解 - 知乎 (zhihu.com)
DNS ，全称 Domain Name System 。
采用 client/server 模式，DNS client 发出查询请求，DNS server 响应请求。DNS client 通过查询 DNS server 获得主机的 IP 地址，进而完成后续的 TCP/IP 通信过程。
DNS 域的本质是一种管理范围的划分，最大的域是根域，向下可以划分为顶级域、二级域、三级域、四级域等。相对应的域名是根域名、顶级域名、二级域名、三级域名等。不同等级的域名使用点号分隔，级别最低的域名写在最左边，而级别最高的域名写在最右边。
.com 表示公司企业，
.net 表示网络服务机构，
.org 表示非盈利组织，
.edu 表示教育机构（仅限美国），
.gov 表示政府部门（仅限美国），
.mil 表示军事部门（仅限美国）。
