母親從海南島回小山村之後，一直自覺後腦頭痛，自己量了血壓發現偏高，於是跑去醫院查了一下，拍了兩張片，說是大腦供血不足，輕度腦萎縮，頸椎退行性病變，醫生給她開了降壓藥，她為了儘量少去醫院，讓醫生多開一些時間的藥，醫生也許誤解了她的意思，於是給她開了二十天一共三種降壓藥，在服藥五天之後，她出現了明顯的胃腸道症狀和乏力，當然一些症狀是降壓藥的副作用，在一個早上她嘔吐不止，心慌氣短，打電話叫來親戚把她攙扶著送去了醫院。
今天已經是住院的第二天，醫生沒有明確的結論，告訴她也許是胃腸道間質瘤轉移到大腦了，母親一臉的懷疑，認為小山村的醫院檢查不出來什麼，說舅舅讓她好一點之後去市區檢查，但我從家裡的監控上看來，雖然她中午和幺姥回來拿東西的時候坐在沙發上就不想動，和我講電話也有點沒力氣，但是她拿東西一陣叮鈴哐啷的陣勢我感覺她還好。
我查閱了一下資料，似乎腦轉移的案例沒有，但是這也許是因為研究樣本不足導致的，因為這個腫瘤大多數都做了手術切除，對於不能切除的腫瘤，研究成果並不多。
撰寫老漢葬禮致詞的時候，母親說老漢個啥子，父親嘛。但我從小就喊的是老漢，叫父親反而自覺顯得生分。
“Three months ago, this attack came from Taiwan. We need to be honest. I will be straight today. From Taiwan,” he said. “And Taiwan, the Foreign Ministry also, they know the campaign. They didn’t disassociate themselves. They even started criticizing me in the middle of all that insult and slur, but I didn’t care.”
譚書記這個性格很玻璃心啊，這種性格，也怪不得會很容易就被中國收買，但此番言論並不是無中生有的，因為川普前一天聲稱要對世界衛生組織斷糧，譚書記如果不出來做一番解釋，恐怕很難給世界衛生組織的專家們一個交代，所以他不得不出面來推卸自己的責任，但是他又是一個很圓滑的人，把責任推給台灣，世界衛生組織的成員國，一個都不必得罪。
三個月前的台灣在大選根本沒有人關注譚書記好嗎，三個月前世界衛生組織還在那遮遮掩掩，欲說還羞的樣子，三個月前的現在美國人都還沒從武漢撤離，請問台灣是要攻擊你什麼？
世界衛生組織原本是一個由醫生們組成的專業組織，但現在看來，已經被腐蝕得七七八八，其實這也未嘗不是好事，這會促進多邊政治的解體，多邊政治看起來就像是和稀泥，但意識形態的對峙和戰爭卻未必會到來，因為中國現在奉行的並沒有什麼固定的主義，既不是社會主義，也不是共產主義，或是民族主義，而是在不斷的修訂過程中，姑且稱之為修正主義。
原本BBC停播之後，我以為VOA也會跟著停播的，畢竟聽的人越來越少，關鍵是真實的聽眾數量無法進行統計，也就無法對下一年的預算做出規劃，今天偶然發現VOA的頻率居然還在廣播，於是找出收音機，從VOA的頻率上，傳來了清晰而又明亮數十年如一日的中央人民廣播電台。
電磁波這種東西，只要頻率一樣就可以進行干擾，考場無法使用手機就是這樣子的原理，因為考場部署了和手機基地台相同頻率的干擾設備，你的手機會根據距離的遠近，優先選擇連結到干擾設備，而不會去連結正確的基地台，短波廣播的干擾原理類似，中央人民廣播電台數十年如一日的將自己的廣播頻率設置在BBC和VOA相同的頻率，目的就是干擾短波收音機的接收，不讓民眾聽到他們的聲音，從物理距離來說中央人民廣播電台離我更近，VOA在日本的短波轉播站即使覆蓋到南方，信號強度也沒有辦法和財大氣粗的中央人民廣播電台相比。
上次把Macmini的普通硬碟換成了SSD，拆過一次Fusion Drive，但是沒有把PCI-SSD和SSD做Fusion Drive，我以為128G的PCI硬碟，裝個系統什麼的，應該是夠了，但是我估計錯誤，PCI硬碟很快就裝滿到了120G，根據SSD的特性，是不能把他裝得太滿，再裝多一些，我估計這塊硬碟會掛點，所以我不得不重建了一次Fusion Drive。
首先當然是備份，最好的備份方式，就是開啟Time Machine，用外置硬碟或者支持TimeMachine的網路存儲都沒問題，我這次使用的是我網路存儲上的備份，網路存儲備份的好處在於，你不用去管他什麼時候為你備份，一切都是自動的。
當備份完成之後，我們就可以來進行磁碟重新分區的操作，從菜單重啓電腦，然後按住cmd+R，直到被咬過一口的白蘋果出現，當出現選擇菜單時，不要選擇任何一個。而是選擇最上面的終端Terminal，進入命令行介面，在terminal窗口中輸入diskutil resetFusion，然後按回車鍵。
這時候，提示有兩塊硬碟，並且兩塊都是SSD， this is nonstandard but OK. 接下來我們輸入Yes，注意Y要大寫，就會開始對兩塊硬碟進行初始化分區，創建分區表的操作。注意！注意！注意！TimeMachine只會備份操作系統所在的那塊硬碟，如果你的第二塊硬碟上有數據，則需要手動備份，由於我的第二塊硬碟上沒有什麼重要的數據，這裏就沒有進行備份操作，當你確認後，你的兩塊硬碟都會被重新分區。
創建FusionDrive的速度很快，大概一兩分鐘就好了，you should now install macOS.
這裏可以選擇全新安裝，全新安裝的話，可以透過網路，下載最新的macOS鏡像，然後解壓縮，安裝，也可以透過外置硬碟或是網路存儲的TimeMachine備份來進行恢復，這裏我選擇Restore from Time Machine Backup。
繼續三兩個提示之後，選擇一下備份恢復的來源，這裏我選擇網路存儲，如果存儲是需要驗證的，那麼下一步會彈出對話框讓你鍵入用戶名和密碼，
很顯然，在網路存儲上我們不止存放有一個備份副本，在不同的時間段，當你修改了文檔，移動了目錄，安裝了新的application，都會形成一個新的備份副本，這裏我選擇最近一次備份。
選擇確認後，會彈出最後一個對話框，是否要erase disk，為什麼會有這個提示？我之前不是已經對硬碟重新分區了嗎？是的，但是程式並不知道啊，恢復備份在很多場景下都會發生，並不是只有這一個場景，當你的系統在正常運行，需要找回被誤刪的文檔時，這個提示就非常有必要了。
接下來是比較漫長的恢復過程，90G的數據大概恢復了兩個小時，我應該把Wi-Fi斷開直接用有線網路傳輸也許會比較快。
當恢復完成，電腦重啓後，熟悉的桌面和設置都還在那，一如既往，Application目錄裡面的app，會自動重新下載，和iPhone非常類似，當app重新下載完成後，就可以開始使用啦。
可以看到，現在系統中只有一塊硬碟叫做Fusion Drive，從實際使用來看，第一次被copy或者move到這塊融合硬碟上的文件，會默認被放在速度較慢的2.5英寸SSD上，當你頻繁的打開它，或是你的程式頻繁的調用它，它才會被移到速度較快的PCI-SSD上去。
因為疫情，第一次用騰訊會議的時候，我覺得這個還挺好用的，簡便快捷，創意也不錯，萬萬沒想到啊，騰訊這個抄襲的習慣，這個還是抄襲的，抄的誰呢？抄的Zoom。
抄襲這個事情很難說對和錯，涉及到商業利益的時候，只是看誰更有權力壓得住對方而已，騰訊會議的功能設置和Zoom幾乎是一模一樣，唯一的區別是Zoom早就開始收費，而騰訊會議目前一直是免費提供。
點到點的視頻或是語音並不新奇，各類軟體層出不窮，FaceTime，Skype，Google Duo，但這些軟體都是基於帳號，想要使用他們，首先你需要下載他們的app，
然後你必須要註冊一個他們的帳號。但會議app則不是這樣的使用流程，你只需要下載一個app，甚至不需要下載那麼多，只下載一個瀏覽器plugin，然後你輸入一串字符，你就可以參加會議了，不需要為了註冊而填寫繁瑣的個資，會議app最核心的一點就是，讓你快速的加入會議，進行討論，如果因為需要註冊或是經由其他的手續，造成你參加會議的障礙，那就應該把這道手續從核心需求中剔除。
但江湖傳言Zoom也是創始人從Cisco WebEX出走之後創立的，Cisco這間公司吧，搞出來這種事情好幾次了，比如obihai，也是個傳奇故事，因為開發VOIP被Cisco收購了兩次，只要能適當的規避知識產權和法律程序上的陷阱，像Zoom這樣的公司應該還有不少，但為什麼Zoom能夠成功壯大？
因為創始人是來自中國的移民，而他把主要的研發中心放在了中國，和矽谷相比之下極為低廉的人力成本讓這間公司在疫情期間因逐漸增多的會議需求而迅速变成热门，之所以引起爭議，是因為Zoom在對將那些在美國，加拿大進行的會議加密時，沒有使用標準的加密算法，而是使用了自己開發的加密算法，這一點，首先也許是基於效率的考慮，但這種設計，重點不在於Zoom可以隨意解密用戶的會議內容，而在於Zoom自己開發的加密算法，並沒有經過不同場景大規模應用的驗證，很可能存在漏洞而導致用戶的會議內容被第三方解密。
所以SpaceX在3月底以事關「重大隱私和安全問題」為由，禁止其員工使用Zoom作為通訊工具，美國國家航空暨太空總署（NASA）也表示，禁止員工使用Zoom。
如果僅僅是可能存在的加密解密漏洞，何以有如此劇烈的反應，原來是因為Zoom將所有的會議密鑰發送到了位於中國的伺服器，這個設計初衷也許是為了統計，也許是為了其他的計算需求，單純講有陰謀有些言過其實，但這一點設計我很不理解，即使是Zoom的Client/Server設計中，將大部分功能設計到Client端，它也完全可以將會議密鑰先發送到位於美國的Zoom伺服器（中繼器或是廣播伺服器），然後再從美國的伺服器發送給中國的伺服器，它為什麼要把密鑰直接從Client發送到中國的伺服器呢？
可能性一：Zoom一開始並沒有想要傳輸會議密鑰，也沒有想要解密用戶數據，因為Zoom的收費模式是按時間和人頭數量計算的，而不是按用戶使用的數據量大小，無論從哪一個維度看，都不需要解密用戶數據，這是一個臨時加上去的功能，至於為什麼要臨時加上去，肯定是出於某種目的，目的是什麼，不得而知。
可能性二：Zoom的互聯網項目是實驗性質的，創始人的解釋也是如此，在美國，Zoom試圖複製WebEX的銷售模式，向大型企業推銷在企業內部部署的伺服器，而不是廣泛的在互聯網上進行會議，針對大型企業的設計而言，需要知道會議內容是一個必然的需求，方便的解密是一個很好的技術實現。
Google Duo的局限性在於，它每次最多只能邀請12個人進入討論，這和Zoom提供的免費版100個人限制相去甚遠，Skype的人頭限制雖然是250個人，但是Skype需要註冊，沒有便捷的參與渠道，最根本的是上面兩者都沒有會議相關的功能，比如禁止參與者發聲。市面上幾乎沒有和Zoom相同的軟體進行競爭，這是疫情期間他可以爆紅的原因，但隨著疫情趨緩，他逐漸回歸到企業客戶也不是什麼難以預料的事情。
看起來像Zoom不走企業客戶賺錢的模式只能是在中國這樣的地方，但問題的關鍵在於，中國這種愛開會的國家，不會喜歡在線上開會的。
網路上各類針對WordPress的攻擊很多，比較討厭的是來自於各大主機商的訪問，比如Digitalocean，OVH，Linode，Aliyun，但是，運行在這些主機商伺服器上的業務，通常和我們的網站並沒有什麼必需的聯繫，所以我們完全可以把他們都封鎖掉。
封鎖他們的IP有很多種方式，最簡單的方式，就是通過CDN的訪問控制列表，在CDN上設置黑名單，然後你可以在Apache或者Nginx設置你的網站只允許CDN的IP訪問，這是你自己的白名單，這就可以確保你的網站不會被其他IP地址訪問，問題是，如果你有多個網站運行在同一個IP地址上，而你又不能為你所有的網站設置同樣的CDN或者同樣的訪問規則時，這個方法就變得不適用。
第二種方式，你可以在Apache或者Nginx設置你的網站禁止特定IP訪問，無論是通過CDN送過來的IP還是直接訪問，均可以達到封鎖效果，問題是，這種方法需要消耗webserver軟體的性能，而且通常都會消耗掉不少的性能，有沒有更好一點的辦法呢？
第三種方式，使用服務器上的防火牆，或者使用VPC防火牆，當你擁有一個數十台服務器的網絡時，你是必然會使用VPC的，否則安全管理會變得非常繁瑣，使用VPC的防火牆，在各大主機商是非常簡單的事情，點擊兩三下，輸入要封鎖的IP地址範圍，就可以了。
那麼，如果我們想使用操作系統的防火牆呢？比如FreeBSD下的PF。
PF是一個久負盛名的軟體，來自於OpenBSD的packet filter，比較有名的應用大概就是pfsense，有商業化運營的硬體產品出售，但由開源軟體發展而來的商業軟體，在性能上和Juniper，Cisco比起來還是差了一大截，如果有硬體防火牆可用，當然優先的選擇是硬體防火牆。在FreeBSD上其實是有很多的防火牆軟體可以選擇，以前我常用ipfw，他的配置是一行一行按順序執行，很多次我都因為寫錯了某個地方然後就把自己鎖在了伺服器的外面，PF好像至今尚未出現過這樣的情形。
一個典型的PF配置如下：
if=”eth0″
icmp_types = “echoreq”
open_tcp = “{ 80,443}”
open_udp = “{ 53}”set block-policy drop
set skip on lo0
set limit { states 10000, frags 5000 }
set loginterface eth0
set optimization normal
set require-order yes
set fingerprints “/etc/pf.os”
set ruleset-optimization basictable persist file “/etc/pf.blocked.ip.conf”
scrub in all
block drop in log (all) quick on $if from to any
block log all
block in all
block return allantispoof quick for $if
pass in on $if proto tcp from any to any port $open_tcp keep state
pass in on $if proto udp from any to any port $open_udp keep statepass out quick all keep state
pass in on $if inet proto icmp all icmp-type $icmp_types keep state
其中，涉及到封鎖IP地址的有兩行配置：
table persist file “/etc/pf.blocked.ip.conf”
block drop in log (all) quick on $if from to any
第一行是定義一個object叫做blockedips，他的文檔類型是一個conf配置文檔。
第二行則是拒絕這個配置文檔中所有的IP地址訪問$if這張網路卡。
那麼這個conf文檔的配置格式為何呢？按照標準的IP地址格式就可以了，我把一些常見的惡意IP地址範圍都加了進去，主要是上面提到的主機商，很多黑客和惡意程式利用這些主機商來進行掃描和攻擊。
#Aliyun
8.208.0.0/16
39.105.0.0/16
47.91.0.0/16
47.111.0.0/16
47.112.0.0/16
123.56.0.0/16
123.57.0.0/16
161.117.0.0/16
182.92.0.0/16#Digitalocean
45.55.0.0/16
68.183.0.0/16
104.248.0.0/16
128.199.0.0/16
138.68.0.0/16
138.197.0.0/16
139.59.0.0/16
142.93.0.0/16
146.185.0.0/16
142.93.0.0/16
146.185.0.0/16
157.230.0.0/16
157.245.0.0/16
159.65.0.0/16
159.89.0.0/16
165.22.0.0/16
165.227.0.0/16
167.172.0.0/16
178.62.0.0/16
178.128.0.0/16
178.186.0.0/16
188.166.0.0/16
185.85.0.0/16
185.86.0.0/16
190.202.0.0/16
206.189.0.0/16
217.182.0.0/16OVH
5.135.0.0/16
51.38.0.0/16
51.68.0.0/16
51.83.0.0/16
51.254.0.0/16
54.36.0.0/16
54.37.0.0/16
91.121.0.0/16
137.74.0.0/16
144.217.0.0/16
147.135.0.0/16
158.69.0.0/16
192.99.0.0/16
213.32.0.0/16Linode
172.104.0.0/16
Huawei 華為雲
114.119.0.0/16
Taobao 淘寶一搜
42.120.0.0/16
我一般都是直接封鎖B類地址範圍，Digitalocean的IP地址實在是太多了。
其實原本還有很多中國的二三流搜索引擎，每天不停的惡意抓取，比如今日頭條，但是，由於中國從來都不按照國際規範分配IP地址，很多時候使用whois檢出的IP地址都只能劃歸到某一個省份，而不是某一個城市，甚至公司，這樣你就很難去把他封鎖掉，只能一個C類地址範圍加進去試試看。
當然，在rc.conf中，我們應該預先定義好log的路徑和名稱，如下，我定義了一個pflog，放在/data/log目錄中：
pf_enable=”YES”
pf_rules=”/etc/pf.conf”
pflog_enable=”YES”
pflog_logfile=”/data/log/pflog”
那麼，如何讀取這個日誌文檔呢？因為他並不是一個純文本文檔，我們不能用vi或者cat或者tail來閱讀他，我們必須使用tcpdump來查看這個日誌文件，查看的命令行格式如下：
tcpdump -n -e -ttt -r /data/log/pflog
執行之後，可以得到如下類似的輸出結果，這個輸出中，我的服務器IP地址是116.128.134.139：
tcpdump -n -e -ttt -r /data/log/pflog
reading from file /data/log/pflog, link-type PFLOG (OpenBSD pflog file)
00:00:00.000000 rule 2/0(match): block in on eth0: 178.62.41.44 > 116.128.134.139: ICMP echo request, id 4282, seq 980, length 16
01:38:36.513282 rule 2/0(match): block in on eth0: 217.182.193.13.56093 > 116.128.134.139.1500: Flags [S], seq 3677707474, win 1024, options [mss 536], length 0
00:38:42.059567 rule 2/0(match): block in on eth0: 178.62.41.44 > 116.128.134.139: ICMP echo request, id 5933, seq 3298, length 16
00:00:04.451304 rule 2/0(match): block in on eth0: 178.62.80.93 > 116.128.134.139: ICMP echo request, id 9026, seq 345, length 16
01:16:14.250758 rule 2/0(match): block in on eth0: 178.62.106.84 > 116.128.134.139: ICMP echo request, id 5864, seq 1941, length 16
00:15:17.692806 rule 2/0(match): block in on eth0: 178.62.78.199 > 116.128.134.139: ICMP echo request, id 30618, seq 1686, length 16
05:04:34.023956 rule 2/0(match): block in on eth0: 178.62.78.199 > 116.128.134.139: ICMP echo request, id 3055, seq 465, length 16
00:20:23.179962 rule 2/0(match): block in on eth0: 178.62.106.84 > 116.128.134.139: ICMP echo request, id 11035, seq 2333, length 16
00:15:19.427828 rule 2/0(match): block in on eth0: 178.62.80.93 > 116.128.134.139: ICMP echo request, id 17857, seq 577, length 16
01:06:00.483685 rule 2/0(match): block in on eth0: 178.62.109.7 > 116.128.134.139: ICMP echo request, id 10094, seq 4315, length 16
00:10:12.073875 rule 2/0(match): block in on eth0: 178.62.41.44 > 116.128.134.139: ICMP echo request, id 14083, seq 420, length 16
00:55:54.286830 rule 2/0(match): block in on eth0: 178.62.78.199 > 116.128.134.139: ICMP echo request, id 6287, seq 2726, length 16
00:10:15.098226 rule 2/0(match): block in on eth0: 178.62.41.44 > 116.128.134.139: ICMP echo request, id 15544, seq 4722, length 16
00:15:24.539292 rule 2/0(match): block in on eth0: 178.62.109.7 > 116.128.134.139: ICMP echo request, id 13960, seq 3050, length 16
可以觀察到，這些惡意bots在發送spam之前，會使用多個不同的主機先ping一下看是否通暢，然後再發起惡意訪問，比如來自Digitalocean的178.62.0.0/16和138.197.0.0/16，就有很多的記錄，這些請求都被PF block掉了，不會到達webserver或是其他地方，甚至還有針對445端口進行掃描的Windows病毒蠕蟲。
如果我們想要查看實時的日誌顯示，那麼我們可以用pflog0這個虛擬網卡，執行如下的命令行可以得到輸出，你看很快的，就進來了一條記錄：
tcpdump -n -e -ttt -i pflog0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 262144 bytes
00:00:00.000000 rule 2/0(match): block in on eth0: 138.197.130.235 > 116.128.134.139: ICMP echo request, id 19068, seq 6044, length 16
如果我們只希望查看某些IP地址或端口的記錄，應當如何使用呢？由於pflog使用的是tcpdump的二進制文檔格式，那麼tcpdump的任何命令都是適用的，幾個樣例如下：
查看80端口的記錄：
tcpdump -n -e -ttt -r /data/log/pflog port 80
查看特定IP地址和端口的記錄：
tcpdump -n -e -ttt -r /data/log/pflog port 80 and host 192.168.1.3
你也可以把它套用到pflog0上：
tcpdump -n -e -ttt -i pflog0 host 192.168.4.2
甚至可以使用更複雜的命令來過濾，和硬體防火牆比起來， 操作略為複雜一些。
tcpdump -n -e -ttt -i pflog0 inbound and action block and on eth0
一些提示：
ip – address family is IPv4.
ip6 – address family is IPv6.
on int – packet passed through the interface int.
ifname int – same as on int.
ruleset name – the ruleset/anchor that the packet was matched in.
rulenum num – the filter rule that the packet matched was rule number num.
action act – the action taken on the packet. Possible actions are pass and block.
reason res – the reason that action was taken. Possible reasons are match, bad-offset, fragment, short, normalize, memory, bad-timestamp, congestion, ip-option, proto-cksum, state-mismatch, state-insert, state-limit, src-limit and synproxy.
inbound – packet was inbound.
outbound – packet was outbound.
顯示防火牆當前的連結，也是一個常用的命令，如何使用呢？我們需要額外安裝一個pftop軟體，然後執行它。
pkg install pftop
pftop
pfTop: Up State 1-26/26, View: default, Order: none, Cache: 10000 6:33:52
PR DIR SRC DEST STATE AGE EXP PKTS BYTES
tcp In 108.162.215.39:38588 116.128.134.139:80 FIN_WAIT_2:FIN_WAIT_2 00:03:23 00:00:07 15 1576
tcp In 108.162.215.127:20290 116.128.134.139:80 FIN_WAIT_2:FIN_WAIT_2 00:02:29 00:01:01 15 1447
tcp In 108.162.215.39:56092 116.128.134.139:80 TIME_WAIT:TIME_WAIT 00:02:23 00:01:07 17 2429
tcp In 172.69.33.38:28072 116.128.134.139:80 ESTABLISHED:ESTABLISHED 00:01:30 23:59:46 10 1584
tcp In 108.162.215.39:39160 116.128.134.139:80 ESTABLISHED:ESTABLISHED 00:01:23 23:59:37 10 1376
tcp In 108.162.215.203:26782 116.128.134.139:80 ESTABLISHED:ESTABLISHED 00:01:21 23:59:40 10 1234
pftop的這個輸出信息量其實並不大，甚至還不如iftop顯示的數據量多，但區別在於，pftop可以顯示出連結的狀態，連結處於CLOSED，ESTABLISHED，還是WAIT的狀態，當遭遇到攻擊的時候，半開連結作為判斷因素有那麼一點點的作用。
對比一下Juniper SSG的輸出：
ssg5-> get session | inc /80
id 10597/s,vsys 0,flag 00000000/8000/1001/0000,policy 1,time 30, dip 2 module 0, di on if 11(nspflag 801a01):10.1.1.5/59689->54.39.179.91/8080,6,000c2997db20,sess token 3,vlan 0,tun 0,vsd 0,route 3,wsf 7 if 0(nspflag 10003a00):10.70.5.12/1427<-54.39.179.91/8080,6,000000000000,sess token 4,vlan 0,tun 0,vsd 0,route 11,wsf 6 id 10627/s,vsys 0,flag 00000000/8000/1001/0000,policy 1,time 30, dip 2 module 0, di on
if 11(nspflag 801a01):10.1.1.105/51382->203.208.39.215/80,6,546009783576,sess token 3,vlan 0,tun 0,vsd 0,route 3,wsf 8
if 0(nspflag 10003a00):10.70.5.12/3892<-203.208.39.215/80,6,000000000000,sess token 4,vlan 0,tun 0,vsd 0,route 11,wsf 6 id 10972/s,vsys 0,flag 00000000/8000/1001/0000,policy 1,time 26, dip 2 module 0, di on if 11(nspflag 801a01):10.1.1.138/49773->223.166.152.106/80,6,a860b62b6556,sess token 3,vlan 0,tun 0,vsd 0,route 3,wsf 7 if 0(nspflag 10003a00):10.70.5.12/3626<-223.166.152.106/80,6,000000000000,sess token 4,vlan 0,tun 0,vsd 0,route 11,wsf 6 id 11108/s,vsys 0,flag 00000000/8000/1001/0000,policy 1,time 23, dip 2 module 0, di on if 11(nspflag 801a01):10.1.1.138/53973->116.128.160.96/8080,6,a860b62b6556,sess token 3,vlan 0,tun 0,vsd 0,route 3,wsf 8
對比一下Cisco ASA的輸出：
F5ASA# sh conn | inc :80
TCP outside 114.247.184.134:53018 inside 172.30.1.121:80, idle 0:09:20, bytes 0, flags UfB
TCP outside 123.54.116.24:59970 inside 172.30.1.121:80, idle 0:16:06, bytes 0, flags UfB
TCP outside 112.44.42.1:1193 inside 172.30.1.121:80, idle 0:16:10, bytes 0, flags UfB
TCP outside 111.44.151.170:11348 inside 172.30.1.121:80, idle 0:36:34, bytes 0, flags UfB
TCP outside 123.54.116.24:59480 inside 172.30.1.121:80, idle 0:42:03, bytes 0, flags UfB
TCP outside 112.32.196.89:8609 inside 172.30.1.121:80, idle 0:56:14, bytes 0, flags UfB
TCP outside 117.157.99.170:60380 inside 172.30.1.165:80, idle 0:00:02, bytes 7330, flags UIOB
TCP outside 117.157.99.170:60379 inside 172.30.1.165:80, idle 0:00:02, bytes 7330, flags UIOB
TCP outside 117.147.16.83:12041 inside 172.30.1.165:80, idle 0:00:00, bytes 30381, flags UIOB
TCP outside 112.39.103.179:26126 inside 172.30.1.165:80, idle 0:00:03, bytes 6025, flags UIOB
TCP outside 113.233.207.78:62067 inside 172.30.1.165:80, idle 0:00:03, bytes 81796, flags UIOB
