Toad的博客

大多数的产品都支持环回接口（Loopback Interface),以允许运行在同一台主机上的客户程序和服务器程序通过TCP/IP进行通信。A类网络号127就是为环回接口预留的。根据惯例，大多数系统把IP地址127.0.0.1分配给这个接口，并命名为localhost。一个传给环回接口的IP数据包不能在任何网络上出现。

 我们想象，一旦传输层检测到目的端地址是环回地址时，应该可以省略部分传输层和所有网络层的逻辑操作。但是大多数的产品还是照样完成传输层和网络层的所有过程，只是当IP数据报离开网络层时把它返回给自己。

      下图是环回接口处理IP数据报的简单过程。

 图中需要指出的关键点是：

 1）传给环回地址的任何数据均作为IP输入。

 2）传给广播地址或多播地址的数据报复制一份传给环回接口，然后送到以太网上。这是因为广播传送和多播传送的定义包含主机本身。

3）任何传给该主机IP地址的数据均送到环回接口。

看上去用传输层和IP层的方法来处理环回数据似乎效率不高，但它简化了设计，因为环回接口可以被看作是网络层下面的另一个链路层。网络层把一份数据报传送给环回接口，就像传给其他链路层一样，只不过环回接口把它返回到IP的输入队列中。

 在上图中，另一个隐含的意思是送给主机本身的IP地址的IP数据报一般不出现在相应的网络上。例如，在一个以太网上，分组一般不被传出去然后读回来。某些BSD以太网的设备驱动程序的注释说明，许多以太网接口卡不能读回他们自己发送出去的数据。由于一台主机必须处理发送给自己的IP数据包，因此上图所示的过程是最为简单的处理办法。

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

这样做的原因是防止它们出现在双方主机的串行接口驱动程序或调制解调器中，因为有时它们会把这些控制字符解释成特殊的含义。另一种可能是用链路控制协议来指定是否需要对这32个字符中的某一些值进行转义。默认情况下是对所有的32个字符都进行转义。

与SLIP类似，由于PPP经常用于低俗的串行链路，因此减少每一帧的字节数可以降低应用程序的交互时延。利用链路控制协议，大多数的产品通过协商可以省略标志符和地址字段，并且把协议字段由2个字节减少到1个字节。如果我们把PPP的帧格式与前面的SLIP的帧格式进行比较会发现，PPP只增加了3个额外的字节：1个字节留给协议字段，另2个给CRC字段使用。另外，使用IP网络控制协议，大多数的产品可以通过协商采用Van Jacobson报文首部压缩方法（对应于CSLIP压缩），减小IP和TCP首部长度。

总的来说，PPP比SLIP具有下面这些优点：（1）PPP支持在单根串行线路上运行多种协议，不只是IP协议；（2）每一帧都有循环冗余检验；（3）通信双方可以进行IP地址的动态协商（使用IP网络控制协议）；（4）与CSLIP类似，对TCP和IP报文首部进行压缩；（5）链路控制协议可以对多个数据链路选项进行设置。为这些优点付出的代价是在每一帧的首部增加3个字节，当建立链路时要发送几帧协商数据，以及更为复杂的实现。

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

PPP数据帧的格式看上去很像ISO的HDLC（高层数据链路控制）标准。下图就是PPP数据帧的格式

每一帧都以标志字符0×7e开始和结束。紧接着是一个地址字节，值始终是0xff，然后是一个值为0×03的控制字节。

接下来是协议字段，类似于以太网中类型字段的功能。当它的值为0×0021时，表示信息字段是一个IP数据包；值为0xc021时，表示信息字段是链路控制数据；值为0×8021时，表示信息字段是网络控制数据。

CRC字段（或FCS，帧检验序列）是一个循环冗余检验码，以检测数据帧中的错误。

由于标志字符的值是0×7e，因此当该字符出现在信息字段中时，PPP需要对它进行转义。在同步链路中，该过程是通过一种称作比特填充（bit stuffing)的硬件技术来完成的。在异步链路中，特殊字符0×7d用作转义字符。当它出现在PPP数据帧中时，那么紧接着的字符的第6个比特要取其补码。具体实现过程如下：

1）当遇到字符0×7e时，需要连续传送两个字符：0×7d和0×5e，以实现标志字符的转义。

2）当遇到转义字符0×7d时，需连续传送两个字符：0×7d和0×5d，以实现转义字符的转义。

3）默认情况下，如果字符的值小于0×20（比如，一个ASCII控制字符），一般都要进行转义。例如，遇到字符0×01时需连续传送0×7d和0×21两个字符（这时，第6个比特取补码后变为1，而前面两种情况均把它变为0）。

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

讲了这么久的基础，今天来点“猛”的！DDOS上场。。。。大家鼓掌！

先看图：

                                                                    图1 

                                                                    图2

由于安全原因，小弟把图片中的目的IP抹去了，这不影响我们要讨论的东东！

这是基于TCP三次握手类型的DDOS，建立一个TCP连接，必须经过3个步骤

1、请求端发送一个SYN包给服务端

2、服务端返回一个SYN/ACK包给请求端

3、请求端再返回一个ACK包给服务端

这样，一个TCP连接就建立了。这个过程的详细讲解，不是我们这一讲要讨论，不明白的朋友，请看以后的TCP协议分析的文章！

这里，要明白一个东东，当服务器端没有收到第三步中的ACK包时，它会干什么？服务器端的这条TCP连接所占的系统资源，将会处于一个等待的状态，等待ACK包的到来！这个等待时间有多长，不同的操作系统不一样。况且，正确建立的TCP连接，在释放后，还会处于一个2MSL（俗称：等待状态，以后详解。。。哈哈）！基于以上两点再加上巨量的SYN包，此时，大家应该能够明白，会发生什么！

我们如何判断是否遭受了DDOS？请看第一张图，sunmmary栏目中，出现大量的SYN包，无SYN/ACK包，也没有其他协议或者进程的包。SYN包的源IP无规则跳变，跨度大！

第二张图是TCP首部，我们可以看到只有SYN域被指为1，而且所有的包都是这样！这绝对是发生了DDOS！

下一讲，我们将讲述一些针对这种类型DDOS的防御措施！其实，这些防御措施都是消极的，当DDOS流量无限增大时，没有任何设备能够完全防御！目前，市面上能够发动几个G流量的DDOS个人和组织很多！通过朋友的渠道得知，各大运营商，在部署分层次的DDOS防御体系，从骨干网到终端网逐级过滤，这让我们看见了曙光！

HTTP是一个简单的协议。客户进程建立一条同服务器进程的TCP连接，然后发出请求并读取服务器进程的响应。服务器进程关闭连接表示本次相应结束。服务器进程返回的文件通常含有指向其他服务器上文件的指针（超文本链接）。用户显然可以很轻松地沿着这些链接从一个服务器到下一个服务器。

         客户进程提供简单、漂亮的图形界面。HTTP服务器进程只是简单返回客户进程所请求的文档，因此HTTP服务器软件比HTTP客户软件要小得多。例如，NCSA版本的1.3的Unix服务器由大约6500行C代码写成，而X Window环境下的Unix Mosaic2.5浏览器有约80000行C代码。

        我么可以一个简单的方法来了解许多Internet协议是怎么工作的：那就是运行一个Telnet的客户程序与相应的服务器程序通信。这种方法对HTTP协议也是可行的，这是因为客户进程发送给服务器进程的语句包含有ASCII命令（以回车和紧跟的换行符表示结束，称为CR/LF），服务器进程返回的内容也是以ASCII字符开始。HTTP协议使用的是8 bit的ISO Latin 1字符集，该字符集由ASCII字符及一些西欧语言中的字符组成。

PPP，点对点协议修改了SLIP协议中的所有权限。PPP包括以下三个部分：

1）、在串行链路上封装IP数据包的方法。PPP既支持数据为8位和无奇偶检验的异步模式，还支持面向比特的同步链接。

2）、建立，配置及检测数据链路的LCP（链路控制协议）。它还允许通信双方进行协商，以确定不同的选项。

3）、针对不同网络层协议的网络控制协议（NCP）体系。当前RFC定义的网络层有IP、OSI网络层、DECnet以及AppleTalk。例如：IP NCP允许双方商定是否对报文首部进行压缩，类似于CSLIP。

RFC 1548描述了报文封装的方法和链路控制协议。RFC 1332描述了针对IP的网络控制协议。

由于串行线路的速率通常较低，而且通信经常是交互式的，因此在SLIP线路上有许多小的TCP分组进行交换。为了传送1个字节的数据都需要20个字节的IP首部和20个字节的TCP首部，总数超过40个字节。

既然承认这些性能上的缺陷，于是人们提出一个被称作CSLIP的写协议，它在RFC 1144中被详细描述。CSLIP一般能把上面的40个字节压缩到3或5个字节。它能在CSLIP的每一端维持多达16个TCP连接，并且知道其中每个连接的首部中的某些字段一般不会发生变化。对于那些发生变化的字段，大多数只是一些小的数字和的改变。这些被压缩的首部大大地缩短了交互响应时间。

SLIP是一种简单的帧封装方法，“简单”是它的优点也是它的缺点：

1）、每一端必须知道对方的IP地址。没有办法把本端的IP地址通知给另一端。

2）、数据帧中没有类型字段。如果一条串行线路用于SLIP，那么它不能同时使用其他协议。

3）、SLIP没有任何数据帧中加上检验和。如果SLIP传输的报文被线路噪声影响而发生错误，只能通过上层协议来发现。这样，上层协议提供某种形式的CRC就显得很重要。这里，我们先提一下：IP首部和TCP首部及其数据始终都有检验和，同时，UDP首部及其数据的检验和是可选的。

串行线路IP全称是：Serial Line IP。它是一种在串行线路上对IP数据包进行封装的简单形式，在RFC 1055中有详细描述。SLIP适用于家庭中每台计算机几乎都有的RS-232串行端口。

还是先看看SLIP的封装格式：

1)、IP数据包一个称作END（0xc0)的特殊字符结束。同时，为了防止数据报到来之前的线路噪声被当成数据报内容，大多数实现在数据报的开始处也传一个END字符，这样做的目的是：如果有线路噪声，那么END字符将结束这份错误的报文。这样当前的报文得以正确的传输，而前一个错误报文交给上层后，会发现其内容毫无意义而被丢弃

2）、如果IP数据包中某个字符为END，那么就要连续传输两个字节0xdb和0xdc来取代它。0xdb这个特殊字符被称作SLIP的ESC字符，但是它的值与ASCII码的ESC字符不同。

3）、如果IP数据包中某个字符为SLIP的ESC字符，那么就要连续传输两个字节0xdb和0xdd来取代它。

RFC 893描述了另一种用于以太网的封装格式， 称作尾部封装。这是一个早期BSD系统在DEC VAX机上运行时运行时的试验格式，他通过调整IP数据报中字段的次序来提高性能。在以太网数据帧中，开始的那部分是变长的字段（IP首部和TCP首部）。把他们移到尾部（CRC之前），哈哈，前面忘了说CRC是什么东东。我们称其为：CRC检验码，一种验证数据包的机制。判断，从遥远网络传来的数据，是否是正确的（中国到美国够远了吧，还要走海底线缆）！其算法好像是：二进制反码求和（记不清了，抱歉！）。

把协议首部移到数据的尾部，这样一来，当把数据复制到内核时，就可以把数据帧中的数据部分映射到一个硬件页面，节省内存到内存的复制过程。TCP数据报的长度是512字节的整数倍，正好可以用内核中的页表来处理。两台主机通过协商使用ARP扩展协议对数据帧进行尾部封装。这些数据帧需要定义不同的以太网帧类型值。

现在，尾部封装已被废弃，我也不知道原因！