1、百度貼吧安卓客戶端網絡通信行為分析目 錄一、實驗環境與結果概述11.1 實驗環境11.2 結果概述1二、登錄行為分析32.1 登錄請求32.2 登錄結果3三、“進吧”相關操作分析53.1 選擇“進吧”功能區53.2 進入某一個吧63.3 看帖73.4 回帖93.5 發帖93.6 簽到10四、“個人中心”相關操作分析114.1 查看“我喜歡的吧”114.2 查看“我的關注”124.3 查看“我的粉絲”124.4 查看“我的收藏”124.5 查看“我的消息”134.6 查看“我的帖子”144.7 查看“我的微貼”154.8 查看“設置->個人資料”164.9 修改“設置->個人資料”1

2、7五、其他操作及行為分析185.1 首頁185.2 身邊18 定位18 查看“身邊的微貼”205.2.3 查看“身邊的吧”205.3 注銷21一、實驗環境與結果概述1.1 實驗環境手機型號：HUAWEI C8812操作系統：應用版本：百度貼吧分析工具：Tcpdump for Android，WireShark 1.2 結果概述百度貼吧客戶端的所有重要通信行為都使用了HTTP協議。貼吧客戶端發出的HTTP請求一般采用POST方法，表1-1對比展示了不同操作對應的請求報文。其中application/x-www-form-urlencoded格式將請求正文分成多個元素，各元素本身由名和值（可能使用

3、URL編碼）組成，各元素之間使用&符號隔開；multipart/form-data格式被用在使用POST方法發送HTML表單時，請求正文被分隔符（由boundary定義）分割成很多子段，每個子段可以自定義子段名稱和值，從而實現在單個消息實體中封裝多個主體的功能。表1-1 不同操作對應的POST請求對比操作請求行URIHost正文格式正文特殊元素個人中心查看“我喜歡的吧”/c/f/forum/likec.tieba.application/x-www- form-urlencodedBDUSS查看“我的收藏”/c/f/post/threadstoreBDUSS,user_id查看“我的關

4、注”/c/u/follow/pageBDUSS查看“我的粉絲”/c/u/fans/pageBDUSS查看“回復我的”消息/c/u/feed/replymeBDUSS,pn,uid查看“我的”消息/c/u/feed/atmeBDUSS,pn,uid查看“我的帖子”/c/u/feed/mypostBDUSS,pn查看“我的微貼”/c/u/feed/ssfBDUSS,pn,rn,uid查看“個人資料”/c/u/user/profileBDUSS,uid修改“個人資料”/c/c/profile/modifymultipart/form-data; boundary=BDUSS,intro,sex進吧點

5、擊“進吧”/c/f/forum/favocommendc.tieba.application/x-www- form-urlencodedBDUSS進入某吧/c/f/frs/pageBDUSS,kw在某吧“簽到”/c/c/forum/signBDUSS,kw看帖/c/f/pb/pageBDUSS,kz回帖/c/c/post/addBDUSS,content,kw,tid發帖/c/c/thread/addBDUSS,content,kw,title身邊點擊“身邊”【定位1】/sdk.phploc.map.application/x-www- form-urlencodedqt,req點擊“身邊”

6、【定位2】/sdk.phpbloc獲取“身邊的微貼”/c/f/lbs/threadc.tieba.BDUSS,guide,height,ispv,lat,lng,pn獲取“身邊的吧”/c/f/lbs/forumBDUSS,ispv,lat,lng首頁登錄/c/s/loginc.tieba.application/x-www- form-urlencodedpasswd,un注銷/c/s/loginoutbduss退出【未注銷】后重啟/c/s/msgBDUSS點擊“首頁”/c/s/tag/allthreadBDUSS服務器返回的響應有著類似的頭部，如圖1-1所示。圖1-1 貼吧服務器返回的響應頭

7、部狀態行一般為HTTP/1.1 200 OK，正文的類型一般純文本文件，正文本身一般經過gzip編碼壓縮，且在傳輸過程中一般使用了chunked編碼進行分塊傳輸。后文在說到響應正文時，一般是指重組解壓后的正文，后文中不再特別指出這一點。一個簡單的正文示例如圖1-2所示。圖1-2 一個最簡單的響應正文示例如上圖，還原出來的完整響應正文普遍使用了JSON格式，該數據格式的特征是所有數據處于一對大括號 內。正文一般分成多個段，每個段由名和值組成，段與段之間用逗號隔開。有些段的值會由多個子段構成，一個段的所有子段也會用一對方括號 或是大括號 括起來。大部分情況下，有四個一級段在正文是都存在的，包括：e

8、rror_code（操作成功時值為0，操作失敗時為對應錯誤代碼）、time、ctime，以及logid。【由于作者在完成分析的時候還不知道JSON，所以后文的相關描述沒有用到JSON格式的特點，顯得不否簡練。但要表達的東西還是完整的，所以不再更改。】【我們約定，與error_code處在同一層次的稱為一級段，一級段的子段為二級段，以此類推。】下面就各行為做具體分析。二、登錄行為分析2.1 登錄請求登錄時，貼吧客戶端使用一個POST請求來提交認證信息。該登錄請求的請求行使用固定的URI：/c/s/login。由請求行的特征和Host頭域的值可以確定一個登錄行為。圖2-1展示了當登錄用戶名為xin

9、hua0123，登錄口令為fengping888時，該請求報文的具體形式。圖2-1 一個登錄請求報文示例請求報文的正文中存在變化過的登錄口令和明文的用戶名，其特征分別如下：u 變化后的口令前綴特征：passwd=u 用戶名前綴特征：un=口令與用戶名的結束標志均為&。貼吧客戶端在發送登錄請求前先對明文口令fengping888進行了Base64編碼，得到中間結果ZmVuZ3Bpbmc4ODg=，接著再對中間結果進行了URL編碼，由此得到最終結果ZmVuZ3Bpbmc4ODg%3d。2.2 登錄結果登錄的結果在前述請求所對應的響應報文中。該響應報文的頭部類似于圖1-1所示的范例，其響應正

10、文根據登錄的結果不同而格式不同。圖2-2分別展示了登錄成功和失敗時，所對應的響應正文。(a)登錄失敗后響應正文(b)登錄成功后響應正文圖2-2 登錄請求的響應正文如上圖，登錄成功與否可以根據error_code的值來判定，若為0，則成功。登錄失敗后的響應正文里存在名為error_msg的一級段，其值為服務器返回的錯誤提示信息的Unicode編碼，如上圖(a)，將u5bc6u7801u9519u8befuff0cu8bf7u91cdu65b0u8f93u5165轉換為對應的Unicode字符，為：密碼錯誤，請重新輸入。這個錯誤信息將會顯示在貼吧客戶端，如圖2-3.所示。圖2-3 登錄失敗后貼吧客

11、戶端給出錯誤提示“密碼錯誤，請重新輸入”登錄成功后，服務器所給響應正文中一個比較重要的段是user，其子段中包含一些重要信息，一是登錄用戶的id和用戶名，另一個是BDUSS。BDUSS是貼吧服務器在用戶每次登錄成功后所給出的一個通行證，以后用戶在進行一些非匿名的操作時，就不用每次都重復登錄，只需在請求正文中包含BDUSS即可。BDUSS在用戶注銷登錄后失效，再次登錄獲得的BDUSS和上次不同。但尚不清楚BDUSS是否存在最長有效期（即在超過某個時限后不論用戶是否注銷登錄，均強制失效）。推測在有效期內，通過BDUSS應該可以冒充登錄用戶進行操作，尚未進行驗證。在貼吧客戶端上有“首頁”、“進吧”、

12、“身邊”、“個人中心”四大功能區，下面按使用頻率依次進行分析。三、“進吧”相關操作分析3.1 選擇“進吧”功能區點擊“進吧”后，客戶端發出一個POST請求，其請求行URI固定為/c/f/forum/favocommend，Host頭域的值為。請求正文以BDUSS=開始，其值與登陸成功后服務器所返回的響應中一致。請求正文中另外還有的信息包括：客戶端類型、版本，時間戳等，如圖3-1。圖3-1 點擊“進吧”后發出的請求報文服務器返回的響應頭部與圖1-1基本一致，解壓后的響應正文如圖3-2所示。圖3-2 點擊“進吧”后服務器的響應正文正文以error_code段開始，其值為0，表明本次操作成功。正文中

13、最重要的是一個名為forum_list的一級段，這其實是一個貼吧列表。列表的每一個表項都用一對大括號 括起來，一個表項里的子段包括：name（貼吧名，使用Unicode編碼）、id（貼吧的標識號）、is_like（是否喜歡，由于百度貼吧現在點擊“喜歡”自動成為一級會員，故此等價于用戶是否為該吧會員）、favo_type、level_id（用戶在該吧的等級）、member_count、avatar以及slogan。對比點擊“進吧”后貼吧客戶端所顯示的內容（如圖3-3所示），我們發現forum_list這個貼吧列表正是客戶端進入“進吧”后所顯示的貼吧列表。圖3-3 點擊“進吧”以后3.2 進入某一

14、個吧在“進吧”選擇列表中某一個吧點擊后，客戶端發出一個POST請求，其請求行URI固定為/c/f/frs/page，Host頭域的值為。請求正文以BDUSS=開始，其值與登陸成功后服務器所返回的響應中一致。正文中特征串kw=后是本次請求所要進入的貼吧名，其結束標志是&。當進入linux吧時，請求報文如圖3-4所示。圖3-4 進入linux吧時客戶端發出的請求服務器給出的響應頭部類似于圖1-1，正文以error_code段開始，其值為0，表明本次操作成功。后面的一級段中比較重要的包括user（用戶信息）、forum（貼吧信息）、managers（貼吧管理員信息）以及thread_list

15、（貼吧首頁的帖子列表）。前面幾個段都很簡單，直接就能找到特征，表3-1對一些信息的特征做了匯總。表3-1 進入某一個吧服務器所給響應中的一些信息特征段名含義所屬父段示例id用戶IDuser288130111name用戶名/昵稱xinhua0123is_manager用戶是否為貼吧管理員0【不是管理員】id貼吧IDforum3171name貼吧名linuxfirst_class貼吧所屬一級分類u79d1u5b66u6280u672f【科學技術】second_class貼吧所屬二級分類u8ba1u7b97u673au8f6fu4ef6【計算機軟件】is_like用戶是否為貼吧會員1【是會員】use

16、r_level用戶在貼吧的會員等級3level_name用戶在貼吧的稱號-wxmember_num貼吧會員總數26274thread_num貼吧帖子總數61346post_num貼吧發言數751557current_rank_info貼吧簽到數當前排名forum/sign_in_info/forum_info"sign_count":"1532","sign_rank":"18","member_count":"25625","dir_rate":&quo

17、t;0.1"yesterday_rank_info貼吧簽到數昨日排名weekly_rank_info貼吧簽到數上周排名"sign_count":"2629","sign_rank":"19","member_count":"25610"monthly_rank_info貼吧簽到數上月排名id貼吧管理員IDmanagers3943785name貼吧管理員昵稱typhoon_wolf下面詳細解說相對復雜的thread_list一級段。前文說過這是一個帖子列表，圖3-5是

18、列表中某一個具體的表項，它處于一對大括號 內。圖3-5 thread_list列表中某表項的數據如上圖，幾個子段的含義為：id是帖子的ID，title是帖子的標題【使用了Unicode編碼】，reply_num是回復數，view_num是點擊數，last_time是最后回復日期，last_time_int是最后回復時間，is_top表示是否置頂【為1置頂】，author里是作者信息，last_replyer里時最后回復人的信息，abstract是帖子的摘要信息。3.3 看帖用戶在貼吧里點擊某篇帖子之后，客戶端發出一個POST請求，其請求行URI固定為/c/f/pb/page，Host頭域的值為

19、。請求正文以BDUSS=開始，其值與登陸成功后服務器所返回的響應中一致。正文中特征串kz=后是本次請求所要閱讀的帖子ID，請求報文如圖3-6所示。圖3-6 點擊某篇帖子之后發出的請求示例服務器給出的響應頭部類似于圖1-1，正文以error_code段開始，其值為0，表明本次操作成功。后面的一級段中比較重要的包括user（所看帖子的作者信息）、forum（貼吧信息）以及post_list（帖子的具體內容）。其中user與forum兩個一級段的分析大致與前文一致或類似，下面詳細分析一下post_list這個段。post_list其實是一個帖子【稱為主貼】的正文，所有對它的回復【為了便于區分，后文以

20、“樓層”代稱】，以及所有對它回復的回復【為了表達簡介，后文以“回復”代稱】。我們知道在貼吧中，帖子的正文往往稱為一樓，對帖子本身的回復稱為按照先后順序分別稱為二樓、三樓而且這些樓層本身也算發帖，會有帖子ID。post_list的所有內容用一對方括號 括起來，里面的每個子段（我們稱為二級段）對應帖子里面的一層樓。圖3-7是post_list的某一個二級段示例。圖3-7 post_list列表中某表項的數據 如上圖，幾個二級段的含義為：id是該樓層的ID，title是樓層的標題（使用了Unicode編碼，一樓的標題是整個主貼的標題，二樓及以后的標題是主貼的標題前加上“回復：”），floor是樓層編

21、號，content是樓層的正文，author是建樓者的信息， sub_post_list是本樓層里的所有回復信息的綜述，他也有一個叫sub_post_list的子段（我稱之為三級段），里面是對本樓層的回復列表，這個列表的每個表項對應本樓層每條回復的詳細信息，包括：author（回復者的信息）、id（回復的ID）、content（回復的正文），以及floor（相當于子樓層數）。3.4 回帖當我們點擊“回復”后，客戶端發出一個POST請求，其請求行URI固定為/c/c/post/add，Host頭域的值為。請求正文以BDUSS=開始，其值與登陸成功后服務器所返回的響應中一致。正文中還有三處重要的信

22、息，分別是回復的內容（中文使用url編碼）、被回復貼所在的貼吧的名字（中文使用url編碼）、被回復貼子的ID。他們的前綴特征分別為content=、kw=、tid=，后綴特征為&。當在四川大學吧回復一個ID為2404920336的帖子，回復內容為”too bad !”時，請求報文如圖3-8所示。圖3-8 回帖時客戶端發送的請求示例服務器返回的響應比較簡單，頭部和正文分別和圖1-1、1-2類似。響應正文中比較重要的是error_code的值，為0的時候說明回復成功。3.5 發帖當我們點擊“發帖”后，客戶端發出一個POST請求，其請求行URI固定為/c/c/thread/add，Host頭

23、域的值為。請求正文則如圖3-9所示。圖3-9 發帖時客戶端發送的請求正文示例如上圖，請求正文以BDUSS=開始，其值與登陸成功后服務器所返回的響應中一致。正文中還有三處重要的信息，分別是所發帖子的內容（中文使用url編碼）、發貼所在貼吧的名字（中文使用url編碼）、所發貼子的標題（中文使用url編碼）。他們的前綴特征分別為content=、kw=、title=，后綴特征為&。 服務器返回的響應比較簡單，頭部和正文分別和圖1-1、1-2類似。響應正文中比較重要的是error_code的值，為0的時候說明回復成功。3.6 簽到用戶在某貼吧里點擊“簽到”后，客戶端發出一個POST請求，其請求

24、行URI固定為/c/c/forum/sign，Host頭域的值為。請求正文以BDUSS=開始，其值與登陸成功后服務器所返回的響應中一致。正文中特征串kw=后是本次所要簽到的的貼吧名（中文使用url編碼），其結束標志是&。當在三國殺吧簽到時，請求報文如圖3-10所示。圖3-10 在“三國殺”吧點擊“簽到”后客戶端發出的請求報文示例 服務器返回的響應頭部與圖1-1基本一致，解壓后的響應正文如圖3-11所示。圖3-11 點擊“簽到”后服務器的響應正文如上圖，正文以user_info一級段開始，其值由多個子段構成，含義分別為：is_sign_in表示簽到是否成功，user_sign_rank的

25、值表示用戶第幾個簽到，sign_time表示用戶簽到時間，cont_sign_num表示用戶本月連續簽到數，cont_total_sign_num表示用戶本月累計簽到數。在整個user_info一級段之后是在1.2節中提到的四個常見一級段。四、“個人中心”相關操作分析 如圖4-1所示，“個人中心”中進行的會引起網絡通信行為的常見操作包括查看“我喜歡的吧”、“我的關注”、“我的粉絲”、“我的收藏”、“我的消息”、“我的帖子”、“我的微貼”，以及在“設置”里查看和修改個人資料。下面分別進行分析。圖4-1 貼吧客戶端-個人中心4.1 查看“我喜歡的吧”當用戶在“個人中心”點擊“我喜歡的吧”后，客戶端

26、發出一個POST請求，其請求行URI固定為/c/f/forum/like，除此之外，整個請求的構造與點擊“進吧”后（見圖3-1）基本一致。服務器返回的響應頭部與圖1-1基本一致，解壓后的響應正文也與點擊“進吧”后類似，以error_code段開始，其值為0，表明本次操作成功。正文中最重要的也是一個名為forum_list的貼吧列表。不同的是，此處forum_list列表中是用戶已經成為會員的貼吧（4.1節中返回的列表是用戶常逛的貼吧），排列順序依照用戶的等級由高到低（4.1節中返回的列表按照用戶近期訪問頻率排列）。這個列表中每個表項的構成也與4.1節中不同，圖4-2是這個列表中的一個表項示例。

27、圖4-2 forum_list中某表項的數據 該表項中幾個重要的子段包括：id（貼吧ID）、name（貼吧名，使用Unicode編碼）、level_id（用戶在本吧的等級）、level_name（用戶在本吧的稱號，使用Unicode編碼）。4.2 查看“我的關注”當用戶在“個人中心”點擊“我的關注”后，客戶端發出一個POST請求，其請求行URI固定為/c/u/follow/page，除此之外，整個請求的構造與點擊“進吧”后（見圖3-1）基本一致。服務器返回的響應頭部與圖1-1基本一致，解壓后的響應正文如圖4-3所示。圖4-3 點擊“我的關注”后服務器返回的響應正文如上圖，正文以error_co

28、de段開始，其值為0，表明本次操作成功。在page一級段中有一個total_count子段，其值為用戶所關注的用戶數。正文中最重要的一級段是user_list，是用戶所關注用戶的列表。與前文提到的一些列表類似，列表的所有表項處于一對方括號內，表項之間用逗號隔開，每個表項的所有子段都用一個大括號 括起來。每個表項中幾個重要的二級段包括：id（所關注用戶的ID）、name（所關注用戶的昵稱，使用Unicode編碼）、intro（所關注用戶的自我簡介，使用Unicode編碼）。4.3 查看“我的粉絲”當用戶在“個人中心”點擊“我的粉絲”后，客戶端所發出請求的結構與點擊“我的關注”后完全一致，但其請求

29、行URI固定為/c/u/fans/page。服務器給出的響應報文的結構也與點擊“我的關注”后完全一致4.4 查看“我的收藏” 當用戶在“個人中心”點擊“我的收藏”后，客戶端發出一個POST請求，其請求行URI固定為/c/f/post/threadstore，Host頭域的值為。如圖4-4所示，請求正文以BDUSS=開始，其值與登陸成功后服務器所返回的響應中一致。正文中特征串user_id=后客戶端用戶的ID，其結束標志是&。圖4-4點擊“我的收藏”后客戶端發出的請求正文示例服務器返回的響應頭部與圖1-1基本一致，解壓后的響應正文如圖4-5所示。圖4-5點擊“我的收藏”后服務器返回的響應

30、正文從上圖可以看到，此處的響應正文與其他操作的一個很大不同在于，它的第一個一級段不再是error_code，而是store_thread。這是一個收藏的帖子列表，和前文提到的一些列表相同，這個列表的所有表項處于一對方括號內，表項之間用逗號隔開，每個表項的所有子段都用一個大括號 括起來。每個表項中幾個重要的二級段包括：thread_id（帖子的ID）、title（帖子的標題）、forum_name（帖子所在的貼吧）、author（帖子的作者信息）、reply_num（帖子的回復數）。error_code這個一級段并非不存在了，只是移到了倒數第四個。在它的前面還有一個名為error的一級段，似乎和

31、error_code所表達的信息一致。4.5 查看“我的消息”“我的消息”分為“回復我的”和“我的”兩種。要完整取回這兩類消息，客戶端會發出兩個POST請求。以查看“回復我的”消息為例，報文范例如圖4-6所示。圖4-6 查看“回復我的”消息時客戶端發出的請求從上圖可以看到，請求行的URI固定為/c/u/feed/replyme，Host頭域的值為。請求正文以BDUSS=開始，其值與登陸成功后服務器所返回的響應中一致。和點擊“進吧”后所發請求不同的是，多了名為pn和uid的元素。前者含義未知，后者是請求用戶的ID。服務器返回的響應頭部與圖1-1基本一致，解壓后的響應正文以error_code段開

32、始，其值為0，表明本次操作成功。正文中最重要的一級段是reply_list，是回復消息的列表。與前文提到的一些列表類似，列表的所有表項處于一對方括號內，表項之間用逗號隔開，每個表項的所有子段都用一個大括號 括起來。圖4-7是一個具體的表項示例。圖4-7 reply_list中某表項的數據 該表項中幾個重要的子段包括：is_floor（為0表示是對一個帖子的直接回復，為1表示是對一個帖子中某一樓層的回復）、unread（為1表示用戶尚未閱讀本消息，為0表示已閱讀）、replyer（回復者的信息）、title（主貼的標題）、content（回復的內容）、thread_id（所在主貼的ID）、pos

33、t_id（樓層的ID），以及fname（回復所在貼吧的名字，中文用Unicode編碼）。查看“我的”消息時，客戶端所發請求報文的結構與查看“回復我的”消息時完全一致，只是請求行的URI不同，固定為/c/u/feed/atme。服務器所返回響應也與查看“回復我的”消息時基本一致，只不過在reply_list一級段對應的位置變成了at_list，這是客戶端用戶的消息列表，表項的結構如圖4-8所示。圖4-8 at_list中某表項的數據該表項中幾個重要的子段包括： replyer（發出者的信息）、title（主貼的標題）、content（含有的帖子/回復內容）、thread_id（所在主貼的ID）、

34、post_id（樓層的ID），以及fname（主貼所在貼吧的名字，中文用Unicode編碼）。4.6 查看“我的帖子”當用戶在“個人中心”點擊“我的帖子”后，客戶端發出一個POST請求，其請求行URI固定為/c/u/feed/mypost。如圖4-9所示，整個請求報文的結構與點擊“進吧”后類似，不同的是正文中多了名為pn的元素，含義未知。圖4-9點擊“我的帖子”后客戶端發出的請求報文示例服務器返回的響應頭部與圖1-1基本一致，解壓后的響應正文以error_code段開始，其值為0，表明本次操作成功。正文中最重要的一級段是post_list，是客戶端使用者所發帖子的列表。與前文提到的一些列表類似

35、，列表的所有表項處于一對方括號內，表項之間用逗號隔開，每個表項的所有子段都用一個大括號 括起來。圖4-10是一個具體的表項示例。圖4-10 post_list中某表項的數據 該表項中幾個重要的子段包括：author（發帖者信息）、title（主貼的標題，中文使用Unicode編碼）、fname（發帖所在貼吧，中文使用Unicode編碼）、reply_time（發帖日期）、reply_num（主貼的回復數）、pid（用戶所發帖子的ID）、tid（主貼的ID），以及is_floor（為1表明這是回復貼，為0表示這是發表貼）。4.7 查看“我的微貼”當用戶在“個人中心”點擊“我的微帖”后，客戶端發出

36、一個POST請求，其請求行URI固定為/c/u/feed/ssf。如圖4-11所示，正文中多了名為rn的元素，含義未知。除此之外，整個報文的結構與查看“回復我的”消息時基本一致。圖4-11點擊“我的微貼”后客戶端發出的請求正文示例服務器返回的響應頭部與圖1-1基本一致。如圖4-12所示，解壓后的響應正文以error_code段開始，其值為0，表明本次操作成功。正文中最重要的一級段是thread_list，是客戶端使用者所發微貼的列表。由于當前為空，所有列表內部結構尚未分析。圖4-12點擊“我的微貼”后服務器返回的響應正文4.8 查看“設置->個人資料”在“個人中心”的右上角有“設置”，點

37、進去后的第二項叫“個人資料”，點擊后即可查看個人資料，如圖4-13所示。圖4-13 查看個人資料在這個過程中，客戶端也會發送一個POST請求，其請求行URI固定為/c/u/user/profile，Host頭域的值為。如圖4-14，請求正文以BDUSS=開始，其值與登陸成功后服務器所返回的響應中一致。正文中有uid元素，值為客戶端用戶的ID。圖4-14 查看個人資料時客戶端發出的請求正文示例服務器返回的響應頭部與圖1-1基本一致。如圖4-12所示圖4-15 查看個人資料時服務器返回的響應正文 如上圖，響應正文中最重要的是user這個一級段。組成其值的幾個重要子段分別為： id（用戶ID）、na

38、me（用戶名，客戶端上有顯示）、intro（用戶個人簡介，中文使用Unicode編碼，客戶端上有顯示）、sex（用戶性別，客戶端上有顯示）、like_forum_num（用戶喜歡的貼吧數，即用戶已成為會員的貼吧數）、concern_num（用戶關注的用戶數）、fans_num（用戶擁有的粉絲數）。4.9 修改“設置->個人資料”在“個人資料”的右上角有“保存”按鈕，點擊后即可完成修改個人資料。在這個過程中，客戶端會發出一個POST請求，其請求行URI固定為/c/c/profile/modify，Content-Type頭域的值為multipart/form-data ; boundary

39、=-7da3d81520810*，表明正文采用了multipart/form-data格式，正文各子段之間使用“-7da3d81520810*”作為分隔符。請求正文如圖4-16所示（由于報文過長，部分不重要的子段被省略，用代替）。圖4-16 修改“個人資料”時客戶端發出的請求正文如上圖，正文以“-7da3d81520810*”標志開始，以“-7da3d81520810*-”標志結束。正文中比較重要的子段的name分別為：BDUSS（登錄憑證）、intro（個人簡介）和sex（性別）。BDUSS子段的值與登陸成功后服務器所返回的響應中一致；intro子段的值是圖4-13中“個人簡介”的信息（中文

40、使用UTF-8字符集）；sex子段的值對應圖4-13中的“性別”信息，男為1，女為2。服務器返回的響應比較簡單，頭部和正文分別和圖1-1、1-2類似。響應正文中比較重要的是error_code的值，為0的時候說明修改成功。五、其他操作及行為分析5.1 首頁點擊“首頁”后，客戶端發出一個POST請求，其請求行URI固定為/c/s/tag/allthread，Host頭域的值為。請求正文以BDUSS=開始，其值與登陸成功后服務器所返回的響應中一致。請求正文中另外還有的信息包括：客戶端類型、版本，時間戳等，如圖5-1。圖5-1點擊“首頁”后發出的請求報文 服務器返回的響應頭部與圖1-1基本一致。與其

41、他操作返回的正文格式為純文本文件不同，此處的響應正文是一個標準html文件。由于正文里沒什么重要信息，在此不作具體分析。5.2 身邊點擊“身邊”后，客戶端和服務端會進行四次重要的HTTP會話，前兩個會話用于客戶端用戶的定位，后兩個會話分別用于查看“身邊的微貼”和“身邊的吧”。下面分別進行分析。 定位在定位過程進行的兩次HTTP會話中，客戶端使用的都是POST請求，兩個請求頭部的結構類似，但與其他操作發出的請求報文結構有極大不同。首先，兩個POST的請求行URI都固定為/sdk.php；其次，請求的服務器（由請求頭部Host頭域的值指定）都變為了，而不再是其他請求中所用的。請求正文的格式（由請求

42、頭部Content-Type頭域的值指定）依舊是application/x-www-form-urlencoded。兩個請求報文的頭部、正文分別如圖5-2【a】、【b】、【c】所示。【a】定位請求的頭部示例【b】第一個定位請求的正文【c】第二個定位請求的正文圖5-2進行定位時客戶端發出的請求報文示例請求正文的含義尚未分析出來。服務器所給兩個響應的報文結構基本一致，但正文的內容有很大不同，如圖5-3所示。【a】第一個定位請求對應的響應【b】第二個定位請求對應的響應正文圖5-3 進行定位時服務器返回的響應報文示例服務器對第一個定位請求返回響應的含義尚未分析出來，但是在第二個定位請求所對應的響應正文中，我們可以還原出一些感興趣的東西