-
UDP优点
- 传输速度快,TCP 3次握手后建立连接 终止需要4次握手
- 没公网IP、做NAT穿透
- 需要更高的带宽抢占能力
- 解决高延迟高丢包下、带宽利用率低问题
- 需要低延迟,不需要完全可靠,为了低延迟可以忍受一定的丢包。如实时音视频
- 连接频繁变动。如手机经常更换基站
-
实时传输
高实时 延迟<1s
准实时1~3s
伪实时>3s
-
文件传输
数据量大,不需要高实时,可以推迟重传时间
-
NAT穿透和透明代理
- 通信双方无法直接连接(IP、端口被封、连接干扰、NAT等),可通过代理对通信链路进行重新构建;
- 通讯双方直接通信性能差,可通过代理加速
-
UDP传输效率
可以在丢包处理、流量控制、拥塞控制、数据统计、状态反馈、状态反馈、流量伪装、路径优化等方面
-
丢包处理
- RUDP
- RTP
- UDT
-
定时重传
-
消极重传
-
激进重传
-
定时器分类
-
重传定时器
主要为了防止报文丢失或者阻塞。当A向B发送报文时,就会启动重传定时器,若在定时器到达之后,仍没有收到B的确认报文,则A会重新发送上次发送的报文。同时,令重传定时器复位。继续计时。
- 检查计时器
当B向A发送了0窗口报文,B此时已经没有空间接受A发送的数据了,通知A停止发送。A在收到后即停止发送,等待一段时间后,B有了一些空间,可以继续接收了。此时再向A发送非0窗口报文。如果此非0窗口报文在网络中阻塞或者丢失了,那么A将永远以为B没有空间接收数据,B也永远在等待A发来的数据。这样就会造成死锁的局面。
在A接收到B发送的0窗口报文后,就设立坚持定时器,当定时器到达后,A就像B发送一个探测报文。B收到探测报文后会给出A确认报文。
-
保活定时器 心跳
应用场景:客户机因为某些故障退出,而服务器并不知道,还在一直等待客户机发来的数据,这样就白白浪费了计算机资源。
在服务器端设置保活计时器,服务器每收到客户机的一次消息,就重置保活计时器,时间通常为2小时。若2个小时都没有收到客户机发来的消息,服务器就像客户机发送一个探测报文,以后每隔75分钟发送一次。若连续发送了10个探测报文后客户机仍无响应,则服务器就会认为客户机故障,并断开这次连接。
-
时间等待定时器
时间等待及时器用于TCP“四次挥手”阶段。当客户端向服务器发送最后一次确认报文时,就设定一个时间等待及时器,等待2MSL时间后再结束连接。
MSL:最长报文段寿命,大小为30s~2分钟。根据不同的应用有不同的设置。
- 客户机为什么要等待2MSL时间?
①为了保证服务器能够收到客户机发送的最后一个确认报文。
因为这个最后报文可能丢失,服务器收不到客户机的确认信息,就无法进入CLOSED状态。就会在重传定时器到达后重新发送上一次的报文(此时会重置时间等待计时器,再次等待2MSL时间),这样客户机在等待2MSL时间过程中就可以收到这个重传报文,并重新发送确认报文。
②防止出现“已失效的连接请求报文”再次出现的情况。
客户机在等待的这2MSL时间中,就可以使此次连接的所有报文都从网络中消失,这样在下一次新的连接中就不会出现旧的连接请求报文。
转自:https://blog.csdn.net/llzk_/article/details/61195825
注意:在服务器发送了FIN-ACK之后,会立即启动超时重传计时器。客户端在发送最后一个ACK之后会立即启动时间等待计时器。
参考:https://blog.csdn.net/LF_2016/article/details/60468161
参考:https://blog.csdn.net/eric0318/article/details/51087513/
提升:
参考:https://blog.csdn.net/xiaofei0859/article/details/52794576
-
快速重传
-
前向纠错
在丢包率25%下TCP已经没有传输能力
-
流量控制
-
拥塞控制
-
TCP拥塞控制相关概念:
- RTT:来回通信延迟
- RTO:根据RTT计算出重传超时时间
- BandWidth:网络带宽
- MSS:最大分段大小(有效数据部分大小)
-
判断拥塞条件
- 传输超时或者TCP重传定时器溢出
- 接收到重复的确认报文
-
Reno
参考:http://www.cnblogs.com/wuchanming/p/4422779.html
-
Cublic
-
BBR
20%
-
vegas
-
数据统计/状态反馈
统计信息:
- 带宽
- RTT
- 丢包率
- 接收端端口
- 拥塞算法及参数
-
流量伪装
-
路径优化
- 串联优化
- 并联优化