iT邦幫忙

1

請問封包傳送速度問題

請教一下若我們在大陸傳送資料到台灣大小大概100k 若單筆單檔傳送大概幾秒就好了,但若把檔案拆成1000筆,但大小不變總共還是100k,但時間就拉長到好幾10分,請問這是什麼原理呢?

樓主錯了,基本上 100K / 1.5K= 67 個封包,要傳很快,但是假如你分成 1000筆,那每個封包的資料量 是 0.1K,但封包大小基本上還是 1.5K,所以等於要傳 1000 個封包才能傳送完成,假如傳送 67 個封包需要 10秒,那麼 1000 各 就是 1000 / 67 * 10 =149 秒,相差 15倍左右,這還不包括每次傳輸一個檔案前的三步握手時間,以及傳輸後的資料比對時間
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中
0
msnman
iT邦研究生 1 級 ‧ 2017-05-04 16:38:11

磁碟IO的問題。
大檔寫入跟小檔寫入的問題。
你自已用磁碟讀寫測速軟體跑看看就知道,4K的寫入是很慢的,4K以下更慢。

0
竹本立里
iT邦好手 1 級 ‧ 2017-05-04 16:50:02

原始資料是100K
但是加上封包的頭尾....格式 傳輸的資料還會是100K 嗎??

6
bizpro
iT邦大師 1 級 ‧ 2017-05-04 21:12:52
  1. TCP/IP的握手需要時間, 海峽間的握手需要更長時間, 加上接續連線請求造成的延遲, 假設平均需要0.5秒, 1000次握手就需要500秒, 那就超過8分鐘. 這也是優化網站效能要減小TCP/IP握手的次數.
  2. TCP/IP的重送效應可能很大.
  3. 另一個大的延時在應用層層次, 對執行緒的處理方式造成耗時, 不同的傳輸應用程式/方式有不同的影響.
  4. TCP/IP的表頭有一些影響, 雖不是很大, 也加了一點點時間.
  5. 硬體層中, 受到儲存裝置處理100k和1000次0.1k的影響應該很小.

註: TCP/IP三階段握手:
Client(CLOSED)-->SYN; Client(SYN_SENT)-->Server(LISTEN)
Server(LISTEN)-->SYN/ACK; Server(SYN_RECEIVED)->Client(SYN_SENT)
Client(SYN_SENT)-->ACK; Client(ESTABLISHED)-->Server(ESTABLISHED)

bizpro iT邦大師 1 級 ‧ 2017-05-05 15:45:42 檢舉

剛好有空寫了一個腳本, 用dd建立了一個100k的空檔, 和1000個0.1k的空檔, 然後用scp傳檔測試, 中間沒有任何sleep:

#!/bin/bash
rm *.txt
dd if=/dev/zero of=100k.txt bs=1024 count=0 seek=100 1>/dev/null
for i in `seq 1 1000`; do
  dd if=/dev/zero of=0.1k-$i.txt bs=102 count=0 seek=1 1>/dev/null
done

START=$(date +%s.%N)
scp 100k.txt adminuser@192.168.0.88:~/testfile/
END=$(date +%s.%N)
DIFF1=$(echo "$END - $START" | bc | sed "s/^./0./" )

START=$(date +%s.%N)
for i in `seq 1 1000`; do
  scp 0.1k-$i.txt adminuser@192.168.0.88:~/testfile/
done
END=$(date +%s.%N)
DIFF2=$(echo "$END - $START" | bc)
DIFF3=$(echo "$DIFF2 - $DIFF1" | bc)
RATIO=$(echo "$DIFF3*100/$DIFF1"|bc)
echo "To scp a single file of 100kb in size takes $DIFF1 and to scp 1000 files of 0.1kb each in size takes $DIFF2"
echo "The time difference ratio is $RATIO%"

結果是:

To scp a single file of 100kb in size takes 0.268555700 and to scp 1000 files of 0.1kb each in size takes 263.874764439
The time difference ratio is 98156%

那是981倍!.

bizpro iT邦大師 1 級 ‧ 2017-05-05 20:50:55 檢舉

再做一次測試, 這次增加一個測試: 1000個1k的檔案:

#!/bin/bash
rm *.txt
dd if=/dev/zero of=100k.txt bs=1024 count=0 seek=100 1>/dev/null
for i in `seq 1 1000`; do
  dd if=/dev/zero of=0.1k-$i.txt bs=102 count=0 seek=1 1>/dev/null
  dd if=/dev/zero of=1k-$i.txt bs=1024 count=0 seek=1 1>/dev/null
done


START=$(date +%s.%N)
scp 100k.txt adminuser@192.168.0.88:~/testfile/
END=$(date +%s.%N)
DIFF1=$(echo "$END - $START" | bc | sed "s/^./0./" )

START=$(date +%s.%N)
for i in `seq 1 1000`; do
  scp 0.1k-$i.txt adminuser@192.168.0.88:~/testfile/
done
END=$(date +%s.%N)
DIFF2=$(echo "$END - $START" | bc)
DIFF3=$(echo "$DIFF2 - $DIFF1" | bc)
RATIO1=$(echo "$DIFF3*100/$DIFF1"|bc)

START=$(date +%s.%N)
for i in `seq 1 1000`; do
  scp 1k-$i.txt adminuser@192.168.0.88:~/testfile/
done
END=$(date +%s.%N)
DIFF4=$(echo "$END - $START" | bc)
DIFF5=$(echo "$DIFF4 - $DIFF1" | bc)
RATIO2=$(echo "$DIFF5*100/$DIFF1"|bc)

DIFF6=$(echo "$DIFF4 - $DIFF2" | bc)
RATIO3=$(echo "$DIFF6*100/$DIFF2"|bc)

echo "1x100k=$DIFF1"
echo "1000x0.1k=$DIFF2; RATIO OVER 1X100K: $RATIO1"
echo "1000x1k=$DIFF4; RATIO OVER 1x100k: $RATIO2; RATIO OVER 1000x0.1k: $RATIO3"

結果是:

1x100k=0.266028082
1000x0.1k=261.604391897; RATIO OVER 1X100K: 98237
1000x1k=262.151353571; RATIO OVER 1x100k: 98442; RATIO OVER 1000x0.1k: 0

傳1000個0.1k或傳1000個1k的時間相近, 差不多是傳一個100k的980+倍, 這表示可以不計TCP/IP的表頭封包的影響, 也可忽略硬體層的影響.

TCP/IP三階段握手非常昂貴, 所以Googlg提出QUIC的協定:
https://en.wikipedia.org/wiki/QUIC
這是一個過牆梯, 爬UDP的牆.

bizpro iT邦大師 1 級 ‧ 2017-05-07 14:23:44 檢舉

再加幾個測試:
1000個5K是1000倍
1000個10K是968倍
也就是說, 1000個10K, 和1000個1K的總傳輸時間相近,其平均時間和傳送單一100K的檔案一樣, 所以, 花在TCP/IP協定的時間是固定的且遠超過在LAN中傳送檔案的時間, 共要花1000次的起滅TCP/IP連線, 單單是在LAN, 這個起滅時間就要260ms了, 何況是複雜的跨海峽連線.
(如果有時間抓封包檢視可能會更真實.)

0
wwx
iT邦好手 1 級 ‧ 2017-05-05 08:36:34

100K的資料傳輸時間由幾秒變成要數十分鐘,
感覺是自行開發的程式所設計的傳輸方式才發生的問題

如果是UDP看是否因為發包頻率不當導致掉包,
那麼就要檢查程式若有掉包的重傳機制是否妥當

使用TCP的話要看每個迴圈是否有安插delay的設計,
因為跑一次迴圈只會被delay一次
而跑1000次迴圈就會被delay 1000次
如果迴圈每送一次是安排休息1秒,
那麼1000次就是16.67分鐘以上了...

我猜是類似後面這種原因最有可能!

WilliamHuang
iT邦研究生 1 級 ‧ 2017-05-05 11:37:38
【**此則訊息已被站方移除**】

我要發表回答

立即登入回答