后端开发面经汇总：计算机网络部分

整理后端开发面经的《计算机网络》部分，持续整理中…

学习书籍：《计算机网络：自顶向下方法》 ,
复习内容请参阅：
《计算机网络：自顶向下方法》 第一章：计算机网络和因特网
《计算机网络：自顶向下方法》 第二章：应用层
《计算机网络：自顶向下方法》 第三章：运输层
《计算机网络：自顶向下方法》 第四章：网络层：数据平面

---

---

字节跳动

---

Source:
字节跳动data后端开发三轮技术面+HR面面经
实习之路-字节跳动后端开发实习生 面经 已口头offer
字节跳动后端实习123面
字节跳动后端开发实习生-----一面
字节跳动-后台开发面经
字节跳动 C++开发实习岗

浏览器中输入网址后敲回车发生了什么？

1. 首先是域名解析，客户端使用DNS协议将URL解析为对应的IP地址；
2. 然后建立TCP连接，客户端与服务器通过三次握手建立TCP连接；
3. 接着是HTTP连接，客户端向服务器发送HTTP连接请求； （HTTP连接无需额外连接，直接通过已经建立的TCP连接发送）
4. 服务器对客户端发来的HTTP请求进行处理，并返回响应；
5. 客户端接收到HTTP响应，将结果渲染展示给用户。

浏览器刷新界面服务器如何区分两次相同的请求？

OSI 7层协议 和 五层协议，分别有哪些？

OSI七层协议模型主要是：应用层（Application）、表示层（Presentation）、会话层（Session）、传输层（Transport）、网络层（Network）、数据链路层（Data Link）、物理层（Physical）。

五层体系结构包括：应用层、传输层、网络层、数据链路层和物理层。

TCP、UDP的区别？

• TCP是面向连接的协议，提供的是可靠传输，在收发数据前需要通过三次握手建立连接，使用ACK对收发的数据进行正确性检验。而UDP是无连接的协议，不管对方有没有收到或者收到的数据是否正确。
• TCP提供流量控制和拥塞控制，而UDP没有。
• TCP对系统资源的要求高于UDP，所以速度也比UDP慢。
• TCP数据包是没有边界的，会出现粘包的问题，UDP包是独立的，不会出现粘包问题。

所以在应用方面，如果强调数据的完整性和正确性用TCP，当要求性能和速度的时候，使用UDP更加合适。
注：单凭TCP是不能保证完整性的，要是有黑客伪造TCP包，是无法识别的。

路由器、防火墙处于哪一层？

DNS协议

HTTP协议了解吗？

HTTP协议与TCP的区别与联系

联系：Http协议是建立在TCP协议基础之上的，当浏览器需要从服务器获取网页数据的时候，会发出一次Http请求。Http会通过TCP建立起一个到服务器的连接通道，当本次请求需要的数据传输完毕后，Http会立即将TCP连接断开，这个过程是很短的。

区别：HTTP和TCP位于不同的网络分层。TCP是传输层的协议，定义的是数据传输和连接的规范，而HTTP是应用层的，定义的是数据的内容的规范。
建立一个TCP请求需要进行三次握手，而由于http是建立在tcp连接之上的，建立一个http请求通常包含请求和响应两个步骤。

HTTP/1.0和HTTP/1.1的区别

HTTP 协议老的标准是 HTTP/1.0 ，目前最通用的标准是 HTTP/1.1 。
HTTP1.0 只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个 TCP 连接，但是最新的http/1.0加入了长连接，只需要在客户端给服务器发送的http报文头部加入Connection:keep-alive；
HTTP 1.1 支持持久连接，默认进行持久连接，在一个 TCP 连接上可以传送多个 HTTP 请求和响应，减少了建立和关闭连接的消耗和延迟。

HTTP请求格式？GET和POST？

HTTP的请求方法包括GET，POST，PUT，DELETE四种基本方法。（四种方法中只有POST不是操作幂等性的）

GET和POST的区别：

GET 方法不会修改服务器上的资源，它的查询是没有副作用的，而 POST 有可能会修改服务器上的资源；
GET 可以保存为书签，可以用缓存来优化，而 POST 不可以；
GET 把请求附在URL上，而 POST 把参数附在HTTP包的包体中；
浏览器和服务器一般对 GET 方法所提交的URL长度有限制，一般是1k或者2k，而对 POST 方法所传输的参数大小限制为80k到4M不等；
POST 可以传输二进制编码的信息，GET 的参数一般只支持ASCII；

---

常见的HTTP的状态码

HTTP状态码的含义

200 - 请求成功
301 - 资源（网页等）被永久转移到其它URL
404 - 请求的资源（网页等）不存在
500 - 内部服务器错误
400 - 请求无效
403 - 禁止访问

HTTP和HTTPS的区别？HTTPS中的 S是指什么？

HTTP 是超文本传输协议，信息是明文传输， HTTPS 则是具有安全性的 SSL 加密传输协议；
HTTP 和 HTTPS 使用的是完全不同的连接方式，用的端口也不一样，前者是 80 ，后者是 443；
HTTP 的连接很简单，是无状态的； HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，比 HTTP 协议安全；
HTTPS 协议需要到 CA 申请证书，一般免费证书较少，因而需要一定费用；

HTTPS讲一下？密钥怎么交换的？(HTTPS的具体实现，怎么确保安全性？)

HTTPS 包括非对称加密和对称加密两个阶段，在客户端与服务器建立连接的时候使用非对称加密，连接建立以后使用的是对称加密。

客户使用 HTTPS 的 URL 访问 Web服务器，要求与Web服务器建立SSL连接（SSL是传输层的协议）；
Web服务器收到客户端请求后，会将网站的公钥传送一份给客户端，私钥自己保存。
客户端的浏览器根据双方同意的安全等级，生成对称加密使用的密钥，称为会话密钥，然后利用网站的公钥将会话密钥加密，并传送给网站；
Web服务器利用自己的私钥解密出会话密钥；
Web服务器利用会话密钥加密与客户端之间的通信，这个过程是对称加密的过程。

服务器第一次传给客户端的公钥其实是CA对网站信息进行加密的数字证书；
客户端的对称加密密钥其实是三个随机数的哈希（1. 客户端第一次给服务端发送请求时附带的随机数 2. 服务器返回时的随机数 3. 客户端收到返回时的随机数）

三次握手、为什么多了第三次?（🌟🌟🌟🌟🌟）

TCP协议中，主动发起请求的一端称为客户端，被动连接的一端称为服务端。不管是客户端还是服务端，TCP连接建立完后都能发送和接收数据。起初，服务器和客户端都为CLOSED状态。在通信开始前，双方都得创建各自的传输控制块（TCB）；服务器创建完TCB后遍进入LISTEN状态，此时准备接收客户端发来的连接请求：

第一次握手：首先Client给Server发送连接请求报文（SYN报文），在这个报文中，包含了SYN=1，客户端随机选择的初始序号 seq为client_isn，发送之后处于SYN-SENT状态，这是第一次握手；

第二次握手：Server端接收到了这个请求，并分配资源，同时给Client返回一个SYNACK报文，这个报文中包含了这些字段，标志位SYN和ACK都为1，服务器自己初始序号seq为serve_isn；而小ack为client_seq+1，此时位于SYN-RCVD状态，这是第二次握手；

第三次握手：Client收到Server发来的ACK信息后呢，他会看到Server发过来的小ack是client_seq+1，这时他知道了Server收到了消息，也给Server回一个ACK报文，报文中同样包含了ACK=1这样的消息，同时还包括了小ack为server_isn+1和初始序号seq为client_isn+1这样的字段。三次握手之后，连接就建立了，Client进入Established（已建立连接）状态；

• 为什么多了第三次，两次握手不行吗？

如果使用两次握手的话，三次握手中的最后一次缺失，服务器不能确认客户端的接收能力。
举两个例子，第一种是黑客会伪造大量SYN请求发送给服务器，服务器立即确认并建立连接，分配资源，但是这一系列连接并不是真实存在的，这大大浪费了服务器的资源并且阻塞了正常用户的连接，这种也叫SYN洪泛攻击。第二种是服务器返回给客户端的ACK数据包可能会在传输的过程中丢失，而客户端没有收到该ACK数据包而拒绝接收服务器接下来发送的数据，于是服务器一直在发送，客户端一直在拒绝，形成死锁。

TCP三次握手时的第一次的seq序号是怎样产生的 ？

第一次的序号是随机序号，但也不是完全随机，它是使用一个ISN算法得到的。

seq = C + H (源IP地址，目的IP地址，源端口，目的端口)。其中，C是一个计时器，每隔一段时间值就会变大，H是消息摘要算法，输入是一个四元组（源IP地址，目的IP地址，源端口，目的端口）。

四次挥手、多了哪一次、为什么?

TCP连接的释放一共需要四步，因此称为四次挥手；因为TCP连接是全双工的，因此在四次挥手中，前两次挥手用于断开一个方向的连接，后两次挥手用于断开另一方向的连接。
TCP断开连接通常是由一方主动，一方被动的，这里我们假设client主动，server被动。

第一次挥手：当client没有数据要发送给server了，他会给server发送一个FIN报文，告诉server：“我已经没有数据要发给你了，但是你要是还想给我发数据的话，你就接着发，但是你得告诉我你收到我的关闭信息了”，这是第一次挥手，挥手之后client进入FIN_WAIT_1的第一阶段；

第二次挥手：当server收到client发来的FIN报文后，告诉client：“我收到你的FIN消息了，但是你等我发完的”此时给client返回一个ACK信息，并且呢ack=seq+1，这是第二次挥手，挥手之后呢server进入CLOSE_WAIT阶段，而client收到之后处于FIN_WAIT_2第二阶段

第三次挥手：当server发完所有数据时，他会给client发送一个FIN报文，告诉client说“我传完数据了，现在要关闭连接了”，然后呢server变成LAST_ACK状态，等着client最后的ACK信息，这是第三次挥手

第四次挥手：当client收到这个FIN报文时，他会对这个消息进行确认，即给server发ACK信息，但是它不相信网络，怕server收不到信息，它会进入TIME_WAIT状态，万一server没收到ACK消息它可以可以重传，而当server收到这个ACK信息后，就正式关闭了tcp连接，处于CLOSED状态，而client等待了2MSL这样长时间后还没等到消息，它知道server已经关闭连接了，于是乎他自己也断开了，这是第四次挥手，这样tcp连接就断开了

TCP TIME_WAIT讲一下？为啥需要这个？

TIME_WAIT 是指四次挥手中客户端接收了服务端的FIN报文并发送ACK报文给服务器后，仍然需要等待2MSL时间的过程。虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，有可能最后一个ACK丢失。如果客户端发送的ACK发生丢失，服务器会再次发送FIN报文给客户端，所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。

2MSL时间内收到了服务器的报文会怎样？

2MSL时间内，除了服务器的连接释放报文，还可能收到其他报文吗？

CLOSE_WAIT和TIME_WAIT

服务器出现大量CLOSE_WAIT的连接的原因以及解决方法？

CLOSE_WAIT状态是在TCP四次挥手的时候收到FIN但是没有发送自己的FIN时出现的，服务器出现大量 CLOSE_WAIT 状态的原因有两种：

1. 服务器内部业务处理占用了过多时间，都没能处理完业务；或者还有数据需要发送；或者服务器的业务逻辑有问题，没有执行close()方法；
2. 服务器的父进程派生出子进程，子进程继承了socket，收到FIN的时候子进程处理但父进程没有处理该信号，导致socket的引用不为0无法回收；

处理方法：

1. 停止应用程序
2. 修改程序里的bug

什么是粘包，怎么设计避免粘包？

因为TCP为了减少额外开销，采取的是流式传输，所以接收端在一次接收的时候有可能一次接收多个包。而TCP粘包就是发送方的若干个数据包到达接收方的时候粘成了一个包。多个包首尾相接，无法区分。
导致TCP粘包的原因有三方面：
1.发送端等待缓冲区满才进行发送，造成粘包；
2.接收方来不及接收缓冲区内的数据，造成粘包；
3.由于TCP协议在发送较小的数据包的时候，会将几个包合成一个包后发送；

避免粘包的措施：
1.通过编程，强制使TCP发生数据传送，不必等到缓冲区满；
2.优化接收方接收数据的过程，使其来得及接收数据包，包括提高接收进程优先级等
设置固定长度的报文或者设置报文头部指示报文的长度。

TCP怎么保证可靠传输的？拥塞控制说一下（重要🌟）

校序重流拥：校验和、确认应答+序列号、超时重传、流量控制、流量控制

校验和：发送的数据包的二进制相加然后取反，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP将丢弃这个报文段和不确认收到此报文段。
确认应答+序列号：TCP给发送的每一个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层。
超时重传：当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。
流量控制：TCP连接的每一方都有固定大小的缓冲空间，TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。TCP使用的流量控制协议是可变大小的滑动窗口协议。
接收方有即时窗口（滑动窗口），随ACK报文发送
拥塞控制：当网络拥塞时，减少数据的发送。
发送方有拥塞窗口，发送数据前比对接收方发过来的即使窗口，取小

防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载，拥塞控制自然也是控制发送者的流量，拥塞控制包括：慢启动、拥塞避免和快速恢复。（慢启动和拥塞避免是TCP的强制部分，快速恢复是推荐部分，并非必须！）
发送方维持一个拥塞窗口 cwnd ( congestion window )的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。发送方让自己的发送窗口等于拥塞窗口 cwnd 和接受窗口 rwnd 的较小值。

1. 慢启动。慢启动算法的思路是当主机开始发送数据时，先以比较小的拥塞窗口进行发送，然后每次翻倍，也就是说，由小到大逐渐增加拥塞窗口的大小，而这个大小是指数增长的，即1、2、4、8、16；
   为了防止拥塞窗口 cwnd 增长过大引起网络拥塞，还要另外设置一个慢启动阈值 ssthresh状态变量。当出现丢包事件（即拥塞），TCP发送方将 cwnd 置为1，将ssthresh置为 cwnd / 2；当拥塞窗口的大小超过慢启动阈值的时候（ cwnd > ssthresh 时），停止使用慢开始算法而改用拥塞避免算法；
   另外一种结束满启动方式：如果检测到3个冗余ACK，这时候TCP执行一种快速重传，并进入快读恢复状态；

2. 拥塞避免。当进入拥塞避免状态，cwnd 值大约是上次拥塞时值的一半，此时距离拥塞并不遥远！拥塞避免算法的思路是让拥塞窗口cwnd缓慢地增大，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1个MSS，而不是加倍；
   何时结束拥塞避免的线性增长：1）出现超时，与慢启动一样，cwnd = 1 MSS，出现丢包事件，ssthresh置为 cwnd / 2；2）发送方连续接收3个冗余ACK（也是丢包）：网络继续从发送方到接收方发送报文，TCP将cwnd值减半，并加上3个MSS，ssthresh置为 cwnd / 2；然后进入快速恢复阶段；

3. 快速恢复。对于引起TCP进入快速恢复的缺失报文段，没收到一个冗余ACK，cwnd +1 MSS… 最终丢失报文段的一个ACK到达时，TCP在降低cwnd后进入拥塞避免；
   当出现超时，表示网络拥塞，慢启动阈值 ssthresh置为 cwnd / 2 ，拥塞窗口cwnd=1 MSS，进入慢启动阶段；

---

HTTPS建立连接的过程