Linux网络中的UDP协议和TCP协议
UDP协议
UDP协议格式
UDP协议特点
- 无连接: 知道对端的IP和端口号就直接进行传输， 不需要建立连接
- 不可靠: 没有确认机制，没有重传机制，如果因为网络故障该段无法发到对方， UDP协议层也不会给应用层返回任何错误信息
- 面向数据报: 不能够灵活的控制读写数据的次数和数量
面向数据报： 应用层交给UDP多长的报文，UDP原样发送，既不会拆分，也不会合并。例如用UDP传输100个字节的数据，如果发送端调用一次sendto，发送100个字节, 那么接收端也必须调用对应的一次recvfrom，接收100个字节，而不能循环调用10次recvfrom，每次接收10个字节
UDP的缓冲区
- UDP没有真正意义上的发送缓冲区，调用sendto会直接交给内核，由内核将数据传给网络层协议进行后
续的传输动作 - UDP有接收缓冲区，但是这个接收缓冲区不能保证收到的UDP报的顺序和发送UDP报的顺序一致，如果缓冲区满了，再到达的UDP数据就会被丢弃、
UDP注意事项
UDP协议首部中有一个16位的最大长度。也就是说一个UDP能传输的数据最大长度是64K(包含UDP首部)。如果我们需要传输的数据超过64K, 就需要在应用层手动的分包, 多次发送, 并在接收端手动拼装
基于UDP的应用层协议
- NFS: 网络文件系统
- TFTP: 简单文件传输协议
- DHCP: 动态主机配置协议
- BOOTP: 启动协议(用于无盘设备启动)
- DNS: 域名解析协议
TCP协议
TCP协议格式
- 源端口号： 发送报文应用程序使用的端口号
- 目的端口： 接收端接收报文使用的端口号
- 序号： 表示报文段所发送数据的第一个字节的编号。在 TCP 连接中，所传送的字节流的每一个字节都会按顺序编号
- 确认序号： 表示接收方期望收到发送方下一个报文段的第一个字节数据的编号
- 首部长度： 表示TCP头部的大小，方便确认数据从哪里开始
- 保留： 目前全部为0
- URG： 紧急指针是否有效
- ACK： 确认号是否有效
- PSH： 提示接收端应用程序立刻从TCP缓冲区把数据读走（如果PSH = 1，表示立刻读取数据）
- RST： 对方要求重新建立连接，把携带RST标识的称为复位报文段
- SYN： 请求建立连接，把携带SYN标识的称为同步报文段
- FIN：通知对方，本端要关闭了，称携带FIN标识的为结束报文段
- 窗口大小： 表示当前接收端的接收窗口还有多少剩余空间，用于 TCP 的流量控制
- 校验和： 用于确认传输的数据是否有损坏
- 紧急指针： 指出本数据段中为紧急数据的字节数，所有紧急数据处理完后，TCP 就会告诉应用程序恢复到正常操作。即使当前窗口大小为 0，也是可以发送紧急数据的，因为紧急数据无须缓存
- 选项： 40个比特位的描述信息
TCP协议特点
- 面向链接
- 可靠传输
- 面向字节流
TCP协议机制
确认应答（ACK）机制
超时重传机制
判定超时的这个最大时间段过短或者过长都不好，TCP为了保证无论在任何环境下都能比较高性能的通信, 因此会动态计算这个最大超时时间
Linux超时以500ms为一个单位进行控制，每次判定超时重发的超时时间都是500ms的整数倍，重发一次得不到应答，会在2500ms后再次重传，再得不到答复在4500ms后重传……累积一定次数TCP认为网络或者对端主机出现问题，强制关闭连接
连接管理机制
滑动窗口机制
- 窗口大小指的是无需等待确认应答而可以继续发送数据的最大值。上图的窗口大小就是400个字节(四个段)
- 发送前四个段的时候，不需要等待任何ACK，直接发送
- 收到第一个ACK后，滑动窗口向后移动，继续发送第五个段的数据，依次类推
- 操作系统内核为了维护这个滑动窗口，需要开辟发送缓冲区来记录当前还有哪些数据没有应答，只有确认应答过的数据，才能从缓冲区删掉
- 窗口越大，则网络的吞吐率就越高
滑动窗口机制应对丢包问题：
- 停等协议：得到一条回复才能发送下一条数据。
- 回退N步协议：一条数据丢失，则发送端需要将这条数据及以后的数据都进行重传。
- 选择重传机制：一条数据丢失，则发送端仅仅针对丢失的数据进行重传
拥塞控制机制
网络上有很多的计算机，可能当前的网络状态就已经比较拥堵，在不清楚当前网络状态下，贸然发送大量的数据，是很有可能引起雪上加霜的。所以TCP引入慢启动 机制，一开始先发少量数据探探路，如果网络状态良好，就会增加一次传输的数据，这个增长速度非常的快，为了不增长的那么快，会有一个阈值，当超过阈值之后，增长速度会慢慢减小。类似于S型曲线
延迟应答机制
如果接收数据的主机立刻返回ACK应答，这时候返回的窗口可能比较小，例如刚接收500k的数据就应答，那么窗口大小就是500k，可以过一段时间再应答，一次处理更多的数据，窗口就稍微大一些 ，窗口越大，网络吞吐量就越大，传输效率就越高。我们的目标是在保证网络不拥塞的情况下尽量提高传输效率。
但是也不是所有的包都可以延迟应答
- 数量限制：每隔N个包应答一次
- 时间限制：超过最大延迟时间就应答一次
捎带应答机制
在延迟应答的基础上，我们发现，很多情况下，客户端服务器在应用层也是 “一发一收” 的。意味着客户端给服务器说 “你好”，服务器也会回复一句“你好”，ACK就可以跟着服务器回复的“你好”一并返回给客户端。