跳到主要內容
tcpdump是Linux下的截获分析网络数据包的工具,对优化系统性能有很大参考价值。
一 安装
tcpdump不是默认安装的,在CentOS下安装:
yum install tcpdump
在Ubuntu下安装:
apt-get install tcpdump
二 开始截获
tcpdump执行很简单,就直接输入即可,不过这样会截获全部的数据包,眼花缭乱,显示的内容根本没有办法用。一般都会为它加上参数,比如:
最常用的是截获某IP的主机的网络数据包:
tcpdump host 192.168.0.123
三 分析一次完整请求
为简单明了起见,我截获了一段“干净”的数据包,显示了本机对某URL发起的一次请求的全过程:
23:30:01.828266 IP 192.168.0.251.34245 > li527-105.members.linode.com.http: Flags [S], seq 2340440979, win 14600, options [mss 1460,sackOK,TS val 237397584 ecr 0,nop,wscale 7], length 0
23:30:01.931109 IP li527-105.members.linode.com.http > 192.168.0.251.34245: Flags [S.], seq 64288983, ack 2340440980, win 14480, options [mss 1440,sackOK,TS val 3220226885 ecr 237397584,nop,wscale 7], length 0
23:30:01.931221 IP 192.168.0.251.34245 > li527-105.members.linode.com.http: Flags [.], ack 1, win 115, options [nop,nop,TS val 237397594 ecr 3220226885], length 0
23:30:01.931544 IP 192.168.0.251.34245 > li527-105.members.linode.com.http: Flags [P.], seq 1:133, ack 1, win 115, options [nop,nop,TS val 237397594 ecr 3220226885], length 132
23:30:02.031923 IP li527-105.members.linode.com.http > 192.168.0.251.34245: Flags [.], ack 133, win 122, options [nop,nop,TS val 3220226987 ecr 237397594], length 0
23:30:02.032171 IP li527-105.members.linode.com.http > 192.168.0.251.34245: Flags [P.], seq 1:323, ack 133, win 122, options [nop,nop,TS val 3220226988 ecr 237397594], length 322
23:30:02.032233 IP 192.168.0.251.34245 > li527-105.members.linode.com.http: Flags [.], ack 323, win 123, options [nop,nop,TS val 237397604 ecr 3220226988], length 0
23:30:02.034852 IP 192.168.0.251.34245 > li527-105.members.linode.com.http: Flags [F.], seq 133, ack 323, win 123, options [nop,nop,TS val 237397605 ecr 3220226988], length 0
23:30:02.139101 IP li527-105.members.linode.com.http > 192.168.0.251.34245: Flags [F.], seq 323, ack 134, win 122, options [nop,nop,TS val 3220227091 ecr 237397605], length 0
23:30:02.139233 IP 192.168.0.251.34245 > li527-105.members.linode.com.http: Flags [.], ack 324, win 123, options [nop,nop,TS val 237397615 ecr 3220227091], length 0
TCP协议要建立连接要经过3次“握手”,截取的数据包也是从3次握手开始,可以看到前三个包的状态(Flags)分别是:
 [S]、[S.]、[.]
首先是客户端向服务端发送一个10位的序号给服务端;服务端收到后把它+1再返回回去;客户端检查返回来的序号是对的,就返回给服务端一个1。根据上面的描述,知道这三个包满足:第一个包的seq+1=第二个包的ack;第三个包的ack=1
连接建立了之后就是具体的数据交互了,tcpdump脚本加-X参数可以通过十六进制和ASCII方式显示出具体的数据内容,这里略过。
TCP协议要断开连接要经过4次“挥手”,上面数据包的最后3条就是挥手的过程。细心的朋友会发现前面说的4次挥手,却只有3个包,这不是笔误。
最后三个包的状态分别是:
[F.]、[F.]、[.]
首先是客户端发一个序号告诉服务器我要断开,服务器说行,服务器发回一个序号,说断开吧,客户端说:“断!”
四次挥手之所以只能看到3个数据包是因为:ACK延迟发送机制。为了提高性能,TCP在收到ACK之后会攒起来而不是立即发送的,在几种情况下才会发送:
1 超过MSS(可以理解为攒得太多了,放不下了)
2 有FIN
3 系统设置为禁用延迟(TCP_NODELAY)
倒数第二条的前面应该还有一个ACK,因为不符合上述3条,所以被延迟(一般是40ms或者200ms)了,等到倒数第二条发出时符合条件了(有FIN)就一块发出来了,所以4次挥手只能看到3个包。如果系统禁用了延迟发送,就会看到4个包了。
以上均为我自己的理解,如果理解的不对,请指正。
 评论
  可给tcpdump 加上 -S 显示原始ack序号.

  ACK固定是1, 这只是tcpdump采用相对量显示,具体数值是seq%2B1,可通过16进制察看.

  “服务器说行,服务器发回一个序号,说断开吧”这两个合并成了一个包

  三次握手第三个确认包的ack=1??不是前一个数据包得seq%2B1吗?
回复:我看到的规律第三个包得ack固定是1,不知道是不是我理解错了。

留言

這個網誌中的熱門文章

opencv4nodejs Asynchronous OpenCV 3.x Binding for node.js   122     2715     414   0   0 Author Contributors Repository https://github.com/justadudewhohacks/opencv4nodejs Wiki Page https://github.com/justadudewhohacks/opencv4nodejs/wiki Last Commit Mar. 8, 2019 Created Aug. 20, 2017 opencv4nodejs           By its nature, JavaScript lacks the performance to implement Computer Vision tasks efficiently. Therefore this package brings the performance of the native OpenCV library to your Node.js application. This project targets OpenCV 3 and provides an asynchronous as well as an synchronous API. The ultimate goal of this project is to provide a comprehensive collection of Node.js bindings to the API of OpenCV and the OpenCV-contrib modules. An overview of available bindings can be found in the  API Documentation . Furthermore, contribution is highly appreciated....

2017通訊大賽「聯發科技物聯網開發競賽」決賽團隊29強出爐!作品都在11月24日頒獎典禮進行展示

2017通訊大賽「聯發科技物聯網開發競賽」決賽團隊29強出爐!作品都在11月24日頒獎典禮進行展示 LIS   發表於 2017年11月16日 10:31   收藏此文 2017通訊大賽「聯發科技物聯網開發競賽」決賽於11月4日在台北文創大樓舉行,共有29個隊伍進入決賽,角逐最後的大獎,並於11月24日進行頒獎,現場會有全部進入決賽團隊的展示攤位,總計約為100個,各種創意作品琳琅滿目,非常值得一看,這次錯過就要等一年。 「聯發科技物聯網開發競賽」決賽持續一整天,每個團隊都有15分鐘面對評審團做簡報與展示,並接受評審們的詢問。在所有團隊完成簡報與展示後,主辦單位便統計所有評審的分數,並由評審們進行審慎的討論,決定冠亞季軍及其他各獎項得主,結果將於11月24日的「2017通訊大賽頒獎典禮暨成果展」現場公佈並頒獎。 在「2017通訊大賽頒獎典禮暨成果展」現場,所有入圍決賽的團隊會設置攤位,總計約為100個,展示他們辛苦研發並實作的作品,無論是想觀摩別人的成品、了解物聯網應用有那些新的創意、尋找投資標的、尋找人才、尋求合作機會或是單純有興趣,都很適合花點時間到現場看看。 頒獎典禮暨成果展資訊如下: 日期:2017年11月24日(星期五) 地點:中油大樓國光廳(台北市信義區松仁路3號) 我要報名參加「2017通訊大賽頒獎典禮暨成果展」>>> 在參加「2017通訊大賽頒獎典禮暨成果展」之前,可以先在本文觀看各團隊的作品介紹。 決賽29強團隊如下: 長者安全救星 可隨意描繪或書寫之電子筆記系統 微觀天下 體適能訓練管理裝置 肌少症之行走速率檢測系統 Sugar Robot 賽亞人的飛機維修輔助器 iTemp你的溫度個人化管家 語音行動冰箱 MR模擬飛行 智慧防盜自行車 跨平台X-Y視覺馬達控制 Ironmet 菸消雲散 無人小艇 (Mini-USV) 救OK-緊急救援小幫手 穿戴式長照輔助系統 應用於教育之模組機器人教具 這味兒很台味 Aquarium Hub 發展遲緩兒童之擴增實境學習系統 蚊房四寶 車輛相控陣列聲納環境偵測系統 戶外團隊運動管理裝置 懷舊治療數位桌曆 SeeM智能眼罩 觸...
自製直播音源線 Bird Liang   October 6, 2016   in  View Bird Liang, Chief Engineer (梁子凌 / 技術長兼工程輔導長) 負責 AppWorks 技術策略與佈署,同時主導工程輔導。人生的第一份正職工作是創業,之後在外商圈電子業中闖蕩多年,經歷過 NXP、Sony、Newport Imagining、Crossmatch 等企業,從事無線通訊、影像系統、手機、面板、半導體、生物辨識等不同領域產品開發。熱愛學習新事物,協助團隊解決技術問題。放棄了幾近退休般的生活加入 AppWorks,為的是幫助更多在創業路上的人,並重新體驗創業的熱情。台大農機系、台科大電子所畢業,熱愛賞鳥、演奏管風琴,亦是不折不扣的熱血 Maker。 隨著 Facebook 開放一般帳號直播,現在我們只要拿起手機,隨時隨地都可以開始直播。回想幾年前 AppWorks 剛開始進行 Demo Day 直播時,還要將 HDMI 訊號接進 PC 中、再編碼打進 YouTube 的複雜度,實不可同日而語。 但用手機或平板直播最大的問題往往不是影像而是聲音。iPhone 或 iPad 上的攝影機,感度和解析度早已不輸數年前的專業攝影機,只要現場光不太差,大概都可以拍出令人滿意的畫面。但直播的聲音一直是個大問題,手機上的麥克風跟人耳所聽到的聲音其實有很大的差距,在比較大的場子裡,光是仰賴內建麥克風的收音多半無法有令人滿意的效果。 在大型的活動中,現場通常會有 PA 系統,最理想的方式還是想辦法將 PA 的訊號餵進 iPad 或 iPhone 中,保證聲音乾淨又清楚,絕對不會有其它有的沒的現場音。 iPhone 的耳機孔雖然可以插帶有麥克風的耳機 (如 Apple 原廠的 EarPods),但它的訊號位準是電容式麥克風的位準。PA 控台的輸出幾乎都是 line level 的,兩者的訊號電壓相差百倍以上,我們得做個小東西來解決這個差距。 Line 與 Mic 在 mixer 上,我們常會看到輸入可以在兩種規格中切換: line level 和 mic level。Mic level 顧名思義就是從麥克風來的訊號,這個訊號的規格是從不需供電的傳統動圈麥克風來的。因為不需...