@hlz0812 HKIX 是要交錢沒錯，但價錢一定比 Private peering/Transit 的低
價錢表是公開的: http://www.hkix.net/hkix/Charge/ChargeTable.htm
比任何一間 ISP 都要便宜吧?

當然沒免費的划算，但問題是有免費的嗎? HKIX 只收取基本的設備維持費用，開始的時候更是免費的，任何人接進去只要負責專線及路由設備的費用，到現在改成了自負盈虧也只按收費表計價。接入方法可以是跟 FTSN 租光訊道，也可以租 Layer 2 通道接進去。

其實 CN2 這麼久才直連 HKIX，要不是需求不大，就是以前成本沒在管都依賴 Peering 穿到 HKIX 去。

樓主都調好了優先序, 路由表就不用 delete route 再 add default route 了, 直接把公司內網的 IP 段指到 LAN gateway 去, 路由表的規則是小 subnet 比大 subnet 甚至 default route 都要優先

@akw2312 我以為你在罵 ChinaNet 及 169....CMCC 在 HKIX 的 route 挺多的吧，但絕大部分是自己 AS 的，transit 的沒研究

先觀看吧, participant list 上還沒有 AS4809, 也沒有公告說 AS4809 接到 HKIX, 應該沒準備好
http://www.hkix.net/hkix/participant.htm

現時 AS4809 (CN2) 接入 HKIX 還是主要經過 AS9304(HGC)/AS4637(Telstra Global)來 transit
https://www.hkix.net/hkix/hkixlg.htm


不過, 123.255.91.150 的 rDNS 是 chinatelecomglobal1-10g.hkix.net , 這顯示了應該會用 CTG 的名義接 HKIX 吧, 但 rDNS 沒有 lacp, 也沒有 chinatelecomglobal2-10g.hkix.net , 看來就只有 10G 的容量, 應該不會像 AS58453(CMI 移動國際) 般有 100G 容量+發佈幾乎完整的 BGP table 了

@v2dead 如果是外部不確定的來源, 做一個非完整的 sturct 就好, 只為需要的(needed)及已知的(known)的地方寫 fields, 像 jackson 般就是可以把沒定義的 fields 全放在 map 之中, 兩者兼顧到

如果整天接到的 json 都是亂來的, 也就認了

@orangeade
對我來說, 只要有封裝的都是可行的設計方法, 我還有用 Golang 呢, 近來在練 Kotlin

拿 23 樓那種超長的例子來說, 如果只是有一天 web-app.servlet.servlet-name 改成了 web-app.servlet.servlet-id

如果有結構封裝, 要改代碼的話, 就把封裝 json 結構的 class 找出來改掉
class servlet{
String servlet-name;
}

直接用 IDE 的 refactor 改成新的 field 名字, 這樣引到用這 field 的地方都會自動改掉, 引用 1 次還是 100 次都沒差
class servlet{
String servlet-id;
}

沒有封裝的話, 如果用 Json["web-app"]["servlet"]["servlet-name"] 的, 嗯, 你們就慢慢手動的 search,再看看是否相關, 然後才 replace......這種 code 你自己用得開心就好, 不要留下來了

@lxy 如果你用的 API 都有良好的 documentation, 或者是 Swagger 那種按 API 定義自動生成的, 你應該會覺得把 json 結構寫成 class 會舒服很多

如果寫後台都是隨心所欲的在改結構又不給 doc, 那我才擔心這種設計合作起來會異常麻煩

最怕那種會直接返回不同結構的 API, 奇怪的狀況要動用 json parser 處理而不是 status code, 根本是浪費大家時間

https://1.1.1.1 及 https://1.0.0.1 也有了，希望會更進一步提供 https DNS 吧。

@alect 我這裡的移動長年在 24, 師傅也說了標準線是 25.......香港家的 PCCW 是 19

不掛路由器呢?

另外有可能可能是 MTU 設太大, 1492 的話再降到 1480/1450/1430/1400.....試試

前用移動遇到過, 症狀就是部分網站卡到出不來但有些測速網站能跑到, 不過非 1480 MTU 的 ISP 還是挺奇葩的

OMV + 1, 喜歡哪個 Linux application 就用 Docker 掛上去

@xshwy 放心吧, 1000 及 10000 還是很小

我有一個類似的, 3500 多 URL 佔用 10MB 不到 RAM

@Cipool 你這種方法, 放棄了 HTTPS 才能用吧....但的確可行

@qiukong 在我看來是有差別的, 我的觀察中 IP 分佈大概是這樣
Free 104.31.xxx~104.24.xxx
Pro 104.25.xxx~104.20.xxx
Biz 104.17.xxx.xxx/16
Enterprise 104.16.xxx.xxx/16

不算中國, 104.16.x.x/16 及 104.17.x.x/16 的路由特別好

redis 的 ZADD/ZRANK 似乎可以解決這種問題, 才 100 個 url 這種小型 dataset 應該是適合的

@bao3 我好奇的是你把中國的網絡看得這麼高......現在大部分世界主要城市的節點都有 IPv6, 你還認為要跟著中國走?

而且 CPE 的 Gigabit Ethernet 口能達到網線一樣的效果, VLAN(例如 IPTV)也能帶, 用一般 WiFi 的話你就準備折騰一番然後效果還是不夠好吧

電力貓+1

非要無線不可的話, 用一般 WiFi 的話廷遲及頻寬都會掉很多

用 TDMA 作為訊號調製方法 CPE 好很多, 就算是舊款二手的 Ubnt LOCO M5 一類也比一般 802.11ac 橋接穩定

日本+1

室外寒冷還可以穿衣服解決, 城市的室內有供暖也不會太冷

另外, 今年日本東北地區很寒冷, 不停在下粉雪, 滑雪的就知道雪質十分好