UDP&TCP（传输层）

最新推荐文章于 2025-11-18 15:51:44 发布

原创最新推荐文章于 2025-11-18 15:51:44 发布 · 713 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#UDP #TCP

Linux 专栏收录该内容

8 篇文章

订阅专栏

传输层：负责端于端之间的数据传输。TCP&UDP
端口：在一台主机上唯一标识一个进程。
一个端口只能被一个进程所绑定。
一个进程可以绑定多个端口
端口划分 unit_8（0~2¹⁶);
知名端口：（0~1023）
http:80 https:443 ssh服务：22 ftp服务：21 telnet服务：23
非知名端口：mysql:3306 oracle:1521
网络当中数据传输的五元组：源IP，源端口，目的ip，目的端口，协议

UDP协议

UDP协议端格式

在这里插入图片描述

UDP的特点

无连接：知道对端的IP和端口号就直接传输，不需要建立连接；

不可靠：没有确认机制，没有重传机制。如果因为网络故障该段无法发现对方，UDP协议也是不会给应用层返回任何错误信息；
面向数据报：不能够灵活的控制读写数剧的次数和数量；

面向数据报：应用层使用UDP协议时，不管是从UDP接收缓冲区当中拷贝数据，还是应用层将数据拷贝到UDP的发送缓冲区，都是一整条数据拷贝的，而不存在两条数据并存在缓冲区当中，既不会拆分也不会合并。

UDP不存在粘包问题：数据报头中有数据报长度
UDP协议包头

struct udphdr                                                                                                                     
  {                                                                  
    u_int16_t uh_sport;       /* source port */                        
    u_int16_t uh_dport;       /* destination port */                   
    u_int16_t uh_ulen;        /* udp length */
    u_int16_t uh_sum;     /* udp checksum */                          
  };

数据报长度：类型是uint16_t最大表示的数值是65535，udp数据报最大是65535个字节
UDP数据报长度（65535）=UDPheader(8字节）+数据
如果大于UDP传输的最大长度，应该怎么办？
就需要在应用层手动的分包, 多次发送, 并在接收端手动拼装;
自定义协议，在自定义协议当中拆分原始数据报，对UDP对最大数据报的限制；
「在应用层进行拆解，分多次使用UDP协议进行传输；UDP的特性是整条数据收发的，所以认为应用层传输的每一个数据都是一个完整的UDP数据报；而对于接收端UDP数据的进程而言，从协议栈当中的传输层的UDP接收的数据对于应用层而言，可能不是完整的；所以数据收发方需要在应用层也定制自定义协议，标识应用层数据长度和是否完整」

检验和

校验数据是否传递一样，如果有损坏，不会提交给应用层，会直接丢弃。
如何通过校验和来判断数据是否有损坏？
计算：
1.将发送方的UDP报文段除校验和的16个比特位外的其他所有16位比特位相加；
2.对加起来的和进行反码运算；
3.将结果放到校验和当中；
验证：
接收到UDP数据报之后，将所有16位比特位全部加起来，如果是11111111 11111111，则认为数据是没有损坏的。
注意：
当两个16位的比特位相加时，如果结果超过了16个比特位，则将第17位比特位和后16位比特位进行相加。成为回卷。

UDP缓冲区

1.对于应用层的数据是整条数据接收和发送的；
2.对于发送端而言，应用层使用sendto接口将数据提交给传输层当中的UDP的发送缓冲区，在发送缓冲区中，加上UDP报头之后，就直接提交给网络层进行下一步的传输；
3.对于接收端而言，应用层使用recvfrom接口将数据从接收缓冲区当中拷贝到应用层，UDP接收缓冲区是不保证数据的有序到达，也不保证可靠；当接收缓冲区当中满的时候，从网卡当中接收的UDP数据包也就直接丢弃了；

基于UDP的应用层协议

1.DHCP：动态主机协议
谁上网给谁分配IP;
ipv4版本ip地址不够用，uint32_t(42亿）;
DHCP协议是通过udp广播来获取ip地址的；
「DHCP(目的ip地址是255.255.255.255)
路由器接收到这样的请求之后，回复一个应答，分配一个IP给请求的主机」

2.DNS：域名解析协议
将域名转换位ip地址的时候，使用的是udp协议

3.NFS：网络文件系统
4.TFTP：简单文件传输协议
5.BOOTP: 启动协议(用于无盘设备启动

TCP协议

TCP协议格式

在这里插入图片描述
源/目的端口号：表示数据从哪个进程来，到哪个进程去；
32位序号：标识TCP源端向TCP目的端发送的数据字节流；
32位确认序号：标识TCP目的端期望TCP源端的下一个请求序号；

4位首部长度：
首部长度字节大小=4位比特位转化成十进制数值15*4（字节）–>TCP协议头部最大表示60字节；（0000~1111（0x00`0XF)–>十进制的数值是15，而并非代表字节数）

6个标志位：
URG：紧急标志位[发送待外数据（配合紧急指针使用）–会给对应进程发送信号SIGURG，只需调用自定义函数signal/sigaction处理信号,在函数内调用recv(sockfd,buf,size,MSG_OOB);]
ACK标志位：表示确认数据；
PSH标志位：表示发送数据；
RST标志位：重置连接
SYN标志位：发起连接
FIN标志位：断开连接

16位窗口大小：2个字节数据，窗口表示范围（0~2^16);
16位校验和：检验数据是否完成
16位紧急指针：和URG标志位一起使用，如果URG标志位为1，则紧急指针指向的数据有效；

选项：剩余的40个字节，可以加上一些选项例如：MSS(最大报文段长度)

TCP的特点

面向连接
可靠传输

1.确认应答机制
2.超时重传机制
3.滑动窗口机制
4.拥塞控制机制 [慢启动，拥塞避免，快重传，快恢复]
5.捎带应答机制
6.延时应答机制

面向字节流

面向连接

TCP连接机制

在这里插入图片描述

可靠传输

确认应答机制

当发送方发送一个报文需要带上序号，当接收方收到报文，需要对报文进行确认，给发送方发送确认报文，而确认报文当中的确认序号是告诉发送方自己期望的下一个序号是多少。

连接双方包序管理：
1.连接双方各自维护一套序号，三次握手的时候进行协商；
2.在三次握手期间，不论是连接方还是被动连接方，序号的起始位置都是随机的；
3.对于数据报文交互时，ACK报文不消耗序号；
4.确认序号的计算=收到的报文（报文的发送方维护的序号）的其实序号+报文长度；

告诉数据发送方，我已经收到你刚刚发送的报文，期待你给我发送确认序号起始的报文；

在这里插入图片描述

网络抓包
win --wireshark
linux-- tcpdump -i any port [端口号] -s o -w 123.dat

超时重传机制

当消息发送方发送一条消息，就会开启一个重传计时器，用来计算消息发出去的时间，如果发出去的时间大于RTO时，还没有收到确认报文，则重传该报文。

RTO=超时重传时间。动态计算出来的；
RTO=2*RTT
RTT=报文往返时间（从发送报文开始计算，直到收到确认应答，所经历的时间就称为报文往返时间）
在这里插入图片描述

滑动窗口机制

根据确认应答机制，滑动窗口机制的引入，不必让发送方等待一个报文的确认到达之后，再发送下一个报文。而是，允许发送方发送多个分组的报文到网络上。双方就会提高发送数据的效率；

窗口：已经被发送方发送到网络上，但是还没有完全确认的分组集合；

分组指TCP发送数据流序号的集合。

窗口大小：允许不接受确认应答，就可以发送到网络上的分组的数据;

窗口大小一般是15，tcp连接开始取值为8；

窗口移动：一定要收到最早的分组的确认应答之后，才可以向后进行滑动；

窗口可以动态变化的，是根据网络转发能力来决定的。
网络良好，窗口就会变大，数据发送的快；网络比较糟糕窗口就会变小，数据发送的慢；

滑动窗口可以动态的控制发送到网络上面的流量；
滑动窗口时传输层TCP协议进行流量控制的一种手段；

对于接收方而言，通知发送方自己可以接收的缓冲区大小，以此来控制发送方发送数据的大小，从而达到流量控制的目的

滑动窗口的大小是在三次握手期间进行协商的；
对于TCP通讯双方而言，都会维护一套窗口，发送窗口和接受窗口

发送窗口：保存的是没有确认的报文，发动缓冲区的一部分
接收窗口：等同与接收缓冲区

滑动窗口的接收方未收到Ack的报文如何处理？
在这里插入图片描述

拥塞控制机制

慢启动，拥塞避免，快重传，快恢复

慢启动

当双方建立连接之后，一开始不要发送大量的数据，而是先发送少量的数据，探测网络拥塞程度。当网络情况比较好的情况下，逐渐增大发送的数据量；

拥塞窗口：cwnd 通常发送方再发送数据的时候，不单单要考虑自己的发送窗口，还需要考虑拥塞窗口；

拥塞窗口一般等于发送窗口；
拥塞窗口小于发送窗口：按照拥塞窗口的大小发送数据；

三次握手期间协商窗口的大小，双方窗口大小需要保持一致；
在每次通信的时候，都会带有窗口的大小，而这个窗口大小的含义就是告诉自己的接收能力；

慢开始门限：是一个阈值，ssthresh,当拥塞窗口大小<慢门限，执行慢开始算法；超过慢开始门限，则执行拥塞避免算法；

在这里插入图片描述
当拥塞窗口小于慢开始门限时，执行慢开始算法（随着传输轮次的增加，拥塞窗口的大小进行指数增长）；
当cwnd==ssthresh,即可以使用慢开始算法，也可以使用拥塞避免算法；
当拥塞窗口大于慢开始门限时，执行拥塞避免算法（随着传输轮次的增加，拥塞窗口的大小进行线性增长）；

注意：
窗口大小决定我们可以往网络上面发送多少字节，并不是决定每次发送多少字节！
MSS:最大报文段长度，决定传输层的tcp协议每一最大给网络层提交多少数据！
(MTU:数据链路层对数据帧报文限制的大小 MTU=网络层ip(20字节）+传输层TCP头部(20)+MSS）

拥塞避免

当拥塞窗口大于慢开始门限时，拥塞窗口的大小随着传输轮次的线性增长；

快重传

当接收方接收到一个报文段的时候，就发出重复确认，意味着想让数据发送方提早的知道有一个数据段没有到达接收方；
对于发送方而言，发送报文之后就会开启一个重传计时器，但是如果收到接收方一连串发送三个重复确认到发送方，则不用等待设置的重传计时器，直接重传丢失的报文；
注意：
快速重传依赖的接收方连续的确认数据包，不会等待接收方进行捎带应答确认；

在这里插入图片描述

快恢复

如果网络拥塞导致发送方某一个TCP报文丢失，接收方会依照快重传，一连串发送3个确认包；
在这里插入图片描述

针对发送方而言，如果能够一连串收到三个重复确认的确认包。发送方会认为网络拥塞的并不是很严重，完全没有从慢开始进行传输，而是设置新的慢开始门限，将拥塞窗口等于新的慢开始门限，从而执行拥塞避免算法；

捎带应答机制

为了减少网络当中的数据量，当接收方接收到一个数据之后，发送确认的时候，是随着接收方发送给发送方的数据一起发送给发送方的；
在这里插入图片描述

延时应答机制

为了减少网络当中的数据包的数据量时，防止网络拥塞。

假设接收端缓冲区为1M. 一次收到了500K的数据; 如果立刻应答, 返回的窗口就是500K;
但实际上可能处理端处理的速度很快, 10ms之内就把500K数据从缓冲区消费掉了;
在这种情况下, 接收端处理还远没有达到自己的极限, 即使窗口再放大一些, 也能处理过来;
如果接收端稍微等一会再应答, 比如等待200ms再应答, 那么这个时候返回的窗口大小就是1M;
在这里插入图片描述

当接收方接收到数据之后，等待200ms，等待应用层程序将接受缓冲区当中的数据读走，从而扩大接收缓冲区的能力；在回复时，尽量告诉发送方自己的接受能力比较大的情况；

延时应答并不是不应答，而是不立即确认，等待一段时间再返回；

保活计时器
1.保证TCP连接时正常的；
2.产生的背景：当前这个连接已经2个小时没有产生数据了，则发送保活探测包；
3.每隔75s发送一个保活探测包，连续发送10次，如果10次都没有收到确认，则认为连接异常；需要断开连接；

保活计时器：只有收到数据，就会重置，从零开始机制

面向字节流

字节流：数据和数据之间没有明显的界限
针对应用层程序而言：接收的时候接收任意大小的数据，
粘包问题：明确两个包之间的边界
（粘包问题中的“包”：指的应用层的数据包）
为什么会产生粘包问题？
在TCP的协议头中，没有如同UDP一样的“报文长度”这样的字段，但是有一个序号这样的字段。
站在传输层的角度，TCP是一个一个报文发过来的，按照序号排序在缓冲区中。
站在应用层的角度，看到的只是一串连续的字节数据。
那么应用程序看到了这么一连串的字节数据，就不知道从那个部分开始到那个部分，是一个完整的应用层数据包。

如何避免粘包问题？
应用层头部+应用层数据+间隔
1.对于定长的包，保证每次都按固定大小读取即可；
2.对于变长的包。可以在包头位置，约定一个包总长度的字段，从而知道包的结束位置；
3.对于变长的包，还可以在包与包之间使用明确的分割符；

**对于UDP协议来说，是否也存在粘包问题？**不存在
对于UDP，如果还没有上层交付数据，UDP报文长度仍然在，同时，UDP是一个一个把数据交付给应用层。就有很明确的数据边界。
站在应用层的角度，使用UDP时，要么接收到完整的UDP报文，要么不收，不会出现“半个”的情况。