网络-----浅析IP数据报格式及TCP/UDP报文段首部格式

港控/mmm° 2022-05-24 00:52 420阅读 0赞

\#\#\#IP数据报的格式

先来上张图在解释：  
![这里写图片描述][70]

来看看每个字段的具体含义：(只讨论IPV4的情况)

**1、版本**  
占4位，指IP协议的版本。通信双方使用IP协议的版本必须一致。例：使用IPV4即填4

**2、首部长度**  
占4位，顾名思义，这个字段就是标识了IP数据报的首部长度。该字段以4字节为单位，可以表示的最大的数是"1111"，也就是十进制数15，所以IP首部长度最大为60字节(15\*4=60)。由于IP首部固定长度为20字节，所以该字段的最小值为"0101"。

**3、区分服务**  
占8位。有3位优先权字段已经弃用，还有4位TOS字段和1位保留字段(这个保留字段必须置为0)。4位TOS字段分别代表最小延时、最大吞吐量、最高可靠性、最低成本。这四者相互冲突，只能选择一个。

**4、总长度**  
占16位，表示IP数据报的总长度(包括数据部分)。单位为字节，所以数据报的最大长度为65535字节(2^16-1)。  
在这里补充一个知识：**最大传输单元MTU**。表示某一层上面可以通过的最大的数据包的大小，所以IP数据报的总长度不能超过下面数据链路层的MTU值。  
为了不使IP数据报的传输速率降低，规定所以主机和路由器必须能够处理的IP数据报长度不得小于576字节。当数据报长度超过网络所容许的最大传输单元时，就要把过长的数据报进程分片，这时数据报首部中的总长度不是指没有分片前的数据报长度，而是指分片后每一个分片数据报的长度。

**5、标识**  
占16位，IP软件在存储器中维持一个计数器，每产生一个数据报计数器就加一，并将这个值赋给标识字段。当数据报长度超过网络的MTU要进行分片时这个标识字段的值就会复制到所有的数据报片的标识字段中。为了之后重新组装数据的时候可以分辨哪些数据报之前属于一个数据报的。

**6、标志**  
占3位。标志虽然占了三位，但目前只有两位有意义

*  \*\*MF：\*\*在最低位，MF=1表示后面还有分片的数据报，MF=0表示这已经是所有数据报片中的最后一个了
 *  \*\*DF：\*\*在中间的一位，DF=1表示不允许分片，DF=0表示允许分片

**7、片偏移**  
占13位。该字段表示，被分片的数据报，每一个数据报片在原分组的相对位置。也就是说相对于用户数据字段的起点该片从何处开始。  
片偏移以8个字节为单位所以每个分片的长度一定是8字节的整数倍

**8、生存时间**  
占8位，这个字段也就是我们常说的**TTL**，表示数据报在网络中的寿命，目的是为了防止数据报在传送过程中无限制的在因特网中兜圈子而白白浪费网络资源。  
TTL的单位是**跳数**，路由器在转发这个数据报之前就将该数据报的TTL减一，当数据报的TTL被减到0时，就丢弃这个数据报。

**9、协议**  
占8位。协议字段指出此数据报携带的是哪种协议，这样就可以使目的主机的网络层知道应该将数据部分上交给哪个传输层协议处理。  
来看看常见的协议及相应的协议字段值：  
![这里写图片描述][70 1]

**10、首部检验和**  
占16位，这个字段是为了帮助路由器检验收到的IP数据报中的比特错误。需要注意的是，这个字段只检验数据报的首部，不包括数据部分。数据报每经过一个路由器，路由器都要重新计算一下首部检验和。  
来看看IP数据报是如何检验的：

1.  在发送方，先把IP数据报首部划分为许多的16位字的序列，并把检验和字段置零。
2.  在用反码算数运算把所有16位字相加后，将得到的和的反码写进检验和字段。
3.  接收方收到数据报之后，将首部的所有16位字在使用反码算数运算相加一次，将得到的和取反码，即得出接收方检验和的计算结果。
4.  我们根据接收方检验和结果判断，如果结果为0，表示此数据报有效，不为0就丢弃该数据报。

**11、源IP地址**  
占32位，表示发送方主机的IP地址

**12、目的IP地址**  
占32位，表示目的主机的IP地址

**13、IP数据报首部的可变部分**  
IP首部的可变部分就是一个选项字段。此字段长度可变，从1字节~40字节不等。最后用全0的填充字段补齐为4字节的整数倍  
注：IPV6不在采用此字段

**14、数据**  
数据字段就是要交付给目的地的传输层报文段(TCP/UDP等)，也可以承载其他类型的数据(ICMP报文段等)

--------------------

\#\#\#TCP报文段首部

同样先上图：

![这里写图片描述][70 2]

**1、源端口号**  
占16位，标识发送主机的端口或进程，一个TCP报文必须包含源端口号，要让接收主机知道该向哪发送确认报文

**2、目的端口号**  
占16位，标识目的主机的端口或进程

**3、序号**  
占32位，即4个字节。序号范围是0~(232-1)，当序号增加到232-1后，下一个序号又会变成0。因为TCP是面向字节流的，在一个TCP连接中的每一个字节都按顺序编号。整个要传送的字节流的起始序号必须在连接建立时设置。首部中的序号字段则指的是本报文段所发送的数据的第一个字节的序号。

**4、确认序号**  
同样的占4个字节，标识了期望收到对方下一个报文段的第一个数据字节的序号。  
注：若确认序号=N，表明到序号N-1为止的所有数据都确认收到

**5、首部长度**  
占4位。这个字段指出TCP报文段的数据起始处距离TCP报文段的起始处有多远。也就是TCP报文段首部的长度。

**6、保留**  
占6位，保留为今后用，目前都置为0

**7、六个标志位**

*  **URG**：紧急标志位。当URG=1时，表明紧急指针字段(后面介绍)有效，它告诉操作系统报文段中有紧急数据应该被尽快传送
 *  **ACK**：确认标志位。仅当ACK=1时该字段才有效。TCP规定在连接建立后所有传送的报文段都必须把ACK置为1.
 *  **PSH**：推送标志位。当两个应用进程进行交互式的通信时，有时在一端的应用进程希望在键入一个命令后立即就能够收到对方的响应。在这种情况下，发送方TCP就可以将PSH字段置 1 ，并立即创建一个报文段发送出去，接收方收到 PSH = 1 的报文段，就尽快地交付给接收应用进程，而不再等到整个缓存都填满后再向上交付。
 *  **RST**：复位标志位。当RST=1时，表明TCP连接中出现了严重差错必须释放连接，然后在重新建立运输连接。RST置为1还可以用来拒绝一个非法的报文段或拒绝打开一个连接。
 *  **SYN**：同步标志位。在连接建立时用来同步序号。当SYN=1而ASK=0时表明这是一个连接请求报文段。如果对方同意建立连接，就可以在响应报文段中使用SYN=1和ACK=1。
 *  **FIN**：终止标志位。用来释放一个连接，当FIN=1时，表明此报文段发送方的数据已经发送完毕，并要求释放连接。

**8、窗口**  
占16位。窗口值是0~(2^16-1)之间的整数。  
窗口指的是发送本报文段的一方的接收窗口，也就是自己接受缓冲区的大小。窗口值告诉对方，从本报文段首部中的确认号算起，接收方目前允许对方发送的数据量。**窗口值作为接收方让发送方设置其发送窗口的依据**。

**9、检验和**  
占16位。和IP数据报不同的是，TCP报文段检验的范围包括首部和数据两部分(IP数据报只检验首部部分)，但是检验方法类似。

1.  在发送方，首先把全零放入检验和字段
2.  把伪首部以及TCP数据报看成是由许多16位字的字串连接起来。若TCP报文段的数据部分不是偶数个字节，则要填入一个全零字节(但此字节不发送)
3.  然后按二进制反码计算出这些16位字的和，将结果的二进制反码写入检验和字段并发送
4.  在接受方，把收到的TCP报文连同伪首部一起按二进制反码求出这些16位字德和。当无差错时结果为1，若结果为0，就表示有差错，接收方就丢弃这个报文段

在这里说一下伪首部的概念：伪首部有12个字节，分为5个字段。  
第一字段和第二字段分别为源IP地址和目的IP地址。  
第三字段是全零  
第四字段是IP首部中的协议字段的值  
第五字段是TCP数据报的长度

**10、紧急指针**  
占16位。紧急指针只在URG=1时有效，标识了本报文段中紧急数据的字节数，指出来紧急数据末尾在报文段中的位置  
注：当窗口为0时，也可以发送紧急数据。

**11、选项**  
也是一个可变长字段最大可达40字节，当没有使用选项时，TCP的首部长度就是20字节。

--------------------

\#\#\#UDP报文段首部

相对于TCP报文段，UDP报文段就很简单了  
![这里写图片描述][70 3]

**1、源端口号**  
占16位。标识源主机的端口或进程，同TCP。

**2、目的端口号**  
占16位。标识要发送个目的主机的哪个端口或进程

**3、首部长度**  
占16位。标识UDP整个数据报的长度(包括首部和数据)。最小值为8(仅有首部)

**4、检验和**  
占16位。检测UDP用户数据报在传输中是否有错，有错就丢掉。检测方式同TCP一样，检验范围也是包括首部和数据。

[70]: /images/20220524/1b9cfe3dbbd7492e962798d261cd8d73.png
[70 1]: /images/20220524/5f3ef304eb2e4152b4a20059dd5405fc.png
[70 2]: /images/20220524/b0f0035fac94441c8fb18099da304976.png
[70 3]: /images/20220524/a71b87c5382544e6b78ad62c441448d3.png