（一）网络基础知识
1）Http 和 Https 的区别？
答： Http 协议运行在 TCP 之上，明文传输，客户端与服务器端都无法验证对方的身份；Https 是身披 SSL(Secure Socket Layer)外壳的 Http，运行于 SSL 上，SSL 运行于 TCP 之上，是添加了加密和认证机制的 HTTP。二者之间存在如下不同：
• 端口不同：Http 与 Http 使用不同的连接方式，用的端口也不一样，前者是 80，后者是 443； • 资源消耗：和 HTTP 通信相比，Https 通信会由于加减密处理消耗更多的 CPU 和内存资源； • 开销：Https 通信需要证书，而证书一般需要向认证机构购买；
Https 的加密机制是一种共享密钥加密和公开密钥加密并用的混合加密机制。
2）对称加密与非对称加密
答： 对称密钥加密是指加密和解密使用同一个密钥的方式，这种方式存在的最大问题就是密钥发送问题，即如何安全地将密钥发给对方；而非对称加密是指使用一对非对称密钥，即公钥和私钥，公钥可以随意发布，但私钥只有自己知道。发送密文的一方使用对方的公钥进行加密处理，对方接收到加密信息后，使用自己的私钥进行解密。
由于非对称加密的方式不需要发送用来解密的私钥，所以可以保证安全性；但是和对称加密比起来，它非常的慢，所以我们还是要用对称加密来传送消息，但对称加密所使用的密钥我们可以通过非对称加密的方式发送出去。
3）三次握手与四次挥手
答： (1). 三次握手（我要和你建立链接，你真的要和我建立链接么，我真的要和你建立链接，成功）
• 第一次握手：Client 将标志位 SYN 置为 1，随机产生一个值 seq=J，并将该数据包发送给 Server，Client 进入 SYN_SENT 状态，等待 Server 确认。 • 第二次握手：Server 收到数据包后由标志位 SYN=1 知道 Client 请求建立连接，Server 将标志位 SYN 和 ACK 都置为 1，ack=J+1，随机产生一个值 seq=K，并将该数据包发送给 Client 以确认连接请求，Server 进入 SYN_RCVD 状态。 • 第三次握手：Client 收到确认后，检查 ack 是否为 J+1，ACK 是否为 1，如果正确则将标志位 ACK 置为 1，ack=K+1，并将该数据包发送给 Server，Server 检查 ack 是否为 K+1，ACK 是否为 1，如果正确则连接建立成功，Client 和 Server 进入 ESTABLISHED 状态，完成三次握手，随后 Client 与 Server 之间可以开始传输数据了。
(2). 四次挥手（我要和你断开链接；好的，断吧。我也要和你断开链接；好的，断吧）： • 第一次挥手：Client 发送一个 FIN，用来关闭 Client 到 Server 的数据传送，Client 进入 FIN_WAIT_1 状态。 • 第二次挥手：Server 收到 FIN 后，发送一个 ACK 给 Client，确认序号为收到序号 +1（与 SYN 相同，一个 FIN 占用一个序号），Server 进入 CLOSE_WAIT 状态。此时 TCP 链接处于半关闭状态，即客户端已经没有要发送的数据了，但服务端若发送数据，则客户端仍要接收。 • 第三次挥手：Server 发送一个 FIN，用来关闭 Server 到 Client 的数据传送，Server 进入 LAST_ACK 状态。 • 第四次挥手：Client 收到 FIN 后，Client 进入 TIME_WAIT 状态，接着发送一个 ACK 给 Server，确认序号为收到序号 +1，Server 进入 CLOSED 状态，完成四次挥手。
(3). 通俗一点的理解就是：
4）为什么 TCP 链接需要三次握手，两次不可以么？
答： “三次握手” 的目的是为了防止已失效的链接请求报文突然又传送到了服务端，因而产生错误。
• 正常的情况：A 发出连接请求，但因连接请求报文丢失而未收到确认，于是 A 再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接。A 共发送了两个连接请求报文段，其中第一个丢失，第二个到达了 B。没有 “已失效的连接请求报文段”。 • 现假定出现了一种异常情况：即 A 发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达 B。本来这是一个早已失效的报文段。但 B 收到此失效的连接请求报文段后，就误认为是 A 再次发出的一个新的连接请求。于是就向 A 发出确认报文段，同意建立连接。
假设不采用“三次握手”，那么只要 B 发出确认，新的连接就建立了。由于现在 A 并没有发出建立连接的请求，因此不会理睬 B 的确认，也不会向 B 发送数据。但 B 却以为新的运输连接已经建立，并一直等待 A 发来数据。这样，B 的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。
5）为什么要四次挥手？
答： TCP 协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。TCP 是全双工模式，这就意味着，当 A 向 B 发出 FIN 报文段时，只是表示 A 已经没有数据要发送了，而此时 A 还是能够接受到来自 B 发出的数据；B 向 A 发出 ACK 报文段也只是告诉 A ，它自己知道 A 没有数据要发了，但 B 还是能够向 A 发送数据。
所以想要愉快的结束这次对话就需要四次挥手。
6）TCP 协议如何来保证传输的可靠性
答： TCP 提供一种面向连接的、可靠的字节流服务。其中，面向连接意味着两个使用 TCP 的应用（通常是一个客户和一个服务器）在彼此交换数据之前必须先建立一个 TCP 连接。在一个 TCP 连接中，仅有两方进行彼此通信；而字节流服务意味着两个应用程序通过 TCP 链接交换 8 bit 字节构成的字节流，TCP 不在字节流中插入记录标识符。
对于可靠性，TCP 通过以下方式进行保证：
• 数据包校验：目的是检测数据在传输过程中的任何变化，若校验出包有错，则丢弃报文段并且不给出响应，这时 TCP 发送数据端超时后会重发数据； • 对失序数据包重排序：既然 TCP 报文段作为 IP 数据报来传输，而 IP 数据报的到达可能会失序，因此 TCP 报文段的到达也可能会失序。TCP 将对失序数据进行重新排序，然后才交给应用层； • 丢弃重复数据：对于重复数据，能够丢弃重复数据； • 应答机制：当 TCP 收到发自 TCP 连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒； • 超时重发：当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段； • 流量控制：TCP 连接的每一方都有固定大小的缓冲空间。TCP 的接收端只允许另一端发送接收端缓冲区所能接纳的数据，这可以防止较快主机致使较慢主机的缓冲区溢出，这就是流量控制。TCP 使用的流量控制协议是可变大小的滑动窗口协议。
7）客户端不断进行请求链接会怎样？DDos(Distributed Denial of Service)攻击？
答： 服务器端会为每个请求创建一个链接，并向其发送确认报文，然后等待客户端进行确认
(1). DDos 攻击：
• 客户端向服务端发送请求链接数据包 • 服务端向客户端发送确认数据包 • 客户端不向服务端发送确认数据包，服务器一直等待来自客户端的确认
(2). DDos 预防：（没有彻底根治的办法，除非不使用TCP）
• 限制同时打开 SYN 半链接的数目 • 缩短 SYN 半链接的 Time out 时间 • 关闭不必要的服务
8）GET 与 POST 的区别？
答： GET 与 POST 是我们常用的两种 HTTP Method，二者之间的区别主要包括如下五个方面：
(1). 从功能上讲，GET 一般用来从服务器上获取资源，POST 一般用来更新服务器上的资源； (2). 从 REST 服务角度上说，GET 是幂等的，即读取同一个资源，总是得到相同的数据，而 POST 不是幂等的，因为每次请求对资源的改变并不是相同的；进一步地，GET 不会改变服务器上的资源，而 POST 会对服务器资源进行改变； (3). 从请求参数形式上看，GET 请求的数据会附在 URL 之后，即将请求数据放置在 HTTP 报文的请求头 中，以 ? 分割 URL 和传输数据，参数之间以 & 相连。特别地，如果数据是英文字母/数字，原样发送；否则，会将其编码为 application/x-www-form-urlencoded MIME 字符串(如果是空格，转换为+，如果是中文/其他字符，则直接把字符串用 BASE64 加密，得出如：%E4%BD%A0%E5%A5%BD，其中 ％XX 中的 XX 为该符号以 16 进制表示的ASCII)；而 POST 请求会把提交的数据则放置在是 HTTP 请求报文的 请求体 中。 (4). 就安全性而言，POST 的安全性要比 GET 的安全性高，因为 GET 请求提交的数据将明文出现在 URL 上，而且 POST 请求参数则被包装到请求体中，相对更安全。 (5). 从请求的大小看，GET 请求的长度受限于浏览器或服务器对 URL 长度的限制，允许发送的数据量比较小，而 POST 请求则是没有大小限制的。
为什么在 GET 请求中会对 URL 进行编码？
我们知道，在 GET 请求中会对 URL 中非西文字符进行编码，这样做的目的就是为了 避免歧义。看下面的例子，
针对 “name1=value1&name2=value2” 的例子，我们来谈一下数据从客户端到服务端的解析过程。首先，上述字符串在计算机中用 ASCII 码表示为：
服务端在接收到该数据后就可以遍历该字节流，一个字节一个字节的吃，当吃到 3D 这字节后，服务端就知道前面吃得字节表示一个 key，再往后吃，如果遇到 26，说明从刚才吃的 3D 到 26 子节之间的是上一个 key 的 value，以此类推就可以解析出客户端传过来的参数。6E616D6531 3D 76616C756531 26 6E616D6532 3D 76616C756532
6E616D6531：name1
3D：=
76616C756531：value1
26：&
6E616D6532：name2
3D：=
76616C756532：value2
现在考虑这样一个问题，如果我们的参数值中就包含=或&这种特殊字符的时候该怎么办？比如，“name1=value1”，其中 value1 的值是“va&lu=e1”字符串，那么实际在传输过程中就会变成这样“name1=va&lu=e1”。这样，我们的本意是只有一个键值对，但是服务端却会解析成两个键值对，这样就产生了歧义。
那么，如何解决上述问题带来的歧义呢？解决的办法就是对参数进行 URL 编码：例如，我们对上述会产生歧义的字符进行 URL 编码后结果：“name1=va%26lu%3D”，这样服务端会把紧跟在“%”后的字节当成普通的字节，就是不会把它当成各个参数或键值对的分隔符。
9）TCP 与 UDP 的区别
答： TCP (Transmission Control Protocol)和 UDP(User Datagram Protocol)协议属于传输层协议，它们之间的区别包括：
• TCP 是面向连接的，UDP 是无连接的； • TCP 是可靠的，UDP 是不可靠的； • TCP 只支持点对点通信，UDP 支持一对一、一对多、多对一、多对多的通信模式； • TCP 是面向字节流的，UDP 是面向报文的； • TCP 有拥塞控制机制;UDP 没有拥塞控制，适合媒体通信； • TCP 首部开销(20 个字节)比 UDP 的首部开销(8 个字节)要大；
10）TCP 和 UDP 分别对应的常见应用层协议
答： (1). TCP 对应的应用层协议：
• FTP：定义了文件传输协议，使用 21 端口。常说某某计算机开了 FTP 服务便是启动了文件传输服务。下载文件，上传主页，都要用到 FTP 服务。 • Telnet：它是一种用于远程登陆的端口，用户可以以自己的身份远程连接到计算机上，通过这种端口可以提供一种基于 DOS 模式下的通信服务。如以前的 BBS 是-纯字符界面的，支持 BBS 的服务器将 23 端口打开，对外提供服务。 • SMTP：定义了简单邮件传送协议，现在很多邮件服务器都用的是这个协议，用于发送邮件。如常见的免费邮件服务中用的就是这个邮件服务端口，所以在电子邮件设置-中常看到有这么 SMTP 端口设置这个栏，服务器开放的是 25 号端口。 • POP3：它是和 SMTP 对应，POP3 用于接收邮件。通常情况下，POP3 协议所用的是 110 端口。也是说，只要你有相应的使用 POP3 协议的程序（例如 Fo-xmail 或 Outlook），就可以不以 Web 方式登陆进邮箱界面，直接用邮件程序就可以收到邮件（如是 163 邮箱就没有必要先进入网易网站，再进入自己的邮-箱来收信）。 • HTTP：从 Web 服务器传输超文本到本地浏览器的传送协议。
(2). UDP 对应的应用层协议：
• DNS：用于域名解析服务，将域名地址转换为 IP 地址。DNS 用的是 53 号端口。 • SNMP：简单网络管理协议，使用 161 号端口，是用来管理网络设备的。由于网络设备很多，无连接的服务就体现出其优势。 • TFTP(Trival File Transfer Protocal)：简单文件传输协议，该协议在熟知端口 69 上使用 UDP 服务
(3). 图示：
11）TCP 的拥塞避免机制
答： 拥塞：对资源的需求超过了可用的资源。若网络中许多资源同时供应不足，网络的性能就要明显变坏，整个网络的吞吐量随之负荷的增大而下降。 拥塞控制：防止过多的数据注入到网络中，使得网络中的路由器或链路不致过载。
拥塞控制的方法：
(1). 慢启动 + 拥塞避免：
慢启动：不要一开始就发送大量的数据，先探测一下网络的拥塞程度，也就是说由小到大逐渐增加拥塞窗口的大小;
拥塞避免：拥塞避免算法让拥塞窗口缓慢增长，即每经过一个往返时间 RTT 就把发送方的拥塞窗口 cwnd 加 1，而不是加倍，这样拥塞窗口按线性规律缓慢增长。
(2). 快重传 + 快恢复：
快重传：快重传要求接收方在收到一个 失序的报文段 后就立即发出 重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时捎带确认。快重传算法规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。
快恢复：快重传配合使用的还有快恢复算法，当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把 ssthresh 门限减半，但是接下去并不执行慢开始算法：因为如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法，而是将 cwnd 设置为 ssthresh 的大小，然后执行拥塞避免算法。
12）浏览器中输入：“`www.xxx.com`” 之后都发生了什么？请详细阐述。
解析：经典的网络协议问题。
答： 1、由域名→IP 地址 寻找 IP 地址的过程依次经过了浏览器缓存、系统缓存、hosts 文件、路由器缓存、 递归搜索根域名服务器。 2、建立 TCP/IP 连接（三次握手具体过程） 3、由浏览器发送一个 HTTP 请求 4、经过路由器的转发，通过服务器的防火墙，该 HTTP 请求到达了服务器 5、服务器处理该 HTTP 请求，返回一个 HTML 文件 6、浏览器解析该 HTML 文件，并且显示在浏览器端 7、这里需要注意：
• HTTP 协议是一种基于 TCP/IP 的应用层协议，进行 HTTP 数据请求必须先建立 TCP/IP 连接 • 可以这样理解：HTTP 是轿车，提供了封装或者显示数据的具体形式；Socket 是发动机，提供了网络通信的能力。 • 两个计算机之间的交流无非是两个端口之间的数据通信,具体的数据会以什么样的形式展现是以不同的应用层协议来定义的。
13）什么是 HTTP 协议无状态协议？怎么解决 Http 协议无状态协议?
答： HTTP 是一个无状态的协议，也就是没有记忆力，这意味着每一次的请求都是独立的，缺少状态意味着如果后续处理需要前面的信息，则它必须要重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就很快。
HTTP 的这种特性有优点也有缺点：
• 优点：解放了服务器，每一次的请求“点到为止”，不会造成不必要的连接占用 • 缺点：每次请求会传输大量重复的内容信息，并且，在请求之间无法实现数据的共享
解决方案：
• 使用参数传递机制：
将参数拼接在请求的 URL 后面，实现数据的传递（GET方式），例如：/param/list?username=wmyskxz
问题：可以解决数据共享的问题，但是这种方式一不安全，二数据允许传输量只有 1kb • 使用 Cookie 技术 • 使用 Session 技术
14）Session、Cookie 与 Application
答： Cookie 和 Session 都是客户端与服务器之间保持状态的解决方案，具体来说，cookie 机制采用的是在客户端保持状态的方案，而 session 机制采用的是在服务器端保持状态的方案。
(1). Cookie 及其相关 API ：
Cookie 实际上是一小段的文本信息。客户端请求服务器，如果服务器需要记录该用户状态，就使用 response 向客户端浏览器颁发一个 Cookie，而客户端浏览器会把 Cookie 保存起来。当浏览器再请求该网站时，浏览器把请求的网址连同该 Cookie 一同提交给服务器，服务器检查该 Cookie，以此来辨认用户状态。服务器还可以根据需要修改 Cookie 的内容。
(2). Session 及其相关 API：
同样地，会话状态也可以保存在服务器端。客户端请求服务器，如果服务器记录该用户状态，就获取 Session 来保存状态，这时，如果服务器已经为此客户端创建过 session，服务器就按照 sessionid 把这个 session 检索出来使用；如果客户端请求不包含 sessionid，则为此客户端创建一个 session 并且生成一个与此 session 相关联的 sessionid，并将这个 sessionid 在本次响应中返回给客户端保存。保存这个 sessionid 的方式可以采用 cookie 机制 ，这样在交互过程中浏览器可以自动的按照规则把这个标识发挥给服务器；若浏览器禁用 Cookie 的话，可以通过 URL 重写机制 将 sessionid 传回服务器。
(3). Session 与 Cookie 的对比： • 实现机制：Session 的实现常常依赖于 Cookie 机制，通过 Cookie 机制回传 SessionID； • 大小限制：Cookie 有大小限制并且浏览器对每个站点也有 cookie 的个数限制，Session 没有大小限制，理论上只与服务器的内存大小有关； • 安全性：Cookie 存在安全隐患，通过拦截或本地文件找得到 cookie 后可以进行攻击，而 Session 由于保存在服务器端，相对更加安全； • 服务器资源消耗：Session 是保存在服务器端上会存在一段时间才会消失，如果 session 过多会增加服务器的压力。
(4). Application：
Application（ServletContext）：与一个Web应用程序相对应，为应用程序提供了一个全局的状态，所有客户都可以使用该状态。
15）滑动窗口机制
答： 由发送方和接收方在三次握手阶段，互相将自己的最大可接收的数据量告诉对方。也就是自己的数据接收缓冲池的大小。这样对方可以根据已发送的数据量来计算是否可以接着发送。在处理过程中，当接收缓冲池的大小发生变化时，要给对方发送更新窗口大小的通知。这就实现了流量的控制。
16）常用的 HTTP 方法有哪些？
答： • GET：用于请求访问已经被 URI（统一资源标识符）识别的资源，可以通过 URL 传参给服务器 • POST：用于传输信息给服务器，主要功能与 GET 方法类似，但一般推荐使用POST方式。 • PUT：传输文件，报文主体中包含文件内容，保存到对应 URI 位置。 • HEAD：获得报文首部，与 GET 方法类似，只是不返回报文主体，一般用于验证 URI 是否有效。 • DELETE：删除文件，与 PUT 方法相反，删除对应 URI 位置的文件。 • OPTIONS：查询相应 URI 支持的 HTTP 方法。
17）常见HTTP状态码
答： 1、1xx（临时响应） 2、2xx（成功） 3、3xx（重定向）：表示要完成请求需要进一步操作 4、4xx（错误）：表示请求可能出错，妨碍了服务器的处理 5、5xx（服务器错误）：表示服务器在尝试处理请求时发生内部错误 6、常见状态码：
- 200（成功）
- 304（未修改）：自从上次请求后，请求的网页未修改过。服务器返回此响应时，不会返回网页内容
- 401（未授权）：请求要求身份验证
- 403（禁止）：服务器拒绝请求
- 404（未找到）：服务器找不到请求的网页
18）SQL 注入
答： SQL 注入就是通过把 SQL 命令插入到 Web 表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的 SQL 命令。
(1).SQL 注入攻击的总体思路：
1、寻找到 SQL 注入的位置 2、判断服务器类型和后台数据库类型 3、针对不通的服务器和数据库特点进行 SQL 注入攻击
(2). SQL注入攻击实例：
比如，在一个登录界面，要求输入用户名和密码，可以这样输入实现免帐号登录：
用户一旦点击登录，如若没有做特殊处理，那么这个非法用户就很得意的登陆进去了。这是为什么呢?下面我们分析一下：从理论上说，后台认证程序中会有如下的 SQL 语句：用户名： ‘or 1 = 1 --
密 码：
String sql = “select * from user_table where username=’ “+userName+” ’ and password=’ “+password+” ‘”; 因此，当输入了上面的用户名和密码，上面的 SQL 语句变成： SELECT * FROM user_table WHERE username=’’or 1 = 1 – and password=’’ 分析上述 SQL 语句我们知道，username=‘ or 1=1 这个语句一定会成功；然后后面加两个-，这意味着注释，它将后面的语句注释，让他们不起作用。这样，上述语句永远都能正确执行，用户轻易骗过系统，获取合法身份。(3). 应对方法：
1.参数绑定：
使用预编译手段，绑定参数是最好的防 SQL 注入的方法。目前许多的 ORM 框架及 JDBC 等都实现了 SQL 预编译和参数绑定功能，攻击者的恶意 SQL 会被当做 SQL 的参数而不是 SQL 命令被执行。在 mybatis 的 mapper 文件中，对于传递的参数我们一般是使用#和
时，变量就是直接追加在 sql 中，一般会有 sql 注入问题。不能识别此Latex公式:
来获取参数值。当使用#时，变量是占位符，就是一般我们使用javajdbc的PrepareStatement时的占位符，所有可以防止sql注入；当使用
2.使用正则表达式过滤传入的参数
19）XSS 攻击
答： XSS 是一种经常出现在 web 应用中的计算机安全漏洞，与 SQL 注入一起成为 web 中最主流的攻击方式。XSS 是指恶意攻击者利用网站没有对用户提交数据进行转义处理或者过滤不足的缺点，进而添加一些脚本代码嵌入到 web 页面中去，使别的用户访问都会执行相应的嵌入代码，从而盗取用户资料、利用用户身份进行某种动作或者对访问者进行病毒侵害的一种攻击方式。
(1). XSS 攻击的危害：
• 盗取各类用户帐号，如机器登录帐号、用户网银帐号、各类管理员帐号 • 控制企业数据，包括读取、篡改、添加、删除企业敏感数据的能力 • 盗窃企业重要的具有商业价值的资料 • 非法转账 • 强制发送电子邮件 • 网站挂马 • 控制受害者机器向其它网站发起攻击 (2). 原因解析：
• 主要原因：过于信任客户端提交的数据！ • 解决办法：不信任任何客户端提交的数据，只要是客户端提交的数据就应该先进行相应的过滤处理然后方可进行下一步的操作。 • 进一步分析细节：客户端提交的数据本来就是应用所需要的，但是恶意攻击者利用网站对客户端提交数据的信任，在数据中插入一些符号以及javascript代码，那么这些数据将会成为应用代码中的一部分了，那么攻击者就可以肆无忌惮地展开攻击啦，因此我们绝不可以信任任何客户端提交的数据！！！
(3). XSS 攻击分类：
• 1. 反射性 XSS 攻击（非持久性 XSS 攻击）：
漏洞产生的原因是攻击者注入的数据反映在响应中。一个典型的非持久性 XSS 攻击包含一个带 XSS 攻击向量的链接(即每次攻击需要用户的点击)，例如，正常发送消息：
接收者将会接收信息并显示 Hello,World；但是，非正常发送消息：http://www.test.com/message.php?send=Hello,World！
http://www.test.com/message.php?send=<script>alert(‘foolish!’)</script>！
接收者接收消息显示的时候将会弹出警告窗口！
• 2. 持久性 XSS 攻击 (留言板场景)：
XSS 攻击向量(一般指 XSS 攻击代码)存储在网站数据库，当一个页面被用户打开的时候执行。也就是说，每当用户使用浏览器打开指定页面时，脚本便执行。与非持久性 XSS 攻击相比，持久性 XSS 攻击危害性更大。从名字就可以了解到，持久性 XSS 攻击就是将攻击代码存入数据库中，然后客户端打开时就执行这些攻击代码。
例如，留言板表单中的表单域：
正常操作流程是：用户是提交相应留言信息 —— 将数据存储到数据库 —— 其他用户访问留言板，应用去数据并显示；而非正常操作流程是攻击者在 value 填写:<input type=“text” name=“content” value=“这里是用户填写的数据”>
并将数据提交、存储到数据库中；当其他用户取出数据显示的时候，将会执行这些攻击性代码。<script>alert(‘foolish!’)；</script> <!--或者html其他标签（破坏样式）、一段攻击型代码-->
(4). 修复漏洞方针：
漏洞产生的根本原因是 太相信用户提交的数据，对用户所提交的数据过滤不足所导致的，因此解决方案也应该从这个方面入手，具体方案包括：
• 将重要的cookie标记为http only, 这样的话Javascript 中的 document.cookie 语句就不能获取到 cookie 了（如果在 cookie 中设置了 HttpOnly 属性，那么通过js脚本将无法读取到 cookie 信息，这样能有效的防止 XSS 攻击）； • 表单数据规定值的类型，例如：年龄应为只能为 int、name 只能为字母数字组合 • 对数据进行Html Encode 处理 • 过滤或移除特殊的Html标签，例如: <script>, <iframe> , < for <, > for>, " for • 过滤JavaScript 事件的标签，例如 “onclick=”, “onfocus” 等等。
需要注意的是，在有些应用中是允许 html 标签出现的，甚至是 javascript 代码出现。因此，我们在过滤数据的时候需要仔细分析哪些数据是有特殊要求（例如输出需要 html 代码、javascript 代码拼接、或者此表单直接允许使用等等），然后区别处理！
20）OSI 网络体系结构与 TCP/IP 协议模型
答： OSI 是一个理论上的网络通信模型，而 TCP/IP 则是实际上的网络通信标准。但是，它们的初衷是一样的，都是为了使得两台计算机能够像两个知心朋友那样能够互相准确理解对方的意思并做出优雅的回应。现在，我们对 OSI 七层模型的各层进行简要的介绍：
(1). 物理层 参考模型的最低层，也是 OSI 模型的第一层，实现了相邻计算机节点之间比特流的透明传送，并尽可能地屏蔽掉具体传输介质和物理设备的差异，使其上层(数据链路层)不必关心网络的具体传输介质。
(2). 数据链路层（data link layer） 接收来自物理层的位流形式的数据，并封装成帧，传送到上一层；同样，也将来自上层的数据帧，拆装为位流形式的数据转发到物理层。这一层在物理层提供的比特流的基础上，通过差错控制、流量控制方法，使有差错的物理线路变为无差错的数据链路，即提供可靠的通过物理介质传输数据的方法。
(3). 网络层 将网络地址翻译成对应的物理地址，并通过路由选择算法为分组通过通信子网选择最适当的路径。
(4). 传输层（transport layer） 在源端与目的端之间提供可靠的透明数据传输，使上层服务用户不必关系通信子网的实现细节。在协议栈中，传输层位于网络层之上，传输层协议为不同主机上运行的进程提供逻辑通信，而网络层协议为不同主机提供逻辑通信，如下图所示。
实际上，网络层可以看作是传输层的一部分，其为传输层提供服务。但对于终端系统而言，网络层对它们而言是透明的，它们知道传输层的存在，也就是说，在逻辑上它们认为是传输层为它们提供了端对端的通信，这也是分层思想的妙处。
(5). 会话层（Session Layer） 会话层是 OSI 模型的第五层，是用户应用程序和网络之间的接口，负责在网络中的两节点之间建立、维持和终止通信。
(6). 表示层（Presentation Layer）：数据的编码，压缩和解压缩，数据的加密和解密 表示层是 OSI 模型的第六层，它对来自应用层的命令和数据进行解释，以确保一个系统的应用层所发送的信息可以被另一个系统的应用层读取。
(7). 应用层（Application layer）：为用户的应用进程提供网络通信服务
21）网络层的 ARP 协议工作原理？
答： 地址解析协议(ARP) 是通过解析网路层地址来找寻数据链路层地址的一个在网络协议包中极其重要的网络传输协议。
网络层的 ARP 协议完成了 IP 地址与物理地址的映射。首先，每台主机都会在自己的 ARP 缓冲区中建立一个 ARP 列表，以表示 IP 地址和 MAC 地址的对应关系。当源主机需要将一个数据包要发送到目的主机时，会首先检查自己 ARP 列表中是否存在该 IP 地址对应的 MAC 地址：如果有，就直接将数据包发送到这个 MAC 地址；如果没有，就向本地网段发起一个 ARP 请求的广播包，查询此目的主机对应的 MAC 地址。此 ARP 请求数据包里包括源主机的 IP 地址、硬件地址、以及目的主机的 IP 地址。网络中所有的主机收到这个 ARP 请求后，会检查数据包中的目的 IP 是否和自己的 IP 地址一致。如果不相同就忽略此数据包；如果相同，该主机首先将发送端的 MAC 地址和 IP 地址添加到自己的 ARP 列表中，如果 ARP 表中已经存在该 IP 的信息，则将其覆盖，然后给源主机发送一个 ARP 响应数据包，告诉对方自己是它需要查找的 MAC 地址；源主机收到这个 ARP 响应数据包后，将得到的目的主机的 IP 地址和 MAC 地址添加到自己的 ARP 列表中，并利用此信息开始数据的传输。如果源主机一直没有收到 ARP 响应数据包，表示 ARP 查询失败。
22）IP 地址的分类
答：整个的因特网就是一个单一的、抽象的网络。IP 地址就是给因特网上的每一个主机（或路由器）的每一个接口分配一个在全世界范围是唯一的 32 位标识符，它是一个逻辑地址，用以屏蔽掉物理地址的差异。IP 地址编址方案将 IP 地址空间划分为 A、B、C、D、E 五类，其中 A、B、C 是基本类，D、E 类作为多播和保留使用，为特殊地址。
每个 IP 地址包括两个标识码（ID），即网络 ID 和主机 ID。同一个物理网络上的所有主机都使用同一个网络 ID，网络上的一个主机（包括网络上工作站，服务器和路由器等）有一个主机 ID 与其对应。A~E 类地址的特点如下：
• A类地址：以0开头，第一个字节范围：0~127； • B类地址：以10开头，第一个字节范围：128~191； • C类地址：以110开头，第一个字节范围：192~223； • D类地址：以1110开头，第一个字节范围为224~239； • E类地址：以1111开头，保留地址
(1). A类地址：1 字节的网络地址 + 3 字节主机地址，网络地址的最高位必须是“0”
一个 A类 IP 地址是指， 在 IP 地址的四段号码中，第一段号码为网络号码，剩下的三段号码为本地计算机的号码。如果用二进制表示 IP 地址的话，A类 IP 地址就由 1 字节的网络地址和 3 字节主机地址组成，网络地址的最高位必须是“0”。A类 IP 地址中网络的标识长度为 8 位，主机标识的长度为 24 位，A类网络地址数量较少，有 126 个网络，每个网络可以容纳主机数达 1600 多万台。
A类 IP 地址的地址范围 1.0.0.0 到 127.255.255.255（二进制表示为：00000001 00000000 00000000 00000000 - 01111110 11111111 11111111 11111111），最后一个是广播地址。A类 IP 地址的子网掩码为 255.0.0.0，每个网络支持的最大主机数为 256 的 3 次方-2=16777214 台。
(2). B类地址: 2 字节的网络地址 + 2 字节主机地址，网络地址的最高位必须是“10”
一个 B 类 IP 地址是指，在 IP 地址的四段号码中，前两段号码为网络号码。如果用二进制表示 IP 地址的话，B 类 IP 地址就由 2 字节的网络地址和 2 字节主机地址组成，网络地址的最高位必须是“10”。B 类 IP 地址中网络的标识长度为 16 位，主机标识的长度为 16 位，B 类网络地址适用于中等规模的网络，有 16384 个网络，每个网络所能容纳的计算机数为 6 万多台。
B 类 IP 地址地址范围 128.0.0.0-191.255.255.255（二进制表示为：10000000 00000000 00000000 00000000—-10111111 11111111 11111111 11111111），最后一个是广播地址。B 类 IP 地址的子网掩码为 255.255.0.0，每个网络支持的最大主机数为 256 的 2 次方-2=65534 台。
(3). C类地址: 3 字节的网络地址 + 1 字节主机地址，网络地址的最高位必须是“110”
一个 C 类 IP 地址是指，在 IP 地址的四段号码中，前三段号码为网络号码，剩下的一段号码为本地计算机的号码。如果用二进制表示 IP 地址的话，C 类 IP 地址就由 3 字节的网络地址和 1 字节主机地址组成，网络地址的最高位必须是“110”。C 类 IP 地址中网络的标识长度为 24 位，主机标识的长度为 8 位，C 类网络地址数量较多，有 209 万余个网络。适用于小规模的局域网络，每个网络最多只能包含 254 台计算机。
C 类 IP 地址范围 192.0.0.0-223.255.255.255（二进制表示为: 11000000 00000000 00000000 00000000 - 11011111 11111111 11111111 11111111）。C 类 IP 地址的子网掩码为 255.255.255.0，每个网络支持的最大主机数为 256-2=254 台。
(4). D类地址:多播地址，用于1对多通信，最高位必须是“1110”
D 类 IP 地址在历史上被叫做多播地址(multicast address)，即组播地址。在以太网中，多播地址命名了一组应该在这个网络中应用接收到一个分组的站点。多播地址的最高位必须是“1110”，范围从 224.0.0.0 到 239.255.255.255。
(5). E类地址:为保留地址，最高位必须是“1111”
23）IP 地址与物理地址
答：物理地址是数据链路层和物理层使用的地址，IP 地址是网络层和以上各层使用的地址，是一种逻辑地址，其中 ARP 协议用于 IP 地址与物理地址的对应。
24）影响网络传输的因素有哪些？
答： 将一份数据从一个地方正确地传输到另一个地方所需要的时间我们称之为响应时间。影响这个响应时间的因素有很多。
• 网络带宽：所谓带宽就是一条物理链路在 1s 内能够传输的最大比特数，注意这里是比特（bit）而不是字节数，也就是 b/s 。网络带宽肯定是影响数据传输的一个关键环节，因为在当前的网络环境中，平均网络带宽只有 1.7 MB/s 左右。 • 传输距离：也就是数据在光纤中要走的距离，虽然光的传播速度很快，但也是有时间的，由于数据在光纤中的移动并不是走直线的，会有一个折射率，所以大概是光的 2/3，这个时间也就是我们通常所说的传输延时。传输延时是一个无法避免的问题，例如，你要给在杭州和青岛的两个机房的一个数据库进行同步数据操作，那么必定会存在约 30ms 的一个延时。 • TCP 拥塞控制：我们知道 TCP 传输是一个 “停-等-停-等” 的协议，传输方和接受方的步调要一致，要达到步调一致就要通过拥塞控制来调节。TCP 在传输时会设定一个 “窗口”，这个窗口的大小是由带宽和 RTT（Round-Trip Time，数据在两端的来回时间，也就是响应时间）决定的。计算的公式是带宽（b/s）xRTT（s）。通过这个值就可以得出理论上最优的 TCP 缓冲区的大小。Linux 2.4 已经可以自动地调整发送端的缓冲区的大小，而到 Linux 2.6.7 时接收端也可以自动调整了。
- END -
网友评论