在HTTP通讯过程中，是客户端还是服务端主动断开连接？

在HTTP通讯过程中，是客户端还是服务端主动断开连接？

http://bbs.csdn.net/topics/100175214/

比如说：IE访问IIS，获取文件，肯定是要建立一个连接，这个连接在完成通讯后，是客户端Close了连接，还是服务端Close了连接。

我用程序测模拟IE和IIS，都没有收到断开连接的消息，也就是都没有触发OnClose事件。我是用Socket建立的连接。

如果两方面都没有主动断开连接，那么我猜测可能是传输的数据中有结束的标志，请问这个标志是怎样的？

 

考虑两种方式:持久连接和非持久连接
这两种连接方式首先取决于http服务器是否支持
标准HTTP服务器支持这两种方式,特殊HTTP服务器只支持非持久连接

持久连接和非持久连接都是服务器端/IE端均可控制的
控制方式是用Connection : xxxxx字段
Connection: Close告诉对方这次传输结束以后关闭socket
Connection: Alive告诉对方这次传输结束以后可以再次利用这个socket

以下模拟持久连接:
IE Request 包含Connection:Alive -> HTTP服务器返回网页,HTTP头部包含 Connection: Alive -> IE在HTTP头部描述的字节数接收完毕以后提交下一个请求,其中继续包含 Connection: Alive -> HTTP服务器继续返回网页

以下模拟非持久连接:
IE Request 包含Connection:Alive -> HTTP服务器返回网页,HTTP头部包含 Connection: Close,表示自己无视IE的Alive请求 -> IE在HTTP头部描述的字节数接收完毕以后关闭socket

需要说明的是,对于持久连接,Server返回的HTTP头部必须包含一个内容大小字段用来确定IE需要接收的data字节,否则持久连接就会发生问题,因为IE无法获知自己什么时候应该发送下一个请求.所以无法确定data字段大小的时候,服务器必须在适当的时候(通常是data发送结束)主动关闭socket

 

HTTP是请求-响应模式的，而有时候会以关闭连接来表示数据发送完毕，所以在其协议定义中有个字段来表示谁关闭连接。

HTTP1.0/1.1都支持持久连接

在1.1中，如果客户端在请求中使用Connection: Close ，服务器端就会在发送完响应后从容关闭连接。但是即使客户端要求使用持久连接，但是服务器也有权在响应完请求后主动关闭连接，但是要在响应头在包含Connection: Close 。

1.0和1.1一样，但是HTTP1.1默认是持久连接的，而且HTTP1.0不是。

 

你可以在用程序测试的时候，用netstat查看一下当前的TCP连接，如果出现close_wait状态，则说明套接字是“被动关闭的”。如果出现“time_wait"状态，说明套接字是“主动关闭的”。

TCP结束的过程如下:

Server                             Client

-------------- FIN -------------->  server: fin_wait_1

<------------- ACK --------------- client: close_wait  server:fin_wait_2

<------------- FIN  --------------- client发出fin之后就关闭 

-------------- ACK ------------->  server发出ack后进入time_wait状态

正常情况下，应该是IIS主动关闭连接的。如果客户端（IE）主动关闭了连接，那么就会在客户端出现time_wait状态。
Time_Wait的默认时间是2倍的MLS，就是240秒钟。MLS是TCP 片在网上的最长存活时间。
TIME_Wait的主要作用是保证关闭的TCP端口不立即被使用。因为当网络存在延迟时，可能当某个端口被关闭后，网络中还有一些重传的TCP片在发向这个端口，如果这个端口立即建立新的TCP连接，则可能会有影响。所以使用2倍的MSL时间来限制这个端口立即被使用。
现在的问题在于，4分钟的时间有点长。大量的Time_wait会带来一些不好的影响，首先每个TCP连接都各自有个数据结构，叫TCP Control Block.Time_wait的时候这个数据结构没有被释放。所以当有太多的TCP连接时，内存可能会被占用很多。
你可以权衡一下，然后决定是由客户端还是服务端主动断开连接。