HTTP1.0和HTTP1.1的区别和联系

长链接&短链接

短链接
HTTP是一种无状态的协议，基于TCP的传输方式传输数据，在HTTP1.0中，服务器为了应对大规模的请求，使用的是短链接的方式进行连接，即浏览器的每次请求都会建立一个TCP连接，服务器完成请求后就立刻断开TCP连接，也就是我的HTTP初探 https://mp.csdn.net/mdeditor/100175799# 这篇博客中的七步，服务器也不会跟踪每个客户也不会记录过去的请求，这样方便了处理大量的连接，但也出现了一些性能上的缺陷。
举一个例子：一个包含有许多图像的网页文件中并没有包含真正的图像数据内容，而只是指明了这些图像的URL地址，当WEB浏览器访问这个网页文件时，浏览器首先要发出针对该网页文件的请求，当浏览器解析WEB服务器返回
的该网页文档中的HTML内容时，发现其中的< img >图像标签后，浏览器将根据< img >标签中的src属性所指定的URL地址再次向服务器发出下载图像数据的请求，如下图所示

显然，如果使用短链接进行数据传输，那么对于这样的一个网页，为了每个小小的img都要耗费资源去新建TCP连接，这显然是很费时的，并且每一次的建立连接和断开连接都是分离的，没有联系。
为了克服HTTP1.0这个缺陷，也就引出了HTTP1.1的长链接。
长链接
HTTP 1.1支持持久连接，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。一个包含有许多图像的网页文件的多个请求和应答可以在一个连接中传输，但每个单独的网页文件的请求和应答仍然需要使用各自的连接。HTTP 1.1还允许客户端不用等待上一次请求结果返回，就可以发出下一次请求，但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果，以保证客户端能够区分出每次请求的响应内容，这样也显著地减少了整个下载过程所需要的时间。基于HTTP 1.1协议的客户机与服务器的信息交换过程，如下图所示。

由此可见，HTTP1.1在继承了HTTP1.0的优点的基础上，也克服了HTTP1.0性能上的一些缺陷，长连接的标识是Connection标志位，如果是keep-alive则表示此次TCP连接是长链接模式，keep-alive无论服务器或是浏览器都是可以发送的，告诉对方不要关闭此次连接，当希望关闭时，Connection标志位将会设置为close，因为是基于TCP协议传输的协议，所以心跳包机制也是可以使用的，用来检测当前连接是否还存活，除此之外，在服务器的应答头信息中会有一个timeout标识，告诉浏览器长链接超时时间，例如：
Keep-Alive：timeout=20 表示这个TCP通道可以保持20秒
Keep-Alive：max=20 表示这个TCP长链接最多接受20次请求就会断开
如果服务器在发送响应头信息并没有说明客户端超时时间，服务器也可以通过四次握手/挥手断开TCP请求，这样客户端就会知晓该TCP连接已经无效

事实上，Connection头域可以携带三种不同类型的符号：

1、一个包含若干个头域名的列表，声明仅限于一次hop连接的头域信息；

2、任意值，本次连接的非标准选项，如Keep-Alive等；

3、close值，表示消息传送完成之后关闭长连接；

HTTP1.1其他方面的更新

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缓存等机制相关的请求头和响应头。

带宽优化
HTTP/1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了。例如，客户端只需要显示一个文档的部分内容，又比如下载大文件时需要支持断点续传功能，而不是在发生断连后不得不重新下载完整的包。

HTTP/1.1中在请求消息中引入了range头域，它允许只请求资源的某个部分。在响应消息中Content-Range头域声明了返回的这部分对象的偏移值和长度。如果服务器相应地返回了对象所请求范围的内容，则响应码为206（Partial Content），它可以防止Cache将响应误以为是完整的一个对象。

另外一种情况是请求消息中如果包含比较大的实体内容，但不确定服务器是否能够接收该请求（如是否有权限），此时若贸然发出带实体的请求，如果被拒绝也会浪费带宽。

HTTP/1.1加入了一个新的状态码100（Continue）。客户端事先发送一个只带头域的请求，如果服务器因为权限拒绝了请求，就回送响应码401（Unauthorized）；如果服务器接收此请求就回送响应码100，客户端就可以继续发送带实体的完整请求了。注意，HTTP/1.0的客户端不支持100响应码。但可以让客户端在请求消息中加入Expect头域，并将它的值设置为100-continue。

节省带宽资源的一个非常有效的做法就是压缩要传送的数据。Content-Encoding是对消息进行端到端（end-to-end）的编码，它可能是资源在服务器上保存的固有格式（如jpeg图片格式）；在请求消息中加入Accept-Encoding头域，它可以告诉服务器客户端能够解码的编码方式。

而Transfer-Encoding是逐段式（hop-by-hop）的编码，如Chunked编码。在请求消息中加入TE头域用来告诉服务器能够接收的transfer-coding方式，

消息传递
HTTP消息中可以包含任意长度的实体，通常使用Content-Length给出消息结束的通知，一般情况下，想要获悉消息的完整长度需要缓存完整的消息才能获悉，但这样获取size()无疑需要很长时间，如果不用长链接的方式，则根据连接关闭的信号来判断消息是否结束，这很不准确。

HTTP/1.1中引入了Chunkedtransfer-coding来解决上面这个问题，发送方将消息分割成若干个任意大小的数据块，每个数据块在发送时都会附上块的长度，最后用一个零长度的块作为消息结束的标志。这种方法允许发送方只缓冲消息的一个片段，避免缓冲整个消息带来的过载。

在HTTP/1.0中，有一个Content-MD5的头域，要计算这个头域需要发送方缓冲完整个消息后才能进行。而HTTP/1.1中，采用chunked分块传递的消息在最后一个块（零长度）结束之后会再传递一个拖尾（trailer），它包含一个或多个头域，这些头域是发送方在传递完所有块之后再计算出值的。发送方会在消息中包含一个Trailer头域告诉接收方这个拖尾的存在。

1.1的Host头域
在这段的一开始有提到，在1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname），但是1.1拓展了功能，它的的请求消息和响应消息都支持Host头域，可以让一台物理服务器同时存在多个虚拟主机，这些虚拟主机共享一个IP，同时，如果使用的是HTTP1.1协议，不添加Host头域则会返回400错误，表示服务器拒绝接受以绝对路径标记的资源请求，也就是必须加上host才认。

错误提示
HTTP/1.0中只定义了16个状态响应码，对错误或警告的提示不够具体。HTTP/1.1引入了一个Warning头域，增加对错误或警告信息的描述。可以更快定位错误位置和错误原因。
此外，在HTTP/1.1中新增了24个状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。

协商传输内容
为了满足互联网使用不同母语和字符集的用户，一些网络资源有不同的语言版本（如中文版、英文版）。HTTP/1.0定义了内容协商（contentnegotiation）的概念，也就是说客户端可以告诉服务器自己可以接收以何种语言（或字符集）表示的资源。例如如果服务器不能明确客户端需要何种类型的资源，会返回300（Multiple Choices），并包含一个列表，用来声明该资源的不同可用版本，然后客户端在请求消息中包含Accept-Language和Accept-Charset头域指定需要的版本。