2. 程式人生 > >實戰！我用 Wireshark 讓你“看得見“ TCP

實戰！我用 Wireshark 讓你“看得見“ TCP

阿新 • • 發佈：2020-05-20
每日一句英語學習，每天進步一點點：

前言

為了讓大家更容易「看得見」 TCP，我搭建不少測試環境，並且資料包抓很多次，花費了不少時間，才抓到比較容易分析的資料包。

接下來丟包、亂序、超時重傳、快速重傳、選擇性確認、流量控制等等 TCP 的特性，都能「一覽無雲」。

沒錯，我把 TCP 的"衣服扒光"了，就為了給大家看的清楚，嘻嘻。

提綱

正文

顯形“不可見”的網路包

網路世界中的資料包互動我們肉眼是看不見的，它們就好像隱形了一樣，我們對著課本學習計算機網路的時候就會覺得非常的抽象，加大了學習的難度。

還別說，我自己在大學的時候，也是如此。

直到工作後，認識了兩大分析網路的利器：tcpdump 和 Wireshark，這兩大利器把我們“看不見”的資料包，呈現在我們眼前，一目瞭然。

唉，當初大學學習計網的時候，要是能知道這兩個工具，就不會學的一臉懵逼。

tcpdump 和 Wireshark 有什麼區別？

tcpdump 和 Wireshark 就是最常用的網路抓包和分析工具，更是分析網路效能必不可少的利器。

  • tcpdump 僅支援命令列格式使用，常用在 Linux 伺服器中抓取和分析網路包。
  • Wireshark 除了可以抓包外，還提供了視覺化分析網路包的圖形頁面。

所以，這兩者實際上是搭配使用的，先用 tcpdump 命令在 Linux 伺服器上抓包，接著把抓包的檔案拖出到 Windows 電腦後，用 Wireshark 視覺化分析。

當然，如果你是在 Windows 上抓包，只需要用 Wireshark 工具就可以。

tcpdump 在 Linux 下如何抓包？

tcpdump 提供了大量的選項以及各式各樣的過濾表示式，來幫助你抓取指定的資料包，不過不要擔心，只需要掌握一些常用選項和過濾表示式，就可以滿足大部分場景的需要了。

假設我們要抓取下面的 ping 的資料包：

要抓取上面的 ping 命令資料包，首先我們要知道 ping 的資料包是 icmp 協議，接著在使用 tcpdump 抓包的時候，就可以指定只抓 icmp 協議的資料包：

那麼當 tcpdump 抓取到 icmp 資料包後， 輸出格式如下：

從 tcpdump 抓取的 icmp 資料包，我們很清楚的看到 icmp echo

的互動過程了，首先發送方發起了 ICMP echo request 請求報文，接收方收到後回了一個 ICMP echo reply 響應報文，之後 seq 是遞增的。

我在這裡也幫你整理了一些最常見的用法，並且繪製成了表格，你可以參考使用。

首先，先來看看常用的選項類，在上面的 ping 例子中，我們用過 -i 選項指定網口，用過 -nn 選項不對 IP 地址和埠名稱解析。其他常用的選項，如下表格：

tcpdump 常用選項類

接下來，我們再來看看常用的過濾表用法，在上面的 ping 例子中，我們用過的是 icmp and host 183.232.231.174，表示抓取 icmp 協議的資料包，以及源地址或目標地址為 183.232.231.174 的包。其他常用的過濾選項，我也整理成了下面這個表格。

tcpdump 常用過濾表示式類

說了這麼多，你應該也發現了，tcpdump 雖然功能強大，但是輸出的格式並不直觀。

所以，在工作中 tcpdump 只是用來抓取資料包，不用來分析資料包，而是把 tcpdump 抓取的資料包儲存成 pcap 字尾的檔案，接著用 Wireshark 工具進行資料包分析。

Wireshark 工具如何分析資料包？

Wireshark 除了可以抓包外，還提供了視覺化分析網路包的圖形頁面，同時，還內建了一系列的彙總分析工具。

比如，拿上面的 ping 例子來說，我們可以使用下面的命令，把抓取的資料包儲存到 ping.pcap 檔案

接著把 ping.pcap 檔案拖到電腦，再用 Wireshark 開啟它。開啟後，你就可以看到下面這個介面：

是吧？在 Wireshark 的頁面裡，可以更加直觀的分析資料包，不僅展示各個網路包的頭部資訊，還會用不同的顏色來區分不同的協議，由於這次抓包只有 ICMP 協議，所以只有紫色的條目。

接著，在網路包列表中選擇某一個網路包後，在其下面的網路包詳情中，可以更清楚的看到，這個網路包在協議棧各層的詳細資訊。比如，以編號 1 的網路包為例子：

ping 網路包
  • 可以在資料鏈路層，看到 MAC 包頭資訊，如源 MAC 地址和目標 MAC 地址等欄位；
  • 可以在 IP 層，看到 IP 包頭資訊，如源 IP 地址和目標 IP 地址、TTL、IP 包長度、協議等 IP 協議各個欄位的數值和含義；
  • 可以在 ICMP 層，看到 ICMP 包頭資訊，比如 Type、Code 等 ICMP 協議各個欄位的數值和含義；

Wireshark 用了分層的方式，展示了各個層的包頭資訊，把“不可見”的資料包，清清楚楚的展示了給我們，還有理由學不好計算機網路嗎？是不是相見恨晚？

從 ping 的例子中，我們可以看到網路分層就像有序的分工，每一層都有自己的責任範圍和資訊，上層協議完成工作後就交給下一層，最終形成一個完整的網路包。

解密 TCP 三次握手和四次揮手

既然學會了 tcpdump 和 Wireshark 兩大網路分析利器，那我們快馬加鞭，接下用它倆抓取和分析 HTTP 協議網路包，並理解 TCP 三次握手和四次揮手的工作原理。

本次例子，我們將要訪問的 http://192.168.3.200 服務端。在終端一用 tcpdump 命令抓取資料包：

接著，在終端二執行下面的 curl 命令：

最後，回到終端一，按下 Ctrl+C 停止 tcpdump，並把得到的 http.pcap 取出到電腦。

使用 Wireshark 開啟 http.pcap 後，你就可以在 Wireshark 中，看到如下的介面：

HTTP 網路包

我們都知道 HTTP 是基於 TCP 協議進行傳輸的，那麼：

  • 最開始的 3 個包就是 TCP 三次握手建立連線的包
  • 中間是 HTTP 請求和響應的包
  • 而最後的 3 個包則是 TCP 斷開連線的揮手包

Wireshark 可以用時序圖的方式顯示資料包互動的過程，從選單欄中，點選 統計 (Statistics) -> 流量圖 (Flow Graph)，然後，在彈出的介面中的「流量型別」選擇 「TCP Flows」，你可以更清晰的看到，整個過程中 TCP 流的執行過程：

TCP 流量圖

你可能會好奇，為什麼三次握手連線過程的 Seq 是 0 ？

實際上是因為 Wireshark 工具幫我們做了優化，它預設顯示的是序列號 seq 是相對值，而不是真實值。

如果你想看到實際的序列號的值，可以右鍵選單， 然後找到「協議首選項」，接著找到「Relative Seq」後，把它給取消，操作如下：

取消序列號相對值顯示

取消後，Seq 顯示的就是真實值了：

TCP 流量圖

可見，客戶端和服務端的序列號實際上是不同的，序列號是一個隨機值。

這其實跟我們書上看到的 TCP 三次握手和四次揮手很類似，作為對比，你通常看到的 TCP 三次握手和四次揮手的流程，基本是這樣的：

TCP 三次握手和四次揮手的流程

為什麼抓到的 TCP 揮手是三次，而不是書上說的四次？

因為伺服器端收到客戶端的 FIN 後，伺服器端同時也要關閉連線，這樣就可以把 ACK 和 FIN 合併到一起傳送，節省了一個包，變成了“三次揮手”。

而通常情況下，伺服器端收到客戶端的 FIN 後，很可能還沒傳送完資料，所以就會先回復客戶端一個 ACK 包，稍等一會兒，完成所有資料包的傳送後，才會傳送 FIN 包，這也就是四次揮手了。

如下圖，就是四次揮手的過程：

四次揮手

TCP 三次握手異常情況實戰分析

TCP 三次握手的過程相信大家都背的滾瓜爛熟，那麼你有沒有想過這三個異常情況：

  • TCP 第一次握手的 SYN 丟包了，會發生了什麼？
  • TCP 第二次握手的 SYN、ACK 丟包了，會發生什麼？
  • TCP 第三次握手的 ACK 包丟了，會發生什麼？

有的小夥伴可能說：“很簡單呀，包丟了就會重傳嘛。”

那我在繼續問你：

  • 那會重傳幾次？
  • 超時重傳的時間 RTO 會如何變化？
  • 在 Linux 下如何設定重傳次數？
  • ….

是不是啞口無言，無法回答？

不知道沒關係，接下里我用三個實驗案例，帶大家一起探究探究這三種異常。

實驗場景

本次實驗用了兩臺虛擬機器，一臺作為服務端，一臺作為客戶端，它們的關係如下：

實驗環境
  • 客戶端和服務端都是 CentOs 6.5 Linux，Linux 核心版本 2.6.32
  • 服務端 192.168.12.36，apache web 服務
  • 客戶端 192.168.12.37

實驗一：TCP 第一次握手 SYN 丟包

為了模擬 TCP 第一次握手 SYN 丟包的情況，我是在拔掉伺服器的網線後，立刻在客戶端執行 curl 命令：

其間 tcpdump 抓包的命令如下：

過了一會， curl 返回了超時連線的錯誤：

從 date 返回的時間，可以發現在超時接近 1 分鐘的時間後，curl 返回了錯誤。

接著，把 tcp_sys_timeout.pcap 檔案用 Wireshark 開啟分析，顯示如下圖：

SYN 超時重傳五次

從上圖可以發現， 客戶端發起了 SYN 包後，一直沒有收到服務端的 ACK ，所以一直超時重傳了 5 次，並且每次 RTO 超時時間是不同的：

  • 第一次是在 1 秒超時重傳
  • 第二次是在 3 秒超時重傳
  • 第三次是在 7 秒超時重傳
  • 第四次是在 15 秒超時重傳
  • 第五次是在 31 秒超時重傳

可以發現，每次超時時間 RTO 是指數（翻倍）上漲的，當超過最大重傳次數後，客戶端不再發送 SYN 包。

在 Linux 中，第一次握手的 SYN 超時重傳次數，是如下核心引數指定的：

$ cat /proc/sys/net/ipv4/tcp_syn_retries
5

tcp_syn_retries 預設值為 5，也就是 SYN 最大重傳次數是 5 次。

接下來，我們繼續做實驗，把 tcp_syn_retries 設定為 2 次：

$ echo 2 > /proc/sys/net/ipv4/tcp_syn_retries

重傳抓包後，用 Wireshark 開啟分析，顯示如下圖：

SYN 超時重傳兩次

實驗一的實驗小結

通過實驗一的實驗結果，我們可以得知，當客戶端發起的 TCP 第一次握手 SYN 包，在超時時間內沒收到服務端的 ACK，就會在超時重傳 SYN 資料包，每次超時重傳的 RTO 是翻倍上漲的，直到 SYN 包的重傳次數到達 tcp_syn_retries 值後，客戶端不再發送 SYN 包。

SYN 超時重傳

實驗二：TCP 第二次握手 SYN、ACK 丟包

為了模擬客戶端收不到服務端第二次握手 SYN、ACK 包，我的做法是在客戶端加上防火牆限制，直接粗暴的把來自服務端的資料都丟棄，防火牆的配置如下：

接著，在客戶端執行 curl 命令：

從 date 返回的時間前後，可以算出大概 1 分鐘後，curl 報錯退出了。

客戶端在這其間抓取的資料包，用 Wireshark 開啟分析，顯示的時序圖如下：

從圖中可以發現：

  • 客戶端發起 SYN 後，由於防火牆遮蔽了服務端的所有資料包，所以 curl 是無法收到服務端的 SYN、ACK 包，當發生超時後，就會重傳 SYN 包
  • 服務端收到客戶的 SYN 包後，就會回 SYN、ACK 包，但是客戶端一直沒有回 ACK，服務端在超時後，重傳了 SYN、ACK 包，接著一會，客戶端超時重傳的 SYN 包又抵達了服務端，服務端收到後，超時定時器就重新計時，然後回了 SYN、ACK 包，所以相當於服務端的超時定時器只觸發了一次，又被重置了。
  • 最後，客戶端 SYN 超時重傳次數達到了 5 次（tcp_syn_retries 預設值 5 次），就不再繼續傳送 SYN 包了。

所以，我們可以發現，當第二次握手的 SYN、ACK 丟包時，客戶端會超時重發 SYN 包，服務端也會超時重傳 SYN、ACK 包。

咦？客戶端設定了防火牆，遮蔽了服務端的網路包，為什麼 tcpdump 還能抓到服務端的網路包？

新增 iptables 限制後， tcpdump 是否能抓到包 ，這要看新增的 iptables 限制條件：

  • 如果新增的是 INPUT 規則，則可以抓得到包
  • 如果新增的是 OUTPUT 規則，則抓不到包

網路包進入主機後的順序如下：

  • 進來的順序 Wire -> NIC -> tcpdump -> netfilter/iptables
  • 出去的順序 iptables -> tcpdump -> NIC -> Wire

tcp_syn_retries 是限制 SYN 重傳次數，那第二次握手 SYN、ACK 限制最大重傳次數是多少？

TCP 第二次握手 SYN、ACK 包的最大重傳次數是通過 tcp_synack_retries 核心引數限制的，其預設值如下：

$ cat /proc/sys/net/ipv4/tcp_synack_retries
5

是的，TCP 第二次握手 SYN、ACK 包的最大重傳次數預設值是 5 次。

為了驗證 SYN、ACK 包最大重傳次數是 5 次，我們繼續做下實驗，我們先把客戶端的 tcp_syn_retries 設定為 1，表示客戶端 SYN 最大超時次數是 1 次，目的是為了防止多次重傳 SYN，把服務端 SYN、ACK 超時定時器重置。

接著，還是如上面的步驟：

  1. 客戶端配置防火牆遮蔽服務端的資料包
  2. 客戶端 tcpdump 抓取 curl 執行時的資料包

把抓取的資料包，用 Wireshark 開啟分析，顯示的時序圖如下：

從上圖，我們可以分析出：

  • 客戶端的 SYN 只超時重傳了 1 次，因為 tcp_syn_retries 值為 1
  • 服務端應答了客戶端超時重傳的 SYN 包後，由於一直收不到客戶端的 ACK 包，所以服務端一直在超時重傳 SYN、ACK 包，每次的 RTO 也是指數上漲的，一共超時重傳了 5 次，因為 tcp_synack_retries 值為 5

接著，我把 tcp_synack_retries 設定為 2，tcp_syn_retries 依然設定為 1:

$ echo 2 > /proc/sys/net/ipv4/tcp_synack_retries
$ echo 1 > /proc/sys/net/ipv4/tcp_syn_retries

依然保持一樣的實驗步驟進行操作，接著把抓取的資料包，用 Wireshark 開啟分析，顯示的時序圖如下：

可見：

  • 客戶端的 SYN 包只超時重傳了 1 次，符合 tcp_syn_retries 設定的值；
  • 服務端的 SYN、ACK 超時重傳了 2 次，符合 tcp_synack_retries 設定的值

實驗二的實驗小結

通過實驗二的實驗結果，我們可以得知，當 TCP 第二次握手 SYN、ACK 包丟了後，客戶端 SYN 包會發生超時重傳，服務端 SYN、ACK 也會發生超時重傳。

客戶端 SYN 包超時重傳的最大次數，是由 tcp_syn_retries 決定的，預設值是 5 次；服務端 SYN、ACK 包時重傳的最大次數，是由 tcp_synack_retries 決定的，預設值是 5 次。

實驗三：TCP 第三次握手 ACK 丟包

為了模擬 TCP 第三次握手 ACK 包丟，我的實驗方法是在服務端配置防火牆，遮蔽客戶端 TCP 報文中標誌位是 ACK 的包，也就是當服務端收到客戶端的 TCP ACK 的報文時就會丟棄，iptables 配置命令如下：

接著，在客戶端執行如下 tcpdump 命令：

然後，客戶端向服務端發起 telnet，因為 telnet 命令是會發起 TCP 連線，所以用此命令做測試：

此時，由於服務端收不到第三次握手的 ACK 包，所以一直處於 SYN_RECV 狀態：

而客戶端是已完成 TCP 連線建立，處於 ESTABLISHED 狀態：

過了 1 分鐘後，觀察發現服務端的 TCP 連線不見了：

過了 30 分別，客戶端依然還是處於 ESTABLISHED 狀態：

接著，在剛才客戶端建立的 telnet 會話，輸入 123456 字元，進行傳送：

持續「好長」一段時間，客戶端的 telnet 才斷開連線：

以上就是本次的實現三的現象，這裡存在兩個疑點：

  • 為什麼服務端原本處於 SYN_RECV 狀態的連線，過 1 分鐘後就消失了？
  • 為什麼客戶端 telnet 輸入 123456 字元後，過了好長一段時間，telnet 才斷開連線？

不著急，我們把剛抓的資料包，用 Wireshark 開啟分析，顯示的時序圖如下：

上圖的流程：

  • 客戶端傳送 SYN 包給服務端，服務端收到後，回了個 SYN、ACK 包給客戶端，此時服務端的 TCP 連線處於 SYN_RECV 狀態；
  • 客戶端收到服務端的 SYN、ACK 包後，給服務端回了個 ACK 包，此時客戶端的 TCP 連線處於 ESTABLISHED 狀態；
  • 由於服務端配置了防火牆，遮蔽了客戶端的 ACK 包，所以服務端一直處於 SYN_RECV 狀態，沒有進入 ESTABLISHED 狀態，tcpdump 之所以能抓到客戶端的 ACK 包，是因為資料包進入系統的順序是先進入 tcpudmp，後經過 iptables；
  • 接著，服務端超時重傳了 SYN、ACK 包，重傳了 5 次後，也就是超過 tcp_synack_retries 的值（預設值是 5），然後就沒有繼續重傳了，此時服務端的 TCP 連線主動中止了，所以剛才處於 SYN_RECV 狀態的 TCP 連線斷開了，而客戶端依然處於ESTABLISHED 狀態；
  • 雖然服務端 TCP 斷開了，但過了一段時間，發現客戶端依然處於ESTABLISHED 狀態，於是就在客戶端的 telnet 會話輸入了 123456 字元；
  • 此時由於服務端已經斷開連線，客戶端傳送的資料報文，一直在超時重傳，每一次重傳，RTO 的值是指數增長的，所以持續了好長一段時間，客戶端的 telnet 才報錯退出了，此時共重傳了 15 次。

通過這一波分析，剛才的兩個疑點已經解除了：

  • 服務端在重傳 SYN、ACK 包時，超過了最大重傳次數 tcp_synack_retries，於是服務端的 TCP 連線主動斷開了。
  • 客戶端向服務端傳送資料包時，由於服務端的 TCP 連線已經退出了，所以資料包一直在超時重傳，共重傳了 15 次， telnet 就 斷開了連線。

TCP 第一次握手的 SYN 包超時重傳最大次數是由 tcp_syn_retries 指定，TCP 第二次握手的 SYN、ACK 包超時重傳最大次數是由 tcp_synack_retries 指定，那 TCP 建立連線後的資料包最大超時重傳次數是由什麼引數指定呢？

TCP 建立連線後的資料包傳輸，最大超時重傳次數是由 tcp_retries2 指定，預設值是 15 次，如下：

$ cat /proc/sys/net/ipv4/tcp_retries2
15

如果 15 次重傳都做完了，TCP 就會告訴應用層說：“搞不定了，包怎麼都傳不過去！”

那如果客戶端不傳送資料，什麼時候才會斷開處於 ESTABLISHED 狀態的連線？

這裡就需要提到 TCP 的 保活機制。這個機制的原理是這樣的：

定義一個時間段，在這個時間段內，如果沒有任何連線相關的活動，TCP 保活機制會開始作用，每隔一個時間間隔，傳送一個「探測報文」，該探測報文包含的資料非常少，如果連續幾個探測報文都沒有得到響應，則認為當前的 TCP 連線已經死亡，系統核心將錯誤資訊通知給上層應用程式。

在 Linux 核心可以有對應的引數可以設定保活時間、保活探測的次數、保活探測的時間間隔，以下都為預設值：

net.ipv4.tcp_keepalive_time=7200
net.ipv4.tcp_keepalive_intvl=75  
net.ipv4.tcp_keepalive_probes=9
  • tcp_keepalive_time=7200：表示保活時間是 7200 秒（2小時），也就 2 小時內如果沒有任何連線相關的活動，則會啟動保活機制
  • tcp_keepalive_intvl=75：表示每次檢測間隔 75 秒；
  • tcp_keepalive_probes=9：表示檢測 9 次無響應，認為對方是不可達的，從而中斷本次的連線。

也就是說在 Linux 系統中，最少需要經過 2 小時 11 分 15 秒才可以發現一個「死亡」連線。

這個時間是有點長的，所以如果我抓包足夠久，或許能抓到探測報文。

實驗三的實驗小結

在建立 TCP 連線時，如果第三次握手的 ACK，服務端無法收到，則服務端就會短暫處於 SYN_RECV 狀態，而客戶端會處於 ESTABLISHED 狀態。

由於服務端一直收不到 TCP 第三次握手的 ACK，則會一直重傳 SYN、ACK 包，直到重傳次數超過 tcp_synack_retries 值（預設值 5 次）後，服務端就會斷開 TCP 連線。

而客戶端則會有兩種情況：

  • 如果客戶端沒傳送資料包，一直處於

    相關推薦

    實戰！我用 Wireshark 讓你“看得見“ TCP

    每日一句英語學習，每天進步一點點： 前言 為了讓大家更容易「看得見」 TCP，我搭建不少測試環境，並且資料包抓很多次，花費了不少時間，才抓到比較容易分析的資料包。 接下來丟包、亂序、超時重傳、快速重傳、選擇性確認、流量控制等等 TCP 的特性，都能「一覽無雲」。 沒錯，我把 TCP 的"衣服扒光"了，就

    在TutorABC學英語 進步讓你看得見

    在現如今這個社會，我們上學時期學的“啞巴英語”已經不能適應這個社會的發展了，現在學英語實用才是王道，英語能開口說才是有用的。那就要放棄傳統的線下英語培訓班，選擇外教老師教課的線上英語培訓，讓大家可以在全英文的環境中學習以英語，這樣會事半功倍，就相當於你去了美國學

    項目實戰！我用Python爬取了14年所有的福彩3D信息

    下載器 rap 寫入excel url req 理論 ola text port 前兩天，在網上看到一個有意思的問題：×××靠譜麽？為什麽還有那麽多的人相信×××？ 暫且不說，×××是否靠譜？×××也分人而異，江湖上騙術很多，有些甚至會誤以為×××的準確度可以很高，這些操盤

    別再問我 new 字串建立了幾個物件了！我來證明給你看！

    我想所有 Java 程式設計師都曾被這個 new String 的問題困擾過，這是一道高頻的 Java 面試題，但可惜的是網上眾說紛紜，竟然找不到標準的答案。有人說建立了 1 個物件，也有人說建立了 2 個物件，還有人說可能建立了 1 個或 2 個物件，但誰都沒有拿出幹掉對方的證據，這就讓我們這幫吃瓜群眾們陷

    柏明頓阿米巴經營會計幫助您的企業提升財務層級，讓經營看得見

    阿米巴經營會計是阿米巴經營體系的落地工具，能夠解決管理會計和財務會計問題，直接為阿米巴經營服務。 為了讓阿米巴經營體系更加系統與完善，柏明頓提出了阿米巴經營體系鐵三角這一概念，由阿米巴經營哲學、阿米巴管理學、阿米巴會計學這三大模組構成，其中阿米巴經營哲學是基礎，阿米巴管

    Python專案實戰：讓我用程式碼評價你的公司

    前言： 隨著網際網路行業的日益興盛，吸引力越來越多的牛人加入其中，也有許多小夥伴躍躍欲試，想要在網際網路的浪潮中大展身手。今天我們通過看準網的資料，幫助大家對各大網際網路公司有一個比較概括的瞭解。 01：資料來源     看準網提供了許多員工對於公司的評

    誰當年還沒看過幾本小說！我用Python爬取全站的的小說！

    nec 打印 b數 技術分享 mon 結果 鏈接 ons ide 然後再將請求發送出去，定義變量response，用read（）方法觀察，註意將符號解碼成utf-8的形式，省的亂碼： 打印一下看結果： 看到這麽

    用 Python 帶你看《我不是藥神》

    存儲位置 RoCE 文件 多個 ffffff url web vpd shadow 我們都是小人物，我們都得了同一種病，我們都窮。——《我不是藥神》 我不是程序員 我就是想求求你們，別動不動就拿篇10W+的文章來嚇唬人好嗎？說點有用的東西好嗎？我們需要精神糧食不需要腐蝕精

    一篇讓你看懂Spark任務執行各物件建立時機！

    1.SparkContext哪一端生成的？ Driver端 2.DAG是在哪一端被構建的？ Driver端 3.RDD是在哪一端生成的？ Driver端 4.廣播變數是在哪一端呼叫的方法進行廣播的？ Driver端 5.要廣播的資料應該在哪一端先建立好再廣播呢？ Driver

    小程式開發必看！一篇文章讓你瞭解 Flex 佈局

    第九程式註明： 要想開發小程式，每個人都需要先了解 Flex。小程式的開發框架使用了 Flex 排版佈局，它能幫助開發者以最快的速度，構建美觀而具有動態調整性質的小程式排版。 但是，Flex 在目前為止尚未大範圍地推廣和使用，甚至許多前端開發者，在上手小程式開發後才知

    一篇文章讓你看明白運維所有發展方向！

    導讀 網際網路運維工作，以服務為中心，以穩定、安全、高效為三個基本點，確保公司的網際網路業務能夠7×24小時為使用者提供高質量的服務。 運維人員對公司網際網路業務所依賴的基礎設施、基礎服務、線上業務進行穩定性加強，進行日常巡檢發現服務可能存在的隱患，對整體架構進行優化以

    剖析執行時（讓你看懂執行時）

    init ont get tle pre art details ddc down 執行時機制：比較高級的特性，純C語言 實際上我們平時寫的OC代碼。都是轉成C語言的執行時代碼，執行時代碼的效率更高，更直接 Person.h @inter

    4張圖讓你看懂分布式架構從硬件到軟件

    開發 基本 行處理 倉庫 tcp -1 管理 img 必須 對於分布式的架構相對很多開發者都是個高大上的項目，其實只要看得懂圖精通tcp通信、精通磁盤管理、精通內存管理、精通多線程與並行處理，精通事務（其實事務就是基於tcp通信層所擴展而來的MQ之類的一種IO消息模式而與）

    五分鐘讓你看明白到底什麽是Activity --java

    Activity 什麽是Activity 寫這篇文章的目的主要是項目組開發第一次使用總結的一點小經驗,不足之處打架多多探討.1.什麽是工作流?以請假為例,現在大多公司的後臺流程是這樣的 a.郵件提出申請 b.上級回郵件同意或其他方式c.上級請假記錄 d.月底將請假上繳公司 e.人事錄電

    Smobiler 4.4已正式發布！（Smobiler能讓你在Visual Studio上開發APP）

    pre 直接 upd 安裝 組件 data .apk 新的 cat Smobiler 4.4已經正式發布，還不快來看看？原文地址：https://www.smobiler.com/portal.php?mod=view&aid=53這次更新要感謝我們的用戶，在使用s

    考研英語：如何巧用暑假讓你突破自己

    進度 高頻 復習 自己的 付出 時間 快速 自然 不知道 考研英語：如何巧用暑假讓你突破自己　　暑假就要到來了，在學校都沒有集中的復習時間，終於有空可以靜下心來學習的了，這個時候好好抓住，相信你考研一定會成功！　　對於英語這門課程，很多的同學還不知道到底應該如何安排時間，不

    一個成功案例讓你看懂智能養卡代還系統

    模式 size 分享 特性 pro alt 自己的 src 代理 隨著三級分銷的商業模式發展以來，越來越受到大家的歡迎，不斷有新的商家加入其中。而三級分銷的支付系統自開發以來也為企業創造了很多價值，那麽三級分銷支付系統到底是怎麽一回事呢?零零壹的小編給你詳細說說吧。一個故事

    這樣玩雲函式路由，讓你看起來很高階

    歡迎大家前往騰訊雲+社群，獲取更多騰訊海量技術實踐乾貨哦~ 本文由李成熙heyli發表於雲+社群專欄 概念回顧 在掘金開發者大會上，在推薦實踐那裡，我有提到一種雲函式的用法，我們可以將相同的一些操作，比如使用者管理、支付邏輯，按照業務的相似性，歸類到一個雲函式裡，這樣比較方便管理、排查問題以及

    這樣玩雲函數路由，讓你看起來很高級

    開發者 實戰 技術分享 ctr login 發布 以及 new t github 歡迎大家前往騰訊雲+社區，獲取更多騰訊海量技術實踐幹貨哦~ 本文由李成熙heyli發表於雲+社區專欄 概念回顧 在掘金開發者大會上，在推薦實踐那裏，我有提到一種雲函數的用法，我們可以將相同

    [Vue進階]為什麼我的程式碼讓別人看起來頭皮發麻？

    面試官：談談你們專案當中的前端程式碼規範吧？ 自己先想一分鐘。 前面的話 有些同學在開發某個新功能時根據需求就哐哐哐（按照自己的程式碼風格）一頓擼。寫完發現，另一個地方也有這個模組功能，可能只是標題的顏色，字型大小不對。怎麼辦？ 於是很雞賊的複製貼上過去，改吧改吧，提交程式碼