OSI是一个开放性的通信系统互连参考模型，他是一个定义得非常好的协议规范。OSI模型有7层结构，每层都可以有几个子层。 OSI的7层从上到下分别是 7 应用层6 表示层 5 会话层 4 传输层3 网络层 2 数据链路层 1 物理层；其中高层（即7、6、5、4层）定义了应用程序的功能，下面3层（即3、2、1层）主要面向通过网络的端到端的数据流。应用层与其它计算机进行通讯的一个应用，它是对应应用程序的通信服务的。例如，一个没有通信功能的字处理程序就不能执行通信的代码，从事字处理工作的程序员也不关心OSI的第7层。但是，如果添加了一个传输文件的选项，那么字处理器的程序员就需要实现OSI的第7层。示例：TELNET，HTTP，FTP，NFS，SMTP等。
应用层
与其它计算机进行通讯的一个应用，它是对应应用程序的通信服务的。例如，一个没有通信功能的字处理程序就不能执行通信的代码，从事字处理工作的程序员也不关心OSI的第7层。但是，如果添加了一个传输文件的选项，那么字处理器的程序就需要实现OSI的第7层。示例：TELNET，HTTP，FTP，NFS，SMTP等。
表示层
这一层的主要功能是定义数据格式及加密。例如，FTP允许你选择以二进制或ASCII格式传输。如果选择二进制，那么发送方和接收方不改变文件的内容。如果选择ASCII格式，发送方将把文本从发送方的字符集转换成标准的ASCII后发送数据。在接收方将标准的ASCII转换成接收方计算机的字符集。示例：加密，ASCII等。
会话层
它定义了如何开始、控制和结束一个会话，包括对多个双向消息的控制和管理，以便在只完成连续消息的一部分时可以通知应用，从而使表示层看到的数据是连续的，在某些情况下，如果表示层收到了所有的数据，则用数据代表表示层。示例：RPC，SQL等。
传输层这层的功能包括是否选择差错恢复协议还是无差错恢复协议，及在同一主机上对不同应用的数据流的输入进行复用，还包括对收到的顺序不对的数据包的重新排序功能。示例：TCP，UDP，SPX。
网络层
这层对端到端的包传输进行定义，它定义了能够标识所有结点的逻辑地址，还定义了路由实现的方式和学习的方式。为了适应最大传输单元长度小于包长度的传输介质，网络层还定义了如何将一个包分解成更小的包的分段方法。示例：IP，IPX等。
数据链路层
它定义了在单个链路上如何传输数据。这些协议与被讨论的各种介质有关。示例：ATM，FDDI等。
物理层OSI的物理层规范是有关传输介质的特性标准，这些规范通常也参考了其他组织制定的标准。连接头、帧、帧的使用、电流、编码及光调制等都属于各种物理层规范中的内容。物理层常用多个规范完成对所有细节的定义。
网络层攻击
Syn-flood
利用TCP建立连接时3次握手的“漏洞”，通过原始套接字发送源地址虚假的SYN报文，使目标主机永远无法完成3次握手，占满了系统的协议栈队列，资源得不到释放，进而拒绝服务，是互联网中最主要的DDOS攻击形式之一。
网上有一些加固的方法，例如调整内核参数的方法，可以减少等待及重试，加速资源释放，在小流量syn-flood的情况下可以缓解，但流量稍大时完全不抵用。防御syn-flood的常见方法有：syn proxy、syn cookies、首包(第一次请求的syn包)丢弃等。
ACK-flood
对于虚假的ACK包，目标设备会直接回复RST包丢弃连接，所以伤害值远不如syn-flood。DDOS的一种原始方式。
UDP-flood
使用原始套接字伪造大量虚假源地址的UDP包，目前以DNS协议为主。
ICMP-flood
Ping洪水，比较古老的方式。
应用层攻击
CC
ChallengeCollapsar的名字源于挑战国内知名安全厂商绿盟的抗DDOS设备-“黑洞”，通过botnet的傀儡主机或寻找匿名代{过}{滤}理服务器，向目标发起大量真实的http请求，最终消耗掉大量的并发资源，拖慢整个网站甚至彻底拒绝服务。
互联网的架构追求扩展性本质上是为了提高并发能力，各种SQL性能优化措施：消除慢查询、分表分库、索引、优化数据结构、限制搜索频率等本质都是为了解决资源消耗，而CC大有反其道而行之的意味，占满服务器并发连接数，尽可能使请求避开缓存而直接读数据库，读数据库要找最消耗资源的查询，最好无法利用索引，每个查询都全表扫描，这样就能用最小的攻击资源起到最大的拒绝服务效果。
互联网产品和服务依靠数据分析来驱动改进和持续运营，所以除了前端的APP、中间件和数据库这类OLTP系统，后面还有OLAP，从日志收集，存储到数据处理和分析的大数据平台，当CC攻击发生时，不仅OLTP的部分受到了影响，实际上CC会产生大量日志，直接会对后面的OLAP产生影响，影响包括两个层面，一个当日的数据统计完全是错误的。第二个层面因CC期间访问日志剧增也会加大后端数据处理的负担。
DDOS攻击本质上是一种只能缓解而不能完全防御的攻击，它不像漏洞那样打个补丁解决了就是解决了，DDOS就算购买和部署了当前市场上比较有竞争力的防御解决方案也完全谈不上彻底根治。防火墙、IPS、WAF这些安全产品都号称自己有一定的抗DDOS能力，而实际上他们只针对小流量下，应用层的攻击比较有效，对于稍大流量的DDOS攻击则无济于事。
以2015年年中的情况为例，国内的DDOS攻击在一个月内攻击流量达到300G的就将近10-20次，这个数值将随着国内家庭宽带网速提升而进一步放大。对于200~500G的攻击流量该如何防御，下来将展示完整的防御结构，通常可以分为4层。
这4层不是严格意义上的纵深防御关系，也不是在所有的防御中4层都会参与，可能有时候只是其中的2层参与防御。但对于超大流量攻击而言，4层就是防御机制的全部，再没有其他手段了。跟厂商们的市场宣传可能有所不同，大流量攻击的防护并不是像某些厂商宣称的那样靠厂商单方面就能解决的，而是多层共同参与防御的结果。
ISP/WAN层
这一层通常对最终用户不可见，如果只是中小企业，那这一层可能真的不会接触到。但如果是大型互联网公司，公有云厂商，甚至是云清洗厂商，这层是必不可少的。因为当流量超过自己能处理的极限时必须要借助电信运营商的能力。大型互联网公司虽然自身储备的带宽比较大，但还没到达轻松抵抗大流量DDOS的程度，毕竟带宽是所有IDC成本中最贵的资源没有之一。目前无论是云计算厂商，大型互联网公司向外宣称的成功抵御200G以上攻击的新闻背后都用到了运营商的抗D能力，另外像第三方的云清洗平台他们实际上或多或少的依赖电信运营商，如果只依靠本身的清洗能力，都是非常有限的。
相比之下，对攻击流量的牵引，清洗，回注的防御方式对用户体验的挑战没那么大，但是跟黑洞路由比防御方的成本比较高，且触发到响应的延时较大。
在运营商防御这一层的主要的参与者是大型互联网公司，公有云厂商，云清洗厂商，其最大的意义在于应对超过自身带宽储备和自身DDOS防御能力之外的超大攻击流量时作为补充性的缓解措施。
CDN/Internet层
CDN并不是一种抗DDOS的产品，但对于web类服务而言，他却正好有一定的抗DDOS能力，以大型电商的抢购为例，这个访问量非常大，从很多指标上看不亚于DDOS的CC，而在平台侧实际上在CDN层面用验证码过滤了绝大多数请求，最后到达数据库的请求只占整体请求量的很小一部分。
对http CC类型的DDOS，不会直接到源站，CDN会先通过自身的带宽硬抗，抗不了的或者穿透CDN的动态请求会到源站，如果源站前端的抗DDOS能力或者源站前的带宽比较有限，就会被彻底DDOS。
云清洗厂商提出的策略是，预先设置好网站的CNAME，将域名指向云清洗厂商的DNS服务器，在一般情况下，云清洗厂商的DNS仍将穿透CDN的回源的请求指向源站，在检测到攻击发生时，域名指向自己的清洗集群，然后再将清洗后的流量回源。
检测方式主要是在客户网站前部署反向代{过}{滤}理(nginx)，托管所有的并发连接。在对攻击流量进行分流的时候，准备好一个域名到IP的地址池，当IP被攻击时封禁并启用地址池中的下一个IP，如此往复。
网上很多使用此类抗D服务的过程可以概括为一句话：更改CNAME指向，等待DNS递归生效。
DC层
Datacenter这一层的DDOS防御属于近目的清洗，就是在DC出口的地方部署ADS设备。
OS/APP层
这是DDOS的最后一道防线。这一层的意义主要在于漏过ADS设备的流量做最后一次过滤和缓解，对ADS防护不了的应用层协议做补充防护。比如NTP反射，可以通过服务器配置禁用monlist，如果不提供基于UDP的服务，可以在边界上直接阻断UDP协议。
互联网在线服务中最大的比重就是web服务，因此有些互联网公司喜欢自己在系统层面去做应用层的DDOS防护，例如对抗CC，有时这些功能也能顺带关联到业务安全上
閱讀更多 小蟻雲防 的文章
