iosandroidsocket

A. android socket什麼意思

android socket
安卓插座
socket
[英][ˈsɒkɪt][美][ˈsɑ:kɪt]
n.
插座; 燈座; 窩，穴; [解]眼窩，孔窩;
vt.
把…裝入插座; 給…配插座;
第三人稱單數：sockets復數：sockets現在分詞：socketing過去式：
1
Never overload an electrical socket.
千萬不要使電源插座過載。

2
Now when He saw that He did not prevail against him, He touched the socket of his hip; and the socket of Jacob's hip was out of joint as He wrestled with him.
那人見自己勝不過他，就將他的大腿窩摸了一把，雅各的大腿窩正在摔跤的時候就扭了。

B. android socket 異常退出問題

你沒有用線程！！！
--------------------
客戶Socket
產生Socket對象，客戶端連接服務端的埠，這也需要放到線程中，由newSocket()子程序負責； 讀Socket得到的字元串通過消息傳給主程序協助顯示，這由clientRead(Socket sk)子程序負責，這兩個耗時性子程序都要放到子線程才能工作， clientRead(final String ip,final int port)產生即時子線程供調用。

Socket newSocket(String ip,int port)
{ Socket sk=null;
try
{ sk=new Socket(ip,port); // 連接服務端，返回Socket
}
catch(Exception e)
{
}
return(sk);
}
void clientRead(Socket sk)
{ // 客戶端讀Socket
DataInputStream inf;
try
{ inf=new DataInputStream(sk.getInputStream());
while(sk.isConnected() && !sk.isClosed())
{ String s=inf.readUTF();
if (s.length()>0)
{ Message msg=cHandler.obtainMessage(2,s);
cHandler.sendMessage(msg);
}
}
}
catch(Exception e)
{
}
}
void clientRead(final String ip,final int port)
{ // 子線程中客戶端讀Socket
new Thread(new Runnable()
{ @Override
public void run()
{ Socket sk=newSocket(ip,port);
clientSocket=sk;
if (sk!=null)
clientRead(sk);
}
}).start();
}
一次成功的連接，在服務端與客戶端各自都會產生一個Socket對象，並包含了許多方法與屬性，對象中可以知道對方的IP地址與埠，還有判斷連接狀態的函數，如Socket.isConected()和Socket.isClosed(),但這只能判斷自已的Socket是否已連接與斷開，但無法判斷對方的是否斷開狀態，解決的辦法是服務端向對方發「心跳包」或自行在對話協議中向對方發應答命令，以是否響應超時作為判斷對方是否斷開的依據。

C. Android socket源碼解析(三)socket的connect源碼解析

上一篇文章著重的聊了socket服務端的bind，listen，accpet的邏輯。本文來著重聊聊connect都做了什麼？

如果遇到什麼問題，可以來本文 https://www.jianshu.com/p/da6089fdcfe1 下討論

當服務端一切都准備好了。客戶端就會嘗試的通過 connect 系統調用，嘗試的和服務端建立遠程連接。

首先校驗當前socket中是否有正確的目標地址。然後獲取IP地址和埠調用 connectToAddress 。

在這個方法中，能看到有一個 NetHooks 跟蹤socket的調用，也能看到 BlockGuard 跟蹤了socket的connect調用。因此可以hook這兩個地方跟蹤socket，不過很少用就是了。

核心方法是 socketConnect 方法，這個方法就是調用 IoBridge.connect 方法。同理也會調用到jni中。

能看到也是調用了 connect 系統調用。

文件：/ net / ipv4 / af_inet.c

在這個方法中做的事情如下：

注意 sk_prot 所指向的方法是， tcp_prot 中 connect 所指向的方法，也就是指 tcp_v4_connect .

文件：/ net / ipv4 / tcp_ipv4.c

本質上核心任務有三件:

想要能夠理解下文內容，先要明白什麼是路由表。

路由表分為兩大類：

每個路由器都有一個路由表(RIB)和轉發表 (fib表)，路由表用於決策路由，轉發表決策轉發分組。下文會接觸到這兩種表。

這兩個表有什麼區別呢？

網上雖然給了如下的定義：

但實際上在Linux 3.8.1中並沒有明確的區分。整個路由相關的邏輯都是使用了fib轉發表承擔的。

先來看看幾個和FIB轉發表相關的核心結構體：

熟悉Linux命令朋友一定就能認出這裡面大部分的欄位都可以通過route命令查找到。

命令執行結果如下：

在這route命令結果的欄位實際上都對應上了結構體中的欄位含義：

知道路由表的的內容後。再來FIB轉發表的內容。實際上從下面的源碼其實可以得知，路由表的獲取，實際上是先從fib轉發表的路由字典樹獲取到後在同感加工獲得路由表對象。

轉發表的內容就更加簡單

還記得在之前總結的ip地址的結構嗎？

需要進行一次tcp的通信，意味著需要把ip報文准備好。因此需要決定源ip地址和目標IP地址。目標ip地址在之前通過netd查詢到了，此時需要得到本地發送的源ip地址。

然而在實際情況下，往往是面對如下這么情況：公網一個對外的ip地址，而內網會被映射成多個不同內網的ip地址。而這個過程就是通過DDNS動態的在內存中進行更新。

因此 ip_route_connect 實際上就是選擇一個緩存好的，通過DDNS設置好的內網ip地址並找到作為結果返回，將會在之後發送包的時候填入這些存在結果信息。而查詢內網ip地址的過程，可以成為RTNetLink。

在Linux中有一個常用的命令 ifconfig 也可以實現類似增加一個內網ip地址的功能：

比如說為網卡eth0增加一個IPV6的地址。而這個過程實際上就是調用了devinet內核模塊設定好的添加新ip地址方式，並在回調中把該ip地址刷新到內存中。

注意 devinet 和 RTNetLink 嚴格來說不是一個存在同一個模塊。雖然都是使用 rtnl_register 注冊方法到rtnl模塊中：

文件：/ net / ipv4 / devinet.c

文件：/ net / ipv4 / route.c

實際上整個route模塊，是跟著ipv4 內核模塊一起初始化好的。能看到其中就根據不同的rtnl操作符號注冊了對應不同的方法。

整個DDNS的工作流程大體如下：

當然，在tcp三次握手執行之前，需要得到當前的源地址，那麼就需要通過rtnl進行查詢內存中分配的ip。

文件：/ include / net / route.h

這個方法核心就是 __ip_route_output_key .當目的地址或者源地址有其一為空，則會調用 __ip_route_output_key 填充ip地址。目的地址為空說明可能是在回環鏈路中通信，如果源地址為空，那個說明可能往目的地址通信需要填充本地被DDNS分配好的內網地址。

在這個方法中核心還是調用了 flowi4_init_output 進行flowi4結構體的初始化。

文件：/ include / net / flow.h

能看到這個過程把數據中的源地址，目的地址，源地址埠和目的地址埠，協議類型等數據給記錄下來，之後內網ip地址的查詢與更新就會頻繁的和這個結構體進行交互。

能看到實際上 flowi4 是一個用於承載數據的臨時結構體，包含了本次路由操作需要的數據。

執行的事務如下：

想要弄清楚ip路由表的核心邏輯，必須明白路由表的幾個核心的數據結構。當然網上搜索到的和本文很可能大為不同。本文是基於LInux 內核3.1.8.之後的設計幾乎都沿用這一套。

而內核將路由表進行大規模的重新設計，很大一部分的原因是網路環境日益龐大且復雜。需要全新的方式進行優化管理系統中的路由表。

下面是fib_table 路由表所涉及的數據結構：

依次從最外層的結構體介紹：

能看到路由表的存儲實際上通過字典樹的數據結構壓縮實現的。但是和常見的字典樹有點區別，這種特殊的字典樹稱為LC-trie 快速路由查找演算法。

這一篇文章對於快速路由查找演算法的理解寫的很不錯: https://blog.csdn.net/dog250/article/details/6596046

首先理解字典樹：字典樹簡單的來說，就是把一串數據化為二進制格式，根據左0，右1的方式構成的。

如圖下所示：

這個過程用圖來展示，就是沿著字典樹路徑不斷向下讀，比如依次讀取abd節點就能得到00這個數字。依次讀取abeh就能得到010這個數字。

說到底這種方式只是存儲數據的一種方式。而使用數的好處就能很輕易的找到公共前綴，在字典樹中找到公共最大子樹，也就找到了公共前綴。

而LC-trie 則是在這之上做了壓縮優化處理，想要理解這個演算法，必須要明白在 tnode 中存在兩個十分核心的數據：

這負責什麼事情呢？下面就簡單說說整個lc-trie的演算法就能明白了。

當然先來看看方法 __ip_dev_find 是如何查找

文件：/ net / ipv4 / fib_trie.c

整個方法就是通過 tkey_extract_bits 生成tnode中對應的葉子節點所在index，從而通過 tnode_get_child_rcu 拿到tnode節點中index所對應的數組中獲取葉下一級別的tnode或者葉子結點。

其中查找index最為核心方法如上，這個過程，先通過key左移動pos個位，再向右邊移動（32 - bits）演算法找到對應index。

在這里能對路由壓縮演算法有一定的理解即可，本文重點不在這里。當從路由樹中找到了結果就返回 fib_result 結構體。

查詢的結果最為核心的就是 fib_table 路由表，存儲了真正的路由轉發信息

文件：/ net / ipv4 / route.c

這個方法做的事情很簡單，本質上就是想要找到這個路由的下一跳是哪裡？

在這裡面有一個核心的結構體名為 fib_nh_exception 。這個是指fib表中去往目的地址情況下最理想的下一跳的地址。

而這個結構體在上一個方法通過 find_exception 獲得.遍歷從 fib_result 獲取到 fib_nh 結構體中的 nh_exceptions 鏈表。從這鏈表中找到一模一樣的目的地址並返回得到的。

文件：/ net / ipv4 / tcp_output.c

D. iOS客戶端與伺服器的數據交互總結

前言:
本文總結了iOS客戶端與伺服器進行交互時，採用 RESTful API + Json 的交互方式，針對不 同的數據形式以及不同的解析方法，如有不足之處，歡迎指正。

先了解一下相關的基本概念。

HTTP通信:
即使用HTTP協議進行通信，工作原理是客戶端向伺服器端發送一條HTTP請求，伺服器收到之後先 解析客戶端的請求，之後會返回數據給客戶端，然後客戶端再對這些數據進行解析和處理。HTTP 連接採取的是「請求—響應」方式，即在請求時建立連接通道，當客戶端像伺服器端發送請求時，服 務器端才能向客戶端發送數據。

Socket通信:Socket又稱套接字，在程序內部提供了與外界通信的埠，即埠通信。通過建立 socket連接，可為通信雙方的數據傳輸傳提供通道。Socket的主要特點有數據丟失率低，使用簡 單且易於移植。Socket類似於peer to peer的連接，一方可隨時向另一方喊話。
小結:HTTP和Socket都是基於TCP協議的。使用兩種通信方式的情況是: 使用HTTP的情況:雙方不需要時刻保持連接在線，比如客戶端資源的獲取、文件上傳等。
使用UDP的情況:大部分即時通訊應用(QQ、微信)、聊天室、蘋果APNs等。

主要有四種:
數據流
1.從web伺服器響應到手機終端的數據 一般打包在一個位元組數組中，這個位元組數據中包含了不同的 數據類型，客端端採取Java數據流和過慮流的方式從位元組數組中取出各種類型的數據。
這種交互方式我在學習iOS之初用過，實際項目中並沒有發現哪家公司在用。這種方式了擴展 了iOS平台在訪問Web伺服器進行交互時的解析數據能力，僅供研究學習。

2.XML Webservice的標准數據格式。 Protocol Buffers

3.Protocol Buffers 是一種輕便高效的結構化數據存儲格式，支持跨平台。它很適合做數據存儲或 RPC 數據交換格式。比 JSON 最大的優點就是傳輸的時候數據體積可以壓縮很小，傳輸效率比較 高。本人在這個在項目中沒有用到過。

4.JSON
JSON(JavaScript Object Notation) 是一種輕量級的數據交換格式。 易於人閱讀和編寫。同時也易於機器解析和生成。毫無疑問，大家最常用。

本文重點會介紹關於Json數據格式 的常用格式。

Json數據格式 的採用，根據業務情況，一般是團隊中的共識。技術的迭代更新，到後期基本都會考慮多 個平台的通用性、可移植性和可讀性。比如 我們開發團隊，有移動端開發(Android、iOS)、前端開發 (H5開發)和後台開發(golang開發)。

關於伺服器的開發規范，我們先來了解一下。
伺服器開發規范 我們採用的是 RESTful ， RESTful 是目前最流流行的 API設計規范，用於web數據接
口的設計。

• 面面向資源(URI)，具有解釋性;
• 行為(GET / POST / PUT / PATCH / DELETE)與資源(URI)分離，更更加輕量量;
• 數據描述簡單，使用用JSON、XML、Protocol Buffers即可全覆蓋， 主要使用用JSON;

它的核心原則是定義用少量方法就能操作的命名資源。資源和方法可視為API的 和動詞。

• GET :讀取(Read)
• POST :新建(Create)
• PUT :更新(Update)，通常是全部更更新
• PATCH :更新(Update)，通常是部分更更新
• DELETE :刪除(Delete)
項目搭建之始，客戶端和伺服器一般用 Get 和Post的方式來交互，隨著業務的演進和技術的規范迭代， 到後期我們都得按規范來。於是 我們採用了上述幾種方式來設計伺服器介面，相應地，移動端的請求方 式也得與之對應。
至此，不在贅述 RESTful API 的設計規范，可自行網路了解更多。

介面的數據一般都採用JSON格式進行傳輸，不過，需要注意的是，JSON的值只有六種數據類型:

•Number:整數或浮點數
•String:字元串
•Boolean:true 或 false
•Array:數組包含在方括弧 [] 中
•Object:對象包含在大括弧 {} 中
•Null:空類型

傳輸的數據類型不能超過這六種數據類型,不能用Date數據類型，不同的解析庫解析方式不同，可能會 導致異常，如果遇到日期的數據，最好的方式就是使用毫秒數表示日期。

本文總結了iOS與伺服器的交互方式和數據類型，並總結了在實際項目的簡單運用。數據格式的運
用場景遠不止上面提到的幾種場景，後期會持續完善，如有不足之處，歡迎指出。

E. iOS 和 Android 的後台推送原理各是什麼有什麼區別

iOS 系統的推送（APNS，即 Apple Push Notification Service）依託一個或幾個系統常駐進程運作，是全局的（接管所有應用的消息推送），所以可看作是獨立於應用之外，而且是設備和蘋果伺服器之間的通訊，而非應用的提供商伺服器
所以， iOS 的推送，可以不嚴謹的理解為：蘋果伺服器朝手機後台掛的一個 IM 服務程序發送的消息。
然後，系統根據該 IM 消息識別告訴哪個 App 具體發生了什麼事。
然後，系統分別通知這些 App
而 Android每個需要後台推送的應用有各自的單獨後台進程，才能和各自的伺服器通訊，交換數據。
其實 Android 也有類似 APNS 的 GCM（Google Cloud Message）的服務，如果一個應用的推送採用這種模式的話，就和iOS推送一個樣了。
GCM相關的程序應該是集成在所謂的Gapps中，但國內的 Android 手機上 GCM 處於基本不可用的狀態，而且Android 因為後台可以長駐，所以，App們各顯神通。
聊天類應用的話，大多數直接借用 XMPP 規范里的一些成果。少量如微信有IM底子的，自己開發協議。這些在實現原理上與 APNs / GCM 沒有本質的區別，但有一定的技術門檻。
而大多數普遍應用，要使用推送的話，則使用輪詢的方式簡單實現，就是定時去伺服器上查詢數據，也叫Polling，還有一種手機跟伺服器之間維護一個 TCP 長連接，當伺服器有數據時，實時推送到客戶端，也就是我們說的 Push。
輪詢的方式不論怎麼優化都比較費電費流量，長連接的方式在網路不穩定的情況下，Socket比較容易斷開推送數據失敗，
安卓推送可以考慮使用第三方推送工具，比如極光推送

F. iOS近場通信(藍牙開發,WiFi開發)

1 AirDrop (UIActivityViewController類)

功能：實現iOS設備間的文件和數據分享。AirDrop使用藍牙來掃描周圍的設備，當兩台設備通過藍牙建立起了連接，考慮到更快速的數據傳輸，它就會創建點對點的WiFi網路來連接兩部iOS 設備。但並不意味著為了使用AirDrop而需要把設備連接至WiFi網路。

傳輸方式：藍牙、WiFi

支持系統：iOS

http://www.cocoachina.com/instry/20131105/7295.html

2 GameKit 框架

功能：GameKit主要是完成iOS設備間聯網的相關功能，包括藍牙和Internet兩種方式。

傳輸方式：藍牙、WiFi

支持系統：iOS

http://www.cocoachina.com/bbs/read.php?tid=97953

3 MultipeerConnectivity 框架

功能：利用Multipeer Connectivity框架，即使在沒有連接到WiFi（WLAN）或移動網路（xG）的情況下，距離較近的Apple設備（iMac/iPad/iPhone）之間可基於藍牙和WiFi（P2P WiFi）技術進行發現和連接實現近場通信。

傳輸方式：藍牙、WiFi

支持系統：iOS

http://blog.csdn.net/phunxm/article/details/43450167

4 ExternalAccessory 框架

功能：External Accessory Framework提供了配件連接iOS設備的通道。開發者可以通過它來開發連接配件的app。配件可以通過30pin、藍牙、USB的方式連接iOS設備。

傳輸方式：藍牙、WiFi

支持系統：iOS

http://www.cnblogs.com/evangwt/archive/2013/04/04/2999661.html

5 CoreBluetooth 框架

功能：藍牙4.0協議之間信息傳輸，支持iOS和Android設備。

傳輸方式：藍牙

支持系統：iOS、Android

http://blog.csdn.net/pony_maggie/article/details/26740237

6 Socket

功能：通過TCP或UDP進行相同區域網內信息傳輸，支持iOS和Android設備。

傳輸方式：WiFi

支持系統：iOS、Android

http://blog.csdn.net/kesalin/article/details/8798039

7 Bonjour

功能：Bonjour是一種能夠自動查詢接入網路中的設備或應用程序的協議。Bonjour 抽象掉 ip 和 port 的概念，讓我們聚焦於更容易為人類思維理解的 service。通過 Bonjour，一個應用程序 publish 一個網路服務 service，然後網路中的其他程序就能自動發現這個 service，從而可以向這個 service 查詢其 ip 和 port，然後通過獲得的 ip 和 port 建立 socket 鏈接進行通信，支持iOS和Android設備。

傳輸方式：WiFi

支持系統：iOS、Android

http://www.cnblogs.com/kesalin/archive/2011/09/15/cocoa_bonjour.html

8 AllJoyn

功能:AllJoyn，由高通公司主導的高創新中心的開源項目開發的，主要用於近距離無線傳輸，通過WiFi或藍牙技術，定位和點對點文件傳輸。支持平台：RTOS、Arino、Linux、Android、iOS、Windows、Mac。

傳輸方式：藍牙、WiFi

支持系統：RTOS、Arino、Linux、Android、iOS、Windows、Mac

https://allseenalliance.org/framework/documentation/develop/tutorial/ios

G. Android-Socket

由於二者不屬於同一層面，所以本來是沒有可比性的。但隨著發展，默認的Http里封裝了下面幾層的使用，所以才會出現Socket & HTTP協議的對比：（主要是工作方式的不同）：

Socket可理解為一種特殊的文件，在伺服器和客戶端各自維護一個文件，並使用SocketAPI函數對其進行文件操作。在建立連接打開後，可以向各自文件寫入內容供對方讀取或讀取對方內容，通信結束時關閉文件。在UNIX哲學中「一切皆文件」，文件的操作模式基本為「打開-讀寫-關閉」三大步驟，Socket其實就是這個模式的一個實現。

創建socket的時候，也可以指定不同的參數創建不同的socket描述符，socket函數的三個參數分別為：

當我們調用socket創建一個socket時，返回的socket描述字它存在於協議族（address family，AF_XXX）空間中，但沒有一個具體的地址。如果想要給它賦值一個地址，就必須調用bind()函數，否則就當調用connect()、listen()時系統會自動隨機分配一個埠。

int bind(int sockfd, const struct sockaddr *addr, socklen_t addrlen);
函數的三個參數分別為：

如果作為一個伺服器，在調用socket()、bind()之後就會調用listen()來監聽這個socket，如果客戶端這時調用connect()發出連接請求，伺服器端就會接收到這個請求。

TCP伺服器端依次調用socket()、bind()、listen()之後，就會監聽指定的socket地址了。TCP客戶端依次調用socket()、connect()之後就想TCP伺服器發送了一個連接請求。TCP伺服器監聽到這個請求之後，就會調用accept()函數取接收請求，這樣連接就建立好了。之後就可以開始網路I/O操作了，即類同於普通文件的讀寫I/O操作。

注意：accept的第一個參數為伺服器的socket描述字，是伺服器開始調用socket()函數生成的，稱為監聽socket描述字；而accept函數返回的是已連接的socket描述字。一個伺服器通常通常僅僅只創建一個監聽socket描述字，它在該伺服器的生命周期內一直存在。內核為每個由伺服器進程接受的客戶連接創建了一個已連接socket描述字，當伺服器完成了對某個客戶的服務，相應的已連接socket描述字就被關閉。

萬事具備只欠東風，至此伺服器與客戶已經建立好連接了。可以調用網路I/O進行讀寫操作了，即實現了網咯中不同進程之間的通信！網路I/O操作有下面幾組：
read()/write()
recv()/send()
readv()/writev()
recvmsg()/sendmsg()
recvfrom()/sendto()
我推薦使用recvmsg()/sendmsg()函數，這兩個函數是最通用的I/O函數，實際上可以把上面的其它函數都替換成這兩個函數。

從圖中可以看出，當客戶端調用connect時，觸發了連接請求，向伺服器發送了SYN J包，這時connect進入阻塞狀態；伺服器監聽到連接請求，即收到SYN J包，調用accept函數接收請求向客戶端發送SYN K ，ACK J+1，這時accept進入阻塞狀態；客戶端收到伺服器的SYN K ，ACK J+1之後，這時connect返回，並對SYN K進行確認；伺服器收到ACK K+1時，accept返回，至此三次握手完畢，連接建立。

總結：客戶端的connect在三次握手的第二個次返回，而伺服器端的accept在三次握手的第三次返回。

某個應用進程首先調用close主動關閉連接，這時TCP發送一個FIN M；
另一端接收到FIN M之後，執行被動關閉，對這個FIN進行確認。它的接收也作為文件結束符傳遞給應用進程，因為FIN的接收意味著應用進程在相應的連接上再也接收不到額外數據；
一段時間之後，接收到文件結束符的應用進程調用close關閉它的socket。這導致它的TCP也發送一個FIN N；
接收到這個FIN的源發送端TCP對它進行確認。
這樣每個方向上都有一個FIN和ACK。

所謂短連接，即連接只保持在數據傳輸過程，請求發起，連接建立，數據返回，連接關閉。它適用於一些實時數據請求，配合輪詢來進行新舊數據的更替。

https://github.com/nuisanceless/MySocketDemo
https://github.com/xuuhaoo/OkSocket

H. android、ios客戶端和伺服器通信一般使用什麼方式，各有什麼優缺點

1、從網路協議上來看，就http方式和socket方式。
2、http方式開發起來效率想對要高一點，但是對於推送這種來說，想對要難做點，因為http是短連接。socket這種方式開發要長，調試略微麻煩，但是做推送想對簡單，可以建立一個長連接。
3、Web Service服務其實也是基於HTTP協議（它基於SOAP協議，而SOAP又是基於HTTP協議）。
最大缺點我覺得是Web Service實在是太厚重了，特別對於移動端來說，WSDL是基於XML，XML已經夠厚重了，WSDL還有一些頭信息，更加厚重。
而且JSON + HTTP的方式，相對來說就非常輕量級了，JSON格式數據本生就是Javascript中的數據或者對象，所以在網路傳輸中具有非常明顯優勢，可以說本來就是網路傳輸用的，毫無違和感嘛：）
還有一個不能算缺點的缺點：目前移動端HTTP網路庫多的要死，Web Service我所知道就是ksoap2，而且非常的難用。。。

I. android socket請求數據怎麼抓包

從網路上面搜索到的資料看，要抓取手機中app的網路包有下面幾種方式：(1).將tcpmp移植到Android平台，然後在命令行下啟動tcpmp進行抓包。Tcpmp程序實際上可以看作是wireshark的命令行版本，將該程序移植到Android平台直接抓包，這是一種最直接的抓包方式，然後將抓獲的數據包文件，從手機傳到windows系統上用wireshark打開進行分析，這種方式貌似不能用於蘋果手機。(2).使用fiddler，在windows系統上打開fiddler軟體，該軟體會將我們的電腦變成一個代理，然後在手機上設置wifi網路，將代理指定為開啟fiddler的那台電腦，並且埠設置為fiddler偵聽的8888埠，這時候使用手機訪問的數據，就會通過該代理，在fiddler中就可以看到http的數據包。這種方法我試了半天怎麼都看不到數據包，不知道哪裡出問題了，根據原理，這種方式支持可以通過代理訪問網路的手機。所以從原理上說是支持Android和蘋果手機的。(3).通過各種方式在pc電腦上建立wifi熱點，然後使用wireshark在pc電腦上監視該wifi熱點，通過手機連接該熱點訪問網路。這樣wireshark會獲取所有流經該熱點的數據包這種方式適用於所有能夠無線訪問的手機，也就是說所有的Android和蘋果手機。那麼如何在pc電腦上建立wifi熱點呢，有這么幾種辦法：(1).Win7電腦經過設置，可以將無線網卡設置為wifi熱點，這種方法我以前用過，可以成功，但是步驟繁瑣，而且不一定能夠成功，其他的windows系統估計就沒戲了。(2).使用軟體自動建立wifi熱點，不需要自己手工配置，這樣的軟體有Connectify Hotspot，獵豹免費wifi，360免費wifi軟體，這幾個軟體我都使用過，比較好用，這種方式同樣也只能針對有無線網卡的筆記本電腦，原理也是將筆記本電腦上的無線網卡建立熱點了，只不過是軟體自動的，不需要人工設置，比方法1要方便。注意：經過實驗發現，手機連接這種方式建立的熱點，所發送的數據，用wireshark去抓包，需要捕獲電腦上本身聯網的那個「網路連接」，例如我的筆記本上面有一個「本地連接」，該連接是使用有線網路的。我用獵豹免費wifi軟體建立一個熱點之後，我的電腦上多出一個「無線網路連接3」，可以看到該「無線網路連接3」是獵豹生成的，但是我抓包的時候，wireshark需要捕獲「本地連接」上的包，也就是我的手機訪問的數據實際上還是使用的「本地連接」，通信IP也是「本地連接」上的IP地址，而在手機的wifi連接設置中看到的ip地址，在我抓的包中也搜不到，也就是說手機通過該熱點訪問網路，實際上還是使用的「本地連接」的IP地址，至於是什麼原理，我目前也不太清楚。但是下面要說的隨身wifi硬體則與此不同，隨身wifi是建立了網卡。(3).使用隨身wifi硬體。這種也是很方便的方法，而且比較穩定，對筆記本電腦和台式機都可以使用。我之前買了一個360的隨身wifi(不是打廣告，本人對360公司不感冒，但是他的隨身wifi做的確實還可以，同事中有買小米wifi的，不太穩定)。只要在360的官網上下載驅動，直接插上隨身wifi就可以使用，我推薦使用這種方法。如果你用的是筆記本電腦可以使用方法2，如果是台式機器可以使用方法3。android socket請求數據怎麼抓包

J. iOS 可以使用socket進行遠程消息推送嗎

ios可以使用socket,但是要想做到遠程推送可能還是需要apns機制,因為應用退到後台的時候只有apns能處理蘋果伺服器推送來的消息。iOS使用Socket的常用方式有如下： （1）BSD Socket：是UNIX系統中通用的網路介面，基於C語言，比較底層
（2）CF Socket：蘋果官方提供，來自於CoreFoundation框架
（3）AsyncSocket：對BSD Socket的封裝，OC語言
（4）ysocket：對BSD Socket的封裝，Swift語言
SOCKET原理：套接字（socket）是通信的基石，是支持TCP/IP協議的網路通信的基本操作單元。是網路通信過程中端點的抽象表示，包含進行。
建立Socket連接至少需要一對套接字，其中一個運行於客戶端，稱為ClientSocket，另一個運行於伺服器端，稱為ServerSocket。建立連接時所需的定址信息為IP地址和埠號。
進行遠程消息推送可以了解一下極光，極光就挺不錯的。JPush iOS 推送相比直接向 APNs 推送減少開發及維護成本：應用開發者不需要去開發維護自己的推送伺服器與 APNs 對接。集成了 JPush iOS SDK 後不必自己維護更新 device token。
通過 JPush 的 Web Portal 直接推送，也可以調用 JPush 的 HTTP 協議 API 來完成，開發工作量大大減少。