计算机网络面经总结

---

前言

本章内容总结自小林coding，笔者只是把自己觉得重要的摘录下来，秋招面试使用。

---

HTTP（超文本传输协议）

GET与POST

Get⽅法的含义是请求从服务器获取资源，这个资源可以是静态的⽂本、⻚⾯、图⽚视频等。

POST ⽅法则是相反操作，它向 URI 指定的资源提交数据，数据就放在报⽂的 body ⾥。

HTTP的优点

简单、灵活和易于扩展、应用广泛和跨平台

HTTP的缺点（双刃剑）

无状态、明文传输、不安全

HTTP1.1优化

长连接：只要任意⼀端没有明确提出断开连接，则保持 TCP 连接状态。

管道网络传输：同一个TCP连接里，客户端可以发起多个请求。

队头堵塞：顺序发送的请求序列中的一个请求因为某种原因被阻塞，则等待。

HTTPS

HTTPS 在 HTTP 与 TCP 层之间加⼊了 SSL/TLS 协议，可以解决：

窃听风险----信息加密

篡改风险----校验机制

冒充风险----身份证书

TCP

什么是TCP

TCP是面向连接的、可靠的、基于字节流的传输层通信协议。

什么是TCP连接

用于保证可靠性和流量控制维护的某些状态信息，这些信息的组合，包括Socket、序列号和窗口大小称为连接。

Socket：由IP地址和端口号组成

序列号：用来解决乱序问题

窗口大小：用来做流量控制

TCP和UDP的区别：

1. 连接
   • TCP是面向连接的传输层协议，传输数据前首先要建立连接。
   • UDP是不需要连接，即刻传输数据。
2. 服务对象
   • TCP是一对一的两点服务，即一条连接只有两个端点。
   • UDP支持一对一、一对多、多对多的交互通信。
3. 可靠性
   • TCP是可靠交付数据
   • UDP是尽最大努力交付，不保证可靠交付数据
4. 拥塞控制
   • TCP有拥塞控制和流量控制机制，保证数据传输的安全性
   • UDP则没有，即使网络非常拥堵了，也不会影响UDP的发送速率。
5. 首部开销
   • TCP首部长度较长，会有一定的开销，首部在没有使用【选项】字段时是20字节，如果使用了【选项】字段则会边长。
   • UDP首部只有8个字节，并且是固定不变的，开销较小。
6. 传输方式
   • TCP是流式传输，没有边界，但保证顺序和可靠。
   • UDP是一个包一个包的发送，是有边界的，但可能会丢包和乱序。
7. 分片不同
   • TCP的数据大小如果大于MSS大小，则会在传输层进行分片，目标主机收到后，也同样在传输层组装TCP数据包，如果中途丢失了一个分片，只需要传输丢失的这个分片。
   • UDP的数据大小如果大于MTU大小，则会在IP层进行分片，目标主机收到后，在IP层组装完数据，接着在传给传输层，但是如果中途丢了一个分片，在实现可靠传输的UDP就需要重传所有的数据包，这样传输效率非常差，所以UDP的报文应该小于MTU。

MTU和MSS

MTU ：⼀个⽹络包的最⼤⻓度，以太⽹中⼀般为 1500 字节；
MSS ：除去 IP 和 TCP 头部之后，⼀个⽹络包所能容纳的 TCP 数据的最⼤⻓度；

TCP连接建立（三次挥手）

一开始，客户端和服务器端都处于CLOSED状态。先是服务器端主动监听某个端口，处于LISTEN状态

客户端会随机初始化序列号（client_isn），将此序号置于TCP首部的【序号】字段中，同时把SYN标志位置为1，表示SYN报文。接着把第一个SYN报文发送给服务端，表示向服务端发起连接，该报文不包含应用层数据，之后客户端处于SYN-SENT状态。

服务端收到客户端的SYN报文后，首先服务端也随机初始化自己的序号（server_isn），将此序号填入TCP首部的【序号】字段中，其次把TCP首部的【确认应答号】字段填入client_isn + 1，接着把SYN和ACK标志位置为1.最后把该报文发送给客户端，该报文也不含应用层数据，之后服务器处于SYN-RCVD状态。

客户端接收到服务端的报文后，还要向服务端回应一个应答报文，首先该应答报文TCP首部ACK标志位置为1，其次【确认应答号】字段填入server_isn + 1，最后把报文发送给服务器端，这次报文可以携带客户到服务器的数据，之后客户端处于ESTABLISHED状态。

服务器接收到客户端的应答报文后，也进入ESTABLISHED状态。

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

分为3种原因：

• 三次握手才可以阻止重复历史连接的初始化（主要原因）
• 三次握手才可以同步双方的初始序列号
• 三次握手才可以避免资源的浪费

原因一：避免历史连接

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

• 一个【旧的SYN报文】比【最新的SYN】提早到达了服务端
• 那么此时服务端就会回一个SYN + ACK 报文给客户端
• 客户端收到后可以根据自身的上下文，判断这是一个历史连接（序列号过期或超时），那么客户端就会发送RST报文给服务器端，表示终止这次连接。

如果是两次握手连接，就不能判断当前连接是否为历史连接，三次握手则可以在客户端（发送方）准备发送第三次报文时，客户端有足够的上下文来判断当前连接是否是历史连接；

• 如果是历史连接，则发送RST报文，终止此次连接
• 如果不是，发送ACK报文，建立连接

原因二：同步双方初始化序列号

TCP协议的通信双方，都必须维护一个【序列号】，序列号是可靠传输的一个关键因素。当服务端发送【初始序列号】给客户端的时候，依然也要得到客户端的应答回应，这样一来一回，才确保双方的初始序列号能被可靠同步。

四次握手其实也能够可靠地同步双方的初始化序列，但由于第二部和第三部可以优化成一步，所以就成了三次握手。

原因三：避免资源浪费

如果客户端SYN阻塞了，重复发送多次 SYN报文，那么服务器在收到请求后会建⽴多个冗余的⽆效链接，造成不必要的资源浪费。

小结

TCP建立连接时，通过三次握手能够防止历史连接的建立，能减少双方不必要的资源开销，能帮助双方同步初始化序列号。序列号能保证数据包不重复，不丢弃和按序传输。

什么是syn攻击？如何避免？

我们都知道TCP连接建立是需要三次握手，假设攻击者短时间伪造不同的IP地址的syn报文，服务端每接收到一个syn报文，就进入SYN_RCVD状态，但服务器发送出去的ACK + SYN报文，无法得到未知IP主机的ACK应答，久而久之就会占满服务端的SYN接收队列，使得服务器不能为正常用户服务。

方式一：通过修改Linux内核参数，控制队列大小和当队列满时应做什么处理。

方式二：SYN队列占满，启动cookie

TCP四次挥手过程和状态变迁

• 客户端打算关闭连接，此时会发送⼀个 TCP ⾸部 FIN 标志位被置为 1 的报文，也即FIN 报文，之后客户端进⼊FIN_WAIT_1 状态。
• 服务端收到该报文后，就向客户端发送ACK 应答报⽂，接着服务端进⼊CLOSED_WAIT 状态。
• 客户端收到服务端的 ACK 应答报⽂后，之后进⼊FIN_WAIT_2 状态。
• 等待服务端处理完数据后，也向客户端发送FIN 报⽂，之后服务端进⼊LAST_ACK 状态。
• 客户端收到服务端的FIN 报⽂后，回⼀个ACK 应答报⽂，之后进⼊TIME_WAIT 状态
• 服务器收到了 ACK 应答报⽂后，就进⼊了CLOSED 状态，⾄此服务端已经完成连接的关闭。客户端在经过2MSL ⼀段时间后，⾃动进⼊CLOSED 状态，⾄此客户端也完成连接的关闭。

这里要注意：主动关闭连接的，才有TIME_WAIT状态。

为什么挥手需要四次？

• 关闭连接时，客户端向服务端发送FIN 时，仅仅表示客户端不再发送数据了但是还能接收数据。
• 服务器收到客户端的FIN 报⽂时，先回⼀个ACK 应答报⽂，而服务端可能还有数据需要处理和发送，等服务端不再发送数据时，才发送FIN 报⽂给客户端来表示同意现在关闭连接。

从上⾯过程可知，服务端通常需要等待完成数据的发送和处理，所以服务端的ACK 和FIN ⼀般都会分开发送，从⽽⽐三次握⼿导致多了⼀次。

为什么TIME_WAIT等待的时间是2MSL？

MSL 是 Maximum Segment Lifetime，报⽂最⼤⽣存时间，它是任何报⽂在⽹络上存在的最⻓时间，超过这个时间报⽂将被丢弃。因为 TCP 报⽂基于是 IP 协议的，⽽ IP 头中有⼀个TTL 字段，是 IP 数据报可以经过的最⼤路由数，每经过⼀个处理他的路由器此值就减 1，当此值为 0 则数据报将被丢弃，同时发送 ICMP 报⽂通知源主机。

MSL 与 TTL 的区别： MSL 的单位是时间，⽽ TTL 是经过路由跳数。所以 MSL 应该要⼤于等于 TTL 消耗为 0 的时间，以确保报⽂已被⾃然消亡。

TIME_WAIT 等待 2 倍的 MSL，比较合理的解释是：网络中可能存在来自发送方的数据包，当这些发送方的数据包被接收方处理后又会向对方发送响应，所以⼀来⼀回需要等待 2 倍的时间。

⽐如如果被动关闭⽅没有收到断开连接的最后的 ACK 报⽂，就会触发超时重发 Fin 报⽂，另⼀⽅接收到 FIN 后，会重发 ACK 给被动关闭⽅， ⼀来⼀去正好 2 个 MSL。

2MSL 的时间是从客户端接收到 FIN 后发送 ACK 开始计时的。如果在 TIME-WAIT 时间内，因为客户端的 ACK 没有传输到服务端，客户端⼜接收到了服务端重发的 FIN 报⽂，那么 2MSL 时间将重新计时。

在Linux系统里2MSL是60秒。

为什么需要TIME_WAIT状态？

1. 防止旧连接的数据包

• 如上图黄色框框服务端在关闭连接之前发送的SEQ = 301 报文，被网络延迟了。
• 这时有相同端⼝的 TCP 连接被复⽤后，被延迟的SEQ = 301 抵达了客户端，那么客户端是有可能正常接收这个过期的报文，这就会产⽣数据错乱等严重的问题。

所以，经过2MSL时间，足以让两个方向上的数据包都被丢弃，使得原来连接的数据包在网络中都自然消失，再出现的数据包一定都是新建立连接所产生的。

2. 保证连接正确关闭

• 如上图红⾊框框客户端四次挥⼿的最后⼀个 ACK 报⽂如果在⽹络中被丢失了，此时如果客户端 TIME-WAIT过短或没有，则就直接进⼊了 CLOSED 状态了，那么服务端则会⼀直处在 LASE_ACK 状态。
• 当客户端发起建⽴连接的 SYN 请求报⽂后，服务端会发送 RST 报⽂给客户端，连接建⽴的过程就会被终⽌。

所以，客户端再TIME_WAIT状态等待2MSL时间后，就可以保证双方的连接都可以正常的关闭。

TIME-WAIT过多的危害

第⼀是内存资源占⽤；
第⼆是对端⼝资源的占⽤，⼀个 TCP 连接⾄少消耗⼀个本地端⼝；

TCP如何Socket编程

• 服务端和客户端初始化 socket ，得到⽂件描述符；服务端调⽤ bind ，将绑定在 IP 地址和端⼝;
• 服务端调⽤ listen ，进⾏监听；
• 服务端调⽤ accept ，等待客户端连接；
• 客户端调⽤ connect ，向服务器端的地址和端⼝发起连接请求；服务端 accept 返回⽤于传输的 socket 的⽂件描述符；
• 客户端调⽤ write 写⼊数据；服务端调⽤ read 读取数据；
• 客户端断开连接时，会调⽤ close ，那么服务端 read 读取数据的时候，就会读取到了 EOF ，待处理完数据后，服务端调⽤ close ，表示连接关闭。

listen 时候参数 backlog 的意义？

• 未完成连接队列（SYN 队列）：接收到⼀个 SYN 建⽴连接请求，处于SYN_RCVD 状态；
• 已完成连接队列（Accpet 队列）：已完成 TCP 三次握⼿过程，处于 ESTABLISHED 状态；

accept握手发生在三次握手的哪一步？

• 客户端的协议栈向服务器端发送了 SYN 包，并告诉服务器端当前发送序列号 client_isn，客户端进⼊SYN_SENT 状态；
• 服务器端的协议栈收到这个包之后，和客户端进⾏ ACK 应答，应答的值为 client_isn+1，表示对 SYN 包client_isn 的确认，同时服务器也发送⼀个 SYN 包，告诉客户端当前我的发送序列号为 server_isn，服务器端进⼊ SYN_RCVD 状态；
• 客户端协议栈收到 ACK 之后，使得应⽤程序从 connect 调⽤返回，表示客户端到服务器端的单向连接建⽴成功，客户端的状态为 ESTABLISHED，同时客户端协议栈也会对服务器端的 SYN 包进⾏应答，应答数据为 server_isn+1；
• 应答包到达服务器端后，服务器端协议栈使得 accept 阻塞调⽤返回，这个时候服务器端到客户端的单向连接也建⽴成功，服务器端也进⼊ ESTABLISHED 状态。

从上⾯的描述过程，我们可以得知客户端 connect 成功返回是在第⼆次握⼿，服务端 accept 成功返回是在三次握⼿成功之后。

客户端调用了close，断开的流程？

• 客户端调⽤ close ，表明客户端没有数据需要发送了，则此时会向服务端发送 FIN 报⽂，进⼊ FIN_WAIT_1状态；
• 服务端接收到了 FIN 报⽂，TCP 协议栈会为 FIN 包插⼊⼀个⽂件结束符 EOF 到接收缓冲区中，应⽤程序可以通过 read 调⽤来感知这个 FIN 包。这个 EOF 会被放在已排队等候的其他已接收的数据之后，这就意味着服务端需要处理这种异常情况，因为 EOF 表示在该连接上再⽆额外数据到达。此时，服务端进⼊ CLOSE_WAIT状态；
• 接着，当处理完数据后，⾃然就会读到EOF ，于是也调⽤close 关闭它的套接字，这会使得客户端会发出⼀个 FIN 包，之后处于 LAST_ACK 状态；
• 客户端接收到服务端的 FIN 包，并发送 ACK 确认包给服务端，此时客户端将进⼊ TIME_WAIT 状态；
• 服务端收到 ACK 确认包后，就进⼊了最后的 CLOSE 状态；
• 客户端经过 2MSL 时间之后，也进⼊ CLOSE 状态；

IP

IP和MAC的关系

• IP 的作⽤是主机之间通信⽤的，⽽ MAC 的作⽤则是实现「直连」的两个设备之间通信，⽽ IP 则负责在「没有直连」的两个⽹络之间进⾏通信传输。

• 在⽹络中数据包传输中也是如此，源IP地址和⽬标IP地址在传输过程中是不会变化的，只有源 MAC 地址和⽬标MAC ⼀直在变化。

域名解析的工作流程

ARP

ARP 是借助 ARP 请求与 ARP 响应两种类型的包确定 MAC 地址的。

操作系统通常会把第⼀次通过 ARP 获取的 MAC 地址缓存起来，以便下次直接从缓存中找到对应 IP 地址的 MAC地址。

RARP协议

ARP 协议是已知 IP 地址求 MAC 地址，那 RARP 协议正好相反，它是已知 MAC 地址求 IP 地址。

DHCP

我们的电脑通过DHCP动态获取IP地址。

下一步需要总结的知识：

• TCP 重传、滑动窗⼝、流量控制、拥塞控制
• 键⼊⽹址到⽹⻚显示，期间发⽣了什么？