前言

之前两篇文章, 分别讲述了HTTP协议、HTTPS和网络安全, 这篇文章主要讲述TCP和UDP相关的内容! 我在第一篇文章中, 也有提到TCP和UDP这两个传输层协议, 那么他们有什么区别呢?

1 连接性质的区别

1.1 TCP
面向连接的传输协议

• 数据传输开始之前, 需要三次握手,建立连接
• 数据传输结束之后, 需要四次挥手,释放连接

1.2 UDP
不是面向连接的协议
传送数据不需要和服务器连接, 只需要知道ip和监听端口

2 可靠性的区别

2.1 TCP
TCP是可靠的传输协议, 保证了(同时, TCP对资源占用较多)

• 传输无差错
• 数据不丢失
• 数据不重复
• 并且按序到达

2.2 UDP
UDP的特点之一是: 尽最大努力交付, 但是并不保证可靠传输(UDP相对对资源占用较少)

• 不保证连接的稳定性
• 不保证数据的准确性
• 不保证数据传输的有序
• 数据在传输过程中可能丢包

3 传输机制的区别

3.1 TCP
TCP是面向字节流的传输机制(即字节流模式), 不管发送方一次性给TCP多次缓冲数据, TCP都会根据实际情况进行合理拆分和组装, 分割成多个数据包, 然后有序稳定的传递给接收方

3.2 UDP
UDP是面向报文的传出机制(即数据报模式), 在传输过程中对数据 既不合并, 也不拆分. 通俗来说就是, UDP在接受到数据缓冲后, 数据大了不会对其进行分包, 数据小了也不会对其合并, 而是来多少我直接传多少.

4 功能的区别

4.1 TCP
TCP协议中数据报收发的功能通常基于连接实现的, 是面向字节流的传输, 在传输过程中, TCP可以通过可靠传输, 流量控制, 拥塞控制等功能实现数据可靠性传输的保证. 后面我们详解

4.2 UDP
UDP协议中数据报收发的功能通常基于UDP端口实现的, UDP自身主要有三个功能, 解释来源于计算机网络

• 复用, 多个用户使用一个IO资源发送消息时, 即为“复用”. 在网络运输层的体现就是, 多个端口(这里一个端口表示一个进程) 利用一个运输层协议发送数据即为复用
• 分用, 多个用户使用一个IO资源接受消息时, 即为“分用”. 多个端口利用一个运输层协议接收数据即为分用
  
• 差错检测
  UDP为了差错检测, 对其报文拼接了一个12字节的伪首部, 之后是8字节的UDP首部, 其中在UDP首部的末位有一个检验和位. 后面是数据部分. 这些不同部分, 都是32位字节数据. 在发送数据时, 发送方会把UDP首部和伪首部拆分成以16位为单位的小数据, 对所有单元进行二进制反码计算并对所有结果求和, 所得最后结果放入UDP首部检验和位
  同样的, 当接收方接受到数据时, 使用同样的策略计算检验和, 并和传递过去的检验和对比, 检验是否一致. (IM通讯就有借鉴这个验证思想)

5 应用场景的区别

5.1 TCP协议适用于对效率要求相对低对准确性要求相对高的场景下, 或者是有一种连接概念的场景下

• 文件传输
• 发送或接收邮件
• 远程登录
• 网络数据库, 分布式高精度计算系统的数据传输

5.2 UDP协议适用于对效率要求相对高, 对准确性要求相对低的场景, 或者是对安全没有什么要求的

• IM, 网络数据大多为短消息
• 网络视频
• 网络负担非常重, 但对响应速度要求高
• 网络语音电话(为什么微信视频电话聊天会因为网络波动卡, 丢失画面和语音, 就是因为UDP要保证时效性, 而不保证可靠性)
• 服务系统内部之间的数据传输, 因为数据可能比较多, 内部系统局域网内的丢包错包率又很低, 即便丢包, 顶多是操作无效

6 TCP的控制手段

6.1 可靠传输(使用停止等待协议)

为什么要三次握手?举个????
在三次握手的过程中, 假设客户端SYN报文因为网络或者其他原因导致丢失或者超时, 那么就会触发TCP的超时重传机制, TCP会重新发送一个SYN请求报文, 以保证及时建立传输通道

如果此时, 超时的报文又传递到了服务端, 因为客户端的超时重传机制, 服务端已经收到了重传的报文, 并产生了回应. 那么此时, 服务端就不会再对此超时报文做任何响应, 这样就避免了建立两次TCP连接的可能(如果建立新的连接就会关闭之前的连接), 一定程度上保证了连接安全

6.1.1 无差错情况

客户端和服务端进行正常(无差错)的数据交互, 每次需要客户端发送报文, 服务端收到返回一个确认报文, 客户端收到确认报文后, 继续发送第二次的报文内容, 如此进行下去, 直到连接关闭

6.1.2 超时重传

客户端给服务端发送报文时, 有可能网络太差导致丢失或滞留, 也有可能报文已经被劫持产生差错, 即产生了有差错的报文, 此时服务端根本收不到报文内容; 客户端在期许的时间范围内得不到报文确认, 就会产生超时, 触发超时重传. 客户端设置了一个超时定时器, 超过设定的等待时间后就认为这个数据包丢失, 然后重新发送. 但是在将来的某个时刻, 客户端发送的超时报文又到达了服务端, 由于服务端对重传后的报文已经回复了确认报文, 就会收下迟到的这个请求报文, 但是什么也不做

6.1.3 确认丢失(仍然触发超时)

客户端给服务端发送报文, 并且服务端收到了报文内容, 但是服务端在返回确认报文的时候, 产生超时或者被攻击劫持等; 客户端在期许的时间范围内得不到报文确认, 就会产生超时, 触发超时重传. 客户端设置了一个超时定时器, 超过设定的等待时间后就认为这个数据包丢失, 然后重新发送, 此时服务端收到了新的重传报文, 但是服务端已经接受过了该报文, 服务端就会丢弃本次重传的报文, 然后返回确认报文

6.1.4 确认迟到(仍然触发超时)

客户端给服务端发送的报文, 服务端收到回复确认的报文超时, 但是在某个时间, 超时的确认报文又到达了客户端, 即为确认报文迟到. 客户端收到这个迟到报文, 什么也不会做

6.2 流量控制(使用滑动窗口协议)

我们以客户端请求服务端为例
应用层提交给TCP的数据, 都放置在TCP的发送缓存区, 并且都有字节编号; TCP按照字节编号从左至右依次递增进行排序.TCP发送缓存区, 有以下三个概念或者说区域

• 已发送区域, 其左沿是最后被确认的字节(server端确认), 其右沿是最后发送的字节
• 将要发送区域(等待发送), 右沿为应用层最后写入的字节
• 发送窗口区域, 大小可能等于已发送区域, 也可能略大于已发送区域; 在其左侧成为窗口前沿, 右侧成为窗口后沿

如果发送窗口区域大于已发送区域, 则两者差值的区域为可发送但是还没发送的字节数据;已发送区域右沿和将要发送区域右沿所夹区域, 为尚未发送待发送的字节时间;

在传输过程中, 滑动窗口协议实际上就是通过控制发送窗口区域大小, 来达到控制流量传输的目的, 而发送窗口又受以下几个方面影响

• 将要发送区域缓存的大小(间接影响了发送窗口的大小)
• 接收方的接收窗口大小, 即网络接收方的接收数据包的速度! 如发送方是高速WiFi网络, 接收方是3g移动网络, 此时发送方发送过快,就会导致接收方接收缓存大量累积数据, 导致接收缓存溢出
  所以接受方需要能够动态调整发送方的发送窗口的大小,进而动态调整数据发送速率, 即流量控制.

接受方在接收到数据之后, 会把数据存放于一个接收缓存区域中, 同样的这个区域也分为几个区域. 其区域排序和结构大致和发送缓存原理相同

• 按序到达, 只能向上层应用层提交该区域部分数据, 以保证有序性
• 未按序到达, 这部分需要进行排序(通过字节编号)提交到按序到达区域, 保证有序性
  
  发送窗口和接受窗口, 实际上是TCP首部的两个字段, 如果速率发送改变, 就需要通过改变TCP首部的两个字段值来达到修改窗口值, 进而达到控制速率的目的

6.3 拥塞控制

6.3.1 慢开始、拥塞避免策略(慢启动协议)

TCP的慢启动特性, 本质是个算法策略
x轴:交互/轮询次数
y轴:窗口值的大小
指数增长: 如刚开始, 每次发送2个字节, 下次发送4个字节…这就是慢开始
拥塞避免: 当速度达到一定值时, 开始线性增长, 避免拥塞
网络拥塞: 界定比较复杂, 可以简单理解为, 发送报文的连续三个确认报文都无法收到
乘法减小: 当拥塞时, 迅速降低速率, 然后重新慢开始, 同时降低拥塞窗口值

6.3.2 快恢复、快重传

基于慢开始策略
上述过程中, 当达到拥塞避免时, 需要降低传输速率, 这时并不会从0开始, 而是从一个大于0的初始值, 开始恢复, 然后启动, 重新传输, 这就是快恢复, 快重传策略

本文完

我是个Coder界的小学生, 如有不足, 万望不吝指教

转载请注明作者和链接哦!
参考资料:
图解HTTP
深入理解TCP、UDP协议及两者的区别