文章目录
应用层
设计一个应用层协议，主要就是包含两个工作：
- 明确传输的信息
- 明确数据的组织格式
常见的协议及区别
当下比较流行的一些协议的模板（数据的组织格式）
- xml
- json
- protobuffer
- HTTP
xml: 可读性好，但是运行效率不高
json: 当下最流行的一种，但是和xml一样，可读性好，运行效率不高
注意：
- json中表示字符串，单引号或者双引号都可以（类似于SQL）
- 最后一个键值对，后面可以有逗号，也可以没有（标准要求是没有的，但是一般的json解析器，都不会在意这个细节）
protobuffer： 可读性不好,运行效率高
HTTP: 当前最知名的应用层协议
传输层
UDP协议
UDP协议端格式
UDP的特点
- 无连接： 知道对端的IP和端口号就直接进行传输，不需要建立连接；
- 不可靠： 没有任何安全机制，发送端发送数据报以后，如果因为网络故障该段无法发到对方，UDP协议层也不会给应用层返回任何错误信息；
- 面向数据报： 应用层交给UDP多长的报文，UDP原样发送，既不会拆分，也不会合并；
缓冲区
- UDP没有真正意义上的发送缓冲区，发送的数据会直接交给内核，由内核将数据传给网络层协议进行后续的传输动作；
- UDP具有接收缓冲区，但是这个接收缓冲区不能保证收到的UDP报的顺序和发送UDP报的顺序一致；如果缓冲区满了，再到达的UDP数据就会被丢弃；
- UDP的socket既能读，也能写，这个概念叫做 全双工
大小受限
TCP协议
TCP协议段格式
TCP原理及协议的主要机制
确认应答（ACK）机制—安全机制
上面这个确认应答虽然汤姆收到了杰瑞的回复，但是还是有一点问题的，就是如果汤姆一下子给杰瑞发了好几条消息呢，会不会收到相对应的回复？
按理说正常情况下应该是上面这个样子，但是网络上，数据接收的顺序，不一定和发送的顺序完全一致❗存在后发先至的情况❗❗❗
从上面的图可以看出不可能！！！明明是后发的，但是反而先到了；这是因为网络环境非常复杂，连续发的两个包，不一定就是走同一条路。
那么该如何解决上述问题呢❓那就是对消息进行编号⬇️⬇️
序号和确认序号:
确认序号是如何进行应答的：
超时重传机制—安全机制
出现丢包的两种情况：
- 发出去的消息丢了
- ACK 丢了，虽然对方收到了消息，但是自己收不到 ACK
TCP内部去重
基于上述确认应答（ACK）和超时重传两个机制，TCP的可靠性得到了有效的保障❗❗
连接管理机制—安全机制
如何建立连接（三次握手）
三次握手有什么用?和可靠性有什么关系?
更具体的说，可以认为三次握手其实也是在检测通信双方的发送能力和接受能力是否都正常
比如：当本博主和小姐妹在使用QQ进行语音聊天时
如何断开连接（四次挥手）
TCP协议中的状态
经典面试题
1. 描述TCP三次握手的过程
上面已经详细的给大家介绍了TCP三次握手的过程，这里不再详细说了。😊😊（小tip：以后面试的时候最好给面试官画图！！）
2.为什么握手是三次?而不是两次?四次?
滑动窗口机制—效率机制
如何处理丢包问题
丢包分成两种情况：ACK丢了或数据丢了
ACK丢了
数据丢了
这里的重传只是需要把丢了的那一块数据给重传了即可，而其他已经到了的数据就不必再重传了，整体的重传效率还是比较高的，因此我们把这个过程称为快重传
这个快重传就像我们小时候看电视剧一样：
流量控制—安全机制
那么接收方如何告知发送方，剩余空间有多大呢？
通过ACK报文来告知——回忆我们的TCP首部中，有一个16位窗口字段，就是存放了窗口大小信息；
过程如下：
拥塞控制—安全机制
拥塞窗口的具体变化情况:（旧版本）
延迟应答—效率机制
还拿上面那个水池的例子来说：
捎带应答—效率机制
客户端和服务器之间的通信有以下几种模型:
- 一问一答:客户端发一个请求，服务器返回一个对应的响应⬇️⬇️⬇️
- 多问一答:上传文件
- 一问多答:下载文件
- 多问多答:直播—串流…
面向字节流——粘包问题
解决方案：关键就是要在应用层协议这里，加入包之间的边界（例如：约定每个包以 ； 结尾）⬇️⬇️⬇️
TCP异常情况
进程终止
机器关机
按照操作系统约定的正常流程关机，而正常流程的关机，会让操作系统杀死所有进程，然后再关机，这也就相当于又回到了我们的第一个异常情况。
机器掉电/网线断开
TCP和UDP的对比
啥时候使用TCP❓
啥时候使用UDP❓
经典面试题
如何基于UDP协议实现可靠传输?
具体实现方式，请仔细阅读全文⬆️⬆️⬆️
