HTTP/1.0和HTTP/1.1 http2.0的区别，HTTP怎么处理长链接（阿里）

 

HTTP1.0 HTTP 1.1主要区别

长链接

HTTP 1.0须要使用keep-alive参数来告知服务器端要创建一个长链接，而HTTP1.1默认支持长链接。

HTTP是基于TCP/IP协议的，建立一个TCP链接是须要通过三次握手的,有必定的开销，若是每次通信都要从新创建链接的话，对性能有影响。所以最好能维持一个长链接，能够用个长链接来发多个请求。

节约带宽

HTTP 1.1支持只发送header信息(不带任何body信息)，若是服务器认为客户端有权限请求服务器，则返回100，不然返回401。客户端若是接受到100，才开始把请求body发送到服务器。

这样当服务器返回401的时候，客户端就能够不用发送请求body了，节约了带宽。

另外HTTP还支持传送内容的一部分。这样当客户端已经有一部分的资源后，只须要跟服务器请求另外的部分资源便可。这是支持文件断点续传的基础。

HOST域

如今能够web server例如tomat，设置虚拟站点是很是常见的，也便是说，web server上的多个虚拟站点能够共享同一个ip和端口。

HTTP1.0是没有host域的，HTTP1.1才支持这个参数。

HTTP1.1 HTTP 2.0主要区别

多路复用

HTTP2.0使用了(相似epoll)多路复用的技术，作到同一个链接并发处理多个请求，并且并发请求的数量比HTTP1.1大了好几个数量级。

固然HTTP1.1也能够多创建几个TCP链接，来支持处理更多并发的请求，可是建立TCP链接自己也是有开销的。

TCP链接有一个预热和保护的过程，先检查数据是否传送成功，一旦成功过，则慢慢加大传输速度。所以对应瞬时并发的链接，服务器的响应就会变慢。因此最好能使用一个创建好的链接，而且这个链接能够支持瞬时并发的请求。

数据压缩

HTTP1.1不支持header数据的压缩，HTTP2.0使用HPACK算法对header的数据进行压缩，这样数据体积小了，在网络上传输就会更快。

服务器推送

意思是说，当咱们对支持HTTP2.0的web server请求数据的时候，服务器会顺便把一些客户端须要的资源一块儿推送到客户端，省得客户端再次建立链接发送请求到服务器端获取。这种方式很是合适加载静态资源。

服务器端推送的这些资源其实存在客户端的某处地方，客户端直接从本地加载这些资源就能够了，不用走网络，速度天然是快不少的。

 

 

1.HTTP简介

　　web浏览器和服务器之类的交互过程必须遵照的协议.他是tcp/ip中的一个应用协议。用来协议数据交换过程和数据自己的格式.主要的有HTTP/1.0和HTTP1.1. 

　　HTTP/1.0和HTTP/1.1都把TCP做为底层的传输协议。

　　HTTP客户首先发起创建与服务器TCP链接。一旦创建链接，浏览器进程和服务器进程就能够经过各自的套接字来访问TCP。如前所述，客户端套接字是客户进程和TCP链接之间的“门”，服务器端套接字是服务器进程和同一TCP链接之间的 “门”。客户往本身的套接字发送HTTP请求消息，也从本身的套接字接收HTTP响应消息。相似地，服务器从本身的套接字接收HTTP请求消息，也往本身 的套接字发送HTTP响应消息。客户或服务器一旦把某个消息送入各自的套接字，这个消息就彻底落入TCP的控制之中。

　　TCP给HTTP提供一个可靠的数据传输服务;这意味着由客户发出的每一个HTTP请求消息最终将无损地到达服务器，由服务器发出的每一个HTTP响应消息最终也将无损地到达客户。咱们可从中看到分层网络体系结构的一个明显优点——HTTP没必要担忧数据会丢失，也无需关心TCP如何从数据的丢失和错序中恢复出来的细节。这些是TCP和协议栈中更低协议层的任务。

　　TCP还使用一个拥塞控制机制。该机制迫使每一个新的TCP链接一开始以相对缓慢的速率传输数据，然而只要网络不拥塞，每一个链接能够迅速上升到相对较高的速率。这个慢速传输的初始阶段称为缓启动(slow start)。

　　须要注意的是，在向客户发送所请求文件的同时，服务器并无存储关于该客户的任何状态信息。即使某个客户在几秒钟内再次请求同一个对象，服务器也不会响应说:本身刚刚给它发送了这个对象。相反，服务器从新发送这个对象，由于它已经完全忘记早先作过什么。既然HTTP服务器不维护客户的状态信息，咱们因而 说HTTP是一个无状态的协议(stateless protocol)。

 2.一个完整的HTTP请求过程

　　HTTP事务=请求命令+响应结果

　　

　　一次完整的请求过程：

　　（1）域名解析

　　（2）创建TCP链接，三次握手

　　（3）Web浏览器向Web服务端发送HTTP请求报文

　　（4）服务器响应HTTP请求

　　（5）浏览器解析HTML代码，并请求HTML代码中的资源（JS，CSS，图片）（这是自动向服务器请求下载的）

　　（6）浏览器对页面进行渲染呈现给客户

　　（7）断开TCP链接

如何解析对应的IP地址？域名解析过程（注意了先走本地再走DNS）

 3.HTTP/1.0和HTTP/1.1的区别

　　HTTP 协议老的标准是HTTP/1.0，目前最通用的标准是HTTP/1.1。　　

　　在同一个tcp的链接中能够传送多个HTTP请求和响应.
　　多个请求和响应能够重叠，多个请求和响应能够同时进行.
　　更加多的请求头和响应头(好比HTTP1.0没有host的字段).

　　它们最大的区别：
　　在 HTTP/1.0 中,大多实现为每一个请求/响应交换使用新的链接。HTTP 1.0规定浏览器与服务器只保持短暂的链接，浏览器的每次请求都须要与服务器创建一个TCP链接，服务器完成请求处理后当即断开TCP链接，服务器不跟踪每一个客户也不记录过去的请求。

　　在 HTTP/1.1 中,一个链接可用于一次或屡次请求/响应交换,尽管链接可能因为各类缘由被关闭。HTTP 1.1支持持久链接，在一个TCP链接上能够传送多个HTTP请求和响应，减小了创建和关闭链接的消耗和延迟。一个包含有许多图像的网页文件的多个请求和应答能够在一个链接中传输，但每一个单独的网页文件的请求和应答仍然须要使用各自的链接。HTTP 1.1还容许客户端不用等待上一次请求结果返回，就能够发出下一次请求，但服务器端必须按照接收到客户端请求的前后顺序依次回送响应结果，以保证客户端可以区分出每次请求的响应内容，这样也显著地减小了整个下载过程所须要的时间。

　　举例说明：

　　一个包含有许多图像的网页文件中并无包含真正的图像数据内容，而只是指明了这些图像的URL地址，当WEB浏览器访问这个网页文件时，浏览器首先要发出针对该网页文件的请求，当浏览器解析WEB服务器返回的该网页文档中的HTML内容时，发现其中的<img>图像标签后，浏览器将根据<img>标签中的src属性所指定的URL地址再次向服务器发出下载图像数据的请求。

　　

　　显然，访问一个包含有许多图像的网页文件的整个过程包含了屡次请求和响应，每次请求和响应都须要创建一个单独的链接，每次链接只是传输一个文档和图像，上一次和下一次请求彻底分离。即便图像文件都很小，可是客户端和服务器端每次创建和关闭链接倒是一个相对比较费时的过程，而且会严重影响客户机和服务器的性能。当一个网页文件中包含Applet，JavaScript文件，CSS文件等内容时，也会出现相似上述的状况。

　　为了克服HTTP 1.0的这个缺陷，HTTP 1.1支持持久链接，在一个TCP链接上能够传送多个HTTP请求和响应，减小了创建和关闭链接的消耗和延迟。一个包含有许多图像的网页文件的多个请求和应答能够在一个链接中传输，但每一个单独的网页文件的请求和应答仍然须要使用各自的链接。

　　HTTP 1.1还容许客户端不用等待上一次请求结果返回，就能够发出下一次请求，但服务器端必须按照接收到客户端请求的前后顺序依次回送响应结果，以保证客户端可以区分出每次请求的响应内容，这样也显著地减小了整个下载过程所须要的时间。

　　基于HTTP 1.1协议的客户机与服务器的信息交换过程，以下图所示

　　

　　可见，HTTP 1.1在继承了HTTP 1.0优势的基础上，也克服了HTTP 1.0的性能问题。

还有哪些小的区别呢？

　　HTTP 1.1还经过增长更多的请求头和响应头来改进和扩充HTTP 1.0的功能。

　　例如，因为HTTP 1.0不支持Host请求头字段，WEB浏览器没法使用主机头名来明确表示要访问服务器上的哪一个WEB站点，这样就没法使用WEB服务器在同一个IP地址和端口号上配置多个虚拟WEB站点。

　　在HTTP 1.1中增长Host请求头字段后，WEB浏览器可使用主机头名来明确表示要访问服务器上的哪一个WEB站点，这才实现了在一台WEB服务器上能够在同一个IP地址和端口号上使用不一样的主机名来建立多个虚拟WEB站点。

　　HTTP 1.1的持续链接，也须要增长新的请求头来帮助实现。

　　例如，Connection请求头的值为Keep-Alive时，客户端通知服务器返回本次请求结果后保持链接；Connection请求头的值为close时，客户端通知服务器返回本次请求结果后关闭链接。

　　HTTP 1.1还提供了与身份认证、状态管理和Cache缓存等机制相关的请求头和响应头。

4.Http怎么处理长链接

　　　基于http协议的长链接

         在HTTP1.0和HTTP1.1协议中都有对长链接的支持。其中HTTP1.0须要在request中增长”Connection： keep-alive“ header才可以支持，而HTTP1.1默认支持.

      http1.0请求与服务端的交互过程:

      （1）客户端发出带有包含一个header：”Connection： keep-alive“的请求

      （2）服务端接收到这个请求后,根据http1.0和”Connection： keep-alive“判断出这是一个长链接,就会在response的header中也增长”Connection： keep-alive“，同时不会关闭已创建的tcp链接.

      （3）客户端收到服务端的response后,发现其中包含”Connection： keep-alive“，就认为是一个长链接，不关闭这个链接。并用该链接再发送request.转到（1）

    http1.1请求与服务端的交互过程:

    （1）客户端发出http1.1的请求

    （2）服务端收到http1.1后就认为这是一个长链接,会在返回的response设置Connection： keep-alive,同时不会关闭已创建的链接.

    （3）客户端收到服务端的response后,发现其中包含”Connection： keep-alive“，就认为是一个长链接，不关闭这个链接。并用该链接再发送request.转到（1）

     基于http协议的长链接减小了请求,减小了创建链接的时间,可是每次交互都是由客户端发起的,客户端发送消息,服务端才能返回客户端消息。由于客户端也不知道服务端何时会把结果准备好，因此客户端的不少请求是多余的,仅是维持一个心跳,浪费了带宽。

栗子：下列哪些http方法对于服务端和用户端必定是安全的？（C）　　

　　　　A.GET

　　　　B.HEAD

　　　　C.TRACE

　　　　D.OPTIONS

　　　　E.POST

TRACE: 这个方法用于返回到达最后服务器的请求的报文，这个方法对服务器和客户端都没有什么危险。

 

HTTP是无状态的 
也就是说，浏览器和服务器每进行一次HTTP操做，就创建一次链接，但任务结束就中断链接。若是客户端浏览器访问的某个HTML或其余类型的Web页中包含有其余的Web资源，如JavaScript文件、图像文件、CSS文件等；当浏览器每遇到这样一个Web资源，就会创建一个HTTP会话

HTTP1.1和HTTP1.0相比较而言，最大的区别就是增长了持久链接支持(貌似最新的 http1.0 能够显示的指定 keep-alive),但仍是无状态的，或者说是不能够信任的。

若是浏览器或者服务器在其头信息加入了这行代码

Connection:keep-alive

TCP链接在发送后将仍然保持打开状态，因而，浏览器能够继续经过相同的链接发送请求。保持链接节省了为每一个请求创建新链接所需的时间，还节约了带宽。

实现长链接要客户端和服务端都支持长链接。

若是web服务器端看到这里的值为“Keep-Alive”，或者看到请求使用的是HTTP 1.1（HTTP 1.1默认进行持久链接），它就能够利用持久链接的优势，当页面包含多个元素时（例如Applet，图片），显著地减小下载所须要的时间。要实现这一点， web服务器须要在返回给客户端HTTP头信息中发送一个Content-Length（返回信息正文的长度）头，最简单的实现方法是：先把内容写入ByteArrayOutputStream，然 后在正式写出内容以前计算它的大小

不管客户端浏览器 (Internet Explorer) 仍是 Web 服务器具备较低的 KeepAlive 值，它都将是限制因素。例如，若是客户端的超时值是两分钟，而 Web 服务器的超时值是一分钟，则最大超时值是一分钟。客户端或服务器均可以是限制因素

在header中加入 --Connection:keep-alive 
在HTTp协议请求和响应中加入这条就能维持长链接。 
再封装HTTP消息数据体的消息应用就显的很是简单易用

Http Keep-Alive seems to be massively misunderstood. Here's a short description of how it works, under both 1.0 and 1.1

HTTP/1.0

Under HTTP 1.0, there is no official specification for how keepalive operates. It was, in essence, tacked on to an existing protocol. If the browser supports keep-alive, it adds an additional header to the request:

Connection: Keep-Alive

Then, when the server receives this request and generates a response, it also adds a header to the response:

Connection: Keep-Alive

Following this, the connection is NOT dropped, but is instead kept open. When the client sends another request, it uses the same connection. This will continue until either the client or the server decides that the conversation is over, and one of them drops the connection.

HTTP/1.1

Under HTTP 1.1, the official keepalive method is different. All connections are kept alive, unless stated otherwise with the following header:

Connection: close

The Connection: Keep-Alive header no longer has any meaning because of this.

Additionally, an optional Keep-Alive: header is described, but is so underspecified as to be meaningless. Avoid it.

Not reliable

HTTP is a stateless protocol - this means that every request is independent of every other. Keep alive doesn’t change that. Additionally, there is no guarantee that the client or the server will keep the connection open. Even in 1.1, all that is promised is that you will probably get a notice that theconnection is being closed. So keepalive is something you should not write your application to rely upon.

KeepAlive and POST

The HTTP 1.1 spec states that following the body of a POST, there are to be no additional characters. It also states that "certain" browsers may not follow this spec, putting a CRLF after the body of the POST. Mmm-hmm. As near as I can tell, most browsers follow a POSTed body with a CRLF. There are two ways of dealing with this: Disallow keepalive in the context of a POST request, or ignore CRLF on a line by itself. Most servers deal with this in the latter way, but there's no way to know how a server will handle it without testing.

 

Java应用

client用apache的commons-httpclient来执行method 。 
用 method.setRequestHeader("Connection" , "Keep-Alive" or "close") 来控制是否保持链接。

 

经常使用的apache、resin、tomcat等都有相关的配置是否支持keep-alive。

 

tomcat中能够设置：maxKeepAliveRequests

 

The maximum number of HTTP requests which can be pipelined until the connection is closed by the server. Setting this attribute to 1 will disable HTTP/1.0 keep-alive, as well asHTTP/1.1 keep-alive and pipelining. Setting this to -1 will allow an unlimited amount of pipelined or keep-alive HTTP requests. If not specified, this attribute is set to 100.

解释1

所谓长链接指创建SOCKET链接后无论是否使用都保持链接，但安全性较差，   
所谓短链接指创建SOCKET链接后发送后接收完数据后立刻断开链接，通常银行都使用短链接

 

解释2

长链接就是指在基于tcp的通信中，一直保持链接，无论当前是否发送或者接收数据。   
而短链接就是只有在有数据传输的时候才进行链接，客户－服务器通讯/传输数据完毕就关闭链接。

 

解释3

长链接和短链接这个概念好像只有移动的CMPP协议中提到了，其余的地方没有看到过。   
通讯方式   
各网元之间共有两种链接方式：长链接和短链接。所谓长链接，指在一个TCP链接上能够连续发送多个数据包，在TCP链接保持期间，若是没有数据包发送，须要双方发检测包以维持此链接。短链接是指通讯双方有数据交互时，就创建一个TCP链接，数据发送完成后，则断开此TCP链接，即每次TCP链接只完成一对 CMPP消息的发送。   
现阶段，要求ISMG之间必须采用长链接的通讯方式，建议SP与ISMG之间采用长链接的通讯方式。

 

解释4

短链接：好比http的，只是链接、请求、关闭，过程时间较短,服务器如果一段时间内没有收到请求便可关闭链接。   
长链接：有些服务须要长时间链接到服务器，好比CMPP，通常须要本身作在线维持。

最近在看“服务器推送技术”，在B/S结构中，经过某种magic使得客户端不须要经过轮询便可以获得服务端的最新信息（好比股票价格），这样能够节省大量的带宽。

 

     传统的轮询技术对服务器的压力很大，而且形成带宽的极大浪费。若是改用ajax轮询，能够下降带宽的负荷（由于服务器返回的不是完整页面），可是对服务器的压力并不会有明显的减小。

 

    而推技术（push）能够改善这种状况。但由于 HTTP链接的特性（短暂，必须由客户端发起），使得推技术的实现比较困难，常见的作法是经过延长http链接的寿命，来实现push。

 

    接下来天然该讨论如何延长 http链接的寿命，最简单的天然是死循环法：

 

    【servlet代码片断】

     public void doGet(Request req, Response res) {

          PrintWriter out = res.getWriter();

          ……

          正常输出页面

          ……

          out.flush();

          while (true) {

                out.print("输出更新的内容");

                out.flush();

                Thread.sleep(3000);

          }

      }

 

     若是使用观察者模式则能够进一步提升性能。

 

     可是这种作法的缺点在于客户端请求了这个servlet后，web服务器会开启一个线程执行servlet的代码，而servlet由迟迟不愿结束，形成该线程也没法被释放。因而乎，一个客户端一个线程，当客户端数量增长时，服务器依然会承受很大的负担。

 

     要从根本上改变这个现象比较复杂，目前的趋势是从web服务器内部入手，用 nio（JDK 1.4提出的java.nio包）改写request/response的实现，再利用线程池加强服务器的资源利用率，从而解决这个问题，目前支持这一非J2EE官方技术的服务器有 Glassfish和 Jetty（后者只是据说，没有用过）。

 

     目前也有一些框架/工具能够帮助你实现推功能，好比pushlets。不过没有深刻研究。

 

     这两天准备学习一下Glassfish中对Comet（彗星：某人给服务器推送技术起的名字）的支持，呵呵。

 

 

poptest是国内惟一一家培养测试开发工程师的培训机构，以学员能胜任自动化测试，性能测试，测试工具开发等工做为目标。若是对课程感兴趣，请你们咨询qq：908821478，咨询电话010-84505200。

HTTP是一个构建在传输层的TCP协议之上的应用层的协议，在这个层的协议，是一种网络交互须要遵照的一种协议规范。

 

HTTP1.0的短链接

HTTP 1.0规定浏览器与服务器只保持短暂的链接，浏览器的每次请求都须要与服务器创建一个TCP链接，服务器完成请求处理后当即断开TCP链接，服务器不跟踪每一个客户也不记录过去的请求。这个过程大概能够描述为：

一、创建链接：首先DNS解析过程。如把域名变成一个ip，若是url不包含端口号，则会使用该协议的默认端口号，HTTP协议的默认端口号为80。而后三次握手创建一个TCP链接；

二、请求：链接成功后，开始向web服务器发送请求，这个请求通常是GET或POST请求。

三、应答：web服务器收到这个请求，进行处理。web服务器会把文件内容传送给响应的web浏览器。包括：HTTP头信息，体信息。

四、关闭链接：当应答结束后，web浏览器与web服务器必须四次握手断开链接，以保证其它web浏览器可以与web服务器创建链接。

 

HTTP1.1的长链接

可是HTTP1.1开始默认创建的是长链接，即一旦浏览器发起HTTP请求，创建的链接不会请求应答以后马上断掉。

 

一、 一个复杂的具有不少HTTP资源的网页会创建多少TCP链接，如何使用这些链接？

二、 已经创建的TCP链接是否会自动断开，时间是多久？

 

对于第一个问题。如今浏览器都有最大并发链接数限制，应该说若是须要，就会尽可能在容许范围内创建更多的TCP持久链接来处理HTTP请求，一样滴，一个TCP持久链接能够不断传输多个HTTP请求，可是若是上一个请求的响应还未收到，则不能处理下一个请求(Pipeling管道技术能够解决这个问题从而进一步提高性能)，因此说不少浏览器其实均可以修改容许最大并发链接数以提高浏览网页的速度。

 

对于第二个问题。问题在于服务器端对于长链接的实现，特别是在对长链接的维护上。FTP协议及SMTP协议中有NOOP消息，这个就能够认为是心跳报文，但HTTP协议没有相似的消息，这样服务器端只能使用超时断开的策略来维护链接。设想超时时间很是短，那么有效空闲时间就很是短，换句话讲：一旦链路上没有数据发送，服务器端很快就关闭链接。

也就是说其实HTTP的长链接很容易在空闲后自动断开，通常来讲这个时间是300s左右。 

 

参考：HTTP/1.0和HTTP/1.1的区别，HTTP怎么处理长链接

参考：HTTP实现长链接（TTP1.1和HTTP1.0相比较而言，最大的区别就是增长了持久链接支持Connection: keep-alive）

参考：老李谈HTTP1.1的长链接

参考：HTTP1.0 HTTP 1.1 HTTP 2.0主要区别

参考：HTTP1.0和HTTP1.1的区别

参考：HTTP 1.1与HTTP 1.0的比较