IPv4 Header
1.IPv4 Header
| 名称 | 作用说明 |
|---|---|
| IP Version | 4 bits , 总共有2^4 变化， 可以表示的数值 0~15 ， 因此 IP Version最多可以标识 16种版本 ，ipv4 版本中 IP Version 的值为4，ipv6版本中 IP Version的值为6 ， 已经被使用的版本：0,1,2,3,4,5,6,7,8 ,9 ， 因此 下一个 IP 版本 应该是IPv10 |
| IHL(Internet Header Length) | 4bits ，总共有2^4 变化， 可以表示的数值 0~15， 该字段 用于声明 IPv4 包的 Header 长度，该字段值有个范围： 5~15, IHL = 5： 标示无 Options 字段 ，及 Header 长度为 20Bytes,IHL =15：表示 含 Options字段， 因为 Options字段最大长度是 40 Bytes ，因此 IPV4包的 Header 长度 最大也就60Bytes,所以只要带有Options字段，那么 IHL字段的值 一般都大于 5,如果是IMCPv4 或者 传输头，那么 数据包的 开头会 跳过前32位，从 Fragment ID 开始 |
| **TOS (Type of Service) ** | 8bits ， 用于描述数据包的优先级，从而确定服务的优先级在RFC 2474，2475 中有相关的定义和说明：http://www.ietf.org/rfc/rfc2474.txt,http://www.ietf.org/rfc/rfc2475.txt,这个是用来 实现一个简单的QoS (Quality of Service) , 通过 协议 、 发送方、 接收方 来管理带宽，例如,您可能想要给你的网络电话连接优先级高于你的视频下载,或从你的老板网络通信更高的优先级比你的同事的网络通信，那么，就得使用 Qos 来定义 你这个连接的优先级了，如果没有QoS,带宽是先到先得，就是无论什么连接，都得排轮子,但是，8位不够真正做好QoS,和DiffServ，所以目前 TOS位 并没有被广泛使用在IPv4网络中 ， 然而 QoS在IPv6得到了很大的提升,TOS位描述的是一个 数据包的优先级——实际上路由器在决定数据包 如何排队等待重传时，就是已经在使用 TOS位来判断优先级了，如果一个数据包无法提供请求的服务水平，那么 路由器 会把数据包的 TOS位标记为：undeliverable |
| Total Length | 该字段总共16 bits,用于描述报文的总长度，肯定也 包含 报头长度,理论上 最小长度是20(20字节的头加上+0字节的Options+ 0字节的数据),和最大是65535个字节(因为只有16位可用来指定),实际上 所有网络设备所能处理的数据包的 长度 各不一样,一般而言 网络设备至少具有 处理数据包的 长度是 576 字节,但一个更典型的包的大小是1508字节 ， 所以一个数据包极有可能遇到一个包处理长度低于被传输包长度的设备（该包的大小 大于该设备的最大包长度处理能力) 此时数据包就需要分片然后传输, 最后 到达目的地进行重组。分片和重组使得 IPv4 变得复杂，也容易混乱,IPv6中针对对此有很大改善 |
| Identification | 数据包被 切片后的 ID,及 Fragment ID,一共16bits,这样就有足够多的ID可用 |
| 空bit | 1bit ， 一个保留位，必须为0 |
| DF | 1bit ， (Don’t Fragment) flag 标示数据包 不允许 切分， 如果 该包的长度 超出了 网络 设备的处理能力，并且又打上的 DF 标签,那么该网络设备会 丢弃掉该数据包 |
| MF | 1bit， (More Fragments) flag ,用于表示 数据包是否被分片了,如果被分片了该位为1,如果没被分片那么该位为0 |
| Fragment Offset | 13bits,分片的偏移量,用于决定分片重组时的顺序 |
| Time-to-live(TTL) | 8bits,用于防止网络中数据包被无限期的循环路由,最初想用秒数来设定TTL,但是没能实现,最后以跳数实现了,所以TTL的值描述的是包所能剩下的跳数(路由次数), 如果没跳一次(路由一次)次值就减一,如果跳数为0 ,这路由设备会丢弃此包,如果包被路由设备 Dropped,那么该路由设备会以返回给包发送者一条 ICMPv4的 不被路由的信息 (“time exceeded”)，Traceroute 就是利用此原理来得到每一跳的路由设备的IP地址的 |
| Protocol | 8bits,用于定义IPv4 Header过后的下一个Header协议类型 |
1 ICMPv4 Internet Control Message Protocol for IPv4 ([RFC 792](http://tools.ietf.org/html/rfc792))
2 IGMP Internet Group Management Protocol (RFCs [1112](http://tools.ietf.org/html/rfc1112), [2236](http://tools.ietf.org/html/rfc2236) and [3376)](http://tools.ietf.org/html/rfc3376)
4 IPv4 IPv4 in IPv4 encapsulation, “IP in IP” tunneling ([RFC 2003)](http://tools.ietf.org/html/rfc2003)
6 TCP Transmission Control Protocol ([RFC 793](http://tools.ietf.org/html/rfc793))
8 EGP Exterior Gatgeway Protocol ([RFC 888](http://tools.ietf.org/html/rfc888))17 UDP User Datagram Protocol ([RFC 768](http://tools.ietf.org/html/rfc768))41 IPv6 IPv6 tunneled over IPv4, “6in4” tunneling ([RFC 2473](http://tools.ietf.org/html/rfc2473))
50 IPSec ESP Header ([RFC 2406](http://tools.ietf.org/html/rfc2406))
51 IPSec AH Header ([RFC 2402](http://tools.ietf.org/html/rfc2402))89 OSPF Open Shortest Path First routing ([RFC 1583](http://tools.ietf.org/html/rfc1583))132 SCTP Streams Control Transmission Protocol ([RFC 4960](http://tools.ietf.org/html/rfc4960))
| Header Checksum | IPv4 Header 校验码，一共16bits,2个字节,当计算校验码时,本字段(Header CheckSum)会被置0,所以Header Checksum 字段是不参与 校验的,因此 Header的20字节里面参与校验的仅有18个字节,又因为 TTL 每一跳都要减一,所有Header的Checksum计算,每跳都要进行 |
| **Source Address ** | 4字节,用于描述源IP |
| Destination Address | 4字节,用于描述目标IP |
| Options | 很少使用,可选,最大 40字节 具体参考 RFC791 |
2. TCP Header
TCP Header
| 名称 | 作用说明 |
|---|---|
| Source Port Number | 源端口号， 16bits ，能表示的数值范围 0~65535， 对于linux 系统而言， 1024 以下的端口是特权端口，仅能root使用 |
| Destination Port Number | 目标端口号， 16bits ，也能表示 0~65535 |
| Sequence Number | 32bits， TCP报文的序列号 |
| Acknowledgement Number | 32bits， 确认 Sequence Number 的 确认号 ， 一般 确认号的表示方式是 ： 被确认的Sequence Numbe + 1， 必要要确认 对方100号报文，那么确认号就是 101 |
| Header Length | 4bits， TCP Header 的长度 最小20字节， 最大60字节 ， 因为 Options 最大40bytes |
| Reserved | 4bits， 保留位 |
| CWR | 1bit， Congestion Window Reduced |
| ECN | 1bit， Explicit Congestion Notice |
| URG | 1bit， Urgent的缩写， 紧急位，大部分报文会在 TCP/IP协议栈的 内核缓存区 等待处理， URG的意思就是 把这个请求 插入到 内核缓存区的前面，让报文尽快被处理 |
| ACK | 1bit， Acknowledgement的缩写， 确认位， 将该位 设置1 既可 开启此位， 开启此位表示 此报文为 确认报文，Acknowledgement Number 才会有效，因此 仅当 3次握手的第一次时 ACK 为0， 其他时候 都为1 |
| PSH | 1bit，推送位，不经过内核缓存区，直接接收处理 |
| RST | 1bit，重置位， 用于重置TCP 连接 |
| SYN | 1bit，请求位，synchronization的缩写， 用于发起 TCP连接请求， 将该位 设置1 既可 开启此位， 表示这是一条 TCP 请求报文，因此 ，3次握手当做 仅有第一次 SYN 位 才为1，其他时候 都为0 |
| FIN | 1bit，结束位，finish的缩写， 用于结束TCP连接请求，将该位 设置1 既可 开启此位， 4次挥手中， Initiator 请求断开时 FIN 为1 ，Receiver 处理完请求，也请求断开时 FIN 为1 |
| Window Size | 16bits, 滑动窗口，根据 接收缓冲进行调整，为了提高效率， 报文不会1个1个的发送，而是一批一批的发送， 确认也是 一批一批的进行确认（及延迟确认）， 那么 一批发送多少个报文合适喃？这个值是根据对方的发送缓冲、线路容纳、 自己接收缓冲 这3个条件， 取最小的那个 作为 批量发送的报文数,当这一批报文 到达自己的 接收缓冲过后， 如果接收缓冲还有空间 缓冲报文， 就会以 Window Size 这个字段告诉 发送方，下次可以 一批发多少个报文过来因此，这个 Window Size 是 动态变化的 |
| TCP Checksum | TCP 报文校验码 |
