TCP和UDP报文头格式

本文详细介绍了TCP和UDP两种传输层协议的特点。对于TCP,重点讲解了其首部字段的含义和作用,包括源端口、目的端口、序号、确认号等;而对于UDP,则简单介绍了其首部字段。此外,还探讨了TCP中的紧急数据处理机制以及一些特殊标志位的功能。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

一、TCP
这里写图片描述
1.源端口和目的端口:各占2个字节。

2.序号:占4字节。序号范围是0~2^32-1。TCP是面向字节流的,TCP连接中传送的字节流中的每个字节都按顺序编号。整个要传送的字节流的起始序号必须要在连接建立时设置。首部中的序号字段值指的是本报文段所发送的数据的第一个字节的序号。

3.确认号:4个字节,是期望收到对方下一个报文段的第一个数据字节的序号。
若确认号=N,则表明:到序号N-1为止的所有数据都已正确收到。
4.数据偏移:4位。指出TCP报文段的数据起始处距离报文段的起始处有多远。这个字段实际上是指出TCP报文段的首部长度。由于首部中还有长度不确定的选项字段,因此数据偏移字段是必要的。单位是32位字,也就是4字节,4位二进制最大表示15,所以数据偏移也就是TCP首部最大60字节

5.保留:6位
下面有6个控制位说明本报文段的性质

6.紧急URG:1位
当URG=1时,表明紧急指针字段有效。它告诉系统此报文段中有紧急数据,应尽快传送(相当于高优先级的数据),而不要按原来的排队顺序来传送。例如,已经发送了很长的一个程序在远地的主机上运行。但后来发现了一些问题,需要取消该程序的运行。因此用户从键盘发出中断命令(Control+c)。如果不使用紧急数据,那么这两个字符将存储在接收TCP的缓存末尾。只有在所有的数据被处理完毕后这两个字符才被交付接收方的应用进程。这样做就浪费了许多时间。

当URG置为1时,发送应用进程就告诉发送方的TCP有紧急数据要传送。于是发送方TCP就把紧急数据插入到本报文段数据的最前面,而在紧急数据后面的数据仍时普通数据。这时要与首部中紧急指针字段配合使用。

7.确认ACK
仅当ACK=1时确认号字段才有效。当ACK=0时,确认号无效。TCP规定,在连接建立后所有的传送的报文段都必须把ACK置1。

8.推送PSH
当两个应用进程进行交互式的通信时,有时在一端的应用进程希望在键入一个命令后立即就能收到对方的响应。在这种情况下,TCP就可以使用推送操作。这时,发送方TCP把PSH置1,并立即创建一个报文段发送出去。接收方TCP收到PSH=1的报文段,就尽快地交付接收应用进程,而不再等到整个缓存都填满了后向上交付。

虽然应用程序可以选择推送操作,但推送还很少使用。

9.复位RST
tcp连接出现严重差错时释放连接,然后重新建立连接。而可以用来拒绝一个非法的报文段或拒绝打开一个连接。

当RST=1时,表明TCP连接中出现严重差错(如由于主机崩溃或其他原因),必须释放连接,然后再重新建立运输连接。RST置1还用来拒绝一个非法的报文段或拒绝打开一个连接。

10.同步SYN
在连接建立时用来同步序号。当SYN=1而ACK=0时,表明这是一个连接请求报文段。对方若同意建立连接,则应在相应的报文段中使用SYN=1和ACK=1。因此,SYN置为1就表示这是一个连接请求或连接接受保温。

11.终止FIN
用来释放一个连接。当FIN=1时,表明此报文段的发送方的数据已发送完毕,并要求释放运输连接。

12窗口 占2字节。窗口值是【0,2^16-1]之间的整数。窗口指的是发送本报文段的一方的接收窗口(而不是自己的发送窗口)。窗口值告诉对方: 从本报文段首部中的确认号算起,接收方目前允许对方发送的数据量。之所以要有这个限制,是因为接收方的数据缓存空间是有限的。总之,窗口值作为接收方让发送方设置其发送窗口的依据。并且窗口值是经常在动态变化着。

13.检验和:2字节。检验范围包括首部和数据两部分。和UDP用户数据报一样,在计算校验和 时,要在TCP报文段加上12字节的伪首部。

14.紧急指针:2字节。紧急指针仅在URG=1时才有意义,它指出本报文段中的紧急数据的字节数(紧急数据结束后就是普通数据)。因此,紧急指针指出了紧急数据的末尾在报文段中的位置。当所有紧急数据都处理完时,TCP就告诉应用程序恢复到正常操作。值得注意的是,即使窗口为零时也可发送紧急数据。

15.选项:长度可变,最长可达40字节。当没有使用“选项”时,TCP的首部长度是20字节。
1)MSS 最大报文段长度
MSS最大报文段长度(数据字段的最大长度,默认是536字节)。MSS不宜设的太大也不宜设的太小。若选择太小,极端情况下,TCP报文段只含有1字节数据,在IP层传输的数据报的开销至少有40字节(包括TCP报文段的首部和IP数据报的首部)。这样,网络的利用率就不会超过1/41。若TCP报文段非常长,那么在IP层传输时就有可能要分解成多个短数据报片。在终点要把收到的各个短数据报片装配成原来的TCP报文段。当传输出错时还要进行重传,这些也都会使开销增大。

因此MSS应尽可能大,只要在IP层传输时不需要再分片就行。在连接建立过程中,双方都把自己能够支持的MSS接入这一字段,以后就按照这个数值传送数据。
2)窗口扩大
窗口扩大选项是为了扩大窗口。TCP首部中窗口字段长度是16位,因此最大窗口大小就是64k字节。对于包含卫星信道的网络可能是不够用的。可以在双方初始建立TCP连接的时候就进行协商。
3)时间戳(计算RTT,防止序号绕回)
A. 用来计算往返时间RTT。发送方在发送报文段时把当前时钟的时间值放入时间戳字段,接收方在确认该报文段时把时间戳字段值复制到时间戳回送回答字段。因此,发送方在收到确认报文后,可以准确地计算RTT来。
4)选择确认选项
二、UDP
这里写图片描述
UDP协议分为首部字段和数据字段,其中首部字段只占用8个字节,分别是个占用两个字节的源端口、目的端口、长度和检验和。

### TCP 报文头部中的确认号 在TCP协议中,确认号(Acknowledgment Number, ACK)是一个非常重要的字段。当ACK标志位被设置为1时,该字段有效。此字段表示期望接收到的下一个字节序号,即接收方希望发送方下次发送的数据起始位置[^2]。 对于建立连接后的通信过程而言,每次一方发送数据给另一方之后,接收方会通过返回带有特定值的确认号来告知对方已成功接收到哪些数据以及期待继续接收后续哪个序列编号的数据包。这种机制有助于实现可靠传输并能及时发现丢失或重复的数据段。 ```python # Python伪代码展示如何处理TCP报文中确认号逻辑 def handle_tcp_ack(ack_number): """ 处理来自远程主机的TCP确认消息 参数: ack_number (int): 接收到的确切确认号码 返回: next_expected_seq_num (int): 下一次应该发送的数据段序列号 """ # 假设当前已经正确接收到了直到seq_num的数据 seq_num = get_last_received_sequence_number() if ack_number == seq_num + 1: print("所有之前发出的数据已被确认") return seq_num + length_of_data_sent elif ack_number < seq_num + 1: print(f"存在未确认的数据, 需要重传 {ack_number} 及其后的内容") else: print("出现了异常情况,可能是因为收到了错误的确认信息") return None ``` ### UDP 报文头部中的确认号 相比之下,在UDP协议的设计里并没有提供像TCP那样复杂的流量控制拥塞管理特性,因此在其标准定义下不存在所谓的“确认号”。这意味着每一个独立的UDP数据报都是单独存在的个体,并不会依赖于之前的任何其他数据报来进行状态跟踪或者顺序排列。所以也就没有必要设立专门用于反馈接收状况的信息域[^1]。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值