在互聯(lián)網(wǎng)后端日常開(kāi)發(fā)接口的時(shí)候中，不管你使用的是C、Java、PHP還是Golang，都避免不了需要調(diào)用mysql、redis等組件來(lái)獲取數(shù)據(jù)，可能還需要執(zhí)行一些rpc遠(yuǎn)程調(diào)用，或者再調(diào)用一些其它restful api。 在這些調(diào)用的底層，基本都是在使用TCP協(xié)議進(jìn)行傳輸。這是因?yàn)樵趥鬏攲訁f(xié)議中，TCP協(xié)議具備可靠的連接，錯(cuò)誤重傳，擁塞控制等優(yōu)點(diǎn)，所以目前應(yīng)用比UDP更廣泛一些。

[[375616]]

相信你也一定聽(tīng)聞過(guò)TCP也存在一些缺點(diǎn)，那就是老生常談的開(kāi)銷要略大。但是各路技術(shù)博客里都在單單說(shuō)開(kāi)銷大、或者開(kāi)銷小，而少見(jiàn)不給出具體的量化分析。不客氣一點(diǎn)，這都是營(yíng)養(yǎng)不大的廢話。經(jīng)過(guò)日常工作的思考之后，我更想弄明白的是，開(kāi)銷到底多大。一條TCP連接的建立需要耗時(shí)延遲多少，是多少毫秒，還是多少微秒?能不能有一個(gè)哪怕是粗略的量化估計(jì)?當(dāng)然影響TCP耗時(shí)的因素有很多，比如網(wǎng)絡(luò)丟包等等。我今天只分享我在工作實(shí)踐中遇到的比較高發(fā)的各種情況。

一、正常TCP連接建立過(guò)程

要想搞清楚TCP連接的建立耗時(shí)，我們需要詳細(xì)了解連接的建立過(guò)程。在前文《圖解Linux網(wǎng)絡(luò)包接收過(guò)程》中我們介紹了數(shù)據(jù)包在接收端是怎么被接收的。數(shù)據(jù)包從發(fā)送方出來(lái)，經(jīng)過(guò)網(wǎng)絡(luò)到達(dá)接收方的網(wǎng)卡。在接收方網(wǎng)卡將數(shù)據(jù)包DMA到RingBuffer后，內(nèi)核經(jīng)過(guò)硬中斷、軟中斷等機(jī)制來(lái)處理(如果發(fā)送的是用戶數(shù)據(jù)的話，最后會(huì)發(fā)送到socket的接收隊(duì)列中，并喚醒用戶進(jìn)程)。

在軟中斷中，當(dāng)一個(gè)包被內(nèi)核從RingBuffer中摘下來(lái)的時(shí)候，在內(nèi)核中是用struct sk_buff結(jié)構(gòu)體來(lái)表示的(參見(jiàn)內(nèi)核代碼include/linux/skbuff.h)。其中的data成員是接收到的數(shù)據(jù)，在協(xié)議棧逐層被處理的時(shí)候，通過(guò)修改指針指向data的不同位置，來(lái)找到每一層協(xié)議關(guān)心的數(shù)據(jù)。

對(duì)于TCP協(xié)議包來(lái)說(shuō)，它的Header中有一個(gè)重要的字段-flags。如下圖：

通過(guò)設(shè)置不同的標(biāo)記為，將TCP包分成SYNC、FIN、ACK、RST等類型。客戶端通過(guò)connect系統(tǒng)調(diào)用命令內(nèi)核發(fā)出SYNC、ACK等包來(lái)實(shí)現(xiàn)和服務(wù)器TCP連接的建立。在服務(wù)器端，可能會(huì)接收許許多多的連接請(qǐng)求，內(nèi)核還需要借助一些輔助數(shù)據(jù)結(jié)構(gòu)-半連接隊(duì)列和全連接隊(duì)列。我們來(lái)看一下整個(gè)連接過(guò)程：

在這個(gè)連接過(guò)程中，我們來(lái)簡(jiǎn)單分析一下每一步的耗時(shí)：

• 客戶端發(fā)出SYNC包：客戶端一般是通過(guò)connect系統(tǒng)調(diào)用來(lái)發(fā)出SYN的，這里牽涉到本機(jī)的系統(tǒng)調(diào)用和軟中斷的CPU耗時(shí)開(kāi)銷
• SYN傳到服務(wù)器：SYN從客戶端網(wǎng)卡被發(fā)出，開(kāi)始“跨過(guò)山和大海，也穿過(guò)人山人海......”，這是一次長(zhǎng)途遠(yuǎn)距離的網(wǎng)絡(luò)傳輸
• 服務(wù)器處理SYN包：內(nèi)核通過(guò)軟中斷來(lái)收包，然后放到半連接隊(duì)列中，然后再發(fā)出SYN/ACK響應(yīng)。又是CPU耗時(shí)開(kāi)銷
• SYC/ACK傳到客戶端：SYC/ACK從服務(wù)器端被發(fā)出后，同樣跨過(guò)很多山、可能很多大海來(lái)到客戶端。又一次長(zhǎng)途網(wǎng)絡(luò)跋涉
• 客戶端處理SYN/ACK：客戶端內(nèi)核收包并處理SYN后，經(jīng)過(guò)幾u(yù)s的CPU處理，接著發(fā)出ACK。同樣是軟中斷處理開(kāi)銷
• ACK傳到服務(wù)器：和SYN包，一樣，再經(jīng)過(guò)幾乎同樣遠(yuǎn)的路，傳輸一遍。 又一次長(zhǎng)途網(wǎng)絡(luò)跋涉
• 服務(wù)端收到ACK：服務(wù)器端內(nèi)核收到并處理ACK，然后把對(duì)應(yīng)的連接從半連接隊(duì)列中取出來(lái)，然后放到全連接隊(duì)列中。一次軟中斷CPU開(kāi)銷
• 服務(wù)器端用戶進(jìn)程喚醒：正在被accpet系統(tǒng)調(diào)用阻塞的用戶進(jìn)程被喚醒，然后從全連接隊(duì)列中取出來(lái)已經(jīng)建立好的連接。一次上下文切換的CPU開(kāi)銷

以上幾步操作，可以簡(jiǎn)單劃分為兩類：

• 第一類是內(nèi)核消耗CPU進(jìn)行接收、發(fā)送或者是處理，包括系統(tǒng)調(diào)用、軟中斷和上下文切換。它們的耗時(shí)基本都是幾個(gè)us左右。
• 第二類是網(wǎng)絡(luò)傳輸，當(dāng)包被從一臺(tái)機(jī)器上發(fā)出以后，中間要經(jīng)過(guò)各式各樣的網(wǎng)線、各種交換機(jī)路由器。所以網(wǎng)絡(luò)傳輸?shù)暮臅r(shí)相比本機(jī)的CPU處理，就要高的多了。根據(jù)網(wǎng)絡(luò)遠(yuǎn)近一般在幾ms~到幾百ms不等。

1ms就等于1000us，因此網(wǎng)絡(luò)傳輸耗時(shí)比雙端的CPU開(kāi)銷要高1000倍左右，甚至更高可能還到100000倍。所以，在正常的TCP連接的建立過(guò)程中，一般可以考慮網(wǎng)絡(luò)延時(shí)即可。一個(gè)RTT指的是包從一臺(tái)服務(wù)器到另外一臺(tái)服務(wù)器的一個(gè)來(lái)回的延遲時(shí)間。所以從全局來(lái)看，TCP連接建立的網(wǎng)絡(luò)耗時(shí)大約需要三次傳輸，再加上少許的雙方CPU開(kāi)銷，總共大約比1.5倍RTT大一點(diǎn)點(diǎn)。不過(guò)從客戶端視角來(lái)看，只要ACK包發(fā)出了，內(nèi)核就認(rèn)為連接是建立成功了。所以如果在客戶端打點(diǎn)統(tǒng)計(jì)TCP連接建立耗時(shí)的話，只需要兩次傳輸耗時(shí)-既1個(gè)RTT多一點(diǎn)的時(shí)間。(對(duì)于服務(wù)器端視角來(lái)看同理，從SYN包收到開(kāi)始算，到收到ACK，中間也是一次RTT耗時(shí))

二、TCP連接建立時(shí)的異常情況

上一節(jié)可以看到在客戶端視角，在正常情況下一次TCP連接總的耗時(shí)也就就大約是一次網(wǎng)絡(luò)RTT的耗時(shí)。如果所有的事情都這么簡(jiǎn)單，我想我的這次分享也就沒(méi)有必要了。事情不一定總是這么美好，總會(huì)有意外發(fā)生。在某些情況下，可能會(huì)導(dǎo)致連接時(shí)的網(wǎng)絡(luò)傳輸耗時(shí)上漲、CPU處理開(kāi)銷增加、甚至是連接失敗。現(xiàn)在我們說(shuō)一下我在線上遇到過(guò)的各種溝溝坎坎。

1. 客戶端connect系統(tǒng)調(diào)用耗時(shí)失控

正常一個(gè)系統(tǒng)調(diào)用的耗時(shí)也就是幾個(gè)us(微秒)左右。但是在《追蹤將服務(wù)器CPU耗光的兇手!》一文中筆者的一臺(tái)服務(wù)器當(dāng)時(shí)遇到一個(gè)狀況，某次運(yùn)維同學(xué)轉(zhuǎn)達(dá)過(guò)來(lái)說(shuō)該服務(wù)CPU不夠用了，需要擴(kuò)容。當(dāng)時(shí)的服務(wù)器監(jiān)控如下圖：

該服務(wù)之前一直每秒抗2000左右的qps，CPU的idel一直有70%+。怎么突然就CPU一下就不夠用了呢。而且更奇怪的是CPU被打到谷底的那一段時(shí)間，負(fù)載卻并不高(服務(wù)器為4核機(jī)器，負(fù)載3-4是比較正常的)。 后來(lái)經(jīng)過(guò)排查以后發(fā)現(xiàn)當(dāng)TCP客戶端TIME_WAIT有30000左右，導(dǎo)致可用端口不是特別充足的時(shí)候，connect系統(tǒng)調(diào)用的CPU開(kāi)銷直接上漲了100多倍，每次耗時(shí)達(dá)到了2500us(微秒)，達(dá)到了毫秒級(jí)別。

當(dāng)遇到這種問(wèn)題的時(shí)候，雖然TCP連接建立耗時(shí)只增加了2ms左右，整體TCP連接耗時(shí)看起來(lái)還可接受。但是這里的問(wèn)題在于這2ms多都是在消耗CPU的周期，所以問(wèn)題不小。 解決起來(lái)也非常簡(jiǎn)單，辦法很多：修改內(nèi)核參數(shù)net.ipv4.ip_local_port_range多預(yù)留一些端口號(hào)、改用長(zhǎng)連接都可以。

2. 半/全連接隊(duì)列滿

如果連接建立的過(guò)程中，任意一個(gè)隊(duì)列滿了，那么客戶端發(fā)送過(guò)來(lái)的syn或者ack就會(huì)被丟棄。客戶端等待很長(zhǎng)一段時(shí)間無(wú)果后，然后會(huì)發(fā)出TCP Retransmission重傳。拿半連接隊(duì)列舉例：

要知道的是上面TCP握手超時(shí)重傳的時(shí)間是秒級(jí)別的。也就是說(shuō)一旦server端的連接隊(duì)列導(dǎo)致連接建立不成功，那么光建立連接就至少需要秒級(jí)以上。而正常的在同機(jī)房的情況下只是不到1毫秒的事情，整整高了1000倍左右。尤其是對(duì)于給用戶提供實(shí)時(shí)服務(wù)的程序來(lái)說(shuō)，用戶體驗(yàn)將會(huì)受到較大影響。如果連重傳也沒(méi)有握手成功的話，很可能等不及二次重試，這個(gè)用戶訪問(wèn)直接就超時(shí)了。

還有另外一個(gè)更壞的情況是，它還有可能會(huì)影響其它的用戶。假如你使用的是進(jìn)程/線程池這種模型提供服務(wù)，比如php-fpm。我們知道fpm進(jìn)程是阻塞的，當(dāng)它響應(yīng)一個(gè)用戶請(qǐng)求的時(shí)候，該進(jìn)程是沒(méi)有辦法再響應(yīng)其它請(qǐng)求的。假如你開(kāi)了100個(gè)進(jìn)程/線程，而某一段時(shí)間內(nèi)有50個(gè)進(jìn)程/線程卡在和redis或者mysql服務(wù)器的握手連接上了(注意：這個(gè)時(shí)候你的服務(wù)器是TCP連接的客戶端一方)。這一段時(shí)間內(nèi)相當(dāng)于你可以用的正常工作的進(jìn)程/線程只有50個(gè)了。而這個(gè)50個(gè)worker可能根本處理不過(guò)來(lái)，這時(shí)候你的服務(wù)可能就會(huì)產(chǎn)生擁堵。再持續(xù)稍微時(shí)間長(zhǎng)一點(diǎn)的話，可能就產(chǎn)生雪崩了，整個(gè)服務(wù)都有可能會(huì)受影響。

既然后果有可能這么嚴(yán)重，那么我們?nèi)绾尾榭次覀兪诸^的服務(wù)是否有因?yàn)榘?全連接隊(duì)列滿的情況發(fā)生呢?在客戶端，可以抓包查看是否有SYN的TCP Retransmission。如果有偶發(fā)的TCP Retransmission，那就說(shuō)明對(duì)應(yīng)的服務(wù)端連接隊(duì)列可能有問(wèn)題了。

在服務(wù)端的話，查看起來(lái)就更方便一些了。netstat -s可查看到當(dāng)前系統(tǒng)半連接隊(duì)列滿導(dǎo)致的丟包統(tǒng)計(jì)，但該數(shù)字記錄的是總丟包數(shù)。你需要再借助watch命令動(dòng)態(tài)監(jiān)控。如果下面的數(shù)字在你監(jiān)控的過(guò)程中變了，那說(shuō)明當(dāng)前服務(wù)器有因?yàn)榘脒B接隊(duì)列滿而產(chǎn)生的丟包。你可能需要加大你的半連接隊(duì)列的長(zhǎng)度了。

$ watch 'netstat -s | grep LISTEN' 
    8 SYNs to LISTEN sockets ignored 

對(duì)于全連接隊(duì)列來(lái)說(shuō)呢，查看方法也類似。

$ watch 'netstat -s  | grep overflowed' 
    160 times the listen queue of a socket overflowed 

如果你的服務(wù)因?yàn)殛?duì)列滿產(chǎn)生丟包，其中一個(gè)做法就是加大半/全連接隊(duì)列的長(zhǎng)度。 半連接隊(duì)列長(zhǎng)度Linux內(nèi)核中，主要受tcp_max_syn_backlog影響 加大它到一個(gè)合適的值就可以。

# cat /proc/sys/net/ipv4/tcp_max_syn_backlog 
1024 
# echo "2048" > /proc/sys/net/ipv4/tcp_max_syn_backlog 

全連接隊(duì)列長(zhǎng)度是應(yīng)用程序調(diào)用listen時(shí)傳入的backlog以及內(nèi)核參數(shù)net.core.somaxconn二者之中較小的那個(gè)。你可能需要同時(shí)調(diào)整你的應(yīng)用程序和該內(nèi)核參數(shù)。

# cat /proc/sys/net/core/somaxconn 
128 
# echo "256" > /proc/sys/net/core/somaxconn 

改完之后我們可以通過(guò)ss命令輸出的Send-Q確認(rèn)最終生效長(zhǎng)度：

$ ss -nlt 
Recv-Q Send-Q Local Address:Port Address:Port 
0      128    *:80               *:* 

Recv-Q告訴了我們當(dāng)前該進(jìn)程的全連接隊(duì)列使用長(zhǎng)度情況。如果Recv-Q已經(jīng)逼近了Send-Q,那么可能不需要等到丟包也應(yīng)該準(zhǔn)備加大你的全連接隊(duì)列了。

如果加大隊(duì)列后仍然有非常偶發(fā)的隊(duì)列溢出的話，我們可以暫且容忍。如果仍然有較長(zhǎng)時(shí)間處理不過(guò)來(lái)怎么辦?另外一個(gè)做法就是直接報(bào)錯(cuò)，不要讓客戶端超時(shí)等待。例如將Redis、Mysql等后端接口的內(nèi)核參數(shù)tcp_abort_on_overflow為1。如果隊(duì)列滿了，直接發(fā)reset給client。告訴后端進(jìn)程/線程不要癡情地傻等。這時(shí)候client會(huì)收到錯(cuò)誤“connection reset by peer”。犧牲一個(gè)用戶的訪問(wèn)請(qǐng)求，要比把整個(gè)站都搞崩了還是要強(qiáng)的。

三、TCP連接耗時(shí)實(shí)測(cè)

我寫(xiě)了一段非常簡(jiǎn)單的代碼，用來(lái)在客戶端統(tǒng)計(jì)每創(chuàng)建一個(gè)TCP連接需要消耗多長(zhǎng)時(shí)間。

<?php 
$ip = {服務(wù)器ip}; 
$port = {服務(wù)器端口}; 
$count = 50000; 
function buildConnect($ip,$port,$num){ 
    for($i=0;$i<$num;$i++){ 
        $socket = socket_create(AF_INET,SOCK_STREAM,SOL_TCP); 
        if($socket ==false) { 
            echo "$ip $port socket_create() 失敗的原因是:".socket_strerror(socket_last_error($socket))."\n"; 
            sleep(5); 
            continue; 
        } 
 
        if(false == socket_connect($socket, $ip, $port)){ 
            echo "$ip $port socket_connect() 失敗的原因是:".socket_strerror(socket_last_error($socket))."\n"; 
            sleep(5); 
            continue; 
        } 
        socket_close($socket); 
    } 
} 
 
$t1 = microtime(true); 
buildConnect($ip, $port, $count); 
echo (($t2-$t1)*1000).'ms'; 

在測(cè)試之前，我們需要本機(jī)linux可用的端口數(shù)充足，如果不夠50000個(gè)，最好調(diào)整充足。

# echo "5000   65000" /proc/sys/net/ipv4/ip_local_port_range 

1. 正常情況

注意：無(wú)論是客戶端還是服務(wù)器端都不要選擇有線上服務(wù)在跑的機(jī)器，否則你的測(cè)試可能會(huì)影響正常用戶訪問(wèn)

首先我的客戶端位于河北懷來(lái)的IDC機(jī)房?jī)?nèi)，服務(wù)器選擇的是公司廣東機(jī)房的某臺(tái)機(jī)器。執(zhí)行ping命令得到的延遲大約是37ms，使用上述腳本建立50000次連接后，得到的連接平均耗時(shí)也是37ms。這是因?yàn)榍懊嫖覀冋f(shuō)過(guò)的，對(duì)于客戶端來(lái)看，第三次的握手只要包發(fā)送出去，就認(rèn)為是握手成功了，所以只需要一次RTT、兩次傳輸耗時(shí)。雖然這中間還會(huì)有客戶端和服務(wù)端的系統(tǒng)調(diào)用開(kāi)銷、軟中斷開(kāi)銷，但由于它們的開(kāi)銷正常情況下只有幾個(gè)us(微秒)，所以對(duì)總的連接建立延時(shí)影響不大。

接下來(lái)我換了一臺(tái)目標(biāo)服務(wù)器，該服務(wù)器所在機(jī)房位于北京。離懷來(lái)有一些距離，但是和廣東比起來(lái)可要近多了。這一次ping出來(lái)的RTT是1.6~1.7ms左右，在客戶端統(tǒng)計(jì)建立50000次連接后算出每條連接耗時(shí)是1.64ms。

再做一次實(shí)驗(yàn)，這次選中實(shí)驗(yàn)的服務(wù)器和客戶端直接位于同一個(gè)機(jī)房?jī)?nèi)，ping延遲在0.2ms~0.3ms左右。跑了以上腳本以后，實(shí)驗(yàn)結(jié)果是50000 TCP連接總共消耗了11605ms，平均每次需要0.23ms。

線上架構(gòu)提示：這里看到同機(jī)房延遲只有零點(diǎn)幾ms，但是跨個(gè)距離不遠(yuǎn)的機(jī)房，光TCP握手耗時(shí)就漲了4倍。如果再要是跨地區(qū)到廣東，那就是百倍的耗時(shí)差距了。線上部署時(shí)，理想的方案是將自己服務(wù)依賴的各種mysql、redis等服務(wù)和自己部署在同一個(gè)地區(qū)、同一個(gè)機(jī)房(再變態(tài)一點(diǎn)，甚至可以是甚至是同一個(gè)機(jī)架)。因?yàn)檫@樣包括TCP鏈接建立啥的各種網(wǎng)絡(luò)包傳輸都要快很多。要盡可能避免長(zhǎng)途跨地區(qū)機(jī)房的調(diào)用情況出現(xiàn)。

2. 連接隊(duì)列溢出

測(cè)試完了跨地區(qū)、跨機(jī)房和跨機(jī)器。這次為了快，直接和本機(jī)建立連接結(jié)果會(huì)咋樣呢?Ping本機(jī)ip或127.0.0.1的延遲大概是0.02ms，本機(jī)ip比其它機(jī)器RTT肯定要短。我覺(jué)得肯定連接會(huì)非常快，嗯實(shí)驗(yàn)一下。連續(xù)建立5W TCP連接，總時(shí)間消耗27154ms，平均每次需要0.54ms左右。嗯!?怎么比跨機(jī)器還長(zhǎng)很多? 有了前面的理論基礎(chǔ)，我們應(yīng)該想到了，由于本機(jī)RTT太短，所以瞬間連接建立請(qǐng)求量很大，就會(huì)導(dǎo)致全連接隊(duì)列或者半連接隊(duì)列被打滿的情況。一旦發(fā)生隊(duì)列滿，當(dāng)時(shí)撞上的那個(gè)連接請(qǐng)求就得需要3秒+的連接建立延時(shí)。所以上面的實(shí)驗(yàn)結(jié)果中，平均耗時(shí)看起來(lái)比RTT高很多。

在實(shí)驗(yàn)的過(guò)程中，我使用tcpdump抓包看到了下面的一幕。原來(lái)有少部分握手耗時(shí)3s+，原因是半連接隊(duì)列滿了導(dǎo)致客戶端等待超時(shí)后進(jìn)行了SYN的重傳。

我們又重新改成每500個(gè)連接，sleep 1秒。嗯好，終于沒(méi)有卡的了(或者也可以加大連接隊(duì)列長(zhǎng)度)。結(jié)論是本機(jī)50000次TCP連接在客戶端統(tǒng)計(jì)總耗時(shí)102399 ms，減去sleep的100秒后，平均每個(gè)TCP連接消耗0.048ms。比ping延遲略高一些。這是因?yàn)楫?dāng)RTT變的足夠小的時(shí)候，內(nèi)核CPU耗時(shí)開(kāi)銷就會(huì)顯現(xiàn)出來(lái)了，另外TCP連接要比ping的icmp協(xié)議更復(fù)雜一些，所以比ping延遲略高0.02ms左右比較正常。

四、結(jié)論

TCP連接建立異常情況下，可能需要好幾秒，一個(gè)壞處就是會(huì)影響用戶體驗(yàn)，甚至導(dǎo)致當(dāng)前用戶訪問(wèn)超時(shí)都有可能。另外一個(gè)壞處是可能會(huì)誘發(fā)雪崩。所以當(dāng)你的服務(wù)器使用短連接的方式訪問(wèn)數(shù)據(jù)的時(shí)候，一定要學(xué)會(huì)要監(jiān)控你的服務(wù)器的連接建立是否有異常狀態(tài)發(fā)生。如果有，學(xué)會(huì)優(yōu)化掉它。當(dāng)然你也可以采用本機(jī)內(nèi)存緩存，或者使用連接池來(lái)保持長(zhǎng)連接，通過(guò)這兩種方式直接避免掉TCP握手揮手的各種開(kāi)銷也可以。

再說(shuō)正常情況下，TCP建立的延時(shí)大約就是兩臺(tái)機(jī)器之間的一個(gè)RTT耗時(shí)，這是避免不了的。但是你可以控制兩臺(tái)機(jī)器之間的物理距離來(lái)降低這個(gè)RTT，比如把你要訪問(wèn)的redis盡可能地部署的離后端接口機(jī)器近一點(diǎn)，這樣RTT也能從幾十ms削減到最低可能零點(diǎn)幾ms。

最后我們?cè)偎伎家幌拢绻覀儼逊?wù)器部署在北京，給紐約的用戶訪問(wèn)可行嗎? 前面的我們同機(jī)房也好，跨機(jī)房也好，電信號(hào)傳輸?shù)暮臅r(shí)基本可以忽略(因?yàn)槲锢砭嚯x很近)，網(wǎng)絡(luò)延遲基本上是轉(zhuǎn)發(fā)設(shè)備占用的耗時(shí)。但是如果是跨越了半個(gè)地球的話，電信號(hào)的傳輸耗時(shí)我們可得算一算了。 北京到紐約的球面距離大概是15000公里，那么拋開(kāi)設(shè)備轉(zhuǎn)發(fā)延遲，僅僅光速傳播一個(gè)來(lái)回(RTT是Rround trip time，要跑兩次)，需要時(shí)間 = 15,000,000 *2 / 光速 = 100ms。實(shí)際的延遲可能比這個(gè)還要大一些，一般都得200ms以上。建立在這個(gè)延遲上，要想提供用戶能訪問(wèn)的秒級(jí)服務(wù)就很困難了。所以對(duì)于海外用戶，最好都要在當(dāng)?shù)亟C(jī)房或者購(gòu)買海外的服務(wù)器。