一個基於C-S的文件傳輸練習而引發的網絡方面的思考

這幾天跟着教主學習java的文件或流,網絡編程等進階知識。以便爲寒假的項目實訓:多文件傳輸項目做準備。對於數據在網絡之間的傳輸,有了比較實在的理解,也漸漸懂得了tcp,udp,ip報文等知識,對於這些知識,之前只知表面,卻不知具體應用和在編程中如何體現。現在,在教主的帶領下,漸漸對這些知識有了更深一層的理解。我也深深地意識到了計算機網絡的重要性,得開始着手準備學習了。如果幸運的你看到了我的這篇博客,不妨先看看我的這個博文(自己整理的):Web開發筆記(一):http協議相關內容,C/S與B/S,ip報文,TCP,UDP

根據運行結果,我發現,我的代碼中,發送端客戶端每次發送8M的文件塊,而接收端服務器每次接收10M大小。開始我以爲,通過文件流的read和write操作,這個文件就是以每次10M進行接收的。然而,我錯了,輸出read操作的返回值(即真正每次讀取的大小),發現一個神奇的現象,TCP協議每次接收的大小不超過65536字節,即64K。

多虧教主,讓我們多看看計算機網絡的書,我還是知道一點TCP/IP協議的,每次接收的大小不超過64K的原因是!!!!!!!!理論上IP數據報(兩字節)最長長度可達65536個字節!!!!!!

所以,如果採用UDP協議實現文件傳輸,你不能保證數據到了底層後,被UDP到底切割了多少,一塊多大等等一系列問題,如果能解決每次發送了多少字節以及把丟的包重新發送等一系列繁瑣的操作,那麼,你就實現了一個TCP協議了,哈哈。

UDP是不管丟包,發送順序等問題的,發送端正常的發,但是接收端是接收多少就顯示多少,丟包後包是不會重新發送的。這一點體現在比如在qq或微信的語音聊天,視頻聊天,鬥魚的直播等等。發送端是保證發送沒問題,到了底層,往網絡上寫也是沒問題的,但是,接收方就不能保證沒問題了,這就是實時通信。

數據在廣域網上傳是要路由的,包在網絡中走得路徑是不一樣的,每到一個節點,就存儲起來,然後轉發給另一個節點,這就叫存儲轉發。網絡中的節點只能知道跟它連接的路由器的目的子網,只有一層,所以,在網絡中,一個路由器能知道自己的目的子網和跟它直接連接的路由器的目的子網。

如果一直在網絡中傳輸,離目的越走越遠,那麼,會發生什麼情況?

最開始我以爲是就在網絡中無限的傳輸,但是,事實卻不是這樣的。IP數據報報頭是有生命週期的,每過一個路由器就減1,等減爲0還沒有找到目的節點的話,這個包就被網絡扔了,即“掉包”。

最後,上面的文件傳輸代碼經過補充,已經可以完整的傳輸一個文件了,代碼如下:你可以下載下來,導入idea運行查看結果,先運行test包下的TestReceiver,再運行TestSebder。

https://github.com/yangchaoy259189888/FileTransfer

好了,我要繼續學習計算機網絡了。。。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章