TCP协议和UDP协议 的特点和对比

都是传输层的协议
一 .UDP协议

1.UDP的特点
(1)无连接:知道对端的IP和端口号就可以了, 不需要建立任何连接就可以传输数据

(2)不可靠: 没有确认机制, 没有重传机制; 如果因为网络故障该段无法发到对方, UDP协议层也不会给应用层返回任何错误信息;

(3)面向数据报:不能灵活的控制数据传输的次数和数量. 应用层交给UDP多长的报文, UDP原样发送, 既不会拆分, 也不会合并;
如: 用UDP传输100个字节的数据:
如果发送端调用一次sendto, 发送100个字节, 那么接收端也必须调用对应的一次recvfrom, 接收100个字节; 而不能循环调用10次recvfrom, 每次接收10个字节;

(4)具有接收缓冲区,没有发送缓冲区

UDP没有真正意义上的 发送缓冲区. 调用sendto会直接交给内核, 由内核将数据传给网络层协议进行后续的传输动作;
UDP具有接收缓冲区. 但是这个接收缓冲区不能保证收到的UDP报的顺序和发送UDP报的顺序一致; 如果缓冲区满了, 再到达的UDP数据就会被丢弃;

(5)数据大小受限, 不能超过64k
UDP协议首部中有一个16位的最大长度. 也就是说一个UDP能传输的数据最大长度是64K(包含UDP首部). 如果我们需要传输的数据超过64K, 就需要在应用层手动的分包, 多次发送, 并在接收端手动拼装;

2.基于UDP的应用层协议
NFS: 网络文件系统
TFTP: 简单文件传输协议
DHCP: 动态主机配置协议
BOOTP: 启动协议(用于无盘设备启动)
DNS: 域名解析协议
当然, 也包括自己写UDP程序时, 自定义的应用层

二. TCP协议

特点:
有连接 ,
可靠 ,
面向字节流: 创建一个TCP的socket, 同时在内核中创建一个 发送缓冲区 和一个 接收缓冲区;调用write时, 数据会先写入发送缓冲区中;如果发送的字节数太长, 会被拆分成多个TCP的数据包发出;如果发送的字节数太短, 就会先在缓冲区里等待, 等到缓冲区长度差不多了, 或者其他合适的时机发送出去;
接收数据的时候, 数据也是从网卡驱动程序到达内核的接收缓冲区;然后应用程序可以调用read从接收缓冲区拿数据;
TCP的一个连接, 既有发送缓冲区, 也有接收缓冲区, 那么对于这一个连接, 既可以读数据, 也可以
写数据. 这个概念叫做 全双工
由于缓冲区的存在, TCP程序的读和写不需要 一 一 匹配,
例如: 写100个字节数据时, 可以调用一次write写100个字节, 也可以调用100次write, 每次写一个字节; 读100个字节数据时, 也完全不需要考虑写的时候是怎么写的, 既可以一次read 100个字节, 也可以一次
read一个字节, 重复100次;

TCP保证可靠性又提高性能的机制


1.确认应答(ACK)机制

TCP将每个字节的数据都进行了编号. 即为***.
每一个ACK(响应数据包)都带有对应的确认***, 意思是告诉发送者, 我已经收到了哪些数据; 下一次你从哪里开始发.

2.超时重传机制

主机A发送数据给B,由于网络等原因,数据包无法到达B,在特定时间后,A没有收到应答,就会重发(依赖发送缓冲区来重发)
*另一种情况是:
主机A未收到B发来的确认应答, 也可能是因为ACK丢失了;
因此主机B会收到很多重复数据. 那么TCP协议需要能够识别出那些包是重复的包, 并且把重复的丢弃掉. 这时候我们可以利用前面提到的***, 就可以很容易做到去重的效果

超时时间的确定:
最理想的情况下, 找到一个最小的时间, 保证 “确认应答一定能在这个时间内返回”.
但是这个时间的长短, 随着网络环境的不同, 是有差异的.如果超时时间设的太长, 会影响整体的重传效率;如果超时时间设的太短, 有可能会频繁发送重复的包;
TCP为了保证无论在任何环境下都能比较高性能的通信, 因此会动态计算这个最大超时时间.

3.连接管理机制
在正常情况下, TCP要经过三次握手建立连接, 四次挥手断开连接
(1)三次握手

A要和B建立连接,
.创建A的连接,发送SYN建立连接的数据包到B
.B响应A的数据包,并创建自己的连接,ACK和SYN一起发送给A;
.A接收到B的响应, 确认连接,响应B的连接,返回一个ACK;

(2)四次挥手断开连接


4.流量控制
接收端处理数据的速度是有限的. 如果发送端发的太快, 导致接收端的缓冲区被打满, 这个时候如果发送端继续发送, 就会造成丢包, 继而引起丢包重传等等一系列连锁反应.因此TCP支持根据接收端的处理能力, 来决定发送端的发送速度. 这个机制就叫做流量控制(Flow Control);
接收端如何把窗口大小告诉发送端呢?
TCP首部中, 有一个16位窗口字段, 就是存放了窗口大小信息;那么问题来了, 16位数字最大表示65535, 那么TCP窗口最大就是65535字节么?实际上, TCP首部40字节选项中还包含了一个窗口扩大因子M, 实际窗口大小是 窗口字段的值左移 M 位.

5.拥塞控制
发送端在不知情的情况下贸然发送太多数据,可能会引起网络阻塞问题, 所以TCP引入慢启动机制,先发少量的数据探探路,再根据网络情况决定以怎样的速度发送数据.

开始以指数级方式增长,达到阈值后线性增长. 当超时重发时,慢启动的阈值会降为一半,拥塞窗口置为1.

1.滑动窗口
窗口大小指无需等待确认应答而可以继续发送数据的最大值(发送端拥塞窗口+接收端流量控制窗口).
操作系统内核为了维护这个滑动窗口, 需要开辟 发送缓冲区 来记录当前还有哪些数据没有应答; 只有确认应答过的数据, 才能从缓冲区删掉;
窗口越大, 则网络的吞吐率就越高
出现丢包有两种情况:
(1)数据包已发送,ACK(响应)丢了

这种情况无关紧要,因为可以根据后续的ACK进行确认.如果收到了后面数据的ACK,那么在此之前的数据包肯定也收到了.

情况二: 数据包就直接丢了

如上图:当1001~2000的数据丢失之后, 发送端会一直收到 1001 这样的ACK, 就像是在提醒发送端 “我想要的是 1001"一样; 如果发送端主机连续三次收到了同样一个 “1001” 这样的应答, 就会将对应的数据 1001 - 2000 重新发送;
这个时候接收端收到了 1001 之后, 再次返回的ACK就是7001了(因为2001 - 7000)接收端其实之前就已经收到了, 被放到了接收端操作系统内核的接收缓冲区中;
这种机制被称为"高速重发控制”(也叫"快重传").

2. 延迟应答
接收端接收到数据后不必立马返回ACK, 而是等待一段时间,让接收端处理数据, 这样返回ACK就能把窗口设置的更大.

3.捎带应答
有些数据包可以合并,比如ACK和自己要发的数据可以合并在一起, 即多次网络传输合并为一次,提高了传输效率.

基于TCP应用层协议
HTTP
HTTPS
SSH
Telnet
FTP
SMTP
还包括程序猿自定义的应用层协议

四. TCP/UDP对比
TCP是可靠连接, 那么是不是TCP一定就优于UDP呢? TCP和UDP之间的优点和缺点, 不能简单, 绝对的进行比较
TCP用于可靠传输的情况, 应用于文件传输, 重要状态更新等场景;
UDP用于对高速传输和实时性要求较高的通信领域, 例如, 早期的QQ, 视频传输等. 另外UDP可以用于广播;
归根结底, TCP和UDP都是程序员的工具, 什么时机用, 具体怎么用, 还是要根据具体的需求场景去判定