為了能使操作系統提供的網絡接口更好地排查網絡通信問題，我們需要熟悉操作系統提供的一些網絡接口函數。
接下來我們先討論一下這些網絡接口函數的使用注意事項：
1.以上函數如果調用出錯后，返回值均為-1;但是返回值是-1，不一定代表出錯，這還得根據對應的套接字模式(阻塞與非阻塞模式)。
2.默認使用的socket函數創建的套接字是阻塞模式的，可以調用相關接口函數將其設置為非阻塞模式。阻塞模式和非阻塞模式的套接字，對
服務器的連接服務器和網絡數據的收發行為影響很大。詳情如下：
阻塞模式下，connect函數如果不能立刻連上服務器，會導致執行流阻塞在那里一會兒，直到connect連接成功或失敗或網絡超時;而非阻塞模式下，無論是否連接成功connect將立即返回，此時如果未連接成功，返回值將是-1，錯誤碼是EINPROGRESS，表示連接操作仍然在進行中。Linux平臺后續可以通過使用select/poll等函數檢測該socket是否可寫來判斷連接是否成功。
阻塞套接字模式下，send函數如果由于對端tcp窗口太小，不足以將全部數據發送出去，將阻塞執行流，直到出錯或超時或者全部發送出去為止;同理recv函數如果當前協議棧系統緩沖區中無數據可讀，也會阻塞執行流，直到出錯或者超時或者讀取到數據。send和recv函數的超時時間可以參考下文關于常用socket選項的介紹。
非阻塞套接字模式下，如果由于對端tcp窗口太小，不足以將數據發出去，它將立刻返回，不會阻塞執行流，此時返回值為-1，錯誤碼是EAGAIN或EWOULDBLOCK，表示當前數據發不出去，希望你下次再試。但是返回值如果是-1，也可能是真正的出錯了，也可能得到錯誤碼EINTR，表示被linux信號中斷了，這點需要注意一下。recv函數與send函數情形一樣。
3.send函數雖然名稱叫“send”，但是其并不是將數據發送到網絡上去，只是將數據從應用層緩沖區中拷貝到協議棧內核緩沖區中，具體什么時候發送到網絡上去，與協議棧本身行為有關系，這點需要特別注意。所以即使send函數返回一個大于0的值n，也不能表明已經有n個字節發送到網絡上去了。同樣的道理，recv函數也不是從網絡上收取數據，只是從協議棧內核緩沖區拷貝數據至應用層緩沖區，并不是真正地從網絡上收數據，所以調用recv時，操作系統的協議棧已經將數據從網絡上收到自己的內核緩沖區中了，recv僅僅是一次數據拷貝操作而已。
4.由于套接字實現是收發全雙工的，收和發通道相互獨立，不會相互影響，shutdown函數是用來選擇關閉socket收發通道中某一路，其how參數取值一般有三個：SHUT_RD/SHUT_WR/SHUT_RDWR，SHUT_RD表示關閉收消息鏈路，即該套接字不能再收取數據，同理SHUT_WR表示關閉套接字發消息鏈路，但是這里有個問題，有時候我們需要等待緩沖區中數據發送完后再關閉連接怎么辦?這里就要用到套接字選項LINGER，關于這個選項請參考下文常見的套接字選項介紹。最后，SHUT_RDWR同時關閉收消息鏈路和發消息鏈路。
通過上面的分析我們得出結論，shutdown函數并不會要求操作系統底層回收套接字等資源，真正會回收資源是close函數，這個函數會要求操作系統回收相關套接字資源，并釋放對ip地址與端口號二元組的占用，但是由于tcp四次揮手最后一個階段有個TIME_WAIT狀態，導致與該socket相關的端口號資源不會被立即釋放，有時候為了達到釋放端口用來復用，我們會設置套接字選項SOL_REUSEPORT。綜合起來，我們關閉一個套接字，一般會先調用shutdown函數再調用close函數，這就是所謂的優雅關閉：
5.常見的套接字選項
嚴格意義上說套接字選項是有不同層級的(level)，如socket級別、TCP級別、IP級別，這里我們不區分具體的級別。
這兩個選項用于設置阻塞模式下套接字，SO_SNDTIMEO用于在send數據由于對端tcp窗口太小，發不出去而最大的阻塞時長;SO_RCVTIMEO用于recv函數因接受緩沖區無數據而阻塞的最大阻塞時長。如果你需要獲取它們的默認值，請使用getsockopt函數。
操作系統底層協議棧默認有這樣一個機制，為了減少網絡通信次數，會將send等函數提交給tcp協議棧的多個小的數據包合并成一個大的數據包，最后再一次性發出去，也就是說，如果你調用send函數往內核協議棧緩沖區拷貝了一個數據，這個數據也許不會馬上發到網絡上去，而是要等到協議棧緩沖區積累到一定量的數據后才會一次性發出去，我們把這種機制叫做nagle算法。默認打開了這個機制，有時候我們希望關閉這種機制，讓send的數據能夠立刻發出去，我們可以選擇關閉這個算法，這就可以通過設置套接字選項TCP_NODELAY，即關閉nagle算法。
linger這個單詞本身的意思，是“暫停、逗留”。這個選項的用處是用于解決，當需要關閉套接字時，協議棧發送緩沖區中尚有未發送出去的數據，等待這些數據發完的最長等待時間。
一個端口，尤其是作為服務器端端口在四次揮手的最后一步，有一個為TIME_WAIT的狀態，這個狀態一般持續2MSL(MSL，maximum segment life， 最大生存周期，RFC上建議是2分鐘)。這個狀態存在原因如下：1. 保證發出去的ack能被送達(超時會重發ack)2. 讓遲來的報文有足夠的時間被丟棄，反過來說，如果不存在這個狀態，那么可以立刻復用這個地址和端口號，那么可能會收到老的連接遲來的數據，這顯然是不好的。為了立即回收復用端口號，我們可以通過開啟套接字SO_REUSEADDR/SO_REUSEPORT。
默認情況下，當一個連接長時間沒有數據來往，會被系統
防火墻之類的服務關閉。為了避免這種現象，尤其是一些需要長連接的應用場景下，我們需要使用心跳包機制，即定時從兩端定時發一點數據，這種行為叫做“保活”。而tcp協議棧本身也提供了這種機制，那就是設置套接字SO_KEEPALIVE選項，開啟這個選項后，tcp協議棧會定時發送心跳包探針，但是這個默認時間比較長(2個小時)，我們可以繼續通過相關選項改變這個默認值。
二、常用的網絡故障排查工具
1.ping
ping命令可用于測試網絡是否連通。
2.telnet
例如：
telnet 120.55.94.78 8888
結合ping和telnet命令我們就可以判斷一個服務器地址上的某個端口號是否可以對外提供服務。由于我們使用的開發機器以windows居多，默認情況下，windows系統的telnet命令是沒有打開的，我們可以在【控制面板】- 【程序】- 【程序和功能】- 【打開或關閉Windows功能】中打開telnet功能。
3.host命令
常見的選項有：
-a (all)顯示所有選項，netstat默認不顯示LISTEN相關
-t (tcp)僅顯示tcp相關選項
-u (udp)僅顯示udp相關選項
-n 拒絕顯示別名，能顯示數字的全部轉化成數字。(重要)
-l 僅列出有在 Listen (監聽) 的服務狀態
-p 顯示建立相關鏈接的程序名(macOS中表示協議 -p protocol)
-r 顯示路由信息，路由表
-e 顯示擴展信息，例如uid等
-s 按各個協議進行統計 (重要)
-c 每隔一個固定時間，執行該netstat命令。
5. lsof命令
lsof，即list opened filedescriptor，即列出當前操作系統中打開的所有文件描述符，socket也是一種file descriptor，常見的選項是:
-i 列出系統打開的socket fd
-P 不要顯示端口號別名
-n 不要顯示ip地址別名(如localhost會用127.0.0.1來代替)
+c w 程序列名稱最大可以顯示到w個字符。
常見的選項組合為lsof –i –Pn：可以看到列出了當前偵聽的socket，和連接socket的tcp狀態。
6.pstack
嚴格意義上來說，這個不算網絡排查故障和調試命令，但是我們可以利用這個命令來查看某個進程的線程數量和線程調用堆棧是否運行正常。指令使用格式：
pstack pid即pstack 進程號。
7.nc命令
即netcat命令，這個工具在排查網絡故障時非常有用，因而被業績稱為網絡界的“瑞士軍刀”。常見的用法如下：
nc l 0.0.0.0 8888
nc 0.0.0.0 8888
我們知道客戶端連接服務器一般都是操作系統隨機分配一個可用的端口號連接到服務器上去，這個指令甚至可以指定使用哪個端口號連接，如：
nc –p 12345 127.0.0.1 8888
客戶端使用端口12345去連接服務器127.0.0.1::8888。
8 .tcpdump
這個是linux系統自帶的抓包工具，功能非常強大，默認需要開啟root權限才能使用。其常見的選項有：
-i 指定網卡
-X –XX 打印十六進制的網絡數據包
-n –nn 不顯示ip地址和端口的別名
-S 以絕對值顯示包的ISN號(包序列號)
常用的過濾條件有如下形式：
tcpdump –i any ‘port 8888’
tcpdump –i any ‘tcp port 8888’
tcpdump –i any ‘tcp src port 8888’
tcpdump –i any ‘tcp src port 8888 and udp dst port 9999’
tcpdump -i any \'src host 127.0.0.1 and tcp src port 12345\' -XX -nn -vv關于tcpdump命令接下來將會以對tcp三次握手和四次揮手的包數據進行抓包來分析。
三、tcp三次握手和四次揮手過程解析
熟練地掌握tcp三次握手和四次揮手過程的每一個細節是我們排查網絡問題的基礎。下面我們來通過tcpdump抓包能實戰一下三次握手的過程，假設我的服務器端的地址是 127.0.0.0.1 : 12345，使用nc命令創建一個服務器程序并在這個地址上進行偵聽：nc –v -l 127.0.0.0.112345;然后在客戶端機器上開啟tcpdump工具;然后在客戶端使用nc命令創建一個客戶端去連接服務器;
三次握手過程是客戶端先給服務器發送一個SYN，然后服務器應答一個SYN+ACK，應答的序列號是遞增1的，表示應答哪個請求，即從4004096087遞增到4004096088，接著客戶端再應答一個ACK。這個時候，我們發現發包序列號和應答序列號都變成1了，這是tcpdump使用相對序號，我們加上-S選項后就變成絕對序列號了。
還有一種情況就是客戶端訪問一個很遙遠的ip，或者網絡繁忙，服務器對客戶端發送的網絡SYN報文沒有應答，會出現什么情況呢?
我們先將防火墻的已有規則都清理掉: iptables -F;然后給防火墻的INPUT鏈上增加一個規則，丟棄本地網卡lo(也就是127.0.0.1這個回環地址)上的所有SYN包。接著，我們看到tcpdump抓到的數據包。連接不上，一共重試了5次，重試的時間間隔是1秒，2秒，4秒，8秒，16秒，最后返回失敗。這個重試次數在/proc/sys/net/ipv4/tcp_syn_retries 內核參數中設置，默認為6。
四次揮手與三次握手基本上類似。實際的網絡開發中，尤其是高QPS的服務器程序，可能在在服務器程序所在的系統上留下大量非ESTABLISHED的中間狀態，如CLOSE_WAIT/TIME_WAIT，我們可以使用以下指令來統計這些狀態信息：
netstat -n | awk \'/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}\'
得到結果可能類似。
下面看下一般比較關心的三種TCP狀態
服務端收到建立連接的SYN沒有收到ACK包的時候處在SYN_RECV狀態。有兩個相關系統配置：
1.net.ipv4.tcp_synack_retries，整形，默認值是5
對于遠端的連接請求SYN，內核會發送SYN + ACK數據報，以確認收到上一個 SYN連接請求包。這是三次握手機制的第二個步驟。這里決定內核在放棄連接之前所送出的 SYN+ACK 數目。不應該大于255，默認值是5，對應于180秒左右時間。通常我們不對這個值進行修改，因為我們希望TCP連接不要因為偶爾的丟包而無法建立。
2.net.ipv4.tcp_syncookies
一般服務器都會設置net.ipv4.tcp_syncookies=1來防止SYN Flood攻擊。假設一個用戶向服務器發送了SYN報文后突然死機或掉線，那么服務器在發出SYN+ACK應答報文后是無法收到客戶端的ACK報文的(第三次握手無法完成)，這種情況下服務器端一般會重試(再次發送SYN+ACK給客戶端)并等待一段時間后丟棄這個未完成的連接，這段時間的長度我們稱為SYN Timeout，一般來說這個時間是分鐘的數量級(大約為30秒-2分鐘)。這些處在SYNC_RECV的TCP連接稱為半連接，并存儲在內核的半連接隊列中，在內核收到對端發送的ack包時會查找半連接隊列，并將符合的requst_sock信息存儲到完成三次握手的連接的隊列中，然后刪除此半連接。大量SYNC_RECV的TCP連接會導致半連接隊列溢出，這樣后續的連接建立請求會被內核直接丟棄，這就是SYN Flood攻擊。能夠有效防范SYN Flood攻擊的手段之一，就是SYN Cookie。SYN Cookie原理由D. J. Bernstain和 Eric Schenk發明。SYN Cookie是對TCP服務器端的三次握手協議作一些修改，專門用來防范SYN Flood攻擊的一種手段。它的原理是，在TCP服務器收到SYN包并返回SYN+ACK包時，不分配一個專門的數據區，而是根據這個SYN包計算出一個cookie值。在收到ACK包時，TCP服務器在根據那個cookie值檢查這個TCP ACK包的合法性。如果合法，再分配專門的數據區進行處理未來的TCP連接。觀測服務上SYN_RECV連接個數為：7314，對于一個高并發連接的通訊服務器，這個數字比較正常。
發起TCP連接關閉的一方稱為client，被動關閉的一方稱為server。被動關閉的server收到FIN后，但未發出ACK的TCP狀態是CLOSE_WAIT。出現這種狀況一般都是由于server端代碼的問題，如果你的服務器上出現大量CLOSE_WAIT，應該要考慮檢查代碼。
根據三次握手斷開連接規定，發起socket主動關閉的一方 socket將進入TIME_WAIT狀態。TIME_WAIT狀態將持續2MSL。TIME_WAIT狀態下的socket不能被回收使用。具體現象是對于一個處理大量短連接的服務器，如果是由服務器主動關閉客戶端的連接，將導致服務器端存在大量的處于TIME_WAIT狀態的socket， 甚至比處于Established狀態下的socket多的多，嚴重影響服務器的處理能力，甚至耗盡可用的socket，停止服務。TIME_WAIT是TCP協議用以保證被重新分配的socket不會受到之前殘留的延遲重發報文影響的機制,是必要的邏輯保證。和TIME_WAIT狀態有關的系統參數有一般有3個。
四、 關于跨系統與跨語言之間的網絡通信連通問題
如何在Java語言中去解析C++的網絡數據包，如何在C++中解析Java的網絡數據包，對于很多人來說是一件很困難的事情，所以只能變著法子使用第三方的庫。其實使用tcpdump工具可以很容易解決與分析。
首先，我們需要明確字節序列這樣一個概念，即我們說的大端編碼(big endian)和小端編碼(little endian)，x86和x64系列的cpu使用小端編碼，而數據在網絡上傳輸，以及Java語言中，使用的是大端編碼。那么這是什么意思呢?
我們舉個例子，看一個x64機器上的32位數值在內存中的存儲方式：i在內存中的地址序列是0x003CF7C4~ 0x003CF7C8，值為40 e2 01 00。十六進制0001e240正好等于10進制123456，也就是說小端編碼中權重高的的字節值存儲在內存地址高(地址值較大)的位置，權重值低的字節值存儲在內存地址低(地址值較小)的位置，也就是所謂的高高低低。相反，大端編碼的規則應該是高低低高，也就是說權值高字節存儲在內存地址低的位置，權值低的字節存儲在內存地址高的位置。
一個C++程序的int32值123456不作轉換地傳給Java程序，那么Java按照大端編碼的形式讀出來的值是：十六進制40E20100 = 十進制1088553216。所以，我們要么在發送方將數據轉換成網絡字節序(大端編碼)，要么在接收端再進行轉換。以上就是小編要和大家分享的服務器開發中網絡數據分析與故障排查經驗，希望對您有所幫助。
故障賠償
極速響應
客戶服務
7*24小時售后支持
免費備案
京公網安備11030102000056號
京ICP備09061941號-4
商品已成功加入購物車
