计算机网络常见面试题

一月 25, 2020 计算机网络

这篇文章主要是谈谈计算机网络常见的面试个考察点，记录一下，里面有很多问题之前面试也遇到过，特此记录一下！

0、讲一下 TCP 三次握手

0、TCP 三次握手是一个 TCP 连接的建立过程，为了确认双方的收发能力正常，并初始化 seq，为后续传输做准备

1、首先 Client 处于 Closed 状态，Server 处于 Listen 状态，Client 向 Server 发了 SYN=1，seq=x，Server 收到后确认了 Server 的接收能力正常，Client 的发送能力正常；

2、Server 回复 SYN=1，ACK=1，ack=x+1，seq=y，Client 收到后做出判断：Client 和 Server 的收发能力都正常，

3、接着 Client 向 Server 发 ACK=1，seq=x+1，ack=y+1，这就是第三次握手，可以携带数据了，Server 收到后便可以确认 Client 接收能力正常，Server 发送能力正常，并把链接从半连接队列移动到全连接队列

1、seq 是固定的吗

seq 是随时间变化的，每个连接都有不同的 seq，seq 是一个 32byte 的计数器，每 4ms 加一，因此 seq 是动态生成的，为后续传输做准备

2、三次握手可以携带数据吗

只有第三次可以携带数据，如果第一次就能携带数据的话服务器会花很多时间对数据进行存储，占用 IO 资源，非常危险，对于第三次握手来说 Client 已经知道双方的收发能力正常，所以携带数据也是没问题的

3、什么是半连接队列

第一次握手后，Server 发出 ACK 报文，等待 Client 向自己发送 ACK 报文，此时就会把请求放在半连接队列，半连接队列满了就会丢弃报文

4、谈谈 SYN 攻击

Client 向 Server 发 SYN=1，seq=x，收到 Server 发来的 ACK 不回复 ACK，或者直接丢弃 Server 的 ACK 报文，导致半连接队列满了，丢弃了其他真实需求的请求报文，导致服务器无法正常提供服务

5、第三次握手丢失，会怎样

服务端会重传，如果收到就会停止，尝试时间间隔为 1s、2s、4s、8s、16s、32s、64s，Linux 最多尝试 64s，之后若还是无应答就会移出半连接队列

6、Linux 如何判断受到了 SYN 攻击

1	netstat -n -p TCP\|grep SYN_RECV

7、Linux 查看网络状态

1	netstat -n \| awk '/^tcp/ {++S [$NF]} END {for (a in S) print a, S [a]}'

它会显示例如下面的信息：

TIME_WAIT 814
CLOSE_WAIT 1
FIN_WAIT1 1
ESTABLISHED 634
SYN_RECV 2
LAST_ACK 1

ESTABLISHED 表示正在通信，TIME_WAIT 表示主动关闭，CLOSE_WAIT 表示被动关闭。

8、讲一下 TCP 四次挥手

TCP 四次挥手用户双方断开连接，TCP 四次挥手由任意一方发起，这里假设 A 主机和 B 主机：

1、A 主动发起释放连接请求，FIN=1，seq=u

2、B 收到 A 的连接释放报文后，立即回复 A 主机一个 ACK 报文（ACK=1，ack=u+1，seq=v），表示自己收到了 A 主机的连接释放报文

3、B 主机此时会通知 ApplicationA 主机要释放连接了，Application 执行资源释放代码，完毕后回复 A 主机连接释放报文，ACK=1，FIN=1，ack=u+1，seq=w

4、A 主机回复 B 主机连接释放报文，ACK=1，ack=w+1，seq=u+1，并且等待 2MSL 时间后关闭，B 主机在收到 A 主机的 ACK 报文后也会关闭

9、为什么会有四次挥手

因为 B 主机收到 A 主机连接释放报文后不会立即关闭 Socket，只能先回复一个 ACK 报文，告诉 A 主机你的连接释放请求报文我已经收到了，等到 B 主机全部发完报文后，B 主机才会向 A 主机发送 FIN 报文

10、什么是 2MSL 的等待时间

MSL 是 TCP 报文段的最大生存时间，2MSL 是报文段在 AB 主机之间的往返时间，为了最后的 ACK 报文能到达 B 主机，B 主机才能正常关闭连接。

如果 B 主机未收到 A 主机发的最后的 ACK 报文，B 主机会重发 FIN 报文，一来一去正好是两个 MSL；还有 2MSL 的等待时间也是为了避免新旧连接混淆，因为经过 2MSL，上一次连接中所有的重复包都会消失

11、服务器出现大量 CLOSE_WAIT 的原因

最有可能的就是资源释放代码有 BUG，没有正确发出 ACK=1、FIN=1 的报文，导致大量连接不能正常关闭，也就是出现大量 CLOSE_WAIT 的原因

12、服务器出现大量 TIME_WAIT 的原因

一些爬虫服务器（如果网管在安装的时候没有做内核参数优化的话）上经常会遇到这个问题，TIME_WAIT 是主动关闭连接的一方保持的状态，对于爬虫服务器来说他本身就是 “客户端”，在完成一个爬取任务之后，他就会发起主动关闭连接，从而进入 TIME_WAIT 的状态，然后在保持这个状态 2MSL（max segment lifetime）时间之后，彻底关闭回收资源。

解决思路很简单，就是让服务器能够快速回收和重用那些 TIME_WAIT 的资源，vim /etc/sysctl.conf

# 对于一个新建连接，内核要发送多少个 SYN 连接请求才决定放弃，不应该大于 255，默认值是 5，对应于 180 秒左右时间  
net.ipv4.tcp_syn_retries=2 
#net.ipv4.tcp_synack_retries=2 
# 表示当 keepalive 起用的时候，TCP 发送 keepalive 消息的频度。缺省是 2 小时，改为 300 秒 
net.ipv4.tcp_keepalive_time=1200 
net.ipv4.tcp_orphan_retries=3 
# 表示如果套接字由本端要求关闭，这个参数决定了它保持在 FIN-WAIT-2 状态的时间 
net.ipv4.tcp_fin_timeout=30   
# 表示 SYN 队列的长度，默认为 1024，加大队列长度为 8192，可以容纳更多等待连接的网络连接数。 
net.ipv4.tcp_max_syn_backlog = 4096 
# 表示开启 SYN Cookies。当出现 SYN 等待队列溢出时，启用 cookies 来处理，可防范少量 SYN 攻击，默认为 0，表示关闭 
net.ipv4.tcp_syncookies = 1 
   
# 表示开启重用。允许将 TIME-WAIT sockets 重新用于新的 TCP 连接，默认为 0，表示关闭 
net.ipv4.tcp_tw_reuse = 1 
# 表示开启 TCP 连接中 TIME-WAIT sockets 的快速回收，默认为 0，表示关闭 
net.ipv4.tcp_tw_recycle = 1 
   
## 减少超时前的探测次数  
net.ipv4.tcp_keepalive_probes=5  
## 优化网络设备接收队列  
net.core.netdev_max_backlog=3000

修改完之后执行 /sbin/sysctl -p 让参数生效。

12、TCP 和 UDP 的区别

UDP 的主要特点是：
（1）无连接；
（2）尽最大努力交付；不保证可靠交付
（3）面向报文，不对报文拆分或者合并；
（4）无拥塞控制；
（5）支持一对一、一对多、多对一和多对多的交互通信；
（6）首部开销小（只有四个字段：源端口、目的端口、长度、检验和，即 8 个字节）。

TCP 的主要特点是：
（1）面向连接；
（2）每一条 TCP 连接只能是点对点的（一对一）；
（3）提供可靠交付的服务；
（4）提供全双工通信；
（5）面向字节流。

13、GET 请求和 POST 请求的区别

HTTP 报文层面 ：GET 将请求信息放在 URL、POST 放在报文体中。GET 请求 URL 长度受浏览器限制， HTTP 协议本身对 URL 长度并没有做任何规定。

数据层层面 ：GET 符合幂等性和安全性，反复读取不应该对访问的数据有副作用；POST 不符合幂等性和安全性

其他层面 ：GET 可以被缓存 POST 不幂等也就意味着不能随意多次执行，因此也就不能缓存。

GET 和 POST 还有一个重大区别，简单的说：GET 产生一个 TCP 数据包；POST 产生两个 TCP 数据包。
对于 GET 方式的请求，浏览器会把 http header 和 data 一并发送出去，服务器响应 200（返回数据）；而对于 POST，浏览器先发送 header，服务器响应 100 continue，浏览器再发送 data，服务器响应 200 ok（返回数据）。

14、Session 的两种实现方式

1、使用 Cookie 来实现，也就是以 SESSIONID 为 Cookie 的 Key，以 SESSIONID 的值为 Cookie 的 Value，每次请求的时候都会通过 Cookie 机制携带上这个 SESSIONID

2、如果客户端禁止使用 Cookie，那么就使用 URL 回写来实现，就在参数 url 中加入 Session ID 信息，然后返回修改后的 url ，通过这种机制，url 中保存了 sessionId，然后点击 URL 时又回传到服务器，来维持身份。

Cookie 数据存放在客户的浏览器上，Session 数据放在服务器上

Session 相对 Cookie 更安全

如果考虑减轻服务器负担，应该使用 Cookie

16、HTTPS 真的很安全吗

浏览器默认填充 http://，请求需要进行跳转，又被劫持的风险，如果一开始输入的地址的 https://… 那么这样还是可以保证安全性的，可以使用 HSTS（HTTP Strict Transport Security）优化，目前还未开始推行

17、UDP 如何实现可靠传输

UDP 要想可靠，就要接收方收到 UDP 之后回复个确认包，发送方有个机制，收不到确认包就要重新发送，每个包有递增的序号，接收方发现中间丢了包就要发重传请求，当网络太差时候频繁丢包，防止越丢包越重传的恶性循环，要有个发送窗口的限制，发送窗口的大小根据网络传输情况调整，调整算法要有一定自适应性。

恭喜你，你在应用层重新实现了 TCP！

18、ARP 地址解析协议，工作原理

《NAT 技术与 ARP 协议 - ARP 协议》 ARP 不是一个单纯的数据链路层的协议，而是一个介于数据链路层和网络层之间的协议。ARP 协议的作用：ARP 协议建立了主机 IP 地址和 MAC 地址的映射关系。其实就是喊话的方式，大家都听见了，但是只有符合 IP 的主机才会回发自己的 MAC 地址。

19、 ICMP 协议

ICMP 是 InternetControl Message Protocol，因特网控制报文协议。它是 TCP/IP 协议族的一个子协议，用于在 IP 主机、路由器之间传递控制消息。控制消息是指网络通不通、主机是否可达、路由器是否可用等网络本身的消息。这些控制消息虽然并不传输用户数据，但是对于用户数据的传递起着重要的作用。ICMP 报文有两种：差错报告报文和询问报文。详情见《辅助 IP 的 ICMP》

20、TTL 是什么？作用是什么？

TTL 是指生存时间，简单来说，它表示了数据包在网络中的时间，经过一个路由器后 TTL 就减一，这样 TTL 最终会减为 0，当 TTL 为 0 时，则将数据包丢弃，这样也就是因为两个路由器之间可能形成环，如果没有 TTL 的限制，则数据包将会在这个环上一直死转，由于有了 TTL，最终 TTL 为 0 后，则将数据包丢弃。

21、TCP 流量控制、拥塞控制

关于 TCP 的流量控制、拥塞控制见《TCP 的高性能机制》，点击链接

Tim's Blog

计算机网络常见面试题

0、讲一下 TCP 三次握手

1、seq 是固定的吗

2、三次握手可以携带数据吗

3、什么是半连接队列

4、谈谈 SYN 攻击

5、第三次握手丢失，会怎样

6、Linux 如何判断受到了 SYN 攻击

7、Linux 查看网络状态

8、讲一下 TCP 四次挥手

9、为什么会有四次挥手

10、什么是 2MSL 的等待时间

11、服务器出现大量 CLOSE_WAIT 的原因

12、服务器出现大量 TIME_WAIT 的原因

12、TCP 和 UDP 的区别

13、GET 请求和 POST 请求的区别

14、Session 的两种实现方式

16、HTTPS 真的很安全吗

17、UDP 如何实现可靠传输

18、ARP 地址解析协议，工作原理

19、 ICMP 协议

20、TTL 是什么？作用是什么？

21、TCP 流量控制、拥塞控制

22、谈谈 OSI 七层模型与 TCP/IP 五层模型

0、讲一下 TCP 三次握手

1、seq 是固定的吗

2、三次握手可以携带数据吗

3、什么是半连接队列

4、谈谈 SYN 攻击

5、第三次握手丢失，会怎样

6、Linux 如何判断受到了 SYN 攻击

7、Linux 查看网络状态

8、讲一下 TCP 四次挥手

9、为什么会有四次挥手

10、什么是 2MSL 的等待时间

11、服务器出现大量 CLOSE_WAIT 的原因

12、服务器出现大量 TIME_WAIT 的原因

12、TCP 和 UDP 的区别

13、GET 请求和 POST 请求的区别

14、Session 的两种实现方式

15、Cookie 和 Session 的区别

16、HTTPS 真的很安全吗

17、UDP 如何实现可靠传输

18、ARP 地址解析协议，工作原理

19、 ICMP 协议

20、TTL 是什么？作用是什么？

21、TCP 流量控制、拥塞控制

22、谈谈 OSI 七层模型与 TCP/IP 五层模型