解决我几天的问题 文件下载

13年前
   问题:  如果是文件下载下来,打开在第一行,和最后一行多了一些数据,下载图片 图片,打不开
   在网上查了很多资料,原来以为是代码的问题,可是还真不是
   我运行的环境 是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,可以说连接任何方式的通信程序

都不存在问题。