计算机网络的各层协议及作用

计算机网络体系可以大致分为一下三种，OSI七层模型、TCP/IP四层模型和五层模型。

OSI七层模型：大而全，但是比较复杂、而且是先有了理论模型，没有实际应用。
TCP/IP四层模型：是由实际应用发展总结出来的，从实质上讲，TCP/IP只有最上面三层，最下面一层没有什么具体内容，TCP/IP参考模型没有真正描述这一层的实现。
五层模型：五层模型只出现在计算机网络教学过程中，这是对七层模型和四层模型的一个折中，既简洁又能将概念阐述清楚。

计算机网络体系结构

七层网络体系结构各层的主要功能：

应用层：为应用程序提供交互服务。在互联网中的应用层协议很多，如域名系统DNS，支持万维网应用的HTTP协议，支持电子邮件的SMTP协议等。
表示层：主要负责数据格式的转换，如加密解密、转换翻译、压缩解压缩等。
会话层：负责在网络中的两节点之间建立、维持和终止通信，如服务器验证用户登录便是由会话层完成的。
运输层：有时也译为传输层，向主机进程提供通用的数据传输服务。该层主要有以下两种协议：
- TCP：提供面向连接的、可靠的数据传输服务；
- UDP：提供无连接的、尽最大努力的数据传输服务，但不保证数据传输的可靠性。
网络层：选择合适的路由和交换结点，确保数据及时传送。主要包括IP协议。
数据链路层：数据链路层通常简称为链路层。将网络层传下来的IP数据包组装成帧，并再相邻节点的链路上传送帧。
物理层：实现相邻节点间比特流的透明传输，尽可能屏蔽传输介质和通信手段的差异。

TCP和UDP的区别

对比如下：

	UDP	TCP
是否连接	无连接	面向连接
是否可靠	不可靠传输，不使用流量控制和拥塞控制	可靠传输，使用流量控制和拥塞控制
是否有序	无序	有序，消息在传输过程中可能会乱序，TCP 会重新排序
传输速度	快	慢
连接对象个数	支持一对一，一对多，多对一和多对多交互通信	只能是一对一通信
传输方式	面向报文	面向字节流
首部开销	首部开销小，仅8字节	首部最小20字节，最大60字节
适用场景	适用于实时应用（IP电话、视频会议、直播等）	适用于要求可靠传输的应用，例如文件传输

总结：

TCP 用于在传输层有必要实现可靠传输的情况，UDP 用于对高速传输和实时性有较高要求的通信。TCP 和 UDP 应该根据应用目的按需使用。

UDP 和 TCP 对应的应用场景是什么

TCP·是面向连接，能保证数据的可靠性交付，因此经常用于：

FTP文件传输
HTTP / HTTPS

UDP 面向无连接，它可以随时发送数据，再加上UDP本身的处理既简单又高效，因此经常用于：

包总量较少的通信，如 DNS 、SNMP等
视频、音频等多媒体通信
广播通信

TCP 的三次握手

图片来自：原地址

三次握手机制：

第一次握手：客户端请求建立连接，向服务端发送一个同步报文（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，客户端和服务器进入ESTABLISHED状态，完成三次握手。

理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP 连接都将被一直保持下去。

为什么需要三次握手，而不是两次

主要有三个原因：

防止已过期的连接请求报文突然又传送到服务器，因而产生错误和资源浪费。

在双方两次握手即可建立连接的情况下，假设客户端发送 A 报文段请求建立连接，由于网络原因造成 A 暂时无法到达服务器，服务器接收不到请求报文段就不会返回确认报文段。

客户端在长时间得不到应答的情况下重新发送请求报文段 B，这次 B 顺利到达服务器，服务器随即返回确认报文并进入 ESTABLISHED 状态，客户端在收到确认报文后也进入 ESTABLISHED 状态，双方建立连接并传输数据，之后正常断开连接。

此时姗姗来迟的 A 报文段才到达服务器，服务器随即返回确认报文并进入 ESTABLISHED 状态，但是已经进入 CLOSED 状态的客户端无法再接受确认报文段，更无法进入 ESTABLISHED 状态，这将导致服务器长时间单方面等待，造成资源浪费。
三次握手才能让双方均确认自己和对方的发送和接收能力都正常。

第一次握手：客户端只是发送处请求报文段，什么都无法确认，而服务器可以确认自己的接收能力和对方的发送能力正常；

第二次握手：客户端可以确认自己发送能力和接收能力正常，对方发送能力和接收能力正常；

第三次握手：服务器可以确认自己发送能力和接收能力正常，对方发送能力和接收能力正常；

可见三次握手才能让双方都确认自己和对方的发送和接收能力全部正常，这样就可以愉快地进行通信了。
告知对方自己的初始序号值，并确认收到对方的初始序号值。

TCP 实现了可靠的数据传输，原因之一就是 TCP 报文段中维护了序号字段和确认序号字段，通过这两个字段双方都可以知道在自己发出的数据中，哪些是已经被对方确认接收的。这两个字段的值会在初始序号值得基础递增，如果是两次握手，只有发起方的初始序号可以得到确认，而另一方的初始序号则得不到确认。

为什么要三次握手，而不是四次

因为三次握手已经可以确认双方的发送接收能力正常，双方都知道彼此已经准备好，而且也可以完成对双方初始序号值得确认，也就无需再第四次握手了。

第一次握手：服务端确认“自己收、客户端发”报文功能正常。
第二次握手：客户端确认“自己发、自己收、服务端收、客户端发”报文功能正常，客户端认为连接已建立。
第三次握手：服务端确认“自己发、客户端收”报文功能正常，此时双方均建立连接，可以正常通信。

请求头和响应头

在 HTTP 通信过程中，Request Headers（请求头） 和 Response Headers（响应头） 是用来传递客户端和服务器之间的额外信息的重要组成部分。它们分别出现在 HTTP 请求和响应的头部区域，包含许多字段，这些字段可以帮助客户端和服务器了解彼此的状态、能力、请求的特性等。

Request Headers（请求头）

定义：Request Headers 是客户端（通常是浏览器）发送给服务器的附加信息，用于描述客户端的环境、请求的详细信息、客户端的能力等。服务器可以根据这些信息做出相应的处理和响应。

常见字段：

Host: 指定请求的主机名和端口号。
例子：Host: www.example.com
User-Agent: 指定客户端的用户代理字符串，通常用于识别浏览器或其他类型的客户端。
例子：User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/85.0.4183.83 Safari/537.36
Accept: 指定客户端能够处理的媒体类型（MIME 类型）。
例子：Accept: text/html, application/xhtml+xml, application/xml;q=0.9, image/webp
Accept-Encoding: 指定客户端支持的数据压缩格式。
例子：Accept-Encoding: gzip, deflate, br
Accept-Language: 指定客户端的语言偏好。
例子：Accept-Language: en-US,en;q=0.9
Authorization: 包含用于认证的凭证信息。
例子：Authorization: Basic dXNlcjpwYXNzd29yZA==
Cookie: 客户端存储的 Cookies，通常用于跟踪和会话管理。
例子：Cookie: session_id=abc123
Content-Type: 指定请求正文的 MIME 类型，通常在 POST 请求中使用。
例子：Content-Type: application/json
Referer: 指定请求来源的 URL，用于追踪请求的来源。
例子：Referer: https://www.google.com
Connection: 指定是否保持连接，通常为 keep-alive 或 close。
例子：Connection: keep-alive
If-Modified-Since: 用于协商缓存，指定客户端缓存的最后修改时间。
例子：If-Modified-Since: Wed, 21 Oct 2023 07:28:00 GMT
If-None-Match: 用于协商缓存，指定客户端缓存的 ETag。
例子：If-None-Match: "abc123"

Response Headers（响应头）

定义：Response Headers 是服务器返回给客户端的附加信息，用于描述响应的内容、服务器的状态、服务器的能力等。客户端可以根据这些信息来处理和展示响应数据。

常见字段：

Content-Type: 指定响应正文的 MIME 类型。
例子：Content-Type: text/html; charset=UTF-8
Content-Length: 指定响应正文的长度（以字节为单位）。
例子：Content-Length: 1024
Content-Encoding: 指定响应正文的压缩算法。
例子：Content-Encoding: gzip
Cache-Control: 指定缓存机制的指令，控制如何缓存响应。
例子：Cache-Control: no-cache, no-store, must-revalidate
Expires: 指定响应过期的日期和时间，用于缓存控制。
例子：Expires: Wed, 21 Oct 2024 07:28:00 GMT
ETag: 为响应资源的版本提供唯一标识符，用于协商缓存。
例子：ETag: "abc123"
Last-Modified: 指定响应资源的最后修改时间。
例子：Last-Modified: Wed, 21 Oct 2023 07:28:00 GMT
Set-Cookie: 设置一个 Cookie。
例子：Set-Cookie: session_id=abc123; Expires=Wed, 21 Oct 2024 07:28:00 GMT; Path=/; Secure; HttpOnly
Location: 指定用于重定向的 URL。
例子：Location: https://www.example.com/new-location
Server: 指定服务器的软件信息。
例子：Server: Apache/2.4.1 (Unix)
WWW-Authenticate: 指定服务器要求客户端提供认证信息的方式。
例子：WWW-Authenticate: Basic realm="Access to the site"
Access-Control-Allow-Origin: 用于 CORS（跨域资源共享），指定哪些域可以访问该资源。
例子：Access-Control-Allow-Origin: *
Connection: 指定连接的控制选项。
例子：Connection: keep-alive

总结

Request Headers 是由客户端发送到服务器的，用于描述请求的环境、客户端的信息、内容类型、认证信息、缓存验证信息等。
Response Headers 是由服务器返回给客户端的，用于描述响应的内容类型、内容长度、缓存策略、重定向信息、服务器信息等。

了解这些请求头和响应头的字段，有助于更好地理解和控制 HTTP 请求和响应的行为，从而优化网络性能和用户体验。

什么是 SYN洪泛攻击？如何防范？

SYN洪泛攻击属于 DOS 攻击的一种，它利用 TCP 协议缺陷，通过发送大量的半连接请求，耗费 CPU 和内存资源。

原理：

在三次握手过程中，服务器发送 [SYN/ACK] 包（第二个包）之后、收到客户端的 [ACK] 包（第三个包）之前的 TCP 连接称为半连接（half-open connect），此时服务器处于 SYN_RECV（等待客户端响应）状态。如果接收到客户端的 [ACK]，则 TCP 连接成功，如果未接受到，则会不断重发请求直至成功。
SYN 攻击的攻击者在短时间内伪造大量不存在的 IP 地址，向服务器不断地发送 [SYN] 包，服务器回复 [SYN/ACK] 包，并等待客户的确认。由于源地址是不存在的，服务器需要不断的重发直至超时。
这些伪造的 [SYN] 包将长时间占用未连接队列，影响了正常的 SYN，导致目标系统运行缓慢、网络堵塞甚至系统瘫痪。

检测：当在服务器上看到大量的半连接状态时，特别是源 IP 地址是随机的，基本上可以断定这是一次 SYN 攻击。

防范：

通过防火墙、路由器等过滤网关防护。
通过加固 TCP/IP 协议栈防范，如增加最大半连接数，缩短超时时间。
SYN cookies技术。SYN Cookies 是对 TCP 服务器端的三次握手做一些修改，专门用来防范 SYN 洪泛攻击的一种手段。

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

服务端：

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

客户端：

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

TCP 的四次挥手过程

图片来源：https://juejin.im/post/5ddd1f30e51d4532c42c5abe

第一次挥手：客户端向服务端发送连接释放报文（FIN=1，ACK=1），主动关闭连接，同时等待服务端的确认。
- 序列号 seq = u，即客户端上次发送的报文的最后一个字节的序号 + 1
- 确认号 ack = k, 即服务端上次发送的报文的最后一个字节的序号 + 1
第二次挥手：服务端收到连接释放报文后，立即发出确认报文（ACK=1），序列号 seq = k，确认号 ack = u + 1。

这时 TCP 连接处于半关闭状态，即客户端到服务端的连接已经释放了，但是服务端到客户端的连接还未释放。这表示客户端已经没有数据发送了，但是服务端可能还要给客户端发送数据。
第三次挥手：服务端向客户端发送连接释放报文（FIN=1，ACK=1），主动关闭连接，同时等待 A 的确认。
- 序列号 seq = w，即服务端上次发送的报文的最后一个字节的序号 + 1。
- 确认号 ack = u + 1，与第二次挥手相同，因为这段时间客户端没有发送数据
第四次挥手：客户端收到服务端的连接释放报文后，立即发出确认报文（ACK=1），序列号 seq = u + 1，确认号为 ack = w + 1。

此时，客户端就进入了 TIME-WAIT 状态。注意此时客户端到 TCP 连接还没有释放，必须经过 2*MSL（最长报文段寿命）的时间后，才进入 CLOSED 状态。而服务端只要收到客户端发出的确认，就立即进入 CLOSED 状态。可以看到，服务端结束 TCP 连接的时间要比客户端早一些。

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

服务器在收到客户端的 FIN 报文段后，可能还有一些数据要传输，所以不能马上关闭连接，但是会做出应答，返回 ACK 报文段.

接下来可能会继续发送数据，在数据发送完后，服务器会向客户单发送 FIN 报文，表示数据已经发送完毕，请求关闭连接。服务器的ACK和FIN一般都会分开发送，从而导致多了一次，因此一共需要四次挥手。

为什么客户端的 TIME-WAIT 状态必须等待 2MSL ？

主要有两个原因：

确保 ACK 报文能够到达服务端，从而使服务端正常关闭连接。

第四次挥手时，客户端第四次挥手的 ACK 报文不一定会到达服务端。服务端会超时重传 FIN/ACK 报文，此时如果客户端已经断开了连接，那么就无法响应服务端的二次请求，这样服务端迟迟收不到 FIN/ACK 报文的确认，就无法正常断开连接。

MSL 是报文段在网络上存活的最长时间。客户端等待 2MSL 时间，即「客户端 ACK 报文 1MSL 超时 + 服务端 FIN 报文 1MSL 传输」，就能够收到服务端重传的 FIN/ACK 报文，然后客户端重传一次 ACK 报文，并重新启动 2MSL 计时器。如此保证服务端能够正常关闭。

如果服务端重发的 FIN 没有成功地在 2MSL 时间里传给客户端，服务端则会继续超时重试直到断开连接。
防止已失效的连接请求报文段出现在之后的连接中。

TCP 要求在 2MSL 内不使用相同的序列号。客户端在发送完最后一个 ACK 报文段后，再经过时间 2MSL，就可以保证本连接持续的时间内产生的所有报文段都从网络中消失。这样就可以使下一个连接中不会出现这种旧的连接请求报文段。或者即使收到这些过时的报文，也可以不处理它。

如果已经建立了连接，但是客户端出现故障了怎么办？

或者说，如果三次握手阶段、四次挥手阶段的包丢失了怎么办？如“服务端重发 FIN丢失”的问题。

简而言之，通过定时器 + 超时重试机制，尝试获取确认，直到最后会自动断开连接。

具体而言，TCP 设有一个保活计时器。服务器每收到一次客户端的数据，都会重新复位这个计时器，以Linux服务器为例，时间通常是设置为 2 小时。若 2 小时还没有收到客户端的任何数据，服务器就开始重试：每隔 75 秒（默认）发送一个探测报文段，若一共发送 10 个探测报文后客户端依然没有回应，那么服务器就认为连接已经断开了。

附：Linux服务器系统内核参数配置

tcp_keepalive_time，在TCP保活打开的情况下，最后一次数据交换到TCP发送第一个保活探测包的间隔，即允许的持续空闲时长，或者说每次正常发送心跳的周期，默认值为7200s（2h）。
tcp_keepalive_probes 在tcp_keepalive_time之后，没有接收到对方确认，继续发送保活探测包次数，默认值为9（次）。
tcp_keepalive_intvl，在tcp_keepalive_time之后，没有接收到对方确认，继续发送保活探测包的发送频率，默认值为75s。发送频率tcp_keepalive_intvl乘以发送次数tcp_keepalive_probes，就得到了从开始探测到放弃探测确定连接断开的时间；举例：若设置，服务器在客户端连接空闲的时候，每90秒发送一次保活探测包到客户端，若没有及时收到客户端的TCP Keepalive ACK确认，将继续等待15秒*2=30秒。总之可以在90s+30s=120秒（两分钟）时间内可检测到连接失效与否。

可以参考TCP保活机制：https://blog.51cto.com/u_15346415/3674622

TIME-WAIT 状态过多会产生什么后果？怎样处理？

从服务器来讲，短时间内关闭了大量的Client连接，就会造成服务器上出现大量的TIME_WAIT连接，严重消耗着服务器的资源，此时部分客户端就会显示连接不上。

从客户端来讲，客户端TIME_WAIT过多，就会导致端口资源被占用，因为端口就65536个，被占满就会导致无法创建新的连接。

解决办法：

服务器可以设置 SO_REUSEADDR 套接字选项来避免 TIME_WAIT状态，此套接字选项告诉内核，即使此端口正忙（处于 TIME_WAIT状态），也请继续并重用它。

调整系统内核参数，修改/etc/sysctl.conf文件，即修改net.ipv4.tcp_tw_reuse 和 tcp_timestamps

1
2

net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭；
net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。

强制关闭，发送 RST 包越过TIME_WAIT状态，直接进入CLOSED状态。

TIME_WAIT 是服务器端的状态?还是客户端的状态?

TIME_WAIT 是主动断开连接的一方会进入的状态，一般情况下，都是客户端所处的状态;服务器端一般设置不主动关闭连接。

TIME_WAIT 需要等待 2MSL，在大量短连接的情况下，TIME_WAIT会太多，这也会消耗很多系统资源。对于服务器来说，在 HTTP 协议里指定 KeepAlive（浏览器重用一个 TCP 连接来处理多个 HTTP 请求），由浏览器来主动断开连接，可以一定程度上减少服务器的这个问题。

TCP协议如何保证可靠性？

TCP主要提供了检验和、序列号/确认应答、超时重传、滑动窗口、拥塞控制和流量控制等方法实现了可靠性传输。

检验和：通过检验和的方式，接收端可以检测出来数据是否有差错和异常，假如有差错就会直接丢弃TCP段，重新发送。
序列号/确认应答：

序列号的作用不仅仅是应答的作用，有了序列号能够将接收到的数据根据序列号排序，并且去掉重复序列号的数据。

TCP传输的过程中，每次接收方收到数据后，都会对传输方进行确认应答。也就是发送ACK报文，这个ACK报文当中带有对应的确认序列号，告诉发送方，接收到了哪些数据，下一次的数据从哪里发。
滑动窗口：滑动窗口既提高了报文传输的效率，也避免了发送方发送过多的数据而导致接收方无法正常处理的异常。
超时重传：超时重传是指发送出去的数据包到接收到确认包之间的时间，如果超过了这个时间会被认为是丢包了，需要重传。最大超时时间是动态计算的。
拥塞控制：在数据传输过程中，可能由于网络状态的问题，造成网络拥堵，此时引入拥塞控制机制，在保证TCP可靠性的同时，提高性能。
流量控制：如果主机A 一直向主机B发送数据，不考虑主机B的接受能力，则可能导致主机B的接受缓冲区满了而无法再接受数据，从而会导致大量的数据丢包，引发重传机制。而在重传的过程中，若主机B的接收缓冲区情况仍未好转，则会将大量的时间浪费在重传数据上，降低传送数据的效率。所以引入流量控制机制，主机B通过告诉主机A自己接收缓冲区的大小，来使主机A控制发送的数据量。流量控制与TCP协议报头中的窗口大小有关。

详细讲一下TCP的滑动窗口？

在进行数据传输时，如果传输的数据比较大，就需要拆分为多个数据包进行发送。TCP 协议需要对数据进行确认后，才可以发送下一个数据包。这样一来，就会在等待确认应答包环节浪费时间。

为了避免这种情况，TCP引入了窗口概念。窗口大小指的是不需要等待确认应答包而可以继续发送数据包的最大值。

从上面的图可以看到滑动窗口左边的是已发送并且被确认的分组，滑动窗口右边是还没有轮到的分组。

滑动窗口里面也分为两块，一块是已经发送但是未被确认的分组，另一块是窗口内等待发送的分组。随着已发送的分组不断被确认，窗口内等待发送的分组也会不断被发送。整个窗口就会往右移动，让还没轮到的分组进入窗口内。

可以看到滑动窗口起到了一个限流的作用，也就是说当前滑动窗口的大小决定了当前 TCP 发送包的速率，而滑动窗口的大小取决于拥塞控制窗口和流量控制窗口的两者间的最小值。

详细讲一下拥塞控制？

TCP 一共使用了四种算法来实现拥塞控制：

慢开始 (slow-start)；
拥塞避免 (congestion avoidance)；
快速重传 (fast retransmit)；
快速恢复 (fast recovery)。

发送方维持一个叫做拥塞窗口cwnd（congestion window）的状态变量。当cwndssthresh时，改用拥塞避免算法。

慢开始：不要一开始就发送大量的数据，由小到大逐渐增加拥塞窗口的大小。

拥塞避免：拥塞避免算法让拥塞窗口缓慢增长，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1而不是加倍。这样拥塞窗口按线性规律缓慢增长。

快重传：我们可以剔除一些不必要的拥塞报文，提高网络吞吐量。比如接收方在收到一个失序的报文段后就立即发出重复确认，而不要等到自己发送数据时捎带确认。快重传规定：发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。

快恢复：主要是配合快重传。当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把ssthresh门限减半（为了预防网络发生拥塞），但接下来并不执行慢开始算法，因为如果网络出现拥塞的话就不会收到好几个重复的确认，收到三个重复确认说明网络状况还可以。

HTTP常见的状态码有哪些？

HTTP状态码是由服务器返回给客户端，用来表示网页请求的结果。这些状态码被分为几个不同的类别，每个类别由第一个数字标识。常见的HTTP状态码包括：

1xx（信息性状态码）：提供信息，表示请求已被接受，继续处理。
- 100 Continue：客户端应继续其请求
- 101 Switching Protocols：服务器根据客户端的请求切换协议
2xx（成功状态码）：表示请求已成功被服务器接收、理解，并接受。
- 200 OK：请求成功。
- 201 Created：请求成功并且服务器创建了新的资源。
- 204 No Content：服务器成功处理了请求，但没有返回任何内容。
3xx（重定向状态码）：要完成请求，需要进一步操作，通常这些状态码用来重定向。
- 301 Moved Permanently：请求的网页已永久移动到新位置。
- 302 Found：服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行后续的请求。
- 304 Not Modified：自从上次请求后，请求的网页未修改过。--协商缓存
4xx（请求错误状态码）：这些状态码表示请求可能出错，妨碍了服务器的处理。
- 400 Bad Request：服务器不理解请求的语法。
- 401 Unauthorized：请求要求身份验证。
- 403 Forbidden：服务器拒绝请求。
- 404 Not Found：服务器找不到请求的网页。
5xx（服务器错误状态码）：这些状态码表示服务器在尝试处理请求时发生了错误。
- 500 Internal Server Error：服务器遇到错误，无法完成请求。
- 502 Bad Gateway：服务器作为网关或代理，从上游服务器收到无效响应。
- 503 Service Unavailable：服务器目前无法使用（由于超载或停机维护）。
- 504 Gateway Timeout：服务器作为网关或代理，但是没有及时从上游服务器收到请求。

这些状态码可以帮助开发者理解他们的网页请求可能遇到的问题，并据此进行调整或修复。

200：服务器已成功处理了请求。通常，这表示服务器提供了请求的网页。
301 ： (永久移动) 请求的网页已永久移动到新位置。服务器返回此响应(对 GET 或 HEAD 请求的响应)时，会自动将请求者转到新位置。
302：(临时移动) 服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。
400 ：客户端请求有语法错误，不能被服务器所理解。
403 ：服务器收到请求，但是拒绝提供服务。
404 ：(未找到) 服务器找不到请求的网页。
500： (服务器内部错误) 服务器遇到错误，无法完成请求。

状态码301和302的区别是什么？

共同点：301和302状态码都表示重定向，就是说浏览器在拿到服务器返回的这个状态码后会自动跳转到一个新的URL地址，这个地址可以从响应的Location首部中获取（用户看到的效果就是他输入的地址A瞬间变成了另一个地址B）。

不同点：301表示旧地址A的资源已经被永久地移除了(这个资源不可访问了)，搜索引擎在抓取新内容的同时也将旧的网址交换为重定向之后的网址；302表示旧地址A的资源还在（仍然可以访问），这个重定向只是临时地从旧地址A跳转到地址B，搜索引擎会抓取新的内容而保存旧的网址。 SEO中302好于301。

补充，重定向原因：

网站调整（如改变网页目录结构）；
网页被移到一个新地址；
网页扩展名改变(如应用需要把.php改成.Html或.shtml)。

HTTP 常用的请求方式？

方法	作用
GET	获取资源，用于请求数据，而不是修改数据。
POST	向服务器提交数据，通常用于创建新的资源或提交表单数据。
PUT	上传指定资源，通常用于更新已有资源或者创建资源（如果资源不存在）。
DELETE	删除指定资源。
HEAD	和GET方法类似，但只返回报文首部，不返回报文实体主体部分
PATCH	对资源进行部分修改
OPTIONS	查询指定的URL支持的方法
CONNECT	要求用隧道协议连接代理
TRACE	服务器会将通信路径返回给客户端

为了方便记忆，可以将PUT、DELETE、POST、GET理解为客户端对服务端的增删改查。

PUT：上传文件，向服务器添加数据，可以看作增
DELETE：删除文件
POST：传输数据，向服务器提交数据，对服务器数据进行更新。
GET：获取资源，查询服务器资源

GET请求和POST请求的区别？

使用上的区别：

GET使用URL或Cookie传参，而POST将数据放在BODY中”，这个是因为HTTP协议用法的约定。
GET方式提交的数据有长度限制，则POST的数据则可以非常大”，这个是因为它们使用的操作系统和浏览器设置的不同引起的区别。
POST比GET安全，因为数据在地址栏上不可见”，这个说法没毛病，但依然不是GET和POST本身的区别。

本质区别

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

幂等性是指一次和多次请求某一个资源应该具有同样的副作用。简单来说意味着对同一URL的多个请求应该返回同样的结果。

解释一下HTTP长连接和短连接？

在HTTP/1.0中，默认使用的是短连接。也就是说，浏览器和服务器每进行一次HTTP操作，就建立一次连接，但任务结束就中断连接。如果客户端浏览器访问的某个HTML或其他类型的 Web页中包含有其他的Web资源，如JavaScript文件、图像文件、CSS文件等；当浏览器每遇到这样一个Web资源，就会建立一个HTTP会话。

但从 HTTP/1.1起，默认使用长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头有加入这行代码：Connection:keep-alive

在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的 TCP连接不会关闭，如果客户端再次访问这个服务器上的网页，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现长连接要客户端和服务端都支持长连接。

HTTP协议的长连接和短连接，实质上是TCP协议的长连接和短连接。

HTTP请求报文和响应报文的格式？

请求报文格式：

请求行（请求方法+URI协议+版本）
请求头部
空行
请求主体

GET/sample.jspHTTP/1.1 请求行
Accept:image/gif.image/jpeg, 请求头部
Accept-Language:zh-cn
Connection:Keep-Alive
Host:localhost
User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)
Accept-Encoding:gzip,deflate

username=jinqiao&password=1234 请求主体

响应报文：

状态行（版本+状态码+原因短语）
响应首部
空行
响应主体

HTTP/1.1 200 OK
Server:Apache Tomcat/5.0.12
Date:Mon,6Oct2003 13:23:42 GMT
Content-Length:112

<html>
    <head>
        <title>HTTP响应示例<title>
    </head>
    <body>
        Hello HTTP!
    </body>
</html>

HTTP1.0和HTTP1.1的区别?

长连接：HTTP 1.1支持长连接（Persistent Connection）和请求的流水线（Pipelining）处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟，在HTTP1.1中默认开启Connection： keep-alive，一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。
缓存处理：在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略，可供选择的缓存头来控制缓存策略。
带宽优化及网络连接的使用：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）。

HTTP1.1和 HTTP2.0的区别？

HTTP2.0相比HTTP1.1支持的特性：

新的二进制格式：HTTP1.1的解析是基于文本。基于文本协议的格式解析存在天然缺陷，文本的表现形式有多样性，要做到健壮性考虑的场景必然很多，二进制则不同，只认0和1的组合。基于这种考虑HTTP2.0的协议解析决定采用二进制格式，实现方便且健壮。
多路复用，即连接共享，即每一个request都是用作连接共享机制的。一个request对应一个id，这样一个连接上可以有多个request，每个连接的request可以随机的混杂在一起，接收方可以根据request的 id将request再归属到各自不同的服务端请求里面。
头部压缩，HTTP1.1的头部（header）带有大量信息，而且每次都要重复发送；HTTP2.0使用encoder来减少需要传输的header大小，通讯双方各自cache一份header fields表，既避免了重复header的传输，又减小了需要传输的大小。
服务端推送：服务器除了对最初请求的响应外，服务器还可以额外的向客户端推送资源，而无需客户端明确的请求。

HTTP 与 HTTPS 的区别？

	HTTP	HTTPS
端口	80	443
安全性	无加密，安全性较差	有加密机制，安全性较高
资源消耗	较少	由于加密处理，资源消耗更多
是否需要证书	不需要	需要
协议	运行在TCP协议之上	运行在SSL协议之上，SSL运行在TCP协议之上

HTTPS 的优缺点?

优点：

安全性：
- 使用HTTPS协议可认证用户和服务器，确保数据发送到正确的客户机和服务器；
- HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性。
- HTTPS是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。
SEO方面：谷歌曾在2014年8月份调整搜索引擎算法，并称“比起同等HTTP网站，采用HTTPS加密的网站在搜索结果中的排名将会更高”。

缺点：

在相同网络环境中，HTTPS 相比 HTTP 无论是响应时间还是耗电量都有大幅度上升。
HTTPS 的安全是有范围的，在黑客攻击、服务器劫持等情况下几乎起不到作用。
在现有的证书机制下，中间人攻击依然有可能发生。
HTTPS 需要更多的服务器资源，也会导致成本的升高。

HTTPS 的原理

图片来源：https://segmentfault.com/a/1190000021494676

加密流程按图中的序号分为：

客户端请求 HTTPS 网址，然后连接到 server 的 443 端口 (HTTPS 默认端口，类似于 HTTP 的80端口)。
采用 HTTPS 协议的服务器必须要有一套数字 CA (Certification Authority)证书。颁发证书的同时会产生一个私钥和公钥。私钥由服务端自己保存，不可泄漏。公钥则是附带在证书的信息中，可以公开的。证书本身也附带一个证书电子签名，这个签名用来验证证书的完整性和真实性，可以防止证书被篡改。
服务器响应客户端请求，将证书传递给客户端，证书包含公钥和大量其他信息，比如证书颁发机构信息，公司信息和证书有效期等。
客户端解析证书并对其进行验证。如果证书不是可信机构颁布，或者证书中的域名与实际域名不一致，或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。

如果证书没有问题，客户端就会从服务器证书中取出服务器的公钥A。然后客户端还会生成一个随机码 KEY，并使用公钥A将其加密。
客户端把加密后的随机码 KEY 发送给服务器，作为后面对称加密的密钥。
服务器在收到随机码 KEY 之后会使用私钥B将其解密。经过以上这些步骤，客户端和服务器终于建立了安全连接，完美解决了对称加密的密钥泄露问题，接下来就可以用对称加密愉快地进行通信了。
服务器使用密钥 (随机码 KEY)对数据进行对称加密并发送给客户端，客户端使用相同的密钥 (随机码 KEY)解密数据。
双方使用对称加密愉快地传输所有数据。

在浏览器中输入url后执行的全部过程？

域名解析（域名 www.baidu.com 变为 ip 地址）。

浏览器搜索自己的DNS缓存（维护一张域名与IP的对应表）；若没有，则搜索操作系统的DNS缓存（维护一张域名与IP的对应表）；若没有，则搜索操作系统的hosts文件（维护一张域名与IP的对应表）。

若都没有，则找 tcp/ip 参数中设置的首选 dns 服务器，即本地 dns 服务器（递归查询），本地域名服务器查询自己的dns缓存，如果没有，则进行迭代查询。将本地dns服务器将IP返回给操作系统，同时缓存IP。
发起 tcp 的三次握手，建立 tcp 连接。浏览器会以一个随机端口（1024-65535）向服务端的 web 程序 80 端口发起 tcp 的连接。
建立 tcp 连接后发起 http 请求。
服务器响应 http 请求，客户端得到 html 代码。服务器 web 应用程序收到 http 请求后，就开始处理请求，处理之后就返回给浏览器 html 文件。
浏览器解析 html 代码，并请求 html 中的资源。
浏览器对页面进行渲染，并呈现给用户。

附一张形象的图片：

什么是 Cookie

HTTP Cookie（也叫 Web Cookie或浏览器 Cookie）是服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上。通常，它用于告知服务端两个请求是否来自同一浏览器，如保持用户的登录状态。Cookie 使基于无状态的 HTTP 协议记录稳定的状态信息成为了可能。

Cookie 主要用于以下三个方面：

会话状态管理（如用户登录状态、购物车、游戏分数或其它需要记录的信息）
个性化设置（如用户自定义设置、主题等）
浏览器行为跟踪（如跟踪分析用户行为等）

什么是 Session

Session 代表着服务器和客户端一次会话的过程。Session 对象存储特定用户会话所需的属性及配置信息。这样，当用户在应用程序的 Web 页之间跳转时，存储在 Session 对象中的变量将不会丢失，而是在整个用户会话中一直存在下去。当客户端关闭会话，或者 Session 超时失效时会话结束。

用户第一次请求服务器的时候，服务器根据用户提交的相关信息，创建对应的 Session ，请求返回时将此 Session 的唯一标识信息 SessionID 返回给浏览器，浏览器接收到服务器返回的 SessionID 信息后，会将此信息存入到 Cookie 中，同时 Cookie 记录此 SessionID 属于哪个域名。

当用户第二次访问服务器的时候，请求会自动判断此域名下是否存在 Cookie 信息，如果存在自动将 Cookie 信息也发送给服务端，服务端会从 Cookie 中获取 SessionID，再根据 SessionID 查找对应的 Session 信息，如果没有找到说明用户没有登录或者登录失效，如果找到 Session 证明用户已经登录可执行后面操作。

根据以上流程可知，SessionID 是连接 Cookie 和 Session 的一道桥梁，大部分系统也是根据此原理来验证用户登录状态。

Cookie和Session的区别

作用范围不同，Cookie 保存在客户端（浏览器），Session 保存在服务器端。
存取方式的不同，Cookie 只能保存 ASCII，Session 可以存任意数据类型，一般情况下我们可以在 Session 中保持一些常用变量信息，比如说 UserId 等。
有效期不同，Cookie 可设置为长时间保持，比如我们经常使用的默认登录功能，Session 一般失效时间较短，客户端关闭或者 Session 超时都会失效。
隐私策略不同，Cookie 存储在客户端，比较容易遭到不法获取，早期有人将用户的登录名和密码存储在 Cookie 中导致信息被窃取；Session 存储在服务端，安全性相对 Cookie 要好一些。
存储大小不同，单个 Cookie 保存的数据不能超过 6k，Session 可存储数据远高于 Cookie。

如何考虑分布式 Session 问题

在互联网公司为了可以支撑更大的流量，后端往往需要多台服务器共同来支撑前端用户请求，那如果用户在 A 服务器登录了，第二次请求跑到服务 B 就会出现登录失效问题。

分布式 Session 一般会有以下几种解决方案：

客户端存储：直接将信息存储在cookie中，cookie是存储在客户端上的一小段数据，客户端通过http协议和服务器进行cookie交互，通常用来存储一些不敏感信息
Nginx ip_hash 策略：服务端使用 Nginx 代理，每个请求按访问 IP 的 hash 分配，这样来自同一 IP 固定访问一个后台服务器，避免了在服务器 A 创建 Session，第二次分发到服务器 B 的现象。
Session 复制：任何一个服务器上的 Session 发生改变（增删改），该节点会把这个 Session 的所有内容序列化，然后广播给所有其它节点。
共享 Session：服务端无状态话，将用户的 Session 等信息使用缓存中间件（如Redis）来统一管理，保障分发到每一个服务器的响应结果都一致。

建议采用共享 Session的方案。

前端缓存

前端缓存是一种在客户端（如浏览器）中存储网页资源（如 HTML 文件、CSS 样式表、JavaScript 脚本、图片等）的技术，目的是加快页面的加载速度并减少服务器的负载。前端缓存主要包括几种不同的类型，每种类型都有其特定的用途和管理策略。了解和合理利用这些缓存机制，可以显著提高网站的性能和用户体验。下面是前端缓存的几种主要形式：

浏览器缓存（HTTP 缓存）

这是最常见的缓存类型，利用 HTTP 协议定义的缓存机制来存储静态资源。浏览器缓存的控制通过 HTTP 头部指令进行，主要包括：

强缓存：使用 Cache-Control （优先级更高）或 Expires 头部直接从本地缓存加载资源，不向服务器发起请求，除非缓存过期。
协商缓存：使用 Last-Modified/If-Modified-Since 或 ETag/If-None-Match 头部与服务器进行资源有效性的验证。如果资源未修改，则服务器返回 304 Not Modified 状态，浏览器继续使用缓存资源。

Service Workers 缓存

Service Workers 提供了一种在浏览器背景下运行脚本的能力，可以用来管理网络请求、缓存内容和提供离线体验。通过 Service Workers，开发者可以精确控制缓存的行为，例如，实现自定义的缓存策略来处理动态内容或应用程序外壳（App Shell）。

Web Storage（localStorage 和 sessionStorage）

Web Storage 提供了在客户端存储数据的能力，但不像 HTTP 缓存那样自动应用。它允许网站存储大量数据而不影响网站性能：

localStorage：提供长期存储，数据在页面重新加载后依然可用，直到被明确清除。存在本地硬盘
sessionStorage：只在当前会话中有效，关闭标签页或浏览器后数据将被清除。

IndexedDB

IndexedDB 是一种在浏览器中存储大量结构化数据的方法。它支持事务和大量数据存储，适合存储应用程序的数据对象。这是实现复杂数据管理和提供离线应用功能的理想选择。

应用程序缓存（已废弃）

应用程序缓存曾是 HTML5 规范的一部分，允许网站指定哪些文件需要被缓存以及哪些需要在线才能访问。由于多种缺陷和限制，它已被 Service Workers 替代。

管理前端缓存的注意事项

版本控制：在文件名中使用版本号或哈希值，确保更新的内容可以被客户端正确识别和拉取。
合理设置过期时间：根据资源的更新频率合理设置 Cache-Control 的 max-age，避免缓存过期导致的不必要请求。
利用协商缓存：对于可能会更新的资源，使用 ETag 或 Last-Modified 头部实现协商缓存，减少数据传输。
离线体验：通过 Service Workers 和缓存 API 提供完整的离线体验，增加用户在无网络状态下的使用满意度。

通过这些缓存机制，前端开发者可以显著提高应用的加载速度和性能，同时提供更加流畅和高效的用户体验。

强缓存和协商缓存

强缓存和协商缓存是 HTTP 缓存机制中的两种主要策略，分别用于在客户端和服务器之间控制和管理资源的缓存行为。它们能够帮助减少网络请求次数，提高网站性能，同时降低带宽消耗。下面详细解释它们的概念、工作原理和区别。

强缓存（Strong Caching）

定义：强缓存是指客户端在缓存的有效期内，直接从本地缓存中读取资源，而不需要与服务器通信确认资源的有效性。

工作原理：

当客户端请求一个资源时，如果这个资源已经存在于本地缓存并且没有过期，那么客户端直接从缓存中读取该资源，无需发送请求到服务器。这种方式减少了请求的数量和网络延迟。
强缓存的有效期由 HTTP 响应头中的 Cache-Control 或 Expires 指令来控制。

主要的 HTTP 头部字段：

**Cache-Control**：
- max-age: 指定资源在缓存中可以存活的最大时间（以秒为单位）。例如，Cache-Control: max-age=3600 表示该资源可以在本地缓存中保存 3600 秒（1 小时）。
- public：表示资源可以被任何缓存（如浏览器、CDN 等）存储。
- private：表示资源只能被客户端的私有缓存存储，不能被共享缓存（如代理服务器）存储。
- immutable：表示资源是不可变的，即在缓存存活期内资源不会发生变化。
**Expires**：
- 指定资源的过期时间（使用 HTTP 日期格式）。例如，Expires: Wed, 21 Oct 2024 07:28:00 GMT。在这个时间之前，客户端可以直接使用缓存资源。

注意：Cache-Control 的优先级高于 Expires。如果两者同时存在，以 Cache-Control 为准。

使用场景：

适用于不经常变化的资源（如图片、CSS、JavaScript 文件等），可以通过强缓存减少请求次数，加快页面加载速度。

协商缓存（Conditional Caching）

定义：协商缓存是指在缓存资源失效或者客户端没有命中强缓存时，客户端向服务器发送一个请求，通过服务器来确定缓存的资源是否仍然有效。

工作原理：

当客户端请求一个资源时，如果没有命中强缓存或资源已过期，客户端会向服务器发送一个请求，附带上次缓存的标识（如时间戳或内容校验值）。
服务器根据这些标识判断资源是否有更新：
- 如果资源没有变化，服务器返回一个 304 Not Modified 响应，告诉客户端继续使用本地缓存的版本，同时不需要传输实际的资源内容。
- 如果资源发生变化，服务器返回 200 OK 状态码，并发送新的资源内容。

主要的 HTTP 头部字段：

**Last-Modified 和 If-Modified-Since**：
- Last-Modified：服务器在响应头中返回的时间戳，表示资源的最后修改时间。
- If-Modified-Since：客户端在后续请求中将此时间戳发送给服务器，询问资源是否自该时间后有过修改。
**ETag 和 If-None-Match**：
- ETag（实体标签）：服务器为每个资源生成的唯一标识符（通常是一个哈希值），表示资源的内容版本。
- If-None-Match：客户端在后续请求中将此 ETag 值发送给服务器，询问资源的内容是否发生变化。

使用场景：

协商缓存适用于可能会被更新的资源（如动态内容、API 响应等），确保客户端始终获得最新的内容。

强缓存和协商缓存的区别

特性	强缓存（Strong Caching）	协商缓存（Conditional Caching）
缓存控制	由 `Cache-Control` 和 `Expires` 控制	由 `Last-Modified`/`If-Modified-Since` 或 `ETag`/`If-None-Match` 控制
请求次数	不需要向服务器发送请求	需要向服务器发送请求，验证缓存是否有效
响应结果	直接从本地缓存读取资源	可能收到 `304 Not Modified` 响应
性能	更高性能（不需要服务器通信）	性能稍差（需要与服务器通信验证）
使用场景	适用于静态、不频繁变化的资源	适用于可能会变化的资源

强缓存和协商缓存的联合使用

在实际应用中，通常会同时使用强缓存和协商缓存，以便在保证性能的同时确保资源的及时更新。例如，首先尝试使用强缓存，如果强缓存未命中或资源过期，再使用协商缓存来验证资源是否仍然有效。

示例配置：
服务器可以配置类似如下的缓存控制头部：

1
2
3

Cache-Control: max-age=3600, must-revalidate
ETag: "abc123"
Last-Modified: Wed, 21 Oct 2024 07:28:00 GMT

在这个例子中：

强缓存：使用 max-age=3600 表示资源在 3600 秒（1 小时）内有效。
协商缓存：当强缓存过期时，通过 ETag 或 Last-Modified 来协商缓存的有效性。

总结：

强缓存：在缓存有效期内，客户端直接使用本地缓存，不与服务器通信。
协商缓存：在缓存过期或未命中时，客户端会向服务器确认资源是否仍然有效，可能减少数据传输量。
两者结合使用可以在保证性能的同时确保资源更新的及时性。

什么是DDos攻击

DDos全称Distributed Denial of Service，分布式拒绝服务攻击。最基本的DOS攻击过程如下：

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

DDoS则是采用分布式的方法，通过在网络上占领多台“肉鸡”，用多台计算机发起攻击。

DOS攻击现在基本没啥作用了，因为服务器的性能都很好，而且是多台服务器共同作用，1V1的模式黑客无法占上风。对于DDOS攻击，预防方法有：

减少SYN timeout时间。在握手的第三步，服务器会等待30秒-120秒的时间，减少这个等待时间就能释放更多的资源。
限制同时打开的SYN半连接数目。

什么是XSS攻击

XSS也称 cross-site scripting，跨站脚本。这种攻击是由于服务器将攻击者存储的数据原原本本地显示给其他用户所致的。比如一个存在XSS漏洞的论坛，用户发帖时就可以引入带有＜script＞标签的代码，导致恶意代码的执行。

预防措施有：

前端：过滤。
后端：转义，比如go自带的处理器就具有转义功能。

SQL注入是什么，如何避免SQL注入？

SQL 注入就是在用户输入的字符串中加入 SQL 语句，如果在设计不良的程序中忽略了检查，那么这些注入进去的 SQL 语句就会被数据库服务器误认为是正常的 SQL 语句而运行，攻击者就可以执行计划外的命令或访问未被授权的数据。

SQL注入的原理主要有以下 4 点

恶意拼接查询
利用注释执行非法命令
传入非法参数
添加额外条件

避免SQL注入的一些方法：

限制数据库权限，给用户提供仅仅能够满足其工作的最低权限。
对进入数据库的特殊字符（’”\尖括号&*;等）转义处理。
提供参数化查询接口，不要直接使用原生SQL。

负载均衡算法有哪些？

多台服务器以对称的方式组成一个服务器集合，每台服务器都具有等价的地位，能互相分担负载。

轮询法：将请求按照顺序轮流的分配到服务器上。大锅饭，不能发挥某些高性能服务器的优势。
随机法：随机获取一台，和轮询类似。
哈希法：通过ip地址哈希化来确定要选择的服务器编号。好处是,每次客户端访问的服务器都是同一个服务器，能很好地利用session或者cookie。
加权轮询：根据服务器性能不同加权。

计算机网络的各层协议及作用

TCP和UDP的区别

UDP 和 TCP 对应的应用场景是什么

TCP 的三次握手

为什么需要三次握手，而不是两次

为什么要三次握手，而不是四次

请求头和响应头

Request Headers（请求头）

常见字段：

Response Headers（响应头）

常见字段：

总结

什么是 SYN洪泛攻击？如何防范？

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

TCP 的四次挥手过程

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

为什么客户端的 TIME-WAIT 状态必须等待 2MSL ？

如果已经建立了连接，但是客户端出现故障了怎么办？

TIME-WAIT 状态过多会产生什么后果？怎样处理？

TIME_WAIT 是服务器端的状态?还是客户端的状态?

TCP协议如何保证可靠性？

详细讲一下TCP的滑动窗口？

详细讲一下拥塞控制？

HTTP常见的状态码有哪些？

状态码301和302的区别是什么？

HTTP 常用的请求方式？

GET请求和POST请求的区别？

解释一下HTTP长连接和短连接？

HTTP请求报文和响应报文的格式？

HTTP1.0和HTTP1.1的区别?

HTTP1.1和 HTTP2.0的区别？

HTTP 与 HTTPS 的区别？

HTTPS 的优缺点?

HTTPS 的原理

在浏览器中输入url后执行的全部过程？

Cookie 和 Session

Cookie 和 Session 是如何配合的

Cookie和Session的区别

如何考虑分布式 Session 问题

前端缓存

浏览器缓存（HTTP 缓存）

Service Workers 缓存

Web Storage（localStorage 和 sessionStorage）

IndexedDB

应用程序缓存（已废弃）

管理前端缓存的注意事项

强缓存和协商缓存

强缓存（Strong Caching）

工作原理：

主要的 HTTP 头部字段：

使用场景：

协商缓存（Conditional Caching）

工作原理：

主要的 HTTP 头部字段：

使用场景：

强缓存和协商缓存的区别

强缓存和协商缓存的联合使用

总结：

什么是DDos攻击

什么是XSS攻击

SQL注入是什么，如何避免SQL注入？

负载均衡算法有哪些？