01 youtube下載器app手機端口轉發(前端抓手機抓包可以看頁面樣式嗎)

IPhone與其他手機相比好在哪里？

iPhone 是綜合實力最強的手機：各家手機都有自己的優勢，也或多或少都有短版（這幾年刷遍

Android 機的觀察），也許是為了區隔市場，也許是在擠牙膏，這個時候一年一只的 iPhone 就成為綜合

實力最強的手機了，拍照可能比不上三星，但也算是名列前茅；電池可能比不上中階 Android，但也足夠

使用一天，所以懶得研究的人，iPhone 就成為一個“不會錯”的選擇了。

系統：雖然 Android 的流暢度已經很棒了，但和 iOS 比，還是差那么一些些，Android 整體順暢，但

還是時不時會卡一下；再者，一些系統設計上的短版，也會讓用戶很麻煩。例如：iOS 卸載 App 后，就不

用管有沒有遺留什么資料在手機里，可安卓在移除 App 時，不一定會移除儲存資料的檔案夾，久而久之，

手機中充滿了不知名的檔案夾，和許多不知道能不能清的垃圾。當然可以下載某某管家、助手來幫助清

理，但總歸不是那么優雅，種種系統上的原因，最后讓我奔向了 iOS

“從樣張審美這件事看，iPhone的樣張水平是最高的“

典型的iPhone風格夜景人像，我們很難在iPhone人像夜景中看到對面部進行大范圍的補光，他們更喜歡塑造光影關系，尤其是有色光源的尋找。遠處的夕陽隱隱約約，一縷光照亮姑娘金色的發絲，加上沉穩的劇中構圖，人物的臉龐若影若現。巧妙的避開了所有手機由于傳感器限制導致的畫質弊端，但即使我有一個相機，我也更愿意拍攝這樣的作品，氛圍感好。

還有

蘋果有統一的推送。

所有的通知要先發給蘋果的服務器，服務器推送給OS，這時候應用是否在運行無所謂。

android因為google不在，那推送怎么辦呢？可以用第三方的，但是各個應用不統一啊。

而且第三方的不穩定，萬一出問題怎么辦?

于是很多APP怕自己漏通知，怎么辦呢？弄一個service不停的跑，需要不時去服務器查詢有沒有通知或者不停的告訴服務器自己的位置（IP和端口）讓服務器推送，但是這個服務萬一被殺死怎么辦？另起一個進程互相監控，其中一個被殺死立馬把另一個拉起來。萬一用戶把進程都殺死怎么辦？還可以注冊事件，例如網絡發生變化，系統啟動，來電話等事件拉起進程。

注意這只是一個APP做的事情，你腦補下你手機里有十幾個APP都在干同樣的事，你手機怎么能不耗電，怎么能不卡？你再高端的android都得面對這事。

前端抓手機抓包可以看頁面樣式嗎

時隔 3 年，重新接觸了移動端 h5 頁面開發，上一次還是大四實習。這一次是 hybrid 開發，涉及到 h5 頁面與原生 app 的交互，h5 頁面需要與原生打通登錄態，以及調用原生app 的接口，比如調用原生相機進行二維碼掃描。跟買粉絲小程序開發不同，本地開發時買粉絲有提供買粉絲開發者工具，可以本地模擬調用而我這邊需要每次都打包靜態文件，上傳服務器才能調試，非常麻煩。

能不能在原生 app 加載線上 h5 時，跑本地的代碼呢？答案是可以的，通過抓包工具比如 whistle 就可以做到攔截線上頁面請求數據，再響應本地代碼，本文主要講述抓包的原理和抓包工具 whistle 使用。

1. 抓包的原理

1.1 什么是抓包？

抓包就是將網絡傳輸發送與接收的數據包進行截獲、重發、編輯、轉存等操作，通過抓包可以：

分析網絡問題

業務分析

分析網絡信息流通量

網絡大數據金融風險控制

探測企圖入侵網絡的攻擊

探測由內部和外部的用戶濫用網絡資源

探測網絡入侵后的影響

監測鏈接互聯網寬頻流量

監測網絡使用流量（包括內部用戶，外部用戶和系統）

監測互聯網和用戶電腦的安全狀態

滲透與欺騙

...

回顧下計算機網絡知識，數據在網絡上是以很小的幀的單位傳輸的，幀通過特定的稱為網絡驅動程序的程序進行成型，然后通過網卡發送到網線上，通過網線到達目的機器，在目的機器的一端執行相反的過程。接收端機器的以太網捕獲到這些幀，并告訴操作系統幀已到達，然后對其進行存儲。在這個傳輸和接收的過程，就可以使用抓包工具（Sniffers）進行抓包，作為前端開發者，通常是抓取應用層的 HTTP/HTTPS 的包。



1.2 HTTP/HTTPS 抓包原理

HTTP/HTTPS 是應用層使用的通信協議，常見的應用層體系結構是客戶端-服務器體系。

對運行在不同端系統上的客戶端程序和服務端程序是如何互相通信的么？實際上，在操作系統上的術語中，進行通信的實際上是進程而不是程序，一個進程可以被認為是運行在端系統中的一個程序。

在 web 應用程序中，一個客戶瀏覽器進程與一臺服務器進程進行會話交換報文。

瀏覽器進程需要知道接收進程的主機地址，以及定義在目的主機中的接收進程的標識符，也就是目的端口。

多數應用程序由通信進程對組成，每對中的兩個進程互相發送報文。進程通過一個稱為套接字的軟件接口向網絡發送報文和從網絡接收報文。

進程可以類比一座房子，而它的套接字可以是它的門，套接字是應用層與運輸層之間的端口。



知道了兩個進程的通信流程，我們要怎么抓包呢？舉一個生活中的例子，小明暗戀小雯，于是他寫了一封情書，但他有點害羞，找了小雯的好朋友小花幫忙傳遞情書。這個時候，小花可以負責小雯與小明之間的情書傳遞，作為中間人，她可以偷偷查看他們的情書內容。

思路就是設置一個中間人進程負責抓包，每次目標進程之間的會話都先與中間人進程通信，再進行轉發。



1.2.1 HTTP 抓包原理

在 買粉絲 標準中，沒有對通信端身份驗證的標準。對于服務器來說，它接收的 HTTP 請求報文只要格式符合規范，就發送響應報文。

對于客戶端來說也是如此，它無法校驗服務器的身份，比如它連接的 買粉絲://買粉絲.jecyu.買粉絲 的主機，但由于中間節點的存在，最終連接的可能是 買粉絲://買粉絲.jerry.買粉絲 的主機。

因此，對于 HTTP 抓包，無需做過多的處理，只需要讓中間人負責轉發客戶端和服務端的數據包。

1.2.2 HTTPS 抓包原理

HTTP 是明文傳輸，容易受到中間人攻擊，不安全。

HTTPS 語義仍然是 HTTP，只不過是在 HTTP 協議棧中 買粉絲 與 tcp 之間插入安全層 SSL/TSL。

安全層采用對稱加密的方式加密傳輸數據和非對稱加密的方式來傳輸對稱密鑰，解決 買粉絲 數據沒有加密、無法驗證身份、數據容易纂改三個核心問題。

HTTP + 加密 + 認證 + 完整性保護 = HTTPS

其中驗證身份問題是通過驗證服務器的證書來實現的，證書是第三方組織（CA 證書簽發機構）使用數字簽名技術管理的，包括創建證書、存儲證書、更新證書、撤銷證書。



瀏覽器連接至一個 HTTPS 網站，服務器發送的不僅僅只是服務器實體證書，而是一個證書鏈，但不包含根證書，根證書會被內嵌在 Windows, Linux, macOS, Android, iOS 這些操作系統里。



其中校驗證書分為兩步，證書的簽發者校驗和服務器實體證書校驗

1、證書鏈校驗：

1.1 瀏覽器從服務器實體證書的上一級證書（比如 B 證書）獲取公鑰，用來校驗服務器實體證書的簽名（簽名是通過 CA 機構的私鑰簽名的），校驗成功則繼續，否則證書校驗失敗。

1.2 瀏覽器從 B 證書的上一級證書（比如 C 證書）獲取公鑰，用來校驗 B 證書的簽名，

校驗成功則繼續，否則證書校驗失敗。

1.3 瀏覽器迭代校驗每張證書的簽名，最后會找到自簽名的根證書（簽發者和使用者是同一個人），由于瀏覽器已經集成了根證書，可以充分信任根證書的公鑰，完成最后的簽名。

2、服務器實體證書校驗：訪問的域名信息是否與證書一致、日期、證書擴展校驗等。

了解完證書校驗后，我們來看看具體的 買粉絲s 通信流程：

首先是 tcp 的三次握手建立連接

接著是非對稱加密的握手過程

client 發送隨機數 random1 + 支持的加密算法集合

server 收到信息，返回選擇的一個加密算法+ 證書 （包含S_公鑰） + random2

client 驗證證書有效性，并用 random1 + random2 生成 pre-master-secure，通過服務端公鑰加密發送給 server

server 收到 pre-master-secure，根據約定的算法使用S_私鑰對 pre-master-secure 解密，

然后用加密算法生成 master-secure（對稱加密的密鑰），然后發送給 client

client 收到生成的 master-secure，對稱加密密鑰傳輸完畢

最后，就可以使用 master-secure 進行真正的數據對稱加密傳輸。

中間人想要抓包，需在 HTTPS 加密通信之前：

截取客戶端發送的包含證書的報文，偽裝成服務端，把自己的證書發給客戶端，然后拿到【客戶端返回的包含對稱加密通信密鑰的報文】，生成中間人與客戶端對稱加密的密鑰。

同樣偽裝成客戶端，以服務端自己的非對稱公鑰加密【客戶端返回的包含對稱加密通信密鑰的報文】發給服務端，獲得服務端生成的對稱加密密鑰。

這樣一來，加密通信建立完成，而中間人拿到了通信的數據密鑰，可以查看、修改 HTTPS 的通信報文。

這里客戶端與中間人通信、中間人與服務端通信，都是正常建立了 HTTPS 加密連接的。



其中很重要的一步是瀏覽器的根證書校驗，CA 機構不可能隨便給一個中間人簽發不屬于它的域名證書，也就不在客戶端的操作系統上了，因此只能把中間人的根證書，導入到客戶端的操作系統了，以此完成建立加密通信時對中間人證書的驗證。

1.3 電腦如何抓手機的包

要想通過電腦端獲取手機 Web 應用的數據包，根據前面所學，就需要中間人策略。

PC 端建立一個服務器中間人進程，偽裝為 web 應用的目標服務器。手機端 web 應用發送的請求數據先經過中間人，中間人進行攔截處理再發送給目標服務器。反過來，目標服務器發送的數據包先通過中間人，再由中間人響應給瀏覽器客戶端。

這里要注意的是，無論是個人電腦PC，還是移動端手機，都需要接入互聯網網絡，可以相互找到對方才能建立通信。

一般對開發來說，個人電腦本地起的服務器進程，在公網上是訪問不到的。一般是無線局域網，個人電腦與手機端連接同一個路由器發出的 Wi-Fi，就可以相互通信。



具體步驟：

在 PC 電腦本地起

很赞哦!（82）