表面上我是個技術博主。

但沒想到今天成了個情感博主。

我是沒想到有一天，我會通過技術知識，來挽救粉絲即將破碎的感情。

掏心窩子的說。這件事情多少是沾點功德無量了。

事情是這樣的。

最近就有個讀者加了我的綠皮聊天軟件，女生，頭像挺好看的，就在我以為她要我拉她進群發成人專升本廣告的時候。

畫風突然不對勁。

她說她男朋友也是個程序員，異地戀，也關注了我，天天研究什么TCP，UDP網絡。一研究就是一晚上，一晚上都不回她消息的那種。

話里有話，懂。

不出意外的出了意外，她發出了靈魂拷問

"你們程序員真的有那么忙嗎？忙到連消息都不知道回。"

沒想到上來就是一記直拳。

但是，這一拳，我接住了。

我很想告訴她"分了吧，下一題"。

但我不能。因為這樣我就傷害了我的讀者兄弟。

沉默了一下。

單核cpu都快轉冒煙了，才顫顫巍巍在九宮格鍵盤上發出消息。

再回慢一點，我就感覺，我要對不起我這全日制本科學歷了。

"其實，他已經回了你消息了，但你知道嗎？網絡是會丟包的。"

"我來幫他解釋下，這個話題就要從數據包的發送流程聊起"

數據包的發送流程

首先，我們兩個手機的綠皮聊天軟件客戶端，要通信，中間會通過它們家服務器。大概長這樣。

聊天軟件三端通信

但為了簡化模型，我們把中間的服務器給省略掉，假設這是個端到端的通信。且為了保證消息的可靠性，我們盲猜它們之間用的是TCP協議進行通信。

聊天軟件兩端通信

為了發送數據包，兩端首先會通過三次握手，建立TCP連接。

一個數據包，從聊天框里發出，消息會從聊天軟件所在的用戶空間拷貝到內核空間的發送緩沖區（send buffer），數據包就這樣順著傳輸層、網絡層，進入到數據鏈路層，在這里數據包會經過流控（qdisc），再通過RingBuffer發到物理層的網卡。數據就這樣順著網卡發到了紛繁復雜的網絡世界里。這里頭數據會經過n多個路由器和交換機之間的跳轉，最后到達目的機器的網卡處。

此時目的機器的網卡會通知DMA將數據包信息放到RingBuffer中，再觸發一個硬中斷給CPU，CPU觸發軟中斷讓ksoftirqd去RingBuffer收包，于是一個數據包就這樣順著物理層，數據鏈路層，網絡層，傳輸層，最后從內核空間拷貝到用戶空間里的聊天軟件里。

網絡發包收包全景圖

畫了那么大一張圖，只水了200字做解釋，我多少是有些心痛的。

到這里，拋開一些細節，大家大概知道了一個數據包從發送到接收的宏觀過程。

可以看到，這上面全是密密麻麻的名詞。

整條鏈路下來，有不少地方可能會發生丟包。

但為了不讓大家保持蹲姿太久影響身體健康，我這邊只重點講下幾個常見容易發生丟包的場景。

建立連接時丟包

TCP協議會通過三次握手建立連接。大概長下面這樣。

TCP三次握手

在服務端，第一次握手之后，會先建立個半連接，然后再發出第二次握手。這時候需要有個地方可以暫存這些半連接。這個地方就叫半連接隊列。

如果之后第三次握手來了，半連接就會升級為全連接，然后暫存到另外一個叫全連接隊列的地方，坐等程序執行accept()方法將其取走使用。

半連接隊列和全連接隊列

是隊列就有長度，有長度就有可能會滿，如果它們滿了，那新來的包就會被丟棄。

可以通過下面的方式查看是否存在這種丟包行為。

#全連接隊列溢出次數
#netstat-s|grepoverflowed
4343timesthelistenqueueofasocketoverflowed

#半連接隊列溢出次數
#netstat-s|grep-i"SYNstoLISTENsocketsdropped"
109timesthelistenqueueofasocketoverflowed

從現象來看就是連接建立失敗。

這個話題在之前寫的《沒有accept，能建立TCP連接嗎？》有更詳細的聊過，感興趣的可以回去看下。

流量控制丟包

應用層能發網絡數據包的軟件有那么多，如果所有數據不加控制一股腦沖入到網卡，網卡會吃不消，那怎么辦？讓數據按一定的規則排個隊依次處理，也就是所謂的qdisc(Queueing Disciplines，排隊規則)，這也是我們常說的流量控制機制。

排隊，得先有個隊列，而隊列有個長度。

我們可以通過下面的ifconfig命令查看到，里面涉及到的txqueuelen后面的數字1000，其實就是流控隊列的長度。

當發送數據過快，流控隊列長度txqueuelen又不夠大時，就容易出現丟包現象。

qdisc丟包

可以通過下面的ifconfig命令，查看TX下的dropped字段，當它大于0時，則有可能是發生了流控丟包。

#ifconfigeth0
eth0:flags=4163mtu1500
inet172.21.66.69netmask255.255.240.0broadcast172.21.79.255
inet6fe80:3eff269fprefixlen64scopeid0x20
ether003e26:9ftxqueuelen1000(Ethernet)
RXpackets6962682bytes1119047079(1.0GiB)
RXerrors0dropped0overruns0frame0
TXpackets9688919bytes2072511384(1.9GiB)
TXerrors0dropped0overruns0carrier0collisions0

當遇到這種情況時，我們可以嘗試修改下流控隊列的長度。比如像下面這樣將eth0網卡的流控隊列長度從1000提升為1500.

#ifconfigeth0txqueuelen1500

網卡丟包

網卡和它的驅動導致丟包的場景也比較常見，原因很多，比如網線質量差，接觸不良。除此之外，我們來聊幾個常見的場景。

RingBuffer過小導致丟包

上面提到，在接收數據時，會將數據暫存到RingBuffer接收緩沖區中，然后等著內核觸發軟中斷慢慢收走。如果這個緩沖區過小，而這時候發送的數據又過快，就有可能發生溢出，此時也會產生丟包。

RingBuffer滿了導致丟包

我們可以通過下面的命令去查看是否發生過這樣的事情。

#ifconfig
eth0:RXerrors0dropped0overruns0frame0

查看上面的overruns指標，它記錄了由于RingBuffer長度不足導致的溢出次數。

當然，用ethtool命令也能查看。

#ethtool-Seth0|greprx_queue_0_drops

但這里需要注意的是，因為一個網卡里是可以有多個RingBuffer的，所以上面的rx_queue_0_drops里的0代表的是第0個RingBuffer的丟包數，對于多隊列的網卡，這個0還可以改成其他數字。但我的家庭條件不允許我看其他隊列的丟包數，所以上面的命令對我來說是夠用了。。。

當發現有這類型丟包的時候，可以通過下面的命令查看當前網卡的配置。

#ethtool-geth0
Ringparametersforeth0:
Pre-setmaximums:
RX:4096
RXMini:0
RXJumbo:0
TX:4096
Currenthardwaresettings:
RX:1024
RXMini:0
RXJumbo:0
TX:1024

上面的輸出內容，含義是RingBuffer最大支持4096的長度，但現在實際只用了1024。

想要修改這個長度可以執行ethtool -G eth1 rx 4096 tx 4096將發送和接收RingBuffer的長度都改為4096。

RingBuffer增大之后，可以減少因為容量小而導致的丟包情況。

網卡性能不足

網卡作為硬件，傳輸速度是有上限的。當網絡傳輸速度過大，達到網卡上限時，就會發生丟包。這種情況一般常見于壓測場景。

我們可以通過ethtool加網卡名，獲得當前網卡支持的最大速度。

#ethtooleth0
Settingsforeth0:
Speed:10000Mb/s

可以看到，我這邊用的網卡能支持的最大傳輸速度speed=1000Mb/s。

也就是俗稱的千兆網卡，但注意這里的單位是Mb，這里的b是指bit，而不是Byte。1Byte=8bit。所以10000Mb/s還要除以8，也就是理論上網卡最大傳輸速度是1000/8 = 125MB/s。

我們可以通過sar命令從網絡接口層面來分析數據包的收發情況。

#sar-nDEV1
Linux3.10.0-1127.19.1.el7.x86_642022年07月27日_x86_64_(1CPU)

08時35分39秒IFACErxpck/stxpck/srxkB/stxkB/srxcmp/stxcmp/srxmcst/s
08時35分40秒eth06.064.040.35121682.330.000.000.00

其中 txkB/s是指當前每秒發送的字節（byte）總數，rxkB/s是指每秒接收的字節（byte）總數。

當兩者加起來的值約等于12~13w字節的時候，也就對應大概125MB/s的傳輸速度。此時達到網卡性能極限，就會開始丟包。

遇到這個問題，優先看下你的服務是不是真有這么大的真實流量，如果是的話可以考慮下拆分服務，或者就忍痛充錢升級下配置吧。

接收緩沖區丟包

我們一般使用TCP socket進行網絡編程的時候，內核都會分配一個發送緩沖區和一個接收緩沖區。

當我們想要發一個數據包，會在代碼里執行send(msg)，這時候數據包并不是一把梭直接就走網卡飛出去的。而是將數據拷貝到內核發送緩沖區就完事返回了，至于什么時候發數據，發多少數據，這個后續由內核自己做決定。之前寫過的《代碼執行send成功后，數據就發出去了嗎？》里有比較詳細的介紹。

tcp_sendmsg邏輯

而接收緩沖區作用也類似，從外部網絡收到的數據包就暫存在這個地方，然后坐等用戶空間的應用程序將數據包取走。

這兩個緩沖區是有大小限制的，可以通過下面的命令去查看。

#查看接收緩沖區
#sysctlnet.ipv4.tcp_rmem
net.ipv4.tcp_rmem=4096873806291456

#查看發送緩沖區
#sysctlnet.ipv4.tcp_wmem
net.ipv4.tcp_wmem=4096163844194304

不管是接收緩沖區還是發送緩沖區，都能看到三個數值，分別對應緩沖區的最小值，默認值和最大值 （min、default、max）。緩沖區會在min和max之間動態調整。

那么問題來了，如果緩沖區設置過小會怎么樣？

對于發送緩沖區，執行send的時候，如果是阻塞調用，那就會等，等到緩沖區有空位可以發數據。

send阻塞

如果是非阻塞調用，就會立刻返回一個 EAGAIN 錯誤信息，意思是 Try again 。讓應用程序下次再重試。這種情況下一般不會發生丟包。

send非阻塞

當接受緩沖區滿了，事情就不一樣了，它的TCP接收窗口會變為0，也就是所謂的零窗口，并且會通過數據包里的win=0，告訴發送端，"球球了，頂不住了，別發了"。一般這種情況下，發送端就該停止發消息了，但如果這時候確實還有數據發來，就會發生丟包。

recv_buffer丟包

我們可以通過下面的命令里的TCPRcvQDrop查看到有沒有發生過這種丟包現象。

cat/proc/net/netstat
TcpExt:SyncookiesSentTCPRcvQDropSyncookiesFailed
TcpExt:015760116

但是說個傷心的事情，我們一般也看不到這個TCPRcvQDrop，因為這個是5.9版本里引入的打點，而我們的服務器用的一般是2.x~3.x左右版本。你可以通過下面的命令查看下你用的是什么版本的linux內核。

#cat/proc/version
Linuxversion3.10.0-1127.19.1.el7.x86_64

兩端之間的網絡丟包

前面提到的是兩端機器內部的網絡丟包，除此之外，兩端之間那么長的一條鏈路都屬于外部網絡，這中間有各種路由器和交換機還有光纜啥的，丟包也是很經常發生的。

這些丟包行為發生在中間鏈路的某些個機器上，我們當然是沒權限去登錄這些機器。但我們可以通過一些命令觀察整個鏈路的連通情況。

ping命令查看丟包

比如我們知道目的地的域名是 baidu.com。想知道你的機器到baidu服務器之間，有沒有產生丟包行為。可以使用ping命令。

ping查看丟包

倒數第二行里有個100% packet loss，意思是丟包率100%。

但這樣其實你只能知道你的機器和目的機器之間有沒有丟包。

那如果你想知道你和目的機器之間的這條鏈路，哪個節點丟包了，有沒有辦法呢?

有。

mtr命令

mtr命令可以查看到你的機器和目的機器之間的每個節點的丟包情況。

像下面這樣執行命令。

mtr_icmp

其中-r是指report，以報告的形式打印結果。

可以看到Host那一列，出現的都是鏈路中間每一跳的機器，Loss的那一列就是指這一跳對應的丟包率。

需要注意的是，中間有一些是host是???，那個是因為mtr默認用的是ICMP包，有些節點限制了ICMP包，導致不能正常展示。

我們可以在mtr命令里加個-u，也就是使用udp包，就能看到部分???對應的IP。

mtr-udp

把ICMP包和UDP包的結果拼在一起看，就是比較完整的鏈路圖了。

還有個小細節，Loss那一列，我們在icmp的場景下，關注最后一行，如果是0%，那不管前面loss是100%還是80%都無所謂，那些都是節點限制導致的虛報。

但如果最后一行是20%，再往前幾行都是20%左右，那說明丟包就是從最接近的那一行開始產生的，長時間是這樣，那很可能這一跳出了點問題。如果是公司內網的話，你可以帶著這條線索去找對應的網絡同事。如果是外網的話，那耐心點等等吧，別人家的開發會比你更著急。

發生丟包了怎么辦

說了這么多。只是想告訴大家，丟包是很常見的，幾乎不可避免的一件事情。

但問題來了，發生丟包了怎么辦？

這個好辦，用TCP協議去做傳輸。

TCP是什么

建立了TCP連接的兩端，發送端在發出數據后會等待接收端回復ack包，ack包的目的是為了告訴對方自己確實收到了數據，但如果中間鏈路發生了丟包，那發送端會遲遲收不到確認ack，于是就會進行重傳。以此來保證每個數據包都確確實實到達了接收端。

假設現在網斷了，我們還用聊天軟件發消息，聊天軟件會使用TCP不斷嘗試重傳數據，如果重傳期間網絡恢復了，那數據就能正常發過去。但如果多次重試直到超時都還是失敗，這時候你將收獲一個紅色感嘆號。

這時候問題又來了。

假設某綠皮聊天軟件用的就是TCP協議。

那文章開頭提到的女生，她男朋友回她的消息時為什么還會丟包？畢竟丟包了會重試，重試失敗了還會出現紅色感嘆號。

于是乎，問題就變成了，用了TCP協議，就一定不會丟包嗎？

用了TCP協議就一定不會丟包嗎

我們知道TCP位于傳輸層，在它的上面還有各種應用層協議，比如常見的HTTP或者各類RPC協議。

四層網絡協議

TCP保證的可靠性，是傳輸層的可靠性。也就是說，TCP只保證數據從A機器的傳輸層可靠地發到B機器的傳輸層。

至于數據到了接收端的傳輸層之后，能不能保證到應用層，TCP并不管。

假設現在，我們輸入一條消息，從聊天框發出，走到傳輸層TCP協議的發送緩沖區，不管中間有沒有丟包，最后通過重傳都保證發到了對方的傳輸層TCP接收緩沖區，此時接收端回復了一個ack，發送端收到這個ack后就會將自己發送緩沖區里的消息給扔掉。到這里TCP的任務就結束了。

TCP任務是結束了，但聊天軟件的任務沒結束。

聊天軟件還需要將數據從TCP的接收緩沖區里讀出來，如果在讀出來這一刻，手機由于內存不足或其他各種原因，導致軟件崩潰閃退了。

發送端以為自己發的消息已經發給對方了，但接收端卻并沒有收到這條消息。

于是乎，消息就丟了。

使用TCP協議卻發生丟包

雖然概率很小，但它就是發生了。

合情合理，邏輯自洽。

所以從這里，我鏗鏘有力的得出結論，我的讀者已經回了這位女生消息了，只是因為發生了丟包所以女生才沒能收到，而丟包的原因是女生的手機聊天軟件在接收消息的那一刻發生了閃退。

到這里。女生知道自己錯怪她男朋友了，哭著表示，一定要讓她男朋友給她買一臺不閃退的最新款iphone。

額。。。

兄弟們覺得我做得對的，請在評論區扣個"正能量"。

這類丟包問題怎么解決？

故事到這里也到尾聲了，感動之余，我們來聊點掏心窩子的話。

其實前面說的都對，沒有一句是假話。

但某綠皮聊天軟件這么成熟，怎么可能沒考慮過這一點呢。

大家應該還記得我們文章開頭提到過，為了簡單，就將服務器那一方給省略了，從三端通信變成了兩端通信，所以才有了這個丟包問題。

現在我們重新將服務器加回來。

聊天軟件三端通信

大家有沒有發現，有時候我們在手機里聊了一大堆內容，然后登錄電腦版，它能將最近的聊天記錄都同步到電腦版上。也就是說服務器可能記錄了我們最近發過什么數據，假設每條消息都有個id，服務器和聊天軟件每次都拿最新消息的id進行對比，就能知道兩端消息是否一致，就像對賬一樣。

對于發送方，只要定時跟服務端的內容對賬一下，就知道哪條消息沒發送成功，直接重發就好了。

如果接收方的聊天軟件崩潰了，重啟后跟服務器稍微通信一下就知道少了哪條數據，同步上來就是了，所以也不存在上面提到的丟包情況。

可以看出，TCP只保證傳輸層的消息可靠性，并不保證應用層的消息可靠性。如果我們還想保證應用層的消息可靠性，就需要應用層自己去實現邏輯做保證。

那么問題叒來了，兩端通信的時候也能對賬，為什么還要引入第三端服務器？

主要有三個原因。

• 第一，如果是兩端通信，你聊天軟件里有1000個好友，你就得建立1000個連接。但如果引入服務端，你只需要跟服務器建立1個連接就夠了，聊天軟件消耗的資源越少，手機就越省電。

• 第二，就是安全問題，如果還是兩端通信，隨便一個人找你對賬一下，你就把聊天記錄給同步過去了，這并不合適吧。如果對方別有用心，信息就泄露了。引入第三方服務端就可以很方便的做各種鑒權校驗。

• 第三，是軟件版本問題。軟件裝到用戶手機之后，軟件更不更新就是由用戶說了算了。如果還是兩端通信，且兩端的軟件版本跨度太大，很容易產生各種兼容性問題，但引入第三端服務器，就可以強制部分過低版本升級，否則不能使用軟件。但對于大部分兼容性問題，給服務端加兼容邏輯就好了，不需要強制用戶更新軟件。

所以看到這里大家應該明白了，我把服務端去掉，并不單純是為了簡單。

總結

• 數據從發送端到接收端，鏈路很長，任何一個地方都可能發生丟包，幾乎可以說丟包不可避免。

• 平時沒事也不用關注丟包，大部分時候TCP的重傳機制保證了消息可靠性。

• 當你發現服務異常的時候，比如接口延時很高，總是失敗的時候，可以用ping或者mtr命令看下是不是中間鏈路發生了丟包。

• TCP只保證傳輸層的消息可靠性，并不保證應用層的消息可靠性。如果我們還想保證應用層的消息可靠性，就需要應用層自己去實現邏輯做保證。

最后給大家留個問題吧，mtr命令是怎么知道每一跳的IP地址的？