㈠ 上網時應如何選擇中國移動GPRS和中國移動Wap網路
打開「設置」-「無線和網路」-「移動網路設置」-「接入點名稱」；
你能看見三個APN，不是三個的建議設置三個：
GPRS上網（cmnet）
移動夢網（cmwap）
移動彩信（cmmms）
具體設置如下：
GPRS上網（cmnet）
1 名稱：GPRS上網
2 APN：cmnet
㈡ 弱網下移動端網路連接處理策略
一、背景
如何度量和模擬「弱網路」對移動APP的開發有著重大的意義，比如：節約測試成本、易於問題重現、加快產品上線等。
一般的方法是使用「丟包率」和「網路延時」來定義和衡量「弱網路」。
二、手機接入伺服器的流程
要講這個問題，首先要來了解下手機接入伺服器的流程。
首先，手機要通過無線網路協議，從基站獲得無線鏈路分配，才能跟網路進行通訊。
無線網路基站、基站控制器這方面，會給手機進行信號的分配，已完成手機連接和交互。
獲得無線鏈路後，會進行網路附著、加密、鑒權，核心網路會檢查你是不是可以連接在這個網路上，是否開通套餐，是不是漫遊等。核心網路有SGSN和GGSN，在這一步完成無線網路協議和有線乙太網的協議轉換。
再下一步，核心網路會給你進行APN選擇、IP分配、啟動計費。
再往下面，才是傳統網路的步驟：DNS查詢、響應，建立TCP鏈接，HTTP GET，RTTP RESPONSE 200 OK，HTTP RESPONSE DATA，LAST HTTP RESPONSE DATA，開始UI展現。
這是手機通過無線網路接入伺服器的全過程。整個過程當中有幾個困擾開發者的問題：
無線網路是怎麼給手機分配到無線鏈路的？
核心網路有接入點（APN），這里的CMNET和CMWAP有什麼區別，僅僅是協議不同嗎嗎？數據轉發又有什麼區別？一個數據包在不同網路上傳輸有不同嗎？
用戶怎麼最快的找到正確的伺服器？內容怎麼快速有效的載入，在第一時間顯示出來？
這幾個問題的重點在於其中的幾個連接點：
3.2 一秒鍾法則
根據以上情況，就形成無線網路的一大特點：秒級狀態管理，秒級狀態轉換。這兩個操作都在幾百ms到幾秒之間進行，對於維持連接來說時間太短，對於從無連接到有連接的轉換來說時間又太長。
相比之下，有線網路的狀態管理如ip分配、tcp連接釋放，都是分鍾級，而狀態轉換則是毫秒級。
這些通訊機制，同時加上無線網路的高延遲、高丟包。如何保證移動互聯網的產品提供穩定的、可預期的服務質量，成為非常大的挑戰：
2G網路上無線部分數據傳輸的延遲有幾百ms，4G網路上無線部分傳輸延遲減少到幾十ms，核心網狀態轉換、協議轉換30~100ms，IP骨幹網上的延遲又跟物理距離以及運營商互聯互通質量有關，跨運營商50-400ms，同運營商5-80ms，這個還要取決於網路擁塞的情況。
無線網路誤碼率比有線高兩個數量級，在不同時間段的波動也非常巨大。
怎麼基於移動網路的特性去優化服務？
這就是我們總結的一秒鍾法則：在一秒內要完成的規定動作。
1,2g網路：1秒內完成dns查詢、和後台伺服器建立連接
2,3g網路：1秒內完成首字顯示（首字時間）
3,wifi網路：1秒內完成首屏顯示（首屏時間）
4,這些指標需要在終端度量，必須跟用戶體驗相關：首字時間、首屏時間都必須是用戶可以直觀感受到的。
四、優化思路
4.1 服務保證原則
從以上分析可知，如何保證移動互聯網的產品提供穩定的、可預期的服務質量，具有非常大的挑戰。以下幾點原則可能會有幫助：
1), 介面設計優化 ，介面的優化理論上不屬於APP弱網路的優化，但是這個的API性能的問題，確實在網路條件不好的情況下才暴露無遺。大家都在談論伺服器的好壞，設備的性能高低，其實，對於一個良好的Server來說，絕大部分拖延請求速度的地方都是在IO上。包括，磁碟讀寫的IO，SQL查詢的IO等等。常用的優化點：慢查詢監控 、多次查詢優化、常用介面cache等。
2) 圖片相關策略。
1）使用更快的圖片格式，嚴格說也不算弱網下的優化，但一個更快的圖片格式真的很重要！這里建議採用WebP格式。（WebP格式，谷歌（google）開發的一種旨在加快圖片載入速度的圖片格式。圖片壓縮體積大約只有JPEG的2/3，並能節省大量的伺服器帶寬資源和數據空間。但WebP是一種有損壓縮。相較編碼JPEG文件，編碼同樣質量的WebP文件需要佔用更多的計算資源。）
2）、不同網路的不同圖片下發。如（對於原圖是600X480的圖片）：2/3G使用低清晰度圖片——>下發300X240，精度為80的圖片、4G普通清晰度圖片——>下發600X480，精度為80的圖片、WiFi高清晰度圖片（最好根據網速來判斷，wifi也有慢的）——>下發600X480，精度為100的圖片。
3) 斷線重連 。這可能是最重的一個特性，因為在無線網路中有太多的原因導致數據連接中斷了。這里可以使用CDN。（CDN 是構建在數據網路上的一種分布式的內容分發網。 CDN 的作用是採用流媒體伺服器集群技術，克服單機系統輸出帶寬及並發能力不足的缺點，可極大提升系統支持的並發流數目，減少或避免單點失效帶來的不良影響。）
4)由於創建連接是一個非常昂貴的操作，所以應盡量 減少數據連接的創建次數 ，且在一次請求中應盡量以批量的方式執行任務。如果多次發送小數據包，應該盡量保證在2秒以內發送出去。在短時間內訪問不同伺服器時，盡可能地復用無線連接。
5), 優化DNS查詢 。應盡量減少DNS查詢、避免域名劫持、DNS污染，同時把用戶調度到「最優接入點」。
6), 減小數據包大小和優化包量 。通過壓縮、精簡包頭、消息合並等方式，來減小數據包大小和包量。
7),控制數據包大小不超過1500， 避免分片 。包括邏輯鏈路控制（Logic Link Control）分片、GGSN分片，以及IP分片。其中，當數據包大小超出GGSN所允許的最大大小時，GGSN的處理方式有以下三種：分片、丟棄和拒絕。
8), 優化TCP socket參數 ，包括：是否關閉快速回收、初始RTO、初始擁塞窗口、socket緩存大小、Delay-ACK、Selective-ACK、TCP_CORK、擁塞演算法(westwood/TLP/cubic)等。做這件事情的意義在於：由於2G/3G/4G/WIFI/公司內網等接入網路的QoS差異很大，所以不同網路下為了取得較好的服務質量，上述參數的取值差異可能會很大。
9), 優化ACK包 。在弱網路的情況下，TCP協議中的ACK包是非常昂貴的，延時甚至能夠達到秒級別，而TCP協議的擁塞控制、快速重傳、快速恢復等特性都非常依賴接收端反饋的ACK包。可想而知，如果發送端接收到的ACK包延時太長，會嚴重影響TCP協議的效率。但是如果發送ACK太多又會佔用寶貴過多的無線資源。在移動網路下通信，「在可靠的連接上，如何在減少ACK包的情況下，降低數據包的延時」是研究的熱點。基本的思想：平衡冗餘包和ACK包個數，達到降低延時，提高吞吐量的目的。例如SGSN和GGSN之間的通信實現：二者之間通過UDP協議通信，發送者在無新的數據包的情況下，每隔一定的時間重試已發送的包，達到最大重試次數後，則丟棄該包。
10), TCP的擁塞控制演算法 是以「丟包意味著網路出現擁塞」為假設設計的，很明顯這個假設在無線網路環境下是不合適的。但是在無線網路環境下，在設計可靠UDP協議時是否能夠完全丟棄擁塞控制呢？這里有其它的文章中提出了幾種在無線網路環境下的TCP友好的擁塞控制演算法，有興趣可以自行查閱。
11), 靈活使用長連接/短連接 ，支持不同協議（TCP/UDP, http、二進制協議等），支持不同埠等。
12), 讓用戶覺得快 。到這里已經不能算是技術層面的方法了，屬於一種心理層面的博弈，一種改善用戶體驗的方式。比如：
1）、不從0開始的進度條。不管網頁的載入進度如何，不管網路條件如何，載入進度始終是從50%起，並且停留在大約98%進度左右的地方。
2）、先顯示文字在載入圖片。同樣是在Webview之中，圖片或者多媒體的載入速度肯定是遠遠慢過文字的載入速度的。由於不同的webview顯示和渲染效果不同，我們可以先讓webview先顯示文字，在顯示圖片。給用戶一種可以先預覽整個網頁概況的感覺。
4.2 接入調度優化
接入調度優化首先要考慮的是減少DNS的影響。移動網路的DNS有如下特點：
1)骨幹網無法識別移動用戶在哪個城市，東西南北各個地方的調度沒有充分調用。目前有一部分全國范圍的DNS承載了超過40%的全網用戶
2),很多山寨機的終端local dns設置是錯誤的
3),另外還有一些有線網路也一樣會遇到的問題，如終端DNS解析濫用、域名劫持、DNS污染、老化、脆弱等。不過對於這些問題，桌面的自愈性會比較好，而在手機上則比較難以解決。
對於DNS的問題，有兩條主要的解決思路：
1),減少DNS的請求、查詢、更新，也就是做DNS緩存
2),在終端配置server list，直接訪問IP，不用DNS
但僅僅這么做還不夠，因為用戶可能來自國內外不同的運營商，還需要進一步優化調度策略：
1),DNS緩存需要多建立接入點，用不同域名區分
2),IP列表需要更新以適應不同網路情況，要做到主動調度。好比最早我們只服務好移動用戶就行，保證移動用戶的接入質量優先，因為絕大多數用戶集中在移動；現在國內有三個運營商，用戶分布的比例在慢慢接近，要區分清楚；智能手機會用wifi，接入的是電信、聯通還是哪個運營商，不知道，所以你不可能預先設置場景再if then，必須通過後台調度能力來解決。
再進一步優化，就產生一種融合的方式：
1),先做域名解析，客戶端直接連接解析的IP，可以用http協議，也可以用tcp socket
2),多埠、多協議組合：不同協議有不同的限制，有些只能http，有些只能tcp socket，各種環境都要適應，客戶端不能只支持一種協議
3),終端測速：接入點越來越多，接入哪個合適，要選擇，可以通過終端測速來選擇最快的。你當然可以每一次新建連接都做測速，但是這樣建立連接時間可能會很長；我們可以給用戶先建立連接後，在後台根據長期速度監控、當前測速的結果，來做動態調度。也就是說，第一次連接可能不是最優，連接建立後動態測速，再轉移到最快接入點。更進一步就是建立網路profile，終端學習的思路。
關於測速采樣的粒度，移動互聯網取IP段是沒用的，比較好的粒度是到網元級別，比如廣東有20多個wap網關，每一個網關的情況都不一樣，這就是一個比較合適的粒度。
最後強調一個所有的接入調度原則：不要把調度邏輯寫死在客戶端，一定要由後台完成。
4.3 協議優化
協議參數優化這塊就簡單列一下，是長期運營過程中總結的一些經驗，在啟動移動互聯網服務時作為運營的規范，可以少走很多彎路：
1,關閉TCP快速回收
2,Init RTO不低於3秒
3,初始擁塞控制窗口不小於10。因為大部分頁面在10kB以下，很多請求在慢啟動階段已經結束，改為10可以降低小頁面資源傳輸時延。內容越大，這個選項的效果就比較不明顯。
4,Socket buffer > 64k
5,TCP滑動窗口可變
6,控制發包大小在1400位元組以下，避免分片
協議優化的原則總結下來是這么幾條：
1,連接重用
2,並發連接控制
3,超時控制
4,包頭精簡
5,內容壓縮
6,選擇更高效率的協議。無論是TCP、HTTP、UDP、長連接、GZIP、SPDY、WUP還是WebP，每一種協議、方案都有其道理，沒有最優，只有是否適合你的產品和服務特點，需要大家在運營過程驗證和取捨。
4.4 WAP接入點優化
關於WAP接入點優化，可能有些人會說，我們的App是高端大氣上檔次的應用，是不是就不用做WAP優化？實際上我們的統計顯示，目前有5%-20%的用戶選擇的接入點是＊WAP（CMWAP、3GWAP、CTWAP），這甚至包括一些iPhone終端。實際上，WAP網關本質是個代理，不完全是落後的東西，隨著技術的進步也在演進，以後在組網架構中可能有綜合網關、內容計費網關來取代目前的WAP網關，所以建議也要一並考慮。以下是做WAP優化需要注意的一些問題：
1,資費提醒頁面
2,302跳轉處理
3,X-Online-Host使用與處理
4,包大小限制
5,劫持與緩存
6,正確獲取資源包大小
4.5 業務邏輯優化
1, 簡化邏輯 ：交互繁瑣的內容盡量用標識更新。舉一個例子，我們在老版的手機QQ上做過一個測試：假如我有100個好友，用手機QQ完成登陸，完成好友列表更新一遍，需要3.5分鍾。這肯定是不合理的。建議用信令狀態來通知是否需要更新，同時合理利用緩存。在比如玩游戲，好友給你送了很多星星，是讓用戶一次一次點還是批量點？從優化的角度肯定是批量點，從用戶體驗的角度這也更加舒服。
另一方面，延長域名圖標的緩存時間也可以有效地優化訪問次數。我們把手機騰訊網圖標的緩存時長從120分鍾延長到2天後，訪問次數優化了差不多35%。
2, 柔性可用 ：這個意思就是在網路質量好的時候給高清大圖，不好的時候先給用戶看小圖，點一下再拉取原圖。舉一個極端的例子，比如萬一地震了，基站毀掉20%，用戶要給家人報平安，這時候產品上就必須優化，比如只發送文字，合理降3, 低網路消耗 。另外在響應很慢的時候，需要給用戶一些合理的頁面提示，比如提示用戶再過5秒會發送，所以你不要一直刷屏，這也可以減少訪問對後台服務、對網路的沖擊。
上面說了那麼多，這里就給出一個實例幫助大家更直觀的理解。
這里給出一個DNS系統設計來實現最優調度。其拓撲結構如下：
TGCP SDK的職責：
1,用HTTP的Get/Post方法從DNSvr獲伺服器和DNSvr本身的最優接入點列表。Get/Post方法的查詢參數包括uin/openid、客戶端版本號、IP列表的MD5（注意IP順序）、域名列表、VIP、ServiceID等。
2,緩存訪問伺服器和DNSvr的IP列表，以及其它元數據（比如IP列表等），且以APN為主鍵。
3,滿足一定的條件下，要主動更新緩存的IP列表，例如緩存過期。
Tconnd的職責：
1,路由查詢請求給活動的DNSvr；
DNSvr的職責：
1,根據靜態和動態策略來決定客戶端的「最優接入點」。靜態策略：根據uin/openid、客戶端版本號或者強制規則來決定IP列表；動態策略：燈塔根據測速數據動態決定用戶的伺服器接入點。
2,支持以手動或自動的方式拉黑某些IP。自動方式：由伺服器的接入tconnd向DNSvr上報其是否存活（需要向多個點上報，包括用公網IP上報），如果在一定時間內沒有接收到上報或者上報消息中明確所有的邏輯伺服器已經掛掉，則自動拉黑相應的IP。如果業務恢復，則自動激活相應的IP。如果項目組接入TGW，對於某個IP和埠是否可用，則需要考慮進程與VIP的映射關系。
3,在tcaplus中緩存燈塔的計算結果。此時要求DNSvr能夠根據客戶端IP判斷所屬的國家、省份、運營商和網關（可以通過訪問MIG的IP庫實現）。如果緩存了燈塔的計算結果，當緩存超時後，要重新從燈塔拉取相應數據。
燈塔的職責：
1,根據客戶端IP和伺服器接入點IP，返回最優的接入點列表，包括IP的排序，以及客戶端接入的國家、省份、運營商、APN和網關。
Tcaplus的職責：
1,保存接入的IP列表和埠、靜態策略，或緩存燈塔的計算結果；
主要的流程：
客戶端批量解析域名流程
1,TGCP以APN和域名列表為關鍵字查詢緩存，如果存在且沒有過期，則直接把IP返回給用戶。如果指定強制解析域名列表，則跳過此步驟；
2,TGCP用預配置或緩存的IP向DNSvr發起查詢請求，如果成功返回結果，則執行步驟3，否則，重試IP列表中的其它IP，如果都失敗，則用域名訪問DNSvr。注意：如果是結果格式不正確，則使用上次的IP重試，不要更換IP重試。
3,DNSvr比較客戶端IP列表和當前最新的IP列表的MD5，如果相等，則告訴客戶端不需要更新本地緩存。否則，TGCP把接入伺服器和DNSvr的IP列表寫入本地。注意：在訪問伺服器時，這些IP的優先順序要高於靜態配置在客戶端的IP。
客戶端使用域名訪問伺服器流程
1,如果本地存在有效的IP（即存在對應APN的IP列表，且沒有失效），則使用IP訪問伺服器。
2,否則，發起「客戶端批量解析域名流程」後，再訪問伺服器。
伺服器接入tconnd主動上報狀態流程：
1,Tconnd周期性向DNSvr上報心跳消息，其中包含本接入點是否可用的信息。
2,DNSvr在一定的時間內沒有收到心跳消息或者相應的接入點不可用，則把相應的IP和埠拉黑，黑掉的IP不在下發給客戶端。
注意：實際部署的時候，接入的Tconnd要向多個DNSvr接入tconnd上報。
向客戶端主動push接入點列表的流程
1,當TGCP連接到伺服器接入的Tconnd時，Tconnd要向DNSvr發起請求，以校驗當前接入IP的質量和時效性。如果IP列表發生變化，Tconnd要把最新的IP列表下發給客戶端緩存起來。
2,當TGCP下次訪問伺服器時，則使用最新的IP列表。
客戶端訪問DNSvr失敗的流程
1,如果訪問DNSvr失敗（包括IP+域名），如果配置了本地IP，則直接用IP訪問伺服器，否則用域名訪問。
優化傳輸層協議設計
在原有tconnd支持的可靠UDP的基礎之上，添加以下邏輯：
1,數據壓縮；
2,數據加密；
3,合並多個數據包；
4,支持流式數據傳輸，便於控制每個UDP包的大小，也便於數據加密和壓縮；
5,可選地支持改進的擁塞控制演算法；
6,即使沒有接收到ACK包，也需要主動重試以發送的數據包；
5.2 Hybird開發下的一些優化
要處理在弱網路下的載入速度，那麼我們要先確定一下我們的整個APP在哪個地方載入的速度如何，最長的載入路徑在哪裡，我們從而才有針對性的進行優化與修改。
5.2.1 WebView
如果是對是APP中內嵌的webview網頁，針對網頁體驗優化已經由來已久了。我們可以使用Chrome的開發者模式，調整到Network模式下，將網路條件設置為3G去請求網頁，那麼我們就能夠看出來一個網頁載入的速度主要都耗費在哪個地方，如下圖所示：
當然，html的加速方式有很多種
1,使用gulpgrunt進行打包壓縮：jscss資源壓縮，CSS Sprites合並等。
2,使用font-awesome替換圖片：字體可以很好的兼容，無限放大，常用的圖片都有
㈢ 手機客戶端網路配置
1、打開手機''設置''，選擇''運營商網路''選項，即可對手機的接入點參數進行自動設置。點擊「一鍵設置APN信息」或者「手動設置APN信息」，選擇運營商就可以設置好了中國移動的接入點。
2、打開手機，找到其中的''設置''選項，找到「無線和網路」選項『找到「移動網路選項」，然後選擇「接入點名稱''，然後點擊「新建接入點''，切換即可。
3、打開手機，找到其中的''設置''選項，在設置界面選擇「更多」，點擊打開''移動網路''，選擇需要打開或設置連接的網路。
4、打開手機，找到其中的''設置''選項，進入後打開「更多」，點擊打開''網路模式''，選擇需要的網路類型。
5、打開手機，找到其中的''設置''選項，點擊並進入，選擇「雙卡與移動網路''，進入之後，將''數據網路''打開，點擊「數據''，就可以切換其他卡的數據。
㈣ 手機上怎麼設置防蹭網
防蹭網的方法有很多，但是大多數不實用，今天我就教大家最簡單有效的方法，無需電腦設置，手機就可以操作。
1、手機需連接自己家的WIFI，然後打開瀏覽器，在地址欄里輸入路由器ip地址，大多數都是192.168.1.1，或者查看路由器底部標簽處
地址欄中輸入ip地址,然後點訪問
找到這個地址後 把它記下來，然後按照下圖操作，先選擇（1）添加新條目，然後選擇（2）點擊 允許列表中生效的mac,然後在點擊（3）啟動過濾
下圖是添加新條目界面，將手機mac添加進去。
當選擇啟動過濾時 會斷網不過不用擔心一會兒就會自動連接。
如果其他人想使用你家WIFI 需要添加新條目就ok了。如果不添加就算他知道密碼都不能連接你的WIFI，在你這萬能鑰匙形同虛設。
㈤ 中國移動互聯網設置和中國移動WAP設置有什麼區別
中國移動互聯網設置和中國移動WAP設置區別為：流量不同、使用不同、適用模式不同。
一、流量不同
1、中國移動互聯網設置：中國移動互聯網設置因為有文字和圖片，所以比較費流量。
2、中國移動WAP設置：中國移動WAP設置經過優化，一般以文字為主，所以比較省流量。
二、使用不同
1、中國移動互聯網設置：中國移動互聯網設置不必開通GPRS就能直接使用。
2、中國移動WAP設置：中國移動WAP設置必須開通GPRS才能使用。
三、適用模式不同
1、中國移動互聯網設置：中國移動互聯網設置適用於PC端模式使用。
2、中國移動WAP設置：中國移動WAP設置適用於手機端模式使用。
㈥ 手機移動網路埠怎麼設置 如何設置手機接入點
1、在手機中選擇「設置」--移動網路--接入點名稱（APN）--新建APN
2、進入新建頁面後，「名稱」可填寫CMWAP ，「APN」也可填寫CMWAP
3、「代理」填寫 10．0．0．172，「埠」填寫 80 ，「用戶名」 和 「密碼」 不用填寫。
4、「伺服器」 可以填寫運營商的官方網址。「MMSC」、「彩信代理」和「彩信埠」不用填寫。
5、「MCC」填寫 460 ，「MNC」填寫 01 ，「身份驗證類型」不用填寫。
6、「APN類型」填寫 default ， 「APN協議」填寫IPv4 ,「APN漫遊協議」填寫IP.
㈦ gm619復位之後怎麼用手機端設置網路配置重新撥號上網
光貓接無線路由第一步：將路由器的WAN口與光貓的任一LAN介面連接
光貓接無線路由 第二步：將路由器復位，用大頭針等物品按路由器上的Reset按鈕。
光貓接無線路由第三步：打開瀏覽器，在地址欄輸入192.168.1.1 打開路由器的管理界面，輸入賬號、口令登錄；路由器默認賬號密碼均為：admin 小寫
光貓接無線路由第四步：點擊左邊功能菜單「設置向導」>選擇「動態IP」點擊下一步；
光貓接無線路由第五步：設置好SSID和無線密碼點擊下一步；
光貓接無線路由第六步：點擊「完成」，路由器將自動重啟。
光貓接無線路由第七步：在重啟完成後，再次登錄到路由器管理，點網路參數>LAN口設置>輸入IP地址：172.168.1.1，保存
就是將原來的192.168.1.1更改成新的網段，因為電信光貓用的就是這個網段，路由器不能與光貓相同。
㈧ 手機移動端怎麼打開網址
手機移動端在手機網路瀏覽器中輸入相應的網址，連接網路就可以了。
1.確定您的手機能夠開通GPRS服務。 參考產品說明書，或打電話向手機生產商咨詢。
2.開通GPRS服務和手機設置。 可以到電信營業廳咨詢辦理業務。 中國移動用戶，可撥打10086服務熱線，或使用網上營業廳咨詢辦理業務。具體詳情，請查閱中國移動的WAP業務介紹 。中國聯通用戶，可撥打10010服務熱線咨詢，詳情請參見中國聯通業務介紹。
3.在手機網路瀏覽器中輸入相應的網址，連接網路就可以了。
㈨ 分析移動端APP的網路請求
為了方便，本文以 iOS 系統來進行演示。
移動操作系統中都有可以設定系統代理的設置，比如在 iOS 中可以通過 Settings->WLAN 看到很多 Networks，通過點擊它們後面的 Info 圖標來設置代理：
這樣的話，所有的請求就會先到我們設置的代理伺服器，然後才有代理轉發給目標伺服器。於是我們就有機會在代理伺服器上獲取到請求的內容。
這里我使用的代理伺服器是 Charles ，在安裝並打開了 Charles 之後，Charles 就已經在後台建立了一個代理服務了。我們可以通過 ifconfig 命令找到自己的區域網 IP，Charles 默認的代理埠是 8888 。現在像上面的截圖那樣，在移動端中進行配置以使用我們的 Charles 代理。
現在你可以在移動端發起一些網路請求，當然最好是 HTTP 的，因為我不清楚 Charles 是否支持其他的協議類型。為了方便，我們可以使用 Safari 打開一段網址，比如 http://news..com (注意目前只是 HTTP 的，關於如何操作 HTTPS 下面會講到)。題外話，正如你所見的，網路的最常用的功能就是檢查網路服務的連通情況，比如 ping .com ，哈。
如果不出意外，那麼你會在 Charles 左邊欄中看到類似下圖的情況：
那麼說明我們的配置已經工作了，如果你點擊它們中的一個，右邊的界面中就會顯示對應的請求內容：
很好，Charles 已經為我們做了很多事，現在我們可以輕松的知道發生了哪些請求以及請求的內容了。
現在我們試一試在 safari 中輸入 www..com ，我們知道網路在 www 子域中使用了 HTTPS，並且當發現用戶使用的不是 HTTPS 訪問此子域時，會自動的 redirect，於是我們到了 https://www..com 。
現在再來看看 Charles 中的情況，我們發現 https://www..com 前面多了一把小鎖：
並且右邊沒有給出請求的內容，但是有一條提示 - 對於 SSL 代理需要進行額外的設置。
下面我就簡單解釋一下為什麼對於 HTTPS 而言 Charles 就暫時罷工了。更加具體的內容，可以見我的這篇文章 非對稱加密和數字證書 。
HTTPS 就是 HTTP over TLS，就是在原本的 HTTP 請求之前，客戶端和伺服器先進行 TLS 握手並建立一個 TLS 鏈接，然後在此鏈接之上進行 HTTP 協議的內容。這樣就使得我們的明文請求變成加密的。但是這里還是有一個缺陷，就是 TLS 握手階段是明文的，那麼為了解決這種雞生蛋蛋生雞的問題，出現了證書 (Certificate) 和證書頒發機構 (Certificate Authority)。
於是在 TLS 握手階段，多了一個校驗證書的步驟，服務端會返回 CA 頒發給其的證書，而客戶端對證書的真實性進行校驗。由於現在的請求內容已經被加密，所以作為代理的 Charles 無法知道其中的內容，於是為了使得 Charles 可以解析 HTTPS 的內容，我們就必須協助其完成 Man-in-the-middle 攻擊，攻擊的對象就是我們自己。
攻擊的方式很簡單，在手機上安裝上 Charles 的 CA 證書即可，所謂 CA 證書就是 CA 機構的證書，來證明 CA 機構的真實性，一些權威的 CA 機構的證書都是內置在我們的操作系統中的。現在我們在移動端上安裝了 Charles 的 CA 證書之後，Charles 就變成了 CA 了，於是它就可以頒發一個偽造的證書來欺騙移動端中的應用。
如果你不想了解其中的原理的話，要實現這個攻擊還是很簡單的，Charles 也提供了很多的便利，按照下面的步驟就行了。
我們在 Charles 的菜單中找到 ：
點擊一下就會看到：
在移動端的 safari 中輸入地址 http://charlesproxy.com/getssl 後，跟著下面的截圖來將 Charles 製作的 CA 證書安裝到移動端中：
到目前為止，Charles 製作的 CA 證書已經安裝到了你的移動端，如果你希望刪除它的話，可以通過 Settings->General->Profile 來找到它並刪除，另外如果你不信任 Charles 自製的 CA 證書的話，它也是支持你使用自己的 CA 證書的。
再回到 Charles 進行一些設置，添加一下 SSL 規則：
現在，再回到移動端，在 safari 中訪問 www..com ，然後再看看 Charles 中的結果，你會發現：
現在我們已經可以解析來自移動端的 HTTPS 請求了。
暫時就先寫這么多吧
㈩ 華為手機怎樣設置移動網路
一、請確保您的 SIM 卡已開通移動數據業務。
二、通過以下任一方式連接移動網路：
1、從屏幕頂部狀態欄下滑出通知面板，繼續向下滑出整個菜單，點擊開啟移動數據。
2、進入設置 > 移動網路 > 移動數據 ，開啟移動數據開關。
當您不使用移動網路時，請及時關閉移動數據，以節省數據流量並延長待機時間。