计算机网络面试知识点

来自公众号：Java面试那点事

1. OSI 七层模型？ HTTP 协议对应第几层？ IP 协议呢？

• 物理层： 通过媒介传输比特， 确定机械及电气规范（比特 Bit）
• 数据链路层： 将比特组装成帧和点到点的传递（帧 Frame）
• 网络层： 负责数据包从源到宿的传递和网际互连（包 Packet）
• 传输层： 提供端到端的可靠报文传递和错误恢复（段 Segment）
• 会话层： 建立、 管理和终止会话（会话协议数据单元 SPDU）
• 表示层： 对数据进行翻译、 加密和压缩（表示协议数据单元 PPDU）
• 应用层： 允许访问 OSI 环境的手段（应用协议数据单元 APDU）

http 协议对应的是应用层， ip 协议对应的是网络层

2. 从一个 URL 到获取页面的过程？

• 浏览器查询 DNS， 获取域名对应的 IP 地址： 具体过程包括浏览器搜索自身的 DNS 缓
  存、 搜索操作系统的 DNS 缓存、 读取本地的 Host 文件和向本地 DNS 服务器进行查
  询等。
• 浏览器获得域名对应的 IP 地址以后， 浏览器向服务器请求建立链接， 发起 TCP 三次
  握手；
• TCP/IP 链接建立起来后， 浏览器向服务器发送 HTTP 请求；
• 服务器接收到这个请求， 并根据路径参数映射到特定的请求处理器进行处理， 并将处理
  结果及相应的视图返回给浏览器；
• 浏览器解析并渲染视图， 若遇到对 js 文件、 css 文件及图片等静态资源的引用， 则重
  复上述步骤并向服务器请求这些资源； 浏览器根据其请求到的资源、 数据渲染页面， 最
  终向用户呈现一个完整的页面。

3. session 的实现原理？ cookie 的原理？

• Cookie 实际上是一小段的文本信息。 客户端请求服务器， 如果服务器需要记录该用户
  状态， 就使用 response 向客户端浏览器颁发一个 Cookie。 客户端浏览器会把 Cookie
  保存起来。 当浏览器再请求该网站时， 浏览器把请求的网址连同该 Cookie 一同提交给
  服务器。 服务器检查该 Cookie， 以此来辨认用户状态。 服务器还可以根据需要修改
  Cookie 的内容。
• 如果说 Cookie 机制是通过检查客户身上的 “通行证” 来确定客户身份的话， 那么
  Session 机制就是通过检查服务器上的 “客户明细表” 来确认客户身份。 Session 相当于
  程序在服务器上建立的一份客户档案， 客户来访的时候只需要查询客户档案表就可以
  了。 使用上比 Cookie 简单一些， 相应的也增加了服务器的存储压力。
• Cookie 通过在客户端记录信息确定用户身份， Session 通过在服务器端记录信息确定用
  户身份。

4. session 和 cookie 的关系？ 禁用 cookie 后对 session 的影响？

Session 的实现常常依赖于 Cookie 机制。 一般默认情况下， 在会话中， 服务器存储 session
的 sessionid 是通过 cookie 存到浏览器里。 如果浏览器禁用了 cookie， 浏览器请求服务器
无法携带 sessionid， 服务器无法识别请求中的用户身份， session 失效。 但是可以通过其他
方法在禁用 cookie 的情况下， 可以继续使用 session。

• 通过 url 重写， 把 sessionid 作为参数追加的原 url 中， 后续的浏览器与服务器交互中
  携带 sessionid 参数。
• 服务器的返回数据中包含 sessionid， 浏览器发送请求时， 携带 sessionid 参数。
• 通过 Http 协议其他 header 字段， 服务器每次返回时设置该 header 字段信息， 浏览
  器中 js 读取该 header 字段， 请求服务器时， js 设置携带该 header 字段。

5. forward 和 redirect 的区别？

• forward 是服务器请求资源， 服务器直接访问目标地址的 URL, 把那个 URL 的响应内
  容读取过来， 然后把这些内容再发给浏览器。 浏览器根本不知道服务器发送的内容从哪
  里来的， 所以它的地址栏还是原来的地址.
• redirect 是服务端根据逻辑， 发送一个状态码 , 告诉浏览器重新去请求那个地址。 所以
  地址栏显示的是新的 URL.

6. 内网和外网 IP 地址的区别？ ABC 三类 IP 地址的划分

• 外网 IP 是全世界唯一的 IP 地址， 仅分配给一个网络设备。 公网 IP 地址全世界仅分
  配给一个网络设备（比如你在家拨号， 分配给你一个 IP 地址吧， 那个地址是唯一的，
  你用你机器做个网站， 别人访问你的 IP 地址就可以连接到你的机器）
• 内网 IP 局域网， 网线都是连接在同一个 交换机上面的， 也就是说它们的 IP 地址是由
  交换机或者路由器进行分配的。 内网用户的电脑都是经过交换机和路由器之后才能连到
  外网。 Internet 上的用户也无法直接访问到内网用户。 不同内网的内网地址可以相同。

IP 地址 = 网络地址 + 主机地址。 A 类前 8 位是（ 0+7 位网络地址） ,B 类前 16 位是
（10+14 位网络地址） ， C 类前 24 位是（110+21 位网络地址） 。

• A 类地址： 以 0 开头， 第一个字节范围： 0~127（1.0.0.0 – 126.255.255.255） ；
• B 类地址： 以 10 开头， 第一个字节范围： 128~191（128.0.0.0 – 191.255.255.255） ；
• C 类地址： 以 110 开头， 第一个字节范围： 192~223（192.0.0.0 – 223.255.255.255） ；

7. 网关和子网掩码的关系是什么？

• 子网掩码： 用来判断任意两台计算机的 ip 地址是否属于同一子网络的根据
• 网关实质上是一个在不同子段网路中传输数据的设备。 比如有网络 A 和网络 B， 若二
  者子网掩码不同， 即二者不属于同一个子网络。 在没有路由器的情况下， 两个网络之间
  是不能进行 TCP/IP 通信的
• 子网掩码相同， 不需要网关即可通讯， 子网掩码不同， 需要网关才能通讯

8. MAC 地址和 IP 地址的关系是什么？

• MAC 地址是硬件地址， 定位全球唯一主机机器， 在网络底层的物理传输过程中， 是通
  过物理地址来识别主机的， 它一定是全球唯一的， 应数据链路层。
• IP 地址是网络拓扑地址， 定位全球唯一网络结构中的主机。 对应网路层
• 可以通过身份证（MAC） 和电话（IP） 来理解

9. 什么是 DNS 服务器？

• DNS 是指： 域名服务器 (Domain Name Server)。 在 Internet 上域名与 IP 地址之间是一
  一对应的， 域名虽然便于人们记忆， 但机器之间只能互相认识 IP 地址， 它们之间的转
  换工作称为域名解析， 域名解析需要由专门的域名解析服务器来完成， DNS 就是进行
  域名解析的服务器 。

10. IP 如何映射到 MAC 地址的？

使用的是 ARP （Address Resolution Protocol： 地址解析协议） ， ARP 协议位于网络层。

工作原理：

• 首先， 每个主机都会在自己的 ARP 缓冲区中建立一个 ARP 列表， 以表示 IP 地址和
  MAC 地址之间的对应关系。 当源主机要发送数据时， 首先检查 ARP 列表中是否有对
  应 IP 地址的目的主机的 MAC 地址， 如果有， 则直接发送数据， 如果没有， 就向本网
  段的所有主机发送 ARP 数据包。
• 当本网络的所有主机收到该 ARP 数据包时， 首先检查数据包中的 IP 地址是否是自己
  的 IP 地址， 如果不是， 则忽略该数据包， 如果是， 则首先从数据包中取出源主机的 IP
  和 MAC 地址写入到 ARP 列表中。
• 如果目标 IP 与自己不在同一个网段， 这种情况需要将包发给默认网关， 所以主要获取
  网关的 MAC 地址。

11. TCP 是如何保证可靠传输数据的？

保证可靠稳定的传输最主要是通过：

• 拥塞控制
• 流量控制
• ARQ 协议

除此之外还有： 超时传送、 丢弃重复、 校验和、 分割合适数据包

拥塞控制：

• 慢启动： 不要一开始就发送大量的数据， 先探测一下网络的拥塞程度， 也就是说由小到
  大逐渐增加拥塞窗口的大小；
• 拥塞避免： 拥塞避免算法让拥塞窗口缓慢增长， 即每经过一个往返时间 RTT 就把发送
  方的拥塞窗口 cwnd 加 1， 而不是加倍， 这样拥塞窗口按线性规律缓慢增长。
• 快重传： 快重传要求接收方在收到一个 失序的报文段 后就立即发出 重复确认（为的
  是使发送方及早知道有报文段没有到达对方） 而不要等到自己发送数据时捎带确认。 快
  重传算法规定， 发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文
  段， 而不必继续等待设置的重传计时器时间到期。
• 快恢复： 快重传配合使用的还有快恢复算法， 当发送方连续收到三个重复确认时， 就执
  行 “乘法减小” 算法， 把 ssthresh 门限减半， 但是接下去并不执行慢开始算法： 因为
  如果网络出现拥塞的话就不会收到好几个重复的确认， 所以发送方现在认为网络可能没
  有出现拥塞。 所以此时不执行慢开始算法， 而是将 cwnd 设置为 ssthresh 的大小， 然
  后执行拥塞避免算法。

流量控制

• TCP 连接的每一方都有固定大小的缓冲空间， TCP 的接收端只允许发送端发送接收端缓
  冲区能接纳的数据。 当接收方来不及处理发送方的数据， 能提示发送方降低发送的速率，
  防止包丢失。 TCP 使用的流量控制协议是可变大小的滑动窗口协议。 （TCP 利用滑动窗
  口实现流量控制）

ARQ 协议

• 停止等待 ARQ 协议： 停止等待协议是为了实现可靠传输的， 它的基本原理就是每发完
  一个分组就停止发送， 等待对方确认（回复 ACK） 。 如果过了一段时间（超时时间后），
  还是没有收到 ACK 确认， 说明没有发送成功， 需要重新发送， 直到收到确认后再发下
  一个分组； 在停止等待协议中， 若接收方收到重复分组， 就丢弃该分组， 但同时还要发
  送确认；
• 连续 ARQ 协议： 连续 ARQ 协议可提高信道利用率。 发送方维持一个发送窗口， 凡位
  于发送窗口内的分组可以连续发送出去， 而不需要等待对方确认。 接收方一般采用累计
  确认， 对按序到达的最后一个分组发送确认， 表明到这个分组为止的所有分组都已经正
  确收到了。

12. TCP 和 UDP 的区别？

• TCP： 面向连接、 面向字节流、 一对一； UDP： 无连接、 面向报文、 一对一、 一对多、
  多对多。
• TCP 的优点： 可靠， 稳定.
• TCP 的缺点： 慢， 效率低， 占用系统资源高， 易被攻击
• UDP 的优点： 快， 比 TCP 稍安全 UDP 没有 TCP 的握手、 确认、 窗口、 重传、 拥塞
  控制等机制， UDP 是一个无状态的传输协议
• UDP 的缺点： 不可靠， 不稳定

13. TCP 三次握手和四次挥手的过程？

三次握手： (我要和你建立链接， 你真的要和我建立链接么， 我真的要和你建立链接， 成功)

• 第一次握手： 客户端发送 syn 包 (syn=x) 到服务器， 并进入 SYN_SEND 状态， 等待服
  务器确认；
• 第二次握手： 服务器收到 syn 包， 必须确认客户的 ACK（ack=x+1） ， 同时自己也发送
  一个 SYN 包（syn=y） ， 即 SYN+ACK 包， 此时服务器进入 SYN_RECV 状态；
• 第三次握手： 客户端收到服务器的 SYN＋ACK 包， 向服务器发送确认包 ACK (ack=y+1)，
  此包发送完毕， 客户端和服务器进入 ESTABLISHED 状态， 完成三次握手。

四次挥手： (我要和你断开链接； 好的， 断吧。 我也要和你断开链接； 好的， 断吧)

• 第一次挥手： 客户端主动关闭方发送一个 FIN， 用来关闭客户端到服务端的数据传送，
  也就是客户端告诉服务端： 我已经不会再给你发数据了 (当然， 在 fin 包之前发送出去
  的数据， 如果没有收到对应的 ack 确认报文， 客户端依然会重发这些数据)， 但是， 此
  时客户端还可以接受数据。
• 第二次挥手： 服务端收到 FIN 包后， 发送一个 ACK 给客户端， 确认序号为收到序号 +
  1（与 SYN 相同， 一个 FIN 占用一个序号） 。
• 第三次挥手： 服务端发送一个 FIN， 用来关闭服务端到客户端的数据传送， 也就是告诉
  客户端， 我的数据也发送完了， 不会再给你发数据了。
• 第四次挥手： 客户端收到 FIN 后， 发送一个 ACK 给服务端， 确认序号为收到序号 + 1，
  至此， 完成四次挥手。

14. TCP 为什么需要三次握手？ 只进行两次会出现什么问题？

• 客户端发出的连接请求报文并未丢失， 而是在某个网络节点长时间滞留了， 以致延误到
  链接释放以后的某个时间才到达 Server（这是第一次握手）。 这时， Server 误以为这是 Client 发出的一个
  新的链接请求， 于是就向客户端发送确认数据包， 同意建立链接。 若不采用 “三次握手”，
  那么只要 Server 发出确认数据包， 新的链接就建立了。 由于 client 此时并未发出建立
  链接的请求， 所以其不会理睬 Server 的确认， 也不与 Server 通信； 而这时 Server 一
  直在等待 Client 的请求， 这样 Server 就白白浪费了一定的资源。 若采用 “三次握手”，
  在这种情况下， 由于 Server 端没有收到来自客户端的确认， 则就会知道 Client 并没有
  要求建立请求， 就不会建立链接。（这是说的最明白的一个了）

15. TCP 第三次握手失败的情况 TCP 是如何处理的？

第三次失败， 只有客户端处于成功状态（因为第 2 次服务器返回了 ACK） ， 服务器端没有
接收到客户端的 ACK。 这要分几种情况讨论：

• 客户端发出的 ACK 丢失了， 发出的 下一个数据包 没有丢失， 则服务端接收到下一个
  数据包（这个数据包里也会带上 ACK 信息） ， 能够进入正常的 ESTABLISHED 状态
• 如果服务端和客户端都没有数据发送， 或者服务端想发送数据（但是发不了， 因为没有
  收到客户端的 ACK） ， 服务器都会有定时器发送第二步 SYN+ACK 数据包， 如果客户端
  再次发送 ACK 成功， 建立连接。
• 如果一直不成功， 服务器肯定会有超时设置， 超时之后会给客户端发 RTS 报文， 进入
  CLOSED 状态， 防止 SYN 洪泛攻击。

16. 为什么连接的时候是三次握手， 关闭的时候却是四次握手？

• TCP 是全双工模式， 关闭连接时， 当主机 B 收到主机 A 的 FIN 报文时， 仅仅表示主
  机 A 不再发送数据了但是还能接收数据。 此时， 主机 B 也未必全部数据都发送给 A
  了， 所以 B 可以立即 close； 也可以发送一些数据给 A 后， 再发送 FIN 报文给对方来
  表示同意现在关闭连接， 因此， 主机 BACK 和 FIN 一般都会分开发送。

17. http1.0 与 http1.1 的区别？ 什么是 keep-alive 模式？

• 缓存处理， 在 HTTP1.0 中主要使用 header 里的 If-Modified-Since,Expires 来做为缓存
  判断的标准， HTTP1.1 则引入了更多的缓存控制策略例如 Entity tag， If-Unmodified-Since,
  If-Match, If-None-Match 等更多可供选择的缓存头来控制缓存策略。
• 带宽优化及网络连接的使用， HTTP1.0 中， 存在一些浪费带宽的现象， 例如客户端只是
  需要某个对象的一部分， 而服务器却将整个对象送过来了， 并且不支持断点续传功能，
  HTTP1.1 则在请求头引入了 range 头域， 它允许只请求资源的某个部分， 即返回码是
  206（Partial Content） ， 这样就方便了开发者自由的选择以便于充分利用带宽和连接。
• 错误通知的管理， 在 HTTP1.1 中新增了 24 个错误状态响应码， 如 409（Conflict） 表
  示请求的资源与资源的当前状态发生冲突； 410（Gone） 表示服务器上的某个资源被永
  久性的删除。
• Host 头处理， 在 HTTP1.0 中认为每台服务器都绑定一个唯一的 IP 地址， 因此， 请求
  消息中的 URL 并没有传递主机名（hostname） 。 但随着虚拟主机技术的发展， 在一台
  物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers） ， 并且它们共享一个
  IP 地址。 HTTP1.1 的请求消息和响应消息都应支持 Host 头域， 且请求消息中如果没有
  Host 头域会报告一个错误（400 Bad Request） 。
• 长连接， HTTP 1.1 支持长连接（Persistent-Connection） 和请求的流水线（Pipelining） 处
  理， 在一个 TCP 连接上可以传送多个 HTTP 请求和响应， 减少了建立和关闭连接的消
  耗和延迟， 在 HTTP1.1 中默认开启 Connection： keep-alive， 一定程度上弥补了
  HTTP1.0 每次请求都要创建连接的缺点。

Keep-Alive 模式

• 当使用 Keep-Alive 模式（ 又称持久连接、 连接重用） 时， Keep-Alive 功能使客户端到
  服务器端的连接持续有效， 当出现对服务器的后继请求时， Keep-Alive 功能避免了建立
  或者重新建立连接。 启用 Keep-Alive 模式肯定更高效， 性能更高。 因为避免了建立 / 释
  放连接的开销。 因此最好能维持一个长连接， 可以用一个长连接来发多个请求。

18. 简单说一下 http2.0？

• HTTP2.0 使用了多路复用的技术， 做到同一个连接并发处理多个请求， 而且并发请求的
  数量比 HTTP1.1 大了好几个数量级。
• 当然 HTTP1.1 也可以多建立几个 TCP 连接， 来支持处理更多并发的请求， 但是创建
  TCP 连接本身也是有开销的。 TCP 连接有一个预热和保护的过程， 先检查数据是否传送
  成功， 一旦成功过， 则慢慢加大传输速度。 因此对应瞬时并发的连接， 服务器的响应就
  会变慢。 所以最好能使用一个建立好的连接， 并且这个连接可以支持瞬时并发的请求。

19. 什么是幂等性？ http 的方法是否都符合幂等性？ 若不符合， 怎么避免？

• 幂等性： HTTP 方法的幂等性是指一次和多次请求某一个资源应该具有同样的副作用。
  说白了就是， 同一个请求， 发送一次和发送 N 次效果是一样的！

HTTP 方法：

• GET 方法用于获取资源， 不应有副作用， 所以是幂等的。
• DELETE 方法用于删除资源， 有副作用， 但它应该满足幂等性。
• PUT 方法用于创建或更新操作， 有副作用， 与 DELETE 相同， 对同一资源无论调用一
  次还是多次， 其副作用是相同的， 因此也满足幂等性。
• POST 方法与 PUT 方法的区别主要在于幂等性， POST 不具备幂等性， 因为 POST 请求
  每次都会创建一个文件， 而 PUT 方法会在服务器验证是否有 ENTITY， 若有则更新该
  ENTITY 而不是重新创建。

POST 方法避免非幂等性， 当我们因为反复刷新浏览器导致多次提交表单， 多次发出同样的
POST 请求， 导致远端服务器重复创建出了资源。

• 第一、 对应的后端 WebService 一定要做到幂等性，
• 第二、 服务器端收到 POST 请求， 在操作成功后必须返回状态码 302 重定向到另外一
  个页面， 这样即使用户刷新页面， url 已经变更， 不需要进行 post 请求， 也不会重复
  提交表单。

20. https 与 http 的区别？

Http 协议运行在 TCP 之上， 明文传输， 客户端与服务器端都无法验证对方的身份； HTTPS
是运行在 SSL/TLS 之上的 HTTP 协议， SSL/TLS 运行在 TCP 之上。 HTTPS 是添加了加密和
认证机制的 HTTP。 二者之间存在如下不同：

• 端口不同： Http 与 Https 使用不同的连接方式， 用的端口也不一样， 前者是 80， 后者
  是 443；
• 资源消耗： 和 HTTP 通信相比， Https 通信会由于加减密处理消耗更多的 CPU 和内存
  资源；
• 开销： Https 通信需要证书， 而证书一般需要向认证机构购买

21. https 加密的过程？

• 浏览器使用 Https 的 URL 访问服务器， 建立 SSL 链接。
• 服务器接收到 SSL 链接后， 发送非对称加密的公钥 A 给浏览器。
• 浏览器生成随机数， 作为对称加密的密钥 B。
• 浏览器使用服务器返回的公钥 A， 对自己生成的对称加密密钥 B 进行加密， 得到密钥
  C。
• 浏览器将密钥 C 发送给服务器
• 服务器使用自己的非对称加密私钥 D 对接受的密钥 C 进行解密， 得到对称加密密钥
  B。
• 浏览器和服务器之间使用密钥 B 作为对称加密密钥进行通信。

注意： 非对称加密之所以不安全， 因为客户端不知道这把公钥是不是属于服务器的。

22. https 是否存在安全问题？ 如何避免？

当服务器发送公钥给客户端， 中间人截获公钥 ， 将 中间人自己的公钥 冒充服务器的公钥
发送给客户端。 之后客户端会用 中间人的的公钥 来加密自己生成的 对称密钥 。 然后把加
密的密钥发送给服务器， 这时中间人又把密钥截取， 中间人用自己的私钥把加密的密钥进行
解密， 解密后中间人就能获取 对称加密的密钥 。

避免方式：

• 一个拥有公信力、 大家都认可的认证中心， 数字证书认证机构。
• 服务器在给客户端传输公钥的过程中， 会把公钥和服务器的个人信 息通过 hash 算法
  生成 信息摘要 。
• 为了 防止信息摘要被调换 ， 服务器会采用 CA 提供的私钥 对信息摘要进行加密来形
  成 数字签名 。 最后会把原来没 Hash 算法之前的个人信息、 公钥及、 数字签名合并在
  一起， 形成数字证书。
• 客户端拿到 数字证书 之后， 使用 CA 提供的公钥对数字证书里的数字签名进行解密
  来得到信息摘要， 然后对数字证书里服务器的公钥及个人信息进行 Hash 得到 另一份
  信息摘要 。 最后将两份信息摘要对比， 如果一样则证明是服务器， 否则就是中间人。

23. get 方法和 post 方法的区别？

• GET 方法从服务器获取资源， POST 是向服务器发送数据
• GET 浏览器回退是无害的， 而 POST 会再次提交请求。
• GET 产生的 URL 地址可以被书签收藏， 并且被浏览器缓存， 而 POST 不能书签收藏也
  不能缓存。
• GET 只能进行 URL 编码， 而 POST 支持多种编码方式。
• GET 参数通过 URL 传递， 并且长度有限制， 而 POST 放在 request body 并且长度没
  有限制。 并且， 正因为这个原因， GET 比 POST 更不安全， 因为参数暴露在 URL 中。

二者还有一个显著区别： GET 产生一个 TCP 数据包； POST 产生两个 TCP 数据包。

• 对于 GET 方式的请求， 浏览器会把 http header 和 data 一并发送出去， 服务器响应
  200（返回数据） ；
• 而对于 POST， 浏览器先发送 header， 服务器响应 100 continue， 浏览器再发送 data，
  服务器响应 200 ok（返回数据） 。

24. 什么 XSS 攻击？ 如何预防？（下面这四种攻击找个视频看一下）

跨站脚本攻击

• 存储型 XSS， 也叫持久型 XSS， 主要是将 XSS 代码发送到服务器（不管是数据库、 内
  存还是文件系统等。 ） ， 然后在下次请求页面的时候就不用带上 XSS 代码了。 用户输
  入的带有恶意脚本的数据存储在服务器端。 当浏览器请求数据时， 服务器返回脚本并执
  行。 最典型的就是留言板 XSS。
• 反射型 XSS， 也叫非持久型 XSS， 把用户输入的数据 “反射” 给浏览器。 通常是， 用户
  点击链接或提交表单时， 攻击者向用户访问的网站注入恶意脚本。 XSS 代码出现在请求
  URL 中， 作为参数提交到服务器， 服务器解析并响应。 响应结果中包含 XSS 代码， 最
  后浏览器解析并执行。 从概念上可以看出， 反射型 XSS 代码是首先出现在 URL 中的，
  然后需要服务端解析， 最后需要浏览器解析之后 XSS 代码才能够攻击。

预防：

• 内容安全策略 (CSP)
  • 入参字符过滤
  • 出参进行编码
  • 入参长度限制
• HttpOnly 阻止 Cookie 劫持攻击， 服务器端 Set-Cookie 字段设置 HttpOnly 参数， 这样
  可以避免 Cookie 劫持攻击。 这时候， 客户端的 Document.cookie API 无法访问带有
  HttpOnly 标记的 Cookie, 但可以设置 cookie。

25. 什么是 CSRF 攻击？ 如何预防？

跨站请求伪造： CSRF 就是利用用户的登录态发起恶意请求， 借助用户的 Cookie 骗取服务
器的信任。

如何预防

• Referer Check， 在 HTTP 头中有一个字段叫做 Referer, 它记录了该 HTTP 请求的来源地
  址。
• token 验证： 在 HTTP 请求中以参数的形式加入一个随机产生的 token， 并在服务器端
  建立一个拦截器来验证这个 token， 若请求无 token 或者 token 不正确， 则认为可能
  是 CSRF 攻击而拒绝该请求。
• 验证码： 验证码会强制用户必须与应用进行交互， 才能完成最终请求

26. 什么是 DDoS 攻击？ 如何预防

DDoS 攻击： 全称 Distributed Denial of Service， 中文意思为 “分布式拒绝服务”， 就是利用大
量合法的分布式服务器对目标发送请求， 从而导致正常合法用户无法获得服务。 通俗点讲就
是利用网络节点资源如： IDC 服务器、 个人 PC、 手机、 智能设备、 打印机、 摄像头等对目
标发起大量攻击请求， 从而导致服务器拥塞而无法对外提供正常服务， 只能宣布 game over。

• 资源消耗类攻击： 资源消耗类是比较典型的 DDoS 攻击， 最具代表性的包括： Syn Flood、
  Ack Flood、 UDP Flood。 这类攻击的目标很简单， 就是通过大量请求消耗正常的带宽和
  协议栈处理资源的能力， 从而达到服务端无法正常工作的目的。
• 服务消耗性攻击： 相比资源消耗类攻击， 服务消耗类攻击不需要太大的流量， 它主要是
  针对服务的特点进行精确定点打击， 如 web 的 CC 攻击， 数据服务的检索， 文件服务
  的下载等。 这类攻击往往不是为了拥塞流量通道或协议处理通道， 它们是让服务端始终
  处理高消耗型的业务的忙碌状态， 进而无法对正常业务进行响应

DDoS 的防护系统本质上是一个基于资源较量和规则过滤的智能化系统

• 资源隔离： 资源隔离可以看作是用户服务的一堵防护盾。
• 用户规则： 根据流量类型、 请求频率、 数据包特征、 正常业务之间的延时间隔等， 判断
  用户是否为攻击行为。
• 大数据智能分析

27. 什么是 SQL 注入攻击？ 如何预防？

SQL 注入（SQLi） 是一种注入攻击， 它通过将任意 SQL 代码插入数据库查询， 使攻击者能
够完全控制 Web 应用程序后面的数据库服务器。 攻击者可以使用 SQL 注入漏洞绕过应用
程序安全措施； 可以绕过网页或 Web 应用程序的身份验证和授权， 并检索整个 SQL 数据
库的内容； 还可以使用 SQL 注入来添加， 修改和删除数据库中的记录。

• 带内注入： 依赖于攻击者修改应用程序发送的 SQL， 以及浏览器中显示的错误和返回的
  信息。
• 盲注入： 推理 SQL 注入（根据： HTTP 响应中的详细信息， 某些用户输入的空白网页
  以及数据库响应某些用户输入需要多长时间）
• 带外注入： 攻击者会制作 SQL 语句， 这些语句在呈现给数据库时会触发数据库系统创
  建与攻击者控制的外部服务器的连接。

预防 SQL 注入：

• 不要使用动态 SQL
• 不要将敏感数据保留在纯文本中
• 限制数据库权限和特权
• 避免直接向用户显示数据库错误
• 对访问数据库的 Web 应用程序使用 Web 应用程序防火墙（WAF）
• 将数据库更新为最新的可用修补程序