區域網內，如何實現把一台電腦的100MB數據最快速的傳輸到其他50台電腦？
區域網內，如何實現把一台電腦的100MB數據最快速的傳輸到其他50台電腦？
用TCP貌似不行啊，因為TCP會同時發50個100MB，大家都慢了。用UDP廣播/組播的話，丟包亂序怎麼辦，有什麼成熟的方案嗎？P2P可以嗎？P2P不也是網路同時有很多數據占著帶寬嗎？
Cisco私有路由協議EIGRP所實現的組播可靠傳輸可以拿來借鑒。
EIGRP工作原理
1）在乙太網廣播網段使用組播地址224.0.0.10發送hello，發現所有的鄰居，建立neighbor list table2）發送路由更新（大塊數據）到224.0.0.10這個地址，neighbor list 里所有鄰居接收到路由更新之後，都需要發送ACK給源路由器，如果源路由器接收到所有鄰居的ACK，說明一切OK，繼續發送；
如果沒有接收到某些路由器的ACK（丟包、路由器掛了），則啟動超時等待，如果定時器超時還沒有收到ACK，則用單播重傳給 NON-ACK 所有路由器，直到接收到ACK為止。
通過以上的組播發送/確認，單播重傳/確認的方式保證傳輸的可靠性。
如果想使用現有的工具，使用P2P軟體是一個不錯的選擇，剛開始可能有點慢，因為數據源只有一個，但一旦別的主機有了文件的copy，也成為數據源，將會有多個P2P、P2MP輻射，傳輸速度會越來越快。
無論組播傳輸、還是P2P，最終的瓶頸是交換機，也就是說，交換機的轉發性能（一秒鐘可以轉發多少G的數據）將是傳輸速率的最終極限。
咱們先看看如果用FTP傳輸的瓶頸在哪裡，伺服器的物理介面帶寬是瓶頸，最終交換機傳輸的數據為50*50 = 2500 M；採用組播，交換機最終傳輸的數據也是2500M（交換機replicate給50個客戶端），但速度肯定比FTP要快；採用P2P最終也是傳輸2500M數據，但由於有多個數據源，即多個物理鏈路帶寬，所以也會比FTP採用單個物理帶寬速度快。如果純粹是吹吹牛的話，當然是組播+軟體。但是，組播網的設計和實施也是個不小的工程好吧？從二層到三層，全網路部署到每一台交換機，你以為網路默認自帶？你這點數據量還不夠網路設計的時間。以前在電信，搞個iptv部署，光接入層的配置，就把人搞死了。組播這東西還未高潮過，就已經沒落了，我基本未見過在現實網路中有應用過。再說組播軟體，恕我小白，只見過視頻播放的軟體。像組播傳輸，都是管殺不管埋的，像視頻這種，卡一下，丟個幀都還能接受，數據怎麼辦？只有交給傳輸層或應用層，需要單播重傳的糾錯機制。你太不了解現在網路的能力了，千兆網都爛大街了，100M也就是一秒的事情，這點數據量對網路基本沒什麼影響。不要搞事情，安靜地用P2P軟體就好了。
要求不是太苛刻的話老老實實TCP。不要用UDP組播或者廣播傳輸大量數據，UDP是沒有流控的，會嚴重影響其他網路流量如TCP的網路質量，而組播很難擴展到跨三層的網路中，組播（IGMP）需要交換機和路由器支持，而廣播不能控制範圍，對大二層網路來說可能廣播的影響範圍會非常大。在流行的一些網路技術如VXLAN中，廣播可能是通過端點複製的方式轉換成單播進行的，效率並不比直接單播高。如果是常規進行的多播傳輸，現在最流行的方案是kafka，它是一個專門為多播優化的MQ。其他可以考慮的方案包括先從一台上複製到多台server，再從多台server複製到更多下層節點的方案。
當然是組播，工具都是現成的。
https://linux.die.net/man/1/udp-sender
https://linux.die.net/man/1/udp-receiver
就沒有人老老實實先問清楚實際的拓撲就瞎扯組播還學思科eigrp? 即便是組播如果下行50個電腦為不同vlan接在同一個物理口(例如mstp線路)用組播反而更慢還會丟包，因為網路設備的組播複製能力也有問題
有些時候不考慮實際拓撲和網路能力及網路設備實際實現能力就是扯淡。
例如很多交換機在組播複製份數過多時fan out 會擁塞
利益相關：國內幾大交易所的行情網(除了組播太多丟包的某所)，都是我設計的，組播不穩定的事處理得多的去了，題目是：「區域網內，如何實現把一台電腦的100MB數據最快速的傳輸到其他50台電腦？」
我的回答是：「糾刪碼（Erasure codes）和P2P」詳細的回答：「將文件F（100MB）編碼為100大小的校驗塊（每個2MB），使得任意50個校驗塊都可以恢復出原始文件F，然後區域網內50個節點開啟P2P程序，每個節點收到50個校驗塊就可以了。」最理想的情況，用網路編碼（network coding）可以達到理論上的最優——即用最小的帶寬達到最大的信息量傳輸。詳情Google network coding。這裡給出一個network coding 最簡單的一個例子（如何從最上面的兩個節點將數據A和B分發給最下面兩個節點的例子）：
看到題目被糾正為100MB數據量了。沒毛病，這個量也不是很大，順帶一提，儘管IGMP看起來很嬌貴，但一個500Mbps的組播對正規的千兆交換機而言都不是問題，也就一秒多就完事了。儘管UDP無流控，但是至少我所用過的幾款交換機似乎都能設置組播速率，而後文中提到的NORM和PGM更是為了提供可靠性及重發送機制，必須設置傳輸速率（因為重發需要緩存已發送的包，二者使用內存存儲，在IVL內對所有發出內容存儲需要佔用內存，為控制最大內存佔用需設置最大速率）。
———————————————
UDP組播顯然效能更高，不過有兩大問題，一是包長受限，UDP不是TCP，理論模型是Datagram不是Stream；二是包序和丟包的問題。可靠組播這個東西，其實很早即有人研究了很多方案了。比較經典的有openpgm的EPGM和PGM協議，利用UDP/RawSocket模擬TCP做到可靠有序傳輸，順帶幫你解決了包變流的問題，不用擔心包長了；還有一個是啥美國海軍先進通信技術研究所折騰出來的NORM協議，原理類似，用過但未深究。利用KCP協議理論上也能搞可靠UDP，不過我也沒去折騰。
當然自己折騰個協議照理說也沒啥不好的，不過這裡面門道還是挺多的，需要比較紮實的基礎。
再一種方法是用類似於BT/ed2k的方式做p2p傳輸，這樣能夠隨著傳輸過程逐步增加數據源而使得傳輸逐步加快。畢竟如今的網卡基本都是全雙工的了，出入不衝突，而正常的交換機的帶寬遠超網卡能力。
不過話說回來了……100Mb……不到13MB……這個數據量簡直小得可憐……
用p2p最實用
題主說的這個情況不就是數字化變電站內部過程層的實時電流電壓數據採集共享嗎？
事實上，IEC早就為這個情況制定了一個協議IEC61850. 大家有興趣可以查一查，在工業上，這種基於區域網的應用一般採用光纖交換機，可以認為是不會丟包的。所以協議層直接採用基於鏈路層也就是乙太網報文的協議，IEC專門為這種乙太網報文定義了幀類別（非IP報文），這是一種單向無鏈接的協議，在鏈路層利用交換機直接進行硬體級的廣播和組播，效率極高。
至於為什麼不用基於IP報文的協議？很簡單，工業系統對實時性，可靠性要求很高。像基於IP包文這種無法保證指定時間內可靠到達，需要重傳的協議，是無法滿足要求的。另外，報文協議棧簡單粗暴，處理起來高效快速。跟著學習一下吧，很多在企業做網管的在內網推Windows Update所面臨的流量爆炸的情景很符合這個題的描述。
答主沒限定必須用乙太網和tcp/udp 協議。要想最快你需要的是infiniband或者omnipath, 你也不用關心底層的那些協議和API, 裝個MPI,然後直接MPI_Bcast，體驗一下什麼叫100Gb/s的帶寬，什麼叫幾百納秒的延遲，什麼叫做RDMA（內存到內存直接複製）。這就叫「一力破十會，菜刀破武術，板磚破氣功。」
WINDOWS系統下請搜索：HOU文件多播
很小的一個軟體，共兩部分：發送端和接收端。鑒於你要同時把資料發送到50台電腦上的這種需求，應該是機房使用，通過批處理先在50台電腦上運行接收端，然後在發送端選擇文件發送，非常快，快到你想哭！（想起以前折騰的那麼多文件傳輸軟體。。。）可惜軟體原作者不更新了。。。
PS：通過共享、FTP或者IIS都不是很好第一、操作不方便第二、各客戶機的傳輸速度是共享發送端主機的物理總帶寬的手持金士頓，站在風雨中。
裝Python3了嗎？裝了話可以這樣搞：發送機：
python3 -m http.server 80
wget.download(發送機IP/filename)
還是UDP組播吧，把文件分片+校驗碼，都傳完了上報一個丟失列表，丟了哪個就重傳哪個。
可以設定一個超時時間，按順序發送（但是因為使用UDP協議還有組播，最終還是會亂序）假設每秒發送1000個包，第一萬號都到了第1號還沒到就可以判斷這個包丟了，發單播重傳吧。
如果單線程複製，這個是斐波那契數列的問題 假設時間單位T是刻：第一台電腦在第一刻，複製到第二個電腦上，然後這2個電腦，在第2刻同時複製出4個，然後是8個1，2，4，8，16，32，64。。。複雜度大概是2^N規模，時間需要T*LgN就是說1024個電腦，需要十次50個電腦，2^6=64&>50,需要6次。當然，可以考慮縮小文件規模，把文件M變成k個小m，需要時間變成t,這樣可以大大縮小總體時間。如果m可以並行，那麼時間就變成了t=T/k每個電腦上提前裝個軟體，用來分發複製，時間需要T*Lg(N)/k ，但是要加上一個分割C1和一個合併C2的時間。這要求C1+T*Lg(N)/k+C2的最小值，要測定三個變數C1、C2和k的最優比是多少。如果C1，C2和k成正比，那麼就變成了
2ck+T*Lg(N)/k的最小值,這裡只有k是變數，用大一知識，對這個函數求2次導數=0，就可以找到在取值範圍內的極值點，得到k
大概思路如此，有些數學早忘記了，可能有不精確的地方，希望大家彌補。我有個同事專門為這種需求,寫了個分散式文件同步服務(基於http) @天才
區域網內bt下載？
btsync
走P2P，方便實用容易跑滿帶寬難道只有我一個是認為直接拔硬碟拷貝么？如果數據量是100T而不是100MB的話
推薦閱讀：
※該怎麼看待網路語言？
※網址上的 https 跟 http 相比，加了一個 s，有什麼用？
※HTTP是個無狀態協議，怎麼保持登錄狀態？
※寫後端 Python，nodejs和php哪個更好一些？
※IP地址為什要分類？就是a類,b類,c類。。。?