功能: 将数据从发送到传给接收端
UDP
- 无连接状态: 知道对端的IP和端口号就直接进行传输, 不需要建立连接
- 不可靠: 没有确认机制, 没有重传机制. 出错不会管
- 面向数据包: 不能够灵活的控制读写数据的次数和数量
- 发送速度快: 立即发送
报文结构
TCP
- 面向连接
- 可靠
- 校验和
- 序列号(按序到达)
- 确认应答
- 超时重传
- 连接管理
- 流量控制
- 拥塞控制
- 性能
- 滑动窗口
- 快速重传
- 延迟应答
- 捎带应答
报文结构
- 源/目的端口号: 表示数据是从哪个进程来,到哪个进程去;
- 32位序号/32位确认号
- 4位TCP报头长度:表示该TCP头部有多少个32位bit(有多少个4字节); 所以TCP头部最大长度是15 * 4 = 60
- 6位标志位:
- URG: 紧急指针是否有效
- ACK: 确认号是否有效
- PSH: 提示接收端应用程序立刻从TCP缓冲区把数据读走
- RST: 对方要求重新建立连接; 我们把携带RST标识的称为复位报文段
- SYN: 请求建立连接; 我们把携带SYN标识的称为同步报文段
- FIN: 通知对方, 本端要关闭了, 我们称携带FIN标识的为结束报文段
- 16位窗口大小: 提高传输效率
- 16位校验和: 发送端填充, CRC校验. 接收端校验不通过, 则认为数据有问题. 此处的检验和不光包含TCP首部, 也包含TCP数据部分.
- 16位紧急指针: 标识哪部分数据是紧急数据;
- 40字节头部选项
TCP的"可靠"
确认应答机制(保证数据收到)
TCP将每个字节的数据都进行了编号. 即为序列号 : 保证了数据有序 + 去重
每一个ACK都带有对应的确认序列号, 意思是告诉发送者, 我已经收到了哪些数据; 下一次你从哪里开始发.
超时重传机制(解决丢包问题)
- 超时重传: 如果主机A在一个特定时间间隔内没有收到B发来的确认应答, 就会进行重发
- 快重传: 如果发送端主机连续三次收到了同样一个确认应答, 发送端会将对应数据重新发送
连接管理机制(确保双方能够正确的发收数据)
TIME_WAIT状态
- 规定:主动断开连接的一方,要处于TIME_WAIT, 等待两个MSL时间后,才能回到CLOSED
- MSL:是TCP报文的最大生存时间
- 等待两个MSL时间:
- 保证最后一个报文可靠到达.
- 保证在两个传输方向上的尚未被接收或迟到的报文段都已经消失
CLOSE_WAIT状态
- 设A方已经完成数据的传输,发送断开连接请求. 而B方还没有完成数据的传输就会进入该状态
- 若有大量的CLOSE_WAIT状态可能说明连接没有正确关闭
TCP的"性能"
滑动窗口(提高传输效率)
- 窗口大小指的是无需等待确认应答而可以继续发送数据的最大值. 上图的窗口大小就是4000个字节(四个段). (一次可以发送多个数据)
- 发送前四个段的时候, 不需要等待任何ACK, 直接发送;
- 收到第一个ACK后, 滑动窗口向后移动, 继续发送第五个段的数据; 依次类推;
- 操作系统内核为了维护这个滑动窗口, 需要开辟 发送缓冲区 来记录当前还有哪些数据没有应答; 只有确认应答过的数据, 才能从缓冲区删掉;
- 窗口越大, 则网络的吞吐率就越高;
流量控制(解决收发速度不匹配)
接收端处理数据的速度是有限的, TCP支持根据接收端的处理能力来决定发送端的速度
发快, 接收端缓冲区满, 在来的数据接收不了(导致丢包), 导致重传等一系列连锁反应
- 接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 "窗口大小" 字段, 通过ACK端通知发送端;
- 窗口大小字段越大, 说明网络的吞吐量越高;
- 接收端一旦发现自己的缓冲区快满了, 就会将窗口大小设置成一个更小的值通知给发送端;
- 发送端接受到这个窗口之后, 就会减慢自己的发送速度;
- 如果接收端缓冲区满了, 就会将窗口置为0; 这时发送方不再发送数据, 但是需要定期发送一个窗口探测数据段, 使接收端把窗口大小告诉发送端
拥塞控制(缓解网络拥塞)
网络上有很多的计算机, 可能当前的网络状态就已经比较拥堵. 在不清楚当前网络状态下, 若还发送大量的数据,是很有可能造成更加拥堵
少量的丢包, 我们仅仅是触发超时重传; 大量的丢包, 我们就认为网络拥塞;
TCP引入慢启动 机制,先发少量的数据, 探探路, 摸清当前的网络拥堵状态, 再决定按照多大的速度传输数
- 此处引入一个概念程为拥塞窗口
- 发送开始的时候, 定义拥塞窗口大小为1;
- 每次收到一个ACK应答, 拥塞窗口加1;
- 每次发送数据包的时候, 将拥塞窗口和接收端主机反馈的窗口大小做比较, 取较小的值作为实际发送的窗口;
- 开始时指数级增长, 达到慢阈值后就变为线性增长
- 当TCP开始启动的时候, 慢启动阈值等于窗口最大值;
- 在每次超时重发的时候, 慢启动阈值会变成原来的一半, 同时拥塞窗口置回1
延迟应答(等待上层读走速度留够空间)
- 假设接收端缓冲区为1M. 一次收到了500K的数据; 如果立刻应答, 返回的窗口就是500K;
- 但实际上可能处理端处理的速度很快, 10ms之内就把500K数据从缓冲区消费掉了;
- 在这种情况下, 接收端处理还远没有达到自己的极限, 即使窗口再放大一些, 也能处理过来;
- 如果接收端稍微等一会再应答, 比如等待200ms再应答, 那么这个时候返回的窗口大小就是1M
捎带应答
发数据的时候捎带ACK
粘包问题
引发
- 发送大量小数据包: 小数据包在传输过程中被合并成一个大的TCP数据报
- 接收方来接收不及时: 接收方接收不及时, 数据包在缓冲区可能会被合并成一个大数据块
解决: 明确包之间的界限
- 对于定长的包, 保证每次都按固定大小读取即可
- 对于变长的包, 可以在包头的位置, 约定一个包总长度的字段
- 对于变长的包, 还可以在包和包之间使用明确的分隔符(协议)
TCP异常
- 进程终止: 进程终止会释放文件描述符, 仍然可以发送FIN. 和正常关闭没有什么区别.
- 机器重启: 和进程终止的情况相同.
- 机器掉电/网线断开: 接收端认为连接还在, 一旦接收端有写入操作, 接收端发现连接已经不在了, 就会进行reset. 即使没有写入操作, TCP自己也内置了一个保活定时器, 会定期询问对方是否还在. 如果对方不在, 也会把连接释放