【复习整理归纳】| C++面经(网络相关)

计算机网络

1 性能指标

【吞吐量】:单位时间内通过某个网络的数据量;

  • 单位:b/s;
  • 受带宽和额定速率的限制;

【时延】:数据从网络的一端传到另一端所需的时间;
【发送时延】:数据在机器中从第一个bit到最后一个bit进入链路中的时间;(数据长度/信道带宽)
【传播时延】:在信道传播的时间,取决电磁波传播速度链路长度;(信道长度/电磁波在信道传播速率)
【排队时延】:等待输入出/入链路可用;
【处理时延】:检查找出口;

【往返时间RTT】:从发送方发送数据开始,到发送方收到接收方的确认(接收方收到数据后立即发送确认)总共经历的时延;

  • RTT越大,在收到数据前,可以发送的数据越多;
  • (往返传播时延=传播时延*2 + 末端处理时间)

2 计算机在发送文件前需要做许多前期的工作

  • 需要对数据通路进行激活
  • 告诉网络如何识别目的主机
  • 查明主机是否开机网络连接是否正常;
  • 对方文件管理程序是否就绪
  • 确保差错和意外可以解决;

3 分层结构

  • 各层之间相互独立,每层只实现一种相对独立的功能
  • 每层之间界面自然清晰,易于理解,相互交流尽可能
  • 结构上可分割开。每层都采用最合适的技术来实现。
  • 上层为下层提供服务;
  • 整个分层结构应该能促进标准化工作。

4 基础概念

【实体】:活动元素,同一层的实体为对等实体;
【协议】:为进行网络中对等实体数据交换而建立的协议;
【三要素】:

  • 语法:规定传输数据的格式;
  • 语义:规定所要完成的功能;
  • 同步:规定各种操作的顺序;

【接口(访问服务点SAP)】:上层使用下层服务的入口;

  • 仅相邻层间才有接口,所提供服务的具体实现细节对上一层安全屏蔽;

【服务】:下层为相邻上层提供的功能调用;
【SDU服务数据单元】:为完成用户所要求的功能而应传达的数据;
【PCI协议控制信息】:控制协议操作的信息;
【PDU协议数据单元】:对等层次之间传送的数据单元;

5 OSI参考模型

【应用层】:用户与网络的界面,典型服务FTP、SMTP、HTTP;
【表示层】:处理在两个通信系统中交换信息的表示方式(数据格式变换数据加密解密、数据的压缩和恢复);
【会话层】:向表示层/用户进程提供建立连接并在连接上有序地传输数据(建立、管理、终止会话校验/同步通信);
【传输层】:负责主机中两个进程的通信(端到端);

  • 可靠、不可靠传输:可靠(TCP),不可靠(UDP)
  • 差错控制:
  • 流量控制:控制发送方的发送流量;
  • 复用分用:复用(多个应用层进程可同时使用下面运输层的服务),分用(运输层把收到的信息分别交付给上面应用层中相应的进程);

【网络层】:把分组从源端传到目的端,为分组交换网上的不同主机提供通信服务;

  • 路由选择:选择合适的路由,最合适的路径;
  • 流量控制:控制发送方的发送流量;
  • 差错控制:
  • 拥塞控制:缓解网络拥塞;

【数据链路层】:把网络层传下来的数据报组装成帧;

  • 成帧:定义帧的开始和结束;
  • 差错控制:帧错+位错;
  • 流量控制:
  • 访问接入控制:控制对信道的访问;

【物理层】:物理媒体上实现比特流的透明传输;

  • 透明传输:不管所传数据是什么样的比特组合,都应当能够在链路上传送;
  • 定义接口特性:
  • 定义传输模式:单工、半双工、双工;
  • 定义传输速率;
  • 比特同步;
  • 比特编码;

6 数据链路层

6.1 透明传输

【透明传输】:数据链路层对上层交付的传输数据没有任何限制,就好像数据链路层不存在一样。

  • 透明传输会导致什么呢?当设置帧头和帧尾时,数据的内部具有一样的标志时,如何才能接收到正确的数据;
    • 在发送帧之前,对其进行检查,是否出现标志相同,若相同,则在该标志前加上转义字符;

【常用方法】:

  • 面向字节的物理链路使用字节填充来实现透明传输;
  • 面向比特的物理链路使用比特填充来实现透明传输;
  • 在发送前使用零比特填充法,对数据进行扫描每5个1后插入0,当接收后将其剔除即可;

6.2 差错检测

由于帧在传输过程中遭遇干扰后可能出现误码,故接收方需要在接收数据的时候判断是否出现误码(0变1,1变0);

  • 故发送方需要在发送帧之前,基于待发送的数据和检错算法计算出检错码,封装在帧尾(FCS),即接受方在接收的时候可以进行检测;

【奇偶校验】:在待发送的数据后面添加1位奇偶校验位,使整个数据(包括所添加的校验位在内)中“1”的个数为奇数或偶数;

  • 奇校验:在数据后添加一个1,让1的总数为奇数,若产生一个位错误(1变0),则进行奇校验时,发送1的总数位奇故判断出现错误;
  • 但同时两个1变成0,即检验无效;
  • 只能在奇数个位发送误码,则奇偶性发送改变,才可以检查误码;

【循环冗余校验CRC】:

  • 收发双方约定好一个生成多项式G(x)
  • 发送方基于待发送的数据和生成多项式计算出差错检测码(冗余码),将其添加到待传输数据的后面一起传输
  • 接收方通过生成多项式来计算收到的数据是否产生了误码;

常用多项式:
CRC-16 = x16+x15+x^2+1
CRC-CCITT = x16+x12+x^5+1
CRC-32 = x^32 +x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+x+1

常见的错误:
分组丢失:没有被接收到;
分组失序:发送早的数据比发送晚的数据早接收到;
分组重复:发送的数据迟迟没有被接收到,重新发送后,原先的数据也被接收到了;

6.3 可靠传输

【不可靠】:当接收方接收到有误码的帧是,将其丢弃即可;
【可靠】:当接收到误码的帧时,能够继续发送一份数据;
【三种可靠传输协议】:可应用于计算机网络体系结构各层协议中;

7 ARP

【如何通过IP地址找到MAC地址】
使用ARP协议,当一台主机要发送数据包时,会先查询自身的ARP高速缓存表,若没有,则无法在包中填写目的MAC地址;
故发送ARP请求报文(广播)来获取接收方的IP地址;该请求报文本封装与帧中,当某台主机解析到IP与自身相符,则先记录发送方MAC地址,在通过该请求(单播)回应

========》UDP考虑等待应答、超时重发、为数据包编号、流量控制《========

7.1 UDP数据报
在这里插入图片描述

8 网络协议

========》Linux网络编程 | 【第一篇】网络协议详解TCP、UDP、ARP《========

9 UDP

========》Linux网络编程 | UDP服务器《========

10 套接字

【UNIX网络编程】| 【01】基本套接字编程(套接字地址结构、值-结果参数、字节序基本函数)
【UNIX网络编程】| 【02】基本TCP套接字编程(socket、connnect、bind、linsten、accept、并发服务器)
【UNIX网络编程】|【06】基本UDP套接字编程【数据报丢失、性能、流量控制…】
========》Linux网络编程 | Socket《========

11 TCP

========》【UNIX网络编程】| 【03】TCP客户/服务器程序示例《========
TCP数据报
在这里插入图片描述

11.1 TCP粘包

问题描述

TCP粘包是指发送方将多个数据包发送到接收方的缓冲区,应用程序读取到接收方缓冲区中多个首尾相连粘在一起的数据包;

主要原因

发送方:由于TCP协议默认使用Nagle算法(通过合并数据,从而减少发送数量来提升TCP/IP传输效率),这个算法会收集多个数据包分组,合并成一个大的数据块,这样会导致接收方难以分辨原来数据包,故Nagle算法可能会导致发送方出现粘包问题。

接收方:由于TCP连接的每一方都有固定大小的缓冲空间,TCP连接的接收方接收到的数据包就会放在其缓冲区中,等待应用程序(应用层)来读取。但有时会出现接收数据的速率大于应用程序读取的速率,这就会导致多个首尾相连的数据包被应用程序视为一个包读取,就出现粘包问题;

解决

发送方:故可通过不使用Nagle算法来解决,发送方用TCP_NODELAY选项来关闭;
接收方:这里接收方解决指的是应用层方面,即格式化数据包附带数据包长度发送

  • 格式化数据包是指为数据包加上开始符和结束符,那么应用程序读取时就能区分出每个数据包的开始和结束。
  • 附带数据包长度发送是指在数据包头部定义出数据包的长度,那么程序在读取时,会按照长度读取对应字节数据,保证读取的是单个包,且数据完整,这样就能保证数据包是单个且完整。

UDP有无粘包问题

UDP不存在粘包问题,因为UDP连接的接收方每次只接收—条独立的数据包,而TCP协议可以将多个数据包—起发送并接收(前提是接收方缓冲区剩余大小要能接收这多个数据),即接收方不保证一次只接收一条信息,所以TCP才存在粘包问题。

11.2 三次握手

========》三次握手《========
========》TCP 连接的建立与关闭《========
========》TCP 连接的建立与关闭《========

  • 【第一次】客户端发送一个带SYN标志的TCP报文到服务器:
    client为SYN_SEND,server为SYN_RCVD
  • 【第二次】服务器端回应客户端,带ACK标志和SYN标志。它表示对刚才客户端SYN的回应;同时又发送SYN给客户端,询问客户端是否准备好进行数据通讯;
    server进入SYN_RCVD
  • 【第三次】客户必须再次回应服务器端一个ACK报文;
    都进入ESTABLISHED;
  • 在建立连接的同时,双方协商了一些信息,例如双方发送序号的初始值最大段尺寸等。

常用标志

  • SYN表示建立连接,
  • FIN表示关闭连接,
  • ACK表示响应,
  • PSH表示有 DATA数据传输,
  • RST表示连接重置

11.3 四次握手

由于TCP连接是【全双工】的,故每个方向都必须【单独进行关闭】。这原则是当一方完成它的数据发送任务后就能【发送一个FIN来终止】这个方向的连接。收到一个 FIN只意味着这一方向上【没有数据流动】,一个TCP连接在收到一个FIN 后【仍能发送数据】。首先进行关闭的一方将执行【主动】关闭,而另一方执行【被动】关闭。

  • 客户端发出段7,FIN位表示关闭连接的请求;
  • 服务器发出段8,应答客户端的关闭连接请求;
  • 服务器发出段9,其中也包含FIN位,向客户端发送关闭连接请求;
  • 客户端发出段10,应答服务器的关闭连接请求;

在这里插入图片描述

11.4 为什么建立连接协议是三次握手,而关闭连接却是四次挥手呢?

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

  • 也可以三次挥手

11.5 为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态?

========》参考链接《========

让4次握手关闭流程更可靠

  • 4次握手的最后一个ACK是由主动关闭方发送出去的,若这个ACK丢失,被动关闭方会再次发送一个FIN过来
  • 若主动关闭方能够保持一个2MSL的TIME_WAIT状态,则有更大的机会让丢失的ACK被再次发送出去

防止lost duplicate对后续新建正常链接的传输造成破坏;保证这次连接的重复数据段从网络中消失

  • lost uplicate在实际的网络中非常常见,常由于路由器产生故障,路径无法收敛导致一个packet在路由器A,B,C之间做类似死循环的跳转。IP头部有个TTL,限制了一个包在网络中的最大跳数,因此这个包有两种命运,要么最后TTL变为0,在网络中消失;要么TTL在变为0之前路由器路径收敛,它凭借剩余的TTL跳数终于到达目的地。但非常可惜的是TCP通过超时重传机制在早些时候发送了一个跟它一模一样的包,并先于它达到了目的地,因此它的命运也就注定被TCP协议栈抛弃;

11.6 滑动窗口:流量控制

========》参考链接《========

该机制允许发送方在停止并等待确认前连续发送多个分组,而不必每发送一个分组就停下来等待确认,从而增加数据传输的速率提高应用的吞吐量;

限制

  • 接收放缓存;
  • 网络带宽小,发太多包会导致丢包;

发送方缓冲区:发送方缓冲区用于存储已经准备就绪数据和发送了但是没有被确认的数据。
接收方缓冲区:接收方缓冲区用于存储已经被接收但是还没有被用户进程消费的数据。
在这里插入图片描述
在这里插入图片描述
TCP 是如何解决窗口关闭时,潜在的死锁现象呢?
为了解决这个问题,TCP 为每个连接设有一个持续定时器,只要 TCP 连接一方收到对方的零窗口通知,就启动持续计时器。

如果持续计时器超时,就会发送窗口探测 ( Window probe ) 报文,而对方在确认这个探测报文时,给出自己现在的接收窗口大小。
窗口探测

  • 如果接收窗口仍然为 0,那么收到这个报文的一方就会重新启动持续计时器;
  • 如果接收窗口不是 0,那么死锁的局面就可以被打破了。

11.7 拥塞控制

========》参考链接《========

12 输入网页会发送什么

查看是否缓存;
DNS解析IP
请求webserver;
处理请求;
返回响应

13 防火墙的结构和原理

可以通过接收方IP地址发送方IP地址发送方端口号TCP控制位可以判断出通信的起点和终点、应用程序种类、访问的方向;

防火墙功能:

  • 允许或阻止网络包的通过;
  • 地址转化功能;

14 通过将请求平均分配给多台服务器来平衡负载

========》参考链接《========

15 epoll模型

========》【UNIX网络编程】|【04】I/O模型、select、pselect、poll《========
========》https://blog.csdn.net/weixin_45926547/article/details/123051768《========

一种同步IO模型,实现一个线程可以监听多个文件句柄,当有某个文件句柄就绪,即通知应用程序进行相应的读写操作;没有句柄就绪,则会阻塞应用程序;

select和epoll区别

  • select需要不断拷贝描述符集合到内核态,消耗;
  • 需要遍历整个描述符集合;
  • 文件描述符的限制;

ET和LT

  • 边缘触发(ET) :只有数据到来才触发,不管缓存区中是否还有数据;
  • 水平触发(LT) :只要有数据都会触发;

16 HTTP图解

【图解HTTP】|【01】简单了解HTTP协议
【图解HTTP】|【02】HTTP报文内的HTTP信息
【图解HTTP】|【03】返回结果的HTTP状态码
【图解HTTP】|【04】与HTTP协作的Web服务器(代理、网关、隧道)
【图解HTTP】|【05】HTTP首部详解
【图解HTTP】|【06】确保web安全的HTTPS
【图解HTTP】|【07】确认访问用户身份的认证
【图解HTTP】|【08】基于HTTP的功能追加协议
【图解HTTP】|【09】Web的攻击技术

17 网络是怎么链接的

【网络是怎样连接的】| 【01】浏览器如何生成消息?如何与服务器通信?
【网络是怎么连接的】| 【02】TCP/IP数据传输
【网络是怎么连接的】| 【03】探索集线器、交换机和路由器
【网络时怎样连接的】| 【04】服务端的局域网、服务器负载均衡
【网络是怎样连接的】| 【05】服务器响应返回浏览器

  • 0
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Jxiepc

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值