前言

2020 年 1 月 6 日，国家信息安全漏洞共享平台（CNVD）收录了由北京长亭科技有限公司发现并报送的 Apache Tomcat 文件包含漏洞。Tomcat AJP 协议由于存在实现缺陷导致相关参数可控，攻击者利用该漏洞可通过构造特定参数，读取服务器 webapp 下的任意文件。若服务器端同时存在文件上传功能，攻击者可进一步实现远程代码的执行。

Tomcat AJP 协议的这种实现缺陷，对于 SpringBoot 开发的 web 应用是否受影响了？且听笔者一一道来。

AJP 协议

根据 apache 官网 AJP 协议相关介绍：


The original document was written by Dan Milstein, danmil@shore.net on December 2000.

Overview of the protocol

The ajp13 protocol is packet-oriented. A binary format was presumably chosen over the more readable plain text for reasons of performance. The web server communicates with the servlet container over TCP connections. To cut down on the expensive process of socket creation, the web server will attempt to maintain persistent TCP connections to the servlet container, and to reuse a connection for multiple request/response cycles.

Once a connection is assigned to a particular request, it will not be used for any others until the request-handling cycle has terminated. In other words, requests are not multiplexed over connections. This makes for much simpler code at either end of the connection, although it does cause more connections to be open at once.


AJP13 协议全称为 Apache JServ Protocol version 1.3 ，最初由 Dan Milstein 于2000年12月发表，后被 Apache 软件基金会 Jakarta 项目采纳。

AJP13 是一种二进制 TCP 传输协议，通过在网络传输二进制包（packet）来完成 Tomcat 与 http 服务器的请求与响应，显然这种方式比纯文本(如 text、xml等)传输的 http 协议效率要高的多。



 

但是 AJP13 协议对浏览器支持不够好，由于其定位是 “ Tomcat 与 HTTP 服务器之间通信的协议”，这或许是 http 协议比较盛行的原因吧。

说完了 Tomcat AJP13 协议的来龙去脉，接着，进入主题。

SpringBoot 为什么这么火？

spring-boot-starter-web

对 Spring 比较熟悉的话， 基于 SpringBoot 开发 web 应用时，引入 spring-boot-starter-web 组件是必不可少的，spring-boot-starter-web 的职责是负责 web 应用的启动 、初始化、运行和停止。而 spring-boot-starter-web 组件之所以能够跑起来，少不了 http 协议的支持，典型代表就是 tomcat 服务器。

通过翻阅 spring-boot-starter-web 组件的相关 maven 依赖，我们找到了 spring-boot-starter-tomcat 组件。

<dependency>    <groupId>org.springframework.boot</groupId>   <artifactId>spring-boot-starter-tomcat</artifactId>    <version>2.1.5.RELEASE</version>  <scope>compile</scope></dependency>

接着查找 spring-boot-starter-tomcat 的 maven 依赖， 其引入了 tomcat-embed-core 、tomcat-embed-el 、tomcat-annotations-api 等嵌入式组件。

<dependency>    <groupId>javax.annotation</groupId>    <artifactId>javax.annotation-api</artifactId>    <version>1.3.2</version>    <scope>compile</scope>  </dependency>  <dependency>    <groupId>org.apache.tomcat.embed</groupId>    <artifactId>tomcat-embed-core</artifactId>    <version>9.0.19</version>    <scope>compile</scope>    <exclusions>      <exclusion>        <artifactId>tomcat-annotations-api</artifactId>        <groupId>org.apache.tomcat</groupId>      </exclusion>    </exclusions>  </dependency>  <dependency>    <groupId>org.apache.tomcat.embed</groupId>    <artifactId>tomcat-embed-el</artifactId>    <version>9.0.19</version>    <scope>compile</scope>  </dependency>  <dependency>    <groupId>org.apache.tomcat.embed</groupId>    <artifactId>tomcat-embed-websocket</artifactId>    <version>9.0.19</version>    <scope>compile</scope>  </dependency></dependencies>

正是由于这些嵌入式组件的加入，免去了 Tomcat 单独安装部署的繁杂步骤，我想这也是 SpringBoot 非常火的原因之一吧。

SpringBoot 对 AJP 协议的支持

通过阅读 tomcat-embed-core 组件，说明嵌入式 tomcat 是支持 AJP 协议的，相关代码在 org.apache.coyote.ajp 目录下。

但是奇怪的是，在 SpringBoot 的 yml 文件配置中，并没有找到 ajp 协议相关的 server 参数配置。



笔者猜测，虽然 Tomcat 集成了 ajp 协议，但是不推荐使用吧。但是有没有办法支持 ajp 协议了，答案是可以的，具体代码如下:

@Configurationpublic class AJPConfig {    private static final String PROTOCOL = "AJP/1.3";    @Value("${tomcat.ajp.port:8009}")    private int ajpPort;    @Bean    public EmbeddedServletContainerFactory servletContainer() {        TomcatEmbeddedServletContainerFactory tomcat = new TomcatEmbeddedServletContainerFactory();        Connector ajpConnector = new Connector();        ajpConnector.setProtocol(PROTOCOL);        ajpConnector.setPort(ajpPort);        tomcat.addAdditionalTomcatConnectors(ajpConnector);        return tomcat;    }}

笔者上述配置需要依赖 SpringBoot 1.x 环境。

AjpProcessor

如果对 tomcat 架构比较了解的话，tomcat 大部分请求与响应由协议（Protocol）中的处理器（Processor）完成的。



 

所以在 tomcat 服务器接收 ajp 请求时， 由 AjpProcessor 来处理 ajp 真实的 request 请求消息。



 

然后，通过 prepareRequest 方法将 ajp 请求内容取出来，设置成 request 对象的 Attribute 属性



 

 



 

因此，黑客通过设置 request_uri、path_info 、servlet_path 属性值，从而可以读取到 /WEB-INF 下面的所有敏感文件，不限于class、xml、jar等文件。

javax.servlet.include.request_urijavax.servlet.include.path_infojavax.servlet.include.servlet_path

至于漏洞的详细分析不是本文重点，传送门：


https://blog.csdn.net/u012206617/article/details/104416626/

概况

HTTP是hypertext transfer protocol（超文本传输协议）的简写，它是TCP/IP协议的一个应用层协议，用于定义WEB浏览器与WEB服务器之间交换数据的过程。 

HTTP是一个属于应用层的面向对象的协议，由于其简捷、快速的方式，适用于分布式超媒体信息系统。它于1990年提出，经过几年的使用与发展，得到不断地完善和扩展。目前在WWW中使用的是HTTP/1.0的第六版，HTTP/1.1的规范化工作正在进行之中，而且HTTP-NG(Next Generation of HTTP)的建议已经提出。



主要特点

HTTP协议的主要特点可概括如下：

1.支持客户/服务器模式。
2.简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。
3.灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。
4.无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。
5.无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。
HTTP协议



HTTP协议详解之URL

http（超文本传输协议）是一个基于请求与响应模式的、无状态的、应用层的协议，常基于TCP的连接方式，HTTP1.1版本中给出一种持续连接的机制，绝大多数的Web开发，都是构建在HTTP协议之上的Web应用。

HTTP URL (URL是一种特殊类型的URI，包含了用于查找某个资源的足够的信息)的格式如下：




http://host[":"port][abs_path]


http表示要通过HTTP协议来定位网络资源； 
host表示合法的Internet主机域名或者IP地址； 
port指定一个端口号，为空则使用缺省端口80； 
abs_path指定请求资源的URI； 
如果URL中没有给出abs_path，那么当它作为请求URI时，必须以“/”的形式给出，通常这个工作浏览器自动帮我们完成。

举例： 

eg: http:192.168.0.1:8080/index.jsp



HTTP协议详解之请求

http请求由三部分组成，分别是：请求行、消息报头、请求正文



请求行

请求行以一个方法符号开头，以空格分开，后面跟着请求的URI和协议的版本，格式如下：



Method Request-URI HTTP-Version CRLF


其中 ： 
Method表示请求方法； 
Request-URI是一个统一资源标识符； 
HTTP-Version表示请求的HTTP协议版本； 
CRLF表示回车和换行（除了作为结尾的CRLF外，不允许出现单独的CR或LF字符）。



请求方法（所有方法全为大写）：

GET　　　 请求获取Request-URI所标识的资源
POST　　　在Request-URI所标识的资源后附加新的数据
HEAD　　　请求获取由Request-URI所标识的资源的响应消息报头
PUT　　　 请求服务器存储一个资源，并用Request-URI作为其标识
DELETE　　请求服务器删除Request-URI所标识的资源
TRACE　　 请求服务器回送收到的请求信息，主要用于测试或诊断
CONNECT　 保留将来使用
OPTIONS　 请求查询服务器的性能，或者查询与资源相关的选项和需求
应用举例：

GET方法：在浏览器的地址栏中输入网址的方式访问网页时，浏览器采用GET方法向服务器获取资源，eg:GET /form.html HTTP/1.1 (CRLF)

POST方法：要求被请求服务器接受附在请求后面的数据，常用于提交表单。

eg：POST /reg.jsp HTTP/ (CRLF) 

Accept:image/gif,image/x-xbit,… (CRLF) 

… 

HOST:XXX.XX.XX (CRLF) 

Content-Length:22 (CRLF) 

Connection:Keep-Alive (CRLF) 

Cache-Control:no-cache (CRLF) 

(CRLF) //该CRLF表示消息报头已经结束，在此之前为消息报头 

user=username&pwd=password//此行以下为提交的数据 


HEAD方法与GET方法几乎是一样的，对于HEAD请求的回应部分来说，它的HTTP头部中包含的信息与通过GET请求所得到的信息是相同的。利用这个方法，不必传输整个资源内容，就可以得到Request-URI所标识的资源的信息。该方法常用于测试超链接的有效性，是否可以访问，以及最近是否更新。

请求报头后述



请求正文

HTTP协议详解之响应

在接收和解释请求消息后，服务器返回一个HTTP响应消息。

HTTP响应也是由三个部分组成，分别是：状态行、消息报头、响应正文

状态行格式如下




HTTP-Version Status-Code Reason-Phrase CRLF


其中： 

HTTP-Version表示服务器HTTP协议的版本； 

Status-Code表示服务器发回的响应状态代码； 

Reason-Phrase表示状态代码的文本描述。

状态代码有三位数字组成，第一个数字定义了响应的类别，且有五种可能取值：

1xx:信息响应类，表示接收到请求并且继续处理 
2xx:处理成功响应类，表示动作被成功接收、理解和接受 
3xx:重定向响应类，为了完成指定的动作，必须接受进一步处理 
4xx:客户端错误，客户请求包含语法错误或者是不能正确执行 
5xx:服务端错误，服务器不能正确执行一个正确的请求
常见状态代码、状态描述、说明：

200 OK //客户端请求成功
400 Bad Request //客户端请求有语法错误，不能被服务器所理解
401 Unauthorized //请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用
403 Forbidden //服务器收到请求，但是拒绝提供服务
404 Not Found //请求资源不存在，eg：输入了错误的URL
500 Internal Server Error //服务器发生不可预期的错误
503 Server Unavailable //服务器当前不能处理客户端的请求，一段时间后可能恢复正常 

eg：HTTP/1.1 200 OK （CRLF）
响应报头后述



响应正文就是服务器返回的资源的内容



HTTP协议详解之消息报头

HTTP消息由客户端到服务器的请求和服务器到客户端的响应组成。请求消息和响应消息都是由开始行（对于请求消息，开始行就是请求行，对于响应消息，开始行就是状态行），消息报头（可选），空行（只有CRLF的行），消息正文（可选）组成。

HTTP消息报头包括普通报头、请求报头、响应报头、实体报头。 

每一个报头域都是由名字+“：”+空格+值 组成，消息报头域的名字是大小写无关的。



普通报头

在普通报头中，有少数报头域用于所有的请求和响应消息，但并不用于被传输的实体，只用于传输的消息。

eg：Cache-Control 用于指定缓存指令，缓存指令是单向的（响应中出现的缓存指令在请求中未必会出现），且是独立的（一个消息的缓存指令不会影响另一个消息处理的缓存机制），HTTP1.0使用的类似的报头域为Pragma。

请求时的缓存指令包括：no-cache（用于指示请求或响应消息不能缓存）、no-store、max-age、max-stale、min-fresh、only-if-cached;
响应时的缓存指令包括：public、private、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age、s-maxage.
eg：为了指示IE浏览器（客户端）不要缓存页面，服务器端的JSP程序可以编写如下：



response.setHeader("Cache-Control","no-cache");
//response.setHeader("Pragma","no-cache");作用相当于上述代码，通常两者//合用


这句代码将在发送的响应消息中设置普通报头域：Cache-Control:no-cache 

Date普通报头域表示消息产生的日期和时间 

Connection普通报头域允许发送指定连接的选项。例如指定连接是连续，或者指定“close”选项，通知服务器，在响应完成后，关闭连接.



请求报头

请求报头允许客户端向服务器端传递请求的附加信息以及客户端自身的信息。

常用的请求报头:

Accept请求报头域用于指定客户端接受哪些类型的信息。 

举例： 

Accept：image/gif，表明客户端希望接受GIF图象格式的资源； 

Accept：text/html，表明客户端希望接受html文本。
Accept-Charset请求报头域用于指定客户端接受的字符集。 

举例：Accept-Charset:iso-8859-1,gb2312. 

如果在请求消息中没有设置这个域，缺省是任何字符集都可以接受。
Accept-Encoding请求报头域类似于Accept，但是它是用于指定可接受的内容编码。 

举例：Accept-Encoding:gzip.deflate. 

如果请求消息中没有设置这个域服务器假定客户端对各种内容编码都可以接受。
Accept-Language请求报头域类似于Accept，但是它是用于指定一种自然语言。 

举例：Accept-Language:zh-cn. 

如果请求消息中没有设置这个报头域，服务器假定客户端对各种语言都可以接受。
Authorization 请求报头域主要用于证明客户端有权查看某个资源。当浏览器访问一个页面时，如果收到服务器的响应代码为401（未授权），可以发送一个包含Authorization请求报头域的请求，要求服务器对其进行验证。
Host请求报头域主要用于指定被请求资源的Internet主机和端口号，它通常从HTTP URL中提取出来的，发送请求时，该报头域是必需的。 

比如 我们在浏览器中输入：http://www.imooc.com/index.jsp 

浏览器发送的请求消息中，就会包含Host请求报头域，如下：Host：www.imooc.com 

此处使用缺省端口号80，若指定了端口号，则变成：Host：www.imooc.com:指定端口号。
User-Agent我们上网登陆论坛的时候，往往会看到一些欢迎信息，其中列出了你的操作系统的名称和版本，你所使用的浏览器的名称和版本，这往往让很多人感到很神奇，实际上，服务器应用程序就是从User-Agent这个请求报头域中获取到这些信息。User-Agent请求报头域允许客户端将它的操作系统、浏览器和其它属性告诉服务器。不过，这个报头域不是必需的，如果我们自己编写一个浏览器，不使用User-Agent请求报头域，那么服务器端就无法得知我们的信息了。
请求报头举例：



响应报头

响应报头允许服务器传递不能放在状态行中的附加响应信息，以及关于服务器的信息和对Request-URI所标识的资源进行下一步访问的信息。

常用的响应报头 

Location响应报头域用于重定向接受者到一个新的位置。Location响应报头域常用在更换域名的时候。 

Server响应报头域包含了服务器用来处理请求的软件信息。与User-Agent请求报头域是相对应的。下面是Server响应报头域的一个例子：Server：nginx 

WWW-Authenticate响应报头域必须被包含在401（未授权的）响应消息中，客户端收到401响应消息时候，并发送Authorization报头域请求服务器对其进行验证时，服务端响应报头就包含该报头域。 

eg：WWW-Authenticate:Basic realm=”Basic Auth Test!” //可以看出服务器对请求资源采用的是基本验证机制。





实体报头

请求和响应消息都可以传送一个实体。一个实体由实体报头域和实体正文组成，但并不是说实体报头域和实体正文要在一起发送，可以只发送实体报头域。实体报头定义了关于实体正文（eg：有无实体正文）和请求所标识的资源的元信息。

常用的实体报头：

Content-Encoding实体报头域被用作媒体类型的修饰符，它的值指示了已经被应用到实体正文的附加内容的编码，因而要获得Content-Type报头域中所引用的媒体类型，必须采用相应的解码机制。ContentEncoding这样用于记录文档的压缩方法，eg：Content-Encoding：gzip
Content-Language实体报头域描述了资源所用的自然语言。没有设置该域则认为实体内容将提供给所有的语言阅读 

者。eg：Content-Language:da
Content-Length实体报头域用于指明实体正文的长度，以字节方式存储的十进制数字来表示。
Content-Type实体报头域用语指明发送给接收者的实体正文的媒体类型。eg：Content-Type:text/html;charset=ISO-8859-1 Content-Type:text/html;charset=GB2312
Last-Modified实体报头域用于指示资源的最后修改日期和时间。
Expires实体报头域给出响应过期的日期和时间。为了让代理服务器或浏览器在一段时间以后更新缓存中(再次访问曾访问过的页面时，直接从缓存中加载，缩短响应时间和降低服务器负载)的页面，我们可以使用Expires实体报头域指定页面过期的时间。eg：Expires：Thu，15 Sep 2006 16:23:12 GMT 

HTTP1.1的客户端和缓存必须将其他非法的日期格式（包括0）看作已经过期。eg：为了让浏览器不要缓存页面，我们也可以利用Expires实体报头域，设置为0，jsp中程序如下：response.setDateHeader(“Expires”,”0”);
工具类HttpUtil.java



import java.io.IOException;
import java.io.UnsupportedEncodingException;

import org.apache.http.HttpEntity;
import org.apache.http.HttpResponse;
import org.apache.http.client.ClientProtocolException;
import org.apache.http.client.methods.HttpGet;
import org.apache.http.client.methods.HttpPost;
import org.apache.http.entity.StringEntity;
import org.apache.http.impl.client.DefaultHttpClient;
import org.apache.http.params.HttpConnectionParams;
import org.apache.http.params.HttpParams;
import org.apache.http.util.EntityUtils;

public class HttpUtil {
    public static String httpGet(String httpUrl) {
        String result = "";
        DefaultHttpClient httpclient = new DefaultHttpClient();// 创建http客户端
        HttpGet httpget = new HttpGet(httpUrl);
        HttpResponse response = null;
        HttpParams params = httpclient.getParams(); // 计算网络超时用
        HttpConnectionParams.setConnectionTimeout(params, 15 * 1000);
        HttpConnectionParams.setSoTimeout(params, 20 * 1000);
        try {
            response = httpclient.execute(httpget);
            HttpEntity entity = response.getEntity();// 得到http的内容
            response.getStatusLine().getStatusCode();// 得到http的状态返回值
            result = EntityUtils.toString(response.getEntity());// 得到具体的返回值，一般是xml文件
            entity.consumeContent();// 如果entity不为空，则释放内存空间
            httpclient.getCookieStore();// 得到cookis
            httpclient.getConnectionManager().shutdown();// 关闭http客户端
        } catch (ClientProtocolException e) {
            e.printStackTrace();
        } catch (IOException e) {
            e.printStackTrace();
        }
        return result;
    }

    public static String httpPost(String httpUrl, String data) {
        String result = "";
        DefaultHttpClient httpclient = new DefaultHttpClient();
        HttpPost httpPost = new HttpPost(httpUrl);
        // httpclient.setCookieStore(DataDefine.mCookieStore);
        HttpParams params = httpclient.getParams(); // 计算网络超时用
        HttpConnectionParams.setConnectionTimeout(params, 15 * 1000);
        HttpConnectionParams.setSoTimeout(params, 20 * 1000);
        httpPost.setHeader("Content-Type", "text/xml");
        StringEntity httpPostEntity;
        try {
            httpPostEntity = new StringEntity(data, "UTF-8");
            httpPost.setEntity(httpPostEntity);
            HttpResponse response = httpclient.execute(httpPost);
            HttpEntity entity = response.getEntity();// 得到http的内容
            response.getStatusLine().getStatusCode();// 得到http的状态返回值
            result = EntityUtils.toString(response.getEntity());// 得到具体的返回值，一般是xml文件
            entity.consumeContent();// 如果entity不为空，则释放内存空间
            httpclient.getCookieStore();// 得到cookis
            httpclient.getConnectionManager().shutdown();// 关闭http客户端
        } catch (Exception e) {
            e.printStackTrace();
        } // base64是经过编码的字符串，可以理解为字符串 // StringEntity
        try {
            httpPostEntity = new StringEntity("UTF-8");
        } catch (UnsupportedEncodingException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }
        return result;
    }
}



HTTPS协议



HTTPS协议概述

HTTPS（Hypertext Transfer Protocol over Secure Socket Layer，基于SSL的HTTP协议）使用了HTTP协议，但HTTPS使用不同于HTTP协议的默认端口及一个加密、身份验证层（HTTP与TCP之间）。这个协议的最初研发由网景公司进行，提供了身份验证与加密通信方法，现在它被广泛用于互联网上安全敏感的通信。HTTPS是一个安全通信通道，用于在客户计算机和服务器之间交换信息。它使用安全套接字层(SSL)进行信息交换，简单来说它是HTTP的安全版。它是由Netscape开发并内置于其浏览器中，用于对数据进行压缩和解压操作，并返回网络上传送回的结果。

HTTPS实际上应用了Netscape的安全全套接字层(SSL)作为HTTP应用层的子层。(HTTPS使用端口443，而不是象HTTP那样使用端口80来和TCP/IP进行通信。)SSL使用40 位关键字作为RC4流加密算法，这对于商业信息的加密是合适的。HTTPS和SSL支持使用X。509数字认证，如果需要的话用户可以确认发送者是谁。



使用HTTPS步骤

客户端在使用HTTPS方式与Web服务器通信时有以下几个步骤。 

（1）客户使用https的URL访问Web服务器，要求与Web服务器建立SSL连接。 

（2）Web服务器收到客户端请求后，会将网站的证书信息（证书中包含公钥）传送一份给客户端。 

（3）客户端的浏览器与Web服务器开始协商SSL连接的安全等级，也就是信息加密的等级。 

（4）客户端的浏览器根据双方同意的安全等级，建立会话密钥，然后利用网站的公钥将会话密钥加密，并传送给网站。 

（5）Web服务器利用自己的私钥解密出会话密钥。 

（6）Web服务器利用会话密钥加密与客户端之间的通信。



工具类HttpsUtils.java



import java.io.BufferedReader;
import java.io.DataOutputStream;
import java.io.InputStreamReader;
import java.net.HttpURLConnection;
import java.net.URL;

import javax.net.ssl.HostnameVerifier;
import javax.net.ssl.HttpsURLConnection;
import javax.net.ssl.SSLContext;
import javax.net.ssl.TrustManager;

public class HttpsUtil {
    static TrustManager[] xtmArray = new MytmArray[] { new MytmArray() };// 创建信任规则列表
    private final static int CONNENT_TIMEOUT = 15000;
    private final static int READ_TIMEOUT = 15000;
    static HostnameVerifier DO_NOT_VERIFY = new HostnameVerifier() {
        public boolean verify(String hostname, SSLSession session) {
            return true;
        }
    };

    /**
     * * 信任所有主机-对于任何证书都不做检查 Create a trust manager that does not validate *
     * certificate chains， Android 采用X509的证书信息机制，Install the all-trusting trust
     * * manager
     */
    private static void trustAllHosts() {
        try {
            SSLContext sc = SSLContext.getInstance("TLS");
            sc.init(null, xtmArray, new java.security.SecureRandom());
            HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory()); // 不进行主机名确认,对所有主机
            HttpsURLConnection.setDefaultHostnameVerifier(DO_NOT_VERIFY);
        } catch (Exception e) {
            e.printStackTrace();
        }
    } 

    // https get方法，返回值是https请求，服务端返回的数据string类型，数据进行xml解析 
    public static String HttpsGet(String httpsurl) { 
        return HttpsPost(httpsurl, null); 
    }

    /**
     * https post方法，返回值是https请求，服务端返回的数据string类型，数据进行xml解析
     */
    public static String HttpsPost(String httpsurl, String data) {
        String result = null;
        HttpURLConnection http = null;
        URL url;
        try {
            url = new URL(httpsurl); // 判断是http请求还是https请求
            if (url.getProtocol().toLowerCase().equals("https")) {
                trustAllHosts();
                http = (HttpsURLConnection) url.openConnection();
                ((HttpsURLConnection) http).setHostnameVerifier(DO_NOT_VERIFY);// 不进行主机名确认
            } else {
                http = (HttpURLConnection) url.openConnection();
            }
            http.setConnectTimeout(CONNENT_TIMEOUT);// 设置超时时间
            http.setReadTimeout(READ_TIMEOUT);
            if (data == null) {
                http.setRequestMethod("GET");// 设置请求类型
                http.setDoInput(true);
                // http.setRequestProperty("Content-Type", "text/xml");
                if (AppSession.mCookieStore != null)
                    http.setRequestProperty("Cookie", AppSession.mCookieStore);
            } else {
                http.setRequestMethod("POST");// 设置请求类型为post
                http.setDoInput(true);
                http.setDoOutput(true);
                // http.setRequestProperty("Content-Type", "text/xml");
                if (AppSession.mCookieStore != null && AppSession.mCookieStore.trim().length() > 0)
                    http.setRequestProperty("Cookie", AppSession.mCookieStore);
                DataOutputStream out = new DataOutputStream(http.getOutputStream());
                out.writeBytes(data);
                out.flush();
                out.close();
            } // 设置http返回状态200（ok）还是403
            AppSession.httpsResponseCode = http.getResponseCode();
            BufferedReader in = null;
            if (AppSession.httpsResponseCode == 200) {
                getCookie(http);
                in = new BufferedReader(new InputStreamReader(http.getInputStream()));
            } else
                in = new BufferedReader(new InputStreamReader(http.getErrorStream()));
            String temp = in.readLine();
            while (temp != null) {
                if (result != null)
                    result += temp;
                else
                    result = temp;
                temp = in.readLine();
            }
            in.close();
            http.disconnect();
        } catch (Exception e) {
            e.printStackTrace();
        }
        return result;
    }

    /** * 得到cookie * */
    private static void getCookie(HttpURLConnection http) {
        String cookieVal = null;
        String key = null;
        AppSession.mCookieStore = "";
        for (int i = 1; (key = http.getHeaderFieldKey(i)) != null; i++) {
            if (key.equalsIgnoreCase("set-cookie")) {
                cookieVal = http.getHeaderField(i);
                cookieVal = cookieVal.substring(0, cookieVal.indexOf(";"));
                AppSession.mCookieStore = AppSession.mCookieStore + cookieVal + ";";
            }
        }
    }
}

总的来说，http效率更高，https安全性更高。



两者的区别

https协议需要到ca申请证书，一般免费证书很少，需要交费。
http是超文本传输协议，信息是明文传输，https 则是具有安全性的ssl加密传输协议 
http和https使用的是完全不同的连接方式用的端口也不一样：前者是80，后者是443。
http的连接很简单，是无状态的 ，HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议 ，要比http协议安全。
HTTPS解决的问题：

1、信任主机的问题。 采用https 的server 必须从CA 申请一个用于证明服务器用途类型的证书。 

该证书只有用于对应的server 的时候，客户度才信任此主机。所以目前所有的银行系统网站，关键部分应用都是https 的。 客户通过信任该证书，从而信任了该主机。其实这样做效率很低，但是银行更侧重安全。 这一点对我们没有任何意义，我们的server，采用的证书不管自己issue 还是从公众的地方issue， 客户端都是自己人，所以我们也就肯定信任该server。 

2、通讯过程中的数据的泄密和被窜改。 

1）一般意义上的https， 就是 server 有一个证书。 

主要目的是保证server 就是他声称的server。这个跟第一点一样。服务端和客户端之间的所有通讯，都是加密的。 
具体讲，是客户端产生一个对称的密钥，通过server 的证书来交换密钥。 一般意义上的握手过程。加下来所有的信息往来就都是加密的。 第三方即使截获，也没有任何意义。因为他没有密钥。当然窜改也就没有什么意义了。 

2）少许对客户端有要求的情况下，会要求客户端也必须有一个证书。 

这里客户端证书，其实就类似表示个人信息的时候，除了用户名/密码， 还有一个CA 认证过的身份。 应为个人证书一般来说上别人无法模拟的，所有这样能够更深的确认自己的身份。目前少数个人银行的专业版是这种做法，具体证书可能是拿U盘作为一个备份的载体。 HTTPS 一定是繁琐的。 

本来简单的http协议，一个get一个response。由于https 要还密钥和确认加密算法的需要。单握手就需要6/7 个往返。任何应用中，过多的round trip 肯定影响性能。接下来才是具体的http协议，每一次响应或者请求， 都要求客户端和服务端对会话的内容做加密/解密。尽管对称加密/解密效率比较高，可是仍然要消耗过多的CPU，为此有专门的SSL 芯片。 如果CPU 信能比较低的话，肯定会降低性能，从而不能serve 更多的请求。



SSL的简介

SSL是Netscape公司所提出的安全保密协议，在浏览器(如Internet Explorer、Netscape Navigator)和Web服务器(如Netscape的Netscape Enterprise Server、ColdFusion Server等等)之间构造安全通道来进行数据传输，SSL运行在TCP/IP层之上、应用层之下，为应用程序提供加密数据通道，它采用了RC4、MD5 以及RSA等加密算法，使用40 位的密钥，适用于商业信息的加密。 

同时，Netscape公司相应开发了HTTPS协议并内置于其浏览器中，HTTPS实际上就是SSL over HTTP，它使用默认端口443，而不是像HTTP那样使用端口80来和TCP/IP进行通信。HTTPS协议使用SSL在发送方把原始数据进行加密，然 后在接受方进行解密，加密和解密需要发送方和接受方通过交换共知的密钥来实现，因此，所传送的数据不容易被网络黑客截获和解密。 

然而，加密和解密过程需要耗费系统大量的开销，严重降低机器的性能，相关测试数据表明使用HTTPS协议传输数据的工作效率只有使用HTTP协议传输的十 分之一。 

假如为了安全保密，将一个网站所有的Web应用都启用SSL技术来加密，并使用HTTPS协议进行传输，那么该网站的性能和效率将会大大降低，而且没有这个必要，因为一般来说并不是所有数据都要求那么高的安全保密级别，所以，我们只需对那些涉及机密数据的交互处理使用HTTPS协议，这样就做到鱼与熊掌兼得。总之不需要用https 的地方，就尽量不要用。

参考：http://aresxiong.com/2015/11/30/protocol_http_and_https

BGP：边界网关路由协议
一. 定义

二. 特点

三. BGP数据包

四. BGP工作过程

五. BGP名词

六. BGP路由黑洞问题

七. BGP的破环机制

八、配置

九、BGP的宣告问题

十、关闭BGP自动汇总问题

十一、BGP的聚合

十二、BGP在MA网络中的下一跳问题
一、定义

BGP：边界网关路由协议，又称为无类别路径矢量路由协议，是典型的EGP协议，作用于AS与AS之间。

自治系统（AS）：由同一个技术管理机构管理，使用同一管理控制和选路策略的一些路由器的集合。AS编号由英特网注册机构统一管理分配，范围是1-65535，其中1-64511是注册的英特网编号，64512-65535是私有的网络编号。

IGP协议工作追求：

1:、收敛快

2、占用资源少

3、选路佳（无环）

EGP协议工作追求：

1、可靠性

2、可控性

3、AS-BY-AS
二、BGP特点

1、无类别路径协议，是距离矢量的升级版（路径矢量和距离矢量均选择共享路由表来收敛，但距离矢量基于一台路由器为一跳，路径矢量基于一个AS为一跳）

2、使用单播更新来发送所有信息，基于TCP 179端口工作

3、增量更新–仅触发无周期

4、具有丰富的属性来取代IGP中度量进行选路----多个参数控制协议

5、可以在进项和出项对流量实施强大的策略–可控性

6、默认不被用于负载均衡-----通过各种选路规则仅仅产生一条最佳路径

7、BGP支持认证和聚合（汇总，一般是往超网汇总所以称为聚合）

8、BGP协议不生产路由，只是路由的搬运工
三、BGP的数据包

BGP所有的数据均基于TCP会话传递，由TCP来进行邻居的发现及所有数据包的ACK

open：存在hold time 和 RID（生成方式和OSPF一致）；用于邻居关系建立；默认仅收发一次即可；邻居发现是由TCP三次握手完成的，包活不用open包

Keeplive ：保活包 ，周期1min保活 TCP会话，hold time 180s；实际是包活TCP的会话

update：更新包—增量更新；路由信息==目标网络号+属性

notificatio：报错包，检测到BGP路由出现错误时发送，发出该消息后BGP连接被立即关闭
四、BGP的工作过程

1、启动配置完成后，本地和对端先单播进行TCP的三次握手，建立TCP的会话。

2、会话建立后，使用open报文进行邻居关系的建立，正常收发一次open报文即可；建立关系后生成邻居表。

3、邻居关系建立后，用户进行路由宣告；宣告配置完成后，BGP使用update包进行路由条目的传递—目标网络号+属性

4、本地接收到的所有路由条目均存储在BGP表中；–装载本地发出和接收到的所有路由。

5、默认仅从BGP表中挑选一条最优路径到路由表内。

6、收敛完成，仅keeplive包继续周期保活TCP会话即可。

注：所有BGP协议的数据包均基于TCP的会话传递；TCP会保证这些数据包的可靠性-确认、重传、排序、流控（窗口机制）

若结构突变：

1、新增网段–BGP路由上出现了新的宣告路由，使用更新包更新即可

2、断开网段–BGP路由上出现断开路由，若本地给邻居发送的是汇总路由；那么只要所有明细没有全部断开，将不进行BGP更新；若明细全部消失，使用更新包告知即可；对端删除该信息即可；

3、无法沟通—hold time到时时，断开邻居关系，删除所有通过该邻居学习到的信息；
五、BGP名词注解

1、对等体（peer），邻居是直连建立关系，对等体非直连建立邻居关系，故把邻居称为对等体peer

2、EBGP邻居关系，不同AS间设备建立的邻居关系，通过EBGP邻居学习的路由，管理距离为20（别人传的不用算路）

3、IBGP邻居关系，同一AS内设备的邻居关系 ，通过IBGP邻居学习到的路由，管理距离200（IBGP邻居学习的所以要算路）
六、BGP的路由黑洞

因为考虑成本和实用性，正常在一个AS内部不是所有的设备都运行BGP协议，故将出现路由可达，但实际数据在传输时，经过中间未运行BGP协议的路由器后被丢弃。

路由黑洞：控制层面可达，数据层面不可达（此概念出于MPLS时代）

控制层面：传路由表的方向
数据层面：访问目标的方向

1、BGP协议是基于TCP单播沟通，可以穿越中间设备来传递路由

2、BGP的路由正常均需要递归多次到直连路由，运行BGP协议的路由基本都可以完成递归，认为可达，不关注下一跳设备是否由路由，只要本地能到下一跳即可

3、BGP生成的路由是唯一路径，但递归可以多条路径传输

解决BGP路由黑洞：

1）物理链路全连（IBGP中运行BGP协议的路由器太远不能实现）

2）邻居关系全连（所有设备均运行BGP）

3）将BGP重发布到IGP（LAB实验环境下应用，慎用）

4）MPLS，多协议标签交换（最佳）
七、BGP的防环机制—水平分割

EBGP水平分割：防止EBGP邻居关系下的环路，路由条目在BGP协议中传递时，存在一个AS path属性。该属性记录经过的每一个AS编号，BGP拒绝接受存在本地AS编号的路由。
IBGP水平分割：防止IBGP邻居关系下的环路，因为AS-BY-AS规则，一条条目在一个AS内部传递时，默认没有任何属性的变化，故很容易在IGBP邻居关系产生环路。

IBGP水平分割规则：从一台IBGP邻居学习到的路由条目不得传递给下一台IBGP邻居的路由器，该设计为实现路由的正常传递，必须进行两两间建立IBGP邻居关系配置量几何式增长-----联邦，路由反射器解决此问题

八、配置

IBGP之间运行协议，处于IBGP边界的设备和EBGP的接口不宣告

【1】建立BGP的邻居关系

在BGP协议中邻居关系的建立与路由条目的宣告是分开进行的


建立普通的EBGP邻居关系

r1(config-router)#neighbor 12.1.1.2 remote-as 2

------------------------------ 对端接口ip —对端的AS号


建立IBGP邻居关系，正常一个AS内部网络拓扑不会是直线型：因此IBGP邻居关系间实际存在多条可达路径（物理接口建立），建议环回建立TCP会话的源，目标IP地址（好处1.存在备份路径 2.同时基于多条路径通讯）邻居关系

r2(config-router)#neighbor 4.4.4.4 remote-as 2

切记环回建邻时，需要将更新源地址也修改为环回接口；

r2(config-router)#neighbor 4.4.4.4 update-source loopback 0


EBGP邻居间，存在多条链路建议使用还回建立

{1} 先处理IP可达问题

r4(config)#ip route 5.5.5.0 255.255.255.0 45.1.1.2

r4(config)#ip route 5.5.5.0 255.255.255.0 54.1.1.2

{2} 使用环回建立关系

r4(config)#router bgp 2

r4(config-router)#neighbor 5.5.5.5 remote-as 3

r4(config-router)#neighbor 5.5.5.5 update-source loopback 0

{3} 默认EBGP邻居间数据包的TTL值为1，IBGP间为255；故若使用环回来建立ebgp邻居关系，必须修改TTL值

r4(config-router)#neighbor 5.5.5.5 ebgp-multihop ?

<1-255>  maximum hop count

     255

r4(config-router)#neighbor 5.5.5.5 ebgp-multihop

建邻配置完成后，两端进行TCP的三次握手行为；建立TCP的会话



当TCP会话建立后，邻居间使用open报文来进行邻居关系；生成邻居表



【2】宣告路由

BGP协议不计算产生路由条目，而是将本地路由表中的路由条目共享到BGP来；这些路由是通过什么方式获取的不关注；

规则：宣告时所填写的条目内容必须和路由表中的记录完全一致 可控性的体现

r1(config)#router bgp 1

r1(config-router)#network 1.1.1.0 mask 255.255.255.0

宣告条目后，本地将生成BGP表—本地收发的所有路由信息；





不可用的条件（不满足不可用就可用了，可用条件不好写）：

1.*号被r取代  r标示不装载—本地路由表中已存在更好的路由

2.*被s取代  s标示抑制—是管理用手工限制该条目的传输

优秀的条件：1.同步问题—本地路由表中必须先通过IGP学习到该路由，为了避免路由黑洞

在IOS版本11.2（8）T以上设备直接默认关闭该限制



2.下一跳可达----AS-BY-AS导致的，条目在传递给IGBP时下一跳属性默认不修改

可以让设备从EBGP邻居处学习到的路由传递给IBGP时，修改下一跳为自己

r2(config)#router bgp 2

r2(config-router)#neighbor 4.4.4.4 next-hop-self

将路由传递给邻居4.4.4.4时修改下一跳地址为本地

当条目传输给EBGP邻居时，进入下一个AS了，过程中修改属性（包括下一跳）


注：一条条目必须优且可用才能加表；只有优同时没有被抑制（人为）就可以传递；
九、BGP的宣告问题

一台运行BGP协议的设备在宣告本地路由表中非本地直连路由时，将携带本地到达这些路由的度量和下一跳地址；
度量问题：AS2中假设R2/R3同时连接着AS1；那么它们在宣告了本AS的路由后，将在路由信息中携带本地到达这些网段的度量值，便于AS1判定R2/R3谁离目标最近；

同时这些路由也会被同一AS内的R4/5学习到，R4/5连接着AS3，它们在将路由传递给AS3时，会将度量清0；可以通过在R4/5上宣告AS2的路由，来向AS3导入R4/5的度量；
总结：所有存在EBGP邻居的路由器均宣告本地AS的路由；
十、关闭BGP自动汇总问题

no auto-summary 对BGP的正常的宣告路由没有影响；正常宣告路由及时设备在auto-summary条件下也携带路由表中的实际掩码；

12.2（8）T以上IOS默认no auto-summary；

自动汇总针对的是从IGP重发布到BGP的路由；

r2(config)#router bgp 2

r2(config-router)#redistribute ospf 1

批量重发布的路由    auto-summary 不携带原有掩码、度量、下一跳

------------------------no auto-summary携带原有掩码、度量、下一跳
总结：所有存在EBGP邻居的路由器均重发布本地AS的路由；同时为 no auto-summary；
将IGP重发布到BGP–批量的将IGP路由宣告到BGP；在BGP协议中逐条宣告IGP路由–逐一的将IGP路由重发布到bgp；这两种的路由区别仅仅在于起源属性不同；

逐一的起源属性优于批量的属性；
十一、BGP的聚合

【1】利用BGP的宣告特点—本地路由表中无论条目的来源均可宣告；

不需要宣告明细路由，而是在准备汇总设备上，先配置一条到达汇总地址的空接口防环路由，然后将其再宣告到BGP协议中

r5(config)#ip route 10.1.0.0 255.255.252.0 null 0

r5(config)#router bgp 3

r5(config-router)#network 10.1.0.0 mask 255.255.252.0

基于优选路径要求，BGP协议常常需要在传递汇总路由给EBGP邻居后，再传递部分的明细路由；这种聚合配置，只需要在宣告了汇总条目后，再逐一宣告需要的明细路由即可
【2】BGP的聚合配置

先逐一宣告所有的明细路由；再在汇总源路由上，进行聚合配置

r5(config)#router bgp 3

r5(config-router)#aggregate-address 10.1.0.0 255.255.252.0

聚合配置完成后，本地自动生成空接口防环路由

注：以上配置完成后，明细和聚合条目，同时发送；

r5(config-router)#aggregate-address 10.1.0.0 255.255.252.0 summary-only

仅传递聚合条目，所有明细路由被抑制；标记S
【3】控制明细的收发

1）抑制列表–在汇总时，设定一张抑制列表，未被抑制的明细路由和汇总路由同时发出

在汇总配置时，先不抑制明细路由；再定义定义一张抑制列表

r5(config)#ip prefix-list ss permit 10.1.2.0/24

r5(config)#route-map ss permit 10

r5(config-route-map)#match ip address prefix-list ss

r5(config-route-map)#exit

r5(config)#router bgp 3

r5(config-router)#aggregate-address 10.1.0.0 255.255.252.0 suppress-map ss

注：以上被允许流量，实际最终被抑制传输；
注：以下三种方式，即便不在汇总时，也可以正常和邻居间使用；

2）分发列表

r5(config)#access-list 1 deny 10.1.2.0

r5(config)#access-list 1 permit any

r5(config)#router bgp 3

r5(config-router)#neighbor 4.4.4.4 distribute-list 1 out 控制层面方向的邻居

r5#clear ip bgp * soft
3）Route-map

r5(config)#ip prefix-list r permit 10.1.2.0/24

r5(config)#route-map r deny 10

r5(config-route-map)#match ip address prefix-list r

r5(config-route-map)#exit

r5(config)#route-map r permit 20

r5(config-route-map)#exit

r5(config)#router bgp 3

r5(config-router)#neighbor 4.4.4.4 route-map r out 控制层面方向

r5(config-router)#end

r5#clear ip bgp * soft

关注实际状态设备，in、out方向均可；若拒绝的条目多，建议编写允许，然后自动拒绝所有；拒绝的少，那么仅关注拒绝流量，添加允许所有；
4）前缀列表

r5(config)#ip prefix-list qq deny 10.1.2.0/24

r5(config)#ip prefix-list qq permit  0.0.0.0/0 le 32

r5(config)#router bgp 3

r5(config-router)#neighbor 4.4.4.4 prefix-list qq out 控制层面方向调用

r5(config-router)#end

r5#clear ip bgp * soft

关注实际状态设备，in、out方向均可；若拒绝的条目多，建议编写允许，然后自动拒绝所有；拒绝的少，那么仅关注拒绝流量，添加允许所有；
十二、BGP在MA网络中的下一跳问题

基于ICMP重定向规则，在MA网段中传递路由时，将定义为最佳下一跳

r1# debug ip bgp updates

r1#clear ip bgp * 硬重启   断开本地所有邻居间的TCP会话然后重建

r1#clear ip bgp 123.1.1.2   和某个特定的邻居进行硬重启

r1#clear ip bgp * soft  软重启，仅和所有邻居重新收发路由信息，不断开邻居关系

r1#clear ip bgp 123.1.1.2 soft   和某个特定的邻居进行软重启
r1#clear ip bgp 123.1.1.2 soft ?  还可以定义方向，区分本地发出和接收流量

in   Soft reconfig inbound update

out  Soft reconfig outbound update
查看本地发送给该邻居的BGP表内容

r1#show ip bgp neighbors 123.1.1.2 advertised-routes

查看本地从某个邻居接收的BGP表内容

r1#show ip bgp neighbors 123.1.1.2 received-routes

% Inbound soft reconfiguration not enabled on 123.1.1.2 默认没有空间来进行区分

创建专用空间，建议查看完空间内容后，删除该空间

r1(config)#router bgp 1

r1(config-router)#neighbor 123.1.1.2 soft-reconfiguration inbound

一、S-MAC（Sensor-MAC）协议
1、概念：一种用于WSN的低能耗MAC协议。
2、设计考虑因素：

 ① 能量效率：WSN中的节点难以充电和更换，节点生存时间短。

 ② 可扩展性和自适应性：WSN中的网络规模、拓扑结构可能发生变化。

 ③ 其他：公平性、延时、吞吐量、带宽利用率等。
3、设计目标：

 ① 从所有的能耗源着手尽可能降低能量损耗。

 ② 在公平性、高信道利用率和低延时之间进行折中设计，以降低能量损耗。




主要的能耗源
解决方法




碰撞 ：需要重传损坏的分组包
使用RTS-CTS机制


监听 ：获取发送给其他节点的分组包
当节点无数据发送或接收时，将射频前端关闭


控制开销 ： 收发过程中控制分组包
使用消息传递机制


空闲侦听 ： 侦听潜在的流量数据
使用周期性侦听和睡眠


4、网络假设：

 ① WSN中的节点以Ad hoc模式部署

 ② 通信传输以节点间的通信为主，而非以与基站传输为主

 ③ 节点间协作完成某种应用任务

 ④ 节点能够实行自配置
5、特征：

① 协调睡眠：以周期性的侦听和睡眠方式实现

每个节点都周期性地进入睡眠模式，在此模式下，射频前端关闭，并设置计时器唤醒节点，再次进入侦听模式。（睡眠和侦听的时长依据应用场景而定）
邻居节点是同步的，即一起侦听和睡眠，以降低控制开销。（并非所有邻居节点都一起同步）
多个邻居节点要与同一个节点通信时，它们需要采用RTS-CTS竞争机制使用媒质资源。
节点进行数据传输时，不会进入周期睡眠模式，直到数据传输完毕。
每个节点都维持一个调度表，存储所有它已知的邻居节点，调度表的更新通过广播同步包SYNC完成。
每个节点之间的时钟偏移可能会导致同步差错，因此侦听周期要远大于预测的时钟飘移值，以维持同步。（时钟偏移：时钟之间的时间差）

② 自适应侦听：事件驱动

当事件发生时，需要将节点进行模式切换，从low-duty-cycle模式切换到更活跃的模式，以降低延时。

③ 碰撞和监听避免

碰撞避免：采用与IEEE 802.11中的RTS-CTS机制类似
监听避免：干扰节点在收到RTS或CTS包后，进入睡眠状态。

④ 消息传递

消息：是有意义的、相互关联的数据单元
面临的问题：长的消息分组包，在重传时代价太大；短的消息分组包，则会导致高的控制开销。（每次传输都要使用RTS、CTS）
解决办法：将消息分片，并以突发模式传输，利用MAC层的ACK机制实现分片级的差错恢复。这样就可以降低消息时延和控制开销，但公平性也因此降低。



二、Z-MAC（Zebra-MAC）协议
1、概念：一种用于WSN的混合型MAC协议。（结合了TDMA和CSMA的优势）
2、特征：

 ① 基本的数据传输以TDMA调度为基础，但节点又可以通过竞争机制在任何时隙内传输数据，从而获取高的信道利用率和低的竞争开销。
 ② 采取 DRAND（一种分布式的TDMA调度策略） 调度方式，可以使同一干扰区域内的两个节点分配到不同时隙，满足无冲突传输调度的需求。

 上图中左侧的是TDMA调度下的时隙分配，右侧的是DRAND调度下的时隙分配，可以看出，在不同的干扰域，节点的传输不会相互影响，但是普通的TDMA调度要使用更多的时隙来进行分配，可能会导致资源的浪费，而DRAND调度则可以高效地分配时隙，能够节约资源并且降低时延。
 ③ 明确竞争通告（ECN：Explicit Contention Notification）：用于通知所有的两跳邻居，不要在此时隙内发送数据。

如果一个节点经历高强度竞争（可以通过丢失ACK检测），它将会发送ECN信息。
当一个节点接收到ECN消息后，它将设置HCL标志，表示当前处于高竞争级别场景。
当一个节点收到单跳节点I的ECN消息后，如果该节点处于节点I的路由路径上，它将转发一个两跳ECN消息，否则将丢弃接收的单跳ECN消息。



（注：图源自中国大学MOOC网中的无线传感网技术课程）