Toad的博客

在讲ARP攻击之前，要先对国产的“科来网络分析系统”提出赞扬！很不错的国产软件，严重支持！当Toad正在为大量的实例而苦恼时，豁然发现网络分析论坛(CSNA)有大量的实例！这些实例都是遇到网络故障的朋友Sniffer的内容。这种实例最大的优点，就是千变万化！很多故障Toad短时内也无法得出答案，这才有意思，老是讲些皮毛和概念没意思，SE一搜，一大堆！以后，Toad会逐渐从CSNA随机选取实例来做讲解！分析的工具有两个：

1、科来网络分析系统

2、Sniffer Pro 4.75

废话不多说了，开始这一讲的正题！什么是ARP攻击，这个问题大家去问SE吧，网上这种文章多如牛毛（哈哈，抱歉，文章取了这么一个题目）！ARP攻击原理，待，我们以后分析完ARP协议后，自然知晓！这里，我们要做到如何判断一个网络中，是否发生了ARP攻击。要做到这一点，只需要Sniffer一下就很直观了，一般情况下，一个网段内，ARP包是非常少的，为什么少呢？如果一个正常的网段内实时的ARP包都很多，那么MAC缓冲池设计就失去意义了！网关上有MAC缓冲池，主机上也有MAC缓冲池。一台主机进入网络，一般情况下只产生两个ARP包：

1）、第一个ARP请求包用于查询同网段内是否有跟自己IP相同的主机

2）、第二个ARP请求用于获得网关的MAC，网关返回一个ARP回应，正是网关的这个ARP回应，促使主机在自己的MAC缓冲池中建立了一条“网关IP——网关MAC”的记录。

经过以上两步后，主机短时内是不会再产生ARP请求的，除非有其他进程促使ARP请求包的生成，或者网关MAC变化，网络不通等等！正是因为MAC缓冲池机制，导致了ARP攻击的可能！通过上面的叙述，我们很容易发现ARP协议的一个重大弊端——那就是ARP协议无验证机制！人人都可以改写其他主机MAC缓冲池中的“IP—–MAC”记录。只要会网络编程，做到这一点很简单！今天就到这里了。。。。下一讲继续！

文章来源于>>TCP/IP协议分析博客                     转载请注明：Toad的博客

IP是TCP/IP协议族中最为核心的协议。所有的TCP、UDP、ICMP及IGMP数据都以IP数据包格式传输。许多刚开始接触TCP/IP的人对IP提供不可靠、无连接的数据报传送服务感到很奇怪，特别是那些具有X.25或SNA背景知识的人。

不可靠（unreliable）的意思是它不能保证IP数据报能成功地到达目的地。IP仅提供最好的传输服务。如果发生某种错误时，如某个路由器暂时用完了缓冲区，IP有一个简单的错误处理算法：丢弃该数据报，然后发送ICMP消息报给信源端。任何要求的可靠性必须由上层来提供（如TCP，应用层的进程）。

无连接（connectionless，请参考Toad写的UDP协议与TCP协议的区别章节中的解释）这个术语的意思是IP并不维护任何关于后续数据报的状态信息。每个数据报的处理是相互独立的。这也说明，IP数据包可以不按发送顺序接收。如果一信源向相同的信宿发送两个连续的数据报（先是A，然后是B），每个数据报都是独立地进行路由选择，可能选择不同的路线，因此B可能在A到达之前先到达。

网络层的讲解阶段，我们将简要介绍IP首部中的各个字段，讨论IP路由选择和子网的有关内容。还要介绍两个有用的命令：ifconfig和netstat。关于IP首部中一些字段的细节，将留在以后使用这些字段的时候再进行讨论。RFC 791[Postel1981a]是IP的正式规范文件。

文章来源于>>TCP/IP协议分析博客              转载请注明：Toad的博客

如果线路速率是9600b/s，而一个字节有8bit，加上一个起始比特和一个停止比特，那么线路的速率就是960B/s（字节/秒）。以这个速率传输一个1024字节的分组需要1066ms。如果用SLIP链接运行一个交互式应用程序，同时还运行另一个应用程序如FTP发送或接收1024字节的数据，那么一般来说就必须等待一半的时间（533ms）才能把交互式应用程序的分组数据发送出去。

假定交互分组数据可以在其他“大块”分组数据发送之前被发送出去。大多数的SLIP实现确实提供这类服务排队方法，把交互数据放在大块的数据前面。交互通信一般有Telnet、Rlogin以及FTP的控制部分（用户的命令，而不是数据）。这种服务排队方法是不完善的。它不能影响已经进入下游（如串行驱动程序）队列的非交互数据。同时，新型的调制解调器具有很大的缓冲区，因此非交互数据可能已经进入该缓冲区了。

对于交互应用来说，等待533ms是不能接受的。关于人的有关研究表明，交互响应时间超过100～200ms就被认为是不好的[Jacobson1990a]。这是发送一份交互报文出去后，直到接收到响应信息（通常是出现一个回显字符）为止的往返时间。

把SLIP的MTU缩短到256就意味着链路传输一帧最长需要266ms，它的一半是133ms（这是一般需要等待的时间）。这样情况会好一些，但仍然不完美。我们选择它的原因（与64或128相比）是因为大块数据提供良好的线路利用率（如大文件传输）。假设CSLIP的报文首部是5个字节，数据帧总长为261个字节，256个字节的数据使线路的利用率为98.1%，帧头占了1.9%，这样的利用率是很不错的。如果把MTU降到256以下，那么将降低传输大块数据的最大吞吐量。

在上一讲的MTU值中，点对点链路的MTU是296个字节。假设数据为256字节，TCP和IP首部占40个字节。由于MTU是IP向链路层查询的结果，因此该值必须包括通常的TCP和IP首部。这样就会导致IP如何进行分片的决策。IP对于CSLIP的压缩情况一无所知。我们对平均等待时间的计算（传输最大数据帧所需时间的一半）只适用于SLIP链路（或PPP链路）在交互通信和大块数据传输这两种情况下。当只有交互通信时，如果线路速率是9600b/s，那么任何方向上的1字节数据（假设有5个字节的压缩帧头）往返一次都大约需要12.5ms。它比前面提到的100~200ms要小得多。需要注意的是，由于帧头从40个字节压缩到5个字节，使得1字节数据往返时间从85ms减到12.5ms。

不幸的是，当使用新型的纠错和压缩调制解调器时，这样的计算就更难了。这些调制解调器所采用的压缩方法使得在线路上传输的字节数大大减少，但纠错机制又会增加传输的时间。不过，这些计算是我们进行合理决策的入口点。

文章来源于>>TCP/IP协议分析博客   转载请注明：Toad的博客

当在同一个网络上的两台主机互相进行通信时，该网络的MTU是非常重要的。但是如果两台主机之间的通信要通过多个网络，那么每个网络的链路层就可能有不同的MTU。重要的不是两台主机所在网络的MTU的值，重要的是两台通信主机路径中的最小MTU。它被称作路径MTU。

两台主机之间的路径MTU不一定是个常数。它取决于当时所选择的路由。而选路不一定是对称的（从A到B的路由可能与从B到A的路由不同），因此路径MTU在两个方向上不一定是一致的。

RFC1191[MogulandDeering1990]描述了路径MTU的发现机制，即在任何时候确定路径MTU的方法。我们在介绍了ICMP和IP分片方法以后再来看它是如何操作的。以后，我们将看到ICMP的不可到达错误就采用这种发现方法。还会看到，traceroute程序也是用这个方法来确定到达目的节点的路径MTU。同时还将讲解当软件支持路径MTU的发现方法时，UDP和TCP是如何进行操作的。

文章来源于>>TCP/IP协议分析博客   转载请注明：Toad的博客

以太网和802.3对数据帧的长度都有一个限制，其最大值分别是1500和1492字节。链路层的这个特性称作MTU，最大传输单元。不同类型的网络大多数都有一个上限。如果IP层有一个数据报要传，而且数据的长度比链路层的MTU还大，那么IP层就需要进行分片（fragmentation），把数据报分成若干片，这样每一片都小于MTU。我们将在以后讨论IP分片的过程。下图列出了一些典型的MTU值：

它们摘自RFC1191[MogulandDeering1990]。点到点的链路层（如SLIP和PPP）的MTU并非指的是网络媒体的物理特性。相反，它是一个逻辑限制，目的是为交互使用提供足够快的响应时间。在以后的文章中，我们将看到这个限制值是如何计算出来的。

文章来源于>>TCP/IP协议分析博客        转载请注明：Toad的博客

上一讲，我们提到了“信道复用技术”！知道了这一点，我们就很容易明白“物理信道”上的“虚拟信道”概念了！不同的信道复用技术，使用不同的复用技术，目的就是创建“虚拟信道”。

一个TCP协议连接其实就是在物理线路上创建的一条“虚拟信道”。这条“虚拟信道”建立后，在TCP协议发出FIN包之前（两个终端都会向对方发送一个FIN包），是不会释放的。正因为这一点，TCP协议被称为面向连接的协议！

UDP协议，一样会在物理线路上创建一条“虚拟信道”，否则UDP协议无法传输数据！但是，当UDP协议传完数据后，这条“虚拟信道”就被立即注销了！因此，称UDP是不面向连接的协议！

大家要知道，一种物理线路，单位时间内，能够创建的“虚拟信道”是有限的！从这个问题，大家应该明白了TCP协议和UDP协议为什么会共存了吧，然而，这只是其中一个原因而已！

那为什么又说TCP协议可靠，UDP协议不可靠呢？以上说的是一个原因，还有一个原因是：使用TCP协议传输数据，当数据从A端传到B端后，B端会发送一个确认包（ACK包）给A端，告知A端数据我已收到！UDP协议就没有这种确认机制！这一点，我们在做TCP协议首部分析时，会详加解释！

QQ普通会员就是使用的UDP协议进行传输数据！既然UDP协议自身没有确认机制，这个工作可以交给应用层的进程来完成（QQ）！大家使用QQ的时候，感觉出错的几率还是非常小吧！当然，把这个确认工作完全交给QQ自身来做，就直接导致了，QQ软件体积增大！

有些应用，对数据传输可靠性要求非常高，例如大家浏览网页，通过网页注册帐号、转帐等服务，这是不容许出错的，使用TCP协议能把出错的可能性降到最低（当然，网络自身很糟糕，TCP协议也没办法）。但是，提供这种可靠服务，会加大网络带宽的开销，因为“虚拟信道”是持续存在的，同时网络中还会出现大量的ACK和FIN包！

因此，鱼和熊掌不可兼得，需，根据实际情况选择传输协议！UDP协议与TCP协议的区别在为涉及首部分析是，就是这些内容了！

文章来源于>>TCP/IP协议分析博客 转载请注明：Toad的博客

网上很多文章都说TCP协议可靠，UDP协议不可靠！为什么前者可靠，后者不可靠呢？既然UDP协议不可靠，为什么还要使用它呢？所谓的TCP协议是面向连接的协议，面向连接是什么呢？这篇文章，我们就是要弄懂以上问题！

TCP和UDP都是传输层的协议！从编程的角度看，就是两个模块（模块就是代码的集合，一系列代码的组合提供相应的功能！模块化最终目的就是：分工协作！模块化好处：便于扩展开发以及维护！）。

先说TCP协议：

这个协议，是面向的连接！面向连接这个概念，我们要从物理层看起。大家都知道，因为“信道复用技术”的迅猛发展，才促使了计算机网络的发展！如果没有“信道复用技术”，那么单条线路上（这里的线路指物理传输介质，例如：双绞线、光纤、电话线）单位时间内只能供一台计算机使用！还是举例说明：就拿你自己的计算机来说，你跟同学“小明”聊天的时候，就不能跟另外一位同学“小强”聊天，如果你想同时跟两位同学聊天，那么你就得装两条线路！那么同时与第三位、第四位同学。。。第N位同学聊天的时候，你需要装几根线路？全世界人民聊天的时候，又需要装几根线路？

“信道复用技术”实现了，在同一条线路上，单位时间内可供X台计算机同时通信！Toad知道以下几种复用技术：

1、频分复用
       2、 时分复用
       3、波分复用
       4、码分复用
       5、空分复用
       6、统计复用
       7、极化波复用

关于“信道复用技术”更深层次的问题，需要你自己去研究！Toad在这方面的知识很薄弱。

文章来源于>>TCP/IP协议分析博客         转载请注明：Toad的博客

MSL          MaximumSegmentLifetime，报文段最大生存时间
MSS          MaximumSegmentSize，报文段最大长度
MTU          MaximumTransmissionUnit，最大传输单元
NCSA         NationalCenterforSupercomputingApplications，国家超级计算中心(美国)
NFS          NetworkFileSystem，网络文件系统
NNRP         NetworkNewsReadingProtocol，网络新闻读取协议
NNTP         NetworkNewsTransferProtocol，网络新闻传送协议
NOAO         NationalOpticalAstronomyObservation，国家光学天文观测(美国)
NOP          NoOperation，无操作
OSF          OpenSoftwareFoundation，开放软件基金
OSI          OpenSystemsInterconnection，开放系统互连
PAWS         ProtectionAgainstWrappedSequencenumber，防止序号重叠
PCB          ProtocolControlBlock，协议控制快
POSIX        PortableOperationSystemInterface，可移植操作系统接口
PPP          Point-to-PointProtocol，点对点协议
PSH          TCP首部中的急迫(PuSH)标志
RDP          ReliableDatagramProtocol，可靠数据报
RFC          RequestForComment，是Internet的文档，意思是“请提意见”。
RPC          RemoteProcedureCall，远程过程调用
RST          TCP首部中的重建(ReSeT)标志
RTO          RetransmissionTimeOut，重传超时
RTT          Round-TripTime，往返时间
SLIP         SerialLineInternetProtocol，串行线路因特网协议
SMTP         SimpleMailTransferProtocol，简单邮件传送协议
SPT          ServerProcessingTime，服务器处理时间
SVR4         SystemVRelease4，系统V版本4
SYN          TCP首部中的序号同步(SYNchronoussequencenumber)标志
TAO          TCPAcceleratedOpen，TCP加速打开
TCP          TransmissionControlProtocol，传输控制协议
TTL          Time-To-Live，寿命，或生存时间
Telnet       远程登录协议
UDP          UserDatagramProtocol，用户数据报协议
URG          TCP首部中的紧急(URGent)指针
URI          UniversalResourceIdentifier，通用资源标识符
URL          UniformResourceLocator，统一资源定位符
URN          UniformResourceName，统一资源名字
VMTP         VersatileMessageTransactionProtocol，通用报文事务协议
WAN          WideAreaNetwork，广域网
WWW          WorldWideWeb，万维网

文章来源于>>网络协议分析博客     转载请注明：Toad的博客

ACK                                   TCP首部中的确认(ACKnowledgment)标志
ANSI                                 AmericanNationalStandardsInstitute，美国国家标准协会
API                                   ApplicationProgrammingInterface，应用编程接口
ARP                                  AddressResolutionProtocol，地址解析协议
ARPANET                    AdvancedResearchProjectsAgencyNETwork，远景研究规划局(美国国防部)网
ASCII                              AmericanStandardCodeforInformationInterchange，美国信息交换标准代码
BPF                                   BSDPacketFilter，BSD分组过滤程序
BSD                                   BerkeleySoftwareDistribution，伯克利软件发布
CC                                      ConnectionCount，连接计数
CERT                                ComputerEmergencyResponseTeam，计算机应急响应工作队
CR                                      CarriageReturn，回车
DF                                      TCP首部中的不分段(Don’tFragment)标志
DNS                                   DomainNameSystem，域名系统
EOL                                    EndofOptionList，选项表结束
FAQ                                   FrequentlyAskedQuestion，经常提出的问题
FIN                                    TCP首部中的终止(FINish)标志
FTP                                     FileTransferProtocol，文件传送协议
GIF                                     GraphicsInterchangeFormat，图形交换格式
HTML                                HyperTextMarkupLanguage，超文本置标语言
HTTP                                 HyperTextTransferProtocol，超文本传送协议
ICMP                                  InternetControlMessageProtocol，因特网控制报文协议
IEEE                                InstituteofElectricalandElectronicsEngineers，电气和电子工程师学会(美国)
INN                                    InterNetNews，因特网新闻
INND                                  InterNetNewsDaemon，因特网新闻守护程序
IP                                          InternetProtocol，网际协议
IPC                                        InterProcessCommunication，进程间通信
IRTP                                     InternetReliableTransactionProtocol，因特网可靠事务协议
ISN                                       InitialSequenceNumber，初始序号
ISO                                        InternationalOrganizationforStandardization，国际标准化组织
ISS                                         InitialSendSequencenumber，初始发送序号
LAN                                     LocalAreaNetwork，局域网
LF                                         LineFeed，换行
MIME                                 MultipurposeInternetMailExtensions，通用因特网邮件扩充

文章来源于>>TCP/IP协议分析博客           转载请注明：Toad的博客

协议概述

PPPoE有两个截然不同的阶段，即发现阶段（Discovery stage）及PPP会话阶段（PPP Session stage）。当一个主机希望初始化一个PPPoE会话，它必须首先执行发现阶段去标识对方的以太MAC地址并且建立一个PPPoE会话标识符（SESSION_ID）。当PPP定义了一个端对端关系时，发现阶段也同时建立了一个客户端-服务器关系。在发现过程中，一个主机（客户端）发现了一个访问集中器（服务器）。基于这个网络拓扑，该主机可能有不止一个可以通信的访问集中器。发现阶段允许该主机发现所有的访问集中器，然后选择使用其中一个。当发现阶段成功结束时，该主机与被选择的访问集中器都拥有将用于建立它们之间在以太网上的点对点连接的信息。

发现阶段将保持无状态，直到PPP会话被建立起来。一当PPP会话被建立起来，主机和访问集中器必须为PPP虚拟接口分配资源。

因为文档中有协议首部的ASCII图，复制粘贴上来，图形会错位！大家还是下载看吧！近期Toad会写一份PPPoE的Sniffer分析报告！

点击下载：[PDF]RFC 2516 中文版