面试/笔试题集锦——计算机网络篇（持续更新中）

最新推荐文章于 2024-07-26 17:19:13 发布

CrazyOnes

最新推荐文章于 2024-07-26 17:19:13 发布

阅读量755

点赞数 4

分类专栏：计算机网络面试经验文章标签：计算机网络面试题笔试题面经计网

本文链接：https://blog.csdn.net/CrazyOnes/article/details/88382655

版权

面试经验同时被 2 个专栏收录

7 篇文章 0 订阅

订阅专栏

计算机网络

2 篇文章 0 订阅

订阅专栏

文章目录

前言

最近加入了春招的行列中，有好多东西需要学习or复习，在这里将持续整理学习、笔试和面试碰到的一些问题，希望能在巩固知识、加深印象的同时，也给大家的招聘之路带来便利，如果大家遇到了其他的经典问题，但是这里没有收录，希望大家能够通过评论等方式发给我，我会尽快的整理到集锦中。最后希望大家都能如愿找到满意的工作。by CrazyOnes

浏览器输入网址后到显示页面期间发生了什么？

同题目的不同问法：浏览器上网过程、在浏览器中键入url后的过程。
我按照四步来记忆：

DNS解析。 输入网址之后要通过域名，查询对应的ip地址，这就是DNS解析。对应ip地址的查找顺序为：浏览器缓存 → 系统缓存 → 路由器缓存 → 根DNS服务器（递归的查找）。根DNS服务器会从网址的顶级域名开始逐级向下递归的查找对应服务器，直至找到准确的域名服务器。
TCP连接。 获得IP地址之后，浏览器主机便可与服务器建立TCP连接，这期间涉及到了重要的知识点：TCP三次握手。
客户端发送请求并接受响应。 连接建立完成后，客户端就会发送HTTP请求；服务器接收到客户端的请求后，返回响应以及HTML。
渲染页面。 解析HTML页面 → 构建DOM树 → 布局DOM树 → 渲染DOM树。在解析时如果遇到外链的脚本文件、样式文件或图片，将会再次发送HTTP请求获取对应的资源，并在获得资源后立即进行处理。

TCP的三次握手

TCP的三次握手是个非常常见的考点，这里在回答的时候不能只回答客户端发起请求、服务器收到请求…这样简单，应能详细的说出关键的标志位和客户端服务器的状态变化。三次握手的过程如下：

第一次握手（请求与服务器建立连接）： Client将标志位SYN置为1，随机生成一个值 x，并令 seq = x，发送请求，并进入SYN-SENT状态。
第二次握手（确定建立连接吗？）： 服务器接收到请求，将SYN置为1，ACK置为1，随机生成一个值 y，并令seq = y，ack = x + 1，返回响应给客户端，并进入SYN-RCVD状态。
第三次握手（确认连接）： 客户端接收到服务器的响应，将ACK置为1，seq = x + 1，ack = y + 1，发送给服务器，并进入ESTABLISHED状态，服务器收到请求后也会变为ESTABLISHED状态。

TCP建立连接时为什么是三次握手而不是两次？

为了防止 已失效的链接请求报文突然又传送到了服务端，因而产生错误。

客户端发出的连接请求报文并未丢失，而是在某个网络节点长时间滞留了，以至延误到链接释放以后的某个时间才到达Server。这是，Server误以为这是Client发出的一个新的链接请求，于是就向客户端发送确认数据包，同意建立链接。若不采用“三次握手”，那么只要Server发出确认数据包，新的链接就建立了。由于client此时并未发出建立链接的请求，所以其不会理睬Server的确认，也不与Server通信；而这时Server一直在等待Client的请求，这样Server就白白浪费了一定的资源。若采用“三次握手”，在这种情况下，由于Server端没有收到来自客户端的确认，则就会知道Client并没有要求建立请求，就不会建立链接。

但是需要注意的是，上边的答案在我搜索标准答案的时候是有分歧的，具体大家可以自己搜索一下，按照以前的教材答案是这样的，所以这里就使用这个答案来作为建议答案。欢迎大家针对这个问题交流讨论。

TCP的四次挥手

第一次挥手：客户端将FIN置为1，假设当前seq为u，发送请求，并进入FIN-WAIT-1状态。
第二次挥手：服务器接收到请求，将ACK置为1，令ack = u + 1，且假设当前seq为v，返回响应，并进入CLOSE-WAIT状态。客户端收到请求进入FIN-WAIT-2状态。
第三次挥手：服务器将剩余数据发送给客户端后，将FIN置为1，ACK置为1，ack = u + 1，且假设当前seq为w，发送报文，并进入LAST-ACK状态。
第四次挥手：客户端接收到报文后，将ACK置为1，seq = u + 1，ack = w + 1，发送给服务器，并进入TIME-WAIT状态。服务器收到报文后立即进入CLOSED状态，客户端仍需等待2 * MSL（最长报文段寿命）后，才进入CLOSED状态（若第四次挥手丢失，则服务器会重新发送FIN报文，此时处于TIME-WAIT状态的客户端会重传ACK报文，也就是确保服务器连接关闭）。

TCP断开连接是不是每次都由客户端发起的？

未完全解决，下边为查资料时发现的答案，觉得比较合适就放在了这里，待确认。原问题是：如果已经建立连接，但是客户端出现故障怎么办？。

TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75分钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

服务器的端口占用的太多怎么办？

IO多路复用。（暂时没有更详细的问题和回答）

TCP和UDP的区别

连接不同：TCP是面向连接的；UDP是无连接的。
系统资源占用不同：TCP对系统的资源要求要多；UDP对系统资源占用较少。
可靠性不同：TCP提供可靠的连接服务，无差错、不丢失、不重复且按序到达；UDP尽力交付，但不保证完全可靠。
数据传输方式不同：TCP是面向字节流传输的；UDP是数据报模式。
点与点之间的关系不同：TCP只能是一对一的；UDP则可以是一对一、一对多、多对多等。

GET和POST请求的区别

GET请求产生一个TCP数据包，POST请求产生两个TCP数据包（一个不常见，但是很重要的区别）
GET请求参数通过URL传递，POST则放在Request Body中。
GET请求传输的参数是有限制的，而POST请求没有。
相对来说GET请求的安全性更低一些，GET请求参数直接在URL中暴露，而POST请求参数相对更隐蔽一些。并且在浏览器的历史纪录中，GET请求的参数会被完整的保留，而POST请求的参数则不会。
GET请求只能使用url编码且只接受ASCII字符，而POST请求对此均无限制。