ip头、tcp头、udp头详解及定义,结合Wireshark抓包看实际情况 - 白羊沈歌 - 博客园

·  阅读 121
原文链接: www.cnblogs.com

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

报文封装整体结构

报文整体结构

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头部结构

/*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字节。

  • 标志字段:占16比特。用来唯一地标识主机发送的每一份数据报。通常每发一份报文,它的值会加1。

  • 标志位字段:占3比特。标志一份数据报是否要求分段。

  • 段偏移字段:占13比特。如果一份数据报要求分段的话,此字段指明该段偏移距原始数据报开始的位置。

  • 生存期(TTL:Time to Live)字段:占8比特。用来设置数据报最多可以经过的路由器数。由发送数据的源主机设置,通常为32、64、128等。每经过一个路由器,其值减1,直到0时该数据报被丢弃。

  • 协议字段:占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头部定义

ip头部结构

/*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头部定义

/*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)

由于维基百科专美与前,无法写的比其更好,所以,贴它的链接在这里:
zh.wikipedia.org/wiki/%E4%BC…

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

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实战

一个简单的请求示例截图如图:
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运作方式

  1. 三次握手: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。这样就完成了三次握手。

  2. 数据传输: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)的示例,就不贴出来了。

  3. 选择确认:TCP报文的接收者为了确保可靠性,在接收到一定数量的连续字节流后才发送确认。

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

参考资料:

1. 传输控制协议,维基百科,zh.wikipedia.org/wiki/%E4%BC…
2.TCP通信流程解析,CSDN博客,blog.csdn.net/phunxm/arti…
3.IP头、TCP头、UDP头详解以及定义,CSDN博客,blog.csdn.net/mrwangwang/…

分类:
阅读
标签:
分类:
阅读
标签:
收藏成功!
已添加到「」, 点击更改