一般有以下幾種：
-
FTP，全稱：File transmission protocol（文件傳輸協議）
-
HTTP，全稱：Hypertext transimission protocol（超文本傳輸協議）
-
SMTP，全稱：Simple Mail Transfer Protocol（簡單郵件轉換協議）
-
BT，全稱：Bit Torrent（比特流）
-
P2P，全稱：Peer to Peer（對等網絡）
Transmission Control Protocol/Internet Protocol的簡寫，中譯名為傳輸控制協議/因特網互聯協議，又名網絡通訊協議，是Internet最基本的協議、Internet國際互聯網絡的基礎，由網絡層的IP協議和傳輸層的TCP協議組成。TCP/IP 定義了電子設備如何連入因特網，以及數據如何在它們之間傳輸的標准。協議采用了4層的層級結構，每一層都呼叫它的下一層所提供的協議來完成自己的需求。通 俗而言：TCP負責發現傳輸的問題，一有問題就發出信號，要求重新傳輸，直到所有數據安全正確地傳輸到目的地。而IP是給因特網的每一台聯網設備規定一個 地址。
其它常用方式也是基於以上協議：飛秋、飛鴿（局域網，可能P2P）；QQ、MSN、微信（可能FTP）；網盤、雲服務器（可能HTTP）；郵箱盤（可能SMTP）等。
一、FTP
FTP 是File Transfer Protocol（文件傳輸協議）的英文簡稱，而中文簡稱為“文傳協議”。用於Internet上的控制文件的雙向傳輸。同時，它也是一個應用程序（Application）。 基於不同的操作系統有不同的FTP應用程序，而所有這些應用程序都遵守同一種協議以傳輸文件。在FTP的使用當中，用戶經常遇到兩個概念："下載" （Download）和"上傳"（Upload）。"下載"文件就是從遠程主機拷貝文件至自己的計算機上；"上傳"文件就是將文件從自己的計算機中拷貝至 遠程主機上。用Internet語言來說，用戶可通過客戶機程序向（從）遠程主機上傳（下載）文件。
FTP可用多種格式傳輸文件，通常由系統決定。大多數系統（包括UNIX系統）只有兩種模式：文本模式和二進制模式。文本傳輸器使用ASCII字 符，並由回車鍵和換行符分開，而二進制不用轉換或格式化就可傳字符，二進制模式比文本模式更快，並且可以傳輸所有ASCII值，所以系統管理員一般將 FTP設置成二進制模式。
一般來說：如果你用錯誤的模式傳輸你的圖片，你將無法看到圖片，看到的會是亂碼。如果你用錯誤模式上傳CGI腳本，那么就將無法運行你的腳本，會看到類似 Server 500 Error的出錯信息。所以，必須使用正確的模式，圖片和執行文件必須用BINARY模式，CGI腳本和普通HTML文件用ASCII模式上傳。
ASCII和BINARY模式的區別：
用HTML和文本編寫的文件必須用ASCII模式上傳，用BINARY模式上傳會破壞文件，導致文件執行出錯。BINARY模式用來傳送可執行文件，壓縮 文件，和圖片文件。如果你用ASCII模式傳，會顯示一堆亂碼，你必須重新用BINARY模式傳。對於第二種情況，是因為有很多ftp服務器和客戶端軟件 能自動識別文件類型，並采取相應的傳輸方式。
ftp是應用層協議，和具體的操作系統無關。ASCII模式和BINARY模式的區別是回車換行的處理，BINARY模式不對數據進行任何處理，ASCII模式將回車換行轉換為本機的回車字符，比如Unix下是\n，Windows下是\r\n，Mac下是\r。
ASCII模式下會轉換文件，不能說是不同系統對回車換行解釋不同，而是不同系統有不同的行結束符，UNIX系統下行結束符是一個字節，即十六進制的 0A，而MS的系統是兩個字節，即十六進制的0D0A。所以當你用ASCII方式從UNIX的ftp server下載文件時（不管是二進制或者文本文件），每檢測到一個字節是0A，就會自動插入一個0D，所以如果你的文件是二進制文件比如可執行文件、壓 縮包什么的，就肯定不能用了。如果你的文件就是UNIX下的文本文件，你用ASCII模式是正確的，要是誤用了BINARY模式，你在Windows上看 這個文件是沒有換行的，里面是一個個的黑方塊。
一般來說，我們最好都用BINARY方式，這樣可以保證不出錯。如果有文本格式轉換的問題，即UNIX格式的文本和DOS格式的文本之間的轉換，有很多工具可以做，不要在ftp傳輸的時候冒險，尤其是你如果對這些東西不是非常清楚的話。
可以使用MIME，把所有的字符，轉換成0~128之間的字符，然后傳送，在接收方再將接收到的字符MIME反向轉換。通常我們發送郵件，就是使用這樣的字符轉換方式。
補充：文本模式和二進制模式傳文本文件的具體區別可以通過在Linux下 使用cat -A 文件名 看到兩者的區別，當然前提是在windows下上傳的文本為DOS格式，這個可以用高級的文本編譯器看，如ultraedit等。兩者的區別是，二進制模 式上傳的文本比文本模式多一個^M符號，這個就是windows下DOS格式的/r回車符號，也就是上面提到的十六進制OD，在vi下使用全局替換：%s /^M//g [^M使用Ctrl+V+M而不是直接輸入^M]，去掉所有的回車符或者使用dos2unix file進行轉換，這樣保存后或者生成后的文件就和文本模式上傳的文件一樣了。
二、HTTP
http和其他幾種網絡協議
HTTP協議的網頁
HTTP 文件上傳的基本原理：
使用html 的<input type=”file” name=”xxx”> 標簽，提交form 的幾個屬性必須為： method=post encType=multipart/form-data;
method 屬性必須設為post的原因是：值不是放在URL之后傳遞到服務器的；
encType屬性：這個屬性管理的是表單的MIME編碼
幾個屬性詳解：
application/x-www-form-urlencoded 在發送前編碼所有字符（默認）
multipart/form-data 不對字符編碼，在使用包含文件上傳控件的表單時，必須使用該值；對於“multipart/form-data”類型的form表單，瀏覽器上傳的實體內 容中的每個表單字段元素的數據之間用字段分隔界線進行分割，兩個分隔界線間的內容稱為一個分區，每個分區中的內容可以被看作兩部分，一部分是對表單字段元 素進行描述的描述頭，另外一部是表單字段元素的主體內容
text/plain 空格轉換為“+”，不對特殊字符編碼
服務器端：
WEB服務器端程序接收到“multipart/form-data”類型的HTTP請求消息后，其核心和基本的編程工作就是讀取請求消息中的實體內容，然后解析出每個分區的數據，接着再從每個分區中解析出描述頭和主體內容部分。
要在jsp里獲得上傳的文件，就是通過request.getInputStream()來得到上傳的整個post實體的流，用 request.getHeader("Content-Type")來取得實體內容的分界字符串，然后根據http協議，分析取得的上傳的實體流，把文 件部分給篩出來，然后在服務器端保存到磁盤文件中，另外因為上傳文件時，form的屬性enctype="multipart/form-data"，所 以其他表單參數在上傳文件時也無法得到，除了篩出文件進行保存，還應該把其他的參數一起取出保存，以便在jsp程序中調用。
具體方法如下：
1、 根據request獲得文件輸入流；
2、 依次讀取行，此時進行兩部分內容的處理，
a:獲取文件名
以 filename=”xxxxx”來標識一個文件頭，
b:獲取其他表單值（因為其流是按照multipart/form-data方式來編碼的，所以在服務器端，不能直接用request.getParameter()來獲得）;
以name=”xxxx”來標識一個表單頭
都以流頭的字符標識為值的結束；
實體內容內部的字段分隔界線是在content-type頭中指定的字段分隔界線前面增加了兩個減號（-）字符而形成的（由瀏覽器隨機生成，由瀏覽器 保證不會與用戶上傳的文件內容重復）
當找到一個分區的開始位置后，程序還需要分辨出分區中的描述頭和主體內容，並對這兩部分內容分開存儲。如何分辨出一個分區的描述頭和主體部分呢？每 個分區中的描述頭和主體內容之間有一空行，再加上描述頭后面的換行，這就說明描述頭和主體部分之間是使用“\n”、“\r”、“\n”、“\r”這四個連 續的字節內容進行分隔。因此，程序需要把“\n”、“\r”、“\n”、“\r”這四個連續的字節內容作為描述頭和主體部分之間的分隔界線，並在字節數組 緩沖區buffer中尋找這個特殊的分隔界線來識別描述頭和主體部分。
3、 根據讀到的文件信息（文件名，文件大小等），判斷是否合法（文件類型、文件大小判斷）。如果合適則返回，如果不合適則創建同名文件並將其刪除；
Web Service基本概念
Web Service也叫XML Web Service WebService是一種可以接收從Internet或者Intranet上的其它系統中傳遞過來的請求，輕量級的獨立的通訊技術。是:通過SOAP在 Web上提供的軟件服務，使用WSDL文件進行說明，並通過UDDI進行注冊。
XML：(Extensible Markup Language)擴展型可標記語言。面向短期的臨時數據處理、面向萬維網絡，是Soap的基礎。
Soap：(Simple Object Access Protocol)簡單對象存取協議。是XML Web Service 的通信協議。當用戶通過UDDI找到你的WSDL描述文檔后，他通過可以SOAP調用你建立的Web服務中的一個或多個操作。SOAP是XML文檔形式的 調用方法的規范，它可以支持不同的底層接口，像HTTP(S)或者SMTP。
WSDL：(Web Services Description Language) WSDL 文件是一個 XML 文檔，用於說明一組 SOAP 消息以及如何交換這些消息。大多數情況下由軟件自動生成和使用。
UDDI (Universal Description, Discovery, and Integration) 是一個主要針對Web服務供應商和使用者的新項目。在用戶能夠調用Web服務之前，必須確定這個服務內包含哪些商務方法，找到被調用的接口定義，還要在服 務端來編制軟件，UDDI是一種根據描述文檔來引導系統查找相應服務的機制。UDDI利用SOAP消息機制（標准的XML/HTTP）來發布，編輯，瀏覽 以及查找注冊信息。它采用XML格式來封裝各種不同類型的數據，並且發送到注冊中心或者由注冊中心來返回需要的數據。
調用原理：
Web服務有兩層含義：1、是指封裝成單個實體並發布到網絡上的功能集合體；2、是指功能集合體被調用后所提供的服務。簡單地講，Web服務是一個URL資源，客戶端可以通過編程方式請求得到它的服務，而不需要知道所請求的服務是怎樣實現的，這一點與傳統的分布式組件對象模型不同。
Web服務的體系結構是基於Web服務提供者、Web服務請求者、Web服務中介者三個角色和發布、發現、綁定三個動作構建的。簡單地說，Web服務提供者就是Web服務的擁有者，它耐心等待為其他服務和用戶提供自己已有的功能；Web服務請求者就是Web服務功能的使用者，它利用SOAP消息向Web服務提供者發送請求以獲得服務;Web服務中介者的作用是把一個Web服務請求者與合適的Web服務提供者聯系在一起，它充當管理者的角色，一般是UDDI。這三個角色是根據邏輯關系划分的，在實際應用中，角色之間很可能有交叉：一個Web服務既可以是Web服務提供者，也可以是Web服務請求者，或者二者兼而有之。顯示了Web服務角色之間的關系:其中，“發布”是為了讓用戶或其他服務知道某個Web服務的存在和相關信息;“查找（發現）”是為了找到合適的Web服務;“綁定”則是在提供者與請求者之間建立某種聯系。
圖2-1 Web service的體系結構
實現一個完整的Web服務包括以下步驟：
◆ Web服務提供者設計實現Web服務，並將調試正確后的Web服務通過Web服務中介者發布，並在UDDI注冊中心注冊； （發布）
◆ Web服務請求者向Web服務中介者請求特定的服務，中介者根據請求查詢UDDI注冊中心，為請求者尋找滿足請求的服務； （發現）
◆ Web服務中介者向Web服務請求者返回滿足條件的Web服務描述信息，該描述信息用WSDL寫成，各種支持Web服務的機器都能閱讀；（發現）
◆ 利用從Web服務中介者返回的描述信息生成相應的SOAP消息，發送給Web服務提供者，以實現Web服務的調用；（綁定）
◆ Web服務提供者按SOAP消息執行相應的Web服務，並將服務結果返回給Web服務請求者。（綁定）
調用方式：
1. Net下采用GET/POST/SOAP方式動態調用WebService的簡易靈活方法(C#)
webservice 的調用有3種方式
1). httpget
2). httppost
3). httpsoap
soap 的優點是 可以傳遞結構化的 數據，而前兩種不行。
btw, soap 最終也是使用 HTTP 傳送 XML
安全：
Webservice為作為方便的服務被用廣大領域使用的同時，也成為了黑客們的美食。在這里，本文將就目前對Webservice安全所能做的改進做簡單介紹。
在Webservice中的安全主要分為以下三個方面。
傳輸 SSL/HTTPS 對連接加密，而不是傳輸數據
消息 數據加密(XML Encryption) 數字簽名(XML-DSIG)
底層架構 利用應用服務安全機制
傳輸時的安全是最容易被加入到你的Webservice應用中的，利用現有的SSL 和HTTPS協議，就可以很容易的獲得連接過程中的安全。
然 而這種安全實現方法有兩個弱點。一是它只能保證數據傳輸的安全，而不是數據本身的安全，數據一旦到達某地，那么就可以被任何人所查看。而在 Webservice中，一份數據可能到達多個地方，而這份數據卻不該被所有的接受者所查看。二是它提供的是要么全有要么全無的保護，你不能選擇哪部分數 據要被保護，而這種可選擇性也是在Webservice中所常要用到的。
第二層的保護是對於消息本身的保護。你可以使用已有的XML安 全擴展標准，實現數字簽名的功能，從而保證你的消息是來自特定方並沒有被修改過。XML文件的加密技術從更大程度上加強了Webservice的安全，它 能夠定制數據傳輸到后，能否被接受者所查看，進一步完善了傳輸后的安全，業界也在不斷的制定Webservice的安全標准，比如SAML 和 WS-Security。
最后一層保護就是依靠底層架構的安全，這更多的來自於操作系統和某些中間件的保護。比如在J2EE中，主持 Webservice的應用服務器。目前很多的J2EE應用服務器都支持Java Authentication and Authorization Service (JAAS)，這是最近被加入到J2SE 1.4當中的。利用主持Webservice的服務器，實現一些安全機制這是很自然的做法。另一種利用底層架構的安全方法就是，做一個獨立的負責安全的服 務器，Webservice的使用者和創建者都需要與之取得安全信任。
特點：
Web Service的主要目標是跨平台的可互操作性。為了實現這一目標，Web Service 完全基於XML（可擴展標記語言）、XSD（XML Schema）等獨立於平台、獨立於軟件供應商的標准，是創建可互操作的、分布式應用程序的新平台。因此使用Web Service有許多優點:
1、跨防火牆的通信
如果應用程序有成千上萬的用戶，而且分布在世界各地，那么客戶端和服務器之間的通信將是一個棘手的問題。因為客戶端和服務器之間通常會有防火牆或者 代理服務器。傳統的做法是，選擇用瀏覽器作為客戶端，寫下一大堆ASP頁面，把應用程序的中間層暴露給最終用戶。這樣做的結果是開發難度大，程序很難維 護。 要是客戶端代碼不再如此依賴於HTML表單，客戶端的編程就簡單多了。如果中間層組件換成Web Service的話，就可以從用戶界面直接調用中間層組件，從而省掉建立ASP頁面的那一步。要調用Web Service，可以直接使用Microsoft SOAP Toolkit或.net這樣的SOAP客戶端，也可以使用自己開發的SOAP客戶端，然后把它和應用程序連接起來。不僅縮短了開發周期，還減少了代碼復 雜度，並能夠增強應用程序的可維護性。同時，應用程序也不再需要在每次調用中間層組件時，都跳轉到相應的"結果頁"。
2、應用程序集成
企業級的應用程序開發者都知道，企業里經常都要把用不同語言寫成的、在不同平台上運行的各種程序集成起來，而這種集成將花費很大的開發力量。應用程 序經常需要從運行的一台主機上的程序中獲取數據；或者把數據發送到主機或其它平台應用程序中去。即使在同一個平台上，不同軟件廠商生產的各種軟件也常常需 要集成起來。通過Web Service，應用程序可以用標准的方法把功能和數據"暴露"出來，供其它應用程序使用。
XML Web services 提供了在松耦合環境中使用標准協議（HTTP、XML、SOAP 和 WSDL）交換消息的能力。消息可以是結構化的、帶類型的，也可以是松散定義的。
3、B2B的集成
B2B 指的是Business to Business，as in businesses doing business with other businesses,商家(泛指企業)對商家的電子商務，即企業與企業之間通過互聯網進行產品、服務及信息的交換。通俗的說法是指進行電子商務交易的供 需雙方都是商家(或企業、公司)，她們使用了Internet的技術或各種商務網絡平台，完成商務交易的過程。
Web Service是B2B集成成功的關鍵。通過Web Service，公司可以只需把關鍵的商務應用"暴露"給指定的供應商和客戶，就可以了，Web Service運行在Internet上，在世界任何地方都可輕易實現，其運行成本就相對較低。Web Service只是B2B集成的一個關鍵部分，還需要許多其它的部分才能實現集成。 用Web Service來實現B2B集成的最大好處在於可以輕易實現互操作性。只要把商務邏輯"暴露"出來，成為Web Service，就可以讓任何指定的合作伙伴調用這些商務邏輯，而不管他們的系統在什么平台上運行，使用什么開發語言。這樣就大大減少了花在B2B集成上 的時間和成本。
4、軟件和數據重用
Web Service在允許重用代碼的同時，可以重用代碼背后的數據。使用Web Service，再也不必像以前那樣，要先從第三方購買、安裝軟件組件，再從應用程序中調用這些組件；只需要直接調用遠端的Web Service就可以了。另一種軟件重用的情況是，把好幾個應用程序的功能集成起來，通過Web Service "暴露"出來，就可以非常容易地把所有這些功能都集成到你的門戶站點中，為用戶提供一個統一的、友好的界面。 可以在應用程序中使用第三方的Web Service 提供的功能，也可以把自己的應用程序功能通過Web Service 提供給別人。兩種情況下，都可以重用代碼和代碼背后的數據。
從以上論述可以看出，Web Service 在通過Web進行互操作或遠程調用的時候是最有用的。不過，也有一些情況，Web Service根本不能帶來任何好處，Web Service有一下缺點：
1、 單機應用程序
目前，企業和個人還使用着很多桌面應用程序。其中一些只需要與本機上的其它程序通信。在這種情況下，最好就不要用Web Service，只要用本地的API就可以了。COM非常適合於在這種情況下工作，因為它既小又快。運行在同一台服務器上的服務器軟件也是這樣。當然 Web Service 也能用在這些場合，但那樣不僅消耗太大，而且不會帶來任何好處。
2、 局域網的一些應用程序
在許多應用中，所有的程序都是在Windows平台下使用COM，都運行在同一個局域網上。在這些程序里，使用DCOM會比SOAP/HTTP有效 得多。與此相類似，如果一個.net程序要連接到局域網上的另一個.net程序，應該使用.net Remoting。其實在.net Remoting中，也可以指定使用SOAP/HTTP來進行Web Service 調用。不過最好還是直接通過TCP進行RPC調用，那樣會有效得多。
1.3、XML Web Service的應用
1.最初的 XML Web Service 通常是可以方便地並入應用程序的信息來源，如股票價格、天氣預報、體育成績等等。
2.以 XML Web Service 方式提供現有應用程序，可以構建新的、更強大的應用程序，並利用 XML Web Service 作為構造塊。
例如，用戶可以開發一個采購應用程序，以自動獲取來自不同供應商的價格信息，從而使用戶可以選擇供應商，提交訂單，然后跟蹤貨物的運輸，直至收到貨 物。而供應商的應用程序除了在Web上提供服務外，還可以使用XML Web Service檢查客戶的信用、收取貨款，並與貨運公司辦理貨運手續。