TCP ip封包

TCP/IP 分析(整理+转帖） 操作系统为Windows2000 server 版，因为在寝室里只有一台电脑，而且没有网卡（只有一个56K 的老猫），所以安装了虚拟机VMware-workstation（ 网上很多地方可以下载，这里就不提供下载了，安装也很简单）； 虚拟操作系统是RedHat 8.0 ，为了节省空间和加快速度，没有安装图形界面。关于虚拟系统的安装可以在Google 上搜一下。 这里说一下 Virtual Networks 的设置，如图1-1： INCLUDEPICTURE "http://oa1.jmu.edu.cn/netoa/libq/pubdisc.nsf/e28ed69f46b9e7ff482567b4002a2622/7173cf0ca72eea9748257288004ff1fd/Body/0.420?OpenElement&FieldElemFormat=jpg" \* MERGEFORMATINET 图1-1 设置虚拟网络     两个虚拟网络分别是VMnet1 地址为192.168.126.0 和VMnet8 地址为192.168.216.0，主操作系统windows2000， 安装了两个虚拟网卡，地址分别是192.168.126.1 和192.168.216.1， 主操作系统和虚拟系统的网络关系是Custom 模式，如图1-2： 图1-2 设置虚拟机网卡     打开虚拟机，以root 用户登录redhat，输入setup，设置虚拟机IP 地址为192.168.126.128， 如图1-3： 图1-3 设置Linux IP 地址   好了，设置完了。当然，这只是因为条件限制才如此的，在局域网中就不用这么麻烦了。 实验目的： 巩固对Ethernet II 封包、ARP 分组及IP、ICMP 数据包的认识     嗯，现在开始了。打开Ethereal，在菜单Capture 下点击Interfaces， 选取要抓包的网卡， 这里选取地址为192.168.126.1 的这个网卡抓取数据包，如图1-4： 图1-4 选择抓取数据包网卡     之后在主操作系统中使用ping 192.168.126.128 –t 的命令，来ping 虚拟机。好，我们来看看抓取的数据包。 图1-5 ARP 广播包     从Ethereal 的第一栏中，我们看到这是个ARP 解析的广播包，如图1-5。由于这个版本的Ethereal 使用的是Ethernet II 来解码的，我们先看看Ethernet II 的封装格式。如下图1-6： 图1-6 以太网封包格式 注意这个和802.3 是有区别的，802.3 的封包格式如图1-7： 图1-7 802.3 封包格式     尽管Ethernet II 和802.3 的封包格式不同，但Ethereal 在解码时，都是从“类型”字段来判断一个包是IP 数据报还是ARP 请求/应答或RARP 请求/应答。     从Ethernet II 知道了是ARP 解析以后，我们来看看Ethereal 是如何判断是ARP 请求呢还是应答的。 我们先复习一下以太网的ARP 请求和应答的分组格式，如图1-8。 图1-8 分组格式    从上图中我们了解到判断一个ARP 分组是ARP 请求还是应答的字段是“op”，当其值为0×0001 时是请求，为0×0002 时是应答。如图1-9、1-10。 图1-9 ARP 请求 图1-10 ARP 应答 我们看看第三个帧的。第三帧“类型”显示是IP 数据报，如图1-11： 图1-11 ICMP ping 包 同样，我们先复习一下IP 包的封包格式，如图1-12： 图1-12 IP 封包格式     关于IP 封包各字段的内容及意义，这里就不再详述了，可以参见三卷本的TCP/IP， www.cnpaf.net 的“资源共享”版里有下载。     我们主要看看TTL，从图1-13 和1-14 的比较来看，图1-13 中的TTL 是128，而图1-14 中的TTL 却是64，什么原因呢？     原来图1-13 中的主机是Windows2000 ，而1-14 中的主机是Linux，看来不同操作系统的TTL 是不同的。 图1-13 Windows 主机的TTL 图1-14 Linux 主机的TTL 好了我们来看看ICMP 报文吧，先看看它的封包格式，如图1-15： 图1-15 ICMP 封包类型 关于ICMP 的“类型”和“代码”字段，这里有一个，如图1-16： 图1-16 ICMP 报文类型 ICMP 报文，我们主要对照图1-16 看抓包的情况。 图1-17 ping 请求 图1-18 ping 应答                                   二：         IP协议(RFC791)-IP包格式 IP协议是在网络层的协议.它主要完成数据包的发送作用. 下面这个表是IP4的数据包格式,IP封包格式(IPv4包首部长度为20字节) |0......4........8..............16....................................32 ------------------------------------------------------------------------- |版本4.|首部长度|服务类型(优先级|数据包总长............................| ------------------------------------------------------------------------- |标识...........................|RF|DF|MF|碎片偏移.....................| ------------------------------------------------------------------------- |生存时间TTL....|协议(TCP/UDP)..|首部较验和............................| ------------------------------------------------------------------------- |源IP地址..............................................................| ------------------------------------------------------------------------- |目的IP地址............................................................| ------------------------------------------------------------------------- |选项..................................................................| ========================================================================= |数据..................................................................| ------------------------------------------------------------------------- Version (4) Internet Header Length (4) Type of Service (8) Total Length (16)  Identification (16) Flags (3) Fragment Offset (13)  Time To Live (8) Protocol (8) Header checksum (16)  Source Address (32)  Destination Address (32)  Options (Variable) Padding (0-24)  　  Data 在上图中括号之内的数字就是各部件的长度(bit)如果您够细心就会计算得出每一列的总长度都是32bit。下面我们分别对各部件名称解释一下 Version 版本(VER)。表示的是IP规格版本目前的IP规格多为版本4(version 4)所以这里的数值通常为 0x4 (注意封包使用的数字通常都是十六进位的)。 Internet Header Length（值5，表示包头长度为5行，即5个32位，5行=5*32bit=20*8bit=20byte=0x14byte）标头长度(IHL)。从IP封包规格中看到前面6行为header，如果Options和Padding没有的话，也就只有5行，所以这里长度为“5”。我们知道每行有32bit也就是4byte，那麽5行就是20byte了，20这个数值换成16进制就成了0x14，所以当封包标头长度为最短的时候这里数值最终会被换算为0x14。 让我们看看我们撷取的ICMP封包其中属於IP部份的开头 在这里我们看到的数值是“45”前面的“4”就是版本号数而後面的“5”则是标头长度。 Type of Service 服务类型(TOS)。这里指的是IP封包在传送过程中要求的服务类型其中一共由8个bit组成其中每个bit的组合分别代表不同的意思 000..... Routine 设定IP顺序预设为0否则数值越高越优先 ...0.... Delay 延迟要求0是正常值1为低要求 ....0... Throughput 通讯量要求0为正常值1为高要求 .....0.. Reliability 可靠性要求0为正常值1为高要求 ......00 Not Used 未使用 在下例中我们可以看到TOS的值为0也就是全部设置为正常值 Total Length 封包总长(TL)。通常以byte做单位来表示该封包的总长度此数值包括标头和数据的总和。从上图我们看到的十六进位数值是“003C”换成十进位就是“60”了。 Identification 识别码(ID)。每一个IP封包都有一个16bit的唯一识别码。我们从OSI的网路层级知识里面知道当程序产生的数据要通过网络传送时都会被拆散成封包形式发送，当封包要进行重组的时候这个ID就是依据了。从上图我们可以看到此封包的ID为40973 (将 a00d 换成十进制就知道了)。 Flag 标记(FL)。这是当封包在传输过程中进行最佳组合时使用的3个bit的识别记号。请参考下表 000. Reserved Fragment 当此值为0的时候表示目前未被使用。 .0.. Don't Fragment 当此值为0的时候表示封包可以被分割，如果为1则不能被分割。 ..0. More Fragment 当上一个值为0时：此值为0就示该封包是最後一个封包，如果为1则表示其後还有被分割的封包。 在下例中我们看到这个封包的标记为“0”也就是目前并未使用。 Fragment Offset 分割定位(FO)。当封包被切开之後由於网路情况或其它因素影响其抵达顺序并不会和当初切割顺序一至的。所以当封包进行切割的时候会为各片段做好定位所以在重组的时候就能够依号入座了。 因为我们刚才撷取到的封包并没有被切割所以暂时找不到例子参考在上例中我们看到的FO为“0”。 Time To Live 延续时间(TTL)。这个TTL我们在许多网路设定上都会碰到当一个物件被赋予TTL值(以秒为单位)之後就会进行计时如果物件在到达TTL值的时候还没被处理的话就会被遗弃。 不过并不是所有的 TTL 都以时间为单位例如 ICMP 协定的 TTL则以封包路由过程中的跳站数目(Hop Count)做单位。TTL 值每经过一个跳站(或被一个 router 处理)之後就会被减低一个数值 。这样当封包在传递过程中由於某些原因而未能抵达目的地的时候就可以避免其一直充斥在网路上面。 上图中我们看到的数值可不是 20 哦因为这是个十六进位数字要换成十进位才知道 TTL 原来是 32 个跳站。 Protocol 协定(PROT)。这里指的是该封包所使用的网路协定类型例如ICMPDNS等。要注意的是这里使用的协定是网路层的协定这和上层的程式协定(如FTPPOP等)是不同的。您可以从Linux的/etc/protocol这个档案中找到这些协定和其代号此档案也存放於NT的/winnt/system32/drivers/etc目录里面。其内容如下  ------------------------------------------------------ ip      0       IP              # internet protocol, pseudo protocol number icmp    1       ICMP            # internet control message protocol igmp    2       IGMP            # Internet Group Management ggp     3       GGP             # gateway-gateway protocol ipencap 4       IP-ENCAP        # IP encapsulated in IP (officially ``IP'') st      5       ST              # ST datagram mode tcp     6       TCP             # transmission control protocol egp     8       EGP             # exterior gateway protocol pup     12      PUP             # PARC universal packet protocol udp     17      UDP             # user datagram protocol hmp     20      HMP             # host monitoring protocol xns-idp 22      XNS-IDP         # Xerox NS IDP rdp     27      RDP             # "reliable datagram" protocol iso-tp4 29      ISO-TP4         # ISO Transport Protocol class 4 xtp     36      XTP             # Xpress Tranfer Protocol ddp     37      DDP             # Datagram Delivery Protocol idpr-cmtp       39      IDPR-CMTP       # IDPR Control Message Transport rspf    73      RSPF            #Radio Shortest Path First. vmtp    81      VMTP            # Versatile Message Transport ospf    89      OSPFIGP         # Open Shortest Path First IGP ipip    94      IPIP            # Yet Another IP encapsulation encap   98      ENCAP           # Yet Another IP encapsulation ------------------------------------------------------ 在我们这个例子中可以看得出PROT的号码为“01”对照/etc/protocol档案我们可以知道这是一个ICMP协定。Header Checksum标头检验值(HC)。这个数值主要用来检错用的用以确保封包被正确无误的接收到。当封包开始进行传送後接收端主机会利用这个检验值会来检验馀下的封包如果一切看来无误就会发出确认信息表示接收正常。 上图中我们看到的封包之HC为“9049”。 Source IP Address 来源地址(SA)。相信这个不用多解释了就是发送端的IP地址是也。 我们将“c0.a8.00.0f”换成十进位就可以得出“192.168.0.15”这个地址了。 Destination IP Address 目的地址(DA)。也就是接收端的IP地址啦。 看看你能不能将“a8.5f.01.54”换成“168.95.1.84”  Options & Padding 这两个选项甚少使用只有某些特殊的封包需要特定的控制才会利用到。这里也不作细表啦。 下面我们看一看IP的结构定义 struct ip { #if __BYTE_ORDER == __LITTLE_ENDIAN unsigned int ip_hl:4; /* header length */ unsigned int ip_v:4; /* version */ #endif #if __BYTE_ORDER == __BIG_ENDIAN unsigned int ip_v:4; /* version */ unsigned int ip_hl:4; /* header length */ #endif u_int8_t ip_tos; /* type of service */ u_short ip_len; /* total length */ u_short ip_id; /* identification */ u_short ip_off; /* fragment offset field */ #define IP_RF 0x8000 /* Reserved Fragment flag */ #define IP_DF 0x4000 /* Don't Fragment flag即第二位为1(不可分包) */ #define IP_MF 0x2000 /* More Fragments flag即二三位为00(可分包,此为最后一个包)或01(还有后继包) */ #define IP_OFFMASK 0x1fff /* mask for fragmenting bits */ u_int8_t ip_ttl; /* time to live */ u_int8_t ip_p; /* protocol */ u_short ip_sum; /* checksum */ struct in_addr ip_src, ip_dst; /* source and dest address */ }; ip_v IP协议的版本号,这里是4,现在IPV6已经出来了 ip_hl IP包首部长度,这个值以4字节为单位.IP协议首部的固定长度为20个字节,如果IP包没有选项,那么这个值为5. ip_tos服务类型,说明提供的优先权. ip_len说明IP数据的长度.以字节为单位. ip_id标识这个IP数据包. ip_off碎片偏移,这和上面ID一起用来重组碎片的. ip_ttl生存时间.没经过一个路由的时候减一,直到为0时被抛弃. ip_p协议,表示创建这个IP数据包的高层协议.如TCP,UDP协议. ip_sum首部校验和,提供对首部数据的校验. ip_src,ip_dst发送者和接收者的IP地址 关于IP协议的详细情况,请参考 RFC791                                              三 ：TCP协议-TCP包格式 TCP协议也是建立在IP协议之上的,不过TCP协议是可靠的.按照顺序发送的.TCP的数据结构比前面的结构都要复杂. 行 0.......4.......8..10...........16..............24..............32 　------------------------------------------------------------------ １|.........源端口.src-port.......|.........目的端口.dst-port.....| 　------------------------------------------------------------------ ２|............................序列号.seq.........................| 　------------------------------------------------------------------ ３|............................确认号.ack_seq.....................| 　------------------------------------------------------------------ 　|........|..........|U|A|P|R|S|F|...............................| ４|首部长度|.保留(6)..|R|C|S|S|Y|I|.......窗口.window.............| 　|..doff..|..........|G|K|H|T|N|N|...............................| 　------------------------------------------------------------------ ５|........校验和.check...........|........紧急指针.urg_ptr.......| 　------------------------------------------------------------------ 　|.......................选项....................|....填充字节...| 　------------------------------------------------------------------ 每行32位=4字节。 Source Port (16) | Destination Port (16) Sequence Number (32) Acknowledgment Number (32) Data Offset(4) | Reserved (6)|UGR|ACK|PSH|RST|SYN|FIN|Window(16) Checksum (16) | Urgent Pointer (16) Options (0 or more 32 bit words + padding) DATA TCP各字段的含义 TCP各字段的含义 Source Port & Destination Port 如果我们将IP比喻成地址那麽Port可以说是门口了试想一下一座大楼有前门後门侧门送货的门出货的门倒垃圾的门扔死尸的门等等乱七八糟的门...... 那麽一个IP地址也有着好多个各种功能的port而每一个port都被不同的服务倾听着就好比看门人一样。下面是一些常用port和其对应的服务有兴趣的朋友可以在Linux的/etc/services这个档案找到它们 ftp-data 20/tcp ftp 21/tcp telnet 23/tcp smtp 25/tcp mail www 80/tcp http # WorldWideWeb HTTP www 80/udp # HyperText Transfer Protocol pop-3 110/tcp # POP version 3 pop-3 110/udp 其实port号码可以随您喜欢任意指定给哪些服务使用但为了避免“找错门口”的情形出现(除非您故意想躲起来)人们将一些比较常用的服务(Well known services)的port号码固定下来了。但是在TCP资料传送过程中可能同时要处理一个以上的封包程式也会建立多个port来避免突。在两台主机进行资料传送的时候来源地的port和目的地的port都必须让TCP知道才行。 Sequence Number 发送序号。当资料要从一台主机传送去另一台主机的时候发送端会为封包建立起一个初始号码然後按照所传送的位元组数依次的递增上去那麽下一个封包的序号就会使用递增之後的值来作为它的序号了。这样接收端就可以根据序号来检测资料是否接收完整了。 Acknowledgement Number 回应序号。当接收端接收到TCP封包之後通过检验确认之後然後会依照发送序号产生一个回应序号发出一个回应封包给发送端这样接收端就知道刚才的封包已经被成功接收到了。 可是如果由於网路状况或其它原因当封包的TTL值达到期限时接收端还没接收到回应序号就会重发该个被以为丢失了的封包。但如果刚好重发封包之後才接收到回应呢这时候接收端就会根据序号来判断该封包是否被重发送如果是的话很简单将之丢弃不做任何处理就是了。 Data Offset 这是用来记录标头固定长度用的，和IP封包的IHL差不多。如果options没设定的话，其长度就是20byte，用十六进位表示就是 0x14了。 Reserved 这是保留区间暂时还没被使用。 Contral Flag 控制标记。一共有六个它们分别是： Urgent data 如果URG为1，表示这是一个携有紧急资料的封包。 Acknowledgment field significant 如果ACK为1，表示此封包属于一个要回应的封包。一般都会为1。 Push function 如果PSH为1，此封包所携带的数据会直接上传给上层应用程序而无需经过TCP处理。如果RST为1，要求重传。表示要求重新设定封包再重新传递。 Synchronize sequence number 如果SYN为1，表示要求双方进行同步沟通。 No more data for sender (Finish) 如果FIN为1，表示传送结束，然後双方发出结束回应进而正式终止一个TCP传送过程。 Window 我们都知道MS Windows是什么东西，但这里的Window却非操作系统的“视窗”哦，这里一般称为“滑动视窗(Sliding Window)”。为什么我们需要使用视窗呢？ 正如您刚才看到的TCP封包会通过SQN和ACK序号来确保传送的正确性，但如果每一个封包都要等上一个封包的回应才被发送出去的话实在是太慢和难以接受的。这样我们可以利用Sliding Window在传送两端划分出一个范围，规定出可以一次性发送的最大封包数目。 当TCP传送建立起来之後两端都会将window的设定值还原到初始值比方说每次传送3个封包。然后发送端就一次发送三个封包出去，然后视窗则会往後移动三个封包填补发送出去之封包的空缺。如果接收端够顺利也能一次处理接收下来的三个封包的话，就会告诉发送端的window值为3，但如果接收端太忙或是其它因素影响暂时只能处理两个封包，那么在视窗里面就剩下一个封包，然后就会告诉发送端window值为2。这个时候发送端就只送出两个封包而视窗就会往後移动两个封包填补发送出去的空缺。您明白为什麽这个视窗会“滑动”了吧。其实，Window值是以字节数计算的。 Chechsum 当资料要传送出去的时候发送端会计算好封包资料大小然後得出这个检验值封包一起发送当接收端收到封包之後会再对资料大小进行计算看看是否和检验值一致如果结果不相称则被视为残缺封包会要求对方重发该个封包。 Urgent Pointer 还记得刚才讲到Control Flag的时候我们提到一个URG的标记吗如果URG被设定为一的时候这里就会指示出紧急资料所在位置。不过这种情形非常少见例如当资料流量超出频宽的时候系统要求网路主机暂缓发送资料所有主机收到这样的信息都需要优先处理。 这个选项也比较少用。当那些需要使用同步动作的程式如Telnet要处理好终端的交互模式就会使用到option来指定资料封包的大小因为telnet使用的资料封包都很少但又需要即时回应。 Option的长度为0,或32bit的整倍数,如果不足则填充到满。 下面我们撷取一个TCP封包看看您能从其中解读出什麽意思 UDP还是TCP 在TCP/IP的网路IP封包会透过ICMP协定来检测对方的存在而确保最大可能性的正确传送。不过在传送层里面除了TCP这个协定之外我们还使用另一个传输协定就是UDP (User Datagram Protocol)他和TCP最大的分别是不侦测对方的存在就直接将资料送给对方而假设对方会自行接收。 这样对那些需要大楼资料存取而又不要求可靠传输的程式如声音传递可以省却双方的沟通和确认时间从而提高资料传输量。使用UDP的程式协定例如有DNSSNMPNFSBOOTP等等。 协定 优点 缺点 TCP 传送稳定资料传送成功率高。 速度比较慢。 UDP 传输量大迅速。 不稳定容易遗失资料。 TCP的结构在中定义为:. struct tcphdr { u_int16_t source; u_int16_t dest; u_int32_t seq; u_int32_t ack_seq; #if __BYTE_ORDER == __LITTLE_ENDIAN u_int16_t res1:4; u_int16_t doff:4; u_int16_t fin:1; u_int16_t syn:1; u_int16_t rst:1; u_int16_t psh:1; u_int16_t ack:1; u_int16_t urg:1; u_int16_t res2:2; #elif __BYTE_ORDER == __BIG_ENDIAN u_int16_t doff:4; u_int16_t res1:4; u_int16_t res2:2; u_int16_t urg:1; u_int16_t ack:1; u_int16_t psh:1; u_int16_t rst:1; u_int16_t syn:1; u_int16_t fin:1; #endif u_int16_t window; u_int16_t check; u_int16_t urg_prt; }; source发送TCP数据的源端口 dest接受TCP数据的目的端口 seq标识该TCP所包含的数据字节的开始序列号，正常情况下，每次的seq为上次的seq加上上次发送的数据字节数（数据字节数=IP包总长-IP头长-TCP头长）。 ack_seq确认序列号,表示接受方下一次接受的数据序列号。以最后接收的seq+接收的数据字节数。doff数据首部长度.和IP协议一样,以4字节为单位.一般的时候为5 urg如果设置紧急数据指针,则该位为1 ack如果确认号正确,那么为1 psh如果设置为1,那么接收方收到数据后,立即交给上一层程序 rst为1的时候,表示请求重新连接 syn为1的时候,表示请求建立连接 fin为1的时候,表示亲戚关闭连接 window窗口,告诉接收者可以接收的大小（字节数） check对TCP数据进行较核 urg_ptr如果urg=1,那么指出紧急数据对于历史数据开始的序列号的偏移值 关于TCP协议的详细情况,请查看 RFC793 7.6 TCP连接的建立 TCP协议是一种可靠的连接,为了保证连接的可靠性,TCP的连接要分为几个步骤.我们把这个连接过程称为"三次握手". 下面我们从一个实例来分析建立连接的过程. 第一步客户机向服务器发送一个TCP数据包,表示请求建立连接. 为此,客户端将数据包的SYN位设置为1,并且设置序列号seq=1000(我们假设为1000). 第二步服务器收到了数据包,并从SYN位为1知道这是一个建立请求的连接.于是服务器也向客户端发送一个TCP数据包.因为是响应客户机的请求,于是服务器设置ACK为1,ack_seq=1001(对方的序列号1000+1)同时设置自己的序列号.seq=2000(我们假设为2000). 第三步客户机收到了服务器的TCP,并从ACK为1和ack_seq=1001知道是从服务器来的确认信息.于是客户机也向服务器发送确认信息.客户机设置ACK=1,和ack_seq=2001(对方的序列号2000+1),seq=1001,发送给服务器.至此客户端完成连接. 最后一步服务器受到确认信息,也完成连接. 通过上面几个步骤,一个TCP连接就建立了.当然在建立过程中可能出现错误,不过TCP协议可以保证自己去处理错误的. 说一说其中的一种错误. 听说过DOS吗?(可不是操作系统啊).今年春节的时候,美国的五大网站一起受到攻击.攻击者用的就是DOS(拒绝式服务)方式.概括的说一下原理. 客户机先进行第一个步骤.服务器收到后,进行第二个步骤.按照正常的TCP连接,客户机应该进行第三个步骤. 不过攻击者实际上并不进行第三个步骤.因为客户端在进行第一个步骤的时候,修改了自己的IP地址,就是说将一个实际上不存在的IP填充在自己IP数据包的发送者的IP一栏.这样因为服务器发的IP地址没有人接收,所以服务端会收不到第三个步骤的确认信号,这样服务务端会在那边一直等待,直到超时. 这样当有大量的客户发出请求后,服务端会有大量等待,直到所有的资源被用光,而不能再接收客户机的请求. 这样当正常的用户向服务器发出请求时,由于没有了资源而不能成功.于是就出现了春节时所出现的情况.                                                                                                          四： UDP协议-UDP包格式   UDP协议是建立在IP协议基础之上的,用在传输层的协议.UDP和IP协议一样是不可靠的数据报服务.UDP的头格式为: 0...............16...............32 ------------------------------------- |UDP源端口.......|UDP目的端口......| ------------------------------------- |UDP数据报长度...|UDP数据报校验....| ------------------------------------- UDP结构在中的定义为: struct udphdr { u_int16_t source; u_int16_t dest; u_int16_t len; u_int16_t check; }; 关于UDP协议的详细情况,请参考 RFC768                                                                                                             五：  ICMP协议-ICMP包格式   ICMP是消息控制协议,也处于网络层.在网络上传递IP数据包时,如果发生了错误,那么就会用ICMP协议来报告错误. ICMP包的结构如下: 0.......8........16..............32 ------------------------------------ |类型....|代码....|校验和..........| ------------------------------------ |数据.............|数据............| ------------------------------------ ICMP在中的定义是 struct icmphdr { u_int8_t type; /* message type */ u_int8_t code; /* type sub-code */ u_int16_t checksum; union { struct { u_int16_t id; u_int16_t sequence; } echo; /* echo datagram */ u_int32_t gateway; /* gateway address */ struct { u_int16_t __unused; u_int16_t mtu; } frag; /* path mtu discovery */ } un; }; 关于ICMP 的“类型”和“代码”字段，这里有一个表，如图1-16： 关于ICMP协议的详细情况可以查看 RFC792                         六：     EAP,EAPOL协议-数据包格式   http://rfc.net/rfc2284.html Packet Format   Exactly one PPP EAP packet is encapsulated in the Information field   of a PPP Data Link Layer frame where the protocol field indicates   type hex C227 (PPP EAP).  A summary of the EAP packet format is shown   below.  The fields are transmitted from left to right.    0                   1                   2                   3    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |     Code      |  Identifier   |            Length             |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |    Data ...   +-+-+-+-+   Code      The Code field is one octet and identifies the type of EAP packet.      EAP Codes are assigned as follows:         1       Request         2       Response         3       Success         4       Failure   Identifier          The Identifier field is one octet and aids in matching          responses with requests.   Length          The Length field is two octets and indicates the length of the          EAP packet including the Code, Identifier, Length and Data          fields.  Octets outside the range of the Length field should          be treated as Data Link Layer padding and should be ignored on          reception.   Data          The Data field is zero or more octets.  The format of the Data          field is determined by the Code field. 2.2.1.  Request and Response A summary of the Request and Response packet format is shown below.   The fields are transmitted from left to right.    0                   1                   2                   3    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |     Code      |  Identifier   |            Length             |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |     Type      |  Type-Data ...   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-   Code      1 for Request;      2 for Response.   Identifier      The Identifier field is one octet.  The Identifier field MUST be      the same if a Request packet is retransmitted due to a timeout      while waiting for a Response.  Any new (non-retransmission)      Requests MUST modify the Identifier field.  If a peer recieves a      duplicate Request for which it has already sent a Response, it      MUST resend it's Response.  If a peer receives a duplicate Request      before it has sent a Response to the initial Request (i.e. it's      waiting for user input), it MUST silently discard the duplicate      Request.   Length      The Length field is two octets and indicates the length of the EAP      packet including the Code, Identifier, Length, Type, and Type-Data      fields.  Octets outside the range of the Length field should be      treated as Data Link Layer padding and should be ignored on      reception.   Type      The Type field is one octet.  This field indicates the Type of      Request or Response.  Only one Type MUST be specified per EAP      Request or Response.  Normally, the Type field of the Response      will be the same as the Type of the Request.  However, there is      also a Nak Response Type for indicating that a Request type is      unacceptable to the peer.  When sending a Nak in response to a      Request, the peer MAY indicate an alternative desired      authentication Type which it supports. An initial specification of      Types follows in a later section of this document.   Type-Data      The Type-Data field varies with the Type of Request and the      associated Response. 2.2.2.  Success and Failure A summary of the Success and Failure packet format is shown below.   The fields are transmitted from left to right.    0                   1                   2                   3    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+