计算机网络

TCP从多个方面来保证了可靠性的传输

检验和：TCP报文首部有一个检验和，可以检测数据在传输过层中的任何变化，如果收到段的校验和有差错，tcp会丢弃这个报文段。

**序列号/确认应答：**TCP传输的过程中，每次接收方收到数据后，都会对传输方进行确认应答。也就是发送ACK报文，这个ACK报文当中带有对应的确认序列号，告诉发送方，接收到了哪些数据，下一次的数据从哪里发。

滑动窗口：利用滑动窗口协议，在窗口中定义了允许使用序列号的范围，并会进行更新。滑动窗口既提高了报文传输的效率，也避免了发送方发送的数据太多导致接收方不能正常处理。

超时重传：通过计算发送出去的数据包到接收到确认包之间的时间判断是否需要重传，如果超过了这个时间会被认为是丢包了，需要重传。最大超时时间是动态计算的。

**拥塞控制：通过拥塞控制避免发送方发送速率太快导致网络处理不了，**在数据传输过程中，可能由于网络状态的问题，造成网络拥堵。使用拥塞控制机制，如果处于发生了拥塞则会动态调整自己的发送速率。在保证TCP可靠性的同时，提高性能。

**流量控制：**如果主机A 一直向主机B发送数据，不考虑主机B的接受能力，可能导致主机B的接受缓冲区满了而无法再接受数据，从而会导致大量的数据丢包，引发重传机制。而在重传的过程中，若主机B的接收缓冲区情况仍未好转，则会将大量的时间浪费在重传数据上，降低传送数据的效率。所以引入流量控制机制，主机B通过告诉主机A自己接收缓冲区的大小，来使主机A控制发送的数据量。流量控制与TCP协议报头中的窗口大小有关。

TCP的拥塞控制方法

TCP采用基于窗口的方法进行拥塞控制。发送方维持一个拥塞窗口 CWND大小，并根据网络的拥塞程度，动态地调整窗口大小。并且发送端利用拥塞窗口调整发送的数据量。 除此之外，发送方的窗口大小还取决于接收方公告的接收窗口。

因此真正的发送窗口值为。

真正的发送窗口值 = Min(对方窗口，拥塞窗口值)拥塞的判断

重传定时器超时

收到三个相同的ACK发生loss事件

TCP拥塞控制算法

慢开始

慢开始不是指cwnd的增长速度慢（指数增长），而是指TCP开始发送设置cwnd=1。之后以指数方式进行增长

思路：不要一开始就发送大量的数据，先探测一下网络的拥塞程度，也就是说由小到大逐渐增加拥塞窗口的大小。拥塞窗口大小是以字节为单位的。 (1，2，4，8，16，17，18…)

拥塞避免

当拥塞窗口大小增加到慢开始门限的时候，在拥塞避免阶段将拥塞窗口控制为按线性规律增长，使网络比较不容易出现拥塞。 思路：让拥塞窗口cwnd缓慢地增大，即每经过一个往返时间RTT就把发送方的拥塞控制窗口加一。

为了防止cwnd增长过大引起网络拥塞，设置一个慢开始门限（ssthresh状态变量）

快恢复

当发现超时事件，则从新进入慢开始阶段 。当发现出现数据丢包时，收到3个相同的ACK（发生了loss事件），下次发送的个数为阈值的一半，并采用拥塞避免算法。

快重传

快重传要求接收方在收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时捎带确认。快重传算法规定，发送方只要一连收到三个重复确认ACK就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-IGbD2hQX-1657959229133)(C:\Users\Hao\Desktop\面试\img\image-20220715210121808.png)]

拥塞控制是一个全局的过程，涉及所有的主机、所有的路由器，以及与降低网络传输性能有关的所有因素。流量控制往往是指点对点通信量的控制，（接收端控制发送端）。流量控制要做的就是抑制发送端发送数据的速率，以便使接收端来得及接收。

第一次握手：客户端请求建立连接，向服务端发送一个同步报文（同步序列号SYN=1），同时选择一个随机数 seq = x 作为初始序列号，并进入SYN_SENT（就是同步已发送状态）状态，等待服务器确认。

第二次握手：：服务端收到连接请求报文后，如果同意建立连接的话，向客户端就会发送同步确认报文（SYN=1，ACK=1），确认号为 ack = x + 1，同时选择一个随机数 seq = y 作为初始序列号，此时服务器进入SYN_RECV（同步收到）状态。

第三次握手：客户端收到服务端的确认后，向服务端发送一个确认报文（ACK=1），确认号为 ack = y + 1，序列号为 seq = x + 1，客户端和服务器都处于ESTABLSHED状态，完成三次握手。

主要就是为了防止已经失效的连接请求报文段突然又传送到了 B，产生错误。就比如这种情况：A 发出的第一个连接请求报文段并没有丢失，节点在网路结点长时间滞留了，一直延误到连接释放以后才到达 B。本来这是一个早就失效的报文段。但是 B 收到这个链接请求报文段后，就误认为 A 又发出一次新的连接请求。于是就会向 A 发出确认报文段，同意建立连接，B 发出确认后就认为新的连接已经建立了，并一直等待 A 发来数据。B 的许多资源就这样白白浪费了。

三次握手连接阶段，最后一次ACK包丢失，会发生什么？

服务端：第三次的ACK在网络中丢失，那么服务端的这个TCP连接的状态为SYN_RECV,并且会根据 TCP的超时重传机制，会等待3秒、6秒、12秒后重新发送SYN+ACK包，以便客户端重新发送ACK包。 如果重发指定次数之后，仍然未收到 客户端的ACK应答，那么一段时间后，服务端自动关闭这个连接。

客户端：客户端认为这个连接已经建立，如果客户端向服务端发送数据，服务端将以RST包（Reset，标示复位，用于异常的关闭连接）响应。此时，客户端知道第三次握手失败。

第一次挥手：客户端向服务端发送连接释放报文（FIN=1）序列号为seq=u，主动关闭连接，同时等待服务端的确认。客户端这时候处于FIN_WAIT1状态

第二次挥手：服务端收到连接释放报文后，立即发出确认报文（ACK=1），序列号 seq = k，确认号 ack = u + 1。服务端进入CLOSE_WAIT

这时 TCP 连接处于半关闭状态，客户端到服务端的连接已经释放了，但是服务端到客户端的连接还没有释放。这表示客户端已经没有数据发送了，但是服务端可能还要给客户端发送数据。

第三次挥手：服务端向客户端发送连接释放报文（FIN=1，ACK=1），序列号 seq = w，确认号 ack = u + 1。主动关闭连接，同时等待客户端的的确认。

第四次挥手：客户端收到服务端的连接释放报文后，立即发出确认报文（ACK=1），序列号 seq = u + 1，确认号为 ack = w + 1。 此时，客户端就进入了 TIME-WAIT 状态必须经过 2*MSL（最长报文段寿命）的时间后，才进入 CLOSED 状态。而服务端只要收到客户端发出的确认，就立即进入 CLOSED 状态

因为TCP连接是全双工的网络协议，允许同时通信的双方同时进行数据的收发，同样也允许收发两个方向的连接被独立关闭，以避免client数据发送完毕，向server发送FIN关闭连接，而server还有发送到client的数据没有发送完毕的情况。所以关闭TCP连接需要进行四次挥手，每次关闭一个方向上的连接需要FIN和ACK两次握手。

为什么要等2*MSL（为什么是2MSL：因为发送最后一次ACK和接收新的FIN+ACK一共两个报文段）

为了保证客户端发送的最后一个ACK报文段能够到达服务器。因为这个ACK有可能丢失，接着客户端再重传一次ACK确认。最后客户端和服务器都能正常的关闭。假设客户端不等待2MSL，而是在发送完ACK之后直接释放关闭，一但这个ACK丢失的话，服务器就无法正常的进入关闭连接状态。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-cAvpdVdX-1657959229134)(C:\Users\Hao\Desktop\面试\img\image-20220715212502973.png)]

物理地址是数据链路层和物理层使用的地址，而ip地址则是网络层及以上各层使用的地址，是一种逻辑地址。ip地址放在ip数据包的首部，而硬件地址则放在MAC帧的首部，当ip数据包放入数据链路层的MAC帧中以后，整个ip数据包就成为MAC帧的数据，因而在数据链路层看不到数据包的ip地址只能看见MAC帧。因此需要用rap协议进行ip地址到数据链路层地址的转换。

IP地址是互联网上计算机唯一的逻辑地址，通过IP地址实现不同计算机之间的相互通信，每台联网计算机都需要通过IP地址来互相联系和分别

每一个ip地址都是通过网络号和主机号两个部分组成，从这个意义上说ip地址是一个分等级的地址结构。可以分为A类B类和C类三类

A类地址：A类地址的网络标识由第一组8位二进制数表示，A类地址的特点是网络标识的第一位二进制数取值必须为“0”。不难算出，A类地址允许有126个网段，每个网络大约允许有1670万台主机，通常分配给拥有大量主机的网络（如主干网）。

B类地址：B类地址的网络标识由前两组8位二进制数表示，网络中的主机标识占两组8位二进制数，B类地址的特点是网络标识的前两位二进制数取值必须为“10”。B类地址允许有16384个网段，每个网络允许有65533台主机，适用于结点比较多的网络（如区域网）。

C类地址：C类地址的网络标识由前3组8位二进制数表示，网络中主机标识占1组8位二进制数，C类地址的特点是网络标识的前3位二进制数取值必须为“110”。具有C类地址的网络允许有254台主机，适用于结点比较少的网络（如校园网）。

通过分组，好处就是ip地址管理机构在分配ip地址时只分配了网络号，而剩下的主机号则可以自行分配。并且路由器仅根据主机所连接的网络号来转发分组，减少路由表的占用空间。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-56g8kXKH-1657959229134)(C:\Users\Hao\Desktop\面试\img\image-20220715212715592.png)]

版本：4bit，version。表示协议版本，

IHL：4bit，header length。首部长度，用于指明首部有多长（定长部分+选项）。

区分服务：8bit，differentiated services field。一般情况下不使用这个字段

总长度：16bit，total length。表示ip数据报首部和数据报之和的长度。一个IP数据报总共可以携带2^16的字节的数据，包括首部。

注意：然而这个长度是很难达到的。在ip层下面的每一种数据链路层协议规定了一个数据帧中的数据字段的最大长度，这称之为最大传送单元MTU。当一个ip数据包封装成链路层的帧时，此数据报的长度一定不能超过下面的数据链路层所规定的MTU的长度，否则的话，就会把过长的数据包进行分片处理。

**标识：**16bit，identification。ip软件在存储器中维持一个计数器，每产生一个数据报，计数器就加1，并将此值赋给标识片段。它的作用是当数据报由于长度超过网络的MTU而必须分片时，这个标识字段的值就被复制到所有数据分片片的标识字段中。相同的标识字段的值就让分片后的各数据片能够正确的重装成原来的数据报。

标志：3bit，flags。

reserved bit：待定

don’t fragment标志字段的中间一位：是否允许路由器分割数据包

more fragment标志字段的最低位：是否是最后一个段

分段偏移量：13bit，fragment offset。较长分组分片之后，某片在原分组中的相对位置。表示该段在当前数据报中的位置。

生存期：8bit，time to live。数据报中的网络寿命，没经过一次路由器就将这个值减一。表示该数据报还能被路由器转发几次。

协议：8bit，protocol。表示携带的载荷用的协议是什么，以便使目的主机的IP层知道应将数据部分上交的哪个处理过程。。TCP为0x06，UDP为0x11，ICMP为0x01，IGMP为0x02。

源地址：32bit，source address。发送这个数据报的地址，是一个IP v4地址。

目的地址：32bit，destination address。接受这个数据包的地址，也是一个IPv4地址

UDP是将整条数据交给网络层，而UDP协议格式中的16位UDP长度可知UDP的最大传输数据大小是216=66536字节，MTU默认的长度为1500， 当一个UDP携带的数据超过1472(1500 - 8(UDP报头) - 20(IP报头))时，在网络层就一定会进行分片 。分片之后，一个数据被分成了多份，数据丢包的概率增加了。并且一个UDP被分成多个片只有第一片包含UDP首部，后面的数据包没有udp首部，但是每片都有IP首部；到达目的地址之后重组。

但是如果超过65536个字节，就需要在应用层对数据进行分包，使用sendto()传输一部分给UDP协议，剩下的再使用sendto()传输给UDP协议。接收方调用recvfrom()，将去掉UDP首部的数据拿到，通过发送方应用层设定好的：标识、标志位、片偏移（和IP数据包有点类似，但这是再应用层写好写入UDP中的），就可以将数据进行组合(用UDP内部的数据进行组合，和应用层设定的标识、标志位、片偏移相关和UDP首部无关)（注意和IP的数据报进行区分）

TCP协议的一个数据报也不能是无限大的，不仅受之于流量控制，拥塞控制的影响，还受MTU的影响。TCP的有效载荷的最大消息长度，称为MSS。

TCP在建立连接，三次握手时，通信双方会进行MSS协商。会在TCP报头写入自己能支持的MSS值。双方知道知道对方的MSS后，选择最小值作为最终MSS。并将MSS值填在TCP报头的选项位置。TCP在传输数据时，严格按照MSS进行传输，所以，这么看一般情况下在网络层以及数据链路层传输时，是不会对TCP数据进行分片的，因为已经协议并规定好其每次发送的数据大小小于MTU，

HTTP是超文本超文本传输协议（Hyper Text Transfer Protocol，HTTP）是一个简单的无状态的请求-响应协议，它通常运行在TCP之上并且是一个非持久性连接

1、客户端向HTTp服务器的80端口发起TCP连接请求

2、HTTP服务器在80端口建立TCP连接请求，接收并通知客户端

3、Http客户端通过建立的TCP连接将消息通过套接字发出，并在URL中包含客户端需要的对象

4、HTTP服务器收到请求消息，将对象包含在相应消息中，通过套接字发送给客户端。

5、服务器端会关闭这个TCP连接，客户端收到响应消息会重复执行上述过程非持久性会在建立TCP连接上花费大量的时间，给服务器造成很大的压力。

HTTP/1.0协议采用非持续连接方式，即一次请求/响应对应一个TCP连接。如果想要再次请求某个资源，就必须重新建立连接，即再进行三次握手。可以看出，请求一个万维网文档所需的时间是该文档的传输时间（与文档大小成正比）加上两倍往返时间RTT(一个RTT用于TCP连接，另一个RTT用于请求和接收万维网文档)。当RTT值较大时，请求一个较小的文档的开销就相对较大。

HTTP/1.0的主要缺点就是每次请求都会建立新的TCP连接都要分配缓存和变量，并初始化各种状态，在关闭连接时又要释放各种资源，特别时万维网服务器往往要同时服务于大量客户请求，这样会使万维网服务器的负担很重。

HTTP/1.1协议使用持续连接，持续连接其实就是对非持续连接的改进，在发送响应后仍然保持这条连接，使同一个客户（浏览器）和该服务器可以继续在这条连接上传送后续的HTTP请求报文和响应报文。

并且为了提高效率，HTTP/1.1协议的持续连接使用了流水线方式工作，即浏览器在收到HTTP的响应报文之前就可连续发送多个请求报文。当请求报文到达服务器后，服务器就回复一个接一个的响应报文（对比HTTP/1.0就节省了很多隔RTT时间）。流水线工作方式使TCP连接中的空闲时间减少，提高下载文档的效率。

新的二进制格式：HTTP1.1的解析是基于文本。HTTP2.0的协议解析决定采用二进制格式。**

多路复用，即连接共享，即每一个request都是用作连接共享机制的。一个request对应一个id，这样一个连接上可以有多个request，每个连接的request可以随机的混杂在一起，接收方可以根据request的 id将request再归属到各自不同的服务端请求里面。

头部压缩，HTTP1.1的头部（header）带有大量信息，而且每次都要重复发送；HTTP2.0使用报头压缩，降低开销

服务端推送：**服务器，而无需客户端明确的请求还可以额外的向客户端推送资源。

HTTP协议的实现本身非常简单，无论是谁发送过来的请求都会响应，因此不确认通信方，会存在一下各种隐患：
无法确定请求发送至目标的Web服务器是否按真是意图返回响应的那台服务器，有可能是伪装的Web服务器

无法确定响应返回到的客户端是否按真实意图接受响应的那个客户端。有可能是已伪装的客户端

无法确定正在通信的对方是否具备访问权限。因为某些Web服务器上保存着重要的信息，只想发给特定用户通信的权限

无法判定请求是来自哪里，谁发送的请求即使是无意义的请求也会照单全收。无法阻止海量请求下的DoS攻击（Denial of Service，拒绝服务攻击）

HTTP有哪些字段

请求报文

请求行：Request Line

• HTTP方法：大概，描述了这个请求想要干什么，例如get意思就是想从服务器获取到什么
• URL：描述了要访问的网络上的资源具体是在哪
• 版本号：表示当前使用的HTTP的版本是什么，目前常用的版本是1.1

请求头：Request Headers
请求空行

请求头的结束标志

请求体：Request Body

响应报文

响应行包括：版本号：代表当前HTTP协议的版本状态码：描述了这个响应是表示成功还是失败的，以及不同的状态码也描述了失败的原因，常见的如404状态码的描述：通过一个或是一组简短的单词描述了当前状态码的含义
响应头：Response Headers
响应体包括：Response Body是服务器返回客户端的具体数据，可能会有各种不同的格式，其中最常见的格式就是HTNL。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-c3NfSSb8-1657959229135)(C:\Users\Hao\Desktop\面试\img\image-20220715213912270.png)]

200：服务器已成功处理了请求。 通常，这表示服务器提供了请求的网页。

301 ： (旧地址永久移动) 永久移动到新位置。 服务器返回此响应(对 GET 或 HEAD 请求的响应)时，会自动将请求者转到新位置。

302：(临时移动) 服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。

400 ：客户端请求有语法错误，不能被服务器所理解。

403 ：服务器收到请求，但是拒绝提供服务。

404 ：(未找到) 服务器找不到请求的网页。

500： (服务器内部错误) 服务器遇到错误，无法完成请求。

• http的超文本传输协议，是无状态的，信息是明文传输，没有进行加密；HTTPS协议是由SSL+HTTP协议构建的，可进行加密传输、身份认证，实现浏览器和服务器的加密传输。比http协议安全。

• https协议需要到CA申请证书，一般免费证书较少，因而需要一定费用。

• http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。

• 在 OSI 网络模型中，HTTP 工作于应用层，而 HTTPS 工作在传输层

加密就是指将明文（要传输的信息）按照指定的方式进行变换，生成密文。

解密就是指将密文按照指定的方式进行变换，还原成为明文。在加密和解密的过程中，一般需要一种或者多个中间转换的数据，来辅助这过程的正常进行，这种数据被叫做密钥。其作用就是为了防止他人获取其中的明文，造成隐患。

（举例）例如：小明想向你表明：swpuyyyds 这个意思但又不想让他人知道便将该明文通过密钥进行转换为密文给你，你收到密文后又通过密钥将其转变为明文从而获得小明的意思。

明文：swpuyyyds暗文：wsupyydys

加密的方式有很多，但是在整体上分为两大类：对称加密和非对称加密。

对称加密对称加密：指的是明文在加密和暗文在解密过程中都使用同一个密钥。比如：一个简单的对称加密, 按位异或明文a=1314,密钥key=1314,当明文引入对称加密后，即使黑客入侵网络设备，让数据被截获，但不知道密钥是什么，也无法进行准确的解密。

但是，如果客户端直接将密钥进行明文传输给服务器，那么黑客也能获得密钥，那么后续的加密操作就没有任何用处了。

因此，客户端在传输密钥的时候必须要给密钥进行加密。为了能够让密钥也能进行加密，那么我们就要引入非对称加密。

非对称加密：一般使用两个密钥，一个是称为‘公钥’，另一个叫做‘私钥’。公钥和私钥是配对的，其最大的缺点就是运算速度慢，比对称加密慢许多。

私钥就可以对密文解密也可以对明文进行加密，公钥也一样。一般情况来说客户端可以获得公钥，而服务器一般使用私钥。

当客户端拥有公钥时，向服务器发送密钥时步骤如下：

客户端中先用公钥将密钥进行加密形成密文，再将密文发送给服务器

服务器接收到密文后，通过私钥对密文进行解密从而获取客户端给的密钥

再将收到密钥的信息发给客户端，让客户端知道自己已经收到密钥了

之后客户端就使用自己生成的密文进行对称加密来传递明文

不过这种方法也有一定问题：如果客户端获取的公钥是黑客伪造的，那么其后续的加密就没有用了。

比如步骤如下：

1.当客户端请求公钥时，黑客趁机将自己生成的公钥发给客户端，客户端以为是服务器的公钥，就用该公钥对自己的密钥进行加密发送出去。

2.当黑客获取该客户发送的密文是用自己生成的私钥进行解密从而获得密钥

3.然后黑客获取服务器的公钥后将获取的密钥进行用服务器公钥进行加密后发给服务器

4.服务器获得该密钥后，用私钥解密从而获得客户端的密钥。

5.之后客户端用该密文进行加密已经没有任何用处了，黑客已经拥有了密钥。

因此通常，在客户端和服务器建立的时候，服务器给客户端返回一个证书，该证书里面就包含公钥，也包含了网站的信息。

讲一讲HTTPS 的握手过程？

客户端请求 HTTPS 网址，然后连接到 server 的 443 端口。

服务器必须要有一套 CA 证书。颁发证书的同时会产生一个私钥和公钥。私钥由服务端自己保存。公钥则是附带在证书的信息中，可以公开的。证书本身也附带一个证书电子签名，这个签名用来验证证书的完整性和真实性，可以防止证书被篡改。服务器响应客户端请求，将证书传递给客户端，证书包含公钥和大量其他信息，比如证书颁发机构信息，公司信息和证书有效期等。

客户端解析证书并对其进行验证。如果证书不是可信机构颁布，或者证书中的域名与实际域名不一致，或者证书已经过期，就会向访问者显示一个警告，由它来选择是否还要继续通信。如果证书没有问题，客户端就会从服务器证书中取出服务器的公钥。然后客户端还会生成一个随机码 KEY，并使用公钥将其加密。

客户端把加密后的随机码 KEY 发送给服务器，作为后面对称加密的密钥。

服务器在收到随机码 KEY 之后会使用私钥将其解密。经过以上这些步骤，客户端和服务器终于建立了安全连接。

服务器使用密钥 (随机码 KEY)对数据进行对称加密并发送给客户端，客户端使用相同的密钥 (随机码 KEY)解密数据。

除了可以将用户信息通过 Cookie 存储在用户浏览器中，也可以利用 Session 存储在服务器端，存储在服务器端的信息更加安全。

有些敏感信息存储在Cokkie中最终存储在用户浏览器中，可能会对数据安全造成影响，，也可以利用 Session 存储在服务器端，由于存储在服务器端，存储的信息更加安全。

比如用 Session 维护用户登录状态的过程如下：

用户进行登录时，用户提交包含用户名和密码的表单，放入 HTTP 请求报文中；

服务器验证该用户名和密码，如果正确则把用户信息存储到 Redis 中，它在 Redis 中的 Key 称为 Session ID；

服务器返回的响应报文的 Set-Cookie 首部字段包含了这个 Session ID，客户端收到响应报文之后将该 Cookie 值存入浏览器中；

客户端之后对同一个服务器进行请求时会包含该 Cookie 值，服务器收到之后提取出 Session ID，从 Redis 中取出用户信息，继续之前的业务操作。

作用范围不同，Cookie 保存在客户端（浏览器），Session 保存在服务器端。

存取方式的不同，Cookie 只能保存 ASCII，Session 可以存任意数据类型，一般情况下我们可以在 Session 中保持一些常用变量信息，比如说 UserId 等。

有效期不同，Cookie 可设置为长时间保持，比如我们经常使用的默认登录功能，Session 一般失效时间较短，客户端关闭或者 Session 超时都会失效。

安全性不同，Cookie 存储在客户端，比较容易遭到不法获取，Session 存储在服务端，安全性相对 Cookie 要好一些。

存储大小不同， 单个 Cookie 保存的数据不能超过 4K，Session 可存储数据远高于 Cookie。

Sql注入攻击

攻击者在HTTP请求中注入恶意的SQL代码，服务器使用参数构建数据库SQL命令时，恶意SQL被一起构造，并在数据库中执行。 用户登录，输入用户名 lianggzone，密码 ‘ or ‘1’=’1 ，如果此时使用参数构造的方式，就会出现 select * from user where name = ‘lianggzone’ and password = ‘’ or ‘1’=‘1’ 不管用户名和密码是什么内容，使查询出来的用户列表不为空

Web端

1）有效性检验。

2）限制字符串输入的长度。

服务端

1）不用拼接SQL字符串。

2）使用预编译的PrepareStatement。

3）有效性检验。(为什么服务端还要做有效性检验？第一准则，外部都是不可信的，防止攻击者绕过Web端请求)

4）过滤SQL需要的参数中的特殊字符。比如单引号、双引号

客户端存储：直接将信息存储在cookie中，cookie是存储在客户端上的一小段数据，客户端通过http协议和服务器进行cookie交互，通常用来存储一些不敏感信息。

Nginx ip_hash 策略：服务端使用 Nginx 代理，每个请求按访问 IP 的 hash 分配，这样来自同一 IP 固定访问一个后台服务器，避免了在服务器 A 创建 Session，第二次分发到服务器 B 的现象。

Session 复制：任何一个服务器上的 Session 发生改变（增删改），该节点会把这个 Session 的所有内容序列化，然后广播给所有其它节点。

共享 Session：**将用户的 Session 等信息使用缓存中间件（如Redis）来统一管理，保障分发到每一个服务器的响应结果都一致。

客户端不断进行请求连接，服务器端会为每个请求创建一个链接，并向其发送确认报文，然后等待客户端进行确认，客户端不发送确认报文，服务器一直等待来自客户端的确认，造成服务器端资源的浪费。

客户端向服务端发送请求链接数据包

服务端向客户端发送确认数据包

客户端不向服务端发送确认数据包，服务器一直等待来自客户端的确认

DDos 预防 ( 没有彻底根治的办法，除非不使用TCP )

限制同时打开SYN半链接的数目

缩短SYN半链接的Time out 时间

关闭不必要的服务

利用网页开发时留下的漏洞（web应用程序对用户的输入过滤不足），巧妙的将恶意的代码注入到网页中，使用户浏览器加载并执行恶意制造的代码，以达到攻击的效果。这恶意的代码通常是JS代码， 浏览器不会判断，只要是符合解析，那么就会执行恶意的代码。

防范XSS攻击：

修改为纯前端渲染，把代码和数据分开。浏览器先加载静态的HTML，此HTML中不包含任何跟业务相关的数据。然后浏览器执行HTML中的JavaScript。JavaScript通过Ajax加载业务数据。

物理地址是数据链路层和物理层使用的地址，而ip地址则是网络层及以上各层使用的地址，是一种逻辑地址。ip地址放在ip数据包的首部，而硬件地址则放在MAC帧的首部，当ip数据包放入数据链路层的MAC帧中以后，整个ip数据包就成为MAC帧的数据，因而在数据链路层看不到数据包的ip地址只能看见MAC帧。因此需要用rap协议进行ip地址到数据链路层地址的转换。

利用ARP协议实现IP与MAC的映射，并进行保存设置过期时间。比如在同一个局域网中，首先，每个主机都会在自己的ARP缓冲区中建立一个ARP列表，表示IP地址和MAC地址之间的对应关系。当源主机要发送数据时，首先检查ARP列表中是否有对应IP地址的目的主机的MAC地址，如果有，则直接发送数据，如果没有，就向本网段的所有主机发送ARP数据包，这个数据包里就包含了：源主机IP地址，源主机MAC地址，目的主机的IP地址。当本网络的所有主机收到该ARP数据包时，首先检查数据包中的IP地址是否是自己的IP地址，如果不是，就忽略这个数据包，如果是，就从数据包中取出源主机的IP和MAC地址，写入到ARP列表中，然后将自己的MAC地址写入ARP响应包中，告诉源主机自己，我就是你要找的MAC地址。源主机收到ARP响应包后。将目的主机的IP和MAC地址写入ARP列表，并利用这个信息发送数据。如果源主机一直没有收到ARP响应数据包，表示ARP查询失败。 （广播发送ARP请求，单播发送ARP响应）

DHCP(Dynamic Host Configuration Protocol),动态主机配置协议，是一个应用层协议。当我们将客户主机ip地址设置为动态获取方式时，DHCP服务器就会根据DHCP协议给客户端分配IP，使得客户机能够利用这个IP上网。

除此之外，DHCP可以、子网掩码、网关、DNS。这些信息全部分配之后，主机的IP信息就相当于分配好了。

DHCP客户端使用的端口68，服务端使用端口67，使用的UDP应用层的协议传输信息。

DHCP一般不为服务器分配IP，因为他们要使用固定IP，所以DHCP一般只为办公环境的主机分配IP。

DHCP服务器和客户端需要在一个局域网内，在为客户端分配IP的时候需要进行多次广播。但DHCP也可以为其他网段内主机分配IP，只要连接两个网段中间的路由器能转发DHCP配置请求即可，但这要求路由器配置中继功能。

DHCP服务器IP分配一般为以下三种方式：

1）自动分配（Automatic Allocation）（MAC地址与IP绑定）动分配是当DHCP客户端第一次成功地从DHCP服务器端分配到一个IP地址之后，就永远使用这个地址。

动态分配（Dynamic Allocation）常用方式动态分配是当DHCP客户端第一次从DHCP服务器分配到IP地址后，并非永久地使用该地址，每次使用完后，DHCP客户端就得释放这个IP地址，以给其他客户端使用

手动分配手动分配是由DHCP服务器管理员专门为客户端指定IP地址

DHCP服务器给主机分配ip地址的工作流程为

1、搜索阶段当DHCP客户端第一次登录网络的时候，计算机发现本机上没有任何IP地址设定，将以广播方式发送DHCP discover发现信息来寻找DHCP服务器，目的主机IP地址设置为1，即向255.255.255.255发送特定的广播信息。源主机ip设置为0，网络上每一台安装了TCP/IP协议的主机都会接收这个广播信息，但只有DHCP服务器才会做出响应。（DHCP DISCOVER）

2、 提供阶段在网络中接收到DHCP discover发现信息的DHCP服务器就会做出响应，它从尚未分配的IP地址池中挑选一个分配给DHCP客户机，向DHCP客户机发送一个包含分配的IP地址和其他设置的DHCP offer提供信息。因为此时客户端还没有IP，所以返回信息也是以广播的方式返回的。（DHCP OFFER）,

3、选择阶段DHCP客户端接受到DHCP offer提供信息之后，选择第一个接收到的提供信息，然后以广播的方式回答一个DHCP request请求信息，该信息包含向它所选定的DHCP服务器请求IP地址的内容。（DHCP REQUEST）

4、确认阶段DHCP服务器收到DHCP客户端回答的DHCP request请求信息之后，便向DHCP客户端发送一个ack确认信息，确认租约，并指定租约时长。告诉DHCP客户端可以使用它提供的IP地址。然后，DHCP客户机便将其TCP/IP协议与网卡绑定。

重新登录时

以后DHCP客户端每次重新登录网络时，就不需要再发送DHCP discover发现信息了，而是直接发送包含前一次所分配的IP地址的DHCP request请求信息。当DHCP服务器收到这一信息后，它会尝试让DHCP客户机继续使用原来的IP地址，并回答一个DHCP ack确认信息。如果此IP地址已无法再分配给原来的DHCP客户机使用时，则DHCP服务器给DHCP客户机回答一个DHCP nack否认信息。当原来的DHCP客户机收到此DHCP nack否认信息后，它就必须重新发送DHCP discover发现信息来请求新的IP地址。

发送端发送一个本地的RARP广播包，广播包中声明自己的MAC地址，并且请求任何收到此请求的RARP服务器分配一个IP地址。本地网段上的RARP服务器收到此请求后，检查其RARP列表，查找该MAC地址对应的IP地址。如果存在，RARP服务器就给源主机发送一个响应数据包，并将此IP地址提供给对方主机使用；如果不存在，RARP服务器对此不做任何响应。源端在收到从RARP服务器来的响应信息后，利用得到的IP地址进行通信。

转发：客户浏览器发送HTTP请求——>web服务器接受请求——>调用内部一个方法在容器内部完成请求处理和转发动作——>再将转发跳转到的那个网页资源返回给客户；转发只能在同一个容器内完成 转发的时候浏览器地址是不会变的，在客户浏览器里只会显示第一次进入的那个网址或者路径，客户看不到这个过程，只是得到了想要的目标资源。转发行为浏览器只做了一次请求。（转发只能跳转一次）

重定向：客户浏览器发送HTTP请求——>web服务器接受请求后发送302状态码以及新的位置给客户浏览器——>客户浏览器发现是302响应，则自动再发送一个新的HTTP请求，请求指向新的地址（302：Found 临时移动，但资源只是临时被移动。即你访问网址A，但是网址A因为服务器端的拦截器或者其他后端代码处理的原因，会被重定向到网址B。）——>服务器根据此请求寻找资源发个客户；再客户浏览器中显示的是重定向之后的路径，客户可以看到地址的变化。重定向行为浏览器做了至少两次请求。（重定向可以跳转多次）

所谓幂等是指不管进行多少次操作，结果都一样。比如，

调用GET方法只是去请求资源，自然每次调用结果都是相同的，就是幂等的。

对于POST请求，两次调用POST请求，可能就会在服务器创建两份资源，所以当然不是幂等的。

GET,安全且幂等

POST,不安全且不幂等

PUT,不安全但幂等

DELETE,不安全但幂等

GET请求，请求的数据会附加在URL之后或者用Cookie传参，以?分割URL和传输数据，多个参数用&连接。POST请求：POST请求会把请求的数据放置在HTTP请求体中(Request body)。

传输数据的大小：在HTTP规范中，没有对URL的长度和传输的数据大小进行限制。但是在实际开发过程中，对于GET，特定的浏览器和服务器对URL的长度有限制。对于POST，理论上是不会受限制的。

安全性：POST的安全性比GET的高。

GET和POST最大的区别主要是GET请求是幂等性的，POST请求不是。这个是它们本质区别。

幂等性是指一次和多次请求某一个资源应该具有同样的作用。简单来说意味着对同一URL的多个请求应该返回同样的结果。 正因为它们有这样的区别，所以不应该且不能用get请求做数据的增删改这些有副作用的操作。因为get请求是幂等的，在网络不好的隧道中会尝试重试。如果用get请求增数据，会有重复操作的风险，而这种重复操作可能会导致副作用（浏览器和操作系统并不知道你会用get请求去做增操作）。

调用POST请求，可能就会在服务器创建两份资源，所以当然不是幂等的。

GET,安全且幂等

POST,不安全且不幂等

PUT,不安全但幂等

DELETE,不安全但幂等

GET请求，请求的数据会附加在URL之后或者用Cookie传参，以?分割URL和传输数据，多个参数用&连接。POST请求：POST请求会把请求的数据放置在HTTP请求体中(Request body)。

传输数据的大小：在HTTP规范中，没有对URL的长度和传输的数据大小进行限制。但是在实际开发过程中，对于GET，特定的浏览器和服务器对URL的长度有限制。对于POST，理论上是不会受限制的。

安全性：POST的安全性比GET的高。

GET和POST最大的区别主要是GET请求是幂等性的，POST请求不是。这个是它们本质区别。

幂等性是指一次和多次请求某一个资源应该具有同样的作用。简单来说意味着对同一URL的多个请求应该返回同样的结果。 正因为它们有这样的区别，所以不应该且不能用get请求做数据的增删改这些有副作用的操作。因为get请求是幂等的，在网络不好的隧道中会尝试重试。如果用get请求增数据，会有重复操作的风险，而这种重复操作可能会导致副作用（浏览器和操作系统并不知道你会用get请求去做增操作）。

PUT和POS都有更改指定URI的语义.但PUT被定义为幂等性的方法，POST则不是非幂等性的方法:如果一个方法重复执行。多次，产生的效果是一样的，那就是idempotent的。也就是说：PUT请求：如果两个请求相同，后一个请求会把第一个请求覆盖掉。（所以PUT用来改资源）Post请求：后一个请求不会把第一个请求覆盖掉。（所以Post用来增资源）