网络面试题

状态码：

1xx：信息性状态码

101：切换请求协议

2xx：成功状态码

200：请求成功

204：请求被受理但没有资源可以返回

206：客户端只是请求资源的一部分，服务器只对请求的部分资源执行GET方法，相应报文中通过Content-Range指定范围的资源。

3xx：重定向状态码

301：永久性重定向，会缓存

302：临时重定向，不会缓存

303：与302状态码有相似功能，只是它希望客户端在请求一个URI的时候，能通过GET方法重定向到另一个URI上

304：发送附带条件的请求时，条件不满足时返回，与重定向无关

307：临时重定向，与302类似，只是强制要求使用POST方法

4xx：客户端错误状态码

400：客户端请求的语法错误，服务器无法识别

401：请求需要认证

403：请求的对应资源禁止被访问，和权限有关

404：服务器无法根据客户端的请求找到资源

5xx：服务端错误状态码

500：服务器内部错误

503：服务器正忙

说说HTTP的状态码，301和302的区别？

301：（永久性转移）请求的网页已被永久移动到新位置。服务器返回此响应时，会自动将请求者转到新位置。

302：（暂时性转移）服务器目前正从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。

HTTP请求方式

GET：对服务器资源获取的简单请求

POST：用于发送包含用户提交数据的请求

PUT：向服务器提交数据，以修改数据

HEAD：请求页面的首部，获取资源的元信息

DELETE：删除服务器上的某些资源

体系结构

ISO七层模型：

物理层；数据链路层；网络层；运输层；会话层；表示层；应用层

TCP/IP四层模型：

网络接口层；网际层IP；运输层；应用层

五层协议：

物理层；数据链路层；网络层；运输层；应用层

如何理解HTTP协议是无状态的

当浏览器第一次发送请求给服务器时，服务器响应了；如果同个浏览器发起第二次请求给服务器时，它还是会响应，但是呢，服务器不知道你就是刚才的那个浏览器。简言之，服务器不会去记住你是谁，所以是无状态协议。

forward和redirect的区别

直接转发方式（Forward） ，客户端和浏览器只发出一次请求，Servlet、HTML、JSP或其它信息资源，由第二个信息资源响应该请求，在请求对象request中，保存的对象对于每个信息资源是共享的。

间接转发方式（Redirect） 实际是两次HTTP请求，服务器端在响应第一次请求的时候，让浏览器再向另外一个URL发出请求，从而达到转发的目的。

#和$的区别

#{}是一个参数占位符，对于字符串类型，会自动加上""，其他类型不加。由于Mybatis采用预编译，其后的参数不会再进行SQL编译，所以一定程度上防止SQL注入。

${}是一个简单的字符串替换，字符串是什么，就会解析成什么，存在SQL注入风险

Session和Cookie

什么是 Cookie

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

Cookie是保存在客户端的一小块文本串的数据。客户端向服务器发起请求时，服务端会向客户端发送一个Cookie，客户端就把Cookie保存起来。在客户端下次向同一服务器再发起请求时，Cookie被携带发送到服务器。服务器就是根据这个Cookie来确认身份的。

什么是 Session

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

Session指的就是服务器和客户端一次会话的过程。Session利用Cookie进行信息处理的，当用户首先进行了请求后，服务端就在用户浏览器上创建了一个Cookie，当这个Session结束时，其实就是意味着这个Cookie就过期了。Session对象存储着特定用户会话所需的属性及配置信息。

Cookie 和 Session 有什么不同？

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

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

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

隐私策略不同，Cookie 存储在客户端，比较容易遭到不法获取，早期有人将用户的登录名和密码存储在 Cookie 中导致信息被窃取；Session 存储在服务端，安全性相对 Cookie 要好一些。

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

为什么需要 Cookie 和 Session，他们有什么关联？

说起来为什么需要 Cookie ，这就需要从浏览器开始说起，我们都知道浏览器是没有状态的(HTTP 协议无状态)，这意味着浏览器并不知道是张三还是李四在和服务端打交道。这个时候就需要有一个机制来告诉服务端，本次操作用户是否登录，是哪个用户在执行的操作，那这套机制的实现就需要 Cookie 和 Session 的配合。

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

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

TCP 的三次握手机制

第一次握手(SYN=1, seq=x)，发送完毕后，客户端就进入SYN_SEND状态

第二次握手(SYN=1, ACK=1, seq=y, ACKnum=x+1)， 发送完毕后，服务器端就进入SYN_RCV状态。

第三次握手(ACK=1，ACKnum=y+1)，发送完毕后，客户端进入ESTABLISHED状态，当服务器端接收到这个包时，也进入ESTABLISHED状态。

---

第一次握手

Client端将SYN置为1，表示希望与Server端建立连接；序号seq初始化为J，并将该数据包发送给Server端，Client进入SYN_SENT状态，等待Server确认。

第二次握手

Server端检查报文发现SYN为1，知道了Client端想建立连接；Server端将SYN置为1，表示Server端也希望与Clinet端建立连接；Server端将ACK置为1，表示收到了Client端建立连接的请求；Server端将seq初始化为K；Server端将ack置为J+1，这里ack=seq + 1，还有疑问（如果控制位占1字节，为什么第三次握手时有ACK=1、SYN=1，ack为什么不是+2？如果+1只是告诉服务端收到了消息，那ACK控制位就已经达到目的了，为什么还要多次一举再加一个ack?）。第二次握手包括服务端确认客户端发来的报文和服务端向客户端发送报文两个过程。

第三次握手

Client收到报文后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，并将该数据包发送给Server，Server检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，Client和Server进入ESTABLISHED状态，完成三次握手，随后Client与Server之间可以开始传输数据了。第三次握手包括客户端确认服务端发来的报文，客户端向服务端发送报文和服务端确认客户端发来的报文三个过程。

 

TCP 的四此挥手机制

第一次挥手(FIN=1，seq=u)，发送完毕后，客户端进入FIN_WAIT_1状态。

第二次挥手(ACK=1，ack=u+1,seq =v)，发送完毕后，服务器端进入CLOSE_WAIT状态，客户端接收到这个确认包之后，进入FIN_WAIT_2状态。

第三次挥手(FIN=1，ACK1,seq=w,ack=u+1)，发送完毕后，服务器端进入LAST_ACK状态，等待来自客户端的最后一个ACK。

第四次挥手(ACK=1，seq=u+1,ack=w+1)，客户端接收到来自服务器端的关闭请求，发送一个确认包，并进入TIME_WAIT状态，等待了某个固定时间（两个最大段生命周期，2MSL，2 Maximum Segment Lifetime）之后，没有收到服务器端的ACK ，认为服务器端已经正常关闭连接，于是自己也关闭连接，进入CLOSED状态。服务器端接收到这个确认包之后，关闭连接，进入CLOSED状态。

---

第一次挥手

假设客户端主动发起断开请求，客户端向服务端发送报文，报文首部包括FIN=1，这个控制位代表客户端想要断开连接；序列号seq=u，这时客户端进入FIN-WAIT-1（终止等待1）状态，停止发送数据，并等待服务端的确认。

第二次挥手

服务端收到客户端的报文后发出确认报文，控制位ACK=1；确认号ack=u+1；序列号seq=v；然后服务端就进入CLOSE-WAIT（关闭等待）状态。TCP服务端会告知上层的应用进程来自客户端的连接即将关闭，让应用程序做好相应的准备。此时客户端已经没有数据向服务端发送了，但服务端向客户端发送数据，客户端依然能接收。

第三次挥手

客户端收到服务器确认报文后，进入FIN-WAIT-2状态。此时服务器再次发送报文，报文首部控制位FIN=1，表示服务端向客户端发送断开连接请求；确认标志ACK=1；确认序号ack=u+1；序号seq=w，然后服务器进入LAST-ACK（最后确认态），等待客户端确认。

第四次挥手

客户端收到了服务端的断开连接的报文后，必须发出确认报文，标志位ACK=1；确认号ack=w+1;序号seq=u+1；之后客户端就进入了TIME-WAIT（时间等待）状态。注意此时客户端的TCP连接还没有释放，必须经过2*MSL（最长报文段寿命）的时间后，客户端才进入CLOSED状态关闭连接。而服务端只要收到了客户端发送的确认报文后就会进入CLOSED状态关闭服务端连接。当客户端和服务端都进入了CLOSED状态后，客户端和服务端之间的连接才完全断开。

TCP四次挥手过程中，为什么需要等待2MSL,才进入CLOSED关闭状态

1.为了保证客户端发送的最后一个ACK报文段能够到达服务端。 这个ACK报文段有可能丢失，因而使处在LAST-ACK状态的服务端就收不到对已发送的FIN + ACK报文段的确认。服务端会超时重传这个FIN+ACK 报文段，而客户端就能在 2MSL 时间内（超时 + 1MSL 传输）收到这个重传的 FIN+ACK 报文段。接着客户端重传一次确认，重新启动2MSL计时器。最后，客户端和服务器都正常进入到CLOSED状态。

2. 防止已失效的连接请求报文段出现在本连接中。客户端在发送完最后一个ACK报文段后，再经过时间2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样就可以使下一个连接中不会出现这种旧的连接请求报文段。

---

客户端发送给服务端回执后，有可能这个回执报文在传输途中丢失等原因，服务端并没有收到，此时服务端会再次向客户端发送FIN=1的断开请求报文，如果客户端没有等待2*MSL时间而直接进入了CLOSED状态，客户端就会收不到服务端再次发送的断开连接的请求报文，导致服务端无法进入CLOSED状态；

等待一段时间是为了让本连接持续时间内所产生的所有报文都从网络中消失，使得下一个新的连接不会出现旧的连接请求报文。

请简述TCP和UDP

TCP是面向连接，而UDP是无连接。

TCP作为一种面向有连接的协议，只有在确认通信对端存在时才会发送数据，会在传输开始前建立连接，传输结束后断开连接，此外，TCP还采取了多种措施保障传输的可靠性。

UDP仅提供了最基本的数据传输功能，至于传输时连接的建立和断开、传输可靠性的保证这些UDP统统不关心，而是把这些问题抛给了UDP上层的应用层程序去处理，自己仅提供传输层协议的最基本功能。

TCP和UDP的区别如下：

TCP是面向有连接型，UDP是面向无连接型；

TCP是一对一传输，UDP支持一对一、一对多、多对一和多对多的交互通信；

TCP是面向字节流的，即把应用层传来的报文看成字节流，将字节流拆分成大小不等的数据块，并添加TCP首部；UDP是面向报文的，对应用层传下来的报文不拆分也不合并，仅添加UDP首部；

TCP支持传输可靠性的多种措施，包括保证包的传输顺序、重发机制、流量控制和拥塞控制；UDP仅提供最基本的数据传输能力。

TCP是如何确保可靠性的呢？

首先，TCP的连接是基于三次握手，而断开则是基于四次挥手。确保连接和断开的可靠性。

其次，TCP的可靠性，还体现在有状态;TCP会记录哪些数据发送了，哪些数据被接收了，哪些没有被接受，并且保证数据包按序到达，保证数据传输不出差错。

再次，TCP的可靠性，还体现在可控制。它有数据包校验、ACK应答、超时重传(发送方)、失序数据重传（接收方）、丢弃重复数据、流量控制（滑动窗口）和拥塞控制等机制。