2020届秋招面试题总结——网络篇

【转载】2020届秋招面试题总结——网络篇

2020届秋招面试题总结——网络篇

1、http1.0和http1.1的区别。

主要是如下的8点：

• 可拓展性。
• 缓存。
• 带宽优化，带来了分块传输。
• 长连接，HTTP1.1支持长连接（默认开启Connect: keep-alive）和请求的流水线处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。
• 消息传递。
• Host头域。
• 错误提示。
• 内容协商。

2、TCP三次握手和四次挥手的流程，为什么断开连接要四次，如果握手只有两次，会出现什么。

三次握手：

主要流程为：

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

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

• 第三次握手(ACK=1，ACKnum=y+1)，发送完毕后，客户端进入 ESTABLISHED 状态，当服务器端接收到这个包时，也进入 ESTABLISHED 状态，TCP 握手，即可以开始数据传输。

为什么 TCP 连接需要三次握手，两次不可以么，为什么？

为了防止已失效的连接请求报文突然又传送到了服务端，因而产生错误。

• 客户端发出的连接请求报文并未丢失，而是在某个网络节点长时间滞留了，以致延误到链接释放以后的某个时间才到达 Server 。
• 若不采用“三次握手”，那么只要 Server 发出确认数据包，新的连接就建立了。由于 Client 此时并未发出建立连接的请求，所以其不会理睬 Server 的确认，也不与 Server 通信；而这时 Server 一直在等待 Client 的请求，这样 Server 就白白浪费了一定的资源。
• 若采用“三次握手”，在这种情况下，由于 Server 端没有收到来自客户端的确认，则就会知道 Client 并没有要求建立请求，就不会建立连接。

四次挥手：

主要流程为：

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

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

握手过程如果只有两次，可能会出现已失效的连接请求报文突然又传送到了服务端，因而产生错误。

在三次握手过程中，为了保证服务端能收接受到客户端的信息并能做出正确的应答而进行前两次(第一次和第二次)握手，为了保证客户端能够接收到服务端的信息并能做出正确的应答而进行后两次(第二次和第三次)握手。

3、TIME_WAIT和CLOSE_WAIT的区别。

TIME_WAIT表示主动关闭，CLOSE_WAIT表示被动关闭。

TCP协议规定，对于已经建立的连接，网络双方要进行四次挥手才能断开连接，如果缺少了其中某个步骤，将会使连接处于假死状态，连接本身占用的资源不会被释放。网络服务器程序要同时管理大量连接，所以很有必要保证无用连接完全断开，否则大量僵死的连接会浪费许多服务器资源。在众多TCP状态中，最值得注意的状态有两个：CLOSE_WAIT和TIME_WAIT。

• TIME_WAIT 是主动关闭链接时形成的，等待2MSL时间，约4分钟。一方面是为了把原来的连接里面的重复数据包都已经在网络中消逝。避免老的连接的数据影响新建立的连接（新老连接的IP和端口号相同，新的被称为老的连接到化身）。 另一方面， 假如客户端回复的ACK丢失，服务端会重发FIN，客户端此时还能接收到FIN，还能再回复一个ACK（此时time_wait会重新计时）（MSL是指一个包的最大存活时间，一般是两分钟。）
• 另一种对于TIME_WAIT的解释：如果没有TIME_WEIT这个等待，释放的端口可能会重连刚断开的服务器端口，这样依然存活在网络里的老的 TCP 报文可能与新 TCP 连接报文冲突，造成数据冲突，为避免此种情况，需要耐心等待网络老的 TCP 连接的活跃报文全部死翘翘，2MSL 时间可以满足这个需求（尽管非常保守）！
• CLOSE_WAIT是被动关闭连接是形成的。根据TCP状态机，服务器端收到客户端发送的FIN，则按照TCP实现发送ACK，因此进入CLOSE_WAIT状态。但如果服务器端不执行close()，就不能由CLOSE_WAIT迁移到LAST_ACK，则系统中会存在很多CLOSE_WAIT状态的连接。此时，可能是系统忙于处理读、写操作，而未将已收到FIN的连接，进行close。此时，recv/read已收到FIN的连接socket，会返回0。

参考链接：TIME_WAIT和CLOSE_WAIT状态区别

4、说说你知道的几种HTTP响应码，比如200，302和404。

HTTP响应码主要分为五种：

• 1XX：请求处理中，请求已被接收，正在处理。
• 2XX：请求成功，请求被成功处理。比如200，OK，表示客户端请求成功。
• 3XX：重定向，要完成请求必须进行进一步处理。比如301，Moved Permanently，永久重定向，使用域名跳转；302，Found，临时重定向，未登录的用户访问用户中心重定向到登陆界面。
• 4XX：客户端错误，请求不合符。比如400，Bad Request，客户端请求有语法错误，不能被服务器所理解；401，Unauthrized，请求未经授权，这个状态代码必须和WWW-Authenticate 报头域一起使用；403，Forbidden，服务器收到请求，但是拒绝提供服务；404，Not Found，请求资源不存在，输入了错误的URL。
• 5XX：服务器端错误，服务器不能处理合法请求。比如500，Internal Servel Error，服务器发生不可预期的错误；503，Server Unavailable，服务器当前不能处理客户端的请求，一段时间后可能恢复正常。

5、当你用浏览器打开一个链接（如：http://www.baidu.com ）的时候，计算机做了哪些工作步骤。

计算机的工作主要是将域名解析成ip地址。

主机解析域名的顺序依次是：

• 浏览器缓存。
• 找本机的hosts文件。
• 路由缓存。
• 找DNS服务器（本地域名、顶级域名、根域名），主要分为递归查询和迭代查询。

需要注意的是：

• 主机向本地域名服务器的查询一般都是采用递归查询。所谓递归查询就是：如果主机所询问的本地域名服务器不知道被查询的域名的IP地址，那么本地域名服务器就以DNS客户的身份，向其它根域名服务器继续发出查询请求报文(即替主机继续查询)，而不是让主机自己进行下一步查询。因此，递归查询返回的查询结果或者是所要查询的IP地址，或者是报错，表示无法查询到所需的IP地址。
• 本地域名服务器向根域名服务器的查询的迭代查询。迭代查询的特点：当根域名服务器收到本地域名服务器发出的迭代查询请求报文时，要么给出所要查询的IP地址，要么告诉本地服务器：“你下一步应当向哪一个域名服务器进行查询”。然后让本地服务器进行后续的查询。根域名服务器通常是把自己知道的顶级域名服务器的IP地址告诉本地域名服务器，让本地域名服务器再向顶级域名服务器查询。顶级域名服务器在收到本地域名服务器的查询请求后，要么给出所要查询的IP地址，要么告诉本地服务器下一步应当向哪一个权限域名服务器进行查询。

递归和迭代查询示意图如下：

参考文章：DNS原理总结及其解析过程详解（递归查询+迭代查询）

6、TCP/IP如何保证可靠性，说说TCP头的结构。

TCP提供一种面向连接的、可靠的字节流服务。其中，面向连接意味着两个使用TCP的应用（通常是一个客户和一个服务器）在彼此交换数据之前必须先建立一个TCP连接。

对于可靠性，TCP通过以下方式进行保证：

• 数据包校验： 目的是检验数据在传输过程中的变化，若检验包有错，则丢弃报文段并且不给出响应，这时TCP发送数据超时后会重发数据。
• 序号机制（序号、确认号）： 确保了数据是按序、完整到达。
• 对失序数据包重排序： 既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序，因此TCP报文段的到达也可能会失序。TCP将对失序数据进行重新排序，然后才交给应用层。TCP传输时将每个字节的数据都进行了编号，这就是序列号。TCP传输的过程中，每次接收方收到数据后，都会对传输方进行确认应答。也就是发送ACK报文。这个ACK报文当中带有对应的确认序列号，告诉发送方，接收到了哪些数据，下一次的数据从哪里发。
• 丢弃重复数据： 对于重复数据，能够丢弃重复数据。这是在超时重传情况下可能发生，判断依据就是序列号。
• 应答机制： 当TCP收到发自TCP连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒。
• 超时重发： 当TCP发出一个段后，他启动一个定时器，等待目的端确认收到这个报文段，如果不能及时收到一个确认，将重发这个报文段。
• 流量控制： TCP根据接收端对数据的处理能力，决定发送端的发送速度，这个机制就是流量控制。在TCP协议的报头信息当中，有一个16位字段的窗口大小。在介绍这个窗口大小时我们知道，窗口大小的内容实际上是接收端接收数据缓冲区的剩余大小。这个数字越大，证明接收端接收缓冲区的剩余空间越大，网络的吞吐量越大。接收端会在确认应答发送ACK报文时，将自己的即时窗口大小填入，并跟随ACK报文一起发送过去。而发送方根据ACK报文里的窗口大小的值的改变进而改变自己的发送速度。如果接收到窗口大小的值为0，那么发送方将停止发送数据。并定期的向接收端发送窗口探测数据段，让接收端把窗口大小告诉发送端。TCP使用的流量控制协议是可变大小的滑动窗口协议。
• 拥塞控制： TCP传输过程中，发送端开始发送数据的时候，如果刚开始就发送大量的数据，那么就可能造成一些问题，网络可能在开始的时候就很拥堵，如果给网络再扔出大量数据，那么这个拥堵就会加剧。拥堵的加剧就会产生大量的丢包，以及大量的超时重传，严重影响传输。所以TCP引入了慢启动的机制，在刚开始发送数据时，先发送少量的数据探路，探清当前的网络状态如何，再决定多大的速度进行传输。这个时候就引入了一个叫做拥塞窗口的概念。拥塞窗口是发送端根据网络拥塞情况确定的窗口值。 在刚刚开始发送报文的时候，先把拥塞窗口设置1，每经过一个传输轮次（把拥塞窗口所允许发送的报文段都连续发送出去，并收到接受方的确认应答），拥塞窗口就加倍， 这个增长速度是指数级别的，为了控制拥塞窗口的增长，不能使拥塞窗口单纯的加倍，设置一个拥塞窗口的阈值，当拥塞窗口大小超过阈值时，不能再按照指数来增长，而是线性的增长。慢开始的“慢”并不是指拥塞窗口的增长速率慢，而是指在TCP开始发送报文段时先设置拥塞窗口=1，使得发送方在开始时只发送一个报文段（目的是试探一下网络的拥塞情况），然后再逐渐增大拥塞窗口。在发送数据之前，首先将拥塞窗口与接收端反馈的窗口大小比对，取最小的值作为实际发送的窗口。一旦造成网络拥塞，发生超时重传时，慢启动的阈值会为原来的一半（这里的原来指的是发生网络拥塞时拥塞窗口的大小），同时拥塞窗口重置为 1。

参考文章：网络基础：TCP协议-如何保证传输可靠性

7、如何避免浏览器缓存。

主要有以下几种方法：

• Cache-Control/Pragma这个HTTP Head字段用于指定所有缓存机制在整个请求/响应链中必须服从的指令，如果知道该页面是否为缓存，不仅可以控制浏览器，还可以控制和HTTP协议相关的缓存或代理服务器。
• Expires通常的使用格式是Expires:Sat,25Feb201212:22:17GMT，后面跟着一个日期和时间，超过这个时间值后，缓存的内容将失效，也就是浏览器在发出请求之前检查这个页面的这个字段，看该页面是否已经过期了，过期了就重新向服务器发起请求。
• Last-Modified/EtagLast-Modified字段一般用于表示一个服务器上的资源的最后修改时间，资源可以是静态（静态内容自动加上Last-Modified字段）或者动态的内容（如Servlet提供了一个getLastModified方法用于检查某个动态内容是否已经更新），通过这个最后修改时间可以判断当前请求的资源是否是最新的。
• 在每次请求后面加上一个随机数，这样保证每次发送的都是不一样的请求。比如url = “http://localhost:8080/test/login/index”?r=Math.random();

参考连接：面试官：你了解过浏览器缓存机制吗？

8、如何理解HTTP协议的无状态性。

无状态，是指协议对于事务处理没有记忆功能。HTTP 是一个无状态协议，这意味着每个请求都是独立的，Keep-Alive 没能改变这个结果。无状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就很快。

无状态，更容易做服务的扩容，支撑更大的访问量。

9、简述Http请求中get和post的区别及数据包格式。

GET：对服务器资源的简单请求，把参数包含在URL中。

POST：用于发送包含用户提交数据的请求，通过request body传递阐述。

另外，对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。

10、HTTP中有哪些method。

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

HEAD：类似于GET，但服务器在响应中只返回首部，不返回实体的主体部分。

PUT：向指定资源位置上传其最新内容，是幂等的。

POST：用于发送包含用户提交数据的请求，是不幂等的，当我们多次发出同样的POST请求后，其结果是创建出了若干个资源。

TRACE：发送一个请求副本，以跟踪其处理进程。

OPTIONS：返回所有可用方法，检查服务器支持哪些方法。DELETE：请求服务器删除请求URL指定的资源。

另外，对幂等理解，幂等是数学的一个用于，对于单个输入或者无输入的运算方法，如果每次都是同样的结果，则称其是幂等的。方法GET，HEAD，PUT，DELETE都有这种性质。POST方法不是幂等的。

11、简述HTTP请求的报文格式。

HTTP的请求报文如图，由四部分构成：

• 请求行，用来说明请求类型、要访问的资源以及所使用的HTTP版本。例如 GET /books/java.html HTTP/1.1
• 请求头部，紧接着请求行（即第一行）之后的部分，用来说明服务器要使用的附加信息，第二行起为请求头部。
• 空行，请求头部后面的空行是必须的。
• 请求数据，也叫主体，可以添加任意的其他数据。

HTTP的响应报文如图，也是由四部分构成：

• 状态行，由HTTP协议版本号、状态码、状态消息三部分构成。
• 消息报文，用来说明客户端要使用的一些附加消息。
• 空行，消息报文后面的空行是必须的。
• 响应报文，服务器返回给客户端的文本信息。

12、HTTP的长连接是什么意思。

HTTP1.0规定浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器完成请求处理后立即断开TCP连接，服务器不跟踪每个客户也不记录过去的请求，此外，由于大多数网页的流量都比较小，一次TCP连接很少能通过slow-start区，不利于提高带宽利用率。

HTTP 1.1支持长连接（PersistentConnection）和请求的流水线（Pipelining） 处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。例如：一个包含有许多图像的网页文件的多个请求和应答可以在一个连接中传输，但每个单独的网页文件的请求和应答仍然需要使用各自的连接。

HTTP 1.1还允许客户端不用等待上一次请求结果返回，就可以发出下一次请求，但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果，以保证客户端能够区分出每次请求的响应内容，这样也显著地减少了整个下载过程所需要的时间（请求的流水线）。

在HTTP/1.0中，要建立长连接，可以在请求消息中包含Connection: Keep-Alive头域，如果服务器愿意维持这条连接，在响应消息中也会包含一个Connection: Keep-Alive的头域。同时，可以加入一些指令描述该长连接的属性，如max，timeout等。

13、HTTPS的加密方式是什么，讲讲整个加密解密流程。

HTTP直接通过明文在浏览器和服务器之间传递消息，容易被监听抓取到通信内容。

HTTPS采用对称加密和非对称加密结合的方式来进行通信，HTTPS不是应用层的新协议，而是HTTP通信接口用SSL/TLS来加强加密和认证机制。

整个加密流程如下：

需要注意的是，第一次服务器向客户端传输证书的具体过程为：

• 把公钥以及服务器的个人信息通过Hash算法生成信息摘要；
• 为了防止信息摘要被人调换，服务器还会用CA提供的私钥对信息摘要进行加密来形成数字签名；
• 最后还会把原来没Hash算法之前的个人信息以及公钥 和 数字签名合并在一起，形成数字证书。

当客户端拿到这份数字证书之后，就会用CA提供的公钥来对数字证书里面的数字签名进行解密来得到信息摘要，然后对数字证书里服务器的公钥以及个人信息进行Hash得到另外一份信息摘要。最后把两份信息摘要进行对比，如果一样，则证明这个人是服务器，否则就不是。

整个的流程如下：

1. 客户端向服务器发起HTTPS请求，连接到服务器的443端口。
2. 服务器端有一个密钥对，即公钥和私钥，是用来进行非对称加密使用的，服务器端保存着私钥，不能将其泄露，公钥可以发送给任何人。
3. 服务器将自己的公钥发送给客户端。
4. 客户端收到服务器端的公钥之后，会对公钥进行检查，验证其合法性，如果发现发现公钥有问题，那么HTTPS传输就无法继续。严格的说，这里应该是验证服务器发送的数字证书的合法性，关于客户端如何验证数字证书的合法性，下文会进行说明。如果公钥合格，那么客户端会生成一个随机值，这个随机值就是用于进行对称加密的密钥，我们将该密钥称之为client key，即客户端密钥，这样在概念上和服务器端的密钥容易进行区分。然后用服务器的公钥对客户端密钥进行非对称加密，这样客户端密钥就变成密文了，至此，HTTPS中的第一次HTTP请求结束。
5. 客户端会发起HTTPS中的第二个HTTP请求，将加密之后的客户端密钥发送给服务器。
6. 服务器接收到客户端发来的密文之后，会用自己的私钥对其进行非对称解密，解密之后的明文就是客户端密钥，然后用客户端密钥对数据进行对称加密，这样数据就变成了密文。
7. 然后服务器将加密后的密文发送给客户端。
8. 客户端收到服务器发送来的密文，用客户端密钥对其进行对称解密，得到服务器发送的数据。这样HTTPS中的第二个HTTP请求结束，整个HTTPS传输完成。

一共是两次非对称加密+一次对称加密。

14、HTTPS握手。

HTTPS有四次握手，具体如上图所示。

15、什么是分块传输。

通常情况下，HTTP的响应消息体 message body 是作为整包发送到客户端的，用头『Content-Length』 来表示消息体的长度， 这个长度对客户端非常重要，因为对于持久连接TCP并不会在请求完立马结束，而是可以发送多次请求/响应，客户端需要知道哪个位置才是响应消息的结束，以及后续响应的开始，因此Content-Length显得尤为重要，服务端必须精确地告诉客户端 message body 的长度是多少， 如果Content-Length 比实际返回的长度短，那么就会造成内容截断，如果比实体内容长，客户端就一直处于pendding状态，直到所有的 message body 都返回了请求才结束。

分块传输编码：它把数据分解为一系列的数据块，并以多个块发送给客户端，服务器发送数据时不再需要预先告诉客户端发送内容的总大小，只需在响应头里面添加Transfer-Encoding: chunked，以此来告诉浏览器我使用的是分块传输编码，这样就不需要 Content-Length 了。

分块编码传输优点：

• HTTP分块传输编码允许服务器为动态生成的内容维持HTTP持久链接。通常，持久链接需要服务器在开始发送消息体前发送Content-Length消息头字段，但是对于动态生成的内容来说，在内容创建完之前是不可知的。
• 分块传输编码允许服务器在最后发送消息头字段。对于那些头字段值在内容被生成之前无法知道的情形非常重要，例如消息的内容要使用散列进行签名，散列的结果通过HTTP消息头字段进行传输。没有分块传输编码时，服务器必须缓冲内容直到完成后计算头字段的值并在发送内容前发送这些头字段的值。
• HTTP服务器有时使用压缩（gzip）以缩短传输花费的时间。分块传输编码可以用来分隔压缩对象的多个部分。在这种情况下，块不是分别压缩的，而是整个负载进行压缩，压缩的输出使用本文描述的方案进行分块传输。在压缩的情形中，分块编码有利于一边进行压缩一边发送数据，而不是先完成压缩过程以得知压缩后数据的大小。

参考连接：HTTP中的分块传输编码是怎么回事？

16、Session和cookie的区别。

Session和cookie都是实现对话管理的方案。主要区别在于：

• Session在服务端，Cookie存储在客户端。
• Session的运行依赖Session ID，而Session ID是存在Cookie中的，也就是说，如果浏览器禁用了Cookie，同时Session也会失效，但是，可以通过其他方式实现，比如在url参数中传递Session ID。
• Tomcat中的Session是存在服务器内存中，不过也可以通过特殊的方式做持久化处理（memcache，redis），方便Session共享。另外，PHP中的Session是存在文件中的。
• cookie不是很安全，别人可以分析存放在本地的cookie并进行cookie欺骗，考虑到安全应当使用session。

参考连接：Session是怎么实现的？存储在哪里？

17、用户在浏览器输入一个URL并回车，这个过程涉及到哪些网络协议，请具体描述。

浏览器输入一个URL并回车：

1. 首先进行域名解析，浏览器搜索自己的DNS缓存，缓存中维护一张域名与IP地址的对应表。若没有，则搜索操作系统的DNS缓存；若没有，则将域名发送至本地域名服务器（递归查询方式），本地域名服务器查询自己的DNS缓存，查找成功则返回结果，否则，本地的DNS服务器向根域名服务器发出查询请求，根域名服务器告知该域名的一级域名服务器，然后本地服务器给该一级域名服务器发送查询请求，然后依次类推直到查询到该域名的IP地址。DNS服务器是基于UDP的，因此会用到UDP协议。
2. 得到IP地址以后，浏览器就要与服务器建立一个HTTP连接，因此要用到HTTP协议。HTTP生成一个GET请求报文。
3. 接下来到了传输层，选择传输协议，TCP或者UDP，TCP是可靠的传输控制协议，对HTTP请求进行封装，加入了端口号等信息。
4. 然后到了网络层，通过IP协议将IP地址封装为IP数据报；然后此时会用到ARP协议，主机发送信息时将包含目标IP地址的ARP请求广播到网络上的所有主机，并接收返回消息，以此确定目标的物理地址，找到目的MAC地址。
5. 接下来到了数据链路层，把网络层交下来的IP数据报添加首部和尾部，封装为MAC帧，现在根据目的mac开始建立TCP连接，三次握手，接收端在收到物理层上交的比特流后，根据首尾的标记，识别帧的开始和结束，将中间的数据部分上交给网络层，然后层层向上传递到应用层。
6. 服务器响应请求并请求客户端要的资源，传回给客户端。
7. 断开TCP连接，浏览器对页面进行渲染呈现给客户端。

18、一致性哈希问题。

在解决分布式系统中负载均衡的问题时候可以使用Hash算法让固定的一部分请求落到同一台服务器上，这样每台服务器固定处理一部分请求（并维护这些请求的信息），起到负载均衡的作用。但是普通的余数hash（hash(比如用户id)%服务器机器数）算法伸缩性很差，当新增或者下线服务器机器时候，用户id与服务器的映射关系会大量失效。一致性hash则利用hash环对其进行了改进。

一致性hash主要是建立起一个在[0,2^{32-1]分布的哈希环。根据资源的Key的Hash值（也是分布为[0,2}32-1]）H1，在环上顺时针的找到离 H1最近（第一个大于或等于 H1）的一个节点，就建立了资源和节点的映射关系。

另外，当一致性哈希算法在服务节点太少时，容易因为节点分布不均匀而造成数据倾斜问题。为了解决这个问题，一致性哈希算法引入了虚拟节点机制，即对每一个服务节点计算多个哈希，每个计算结果位置都放置一个此服务节点，称为虚拟节点。具体做法可以在服务器ip或主机名的后面增加编号来实现。

具体信息建议直接去看文章：深入浅出一致性Hash原理和一致性哈希(hash)算法

19、ETag的含义和作用。

ETag是Entity Tag的缩写，中文译过来就是实体标签的意思。在HTTP1.1协议中的其实就是请求Head中的一个属性。比如

HTTP/1.1 200 OK
Date: Mon, 23 May 2005 22:38:34 GMT
Content-Type: text/html; charset=UTF-8
Content-Encoding: UTF-8
Content-Length: 138
Last-Modified: Wed, 08 Jan 2019 23:11:55 GMT
Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
ETag: "3f80f-1b6-3e1cb03b"
Accept-Ranges: bytes
Connection: close

ETag是HTTP1.1中才加入的一个属性，类似于资源指纹，用来帮助服务器控制Web端的缓存验证。它的原理是这样的，当浏览器请求服务器的某项资源（A）时，服务器根据A算出一个哈希值（3f80f-1b6-3e1cb03b）并通过ETag返回给浏览器，浏览器把“3f80f-1b6-3e1cb03b”和A同时缓存在本地，当下次再次向服务器请求A时，会通过类似If-None-Match: "3f80f-1b6-3e1cb03b"的请求头把Etag信息发送给服务器，服务器再次计算A的哈希值并和浏览器请求的值作比较，如果发现A发生了变化就把A返回给浏览器（200），如果发现A没有变化，就给浏览器返回一个304未修改。这样通过控制浏览器端的缓存，可以节省服务器的带宽，因为服务器不需要每次都把全量数据返回给客户端。

注意的是，HTTP并没有指定如何生成ETag，哈希是比较理想的选择。但在一些服务器情况下，并不会用哈希来计算ETag，因为这会严重浪费服务器资源，所以很多时候通过资源的版本或者修改时间来生成ETag。如果通过资源修改时间来生成ETag，那么效果和HTTP协议里面的另外一个控制属性(Last-Modified)就雷同了，使用 Last-Modified 的问题在于它的精度在秒(s)的级别，比较适合不太敏感的静态资源。

20、转发和重定向的区别。

转发是指RequestDispatcher.forward，而重定向是指HttpServletResponse.sendRedirect。主要区别如下：

• forword方法只能将请求转发给同一个WEB应用中的组件，而sendRedirect方法不仅可以重定向到当前应用程序的其他资源，还可以重定向到同一个站点上的其他应用程序中的资源。
• forword方法的请求转发过程结束后，浏览器地址栏保持初始的URL地址不变；而sendRedirect方法重定向的访问过程结束后，浏览器地址栏中显示的URL会发现改变，由初始的URL地址变成重定向的目标URL。
• forword方法服务器端内部将请求转发给另外一个资源，浏览器只知道发出了请求并得到了响应结果，并不知道在服务器程序内部发生了转发行为；而sendRedirect方法对浏览器的请求直接作出响应，响应的结果就是告诉浏览器去重新发出对另外一个URL的访问请求。
• forword方法的调用者与被调用者之间共享相同的request对象和response对象，它们属于同一个访问请求和响应过程；而sendRedirect方法调用者与被调用者使用各自的request对象和response对象，它们属于两个独立的访问请求和响应过程。

注意：

• 转发比重定向快，因为重定向需要经过客户端，而转发没有。
• 使用重定向不太方便的地方是，使用它无法将值轻松地传递给目标页面。而采用转发，则可以简单地将属性添加到Model,使得目标视图可以轻松访问。

重定向的使用场景：当提交产品表单的时候，执行保存的方法将会被调用，并执行相应的动作；这在一个真实的应用程序中，很有可能将表单中的所有产品信息加入到数据库中。但是如果在提交表单后，重新加载页面，执行保存的方法就很有可能再次被调用。同样的产品信息就将可能再次被添加，为了避免这种情况，提交表单后，你可以将用户重定向到一个不同的页面，这样的话，这个网页任意重新加载都没有副作用。

21、HTTP2.0带来的变化。

HTTP2.0和HTTP1.x相比的新特性为：

• 新的二进制格式，HTTP1.x的解析是基于文本。基于文本协议的格式解析存在天然缺陷，文本的表现形式有多样性，要做到健壮性考虑的场景必然很多，二进制则不同，只认0和1的组合。基于这种考虑HTTP2.0的协议解析决定采用二进制格式，实现方便且健壮。
• 多路复用，即连接共享，做到同一个连接并发处理多个请求，而且并发请求的数量比HTTP1.1大了好几个数量级。
• 多个请求可以同时在一个连接上并行执行，某个请求任务耗时严重，不会影响到其他连接的正常执行。这块和HTTP1.1的长连接有区别，长连接是串行化执行多个请求。
• 首部压缩，HTTP1.1不支持header数据的压缩，HTTP2.0使用HPACK算法对header的数据进行压缩，这样数据体积小了，在网络上传输就会更快。
• 服务器推送，当我们对支持HTTP2.0的web server请求数据的时候，服务器会顺便把一些客户端需要的资源（比如css、js文件）一起推送到客户端，免得客户端再次创建连接发送请求到服务器端获取。这种方式非常合适加载静态资源。还没有收到浏览器的请求，服务器就把各种资源推送给浏览器了。

22、SSH相关。

SSH是一种协议标准，其目的是实现远程登录以及其他安全网络服务。SSH和telnet、ftp等协议主要的区别在于安全性。

SSH中用了非对称加密方式。但与HTTPS可以通过CA认证不同，SSH的公钥和密钥都是自己生成的，没法公证，只能通过client端自己对公钥进行确认。一般是在第一次登陆的过程时实现。具体过程如下。

23、网络模型。

自上而下分别是：

• 应用层（数据）：确定进程之间通信的性质以满足用户需要以及提供网络与用户应用。
• 表示层（数据）：主要解决用户信息的语法表示问题，如加密解密。在表示层进行代码/编码转换。
• 会话层（数据）：提供包括访问验证和会话管理在内的建立和维护应用之间通信的机制，如服务器验证用户登录便是由会话层完成的。在会话层封装会话控制参数。
• 传输层（段）：实现网络不同主机上用户进程之间的数据通信，可靠与不可靠的传输，传输层的错误检测，流量控制等。在传输层封装传输控制。
• 网络层（包）：提供逻辑地址（IP）、选路，数据从源端到目的端的传输。在网络层加上逻辑寻址地址。
• 数据链路层（帧）：将上层数据封装成帧，用MAC地址访问媒介，错误检测与修正。在数据链路层封装基于MAC的信息。
• 物理层（比特流）：设备之间比特流的传输，物理接口，电气特性等。在物理层连接到线缆系统进行实际传递。

24、网络层的ARP协议工作原理。

网络层的 ARP 协议完成了 IP 地址与物理地址的映射。

首先，每台主机都会在自己的 ARP 缓冲区中建立一个 ARP 列表，以表示 IP 地址和 MAC 地址的对应关系。

当源主机需要将一个数据包要发送到目的主机时，会首先检查自己 ARP 列表中是否存在该 IP 地址对应的 MAC 地址：

• 如果有，就直接将数据包发送到这个 MAC 地址。
• 如果没有，就向本地网段发起一个ARP请求的广播包，查询此目的主机对应的 MAC 地址。

25、对于TCP连接，客户端不断进行请求链接会怎么样？

服务器端准备为每个请求创建一个链接，并向其发送确认报文，然后等待客户端进行确认后创建。如果此时客户端一直不确认，会造成 SYN 攻击，即：SYN 攻击，英文为 SYN Flood ，是一种典型的 DoS/DDoS 攻击。

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

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

对于SYN攻击，只能预防，没有彻底根治的办法，除非不使用 TCP 。方法主要如下：

• 限制同时打开SYN半链接的数目。
• 缩短SYN半链接的超时时间。
• 关闭不必要的服务。
• 增加半链接数据。
• 过滤网关防护。

26、TCP和UDP的区别。

TCP和UDP都属于传输层协议，它们之间的区别在于：

• TCP 是面向连接的；UDP 是无连接的。
• TCP 是可靠的；UDP 是不可靠的。
• TCP 只支持点对点通信；UDP 支持一对一、一对多、多对一、多对多的通信模式。
• TCP 是面向字节流的；UDP 是面向报文的。
• TCP 有拥塞控制机制；UDP 没有拥塞控制，适合媒体通信。
• TCP 首部开销(20 个字节)，比 UDP 的首部开销(8 个字节)要大。

27、TCP中RST标志位的作用。

TCP报文中一共有6个标志位，分别为：URG/ACK/PSH/RST/SYN/FIN。

• SYN：TCP三次握手时，如果A是发起端，则A就对服务器发送一个SYN报文，表示想要建立连接。
• ACK：收到数据或者请求后发送响应时发送ACK报文。
• RST：关闭异常连接。
• FIN：TCP四次挥手时，表示关闭连接。
• PSH：发送端需要发送一段数据，这个数据需要接收端一收到就进行向上交付。而接收端在收到PSH标志位有效的数据时，迅速将数据交付给应用层，所以PSH又叫做急迫比特。
• URG：紧急指针，意思为URG位有效的数据包，是一个紧急需要处理的数据包，需要接收端在接收到之后迅速处理。

RST标志位应用场景如下。
TCP正常关闭连接的时候使用FIN，但是如果是关闭异常连接，则使用RST，发送RST包。与FIN包存在两点不同：

• RST不必等缓冲区的包都发出去，直接就丢弃缓冲区的包去发送RST包，而FIN需要先处理完缓冲区的包才行。
• 接收端收到RST包之后，不需要发送ACK包进行确认，而接收端接收到FIN包的时候需要ACK包应答。

28、TCP和UDP报文段的首部格式。

TCP报文分为首部和数据两部分，TCP的全部功能体现在首部的各字段作用上。

首部固定部分各字段的意义。

• 源端口和目的端口： 各占两个字节。
• 序号： 占四个字节。
• 确认号： 占四个字节。
• 数据偏移： 占四个字节，指出TCP报文段的数据起始处距离TCP报文段的起始处有多远。
• 保留： 占六个字节，保留为今后使用，但目前应置为0。

还有六个控制位，就在27题里讲述了。TCP示意图如下所示。

UDP报文首部相对简单。主要分为四部分：

• 源端口和目的端口。
• 数据包长度。
• 校验值。