目录
1、socket套接字技术
（1）socket的产生
网络通信涉及很多底层细节和繁琐步骤，像数据分包、添加各种协议头、维护连接状态、确认数据完整性等等，手动操作起来确实很麻烦。
这时候就有了一个封装好了的工具即套接字--socket
socket帮我们封装好了复杂的细节，我们只需要告诉它：
要发送的数据
目标的 IP 地址和端口号
socket 会帮我们自动：
补充协议需要的各种信息（比如本机设备标志、序号、校验等）
自动把大数据拆分成合适大小的包，并带上序号
处理网络传输过程中的重发和确认
收到数据后帮我们把拆包后的数据完整还原
这样，我们的程序写起来更简单、更直观，不用管底层复杂的实现。
但是同一局域网下 socket 默认拿不到对方 设备 MAC地址【因为socket API 工作在传输层/应用层，它关注的是“IP+端口”级别的通信，而不是底层的 MAC 级别】，这时候需要我们用程序补全此功能
（2）本质
最早是 C 语言在操作系统里提供的网络通信接口（系统调用），用来和 TCP/IP 协议栈打交道，
Java、Python、Go、C++ 等高级语言都在它的基础上做了封装，所以功能本质一样，只是语法不同。所以所有语言都有socket功能，可以进行网络编程通信。
在应用层使用它收发数据，底层由操作系统帮我们完成 IP、MAC、端口等细节处理。
（3）一个 Socket 对象对接一个通信会话
在服务器端，常见做法是：创建一个“监听 socket”（只用来等待连接，不传数据）---->一旦有客户端连接，请求会交给一个新的 socket 对象来专门负责和该客户端通信
因为 socket 会保存通信双方的唯一标识（四元组：源IP、源端口、目标IP、目标端口），所以一个 socket 实例只能跟一个客户端会话绑定。
一对多（服务器对多个客户端）：
服务器需要为每个客户端连接创建一个 socket 对象
例如：10 个人在线聊天 = 10 个客户端连接 = 10 个 socket 对象
多对多（像群聊）：
服务器端是多组 socket（每个客户端都有自己的）
服务器需要负责转发数据到对应 socket
通常会用socket 列表 / 集合来维护所有在线连接
这里区分websocket，他和socket的关系就像雷峰塔和雷锋一样，毫无关系
2、视频加载技术与断点续传技术
（1）产生背景
文本 vs 文件 —— 网络传输的本质
相同点
都是二进制数据（字节流 / 数组），网络层只关心“数据包”，不关心数据是什么类型
传输方式类似：都要经过协议封装 → socket 发送 → 接收端还原
不同点（主要在应用层处理）
| 类型 | 编码特征 | 传输解析方式 |
|---|---|---|
| 文本 | 固定、简单编码（UTF-8、GBK等） | 协议里通常会写明编码，接收方可直接解析成字符 |
| 文件 | 复杂、不固定编码（视频、图片、Word、PPT…） | 一般“透传”，接收方不解析内容，只保存为原文件（需要知道文件名和扩展名） |
这样大文件传输时网络传输会把大文件拆成多个小数据包（TCP 会分段），接收端必须在全部收到后再排序 & 合并，只有在“全部接收完”才能合并文件 → 没法边看边传。。。。
痛点：底层传输协议（TCP/UDP）不支持“部分文件先播放”，必须整个文件收齐 → 排序合并 → 才能用
视频必须下载完整才能播放
下载中断（断电、断网）后要从头开始
于是才有了视频加载和断点续传两大技术来改善体验。
（2）视频加载技术
让接收端可以边接收边解码，而不是等所有分片下载完成再合并。其实就是文件切分
关键在应用层协议：
允许分段数据“可独立播放”
每段带有可播放的元信息（如视频关键帧、时间戳等）
【例】B 站、YouTube、爱奇艺为什么能“边播边看、随意拖动”？？？
视频痛点：底层传输协议（TCP/UDP）不支持“部分文件先播放”，，必须整个文件收齐 → 排序合并 → 才能用。。文件太大（500MB+）下载时间长想看中间某一段必须等前面全部下完，但是不能直接改 TCP/HTTP（因为全网硬件都遵循现有协议）
解决思路：在传输之前，把“大文件”人为拆分成多个小文件（每个都可独立播放）
① 文件预处理：原始文件（500MB） → 拆成 N 个小文件（例如 50 个 10MB，或 500 个 1MB），每个小文件自带文件头（文件大小、编码信息、关键帧等），能独立播放。
② 传输过程：播放器先下载一个或几个小文件（很快，1MB~10MB） → 立即播放；如果用户拖动进度条到某个时间点 → 直接请求该位置对应的小文件--->后台按顺序/并发继续下载后续小文件.
（3）断点续传技术
断点续传 = 文件分片 + 双方约定记录机制
为什么浏览器没做断点续传？？
技术上需要“双方约定”：发送方（服务器）和接收方（客户端下载程序）必须能互相确认：
已经传了多少、哪些部分还没传，重新连接时只补传缺失部分，但是浏览器种类太多（Chrome、Firefox、Edge、360 等）、Web 服务器种类也多（Tomcat、Nginx、Apache、IIS、各种语言自写），双方没有统一标准去保存/读取这些断点信息，存储这些记录很麻烦（要区分是谁下载的、哪一天下载的、哪个文件）所以浏览器默认不做。
断点续传能实现的前提：发送方和接收方最好是同一个公司的软件，双方可以约定切分方式 + 序号标记 + 记录机制
例如：
文件先切成多个固定大小的小文件（如 1MB/份）
每个分片有编号（#1、#2、#3…）
接收方每收到一个就记录下来
中断后重新连接时，把已完成的编号发给发送方，让它只补传剩余的
浏览器没法做，是因为它和服务器之间没这个统一约定；而云盘、迅雷能做，是因为发送端和接收端都是自己家的。
数据粒度选择：
按网络数据包切（64KB 左右） → 太细，记录量大，没必要
按 1MB 或更大切 → 常用，记录量小、传输效率高
例如：500MB 文件 → 切成 500 份 1MB 分片，假设收了 266 份 → 中断后补传剩余 234 份即可