大三后端暑期实习面经总结——计算机网络篇

Posted Baret-H

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了大三后端暑期实习面经总结——计算机网络篇相关的知识，希望对你有一定的参考价值。

img
博主现在大三在读，从三月开始找暑期实习，暑假准备去tx实习啦！总结下了很多面试真题，希望能帮助正在找工作的大家！相关参考都会标注原文链接，尊重原创！

目录

参考：

1. 输入网址回车经历的过程

当你的浏览器中地址栏输入地址并回车的一瞬间到页面能够展示回来，经历了什么？

1. 域名解析

当我们输入一个域名，回车时；首先检查本机的‪C:\\Windows\\System32\\drivers\\etc\\hosts)配置文件下有没有对应的域名映射

hosts文件负责将主机名映射到相应的IP地址，通常用于补充或取代网络中DNS的功能。和DNS不同的是，计算机的用户可以直接对hosts文件进行控制。

有：直接返回对应的ip地址

没有：浏览器会发出一个 DNS请求到本地DNS服务器找对应的ip地址，本地DNS服务器一般都是你的网络接入服务器商提供，比如中国电信，中国移动

  • 若域名服务器不能回答该请求，则此域名服务器就暂成为DNS中的另一个客户，向根域名服务器发出请求解析，根域名服务器一定能找到下面的所有二级域名的域名服务器，这样以此类推，一直向下解析，直到查询到所请求的域名

image-20200629165718027

2. 建立TCP连接：三次握手

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

  • 浏览器向服务器发送连接请求报文
  • 服务器接受到浏览器发送的请求报文后，为该TCP连接分配缓存和变量，并返回确认报文段，允许连接
  • 然后浏览器为该TCP连接分配缓存和变量，向服务端返回确认的确认

3. HTTP请求响应

建立好TCP连接后，浏览器通过http协议发送请求，请求数据包；

服务器处理请求，就将请求的数据返回给浏览器

4. 释放TCP连接：四次挥手

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

  • 浏览器发出连接释放报文，停止发送数据，主动关闭TCP连接
  • 服务端返回确认报文，浏览器到服务器这个方向的连接释放——半关闭
  • 服务器发送完全部的数据后，发出连接释放报文，主动关闭TCP连接
  • 浏览器返回确认报文，再等待时间等待计时器设置的2MSL（最长报文段寿命）后，连接彻底关闭

5. 浏览器显示

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

2. TCP/UDP

两者都是传输层的协议

  • TCP：传输控制协议，面向连接、点对点、可靠、提供全双工通信、面向字节流、有拥塞控制、流量控制、头部20B
  • UDP：用户数据包协议，无连接不可靠、面向报文、尽最大努力交付、无拥塞控制、首部开销小8B
  • TCP面向连接（如打电话要先拨号建立连接）;UDP是无连接的，即发送数据之前不需要建立连接。
  • TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达；UDP尽最大努力交付，即不保证可靠交付。
  • Tcp通过校验和，重传控制，序号标识，滑动窗口、确认应答实现可靠传输。如丢包时的重发控制，还可以对次序乱掉的分包进行顺序控制。
  • UDP具有较好的实时性，工作效率比TCP高，适用于对高速传输和实时性有较高的通信或广播通信。
  • 每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信。
  • TCP对系统资源要求较多，UDP对系统资源要求较少。

3. TCP拥塞控制

慢开始&拥塞避免

起始时，拥塞窗口cwnd为1，然后每经过一个RTT传输轮次，拥塞窗口大小以2的指数增长，直到拥塞窗口大小为ssthresh慢开始门限，即进入拥塞避免阶段，拥塞窗口随RTT线性增长每次+1，直到到达网络拥塞状态，将拥塞窗口大小置为1，慢开始门限置为原来的1/2；以此往复

快重传&快恢复

起始时，拥塞窗口cwnd为1，然后每经过一个RTT，拥塞窗口大小以2的制数形式增长，直到到慢开始门限，开始线性增长；在收到三个冗余的ACK后，执行快重传算法：慢开始门限降为拥塞窗口的1/2，再重新线性增长，以此往复；

4. TCP流量控制

采用滑动窗口机制，接收方根据自己的接收缓存大小，动态的调整发送方发送窗口的大小

  • 接收窗口rwnd
  • 拥塞窗口cwnd

发送窗口取决于rwnd和cwnd的最小值

5. HTTP和HTTPS的区别

HTTP（HyperText Transfer Protocol：超文本传输协议）

  • 基于 TCP/IP 通信协议
  • 用于 B/S 架构
  • 默认工作在 TCP 协议 80 端口
  • HTTP 协议以明文方式发送内容，不提供任何方式的数据加密，如果攻击者截取了Web浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息，因此，HTTP协议不适合传输一些敏感信息，比如：信用卡号、密码等支付信息

HTTPS（Hypertext Transfer Protocol Secure：超文本传输安全协议）是一种透过计算机网络进行安全通信的传输协议。

  • 基于 HTTP 进行通信，但利用 SSL/TLS 来加密数据包。

    SSL(Secure Sockets Layer 安全套接字协议),及其继任者传输层安全（Transport Layer Security，TLS）是为网络通信提供安全及数据完整性的一种安全协议。TLS与SSL在传输层与应用层之间对网络连接进行加密。

  • HTTPS 开发的主要目的，是提供对网站服务器的身份认证，保护交换数据的隐私与完整性。

  • 默认工作在 TCP 协议 443 端口，它的工作流程一般如以下方式：

    1、TCP 三次同步握手

    2、客户端验证服务器数字证书

    3、DH 算法协商对称加密算法的密钥、hash 算法的密钥

    4、SSL 安全加密隧道协商完成

    5、网页以加密的方式传输，用协商的对称加密算法和密钥加密，保证数据机密性；用协商的hash算法进行数据完整性保护，保证数据不被篡改。

区别

  • HTTP 明文传输，数据都是未加密的，安全性较差，HTTPS（SSL+HTTP） 数据传输过程是加密的，安全性较好。
  • 使用 HTTPS 协议需要到 CA（Certificate Authority，数字证书认证机构） 申请证书，一般免费证书较少，因而需要一定费用。证书颁发机构如：Symantec、Comodo、GoDaddy 和 GlobalSign 等。
  • HTTP 页面响应速度比 HTTPS 快，主要是因为 HTTP 使用 TCP 三次握手建立连接，客户端和服务器需要交换 3 个包，而 HTTPS除了 TCP 的三个包，还要加上 ssl 握手需要的 9 个包，所以一共是 12 个包。
  • http 和 https 使用的是完全不同的连接方式，用的端口也不一样，前者是 80，后者是 443。
  • HTTPS 其实就是建构在 SSL/TLS 之上的 HTTP 协议，所以，要比较 HTTPS 比 HTTP 要更耗费服务器资源。

6. OSI七层参考模型

image-20201125232106589
  1. 应用层：网络服务与最终用户的一个接口。
  2. 表示层：数据的表示、安全、压缩。
  3. 会话层：建立、管理、终止会话。
  4. 传输层：定义传输数据的协议端口号，以及流控和差错校验。
  5. 网络层：进行逻辑地址寻址，实现不同网络之间的路径选择。
  6. 数据链路层：建立逻辑连接、进行硬件地址寻址、差错校验等功能。
  7. 物理层：建立、维护、断开物理连接。

7. http1.0、1.1、2.0、3.0的区别

HTTP1.0

  • 1996年引入
  • 仅提供了最基本的认证，用户名和密码都未加密
  • 仅支持短连接，每次发送数据都会经过TCP三次握手和四次挥手，效率低
  • 只使用了header的if=modified-Since和Expires作为缓存失效的标准
  • 不支持断点续传，每次发送数据都会发送全部数据
  • 认为每台计算机都只能绑定一个IP地址，不支持虚拟网络

HTTP1.1

  • 1999年引入
  • 使用了摘要算法进行身份验证
  • 默认使用长连接：只需要建立一次连接，可以传输多次数据，传输完成之后，只需要一次切断即可。通过请求头的keep-alive设置
  • 支持断点续传(状态码206)，通过请求头的Range实现
  • 使用了虚拟网络，在一台物理服务器上可以存在多个虚拟主机，共享一个IP地址

HTTP2.0

  • 2015年建立
  • 头部压缩：利用HPACK算法进行压缩，由于HTTP1.1头部经常出现Cookie、Accept、Sever、Range等字段可能会占用几百到几千字节，而body有时只有几十字节（头重身轻）
  • 二进制格式：HTTP2.0选择了更靠近TCP/IP的二进制格式，抛弃了ASCII码，提高了解析效率
  • 强化安全：HTTP2.0一般都跑在HTTPS上
  • 多路复用：一个连接上可以有多个请求

HTTP3.0

  • 基于google的QUIC协议，而quic协议是使用udp实现的
  • 减少了tcp三次握手时间，以及tls握手时间
  • 解决了http 2.0中前一个stream丢包导致后一个stream被阻塞的问题
  • 优化了重传策略，重传包和原包的编号不同，降低后续重传计算的消耗
  • 连接迁移，不再用tcp四元组确定一个连接，而是用一个64位随机数来确定这个连接
  • 更合适的流量控制

HTTP1.0和HTTP1.1的区别

  1. 长连接(Persistent Connection)

    HTTP1.1支持长连接和请求的流水线处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟，在HTTP1.1中默认开启长连接keep-alive，一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。HTTP1.0需要使用keep-alive参数来告知服务器端要建立一个长连接。

  2. 节约带宽

    HTTP1.0中存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能。HTTP1.1支持只发送header信息（不带任何body信息），如果服务器认为客户端有权限请求服务器，则返回100，客户端接收到100才开始把请求body发送到服务器；如果返回401，客户端就可以不用发送请求body了节约了带宽。

  3. HOST域

    在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname），HTTP1.0没有host域。随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都支持host域，且请求消息中如果没有host域会报告一个错误（400 Bad Request）。

  4. 缓存处理

    在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。

  5. 错误通知的管理

    在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。

HTTP1.1和HTTP2.0的区别

  1. 多路复用

    HTTP2.0使用了多路复用的技术，做到同一个连接并发处理多个请求，而且并发请求的数量比HTTP1.1大了好几个数量级。HTTP1.1也可以多建立几个TCP连接，来支持处理更多并发的请求，但是创建TCP连接本身也是有开销的。

  2. 头部数据压缩

    在HTTP1.1中，HTTP请求和响应都是由状态行、请求/响应头部、消息主体三部分组成。一般而言，消息主体都会经过gzip压缩，或者本身传输的就是压缩过后的二进制文件，但状态行和头部却没有经过任何压缩，直接以纯文本传输。随着Web功能越来越复杂，每个页面产生的请求数也越来越多，导致消耗在头部的流量越来越多，尤其是每次都要传输UserAgent、Cookie这类不会频繁变动的内容，完全是一种浪费。

    HTTP1.1不支持header数据的压缩，HTTP2.0使用HPACK算法对header的数据进行压缩，
这样数据体积小了，在网络上传输就会更快。

  3. 服务器推送

    服务端推送是一种在客户端请求之前发送数据的机制。网页使用了许多资源：html、样式表、脚本、图片等等。在HTTP1.1中这些资源每一个都必须明确地请求。这是一个很慢的过程。浏览器从获取HTML开始，然后在它解析和评估页面的时候，增量地获取更多的资源。因为服务器必须等待浏览器做每一个请求，网络经常是空闲的和未充分使用的。

    为了改善延迟，HTTP2.0引入了server push，
它允许服务端推送资源给浏览器，在浏览器明确地请求之前，免得客户端再次创建连接发送请求到服务器端获取。
这样客户端可以直接从本地加载这些资源，不用再通过网络。

8. http常见状态码

状态码的职责是当客户端向服务器端发送请求时，描述返回的请求结果。借助状态码，用户可以知道服务器端是正常处理了请求，还是出现了错误。
image-20210508173305456

2XX 成功

  • 200 ok（请求成功）
  • 204 no content（请求成功，但是没有结果返回）
  • 206 partial content（客户端请求一部分资源，服务端成功响应，返回一范围资源）

3XX 重定向

  • 301 move permanently（永久性重定向）
  • 302 found（临时性重定向）
  • 303 see other（表示请求的资源被分配了新的URL，应使用GET方法定向获取请求的资源）
  • 304 not modified （表示在客户端采用带条件的访问某资源时，服务端找到了资源，但是这个请求的条件不符合。跟重定向无关）
  • 307 temporary redirect （跟302一个意思）

4XX 客户端错误

  • 400 bad request （请求报文存在语法错误）
  • 401 unauthorized （需要认证（第一次返回）或者认证失败（第二次返回））
  • 403 forbidden （请求被服务器拒绝了）
  • 404 not found （服务器上无法找到请求的资源）

5XX 服务器错误

  • 500 internal server error （服务端执行请求时发生了错误）
  • 503 service unavailable （服务器正在超负载或者停机维护，无法处理请求）

8. TCP真的可靠吗

面试官经常会问的一个问题是，如果TCP服务器宕机了，会发生什么？换句话说，TCP真的可靠吗？

这个问题需要从两个方面回答：

  1. TCP是个可靠的协议，通过序号和超时重传保证了端到端的可靠。
  2. TTCP并不能保证应用层的可靠。

TCP如何保证可靠性？

首先，我们看看数据报不可靠有哪些问题，以及TCP是怎么解决的？

  1. 差错：TCP通过首部的校验和，可以校验首部和和数据。这是一种端到端的校验，目的是检测数据在传输过程中的任何变化，如果收到对端的校验和有差错，TCP将这个包丢弃并且不确认。

  2. 丢包：TCP发出一个数据包后，启动一个定时器，等待对端确认收到这个数据包，如果不能及时收到这个确认，将重发这个报文。

  3. 失序：TCP承载于IP数据包来传输，IP包的到达可能会失序，因此TCP数据包的到达也可能失序，TCP对收到的数据包按照首部的序列号进行重新排序。

  4. 重复：IP数据包会发生重复，TCP接收端根据TCP首部的序列号将重复的数据丢弃。

此外，确认数据包，也不能是确认了一个数据包再发送下一个数据包，这不利于并行的批量发送，我们可以批量的发送，再批量的确认。这里有两个问题需要考虑：1.接收方的处理能力，2.网络的处理能力。

  1. 先来看看接收方的处理能力。当接收方的硬件能力不如发送方，或者是系统繁忙，那发送过去的报文只能丢弃。要限制发送方的发送速度，接收方就要告诉发送方它的处理能力，好让发送发方限制它的发送速度就可以了，这就是滑动窗口的由来。

  2. 下面来看看网络处理能力。如果发送TCP数据包的速度快于中间某个路由器的发速度，路由器就开始丢包。导致较高的丢包率，如果TCP继续保持这个速度送数据，那么网络的性能就会极大的降低。这就需要拥塞控制算法。它分为两分，一个是慢启动，一个是拥塞避免。

    慢启动指的就是TCP在一开始发送数据的时候以低速传输，只要能够得到对应报文的ACK，就以指数级的速度提高速率。当增长到一个阈值时，增长速度就变成线性增长，而不是指数级的。或者是丢包严重了，说明网络出现拥塞，要降低发送速率，进入拥塞避免阶段。

TCP并不能保证它所发送数据的可靠传输

可靠指的是什么，不可靠指的是什么？

上面我们讨论了TCP通过很多机制保证可靠，**这种可靠只是在端到端的通信上。**假设数据从A进程送到B进程，数据从A进程通过它所在主机TCP/IP协议栈向下传输，经过若干台路由器，通过进程B所在主机的TCP/IP协议栈向上传输，最后到达B进程。这些路由器没有TCP层，只是转发IP数据报，IP是个不可靠的协议。

image-20210504170600259

TCP能够向进程B保证所有到达的数据是按序且未受损的。但有个问题，**TCP已经ACK的数据包实际上不一定会抵达应用进程。**比如，接收端TCP刚对数据进行ACK，但应用程序还没有读走，就崩溃了。

9. TCP重要报头字段

TCP为了保证可靠的传输，设计了复杂的头部

image-20210504172656056

  • 源端口和目的端口：主要是决定数据发给哪个应用程序的。

  • 序列号：序号主要是为了解决乱序问题。

  • 确认号：发送出去的包都需要确认，如果没有收到对方的确认包，就重新发送，直到送达。

  • 首部长度：TCP头部的大小。

  • 标志位：

    • CWR：拥塞窗口减少。
    • ECE：显示拥塞提醒回应。
    • URG：紧急指针。
    • ACK：设置为1时，确认号有效。
    • PSH：设置为1时，接收方应尽快将这个报文交给应用层。
    • RST：为1时，表示出现严重差错，必须释放连接，重连。
    • SYN：为1时，发起一个连接。
    • FIN：为1时，关闭一个连接。

  • 窗口大小：主要用于流量控制。

  • 校验和：对TCP头和数据进行校验。

  • 紧急指针：当URG位为1，这个指针有效。

10. TCP三次握手&四次挥手

image-20201226221528564

  • 浏览器向服务器发送连接请求报文
  • 服务器接受到浏览器发送的请求报文后，为该TCP连接分配缓存和变量，并返回确认报文段，允许连接
  • 然后浏览器为该TCP连接分配缓存和变量，向服务端返回确认的确认

image-20201226223519663

  • 浏览器发出连接释放报文，停止发送数据，主动关闭TCP连接
  • 服务端返回确认报文，浏览器到服务器这个方向的连接释放——半关闭
  • 服务器发送完全部的数据后，发出连接释放报文，主动关闭TCP连接
  • 浏览器返回确认报文，再等待时间等待计时器设置的2MSL（最长报文段寿命）后，连接彻底关闭

11. 为什么要三次握手，四次挥手？

为什么建立连接是三次握手，四次不可以吗

# 第一次握手
Client什么都不能确认   
Server确认了对方发送正常

# 第二次握手
Client确认：自己发送/接收正常，对方发送/接收正常
Server确认：自己接收正常 ，对方发送正常

# 第三次握手
Client确认：自己发送/接收正常， 对方发送/接收正常
Server确认：自己发送/接收正常，对方发送/接收正常

所以通过三次握手确认双方收发功能都正常，四次也可以但是显得比较多余

如果两次握手会怎么样

防止已失效的连接请求又传送到服务器端，因而产生错误

有这样一种情况，当A发送一个消息给B，但是由于网络原因，消息被阻塞在了某个节点，然后阻塞的时间超出设定的时间，A会认为这个消息丢失了，然后重新发送消息，然后AB正常连接通信，当A和B通信完成后并释放连接后，这个被A认为失效的消息，到达了B，对于B而言，以为这是一个新的请求链接消息，就向A发送确认，对于A而言，它认为没有给B再次发送消息（因为上次的通话已经结束）所有A不会理睬B的这个确认，但是B则会一直等待A的消息，这就导致了B的时间被浪费（对于服务器而言，CPU等资源是一种浪费），这样是不可行的，这就是为什么不能两次握手的原因了。

为什么是四次挥手，而不是三次

因为TCP是一个全双工协议，必须单独拆除每一条信道。如果是三次挥手，服务端在收到FIN消息之后，需要同时回复ACK和Server端的FIN消息，如果服务端在该连接上面并没有额外的消息要处理，那么是可以的，如果服务端还有其他的消息待传送，那么这样的三次挥手就不能满足条件

为什么四次挥手最后要等待2MSL

  1. 为实现TCP这种全双工连接的可靠释放

    这样可让TCP再次发送最后的ACK以防这个ACK丢失(另一端超时并重发最后的FIN)这种2MSL等待的另一个结果是这个TCP连接在2MSL等待期间，定义这个连接的插口(客户的IP地址和端口号，服务器的IP地址和端口号)不能再被使用。这个连接只能在2MSL结束后才能再被使用。

  2. 为使旧的数据包在网络因过期而消失

    每个具体TCP实现必须选择一个报文段最大生存时间MSL，它是任何报文段被丢弃前在网络内的最长时间，一来一回就是2MSL

12. TCP粘包怎么产生的

1️⃣ 发送方产生粘包

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

image-20210513180627862

2️⃣ 接收方产生粘包

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

image-20210513180723344

以上是关于大三后端暑期实习面经总结——计算机网络篇的主要内容，如果未能解决你的问题，请参考以下文章

大三后端暑期实习面经总结——MySQL篇

大三后端暑期实习面经总结——MySQL篇

大三Java后端暑期实习面经总结——Java容器篇

大三Java后端暑期实习面经总结——Java容器篇

大三Java后端暑期实习面经总结——JVM篇

大三Java后端暑期实习面经总结——JVM篇