TCP/UDP协议详解_udp协议字段长度不够16位的要补全吗

TCP/UDP都属于传输层协议

一、UDP - 用户数据报协议

1、UDP协议段格式

16位UDP长度：整个数据报（UDP首部+UDP数据）的最大长度，一个UDP完整数据报总长度不大于64k

16位数据报长度限制了一个UDP协议要发送的数据最大长度不能大于64k-8；一旦超过，则发送失败。因此，若数据长度大于64k-8，则需要用户在应用层进行分包操作

UDP不保证数据有序到达，需要用户在应用层进行包序管理（应用层手动分包，多次发送，接收端手动拼接）

2、UDP协议的特点：

（1）无连接

发送端只需要知道接收端的地址和端口号，就可以直接发送信息，不需要建立连接

（2）不可靠

没有确认机制、没有重传机制；如果由于网络故障数据无法发送到对方，UDP协议层不会给应用层返回任何错误信息

（3）面向数据报

应用层交给UDP多长的报文，UDP原样发送，既不会拆分，也不会合并

注：UDP面向数据报意味着数据都是整条收发（交付），不会出现接收半条数据的情况；如果没有这个特性，那么当数据不是整条交付的时候，就需要花费资源去维护

3、基于UDP的应用层协议

NFS：网络文件系统

TFTP：简单文件传输协议

DHCP：动态主机配置协议

BOOTP：启动协议（用于无盘设备启动）

DNS：域名解析协议

二、TCP - 传输控制协议

1、TCP协议段格式

（1）源/目的端口号：表示数据是从哪个进程来，到哪个进程去

（2）32位序号/32位确认序号：明确告诉发送方哪些报文丢失了；按序到达，保证通信双方的可靠性

（3）4位TCP报头长度：表示该TCP头部有多少个32位bit（有多少个4字节）；所以TCP头部最大长度是15*4=60

（4）6位标志位：

URG：紧急指针是否有效（某些数据高优先级处理）

ACK：确认号是否有效

PSH：提示接收端应用程序立刻从TCP缓冲区把数据读走

RST：对方要求重新建立连接（携带RST标识的为复位报文段）

SYN：请求建立连接（携带SYN标识的为同步报文段）

FIN：请求断开连接（携带FIN标识的为结束报文段）

（5）16位窗口大小：自己接收缓冲区剩余空间的大小（三次握手建立时交换窗口大小信息）

（6）16位校验和：发送端填充，CRC校验；接收端校验不通过，则认为数据有问题；此处的校验和不仅包括TCP首部，也包含TCP数据部分

（7）16位紧急指针：标识哪部分数据是紧急数据

2、TCP协议的特点

（1）面向连接

TCP连接管理：三次握手/四次挥手

• 三次握手

I.第一次握手：建立连接时，客户端发送SYN到服务器，并进入SYN_SENT状态，等待服务器确认；

II.第二次握手：服务器收到SYN，必须确认客户端的请求，同时还需要发送SYN到客户端，即ACK+SYN，服务器进入SYN_RECV状态，等待客户端确认

III.第三次握手：客户端收到服务端的ACK+SYN，向服务器发送ACK确认，客户端和服务器进入ESTABLISHED状态，完成三次握手，连接建立成功

• 四次挥手

I.第一次挥手：主动关闭方主动调用close，发送FIN给被动关闭方，并进入FIN_WAIT_1状态，用来关闭主动关闭方到被动关闭方的数据传送，等待被动关闭方确认

II.第二次挥手：被动关闭方收到FIN，发送ACK给主动关闭方进行确认，被动关闭方进入CLOSE_WAIT状态

III.第三次挥手：被动关闭方调用close，发送FIN给主动关闭方，并进入LAST_ACK状态，用来关闭被动关闭方到主动关闭方的数据传送，等待主动关闭方确认

IV：第四次挥手：主动关闭方收到FIN，发送ACK给被动关闭方进行确认，并进入TIME_WAIT状态，等待2MSL，彻底断开连接

• TIME_WAIT状态的作用

前提：假如主动关闭方没有TIME_WAIT

主动关闭方最后回复的ACK数据若丢失，被动关闭方则会重新发送FIN请求，有可能对后续新连接造成影响（主动关闭方立即重启应用，且使用相同的地址信息，发送SYN请求，被动关闭方因为一直等待最后一个ACK，则收到SYN后认为连接异常，回复RST报文要求重置连接）

因此，主动关闭方不能直接进入CLOSE状态，释放socket资源；而是需要等待一段时间处理对端有可能重发的FIN请求

等待时间：2MSL（MSL-报文最大生命周期-60）- 等待所有报文都消失在网络中，防止对后续连接造成影响

• 服务端大量TIME_WAIT的原因

服务端主动关闭了大量客户端连接，可能造成资源过度占用

解决方案：减小MSL的值

（2）可靠传输

• 确认应答机制

TCP将每个字节的数据进行编号，即为序列号

每一个ACK都带有对应的确认序列号，意思是接收方告诉发送方已经收到了哪些数据，下一次发送方应从哪里开始发数据

• 超时重传机制

数据丢失 

主机A发送数据给主机B之后，可能因为网络拥堵等原因，数据无法到达主机B

如果主机A在一个特定的时间间隔内（500ms的整数倍）没有收到B发来的确认应答，就会进行重发

确认丢失 

主机B会收到很多重复数据，但会根据序列号去重

• 协议字段中的序号/确认序号
• 协议字段中的校验和

TCP为了保证可靠传输，牺牲了部分传输性能，但是有些性能的牺牲是没有必要的（比如确认回复丢失导致的数据超时传输）；需要尽可能保证性能处于巅峰水平

• 滑动窗口机制

在协议字段中包含窗口大小（uint16_t类型）字段；通信双方通过窗口大小协商对方接下来最多发送多少数据

流量控制

通信双方在每一次发送的数据中都会带有协商窗口大小，决定对方下一次应该发送多少数据，这个窗口大小不大于接收缓冲区中剩余的空间大小（避免数据处理过慢发送过快导致的数据丢失重传）

快速重传机制（快重传）

在双方通信中，每一个确认回复都必须保证ACK确认序号之前的数据都已经安全到达（避免了因为ACK确认回复丢失而导致的重传）

在双方通信中，接收方收到了第二条数据，但是没有收到第一条数据（接收方收到的数据序号并非连续，认为序号之前的数据丢失），这时会立即向发送方连续（间隔）发送三条第一条数据的重传请求，发送方收到连续三次的重传请求后，会将指定数据重新传输

在第三次发送重传请求之前，数据有可能刚好到达（延迟到达），这时因为重传请求不足三次，发送方就不需要进行重传

• 拥塞控制

通信双方通过窗口大小控制一次传输的数据量，但是在初始通信时，一次传输大量的数据有可能会因为网络原因，导致大量的丢包重传

在通信的时候以慢启动、快增长的形式传输数据；这个增长增加到一个阈值（窗口大小）时，趋于平缓；一旦通信过程中出现丢包，会重新初始化拥塞流量控制

发送端通过自身维护一个拥塞窗口大小来实现拥塞控制

• 延迟应答机制

接收到数据之后，并不进行立即回复，而是等待一会（不超过500ms）进行回复；尽可能保证窗口大小，维持最大的数据吞吐量

• 捎带应答机制

将确认序号放到即将要发送的数据头信息中，避免纯tcp头部的确认回复占用宽带

（3）面向字节流

传输灵活 ，但是会造成粘包问题

• 粘包

粘包有可能在发送方产生（几组数据放在一起，封装一个TCP协议头发送到接收方，接收方将其视为一组数据），也可能在接收方发生（接收方先收到一组数据，在延迟应答过程中又接收到一组数据，接受方将其视为一组数据）

粘包的本质原因：TCP协议栈，对缓冲区中的数据没有明确的边界之分，只关注字节流字符串

解决方法：用户在应用层对数据进行边界区分

       特殊字符间隔；数据定长；不定长数据 - 在协议头中增加数据长度字段

小tips

• TCP连接管理中的保活机制

TCP通信双方，长时间（7200s）没有数据往来，这时候每隔一段时间（75s）向对方发送保活探测数据包（要求对方确认应答）；若是收到回复，认为通信正常；假若发送多次（9次）保活探测都没有确认应答，这时候则认为连接断开了

连接断开在程序中的体现：recv返回0（默认阻塞），send触发异常（导致进程退出）

正常断开连接：ctrl+c、四次挥手、电脑关机

异常断开连接（保活机制）：断电