Java实习生每日面试题打卡——计算机网络篇

Posted 2021-06-21 兴趣使然の草帽路飞

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Java实习生每日面试题打卡——计算机网络篇相关的知识，希望对你有一定的参考价值。

临近秋招，备战暑期实习，祝大家每天进步亿点点！Day14
本篇总结的是 计算机网络 相关的面试题，后续会每日更新~
文章参考自：硬核！30 张图解 HTTP 常见的面试题、JAVA开发面试题_网络_操作系统、计算机网络面试题、JavaGuide

在这里插入图片描述

1、OSI 七层结构、TCP/IP 四层结构、五层协议结构

OSI 七层：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层。
TCP/IP 四层：网络接口层、网际层、运输层、应用层。
五层协议：物理层、数据链路层、网络层、运输层、应用层。

注：按照由下至上的顺序。

OSI 七层参考模型，每一层的作用：

对应的层	作用	对应的网络协议/硬件
物理层	提供数据传输的硬件保证，网卡接口，传输介质。	中继器、集线器、网关.
数据链路层	进行数据交换，将要传输的数据转换为二进制形式。	网卡、网桥、交换机
网络层	进行路由选择，网络互联。	IP、ICMP、…
传输层	用于端到端的可靠数据传输。	TCP 、UDP、…
会话层	用于建立用户级的连接，选择适当的传输服务。	SQL、RPC、…
表示层	用于对数据的压缩、加密。	JPEG、MPEG、ASII、…
应用层	提供用户服务，具体功能由应用程序实现。	SMTP、HTTP、DNS、…

2、TCP 和 UDP 的区别？基于 TCP、UDP 的协议有哪些？

TCP 和 UDP 的区别？

TCP 提供面向连接的、可靠的数据流传输，而 UDP 提供的是无连接的、不可靠的数据流传输。
TCP 只能一对一通信，而 UDP 支持一对一、一对多、多对一、多对多通信。
TCP 传输单位称为 TCP 报文段，UDP 传输单位称为用户数据报。
TCP 注重数据安全性，UDP 数据传输快，因为不需要连接等待，少了许多操作，但是其安全性却一般。

面向连接与非面向连接区别？

面向连接的服务，通信双方在进行通信之前，要先在双方建立起一个完整的可以彼此沟通的通道，在通信过程中，整个连接的情况一直可以被实时地监控和管理。
非面向连接地服务，不需要预先建立一个联络两个通信节点地连接，需要通信地时候，发送节点就可以往网络上发送信息，让信息自主地在网络上去传，一般在传输地过程中不再加以监控。

基于 TCP、UDP 的协议有哪些？

基于 TCP 的协议：

HTTP：Web服务器传输超文本到本地浏览器的传送协议。
SMTP：邮件传送协议，用于发送邮件。服务器开放的是 25 号端口。
FTP：定义了文件传输协议，使用21 端口。
…

基于 UDP 的协议：

DNS：用于域名解析服务，将域名地址转换为 IP 地址。DNS 用的是53号端口。
…

TCP 与 UDP 的适用场景：

TCP：当对网络通讯质量有要求的时候，比如：整个数据要准确无误的传递给对方，HTTP、HTTPS、FTP等传输文件的协议会使用到。

UDP：当强调传输性能而不是传输的完整性时，要求网络通讯速度能尽量的快：如 QQ语音，QQ视频等。

3、TCP 协议如何保证可靠传输？

TCP 通过以下几种措施来保证数据的可靠传输：

① 对应用数据进行分割：将应用数据被分割成 TCP 认为最适合发送的数据块。
② 对数据包进行编号：TCP 给要发送的每一个数据包进行编号，接收方按照编号对数据包进行排序，把有序数据传送给应用层。
③ 校验和：这是一个端到端的校验，目的是检测数据在传输过程中的任何变化。如果接受端的校验有差错，说明数据在传输过程中出问题了，接收端将丢弃不再接受该数据。
④ 流量控制： TCP 连接的每一方都有固定大小的缓冲空间，TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。TCP 使用的流量控制协议是可变大小的滑动窗口协议。（TCP 利用滑动窗口实现流量控制）
⑤ 拥塞控制：当网络拥塞时，减少数据的发送。防止过多的数据注入到网络中，避免传输链路过载。
⑥ ARQ协议：该协议也是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组。
⑦ 超时重传：当 TCP 发出一个报文段后，它启动一个定时器，等待接收端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。

滑动窗口和流量控制：

TCP利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率，保证接收方来得及接收。

接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为 0，则发送方不能发送数据。

TCP如何实现拥塞控制？

为了进行拥塞控制，TCP 发送方要维持一个 拥塞窗口(cwnd) 的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度，并且动态变化。发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的一个。

TCP的拥塞控制采用了四种算法，即 慢开始、拥塞避免 、快重传 和 快恢复。

慢开始：慢开始算法的思路是当主机开始发送数据时，如果立即把大量数据字节注入到网络，那么可能会引起网络阻塞，因为现在还不知道网络的符合情况。经验表明，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是由小到大逐渐增大拥塞窗口数值。cwnd初始值为1，每经过一个传播轮次，cwnd加倍。
拥塞避免：拥塞避免算法的思路是让拥塞窗口cwnd缓慢增大，即每经过一个往返时间RTT就把发送放的cwnd加1.
快重传与快恢复：在 TCP/IP 中，快速重传和恢复（fast retransmit and recovery，FRR）是一种拥塞控制算法，它能快速恢复丢失的数据包。没有 FRR，如果数据包丢失了，TCP 将会使用定时器来要求传输暂停。在暂停的这段时间内，没有新的或复制的数据包被发送。有了 FRR，如果接收机接收到一个不按顺序的数据段，它会立即给发送机发送一个重复确认。如果发送机接收到三个重复确认，它会假定确认件指出的数据段丢失了，并立即重传这些丢失的数据段。有了 FRR，就不会因为重传时要求的暂停被耽误。　当有单独的数据包丢失时，快速重传和恢复（FRR）能最有效地工作。当有多个数据信息包在某一段很短的时间内丢失时，它则不能很有效地工作。

4、什么是 TCP 粘包，它的产生原因以及解决方法？

TCP 粘包是指：发送方发送的若干个包数据到接收方接收时，粘成一个包数据。
TCP 是基于字节流的，虽然应用层和 TCP 传输层之间的数据交互是大小不等的数据块，但是 TCP 把这些数据块仅仅看成一连串无结构的字节流，没有边界，这就可能导致字节流合并（粘包）。

TCP 粘包产生的原因：

① 发送方产生的粘包

采用 TCP 协议传输数据的客户端与服务器经常是保持一个长连接的状态（一次连接发一次数据不存在粘包），双方在连接不断开的情况下，可以一直传输数据。但当发送的数据包过于的小时，那么 TCP 协议默认的会启用 Nagle 算法，将这些较小的数据包进行合并发送（缓冲区数据发送是一个堆压的过程）；这个合并过程就是在发送缓冲区中进行的，也就是说数据发送出来它已经是粘包的状态了。
总结：要发送的数据小于 TCP 发送缓冲区的大小，TCP 将多次写入缓冲区的数据一次发送出去，将会发生粘包。

② 接受方产生的粘包

接收方采用 TCP 协议接收数据时的过程是这样的：数据到接收方，从网络模型的下方传递至传输层，传输层的 TCP 协议处理是将其放置接收缓冲区，然后由应用层来主动获取（例如C 语言用函数等）；这时会出现一个问题，就是我们在程序中调用的读取数据函数不能及时的把缓冲区中的数据拿出来，而下一个数据又到来并有一部分放入的缓冲区末尾，等我们读取数据时就是一个粘包。（放数据的速度 > 应用层拿数据速度）。
总结：接收数据端的应用层没有及时读取缓冲区中的数据，导致缓冲区数据堆积，将发生粘包。

如何避免粘包？

避免粘包有以下两种方式：

在每个包的末尾加上特殊字符，用以区分连续的两个包。（例如加\\r\\n标记）
在报文首部添加包的长度。

5、TCP 三次握手和四次挥手

为了准确无误地把数据送达目标处，TCP 协议采用了三次握手策略。
建立一个 TCP 连接需要"三次握手"。

5.1、三次握手图解

如下图所示，下面的两个机器人通过 3 次握手确定了对方能正确接收和发送消息：

上图流程为：

一次握手：客户端发送带有 SYN 标志的数据包给服务端。
二次握手：服务端发送带有 SYN/ACK 标志的数据包给客户端。
三次握手：客户端发送带有带有 ACK 标志的数据包给服务端。

5.2、为什么要三次握手？

三次握手的目的是建立可靠的通信信道，说到通讯，简单来说就是数据的发送与接收，而三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。

第一次握手：是为了服务端确认对方 (客户端) 发送数据正常，自己接收数据正常。
第二次握手：是为了客户端确认自己发送、接收数据正常，同时客户端也知道了对方 (服务端) 发送、接收数据都正常。
第三次握手：是为了让服务端确认自己发送、接收数据正常，同时服务端也知道了对方 (客户端) 发送、接收数据正常。

所以三次握手为了让客户端和服务端双方，互相都知道自己和对方发送、接收功能都正常，缺一不可。

5.3、第二次握手服务端传回了 ACK 为什么还要传回 SYN ？

服务端端传回发送端所发送的 ACK 是为了告诉客户端，我接收到的信息确实就是你所发送的信号了，这表明从客户端到服务端的通信是正常的。而回传 SYN 则是为了建立从服务端到客户端的通信。

SYN 同步序列编号(Synchronize Sequence Numbers) 是 TCP/IP 建立连接时使用的握手信号。在客户机和服务器之间建立正常的 TCP 网络连接时，客户机首先发出一个 SYN 消息，服务器使用 SYN-ACK 应答表示接收到了这个消息，最后客户机再以 ACK(Acknowledgement）消息响应。这样在客户机和服务器之间才能建立起可靠的 TCP 连接，数据才可以在客户机和服务器之间传递。

5.4 为什么要四次挥手？

如图所示：

断开一个 TCP 连接则需要“四次挥手”：

第一次挥手：客户端发送一个 FIN 数据包给服务端，用来告诉服务端，我要关闭与你的 TCP 连接。(客户端主动关闭到服务器的数据传输，但此时客户端还能接收服务端传来的数据)
服务端收到这个 FIN 数据包后，它返回一个 ACK 数据包给客户端，确认序号为收到的序号加 1 （和 SYN 一样，一个 FIN 将占用一个序号），目的是告诉客户端，我收到了你的关闭连接请求。
服务端主动关闭到客户端的连接，并发送一个FIN 数据包给客户端，告诉客户端我也关闭了和你的 TCP 连接。(服务端不会再给客户端发送数据了)
客户端收到服务端返回的 FIN 数据包后，再发送一个 ACK 数据包给服务端确认，并将确认序号设置为收到序号加 1。

5.5、如果已经建立了连接，但是客户端突然出现故障了怎么办？

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

6、在浏览器中输入URL 地址，回车后经历了那些过程

所经历的过程：DNS 域名解析、TCP 连接、发送 HTTP 请求、服务器处理请求并返回 HTTP 报文、浏览器渲染、结束。

下面来逐步分析一下：

① DNS 域名解析

当我们在浏览器中输入一个域名然后回车时，首先检查本机的‪C:\\Windows\\System32\\drivers\\etc\\hosts配置文件下有没有对应的域名映射，如下所示：

# 前台本机域名映射
127.0.0.1:80 web.csp1999.com
    
# 后端接口本机域名映射
127.0.0.1:8080 api.csp1999.com

如果有，则返回对应的 IP 地址。

如果没有，浏览器会发出一个 DNS 请求到本地DNS服务器找对应的 IP 地址，本地 DNS 服务器一般都是你的网络接入服务器商提供，比如中国电信，中国移动：（图片来源：https://blog.csdn.net/qq_45173404/article/details/117396953）

② 建立 TCP 连接：三次握手

解析出 IP 地址后，浏览器根据 IP 地址和默认端口 443 向网站的服务器发起请求，三次握手，建立 TCP 连接。

③ 发送 HTTP 请求

建立好 TCP 连接后，浏览器 (客户端) 通过 HTTP 协议发送请求，请求从服务器端获取数据。
服务器处理客户端的 HTTP 请求后，就将请求的数据返回给浏览器。

④ 关闭 TCP 连接：四次挥手

浏览器与服务器数据传送完毕后，四次握手，释放 TCP 连接。

⑤ 浏览器回显

浏览器对数据进行解析并渲染显示。

7、什么是HTTP协议？

HTTP的概念：

HTTP 是超文本传输协议，用于客户端和服务器端之间的通信，即在「两点」之间「传输」文字、图片、音频、视频等「超文本」数据的「约定和规范」。

HTTP 的特性(优点)：

HTTP 最凸出的优点是「简单、灵活和易于扩展、应用广泛和跨平台」。

HTTP的常见字段：

① Host 字段

客户端发送请求时，用来指定服务器的域名。

Host: www.A.com

有了 Host 字段，就可以将请求发往「同一台」服务器上的不同网站。

② Content-Length 字段

服务器在返回数据时，会有 Content-Length 字段，表明本次响应的数据长度。

Content-Length: 1000

如上面则是告诉浏览器，本次服务器回应的数据长度是 1000 个字节，后面的字节就属于下一个回应了。

③ Connection 字段

Connection 字段最常用于客户端要求服务器使用 TCP 持久连接，以便其他请求复用。

HTTP/1.1 版本的默认连接都是持久连接，但为了兼容老版本的 HTTP，需要指定 Connection 首部字段的值为 Keep-Alive。

Connection: keep-alive

一个可以复用的 TCP 连接就建立了，直到客户端或服务器主动关闭连接。但是，这不是标准字段。

④ Content-Type 字段

Content-Type 字段用于服务器回应时，告诉客户端，本次数据是什么格式。

Content-Type: text/html; charset=utf-8

上面的类型表明，发送的是网页，而且编码是UTF-8。

客户端请求的时候，可以使用 Accept 字段声明自己可以接受哪些数据格式。

Accept: */*

上面代码中，客户端声明自己可以接受任何格式的数据。

⑤ Content-Encoding 字段

Content-Encoding 字段说明数据的压缩方法。表示服务器返回的数据使用了什么压缩格式。

Content-Encoding: gzip

上面表示服务器返回的数据采用了 gzip 方式压缩，告知客户端需要用此方式解压。

客户端在请求时，用 Accept-Encoding 字段说明自己可以接受哪些压缩方法。

Accept-Encoding: gzip, deflate

8、GET 和 POST 的区别？

URL 中参数可见性：GET 参数可见（通过拼接 URL 进行传递参数），POST 参数不可见。
是否可缓存：GET 请求是可以缓存的，POST 请求不可以缓存。
传输数据的大小：GET 一般传输数据大小不超过 2k-4k（根据浏览器不同，限制不一样，但相差不大），POST 请求传输数据的大小根据 php.ini 配置文件设定，也可以无限大。
安全性：GET 不安全，POST 安全。
数据包个数：GET 产生一个 TCP 数据包；POST 产生两个 TCP 数据包。

9、HTTP 的优缺点

HTTP 协议的特性「无状态、明文传输」既是优点也是缺点，同时还有一大缺点「不安全」。

① 无状态协议的优缺点：

无状态的好处：服务器不用去记忆 HTTP 的状态，不需要额外的资源来记录状态信息，这能减轻服务器的负担，能够把更多的 CPU 和内存资源用在对外提供服务上。
无状态的坏处：服务器没有记忆能力，它在完成有关联性的操作时会非常麻烦。
- 例如登录 -> 添加购物车 -> 下单 -> 结算 -> 支付，这系列操作都要知道用户的身份才行。但服务器不知道这些请求是有关联的，每次都要确认一遍用户身份信息。

对于无状态的问题，解法方案有很多种，其中比较简单的方式用 Cookie 技术。

Cookie 通过在请求和响应中写入 Cookie 信息来控制客户端的状态。相当于，在客户端第一次请求后，服务器会下发一个带有客户身份信息的「小贴纸」，后续客户端请求服务器的时候，带上「小贴纸」，服务器就能试别了：

② 明文传输的优缺点：

明文意味着在传输过程中的信息，是可方便阅读的，通过浏览器的 F12 控制台或 Wireshark 抓包都可以直接肉眼查看，为我们调试工作带了极大的便利性。
但是这正是这样，HTTP 的所有信息都暴露在了光天化日下，相当于信息裸奔。在传输的漫长的过程中，信息的内容都毫无隐私可言，很容易就能被窃取，如果里面有你的账号密码信息，那你号没了。

10、HTTP 和 HTTPS 的区别是什么？

① 安全性区别：HTTP 是超文本传输协议，信息是明文传输，存在安全风险的问题。HTTPS 可以保证信息传输安全，在 TCP 和 HTTP 网络层之间加入了 SSL/TLS 安全协议，使得报文能够加密传输。
② 建里连接流程区别：HTTP 连接建立相对简单， TCP 三次握手之后便可进行 HTTP 的报文传输。而 HTTPS 在 TCP 三次握手之后，还需进行 SSL/TLS 的握手过程，才可进入加密报文传输。
③ 端口区别：HTTP 的端口号是 80，HTTPS 的端口号是 443。
④ 是否需要申请数字证书：HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的。而 HTTP 协议不需要。

混合加密：

HTTPS 采用对称加密和非对称加密结合的「混合加密」方式，将服务器公钥放到数字证书中，来解决窃听风险。

在通信建立前采用非对称加密的方式交换「会话秘钥」，后续就不再使用非对称加密。
在通信过程中全部使用对称加密的「会话秘钥」的方式加密明文数据。

摘要算法：

HTTPS 采用摘要算法来确保数据的完整性，解决了数据被篡改的风险。
摘要算法能够为数据生成独一无二的「标识」，用于校验数据的完整性，从而解决了篡改的风险。

HTTPS 在 HTTP 与 TCP 层之间加入了 SSL/TLS 协议，如图：

11、Cookie 的作用是什么？和 Session 有什么区别?

Cookie 和 Session 的作用：

Cookie 和 Session都是用来跟踪浏览器用户身份的会话方式，但两者有所区别：

Cookie 一般用来保存用户信息。比如我们在 Cookie 中保存已经登录过得用户信息，下次访问网站的时候页面可以自动帮你登录的一些基本信息给填了；
**Session 的主要作用就是通过服务端记录用户的状态。**典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了。

Cookie 和 Session 的区别如下：

Cookie 数据保存在客户端，Session 数据保存在服务器端。
Cookie 存储在客户端中，而Session存储在服务器上，相对来说 Session 安全性更高。如果要在 Cookie 中存储一些敏感信息，不要直接写入 Cookie 中，最好能将 Cookie 信息加密然后使用到的时候再去服务器端解密。
Cookie ⼀般⽤来保存⽤户信息，Session 的主要作用就是通过服务端记录用户的状态。

12、URI 和 URL 的区别是什么？

URI：是统一资源标志符，可以唯一标识一个资源。
- 例如：如：https://blog.csdn.net/qq_32595453/article/details/79516787
URL：是统一资源定位符，可以提供该资源的路径。URL 是 URI 的一个子集，它不仅唯一标识资源，而且还提供了定位该资源的信息。

URI 的作用像身份证号一样，URL 的作用更像家庭住址一样。

13、HTTP 1.0 、 HTTP 1.1 、HTTP 2.0 的主要区别是什么？

HTTP 1.0：默认使用短连接，浏览器每次请求都需要与服务器建立一次 TCP 连接，服务器处理完成后立即断开 TCP 连接（无连接），服务端不记录客户端的请求状态（无状态）。
HTTP 1.1：默认使用长连接，用以保持连接特性。使用长连接的 HTTP 协议，会在响应头加入这行代码：
```
// Keep-Alive不会永久保持连接，它有一个持续时间，可以在不同的服务器软件中设定这个时间。
// 实现长连接需要客户端和服务端都支持长连接。
Connection:keep-alive
```
在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输 HTTP 数据的 TCP 连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。
HTTP 2.0：引入二进制数据帧和流的概念，支持多路复用、服务器推送，支持使用二进制格式传输数据，而 HTTP 1.0 依然使用文本格式传输。