【Spark】网络原理概述

一、关键词

网络拓扑、连接模式、网关、ISP、路由器

应用层：DNS、CDN、DHCP协议、HTTP缓存、Web代理(正向/反向)

传输层：UDP、TCP(四个定时器、停止等待协议、ARQ协议、流量控制、拥塞控制、可靠传输、三握四挥)、RTT、MSLRTP

网络层：路由器、IP协议、IP首部(TLL)、hop-by-hop、ARP、NAT、NAPT表、ICMP、路由、自治系统(AS)、内部网关协议(RIP、OSPF)、外部网关协议(BGP)、P2P

数据链路层：帧、奇偶校验码、循环冗余校验码CRC、MTU、相邻

物理层：信道、分用复用技术

WebSocket、WebRTC、HTTPS

先来个奇闻轶事：宇宙射线导致网络数据错误（思科路由器）
OSI七层模型市场化失败的原因：纸上谈兵、制定周期过长、一些功能多层中重复出现
—> 利用一个请求和响应，其实能串联起所有知识点

二、应用层

功能：定义应用间通信的规则(传输层负责传输)

1. DNS：Domain Name System(域名系统)

功能：根据域名查询IP，区域传输使用TCP(主辅域名服务器数据同步)，其他用UDP
流程：按照不同层级的域名，层层查找，但实际上为了网络优化，都会使用DNS代理，直接查

2. DHCP协议：Dynamic Host Configuration Protocol: 动态主机设置协议

功能：自动获得IP地址（临时IP/租期，结合NAT理解）
范围：局域网协议
流程：(主机)广播 [IP全是1] —> (DHCP服务器)响应 —> (主机)请求 [IP地址] —> (DHCP服务器)响应

3. HTTP

缓存(Redis)、主存(Memcached)、辅存(内存/SSD) --> 基于二八定律设计

4. WebSocket

1.WebSocket：服务器主动向客户端发送消息的技术
2.为什么不用Http？为什么不用TCP？（协议头、兼容浏览器）
3.Http和WebSocket怎么兼容（HandShake：Upgrade/Connection/Sec-WebSocket-Version/Sec-WebSocket-Key、SHA1/Base64）
4.协议帧格式：header、payload(length)、masking-key、payload data(负载数据)
5.MaskKey计算：header里有MASK标志位，决定是否传明文

5. Web代理

正向代理(客户端访问原始服务器中间的一个处理层，一般需要配置)：
1.科学上网；2.缓存；3.授权；4.记录访问记录，对外隐藏用户信息
反向代理：
1.保证内网安全；2.负载均衡

更多参考：正向代理与反向代理

6. CDN：Content Delivery Network：内容分发网络

CDN就可以理解为分布在每个县城的火车票代售点(正向代理也能实现缓存)
优点：1.降低访问延时；2.减轻源站的负载

7. HTTPS

SSL安全套接层：既不负责传输，又不负责数据格式的定义
SSL握手流程：随机数、协议版本、数字证书

8. 更多HTTP/HTTPS细节

1.1.1：range、对比缓存、长连接、hostname(虚拟主机技术)
2.SPDY：多路复用、请求优先级、header压缩(算法/cache)、server push
3.2.0：基于二进制 + SPDY
4.请求慢：DNS、连接复用(tcp/http long-polling/chuncked/web-socket)、http pipelining
5.HTTP缓存：强制缓存(Expires/Cache-Control)、对比缓存(Last-Modified/Entry-Tag)
6.客户端如何校验CA证书
7.SSL连接如何建立
8.中间人攻击：嗅探、数据包注入、会话劫持、SSL剥离

扩展阅读：一文读懂Https的安全性原理、数字证书、单项认证、双项认证等
—> 实现上注意客户端证书的更新和可靠性

三、传输层

1. UDP

无连接、数据报(不合并也不拆分)、首部开销小

1. RTP结构

1.一个NALU就是一个RTP包的情况： RTP_FIXED_HEADER（12字节） + NALU_HEADER（1字节） + EBPS
2.一个NALU分成多个RTP包的情况： RTP_FIXED_HEADER （12字节） + FU_INDICATOR （1字节）+ FU_HEADER（1字节） + EBPS(1400字节)

0.RTP包数据内容严格按照顺序填充
1.RTP Header里有个标志位M(marker)表示是否需要分包，pt(playload type)表示负载类型，我们用H264(96)，SN(SeqNum)表示包序号，时间戳(H264视频采样率90000/帧率(25)，为3600)，SSRC：用来标识同步源，CSRC：多信号源+混合器才有用(CSRC表，因为我们是单信号源，SSRC也只是标识音视频)
2.NALU(压缩视频的基本单位)不需要分包 NALU Header，payload表示NALU，里面有个NRI，表示该帧是否会影响帧间预测 —> I帧？
3.NALU 需要分包 ，则没用NALU Header，改为 FU Indicator(功能与NALU Header一致，payload为FU-A或Fu-B)
和 FU Header(S:分片NAL单元的开始，E：分屏NAL单元的结束，R保留位，payload表示NALU)
–> 与RTCP结合理解

2. 从NPQ思考RTCP

RTCP是RTP的姊妹协议，RTCP用于控制传输质量，实现QoS，因为码流数据较大肯定采用UDP，
但传输质量控制肯定需要知道接收方的接收情况，所以即使用TCP，但数据量不会很大，起到一个信令的作用。
–> TCP响应也可以理解为一种传输控制了
策略：
1.基于RTT和重传次数递减，避免TCP的重传风暴；
2.统计丢包率，并基于丢包率
3.带宽探测(每次探测簇统计15ms数据量，指数上涨，初始800Kbps，到上限后停止探测)
4.基于丢包的拥塞控制：丢包率<2%上探8%(25ms)，丢包率>10%下调码率
5.基于延时的拥塞控制：乘性上涨8%，加性上涨不超过4Kbps，检测到拥塞下调目标码率为实际接收到的码率
6.码流整形：避免I帧过大导致瞬时码率太大

各种传输协议RTP_RTCP TCP UDP RTMP RTSP
UDP协议为什么比TCP协议快的原理

2. TCP

有连接、可靠、全双工、字节流
TCP粘包、拆包及解决方法

1. TCP的首部结构

源端口 / 目的端口
序号 / 确认号
数据偏移 / 保留字段 / TCP标记 / 窗口
校验和 / 紧急指针
————————————————————
TCP标记：URG、ACK 、PSH、RST、SYN、FIN
窗口：指明允许对方发送的数据量（结合确认号计算）
紧急指针：指定紧急数据在报文的位置

TCP协议的四个定时器：重传定时器（2RTT，未收到确认报文）、坚持定时器（零窗口死锁）、等待计时器（2MSL,连接终止）、保活计时器（2小时后，发送探测报文给客户端）
–> 联系一个遇到过的问题：Linux:TCP状态/半关闭/2MSL/端口复用

2. TCP可靠传输：滑动窗口(确认号)、超时重传(优化：选择重传)

因为假如窗口是20-30，25收到确认号，但20没收到是没有意义的，要从20开始重传
选择重传：TCP选项最多存储10个序号，实际是重传一段数据
—> 因为TCP一次传输成百上千个字节，不是丢一两个的

滑动窗口的实现依赖于数据链路层：滑动窗口技术+请求重发技术

3. TCP流量控制

让发送方发送速率不要太快（TCP特有）

实现：滑动窗口，其实就是接收方发送确认消息的时候，添加一个当前剩余窗口大小的参数，通知发送方还能不能继续发。
特例：在发送方接收到剩余为0的窗口后等待后，接收方剩余1000(可以理解为恢复发送的报文)，没有到达发送方，会进入死锁
解决：坚持定时器，每隔一段时间发送一个窗口探测报文(接收到窗口为0的消息后启动)

4. TCP拥塞控制

对比 流量控制(端对端)、拥塞控制(全局观)
粗暴的判断：报文超时则认为是拥塞
算法：慢启动算法(指数)+拥塞避免(试探着调大拥塞窗口，线性)
扩展阅读：TCP的拥塞控制、流量控制与拥塞控制区别

流量控制：端对端，滑动窗口大小改变来实现，避免A发送太快，B的缓冲窗口过小而没法接收
拥塞控制：全局性(设计所有主机、路由器–>木桶效应)，避免A与B之间的网络发生堵塞导致传输过慢或者丢包，来不及传输
–> 慢开始和拥塞避免(重传定时器超时过长：快重传，快恢复，发送端收到三个重复的确认ACK，立即重传)
(慢开始)指数规律增长、加法增大、乘法减小

5. TCP三次握手：SYN(请求连接)、ACK(序列号)

SYN-Flood(发送方确实第二次握手就可以确认进入连接了，但服务端不能确定，如果不释放还占用资源)

6. TCP四次挥手：FIN

为什么有关闭等待状态？
等待计时器：排查一个问题，主动释放连接方，端口不是马上可用的，需要等待计时器结束(和手机连接大屏热点，大屏切换热点，端口号不可用的问题可能相关)
—> 关于linux socket 编程 端口复用的理解
等待计时器的时间往往是2MSL：MSL(Max Segment Lifetime): 最长报文段寿命，建议设置为2分钟
等待计时器的功能：确保到达、确保过期

7. 更多TCP/UDP细节

1.TCP三次握手/四次挥手(原理及目的)：status、ack/sync/seq
2.TCP可靠传输实现：滑动窗口、流量控制、拥塞控制
3.流/数据报
4.UDP上如何实现可靠传输（seq/ack、发送/接收缓冲区、超时重传）
–> 其实就是移到应用层去保证可靠性，传输就很快（QoS服务，NPQ）
5.RUDP对拥塞控制的改进
6.RTP的实现，为何适合组播或单播网络
7.TCP连接会断开的原因（防火墙/路由器/网关，非活跃）
8.心跳机制实现（TCP协议入手、应用层实现）
9.Cookie/Session
10.IP报文（MTU、TTL、首部校验和） --> 从TTL可引申出ICMP协议：ICMP是报错(传递控制消息)
11.浏览器输入地址到返回发生了什么？
12.如何优化网络？（缓存/DNS/压缩）

四、网络层

路由器是网络层的重点设备、IP协议是网络层的重点协议

组成：IP首部+IP数据报的数据

1. IP首部

版本、协议、总长度(65535，比MTU大，所以需要分片)、片偏移、TTL、首部校验和(每经过一个设备-1，为0必须丢弃)、源IP和目标IP地址

IP 协议首部格式与其配套使用的四个协议(ARP,RARP,ICMP,IGMP)

MSL是报文最大生存时间、TTL是IP首部的一个表示“生存时间”的字段，每经过一个路由器-1、RTT是客户端到服务器往返所花时间
详见：MSL、TTL和RTT简介

2. IP转发：hop-by-hop

IP协议的转发流程（hop-by-hop）：
原因： 数据链路层只解决相邻的，不转发到网络层，哪能找到目的MAC
流程：每一跳都由路由器的数据链路层传递给网络层去找下一跳

• 数据帧每一跳的MAC地址都在变化
• IP数据报的IP地址始终不变

所以传输过程中数据不断在数据链路层、网络层沉浮，但是其实分层传输效率很高的，每次找路由，从首部找即可

1. ARP

网络层IP —> 数据链路层MAC、广播喊话、ARP缓存表(非永久)、arp -a
—> RARP协议很少用了

127.0.0.1：本地回环地址(Loopback Address)，一般都会用来检查本地网络

CIDR(斜线记法)：由子网掩码概念其实就可以想到，因为只和1，0的位数相关

2. NAT

减缓了IP地址的消耗，但是增加了网络通信的复杂度

扩展阅读：NAT技术详解，网络安全之NAT(地址转换)技术详解

NAPT表：结合锥形NAT理解就知道为何要记端口号了

3. ICMP

网际控制报文协议、无连接、不传输用户数据、辅助IP协议做数据传输工作、差错报告报文

应用：ping(判断网络质量)、tracert(跟踪路由，即跟踪每一跳的路径，TTL)

3. 路由算法

路由表哪里来的？下一跳地址是唯一的吗？下一跳地址是怎么来的？下一跳地址是最佳的吗？ 路由器怎么多，他们是怎么协同工作的？
—> 路由算法、自治系统

自治系统（Autonomous System）：内部网络自行管理，对外提供一个或者多个出(入)口

主干、地区、公司/校园/家庭：不同层次都算一个不同的AS
内部网关协议(RIP、OSPF)、外部网关协议(BGP)

1. RIP协议：Routing Information Protocol

距离矢量(DV)算法：画表，加入新节点的距离信息，更新较小距离(假设以A为基准，加入B，AB的直接距离是已知的)
距离 -> 跳数(hop)、30s交换一次路由信息、hop>15为不可达
问题：故障收敛慢（一个节点宕机，需要反复询问相邻节点，直到达到16） --> 水平分割
1.随便相信“隔壁老王”，2.“自己不思考”， “视野不够”
用处：AS里使用，实际中较少使用

2. OSPF协议：链路状态协议（一传十、十传百）

利用Dijkstra算法，获得网络的完整拓扑(全网一致)：从U集合不断纳入较近的节点到S集合，更新到剩余节点的路径，与当前取较小 —> 确实比DV妙很多
流程：路由器接入网络 --> 路由器向邻居发出问候信息 --> 与邻居交流链路状态数据库 --> 广播和更新未知路由

3. BGP协议：边际网关协议

引入原因：1.互联网很大、Dijkstra算法会炸；2.不同AS采用的内部网关协议可能不同；3.墙
BGP Speaker：位于AS系统的边界，交换路由信息 —> 找到一条比较好的路由

4. 单播/组播/广播

单播：有一台设备，数据就复制传输一次，服务器流量＝客户机数量×客户机流量
广播：一台机器发出的数据能被一个网段的机器都收到
组播：D类IP多用于组播，如群组场景：局域网内主屏收到数据，往其他组内辅屏转发，节省了客户端到主屏这一段的数据复制成本，流量是要钱的(虽然很不恰当，但和反向代理的拓扑图确实很像)
扩展阅读单播、广播和组播优缺点

5. IP层的骚操作

1. P2P

1.P2P：ipv4的产物
2.桥接模式 / NAT / 仅主机模式 --> 网络拓扑
3.P2P网络：迅雷不存资源，只存服务器的地址和资源映射
4.完全锥形NAT(一对多，好穿) / IP限制锥形NAT / 端口限制锥形NAT / 对称NAT(一对一：难搞)：网关

2. Web RTC

1.信令服务器(房间服务器)：知道彼此的存在
2.sdp媒体协商 ：交换SDP
3.ice网络协商：交换ICECandidate
4.STUN、TURN：SDP路径有交叉点，则可STUN进行P2P打洞，成功直连，不成功则TURN服务器转发
<TURN比STUN多了个“中间人”，ICE不是协议而是框架，可以整合其他协议，通过搜集尽可能多的网络信息，提高穿透率>
扩展阅读：STUN, TURN, ICE介绍

五、数据链路层

帧：在发送端，数据链路层把网络层传下来得数据封装成帧，然后发送到链路上去；在接收端，数据链路层把收到的帧中的数据取出并交给网络层

1. 帧结构：[ SOH / 帧数据 / EOT ]

数据里面恰好有两个特殊的比特流咋办？
1.透明传输：转义，转义的转义
2.算法上也应尽量避免出现SOH、EOT比特流

2. 差错检测

1. 奇偶校验码

在比特流后面添加一位，表示前面数据相加的和的奇偶（偶数个出错，就校验不出来了）

2. 循环冗余校验码CRC

模"2"除法（异或：不一样为1，一样为0），最高阶为1就退化成了奇偶校验
—> g(x)类似于哈希函数的功能 + 利用模"2"除法，实现类似非对称加密的功能
区别：校验根本没有key，只有一个相同的g(x)
g(x)去维基百科上查一下，有常用的CRC函数

数据链路层只进行数据的检测，不进行纠正

3. MTU：最大传输单元(Maximum Transmission Unit)

数据帧过大影响时延，过小影响性能（冗余操作过多）
路径MTU：路径MTU由链路中MTU的最小值决定（木桶效应）

默认不同：以太网(1500)、路由器(1492)、蓝牙(692)
—> 曾怀疑过无线下大概率丢包是不是RTP的payload设置了1500，在无线的情况下稳定丢包(但其实就是网络状况太差)，但其实不影响，RTP是上层协议，有分片的

4. ARQ协议：

1.停止等待ARQ协议(信道利用率低，一比特的连续ARQ协议)、
2.连续ARQ协议(发送窗口大小固定，传一段，滑动一段)
3.回退n帧ARQ协议(一口气发送x个帧，若中间有1帧没收到，发送方需要重发未收到帧后续的)
4.选择重传ARQ协议(接收端缓存所有接收到的帧，只让发送端重传有问题的帧，需要更多缓存)
扩展阅读：计算机网络 TCP------滑动窗口协议与ARQ协议

思考：UDP是只发不应答的吗？NoNoNo，从数据链路层的ARQ协议上也可以得出，可以应答只是根据需要选择应答频率和重传时机

六、物理层

1. 信道

作用：传输比特流(01010101)
信道：往一个方向传送信息的媒体
信道和电路：一条通信电路包含一个接收信道和一个发送信道
分类：单工(有线电视、无线收音机)、半双工(双方都可收发，但不能同时)、全双工

2.分用复用技术

为什么要引入分用-复用技术：并不是所有计算机都活跃，每个计算机之间都用信道直接连接，利用率不高
实现：类似EventBus，往总线发，统一调度
—> 频分复用、时分复用、波分复用、码分复用

七、细节升华

1. TCP/IP四层模型

层次	协议
应用层	HTTP、FTP、SMTP、POP3
传输层	TCP、UDP
网络层	IP、ICMP
网络接口层	Ethernet、PPP、ARP、RARP

路由器最上只到网络层

延时指标

1. 发送时延（受限于网卡）
2. 传播时延（受限于传输介质）
3. 排队时延（比如数据可能会在路由器里等待一段时间）
4. 处理时延（服务器性能）
   总时延 = 发送时延 + 排队时延 + 传播时延 + 处理时延
   —> 前三者是网络优化时，需要控制的变量

网络拓扑

终端机器 —> 路由器 —> 网关(内部网关 —> 统一网关) —> 地区ISP —> 主干ISP —> 路由器(核心部分的)
但实际上，我们不关心网络拓扑，我们更关心连接模式：CS、P2P

2. Socket编程填坑

1.一个端口如何区分多个Client发过来的数据？

根据目标IP，找到对应的连接句柄
–> 一个端口可以绑定多个socketFd，通过select/poll/epoll，判断这个文件可不可读，
如果可读，调用recv/可不可写，如果可写，调用send

2.端口复用：

使用场景：多个应用复用端口，只有最后一个绑定的socket可以接受数据，所有socket都可以发送数据
主要用途：防止 服务器重启时之前绑定的端口还未释放 或 程序突然退出而系统没有释放端口
–> 新启动的服务器绑定端口，若没设置端口复用，绑定会失败，提示ADDR已经在使用中
–> 原因：TCP的等待定时器，2MSL内处于TIME_WAIT状态，不可重新建立连接
原理：本来以为是找个可用端口绑上去，但研究了下，太底层，实现方式还有好几种

有兴趣的可以扩展阅读：Linux端口复用、Linux网络编程——端口复用（多个套接字绑定同一个端口）

3. 案例：低端PC机的不断网络重连

打通思路：与TCP的流量控制和拥塞控制结合思考

直接原因：RTCP超过10秒都没收到响应，认定断开
排查过程：ping排查发现网络确实不行，且低端PC尤其严重，会出现ping超时，（思维跃迁点）抓包分析网卡收到数据正常，但RTCP回调里的日志不正常
1.低端机造成网络不断重连，定位历程：网络、低端机、(抓包)网卡、阻塞、NPQ是线程安全的库，故码流sendTo和RTCP回调相互阻塞，解决：异步处理回调，增设发送缓存
2.TCP模式这些情况已经考虑，瞬时流量过大会导致拥塞，丢包(花屏)、传输过慢(卡顿、延时大)，增设缓冲区，会让情况缓解不少（视频直播场景瞬时流量过大可利用码流整形计数打平）
3.TCP的接收和发送会相互阻塞？网卡的发送和接收，底层来看，都是用的不同的口，缓冲区也是不同的(但上层<应用层、传输层>代码策略上可能会导致相互阻塞)