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。

轉載于:https://blog.51cto.com/ghostzyz/816401

總結

以上是生活随笔為你收集整理的established关键字的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。