ip头、tcp头、udp头详解及定义，结合Wireshark抓包看实际状况

时间 2019-11-21

标签 tcp udp 详解定义结合 wireshark 抓包实际状况栏目系统网络繁體版

原文原文链接

公司的同事们在分析网页加载慢的问题，突然使用到了Wireshark工具，我就像发现新大陆同样好奇，赶忙看了看，顺便复习了一下相关协议。上学时学的忘的差很少了，汗颜啊！windows

报文封装总体结构

mac帧头定义

/*数据帧定义，头14个字节，尾4个字节*/
typedef struct _MAC_FRAME_HEADER
{
 char m_cDstMacAddress[6];    //目的mac地址
 char m_cSrcMacAddress[6];    //源mac地址
 short m_cType;       　　　　　//上一层协议类型，如0x0800表明上一层是IP协议，0x0806为arp
}__attribute__((packed))MAC_FRAME_HEADER,*PMAC_FRAME_HEADER;

ip头部定义

/*IP头定义，共20个字节*/
typedef struct _IP_HEADER 
{
 char m_cVersionAndHeaderLen;     　　//版本信息(前4位)，头长度(后4位)
 char m_cTypeOfService;      　　　　　 // 服务类型8位
 short m_sTotalLenOfPacket;    　　　　//数据包长度
 short m_sPacketID;      　　　　　　　 //数据包标识
 short m_sSliceinfo;      　　　　　　　  //分片使用
 char m_cTTL;        　　　　　　　　　　//存活时间
 char m_cTypeOfProtocol;    　　　　　 //协议类型
 short m_sCheckSum;      　　　　　　 //校验和
 unsigned int m_uiSourIp;     　　　　　//源ip
 unsigned int m_uiDestIp;     　　　　　//目的ip
} __attribute__((packed))IP_HEADER, *PIP_HEADER ;

版本（Version）字段：占4比特。用来代表IP协议实现的版本号，当前通常为IPv4，即0100。服务器
报头长度（Internet Header Length，IHL）字段：占4比特。是头部占32比特的数字，包括可选项。普通IP数据报（没有任何选项），该字段的值是5，即160比特=20字节。此字段最大值为60字节。网络
服务类型（Type of Service ，TOS）字段：占8比特。其中前3比特为优先权子字段（Precedence，现已被忽略）。第8比特保留未用。第4至第7比特分别表明延迟、吞吐量、可靠性和花费。当它们取值为1时分别表明要求最小时延、最大吞吐量、最高可靠性和最小费用。这4比特的服务类型中只能置其中1比特为1。能够全为0，若全为0则表示通常服务。服务类型字段声明了数据报被网络系统传输时能够被怎样处理。例如：TELNET协议可能要求有最小的延迟，FTP协议（数据）可能要求有最大吞吐量，SNMP协议可能要求有最高可靠性，NNTP（Network News Transfer Protocol，网络新闻传输协议）可能要求最小费用，而ICMP协议可能无特殊要求（4比特全为0）。实际上，大部分主机会忽略这个字段，但一些动态路由协议如OSPF（Open Shortest Path First Protocol）、IS-IS（Intermediate System to Intermediate System Protocol）能够根据这些字段的值进行路由决策。并发
总长度字段：占16比特。指明整个数据报的长度（以字节为单位）。最大长度为65535字节。tcp
标志字段：占16比特。用来惟一地标识主机发送的每一份数据报。一般每发一份报文，它的值会加1。工具
标志位字段：占3比特。标志一份数据报是否要求分段。学习
段偏移字段：占13比特。若是一份数据报要求分段的话，此字段指明该段偏移距原始数据报开始的位置。大数据
生存期（TTL：Time to Live）字段：占8比特。用来设置数据报最多能够通过的路由器数。由发送数据的源主机设置，一般为3二、6四、128等。每通过一个路由器，其值减1，直到0时该数据报被丢弃。ui
协议字段：占8比特。指明IP层所封装的上层协议类型，如ICMP（1）、IGMP（2）、TCP（6）、UDP（17）等。操作系统
头部校验和字段：占16比特。内容是根据IP头部计算获得的校验和码。计算方法是：对头部中每一个16比特进行二进制反码求和。（和ICMP、IGMP、TCP、UDP不一样，IP不对头部后的数据进行校验）。
源IP地址、目标IP地址字段：各占32比特。用来标明发送IP数据报文的源主机地址和接收IP报文的目标主机地址。
可选项字段：占32比特。用来定义一些任选项：如记录路径、时间戳等。这些选项不多被使用，同时并非全部主机和路由器都支持这些选项。可选项字段的长度必须是32比特的整数倍，若是不足，必须填充0以达到此长度要求。

tcp头部定义

/*TCP头定义，共20个字节*/
typedef struct _TCP_HEADER 
{
 short m_sSourPort;        　　　　　　// 源端口号16bit
 short m_sDestPort;       　　　　　　 // 目的端口号16bit
 unsigned int m_uiSequNum;       　　// 序列号32bit
 unsigned int m_uiAcknowledgeNum;  // 确认号32bit
 short m_sHeaderLenAndFlag;      　　// 前4位：TCP头长度；中6位：保留；后6位：标志位
 short m_sWindowSize;       　　　　　// 窗口大小16bit
 short m_sCheckSum;        　　　　　 // 检验和16bit
 short m_surgentPointer;      　　　　 // 紧急数据偏移量16bit
}__attribute__((packed))TCP_HEADER, *PTCP_HEADER;
/*TCP头中的选项定义

kind(8bit)+Length(8bit，整个选项的长度，包含前两部分)+内容(若是有的话)

KIND = 
  1表示 无操做NOP，无后面的部分

  2表示 maximum segment   后面的LENGTH就是maximum segment选项的长度（以byte为单位，1+1+内容部分长度）

  3表示 windows scale     后面的LENGTH就是 windows scale选项的长度（以byte为单位，1+1+内容部分长度）

  4表示 SACK permitted    LENGTH为2，没有内容部分

  5表示这是一个SACK包     LENGTH为2，没有内容部分

  8表示时间戳，LENGTH为10，含8个字节的时间戳
*/

源、目标端口号字段：占16比特。TCP协议经过使用"端口"来标识源端和目标端的应用进程。端口号可使用0到65535之间的任何数字。在收到服务请求时，操做系统动态地为客户端的应用程序分配端口号。在服务器端，每种服务在"众所周知的端口"（Well-Know Port）为用户提供服务。
顺序号字段：占32比特。用来标识从TCP源端向TCP目标端发送的数据字节流，它表示在这个报文段中的第一个数据字节。
确认号字段：占32比特。只有ACK标志为1时，确认号字段才有效。它包含目标端所指望收到源端的下一个数据字节。
头部长度字段：占4比特。给出头部占32比特的数目。没有任何选项字段的TCP头部长度为20字节；最多能够有60字节的TCP头部。
标志位字段（U、A、P、R、S、F）：占6比特。各比特的含义以下：
- URG：紧急指针（urgent pointer）有效。
- ACK：确认序号有效。
- PSH：接收方应该尽快将这个报文段交给应用层。
- RST：重建链接。
- SYN：发起一个链接。
- FIN：释放一个链接。
- 窗口大小字段：占16比特。此字段用来进行流量控制。单位为字节数，这个值是本机指望一次接收的字节数。
- TCP校验和字段：占16比特。对整个TCP报文段，即TCP头部和TCP数据进行校验和计算，并由目标端进行验证。
- 紧急指针字段：占16比特。它是一个偏移量，和序号字段中的值相加表示紧急数据最后一个字节的序号。
- 选项字段：占32比特。可能包括"窗口扩大因子"、"时间戳"等选项。

udp头部定义

/*UDP头定义，共8个字节*/

typedef struct _UDP_HEADER 
{
 unsigned short m_usSourPort;    　　　// 源端口号16bit
 unsigned short m_usDestPort;    　　　// 目的端口号16bit
 unsigned short m_usLength;    　　　　// 数据包长度16bit
 unsigned short m_usCheckSum;    　　// 校验和16bit
}__attribute__((packed))UDP_HEADER, *PUDP_HEADER;

传输控制协议（tcp）

因为维基百科专美与前，没法写的比其更好，因此，贴它的连接在这里：
https://zh.wikipedia.org/wiki/%E4%BC%A0%E8%BE%93%E6%8E%A7%E5%88%B6%E5%8D%8F%E8%AE%AE#.E8.BF.90.E4.BD.9C.E6.96.B9.E5.BC.8F

主要学习它的运做方式部分，就能较好的理解操做过程了。

wireshark使用前储备：MTU和MSS

wireshark以太网帧的封包格式为：

Frame=Ethernet Header +IP Header +TCP Header +TCP Segment Data

Ethernet Header =14 Byte =Dst Physical Address（6 Byte）+ Src Physical Address（6 Byte）+Type（2 Byte），以太网帧头如下称之为数据帧。
IP Header =20 Byte（without options field），数据在IP层称为Datagram，分片称为Fragment。
TCP Header = 20 Byte（without options field），数据在TCP层称为Stream，分段称为Segment（UDP中称为Message）。
54个字节后为TCP数据负载部分（Data Portion），即应用层用户数据。

Ethernet Header如下的IP数据报最大传输单位为MTU（Maximum Transmission Unit，Effect of short board），对于大多数使用以太网的局域网来讲，MTU=1500。

TCP数据包每次可以传输的最大数据分段为MSS，为了达到最佳的传输效能，在创建TCP链接时双方将协商MSS值——双方提供的MSS值中的最小值为此次链接的最大MSS值。MSS每每基于MTU计算出来，一般MSS=MTU-sizeof(IP Header)-sizeof(TCP Header)=1500-20-20=1460。

这样，数据通过本地TCP层分段后，交给本地IP层，在本地IP层就不须要分片了。可是在下一跳路由（Next Hop）的邻居路由器上可能发生IP分片！由于路由器的网卡的MTU可能小于须要转发的IP数据报的大小。

这时候，在路由器上可能发生两种状况：

（1）若是源发送端设置了这个IP数据包能够分片（May Fragment，DF=0），路由器将IP数据报分片后转发。

（2）若是源发送端设置了这个IP数据报不能够分片（Don’t Fragment，DF=1），路由器将IP数据报丢弃，并发送ICMP分片错误消息给源发送端。

wireshark实战

一个简单的请求示例截图如图：

从左到有依次为no（Frame编号)、Time(时间)、Source（源地址）、Destination(目的地址)、Protocal（协议）、Length（包大小）、Info（详细信息）。
tcp请求与回复的info中包括：端口信息（如63703->8279）表示src.port -> des.port，标志位信息（如SYN、ACK）、Seq信息、Ack信息（注意，这个ack是确认号字段m_uiAcknowledgeNum）、len（上层数据长度）、MSS（mss长度）、WS（窗口大小字段）。
实际操做中，头部为66字节，是由于加了12字节的tcp选项信息。实际MSS为1460.
每条数据的详细信息均可以在选中数据后在下方显示，如图：

从上到下依次为Frame（整个桢信息）、Ethernet II（以太头信息）、Internet Protocal Version(IP头信息)、Transmission Control Protocal（TCP头信息），点开后每个字段的详细信息均可显示，与协议一致。

结合实践分析tcp运做方式

三次握手：tcp经过三次握手建立连接，如图，
首先63703->8279 发送SYN，Seq=0;而后8279->63703, 发送SYN&&ACK, Seq=0, Ack=1;最后63703->8279 发送ACK,Seq=1，Ack=1。这样就完成了三次握手。
与维基百科中的相关知识，作对照，发现彻底符合实践:

1.客户端经过向服务器端发送一个SYN来建立一个主动打开，做为三路握手的一部分。客户端把这段链接的序号设定为随机数A。首先63703->8279 发送SYN，Seq=0 A=0.
2.服务器端应当为一个合法的SYN回送一个SYN/ACK。ACK的确认码应为A+1，SYN/ACK包自己又有一个随机序号B。而后8279->63703, 发送SYN&&ACK, Seq=0, Ack=1 B=0
3.最后，客户端再发送一个ACK。当服务端受到这个ACK的时候，就完成了三路握手，并进入了链接建立状态。此时包序号被设定为收到的确认号A+1，而响应则为B+1。最后63703->8279 发送ACK,Seq=1，Ack=1。这样就完成了三次握手。
数据传输：69和70是一个http请求，由于包过长，切分红两个tcp包。75和76分别对这两个包进行ack响应，告知已经收到。81则对请求作了业务上的响应返回。而82则是对81的ack响应。（未贴出数据：69：Seq=1,Ack=1,Len=1448 ; 70:Seq=1449,Ack=1,Len=112 ; 81:Seq=1, Ack=1561, Len=123）。分析上述几条数据咱们发现，Seq的递增主要是看上一条发送数据的Len，如Seq70 = Seq69 + Len69。而一条数据的ack信息的ack值也是看请求数据的seq和len。如75是对69的ack，则Ack75=Seq69+Len69。这一规律也符合协议规定。具体见维基百科数据传输举例。固然，也有选择确认（Selective Acknowledgement）的示例，就不贴出来了。
选择确认：TCP报文的接收者为了确保可靠性，在接收到必定数量的连续字节流后才发送确认。

Wireshark（前称Ethereal）是一个网络封包分析软件。网络封包分析软件的功能是撷取网络封包，并尽量显示出最为详细的网络封包资料。Wireshark使用WinPCAP做为接口，直接与网卡进行数据报文交换。做为一个免费的软件，真的很是好用。

参考资料：

1. 传输控制协议,维基百科，https://zh.wikipedia.org/wiki/%E4%BC%A0%E8%BE%93%E6%8E%A7%E5%88%B6%E5%8D%8F%E8%AE%AE#.E5.BB.BA.E7.AB.8B.E9.80.9A.E8.B7.AF
2.TCP通讯流程解析，CSDN博客，http://blog.csdn.net/phunxm/article/details/5836034
3.IP头、TCP头、UDP头详解以及定义，CSDN博客,http://blog.csdn.net/mrwangwang/article/details/8537775#comments