TCP/IP协议栈与数据报封装 (802.3 Ethernet 以太网 802.11 WLAN 无线网 )

http://blog.csdn.net/jnu_simba/article/details/8957242

一、ISO/OSI参考模型

OSI（open system interconnection）开放系统互联模型是由ISO（International Organization for Standardization）

国际标准化组织定义的网络分层模型，共七层，如下图。

物理层(Physical Layer)：物理层定义了所有电子及物理设备的规范，为上层的传输提供了一个物理介质，本层中数据传输的单位为比特（bit）。

属于本层定义的规范有EIA/TIA RS-232、EIA/TIA RS-449、V.35、RJ-45等，实际使用中的设备如网卡等属于本层。

数据链路层（Data Link Layer）：对物理层收到的比特流进行数据成帧。提供可靠的数据传输服务，实现无差错数据传输。

在数据链路层中数据的单位为帧（frame）。属于本层定义的规范有SDLC、HDLC、PPP、STP、帧中继等，实际使用中的设备如switch交换机属于本层。

网络层（Network Layer）：网络层负责将各个子网之间的数据进行路由选择，分组与重组。本层中数据传输的单位为数据包（packet）

（This packet can be either an IP datagram or a fragment of an IP datagram）。

属于本层定义的规范有IP、IPX、RIP、OSPF、ICMP、IGMP等。实际使用中的设备如路由器属于本层。 

注：可能大家经常被数据包还是数据报的名词混淆，下面给出较准确的定义：

an IP datagram is the unit of end-to-end transmission at the IP layer (before fragmentation and after reassembly),

and a packet is the unit of data passed between the IP layer and the link layer.

A packet can be a complete IP datagram or a fragment of an IP datagram.

an IP datagram = packet + packet + packet + ... + packet

传输层（Transport Layer）：提供可靠的数据传输服务，它检测路由器丢弃的包，然后产生一个重传请求，

能够将乱序收到的数据包重新排序。在传输层数据的传输单位是段（segment）。

会话层（Session Layer）：管理主机之间会话过程，包括会话建立、终止和会话过程中的管理。

表示层（Presentation Layer）：表示层对网络传输的数据进行变换，使得多个主机之间传送的信息能够互相理解，

包括数据的压缩、加密、格式转换等。

应用层（Application Layer）：应用层与应用程序界面沟通，以达至展示给用户的目的。

在此常见的协定有: HTTP，HTTPS，FTP，TELNET，SSH，SMTP，POP3等 

二、TCP/IP协议四层模型

TCP/IP网络协议栈分为应用层（Application）、传输层（Transport）、网络层（Network）和链路层（Link）四层。

如下图所示，如果没有特别说明，一般引用的图都出自《TCP/IP详解》。

 

两台计算机通过TCP/IP协议通讯的过程如下所示：

 

传输层及其以下的机制由内核提供，应用层由用户进程提供，应用程序对通讯数据的含义进行解释，

而传输层及其以下处理通讯的细节，将数据从一台计算机通过一定的路径发送到另一台计算机。

应用层数据通过协议栈发到网络上时，每层协议都要加上一个数据首部（header），称为封装（Encapsulation），如下图所示：

 

不同的协议层对数据包有不同的称谓，在传输层叫做段（segment），在网络层叫做数据包（packet），在链路层叫做帧（frame）。

数据封装成帧后发到传输介质上，到达目的主机后每层协议再剥掉相应的首部，最后将应用层数据交给应用程序处理。

上图对应两台计算机在同一网段中的情况，如果两台计算机在不同的网段中，

那么数据从一台计算机到另一台计算机传输过程中要经过一个或多个路由器，如下图所示：

其实在链路层之下还有物理层，指的是电信号的传递方式，比如现在以太网通用的网线（双绞线）、

早期以太网采用的的同轴电缆（现在主要用于有线电视）、光纤等都属于物理层的概念。

物理层的能力决定了最大传输速率、传输距离、抗干扰性等。

集线器（Hub）是工作在物理层的网络设备，用于双绞线的连接和信号中继（将已衰减的信号再次放大使之传得更远）。

 

链路层有以太网、令牌环网等标准，链路层负责网卡设备的驱动、帧同步（就是说从网线上检测到什么信号算作新帧的开始）、

冲突检测（如果检测到冲突就自动重发）、数据差错校验等工作。交换机是工作在链路层的网络设备，

可以在不同的链路层网络之间转发数据帧（比如十兆以太网和百兆以太网之间、以太网和令牌环网之间），

由于不同链路层的帧格式不同，交换机要将进来的数据包拆掉链路层首部重新封装之后再转发。

网络层的IP协议是构成Internet的基础。负责点到点（point-to-point）的传输（这里的“点”指主机或路由器）

Internet上的主机通过IP地址来标识，Internet上有大量路由器负责根据IP地址选择合适的路径转发数据包，

数据包从Internet上的源主机到目的主机往往要经过十多个路由器。

路由器是工作在第三层的网络设备，同时兼有交换机的功能，可以在不同的链路层接口之间转发数据包，

因此路由器需要将进来的数据包拆掉网络层和链路层两层首部并重新封装。

IP协议不保证传输的可靠性，数据包在传输过程中可能丢失，可靠性可以在上层协议或应用程序中提供支持。 

网络层负责点到点（point-to-point）的传输（这里的“点”指主机或路由器），而传输层负责端到端（end-to-end）的传输（这里的“端”指源主机和目的主机）。

 

传输层可选择TCP或UDP协议。负责端到端（end-to-end）的传输（这里的“端”指源主机和目的主机）。

TCP是一种面向连接的、可靠的协议，有点像打电话，双方拿起电话互通身份之后就建立了连接，然后说话就行了，

这边说的话那边保证听得到，并且是按说话的顺序听到的，说完话挂机断开连接。

也就是说TCP传输的双方需要首先建立连接，之后由TCP协议保证数据收发的可靠性，丢失的数据包自动重发，

上层应用程序收到的总是可靠的数据流，通讯之后关闭连接。

UDP协议不面向连接，也不保证可靠性，有点像寄信，写好信放到邮筒里，既不能保证信件在邮递过程中不会丢失，

也不能保证信件是按顺序寄到目的地的。使用UDP协议的应用程序需要自己完成丢包重发、消息排序等工作。 

目的主机收到数据包后，如何经过各层协议栈最后到达应用程序呢？整个过程如下图所示：

 

 

以太网驱动程序首先根据以太网首部中的“上层协议”字段确定该数据帧的有效载荷（payload，指除去协议首部之外实际传输的数据）是

IP、ARP还是RARP协议的数据报，然后交给相应的协议处理。

假如是IP数据报，IP协议再根据IP首部中的“上层协议”字段确定该数据报的有效载荷是

TCP、UDP、ICMP还是IGMP，然后交给相应的协议处理。

假如是TCP段或UDP段，TCP或UDP协议再根据TCP首部或UDP首部的“端口号”字段

确定应该将应用层数据交给哪个用户进程。

IP地址是标识网络中不同主机的地址，而端口号就是同一台主机上标识不同进程的地址，

IP地址和端口号合起来标识网络中唯一的进程。

注意，虽然IP、ARP和RARP数据报都需要以太网驱动程序来封装成帧，但是从功能上划分，

ARP和RARP属于链路层，IP属于网络层。

虽然ICMP、IGMP、TCP、UDP的数据都需要IP协议来封装成数据报，

但是从功能上划分，ICMP、IGMP与IP同属于网络层，TCP和UDP属于传输层。

 

IP协议--IP数据报格式

http://yin123.blog.51cto.com/882581/461436

 

IP协议特点

IP协议位于网络层，是因特网的核心协议，除了ARP和RARP报文外，几乎所有的数据都要经过IP协议进行发送。

由于IP协议在网络层中具有重要地位，人们又将TCP/IP协议的网络层称为IP层。

IP协议是不可靠的无连接数据报协议，提高尽力而为的传输服务，具有一下特点：

① 是点对点协议，虽然IP数据报携带源IP和目的IP地址，但进行数据传输时的对等实体一定相邻设备（同一网络中）的对等实体。

② IP协议不保证传输的可靠性，不对数据进行差错校验和跟踪，可靠性有IP的上层TCP协议加以保证。

③ IP协议提供无连接数据报服务，各个数据报独立传输，可能沿着不同路径到达目的地，也可能不按序到达目的地。

正因为IP协议采用尽力传输的思想，所以IP协议的效率非常高，实现也简单。

IP层向下要面对各种不同的物理网络，向上却提供一个同一的数据传输服务。

通过IP数据报实现了物理数据帧的同一，IP层达到了向上屏蔽底层差异的目的。

IP数据报

IP协议所处理的数据单元称为IP数据报。其格式如下：

IP数据报由首部和数据两部分组成，首部又分为定长部分和变长部分。

版本(VER)：4位，表示数据报的IP协议版本，

当前的IP协议版本号为4，即IPv4;

下一代网络协议IPv6，版本号为6.

首部长度（HLEN）:4位，表示以字长（4字节）为单位的数据报首部长度。

服务类型（SERVICE TYPE）: 8位，规定本数据报的处理方式。

前三位是优先级，0-7，0表示最低，7最高（最重要），但目前的IPv4没有使用优先级。

后4位是TOS，表示本数据报在传输过程中所希望得到的服务，

D--最小延迟（minimize delay）；T--最大吞吐率（maximize throughout）；

R--最高可靠性（maximize reliability）；C--最低成本（minimize cost）。

 

值得注意的有2点：

①服务类型代表用户的希望，并不具有强制性，目前许多设备TCP/IP中不支持服务类型特性。

②在D、T、R、C这4个参数中只能设置其中一个。

 

数据报总长度： 在IP数据报封装到以太网帧中进行传输时很有用.

标识（IDENTIFICATION）：16位每个IP数据报都有一个本地唯一的标识符，它由信源机赋予IP数据报。每次自动加1.

标志（FLAGS）：3位，表示该IP数据报是否允许分片以及是否最后一片。

片偏移（FRAGMENTATION OFFSET）：表示本片数据在他所属原始数据报数据区的偏移量。

生存时间（time to live,TTL）: 8位，

协议（PROTOCOL）：8位，指明被IP数据报封装的协议:

ICMP=1,IGMP=2,TCP=6,EGP=8,UDP=17,OSPF=89.

 

首部校验和（HEADER CHECKSUM）：16位，保证首部数据完整性。

源IP地址（SOURCE ADDRESS）：32位（IPv4中），发送方源地址。

目的地址（DESTINATION ADDRESS）: 32位（IPv4中），最总接收方IP地址。

IP选项（IP OPTIONS）：变长字段，传输数据报时的附加功能。

http://blog.pfan.cn/xman/44383.html

版本字段长度为4，用来表明建立数据报的IP版本，

目前的IP版本是IPv4,IPv6正在发展中。IPv4的字段为0100 。

首部长度（报头长度）指的是首部占32 bit字的数目，包括任何选项。

由于它是一个4比特字段，因此首部最长为60个字节。

15x32/8=60字节.

IP首部始终是32 bit的整数倍.IP数据报报头的最小长度为20个字（不含填充字段和IP选项字段的IP报头是最常见的IP报头，为20个字节）

服务类型TOS（Type Of Service）总长度字段是指整个I P数据报的长度，以字节为单位.由于该字段长16比特，

所以I P数据报最长可达6 5 5 3 5字节(64KB).总长度字段是I P首部中必要的内容。数据长度＝总长－报头长度。

标识符长16比特。标志位长度为3比特，用于分段控制：

第0位为预留位，第1位表示可否分段。当该位的值为0时，表示数据报不可分段，值为1时，表示数据报可被分段。

第2位为段是否结束位，当该位的值为0时，表示该段是原数据报的最后一段，值为1时，表示后面不有更多的分段。

当网络设备要发送的数据报长度比所在网络的最大传输单元（MTU，Max Transfer United）大，

并且标志位的第1位设置为不能分段（0）时，网络设备会向发送方返回一个因特网控制消息协议ICMP错误消息，

并丢弃该数据报。除了最后一个分段外，其余分段的第2位均设置为1。 

段偏移13比特长度，用于指定分段在原始数据报中的位置,以8个字节为单位.

生存时间TTL长度为8比特，用于指定数据报允许保留在网络上的时间。

协议字段长度为8比特，用于指定数据报数据区中携带的消息是由哪种高级协议建立的。

ICMP为1,TCP为6，UDP为17。 协议号分配RFC790.

报头校验和16比特，仅用于IP报头校验和。

源IP地址及目的IP地址。

选项，填充字段用于确保将选项字段填充为最少32个比特位，以保证IP报头以32位结束。

分段：分段是将一个大的IP数据报分解成几个较小的数据报段的过程。

当IP模块需要通过一个具有较小MTU的网络传送较大的数据包时，就必须将其分段。

//定义ip报头数据结构

typedef struct _iphdr

{

    byte ver_len;  //版本4位,头长度4位,报头长度以32位为一个单位

    byte type;   //类型8位

    byte length[2];  //总长度,16位,指出报文的以字节为单位的总长度

    //报文长度不能超过65536个字节，否则认为报文遭到破坏

    byte id[2];   //报文标示,用于多于一个报文16位

    byte flag_offset[2];//标志,3位 数据块偏移13位

    byte time;   //生存时间,8位

    byte protocol;  //协议,8位

    byte crc_val[2]; //头校验和，16位

    byte src_addr[4]; //源地址,32位

    byte tar_addr[4]; //目标地址,32位

    byte options[4]; //选项和填充,32位

}IP_HEADER;

 

TCP报文格式

传输控制协议（TCP）向上与用户应用程序进程接口，向下与网络层协议IP接口。

用户应用程序采用首先调用TCP（或UDP），然后将应用程序数据递交给TCP这一方式，

在IP网络上传送数据。TCP将这些数据打包分段并调用IP模块向目的主机传送每个数据段。

接收方的TCP将段中的数据放入接收缓冲器，然后将段重装为应用程序数据，

再将这些数据发送到目的的应用程序进程。尽管TCP和UDP都使用相同的网络层（IP），

TCP却向应用层提供与UDP完全不同的服务。TCP提供一种面向连接的、可靠的字节流服务。

源端口号（16位），标识主机上发起传送的应用程序；

目的端口（16位）标识主机上传送要到达的应用程序。

源端和目的端的端口号，用于寻找发端和收端应用进程。

这两个值加上I P首部中的源端I P地址和目的端I P地址唯一确定一个T C P连接。

一个I P地址和一个端口号有时也称为一个插口（socket），

插口对（socket pair）(包含客户I P地址、客户端口号、服务器 I P地址和服务器端口号的四元组 )

可唯一确定互联网络中每个T C P连接的双方。

IP+TCP端口唯一确定一个TCP连接。

TCP协议通过使用"端口"来标识源端和目标端的应用进程。

端口号可以使用0到65535之间的任何数字。

在收到服务请求时，操作系统动态地为客户端的应用程序分配端口号。

在服务器端，每种服务在"众所周知的端口"（Well-Know Port）为用户提供服务。

顺序号字段：占32比特。用来标识从TCP源端向TCP目标端发送的数据字节流，它表示在这个报文段中的第一个数据字节。

确认号字段：占32比特。只有ACK标志为1时，确认号字段才有效。它包含目标端所期望收到源端的下一个数据字节。

头部长度字段：占4比特。给出头部占32比特的数目。没有任何选项字段的TCP头部长度为20字节；最多可以有60字节的TCP头部。

预留：由跟在数据偏移字段后的6位构成，预留位通常为0.

标志位字段（U、A、P、R、S、F）：占6比特。各比特的含义如下：
　　 URG：紧急指针（urgent pointer）有效。
　　 ACK：确认序号有效。
　　 PSH：接收方应该尽快将这个报文段交给应用层。
　　 RST：重建连接。
　　 SYN：发起一个连接。
　　 FIN：释放一个连接。

窗口大小字段：占16比特。此字段用来进行流量控制。单位为字节数，这个值是本机期望一次接收的字节数。
TCP校验和字段：占16比特。对整个TCP报文段，即TCP头部和TCP数据进行校验和计算，并由目标端进行验证。
紧急指针字段：占16比特。它是一个偏移量，和序号字段中的值相加表示紧急数据最后一个字节的序号。
选项字段：占32比特。可能包括"窗口扩大因子"、"时间戳"等选项。

数据： TCP 报文段中的数据部分是可选的。在一个连接建立和一个连接终止时，双方交换的报文段仅有 TCP 首部。

如果一方没有数据要发送，也使用没有任何数据的首部来确认收到的数据。

在处理超时的许多情况中，也会发送不带任何数据的报文段。

 

//定义TCP报头
typedef struct _tcphdr
{
 byte source_port[2]; //发送端端口号,16位
 byte dest_port[2];  //接收端端口号,16位
 byte sequence_no[4]; //32位，标示消息端的数据位于全体数据块的某一字节的数字
 byte ack_no[4];   //32位，确认号,标示接收端对于发送端接收到数据块数值
 byte offset_reser_con[2];//数据偏移4位，预留6位，控制位6为
 byte window[2];   //窗口16位
 byte checksum[2];  //校验码,16位
 byte urgen_pointer[2]; //16位，紧急数据指针
 byte options[3];  //选祥和填充,32位
}TCP_HEADER;

 

 

UDP协议及包格式

http://yin123.blog.51cto.com/882581/461450

 

1.无连接，不可靠；
2.出错（通过校验和检查）就丢掉此包，丢失不重传，只是给个警告；
3.包的格式，有源端口和目的端口，校验和等；
4.端口号，根据应用层服务的不同，可以是默认的端口，也可以自己设定。

UDP是一种无连接的、不可靠的传输层协议；
在完成进程到进程的通信中提供了有限的差错检验功能；
设计比较简单的UDP协议的目的是希望以最小的开销来达到网络环境中的进程通信目的；
进程发送的报文较短，同时对报文的可靠性要求不高，那么可以使用UDP协议。

 

源端口号和目的端口号如上和TCP的相同。

UDP长度：UDP报文的字节长度（包括首部和数据）。

UDP校验和: 检验UDP首部和数据部分的正确性。

http://www.cw.njupt.edu.cn/shenjl/frame/wlkj/ch8/chapter83.htm

用户数据报UDP有两个字段：数据字段和首部字段。首部字段有8个字节，由4个字段组成，每个字段都是两个字节。

在计算检验和时，临时把“伪首部”和UDP用户数据报连接在一起。伪首部仅仅是为了计算检验和。

 

UDP用户数据报的首部中长度字段定义了数据报的总长度，即首部加数据部分。

UDP用户数据报的首部中检验和用来检验整个用户数据报（首部加数据部分）出现的差错。计算伪首部可以增加可靠性。

( 4 + 4 + 1 + 1 + 2 ) + (2 + 2 + 2 + 2 ）= 20 

伪首部的作用是用于检验UDP数据报已经到达正确的目的地，即正确的主机和协议端口。

尽管IP数据报首部已经包含了必要的校验和，但是，它并不能保证检验出所有的首部错误，

因此，为了确保数据传输的正确性，在UDP的报文验证时，通过增加伪首部信息校验，

再次对IP数据报中的源IP地址、目的IP地址、协议类型和数据长度等信息进行校验。

需要注意的是，伪首部的内容在报文的传输中是不需要传送的，

即报文中并不安排专门的位置存放伪首部内容，只是在发送报文时计算校验和，

以及接收报文时验证校验和时，需要将伪首部定义的内容纳入校验和计算和验证的范畴

伪首部包含IP首部一些字段。其目的是让UDP两次检查数据是否已经正确到达目的地，只是单纯为了做校验用的。

还有一个概念十分重要，那就是16位UDP总长度，请注意该长度不是报文的总长度，

而只是UDP（包括UDP头和数据部分）的总长度

 

互联网通讯协议知识讲座

http://www.itokit.com/2012/0830/74714.html

最底下的一层叫做"实体层"（Physical Layer），最上面的一层叫做"应用层"（Application Layer），

中间的三层（自下而上）分别是"链接层"（Link Layer）、"网络层"（Network Layer）和"传输层"（Transport Layer）。

越下面的层，越靠近硬件；越上面的层，越靠近用户。

层与协议

每一层都是为了完成一种功能。为了实现这些功能，就需要大家都遵守共同的规则。

大家都遵守的规则，就叫做"协议"（protocol）。

互联网的每一层，都定义了很多协议。这些协议的总称，就叫做"互联网协议"（Internet Protocol Suite）。

它们是互联网的核心，下面介绍每一层的功能，主要就是介绍每一层的主要协议。

实体层

 

它就是把电脑连接起来的物理手段。它主要规定了网络的一些电气特性，作用是负责传送0和1的电信号。

以太网协议

早期的时候，每家公司都有自己的电信号分组方式。逐渐地，一种叫做"以太网"（Ethernet）的协议，占据了主导地位。

以太网规定，一组电信号构成一个数据包，叫做"帧"（Frame）。每一帧分成两个部分：标头（Head）和数据（Data）

标头"包含数据包的一些说明项，比如发送者、接受者、数据类型等等；"数据"则是数据包的具体内容。

"标头"的长度，固定为18字节。"数据"的长度，最短为46字节，最长为1500字节。

因此，整个"帧"最短为64字节，最长为1518字节。如果数据很长，就必须分割成多个帧进行发送。

网卡的地址，就是数据包的发送地址和接收地址，这叫做MAC地址。

每块网卡出厂的时候，都有一个全世界独一无二的MAC地址，长度是48个二进制位，通常用12个十六进制数表示。

前6个十六进制数是厂商编号，后6个是该厂商的网卡流水号。有了MAC地址，就可以定位网卡和数据包的路径了。

网络层的由来

以太网协议，依靠MAC地址发送数据。理论上，单单依靠MAC地址，上海的网卡就可以找到洛杉矶的网卡了，技术上是可以实现的。

但是，这样做有一个重大的缺点。以太网采用广播方式发送数据包，所有成员人手一"包"，不仅效率低，而且局限在发送者所在的子网络。

也就是说，如果两台计算机不在同一个子网络，广播是传不过去的。

这种设计是合理的，否则互联网上每一台计算机都会收到所有包，那会引起灾难。

互联网是无数子网络共同组成的一个巨型网络，很像想象上海和洛杉矶的电脑会在同一个子网络，这几乎是不可能的。

因此，必须找到一种方法，能够区分哪些MAC地址属于同一个子网络，哪些不是。

如果是同一个子网络，就采用广播方式发送，否则就采用"路由"方式发送。

（"路由"的意思，就是指如何向不同的子网络分发数据包，这是一个很大的主题，本文不涉及。）

遗憾的是，MAC地址本身无法做到这一点。它只与厂商有关，与所处网络无关。

这就导致了"网络层"的诞生。它的作用是引进一套新的地址，使得我们能够区分不同的计算机是否属于同一个子网络。

这套地址就叫做"网络地址"，简称"网址"。

于是，"网络层"出现以后，每台计算机有了两种地址，一种是MAC地址，另一种是网络地址。

两种地址之间没有任何联系，MAC地址是绑定在网卡上的，网络地址则是管理员分配的，它们只是随机组合在一起。

网络地址帮助我们确定计算机所在的子网络，MAC地址则将数据包送到该子网络中的目标网卡。

因此，从逻辑上可以推断，必定是先处理网络地址，然后再处理MAC地址。

协议

规定网络地址的协议，叫做IP协议。它所定义的地址，就被称为IP地址。

目前，广泛采用的是IP协议第四版，简称IPv4。这个版本规定，网络地址由32个二进制位组成。

习惯上，我们用分成四段的十进制数表示IP地址，从0.0.0.0一直到255.255.255.255。

互联网上的每一台计算机，都会分配到一个IP地址。

这个地址分成两个部分，前一部分代表网络，后一部分代表主机。

比如，IP地址172.16.254.1，这是一个32位的地址，

假定它的网络部分是前24位（172.16.254），那么主机部分就是后8位（最后的那个1）。

处于同一个子网络的电脑，它们IP地址的网络部分必定是相同的，

也就是说172.16.254.2应该与172.16.254.1处在同一个子网络。

但是，问题在于单单从IP地址，我们无法判断网络部分。

还是以172.16.254.1为例，它的网络部分，到底是前24位，还是前16位，甚至前28位，从IP地址上是看不出来的。

那么，怎样才能从IP地址，判断两台计算机是否属于同一个子网络呢？这就要用到另一个参数"子网掩码"（subnet mask）。

所谓"子网掩码"，就是表示子网络特征的一个参数。

它在形式上等同于IP地址，也是一个32位二进制数字，它的网络部分全部为1，主机部分全部为0。

比如，IP地址172.16.254.1，如果已知网络部分是前24位，主机部分是后8位，

那么子网络掩码就是11111111.11111111.11111111.00000000，写成十进制就是255.255.255.0。

知道"子网掩码"，我们就能判断，任意两个IP地址是否处在同一个子网络。

方法是将两个IP地址与子网掩码分别进行AND运算（两个数位都为1，运算结果为1，否则为0），然后比较结果是否相同，

如果是的话，就表明它们在同一个子网络中，否则就不是。

比如，已知IP地址172.16.254.1和172.16.254.233的子网掩码都是255.255.255.0，请问它们是否在同一个子网络？

两者与子网掩码分别进行AND运算，结果都是172.16.254.0，因此它们在同一个子网络。

总结一下，IP协议的作用主要有两个，一个是为每一台计算机分配IP地址，另一个是确定哪些地址在同一个子网络。

IP数据包

根据IP协议发送的数据，就叫做IP数据包。不难想象，其中必定包括IP地址信息。

但是前面说过，以太网数据包只包含MAC地址，并没有IP地址的栏位。那么是否需要修改数据定义，再添加一个栏位呢？

回答是不需要，我们可以把IP数据包直接放进以太网数据包的"数据"部分，因此完全不用修改以太网的规格。

这就是互联网分层结构的好处：上层的变动完全不涉及下层的结构。

具体来说，IP数据包也分为"标头"和"数据"两个部分。

"标头"部分主要包括版本、长度、IP地址等信息，"数据"部分则是IP数据包的具体内容。

它放进以太网数据包后，以太网数据包就变成了下面这样。

 

 

P数据包的"标头"部分的长度为20到60字节，整个数据包的总长度最大为65,535字节。

因此，理论上，一个IP数据包的"数据"部分，最长为65,515字节。

前面说过，以太网数据包的"数据"部分，最长只有1500字节。

因此，如果IP数据包超过了1500字节，它就需要分割成几个以太网数据包，分开发送了。

ARP协议

关于"网络层"，还有最后一点需要说明。

因为IP数据包是放在以太网数据包里发送的，所以我们必须同时知道两个地址，

一个是对方的MAC地址，另一个是对方的IP地址。

通常情况下，对方的IP地址是已知的（后文会解释），但是我们不知道它的MAC地址。

所以，我们需要一种机制，能够从IP地址得到MAC地址。

这里又可以分成两种情况。

第一种情况，如果两台主机不在同一个子网络，那么事实上没有办法得到对方的MAC地址，

只能把数据包传送到两个子网络连接处的"网关"（gateway），让网关去处理。

第二种情况，如果两台主机在同一个子网络，那么我们可以用ARP协议，得到对方的MAC地址。

ARP协议也是发出一个数据包（包含在以太网数据包中），其中包含它所要查询主机的IP地址，

在对方的MAC地址这一栏，填的是FF:FF:FF:FF:FF:FF，表示这是一个"广播"地址。

它所在子网络的每一台主机，都会收到这个数据包，从中取出IP地址，与自身的IP地址进行比较。

如果两者相同，都做出回复，向对方报告自己的MAC地址，否则就丢弃这个包。

总之，有了ARP协议之后，我们就可以得到同一个子网络内的主机MAC地址，

可以把数据包发送到任意一台主机之上了。

传输层的由来

有了MAC地址和IP地址，我们已经可以在互联网上任意两台主机上建立通信。

接下来的问题是，同一台主机上有许多程序都需要用到网络，比如，你一边浏览网页，一边与朋友在线聊天。

当一个数据包从互联网上发来的时候，你怎么知道，它是表示网页的内容，还是表示在线聊天的内容？

也就是说，我们还需要一个参数，表示这个数据包到底供哪个程序（进程）使用。

这个参数就叫做"端口"（port），它其实是每一个使用网卡的程序的编号。

每个数据包都发到主机的特定端口，所以不同的程序就能取到自己所需要的数据。

"端口"是0到65535之间的一个整数，正好16个二进制位。

0到1023的端口被系统占用，用户只能选用大于1023的端口。

不管是浏览网页还是在线聊天，应用程序会随机选用一个端口，然后与服务器的相应端口联系。

"传输层"的功能，就是建立"端口到端口"的通信。

相比之下，"网络层"的功能是建立"主机到主机"的通信。

只要确定主机和端口，我们就能实现程序之间的交流。

因此，Unix系统就把主机+端口，叫做"套接字"（socket）。有了它，就可以进行网络应用程序开发了。

 

UDP协议

现在，我们必须在数据包中加入端口信息，这就需要新的协议。

最简单的实现叫做UDP协议，它的格式几乎就是在数据前面，加上端口号。

UDP数据包，也是由"标头"和"数据"两部分组成。

"标头"部分主要定义了发出端口和接收端口，"数据"部分就是具体的内容。

然后，把整个UDP数据包放入IP数据包的"数据"部分，而前面说过，

IP数据包又是放在以太网数据包之中的，所以整个以太网数据包现在变成了下面这样：

UDP数据包非常简单，"标头"部分一共只有8个字节，总长度不超过65,535字节，正好放进一个IP数据包。

TCP协议

UDP协议的优点是比较简单，容易实现，但是缺点是可靠性较差，一旦数据包发出，无法知道对方是否收到。

为了解决这个问题，提高网络可靠性，TCP协议就诞生了。这个协议非常复杂，但可以近似认为，

它就是有确认机制的UDP协议，每发出一个数据包都要求确认。

如果有一个数据包遗失，就收不到确认，发出方就知道有必要重发这个数据包了。

因此，TCP协议能够确保数据不会遗失。它的缺点是过程复杂、实现困难、消耗较多的资源。

TCP数据包和UDP数据包一样，都是内嵌在IP数据包的"数据"部分。

TCP数据包没有长度限制，理论上可以无限长，但是为了保证网络的效率，

通常TCP数据包的长度不会超过IP数据包的长度，以确保单个TCP数据包不必再分割。

 

应用层

应用程序收到"传输层"的数据，接下来就要进行解读。

由于互联网是开放架构，数据来源五花八门，必须事先规定好格式，否则根本无法解读。

"应用层"的作用，就是规定应用程序的数据格式。

举例来说，TCP协议可以为各种各样的程序传递数据，比如Email、WWW、FTP等等。

那么，必须有不同协议规定电子邮件、网页、FTP数据的格式，这些应用程序协议就构成了"应用层"。

这是最高的一层，直接面对用户。它的数据就放在TCP数据包的"数据"部分。

因此，现在的以太网的数据包就变成下面这样。

至此，整个互联网的五层结构，自下而上全部讲完了。这是从系统的角度，解释互联网是如何构成的。

下一篇，我反过来，从用户的角度，自上而下看看这个结构是如何发挥作用，完成一次网络数据交换的。

DHCP协议

首先，它是一种应用层协议，建立在UDP协议之上，所以整个数据包是这样的：

1）最前面的"以太网标头"，设置发出方（本机）的MAC地址和接收方（DHCP服务器）的MAC地址。

前者就是本机网卡的MAC地址，后者这时不知道，就填入一个广播地址：FF-FF-FF-FF-FF-FF。

2）后面的"IP标头"，设置发出方的IP地址和接收方的IP地址。这时，对于这两者，本机都不知道。

于是，发出方的IP地址就设为0.0.0.0，接收方的IP地址设为255.255.255.255。

3）最后的"UDP标头"，设置发出方的端口和接收方的端口。

这一部分是DHCP协议规定好的，发出方是68端口，接收方是67端口。

这个数据包构造完成后，就可以发出了。以太网是广播发送，同一个子网络的每台计算机都收到了这个包。

因为接收方的MAC地址是FF-FF-FF-FF-FF-FF，看不出是发给谁的，所以每台收到这个包的计算机，

还必须分析这个包的IP地址，才能确定是不是发给自己的。

当看到发出方IP地址是0.0.0.0，接收方是255.255.255.255，

于是DHCP服务器知道"这个包是发给我的"，而其他计算机就可以丢弃这个包。

接下来，DHCP服务器读出这个包的数据内容，分配好IP地址，发送回去一个"DHCP响应"数据包。

这个响应包的结构也是类似的，以太网标头的MAC地址是双方的网卡地址，

IP标头的IP地址是DHCP服务器的IP地址（发出方）和255.255.255.255（接收方），

UDP标头的端口是67（发出方）和68（接收方），分配给请求端的IP地址和本网络的具体参数则包含在Data部分。

新加入的计算机收到这个响应包，于是就知道了自己的IP地址、子网掩码、网关地址、DNS服务器等等参数。

 DNS协议

我们知道，发送数据包，必须要知道对方的IP地址。

但是，现在，我们只知道网址www.google.com，不知道它的IP地址。

DNS协议可以帮助我们，将这个网址转换成IP地址。

已知DNS服务器为8.8.8.8，于是我们向这个地址发送一个DNS数据包（53端口）。

然后，DNS服务器做出响应，告诉我们Google的IP地址是172.194.72.105。于是，我们知道了对方的IP地址。

子网掩码

接下来，我们要判断，这个IP地址是不是在同一个子网络，这就要用到子网掩码。

已知子网掩码是255.255.255.0，本机用它对自己的IP地址192.168.1.100，

做一个二进制的AND运算（两个数位都为1，结果为1，否则为0），计算结果为192.168.1.0；

然后对Google的IP地址172.194.72.105也做一个AND运算，计算结果为172.194.72.0。

这两个结果不相等，所以结论是，Google与本机不在同一个子网络。

因此，我们要向Google发送数据包，必须通过网关192.168.1.1转发，

也就是说，接收方的MAC地址将是网关的MAC地址。

应用层协议

浏览网页用的是HTTP协议，它的整个数据包构造是这样的：

 

假定这个部分的长度为4960字节，它会被嵌在TCP数据包之中。

TCP协议

TCP数据包需要设置端口，接收方（Google）的HTTP端口默认是80，

发送方（本机）的端口是一个随机生成的1024-65535之间的整数，假定为51775。

TCP数据包的标头长度为20字节，加上嵌入HTTP的数据包，总长度变为4980字节。

IP协议

然后，TCP数据包再嵌入IP数据包。IP数据包需要设置双方的IP地址，这是已知的，

发送方是192.168.1.100（本机），接收方是172.194.72.105（Google）。

IP数据包的标头长度为20字节，加上嵌入的TCP数据包，总长度变为5000字节。

以太网协议

最后，IP数据包嵌入以太网数据包。

以太网数据包需要设置双方的MAC地址，发送方为本机的网卡MAC地址，接收方为网关192.168.1.1的MAC地址（通过ARP协议得到）。

以太网数据包的数据部分，最大长度为1500字节，而现在的IP数据包长度为5000字节。

因此，IP数据包必须分割成四个包。因为每个包都有自己的IP标头（20字节），

所以四个包的IP数据包的长度分别为1500、1500、1500、560。

 服务器端响应

经过多个网关的转发，Google的服务器172.194.72.105，收到了这四个以太网数据包。

根据IP标头的序号，Google将四个包拼起来，取出完整的TCP数据包，

然后读出里面的"HTTP请求"，接着做出"HTTP响应"，再用TCP协议发回来。

本机收到HTTP响应以后，就可以将网页显示出来，完成一次网络通信。 

 

802.11 WLAN Packets and Protocols

 http://www.wildpackets.com/resources/compendium/wireless_lan/wlan_packets

802.11 WLAN overview

 

This section presents a detailed overview of the 802.11 WLAN standards.

The information is presented under general functional headings.

A detailed breakdown of 802.11 WLAN packet headers and of 802.2 LLC headers is presented after the overview.

 

Development of the IEEE 802.11 WLAN standards

 

In 1997, IEEE approved 802.11, the first internationally sanctioned wireless LAN standard.

This first standard proposed any of three (mutually incompatible) implementations for the physical layer:

infrared (IR) pulse position modulation, or radio frequency (RF) signalling in the 2.4 GHz band

using either frequency hopping spread spectrum (FHSS) or direct sequence spread spectrum (DSSS).

The IR method was never commercially implemented.

The RF versions suffered from low transmission speeds (2 Mbps).

In an effort to increase throughput, IEEE established two working groups (A and B) to explore alternate implementations of 802.11.

A third group, Working Group G, was set up after these two.

 

 

Packet structure and packet types

 

 

Like the rest of the 802 family of LAN protocols, 802.11 WLAN sends all network traffic in packets.

There are three basic types:

data packets,

network management packets and

control packets.

The first section describes the basic structure of 802.11 WLAN data packets

and the information they provide for network analysis.

The second section describes the management and control packets,

their functions and the role they play in network analysis.

 

Packet structure

 

All the functionality of the protocol is reflected in the packet headers.

RF technology and station mobility impose some complex requirements on 802.11 WLAN networks.

This added complexity is reflected in the long physical layer convergence protocol (PLCP) headers

as well as the data-rich MAC header.

Because 802.11 WLANs must be able to form and re-form their membership constantly,

and because radio transmission conditions themselves can change, coordination becomes a large issue in WLANs.

Management and control packets are dedicated to these coordination functions.

In addition, the headers of ordinary data packets contain a great deal more information about network conditions and topology than,

for example, the headers of Ethernet data packets would contain.

 

WLAN frames and packet headers

 

This section describes the various layers of 802.11 WLAN packet headers and

the clues they contain to the protocols found in the network data which they frame.

The typical 802.11 packet frames the network data inside a physical layer header,

followed by a MAC layer header with a FCS trailer for error control.

All versions of 802.11 support use of the 802.2 standard for Logical Link Control or LLC.

As Figure C.12 above shows, the hardware preamble,

packet start delimiter and end delimiter bytes are not captured by OmniPeek.

The PLCP header is used by network hardware to control the transmission and

maintain the physical (in this case, radio wave) link between stations.

Higher layers in the packet, beginning with the MAC header,

are captured by OmniPeek and presented both as raw data and as decoded data.

 

PLCP

 

802.11 WLAN protocols permit negotiation of transmission rates for each session.

They also permit changes in packet fragmentation to improve overall throughput under changing conditions.

To support these functions, they use a physical layer header called the PLCP (Physical Layer Convergence Protocol),

consisting of a PLCP preamble and the PLCP header.

 

The physical layers of the 802.11a WLAN and the 802.11b WLAN are different,

and so the PLCP is distinct for each. Even so, they have important similarities.

In both standards, the PLCP header is transmitted immediately after an initial synchronization or training sequence,

and immediately before the MAC header.

In both standards, the PLCP header contains information on the rate and length of the rest of the packet.

 

Whether the packet length is expressed in bytes or as a unit of time, receiving stations can use the PLCP header to determine

how much time should be allowed for transmission of this packet.

Even if a receiver does not support the data rate requested in the packet, it knows how long to wait before the channel will again be clear.

PLCP header also contains error correction and information on the encoding scheme (related to data rate) used in the remainder of the packet.

 

The PLCP portion of the transmission is always sent at the lowest commonly supported data rate,

to insure maximum reliability and compatibility with other stations.

 

802.11 MAC header

 

The particular format of the 802.11 MAC header depends on the type of packet:

data packets, network management packets or control packets.

The description which follows (based on Figure C.13) is for an 802.11 WLAN data packet.

Management and control packets have only the first three of the four address fields.

They may also contain information in the frame body in fields of fixed or

variable length which are specific to that particular type and subtype of packet.

 

 

802.2 headers

 

Like all LAN protocols in the IEEE 802 family, 802.11 permits the use of the 802.2 protocol for Logical Link Control (LLC).

The 802.2 header, usually called the LLC, contains information about the protocol type of the packet.

These 802.2 headers are either 3 bytes or 8 bytes long.

The first section of the LLC header is 3 bytes long and contains two LSAP values and one LSAP command.

These LSAP values can either contain information about the protocol of the packet,

or they can point to the optional 5 byte SNAP section that follows.

If they point to the SNAP section of the header then the protocol is described by this 5 byte Protocol Discriminator or SNAP ID.