真的是閒 wrote:
那張英文的就是骨科給的報告，其實我告訴他的疼痛感是打七折的他覺得我像個沒事人的樣子很奇怪，說那再復健兩個月看看 如果不行 介紹了另外一位脊椎專科醫生。
今天看診的結果我跟正宮都鬆了一口氣
有一姐陪伴，
祝閒哥否極泰來，
閒伉儷永浴愛河。
時間差不多了，
閒哥晚安，
大家晚安，
終於發現了，已突破盲點．Ｃａｋｅ改回用預設值就行了．--
０２／０６晚上更正，預設值真的很好．封包經過Ｄ３後，不合理的都斷流，至於ＮＡＴ．
在封包經過Ｄ３之前，會先比對規則的ＮＡＴ確認實際位址再進行區隔管制，優缺點都有，
但Ｄ３架構完善，若開啟ｃａｋｅ－ｎａｔ會影響到Ｄ３斷流機制．連同Ｄ４也如此類推．
本來Ｄ３或Ｄ４不合理的斷流，在ｎａｔ比對情況下而改變了Ｄ３與Ｄ４的神奇魔法機制．
這點網軍不樂見也不喜歡，會影響牠們的詐騙行情，運用廣告釣魚與劫持阻斷的優勢沒了．
因為規則一改完後，過不到三分鐘，疑詐騙與騷擾電話就打來，我嘴角上揚，測試結束了．
就不需要改雙主機ｄｕａｌ－Ｄ或Ｓ．因沒開啟ＮＡＴ的情況下會影響電視正常收看ＹＴ．
交給預設值三重隔離作判斷就好，當封包進去後直接進入Ｄ３機制，然後再經過三重隔離，
最後在進行封包傳遞．若開ＮＡＴ的情況是，封包還沒進去先檢查隱蔽，符合就避開機制，
優點是迅速，缺點是本來機制該合理的斷流，因為ｎａｔ優先而避開Ｄ３Ｄ４的合理斷流，
這就是網軍可以利用的破口．若沒開啟ＮＡＴ的情況，完全遵循Ｄ３Ｄ４機制作區隔斷流，
當電視機收看ＹＴ時，封包先進入Ｄ３Ｄ４機制檢查，可以通過了，在沒開啟ＮＡＴ情況，
交給三重隔離作區隔，然而電視機就可以正常收看ＹＴ．若條件設雙主機，彼此之間區隔，
又沒開啟ＮＡＴ，導致無法找出實際位址作封包傳遞，這就是導致電視無法正常收看ＹＴ．
對了，真的別忘記Ｔｏｔａｌ，查完資料後，確定Ｔｏｔａｌ有必要加進，條件才能一致．
--
/queue type
add cake-bandwidth=100.0Mbps kind=cake name=cake-download
add cake-bandwidth=40.0Mbps kind=cake name=cake-upload
add kind=cake name=cake-total
/queue simple
# CAKE type with bandwidth setting detected, configure traffic limits within queue itself
add bucket-size=0.01/0.01 name=cake queue=cake-download/cake-upload \
target=pppoe-out1 total-queue=cake-total
呵呵呵呵呵呵呵．古柯鹼教母好看．雖說有點落漆，但依照以前的時空背景，情境合理．為啥會有落漆感，因為我完全用現在的情境去看過去，要是現在科技偵辦，條子沒這麼廢．
當我隨即用過去的情境去看這部片，合情合理，沒這麼落漆，但同樣的對事情要用對心態．
心態正確，對事情處理成分就不需要這麼類似於情緒勒索的低級，搞低級的人自然被淘汰．
就像看部描述數十年前歷史或未來未知的概念，前者是過來人所以知道過去，後者是抽象，
但不要失真，太過科幻，不管是看過去與未來，要用寫實與真實去看待，這樣就不需靠吹．
吹這種東西，就是一種老古板已是淘汰卻硬要在邊緣巴結，而靠這去不切實際拖別人掉坑．
--
ＣＡＫＥ的ＳｉｍｐｌｅＱｕｅｕｅｓ搞定後，接著花時間研究如何在Ｔｒｅｅ裡頭運作．
十一點時測試了半小時後可以在不開啟快速通道的情況下解限速，真心不推薦，到此為止．
--
CTI中天新聞24小時HD新聞直播 │ CTITV Taiwan News HD Live｜台湾のHDニュース放送｜ 대만 HD 뉴스 방송 【中天大直播】人品是做人最好的底牌．
內文搜尋
從 APP 打開
X