关于ACL的established使用
TCP数据包中有六个标志位(Code Bits)：6 位标志域。表示为：紧急标志、有意义的应答标志、推、重置连接标志、同步序列号标志、完成发送数据标志。按照顺序排列是：URG、ACK、PSH、RST、SYN、FIN。在整个TCP数据传输过程中ACK位除了在第一次握手的时候置位为0外，其他任何时候都置位为1。
三次握手过程：
在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接。
第一次握手：建立连接时，客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；
第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。
2，再次拿一个ACL来举例说明（摘自TCP/IP路由技术 第一卷 第556页）：
假设你实现了一个访问列表可以阻止外部发起的TCP会话进入到你的网络中，但是你又想让内部发起的TCP会话的响应通过，那应该怎么办？通过检查TCP段头内的ACK和RST标记，关键字established可以实现这一点。如果这两个标记都没有被设置，表明源点正在向目标建立TCP连接，那么匹配不会发生。最终报文将会在访问列表中的后继行中被拒绝。示例如下：
access-list 110 permit tcp any 172.22.0.0 0.0.255.255 established
access-list 110 permit tcp any host 172.22.15.83 eq 25
access-list 110 permit tcp 10.0.0.0 0.255.255.255 172.22.114.0 0.0.255 eq 23
第1行：如果链接是从网络172.22.0.0发起的，那么允许从热和原电到该网络的TCP报文通过；
第2行：允许来自任意源点，且目标端口号是主机172.22.16.83的端口25的TCP报文通过；
第3行：允许来自网络10.0.0.0，去向网络172.22.114.0/24且目标端口为23的TCP报文通过。
通过上面的ACL，大家有没有注意过，一个从any到172.22.15.83的25端口的连接，TCP的三次握手，第一次握手肯定是需要匹配第2行ACL，因为此报文的标志位ACK置位为0，不能匹配第1行ACL。但是此会话的后面的所有数据报文都会匹配第1行了，因为此报文的标志ACK已经置位为1了。这里是否有问题，请相关牛人鉴定！
3，ACL对分片包的处理（摘自一英文技术宝典，经我翻译如下）：
当一IP包被分片时，仅在第一个分片中包含所有三层与四层信息，而后续分片则只包含三层信息，四层信息丢失。
ACL的处理机制：
对于permit ACEs：当第一分片被匹配上后，后续分片也会匹配上（不检查四层信息）；
对于deny ACEs：所有分片都要检查三、四层信息。实际上，对于deny ACEs，当第一分片被匹配上后被丢弃，而后续分片由于无四层信息则不能匹配该deny ACEs，可能在后面检查时允许通过，则传到目标地后，由于不能进行重组而被丢弃。但这样占用了带宽及目标主机的CPU。
综合以上，根据3，是否可以判定ACL的处理机制有点smart，它可以根据每条ACE条目记录某一个时段的匹配内容，匹配内容主要包括源和目标IP地址，甚至端口号（tcp条目），从而不会将流量报文匹配错。也就是说根据2说的同一会话的后续报文不会去匹配第1行ACL，而根据ACL的记录内容去匹配第2行ACL。
以上纯粹是我个人针对ACL的分析，有任何不对或者有争议之处，还请牛人指正，不胜感激！！！
本文出自 “Network Manage Tech Experience” 博客，请务必保留此出处http://ipneter.blog.51cto.com/341177/74361
