引入长连接的原因
在Http1.1之前，无论浏览器什么时候连接到Web服务器，当服务器将请求的资源返回后，就会断开与浏览器的连接。但是网页上会包含一些其他资源，如图片等。因此，当请求一个页面时，浏览器还需要下载这些被页面引用的资源。如果页面和它引用的所有资源文件都使用不同的连接进行下载的话，处理过程会很慢。这就是为什么HTTP1.1中会引出持久连接。使用持久连接后，当下载了页面后，服务器并不会立即关闭连接，相反，它会等待WEB客户端请求呗改页面所应用的所有资源。这样一来，页面和被页面引用的资源都会使用同一个连接来下载，考虑到建立/关闭HJTTP连接是一个系统开销很大的操作，使用同一个连接来下载所有的资源会为WEB服务器、客户端和网络节省很多时间和工作量。
在HTTP1.1中，会默认使用持久连接，当然，也可以显示的使用，方法是浏览器发送如下的请求信息：
connection：keep-alive
交互过程
建立了持久连接之后，服务器可以从多个资源发送字节流，而客户端也可以使用该连接发送多个请求，这样的结果就是发送方必需在每个请求响应中添加“content-length”投信息，这样，接收方才能知道如何读取、解释这些信息，但通常情况下，发送方并不知道要发送多少字节。servlet可能在接收到一些字节后，就开始发送响应信息，而不必等到接完所有的信息，这就是说，必需有一种方法来告诉接收方在不知道发送内容长度的情况下，如何解析已经接收到的内容。
其实，即使在没有发出多个请求或发送多个响应，服务器或客户端也不需要知道有多少字节要发送，在HTTP1.0中，服务器可以不写"content-length"头信息，只管往连接中写响应内容就行，当发送完信息后，就直接关闭连接，在这种情况下，客户端一只读取内容，直到读到-1，表明已经读到了末尾。
image.png
状态码100
那么问题来了，客户端是如何让服务器端知道是分块发送数据的呢？答案是在请求头上加一个配置：
Expect:100-continue
当客户端准备发送一个较长的请求体，而不确定服务器是否会界首市，就可能发送上面的头信息，若是客户端发送了较长的请求体，却发现服务器拒绝界首市，会是交大的浪费。
接收到“Expect:100-continue"请求头后，若古武器可以接受并处理该请求时，可以发送如下响应头：
HTTP/1.1 100 Continue
网友评论