计算机网络——大厂面试问题集合

摘和 

本博文主要收集面试过程中涉及到计算机网络的面试题目与解答。以下博文的问题都来源互联网中收集的面试题目。其中有些的问题的解答可能存在错误。还请大家帮忙指正。

计算机网络知识脑图

计算机网络——计算机网络知识脑图_庄小焱的博客-CSDN博客_计算机网络面试题总结

计算机网络大厂面试问题集合

计算机网络——大厂面试问题集合_庄小焱的博客-CSDN博客

计算机网络基础知识

计算机网络——网络基础知识_庄小焱的博客-CSDN博客_数据转发服务器

IP相关基础原理

计算机网络——IP协议基础原理_庄小焱的博客-CSDN博客_ip网络技术

HTTP协议原理

计算机网络——HTTP协议原理_庄小焱的博客-CSDN博客_http协议原理

HTTP的优化方式

计算机网络——HTTP的优化方式_庄小焱的博客-CSDN博客

HTTPS协议原理

计算机网络——HTTPS协议原理_庄小焱的博客-CSDN博客_https协议原理

HTTPS的优化方式

计算机网络——HTTPS的优化方式_庄小焱的博客-CSDN博客

TCP可靠性传输原理

计算机网络——TCP可靠性传输原理_庄小焱的博客-CSDN博客_tcp的可靠性是如何实现的

TCP/IP三次握手四次挥手原理

计算机网络——HTTP的三次握手与四次挥手原理_庄小焱的博客-CSDN博客_三次握手和四次挥手原理

TCP的优化方式

计算机网络——TCP的优化方式_庄小焱的博客-CSDN博客_tcp协议优化技术

DNS协议（域名解析）原理

计算机网络——DNS协议（域名解析）原理_庄小焱的博客-CSDN博客_计算机网络dns

ARP协议(地址解析)原理

计算机网络——ARP协议(地址解析)原理_庄小焱的博客-CSDN博客_地址解析协议的工作原理

ARQ协议(自动重传请求)原理

计算机网络——ARQ协议(自动重传请求)原理_庄小焱的博客-CSDN博客_连续arq协议的原理

DHCP协议原理

计算机网络——DHCP（动态获取IP）原理_庄小焱的博客-CSDN博客_计算机网络dhcp

NAT协议原理

计算机网络——NAT协议（网络地址转换）原理_庄小焱的博客-CSDN博客

ICMP/IGMP协议原理

计算机网络——ICMP/IGMP协议原理_庄小焱的博客-CSDN博客_计算机网络igmp

HTTP网络访问全流程

计算机网络——HTTP网络访问全流程_庄小焱的博客-CSDN博客_网络访问流程

虚拟网路模型原理

计算机网络——虚拟网路模型原理_庄小焱的博客-CSDN博客

其他网络知识

计算机网络——select/poll/epoll底层原理_庄小焱的博客-CSDN博客

计算机网络——cookie/session/token原理_庄小焱的博客-CSDN博客

计算机网络——网络通信加密原理_庄小焱的博客-CSDN博客_网络通信加密

计算机网络——GRPC通信原理_庄小焱的博客-CSDN博客_grpc原理

计算机网络——tcpdump/Wireshark抓包实战_庄小焱的博客-CSDN博客_网络抓包

计算机网络——TCP抓包连接实战_庄小焱的博客-CSDN博客_tcp全连接和半连接

一、TCP/IP问题

TCP 协议如何保证可靠传输？

• 应用数据被分割成 TCP 认为最适合发送的数据块。

• TCP 给发送的每一个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层。

• 校验和： TCP 将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP 将丢弃这个报文段和不确认收到此报文段。

• TCP 的接收端会丢弃重复的数据。

• 流量控制： TCP 连接的每一方都有固定大小的缓冲空间，TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。TCP 使用的流量控制协议是可变大小的滑动窗口协议。 （TCP 利用滑动窗口实现流量控制）

• 拥塞控制： 当网络拥塞时，减少数据的发送。

• ARQ协议： 也是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组。

• 超时重传： 当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。

ARQ协议是什么？

超时重传的原理是什么？

• 超时重传
• 快速重传

发生超时重传的拥塞发⽣算法 ：当发⽣了超时重传，则就会使用拥塞发⽣算法。 这个时候，ssthresh 和 cwnd 的值会发⽣变化： ssthresh 设为 cwnd/2 ， cwnd 重置为 1。接着，就重新开始慢启动，慢启动是会突然减少数据流的。这真是⼀旦超时重传，⻢上回到解放前。但是这种方式太激进了，反应也很强烈，会造成网络卡顿。

发⽣快速重传的拥塞发⽣算法： 当接收方发现丢了⼀个中间包的时候，发送三次前⼀个包的 ACK，于是发送端就会快速地重传，不必等待超时再重传。

二、HTTP/HTTPS问题

HTTP 常用的状态码及含义？

• 1xx：接受的请求正在处理 （信息性状态码）

• 2xx：表示请求正常处理完毕 （成功状态码）

• 3xx：表示重定向状态，需要重新请求 （重定向状态码）

• 4xx：服务器无法处理请求 （客户端错误状态码）

• 5xx：服务器处理请求出错 （服务端错误状态码）

• 101 切换请求协议，从 HTTP 切换到 WebSocket

• 200 请求成功，表示正常返回信息。

• 301 永久重定向，会缓存

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

• 400 请求错误

• 403 服务器禁止访问

• 404 找不到与 URI 相匹配的资源。

• 500 Internal Server Error与 400 类型，是个笼统通⽤的错误码，服务器发⽣了什么错误，我们并不知道。
• 501 Not Implemented表示客户端请求的功能还不⽀持，类似“即将开业，敬请期待”的意思。
• 502 Bad Gateway通常是服务器作为⽹关或代理时返回的错误码，表示服务器⾃身⼯作正常，访问后端服务器 发⽣了错误。
• 503 Service Unavailable表示服务器当前很忙，暂时⽆法响应服务器，类似“⽹络服务正忙，请稍后在试”的意思

HTTP请求的方式有几种？

1. GET：获取资源，当前网络中绝大部分使用的都是 GET；
2. HEAD：获取报文首部，和 GET 方法类似，但是不返回报文实体主体部分；
3. POST：传输实体主体
4. PUT：上传文件，由于自身不带验证机制，任何人都可以上传文件，因此存在安全性问题，一般不使用该方法。
5. PATCH：对资源进行部分修改。PUT 也可以用于修改资源，但是只能完全替代原始资源，PATCH 允许部分修改。
6. OPTIONS：查询指定的 URL 支持的方法；
7. CONNECT：要求在与代理服务器通信时建立隧道。使用 SSL（Secure Sockets Layer，安全套接层）和 TLS（Transport Layer Security，传输层安全）协议把通信内容加密后经网络隧道传输。
8. TRACE：追踪路径。服务器会将通信路径返回给客户端。发送请求时，在 Max-Forwards 首部字段中填入数值，每经过一个服务器就会减 1，当数值为 0 时就停止传输。通常不会使用 TRACE，并且它容易受到 XST 攻击（Cross-Site Tracing，跨站追踪）。

HTTP和 HTTPS的区别？

1. 端口不同：HTTP 和 HTTPS 使用的是完全不同的连接方式，用的端口也不一样，前者是 80，后者是 443；
2. 开销：HTTPS 协议需要到 CA 申请证书，一般免费证书很少，需要交费；
3. 资源消耗：HTTP 是超文本传输协议，信息是明文传输，HTTPS 则是具有安全性的 ssl 加密传输协议，需要消耗更多的 CPU 和内存资源；
4. 安全性：HTTP 的连接很简单，是无状态的；HTTPS 协议是由 TSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，比 HTTP 协议安全。

Http1.0,Http1.1和Http2.0的区别

• Http1.0短连接（100张图，100次tcp握手和挥手)
• Http1.1长连接(100张图,1次tcp握手挥手)
• Http2.0长连接+io多路复用模型(五大模型之一)

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

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

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

RPC与HTTPS的区别？

HTTP/1.1 相比 HTTP/1.0 提高了什么性能？

1. 长连接 : 在HTTP/1.0中，默认使用的是短连接，也就是说每次请求都要重新建立一次连接。HTTP 是基于TCP/IP协议的,每一次建立或者断开连接都需要三次握手四次挥手的开销，如果每次请求都要这样的话，开销会比较大。因此最好能维持一个长连接，可以用个长连接来发多个请求。HTTP 1.1起，默认使用长连接 ,默认开启Connection： keep-alive。 HTTP/1.1的持续连接有非流水线方式和流水线方式 。流水线方式是客户在收到HTTP的响应报文之前就能接着发送新的请求报文。与之相对应的非流水线方式是客户在收到前一个响应后才能发送下一个请求。

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

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

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

HTTP/1.1 还有那些性能瓶颈：

1. 请求 / 响应头部（Header）未经压缩就发送，首部信息越多延迟越大。只能压缩 Body 的部分。
2. 发送冗长的首部。每次互相发送相同的首部造成的浪费较多。
3. 服务器是按请求的顺序响应的，如果服务器响应慢，会招致客户端一直请求不到数据，也就是队头阻塞。
4. 没有请求优先级控制。
5. 请求只能从客户端开始，服务器只能被动响应。

HTTP/1.1 的性能瓶颈，HTTP/2做了什么优化？

HTTP/2 协议是基于 HTTPS 的，所以 HTTP/2 的安全性也是有保障的。那 HTTP/2 相比 HTTP/1.1 性能上的改进：

1. 头部压缩：HTTP/2 会压缩头（Header），如果你同时发出多个请求，他们的头是一样的或是相似的，那么，协议会帮你消除重复的部分。
2. 二进制格式：HTTP/2 不再像 HTTP/1.1 里的纯文本形式的报文，而是全面采用了二进制格式，头信息和数据体都是二进制，并且统称为帧（frame）：头信息帧和数据帧。
3. 数据流：每个请求或回应的所有数据包，称为一个数据流（Stream）。每个数据流都标记着一个独一无二的编号，其中规定客户端发出的数据流编号为奇数， 服务器发出的数据流编号为偶数。
4. 多路复用：HTTP/2 是可以在一个连接中并发多个请求或回应，而不用按照顺序一一对应。

TCP/IP的三次握手和四次挥手？

三次握手流程：

1. 第一次握手：建立连接时，客户端发送syn包（syn=x）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）。
2. 第二次握手：服务器收到syn包，必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN包（syn=y），即SYN+ACK包，此时服务器进入SYN_RECV状态；
3. 第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=y+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。

为什么是三次握手？不是两次、四次？

三次握手才可以阻⽌冲重复历史连接的初始化（主要原因）

⽹络环境是错综复杂的，往往并不是如我们期望的⼀样，先发送的数据包，就先到达⽬标主机，反⽽它很骚，可能 会由于⽹络拥堵等乱七⼋糟的原因，会使得旧的数据包，先到达⽬标主机，那么这种情况下 TCP 三次握⼿是如何避免的呢？

客户端连续发送多次SYN 建⽴连接的报⽂，在网络拥堵情况下：

• ⼀个旧 SYN 报⽂⽐最新的 SYN 报⽂早到达了服务端；
• 那么此时服务端就会回⼀个 SYN + ACK 报⽂给客户端；
• 客户端收到后可以根据⾃身的上下⽂，判断这是⼀个历史连接（序列号过期或超时），那么客户端就会发送 RST 报⽂给服务端，表示中⽌这⼀次连接。
• 如果是两次握⼿连接，就不能判断当前连接是否是历史连接，三次握⼿则可以在客户端（发送⽅）准备发送第三次 报⽂时，客户端因有⾜够的上下⽂来判断当前连接是否是历史连接：
• 如果是历史连接（序列号过期或超时），则第三次握⼿发送的报⽂是 RST 报⽂，以此中⽌历史连接；
• 如果不是历史连接，则第三次发送的报⽂是 ACK 报⽂，通信双⽅就会成功建⽴连接； 所以，TCP 使⽤三次握⼿建⽴连接的最主要原因是防⽌历史连接初始化了连接。

三次握手才可以同步双方的初始序列号

TCP协议的通信双方，都必须维护⼀个序列号， 序列号是可靠传输的⼀个关键因素，它的作⽤：

• 接收⽅可以去除重复的数据；
• 接收⽅可以根据数据包的序列号按序接收；
• 可以标识发送出去的数据包中， 哪些是已经被对⽅收到的

序列号在 TCP 连接中占据着常重要的作⽤，所以当客户端发送携带初始序列号的SYN报⽂时候，需要服务端回⼀个ACK 应答报⽂，表示客户端的 SYN 报⽂已被服务端成功接收，那当服务端发送初始序 列号给客户端的时候，依然也要得到客户端的应答回应，这样⼀来⼀回，才能确保双⽅的初始序列号能被可靠的同步。

四次握⼿其实也能够可靠的同步双⽅的初始化序号，但由于第⼆步和第三步可以优化成⼀步，所以就成了三次握 ⼿。 而两次握⼿只保证了⼀⽅的初始序列号能被对⽅成功接收，没办法保证双⽅的初始序列号都能被确认接收。

三次握手才可以避免资源浪费

如果只有两次握⼿，当客户端的SYN 请求连接在⽹络中阻塞，客户端没有接收到 ACK 报⽂，就会重新发送SYN ，由于没有第三次握⼿，服务器不清楚客户端是否收到了⾃⼰发送的建⽴连接的 ACK 确认信号，所以 每收到⼀个SYN 就只能先主动建⽴⼀个连接，这会造成什么情况呢？ 如果客户端的 SYN 阻塞了，重复发送多次SYN报⽂，那么服务器在收到请求后就会建⽴多个冗余的⽆效链 接，造成不必要的资源浪费。

四次挥手的流程：

1. 客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
2. 服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
3. 客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
4. 服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
5. 客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
6. 服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

为什么需要四次了

• 关闭连接时，客户端向服务端发送 FIN 时，仅仅表示客户端不再发送数据了但是还能接收数据。
• 服务器收到客户端的 FIN 报⽂时，先回⼀个 ACK 应答报⽂，⽽服务端可能还有数据需要处理和发送，等服务端不再发送数据时，才发送 FIN 报⽂给客户端来表示同意现在关闭连接。 从上⾯过程可知，服务端通常需要等待完成数据的发送和处理，所以服务端的ACK和FIN⼀般都会分开发送，从⽽⽐三次握⼿导致多了⼀次。

对于FIN_WAIT_2，CLOSE_WAIT状态和TIME_WAIT状态？你知道多少?

FIN_WAIT_2：

• 半关闭状态。

• 发送断开请求一方还有接收数据能力，但已经没有发送数据能力。

CLOSE_WAIT状态：

• 被动关闭连接一方接收到FIN包会立即回应ACK包表示已接收到断开请求。

• 被动关闭连接一方如果还有剩余数据要发送就会进入CLOSED_WAIT状态。

TIME_WAIT状态：

• 又叫2MSL等待状态。

• 如果客户端直接进入CLOSED状态，如果服务端没有接收到最后一次ACK包会在超时之后重新再发FIN包，此时因为客户端已经CLOSED，所以服务端就不会收到ACK而是收到RST。所以TIME_WAIT状态目的是防止最后一次握手数据没有到达对方而触发重传FIN准备的。

• 在2MSL时间内，同一个socket不能再被使用，否则有可能会和旧连接数据混淆（如果新连接和旧连接的socket相同的话）。

为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？

虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是网络是不可靠的，有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。

在Client发送出最后的ACK回复，但该ACK可能丢失。Server如果没有收到ACK，将不断重复发送FIN片段。所以Client不能立即关闭，它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。

Client会设置一个计时器，等待2MSL的时间。如果在该时间内再次收到FIN，那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。

为什么客户端发出第四次挥手的确认报文后要等2MSL的时间才能释放TCP连接？

这里同样是要考虑丢包的问题，如果第四次挥手的报文丢失，服务端没收到确认ack报文就会重发第三次挥手的报文，这样报文一去一回最长时间就是2MSL，所以需要等这么长时间来确认服务端确实已经收到了。

HTTPS采用的加密方式有哪些？是对称还是非对称？

HTTPS 采用混合的加密机制，使用非对称密钥加密用于传输对称密钥来保证传输过程的安全性，之后使用对称密钥加密进行通信来保证通信过程的效率。

确保传输安全过程（其实就是rsa原理）：

1. Client给出协议版本号、一个客户端生成的随机数（Client random），以及客户端支持的加密方法。

2. Server确认双方使用的加密方法，并给出数字证书、以及一个服务器生成的随机数（Server random）。

3. Client确认数字证书有效，然后生成呀一个新的随机数（Premaster secret），并使用数字证书中的公钥，加密这个随机数，发给Server。

4. Server使用自己的私钥，获取Client发来的随机数（Premaster secret）。

5. Client和Server根据约定的加密方法，使用前面的三个随机数，生成”对话密钥”（session key），用来加密接下来的整个对话过程。

为什么有的时候刷新页面不需要重新建立SSL 连接？

TCP连接有的时候会被浏览器和服务端维持一段时间，TCP不需要重新建立，SSL自然也会用之前的。

HTTP如何禁用缓存？如何确认缓存？

HTTP/1.1 通过 Cache-Control 首部字段来控制缓存。

禁止进行缓存：no-store 指令规定不能对请求或响应的任何一部分进行缓存。

Cache-Control: no-store

强制确认缓存：no-cache 指令规定缓存服务器需要先向源服务器验证缓存资源的有效性，只有当缓存资源有效时才能使用该缓存对客户端的请求进行响应。

Cache-Control: no-cache

三、TCP的可靠性传输问题

拥塞控制原理听说过吗？

拥塞控制目的是防止数据过多注网络中导致网络资源（路由器、交换机等）过载。因为拥塞控制涉及网络链路全局，所以属于全局控制。

TCP拥塞控制算法：

• 慢启动
• 拥塞避免
• 拥塞发⽣
• 快速恢复

慢启动：TCP 在刚建⽴连接完成后，⾸先是有个慢启动的过程，这个慢启动的意思就是⼀点⼀点的提⾼发送数据包的数量， 如果⼀上来就发⼤量的数据，这不是会造成网络阻塞嘛？ 慢启动的算法就是：当发送⽅每收到⼀个 ACK，拥塞窗⼝cwnd的⼤⼩就会加1。

那慢启动涨到什么时候是个头呢？

有⼀个叫慢启动⻔限 ssthresh（slow start threshold）状态变量。

• 当 cwnd < ssthresh 时，使⽤慢启动算法。
• 当 cwnd >= ssthresh 时，就会使⽤拥塞避免算法。

拥塞避免：当拥塞窗⼝ cwnd 超过慢启动⻔限 ssthresh 就会进⼊拥塞避免算法。 ⼀般来说 ssthresh 的大小是 65535 字节，那么进⼊拥塞避免算法后，它的规则是：每当收到⼀个 ACK 时，cwnd 增加 1/cwnd。

拥塞避免算法就是将原本慢启动算法的指数增⻓变成了线性增长，还是增长阶段，但是增长速度缓慢了⼀些。 就这么⼀直增⻓着后，网络就会慢慢进⼊了拥塞的状况了，于是就会出现丢包现象，这时就需要对丢失的数据包进⾏重传。 当触发了重传机制，也就进⼊了拥塞发⽣算法。

拥塞发⽣算法：当⽹络出现拥塞，也就是会发⽣数据包重传，重传机制主要有两种 ：

• 超时重传
• 快速重传

发生超时重传的拥塞发⽣算法 ：当发⽣了超时重传，则就会使用拥塞发⽣算法。 这个时候，ssthresh 和 cwnd 的值会发⽣变化： ssthresh 设为 cwnd/2 ， cwnd 重置为 1。接着，就重新开始慢启动，慢启动是会突然减少数据流的。这真是⼀旦超时重传，⻢上回到解放前。但是这种方式太激进了，反应也很强烈，会造成网络卡顿。

发⽣快速重传的拥塞发⽣算法： 当接收方发现丢了⼀个中间包的时候，发送三次前⼀个包的 ACK，于是发送端就会快速地重传，不必等待超时再重传。

TCP 认为这种情况不严重，因为⼤部分没丢，只丢了⼀⼩部分，则 ssthresh 和 cwnd 变化如下：

• cwnd = cwnd/2 ，也就是设置为原来的⼀半;
• ssthresh = cwnd ;
• 进⼊快速恢复算法

快速重传和快速恢复算法⼀般同时使⽤，快速恢复算法是认为，你还能收到3个重复ACK说明⽹络也不那么糟糕，所以没有必要像RTO超时那么强烈。

拥塞窗口：cwnd = ssthresh + 3 （ 3 的意思是确认有 3 个数据包被收到了）；重传丢失的数据包； 如果再收到重复的ACK，那么cwnd 增加 1； 如果收到新数据的 ACK 后，把 cwnd 设置为第⼀步中的 ssthresh 的值，原因是该 ACK 确认了新的数据，说 明从 duplicated ACK 时的数据都已收到，该恢复过程已经结束，可以回到恢复之前的状态了，也即再次进⼊拥塞避免状态；

四、网络协议问题

网络层常见协议？可以说一下吗？

协议名称作用其他IP协议IP协议不但定义了数据传输的基本单元和基本格式，还定义了数据传输的方法和路由选择网际协议ICMP协议一个错误侦测与信息回传机制，检测网络连接状态，也是确保连接的准确性。超文本传输协议RIP协议使用跳数来衡量目标到路由的距离路由信息协议IGMP协议实现组广播和广播通信Internet组管理协议

 DNS 的解析过程

1. 客户端⾸先会发出⼀个 DNS 请求，问 www.server.com 的 IP 是啥，并发给本地 DNS 服务器（也就是客户端 的 TCP/IP 设置中填写的 DNS 服务器地址）。
2. 本地域名服务器收到客户端的请求后，如果缓存⾥的表格能找到 www.server.com，则它直接返回 IP 地址。 如果没有，本地 DNS 会去问它的根域名服务器：“⽼⼤， 能告诉我 www.server.com 的 IP 地址吗？” 根域名 服务器是最⾼层次的，它不直接⽤于域名解析，但能指明⼀条道路。
3. 根 DNS 收到来⾃本地 DNS 的请求后，发现后置是 .com，说：“www.server.com 这个域名归 .com 区域管 理”，我给你 .com 顶级域名服务器地址给你，你去问问它吧。”
4. 本地 DNS 收到顶级域名服务器的地址后，发起请求问“⽼⼆， 你能告诉我 www.server.com 的 IP 地址吗？”
5. 顶级域名服务器说：“我给你负责 www.server.com 区域的权威 DNS 服务器的地址，你去问它应该能问到”。
6. 本地 DNS 于是转向问权威 DNS 服务器：“⽼三，www.server.com对应的IP是啥呀？” server.com 的权威 DNS 服务器，它是域名解析结果的原出处。为啥叫权威呢？就是我的域名我做主。
7. 权威 DNS 服务器查询后将对应的 IP 地址 X.X.X.X 告诉本地 DNS。
8. 本地 DNS 再将 IP 地址返回客户端并缓存在本地的DNS服务器中以便于下一次访问，客户端和⽬标建⽴连接。

 WebSocket 与 Socket 的区别？

• Socket 其实就是等于 IP 地址 + 端口 + 协议。Socket 一个是网编编程的标准接口，而 WebSocket则是应用层通信协议。
• WebSocket是一个持久化的协议，它是伴随H5而出的协议，用来解决http不支持持久化连接的问题。

五、其他网络问题

七层网络模型

• 7-应用层 -> 网络流程应用（表示的是用户界面，例如Telnet，HTTP）
• 6-表示层 -> 数据表示 (数据如何呈现，特殊处理->例如加密，比如ASCII，JPEG）
• 5-会话层 -> 主机间的通信（将不同应用程序的数据分开。建立，管理和终止应用之间的会话）
• 4-传输层 -> 端到端连接（可靠或不可靠的传递，例如TCP，UDP)
• 3-网络层 -> 地址和最佳路径（提供路由器用于路径的逻辑寻址，比如IP）
• 2-数据链路层 -> 媒体访问（将位组合成字节，将字节组合成帧，使用MAC地址访问，错误检测-比如HDLC）
• 1-物理层 -> 二进制传输（在设备之间移动bits。例如V.35）

五层模型

1. 应用层：对应于 OSI 参考模型的（应用层、表示层、会话层）。
2. 传输层：对应 OSI 参考模型的的传输层
3. 网络层：对应 OSI 参考模型的的网络层
4. 数据链路层：对应 OSI 参考模型的的数据链路层
5. 物理层：对应 OSI 参考模型的的物理层。

从浏览器地址栏输入 url 到显示主页的过程？

大概的过程比较简单，但是有很多点可以细挖：DNS解析、TCP三次握手、HTTP报文格式、TCP四次挥手等等。

1. DNS 解析：将域名解析成对应的 IP 地址。
2. TCP连接：与服务器通过三次握手，建立 TCP 连接。
3. 向服务器发送 HTTP 请求。
4. 服务器处理请求，返回HTTp响应。
5. 浏览器解析并渲染页面。
6. 断开连接：TCP 四次挥手，连接结束。

RSA和AES算法有什么区别？

• RSA采用非对称加密的方式，采用公钥进行加密，私钥解密的形式。其私钥长度一般较长，由于需要大数的乘幂求模等运算，其运算速度较慢，不合适大量数据文件加密。
• AES采用对称加密的方式，其秘钥长度最长只有256个比特，加密和解密速度较快，易于硬件实现。由于是对称加密，通信双方在进行数据传输前需要获知加密密钥。

什么是 DoS、DDoS、DRDoS 攻击？

• DOS: (Denial of Service), 翻译过来就是拒绝服务, 一切能引起拒绝行为的攻击都被称为 DOS 攻击。最常见的 DoS 攻击就有计算机网络宽带攻击、连通性攻击。
• DDoS: (Distributed Denial of Service)，翻译过来是分布式拒绝服务。是指处于不同位置的多个攻击者同时向一个或几个目标发动攻击，或者一个攻击者控制了位于不同位置的多台机器，并利用这些机器对受害者同时实施攻击。主要形式有流量攻击和资源耗尽攻击，常见的 DDoS攻击有： SYN Flood、Ping of Death、ACK Flood、UDP Flood 等。
• DRDoS: (Distributed Reflection Denial of Service)，中文是分布式反射拒绝服务，该方式靠的是发送大量带有被害者 IP 地址的数据包给攻击主机，然后攻击主机对 IP 地址源做出大量回应，从而形成拒绝服务攻击。

针对DDoS中的流量攻击，最直接的方法是增加带宽，理论上只要带宽大于攻击流量就可以了，但是这种方法成本非常高。在有充足带宽的前提下，我们应该尽量提升路由器、网卡、交换机等硬件设施的配置。

针对资源耗尽攻击，我们可以升级主机服务器硬件，在网络带宽得到保证的前提下，使得服务器能够有效对抗海量的SYN攻击包。我们也可以安装专业的抗DDoS防火墙，从而对抗SYN Flood等流量型攻击。瓷碗，负载均衡，CDN等技术都能有效对抗DDos攻击。

XSS 是如何攻击的呢？

XSS 攻击也是比较常见，XSS，叫跨站脚本攻击（Cross-Site Scripting），因为会与层叠样式表 (Cascading Style Sheets, CSS) 的缩写混淆，因此有人将跨站脚本攻击缩写为 XSS。它指的是恶意攻击者往 Web 页面里插入恶意 html 代码，当用户浏览网页的时候，嵌入其中 Web 里面的 html 代码会被执行，从而达到恶意攻击用户的特殊目的。

XSS的攻击方式就是想办法“教唆”用户的浏览器去执行一些这个网页中原本不存在的前端代码。

1. 攻击者构造出特殊的 URL，其中包含恶意代码。
2. 用户打开带有恶意代码的 URL 时，访问正常网站服务器
3. 网站服务端将恶意代码从 URL 中取出，拼接在 HTML 中返回给浏览器。
4. 用户浏览器接收到响应后解析执行，混在其中的恶意代码也被执行，请求恶意服务器，发送用户数据
5. 攻击者就可以窃取用户的数据，以此冒充用户的行为，调用目标网站接口执行攻击者指定的操作。

如何应对 XSS 攻击？

• 对输入进行过滤，过滤标签等，只允许合法值。
• HTML 转义。
• 对于链接跳转，如