【复习整理归纳】| C++面经网络相关（三）

文章目录

- 计算机网络
- - 性能指标
  - 计算机在发送文件前需要做许多前期的工作
  - 分层结构
  - 概念
  - OSI参考模型
  - 数据链路层
  - ARP
  - 网络协议
  - UDP
  - 套接字
  - TCP
  - - TCP粘包
    - 三次握手
    - 四次握手
    - 为什么建立连接协议是三次握手，而关闭连接却是四次挥手呢？
    - 为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态？
    - 滑动窗口：流量控制
    - 拥塞控制
  - 输入网页会发送什么
  - 防火墙的结构和原理
  - 通过将请求平均分配给多台服务器来平衡负载
  - epoll模型
  - HTTP图解
  - 网络是怎么链接的

计算机网络

性能指标

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

单位：b/s；
受带宽和额定速率的限制；

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

【往返时间RTT】：从发送方发送数据开始，到发送方收到接收方的确认（接收方收到数据后立即发送确认)总共经历的时延；

RTT越大，在收到数据前，可以发送的数据越多；
（往返传播时延=传播时延*2 + 末端处理时间）

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

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

分层结构

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

概念

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

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

【接口（访问服务点SAP）】：上层使用下层服务的入口；

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

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

OSI参考模型

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

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

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

路由选择：选择合适的路由，最合适的路径；
流量控制：控制发送方的发送流量；
差错控制：
拥塞控制：缓解网络拥塞；

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

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

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

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

数据链路层

透明传输

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

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

【常用方法】：

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

差错检测

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

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

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

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

【循环冗余校验CRC】：

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

常用多项式：
CRC-16 = x^16+x15+x^2+1
CRC-CCITT = x^16+x12+x^5+1
CRC-32 = x^32 +x^26+x23+x^22+x16+x^12+x11+x^10+x8+x^7+x5+x^4+x2+x+1

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

可靠传输

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

ARP

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

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

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

网络协议

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

UDP

Linux网络编程 | UDP服务器

套接字

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

TCP

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

TCP粘包

问题描述

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

主要原因

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

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

解决

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

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

UDP有无粘包问题

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

三次握手

https://liuyu121.github.io/post/tcp/
https://amsimple.com/blog/article/109.html

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

常用标志

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

四次握手

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

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

在这里插入图片描述

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

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

也可以三次挥手；

为什么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协议栈抛弃；

滑动窗口：流量控制

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

限制

接收放缓存；
网络带宽小，发太多包会导致丢包；

发送方缓冲区：发送方缓冲区用于存储已经准备就绪数据和发送了但是没有被确认的数据。
接收方缓冲区：接收方缓冲区用于存储已经被接收但是还没有被用户进程消费的数据。

TCP 是如何解决窗口关闭时，潜在的死锁现象呢？
为了解决这个问题，TCP 为每个连接设有一个持续定时器，只要 TCP 连接一方收到对方的零窗口通知，就启动持续计时器。