無線網路基站、基站控制器這方面，會給手機進行訊號的分配，已完成手機連線和互動。
獲得無線鏈路後，會進行網路附著、加密、鑑權，核心網路會檢查你是不是可以連線在這個網路上，是否開通**，是不是漫遊等。核心網路有sgsn和ggsn，在這一步完成無線網路協議和有線乙太網的協議轉換。
再下一步，核心網路會給你進行apn選擇、ip分配、啟動計費。
再往下面，才是傳統網路的步驟：dns查詢、響應，建立tcp鏈結，http get，rttp response 200 ok，http response data，last http response data，開始ui展現。
這是手機通過無線網路接入伺服器的全過程。整個過程當中有幾個困擾開發者的問題：
無線網路是怎麼給手機分配到無線鏈路的？
核心網路有接入點（apn），這裡的cmnet和cmwap有什麼區別，僅僅是協議不同嗎嗎？資料**又有什麼區別？乙個資料報在不同網路上傳輸有不同嗎？
使用者怎麼最快的找到正確的伺服器？內容怎麼快速有效的載入，在第一時間顯示出來？
這幾個問題的重點在於其中的幾個連線點：
無線鏈路分配。這是乙個物理實連線。
ip層鏈結。這是乙個邏輯虛連線。
tcp層鏈結。這是乙個邏輯虛連線。
http層鏈結。這是乙個邏輯虛連線。
以用手機打**的場景示例：使用者在手機上撥號出去後，手機會跟網路申請無線鏈路，呼叫申請會發給電路域的核心網，通過**交換機找尋被叫**，被叫方接通**，無線鏈路建立；完成通話，結束通話的時候，手機給網路傳送指令，表示服務使用結束，把已經分配的無線鏈路釋放。
在2g edge網路下，差不多是1秒鐘不傳資料，就釋放物理連線，**給其他人備用。3g網路會延長幾秒鐘。
這樣的設定是有原因的。比如現在我們這個會場裡有200人，那麼我們200人同時上網的前提是共享同乙個基站的資源，共享資源必須要有規則，比如要有排序，根據資源情況、使用者鏈結活躍決定分配還是**，這都是通過無線網路信令控制的。
給乙個手機分配無線通道的信令又有好幾個情況，比如基站跟手機，基站跟基站控制器、核心網。舉個例子，伺服器從後台傳送push訊息，流動網路可能不知道這個手機是否活躍，不知道在哪個小區，流動網路就會發乙個尋呼，在各個小區找這個手機，當然這個不能基於ip，而是其他的網路標識。找到了之後，這個手機再去申請通道資源，然後才能接受push。所以，這種場景下信令的消耗可能會在很多小區產生。
根據以上情況，就形成無線網路的一大特點：秒級狀態管理，秒級狀態轉換。這兩個操作都在幾百ms到幾秒之間進行，對於維持連線來說時間太短，對於從無連線到有連線的轉換來說時間又太長。
相比之下，有線網路的狀態管理如ip分配、tcp連線釋放，都是分鐘級，而狀態轉換則是毫秒級。
這些通訊機制，同時加上無線網路的高延遲、高丟包。如何保證移動網際網路的產品提供穩定的、可預期的服務質量，成為非常大的挑戰：
2g網路上無線部分資料傳輸的延遲有幾百ms，4g網路上無線部分傳輸延遲減少到幾十ms，核心網狀態轉換、協議轉換30~100ms，ip骨幹網上的延遲又跟物理距離以及運營商互聯互通質量有關，跨運營商50-400ms，同運營商5-80ms，這個還要取決於網路擁塞的情況。
無線網路誤位元速率比有線高兩個數量級，在不同時間段的波動也非常巨大。
怎麼基於流動網路的特性去優化服務？這就是我們總結的一秒鐘法則：在一秒內要完成的規定動作。
2g網路：1秒內完成dns查詢、和後台伺服器建立連線
3g網路：1秒內完成首字顯示（首字時間）
wifi網路：1秒內完成首屏顯示（首屏時間）
這些指標需要在終端度量，必須跟使用者體驗相關：首字時間、首屏時間都必須是使用者可以直觀感受到的。
接入排程優化首先要考慮的是減少dns的影響。流動網路的dns有如下特點：
骨幹網無法識別移動使用者在哪個城市，東西南北各個地方的排程沒有充分呼叫。目前有一部分全國範圍的dns承載了超過40%的全網使用者
很多山寨機的終端local dns設定是錯誤的
另外還有一些有線網路也一樣會遇到的問題，如終端dns解析濫用、網域名稱劫持、dns汙染、老化、脆弱等。不過對於這些問題，桌面的自癒性會比較好，而在手機上則比較難以解決。
對於dns的問題，有兩條主要的解決思路：
減少dns的請求、查詢、更新，也就是做dns快取
在終端配置server list，直接訪問ip，不用dns
但僅僅這麼做還不夠，因為使用者可能來自國內外不同的運營商，還需要進一步優化排程策略：
dns快取需要多建立接入點，用不同網域名稱區分
ip列表需要更新以適應不同網路情況，要做到主動排程。好比最早我們只服務好移動使用者就行，保證移動使用者的接入質量優先，因為絕大多數使用者集中在移動；現在國內有三個運營商，使用者分布的比例在慢慢接近，要區分清楚；智慧型手機會用wifi，接入的是電信、聯通還是哪個運營商，不知道，所以你不可能預先設定場景再if then，必須通過後台排程能力來解決。
再進一步優化，就產生一種融合的方式：
先做網域名稱解析，客戶端直接連線解析的ip，可以用http協議，也可以用tcp socket
多埠、多協議組合：不同協議有不同的限制，有些只能http，有些只能tcp socket，各種環境都要適應，客戶端不能只支援一種協議
終端測速：接入點越來越多，接入哪個合適，要選擇，可以通過終端測速來選擇最快的。你當然可以每一次新建連線都做測速，但是這樣建立連線時間可能會很長；我們可以給使用者先建立連線後，在後台根據長期速度監控、當前測速的結果，來做動態排程。也就是說，第一次連線可能不是最優，連線建立後動態測速，再轉移到最快接入點。更進一步就是建立網路profile，終端學習的思路。
測速取樣的粒度我也說一下，移動網際網路取ip段是沒用的，比較好的粒度是到網元級別，比如廣東有20多個wap閘道器，每乙個閘道器的情況都不一樣，這就是乙個比較合適的粒度。
另外我們後面還有乙個set模型，可以就近提供服務。
最後想強調乙個所有的接入排程原則：不要把排程邏輯寫死在客戶端，一定要由後台完成。
協議引數優化這塊就簡單列一下，是我們長期運營過程中總結的一些經驗，在啟動移動網際網路服務時作為運營的規範，可以少走很多彎路：
關閉tcp快速**
init rto不低於3秒
初始擁塞控制視窗不小於10。因為大部分頁面在10kb以下，很多請求在慢啟動階段已經結束，改為10可以降低小頁面資源傳輸時延。內容越大，這個選項的效果就比較不明顯。
socket buffer > 64k
tcp滑動視窗可變
控制發包大小在1400位元組以下，避免分片
協議優化的原則總結下來是這麼幾條：
連線重用
併發連線控制
超時控制
包頭精簡
內容壓縮
選擇更高效率的協議。無論是tcp、http、udp、長連線、gzip、spdy、wup還是webp，每一種協議、方案都有其道理，沒有最優，只有是否適合你的產品和服務特點，需要大家在運營過程驗證和取捨。
資費提醒頁面
302跳轉處理
x-online-host使用與處理
包大小限制
劫持與快取
正確獲取資源包大小
簡化邏輯：互動繁瑣的內容盡量用標識更新。舉乙個例子，我們在老版的手機qq上做過乙個測試：假如我有100個好友，用手機qq完成登陸，完成好友列表更新一遍，需要3.5分鐘。這肯定是不合理的。建議用信令狀態來通知是否需要更新，同時合理利用快取。在比如玩遊戲，好友給你送了很多星星，是讓使用者一次一次點還是批量點？從優化的角度肯定是批量點，從使用者體驗的角度這也更加舒服。
柔性可用：這個意思就是在網路***的時候給高畫質大圖，不好的時候先給使用者看小圖，點一下再拉取原圖。舉乙個極端的例子，比如萬一**了，基站毀掉20%，使用者要給家人報平安，這時候產品上就必須優化，比如只傳送文字，合理降低網路消耗。另外在響應很慢的時候，需要給使用者一些合理的頁面提示，比如提示使用者再過5秒會傳送，所以你不要一直刷屏，這也可以減少訪問對後台服務、對網路的衝擊。
最後談談對優化方法的實踐和結果的評估。qq手機瀏覽器從4.5版本、5.0版本到5.1版本，我們對2g網路下的連線時間、3g網路下的首字耗時、wifi網路下的首屏耗時進行持續監控，耗時降到一秒鐘以下還在不斷的改進，每個新的版本平均值均有所壓縮。這個結果是從每天使用者實際使用的運營資料中得到的，覆蓋到絕大多數的手機終端和網路環境。不過平均值只是一方面，我們另一方面還要看「有多少比例的資料滿足了一秒鐘法則」這個維度，因為無線網路的長尾資料波動很大，這乙個維度也非常重要。目前現狀是我們2g網路做到79%，3g網路做到73%，wifi網路做到69%。目前我們的目標是達到80%，實現之後，再進一步挑戰90%的比例，不斷追求極致。
感謝楊賽對本文的整理。
Python每隔一秒鐘列印當地時間
import threading,time global tdef sayhello print time.strftime y m d h m s time.localtime time.time t threading.timer 1.0 sayhello t.start t threading...
一秒鐘搞懂zookeeper實現的分布式鎖
分布式鎖獲取思路 a 在zookeeper指定節點 locker 下建立臨時順序節點。b 客戶端呼叫createnode方法在locker下建立臨時順序節點，然後呼叫getchildren locker 來獲取locker下面的所有子節點，注意此時不用設定任何watcher。c 客戶端獲取到所有的子...
教你以一秒鐘10萬 個密碼的速度破解WiFi
本文中涉及的所有技術僅供個人學習 技術交流，禁止用於非法用途！請在國家法律允許的範圍內使用！本文中涉及的所有技術僅供個人學習 技術交流，禁止用於非法用途！請在國家法律允許的範圍內使用！本文中涉及的所有技術僅供個人學習 技術交流，禁止用於非法用途！請在國家法律允許的範圍內使用！破解原理 使用你的監聽網...