2015-06-30 207 views
1

我有一些服務器,必須根據數據包的延遲情況做出不同的響應。獲取數據包的延遲(TCP UDP)

是否有可能在服務器端獲取單獨數據包的延遲(「旅行時間」)?(使用Python優先(但不是必需)或以某種方式配置的服務器)?

舉例清醒的認識:

# Pseudo-code 
def handle_packet(packet): 
    if packet.latency > X: 
     # Declare war on the latency gods 
    else: 
     # Make peace with the latency gods 

回答

0

假設我理解你的問題正確,你將不得不修改客戶端有一個「平」的操作。服務器將不得不ping通客戶端,然後客戶端立即用乒乓球迴應,並且服務器將不得不花時間從發送乒乓球到獲得乒乓球。這最好用UDP​​或TCP帶外完成,因爲使用普通TCP時,您的數據包可能會滯留在其他數據的隊列中,這些數據仍然是人爲增加ping的傳輸數據。

要回答更多的問題,我想你問。從計算機a到計算機b並返回到a的往返時間不是TCP或UDP中的標準操作,而是由ICMP(ping)處理的。你可以自由地使用TCP或UDP來實現自己的ping操作,但它不是標準的。

P.S.在你問之前,有幾個原因不要使用ICMP ping。其中一個可能會被防火牆擋住的可能性很小。二,它通常不會從無特權的過程中工作。大多數操作系統不支持ICMP協議,因此您必須對具有特權操作的網絡接口進行原始訪問。

迴應您的評論:

看來什麼你問的是得到它把數據包從客戶端去服務器沒有做乒乓球的時間。做到這一點的唯一可能的方法是,如果時鐘已同步,並且您將客戶端的時間放入數據包中。答:您的客戶很可能沒有同步時鐘。 B.即使客戶端確實擁有同步時鐘,您也必須在應用程序級別更改協議以添加此時間戳,這聽起來像您的問題聲明中不允許您這樣做。

+0

是的,但我必須得到服務器上的延遲,對於單獨的數據包,無需發送響應!那是主要特徵(和問題)。 – progerz

+0

@progerz根據我的猜測編輯 – CrazyCasta

+0

我不會低估,但推薦UDP或真正的任何「帶外」計時機制都有一些問題。更明顯的一點是,主流TCP流量和帶外測量很可能分開進行。或者將通過插入的開關元件進行不同的處理。使用「流失(out-of-flow)」機制來說明特定流量的內容是很難說的。 – cnicutar

0

這是不可能的。在分佈式系統中衆所周知,你不能相信在所有節點上都有相同的時鐘。只有當你有像NTP這樣的機制時,你才能擁有類似的時鐘,但仍然存在時鐘漂移(這取決於你可以忍受的錯誤)。即使你有相同的時鐘,你也需要一種方法來確定數據包何時離開PC,而你沒有。它是一個受控制的環境,或者你可能有未知的客戶?您能容忍測量中的任何誤差範圍嗎?我們是在談論100毫秒還是少於10毫秒的時間?這些是解決您的問題的關鍵。

根據@progerz的評論添加信息到我的回覆 如果NTP和幾ms的時鐘漂移適合你,那麼你可能有一個機制去做你需要的。請記住,您擁有的環境越不受控制,這可能就不那麼有用。例如,這可以在同一個數據中心內正常工作,而且在Wifi餐廳的連接客戶端和數據中心的服務器之間的連接不太好。

關於修改UDP或TCP,如果你需要修改UDP頭,基本上你正在實現一個新的協議,這是一種可能性,你需要給它分配一個新的協議號。您將無法使用數據報AF_INET套接字(或TCP流情況下的流套接字),您必須考慮使用較低級套接字(如原始套接字(或套接字套接字),但這不是必需的)。

#include <sys/socket.h> 
#include <netinet/in.h> 
raw_socket = socket(AF_INET, SOCK_RAW, your_new_protocol_number); 

另一種方法是通過UDP或TCP創建應用層協議。在這種情況下,你將能夠使用數據報/流套接字。

+0

現在,我正試圖讓這個計劃爲我工作,它真的很有趣。據我所知,NTP允許有類似的時鐘,差異可達幾毫秒。 所以我需要以某種方式修改UDP數據包,插入時間戳... – progerz

+0

@progerz在閱讀您的評論後,我修改了我的回覆以添加信息 – rodolk

+0

@progerz,這裏是解釋NTP如何用於Cassandra的另一個鏈接:https:// blog.logentries.com/2014/03/synchronizing-clocks-in-a-cassandra-cluster-pt-1-the-problem/。告訴我這個回覆是否有用。 – rodolk

0

如果度量的準確性不重要,您可以從某些應用程序行爲中猜出此值。例如,對於TCP,您可以假定客戶端在「連接」之後立即發送請求,並且客戶端的處理時間相對於網絡時間可以忽略不計。 也許你可以在應用程序中找到其他地方,在服務器的特定響應之後,客戶端會向你發送一些信息 - 然後再次使用時間差異來估計RTT。

因爲,如果需要更高的準確度,這些方法將無法很好地工作。