上傳文件的原理

Ⅰ qq傳輸文件原理是什麼，

QQ是一個基於TCP/UDP協議的通訊軟體，在 TCP/IP協議中，唯一標識一個應用進程的是socket，它通過網路層的IP地址和傳輸層的埠號來實現，對與同一個IP地址的內部網路，通過不同的埠號來標識不同的QQ進程；當你登陸QQ伺服器的時候，伺服器會保留你的保留IP地址和埠號信息，並在你的好友的QQ進程中進行列表顯示，然後兩個進程就可以通信了。
通常，發送文件的計算機首先要通過消息伺服器將其IP地址發送給接收計算機，當接收計算機同意接收的確認消息反饋到消息伺服器後，消息伺服器將據此設置好文件傳輸對話。隨即，發送計算機與接收計算機就會在確定好的埠范圍內，建立起TCP或UDP連接開始文件的檢索與傳輸。 在默認狀態下，QQ優先採用了UDP（User Data Protocol，用戶數據報協議）協議傳送數據，而對可靠性要求高的數據通訊系統往往使用TCP協議傳輸數據。與TCP協議不同，UDP協議並不提供數據傳送的驗證機制——在整個文件傳輸過程中如果出現數據報的丟失，協議本身並不能作出任何的檢測或提示。因此，通常人們把UDP協議稱為不可靠的傳輸協議。 UDP協議適用於無須應答、要求時效的軟體使用，這樣的設計正好與QQ追求的目標相符，所以QQ優先使用了此協議進行一切功能應用。但是，由於UDP協議具有不可靠性，常會因種種原因導致消息或數據的發送失敗（很多時候會發現發送文件給對方接收時，對方根本收不到要求接收文件的消息。或是發送聊天消息時，對方根本沒有收到過消息）。顯然，UDP協議由於排除了信息可靠傳遞機制，將安全和排序等功能移交給上層應用來完成，極大降低了執行時間，使速度得到了保證。QQ在數據傳輸上更注重實際性能，為了獲得更好的使用效果，往往可以犧牲一定的可靠性。

Ⅱ ftp文件傳輸原理

在遇到了一個wireshark數據包分析題之後，看到了ftp的相關信息，但是沒找到相關的flag信息，請教了大佬的解釋，才知道ftp文件傳輸並不是在21埠，ftp文件傳輸有主動和被動兩種方式，

被動（PASV）模式：

PASV（被動）方式的連接過程是：客戶端向伺服器的FTP埠（默認是21）發送連接請求，伺服器接受連接，建立一條控制連接。當需要傳送數據時，伺服器在命令鏈路上用PASV命令告訴客戶端：「我打開了XXXX埠，你過來連接我」。於是客戶端向伺服器的XXXX埠發送連接請求，建立一條數據鏈路來傳送數據。

伺服器控制埠（21），伺服器端等待的數據傳輸埠（動態申請）

ftp伺服器動態申請一個埠（一般大於1024）然後告訴客戶端，我在這個埠上等待你的連接，客戶端收到以後便向伺服器的這個埠發起連接，數據連接建立以後，數據傳輸就可以開始了

埠計算方法：172,16,101,104,7,254，256*7+254=2046

一次完整的被動連接及數據傳輸過程：

狀態: 正在連接 172.16.101.104:21...

狀態: 連接建立，等待歡迎消息...

響應: 220 Serv-U FTP Server v6.4 for WinSock ready...

命令: USER test

響應: 331 User name okay, need password.

命令: PASS ****

響應: 230 User logged in, proceed.

狀態: 已連接

狀態: 讀取目錄列表...

命令: PWD

響應: 257 "/" is current directory.

狀態: 列出目錄成功

狀態: 正在連接 172.16.101.104:21...

狀態: 連接建立，等待歡迎消息...

響應: 220 Serv-U FTP Server v6.4 for WinSock ready...

命令: USER test

響應: 331 User name okay, need password.

命令: PASS ****

響應: 230 User logged in, proceed.

狀態: 已連接

狀態: 開始上傳 E:\Downloads\liugong\liugong\404.htm

命令: CWD /

響應: 250 Directory changed to /

命令: TYPE A

響應: 200 Type set to A.

命令: PASV

響應: 227 Entering Passive Mode (172,16,101,104,8,86)

命令: STOR 404.htm

響應: 150 Opening ASCII mode data connection for 404.htm.

響應: 226 Transfer complete.

狀態: 文件傳輸成功，傳輸了 2,052 位元組 (用時1 秒)

狀態: 讀取目錄列表...

命令: TYPE I

響應: 200 Type set to I.

命令: PASV

響應: 227 Entering Passive Mode (172,16,101,104,8,88)

命令: MLSD

響應: 150 Opening BINARY mode data connection for MLSD.

響應: 226 Transfer complete.

狀態: 列出目錄成功

主動（PORT）模式：

PORT（主動）方式的連接過程是：客戶端向伺服器的FTP埠（默認是21）發送連接請求，伺服器接受連接，建立一條控制連接。當需要傳送數據時，客戶端在命令鏈路上用PORT命令告訴伺服器：「我打開了XXXX埠，你過來連接我」。於是伺服器從20埠向客戶端的XXXX埠發送連接請求，建立一條數據鏈路來傳送數據。

一次完整的主動連接及數據傳輸過程：

狀態: 正在連接 172.16.101.104:21...

狀態: 連接建立，等待歡迎消息...

響應: 220 Serv-U FTP Server v6.4 for WinSock ready...

命令: USER test

響應: 331 User name okay, need password.

命令: PASS ****

響應: 230 User logged in, proceed.

狀態: 已連接

狀態: 開始上傳 E:\Downloads\liugong\liugong\404.htm

命令: CWD /

響應: 250 Directory changed to /

命令: TYPE A

響應: 200 Type set to A.

命令: PORT 172,16,101,104,8,76

響應: 200 PORT Command successful.

命令: STOR 404.htm

響應: 150 Opening ASCII mode data connection for 404.htm.

響應: 226 Transfer complete.

狀態: 文件傳輸成功，傳輸了 2,052 位元組 (用時1 秒)

狀態: 讀取目錄列表...

命令: TYPE I

響應: 200 Type set to I.

命令: PORT 172,16,101,104,8,77

響應: 200 PORT Command successful.

命令: MLSD

響應: 150 Opening BINARY mode data connection for MLSD.

響應: 226 Transfer complete.

狀態: 列出目錄成功

再回來說這一題，看到

計算埠為 4*256+17=1041

埠過濾，追蹤tcp流

Ⅲ ASP文件上傳原理分析及實現實例

摘要 在基於/的應用環境中 上傳各種類型的文件一直是困擾用戶文件管理應用的難題之一 在HTTP中上傳文件有三種機制 RFC PUT和WebDAV 常用的實現方法是利用在RFC 中引入的一個新類型 File以及ADO Stream對象 本文對上述上傳方法及實現原理作了論述 並給出了具體解決實例 ASP FILE對象

當前 基於/模式的應用比較流行 當用戶需要將文件傳輸到上時 常用方法之一是運行FTP並將每個用戶的FTP默認目錄設為用戶的Web主目錄 這樣用戶就能運行FTP客戶程序並上傳文件到指定的 Web目錄 這就要求用戶必須懂得如何使用FTP客戶程序 因此 這種解決方案僅對熟悉FTP且富有經驗的用戶來說是可行的 如果我們能把文件上傳功能與Web集成 使用戶僅用Web就能完成上傳任務 這對於他們來說將是非常方便的 但是 一直以來 由於File System Object的僅能傳送文本文件的局限 所以ASP最大的難題就是文件上傳問題 下面介紹的就是如何在基於HTTP協議的網頁中實現文件的上傳

一 通過HTTP上傳的三種機制

通過HTTP上傳有三種機制 RFC PUT 和 WebDAV

PUT 是在HTTP 引入了一個新的HTTP動詞 當web收到一個HTTP PUT和對象名字 它將會驗證用戶 接收HTTP流的內容 並把它直接存入web 由於這可能會對一個web站點造成破壞 並且還會失去HTTP最大的優勢 可編程性 在PUT的情況下 自己處理請求 沒有空間讓CGI或者ASP應用程序介入 唯一讓你的應用程序捕獲PUT的方法是在低層操作 ISAPI過濾層 由於相應的原因 PUT的應用很有限

而WebDAV允許web內容的分布式拆吵認證與翻譯 它引入了幾種新的HTTP動詞 允許通過HTTP上傳 鎖定/解鎖 登記/檢驗web內容行御知 Office 中的 Save to web 就是通過WebDAV來實現的 如果你所感興趣的一切都是上傳內容 WebDAV應用得非常出色 它解決了很多問題 然而 如果你需要在你的web應用程序裡面上傳文件 WebDAV對你就毫無用處可言 象HTTP PUT一樣 那些WebDAV的動詞是被解釋的 而不是web應用程序 你需要工作在ISAPI過濾層來訪問WebDAV的這些動詞 並在你的應用程序中解釋內容

RFC （） 最終被W C在HTML 中接受前 是作為一種建議標准 它是一種非常簡單但是功能很強大的想法 在表單欄位中定義一個新類型 <INPUT TYPE= FILE >

並且在表單本身加入了不同的編碼方案 不再使用典型的 <FORM ACTION= formproc asp METHOD= POST > 而是使用 <FORM ACTION= formproc asp METHOD= POST ENCTYPE= multipart/form data >

這種編碼方案在傳送大量數據的時候 比起預設的 application/x url encoded 表單編碼方案 顯得效率要高得多 URL編碼只有很有限的字元集 使用任何超出字檔消符集的字元 必須用 %nn 代替 這里的nn表示相應的 個十六進制數字 例如 即使是普通的空格字元也要用 % 代替 而RFC 使用多部分MIME編碼 就象通常在e mail消息中看到的那樣 不編碼來傳送大量數據 而只是在數據周圍加上很少的簡單但實用的頭部 主要的廠商都採用了建議的 瀏覽…… 按鈕 用戶能很容易的使用本地 打開文件…… 對話框選擇要上傳的文件

RFC 仍然將大多數文件上傳的靈活方法留給了你的web應用程序 PUT用得很有限 WebDAV對內容的作者很有用 比如FrontPage用戶 但是對想在web應用程序中加入文件上傳的web開發者來說很少用到 因此 RFC 是在web應用程序中加入文件上傳的最好的辦法

在實際應用中 免費提供了Posting Acceptor ASP不懂 multipart/form data 編碼方案 取而代之 提供了Posting Acceptor Posting Acceptor是一種在上傳完成後 接受REPOST到一個ASP頁的ISAPI應用程序

Sofare Artisans的SA FileUp是最早的商業Active Server之一 幾經改進 現在作為一個純粹的ASP存在

二 基於ASP的文件上傳實現原理分析

基本原理是 採用ADO Stream對象的BinaryRead方法將FORM中的所有數據讀出 從中截取出所需的文件數據 以二進制文件方式存檔

下面是上傳文件頁面的一個例子（） <><body><form name= Upload Method= Post Enctype= multipart/form data Action= Upload asp ><input type= file name= FileName ><INPUT TYPE= Submit VALUE= Upload ></TD></form></body></>

程序中使用了文件對象 這樣在Upload asp中採用BinaryRead方法讀來的原始數據就不僅僅是選擇的文件本身的數據 還包含該文件在用戶硬碟上的路徑 類型 提交頁面的表單等相關信息的描述 這樣我們就需從中提取出文件的具體內容 根據分析 數據的頭部信息與數據的分界線是兩對回車換行符 尾部也有分隔信息 我們可以採用類似以下的方法獲取文件數據 Dim FormData FormSize DataStart CLStr DivStrFormSize=Request TotalBytesFormData=Request BinaryRead(FormSize)CLStr=ChrB( )&ChrB( )DataStart=InStrB(FormData CLStr&CLStr)+ 是兩對回車換行符的長度DivStr=LeftB(FormData InStrB(FormData CLStr) )DataSize=InStrB(DataStart+ FormData DivStr) DataStart FormData=MidB(FormData DataStart DataSize) FormData就是文件的內容了 中間根據需要 可進行相應的處理 最後的工作就是將文件保存了 保存的方法可以有兩種 一種是利用VB或VC之類程序中的二進制文件操作方法 在工程中加入適當的類型庫 最終編譯成DLL文件 使用時再將該DLL文件注冊就可以了 文件存貯程序如下 Public Function SaveFile(Pathname As String) As String Dim objContext As ObjectContext Dim objRequest As Request Set objContext=GetObjectContext() Set objRequest=objContext( Request ) 以下的一段代碼是進行文件存貯的有關操作Dim FormData() As Byte CLStr DivStr Dim DataStart As Long DataSize As Long DataSize=objRequest TotalBytes Redim FormData(DataSize ) FormData=objRequest BinaryRead(DataSize) CLStr=ChrB( ) & ChrB( ) DataStart=InStrB(FormData CLStr & CLStr)+ DivStr=LeftB(FormData InStrB(FormData CLStr) ) DataSize=InStrB(DataStart+ FormData DivStr) DataStart FormData=MidB(FormData DataStart DataSize) 創建一個二進制文件並將FormData寫入其中 Open Pathname For Binary As Put # FormData Close # SaveFile= OK! End Function 第二種方法是利用ADO STREAM中提供的二進制文件操作方法來完成 保存文件的語句是 StreamOBJ SaveToFile (fileName ) 在 這種操作中 我們可以將有關的操作存放在一個類文件中 在應用時 直接將該類文件包含在ASP程序中就可以了 具體處理方法 請參閱有關介紹 三．文件上傳實現方法實例 實現文件上傳可使用或無方式 對於類 比如說microsoft posting acceptor（簡稱mpa） 就是公司發布的一個免費 這類的安裝也比較方便 對於的mpa 運行它的安裝文件就可以了 而一般的dll形式的 我們則需要進行注冊 例如 要使用aspcnUP dll 只要在Window 上執行regsvr [path]aspcnUP dll 系統出現注冊成功的信息提示就可以使用該了 對於無類 如的無上傳類 upload_ xsoft 在使用時 只要在處理程序中包含以下的語句就可以了 <! #include FILE= upload inc >set upload=new upload_ xSoft 建立上傳對象 有關的屬性與操作方法 請參閱該的使用手冊 下面是詀spcnUP dll為例 上傳部分類型文件的源代碼（upload asp） <% @ language= vbscript Set fileUP=Server CreateObject( aspcn Upload )fileUP Maxsize= fileUP Path= d:upfile fileUP UploadFor i= to fileUP Countfieldname=fileUP FieldName(i)If fileUP FileType(fieldname)= zip Or ileUP FileType(fieldname)= rar ThenfileUP Save fieldnameEnd If NextSet fileUP=Nothing%> 四．結束語 應用模式還在快速地發展著 在ASP．NET中 已經內置了文件上傳的功能 使用非常簡單方便 作為一種全新的技術 ASP．NET並不只是ASP的簡單升級 它是一個用於Web開發的全新框架 其中包含了許多新的特性 ASP．NET提供了更易於編寫 結構更清晰的代碼 利用這些代碼我們將會更容易地進行再利用和共享 從而開發出更多更實用的程序來 lishixin/Article/program/net/201311/13562

Ⅳ http中上傳文件的原理

http中上傳文件的原理如下：
在最初的http協議中，沒有上傳文件方面的功能。 rfc1867 ( http://www.ietf.org/rfc/rfc1867.txt ) 為 http 協議添加了這個功能。客戶端的瀏覽器，如 Microsoft IE, Mozila, Opera 等，按照此規范將用戶指定的文件發送到伺服器。伺服器端的網頁程序，如 php, asp, jsp 等，可以按照此規范，解析出用戶發送來的文件。Microsoft IE, Mozila, Opera 已經支持此協議，在網頁中使用一個特殊的 form 就可以發送文件。絕大部分 http server ，包括 tomcat ，已經支持此協議，可接受發送來的文件。各種網頁程序，如 php, asp, jsp 中，對於上傳文件已經做了很好的封裝。

超文本傳輸協議（HTTP，HyperText Transfer Protocol)是互聯網上應用最為廣泛的一種網路協議。所有的WWW文件都必須遵守這個標准。設計HTTP最初的目的是為了提供一種發布和接收HTML頁面的方法。1960年美國人Ted Nelson構思了一種通過計算機處理文本信息的方法，並稱之為超文本（hypertext）,這成為了HTTP超文本傳輸協議標准架構的發展根基。

Ⅳ 前端上傳文件實時顯示進度條和上傳速度的工作原理是怎樣的

後端的責任。

Ⅵ SpringBoot文件上傳的使用以及原理

這是因為上傳的內容超出了 SpringBoot 默認配置的上傳文件的大小 1MB

通過該註解可以指導，在配置類中修改 spring.servlet.multipart 下的配置項即可

可以看到有一個 max-file-size 的配置項，默認是"1MB"，說明修改該配置項為想要限制的大小即可，這里我改成10MB，而 max-request-size 是多文件上傳時，總的一次提交的最大大小，默認是10MB，我改成100MB

可以看到，在選擇使用哪個解析器去處理請求（也就是根據映射關系，找到請求的 url 對應的用 @RequestMapping 註解過的方法）之前，會先調用 checkMultipart() 檢查一下當前的請求是否是一個文件上傳的請求

前面已經分析了，文件上傳欄位的註解是 @RequestPart ，而相應的解析器是 ，所以我們需要先找到該解析器的執行流程先

總體原理就是根據註解的類型以及註解中的參數，構造出一個映射，這個映射是以註解 @RequestPart 中的 name 為key，而上傳的文件為value，根據這個映射就可以給相應的參數賦值，這樣我們就可以從 MultipartFile 對象中調用相應方法對上傳的文件做想要的操作了

Ⅶ 大文件秒上傳的原理是什麼

不清楚,
我只能大致猜測一下,不要當真,也只是想想而已:
在互聯網上有很多資源,
每個資源有各自的身份ID, 類似於MD5,或者HASH,
上傳的時候,會看你的資源是否在網路上有相同的ID,
有的話,就從網路上獲取,並存放在你的文件夾下,
速度幾乎可以達到秒傳,只是搜索了一個相同的鏈接而已,所以速度很快,
本地的哪個文件,可能壓根就沒傳上去,
那個上傳的資源其實並不正真在你的網盤裡面而是一個類似於網路資源的鏈接,
可以把網路想像成一個巨大的文件伺服器磁碟,
你從你 的電腦上傳文件的時候,它會檢索自己的磁碟是否有重復的文件,有就不會復制你的文件,
直接在自己的磁碟裡面調用,
那沒有的怎麼辦? 其實這個也好解決, 基本上我們的資源是取之於網用之於網,
網路上的資源可以想像成覆蓋了哦我們本地99%的資源, 大部分都能在網上找到匹配的
只是想想而已,不必當真!
呵呵!!

Ⅷ http文件上傳的原理

HTTP 協議定義伺服器端和客戶端之間文件傳輸的溝通方式。目前HTTP協議的版本是Http1.1。RFC 2616描述了HTTP協議的具體信息。

這個協議已經成為瀏覽器和Web站點之間的標准。

當我上網的時候底層是如何進行交互的？

當訪問者點擊一個超鏈接的時候，將會給瀏覽器提交一個URL地址。通過這個URL地址，瀏覽器便知道去鏈接那個網站並去取得具體的頁面文件（也可能是一張圖片，一個pdf文件）。

HTTP工作的基礎就是，連接一個伺服器並開始傳輸文件到瀏覽器。

HTTP傳輸的基本過程

在http傳輸的過程中，被稱為客戶端的請求者向伺服器請求一個文件。

最基本的過程是:
1 客戶端連接一個主機；
2 伺服器接收連接,
3 客戶端請求一個文件,
4 伺服器發送一個應答.