网络面试问题整理（1~10）

常见的的网络面试100问（1~10）

1、 介绍 TCP 连接的三次握手？追问：为什么 TCP 握手需要三次？

第一次： 客户端发送syn（序列号SYN=1，ACK=0,seq=i）同步序列号请求报文至服务器 ，进入SYN_SEND同步已发送状态。

第二次：服务器接收到客户端的请求之后必须对客户端的请求做出回复，即，(ack=i+1) 确认，并且也发出一个syn（seq=j ，ACK=1）同步序列号请求至客户端,此时服务端进入SYN_RCVD同步收到状态.

第三次：客户端接收到这个请求之后，对服务端做出回应，确认报文（SYN-=0,ACK=1seq=i+1 ack=j+1）至服务端双方成功建立链接。

1.1）为什么ack=i+1？

服务器对客户端的数据进行确认，因为已经收到序列号为i的数据包，准备接受序列号为i+1的数据包，所以确认号ack=i+1。

1.2）为什么第三次握手 seq =i +1？

ACK报文段可以携带数据，因此如果不携带数据，不消耗序列号，则下一个报文的序列号仍然是seq=i+1；如果携带数据，则序列号为在i+1的基础上增加携带数据的大小。此处默认第三次握手客户端不发送携带数据的报文段。（简单理解，序列号已经加1，不携带数据无需加1）

1.3） 为什么需要三次握手？

1.3.1）假设两次？

如果只是前两次握手没有第三次握手，客户端无法对服务端的数据请求做出确认，因为TCP的确认，重传机制，会导致服务端以为客户端没有收到该数据包，从而导致不断重传，造成资源浪费。

1.3.2）假设四次？

如果是四次握手，假设将第二次的握手中的 取确认报文与同步分开进行，传输效率大大下降，可以提高连接的速度与效率。
总结：本质：1、保证信道数据传输的可靠性；2、避免资源浪费 3、三次是保证双方互相明确对方能收能发的最低值。

2、 介绍 TCP 断开的四次挥手，追问：为什么 TCP 的挥手需要四次？

• 第一次：客户端传输完毕数据时向服务端发送FIN（FIN=1,）请求断开链接报文，此时客户端进入FIN_WAIT1等待关闭状态不再进行发出数据，但仍可正常接收数据。

• 第二次：服务端收到客户端的 FIN请求断开开链接报文后，对其做出回应，发送一个确认报文给客户端并进入CLOSE_WAIT关闭等待状态，客户端接收到这个报文后进入FIN_WAIT2状态。

• 第三次：服务器在传输完成剩余数据后会向客户端发出 FIN 请求断开链接报文，同时进入LAST_ACK状态。

• 第四次：客户端收到服务端的断开链接请求后会启动一个定时器（TIME_WAIT定时器），该定时器时长是2MSL(最大段报文生存时间)，同时发送最后一次ACK报文。

2.1） 为什么四次挥手？

TCP是全双工的通信机制，每个方向必须单独进行关闭。
TCP传输连接关闭的原则如下：
当一端完成它的数据发送任务后就可以发送一个FIN字段置1的数据段来终止这个方向的数据发送；当另一端收到这个FIN数据段后，必须通知它的应用层 对端已经终止了那个方向的数据传送.

2.2）为什么不能用三次握手中捎带应答机制减少一次握手？

TCP是全双工通信的，服务端收到断开链接请求后只是表示客户端不会传输数据到服务端了，但是并不表示服务端不传输数据到客户 端。
如果采用捎带应答，服务端将无法把剩余的数据传输到客户端端。

2.3）为何需要等待2msl 的时间？

网络是不可靠的，TCP是可靠协议，必须保证最后一次报文送达之后才能断开链接，否则会再次收到服务端端的FIN报文信息。
而等待2MSL时间就是为了保证最后最后一次报文丢失时还能重新发送。

3、 TCP 的 syn 攻击的过程？追问：怎么防御？

常见的攻击手段，syn洪泛（syn flood），

原理：又称为SYN洪泛攻击模式拒绝服务攻击的一种，利用TCP三次握手协议的缺陷，向目标主机发送大量的伪造源地址的SYN连接请求，消耗目标主机的连接队列资源，从而不能够为正常用户提供服务。

防范措施：SYN-Cookie技术，该技术改变的资源分配策略：当服务器收到一个SYN报文后，不立即分配缓冲区，而是将连接信息生成一个cookie，并将这个Cookie作为将要返回的SYN+ACK报文的初始序列号。单客户端返回一个ACK报文是，根据报头信息计算cookie，与返回的确认号（初始的序列号+1）的前24位进行比较，如果相同，那么是一个正常连接，分配资源，建立连接。

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

Tcp连接为什么不是四次：如果是四次握手，假设将第二次的握手中的 取确认报文与同步分开进行，传输效率大大下降，可以提高连接的速度与效率。

TCP断开为什么不可以是三次：TCP是全双工通信的，服务端收到断开链接请求后只是表示客户端不会传输数据到服务端了，但是并不表示服务端不传输数据到客户 端。
如果采用捎带应答，服务端将无法把剩余的数据传输到客户端。

5、 TCP 是如何通过滑动窗口协议实现流量控制的？

滑动窗口协议：滑动窗口协议，该协议允许发送方在停止并等待确认前发送多个数据分组。由于发送方不必每发送一个分组就停下来确认，因此该协议可以加速数据的传输。

滑动窗口工作原理：
TCP滑动窗口用来暂存两台计算机间要传送的数据分组。每台运行TCP协议的计算机有两个滑动窗口:一个用于数据发送，另一个用于数据接收。发送端待发数据分组在缓冲区排队等待送出。被滑动窗口框入的分组，是可以在未收到接收确认的情况下多送出的部分。滑动窗口对端端标志的分组，是已经被接收端确认收到的分组。随着新的确认到来，窗口不断向右滑动。

滑动窗口的流量控制：
如果发送端数据发送过快，接收方来不接接受就会造成数据丢失，导致重传浪费资源，流量控制的目的就是限制流量发送速率，保证对端接受率。
实质：通过接收方窗口接受额度字节大小，限制发送端的流量字节大小。

6、 描述 TCP 和 UDP 的区别？

7、 TCP 有哪些定时器？

TCP 七种定时器：（常见的为前四种）

• 建立连接定时器(connection-establishment timer)
• 重传定时器(retransmission timer)
• 延迟应答定时器(delayed ACK timer)
• 坚持定时器(persist timer)
• 保活定时器(keepalive timer)
• FIN_WAIT_2定时器(FIN_WAIT_2 timer)
• TIME_WAIT定时器 (TIME_WAIT timer, 也叫2MSL timer

建立连接定时器(connection-establishment timer)

顾名思义，这个定时器是在建立连接的时候使用的， 我们知道， TCP建立连接需要3次握手建立连接的过程中，在发送SYN时， 会启动一个定时器(** 默认应该是3秒 **)，如果SYN包丢失了， 那么3秒以后会重新发送SYN包的(当然还会启动一个新的定时器， 设置成6秒超时)，当然也不会一直没完没了的发SYN包， 在/proc/sys/net/ipv4/tcp_syn_retries 可以设置到底要重新发送几次SYN包。

重传定时器(retransmission timer)

重传定时器在TCP发送数据时设定，在计时器超时后没有收到返回的确认ACK，发送端就会重新发送队列中需要重传的报文段。使用RTO重传计时器一般有如下规则：

当TCP发送了位于发送队列最前端的报文段后就启动这个RTO计时器；
如果队列为空则停止计时器，否则重启计时器；
当计时器超时后，TCP会重传发送队列最前端的报文段；
当一个或者多个报文段被累计确认后，这个或者这些报文段会被清除出队列
   重传计时器保证了接收端能够接收到丢失的报文段，继而保证了接收端交付给接收进程的数据始终的有序完整的。因为接收端永远不会把一个失序不完整的报文段交付给接收进程。

延迟应答定时器(delayed ACK timer)

延迟应答也被称为捎带ACK， 这个定时器是在延迟应答的时候使用的。 为什么要延迟应答呢？ 延迟应答是为了提高网络传输的效率。

举例说明，比如服务端收到客户端的数据后， 不是立刻回ACK给客户端， 而是等一段时间(一般最大200ms)，这样如果服务端要是有数据需要发给客户端，那么这个ACK就和服务端的数据一起发给客户端了， 这样比立即回给客户端一个ACK节省了一个数据包。

坚持定时器(persist timer)

我们已经知道TCP通过让接收方指明希望从发送方接收的数据字节数（即窗口大小）来进行流量控制。如果窗口大小为 0会发生什么情况呢？这将有效地阻止发送方传送数据，直到窗口变为非0为止。接收端窗口变为非0后，就会发送一个确认ACK指明需要的报文段序号以及窗口大小。

如果这个确认ACK丢失了，则双方就有可能因为等待对方而使连接终止：接收方等待接收数据（因为它已经向发送方通告了一个非0的窗口），而发送方在等待允许它继续发送数据的窗口更新。为防止这种死锁情况的发生，发送方使用一个坚持定时器 (persist timer)来周期性地向接收方查询，以便发现窗口是否已增大。这些从发送方发出的报文段称为窗口探查 (window probe)。

保活定时器(keepalive timer)

在TCP连接建立的时候指定了SO_KEEPALIVE，保活定时器才会生效。如果客户端和服务端长时间没有数据交互，那么需要保活定时器来判断是否对端还活着，但是这个其实很不实用，因为默认是2小时没有数据交互才探测，时间实在是太长了。如果你真的要确认对端是否活着， 那么应该自己实现心跳包，而不是依赖于这个保活定时器。

FIN_WAIT_2定时器(FIN_WAIT_2 timer)

主动关闭的一端调用完close以后（即发FIN给被动关闭的一端， 并且收到其对FIN的确认ACK）则进入FIN_WAIT_2状态。如果这个时候因为网络突然断掉、被动关闭的一段宕机等原因，导致主动关闭的一端不能收到被动关闭的一端发来的FIN，主动关闭的一段总不能一直傻等着，占着资源不撒手吧？这个时候就需要FIN_WAIT_2定时器出马了， 如果在该定时器超时的时候，还是没收到被动关闭一端发来的FIN，那么不好意思， 不等了， 直接释放这个链接。FIN_WAIT_2定时器的时间可以从/proc/sys/net/ipv4/tcp_fin_timeout中查看和设置。

TIME_WAIT定时器 (TIME_WAIT timer, 也叫2MSL timer)

TIME_WAIT是主动关闭连接的一端最后进入的状态， 而不是直接变成CLOSED的状态， 为什么呢？第一个原因是万一被动关闭的一端在超时时间内没有收到最后一个ACK， 则会重发最后的FIN，2MSL（报文段最大生存时间）等待时间保证了重发的FIN会被主动关闭的一段收到且重新发送最后一个ACK；另外一个原因是在2MSL等待时间时，任何迟到的报文段会被接收并丢弃，防止老的TCP连接的包在新的TCP连接里面出现。不可避免的，在这个2MSL等待时间内，不会建立同样(源IP, 源端口，目的IP，目的端口)的连接。

8、 什么是 CDN？CDN 是如何工作的？

概念：CDN全称叫做“Content Delivery Network”，中文叫内容分发网络,用于改善网络分布,大大缩短网络延时，加速网站访问。

基本思路：
尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节，使内容传输的更快、更稳定。通过在网络各处放置节点服务器所构成的在现有的互联网基础之上的一层智能虚拟网络，CDN系统能够实时地根据网络流量和各节点的连接、负载状况以及到用户的距离和响应时间等综合信息将用户的请求重新导向离用户最近的服务节点上。

目的：
解决因分布、带宽、服务器性能带来的访问延迟问题，适用于站点加速、点播、直播等场景。使用户可就近取得所需内容，解决 Internet网络拥挤的状况，提高用户访问网站的响应速度和成功率。

9、 什么是 DNS？说说 DNS 的解析过程？

域名：

DNS （域名解析协议）通过网站域名获取 IP 地址 ，比如www.baidu.com —>x.x.x.x
UDP 53 端口

解析过程：
1、找缓存
2、找本机的hosts文件
3、找DNS服务器（递归，迭代）
递归与迭代：
（1）递归查询：本机向本地域名服务器发出一次查询请求，就静待最终的结果。如果本地域名服务器无法解析，自己会以DNS客户机的身份向其它域名服务器查询，直到得到最终的IP地址告诉本机
（2）迭代查询：本地域名服务器向根域名服务器查询，根域名服务器告诉它下一步到哪里去查询，然后它再去查，每次它都是以客户机的身份去各个服务器查询。

详细：域名解析总体可分为一下过程：
(1) 输入域名后, 先查找自己主机对应的域名服务器，域名服务器先查找自己的数据库中的数据.
(2) 如果没有， 就向上级域名服务器进行查找， 依次类推
(3) 最多回溯到根域名服务器, 肯定能找到这个域名的IP地址
(4) 域名服务器自身也会进行一些缓存， 把曾经访问过的域名和对应的IP地址缓存起来, 可以加速查找过程
具体可描述如下：

1. 主机先向本地域名服务器进行递归查询
2. 本地域名服务器采用迭代查询，向一个根域名服务器进行查询
3. 根域名服务器告诉本地域名服务器，下一次应该查询的顶级域名服务器的IP地址
4. 本地域名服务器向顶级域名服务器进行查询
5. 顶级域名服务器告诉本地域名服务器，下一步查询权限服务器的IP地址
6. 本地域名服务器向权限服务器进行查询
7. 权限服务器告诉本地域名服务器所查询的主机的IP地址
8. 本地域名服务器最后把查询结果告诉主机

10、 什么是 DHCP?描述工作过程？

概念
DHCP，动态主机配置协议，前身是BOOTP协议，是一个局域网的网络协议，使用UDP协议工作，常用的2个端口：67(DHCP server服务器),68(DHCP client客户端)。
DHCP通常被用于局域网环境，主要作用是集中的管理、分配IP地址，使client动态的获得IP地址、Gateway地址、DNS服务器地址等信息，并能够提升地址的使用率。简单来说，DHCP就是一个不需要账号密码登录的、自动给内网机器分配IP地址等信息的协议。

DHCP工作流程:

1：寻找DHCP服务器

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

2：分配IP地址

在网络中接收到DHCP discover发现信息的DHCP服务器就会做出响应，它从尚未分配的IP地址池中挑选一个分配给DHCP客户机，向DHCP客户机发送一个包含分配的IP地址和其他设置的DHCP offer提供信息。

3：接受IP地址

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

4：IP地址分配确认

当DHCP服务器收到DHCP客户端回答的DHCP request请求信息之后，便向DHCP客户端发送一个包含它所提供的IP地址和其他设置的DHCP ack确认信息，告诉DHCP客户端可以使用它提供的IP地址。然后，DHCP客户机便将其TCP/IP协议与网卡绑定，另外，除了DHCP客户机选中的DHCP服务器外，其他的DHCP服务器将收回曾经提供的IP地址。

5：重新登录

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

6：更新租约

DHCP服务器向DHCP客户机出租的IP地址一般都有一个租借期限，期满后DHCP服务器便会收回出租的IP地址。如果DHCP客户机要延长其IP租约，则必须更新其IP租约。DHCP客户机启动时和IP租约期限到达租约的50%时，DHCP客户机都会自动向DHCP服务器发送更新其IP租约的信息。

DHCP 报文:

• DHCP Discover：客户端开始DHCP过程发送的包，是DHCP协议的开始
• DHCP Offer：服务器接收到DHCP DISCOVER之后做出的响应，它包括了给予客户端的IP（yiaddr）、客户端的MAC地址、租约过期时间、服务器的识别符以及其他信息
• DHCP Request：客户端对于服务器发出的DHCP OFFER所做出的响应。在续约租期的时候同样会使用。
• DHCP ACK ：服务器在接收到客户端发来的DHCP REQUEST之后发出的成功确认的报文。在建立连接的时候，客户端在接收到这个报文之后才会确认分配给它的IP和其他信息可以被允许使用。
• DHCP NAK ：DHCP ACK的相反的报文，表示服务器拒绝了客户端的请求。
• DHCP Release ：一般出现在客户端关机、下线等状况。这个报文将会使DHCP服务器释放发出此报文的客户端的IP地址
• DHCP Inform ：客户端发出的向服务器请求一些信息的报文
• ** DHCP Decline**:当客户端发现服务器分配的IP地址无法使用（如IP地址冲突时），将发出此报文，通知服务器禁止使用该IP地址。

DHCP 自动状态机

• DHCP获得ip地址的4步骤：discover­>offer­>request­>ack(nak)
• DHCP刷新租期的步骤：request­>ack(nak)
• DHCP释放ip的步骤：release