1，首先回顧一下TCP協議：
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。