解決我幾天的問題 文件下載

chyx413332087 13年前發布 | 1K 次閱讀 qtmib
   問題:  如果是文件下載下來,打開在第一行,和最后一行多了一些數據,下載圖片 圖片,打不開
   在網上查了很多資料,原來以為是代碼的問題,可是還真不是
   我運行的環境 是IE8  ,原來IE8  模式是http  1.1  ,http 1.1  默認的是  使用的http長連接  ,長連接在文件下載服務端,有需要知道返回的數據包長度,
因此 ,在加上 resopnse.setHead(content-length,length);  length  是文件的長度,  ,就正常了,
 后來,我取消了 http 1.1使用http  1.0  因為http 1.0 是短連接 ,不用加上面的content-length也就對了
       下面是長短,連接的說明:
 
、長連接與短連接:
長連接:client方與server方先建立連接,連接建立后不斷開,然后再進行報文發送和接收。
這種方式下由于通訊連接一直存在。此種方式常用于P2P通信。
短連接:Client方與server每進行一次報文收發交易時才進行通訊連接,交易完畢后立即斷開連接。
此方式常用于一點對多點通訊。C/S通信。

二、長連接與短連接的操作過程:

短連接的操作步驟是:
建立連接——數據傳輸——關閉連接...建立連接——數據傳輸——關閉連接
長連接的操作步驟是:
建立連接——數據傳輸...(保持連接)...數據傳輸——關閉連接

三、長連接與短連接的使用時機:

長連接:短連接多用于操作頻繁,點對點的通訊,而且連接數不能太多的情況。
每個TCP連接的建立都需要三次握手,每個TCP連接的斷開要四次握手。
如果每次操作都要建立連接然后再操作的話處理速度會降低,所以每次操作
下次操作時直接發送數據就可以了,不用再建立TCP連接。例如:數據庫的連接用長連接,
如果用短連接頻繁的通信會造成socket錯誤,頻繁的socket創建也是對資源的浪費。
短連接:web網站的http服務一般都用短連接。因為長連接對于服務器來說要耗費一定的資源。
像web網站這么頻繁的成千上萬甚至上億客戶端的連接用短連接更省一些資源。試想如果都用長連接,
而且同時用成千上萬的用戶,每個用戶都占有一個連接的話,可想而知服務器的壓力有多大。
所以并發量大,但是每個用戶又不需頻繁操作的情況下需要短連接。
總之:長連接和短連接的選擇要視需求而定。

四、發送接收方式:

1、異步報文發送和接收是分開的,相互獨立,互不影響的。這種方式又分兩種情況:
異步雙工:接收和發送在同一個程序中,有兩個不同的子進程分別負責發送和接送。
異步單工:接送和發送使用兩個不同的程序來完成。
2、同步:報文發送和接收是同步進行,即報文發送后等待接送返回報文。同步方式
一般需要考慮超時問題,試想我們發送報文以后也不能無限等待啊,所以我們要設定一個等待
時候。超過等待時間發送方不再等待讀返回報文。直接通知超時返回。

五、報文格式:

通信報文格式多樣性更多,相應地就必須設計對應的讀寫報文的接 
收和發送報文函數。

阻塞與非阻塞方式

1、非阻塞方式:讀函數不停的進行讀動作,如果沒有報文接收到,等待一段時間后超時返回,
這種情況一般需要指定超時時間。
2、阻塞方式:如果沒有接收到報文,則讀函數一直處于等待狀態,知道報文到達。

循環讀寫方式

1、一次直接讀寫報文:在一次接收或發送報文動作中一次性不加分別地全部讀取或全部發送報文字節。
2、不指定長度循環讀寫:這一版發生在短連接進程中,受網絡路由等限制,一次較長的報文可能
在網絡傳輸過程中被分解成很多個包,一次讀取可能不能全部讀完一次報文,這就需要循環讀取報文,
知道讀完為止。
3、帶長度報文頭循環讀寫:這種情況一般在長連接中,由于在長連接中沒有條件能夠判斷循環讀寫什么時候結束。
必須要加長度報文頭。讀函數先是讀取報文頭的長度,再根據這個長度去讀報文,實際情況中,報頭碼制格式還經常不一樣,
如果是非ASCII的報文頭,還必須轉換成ASCII常見的報文頭編制有:
1、n個字節的ASCII碼。
2、n個字節的BCD碼。
3、n個字節的網絡整型碼。

以上是幾種比較典型的讀寫報文方式,可以與通信方式模板一起 預先提供一些典型的API讀寫函數

當然在實際問題中,可能還必須編寫與對方報文格式配套的讀寫API. 在實際情況中,往往需要

把我們自己的系統與別人的系統進行連接, 有了以上模板與API,可以說連接任何方式的通信程序

都不存在問題。

 
  
 本文由用戶 chyx413332087 自行上傳分享,僅供網友學習交流。所有權歸原作者,若您的權利被侵害,請聯系管理員。
 轉載本站原創文章,請注明出處,并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺,歡迎各類分享!